Таблица 21
Отношение Owner в третьей нормальной форме
Отношения Property_for_Rent и Owner находятся в третьей нормальной форме, поскольку в них нет никаких транзитивных зависимостей от первичного ключа.
В результате выполнения нормализации представленное в табл. 16 исходное отношение Customer_Rental было преобразовано в четыре отдельных отношения, каждое из которых находится в третьей нормальной форме. На рис. 14 приведена схема данного процесса, поясняющая, как 1HФ-отношение было преобразовано в четыре ЗНФ-отношения, имеющие следующий вид:
Customer (Customer_.No, CName)
Rental (Customer_No. Property.No, RentStart, RentFinish)
Property for Rent (Property_No, PAddress, Rent, Owner_No)
Owner (Owner_No. OName)
Исходное отношение Customer Rental, представленное в табл. 16, может быть восстановлено путем соединения отношений Customer, Rental, Property_for_Rent и Owner. Данная цель достигается за счет использования первичных и внешних ключей. Например, атрибут Owner_No является первичным ключом отношения Owner и, кроме того, присутствует в отношении Property for Rent как его внешний ключ. Атрибут Ovner_No, используемый для создания пары из первичного и внешнего ключей, позволяет связать отношения Property_for_Rent и Owner с целью определения имен владельцев объектов недвижимости, сдаваемых в аренду.
Рис. 14. Схема декомпозиции 1НФ-отношения Customer Rental на четыре отношения в третьей нормальной форме
Атрибут Customer_No является первичным ключом отношения Customer и дополнительно внешним ключом отношения Rental. Обратите внимание на то, что в отношении Rental атрибут Customer_No выполняет функции как внешнего, так и части первичного ключа. Аналогичным образом, атрибут Property_No является первичным ключом отношения Property_for Rent и дополнительно в отношении Rental выполняет функции как внешнего ключа, так и части первичного ключа.
Иначе говоря, процесс нормализации заключается в декомпозиции исходного отношения Customer_Rental посредством последовательного выполнения нескольких операций проекции реляционной алгебры. Полученные в результате декомпозиции отношения обеспечивают выполнение их соединения без потерь, поэтому данную процедуру иначе называют беспроигрышной (nonloss) (или неаддитивной (nonadditive)) декомпозицией. Результаты декомпозиции можно обратить посредством операции естественного соединения.
Окончательный вид отношений Customer, Rental, Property_for_Rent и Owner, полученных в результате декомпозиции, представлен в табл. 22–25.
Таблица 22
Отношение Customer
Таблица 23
Отношение Rental
Таблица 24
Отношение Property for Rent
Таблица 25
Отношение Owner
Определение нормальной формы Бойса–Кодда. Нормальная форма Бойса–Кодда (НФБК) учитывает функциональные зависимости, в которых участвуют все потенциальные ключи отношения, а не только его первичный ключ. Для отношения с единственным потенциальным ключом его ЗНФ и НФБК являются эквивалентными.
Отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом.
Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами. Напомним, что детерминантом является один атрибут или группа атрибутов, от которой полностью функционально зависит другой атрибут.
Различие между 3НФ и НФБК заключается в том, что функциональная зависимость А –> В допускается в 3НФ-отношении, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. Тогда как в НФБК-отношении эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно, нормальная форма Бойса–Кодда является жесткой версией формы 3НФ, поскольку каждое НФБК-отношение является 3НФ-отношением, но не всякое 3НФ-отношение является НФБК-отношением.
Перед тем как обратиться к очередному примеру, еще раз рассмотрим отношения Customer, Rental, Property for Rent и Owner (см. табл. 22–25). Отношения Customer, Property_for_Rent и Owner являются НФБК-отношениями, так как каждое из них имеет только один детерминант, который в то же время является потенциальным ключом этого отношения. Тут следует напомнить, что отношение Rental содержит три детерминанта – (Customer No, Property No), (Customer No, RentStart) и (Property_No, RentStart)– и имеют следующий вид:
fd1 Customer_No, Property No –> RentStart, RentFinish
fd5* Customer_Mo, RentStart –>Property_No, RentFinish
fd6* Property No, RentStart –> Custoroer No, RentFinish
Поскольку эти три детерминанта отношения Rental являются также потенциальными ключами, то отношение Rental находится в НФБК. Нарушения требований НФБК происходят крайне редко, поскольку это может случиться только в следующих случаях:
• имеются два (или более) составных потенциальных ключа;
• эти потенциальные ключи перекрываются, т.е. ими совместно используется, по крайней мере, один общий атрибут.
Опишем ситуацию, когда отношение нарушает требования НФБК, и представим метод преобразования этого отношения в НФБК. Рассмотрим отношение Client Interview, которое содержит сведения о собеседованиях клиентов с сотрудниками компании. Для проведения собеседования в тот день, на который назначена встреча с клиентом, в распоряжение сотрудника предоставляется особая комната. Однако в течение рабочего дня эта комната может использоваться несколькими разными сотрудниками. С клиентом проводится только одно собеседование в день, но он может участвовать в нескольких собеседованиях в разные дни. Обсуждаемое отношение имеет три потенциальных ключа: (Client No, Interview Date), (Staff No, Interview Date, Interview Time) и (Room No, Interview Date, Interview Time). Следовательно, отношение Client Interview обладает тремя составными потенциальными ключами, которые перекрываются, т.е. ими совместно используется один общий атрибут Interview Date. В качестве первичного ключа данного отношения выбрана комбинация атрибутов (Client No, Interview Date). Это отношение представлено в табл. 26 и имеет следующий вид:
Client_Interview (Client_No. Interview.Date. Interview_Time, Staff_No, Room No)
Таблица 26
