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

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

Вторая нормальная форма применяется к отношениям с составными ключами, т. е. к таким отношениям, первичный ключ которых состоит из двух или более атрибутов. Отношение, у которого первичный ключ включает только один атрибут, всегда находится во 2НФ.

БД находится во 2НФ, если она находится в 1НФ, и каждый неключевой атрибут функционально полно зависит от первичного ключа.

Рассмотрим отношение

КОНСУЛЬТАЦИИ_ДИПЛОМНИКОВ (Таб_Ном_преп, Ном_зач_кн, Дата, ВремяФИО_преп, Должность, ФИО_студ, Тема_диплома,, Аудитория, Вместимость).

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

(Таб_Ном_преп, Ном_зач_кн, Дата Время) → (ФИО_преп, Должность,ФИО_студ, Тема_липлома,, Аудитория, Вместимость).

Описательные атрибуты преподавателя ФИО_преп, Должность зависят только от части первичного ключа. Данную ситуацию определяет зависимость:

Таб-Ном_преп → (ФИО_преп, Должность).

Описательные атрибуты студента ФИО_студ, Тема_диплома также зависят только от части первичного ключа и не зависят от остальных атрибутов ключа, то есть имеется зависимость вида:

Ном_зач_кн → (ФИО_студ. Тема_диплома).

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

Устранение данных отрицательных явлений осуществляется путем декомпозиции исходного отношения на три со следующими схемами:

ПРЕПОДАВАТЕЛЬ (Таб_Ном_преп, ФИО_преп, Должность);

СТУДЕНТ (Ном_зач_кн, ФИО_студ, Тема_диплома);

КОНСУЛЬТАЦИИ (Таб_Ном_преп, Ном_зач_кн, Дата, Время, Аудитория, Вместимость).

 

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

Рассмотрим транзитивную зависимость следующего типа: если А →В, В -/→ А (В не является ключом), В → С, то А → С. В этом случае считается, что С транзитивно зависит от А.

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

Рассмотрим схему базы данных примера предыдущего раздела.

ПРЕПОДАВАТЕЛЬ (Таб_Ном_преп, ФИО_преп, Должность);

СТУДЕНТ (Ном_зач_кн, ФИО_студ, Тема_диплома);

КОНСУЛЬТАЦИИ (Таб_Ном_преп, Ном_зач_кн, Дата, Время, Аудитория, Вместимость).

Последнее отношение содержит транзитивную зависимость:

(Таб_Ном_преп, Ном_зач_кн, Дата) → Аудитория →Вместимость.

Следовательно, это отношение не находится в ЗНФ со всеми вытекающими из этого последствиями, и прежде всего следующими:

􀂃 если аудитория исключается из расписания консультаций, то о ней вообще теряются сведения;

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

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

Таким образом, база данных этого примера, лишенная транзитивных зависимостей, в ЗНФ будет выглядеть так:

ПРЕПОДАВАТЕЛЬ (Таб_Ном_преп, ФИО_преп, Должность);

СТУДЕНТ Ном_зач_кн, ФИО_студ, Тема_диплома);

КОНСУЛЬТАЦИИ (Таб_Ном_преп, Ном_зач_кн, Дата, Время,Аудитория);

АУДИТОРИЯ (Аудитория, Вместимость).

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