3.3 Нормализация таблиц

Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.

Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.

Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).

Отношение находится в первой нормальной форме (см. рис. 3.6) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

Название аптеки

№ аптеки

Адрес аптеки

Телефон аптеки

Лицензия

Владелец

Название изготовителя

Телефон изготовителя

Адрес изготовителя

Название препарата

Дата изготовления

Рецепт

Тип

Название медикамента

Дата поступления

Кол-во

Цена

Рисунок 3.6 – Первая нормальная форма

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и при этом любой его атрибут, не входящий в состав потенциального ключа, функционально полно зависит от каждого возможного ключа.

Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

1. Отношение R (таблица) находится во второй нормальной форме.

2. Каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых На рисунке 3.7 отображены таблицы «Поступление», «Изготовитель», «Владелец», приведенные к третьей нормальной форме.

Рисунок 3.7 – Третья нормальная форма

4 Программная реализация системы

Программная реализация системы это последний этап проектирования БД. Физическое проектирование – это реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных. Эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД.

Физическое проектирование становится возможным, когда все объекты могут быть представлены отдельными таблицами, причем каждая из таблиц уже находится в третьей нормальной форме.

Переход от логического к физическому описанию модели состоит из следующих шагов:

1. Все простые объекты превращаются в отношения, имя объекта становится именем отношения.

2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать NULL -значения.

3. Компоненты уникального идентификатора объекта превращаются в первичный ключ отношения.

4. Связи "1: ∞ " становятся внешними ключами.

В таблицах, построенных на основе ассоциаций, внешние ключи используются для идентификации участников ассоциаций, а в таблицах, построенных на основе характеристик, внешние ключи используются для идентификации сущностей, описываемых этими характеристиками:

1. Разрешение проблемы наличия подтипов.

2. Выполнение шагов по нормализации полученных отношений. Имеющаяся модель находится в третьей нормальной форме.

3. Указание ограничений целостности проектируемой базы данных и краткое описание полученных таблиц и их полей.

Учитывая прямое соответствие логической модели и физической реализации, последняя четко отражает первую, внося некоторые уточнения по способу хранения информации.