Для упрощения нормализации подобных таблиц целесообразно использовать следующую рекомендацию.
|
Рекомендация. При проведении нормализации таблиц, в которые введены цифровые (или другие) заменители составных и (или) текстовых первичных и внешних ключей, следует хотя бы мысленно подменять их на исходные ключи, а после окончания нормализации снова восстанавливать. |
При использовании этой рекомендации таблицы рис. временно превращаются в таблицы рис. , а после выполнения нормализации и восстановления полей БЛ, ПР и ПОС – в нормализованные таблицы рис. .
|
Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. |
После разделения таблицы Поставщики рис. на две части все таблицы этого проекта удовлетворяют определению 2НФ, а так как в них нет неключевых полей, функционально зависящих друг от друга, то все они находятся в 3НФ.
Как ни странно, этого нельзя сказать об аналогичных таблицах рис . Если забыть рекомендацию о подмене на время нормализации ключей БЛ, ПР и ПОС на Блюдо, Продукт и (Поставщик, Город), то среди этих таблиц появятся две, не удовлетворяющие определению 3НФ. Действительно, так как после ввода первичных ключей БЛ и ПР поля Блюдо и Продукт стали неключевыми – появились несуществовавшие ранее функциональные зависимости между неключевыми полями:
Блюдо->Вид и Продукт->Калорийность.
Следовательно, для приведения таблиц Блюда и Продукты рис. к 3НФ их надо разбить на
Блюда(БЛ, Блюдо), Вид_блюда(БЛ, Вид); Продукты(ПР, Продукт); Калор_прод(ПР,Калорийносить),
хотя интуиция подсказывает, что это лишнее разбиение, совсем не улучшающее проекта базы данных.
Столкнувшись с подобными несуразностями, которые могут возникать не только из-за введения кодированных первичных ключей, теоретики реляционных систем Кодд и Бойс обосновали и предложили более строгое определение для 3НФ, которое учитывает, что в таблице может быть несколько возможных ключей.