BPwin и Erwin. CASE-средства для разработки информационных систем

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

первая нормальная форма (1NF);

вторая нормальная форма (2NF);

третья нормальная форма (3NF);

нормальная форма Бойса - Кодда (усиленная 3NF);

четвертая нормальная форма (4NF);

пятая нормальная форма (5NF).

На практике обычно ограничиваются приведением данных к третьей нормальной форме (полная атрибутивная модель, FA, см. 2.2.1). В данном подразделе будут достаточно кратко рассмотрены первые три нормальные формы и, в качестве иллюстрации, четвертая нормальная форма.

Для углубленного изучения нормализации следует рекомендовать книгу К. Дж. Дейта "Введение в системы баз данных" (Киев;М.:Диалектика, 1998).

Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин "зависимость"). Приведем формальное определение для функциональной зависимости.

Функциональная зависимость (FD). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение А в Е связало с ним точно одно значение В в Е, т. е. А однозначно определяет В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

Рис. 2.47. Ненормализованная сущность "Сотрудник"

На рис. 2.47 в сущности Сотрудник значение атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество зависят от атрибута Табельный номер. Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибут Оклад зависит от атрибута Должность; если оклад зависит еще, например, от стажа, то такой зависимости нет. В нижеследующих примерах будем считать для определенности, что такая зависимость есть.

Рассмотрим нормальные формы.

Первая нормальная форма (1NF). Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е. несколько значений для каждого экземпляра. На рис, 2 47 атрибуты Телефон и Хобби являются нарушением первой нормальной формы. Что будет, если у сотрудника несколько рабочих телефонов? Запись значения колонки через разделитель, например "124-56-78, 124-56-79, 124-56-90" или "Аквалангист, мотоциклист, шахматист", приводит к ряду проблем. Размера поля может не хватить для хранения данных (нельзя увеличивать список телефонов до бесконечности), по такой колонке невозможно построить индекс и т. д. и т. п. Сущность, приведенная на рис. 2.48, не является решением проблемы. Что будет, если у сотрудника появится четвертый телефон или третье хобби? Эту информацию будет негде хранить.

Рис. 2.48. Еще один пример ненормализованной сущности

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

Для приведения сущности к первой нормальной форме следует:

разделить сложные атрибуты на атомарные,

создать новую сущность,

перенести в нее все "повторяющиеся" атрибуты,

выбрать возможный ключ для нового РК (или создать новый РК).

установить идентифицирующую связь от прежней сущности к новой, РК прежней сущности станет внешним ключом (FK) для новой сущности.

На рис. 2.49 показана сущность Сотрудник, приведенная к первой нормальной форме.

Рис. 2.49. Сущность "Сотрудник", приведенная к первой нормальной форме