Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Отсутствующие возможности




Пространственное размещение элементов ER-модели

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

Многие CASE-средства позволяют выделять фрагменты из общей схемы и работать с ними как с самостоятельными компонентами мо­дели, а также проводить объединение отдельных фрагментов в еди­ную схему.

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

Многие CASE-системы позволяют выводить на экран информа­цию с разной степенью детализации (например, только названия сущ­ностей, либо сущности и все их свойства, либо только ключевые ат­рибуты и т.п.). Такие возможности совсем не присущи ручным спосо­бам проектирования (хотя могут использоваться как методологический прием: проектирование сначала выполняется с минимальной степенью детализации, а затем проводится последовательное повышение степе­ни детализации - обычный прием в структурном проектировании).

Некоторые возможности, имеющиеся в одних системах или мето­диках, отсутствуют в других. В этих случаях возможны различные варианты:

· для изображения ситуации, имеющей место в предметной обла­сти, используются возможности, предоставляемые данной методоло­гией, но это требует применения определенных приемов, часто не­сколько искусственных, для их представления;

· ситуация просто не отображается в модели.

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

Так, в IDEF1X, как и в других широко известных CASE-системах, свойства объекта могут быть только единичные и всегда опреде­ленные (не условные). Если свойство может отсутствовать у каких-либо объектов, то надо выделять отдельные сущности, например СЛУЖАЩИЙ_ШТАТНЫЙ с атрибутом «Оклад» и ПОЧАСОВИК, не имеющий такого атрибута. Это приведет к необходимости выделения большого числа объектов и связей в ИЛМ, к снижению наглядности модели. Например, отдельные экземпляры объекта ЛИЧНОСТЬ могут иметь или не иметь ученое звание, ученую степень, год оконча­ния вуза и много других признаков. По каждому из этих признаков придется выделять подклассы (либо не фиксировать в модели, явля­ются ли эти свойства условными).

Некоторые методики не вводят агрегированный объект как само­стоятельную категорию. В таком случае сущность, соответствующая агрегированному объекту, изображается как простой объект; при этом пользователь должен предварительно определить идентификатор этого объекта (что является далеко не тривиальной задачей) и его свойства. Далее изображение будет зависеть от того, могут ли в используемой нотации быть изображены только бинарные связи либо с объектом можно связать несколько разных объектов.

Кроме указанных сложностей при определении идентификатора агрегированной сущности могут возникнуть и проблемы при перехо­де от ИЛМ к даталогической модели.

Если модель допускает изображение только двоичных (бинарных) связей, то проектировщик должен преобразовать n-арную связь в со­вокупность бинарных.

Связь типа «арк», использованная вбазовой модели и имеющая­ся в CASE Oracle, отсутствует в большинстве других рассматривае­мых в данном учебнике систем. Это делает неудобным отображение тех ситуаций, где следовало бы использовать эту возможность (чаще всего при этом приходится вводить лишнюю сущность).

Если методика построения модели не предполагает фиксацию класса принадлежности объекта в связи, то эта информация будет просто потеряна.

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

В некоторых CASE-системах имеет место ситуация, когда какая-то конструкция допускается в системе как промежуточная. Например, в IDEF1X и CASE Oracle связь М:М допускается как так называемое неспецифическое отношение. Его наличие разрешается на ранних стадиях разработки проекта, но в дальнейшем оно должно быть за­менено на специфическое отношение (т.е. отношение типа 1:М). Это достигается посредством введения в модель дополнительной третьей сущности и соединения с ней исходных сущностей связью типа 1:М (другими словами, одна связь М:М заменяется на две 1:М). Это яв­ляется недостатком подобных систем, так как, во-первых, не все це­левые СУБД требуют такого преобразования (некоторые системы поддерживают отношение М:М в явном виде) и, во-вторых, если та­кое преобразование все-таки потребуется, система автоматизации проектирования вполне могла бы выполнить его автоматически на этапе даталогического проектирования. Даже если выполняется руч­ное проектирование, то указанное преобразование должно выполнять­ся проектировщиком на стадии даталогического проектирования, а не при описании предметной области. Кроме того, при рассматривае­мом преобразовании на стадии инфологического проектирования в IDEF вводится новая категория сущностей - сущности пересечения, или ассоциативные сущности. Введение новых сущностей влечет за собой введение в ER-модель и дополнительных связей. Все это вмес­те взятое усложняет и без того нелегкую задачу инфологического про­ектирования.

В предметной области могут быть сущности, идентификаторы которых являются зависимыми от идентификатора какого-то другого объекта. Например, если участки на предприятии нумеруются в пределах цеха, то идентификатор участка будет составным, включа­ющим в себя код цеха и код участка. В инфологической модели мож­но ограничиться указанием этого составного идентификатора. Неко­торые методики построения ER-моделей (например, IDEF1X, ProKit*WORKBENCH) предусматривают введение особых видов сущностей и особых видов отношений для отображения подобных си­туаций. Так, в IDEF1X сущность, для идентификации которой надо рас­сматривать ее отношение с другими сущностями, называется зависи­мой от идентификатора сущностью, и для ее изображения исполь­зуется блок с закругленными углами (в отличие от сущности, не зависимой от идентификации, для обозначения которой используют­ся прямоугольники). Для связи объектов, один из которых нужен для полной идентификации другого, вводится понятие идентифицирую­щего отношения. Дня него также вводится свое условное обозначе­ние. В IDEF1X для идентифицирующего отношения используется сплошная линия, а для неидентифицирующего - пунктирная.

Способ идентификации отражает не особенности предметной области, а языковые характеристики, а именно - способ именования объектов. Но лингвистические отношения тоже являются частью ИЛМ, и они могут быть отражены в ER-модели.

Если модель не использует в явном виде указание на способ иден­тификации объекта, то, как указывалось выше, эту ситуацию нужно отразить просто путем соответствующего использования идентифи­каторов. Так, например, если на предприятии участки нумеруются в пределах цеха, то в качестве идентификатора объекта ЦЕХ следует использовать «Код_цеха*Код_участка» (рис. 2.34). Следует обратить внимание на то, что прямоугольник, соответствующий зависимой по идентификации сущности, в этом случае на сектора не делится.

Рис. 2.34.Изображение зависимой по идентификации сущности

в случае отсутствия специальных обозначений

 

Как отмечалось выше, ИЛМ включает в свой состав много разно­образных компонентов. Методологии моделирования и конкретные системы различаются полнотой и широтой охвата характеристик, отражаемых при описании предметной области. Так, некоторые систе­мы предусматривают описание запросов (в частности, ключей поис­ка), количественных характеристик классов объектов и запросов, огра­ничений целостности и т.д., другие - нет. Указанные описания иногда бывают объединены с ER-моделью (например, в ProKit*WORKBENCH) или оформляются как отдельные самостоятельные компоненты.




Поделиться с друзьями:


Дата добавления: 2015-04-24; Просмотров: 492; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.014 сек.