Доменно-ключевая нормальная форма

Первая нормальная форма

Любая таблица, удовлетворяющая определению отношения, находится в 1НФ.
Вот основные характеристики таблицы в 1НФ:

· В каждой строке таблицы должны содержаться данные, соответствующие некоторому объекту или его части;

· В каждом столбце должны находиться данные, соответствующие одному из атрибутов отношения;

· В каждой ячейке таблицы должно находиться только единственное значение;

· У каждого столбца должно быть уникальное имя;

· Все строки (записи) в таблице должны быть различными;

· Порядок расположения столбцов и строк в таблице не имеет значения.

 

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

Вторая нормальная форма

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

Рассмотрим пример отношения

Таблица: Секции.

Имя	Секция	Оплата
Иванов	Футбол
Иванов	Волейбол
Петров	Лыжи
Сидоров	Шахматы
Сидоров	Лыжи
Фёдоров	Лыжи
Фёдоров	Волейбол

 

Ключом в данном отношении является {имя, Секция}, но оно содержит функциональную зависимость секция - плата. Аргумент. (левая часть) этой зависимости является лишь частью составного ключа. Отношение секции имеет аномалии удаления и добавления. Так, если мы захотим удалить записи с именем "иванов", то потеряем стоимость футбольной секции. Мы не сможем добавить запись о новой секции, пока в нее кто-нибудь не запишется. Данных аномалий можно было бы избежать, если бы атрибут плата зависел от всего ключа (однозначно определялся всем ключом).

Отношение секции (Имя, Секция, Плата) в 1НФ можно разбить на два отношения во 2НФ:

1. Секция_члены (Имя, Секция);

2. Секция_плата (Секция, Плата).

 

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

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

Рассмотрим в качестве примера отношение гости (ID_гостя, тип_номера, плата), представляющее сведения о проживающих в гостинице. Ключом в этом отношении является ID_гостя, плата однозначно определяется атрибутом тип номера (например, люкс, полулюкс и т. д.), т. е. имеется функциональная зависимость тип номера — > плата. Поскольку каждый гость проживает только в одном номере определенного типа, в отношении есть и функциональная зависимость ID_гостя — >тип_номера. Таким образом, возникает транзитивная (опосредованная) зависимость ID_гостя-> плата. Так как ключ состоит из единственного атрибута ID_гостя, то отношение находится в 2НФ.

В рассматриваемом отношении существует аномалия удаления. Удалив запись, мы потеряем не только информацию о каком-то госте (где он проживает), но и сведения о том, сколько стоит номер соответствующего типа.

Чтобы устранить указанную аномалию, следует декомпозировать

исходное отношение гости (ID_гостя, Тип_номера, плата) на два:

1. Проживание (ID_гостя, Тип_номера);

2. Тип плата (Тип_номера, Плата).

Эти отношения будут находиться в 2НФ и не содержать транзитивных зависимостей.

Таким образом, отношение находится в 3НФ, если оно находится в 2НФ и не содержит транзитивных зависимостей.

 

Доменно-ключевая нормальная форма

Если таблица находится в ЗНФ, то остается довольно мало шансов для возникновения аномалий модификации данных, но они все равно есть. Чтобы исключить все виды возможных аномалий, таблица должна находиться в доменно-ключевой нормальной форме (ДКНФ).

Понятие ДКНФ довольно просто: отношение находится в ДКНФ, если каждое ограничение, накладываемое на него, является логическим следствием определения доменов и ключей. Термин ограничение (constraint) здесь намеренно трактуется широко. Р. Фагин определяет ограничение как любое правило, регулирующее возможные статические значения атрибутов, достаточно точное, чтобы можно было проверить его выполнимость. Правила редактирования, ограничения взаимосвязей и структуры отношений, функциональные и многозначные зависимости являются примерами таких ограничений. Отсюда исключаются ограничения, связанные с изменением данных (ограничения, зависящие от времени). Другими словами, отношение находится в ДКНФ, если выполнение ограничений на домены и ключи влечет за собой выполнение всех ограничений.

Однако в настоящее время не известен алгоритм преобразования отношения в ДКНФ. Неизвестно также, какие отношения в принципе могут быть приведены к ДКНФ. Поиск и создание отношений в ДКНФ сейчас является искусством, а не наукой. В литературе обычно приводятся только примеры отношений в ДКНФ, которые мы здесь рассматривать не будем.

 

Денормализация

Чтобы исключить как можно больше аномалий модификации данных, старайтесь как можно больше нормализовать таблицы базы данных. Лучше, если вы доведете их до ДКНФ, хотя на практике это редко происходит. Чаще ограничиваются второй или третьей нормальными формами. Занимаясь нормализацией, вы увеличиваете количество таблиц в базе данных, и при определенном их количестве эффективность работы может оказаться слишком низкой. Кроме того, формулировать SQL-запросы к базе данных тем легче, чем меньше в ней таблиц. Так что на любом этапе своего развития база данных может быть в какой-то степени денормализованной.