4.5. Нормальные формы
В п. 4.4 было дано
определение первой нормальной
формы (1НФ). Приведем здесь более
строгое ее определение, а также
определения других нормальных
форм.
| Таблица находится в первой
нормальной форме (1НФ)
тогда и только тогда, когда ни
одна из ее строк не содержит в
любом своем поле более одного
значения и ни одно из ее
ключевых полей не пусто. |
Из таблиц, рассмотренных в п. 4, не
удовлетворяет этим требованиям
(т.е. не находится в 1НФ) только
таблица рис. 4.1.
| Таблица находится во второй
нормальной форме (2НФ),
если она удовлетворяет
определению 1НФ и все ее поля,
не входящие в первичный ключ,
связаны полной функциональной
зависимостью с первичным
ключом. |
Кроме таблицы рис. 4.1
не удовлетворяет этим требованиям
только таблица 4.2.
Как обосновано ниже (пример 4.2) она имеет
составной первичный ключ
Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П
и содержит множество неключевых
полей (Вид, Рецепт, Порций,
Калорийность и т.д.), зависящих лишь
от той или иной части первичного
ключа. Так поля Вид и Рецепт зависят
только от поля Блюдо, Калорийность
– от поля Продукт и т.п.
Следовательно, эти поля не связаны
с первичным ключом полной
функциональной зависимостью.
Ко второй нормальной форме
приведены почти все таблицы рис. 4.3 кроме таблицы
Поставщики, в которой Страна
зависит только от поля Город,
который является частью первичного
ключа (Поставщик, Город). Последнее
обстоятельство приводит к
проблемам при:
- включении данных (пока не
появится поставщик из
Вильнюса, нельзя
зафиксировать, что этот город
Литвы),
- удалении данных (исключение
поставщика может привести к
потере информации о
местонахождении города),
- обновлении данных (при
изменении названия страны
приходится просматривать
множество строк, чтобы
исключить получение
противоречивого результата).
Разбивая эту таблицу на две
таблицы Поставщики и Города (рис. 3.2), можно исключить
указанные аномалии.
Что же касается таблиц рис. 4.4, то ввод в них
отсутствующих в предметной области
цифровых первичных и внешних
ключей формально затрудняет
процедуру выявления
функциональных связей между этими
ключами и остальными полями.
Действительно, легко установить
связь между атрибутом Блюдо и Вид
(блюда): Харчо – Суп, Лобио –
Закуска и т.п., но нет прямой
зависимости между полями БЛ и Вид
(блюда), если не помнить, что
значение БЛ соответствует номеру
блюда.
Для упрощения нормализации
подобных таблиц целесообразно
использовать следующую
рекомендацию.
| Рекомендация. При
проведении нормализации
таблиц, в которые введены
цифровые (или другие)
заменители составных и (или)
текстовых первичных и внешних
ключей, следует хотя бы
мысленно подменять их на
исходные ключи, а после
окончания нормализации снова
восстанавливать. |
При использовании этой
рекомендации таблицы рис. 4.4 временно
превращаются в таблицы рис. 4.3, а после выполнения
нормализации и восстановления
полей БЛ, ПР и ПОС – в
нормализованные таблицы рис. 3.2.
| Таблица находится в третьей
нормальной форме (3НФ),
если она удовлетворяет
определению 2НФ и не одно из ее
неключевых полей не зависит
функционально от любого
другого неключевого поля. |
После разделения таблицы
Поставщики рис. 4.3
на две части все таблицы этого
проекта удовлетворяют определению
2НФ, а так как в них нет неключевых
полей, функционально зависящих
друг от друга, то все они находятся
в 3НФ.
Как ни странно, этого нельзя
сказать об аналогичных таблицах
рис 4.4. Если забыть
рекомендацию о подмене на время
нормализации ключей БЛ, ПР и ПОС на
Блюдо, Продукт и (Поставщик, Город),
то среди этих таблиц появятся две,
не удовлетворяющие определению 3НФ.
Действительно, так как после ввода
первичных ключей БЛ и ПР поля Блюдо
и Продукт стали неключевыми –
появились несуществовавшие ранее
функциональные зависимости между
неключевыми полями:
Блюдо->Вид и Продукт->Калорийность.
Следовательно, для приведения
таблиц Блюда и Продукты рис. 4.4 к 3НФ их надо
разбить на
Блюда(БЛ, Блюдо),
Вид_блюда(БЛ, Вид);
Продукты(ПР, Продукт);
Калор_прод(ПР,Калорийносить),
хотя интуиция подсказывает, что
это лишнее разбиение, совсем не
улучшающее проекта базы данных.
Столкнувшись с подобными
несуразностями, которые могут
возникать не только из-за введения
кодированных первичных ключей,
теоретики реляционных систем Кодд
и Бойс обосновали и предложили
более строгое определение для 3НФ,
которое учитывает, что в таблице
может быть несколько возможных
ключей.
| Таблица находится в нормальной
форме Бойса-Кодда (НФБК),
если и только если любая
функциональная зависимость
между его полями сводится к
полной функциональной
зависимости от возможного
ключа. |
В соответствие с этой
формулировкой таблицы Блюда и
Продукты рис. 4.4,
имеющие по паре возможных ключей
(БЛ и Блюдо) и (ПР и Продукт)
находятся в НФБК или в 3НФ.
В следующих нормальных формах (4НФ
и 5НФ) учитываются не только
функциональные, но и многозначные
зависимости между полями таблицы.
Для их описания познакомимся с
понятием полной декомпозиции
таблицы.
| Полной
декомпозицией таблицы
называют такую совокупность
произвольного числа ее
проекций, соединение которых
полностью совпадает с
содержимым таблицы. |
Например, естественным
соединением (см. п. 3.3)
таблиц рис. 4.3 можно
образовать исходную таблицу,
приведенную на рис. 4.2.
Ту же таблицу можно получить
композицией таблиц рис. 3.2. Следовательно,
таблицы рис. 4.3, 4.4 и 3.2
являются полными декомпозициями
таблицы Питание рис. 4.2.
Теперь можно дать определения
высших нормальных форм. И сначала
будет дано определение для
последней из предложенных – 5НФ.
| Таблица находится в пятой
нормальной форме (5НФ)
тогда и только тогда, когда в
каждой ее полной декомпозиции
все проекции содержат
возможный ключ. Таблица, не
имеющая ни одной полной
декомпозиции, также находится
в 5НФ. |
Четвертая нормальная форма (4НФ)
является частным случаем 5НФ, когда
полная декомпозиция должна быть
соединением ровно двух проекций.
Весьма не просто подобрать
реальную таблицу, которая
находилась бы в 4НФ, но не была бы в
5НФ.
[Назад] [Содержание] [Вперед]
|