Представление связей в одном направлении

Наличие бинарной связи между двумя множествами сущностей предполагает возможность выбирать отношение, в котором эта свизь может появиться, т.е. OTHoujeHHe, построенное для любого из этих множесгв. Важно ли, какое именно из них выбирается? По-видимому, нет, если связь имеет тип многие-ко-многим или одии-к-одному . Но в случае связи типа многие-к-одному мы рекомендуем выбирать то, к чему относится слово многие , т.е. м}Южество сущностей, многие элементы которого могут быть связаны с единстБенной сущностью другого множества. В результате исключается избыточность.

Например, связь Owns между Movies и Studios лучше поместить в Movies. Таким образом отнохиение для Movies получает атрибут для имени владеющей фильмом студии и каждый кортеж расширяется именем такой студии. Напротив, если связь добавляется в Studios, кортеж для каждой студии необходимо расширять до множества кортежей, по одному для каждого фильма, которым владеет студия. В результате вся остальная информация о каждой студии будет дублироваться для каждого фшгьма, которым эта студия владеет.

3.2.8 Упражнения к разделу 3.2

Ылрожисние 3.2.1. Преобразуйте в схемы реляционных БД проекты ODL следующих упражнений;

*а) упражнения 2.1.1;

b) упражнения 2.1.2 (включая все четыре модификации, указанные в этом упражнении);

c) упражнения 2.1.3;

d) упражнения 2.1.4 *е) упражнения 2.1 5:

f) упражнения 2.1.6.

3 Конечно, нельзя гарант 1рооать, что в конкретной 0DL-pca4H43UHii эти указатели будут представлены именно так, как ожидается; фактически реатнзания может иметт, единсткснное представление лля пары юаимно обргипых спичей

Однако представления связи stars и ее обращения вместе избыточны, так как каадое из них выражает одну и ту же информацию. Поэтому можно, например, вообще убрать информацию starredin из оттюшения Star 1ли же оставить ее, но удалить ътраОут starName из отношения Move. В разделе 3.3.2 будет изложен третий возможный подход, при котором связь и ее обращение выделяются в виде новых отношений. Иногда, хотя и не всегда, именно такой подход прелпочтите.11Ь-нее. Впрочем, при выборе такого подхода процесс нормализации , обсуждаемый и разделе 3.7, иногда вынуждает разделять связь иа два новых отношения, даже если такого разделения не было в исходном реляционном проекте.

Заметим, что в модели ODL необходимы и связь, и ее обращение, так как они содержат указатели от фильмов на занятых в них кинозвездах и от кинозвезд на фильмы, в которых они играют. Невозможно следовать указателю обратно , поэтому нужны указатели в обоих направлениях Но в реляционной модели типа E/R-модели связи представляются с помощью соединения значений (ключей). Для отслеживания связей в обоих направлениях можно использовать кортежи с парами связанных ключей, например с названием и годом выпуска фильма и именем кинозвезды.

Упрожнение 3.2.2. Преобразуйте описание ODL на рис. 2.7 в схему реляиионной БД. Как повлияет на эт\ схему каждое нз трех изменений из упражнения 2.1.8?

Упражнение 3.2.3. На рис. 3.14 дано определение ODL класса клиентов. В объектах этого класса хранится множество типов телефонов (домашних, служебных, факсов) и множество ссылок , где отмечены заслуги клиента в асле воапечения в бизнес других клиентов. Преобразуйте это определение в схему реляционной БД.

interface Customer { attribute Struct Name

{string first, string last} name; attnbute Set <

Struct Phone {string type, int number} > phones;

relationship Customer referredSy inverse referrals; relationship Set<Customer> refen-als inverse referred By;

Рис. 3.14. Зописи о нлиентох

Указатели: \

полезное средство j

или технический недостаток? j

I Связи ODL реализуются преимущественно с помошью указателей и ссылок 1 от каадого объекта на связанные с ним объекты или объект. Такая реализа- j ция очень удобна, так как позволяет быстро перейти от объекта к связанным j с ним обг>екгам. По сравнению с этим способом реляционная модель, пред- J } сгавляюшая объекты значением их ключа, а не указателем, требует более f J мелпенного перехода между связанными объектами. ,

i Так. в примере 3.7 объект Movie представлен одним кортежем для каждой Е кинозвезды, играющей в фильме. В таком кортеже отсутствует какая-либо i информации о кинозвезде, кроме имени. Чтобы найти адреса кинозвезд, занятых в фильме laynes World, нужно взять имя каждой кинозвезды и найти в отношении Star кортеж или кортежи для искомой кинозвезды - только тогда получим адрес.

Таким образом, возникает впечатление, что отсутствие указателей - это технический недостаток реляционной модели. На практике же можно создать индексы на отношениях, которые позволяют вести эффективный поиск кортежей, имеющих заданное значение в заданном компоненте (см. разделы 1.2.1 и 5,7.7). Значит, при отсутствии указателей прак-тические потери невелики. Ьолее того, указатели очень полезны в программах, которые действуют в главной памяти и выполняются за считанные секунды, а БД значительно отличаются от таких iipoipaMM. Реализация указателей среди объектов, существующих гоаами и распределенных по многим устройствам вторичной памяти, подключенным к широко распределенным компьютерным системам, намного сложнее метода реляционных моделей, не содержащих указателей.

3-3 Переход от E/R-диаграмм к реляционным проектам

Переход от диаграммы сушностм-связн к схеме БД аналогичен переходу к ней от проекта ODL. В принципе, E/R-модсль - это переходная форма между объектно-ориентированным н реляционным проектами. Поэтому, начав с E/R-диаграмыы, мы имеем проект, в котором уже проделана большая часть работы. Между ODL и E/R-моделями есть три важных различия:

1. В E/R-модели связь является отдельным понятием, а не свойством юшсса, что помогает избежать избыточности (см. раздел 3.2.2), которая возникает при погружении многозначной связи типа stars в кортежи, представляющие объекты Movie.

2. В ODL атрибуты могут иметь любой тип множества, например <Set>. В E/R-модели точно не определено, какие именно типы разрешены, но обычно считается, что допустимы структурированные значения, но не множества или другие конструкторы типа множества.* В результате атрибуты типа множества адресов кинозвезды из примера 3.4 вынуждают рассматривать адрес в E/R-модели как множество сушностей и определять связь Lives-at между кинозвездами и их адресами.

3. В E/R-модели связи могут иметь атрибуты. В ODL соответствующего понятия нет.

3.3-1 Переход от множества сущностей к отношениям

Рассмотрим множество сушностей, не являющееся слабым (модификации, связанные со слабыми множествами сущностей, оставим до раздела 3.3.3). Для каждого не слабого множества создадим отношение с таким же именем и с тем же самым множеством атрибутов. В этом отношении не будет никаких указаний на связи, в которых участвует данное множество сущностей; мы будем работать со связями с помощью отдельных отношений, как было показано в разделе 3.3.2.

Пример ЗЛО. Рассмотрим множества Movies, Stars и Studios, изображенные на рис. 2 8, который здесь воспроизведен как рис. 3.15. Атрибутами множества Movies являются title, year, length и filmType. Поэтому отношение Movie имеет точно такой же вид, как на рис. 3.1, с которого начинается раздел 3.1. □

Рие. 3.15. е/О-диогромлю дпя БД фильмов

4 Все же существуют (]юрмулировки E/R-модели, испояьзуюшис в точпости те же ограничения на типы атрн6)тн. что и ODL типом может быть .множество структур . или что то более простое.