interface Contract {

reiationstiip Studio owneЮfSlaг, reiationstiip Studio producingStudio; reiationsfitp Star star; relationsfilp Movie movie;

Рис. 2.16. Представление контроктов в ODL

2.2.6 Упражнения к разделу 2.2

* Упражнение 2.2.1. Представьте банковскую БД из упражнения 2.1.1 в виде E/R-модели. Обязательно введите стрелки (там, где они необходимы) для выражения множественности связи.

Упражнение 2.2.2. Измените результат выполнения упражнения 2.2.1 для отражения изменений, указанных в упражнении 2.1.2:

a) Измените диаграмму так, чтобы счет мог принадлежать только одному клиенту.

b) Далее измените диаграмму так, чтобы оиент мог иметь только один счет.

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

. d) Далее измените диаграмму так, чтобы клиент мог иметь мнох-ество адресов и множество телефонов по каждому адресу.

Упрожненне 2.2.3. Представьте БД команды/игроки /&onehbmnKv\ из упражнения 2.1.3 в виде E/R-мQaeли. Помните, что множество цветов - неподхоаяший тип атрибута для команд. Как можно обойти это офаничение?

! Упрйжнение 2.2.4. Предположим, что к схеме упражнения 2.2.3 нужно добавить связи Led-by между двумя игроками и командой. Оно состоит из таких троек

(игрок!, игрок2, команда)

в которых игрок! выступал за данную команду, когда ее капитаном был игрок2.

a) Введите изменения в E/R-диаграмму.

b) Замените тернарную связь новым множеством сущностей и бинарными связями.

!с) Являются ли новые бинарные связи такими же, как любая из прежде существовавших связей? Учтите, что речь идет о разных игроках: ни один капитан команды не может возглавлять самого себя.

Упрожиснис 2.2.5. Измените E/R-диаграмму упражнения 2.2.3, включив в нее истории игроков, как в упражнении 2.1.4.

! Упрожнение 2.2.6. Представьте БД из упражнений 2.1.5 и 2.1.6 в виде E/R-модели. Включите в нее связи для матери, отца и детей; не забудьте указать роли, когда множество сущностей используется в связи более одного раза. Включите в модель информацию об ученых степенях, полученных каждым человеком, как было указано в упражнении 2.1.6. Укажите сложность каждой связи. Нужны ли отдельные связи для матери, отца и детей? Почему?

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

Более подробное знакомство с моделями ODL и E/R у вас еще впереди, но уже сейчас вы знаете достаточно, чтобы разобраться в том, из чего состоит хоро-пшИ проект и чего нужно избегать при его построении, В этом разделе рассматриваются некоторые полезные приниипы проектирования,

2.3.1 Правильность

Первое и самое главное: проект должен быть правильным относительно конкретной области. Классы, или множества сущностей и их атрибуты, должны отражать реальность. Нельзя приписывать кинозвезде атрибут число цилиндров , хотя это имеет смысл для класса автомобилей. Любые установленные связи должны соотноситься с нашими знаниями о моделируемой части реального мира.

Пример 2.74. Если определяется связь Siars-in между Star и Afovie, она должна быть типа многие-ко-многим . так как наблюдения за реальным миром показывают, что кинозвезды могут играть во многих фильмах, а несколько кинозвезд может участвовать в одном фильме. Неверно определять эту связь как многие-к-одиому в любом направлении или как связь типа один-к-одному . □

2.3.2 Ликвидация избыточности

Необходимо следить за тем, чтобы каждый факт упоминался не более одного раза. Например, мы использовали связь Owns между фильмами и студиями. Можно было бы еще ввести атрнбуг studioName или множество сущностей Movies, в чем нет ничего незаконного. Однако это опасно по многим причи11а.ч.

1. Два представления одного и того же факта владения фильмом занимают больше места. че.м любое единственное представление.

2. Если фильм был продан, мы можем изменить студию-владельца с помошью Oiw.v, забыв при зто.м изменить значение априбуга studioName. или наоборот. Конечно, такая небрежность недопустима, Тем не .менее на практике ошибки случаются часто: стараясь ска.зать одно и то же дву.мя разными способами, легко нак.пикать проблемы.

В ра.зделс 3.7 дано более форлишьное описание таких проблем и некоторых средств пересмотра счем БД, позволяющих избежать избыточности.

1прс1жненив 2.2.7. Альтернативный способ представления информации упражнении 2.1.5-ввести тернарную связь Family, полагая, что тройкой в множестве отношений для Family является

(человек, отец, мать)

и псе ее члены, разумеется, входят во .множество People.

*л) Составьте диаграмму с указанной связью (не включая в нее информацию об образовании). Используйте стрелки там, где они нужны.

Ь) Замените тернарную связь Family .множеством сущностей и бинарными связями; мя Офажения множественности связей используйте стрелки.

Упражнение 2.2.8. Представьте <HBcpcHTeTCKiTo БД из упражнения 2.1.7 в виде E/R-моаели.

2.3 Принципы проектирования 4!

Избыточность и обратные связи

Можно подумать, что использование связи и ее обращения в ODL -это пример излишеств в модели. Однако не следует полагать, что связь и ее обращение будут представлены двумя различными структурами данных, например указателями в различных направлениях. Вспомните, что определение связи и се обращения лишь отражают тот факт, что связи в принщ<пе можно придать любое направление.

Если же связь действительно реализуется двумя отдельными структурами данных, возникает риск, связанный с избыточностью. Поскольку предполагается, что базовые указатели постоянно используются при изменении данньх, при реализации СУБД, основанных на ODL, нужно внимательно относиться к способам изменений БД. Но эта проблема относится к уровню системы, причем предполагается, что разработчики системы успешно (в конечном счеге) с ней справятся. На уровне реализации с избыточностью связан меньший риск, и существование указателей в обоих направлениях может привести к существенному повышению скорости, с которой связи придается то или иное иап:)авление.

2-3-3 Простота

Нельзя вводить в проект больше эле.ментов, чем это необходимо.

Пример 2.15. Предположим, что вместо связи между Movies и Studios было постулировано существование фильм-холдинга , владения единственным фильмом. Тогда можно создать еще один класс или множество сущностей Holdings. Между каждым фильмом и единственным представляющим его холдингом можно ввести связь Represents типа один-к-одному И связь типа многие-к-Одному множества Holdings с множеством Swdios завершает схему, показанную на рис. 2.17.

Movies

Рис. 2.17. Слобый проект с ненужным множестнолл сущностей

Технически такая структура правильно представляет реальный мир, так как е.5инственную стадию, владеющую фильмом, можно определять через холдинги. Однако множество Holdings при этом бесполезно, и лучше обой ись Ее него. Оно порождает программы, использующие более сложные связи между ф1льмом и сту дней, занимает излишнее пространство памяти и порождает ошибки. D

2.3.4 Выбор элементов правильного вида

Иногда приходится выбирать тип элементов проекта, применяемые для представления объектов реального мира. При этом часто выбор .заключается в том. ч о испотьзовать- атрибуты и ш же классы, множества сущностей. В общем стучае атрибут проше реализовать, чем любой класс/множество сущностей 11ли связь. Впрочем, если все делать только с помощью сггрибртов, возникнут осложнения.