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

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

Рассмотрим зависимости между атрибутами отношения ПОСТАВЩИК1.

Каждый из не ключевых атрибутов полностью зависит от первичного ключа П#, но в то же время атрибут Тариф функционально полно зависит только от атрибута Город. Эти атрибуты могут существовать вне зависимости от первичного ключа. Следовательно, это отношение находится не в 3НФ.

В таком отношении также могут возникнуть аномалии включения-удаления. Если потребуется включить в таблицу сведения о новом городе и стоимости перевозок из него, то мы не сможем этого сделать до тех пор, пока в этом городе не появится новый поставщик и не получит свой статус поставщика. До тех пор ему не присвоен код П#, т.е. П# =0 и кортеж, содержащий сведения об этом городе не будет иметь первичного ключа (аномалия включения). Если же предприятие Заря перестанет поставлять нам изделия и потеряет статус поставщика и код П#, то из таблицы придется исключить все сведения о нем, в том числе и те, которые мы хотели бы сохранить, например, стоимость доставки из Самары (аномалия удаления).

Для приведения отношения к 3НФ необходимо выделить в отдельную таблицу не ключевые атрибуты, функционально полно зависящие друг от друга. Таблицу ПОСТАВЩИК1 разделим на две таблицы: ПОСТАВЩИК и ДОСТАВКА.

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

Теперь эти отношения находятся в 3НФ и в БД можно включать сведения о новых городах и тарифах даже в том случае, когда из этих городов пока не делается никаких поставок. Между полученными отношениями существует связь типа 1:М (на стороне 1 находится отношение ДОСТАВКА). Связь осуществляется через атрибут Город.

Таким образом, исходная таблица ПОСТАВКИ2 разделилась на три таблицы: ПОСТАВЩИК, ДОСТАВКА, ПОСТАВКИ. Каждая из таблиц находится в 3НФ. Эти таблицы можно рассматривать в качестве модели данных реляционной БД.