Представление связи «один ко многим» с обязательным участием в связи сущности «Заявка»
Установленный тип связи утверждает, что экземпляры сущности «Заказчик» могут появиться в БД без связанных экземпляров сущности «Заявка», но каждый экземпляр сущности «Заявка» должен быть связан точно с одним экземпляром сущности «Заказчик». Это связь типа «один ко многим» (1:М) со слабой сущностью «Заявка».
Другой пример взаимодействия это связь между договором и сметой. Каждому договору должна соответствовать своя единственная смета, являющаяся обоснованием цены.
Таким образом, связь между экземплярами этих сущностей является «один к одному» (1:1) с обязательным участием обоих объектов в связи (см. рисунок 4).
Представление связи «один к одному» с обязательным участием обеих сущностей в связи
В третьем примере рассматривается взаимодействие между сущностями «Договор» и «Типовая конструкция». В одном договоре может не быть типовых конструкций, а в другом использоваться их любое число, типовая конструкция может не применяться, если она только что разработана, или применяться во многих договорах. Эту связь следует представить бинарным отношением типа «многие ко многим» с «сильными» сущностями, необязательно участвующими в связи (см. рисунок 5).
Представление необязательной связи «многие ко многим»
Приведенные примеры взаимодействий (связей) сущностей являются наиболее распространенными и поэтому именно они являются основой другого типа схем для представления информационной модели ПрО – ER диаграммы.
Диаграмма «сущность связь» (Essence Relation) или ER диаграмма также представляет собой граф, вершинами которого являются сущности ПрО, взаимодействия которых задаются только бинарными связями, не имеющими имен и атрибутов. Поэтому для отображения произвольных связей объектов ПрО в схему должны вводиться дополнительные сущности, представляющие связи. Бинарные связи в ER диаграмме задаются непоименованными линиями.
Для обозначения типа связи на ER диаграмме используются различные соглашения. Связь «один к одному» и «один ко многим» может обозначаться соответствующим символом (1, М, ∞, ●, , ) на линии, связывающей сущности. Использование этих соглашений показано на рисунке 6, представляющих связь типа «один ко многим».
При этом сущность, помеченная 1 (слева), считается «сильной», следовательно, ее экземпляры могут существовать в БД независимо от наличия экземпляров связанной сущности.
Различные способы представления бинарной связи типа «один ко многим»
Для обозначения обязательности или необязательности участия в связи сущности, помеченной знаком (М, ∞ или ●), используется толщина соединяющей линии. Это показано на следующем рисунке 7.
Способы представления бинарной связи «один ко многим» с обязательным участием сущности в связи
Из приведенных описаний видно, что ER диаграммы более соответствуют модели данных в реляционной базе. Как и реляционная модель, ER диаграмма непосредственно поддерживает ограниченный набор типов связей: бинарные связи «один к одному» и «один ко многим». Поэтому ER диаграммы часто являются промежуточным представлением между концептуальной схемой в виде диаграммы Питера Чена и структурой реляционной базы.
Программы автоматизации проектирования БД (например, ERWin, CaseStudio) не только имеют средства «рисования» ER диаграмм, но и позволяют для каждой связи выбрать в диалоговых окнах ее тип и вид, чтобы далее преобразовать полученную схему данных в структуру базы для конкретной СУБД или сформировать скрипт на языке SQL для последующей генерации базы. А многие СУБД (например, Access, MS SQL Server) позволяют построить графическое представление структуры данных, близкое к ER – диаграмме.
Сопоставляя ER диаграммы с моделями Питера Чена, можно утверждать, что диаграммы Питера Чена позволяют более адекватно и наглядно представить сложные взаимодействия сущностей и, поэтому более ориентированы на обследование и документирование информационных потребностей задач, решаемых в предметной области. В то же время ограниченность и простота типов связей в ER диаграммах упрощает переход от схемы данных к структуре базы. При этом любой из рассмотренных способов документирования процессов и данных не является исчерпывающим и предполагает дополнение представленных схем пояснительным текстом.
В целом при выполнении этапов анализа ПрО и концептуального проектирования можно рекомендовать следующую схему действий.
1. Выясняется круг специалистов – пользователей информационной системы.
2. Определяются процессы, реализуемые специалистами в данной ПрО. Выделяются перспективные для автоматизации процессы и для них путем последовательной декомпозиции строятся схемы выполнения с необходимой степенью детализации функций. Для каждой функции определяются входные и выходные объекты. Схемы процессов дополняются текстовой информацией, содержащей требования по частоте, трудоемкости функций, количеству обрабатываемых объектов.
3. Из схем принятых к автоматизации процессов следуют функции программного обеспечения, необходимые пользователям автоматизированных систем. Эти функции образуют пункты главного и контекстного меню и другие элементы управления в экранных формах пользовательских приложений.
4. Путем типизации входных и выходных объектов, выбранных для автоматизации функций, создаются сущности ПрО, которые должны быть представлены в БД. Для сущностей устанавливаются необходимые атрибуты и выбираются ключи.
5. Анализируя взаимодействия объектов, образовавших сущности, выясняются связи между сущностями и создается концептуальная схема ПрО, например, в виде диаграммы Питера Чена. При необходимости сложные сущности декомпозируются на более простые посредством их детализации и конкретизации с соответствующей декомпозицией связей. На рисунке 8 приведен пример частичной концептуальной схемы данных в виде диаграммы Питера Чена для рассмотренного ранее процесса приема и исполнения заказа (см. рисунок 8).
6. Концептуальная схема дополняется текстовым описанием, в котором перечисляются атрибуты и ключи сущностей, форматы и логические ограничения на данные. Для каждой сущности дается оценка числа экземпляров в базе. Концептуальная схема согласовывается со специалистами (преподавателем) в автоматизируемой области.
Результаты обследования и анализа ПрО должны быть оформлены в основной части пояснительной записки в виде технологических схем, диаграмм, таблиц и пояснительного текста. Описание должно отражать все факторы, учитываемые при создании информационной модели ПрО и приложений для пользователей.
