Общий подход к декомпозиции отношений

Проектирование реляционной БД методом декомпозиции отношений в простейшем случае состоит из четырех шагов [5].

• 1. Разработка универсального отношения для БД.
• 2. Определение всех ФЗ между атрибутами отношения.
• 3. Определение того, находится ли отношение в НФБК. Если да, проектирование завершается; если нет, отношение должно быть разбито на два отношения.
• 4. Повторение шагов 2 и 3 для каждого нового отношения, полученного в результате декомпозиции. Проектирование завершается, когда все отношения будут находиться в НФБК.

Разбиение отношения на два новых отношения осуществляется с помощью ФЗ следующим образом.

Пусть отношение R (A, B_yC, D, E_y…) не находится в НФБК. Определяется ФЗ, например С—про которую известно, что она служит причиной того, что отношение R не находится в НФБК (т.е. С является детерминатом, но не является возможным ключом). Создаются два новых отношения — проекции отношения R — R1(A_yB_yC_yE_y…) и R2(C_yD), где зависимая часть ФЗ (т.е. атрибут D) была выделена из R и опущена мри формировании отношения R1, а ФЗ была использована полностью при формировании отношения R2. После этого нужно проверить, находятся ли в НФБК отношения R1 и R2.

Этот тип декомпозиции называется декомпозицией без потерь при естественном соединении.

В качестве примера использования описанного метода проведем декомпозицию отношения Zgrad. Обращаясь к определенным в предыдущем разделе детерминантам и возможным ключам этого отношения, видим, что имеются два детерминанта, которые не являются возможными ключами:

и .

Перед началом декомпозиции разрабатывается универсальное отношение.

Zgrad (Nom. Source. FIO, Rdate, Pol, Adr, Ntcl, Money, SumD) и определяются все ФЗ между атрибутами отношения (см. рис. 5.5).

Кандидатами среди ФЗ для осуществления проекций являются ФЗ, зависящие от детерминантов Nom и Adr: Nom—"FIO, Nom-" Relate, Nom-" Pol, Nom-«SumD, Nom-» Adr, Adr-«Ntel, Nom—"Ntel.

Далее нужно решить, какую ФЗ следует выбрать для проведения первой проекции. Простым правилом выбора ФЗ для проекции может служить поиск «цепочки ФЗ» вида А—"5-«С с последующим использованием для проекции крайней правой зависимости. В нашем случае такой «цепочкой» является Nom—"Adr—"Ntel и «конец цепочки» Adr—"Ntel порождает первую проекцию. Полученные в итоге отношения R1 и R2 приведены на рис. 5.6 вместе с их ФЗ.

Поскольку все детерминанты отношения R2(Adr. Ntcl) являются возможными ключами, то оно находится в НФБК и не нуждается более в декомпозиции. Однако отношение R1(Nom,

ЯД Nom, Source. FIO, Relate, Pol, SumD, Adr, Money).

Puc. 5.6'. Отношения R1 и R2 как результат проекций отношения Zgrad.

Source. FIO, Rdate, Pol, SumD, Adr, Money) не находится в НФБК, так как детерминант не является возможным ключом. Следовательно отношение R1 необходимо подвергнуть дальнейшему разбиению. Детерминант, из-за которого возникло затруднение, имеет пять зависимых от него атрибутов.

Nom-«FIO, Norn-» Rdate, Norn-" Pol, Nom-«SumD, Norn-» Adr, что можно рассматривать в качестве единой ФЗ с составной правой частью.

Проекции отношения R1 на множества атрибутов {Norn, FIO, Rdate, Pol, SumD, Adr} и {Nom, Source, Money} приводят к получению отношений RJ и R4, показанных на рис. 5.7. Эти два отношения находятся в НФБК и вместе с отношением R2 могут использоваться в качестве дататогической модели БД со сведениями о жителях. На рис. 5.8 представлен окончательный вид отношений для спроектированной БД ZgradDB, а также экземпляры каждого отношения с данными, совпадающими с использованными для исходного отношения Zgrad (см. табл. 5.1).

Из полученной БД видно, что в процессе декомпозиции автоматически произошло разбиение исходного отношения Zgrad на три логических компонента: R2, в котором содержится ин;

Рис. 5.7. Отношения R3 и R4 как результат проекций отношения R1.

формация о квартирах и телефонах; R3, в котором содержится информация о жителях, их общих доходах и адресах; R4, в котором содержится информация об источниках и размерах доходов жителей. Такое логическое разбиение является прямым результатом использования в процессе декомпозиции заложенной в ФЗ информации, детализирующей то, как различные атрибуты в исходном отношении соотносятся друг с другом.

Подобно тому, как проверялась на наличие аномалий вставки, обновления и удаления одиотабличная БД Zgrad, следует проверить и спроектированную БД ZgradDB.

Аномалия вставки. Если появляется новый житель, у которого отсутствуют источники дохода, то для него в отношение R3 включается строка с известными (непустыми) значениями всех полей. В другие отношения строки не вставляются, а факт отсутствия источников доходов у жителя представляется в БД ZgradDB нулевым значением общего дохода SumD. Поскольку пустых (т.е. неопределенных) полей в БД не появляется, го регистрация нового жителя в БД происходит успешно, а следовательно, аномалия вставки не проявляется.

Рис. 5.8. Спроектированная база данных ZgradDB:

а — отношения; б — экземпляры отношений.

Аномалия обновления. В БД ZgradDB существенно уменьшена избыточность. Так, независимо от числа доходов у жителя сведения о каждом жителе в отношении R3 представлены одной строкой. Например, если Петрова П. П. сообщит об изменении своего адреса, то придется изменить ее адрес в единственной строке отношения R3, а не во многих строках, как это происходит в БД Zgrad.

В спроектированной БД также исключена избыточность номеров телефонов, установленных в квартирах. Допустим, Иванов И. И. 1978 года рождения известит служащего, работающего с базой данных, о том, что его номер телефона изменен на 531−55−33. Служащий изменит помер телефона только в одной строке отношения /?2, содержащей телефонный номер, соответствующий квартире с адресом 802−12, в которой проживает Иванов И. И. 1978 года рождения. При этом для всех жителей этой квартиры в БД окажется сохраненным правильный номер телефона.

Рассмотренные примеры обновления данных свидетельствуют, что в БД ZgradDB аномалия обновления не проявляется.

Аномалия удаления. Предположим, что работающий с базой данных служащий узнает, что житель Ильин Ф. П. лишился своего источника дохода, условно именуемого РаботаЗ, и удаляет из отношения R4 кортеж. Вся другая информация об Ильине в БД сохраняется. Если служащий вслед за этим запросит список жителей, зарегистрированных в БД, в нем окажутся сведения и об Ильине, т. е. в БД ZgradDB аномалия удаления не проявляется.

Следовательно, НФБК действительно гарантирует устранение большинства аномалий в базах данных.