Нормализация

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

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

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

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

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

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

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

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

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

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

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

Первая нормальная форма (1NF). Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е. несколько значений для каждого экземпляра.

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

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

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

· перенести в нее все «повторяющиеся» атрибуты;

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

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

Вторая нормальная форма (2NF). Сущность находится во второй нормальной форме, если она удовлетворяет ограничениям первой нормальной формы, и каждый неключевой атрибут полностью зависит от первичного ключа (не должно быть зависимости от части ключа). Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первичный ключ.

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

· выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность;

· поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность;

· установить идентифицирующую связь от прежней сущности к новой.

Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).

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

· создать новую сущность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

· использовать атрибут(ы), определяющий эту зависимость, в качестве первичного ключа новой сущности;

· установить неидентифицирующую связь от новой сущности к старой .

Поддержка нормализации в ERwin. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила «один факт – в одном месте». Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

Денормализация

В результате нормализации все взаимосвязи данных становятся правильно определенными, исключаются аномалии при оперировании данными, модель данных становится легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Например, для получения полной информации, о сотруднике из ненормализованной структуры данных достаточно обратиться к одной таблице. После приведения структуры данных к третьей нормальной форме информация о сотруднике может содержаться уже в четырех таблицах. Хотя общее количество строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу базы данных необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много раз превосходить время выполнения запроса к одной таблице; другими словами, в приведенном примере общая производительность ИС в результате нормализации, скорее всего, упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.

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

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

Для поддержки денормализации ERwin позволяет создавать сущности, атрибуты, ключи и домены только на уровне логической модели, включив в соответствующих редакторах опцию Logical Only. Такие объекты не будут отображаться на уровне физической модели, и не будут создаваться при генерации базы данных. С другой стороны, таблицы, колонки, домены и индексы можно создавать только на уровне физической модели (опция Physical Only).