Модель сущность-атрибут-связь (ER)

 

Модель сущность–атрибут–связь была предложена Петером Пин-Шен Ченов в 1976 г. На использовании разновидностей ER модели основано большинство современных подходов к проектированию баз данных (главным образом реляционных). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое количество разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE системах, поддерживающих автоматизированное проектирование реляционных баз данных.

Базовыми понятиями ER-модели являются сущность, атрибут и связь.

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

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

Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте “стыковки” связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплош­ной линией, а необязательный – прерывистой линией.

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

Каждый СТУДЕНТ учится только в одной ГРУППЕ;

Любая ГРУППА состоит из одного или более СТУДЕНТОВ.

 

Рис. 1. Связь между сущностями

 

На рис. 2 изображена сущность ЧЕЛОВЕК с рекурсив­ной связью, связывающей ее с ней же самой. Лаконичной устной трактовкой изображенной диаграммы является следующая:

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛО­ВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮ­ДЕЙ (“ЧЕЛОВЕКОВ”).

 

Рис. 2. Рекурсивная связь

 

 

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

 

 

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

Связи “многие-со-многими”. Иногда бывает необходимо связывать сущ­ности таким образом, что с обоих концов связи могут присутствовать не­сколько экземпляров сущности (например, все члены кооператива сообща владеют имуществом кооператива). Для этого вводится разновидность связи “многие-со-многими”.

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

Каскадные удаления экземпляров сущностей. Некоторые связи бывают настолько сильными (конечно, в случае связи “один-ко-многим”), что при удалении опорного экземпляра сущности (соответствующего концу связи “один”) нужно удалить и все экземпляры сущности, соответствующие кон­цу связи “многие”. Соответствующее требование “каскадного удаления” можно сформулировать при определении сущности.

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

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

Наиболее часто на практике ER-моделирование использу­ется на первой стадии проектирования базы данных. Его результатом, как правило, является концептуальная модель предметной области, выражен­ная в терминах ER-модели.

При переходе к следующему этапу – моделированию схемы БД – перед разработчиком возникает проблема выражения концептуальной модели предметной области в терминах применяемой модели данных (например, реляционной). Существует три подхода к решению этой про­блемы.

Первый подход состоит в ручном преобразовании концептуаль­ной модели предметной области в схему БД, выполняемом согласно мето­дикам, в которых достаточно четко оговорены все этапы такого преобра­зования.

Во втором подходе реализуется автоматизированная компиляция кон­цептуальной модели предметной области в схему БД (чаще всего реляци­онную). Известны два типа подхода:

подход, основанный на явном представлении концептуальной мо­дели предметной области как исходной информации для компиля­ции;

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

И в том, и в другом случае в результате создается реляционная схема базы данных в третьей нормальной форме.

Наконец, третий подход – это непосредственная работа с базой данных в семантической модели, т.е. применение СУБД, основанных на семанти­ческих моделях данных. При этом снова рассматриваются два варианта.

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

Второй вариант – прямая реализация СУБД, основанная на какой-либо семантичес­кой модели данных.

Наиболее близко ко второму варианту находятся современные объект­но-ориентированные СУБД, модели данных которых по многим парамет­рам близки к семантическим моделям (хотя в некоторых аспектах они бо­лее мощны, а в некоторых – более слабы). Хотя в целом можно сказать, что этот подход еще не вышел за пределы исследовательских и экспери­ментальных проектов.

В настоящее время на рынке программного обеспечения появилось до­статочно много универсальных (не привязанных к какой-либо конкретной СУБД) пакетов автоматизированного проектирования БД, позволяющих производить концептуальное моделирование предметной области. В ос­нове практически всех систем такого рода лежит та или иная интерпрета­ция ER-модели. Такие системы являются реализацией второго из рассмот­ренных выше подходов. Одним из наиболее популярных программных продуктов в этой области является ERwin компании Platinum.

 

Модели данных

 

Способ отображения сущностей, атрибутов и связей на структуры данных определяется моделью данных. Существуют 4 основные модели данных – списки, реляционные базы данных, иерархические и сетевые структуры. Рассмотрим их подробнее.

Самый простой тип – это список – структура данных в виде линейной последовательности.

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

 

Рис. 3. Иерархическая древовидная структура БД

 

Основными внутренними ограничениями иерархической модели данных являются следующие:

– все типы связей должны быть функциональными, т.е. 1:1, 1:М, М:1;

– структура связей должна быть древовидной.

Результатом действия этих ограничений является ряд особен­ностей процесса структуризации данных в иерархической модели.

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

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

– имеется единственная особая вершина, называемая корнем, в которую не заходит ни одно ребро;

– во все остальные вершины заходит только одно ребро, а ис­ходит произвольное количество ребер;

– нет циклов.

Иерархическая древовидная структура, ориен­тированная от корня, удовлетворяет следующим условиям:

– иерархия всегда начинается с корневого узла;

– на первом уровне иерархии может находиться только корне­вой узел;

– на нижних уровнях находятся порожденные (зависимые) узлы;

– каждый порожденный узел, находящийся на уровне L, свя­зан только с одним непосредственно исходным узлом (непосредст­венно родительским узлом), находящимся на более верхнем (L – 1)-м уровне иерархии дерева;

– каждый исходный узел может иметь один или несколько не­посредственно порожденных узлов, называемых подобными;

– доступ к каждому порожденному узлу выполняется через его непосредственно исходный узел;

– существует единственный иерархический путь доступа к узлу начиная от корня дерева (рис. 4).

 

 

Рис. 4. Иерархический путь доступа к узлу

Другими словами, иерархическая модель представления знаний (или дерево) – структура данных, в которой каждый узел имеет только одного “родителя”, т.е. господствующий узел (кроме самого верхнего узла) и неограниченное количество “потомков”, т.е. узлов, над которыми данный узел господствует.

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

 

Рис. 5. Сетевая структура

 

В 70-х годах начали активно проводиться теоретические иссле­дования реляционной модели данных. С появлением персональных ЭВМ реляци­онные модели стали доминировать на рынке информационных систем. Реляционное представление знаний– представление знаний в виде отношений.

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

 

Логическое проектирование

 

В предлагаемой методологии проектирования баз данных весь процесс разработки разделяется на три основные фазы: концептуальное, логическое и физическое проектирование. Логическое проектирование баз данных – это процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально ис­пользуемой СУБД и других физических условий.

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

1. Удаление связей типа M:N.

2. Удаление сложных связей.

3. Удаление рекурсивных связей.

4. Удаление связей с атрибутами.

5. Удаление множественных атрибутов.

6. Перепроверка связей типа 1:1.

7. Удаление избыточных связей.

1. Удаление связей типа M:N. Если в концептуальной модели присутствуют связи типа M:N (“многие-ко-мно­гим”), то их следует устранить путем определения некоторой промежуточной сущно­сти. Связь типа M:N заменяется двумя связями типа 1:М, устанав­ливаемыми со вновь созданной сущностью.

В качестве примера рассмотрим следующую M:N связь: газета печатает объявления об объектах, сдаваемых в аренду (рис. 6)

 

Рис. 6. M:N связь

 

С целью устранения этой связи мы определяем промежуточную сущность ОБЪЯВЛЕНИЕ и создаем две новые связи типа 1:М. В результате связь типа M:N будет заме­нена двумя связями (рис. 7).

 

Рис. 7. Связи типа 1 : M

2. Удаление сложных связей. Сложной называется связь, существующая между тремя и больше типами сущно­стей. Если в концептуальной модели присутствует сложная связь, ее следует устранить с помощью промежуточной сущности. Сложная связь заменяет­ся необходимым количеством бинарных связей типа 1:М, устанавливаемых со вновь созданной сущностью. Например, тройная связь “Сдается внаем” (изображается ромбом) отражает от­ношения, существующие между оформляющим аренду работником компании, зе­мельным участком и арендатором (рис. 8).

 

 

Рис. 8. Сложная связь

 

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

В нашем примере связь “Сдается внаем” можно устранить посредством введения новой слабой сущности с именем Соглашение. Вновь созданная сущность будет связана с исходными сущностями тремя новыми бинарными связями (рис. 9).

 

 

Рис. 9. Упрощение сложной связи

 

3. Удаление рекурсивных связей. Рекурсивными называются такие связи, в которых сущность некоторого типа взаимодействует сама с собой. Если концептуальная модель содержит рекурсивные связи, они должны быть устранены посредством определения неко­торой промежуточной сущности. Например, для отображения ситуации, когда один из работников руководит группой других работников, может быть установлена ре­курсивная связь типа “один-ко-многим” (1:М).

4. Удаление связей с атрибутами. Если в концептуальной модели присутствуют связи, имеющие собственные атри­буты, они должны быть преобразованы путем создания новой сущности. Например, рассмотрим ситуацию, когда требуется фиксировать количест­во рабочих часов, отработанных временным персоналом каждого из отделений пред­приятия. Связь “Работает в” имеет атрибут с именем “Отработано часов”. Преобразуем связь “Работает в” в сущность с именем “Распределение по отделам”, которой назначим атрибут “Отработано часов”, после чего создадим две новых связи типа 1:М.

5. Удаление множественных атрибутов. Множественными называют атрибуты, которые могут иметь одновременно не­сколько значений для одного и того же экземпляра сущности. Если в концептуальной модели присутствует множественный атрибут, его следует преоб­разовать путем определения новой сущности. Например, для отображения ситуации, когда одно и то же отделение компании имеет несколько телефонных номеров, в концептуальной модели был определен множественный атрибут “Телефонный номер”, относящийся к сущности “Отделение компании”. Этот множественный атрибут сле­дует удалить, определив новую сущность “Телефон”, имеющую единственный простой атрибут “Телефонный номер”, и создав новую связь типа 1.

6. Перепроверка связей типа 1:1. В процессе определения сущностей могли быть созданы две различные сущности, которые на самом деле представляют один и тот же объект в предметной области приложения. Например, могли быть созданы две сущности “Отдел” и “Департамент”, ко­торые на самом деле представляют один и тот же тип объекта. Другими словами, имя “Отдел” является синонимом имени “Департамент”. В подобном случае следует объе­динить эти две сущности в одну. Если первичные ключи объединяемых сущностей различны, выберите один из них в качестве первичного, а другой укажите как аль­тернативный ключ.

7. Удаление избыточных связей. Связь является избыточной, если одна и та же информация может быть получена не только через нее, но и с помощью другой связи. Всегда следует стремиться созда­вать минимальные модели данных, и поэтому, если избыточная связь не является очевидно необходимой, ее следует удалять. Установить, что между двумя сущностя­ми имеется больше одной связи, довольно просто. Однако из этого еще не следует, что одна из двух связей обязательно является избыточной, поскольку обе они могут представлять различные объединения, реально существующие в организации.

При устранении избыточности доступа большое значение имеют временные пока­затели. Например, рассмотрим ситуацию, когда необходимо смоделировать связи между сущностями “Мужчина”, “Женщина” и “Ребенок”. Очевидно, что между сущностями “Мужчина” и “Ребенок” имеется два пути доступа: один – через непосредственную связь “Является отцом” и другой – через связи “Женат на” и “Является матерью”. На первый взгляд кажет­ся, что связь “Является отцом” избыточна. Однако это утверждение может оказать­ся ошибочным по двум причинам. Во-первых, отец может иметь детей от предыду­щего брака, а мы моделируем только текущий брак отца (через связь 1:1). Во-вторых, отец и мать могут быть вообще не женаты или отец может быть женат на женщине, которая не является матерью данного ребенка (или же мать может быть замужем за мужчиной, который не является отцом ребенка). Поэтому все сущест­вующие взаимоотношения не могут быть смоделированы без использования связи типа “Является отцом” (рис. 10).

 

Рис. 10. Связь между сущностями “Мужчина”, “Женщина”, “Ребенок”