Пример 2.16. Рассмотрим конкретную проблему. Правильно ли мы поступил i, саелан стлию классом на рис. 2.6 или мнолссгвом сущностей на рис. Lfi Может быть, вместо ЭТ010 надо было сделать атрибутами студии ее название и адрес. vCJpaHiiB соо1Т!етствующиГ1 класс и..тн множество сущностей? С одной стороны, тогда пришлось бы адрес студии повторять для каждого фильма, что ведет к избы-точиостм. Кроме неудобств с изл1И11есгвами. упомянутых в разлеле 2.3.2, возникает риск потерять аакс студии, не ападеющсй ни одним фильмом.

С apyioii стороны, если адреса стдиГ! не записывагшсь, то нет ничего страшного в том. чтобы сделат!, название студии атрибутом фильмов Избыточности. связанноГ! с повторением адресов, не возникает. Ведь Г1ельзя считать избыточным упо.минание ступни Disney в связи с каждым фильмом, которым она владеет, поскольку нужно как-то определять владельца каждого фильма, а назвать при этом его имя вnoиe разумно. □

В общем случае предполагается, что если о чем-то известно больше, чем просто имя. то это что-то , по видимому, должно быть множеством сущностей, или классом, однако, если в модели можно использовать только имя, лучше создать атрибут. Здесь мы стапкиваемся с вопросом нормализации схем в реляционной модели, который будет рассматриваться в разделе 3.7.

Пример 2.17. Рассмотрим ситуацию, предполагающую определенный баланс между результатом применения многосторонней связи и множества связующих сущностей с бинарными связями. Например, четырехсторонняя связь Contracts между кинозвездой, фильмом и двумя студиями (см. рис. 2.12) механически конвертируется в множество сущностей Contracts (см. рис. 2.15). Имеет ли значение, какой из этих подходов выбирается?

В проектировании ODL, фактически, выбора нет, так как многосторонних связей не существует. В E/R-моделн приемлем любой подход. Однако незначительное изменение исходной задачи практически вынуждает нас выбирать подход, при котором используется множество связующих сущностей. Предположим, что в контракте могут фигурировать одна кинозвезда, один фильм, но любое множество студи!). Эга ситуация сложнее той, что изображена на рис. 2.12, где было всего две студии, играющие дпс роли Сейчас допускается любое число студий. Одна, возможно, выпускает фильм, другая организует спецэффекты, третья продает фильм кинотеат])ам и -г.д. Таким образом, приписать роли студиям невозможно.

В данио.4 случае оказывается, что множество отношений для связи Contracts должно содержать тройки вида

(кинозвезда, фильм, множество студий),

а сама связь Contracts - не только обычные множества сущностей Stars и Movies, но и новое множество сущностей, элементами которого являются множества студий. Если гакоГ) подход допустим, считать множества студий базовыми сущностями неприемлемо: мы ие рекомендуем это делать.

Contracts

Studios

Рис. 2.18. Иоктрокты, сввзывоющие кинозвезду, фильм и множество студий

2.3 Принципы гроектирования 43

Лучше считать множеством сушносп-ей контракты. Как и на рис. 2.15, контракт связывает кинозвезду, фильм и множество студий, о теперь число стдий ие ограничено. Поэтому между контрактами и студиями имеется связь типа .многие-ко-многим , а не многие-к-одному , как это было бы, если бы контракты были мастояшим множеством снязуюших сурдностей. Набросок E/R-диаграммы показан иа рис 2.18. Заметим, что здесь контракт связан с единственной кинозвездой и единственным фильмом, но с произвольным множеством студий.

Такая же стратегия проектирования под.чолит и для ODL Например, вполне приемлемо следующее о1И1сание интерфейса ODL:

interface Contract {

relationship Star theSlar; relationship Movie theMovie; relationship Set<Studio> studios;

Здесь объекты контрактов имеют три связи: с единственной кинозвездой, с единственным фильмом и с множеством студий. Обратные связи опушены. □

2.3.5 Упражнения к разделу 2.3

Упражнение 2.3.1. На рис. 2.19 дана ODL-разработка банковской БД, содержащей клиентов и счета. Предполагается, что смысл различных связей, и атрибутов выражен и\ именами. Сделайте критический разбор этой разработки. Какие правила здесь нарушены Предложите ваши изменения.

interface Address { atlnbute siring addr; relationship Set<Customer> residents inverse Customer:: livesAt;

interface Customer { attribute string name; relationship Address livesAt

inverse Address:.residents; relationship AcclSet accounts

inverse AcctSel::owner;

interface Account { attribute real balance; relationship Set<AcctSet> memberOf inverse AcctSel.:members;

interface AcctSet {

attribute string ownerAddress; relationship Customer owner

inverse Customer::accounts; relationship Set<Accounts> members

inverse Account: memberOf;

Рис. 2.19. Неудочноя роэроботко бонковской 6Д

Motlters

Babies

Births

Nurses

Doctors

Ри<. 2.20. Предсгоаление рождения с помощьо многосторонней связи

1! Ыпрожисние 2.3.2. В этом и следующем упражнениях рассматриваются два варианта разработки E/R-молел , описывающей рождение детей. В рождении участвует один ребенок (близнецы ассоциируются с двумя актами рождения), одна мать, любое число медсестер н любое число врачей. Поэтому предполагается, что есть множества сущностей ВоЫе, Mothers, Nuises и Doctors, а также связь Births между эт![ми множествами, как показано на рис. 2.20. Заметим, что кортеж множества oTHouiemiH для Births имеет вид

(ребенок, мать, медсестра, врач)

Если в родах участвуют несколько медсестер и/или врачей, будет множество кортежей с одними и теми же ребенком и матерью - по одному кортежу для каждой комбинации медсестры и врача.

Существуют определенные предпосылки, которые вполне уместно включить в эт> разработку. Покажите, как добавить в E/R-диаграмму стрелки или другие элементы, чтобы выразить каждую предпосылку.

a) У каждого ребенка есть единственная мать.

b) Для каждой комбинации ребенка, медсестры и доктора существует единственная мать.

c) .Цля каждой комбинаш<и ребенка и магери существует единственный врач.

1 Упрожнение 2.3.3. Другой подход решения проблемы из упражнения 2.3.2 состоит в то.м. чтоб1й связать четыре множества сущносгей Babies, Mothers, Nurses II Dociors с помощью одного множества сущностей Births с четырьмя связями между Biri/is и каждым из остальных множеств, как показано на рис. 2.21.

(Ы<. 2.21. Лредстоелеиие рождения с помощью множество сущностей