Отношение Property for_Rent в третьей нормальной форме

 

Таблица 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