4.4.5 Нормальная форма Бойса-Кодда

В некоторых редких случаях таблицы, приведенные к 3НФ, тем не менее, обладают недостатками, аналогичными рассмотренным выше. В этом случае требуется приведение таблиц к нормальным формам более высоких порядков.

Если в отношении имеется зависимость атрибутов составного ключа от неключевых атрибутов, то необходимо перейти к усиленной ЗНФ, т.е к нормальной форме Бойса - Кодда (БКНФ).

Отношение находится в БКНФ, если оно находится в ЗНФ и в нем отсут­ствуют зависимости ключей (атрибутов составного ключа) от неключевыхатрибутов.

Для более глубокого рассмотрения БКНФ необходимо вспомнить термины детерминантивозможный ключ, определенные в п. 4.3.2.

Атрибут (или группа атрибутов) называется детерминантом, если от него функционально зависит какой-либо другой атрибут. Другими словами, если имеется функциональная зависимость A → B, то A – детерминант.

Атрибут (или группа атрибутов) называется возможным ключом, если он может использоваться в качестве ключа.

С учетом этих определений, таблица находится БКНФ, если она находится в 3НФ, и при этом каждый детерминант в таблице является возможным ключом.

Таблица, не находящаяся в БКНФ, может иметь ряд аномалий.

Пример– Разрабатывается БД о поставках деталей внутри предприятия. На предприятии имеются цехи-поставщики (выпускающие детали, используемые другими цехами) и цехи-заказчики или потребители (использующие детали, выпущенные цехами-поставщиками, и выпускающие готовую продукцию). Известно следующее:

каждый цех-поставщик (Цп) выпускает (и поставляет цехам-заказчикам) детали только одного вида;

каждый цех-заказчик (Цз) получает детали каждого вида только от одного цеха-поставщика (например, если Цз Ц22 получает гайки от Цп Ц17, то он не получает гайки от каких-либо других цехов);

Цп может поставлять детали (одного вида) нескольким Цз;

один вид деталей может выпускаться несколькими Цп.

Фрагмент БД приведен на рис. 4.8.

Цех-заказчик (Цз)	Деталь	Цех-поставщик (Цп)
Ц21	планка	Ц10
Ц21	гайка	Ц12
Ц21	этикетка	Ц15
Ц22	гайка	Ц17
Ц22	штепсель	Ц11
Ц23	планка	Ц10
Ц23	штепсель	Ц11

Рис. 4.8 – БД о поставках деталей внутри предприятия

Здесь ни один из атрибутов в отдельности не является ключом, так как значение любого атрибута в БД может встречаться несколько раз. В качестве ключей могут использоваться комбинации атрибутов (Цз, Деталь) или (Цз, Цп), так как, согласно постановке задачи, любая комбинация значений этих атрибутов может встречаться в БД (структура которой показана на рис. 4.8) только один раз. Например, любая комбинация значений (Цз, Деталь) встречается в БД только один раз, так как Цз получает детали любого определенного вида только от одного Цп. Комбинация значений (Цз, Цп) встречается в БД только один раз, так как Цз и Цп могут быть связаны поставками только одной детали. Таким образом, комбинации атрибутов (Цз, Деталь) и (Цз, Цп) – возможные ключи.

В данном примере имеются следующие функциональные зависимости: (Цз, Деталь) →Цп, (Цз, Цп) →Деталь,Цп →Деталь. Таким образом, атрибутЦпявляется детерминантом, но не является возможным ключом.

Будем использовать в качестве ключа комбинацию атрибутов (Цз, Деталь). Тогда таблица на рис. 4.8 находится в 2НФ (так как нет функциональных зависимостей от частей ключа) и в 3НФ (так как отсутствуют транзитивные зависимости видаA→B→C). Однако таблица не находится в БКНФ, так как имеется детерминант (Цп), не являющийся возможным ключом. Это является причиной следующих недостатков:

избыточность данных: некоторые данные хранятся многократно. Например, данные о том, какая деталь выпускается Цп, хранятся несколько раз (столько, сколько имеется Цз, получающих у Цп данную деталь). Так, информация о том, что цех Ц10 выпускает планки, приведена в таблице на рис. 4.8 дважды;

аномалия добавления (ввода): невозможность ввода данных о Цп, пока он не начал выпуск какой-либо детали;

аномалия удаления: например, если цех Ц22 прекратит получать гайки от цеха Ц17, то информация о цехе Ц17 будет потеряна;

аномалия обновления: если Цп перейдет на выпуск другой детали, то потребуется вносить изменения в несколько записей. Кроме того, при этом в некоторый момент времени одному Цп будут соответствовать разные детали.

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

В рассматриваемом примере таблица на рис. 4.8 не находится в БКНФ из-за функциональной зависимости Цп →Деталь. Значит, требуется выделить их в отдельную таблицу (рис. 4.9). АтрибутЦпв этой таблице является ключом. Еще одна таблица будет содержать все атрибуты, кроме атрибутаДеталь(рис. 4.10). Таким образом, БД о внутренних поставках деталей, приведенная к БКНФ, будет состоять из двух таблиц, показанных на рис. 4.9 и 4.10.

Деталь	Цех-поставщик
планка	Ц10
гайка	Ц12
этикетка	Ц15
гайка	Ц17
штепсель	Ц11

Рис. 4.9 – Цехи-поставщики

Цех-заказчик	Цех-поставщик
Ц21	Ц10
Ц21	Ц12
Ц21	Ц15
Ц22	Ц17
Ц22	Ц11
Ц23	Ц10
Ц23	Ц11

Рис. 4.10 – Поставки

В таблицах отсутствуют недостатки, указанные выше. Таким образом, проектирование БД о поставках деталей внутри предприятия завершено.

Примечание – Как было показано выше, в данном примере имелось два возможных ключа. (Цз, Деталь) и (Цз, Цп). В рассматриваемом примере в качестве ключа использовалась комбинация атрибутов (Цз, Деталь). Если бы в качестве ключа была выбрана комбинация (Цз, Цп), то потребовалось бы приведение таблицы к 2НФ из-за наличия неполной функциональной зависимости: атрибут Деталь зависел бы от части ключа Цп. Результатом приведения к 2НФ (см. п. 4.2.4) были бы таблицы 4.9 и 4.10.