Первая нормальная форма (1НФ) отношения Customer Rental

Отношение Customer Rental определяется следующим образом:

Customer Rental (Customer_No, Property_No, CName, PAddress, RentStart,RentFinish, Rent, Owner_No, OName).

Отношение Customer Rental находится в первой нормальной форме, поскольку на пе­ресечении каждой строки и каждого столбца имеется единственное значение. Это от­ношение содержит данные о клиентах, арендованных объектах недвижимости и их владельцах, которые несколько раз повторяются. Таким образом, отношение Customer_Rental характеризуется значительной избыточностью данных.

Вторая нормальная форма (2НФ). Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух и более атрибутов. Дело в том, что отношение с первичным ключом на основе единственно­го атрибута всегда находится, по крайней мере, в 2НФ. Отношение, которое не на­ходится в 2НФ, может страдать от аномалий обновления. Например, предположим, что необходимо изменить арендную плату (Rent) для объекта недвижимости с номером ‘PG4’. Для этого потребуется обновить две строки отношения Customer Rental. Если значение арендной платы будет обновлено только в одной строке, то в результате база данных будет приведена в противоре­чивое состояние.

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

Нормализация 1НФ-отношений с образованием 2НФ-отношений включает устра­нение частичных зависимостей, что демонстрируется на примере отношения Customer_Rental (см. табл. 16). Если в отношении между атрибутами су­ществует частичная зависимость, то функционально-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.

Пример. На рис. 13 показаны функциональные зависимости (от fdl до fd6) для отношения Customer_Rental с парой атрибутов (Customer_No, Property_No) в качестве первичного ключа. Отношение Customer Rental обладает следующими функциональными зависимостями:

Рис. 13. Функциональные зависимости отношения Customer_Rental

После выявления функциональных зависимостей процесс нормализации отноше­ния Customer_Rental продолжается проверкой его принадлежности ко второй нор­мальной форме. Для этого требуется найти хотя бы один случай частичной зависимости от первичного ключа. Нетрудно заметить, что атрибут имени клиента CName частично зависит от первичного ключа, иначе говоря, он зависит только от атрибута Customer_No (эта зависимость представлена на рис. 13 как fd2). Кроме того, атрибуты объекта недвижимости (PAddress, Rent, Owner_No, OName) также частично за­висят от первичного ключа, но на этот раз только от атрибута Property_No (эта зависимость представлена на рис. 13 как fd3). В свою очередь, атрибуты арендованных объектов недвижимости (RentStart и RentFinish) полностью функционально зависят от первичного ключа в целом, т.е. от атрибутов Customer_No и Property_No (эта завиcимость представлена на рис. 13 как fd1).

Обратите внимание на то, что на рисунке показано наличие транзитивной зависи­мости (transitive dependence) от первичного ключа (эта зависимость представлена на рис. 13 как fd4). Хотя транзитивная зависимость также может послужить причиной аномалий обновления, тем не менее ее присутствие в отношении не нарушает oграничений для 2НФ. Такие зависимости будут устранены при переходе к 3НФ.

Обнаружение частичных зависимостей внутри отношения Customer Rental обозна­чает, что данное отношение не находится во второй нормальной форме. Для преоб­разования отношения Customer Rental в 2НФ необходимо создать новые отношения, причем так, чтобы атрибуты, не входящие в первичный ключ, были перемещены в них вместе с копией части первичного ключа, от которой они функционально зависят. Применение этого правила в нашем случае приведет к созданию трех новых отношений – Customer, Rental и Property_Owner, которые представлены в табл. 17–19 соответственно. Теперь эти три отношения находятся во второй нормальной форме, поскольку каждый атрибут, не входящий в первичный ключ, полностью функционально зависит от первичного ключа отношения. Эти отношения имеют следующий вид (подчеркнутые атрибуты – это ключи):

Customer (Customer_No. CName)

Rental (Cus’tomer_No, Property_No, RentStart, RentFinish)

Property_Owner (Property_No. PAddress, Rent, Owner_Mo, OMame)

Таблица 17

Отношение Customer

Таблица 18

Отношение Rental

Таблица 19

Отношение Property_Owner

Третья нормальная форма (3НФ).Хотя 2НФ-отношения в меньшей степени обладают избыточностью данных, чем 1НФ-отношения, они все еще могут страдать от аномалий обновления. Так, при попытке обновления имени владельца недвижимости (например, Tony Shaw с номе­ром С093 (атрибут Owner No)) потребуется обновить две строки отношения Ргорerty_Owner. Если обновить только одну из этих двух строк, база данных попадет в противоречивое состояние. Эта аномалия обновления вызывается транзитивной зависимостью, присутствующей в данном отношении. Она может быть устранена путем приведения данного отношения к третьей нор­мальной форме. В этом разделе транзитивные зависимости рассматриваются вместе с третьей нормальной формой.

Транзитивная зависимость – если для атрибутов А, В и С некоторого отношения существуют зависимости вида А–>В и В–>С, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).

Транзитивная зависимость является описанием такого типа функциональной зависимости, которая возникает при наличии следующих функциональных зависимо­стей между атрибутами А, В и С:

А–>В и В–>С.

В данном случае транзитивная зависимость А–>С осуществляется через атрибут В. Это утверждение справедливо только в том случае, если атрибут А функционально не зависит от атрибутов В и С.

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

Нормализация 2НФ-отношений с образованием 3НФ-отношений включает устранение транзитивных зависимостей. Если в отношении существует транзи­тивная зависимость между атрибутами, то транзитивно-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.

Пример. Сначала рассмотрим функциональные зависимости, существующие в отношениях Customer, Rental и Property_Owner.

Отношение Customer

fd2 Customer No –> CName

Отношение Rental

fd1 Customer No, Property No –> RentStart, RentFinish

fd5* Customer No, RentStart –> Property_No, RentFinish

fd6* Property No, RentStart –> Customer No, RentFinish

Отношение Property Owner

fd3 Property No –> PAddress, Rent, Owner No, OName

fd4 Owner No –> OName

Все не входящие в первичный ключ атрибуты отношений Customer и Rental функционально зависимы только от их первичных ключей. Следовательно, отношения Customer и Rental не имеют транзитивных зависимостей, а потому они уже находятся в третьей нормальной форме. (Обратите внимание на то, что обозначения некоторых функциональных зависимостей (fd) помечены звездочкой (*), что означает изменение этой зависимости (по сравнению с исходной функциональной зависимостью.)

Все не входящие в первичный ключ атрибуты отношения Property_Owner функционально зависят от первичного ключа, за исключением атрибута OName, который также зависит и от атрибута Owner_No (зависимость fd4). Это типичный пример транзитивной зависимости, которая имеет место при наличии зависимости не входящего в первичный ключ атрибута (OName) от одного или нескольких других атри­бутов, также не входящих в первичный ключ (Owner_No). Данная транзитивная за­висимость схематически показана на рис. 13.

Для преобразования отношения Property_Owner в третью нормальную форму необходимо прежде всего удалить упомянутую выше транзитивную зависимость путем создания двух новых отношений Property_for Rent и Owner, которые представлены в табл. 20 и 21 соответственно. Новые отношения имеют следующий вид:

Property_for_Rent (Property.No. PAddress, Rent, Owner_No)

Owner (Owner No. OName)

Таблица 20