Первая нормальная форма (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