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

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

1. Разработка универсального отношения для БД.

2. Определение всех ФЗ между атрибутами отношения.

3. Определение того, находится ли отношение в НФБК. Если да, проектирование завершается; если нет, отношение должно быть разбито на два отношения.

4. Повторение шагов 2 и 3 для каждого нового отношения, полученного в результате декомпозиции. Проектирование завершается, когда все отношения будут находиться в НФБК.

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

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

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

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

<Nom> и <Adr>.

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

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

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

Далее нужно решить, какую ФЗ следует выбрать для проведения первой проекции. Простым правилом выбора ФЗ для проекции может служить поиск “цепочки ФЗ” вида А®В®С с последующим использованием для проекции крайней правой зависимости. В нашем случае такой “цепочкой” является Nom®Adr®Ntel и “конец цепочки” Adr®Ntel порождает первую проекцию. Полученные в итоге отношения R1 и R2 приведены на рис.1.6 вместе с их ФЗ.

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

Nom®FIO, Nom®Rdate, Nom®Pol, Nom®SumD, Nom®Adr,
что можно рассматривать в качестве единой ФЗ с составной правой частью

Nom®FIO,Rdate,Pol,SumD,Adr.

Рис.1.6. Отношения R1 и R2 как
результат проекций отношения Zgrad

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

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

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

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

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

R3 (Nom, FIO, Rdate, Pol, SumD, Adr)

R2 (Adr, Ntel)

R4 (Nom, Source, Money )

а

Nom	FIO	Rdate	Pol	SumD	Adr
	Иванов И.И.	11.03.78	м		801-12
	Петрова П.П.	01.12.79	ж		05-321
	Иванова И.И.	14.04.30	ж		801-12
	Ильин Ф.П.	25.06.70	м		901-323
	Иванов И.И.	23.10.28	м		801-12

Adr	Ntel		Nom	Source	Money
801-12	531-5894			Работа1
05-321	Нет			Работа2
901-323	534-9900			Стипендия
				Работа1
				Пособие
				Пенсия
				Работа3
				Пенсия

б

Рис.1.8. Спроектированная база данных ZgradDB:
а - отношения; б - экземпляры отношений

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

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

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

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

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

Дата добавления: 2015-07-20