Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Типы элементов проекта

Омск 2003 | Город_размещения_Поставщика | SUMMARIZE SP BY (M#) ADD SUM (Количество) AS Общее количество | Основные инструкции языка SQL | DROP TABLE SALE | TO IVANOV | DELETE FROM ORDERS | Устранение избыточности | Ссылочная целостность | Многосторонние связи |


Читайте также:
  1. III. Номинации Конкурса и требования к представляемым проектам
  2. UPM и ЮВИ СПб объявляют о старте проекта «Бумажный Бум» в Москве
  3. VI этап. Презентация итогов проекта.
  4. Автор проекта
  5. Анализ показателей экономической эффективности проекта
  6. Бюджет проекта
  7. БЮДЖЕТ ПРОЕКТА

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

Пример 4.21. Рассмотрим пример, иллюстрирующий эффект от применения многосторонней связи, и эквивалентный пример с использованием бинарных связей. Связь Договоры между мастером, изделием и двумя цехами (рис. 51) является четырехсторонней и механически конвертируется в множество сущностей Договоры (рис. 54). Имеет ли значение, какой из этих подходов выбирается?

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

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

 

(мастер, изделие, множество цехов),

 

а сама связь Договоры – не только обычные множества сущностей Мастера и Изделия, но и новое множество сущностей, элементами которого являются множества цехов. Если такой подход допустим, считать множества цехов базовыми сущностями неприемлемо.

 
 

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

Набросок E/R-диаграммы показан на рис. 56. Заметим, что здесь договор связан с единственным мастером и единственным цехом, но с произвольным множеством цехов.

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

interface Договор{

relationship Мастер мастер1;

relationship Изделие изделие1;

relationship Set <Цех> цеха;

};

Здесь объекты договоров имеют три связи: с единственным мастером, с единственным изделием и с множеством цехов. Обратные связи опущены.


Дата добавления: 2015-07-19; просмотров: 58 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Простота| Определения подклассов

mybiblioteka.su - 2015-2024 год. (0.005 сек.)