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

Реляционная таблица имеет третью нормальную форму (ЗНФ), если для любой ФЗ: Х —> Y Х является ключом. Заметим попутно, что из определе­ния следует, что любая таблица, удовлетворяющая ЗНФ, также удовлетво­ряет и 2НФ. Однако обратное неверно, в чем мы сейчас убедимся.

Третья нормальная форма (ЗНФ). Любой детерминант является ключом.

Рассмотрим таблицу WORKER' на рис. 8. Мы видим, что поскольку WORKER-ID является ключом, то в таблице имеются функциональные за­висимости

ФЗ: WORKER-ID -> SKILL-TYPE

ФЗ: WORKER-ID -> BONUS-RATE

Однако также имеется функциональная зависимость

ФЗ: SKILL-TYPE -> BONUS-RATE

Ясно, что первые две функциональные зависимости удовлетворяют кри­терию ЗНФ, но как обстоит дело с последней? Очевидно, что SKILL-TYPE не является ключом, поэтому критерий ЗНФ нарушен. Таким образом, таблица WORKER' не удовлетворяет ЗНФ. Обратите, однако, внимание, что таблица WORKER' удовлетворяет 2НФ (иначе быть не может, так как ключ состоит из одного атрибута). Таким образом, таблица может быть в 2НФ, но не в ЗНФ.

Рис. 8. Таблица WORKER'

Чем плохи таблицы, не удовлетворяющие ЗНФ? Вызванные ими про­блемы схожи с перечисленными для таблиц, нарушающих 2НФ:

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

2. Если размер премиальных для типа специальности изменяется, то тре­буется обновить каждую такую строку. Если строка удаляется, то мы можем потерять информацию о размере премиальных для данной специ­альности. Таким образом, таблица подвержена аномалиям обновления и удаления.

3. Если в какой-то момент времени отсутствуют работники данной специ­альности, то может не оказаться строки, в которой можно хранить раз­мер премиальных. Это аномалия ввода.

К счастью, если мы установили, что таблица удовлетворяет ЗНФ, то мы можем быть уверены, что она удовлетворяет и 2НФ. Но как преобразовать реляционную схему, нарушающую ЗНФ, в набор таблиц, удовлетворяющих ЗНФ? Самый простой метод — разбиение. Им мы пользовались для преобра­зования таблицы, нарушающей 2НФ (ASSIGNMENT на рис. 6), в две таб­лицы, удовлетворяющие 2НФ (рис. 7). Теперь мы покажем, как применять процесс разбиения к таблицам, нарушающим ЗНФ.

Начнем с реляционной схемы WORKER'. Создадим новую таблицу (R1), удалив из WORKER' все атрибуты, стоящие в правой части ФЗ, нарушаю­щие критерий ЗНФ. В нашем примере это ПРЕМИАЛЬНЫЕ (BONUS-RATE). Создадим новую таблицу, состоящую из атрибутов как из левой, так и из правой частей ФЗ, нарушающей критерий ЗНФ. В нашем примере это SKILL-TYPE и BONUS-RATE. Детерминант ФЗ SKILL-TYPE будет ключом. Если мы назовем эту новую таблицу R2, то тогда

R1 {WORKER-ID, SKILL-TYPE)

Внешний ключ: SKILL-TYPE ссылается на R2

и

R2 {SKILL-TYPE, BONUS-RATE}

схемы двух реляционных таблиц, занявших место таблицы WORKER'. Если хотя бы одна из таблиц R1 или R2 нарушает ЗНФ, то мы продолжим процесс разбиения до тех пор, пока все таблицы не будут удовлетворять ЗНФ. В нашем случае и R1, и R2 удовлетворяют ЗНФ, поэтому мы можем остановиться.

Мы разбили таблицу WORKER' на таблицы R1 и R2, каждая из кото­рых удовлетворяет ЗНФ. Вы должны проверить, что обе полученные таб­лицы действительно удовлетворяют ЗНФ. Пожалуйста, обратите внимание, что SKILL-TYPE является внешним ключом в таблице R2.

Поскольку каждая таблица по определению удовлетворяет 1НФ, а также, поскольку ЗНФ-таблицы всегда удовлетворяют 2НФ, то верна следующая цепочка импликаций: