4.2 Модель «сущность-связь».

4.2.1 Появление и развитие метода. Современное состояние.

Данная модель была впервые предложена Питером Ченом в 1976 году. Ее предназначение – концептуальное моделирование предметной области.

Надо отметить, что первоначальный вариант модели предполагал более общий подход к моделированию, нежели реализованный в методе Баркера. В частности, можно было включать в модель составные и многозначные атрибуты, имелось большее разнообразие сущностей, допускалось использование связей типа «многие ко многим» и так далее. Модели, построенные с использованием этого подхода, на этапе даталогического проектирования можно было преобразовать в схемы различных баз данных, как реляционных, так и сетевых и иерархических.

Но с 1976 года рынок СУБД изменился и доминирующее положении на нем заняли именно реляционные СУБД. Соответственно, методы построения концептуальной модели тоже трансформировались, и многие возможности, которые не могут быть напрямую реализованы средствами реляционной СУБД, из них исчезли. В каком-то смысле, это неплохо – раз их все равно придется исключить на этапе даталогического проектирования, то возможно, не стоит дважды тратить время – сначала на их добавление в концептуальную модель, а затем на преобразование к структуре реляционной базы данных. Так или иначе, доступные на сегодня программные средства для построения моделей оперируют как раз такими, упрощенными подходами, поэтому в данном конспекте мы не будем рассматривать начальный вариант. Интересующиеся всегда могут обратиться к литературе, довольно хорошее описание приведено в [].

Можно также отметить, что подход анализу предметной области, реализованный в модели «сущность-связь», послужил одним из источников для методов объектно-ориентированного анализа, а сами сущности напоминают классы (правда, классы, помимо атрибутов, обладают еще и поведением).

4.2.2 Метод Баркера.

Метод Баркера является одной из вариаций модели «сущность-связь» (Entity-Relationship model, ER-model).

Как и во всех других методах построения моделей «сущность-связь», в методе Баркера центральными понятиями являются, как легко понять, «сущность» и «связь». Начнем наше рассмотрение с обсуждения сущностей и атрибутов.

Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению (рисунок).

Рис. 4.1 Графическое изображение сущности

Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:

• каждая сущность должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;

• сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

• каждая сущность может обладать любым количеством связей с другими сущностями модели.

В качестве имени сущности следует выбирать существительное в единственном числе и в именительном падеже.!!! Если для именования сущности используется несколько различных существительных, их также следует зафиксировать в словаре терминов предметной области. Если у наименование имеется один синоним, можно указывать его на диаграмме вместе с основным наименованием через косую черту, например «Автомобиль / Автомашина».

Как уже было сказано, сущность обладает одним или несколькими атрибутами. Атрибут – некоторая характеристика сущности, описывающий сущность элемент информации. Можно сказать, что атрибуты связаны с сущностью (то есть, выделить связь «сущность – атрибут»), но на наш взгляд, правильнее сказать, что атрибут принадлежит (входит в состав) сущности.

Это подчеркивается и обозначением атрибутов в методе Баркера. Атрибуты перечисляются внутри блока сущности, ниже наименования. Например – рис. 4.2.

Рис. 4.2 Обозначение атрибутов.

На этапе концептуального проектирования мы еще не знаем, какая именно СУБД будет использована, поэтому указать точные типы данных для атрибутов не можем. На графическом представлении сущности они не отображаются.

Каждая сущность обязательно должна иметь первичный ключ, то есть, один или несколько атрибутов, значения которых позволяют однозначно идентифицировать конкретный экземпляр сущности. Атрибуты, входящие состав первичного ключа обозначаются знаком «#». На приведенном примере видно, что для сущности «Студент» первичным ключом выступает номер зачетной книжки.

Также мы может пометить часть атрибутов как обязательные, то есть, каждый экземпляр сущности должен обладать ими. Когда база данных будет создана, в ней будет установлено требование обязательного заполнения полей таблицы, в которых хранятся значения обязательных атрибутов. В нашем примере обязательными являются атрибуты «Фамилия», «Имя» и «Отчество», которые помечены знаком «*». Мы предполагаем, что каждый студент обязательно имеет фамилию, имя и отчество и требуем обязательного занесения этих данных в базу данных.

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

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

Связь. Характеристики связей.

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.

Рис. 4.3 Пример связи в методе Баркера.

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

Вторая характеристика связи – это степень связи, то есть, количество участвующих в ней экземпляров каждой из сущностей. В зависимости от степени выделяют связи «один к одному», «один ко многим» (или «многие к одному») и «многие ко многим». Степень связи изображается при помощи так называемой «вороньей лапки» - разветвления линии связи возле сущности. На рисунке мы видим, что в связи участвует одна группа и много студентов, а степень связи – «один ко многим». В реальности дело обстоит именно так – в группу должно входить несколько студентов, но каждый студент входит только в одну группу.

Наконец, связи также характеризуются обязательностью участия в них. Эту характеристику называют также «класс принадлежности», который может быть обязательным и необязательным. В нашем примере каждая группа обязательно должна включать студентов, иначе ее существование бессмысленно. Аналогично, каждый студент должен входить в состав какой-либо группы. То есть, класс принадлежности для обеих сущностей – обязательный. Необязательный класс принадлежности показывается при помощи изображения соответствующего конца связи пунктирной линией. В следующем примере мы рассмотрим эту ситуацию.

Рассмотрев характеристики связей, вернемся снова к степени связи. Связи «один к одному» встречаются достаточно редко, и всегда, когда в модели появляется такая связь, нужно рассмотреть ее внимательно. Если класс принадлежности для обеих сущностей обязательный, то возможно, что следует объединить их и сделать из двух сущностей одну. Это позволит упростить модель и повысить производительность базы данных (одна таблица обрабатывается быстрее, чем две). Если же каждая сущность имеет самостоятельное значение и самостоятельно участвует и в других связях, то такое объединение нецелесообразно. Вторая возможная ситуация для связи «один к одному» - ошибка в определении степени связи. При более подробном анализе часто выясняется, что для одной из сущностей степень связи будет не «один», а «много».

Несколько более сложна ситуация со связями «многие ко многим». Как мы помним из описания реляционной модели данных, одним из принципов является атомарность атрибутов. Одновременно мы помним, что связи между таблицами задаются при помощи внешних ключей, то есть значения первичного ключа главной таблицы переносятся в зависимую таблицу. Но как быть, если каждая запись подчиненной таблицы связана с несколькими записями главной (а именно это получается для связи «многие ко многим»)? Очевидно, что в поле внешнего ключа записать несколько значений не удастся – это нарушает принцип атомарности атрибутов. То есть, связь «многие ко многим» напрямую в реляционной СУБД реализовать нельзя. Как быть? Рассмотрим эту ситуацию на примере.

Допустим, что мы выяснили, что студенты могут заниматься не одним видом спорта, а несколькими. Кроме того, для упорядочения учета спортсменов мы решили составить список видов спорта, чтобы избежать возможных разночтений в их наименованиях. То есть, наша модель принимает вид, приведенный на рисунке 4.4.

Рис. 4.4 Связь «многие ко многим».

Итак, мы видим, что у нас появилась новая сущность «Вид спорта», связанная с сущностью «Студент» связью «многие ко многим», при этом класс принадлежности необязательный для обеих сущностей. В самом деле, не каждый студент занимается спортом, и не для каждого вида спорта найдутся занимающиеся им студенты (предположим, что мы сформировали список видов спорта на перспективу, не отталкиваясь от наличия спортсменов).

Такой вид модель может иметь на начальных этапах моделирования, пока мы не изучили предметную область достаточно подробно. В дальнейшем мы должны вернуться к связям со степенью «многие ко многим» и преобразовать их. Конечно, можно оставить эту задачу для этапа даталогического проектирования, но метод Баркера все же предполагает работу с ними на этапе анализа предметной области.

В самом простом случае мы должны просто заменить связь «многие ко многим» на так называемую граничную сущность, задача которой состоит только в связывании между собой других сущностей, а ее атрибутами являются первичные ключи связываемых сущностей. После ее добавления, ее можно связать с двумя исходными сущностями при помощи связей «один ко многим». Но если вместо простого механического добавления сущности провести и анализ предметной области, то может оказаться, что у граничной сущности, помимо первичных ключей, есть и другие атрибуты. Вот как это может получиться в нашем случае (Рис. 4.5).

Рис. 4.5 Результат преобразования связи «многие ко многим»

На рисунке мы видим, что у нас в модели появилась новая сущность «Занятие спортом», с которой и связаны студенты и виды спорта. Степени этих связей – «один ко многим», студент может заниматься различными видами спорта, аналогично, одни видом спорта могут заниматься различные студенты. Но кроме самого факта занятия тем или иным видом спорта мы можем хранить и факт наличия спортивного разряда по нему, а также дату его присвоения. Очевидно, что далеко не все студенты, занимающиеся спортом, имеют разряд, так что эти атрибуты сделаны необязательными. Подобным образом должны преобразовываться все связи со степенью «многие ко многим».

Обобщенные сущности.

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

Обобщенная сущность включает в себя несколько вложенных сущностей. Выглядит это так, как показано на рисунке 4.6.

Рис. 4.6 Обобщенная сущность и вложенные сущности.

На рисунке мы видим результат более подробного анализа сущности «Студент». В результате этого анализа мы выяснили, что у нас имеется три разновидности студентов – обучающиеся на дневном отделении, на заочном отделении и на вечернем отделении. У каждой разновидности есть свои специфические атрибуты (пример условный, поэтому атрибуты приведены также условно). То есть, имеет смысл показать эти три разновидности при помощи вложенных сущностей, чтобы подчеркнуть отличие между ними и в явном виде распределить атрибуты.

Вложенные сущности обладают атрибутами обобщенной сущности и добавляют к ним свои, присущие только ей. Очевидно, что у каждой вложенной сущности должны быть такие атрибуты, иначе ее выделение ничем не оправдано.

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

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

Дополнительные характеристики связей. Группировка связей. Неперемещаемые связи.

В реальности может возникать ситуация, когда сущность участвует строго в одной связи из некоторой группы. Примером такой связи может служить показанная на рисунке 4.7.

Рис. 4.7 Группировка связей.

В приведенном примере мы анализируем разные варианты заключения договора на обучение. Нам удалось выделить три возможных варианта. Их количество и атрибуты в данный момент не принципиальны и показаны условно. Важно, что студент может заключить только один из них, то есть каждый экземпляр сущности «Студент» может участвовать только в одной из трех связей. Такие связи образуют группу, и чтобы это показать, на диаграмме они объединяются дугой.

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

Рис. 4.8 Неперемещаемая связь.

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