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

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

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

Или другими словами: в 2НФ нет неключевых атрибутов, зависящих от части составного ключа (+ выполняются условия 1НФ).

Пусть наличие компьютера у сотрудника по правилам фирмы зависит от должности (начальник – есть компьютер, подчинённый – нет компьютера). Тогда приведённое на рисунке отношение НЕ находится во 2НФ, т.к. допускает указание наличия компьютера у подчинённого.

Рисунок 3.4.7.1 – Отношение, НЕ находящееся во 2НФ

Чтобы привести это отношение ко 2НФ, нужно разбить его на два отдельных:

Рисунок 3.4.7.2 – Новая схема БД, соответствующая 2НФ

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

• пересмотру состава ключа отношения;

• созданию подчинённого отношения, в которое будут вынесены все те неключевые атрибуты исходного отношения, которые не зависят от ключа исходного отношения.

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

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

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2НФ и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых.

Вспомним: транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A à B и B à C, где A – набор ключевых атрибутов (ключ), B и С – различные множества неключевых атрибутов.

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

Более того: после нескольких лет работы с БД почти невозможно «заставить своё сознание» создать модель БД, не находящейся в 3НФ.

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

Т.о. приведённое ниже отношение НЕ находится в 3НФ.

Рисунок 3.4.8.1 – Отношение, НЕ находящееся в 3НФ

Разбив это отношение на два отдельных, мы получим 3НФ:

Рисунок 3.4.8.2 – Схема БД, соответствующая 3НФ

3.4.9. Нормальная форма Бойса-Кодда

Отношение находится в нормальной форме Бойса-Кодда (НФБК), если оно находится в 3НФ, и в нём отсутствуют зависимости ключевых атрибутов (или их частей) от неключевых атрибутов.

НФБК можно определить и так:

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

Отношение находится в НФБК, если оно находится в 3НФ и каждый детерминант является возможным ключом.

Рассмотрим следующее отношение:

Рисунок 3.4.9.1 – Отношение, НЕ находящееся в НФБК

Курсовые проекты ведут несколько преподавателей по различным дисциплинам, и каждый студент закреплён за одним из них.

Студент выполняет только один проект, а одну и ту же тему проекта могут выполнять несколько студентов, но у разных преподавателей.

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

Преподаватель, Тема;

Предмет, Тема.

Функциональные зависимости:

Преподаватель, Тема à Студент (от ключа)

Предмет, Тема à Студент (от ключа)

Студент à Тема.

Это отношение находится в 3НФ, так как в нём отсутствуют частичные и транзитивные зависимости неключевых атрибутов от ключа.

Однако имеется зависимость части составного ключа Тема от неключевого атрибута Студент, что порождает следующие аномалии:

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

• данные о студенте и его проекте не могут быть занесены в БД до тех пор, пока не назначен руководитель проекта;

• и наоборот, если необходимо удалить руководителя, то будут удалены данные о руководимом им студенте.

Устранение этих аномалий достигается устранением функциональной зависимости части составного ключа от неключевого атрибута (Студент à Тема).

После преобразования мы получим такой набор отношений:

Рисунок 3.4.9.2 – Схема БД, соответствующая НФБК

Вопрос: в чём здесь будет проблема?

Ответ: теперь каждый преподаватель может вести курсовые строго по одному предмету. Если так и надо – OK. Если нет – нужно дальше перерабатывать модель БД.

Однако, есть ещё проблема:

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

Приведённое на рисунке отношение находится в НФБК, но позволяет допустить ошибку: вписать не тот тариф не тому корту.

Рисунок 3.4.9.3 – Отношение в НФБК, допускающее внесение ошибочных данных

Здесь по бизнес-правилам есть только один первичный ключ – {Корт, Сеанс, Тариф}.

Разобьём отношение на два так, чтобы исключить возможность возникновения только что описанной ошибки.

Рисунок 3.4.9.4 – Схема БД, не допускающая внесения ошибочных данных

Обратите внимание!

В первой таблице у нас первичный ключ: Корт + Сеанс (т.к. по здравому смыслу эта комбинация полей должна иметь уникальные значения).

Во второй таблице у нас первичный ключ: Корт + Тариф (т.к. по правилам фирмы эта комбинация полей должна иметь уникальные значения).

Но! При установлении связей осуществляется миграция ВСЕГО первичного ключа из родительской таблицы в дочернюю.

Т.о. мы получим исходное отношение + потеряем автоматическую реализацию вышеназванных правил фирмы и здравого смысла.

«Выкрутиться» можно так: связать отношения ТОЛЬКО по ключу Корт, ввести в таблицу Сеанс суррогатный первичный ключ, а выполнение правил «навесить» на триггеры или хранимые процедуры.