WikiDer > Нормальная форма Бойса – Кодда

Нормальная форма Бойса – Кодда (или же BCNF или же 3,5 нФ) это нормальная форма используется в нормализация базы данных. Это немного более сильная версия третья нормальная форма (3НФ). BCNF был разработан в 1974 г. Раймонд Ф. Бойс и Эдгар Ф. Кодд для устранения определенных типов аномалий, не рассматриваемых 3NF в соответствии с первоначальным определением.^[1]

Если реляционная схема находится в BCNF, тогда вся избыточность основана на функциональная зависимость был удален, хотя другие типы резервирования все еще могут существовать. Реляционная схема р находится в нормальной форме Бойса – Кодда если и только если для каждого из своих зависимости X → Y, выполняется хотя бы одно из следующих условий:^[2]

• Икс → Y является тривиальной функциональной зависимостью (Y ⊆ X),
• Икс это суперключ для схемы р.

Таблица 3NF всегда соответствует BCNF (нормальная форма Бойса – Кодда)

В этом разделе фактическая точность оспаривается. Соответствующее обсуждение можно найти на Обсуждение: нормальная форма Бойса – Кодда. Пожалуйста, помогите убедиться, что оспариваемые утверждения надежный источник. (Декабрь 2019 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

Только в редких случаях таблица 3NF не соответствует требованиям BCNF. Таблица 3NF, не имеющая множественного перекрытия ключи-кандидаты гарантированно находится в BCNF.^[3] В зависимости от того, каковы ее функциональные зависимости, таблица 3NF с двумя или более перекрывающимися ключами-кандидатами может быть или не находиться в BCNF.

Примером таблицы 3NF, которая не соответствует BCNF, является:

• Каждая строка в таблице представляет бронирование корта в теннисном клубе. В этом клубе есть один корт с твердым покрытием (Корт 1) и один корт с травяным покрытием (Корт 2).
• Бронирование определяется его судом и периодом, на который зарезервирован суд.
• Кроме того, с каждым бронированием связан тип тарифа. Существует четыре различных типа ставок:
  • SAVER, для заказов Court 1, сделанных участниками
  • СТАНДАРТ, для заказов Корт 1, сделанных не членами
  • PREMIUM-A, для заказов Court 2, сделанных участниками
  • PREMIUM-B, для заказов Court 2, сделанных не членами

Столы суперключи находятся:

• S₁ = {Суд, время начала}
• S₂ = {Суд, время окончания}
• S₃ = {Тип цены, Время начала}
• S₄ = {Тип цены, Время окончания}
• S₅ = {Суд, время начала, время окончания}
• S₆ = {Тип цены, время начала, время окончания}
• S₇ = {Корт, Тип ставки, Время начала}
• S₈ = {Суд, Тип ставки, Время окончания}
• S_Т = {Суд, Тип ставки, Время начала, Время окончания}, простая суперклавиша

Обратите внимание, что хотя в приведенной выше таблице Начальное время и Время окончания атрибуты не имеют повторяющихся значений для каждого из них, мы все равно должны признать, что в другие дни два разных бронирования на корте 1 и корте 2 могли начать одновременно или же заканчиваться одновременно. По этой причине {Время начала} и {Время окончания} нельзя рассматривать как суперключи таблицы.

Однако только S₁, S₂, S₃ и S₄ находятся ключи-кандидаты (то есть минимальные суперключи для этого отношения), потому что, например, S₁ ⊂ S₅, поэтому S₅ не может быть кандидатом ключа.

Напомним, что 2NF запрещает частичные функциональные зависимости непервичных атрибутов (т. е. атрибут, который не встречается в любой кандидат ключ. Видеть ключи-кандидаты) на ключах-кандидатах, и что 3NF запрещает транзитивные функциональные зависимости непервичных атрибутов ключей-кандидатов.

В Судебные заказы сегодня В таблице нет непростых атрибутов: то есть все атрибуты принадлежат некоторому ключу-кандидату. Поэтому таблица соответствует как 2NF, так и 3NF.

Таблица не соответствует BCNF. Это связано с зависимостью Тип ставки → Суд, в которой определяющий атрибут Тип ставки - от которого зависит Суд - (1) не является ни кандидатным ключом, ни надмножеством кандидата-ключа, и (2) Суд не является подмножеством типа ставки.

Тип ставки зависимости → Суд соблюдается, поскольку тип ставки должен применяться только к одному суду.

Конструкцию можно изменить, чтобы она соответствовала BCNF:

Возможные ключи для таблицы типов ставок: {Тип ставки} и {Суд, флаг члена}; возможные ключи для таблицы сегодняшних бронирований: {Суд, Время начала} и {Суд, Время окончания}. Обе таблицы находятся в BCNF. Когда {Тип ставки} является ключевым в таблице типов ставок, невозможно связать один тип ставки с двумя разными судами, поэтому при использовании {Тип ставки} в качестве ключа в таблице типов ставок возникла аномалия, влияющая на исходную таблицу. устранено.

Достижимость BCNF

В некоторых случаях таблица, не относящаяся к BCNF, не может быть разложена на таблицы, которые удовлетворяют BCNF и сохраняют зависимости, которые содержались в исходной таблице. Бери и Бернштейн показали в 1979 году, что, например, набор функциональных зависимостей {AB → C, C → B} не может быть представлен схемой BCNF.^[4]

Рассмотрим следующую таблицу, не относящуюся к BCNF, функциональные зависимости которой следуют шаблону {AB → C, C → B}:

Для каждой комбинации типов "Человек / Магазин" в таблице указано, какой магазин этого типа географически ближайший к дому человека. Для простоты мы предполагаем, что один магазин не может быть более одного типа.

Возможные ключи таблицы:

• {Человек, Тип магазина},
• {Человек, ближайший магазин}.

Поскольку все три атрибута являются первичными атрибутами (т. Е. Принадлежат ключам-кандидатам), таблица находится в 3NF. Однако таблица отсутствует в BCNF, так как атрибут типа Shop функционально зависит от не суперключи: ближайший магазин.

Нарушение BCNF означает, что таблица подвержена аномалиям. Например, для Eagle Eye тип магазина может быть изменен на «Оптометрист» в записи «Фуллера», но при этом сохранен тип магазина «Оптик» в записи «Дэвидсон». Это означало бы противоречивые ответы на вопрос: «Что такое тип магазина Eagle Eye?» Было бы предпочтительнее держать каждый тип магазина только один раз, так как это предотвратит появление таких аномалий:

В этом пересмотренном дизайне таблица «Магазин рядом с человеком» имеет ключ-кандидат {Person, Shop}, а таблица «Shop» - ключ-кандидат {Shop}. К сожалению, хотя этот дизайн соответствует BCNF, он неприемлем по разным причинам: он позволяет нам регистрировать несколько магазинов одного типа против одного и того же человека. Другими словами, его ключи-кандидаты не гарантируют, что функциональная зависимость {Person, Shop type} → {Shop} будет соблюдаться.

Возможна конструкция, которая устраняет все эти аномалии (но не соответствует BCNF). Этот дизайн представляет новую нормальную форму, известную как Элементарный ключ нормальной формы.^[5] Этот дизайн состоит из оригинальной таблицы «Ближайшие магазины», дополненной таблицей «Магазин», описанной выше. Структура таблицы, созданная алгоритмом генерации схемы Бернштейна^[6] на самом деле является EKNF, хотя это расширение до 3NF не было распознано во время разработки алгоритма:

Если ограничение ссылочной целостности определяется так, что {Тип магазина, Ближайший магазин} из первой таблицы должен ссылаться на {Тип магазина, Магазин} из второй таблицы, тогда аномалии данных, описанные ранее, предотвращаются.

Несговорчивость

это НП-полный, учитывая схему базы данных в третья нормальная форма, чтобы определить, нарушает ли он нормальную форму Бойса – Кодда.^[7]

История

Крис Дата указал, что определение того, что мы теперь знаем как BCNF, появилось в статье Яна Хита в 1971 году.^[8] Дата пишет:^[9]

Поскольку это определение предшествовало собственному определению Бойса и Кодда примерно на три года, мне кажется, что BCNF по праву следует называть Хит нормальная форма. Но это не так.

Эдгар Ф. Кодд выпустил свою оригинальную статью «Реляционная модель данных для больших общих банков данных» в июне 1970 года. Это была первая публикация понятия реляционной базы данных. Вся последующая работа, включая метод нормальной формы Бойса – Кодда, была основана на этой реляционной модели.

Рекомендации

Библиография

внешняя ссылка

• Правила нормализации данных
• Расширенная нормализация ITS, Техасский университет.