Посмотрим теперь на рис. каждый продукт может быть получен от разных поставщиков, и тройная связь отсутствует.

Suppliers

SuppllerProducts &

Products

Customera

Гис, 3-17. Тройная связь отсутствует

Один из способов решить проблему - выяснить направление связи один ко многим . Для каждой отдельной сущности, участвующей в связи со стороны многие , можно однозначно определить соответствующую сущность, участвующую в связи со сторон одинб. Так, для каждого конкретного значения атрибута 3-16)

можно определить, к какому из значений атрибута Orders он принадлежит; зная значение Orders, нетрудно определить значение Customers. Точно так же выполнимы эти действия и в обратную сторону: зная значение OrderDetails, можно определить, какой именно продукт заказан и кто являлся его поставщиком.

Однако в обратном направлении связи один ко многим подобный подход применить не удастся, поскольку каждой сущности, участвующей в связи со стороны один , невозможно сопоставить ственную сущность, участвующую в связи со стороны многие . Рассмотрим пример на рис. 3-17. По определенному значению атрибута OrderDetails невозможно определить, какой продукт был заказан. Если же это известно, нельзя определить, с какой именно сущностью

связан этот продукт, или другими словами, выяснить, кто

поставил.

Отсюда следует упрощенное правило: в цепочке связей нельзя менять направления связей один ко многим на многие к одному

более одного раза. В цепочке связей на рис. 3-16 направление изменяется только один раз, на сущности OrderDetails. В цепочке связей на рис. 3-17 направление меняется дважды - один раз на сушности OrderDetails, а второй - на plieiProducts.

Проблему можно решить, исключив сущность Products из цепочки связей (рис. 3-18).

Products

Suppliers

SupptierProdiiCtsI -Т-

I-Щ OrderDetails

Orders -m-

Gusto me rs

Рис. 3-18 ойные связи сохранены

В получившейся т)чке направление связи меняется только один раз - на сущности OrderDetails, и таким образом связь поддерживается. При этом сущность Products отнюдь не исключена из модели, Скорее всего, заказы будут оформляться на продукты (сущность Products), а не на поставщиков (сущность Pmdiicts),и сущность Products позволит учитывать это при разработке пользовательского интерфейса.

Конечно, может быть, для вашей предметной области тройные связи не играют существенной роли. Или же тройная связь не нужна, так как вы применяете иной способ проследить необходимые связи (например, с помощью номера на коробке с расфасованным товаром). Важно, что модель на рис. 3- iS ничуть не лучше и не правильнее модели на рис. 3-17. Выбор модели определяется прежде всего семантикой предметной области.

Связи определенной мощности

Часто число кортежей отношения, участвующего в связ ко

многим со стороны многие , можно оценить заранее: известно ми-.

максимальное или точное число таких записей. Например, у школьников младших классов каждый день бывает не больше пяти уроков, скелет взрослого человека состоит из 200 костей, а на шахматном турнире каждый из участников соревнований должен сыграть определенное число партий,

В подобной ситуации появляется искушение построить модель данных таким образом, чтобы включить ключ-кандидат каждого кортежа как атрибут отношения с одной стороны (рис. 3-19). Но у такого способа два серьезных недостатка, Первый в подобной модели существуют повторяющиеся группы атрибутов, второй - она не надежна.

rEiotcgy Frlпcl Enqliin Hin ](

ш-...........-1 J ..........---Й.-

чащ Frpncri E-qHih

A(c. J-JP. Модель для связи тной мощностью (неверный подход)

атрибуты на рис. 3-19 легко выявить по именам, однако все они определены на одном домене - Когда в

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

за имена атрибутов.

К тому же, как уже говорилось, структуры, организованные по этому принципу, не надежны. Допустим, компания проводит такую кадровую политику; за каждым менеджером закрепляется не более пяти служащих, отчитывающихся непосредственно перед ним. Увы, политика и реальность - это разные вещи. Закладывая политику в модель данных, вы тем самым реализуете ее как жесткое системное ограничение, которое не может быть изменено впоследствии. Могу поспорить, что при вводе реальных данных хотя бы

за одним менеджером в компании закреплено шесть а не

пять. Что произойдет в этом случае? Будет ли одному из служащих

назначен другой менеджер? Будет ли продублирована запись, идентифицирующая менеджера в базе данных, и соответственно увеличится ли заработная плата, начисляемая менеджеру? Или же дело ограничится тем, что сотрудник отдела информационных технологий, к которому обратился озадаченный пользователь, позвонит вам и выскажет все, что он думает о таком разработчике баз данных?

Подобные ограничения, налагаемые на связи, должны

реализоваться как системные и никак не влиять на структуру данных в проектируемых отношениях. Кроме того, следует очень тщательно