Нормализация – это процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели
Нормализация позволяет быть уверенным, что
каждый атрибут определен для своей сущности;
значительно сократить объем памяти для хранения информации ;
устранить аномалии в организации хранения данных.
В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте.
Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных.
Известно 6 нормальных форм:
На практике обычно ограничиваются приведением данных к третьей нормальной форме.
Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин «зависимость»).
Функциональная зависимость (FD). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение А в Е связано с точно одним значением В в Е, т.е. А однозначно определяет В.
Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.
На рис. 1. в сущности Сотрудник значения атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер стотрудника, т.е. атрибуты Фамилия, Имя и Отчество зависят от атрибута Код сотрудника.
Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибут Оклад зависит от атрибута Должность; если оклад зависит еще, например, от стажа, то такой зависимости нет.
Рис. 1. Ненормализованная сущность Сотрудник
Рассмотрим подробнее нормальные формы.
Первая нормальная форма (1NF). Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения.
Среди атрибутов не должно встречаться повторяющихся групп, т.е. несколько значений для каждого экземпляра.
На рис. 1. атрибуты Телефон и Хобби являются нарушением первой нормальной формы, если у сотрудника несколько рабочих телефонов. Можно записать значения атрибутов через разделитель, например через запятую (25-26-27, 25-26-28, 25-26-29). Но такой вид записи приводит к ряду проблем: может не хватить размера поля, по такой колонке невозможно построить индекс и т.д.
Сущность, приведенная на рис. 2 – не является решением проблемы.
Рис. 2. Пример нарушения первой нормальной формы
У сотрудника может появиться четвертый телефон или третье хобби, и эту информацию будет негде хранить.
Существует еще одна ошибка нормализации – хранение в одном атрибуте разных по смыслу значений. На рис. 1. Атрибут Дата зачисления или увольнения хранит информацию как о зачислении, так и об увольнении сотрудника. Если хранится только одно значение, то невозможно понять, какая именно дата внесена.
Для приведения сущности к первой нормальной форме следует:
Откройте файл Модели\7\1.er1.
Обратимся к нашей сущности Сотрудник (рис.1).
Рассмотрим тщательно все ее атрибуты. Все ли они атомарные? Все, кроме атрибутов телефон и хобби.
Как и в приведенном выше примере, может оказаться, что необходимо хранить информацию о нескольких телефонах сотрудника (2 или 3 телефона) и нескольких хобби.
Следовательно, нам необходимо привести сущность к первой нормальной форме. Для этого выполните следующие действия:
Шаг 1. Создайте новую сущность (с помощью щелчка по соответствующей кнопке на палитре инструментов).
Шаг 2. Присвойте ей имя Телефон
Шаг 3. Перетащите из сущности Сотрудник во вновь созданную сущность атрибут телефон.
Шаг 4. Назначьте атрибут Номер телефона первичным ключом
Шаг 5. Установите идентифицирующую связь от сущности Сотрудник к сущности Телефон.
Шаг 6. Аналогично поступите с атрибутом хобби.
Результат выполнения задания представлен на рис. 3.
Рис. 3. Результат нормализации сущности Сотрудник
Вторая нормальная форма (2NF). Сущность находится во второй нормальной форме, если она находится в первой нормальной форме, и каждый неключевой атрибут полностью зависит от первичного ключа (не должно быть зависимости от части ключа).
Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первый ключ.
Предположим, сущность Проект содержит информацию о проекте, которым руководит сотрудник, причем информация содержится как непосредственно о проекте, так и о руководителе проекта (рис. 4).
Рис. 4. Сущность Проект
Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута Табельный номер , но вовсе не от Номер проекта. Т.е. существует зависимость только от части первичного ключа.
Для приведения сущности ко второй нормальной форме следует:
Рис. 5. Сущность проект приведенная ко второй нормальной форме
Вторая нормальная форма позволяет избежать следующих аномалий при выполнении операций:
Третья нормальная форма (NF3). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).
На рис. 3 сущность Сотрудник находится во второй нормальной форме (имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части ключа), но, допустим, что неключевой атрибут Оклад зависит от другого неключевого атрибута – Должность, т.е. одному значению атрибута Должность соответствует одно значение атрибута Оклад - налицо нарушение 3 нормальной формы.
Для приведения сущности к третьей нормальной форме следует:
Рис. 6. Сущность Сотрудник, приведенная к третьей нормальной форме
В нашем случае, как и в рассмотренном примере, в сущности Сотрудник присутствует атрибут Оклад, который зависит от атрибута Должность. Для приведения сущности Сотрудник к третьей нормальной форме необходимо ликвидировать эту взаимозависимость.
Шаг 1. Создайте новую сущность (с помощью щелчка по соответствующей кнопке на палитре инструментов).
Шаг 2. Назовите новую сущность Должность.
Шаг 3. Перенесите из сущности Сотрудник в новую сущность Должность атрибут Оклад.
Шаг 4. Перенесите из сущности Сотрудник в новую сущность Должность атрибут Должность в качестве первичного ключа.
Шаг 5. Установите неидентифицирующую связь от сущности Должность к сущности Сотрудник (первичный ключ Должность сущности Должность должен мигрировать в состав неключевых атрибутов сущности Сотрудник).
Результат выполнения представлен на рис. 6.
Ответьте на следующие вопросы и покажите преподавателю результат выполнения лабораторной работы.