- •Введение
- •Глава 1. Системный анализ предметной области асу «Туристическая фирма»
- •1.1. Анализ объекта автоматизации ооо «Вокруг света»
- •1.2. Обзор информационных технологий, подходящих для разработки бд
- •1.4. Требования к разрабатываемой базе данных
- •2.1. Разработка инфологической модели бд
- •2.2. Обоснование выбора модели данных
- •Сетевая модель
- •Иерархическая модель
- •Объектно-ориентированная модель
- •Реляционная модель
- •2.3. Даталогическое проектирование бд
- •2.4 Нормализация
- •Глава 3. Программная реализация бд туристической фирмы «вокруг света»
- •3.1 Анализ и выбор субд
- •3.2. Физическое проектирование бд
- •3.3 Разработка представлений
- •3.4 Разработка форм
- •3.5 Разработка отчетов
- •3.6. Безопасность и контроль
- •Заключение
- •Список источников и литературы
2.4 Нормализация
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.
Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса поставщика гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Provider и нигде больше.
Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме». Есть и другие уровни нормализации, однако для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы.
Первая нормальная форма
-Устранение повторяющихся групп в отдельных таблицах.
-Создание отдельной таблицы для каждого набора связанных данных.
-Идентификация каждого набора связанных данных с помощью первичного ключа.
Не следует использовать несколько полей в одной таблице для хранения похожих данных. Например, для слежения за товаром, который закупается у двух разных поставщиков, можно создать запись с полями, определяющими код первого поставщика и код второго поставщика.
Вторая нормальная форма
-Создание отдельных таблиц для наборов значений, относящихся к нескольким записям.
-Связать эти таблицы с помощью внешнего ключа.
Записи могут зависеть только от первичного ключа таблицы (составного ключа, если необходимо). Возьмем для примера адрес клиента в системе бухгалтерского учета. Этот адрес необходим не только таблице Customers, но и таблицам Orders, Shipping, Invoices, Accounts Receivable и Collections. Вместо того чтобы хранить адрес клиента как отдельный элемент в каждой из этих таблиц, храните его в одном месте: или в таблице Customers, или в отдельной таблице Addresses.
Третья нормальная форма
- Устранение полей, не зависящих от ключа.
Значения, входящие в запись и не являющиеся частью ключа этой записи, не принадлежат таблице. Если содержимое группы полей может относиться более чем к одной записи в таблице, то нужно поместить эти поля в отдельную таблицу.
Разрабатываемая база данных удовлетворяет данным требованиям.
Выводы
Во рамках курсовой работы была создана новая информационно-логической модель. Затем была построена инфологическая модель предметной области с выделением сущностей и сформулировано их описание.
Для обоснования выбора модели данных были изучены и проанализированы несколько наиболее популярных моделей данных. А именно, сетевая, иерархическая, объектно-ориентированная и реляционная модели. Для каждой из моделей были приведены и учтены все их преимущества и недостатки. Таким образом выбор пал в пользу последней модель.
Реляционная модель данных, построенная на основании инфологической модели. Затем был создан список атрибутов ее отношений и проведена нормализация до третьей нормальной формы. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой информационной системы в одной из реляционных СУБД.