5.6.3. Третья нормальная форма. (вопрос 57)
Реляционная таблица находится в третьей нормальной форме, если она находится во второй нормальной форме и все ее неключевые поля зависят в каждый момент времени только от первичного ключа и ни один неключевой атрибут не должен зависеть от другого неключевого столбца.
Таблица Order Details уже находится в третьей нормальной форме. Неключевое поле Quantity этой таблицы полностью зависит от составного первичного ключа (OrderID, ProductID).
Таблица Order Info не находится в третьей нормальной форме, так как содержит зависимость между неключевыми полями (она называется транзитивной зависимостью – transit dependency) – поле Address зависит от поля CustomerID.
Для того чтобы от второй нормальной формы перейти к третьей, нужно выполнить следующие шаги:
-
Определить все поля (или группы полей), от которых зависят другие поля.
-
Создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные переменные поля, станет при этом первичным ключом новой таблицы.
-
Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами.
Для приведения таблицы Order Info к третьей нормальной форме создадим новую таблицу Customers и переместим в нее поля Customer ID и Address рис. 5.18.
Поле Address из исходной таблицы удалим, а поле Customer ID оставим – теперь это внешний ключ.
Рис. 5.18. Приведение таблицы Order Info к третьей нормальной форме.
После приведения исходной таблицы Ordered Products к третьей нормальной форме таблиц стало три: Customers, Orders и Order Details.
Таким образом, нормализация устраняет избыточность, что позволяет снизить объем хранимых данных и избавиться от описанных выше аномалий. Например, после приведения рассмотренной выше базы данных к третьей нормальной форме получены следующие улучшения:
-
сведения об адресе клиента можно хранить в базе данных, даже в том случае, если это только потенциальный клиент, не разместивший ни одного заказа;
-
сведения о заказанном продукте можно удалять, не опасаясь удаления данных о клиенте и заказе;
-
изменения адреса клиента или даты регистрации заказа требует изменения только одной записи.
Результатом проектирования схем таблиц и их нормализации является законченная логическая структура базы данных.
Технологически описание схемы баз данных помещается в каталог базы данных, который в реляционных СУБД также представляет таблицу (системную таблицу), структура (поля) которой описывает объекты базы данных (таблицы), их названия, поля, параметры и т.д.
Как правило, каталог базы данных хранится в файле БД вместе с данными.
В определенных случаях (системы “клиент-сервер”, распределенные системы, системы на основе репликации) может устанавливаться специальный режим размещения и доступа к каталогу базы данных.
5.7. Способы создания таблиц, ключей, связей. (вопрос 58)
Обычно современные СУБД содержат средства, позволяющие создавать таблицы и ключи. Существуют и утилиты, поставляемые отдельно от СУБД (и даже обслуживающие одновременно несколько различных СУБД), позволяющие создавать таблицы, ключи и связи.
Другой способ создания таблиц, ключей и связей в базе данных – это написание так называемого DDL-сценария (скрипта).
DDL – Data Definition Language – язык описания (определения) данных – часть языка SQL.
Наконец, еще один способ – это использование специальных средств, называемых CASE-средствами (Computer-Aided Software Engineering).
Существует несколько типов CASE-средств, но для создания баз данных используются инструменты для реализации диаграмм “сущность-связь” (Entity-Relationship Diagrams, ER diagrams, ERD).
С помощью этих инструментов создается логическая модель данных, описывающая факты и объекты, подлежащие регистрации в ней (в таких моделях прототипы таблиц называются сущностями (entities), а поля – их атрибутами (attributes)).
После установления связей между сущностями, определения атрибутов и проведения нормализации, создается физическая модель данных для конкретной СУБД, в которой определяются все таблицы, поля и другие объекты базы данных. После этого можно сгенерировать либо саму базу данных, либо DDL-сценарий для ее создания.
Список популярных CASE-средств приведен в таблице 5.2.
Таблица 5.2. Список наиболее популярных CASE-средств.