Нормальные формы

Каждая нормальная форма ограничивает определенный тип функциональной зависимости и устраняет соответствующие аномалии при работе с БД.

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

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто.

Из таблиц, рассмотренных в п. 4, не удовлетворяет этим требованиям (т.е. не находится в 1НФ) только таблица рис. 4.1.

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

Кроме таблицы рис. 4.1 не удовлетворяет этим требованиям только таблица 4.2.

Как обосновано ниже (пример 4.2) она имеет составной первичный ключ

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П

и содержит множество неключевых полей (Вид, Рецепт, Порций, Калорийность и т.д.), зависящих лишь от той или иной части первичного ключа. Так поля Вид и Рецепт зависят только от поля Блюдо, Калорийность – от поля Продукт и т.п. Следовательно, эти поля не связаны с первичным ключом полной функциональной зависимостью.

Ко второй нормальной форме приведены почти все таблицы рис. 4.3 кроме таблицы Поставщики, в которой Страна зависит только от поля Город, который является частью первичного ключа (Поставщик, Город). Последнее обстоятельство приводит к проблемам при:

включении данных (пока не появится поставщик из Вильнюса, нельзя зафиксировать, что этот город Литвы),

удалении данных (исключение поставщика может привести к потере информации о местонахождении города),

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

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

Лом.

1/9/94

Фасоль

"Хуанхэ"

Пекин

Китай

0.37

24/8/94

Лук

"Наталка"

Киев

Украина

0.52

27/8/94

Масло

"Лайма"

Рига

Латвия

1.55

30/8/94

Зелень

"Даугава"

Рига

Латвия

0.99

30/8/94

Харчо

Суп

...

1/9/94

Мясо

"Наталка"

Киев

Украина

2.18

27/8/94

Лук

"Наталка"

Киев

Украина

0.52

27/8/94

Томаты

"Полесье"

Киев

Украина

0.45

27/8/94

Рис

"Хуанхэ"

Пекин

Китай

0.44

24/8/94

Масло

"Полесье"

Киев

Украина

1.62

27/8/94

Зелень

"Наталка"

Киев

Украина

0.88

27/8/94

Шашлык

Горячее

...

1/9/94

Мясо

"Юрмала"

Рига

Латвия

2.05

30/8/94

Лук

"Полесье"

Киев

Украина

0.61

27/8/94

Томаты

"Полесье"

Киев

Украина

0.45

27/8/94

Зелень

"Даугава"

Рига

Латвия

0.99

30/8/94

Кофе

Десерт

...

1/9/94

Кофе

"Хуанхэ"

Пекин

Китай

2.87

24/8/94

Рис. 4.1. Данные, необходимые для создания базы данных "Питание"

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

Лом.

1/9/94

Фасоль

"Хуанхэ"

Пекин

Китай

0.37

24/8/94

Лобио

Закуска

Лом

1/9/94

Лук

"Наталка"

Киев

Украина

0.52

27/8/94

Лобио

Закуска

Лом

1/9/94

Масло

"Лайма"

Рига

Латвия

1.55

30/8/94

Лобио

Закуска

Лом

1/9/94

Зелень

"Даугава"

Рига

Латвия

0.99

30/8/94

Харчо

Суп

...

1/9/94

Мясо

"Наталка"

Киев

Украина

2.18

27/8/94

Харчо

Суп

...

1/9/94

Лук

"Наталка"

Киев

Украина

0.52

27/8/94

Харчо

Суп

...

1/9/94

Томаты

"Полесье"

Киев

Украина

0.45

27/8/94

Харчо

Суп

...

1/9/94

Рис

"Хуанхэ"

Пекин

Китай

0.44

24/8/94

Харчо

Суп

...

1/9/94

Масло

"Полесье"

Киев

Украина

1.62

27/8/94

Харчо

Суп

...

1/9/94

Зелень

"Наталка"

Киев

Украина

0.88

27/8/94

Шашлык

Горячее

...

1/9/94

Мясо

"Юрмала"

Рига

Латвия

2.05

30/8/94

Шашлык

Горячее

...

1/9/94

Лук

"Полесье"

Киев

Украина

0.61

27/8/94

Шашлык

Горячее

...

1/9/94

Томаты

"Полесье"

Киев

Украина

0.45

27/8/94

Шашлык

Горячее

...

1/9/94

Зелень

"Даугава"

Рига

Латвия

0.99

30/8/94

Кофе

Десерт

...

1/9/94

Кофе

"Хуанхэ"

Пекин

Китай

2.87

24/8/94

Рис. 4.2. Универсальное отношение "Питание"

Блюда

Рецепты

Расход

Блюдо

Вид

Блюдо

Рецепт

Блюдо

Порций

Дата_Р

Лобио

Закуска

Лобио

Ломаную очищ

Лобио

1/9/94

Харчо

Суп

...

...

Харчо

1/9/94

Шашлык

Горячее

Шашлык

1/9/94

Кофе

Десерт

Кофе

1/9/94

...

...

...

...

...

Продукты

Состав

Поставщики

Продукт

Калор.

Блюдо

Продукт

Вес (г)

Поставщик

Город

Страна

Фасоль

Лобио

Фасоль

"Полесье"

Киев

Украина

Лук

Лобио

Лук

"Наталка"

Киев

Украина

Масло

Лобио

Масло

"Хуанхэ"

Пекин

Китай

Зелень

Лобио

Зелень

"Лайма"

Рига

Латвия

Мясо

Харчо

Мясо

"Юрмала"

Рига

Латвия

...

...

...

...

...

...

...

...

Поставки

Поставщик

Город

Продукт

Вес (кг)

Цена ($)

Дата_П

"Полесье"

Киев

Томаты

0.45

27/8/94

"Полесье"

Киев

Масло

1.62

27/8/94

"Полесье"

Киев

Лук

0.61

27/8/94

"Наталка"

Киев

Лук

0.52

27/8/94

...

...

...

...

...

...

Рис. 4.3. Преобразование универсального отношения "Питание" (первый вариант)

Блюда

Рецепты

Расход

БЛ

Блюдо

Вид

Блюдо

Рецепт

Блюдо

Порций

Дата_Р

Лобио

Закуска

Лобио

Ломаную очищ

Лобио

1/9/94

Харчо

Суп

...

...

Харчо

1/9/94

Шашлык

Горячее

Шашлык

1/9/94

Кофе

Десерт

Кофе

1/9/94

...

...

...

...

...

...

Продукты

Состав

Поставщики

ПР

Продукт

Калор.

БЛ

ПР

Вес (г)

ПОС

Поставщик

Город

Страна

Фасоль

"Полесье"

Киев

Украина

Лук

"Наталка"

Киев

Украина

Масло

"Хуанхэ"

Пекин

Китай

Зелень

"Лайма"

Рига

Латвия

Мясо

"Юрмала"

Рига

Латвия

...

...

...

...

...

...

...

...

...

...

Поставки

ПОС

ПР

Вес (кг)

Цена ($)

Дата_П

0.45

27/8/94

1.62

27/8/94

0.61

27/8/94

0.52

27/8/94

...

...

...

...

...

Рис. 4.4. Преобразование универсального отношения "Питание" (второй вариант)

Разбивая эту таблицу на две таблицы Поставщики и Города (рис. 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НФ.

Дата добавления: 2014-01-13