Теория нормальных форм

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

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

1. Исключение некоторых типов избыточности.
2. Устранение некоторых аномалий обновления.
3. Разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения.
4. Упрощение процедуры применения необходимых ограничений целостности.

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

При том, что идеи нормализации весьма полезны для проектирования баз данных, они отнюдь не являются универсальным или исчерпывающим средством повышения качества проекта БД. Это связано с тем, что существует слишком большое разнообразие возможных ошибок и недостатков в структуре БД, которые нормализацией не устраняются. Несмотря на эти рассуждения, теория нормализации является очень ценным достижением реляционной теории и практики, поскольку она даёт научно строгие и обоснованные критерии качества проекта БД и формальные методы для усовершенствования этого качества. Этим теория нормализации резко выделяется на фоне чисто эмпирических подходов к проектированию, которые предлагаются в других моделях данных. Более того, можно утверждать, что во всей сфере информационных технологий практически отсутствуют методы оценки и улучшения проектных решений, сопоставимые с теорией нормализации реляционных баз данных по уровню формальной строгости.

Всего выделяют 6 нормальных форм, но мы рассмотрим только первые 3.

Первая нормальная форма (1НФ)

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

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение.

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

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

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

Пример

Исходная ненормализованная (то есть не являющаяся правильным представлением некоторого отношения) таблица:

Таблица, приведённая к 1НФ, являющаяся правильным представлением некоторого отношения:

Атомарность

Многие авторы дополняют определение первой нормальной формы требованием атомарности (неделимости) значений. Однако концепция «атомарности» является слишком неясной. Например, многие типы данных (строки, даты, числа с фиксированной точкой и т. д.) при необходимости легко могут быть декомпозированы на составляющие элементы с помощью стандартных операций, предоставляемых СУБД. К. Дейт заключает, что «понятие атомарности не имеет абсолютно никакого смысла».

Исторически концепция «атомарности» берёт начало от «простых доменов» (англ. simple domains), предложенных автором реляционной модели данных Э. Ф. Коддом. Цель «нормальной формы», которую предложил Кодд в статье «Реляционная модель данных для больших совместно используемых банков данных», не была связана с каким-либо теоретическим аспектом, например, с борьбой с аномалиями или избыточностью. Кодд предложил использовать «простые домены» только для облегчения будущей программной реализации, а именно:

1. Для облегчения хранения отношений в виде двумерных массивов. Отношение, все домены которого являются простыми, может быть представлено при хранении двухмерным массивом с однородными столбцами.
2. Для облегчения передачи данных в гетерогенных системах. Простота представления отношений массивами, осуществимая в случае приведения всех отношений в нормальную форму, предоставляет преимущества не только при хранении, но также при передаче больших объёмов данных между системами, использующими во многом отличные представления данных.

Вторая нормальная форма (2НФ)

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

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

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

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

Пример

Пусть в следующем отношении первичный ключ образует пара атрибутов {Филиал, Должность}:

Допустим, что зарплата зависит от филиала и должности, а наличие компьютера зависит только от должности.

Существует функциональная зависимость Должность → Наличие компьютера, в которой левая часть (детерминант) является лишь частью первичного ключа, что нарушает условие второй нормальной формы.

Для приведения к 2NF исходное отношение следует декомпозировать на два отношения:

Третья нормальная форма (3НФ)

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

Пример

Рассмотрим в качестве примера отношение:

Каждый сотрудник относится исключительно к одному отделу; каждый отдел имеет единственный телефон. Атрибут Сотрудник является первичным ключом. Личных телефонов у сотрудников нет, и телефон сотрудника зависит исключительно от отдела.

В примере:

• Отдел зависит от Сотрудника.
• Телефон зависит от Отдела.
• Телефон зависит от Сотрудника (транзитивно).

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

Телефон зависит от неключевого атрибута Отдел следовательно, отношение не находится в третьей нормальной форме.

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

Для приведения отношения к третьей нормальной форме, необходимо разделить его на два:

Упражнение

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

Исходная таблица таблица Orders (Заказы):

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

Чтобы быть во второй нормальной форме, все неключевые атрибуты должны полностью зависеть от всего потенциального ключа.

• Потенциальный ключ: (OrderID, ProductID) (составной ключ).
• Неключевые атрибуты: CustomerID, CustomerName, ProductName, Quantity, Price.

При этом есть проблемы:

• CustomerID и CustomerName зависят только от OrderID, а не от всего ключа (OrderID, ProductID).
• ProductName и Price зависят только от ProductID, а не от всего ключа.

Кроме этого, CustomerName и ProductName дублируются для каждого заказа.

Для приведения отношения ко второй нормальной форме декомпозируем таблицу на три отношения:

1. Orders (Заказы):

   OrderID	CustomerID	CustomerName
   1	101	Иванов
   2	102	Кузнецов
   3	101	Иванов

2. OrderDetails (Детали заказов):

   OrderID	ProductID	Quantity
   1	201	2
   1	202	3
   2	201	1
   3	203	1

3. Products (Товары):

   ProductID	ProductName	Price
   201	Ноутбук	1200
   202	Мышь	20
   203	Клавиатура	50

Чтобы быть в третьей нормальной форме неключевые атрибуты не должны зависеть от других неключевых атрибутов. Однако, в таблице Orders CustomerID зависит от OrderID, а CustomerName зависит от CustomerID.

Для устранения этого, декомпозируем таблицу Orders:

1. Orders (Заказы):

   OrderID	CustomerID
   1	101
   2	102
   3	101

2. Customers (Клиенты):

   CustomerID	CustomerName
   101	Иванов
   102	Кузнецов

Таким образом, в результате нормализации мы получаем базу данных из 4-х таблиц, находящихся в 3-й нормальной форме.

1. Orders (Заказы):

   OrderID	CustomerID
   1	101
   2	102
   3	101

2. Customers (Клиенты):

   CustomerID	CustomerName
   101	Иванов
   102	Кузнецов

3. OrderDetails (Детали заказов):

   OrderID	ProductID	Quantity
   1	201	2
   1	202	3
   2	201	1
   3	203	1

4. Products (Товары):

   ProductID	ProductName	Price
   201	Ноутбук	1200
   202	Мышь	20
   203	Клавиатура	50

Контрольные вопросы

1. Для чего используется нормализация?
2. Приведите пример нарушения первой нормальной формы?
3. Приведите пример нарушения второй нормальной формы?
4. Что такое полная функциональная зависимость?
5. Приведите пример нарушения третьей нормальной формы?