Введение в банки данных (стр. 6 )

Естественно, что классификация может быть многоуровневой. Так, в рассматриваемом примере обобщенный объект “ЛИЧНОСТЬ” может быть разбит на два подкласса: СОТРУДНИК и УЧАЩИЙСЯ. СОТРУДНИКИ, в свою очередь, могут быть классифицированы на ПРОФЕССОРСКО-ПРЕПОДАВАТЕЛЬСКИИ СОСТАВ, АДМИНИСТРАЦИЯ и т. д.

Личность

 

Рис. 2.14 Изображение обобщенного объекта

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

Рис. 2.15 Граф пересечений

Граф пересечений содержит дополнительную информацию о предметной области и не относится к классу ER-моделей.

Агрегированные объекты соответствуют обычно какому-либо процессу, в который оказываются “вовлеченными” другие объекты. Например, агрегированный объект “ПОСТАВКА” объединяет в себе объекты “ПОСТАВЩИК”, который поставляет продукцию, “ПОТРЕБИТЕЛЬ”, который получает эту продукцию, а также саму поставляемую “ПРОДУКЦИЮ”. Своеобразным объектом является “ДАТА ПОСТАВКИ”. Агрегированный объект может, так же как и простой объект, иметь характеризующие его свойства. В рассматриваемом примере таким свойством может быть размер поставки.

Агрегированные объекты обычно называются отглагольными существительными (например, поставлять—поставка, выпускать— выпуск, продавать—продажа и т. д.).

 

Рис. 2.16 Изображение агрегированного объекта

Для отображения агрегированного объекта в инфологической модели будем использовать следующие условные обозначения:

сам агрегированный объект будем изображать ромбом, рядом с которым указывается имя соответствующего объекта. Этот ромб необходимо связать с условными обозначениями тех объектов, которые образуют этот агрегированный объект. Свойства агрегированного объекта изображаются так же, как и для простого объекта. На рис. 2.16 изображен агрегированный объект “ПОСТАВКА ПРОДУКЦИИ”.

2.3. СРАВНЕНИЕ МЕТОДИК ПОСТРОЕНИЯ ER-МОДЕЛЕЙ

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

Далее мы рассмотрим особенности представления ER-моделей в трех наиболее известных системах автоматизации проектирования (CASE-системах): Prokit*WORKBENCH, Desing/IDEF и CASE ORACLE, а также в некоторых литературных источниках.

Можно выделить несколько категорий различий в изображении ER-моделей.

Разные условные обозначения используются и для изображения типа связи (1:1, 1:М, М:М).

2. Различия, также связанные со способом изображения тех или иных ситуаций, но более существенные, приводящие различиям в самих моделях. Например, в системе ORACLE обобщенный объект изображается путем “вложения” блоков, обозначающих “видовые” объекты, внутрь блока, изображающего “родовой” объект. На рис. 2.20 показано изображение объекта (ЛИЧНОСТЬ”, рассмотренного выше (см. рис. 2.14), в условных обозначениях, используемых в CASE ORACLE. Как следует из сравнения рисунков, изображение обобщенных объектов в сравниваемых методиках различается не только по форме представления. Так, если объект классифицируется по разным признакам, то при использовании первого из рассмотренных способов изображения обобщенных объектов (см. рис. 2.14) наглядно видно, по какому признаку осуществляется классификация. Второй же способ изображения (см. рис. 2.17) не обеспечивает этого.

Рис. 2.17 Изображение обобщенного объекта в системе CASE ORACLE

3. Кроме различия в изображении тех или иных сущностей, в теории инфологического моделирования наблюдается расхождение в используемой терминологии. Например в CASE ORACLE родо – видовой объект называется супертип (super – type),в видовой - подтип (sub - type). Таких различий в терминологии можно привести много, но это не является сейчас нашей целью.

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

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

Различные приемы используются и для того, чтобы уменьшить число пересечений линий на схеме. Так, в системе Prokit для этих целей допускается дублирование изображения объекта и размещение этого дубля рядом с тем объектом, с которым его надо связать. Для того чтобы показать, что это не новый объект, используется какое-либо условное обозначение, например, у соответствующих блоков отчеркивается уголок.

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

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

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

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

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

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

Вариант, когда ситуация не может быть отражена в ИЛМ, может быть проиллюстрирован на следующем: если методика построения модели не предполагает фиксацию класса членства в связи, то эта информация будет, просто потеряна.

В некоторых САSЕ-системах имеет место ситуация, когда какая-то конструкция допускается в системе как промежуточная.

Например, в IDEF и САSЕ ОRАСLЕ отношение М: М допускается как неспецифическое отношение. Его наличие разрешается на ранних стадиях разработки проекта, а в дальнейшем оно должно быть заменено на специфическое отношение посредством введения третьей сущности. Это является недостатком системы, так как, во-первых, не все СУБД требуют такого преобразования (некоторые системы поддерживают отношение М:М в явном виде), и, во-вторых, если такое преобразование потребуется, его вполне система автоматизации проектирования могла бы выполнить автоматически на этапе даталогического проектирования. Даже если выполняется «ручное» проектирование, то указанное преобразование должно выполняться проектировщиком на стадии даталогического проектирования, а не при описании предметной области.

Кроме того, при рассматриваемом преобразовании на стадии инфологического проектирования в ЮЕР вводится новая категория сущностей — сущности пересечения или ассоциативные сущности. Введение новых сущностей влечет за собой введение в ИЛМ и дополнительных связей. Все это, вместе взятое, усложняет и без того нелегкую задачу инфологического проектирования.

В предметной области могут быть сущности, идентификаторы которых являются зависимыми от идентификатора какого-то другого объекта. Например, если участки на предприятии нумеруются в пределах цеха, то идентификатор участка будет составным, включающим в себя код цеха и код участка. В инфологической модели можно ограничиться указанием этого составного идентификатора. Некоторые методики построения ЕR - моделей (например, методология IDEF1X, Рrokit) предусматривают введение особых видов сущностей и особых видов отношений для отображения подобных ситуаций. Так, в IDEF сущность, для идентификации которой надо рассматривать ее отношение с другими сущностями, называется зависимой от идентификатора сущностью, и для ее изображения используется блок с закругленными углами. Для изображения же не зависимой от идентификации сущности используется прямоугольник. Для связи объектов, один из которых нужен для полной идентификации другого, вводится понятие идентифицирующего отношения. Для него также вводится свое условное обозначение. В ЮЕР для идентифицирующего отношения используется сплошная линия, а для неидентифицирующего — пунктирная.