Нормальная форма Бойса-Кодда (НФБК)
Отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом. Отношения базы данных проектируются таким образом, чтобы исключить в них присутствие частичных или транзитивных зависимостей, поскольку эти зависимости приводят к появлению аномалий обновления. До сих пор мы использовали определения второй и третьей нормальных форм, для получения которых требуется найти и исключить частичные и транзитивные зависимости от первичного ключа. Однако в этих определениях не рассматриваются такие же зависимости от потенциальных ключей отношения, если таковые имеются. Нормальная форма Бойса-Кодда (НФБК) учитывает функциональные зависимости, в которых участвуют все потенциальные ключи отношения, а не только его первичный ключ. Для отношения с единственным потенциальным ключом его ЗНФ и НФБК являются эквивалентными. Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами. Напомним, что детерминантом является один атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут. Различие между ЗНФ и НФБК заключается в том, что функциональная зависимость А—>В допускается в ЗНФ-отношении, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. Тогда как в НФБК-отношении эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно нормальная форма Бойса-Кодда является жесткой версией формы ЗНФ, поскольку каждое НФБК-отношение является ЗНФ-отношением, но не всякое ЗНФ-отношение является НФБК-отношением. Перед тем как обратиться к очередному примеру, еще раз рассмотрим отношения Клиент, Аренда, Свойства_Аренды и Владелец. Отношения Клиент, Свойства_Аренды и Владелец являются НФБК-отношениями, так как каждое из них имеет только один детерминант, который в то же время является потенциальным ключом этого отношения. Тут следует напомнить, что отношение АРЕНДА содержит три детерминанта — (Номер_Клиента, Номер_Объекта недвижимости), (Номер_Клиента, Начало_Аренды) и (Номер Объекта_ недвижимости, Конец_Аренды),— которые были выше выявлены нами и имеют вид, показанный ниже. FD1: Номер клиента, Номер объекта недвижимости → Начало аренды, Конец аренды FD5*: Номер клиента, Начало аренды → Номер объекта недвижимости, Конец аренды FD6*: Номер объекта недвижимости, Начало аренды → Номер клиента, Конец аренды Поскольку этих три детерминанта отношения АРЕНДА являются также потенциальными ключами, то отношение АРЕНДА находится в НФБК. Нарушения требований НФБК происходят крайне редко, поскольку это может случиться только тогда, когда: - имеются два (или более) составных потенциальных ключа; - эти потенциальные ключи перекрываются, т.е. ими совместно используется, по крайней мере, один общий атрибут. Рассмотрим случай, когда отношение нарушает требования НФБК, и метод преобразования этого отношения в НФБК. Рассмотрим отношение ИНТЕРВЬЮ_С_КЛИЕНТАМИ, которое содержит сведения о собеседованиях клиентов с сотрудниками компании. Таблица 12. Отношение Интервью_С_Клиентами
Для проведения собеседования в тот день, на который назначена встреча с клиентом, в распоряжение сотрудника предоставляется особая комната. Однако в течение рабочего дня эта комната может использоваться несколькими разными сотрудниками. С клиентом проводится только одно собеседование в день, но он может участвовать в нескольких собеседованиях в разные дни. Обсуждаемое отношение имеет три потенциальных ключа: (Номер клиента, Дата_Интервью), (Номер_Сотрудника, Дата_Интервью, Время_Интервью) и (Номер_Комнаты, Дата_Интервью, Время Интервью). Следовательно, отношение ИНТЕРВЬЮ_С__КЛИЕНТАМИ обладает тремя составными потенциальными ключами, которые перекрываются, т.е. ими совместно используется один общий атрибут — Дата_Интервью. В качестве первичного ключа данного отношения выбрана комбинация атрибутов (Номер_Клиента, Дата_Интервью). Это отношение представлено в верхней табл.12 и имеет следующий вид: Интервью_С_Клиентами (Номер_Клиента, Дата_Интервью, Время_Интервью, Номер_Сотрудника, Номер_комнаты) Рассмотрим функциональные зависимости для определения нормальной формы отношения Интервью_с_Клиентами: Fdl: Номер_Клиента, Дата_Интервью -> Время_Интервью, Номер_Сотрудника, Номер_Комнаты Первичный ключ fd2: Номер_Сотрудника, Дата_Интервью, Время_Интервью -> Номер_Клиента Потенциальный ключ fd3: Номер_Комнаты, Дата_Интервью, Время_Интервью -> Номер_Сотрудника, Номер_Клиента Потенциальный ключ fd4:Номер_Сотрудника, Дата_Интервью -> Номер_Комнаты Поскольку функциональные зависимости fd1, fd2 и fd3 являются потенциальными ключами этого отношения, то они не вызовут никаких проблем. Нам потребуется рассмотреть только функциональную зависимость Номер_Сотрудника, Дата_Интервью -> Номер_Комнаты (зависимость fd4). Даже если комбинация атрибутов (Номер_Сотрудника, Дата_Интервью) не является потенциальным ключом отношения ИНТЕРВЬЮ_С_КЛИЕНТОМ, эта функциональная зависимость допускается в 3НФ, потому что атрибут Номер Комнаты является атрибутом первичного ключа и частью потенциального ключа ( НомерКомнаты, Дата_Интервью, Время_Интервью). Поскольку в этом отношении нет.никаких частичных или транзитивных зависимостей от первичного ключа (Номер_Клиента, Дата_Интервью) и допускается наличие функциональной зависимости fd4, можно считать, что отношение ИНТЕРВЬЮ_С_КЛИЕНТОМ находится в ЗНФ. Однако это отношение не находится в НФБК (более строгий вариант ЗНФ), так как в нем присутствует детерминант (Номер_Сотрудника, Дата_Интервью), который не является потенциальным ключом этого отношения. В НФБК требуется, чтобы все детерминанты отношения были его потенциальными ключами. В противном случае отношение ИНТЕРВЬЮ_С_КЛИЕНТОМ может страдать от аномалий обновления. Например, 13 мая 2005 года (значение '13-Мая-05¥) при изменении номера комнаты, выделенной сотруднику 'SG5','' потребуется обновить значения в двух строках. Если при этом будет обновлена только одна строка, то база данных будет приведена в противоречивое состояние. Для преобразования отношения ИНТЕРВЬЮ_С_КЛИЕНТОМ в форму НФБК необходимо устранить нарушающую ее ограничения функциональную зависимость посредством создания двух новых отношений - ИНТЕРВЬЮ и ОФИС_СОТРУДНИКА, - представленных в табл. ниже соответственно. Таблица 13. Отношение Интервью:
Таблица 14. Отношение Офис_Сотрудника
Отношения ИНТЕРВЬЮ и ОФИС_СОТРУДНИКА имеют следующий вид: ИНТЕРВЬЮ( Номер_Клиента, Дата_Интервью, Время_Интервью,Номер_Сотрудника) ОФИС_СОТРУДНИКА ( Номер_Сотрудника, Дата_Интервью,Номер_Комнаты ) Любое отношение, которое не находится в НФБК, можно декомпозировать с образованием НФБК-отношений, однако делать это не всегда желательно. Например, декомпозиция будет нежелательна, если в результате ее выполнения утрачивается некоторая функциональная зависимость (т.е. детерминант и определяемые им атрибуты помещаются в разные отношения). В этой ситуации будет трудно обеспечить исходную функциональную зависимость отношения и важное ограничение может быть утрачено. Если имеет место упомянутая ситуация, то лучше закончить процесс нормализации на этапе образования ЗНФ-отношений, в которых все требуемые зависимости всегда сохраняются. В данном примере при создании двух новых НФБК-отношений на основе исходного отношения ИНТЕРВЬЮ_С_КЛИЕНТОМ утрачивается следующая функциональная зависимость: Номер_комнаты, Дата_Интервью, Время_Интервью -> Номер_Сотрудника, Номер_Клиента (зависимость fd3), поскольку детерминант этой зависимости больше не будет находиться в том же отношении, что и определяемые им атрибуты. Однако следует признать, что если не устранить функциональную зависимость Номер_Сотрудника, Дата_Интревью -> Номер_Комнаты (зависимость fd4), то отношение ИНТЕРВЬЮ_С_КЛИЕНТОМ обладать избыточностью данных.
|
