Реляционная таблица находится в третьей нормальной форме, если она находится во второй нормальной форме и все ее неключевые поля зависят в каждый момент времени только от первичного ключа и ни один неключевой атрибут не должен зависеть от другого неключевого столбца.
Таблица 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.
Таким образом, нормализация устраняет избыточность, что позволяет снизить объем хранимых данных и избавиться от описанных выше аномалий. Например, после приведения рассмотренной выше базы данных к третьей нормальной форме получены следующие улучшения:
• сведения об адресе клиента можно хранить в базе данных, даже в том случае, если это только потенциальный клиент, не разместивший ни одного заказа;
• сведения о заказанном продукте можно удалять, не опасаясь удаления данных о клиенте и заказе;
• изменения адреса клиента или даты регистрации заказа требует изменения только одной записи.
Результатом проектирования схем таблиц и их нормализации является законченная логическая структура базы данных.
Технологически описание схемы баз данных помещается в каталог базы данных, который в реляционных СУБД также представляет таблицу (системную таблицу), структура (поля) которой описывает объекты базы данных (таблицы), их названия, поля, параметры и т.д.
Как правило, каталог базы данных хранится в файле БД вместе с данными.
В определенных случаях (системы “клиент-сервер”, распределенные системы, системы на основе репликации) может устанавливаться специальный режим размещения и доступа к каталогу базы данных.