Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Типы элементов проекта
|
|
Часто приходится выбирать тип элементов проекта, применяемых для представления объектов реального мира. При этом часто выбор заключается в том, что использовать: атрибуты или же классы, множества сущностей. В общем случае атрибут проще реализовать, чем любой класс/множество сущностей или связь. Впрочем, если все делать только с помощью атрибутов, возникнут осложнения.
Пример 4.21. Рассмотрим пример, иллюстрирующий эффект от применения многосторонней связи, и эквивалентный пример с использованием бинарных связей. Связь Договоры между мастером, изделием и двумя цехами (рис. 51) является четырехсторонней и механически конвертируется в множество сущностей Договоры (рис. 54). Имеет ли значение, какой из этих подходов выбирается?
Решение в ODL однозначно, так как многосторонних связей не существует. В E/R-модели приемлем любой подход. Однако незначительное изменение исходной задачи практически вынуждает нас выбирать подход, при котором используется множество связующих сущностей. Для иллюстрации предположим, что в договоре могут фигурировать один мастер, одно изделие, но любое множество цехов. Эта ситуация сложнее той, что изображена на рис. 51, где было всего два цеха, играющие две роли. Сейчас допускается любое число цехов. Один, возможно, выпускает изделие, в другом делается плиссировка и т.д. Таким образом, приписать роли цехам невозможно.
В данном случае оказывается, что множество отношений для связи Договора должно содержать тройки вида
(мастер, изделие, множество цехов),
а сама связь Договоры – не только обычные множества сущностей Мастера и Изделия, но и новое множество сущностей, элементами которого являются множества цехов. Если такой подход допустим, считать множества цехов базовыми сущностями неприемлемо.
 |
Лучше считать множеством сущностей Договоры. Как и на рис. 54, договор связывает мастера, изделие и множество цехов, но теперь число цехов не ограничено. Поэтому между договорами и цехами имеется связь типа " многие-ко-многим", а не " многие-к-одному", как это было бы, если бы договора были настоящим множеством " связующих" сущностей.
Набросок E/R-диаграммы показан на рис. 56. Заметим, что здесь договор связан с единственным мастером и единственным цехом, но с произвольным множеством цехов.
Такая же стратегия проектирования подходит и для ODL. Например, вполне приемлемо следующее описание интерфейса ODL:
interface Договор{
relationship Мастер мастер1;
relationship Изделие изделие1;
relationship Set < Цех> цеха;
};
Здесь объекты договоров имеют три связи: с единственным мастером, с единственным изделием и с множеством цехов. Обратные связи опущены.
|
|