Модель сущность-атрибут-связь (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. Связь между сущностями “Мужчина”, “Женщина”, “Ребенок”