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

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

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

Произведем следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:

 

СОТРУДНИКИ-ОТДЕЛЫ(СОТРУДНИК, ЗАРПЛАТА, ОТДЕЛ)

Первичный ключ: СОТРУДНИК

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

СОТРУДНИК–>ЗАРПЛАТА

СОТРУДНИК–>ОТДЕЛ

ОТДЕЛ–>ЗАРПЛАТА

СОТРУДНИКИ-ПРОЕКТЫ(СОТРУДНИК, ПРОЕКТ, ЗАДАНИЕ)

Первичный ключ: (СОТРУДНИК, ПРОЕКТ).

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

(СОТРУДНИК, ПРОЕКТ)–>CОТР_ЗАДАН

 

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

Если допустить наличие нескольких ключей, то определение 2NF примет следующий вид:

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

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

 

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

Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТРУДНИК–> ЗАРПЛАТА является транзитивной; она является следствием функциональных зависимостей СОТРУДНИК–>ОТДЕЛ и ОТДЕЛ–>ЗАРПЛАТА. Другими словами, заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает. В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела. То есть в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.

Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится во 2NF и не содержит транзитивных зависимостей.

Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

 

СОТРУДНИКИ (СОТРУДНИК, ОТДЕЛ)

Первичный ключ: СОТРУДНИК

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

СОТРУДНИК–>ОТДЕЛ

ОТДЕЛЫ(ОТДЕЛ, ЗАРПЛАТА)

Первичный ключ: ОТДЕЛ

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

ОТДЕЛ–>ЗАРПЛАТА

 

Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.

Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму:

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

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

 

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

Рассмотрим следующий пример схемы отношения:

 

СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ФИО, ПРОЕКТ, ЗАДАНИЕ)

Возможные ключи: (СОТР_НОМЕР, ПРОЕКТ), (СОТР_ФИО, ПРОЕКТ)

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

(СОТР_НОМЕР, ПРОЕКТ)–>CОТР_ЗАДАН

(СОТР_ФИО, ПРОЕКТ)–>CОТР_ЗАДАН

СОТР_НОМЕР–>ПРОЕКТ

СОТР_ФИО–>ПРОЕКТ

СОТР_НОМЕР–>CОТР_ФИО

СОТР_ФИО–>CОТР_НОМЕР

 

В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем (это не вполне корректное предположение, но достаточное для примера).

Отношение СОТРУДНИКИ-ПРОЕКТЫ находится в 3NF. Две последние зависимости означают, что имеются неполные функциональные зависимости от возможного ключа атрибута, который является частью другого возможного ключа. Это также приводит к аномалиям. Например, для того чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все кортежи, включающие его номер.

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

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

Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:

 

СОТРУДНИКИ(СОТР_НОМЕР, СОТР_ФИО)

Возможные ключи: СОТР_НОМЕР и СОТР_ФИО.

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

СОТР_НОМЕР–>CОТР_ФИО

СОТР_ФИО–>СОТР_НОМЕР

СОТРУДНИКИ-ПРОЕКТЫ(СОТР_НОМЕР, ПРОЕКТ, ЗАДАНИЕ)

Возможный ключ: (СОТР_НОМЕР, ПРОЕКТ)

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

(СОТР_НОМЕР, ПРОЕКТ)–>ЗАДАНИЕ

Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ФИО. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны отмеченные аномалии. Однако первый вариант предпочтительней, т.к. при изменении фамилии сотрудника модифицируется только один кортеж отношения СОТРУДНИКИ.

 

Поддержка целостности БД

 

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1, 2, 3, 4, 5, 6, 7).

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

Выделяют три группы правил целостности:

- Целостность по сущностям.

- Целостность по ссылкам.

- Целостность, определяемая пользователем.

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

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

Значение внешнего ключа должно либо:

- быть равным значению первичного ключа цели;

- быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.

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

- уникальность тех или иных атрибутов,

- диапазон значений (экзаменационная оценка от 2 до 5),

- принадлежность набору значений (пол «М» или «Ж»).