Определение. Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость

Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной. Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции — соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.

Очень редко таблица, находящаяся в 4NF, не соответствует 5NF. Это те ситуации, в которых реальные правила, ограничивающие допустимые комбинации атрибутов, никак не выражены в структуре таблицы (например, правила определенного бизнеса). В таком случае, если таблица не приведена к 5NF, бремя обеспечения логической целостности данных отчасти переляжет на приложение, отвечающее за добавление, удаление и изменения таблицы. В этом случае существует риск возникновения аномалий данных. Пятая нормальная форма исключает возникновение таких аномалий.

Пример

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

Отношение {Продавец, Фирма, Вид товара} соответствует 4NF, однако не отражает ограничения, связанного с ассортиментом продукции фирм. Может возникнуть кортеж, в котором фирме будет соответствовать вид товара, который она не выпускает.

В данном случае (для приведения к 5NF) отношение должно быть разбито на три: {Продавец, Фирма}, {Фирма, Вид товара}, {Продавец, Вид товара}.

Доменно-ключевая нормальная форма (DKNF) — одна из возможных нормальных форм таблицы реляционной базы данных. Её предложил Рональд Фагин в 1981 году.

Определение

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

Пример

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

Недостатки теории доменно-ключевой нормальной формы (DKNF) Рональда Фагина (Ronald Fagin)

Тарасов И. А.

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

Ограничения целостности задаются одним из следующих способов в современных СУБД:

· задание первичного ключа или индекса

· задание типа домена, например, UNSIGNED INT, CHAR(6)

· задание ссылочной целостности по внешним ключам: ON DELETE..., ON UPDATE...

· триггеры: ограничение на вставку, изменение, удаление кортежа

· транзакции

Ronald Fagin в [1] рассматривает только ограничения целостности таблицы, которые определяются функциональными зависимостями, многозначными зависимостями, зависимостями соединения, зависимостями домена (domain dependencies) и зависимостями ключа (key dependencies). Очевидно, что данные зависимости не позволят нам сохранить целостность данных всей базы данных. Например, при удалении преподавателя мы должны либо удалить либо установить внешний ключ в NULL для всех подчиненных записей о дисциплинах, которые он читал. При вставке записи в таблицу водительских прав должен сработать триггер, который запретит вставку, если данный пользователь присутствует в группе наркоманов. Перевод денег со счета на счет может выполняться исключительно в виде транзакции.

Определения аномалий вставки и удаления данных в [1] противоречивы.

Definition 3.2. Relation schema R * has an insertion anomaly if there is a valid instance R of R* and there is a tuple t compatible with R such that R U {t}, the relation obtained by inserting t into R, is not a valid instance of R* (i.e., violates a constraint of R *),

Противоречие здесь заключается в том, что выполнить операцию вставки кортежа t в таблицу R^* не получится, если R U t нарушает какое-либо ограничение целостности данных. В этом как раз и заключается основная задача СУБД — не допускать вставки данных, которые нарушают целостность данных. В тоже время под определение Р. Фагина 3.2 аномалии вставки данных подпадает ситуация, когда кортеж допустимый для вставки в таблицу R^* не вставляется в эту таблицу из-за совпадения значения ключа или группы уникальных атрибутов. Хотя в этом случае никакой аномалии вставки нет.

Аналогичным образом обстоит дело и с определением аномалии удаления.

Правильное определение аномалий модификации данных см. в [2].

Как было показано в статье «Целостность данных, аномалии модификации данных и нормальные формы таблиц реляционных баз данных» аномалий модификации данных нет. Проект логической структуры реляционной БД может быть не адекватен предметной области. Приведем здесь определение из [2].

Определение проекта БД (структура таблиц и дополнительных ограничений в виде ссылочной целостности, триггеров, транзакций) неадекватного предметной области: пусть задана структура реляционной базы данных с набором ограничений С и множеством данных D₁, которое удовлетворяет всем ограничениям C. Пусть также имеется операция модификации данных, которая переводит множество D₁ в D₂. Тогда проект будет не адекватен предметной области в следующих случаях:

1. D₂ удовлетворяет C, но отражает противоречивое состояние предметной области.

2. D₂ противоречит C, но отражает реальное состояние предметной области, т.е. отразить изменение состояния предметной области в БД невозможно.

Рассмотрим теперь определение доменно-ключевой нормальной формы.

Definition 3.12. Let R* be a 1NF relation schema, and let Г be the set of DDs and KDs of the schema. R * is in domain-key normal form (DK/NF) if Г => σ for every constraint σ of R*.

Таблица находится в ДКНФ, если каждое ограничение целостности таблицы является следствием ограничений целостности доменов и ключей.

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

Следующая теорема из [1] не имеет смысла в силу противоречий в определениях аномалий вставки и удаления из [1].

THEOREM 3.13. A satisfiable 1NF relation schema is in DK/NF if and only if it has no insertion or deletion anomalies.

Аналогичным образом рушатся и все остальные рассуждения в [1].

Вывод: ДКНФ не является спасательным кругом и не удовлетворяет выводам, которые были сделаны в [3].

1. Fagin R.A. Normal Form for Relational Databases That is Based on Domains and Key //ACM Transactions on Database Systems. - 1981. - V.6, №3. - P.387-415. (Перевод статьи "Доменно-ключевая нормальная форма" Рональда Фагина на русский язык)

2. Целостность данных, аномалии модификации данных и нормальные формы таблиц реляционных баз данных

3. Основание нормальных форм таблиц и функциональных зависимостей реляционных баз данных

Шестая нормальная форма (6NF) — одна из возможных нормальных форм таблицы реляционной базы данных.

Дата добавления: 2015-07-15