Связи между сущностями и их виды примеры. Модель сущность-связь

Логическая модель (Сущностная) данных является независимым логическим представлением данных.

Физическая модель (Табличная) данных содержит определения всех реализуемых объектов в конкретной базе данных для конкретной СУБД.

Модели являются краеугольным камнем проектирования. Инженеры должны построить модель автомобиля, проработать все детали, прежде чем запустить его в производство. Таким же образом, системные инженеры сперва разрабатывают модели для изучения бизнес-логики и углубления понимания структуры базы данных.

В прошлой лекции мы познакомились с методологиями IDEF0 и DFD которые позволяют описать бизнес-процессы протекающие в информационной системе. В модели DFD мы рассмотрели элемент - хранилище данных, который показывает типы информации, которой оперирует система. Однако эта методология не предназначена для описания структуры хранимой информации. Для этого больше подходят различные Entity Relationship - диаграммы (сущностные диаграммы), целью которых является описание структуры хранимых данных и взаимосвязей между ними. Разработаны методики, которые позволяют преобразовать такие данные в набор команд, который создаст необходимые хранилища (таблицы) внутри базы данных информационной системы.

ER-моделирование

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

Основные преимущества ER-моделей:

Точный и понятный формат документирования структуры информации.
Позволяет указать требования к данным и связям между ними.
Позволяет наглядно показать структуру хранилища для облегчения проектирования базы данных.
Существуют методы отображения ER-моделей в таблицы БД и обратно.
Закладывают основу для интеграции с другими приложениями.

Основные типы объектов на ER-диаграмме:

Сущность (Entity) - тип объектов, информация о которых будет хранится в БД. Например: отделы, сотрудники, товары, накладные.
Атрибут (Attribute) - элементы из которых состоят сущности. Например, для сущности «товары» атрибутами могут быть «название», «описание», «количество», «цена» и другие, в зависимости от потребностей информационной системы. В зависимости от нотации ER-диаграммы рядом с атрибутом, кроме его имени указывают тип и обязательность заполнения. На слайде представлена ER-диаграмма в нотации «Information Engineering», согласно которой для атрибута указывается имя, тип, и является он внешним и/или первичным кличем.
Связь (Relationship) показывают связи между сущностями. Например сотрудник работает в отделе, где «отдел» и «отдел» - сущности.

Сущность - набор объектов реального мира, каждый из которых имеет следующие характеристики:

Уникален (может быть отделен от всех прочих каким-либо образом)
Играет определенную роль в моделируемой системе
Может быть описан одним или более элементом информации (Атрибутом)

Пример: люди, персонал, события, заказы, продажи, покупатели, поставщики

Атрибут описывает некоторые свойства сущности. Сущность может иметь много атрибутов, но выбираются только те, которые важны для системы. Атрибуты делятся на ключевые (Entity Keys) и описательные (Entity Descriptors). Ключевые атрибуты должны уникальным образом идентифицировать экземпляры сущности. Для каждого атрибута должен быть указан домен (тип, предметная область).

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

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

Базовые термины

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

" Тип данных " (type, domean - домен) - множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.
" Отношение " (relation) - множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").
" Ключ " (key) - группа атрибутов, значения которых во всех наборах в отношении различны, но ни одна подгруппа этих атрибутов таким свойством уже не обладает (свойство "минимальности" ключа). В частности, группа может состоять из единственного атрибута. Ключ в отношении обязан иметься всегда, а если их несколько, один из них обязан быть назначен "первичным" (primary).
" Внешний ключ " (foreign key) - группа атрибутов, значения которых в каждом наборе величин отношения обязаны совпадать со значениями ключа возможно другого отношения. Внешние ключи в отношении не обязательны и провозглашаются по потребностям моделирования.
" Операции " (operation) - множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.
" Реляционная база данных " (relational database) - набор отношений.

"Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

Для удобства отношения часто изображают в виде таблиц, хотя такое представление неправомерно (в отношении не определен ни порядок атрибутов, ни порядок наборов величин, в отличие от таблицы). В SQL, на основе которого построена в том числе СУБД Oracle, понятие "отношения" как инструмента моделирования заменено как раз на "таблицу". Другим представлением данных отношения может быть гиперкуб, и к нему тоже иногда удобно прибегать в рассуждениях об имеющейся БД.

Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

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

Приведенный взгляд на реляционную БД (набор отношений и операции) характерен для реляционной алгебры . Это не единственная точка зрения. Каждый набор величин в переменной отношения можно понимать как истинное высказывание ("предикат"): имеется такой-то сотрудник с такими-то свойствами; такой-то отдел и так далее. Тем самым реляционная база данных в каждый момент времени представляет собой набор истинных высказываний о предметной области, сформулированный через отношения. По сути, набор высказываний в переменных отношений и образует модель предметной области, представленную базой данных. Такой взгляд на реляционную БД характерен для реляционного исчисления . Оба взгляда на реляционную модель хорошо изучены и доказана их выразительная равносильность.

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

Отношение → Таблица
Кортеж → Строка, запись
Кардинальность → Количество строк
Атрибут → Столбец, поле
Степень → Количество столбцов
Первичный ключ → Идентификатор
Домен → Область допустимых значений

Ключевые поля

Часть из атрибутов отношения является ключевыми или ключами. Выделяют несколько типов ключей:

Простой ключ - состоит из одного атрибута, составной - из нескольких.
Потенциальный ключ - атрибут или набор атрибутов, которые могут идентифицировать каждый из кортежей отношения. Например в отношении паспортный стол («Номер паспорта») и («ФИО» и «Дата рождения») - потенциальные ключи, которые позволяют уникальным образом идентифицировать каждого человека.
В каждом отношении может быть только один первичный ключ - атрибут или набор атрибутов значения которого уникальным образом идентифицирую каждую запись. Если такими свойствами обладают несколько наборов атрибутов, то один из них выбирается первичным, а все остальные - альтернативными.
Внешний ключ - хранит значение первичного ключа другого отношения. Внешние ключи используются для связи между отношениями.

Первичный ключ

Каждое реляционное отношение имеет только 1 первичный ключ , все остальные - альтернативные.
Значение всех атрибутов первичного ключа не может быть не определено. Например, отношение хранит информацию о жителях города. Первичный ключ - составной (ИМЯ, ФАМИЛИЯ, дата рождения). Информационную систему установили в Исландии, где не используют фамилий, значит атрибут «фамилия» для большинства кортежей будет незаполненным. Несмотря на это составной первичный ключ будет продолжат уникальным образом идентифицировать каждый из кортежей. Однако недопустимо, чтобы значения одновременно всех атрибутов первичного ключа были пустыми.
Значение первичного ключа не влияет на расположение кортежей в табличном представлении отношения. Даже если значение первичного ключа - число (например 1,2,3 …) в общем случае это не гарантирует, что кортежи внутри БД хранятся в том же порядке и будут выводится в таком же порядке. В «общем случае» означает, что иногда из-за специфики конкретной СУБД строки могут хранится упорядочено по первичному ключу, но это скорее исключение. В случае вывода результатов запроса мы должны явно указывать порядок, в котором нужно выводить строки, если такой порядок важен. Результаты запроса «дай мне первых 5 человек» непредсказуем, если мы не укажем, по какому критерию они должны быть «первыми».
Первичный ключ не влияет на доступ к атрибутам кортежа. Например в отношении «паспортный стол» вместе с ФИО и датой рождения хранится адрес регистрации человека. Мы можем попросить БД извлечь все адреса, не зная ФИО и дату рождения.

Внешний ключ

Внешний ключ используется для установления связей между отношениями. Например возьмем два отношения «Владельцы» (первичный ключ «номер паспорта») и «Недвижимость». Чтобы установить, кто владеет каждым из объектов недвижимости мы свяжем эти отношения по значению атрибута «номер паспорта». В отличии от первичного ключа значение внешнего ключа может быть неопределённо (строка 4 на слайде) - если мы не знаем владельца недвижимости мы его не указываем. В отличие от первичного ключа значение внешнего ключа может повторятся (стоки 1,3 на слайде) - у одного владельца может быть несколько объектов недвижимости. Однако то что атрибут «номер паспорта» в отношении «Недвижимость» является внешним ключом на первичный ключ отношения «Владелец» гарантирует что значением атрибута «номер пастора» могут быть только значения из первичного ключа. Мы не можем указать в качестве значения атрибута номер пастората человека, которого еще нет в отношении «Владелец» (строка 5).

Устанавливая внешний ключ можно явно задать поведение СУБД, если изменить значение первичного ключа или удалить кортеж. Однако при этом сохраняется правило «во внешнем ключе хранятся только значения, которые есть в первичном ключе или неопределённое значение (NULL)».

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

ЕR-модели: связи

На ER-моделях внешние ключи отображаются в виде связей.

Каждая связь характеризуется 4 свойствами - силой , мощностью , степенью и участием сущности в связи.

Разберем эти характеристики.

Участие сущности в связи

Обозначается на связи поперечной линией или кружком.

Поперечная линия означает обязательное (mandatory ) участие сущности в связи, а кружок - необязательное (optional ).

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

В отделе может работать несколько сотрудников. Сотрудник должен работать в каком-то из отделов.

Степень связи (relationship degree ) указывает на число ассоциированных сущностей . Бинарная связь (binary relationship ) описывает ассоциации двух сущностей. Тернарная связь (ternary relationship ) имеет место, когда связываются три сущности. Унарная связь (unary relationship ) описывает ассоциации внутри единственной сущности.

Наиболее распространены бинарные связи - они связываю две разные сущности («Отдел»- «Сотрудник», «Заказ»- «Товары», «Курс»- «Лекции», «Группа»- «Студенты»). Менее распространенными, но все-таки часто используемыми являются унарные связи. С их помощью обычно задают отношение вложенности на однотипных объектах (отношение «Детали» - можем указать составной частью какой детали является данная, отношение «Сотрудники» - можем указать, кто из сотрудников является начальником для данного).

Мощность связи показывает, какое число экземпляров одной сущности связано с экземплярами другой сущности.

Мощность может быть:

один-к-одному (1:1) - в группе студентов один староста;
один-ко-многим (1:N) - в одном отделе работает много сотрудников;
многие-ко-многим (M:N) - один покупатель купил много товаров, товаров покупали много покупателей.

Сила связи : сильная связь (Identifying Relationship)

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

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

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

Сила связи: Слабая связь (Nonidentifying Relationship)

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

Первичный ключ мигрирует из родительской сущности в дочернюю и не входит в состав первичного ключа (становится просто внешним ключом).

На диаграмме сильная связь отображается пунктирной линией между сущностями.

Рекурсивная-связь (унарная связь)

Чаще всего используется для построение иерархий.

Поставщик МОЖЕТ работать с НУЛЕМ или БОЛЕЕ заказчиков (id_Customer).

Заказчик ДОЛЖЕН работать с одним поставщиком (id_Sup).

Но поставщик и заказчик - это фирма ли организация - объекты одного типа и потому хранятся в одном отношении.

Связь многие-ко-многим.

Пример: поставщики могут поставлять много типов товаров. Разные поставщики могут поставлять одинаковые типы товаров.

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

Неоднозначность связи разрешается введением переходных сущностей, как показано на слайде.

ER-модели и реальность

При ближайшем рассмотрении связи типа "один к одному" почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Представим, что А - поставщик, B - товар.

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (Supplier) должен поставлять только один уникальный набор товаров (Invoice). С точки зрения теории тут все хорошо. На практике это не допустимо: ни кто не будет искать нового поставщика, если проверенный вами поставщик может предоставить несколько номенклатур товара. А теперь об эмоциях, кот будет испытывать оператор при попытке ввода данных о новом поставщике. Он не сможет ввести данные ни в одну из таблиц. Так что весь багаж неприличной лексики будет направлен в ваш адрес.

Optional-mandatory. Пример связи приведен на слайде. Как видим у оператора теперь все хорошо: данные вводить он может. У бизнеса опять проблема: он должен искать нового поставщика, даже если проверенный вами поставщик может предоставить несколько номенклатур товара. А бизнесу нужны проблемы? Нет. Он должен функционировать. Как удовлетворить бизнес? Ответ простой. При проектировании БД нужно думать о нормализации. Если Supplier - сущность, то используйте связи типа optional-mandatory (mandatory-optional) или optional-optional. Хотя чаще всего связи один-к-одному - это ошибка.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса опять проблема. Подведем итоги для связи один-к-одному. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь; - optional-mandatory (mandatory-optional) или optional-optional, то сопровождение бизнеса проблематично.

Связь один-ко-многим mandatory-mandatory - достаточно сильная конструкция, предполагающая, что вхождение сущности B не может быть создано без одновременного создания по меньшей мере одного связанного с ним вхождения сущности A. Чаще всего это неверная связь.

Связь один-ко-многим mandatory-optional - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

Связь один-ко-многим optional-optional - Как A, так и B могут существовать без связи между ними.

В терминах предыдущего слайда эти диаграммы можно проиллюстрировать на следующих примерах.

Связи один-ко-многим. Эти связи предполагают, что одна запись в одной таблице может быть логически связана с несколькими записями в другой таблице.

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (A) должен поставлять один или более наборов товаров (B). С точки зрения теории тут все хорошо. Однако на практике оператор не сможет ввести данные ни в одну из таблиц, поскольку записи необходимо одновременно вводить в обе таблицы.

Optional-mandatory. В этом случае у оператора теперь все хорошо: данные вводить он может, а у бизнеса могут возникнуть проблемы. Дело в том, что связь optional-mandatory предполагает, что поставщик (A) должен поставлять один или более наборов товаров (B), в то время как B может принадлежать поставщику. Другими словами, товары могут существовать без поставщика, в то время как у поставщика есть товары. Т.е. возможно неконтролируемое ведение бизнеса: кто поставил товар? С кого спрашивать? А бизнесу проблемы нужны? Нет. Он должен давать прибыль. В этом случае лучше использовать mandatory-optional: поставщик может поставлять один или более наборов товаров, в то время как товар должен принадлежать поставщику. Другими словами, у товара есть поставщик, а данные о поставщиках, которые когда-то поставляли товар будут сохранены. И овцы целы и волки сыты - оператор может вводить данные и бизнесмен в кусе дел.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса проблема - безконтрольность: Товар может существовать без поставщика и поставщик без товара.
Подведем итоги для связи один-ко-многим. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь, поскольку вводить записи одновременно в обе таблицы невозможно; - optional-optional, то сопровождение бизнеса проблематично.

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

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

Многие-ко-многим mandatory-optional - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

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

Optional-optional один-к-одному. Для примера, который приведен на слайде эта связь означает, что любой мужчина (женщина) может состоять в браке с одной женщиной (мужчиной). Эта связь удобна для отслеживания истории брачующихся: впервые, повторно, ... Другими словами, связь альтернативного типа.

Optional-optional один-ко-многим. Пример связи приведен на слайде. Это классическая иерархия (древовидная структура). Связь, приведенную на слайде можно интерпретировать, например, так: любой сотрудник может быть подчинен только одному менеджеру, в то время как менеджер может руководить одним или многими сотрудниками.

Optional-optional М:М Пример связи приведен на слайде 3. Это сетевая структура.

Контрольный список вопросов к сущностям

Отражает ли имя сущности суть данного объекта?
Нет ли пересечения с другими сущностями?
Имеются ли хотя бы два атрибута?
Всего атрибутов не более восьми?
Есть ли синонимы/омонимы данной сущности?
Сущность определена полностью?
Есть ли уникальный идентификатор?
Имеется ли хотя бы одна связь?
Существует ли хотя бы одна функция по созданию, поиску, корректировке, удалению, архивированию и использованию значения сущности?
Ведется ли история изменений?
Имеет ли место соответствие принципам нормализации данных?
Нет ли такой же сущности в другой прикладной системе, возможно, под другим именем?
Не имеет ли сущность слишком общий смысл?
Достаточен ли уровень обобщения, воплощенный в ней?

Контрольный список вопросов к атрибутам:

Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
Имеет ли атрибут только одно значение в каждый момент времени?
Отсутствуют ли повторяющиеся значения (или группы)?
Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
Не может ли он быть пропущенной связью?
Нет ли где-нибудь ссылки на атрибут как на "особенность проекта", которая при переходе на прикладной уровень должна исчезнуть?
Есть ли необходимость в истории изменений?
Зависит ли его значение только от данной сущности?
Если значение атрибута является обязательным, всегда ли оно известно?
Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
Зависит ли его значение только от какой-то части уникального идентификатора?
Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

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

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

2.1 Семантические модели и когнитивный аспект

2.1.1 Семантические модели данных

Что хранят базы данных? Конечно же, данные. Однако, даже для организации хранения данных приходится учитывать связанные с ними смыслы. Так, в предыдущем разделе описывался первичный ключ, который не позволяет дублировать записи в наборе. Это свойство определяет частный смысл набора записей с первичным ключом. Типы данных, домены, метаданные определяют другие смыслы хранящихся данных.

Но если в базе хранятся только данные, то, как же хранятся смыслы? Прежде всего, смыслы -это тоже данные, связанные с теми данными, смысл которых они представляют.

Выделим следующие виды смыслов:

Смыслы, предназначенные только для человека. Могут хранится в информационных системах (ИС), но пассивны, то есть недоступны системе, и потому не влияют на ее поведение. Извлекаются только человеком
Смыслы, внутренние для ИС. Они активны, то есть изменяют или создают новое поведение ИС. Типичные примеры: ключи, типы данных, метаданные.
Смыслы внешние, связанные с системами или задачами, внешними по отношению к ИС, или, более узко, к базе данных. Эти смыслы также активны.

Как проявляется активность внутренних смыслов? Пусть имеется первичный ключ. Вы хотите записать запись в набор. Однако, СУБД сначала сделает то, что вы не просили - проверит допустимость вводимого значения ключа, - и только если это значение отсутствует, занесет запись.

Пример смысла третьего типа: Имеется таблица, содержащая оценки всех студентов по всем дисциплинам. Можно ли вычислить средний балл? Конечно. Однако, если вы знакомы со шкалами измерений, то вы знаете, что измерения успеваемости проводятся в шкале порядка. В ней средний балл смысла не имеет, или, говоря официальным языком, является неадекватной статистикой.

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

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

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

Детально семантика данных будет рассмотрена в лекции "Семантика баз данных" учебника.

Самая известная семантическая модель "сущность-связь" ("entity-rela-tionship" - ER) была предложена Питером Пин Шен Ченом (Peter Chen) в 1976 году.

2.1.2 Когнитивный аспект

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

2.1.3 Уровни модели

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

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

Забегая вперед, заметим, что реляционная модель относится к уровням 2 и 3. Сетевая и иерархическая модели, в том виде как они существовали 20 лет назад, работают в основном на уровне 3 и 4. UML -это уровни 1, 2 и 3, но UML далеко выходит за рамки описания данных. Модель "сущность-связь" работает на уровнях 1 и 2.

ЛЕКЦИЯ

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

Основные понятия: Сущность, Свойства, Связи.

Представление сущностей, свойств, связей

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

Наиболее распространенным средством моделирования предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность-связь» (Entity - Relationship Model - ER М ), впервые предложенная Питером Пин-Шэн Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, но, по существу, реализует объектный подход к моделированию предметной области.

Модель “сущность-связь” положена в основу значительного количества коммерческих CASE-продуктов, поддерживающих полный цикл разработки систем баз данных или отдельные его стадии. При этом многие из них не только поддерживают стадию концептуального проектирования предметной области разрабатываемой системы, но и позволяют осуществить на основе построенной их средствами модели стадию логического проектирования путем автоматической генерации концептуальной схемы базы данных для выбранной СУБД, например, схемы базы данных для какого-либо SQL-сервера или объектной СУБД.

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

Семантическую основу ER -модели составляют следующие предположения:

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

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

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

- систематизация представления, основанная на классах, в общем случае предполагает иерархическую зависимость типов: сущность типа А является подтипом сущности B , если каждый экземпляр типа А является экземпляром сущности типа B ;

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

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

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

На слайде 3 приведенный пример представления сущности, который не является полным и не претендует на точное соответствие какой либо версии построения ER -диаграмм.

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

1. связи между объектами и наборами характеристических свойств и таким образом определить сами объекты;

2. связи между объектами, задающие характер и функциональную природу их взаимозависимости.

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

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

Сущность имеет имя , уникальное в пределах модели. При этом имя сущности - это имя типа , а не некоторого конкретного экземпляра.

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

Свойства(слайд 4)

Природа свойства, как характер связи свойства с сущностью (объектом), может быть различной. Рассмотрим основные виды свойств.

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

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

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

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

Значения свойств могут быть постоянными - статическими , или динамическими , т.е. меняться со временем. Например, свойство «Таб. номер» является статическим, а «Адрес» - динамическим. Свойство может быть неопределенным , если оно является динамическим, но его текущее значение еще не задано.

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

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

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

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

Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным ); в противном случае – неполным (или необязательным ).

Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи ). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1: М), «многие к одному» (М:1), «многие ко многим» (М:М ) (Слайды 5, 6, 7) .

Следует отметить, что инструмент связей - это средство представления сложных объектов , каждый из которых может рассматриваться как множество некоторым образом взаимосвязанных простых объектов . Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностям анализа предметной области, т.е. в конце концов – характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрения, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения поставщика – простым.

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

Отношение «часть-целое» используются для представления составных объектов . Например, МАШИНЫ состоят из УЗЛОВ, УЗЛЫ состоят из ДЕТАЛЕЙ. Здесь возможны как отношения «один ко многим», так и «многие ко многим».

Отношение «род-вид» - для представления обобщенных объектов . Например, СОТРУДНИКИ подразделяются по профессии на КОНСТРУКТОРОВ, ПРОГРАММИСТОВ, РАБОЧИХ; ПРОГРАММИСТЫ – на ПРИКЛАДНЫХ ПРОГРАММИСТОВ и СИСТЕМНЫХ ПРОГРАММИСТОВ. Иерархические отношения, и, в частности – «родо-видовые », обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

Другой широко используемой разновидностью взаимосвязи является агрегирование – объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, «Состав »: ПОДРАЗДЕЛЕНИЕ состоит из СОТРУДНИКОВ; «Поставка »: ПОСТАВЩИК поставляет ДЕТАЛИ.

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

Сущность, на основе которой определяются подтипы, называется супертипом . Подтипы должны образовывать полное множество, т.е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например ПРОЧИЕ.

Подтип наследует свойства и связи супертипа . Например, тип сущности ПРОГРАММИСТ является подтипом сущности СОТРУДНИК. Программисты обладают всеми свойствами сотрудников и участвуют во всех связях, однако обратные утверждения неверны.

Тип сущности, его подтипы, подтипы этих подтипов и т.д. образуют иерархию типов сущности , пример которой приведен на Слайде 8.

9.2. ER- диаграмма

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

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

Сущности .Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе. Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями. Например, в представленной на слайде 9 ER-диаграмме ПОДЧИНЕННЫЙ – сущность слабого типа.

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

Имена ключевых свойств подчеркиваются. Например, свойство «Таб.н омер» сущности СОТРУДНИК.

Контур эллипса рисуется двойной линией, если свойство многозначное. Например, свойство «специальность» сущности СОТРУДНИК.

Контур эллипса рисуется штриховой линией, если свойство производное. Например, свойство «кол-во» сущности ПОСТАВЩИК.

Эллипс соединяется пунктирной линией, если свойство условное. Например, свойство «Ин. я зык» сущности СОТРУДНИК.

Если свойство составное, то составляющие его свойства отображаются другими эллипсами, соединенными с эллипсом составного. Например, свойство «Адрес» сущности СОТРУДНИК состоит из простых свойств «Город», «Улица», «Дом».

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

Стороны ромба рисуют двойными линиями, если это связь сущности слабого типа с сущностью от которой она зависит. Например, связь «Подчинение», связывающая сущность слабого типа ПОДЧИНЕННЫЙ с сущностью СОТРУДНИК, от которой она зависит.

Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны. Например, связь «Подчинение», со стороны сущности ПОДЧИНЕННЫЙ.

Связь может быть модифицирована указанием роли. Например, для рекурсивной связи «Состав», указаны роли: «Деталь состоит из …» и «Деталь входит в состав …».

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать многие сотрудники.

Пример нормализованной формы ER-диаграммы приведен на слайде 10.

Одна из разновидностей модели «сущность-связь» используется в нотации IDEF1Х, входящем в семейство стандартов IDEF.

Графический язык модели и пример диаграммы представлены на слайде 11 .

Необязательные связи между сущностями Отдел и Сотрудник, Сотрудник и Подчиненный имеют мощность «один ко многим» (конец связи «многие» обозначен жирной точкой), а обязательная связь между сущностями Сотрудник и Проект имеет мощность «многие ко многим».

Графические элементы основных нотаций модели «сущность-связь» представлены на слайде 12 .

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

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

Модель "Сущность - связь"

ФИО

Байрамов Александр Мавлеевич

Место работы

МБОУ Средняя школа №6 г. Вязьма Смоленской области

Должность

Предмет

информатика и ИКТ

Эта страничка описывает и иллюстрирует использование модели «Сущность-связь» (entity-relationship model), введенной Питером Ченом (Peter Chen) в 1976 г. В этой статье Чен заложил основу модели, которая с тех пор расширялась и модифицировалась самим Ченом и многими другими. Кроме того, модель «Сущность-связь» вошла в состав множества CASE-инструментов, которые также внесли свой вклад в ее эволюцию. На сегодняшний день не существует единого общепринятого стандарта для модели «Сущность-связь», зато есть набор общих конструкций, которые лежат в основе большинства вариантов этой модели. Описанию этих общих конструкций и демонстрации их применения и посвящена данная глава. Символы, применяемые для графического представления модели «Сущность-связь», весьма различны. Мы обсудим не только традиционные символы, но и символы языка UML (Unified Model Language, унифицированный язык моделирования) - средства проектирования, завоевывающего все большую популярность среди программистов ООП и включающего в себя модель «Сущность-связь».

Ключевыми элементами модели «Сущность-связь» являются:

сущности

атрибуты

идентификаторы

связи

Сущности

Сущность (entity) - это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Примерами сущностей могут служить СОТРУДНИК Мэри Доу, КЛИЕНТ 12345, ЗАКАЗ 1000, ПРОДАВЕЦ Джон Смит или ПРОДУКТ А4200. Сущности одного и того же типа группируются в классы сущностей (entity classes). Так, класс сущностей СОТРУДНИК является совокупностью всех сущностей СОТРУДНИК. В тексте книги классы сущностей обозначаются заглавными буквами.

Важно уяснить разницу между классом сущностей и экземпляром сущности. Класс сущностей - это совокупность сущностей, и описывается он структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности (entity instance) представляет конкретную сущность, такую как КЛИЕНТ 12345; он описывается значениями атрибутов данной сущности. Обычно класс сущностей содержит множество экземпляров сущности. Например, класс КЛИЕНТ содержит множество экземпляров - по одному на каждого клиента, для которого имеется запись в базе данных. Пример класса сущностей и двух экземпляров сущности показан на рис. 1.

Рис. 1. КЛИЕНТ: пример сущности

Атрибуты

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

Исходное определение модели «сущность-связь» включает в себя композитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued attributes).

В качестве примера композитного атрибута можно привести атрибут Адрес, состоящий из группы атрибутов {Улица, Город, Штат, Индекс}. Примером многозначного атрибута может служить атрибут ИмяДоверенногоЛица сущности КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного клиента.

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

Идентификаторы

Экземпляры сущностей имеют идентификаторы (identifiers) - атрибуты, с помощью которых эти экземпляры именуются, или идентифицируются. Например, экземпляры сущностей класса СОТРУДНИК могут идентифицироваться по атрибутам НомерСоциальнойСтраховки, ТабельныйНомерСотрудника или ИмяСотрудника. Такие атрибуты, как Зарплата или ДатаНайма, вряд ли могут служить идентификаторами экземпляров сущностей класса СОТРУДНИК, поскольку обычно эти атрибуты не используются для однозначного указания на конкретного сотрудника. Подобно этому, сущности класса КЛИЕНТ могут идентифицироваться по атрибутам НомерКлиента или ИмяКлиента, а сущности класса ЗАКАЗ могут идентифицироваться по атрибуту НомерЗаказа.

Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникалъным (nonunique).

Если идентификатор является уникальным, его значение будет указывать на один и только один экземпляр сущности.

Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров. ТабельныйНомерСотрудника является, скорее всего, уникальным идентификатором, а ИмяСотрудника - неуникальным (например, может быть несколько сотрудников по имени Джон Смит).

Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами (composite identifiers). Примерами могут служить совокупности вида (КодРегиона, МестныйНомер}, (НазваниеПроекта, НазваниеЗадачи} и (Имя, Фамилия, ДобавочныйНомерТелефона}.

Связи

Взаимоотношения сущностей выражаются связями (relationships). Модель «сущность-связь» включает в себя классы связей и экземпляры связей. Классы связей (relationship classes) - это взаимоотношения между классами сущностей, а экземпляры связи (relationship instances) - взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты.

Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree). Изображенная на рис. 2, а связь ПРОДАВЕЦ-ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей: ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ на рис. 2; б имеет степень 3, так как в ней участвуют три класса сущностей: МАТЬ, ОТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют еще бинарными связями (binary relationships).

Рис.2. Различные степени связей: а - связь степени 2; б - связь степени 3

Три типа бинарных связей

На рис. 3 показаны три типа бинарных связей. В связи 1:1 («один к одному») одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. На рис. 3, а связь СЛУЖЕБНЫЙ_АВТОМОБИЛЬ связывает одиночную сущность класса СОТРУДНИК с одиночной сущностью класса АВТОМОБИЛЬ. В соответствии с этой диаграммой, ни за одним сотрудником не закреплено более одного автомобиля, и ни один автомобиль не закреплен более чем за одним сотрудником.

Рис. 3. Три типа бинарных связей: а - бинарная связь 1:1; б - бинарная связь 1:N; в - бинарная связь N:М; г- представление связи с помощью разветвлений

На рис. 3, б изображен второй тип связи, 1:N («один к N» или «один ко многим»). В этой связи, которая называется ОБЩЕЖИТИЕ-ЖИЛЕЦ, единичный экземпляр сущности класса ОБЩЕЖИТИЕ связан со многими экземплярами сущности класса СТУДЕНТ. В соответствии с этим рисунком, в общежитии проживает много студентов, но каждый студент живет только в одном общежитии.

Позиция, в которой стоят 1 и N, имеет значение. Единица стоит на той стороне связи, где располагается ОБЩЕЖИТИЕ, а N стоит на той стороне связи, где располагается СТУДЕНТ. Если бы 1 и N располагались наоборот, и связь записывалась бы как N:l, получилось бы, что в общежитии живет один студент, причем каждый студент живет в нескольких общежитиях. Это, разумеется, не так.

На рис. 3, в показан третий тип бинарной связи, N:M (читается «N к М» или «многие ко многим»). Эта связь называется СТУДЕНТ-КЛУБ, и она связывает экземпляры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов.

Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи. Например, о связи, изображенной на рис. 3, б, говорят, что она обладает максимальной кардинальностью 1:N. Кардинальные числа могут иметь и другие значения, а не только 1 и N. Например, связь между сущностями БАСКЕТБОЛЬНАЯ_КОМАНДА и ИГРОК может иметь кардинальность 1:5, что говорит нам о том, что в баскетбольной команде может быть не более пяти игроков.

Связи трех типов, представленных на рис. 3, называются иногда связями типа «ИМЕЕТ», или связями обладания (HAS-A relationships). Такой термин используется потому, что одна сущность имеет (has) связь с другой сущностью. Например: сотрудник имеет автомобиль, студент имеет общежитие, клуб имеет студентов.

Схемы, изображенные на рис. 3, называются диаграммами «Сущность-связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams). Такие диаграммы стандартизированы, но не слишком жестко. В соответствии с этим стандартом, классы сущностей обозначаются прямоугольниками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба. Имя сущности указывается внутри прямоугольника, а имя связи указывается рядом с ромбом Хотя в некоторых ER-диаграммах имя связи указывается внутри ромба, получающаяся при этом диаграмма может выглядеть ужасно, поскольку ромбы приходится делать большого размера и вне масштаба, чтобы в них поместилось имя связи. Чтобы избежать этого, имена связей иногда пишут над ромбом. Когда имя помещается внутрь или поверх ромба, кардинальность связи изображается с помощью разветвлений на линиях, соединяющих сущность (или сущности) с множественной стороной связи. На рис. 3, г показаны связи ОБЩЕЖИТИЕ-ЖИЛЕЦ и СТУДЕНТ-КЛУБ с такими разветвлениями.

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

Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрированный на рис. 4.

Рис. 4. Связь с указанной минимальной кардинальностью

Этот способ заключается в следующем: чтобы показать, что сущность обязана участвовать в связи, на линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал. Соответственно, рис. 4 показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана иметь связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное число, равное единице, и максимальное кардинальное число, равное «многим» сущностям СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число, равное нулю, и максимальное кардинальное число, равное одному экземпляру сущности ОБЩЕЖИТИЕ.

Может существовать связь между сущностями одного и того же класса. Например, для сущностей класса СТУДЕНТ может быть определена связь СОСЕД_ПО_КОМНАТЕ. Такая связь показана на рис. 5, а, а на рис. 5, б изображены экземпляры сущностей, охваченных этой связью. Связи между сущностями одного и того же класса называются иногда рекурсивными связями (recursive relationships).

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

Элементы модели «сущность-связь» Сущность - Класс сущностей - Экземпляр сущности Атрибуты - Композитные атрибуты - Многозначные атрибуты Идентификаторы - Уникальные/неуникальные - Композитные Связи - Классы связей - Экземпляры связей - Рекурсивные связи

Элементы модели «сущность-связь» Класс сущностей (entity classes) – это совокупность сущностей, описывается структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности (аn instance) представляет конкретную сущность Обычно класс сущностей держит множество экземпляров сущности.

Элементы модели «сущность-связь» Атрибуты Атрибуты (свойства) – описывают характеристики сущности. Пример композитного атрибута: Адрес, состоящий из группы атрибутов {Улица, Город, Индекс}. Пример многозначного атрибута: атрибут Имя студента сущности ПРЕПОДАВАТЕЛЬ, который может содержать имена нескольких обучаемых им студентов.

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

Элементы модели «сущность-связь» Связи Взаимоотношения сущностей выражаются связями. Классы связей (relationship classes) это взаимоотношения между классами сущностей. Экземпляры связи (relationship instances) взаимоотношения между экземплярами сущностей Степень связи (relationship degree) число классов сущностей, участвующих в связи. Обозначение средствами в UML-диаграммах: Связь обозначается

Элементы модели «сущность-связь» Три типа бинарных связей Обозначение средствами в UML- диаграммах: Связь 1:1(«один к одному») обозначается Связь 1:N («один к N» или «один ко многим») – Связь N:M (читается «N к М» или «многие ко многим») – Связь обладания в обобщенном виде, когда не указан конкретный тип связи - Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи.

Диаграммы «сущность-связь» Схемы бинарных связей, изображенных выше, называются диаграммами «сущность-связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams). Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрирован ниже. Связь с указанной минимальной кардинальностью

Слабые сущности Слабые сущности (weak entity) - сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью (strong entity). Идентификационно-зависимые сущности (ID-dependent entities) - это такие сущности, идентификаторы которых содержат идентификатор другой сущности.

Диаграммы «сущность-связь» в стиле UML Конструкции ООП, введенные языком UML Классы всех сущностей, которые должны храниться в базе данных, помечаются стереотипом «Persistent» (устойчивый) UML допускает назначение атрибутов классам сущностей UML использует объектно-ориентированную нотацию для обозначения видимости атрибутов и методов «+» - открытые «#» - защищенными «-» - закрытыми

Диаграммы «сущность-связь» в стиле UML Открытым (public) называется такой атрибут, который может читаться и изменяться любым методом любого объекта. Термин защищенный (protected) означает, что атрибут или метод доступен только для методов данного класса и его подклассов. А термин закрытый (private) указывает на то, что соответствующий атрибут или метод доступен только для методов данного класса. В UML задаются ограничения и методы.