4.6. Итоговая схема процедуры нормализации

Основные правила процедуры нормализации для проектирования БД содержат следующие пункты:

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

2. Отношения в 2НФ разбиваем на проекции для исключения любых транзитивных ФЗ. Получим набор отношений в 3НФ.

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

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

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

4.7. Альтернативный набор определений нфбк, 4нф и 5нф

• Отношение R находится в НФБК тогда и только тогда, когда каждая функциональная зависимость подразумевается потенциальными ключами отношения R.

• Отношение R находится в 4НФ тогда и только тогда, когда каждая МЗЗ подразумевается потенциальными ключами отношения R.

• Отношение R находится в 5НФ тогда и только тогда, когда каждая зависимость соединения подразумевается потенциальными ключами отношения R.

4.8. Выделим цели процесса нормализации

Проведение процесса нормализации приводит к следующему результату:

1. Исключаются некоторые типы избыточности.

2. Устраняются некоторые аномалии обновления.

3. Обеспечивается проектирование макета БД, который являлся бы «хорошим» представлением реального мира, для дальнейшего развития.

4. Упрощается процесс наложения ограничения целостности. Нормализация действительно может помочь привезти в действие ограничения целостности, но помимо зависимостей соединения, ФЗ и МЗЗ, существует также другие типы ограничений, которые встречаются на практике.

4.9. Другие нормальные формы

Рассмотрим в качестве примера описание других двух нормальных форм.

1. Доменно-ключевая нормальная форма – ДКНФ. Она была предложена Фейгиным. В отличие от рассмотренных форм, она не определяется на основе ФЗ, МЗЗ и ЗС. Отношение R находится в ДКНФ тогда и только тогда, когда каждое ограничение, наложенное на R, является логическим следствием ограничения доменов и ограничений ключей, наложенных на отношения R.

Ограничение домена – это ограничение на использование значений для данного атрибута из некоторого предписанного домена.

Ограничение ключа – это ограничение на то, что некоторый атрибут или некоторая комбинация атрибутов представляют собой потенциальный ключ.

Фейгин показал, что любое отношение, находящееся в ДКНФ, находится в 5НФ (а значит и в 4НФ), а также в форме 3НФ.

2. Нормальная форма типа «выборка-объединение».

Зачем хранить сведения обо всех поставщиках в отношении S? Может быть, лучше разместить данные о поставщиках из Москвы в одном отношении (например, МS), из Пскова – в другом (например, ПS) и т.д.? То есть, может, стоило бы рассмотреть возможность декомпозиции на основе выборок по строкам, а не проекцией?

В заключение следует отметить, что дальнейшие исследования в области теории нормализации, точнее, теории зависимостей, остаются одним из самых субъективных разделов проектирования БД, для которого необходимо создать более твердые принципы и методики.