Что означает модальность связи и как она обозначается в er диаграмме
Основные понятия ER-диаграмм
Определение 1. Сущность (Entity)— это реальный или представляемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором должна сохраняться и быть доступна.
Каждая сущность должна иметь уникальное наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная». Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис.1). При этом имя сущности – это имя типа, а не некоторого конкретного экземпляра этого типа.
Рис. 1. Обозначение сущности.
Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.
Например, представителем сущности «Сотрудник» может быть «Сотрудник Иванов».
Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности (это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах).
Типы сущностей можно классифицировать как сильные и слабые. Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных. Например, читатель библиотеки – сильная сущность, а абонемент этого читателя – слабая, которая зависит от наличия соответствующего читателя. Слабые сущности называют подчинёнными (дочерними), а сильные – базовыми (основными, родительскими).
Также сущности разделяют на независимыеизависимые.Сущность является независимой, если каждый экземпляр ее может быть однозначно идентифицирован без определения его отношений с другими сущностями. Независимая сущность изображается прямоугольником с четко выраженными углами. Сущность является зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Зависимая сущность изображается прямоугольником со скругленными углами.
Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника определяющего сущность, причем каждый атрибут занимает отдельную строку, и отделяются от названия сущности линией (рис. 2).
Рис. 2. Указание атрибутов сущности.
Рядом с именем атрибута можно приводить примеры значений данного атрибута.
1. Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ. В качестве первичного ключа обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам сущности. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
2. Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
3. Однозначные и многозначные атрибуты. Могут иметь соответственно одно или много значений для каждого экземпляра сущности. На диаграмме изображаются с двойным подчеркиванием.
4. Основные и производные атрибуты.Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).
Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности – множества значений (или домена), которые может принимать данный атрибут.
Рис. 3. Указание обязательных и необязательных атрибутов сущности.
Сущность может иметь несколько различных ключей. Различают первичный, альтернативный и внешнийключи.
Рис. 4. Указание ключевого атрибута.
Внешние ключи (Foreign Key)создаются, когда сущности соединяются связью при построениифизических ER-диаграмм. Происходит миграция атрибутов первичного ключа родительской сущности в дочернюю сущность. Появившийся таким образом в дочерней сущности атрибут будет являться внешним ключом. (Из родительской сущности атрибут не исчезает, а просто копируется в дочерней сущности). Внешний ключ обозначается ВК.
Первичный ключ может бытьабсолютный или относительный. Если все атрибуты, составляющие первичный ключ, принадлежат сущности, то он является абсолютным. Если один или более атрибутов первичного ключа принадлежат другой сущности, то он является относительным. Когда первичный ключ является относительным, сущность определяется как зависимая сущность, поскольку ее идентификатор зависит от другой сущности. В примере на рисунке 5 первичный ключ сущности Компания является относительным. Он включает первичный ключ сущности Список компаний.
Рис. 5. Относительный первичный ключ.
Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Определение связи в методе Баркера несколько отличается от данного Ченом.
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указывается:
· тип конца связи (сколько экземпляров данной сущности связывается),
· обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).
Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с сущностью используется трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией (рис. 6).
Рис. 6. Изображение связи между сущностями.
Наименование связи обычно выражается в неопределенной глагольной форме: «иметь», «принадлежать» и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности. Имя каждой связи между двумя сущностями должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения родителя, так что может быть образовано предложение соединением имени сущности-родителя, имени связи, выражения степени и имени сущности-потомка.
Каждая связь может иметь один из следующих типов связи (рис. 7):
Рис. 7. Типы связей и их изображение на диаграмме.
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностейсвязи (рис. 8):
Рис. 8. Модальность связи и ее изображение на диаграмме.
Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с однимэкземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на рис. 6).
Тип связи в совокупности с модальностью называют еще кардинальностью связи (табл. 1):
Таблица 1. Кардинальность связи.
| Обозначение | Кардинальность |
 | 0,1 |
 | 1,1 |
 | 0,N |
 | 1,N |
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 6 читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».
На следующем примере (рис. 9) изображена рекурсивная связь, связывающая сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем «являться сыном» определяет тот факт, что один человек может быть сыном не более чем одному отцу. Конец связи с именем «являться отцом» означает, что один человек может являться отцом для одного или более ЛЮДЕЙ (т.е не каждый человек имеет детей).
Нотации модели сущность-связь (ER диаграммы)
Модель сущность-связь (Entity-Relationship, ER) применяется для моделирование предметной области (разработки словаря системы) и логической структуры базы данных.
В этой статье вас никто не будет пытаться убедить что предметную область надо моделировать, а базу данных — проектировать. Вы не научитесь проектировать БД, проектирование — большая и сложная тема для других статей. Не будет тут никаких открытий и откровений.
Цель статьи — помочь в ситуации, когда по каким-то причинам вам нужно построить ER-диаграмму, но вы не знаете как это правильно сделать.
ER-модель описывает сущности и отношения между ними с использованием графической нотации. Сущности содержат атрибуты (свойства). Например, если вы разрабатываете систему для спортивных клубов — то:
Проблемы с разработкой ER-модели возникают потому что:
1 Основные возможности. Нотация Чена
В качестве единственного примера этой нотации рассмотрим ER-диаграмму базы кинотеатра из соседней статьи [Chen_model]. Кстати, в статье описан процесс проектирования структуры БД.
Ключевые поля на диаграмме помещаются в верхнюю секцию прямоугольника, видно что у Билета используется составной ключ. Кроме того, эта нотация позволяет описать типы полей (у Чена только названия).
3 Нотация диаграммы классов UML
Нотация Мартина во многом похожа на нотацию диаграммы классов UML, ознакомиться с которой можно в статье [UML_class]. Однако, ее применение для моделирования предметной области и структуры БД имеет ряд особенностей:
Диаграмма классов активно используется при объектно-ориентированном проектировании и для ее построения существует множество инструментов. Это очень удобно если вы при изучении программирования уже успели познакомиться с нотацией диаграммой классов. В качестве ER-модели эта ноация исопльзуется, например, в инструментах серии Rational от IBM. Самое главное отличие этой нотации от предыдущих — на нее существует международный стандарт [UML_ISO_1, UML_ISO_2]. Дополнительно рекомендую прочитать статью [ER_Krivishein], так как мной были упущены некоторые аспекты — например, особенности использования агрегации и наследования на этих диаграммах (лично я считаю, что в 99% случаев они будут лишними).
4 Нотация IDEF1X
Существует масса других нотаций, которые от описанных выше отличаются системой обозначений и лишь в редких случаях вносят какие-либо новые возможности. Рассматривать их нет никакого смысла. Однако, нельзя не упомянуть про IDEF1X так как на него существует международный стандарт [IDEF1X_ISO]. Очень хороший материал по использованию этого стандарта приведен в [Anisimov_IDEF1X].
Из неприятного, в стандарте IDEF1X исопльзуются символы и типы связей, не поддерживаемые многими инструментальными средствами. Инструмент ERwin Data Modeler целиком и полностью посвящен моделированию БД с исопльзованием IDEF1X. При этом ERwin работает только под Windows и имеет проприетарную лицензию.
На мой взгляд, наиболее удобные инструментальные средства используют нотации Мартина или UML. Я рекомендую выбирать для работки модели одну из этих двух нотаций исходя из того, насколько вам важна стандартизация — на UML есть стандарт, а на нотацию Мартина нет.
Модальность связи
Каждая связь может иметь одну из двух модальностей связи:
Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.
Связь может иметь разную модальность с разных концов (как на Рис. 4).
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».
Пример разработки простой ER-модели
При разработке ER-моделей мы должны получить следующую информацию о предметной области:
Список сущностей предметной области.
Список атрибутов сущностей.
Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.
Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:
Хранить информацию о покупателях.
Печатать накладные на отпущенные товары.
Следить за наличием товаров на складе.
(?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.
Куда поместить сущности «Накладная» и «Склад» и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями «Покупатель» и «Товар»? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:
Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:
Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.
Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.
Каждый склад имеет свое наименование.
Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Что такое ER-диаграмма и как ее создать?
Каковы ваши потребности в диаграммах?
содержание
В этом разделе вы подробно познакомитесь с ER-диаграммами и моделями, их истоками, сферами применения, примерами, компонентами и ограничениями. Здесь же вы узнаете, как создать собственную ER-диаграмму на нашей платформе.
Читается за 12 мин.
Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.
Что такое ER-диаграмма?
Схема «сущность-связь» (также ERD или ER-диаграмма) — это разновидность блок-схемы, где показано, как разные «сущности» (люди, объекты, концепции и так далее) связаны между собой внутри системы. ER-диаграммы чаще всего применяются для проектирования и отладки реляционных баз данных в сфере образования, исследования и разработки программного обеспечения и информационных систем для бизнеса. ER-диаграммы (или ER-модели) полагаются на стандартный набор символов, включая прямоугольники, ромбы, овалы и соединительные линии, для отображения сущностей, их атрибутов и связей. Эти диаграммы устроены по тому же принципу, что и грамматические структуры: сущности выполняют роль существительных, а связи — глаголов.
ER-диаграммы — «родственники» схем структуры данных (DSD), где вместо связей между самими сущностями отображаются отношения между элементами внутри них. ER-диаграммы часто используются в сочетании с диаграммами DFD, которые схематично показывают движение потоков информации в рамках процесса или системы.
В ER-моделях и моделях данных обычно выделяют до трех уровней детализации:
Обращаем ваше внимание на тот факт, что похожие уровни масштаба и детализации встречаются и в других видах схем (например, в диаграммах DFD), однако данная классификация отличается от трехсхемного подхода в разработке ПО, где деление информации осуществляется по несколько иному принципу. Правда, иногда разработчики применяют ER-диаграммы с дополнительными иерархиями, если дизайн базы данных требует больше информационных уровней. К примеру, разработчик может добавить новые группы по принципу расширения вверх (суперклассы) и вниз (подклассы).
Области применения диаграмм «сущность-связь»
Символы и способы нотации ERD
Диаграммы «сущность-связь» (или ERD) — неотъемлемая составляющая процесса моделирования любых систем, включая простые и сложные базы данных, однако применяемые в них фигуры и способы нотации могут запросто ввести в заблуждение любого. Это руководство поможет вам стать настоящим экспертом по нотации ER-диаграмм и уверенно взяться за моделирование собственных баз данных!
Концептуальные модели данных дают общее представление о том, что должно входить в состав модели. Концептуальные ER-диаграммы можно брать за основу логических моделей данных. Их также можно использовать для создания отношений общности между разными ER-моделями, положив их в основу интеграции. Все приведенные ниже символы можно найти в библиотеках «Сущность-связь» для UML» и «Фигуры по модели «сущность-связь» на Lucidchart.
Символы ERD-сущностей
Под понятием «сущности» подразумеваются объекты или понятия, несущие важную информацию. С точки зрения грамматики, они, как правило, обозначаются существительными, например, «товар», «клиент», «заведение» или «промоакция». Ниже представлены три наиболее распространенных типа сущностей, используемых в ER-диаграммах.
| Символ | Название | Описание |
|---|---|---|
| Ассоциативная сущность | Соединяет экземпляры сущностей разных типов. Также содержит атрибуты, характерные для связей между этими сущностями. |
Символы ERD-связей
Связи используются в схемах «сущность-связь» для обозначения взаимодействия между двумя сущностями. Грамматически связи, как правило, выражаются глаголами, например, «назначить», «закрепить», «отследить», и несут полезную информацию, которую невозможно получить, опираясь только на типы сущностей.
