Третья нормальная форма. (вопрос 57)

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

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

Таблица Order Info не находится в третьей нормальной форме, так как содержит зависимость между неключевыми полями (она называется транзитивной зависимостью – transit dependency) – поле Address зависит от поля CustomerID.

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

1) Определить все поля (или группы полей), от которых зависят другие поля.

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

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

Для приведения таблицы Order Info к третьей нормальной форме создадим новую таблицу Customers и переместим в нее поля Customer ID и Address рис. 5.18.

Поле Address из исходной таблицы удалим, а поле Customer ID оставим – теперь это внешний ключ.

Рис. 5.18. Приведение таблицы Order Info к третьей нормальной форме.

После приведения исходной таблицы Ordered Products к третьей нормальной форме таблиц стало три: Customers, Orders и Order Details.

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

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

• сведения о заказанном продукте можно удалять, не опасаясь удаления данных о клиенте и заказе;

• изменения адреса клиента или даты регистрации заказа требует изменения только одной записи.

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

Технологически описание схемы баз данных помещается в каталог базы данных, который в реляционных СУБД также представляет таблицу (системную таблицу), структура (поля) которой описывает объекты базы данных (таблицы), их названия, поля, параметры и т.д.

Как правило, каталог базы данных хранится в файле БД вместе с данными.

В определенных случаях (системы “клиент-сервер”, распределенные системы, системы на основе репликации) может устанавливаться специальный режим размещения и доступа к каталогу базы данных.