Нормализация баз данных

Печать
Рейтинг пользователей: / 1
ХудшийЛучший 

Нормализация базданных.

Имеются ввиду не "нормальные таблицы", а нормальные формы базы данных.

 Это способ представления и законы, по которым строятся реляционные базы данных, созданные

 Э. Ф. Коддом. Процесс преобразования базы данных из более низшей в более высшую нормальную

 форму называется нормализацией БД. Нормализация осуществляется с целью оптимизации объема

 БД, быстродействия запросов и т.п. Вообще-то нормальных форм 5, но реально, на практике,

используются 3 нормальные формы, точнее база данных в третьей нормальной форме (3НФ).


Ключи

Ключом (key) называется набор атрибутов, однозначно определяющий запись. Существуют пять типов ключей: возможные ключи (candidate keys), первичные ключи (primary keys), альтернативные ключи (alternate keys), общие ключи (common keys) и внешние ключи (foreign keys). Ключи также делятся на два класса: простые (singleton) и составные (composite).

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

Возможные ключи

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

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

Первичные ключи

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

Альтернативные ключи

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

Общие ключи

Общим ключом называется любой атрибут, используемый для объединения двух таблиц. Как правило, общие ключи являются внешними. Если в таблице имеются общие ключи, которые не являются внешними, вероятно, база данных не была нормализована.

Внешние ключи

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


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

Нормализацией называется процесс удаления избыточных данных. Каждый элемент данных должен храниться в базе в одном и только одном экземпляре. Существует пять распространенных форм нормализации, основанных на математической теории отношений. Как правило, база данных приводится к третьей нормальной форме. Различные формы нормализации таковы:

·  Первая нормальная форма - удаление повторяющихся групп.

·  Вторая нормальная форма - удаление избыточных данных.

·  Третья нормальная форма - удаление атрибутов, не зависящих от первичного ключа.

·  Четвертая нормальная форма - изоляция независимых множественных отношений.

·  Пятая нормальная форма - изоляция семантически связанных множественных отношений.

Большинство баз данных нормализуются в третьей нормальной форме.

 Обычно это приводит к увеличению числа сущностей, обладающих меньшим количеством атрибутов.

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

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


Первая нормальная форма

Чтобы преобразовать сущность в первую нормальную форму, следует исключить повторяющиеся группы и добиться того, чтобы каждый атрибут содержал только одно значение. Другими словами, каждый атрибут должен храниться в сущности лишь в одном экземпляре. Сущность <Дом> на рис. 2.8 не нормализована. В частности, она не соответствует первой нормальной форме, поскольку в ней присутствуют повторяющиеся атрибуты для хранения данных о владельце.

Чтобы атрибуты Владелец 1-Владелец N на рис. 2.8 не повторялись, следует создать отдельную сущность для каждого набора атрибутов; в результате у вас появятся две сущности. На рис. 2.9 показана сущность <Дом> после преобразования в первую нормальную форму.

Вторая нормальная форма

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

Рис. 2.8. Ненормализованная сущность

Рис. 2.9. Первая нормальная форма

Продолжим предыдущий пример. В модели, изображенной на рис. 2.9, атрибут <Цена чая> не имеет ничего общего с домовладельцем. Кроме того, атрибут <Мэр> не зависит от всего первичного ключа. Следовательно, сущность <Дом> не соответствует требованиям второй нормальной формы.

Чтобы исправить модель данных, мы удаляем атрибут <Цена чая> (эта информация в дальнейшем не отслеживается) и переносим атрибут <Мэр> в отдельную сущность. На рис. 2.10 та же база данных изображена во второй нормальной форме.

Третья нормальная форма

В третьей нормальной форме исключаются атрибуты, не зависящие от всего ключа. Любая сущность, находящаяся в третьей нормальной форме, заведомо находится во второй нормальной форме. Это самая распространенная форма баз данных. Для запоминания можно воспользоваться формулой: каждый атрибут зависит от ключа, от всего ключа и ни от чего, кроме ключа. Любая сущность, находящаяся во второй нормальной форме и не имеющая составного первичного ключа, автоматически находится в третьей нормальной форме.

Пример: хотя у каждого человека имеется определенный знак зодиака, этот знак зависит от даты рождения и потому не должен находиться в той же сущности, что и остальные данные об этом человеке. На рис. 2.11 изображена база данных <Дом> в третьей нормальной форме.

Рис. 2.10. Вторая нормальная форма

Рис. 2.11. Третья нормальная форма


НФБК

Между третьей и четвертой формами существует еще одна разновидность - нормальная форма Бойса-Кодда (НФБК). В соответствии с ее требованиями при наличии нескольких возможных ключей для каждого из них создается отдельная сущность. Чтобы сущность соответствовала НФБК, она должна находиться в третьей нормальной форме. Любая сущность с единственным возможным ключом, соответствующая требованиям третьей нормальной формы, автоматически находится в НФБК.

 ·  Четвертая нормальная форма

В четвертой нормальной форме изолируются многозначные зависимости. Многозначная зависимость возникает в случае, когда два полностью независимых атрибута объединяются третьим атрибутом (обычно ключевым). Чтобы сущность соответствовала четвертой нормальной форме, она должна заведомо соответствовать третьей нормальной форме или НФБК.

Рис. 2.12. Сущность <Фильм>

Сущность на рис. 2.12 находится в нормальной форме Бойса-Кодда, а все ее атрибуты являются ключевыми. Однако она не соответствует четвертой нормальной форме, поскольку каждый из атрибутов <Режиссер> и <Актер> зависит от атрибута <Название>, но между этими атрибутами не существует отношения.

У фильма может быть много режиссеров и актеров, не зависящих друг от друга. Режиссер может снимать несколько картин, а актер может сниматься в нескольких фильмах. Чтобы сущность <Фильм> соответствовала четвертой нормальной форме, ее необходимо разделить на две сущности (рис. 2.13).

Пятая нормальная форма

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

Рис. 2.13. Нормализация сущностей <Фильм>


Целостность данных

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

·  Целостность сущностей. Каждая запись сущности должна обладать уникальным идентификатором и содержать данные.

·  Целостность доменов. Каждый атрибут принимает лишь допустимые значения.

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

·  Пользовательские правила целостности. Любые правила целостности, не относящиеся ни к одной из перечисленных выше категорий.


Деловые правила

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

Физическая модель

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

Преобразование логической модели в физическую

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

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

·  Каждая таблица должна иметь уникальный идентификатор (первичный ключ).

·  Все данные таблицы должны относиться к одной сущности.

·  Желательно избегать атрибутов, способных принимать неопределенные значения.

·  Таблица не должна содержать повторяющихся полей.