Транзитивные зависимости. Третья нормальная форма (3НФ).

Теперь рассмотрим понятие транзитивной зависимости. Пусть X, Y, Z – атрибуты некоторого отношения. При этом X→Y и Y→Z, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (X→→Z).

Отношение находится в 3НФ, если оно находится во 2НФ и в нем отсутствуют транзитивные зависимости.

Для отношения КНИГИ (табл. 8.3) атрибут Theme зависит от атрибута Code, а не от ключа (хотя название рубрики, естественно, соответствует её шифру). Поэтому для приведения отношения к 3НФ (табл. 8.5) нужно выделить из него ещё одно отношение РУБРИКАТОР (табл. 8.6).

Таблица 8.5. Отношения КНИГИ, приведённые к 3НФ ID Code Title Type Year Pg 22.18 Язык программирования СИ учебник 22.18 Язык АДА учебник 32.97 Операционные системы ЭВМ учебное пособие 32.81 Общение с ЭВМ на естественном языке учебник 32.97 ПУ для ПЭВМ справочник 32.973 Интерфейс «человек-компьютер» учебник

Табл. 8.6. Отношение РУБРИКАТОР Code Theme 22.18 МК 32.97 BT 32.973 ЭВМ 32.81 Кибернетика

Отношения, находящиеся в 3НФ, свободны от аномалий модификации. Но для табл. 8.5 можно ещё вынести в отдельную таблицу поле Тип, чтобы реализовать ограничение на домен для этого поля. Таблица ТИПЫ ИЗДАНИЙ будет состоять из одного поля Название типа, определённого как первичный ключ. Тогда поле Тип таблицы КНИГИ станет внешним ключом.

Примечание: если для атрибутов X,Y,Z есть транзитивная зависимость X →→ Z, и при этом Y → X или Z → Y, то такая зависимость не требует декомпозиции отношения. Например, для отношения АВТОМОБИЛИ с первичным ключом Государственный номерной знак и полями № кузова и № двигателя очевидно, что номера кузова и двигателя зависят как друг от друга, так и от первичного ключа. Но эта зависимость взаимно однозначная, поэтому декомпозиции отношения не нужна.

Четвертая нормальная форма (4НФ).

Введём понятие многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y. Если в отношении есть многозначные зависимости, то схема отношения должна находиться в 4НФ.

Перефразируя вышесказанное, многозначная зависимость (X–»Y) имеет место, если по значению некоторого атрибута (Х) мы можем определить набор значений другого атрибута (Y). Например, зная название страны, мы можем определить названия всех соседних с нею стран.

Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется многозначная зависимость X–»Y, для которой Y d X или X U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется (т.е. Y не является подмножеством X или X U Y состоит не из всех атрибутов R), то такая многозначная зависимость называется нетривиальной.

Отношение находится в 4НФ, если оно находится в 3НФ и в нем отсутствуют нетривиальные многозначные зависимости.

Отрицательный момент в нарушении 4НФ заключается в том, что в одно отношение включаются независящие друг от друга атрибуты. Например, у книги «Язык программирования СИ» (табл. 8.1) два автора и два редактора, но это не значит, что редактор Садчиков редактировал автора Бочкова, а редактор Седов – автора Субботина. А если у книги нет автора или редактора, то соответствующие поля останутся пустыми (null). Т.е. в отношении КНИГИ–АВТОРЫ–РЕДАКТОРЫ (табл. 8.4) атрибуты Author и Editor образуют две многозначные зависимости от ключа, и при этом значения этих атрибутов не зависят друг от друга. Поэтому для приведения отношения к 4НФ нужно разбить его на два отношения КНИГИ–АВТОРЫ и КНИГИ–РЕДАКТОРЫ (табл. 8.7, 8.8).

Таблица 8.7. Отношение КНИГИ–АВТОРЫ (4НФ) ID Author Бочков С. Субботин Д. Джехани Н. Крон Г.1 Гик Е.Я. Фролов Г. Кузнецов Э.

Таблица 8.8. Отношение КНИГИ–РЕДАКТОРЫ (4НФ) ID Editor Садчиков П. Баранов А. Кикоин И. Капица С. Витенберг Э. Храмов А. Рожков П.

Обратите внимание, в отношениях, полученных после приведения к 4НФ, первичный ключ (ПК) состоит из всех атрибутов отношения.

Примечание. Есть ещё т.н. третья усиленная форма (НФБК – нормальная форма Бойса-Кодда) и 5НФ. Описание этих форм можно найти в [1].

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

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

Иногда после нормализации отношений проводят их денормализацию. Обоснованием денормализации может служить требование обеспечения определённой производительности для критических запросов. В нормализованной БД одна сущность ПО разбивается на несколько отношений, и для получения исходного отношения требуется выполнить операцию соединения. Эта операция занимает много времени, поэтому нормализация может привести к падению производительности БД. Денормализация бывает нескольких видов:

1. Восходящая

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

1. Нисходящая

В этом случае информация переносится из родительского отношения в подчинённое. Например, в схеме ДОЛЖНОСТИ <–>> СОТРУДНИКИ можно в качестве внешнего ключа использовать поле Название должности, а не идентификатор. Для этого название в отношении ДОЛЖНОСТИ должно быть определено как unique. Это позволяет избежать соединения отношений при запросе должности сотрудника.

1. 3. Разбиение одного отношения на два.

В одно отношение помещаются все атрибуты сущности, которые связаны с экземпляром сущности как 1:1. Но бывает так, что запись имеет большую длину за счёт наличия атрибутов большого объёма (графические данные, текстовые описания и проч.). Если данные этих атрибутов редко используются, то можно выделить в отдельное отношение атрибуты большого объёма. Для связи с исходным отношением вводится уникальный внешний ключ. А для получения исходного отношения создаётся представление (view), которое является соединением двух полученных отношений.

После нормализации/денормализации получается окончательная концептуальная схема БД, на основе которой проводится физическое про-ектирование. Пример проектирования БД с использованием метода "сущность-связь" и нормализации отношений приведён в [2].

	"Решенные проблемы исчезают в прошлое. Поставленные рожда-ют будущее. В особенности принципиально неразрешимые проблемы. Они вечны. Человек вообще начинается со стремления сделать невоз-можное".
	«Зияющие высоты», Александр Зиновьев, советский философ, логик, социолог, публицист