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

Рассмотрим схему отношения, содержащего данные о поставках товаров поставщиками, адреса и статуса поставщика. Пусть статус поставщика определяется его адресом:

ПОСТАВКИ (КОД_ПОСТАВЩИКА, СТАТУС, АДРЕС, КОД_ТОВАРА, КОЛИЧЕСТВО)

Первичный ключ:

КОД_ПОСТАВЩИКА, КОД_ТОВАРА

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

КОД_ПОСТАВЩИКА -> СТАТУС,

КОД_ПОСТАВЩИКА -> АДРЕС,

АДРЕС -> СТАТУС,

КОД_ПОСТАВЩИКА, КОД_ТОВАРА -> СТАТУС;

КОД_ПОСТАВЩИКА, КОД_ТОВАРА -> АДРЕС;

КОД_ПОСТАВЩИКА, КОД_ТОВАРА -> КОЛИЧЕСТВО

Как видно, хотя первичным ключом является составной КОД_ПОСТАВЩИКА, КОД_ТОВАРА, атрибуты СТАТУС и АДРЕС функционально зависят от части первичного ключа, т.е. атрибута КОД_ПОСТАВЩИКА. В результате, мы не сможем вставить в отношение ПОСТАВКИ кортеж, описывающий поставщика, который еще не поставляет товары (первичный ключ не может содержать неопределенное значение). При удалении кортежа мы утрачиваем информацию о адресе и статусе поставщика. При изменении адреса поставщика мы будем вынуждены модифицировать все кортежи, содержащие информацию о его поставках, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.

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

Можно произвести следующую декомпозицию отношения ПОСТАВКИ в два отношения ПОСТАВКИ1 и ПОСТАВЩИКИ:

ПОСТАВКИ1 (КОД_ПОСТАВЩИКА, КОД_ТОВАРА, КОЛИЧЕСТВО)

Первичный ключ:

КОД_ПОСТАВЩИКА, КОД_ТОВАРА

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

КОД_ПОСТАВЩИКА, КОД_ТОВАРА ->КОЛИЧЕСТВО

и

ПОСТАВЩИКИ (КОД_ПОСТАВЩИКА, СТАТУС, АДРЕС,)

Первичный ключ:

КОД_ПОСТАВЩИКА

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

КОД_ПОСТАВЩИКА ->СТАТУС;

КОД_ПОСТАВЩИКА ->АДРЕС;

АДРЕС -> СТАТУС

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

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

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

В результате, мы не сможем занести в базу данных информацию, характеризующую город, до тех пор, пока не появится хотя бы один поставщик из этого города. При удалении кортежа, описывающего последнего поставщика из данного города, мы лишимся информации о статусе поставщиков этого города. Чтобы согласованным образом изменить статус,соответствующий данному городу, мы будем вынуждены предварительно найти все кортежи, описывающие поставщиков этого города. Т.е. в отношении ПОСТАВЩИКИ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.

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

Эквивалентным является следующее:

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

Можно произвести декомпозицию отношения ПОСТАВЩИКИ в два отношения ПОСТАВЩИКИ1 и ГОРОДА:

ПОСТАВЩИКИ1(КОД_ПОСТАВЩИКА, АДРЕС,)

Первичный ключ:

КОД_ПОСТАВЩИКА

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

КОД_ПОСТАВЩИКА -> АДРЕС

и

ГОРОДА (АДРЕС,СТАТУС)

Первичный ключ:

АДРЕС

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

АДРЕС -> СТАТУС

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

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