Методы проектирования логических моделей реляционных баз данных. Декомпозиция и синтез отношений
Сформулируем третье правило.
Правило 3. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей не является обязательным, то требуется построение трех отношений - по одному на каждую объектную сущность и одному для связывающего отношения. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи, с первичным ключом, составленным из ключей объектных сущностей.
Пример. Исходное отношение: ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов) Результирующие отношения: ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов) ЧИТАЕТ (Табельный_номер, Предмет)
Это правило можно применить в третьем варианте поведения предметной области, когда исходное отношение необходимо разбить на три отношения. Разбиение на два отношения не позволит исключить проблему нуль-значений. В случае трех отношений такая проблема исключается: в отношение ПРЕДМЕТЫ для предмета, который в данный момент не читается, определяется непустое значение по умолчанию.
Сформулируем четвертое правило.
Правило 4. Если степень бинарной связи 1:N, и класс принадлежности n-связной сущности является обязательным, то достаточно построить два отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения, а ключ 1-связной сущности добавляется в отношение для n -связной сущности в качестве атрибута.
Пример. Исходное отношение: ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов) Результирующие отношения: ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов, Табельный_номер)
Сформулируем пятое правило.
Правило 5. Если степень бинарной связи 1:N и класс принадлежности n-связной сущности не является обязательным, то необходимо построить три отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами последнего отношения.
Пример. Исходное отношение: ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов) Результирующие отношения: ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов) ЧИТАЕТ (Предмет, Табельный_номер)
Отметим, что если степень бинарной связи 1:N, то фактором, определяющим выбор одного из правил (правила 4, 5), является класс принадлежности n-связной сущности. Класс принадлежности 1-связной сущности не влияет на конечный результат декомпозиции. В ситуации правила 4 имеет место проблема нуль-значений по атрибуту Предмет, в ситуации правила 5 имеет место проблема нуль-значений по атрибутам Предмет и Преподаватель. Поэтому во избежание дублирования и нуль-значений в ситуации правил 4 и 5 необходимо строить два и три результирующих отношения соответственно. Миграция ключа 1-связной сущности выполняется для восстановления исходного отношения при соединении.
Если степень бинарной связи N:M, то во избежание дублирования и нуль-значений необходимо всегда строить три отношения. Сформулируем шестое правило.
Правило 6. Если степень бинарной связи M:N, то необходимо построить три отношения - по одному для каждой сущности и одно отношение для связи. При этом ключ каждой сущности является первичным ключом соответствующего отношения, и входит в составной первичный ключ отношения для связи.
Пример. Исходное отношение: ПРЕПОДАВАТЕЛЬ_1 (Табельный_номер, Фамилия, Предмет, Количество_часов) Результирующие отношения: ПРЕПОДАВАТЕЛЬ_2 (Табельный_номер, Фамилия) ПРЕДМЕТЫ (Предмет, Количество_часов) ЧИТАЕТ (Предмет, Табельный_номер)
Для отношения с трех- и более сторонней связью во избежание избыточности и нуль-значений требуется построение не менее четырех отношений. Сформулируем седьмое правило.
Правило 7. Если связь является трехсторонней, необходимо построить четыре отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами последнего отношения.
Аналогично для отношения с n-сторонней связью требуется построение n+1 отношений.
Отметим, что все вышесформулированные правила построены по одному общему принципу: каждому неключевому атрибуту - свое отношение, т.е. миграция неключевых атрибутов запрещена.
Следует помнить, что после предварительного разбиения исходного отношения необходимо показать, используя ФЗ и ключи отношений, что полученная схема реляционной базы данных находится в НФ Бойса-Кодда (НФБК) (или 3НФ). Только тогда полученная схема отношений может считаться окончательной. Обычно проектировщики баз данных при использовании метода декомпозиции не выполняют таких действий, так как в большинстве случаев (но не всегда!) применение правил преобразования дает НФБК.
В некоторых случаях может оказаться, что для создания логической модели предметной области базы данных недостаточно имеющихся сущностей и связей. Одним из них является ситуация, когда экземпляры одной сущности играют разные роли (супертип/подтип) в предметной области базы данных. Это обусловливается наличием между экземплярами сущности отношения иерархии или агрегации по включению. При этом сущность представляет собой множество с отношением порядка на экземплярах, что приводит к наличию классов эквивалентности, имеющих различную семантическую интерпретацию в предметной области.
Так, например, база данных кафедры института содержит две категории служащих - преподаватели и заведующий кафедрой. Заведующий кафедрой также может читать лекции по предметам, но получает обычно фиксированный оклад; преподаватели имеют почасовую ставку оплаты. Попробуем представить информацию о служащих кафедры более подходящим образом. Выделим для каждой категории служащих кафедры отдельную сущность и рассмотрим ER-диаграмму Зав. кафедрой Руководит Преподавателями.
При этом ключом каждой сущности будет являться табельный номер служащего. Поскольку связь Руководит имеет степень 1:N, и класс принадлежности обеих сущностей является обязательным, то согласно правилу 4 достаточно построить два предварительных отношения. Поскольку неключевые атрибуты Фамилия и Адрес_служащего помещены в оба предварительных отношения, то согласно общему принципу правил преобразования они должны быть переопределены для одного из отношений. Переименование атрибутов в одном из отношений порождает проблему ответа на запрос: для того чтобы найти домашний телефон конкретного служащего, необходимо пересмотреть оба отношения и построить объединение результатов просмотра. Таким образом, переименование атрибутов, к которому иногда поспешно прибегают проектировщики, не является хорошим решением.
Рассмотрим иной вариант представления данных о служащих кафедры. Будем считать заведующего кафедрой и преподавателей служащими, и представим их функции как роли, которые данный служащий может играть. Тогда Отношение СЛУЖАЩИЙ представляет собой родительское отношение - супертип для двух подчиненных отношений - подтипов ЗАВ. КАФЕДРОЙ и ПРЕПОДАВАТЕЛЬ, которые соединяются связью Руководит (см. рис. 7.1).
Родительское отношение - супертип - содержит общие с подчиненными отношениями-подтипами атрибуты. Подчиненные отношения - подтипы содержат специфическую для их ролей информацию. Каждое порождаемое ролью отношение связано с общим отношением через атрибут общего домена, в данном случае табельный номер. Окончательный набор отношений будет состоять из трех отношений.
Результирующие отношения:
СЛУЖАЩИЙ (#служащий, общие атрибуты для всех служащих) ЗАВЕДУЮЩИЙ (#заведующий, .... ) ПРЕПОДАВАТЕЛЬ (#преподаватель, ..., #заведующий)
Заметим, что связь, которая соединяет две роли одной исходной сущности, называется рекурсивной (служащие руководят служащими). Связь, которая соединяет роли двух различных сущностей, не является рекурсивной.
Чтобы избежать поиска с целью выявления типа работы служащего, можно ввести в родовое отношение дополнительный атрибут, определяющий, кем является служащий. Несмотря на то, что с точки зрения теории реляционных баз данных такой прием приводит к избыточности данных, к нему прибегают в целях увеличения производительности системы.
Сформулируем восьмое правило.
Правило 8. Исходная сущность служит источником генерации одного отношения. Ключ сущности есть ключ отношения. Подчиненные сущности (ролевые элементы) и связи, соединяющие их, порождают такое количество отношений, которое определяется набором правил 1-7, причем каждый ролевой элемент трактуется как обычная сущность.