Модель сущность-связь — различия между версиями
Kabanov (обсуждение | вклад) (Новая страница: «== Сущности == == Связи == == Ассоциации == == Слабые сущности == == Альтернативные нотации ==») |
м (rollbackEdits.php mass rollback) |
||
(не показано 19 промежуточных версий 3 участников) | |||
Строка 1: | Строка 1: | ||
== Сущности == | == Сущности == | ||
+ | {{Определение | ||
+ | |definition = | ||
+ | '''Сущностью''' (англ. ''entity'') называют некоторый объект, обладающий именем и атрибутами.}} | ||
+ | {{Определение | ||
+ | |definition = | ||
+ | '''Атрибутом''' (англ. ''attribute'') называют некоторую характеристику объекта, содержащую имя атрибута и домен и обладающую некоторыми свойствами. }} | ||
+ | |||
+ | [[Файл:Student сущность.png|400px|thumb|right|Пример сущности $Student$]] | ||
+ | |||
+ | Домен не указывает конкретный физический тип, однако позволяет указать, какие атрибуты будут иметь одинаковый тип в физической модели. Так, например, атрибуты $FirstName$ и $LastName$ сущности $Student$ будут обладать одним физическим типом. | ||
+ | |||
+ | '''Типы доменов:''' | ||
+ | * Простой {{---}} атомарное значение, например, $id$ | ||
+ | * Составной {{---}} состоящий из нескольких значений, например, <code>passport { series: char(4), number: char(6) }</code> | ||
+ | |||
+ | '''Свойства атрибутов:''' | ||
+ | |||
+ | {| class="wikitable" style="background-color:#FFF; text-align:center" | ||
+ | ! style="background-color:#F0F8FF;" |Обозначение | ||
+ | ! style="background-color:#F0F8FF;" |Свойство | ||
+ | |- | ||
+ | |'''M''' | ||
+ | |Обязательное (англ. ''mandatory'') | ||
+ | |- | ||
+ | |'''O''' | ||
+ | |Необязательное (англ. ''optional'') | ||
+ | |- | ||
+ | |'''PK''' | ||
+ | |Основной ключ (англ. ''primary key'') | ||
+ | |- | ||
+ | |'''Kn''' | ||
+ | |Дополнительный ключ $n$ (англ. ''key'') | ||
+ | |} | ||
+ | |||
+ | '''Замечания:''' | ||
+ | * Так как любой атрибут обладает либо свойством обязательности, либо свойством необязательности, будем считать атрибуты необязательными по умолчанию, не указывая это свойство явно. | ||
+ | * Основной ключ можно выделить, подчеркнув атрибуты, входящие в него, сплошной линией. | ||
== Связи == | == Связи == | ||
+ | |||
+ | [[Файл:ERM Student Group.png|400px|thumb|right|Пример связи]] | ||
+ | '''Связь''' обозначается линией с двумя концами и обладает следующими характеристиками: | ||
+ | * Имя | ||
+ | * Связываемые сущности и их роли | ||
+ | * Тип связи (задается типами концов) | ||
+ | |||
+ | На примере показано, что студен принадлежит одной группе, а в группе может быть несколько студентов (в том числе нуль). | ||
+ | |||
+ | '''Типы концов:''' | ||
+ | {| class="wikitable" style="background-color:#FFF; text-align:center" | ||
+ | ! style="background-color:#F0F8FF;" |Тип | ||
+ | ! style="background-color:#F0F8FF;" |Обозначение | ||
+ | |- | ||
+ | |style="padding: 3px" |Один | ||
+ | |[[Файл:Db mandatory.png|50px]] | ||
+ | |- | ||
+ | |style="padding: 3px" | Много | ||
+ | |[[Файл:Db many.png|50px]] | ||
+ | |- | ||
+ | |Обязательный | ||
+ | |[[Файл:Db mandatory.png|50px]] | ||
+ | |- | ||
+ | |style="padding:3px"| Необязательный | ||
+ | |[[Файл:Db optional.png|50px]] | ||
+ | |} | ||
+ | |||
+ | Можно выбрать значение по умолчанию, которое будет обозначаться сплошной линией без символов. | ||
+ | |||
+ | '''Примеры:''' | ||
+ | {| class="wikitable" style="background-color:#FFF; text-align:center" | ||
+ | ! style="background-color:#F0F8FF;" |Связь | ||
+ | ! style="background-color:#F0F8FF;" |Значение | ||
+ | ! style="background-color:#F0F8FF;" |По умолчанию | ||
+ | |- | ||
+ | |style="padding: 2px"|[[Файл:Many to many.png|120px]] | ||
+ | |Многие ко многим | ||
+ | |style="padding: 2px"|Единственность, необязательность | ||
+ | |- | ||
+ | |style="padding: 2px"|[[Файл:One to many.png|120px]] | ||
+ | |Один ко многим | ||
+ | |Единственность, обязательность | ||
+ | |- | ||
+ | |style="padding: 2px"|[[Файл:One to one.png|120px]] | ||
+ | |Один к одному | ||
+ | |Единственность, обязательность | ||
+ | |- | ||
+ | |} | ||
+ | |||
+ | '''Замечание:''' В дальнейшем будем считать, что значениями по умолчанию будет «один» и «необязательный». | ||
== Ассоциации == | == Ассоциации == | ||
+ | {{Определение | ||
+ | |definition = | ||
+ | '''Ассоциацией''' (англ. ''association'') называется многосторонняя связь, нагруженная произвольными не ключевыми атрибутами.}} | ||
+ | |||
+ | [[Файл:Association contract.png|400px|thumb|right|Графическое обозначение ассоциации]] | ||
+ | '''Замечания:''' | ||
+ | * Ассоциация обозначается прямоугольником с закругленными краями | ||
+ | * Может содержать не ключевые атрибуты | ||
+ | * Имеет произвольное количество концов с произвольными ролями и типами | ||
+ | |||
+ | [[Файл:Db erm contract.png|400px|thumb|left|Пример с ассоциацией]] | ||
+ | Проанализируем пример. Контракт заключается с одним студентом, на одну специальность, которая может быть не указана на момент заключения контракта. У контракта должен быть один или более поручителей. Контракт нагружен информацией о датах, когда контракт был подготовлен (обязательный атрибут) и подписан (опциональный атрибут, поскольку контракт может быть подписан не сразу). | ||
+ | |||
+ | '''Как понять, что использовать: ассоциацию, связь или сущность?''' | ||
+ | * Если нужно два конца и нет нагруженности, используем связь | ||
+ | * Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов | ||
+ | * Иначе используется ассоциация | ||
+ | |||
+ | ===Многосторонние ассоциации=== | ||
+ | [[Файл:Association неопределнность нотации.png|thumb|right|350px|Пример неоднозначности интерпретации связей]] | ||
+ | Многостороннюю ассоциацию можно интерпретировать по-разному. Так, например, на рисунке может быть обозначено следующее: | ||
+ | * У каждого контракта есть один поручитель | ||
+ | * Можно быть поручителем у ровно одного контракта | ||
+ | |||
+ | {| class="wikitable" style="background-color:#FFF; text-align:center" | ||
+ | |'''Ограничение по Чену''' <br /> (англ. ''Chen-like'', ''Look-across'') | ||
+ | |[[Файл:Chen-like.png|350px]] | ||
+ | |style="padding: 10px;"|Зафиксировав остальные сущности, получаем<br/> ограничение на рассматриваемую. <br/> У каждого контракта есть поручитель. | ||
+ | |- | ||
+ | |'''Ограничение по Мерис''' <br /> (англ. ''Merise-like'', ''Look-here'') | ||
+ | |[[Файл:Merise-like.png|350px]] | ||
+ | |style="padding: 10px;"|Ограничение непосредственно на сущность. <br/> Можно быть поручителем у одного контракта. | ||
+ | |} | ||
+ | Также существуют '''обобщенные ограничения''' (англ. ''generic''), позволяющие зафиксировать произвольное подмножество. | ||
+ | [[Файл:Все ограничения.png|600px]] | ||
+ | |||
+ | === Выразительная мощность ограничений === | ||
+ | * Для ассоциаций с двумя концами: | ||
+ | ** Чен = Мерис = Обобщенные | ||
+ | * Для ассоциаций с тремя концами: | ||
+ | ** Чен + Мерис = Обобщенные | ||
+ | * Для ассоциации с четырьмя и более концами: | ||
+ | ** Чен + Мерис < Обобщенные | ||
== Слабые сущности == | == Слабые сущности == | ||
+ | {{Определение | ||
+ | |definition = | ||
+ | '''Слабой сущностью''' называется сущность, у которой недостаточно атрибутов для идентификации.}} | ||
+ | Слабая сущность обозначается прямоугольником с двойной границей. | ||
+ | {{Определение | ||
+ | |definition = | ||
+ | '''Идентифицирующей связью''' называется связь, позволяющая слабой сущности получить атрибуты, необходимые для ее идентификации.}} | ||
+ | [[Файл:Weak entity.png|400px|thumb|right|Пример слабой сущности]] | ||
+ | Идентифицирующая связь обозначается двойной сплошной линией. | ||
+ | |||
+ | Например, название учебной группы уникально в рамках одного университета. Если же мы будем рассматривать несколько университетов, для идентификации группы будет недостаточно лишь ее названия. В таком случае можно считать группу слабой сущностью, для идентификации которой необходим университет. | ||
== Альтернативные нотации == | == Альтернативные нотации == | ||
+ | Выше рассматривалась нотация '''Crow's foot''', предложенная Гордоном Эверестом. | ||
+ | ===Нотация Питера Чена=== | ||
+ | Модель Сущность-связь была предложена Питером Ченом в 1976 году, им же была предложена следующая графическая нотация: | ||
+ | |||
+ | [[Файл:Нотация Питера Чена.png|600px]] | ||
+ | |||
+ | ===UML-нотация=== | ||
+ | Для каждой таблицы явно подписывается, что она обозначает (ассоциацию, сущность и т.д.). Ограничения прописываются в виде $i..k$ (например, $1..n$), это позволяет наложить ограничение $2..n$, что было невозможно в Crow's foot. | ||
+ | |||
+ | [[Файл:UML-нотация.png|400px]] | ||
+ | |||
+ | ===Object Definition Language=== | ||
+ | Позволяет задавать схему базы данных кодом. | ||
+ | |||
+ | Рассмотрим пример. У студента есть идентификатор <code>Id</code>, имя <code>Name</code>, а также ссылка на группу <code>group</code>. Явно указываем, что противоположностью этой ссылки является соответствующее поле класса <code>Group</code>: <code>inverse Group::students</code>. | ||
+ | |||
+ | У группы есть <code>Id</code> и смножество студентов <code>students</code>, учащихся в группе. Указываем, что у студентов ссылка хранится в поле <code>group</code>. | ||
+ | |||
+ | В данном примере выражена связь один ко многим: студент зачислен в одну группу, в каждой группе есть несколько студентов. | ||
+ | |||
+ | '''class''' Student { | ||
+ | int Id; | ||
+ | string Name; | ||
+ | Group group inverse Group::students; | ||
+ | } | ||
+ | |||
+ | '''class''' Group { | ||
+ | int id; | ||
+ | Set<Student> students inverse Student::group; | ||
+ | } |
Текущая версия на 19:23, 4 сентября 2022
Содержание
Сущности
Определение: |
Сущностью (англ. entity) называют некоторый объект, обладающий именем и атрибутами. |
Определение: |
Атрибутом (англ. attribute) называют некоторую характеристику объекта, содержащую имя атрибута и домен и обладающую некоторыми свойствами. |
Домен не указывает конкретный физический тип, однако позволяет указать, какие атрибуты будут иметь одинаковый тип в физической модели. Так, например, атрибуты $FirstName$ и $LastName$ сущности $Student$ будут обладать одним физическим типом.
Типы доменов:
- Простой — атомарное значение, например, $id$
- Составной — состоящий из нескольких значений, например,
passport { series: char(4), number: char(6) }
Свойства атрибутов:
Обозначение | Свойство |
---|---|
M | Обязательное (англ. mandatory) |
O | Необязательное (англ. optional) |
PK | Основной ключ (англ. primary key) |
Kn | Дополнительный ключ $n$ (англ. key) |
Замечания:
- Так как любой атрибут обладает либо свойством обязательности, либо свойством необязательности, будем считать атрибуты необязательными по умолчанию, не указывая это свойство явно.
- Основной ключ можно выделить, подчеркнув атрибуты, входящие в него, сплошной линией.
Связи
Связь обозначается линией с двумя концами и обладает следующими характеристиками:
- Имя
- Связываемые сущности и их роли
- Тип связи (задается типами концов)
На примере показано, что студен принадлежит одной группе, а в группе может быть несколько студентов (в том числе нуль).
Типы концов:
Тип | Обозначение |
---|---|
Один | |
Много | |
Обязательный | |
Необязательный |
Можно выбрать значение по умолчанию, которое будет обозначаться сплошной линией без символов.
Примеры:
Связь | Значение | По умолчанию |
---|---|---|
Многие ко многим | Единственность, необязательность | |
Один ко многим | Единственность, обязательность | |
Один к одному | Единственность, обязательность |
Замечание: В дальнейшем будем считать, что значениями по умолчанию будет «один» и «необязательный».
Ассоциации
Определение: |
Ассоциацией (англ. association) называется многосторонняя связь, нагруженная произвольными не ключевыми атрибутами. |
Замечания:
- Ассоциация обозначается прямоугольником с закругленными краями
- Может содержать не ключевые атрибуты
- Имеет произвольное количество концов с произвольными ролями и типами
Проанализируем пример. Контракт заключается с одним студентом, на одну специальность, которая может быть не указана на момент заключения контракта. У контракта должен быть один или более поручителей. Контракт нагружен информацией о датах, когда контракт был подготовлен (обязательный атрибут) и подписан (опциональный атрибут, поскольку контракт может быть подписан не сразу).
Как понять, что использовать: ассоциацию, связь или сущность?
- Если нужно два конца и нет нагруженности, используем связь
- Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов
- Иначе используется ассоциация
Многосторонние ассоциации
Многостороннюю ассоциацию можно интерпретировать по-разному. Так, например, на рисунке может быть обозначено следующее:
- У каждого контракта есть один поручитель
- Можно быть поручителем у ровно одного контракта
Также существуют обобщенные ограничения (англ. generic), позволяющие зафиксировать произвольное подмножество.
Выразительная мощность ограничений
- Для ассоциаций с двумя концами:
- Чен = Мерис = Обобщенные
- Для ассоциаций с тремя концами:
- Чен + Мерис = Обобщенные
- Для ассоциации с четырьмя и более концами:
- Чен + Мерис < Обобщенные
Слабые сущности
Определение: |
Слабой сущностью называется сущность, у которой недостаточно атрибутов для идентификации. |
Слабая сущность обозначается прямоугольником с двойной границей.
Определение: |
Идентифицирующей связью называется связь, позволяющая слабой сущности получить атрибуты, необходимые для ее идентификации. |
Идентифицирующая связь обозначается двойной сплошной линией.
Например, название учебной группы уникально в рамках одного университета. Если же мы будем рассматривать несколько университетов, для идентификации группы будет недостаточно лишь ее названия. В таком случае можно считать группу слабой сущностью, для идентификации которой необходим университет.
Альтернативные нотации
Выше рассматривалась нотация Crow's foot, предложенная Гордоном Эверестом.
Нотация Питера Чена
Модель Сущность-связь была предложена Питером Ченом в 1976 году, им же была предложена следующая графическая нотация:
UML-нотация
Для каждой таблицы явно подписывается, что она обозначает (ассоциацию, сущность и т.д.). Ограничения прописываются в виде $i..k$ (например, $1..n$), это позволяет наложить ограничение $2..n$, что было невозможно в Crow's foot.
Object Definition Language
Позволяет задавать схему базы данных кодом.
Рассмотрим пример. У студента есть идентификатор Id
, имя Name
, а также ссылка на группу group
. Явно указываем, что противоположностью этой ссылки является соответствующее поле класса Group
: inverse Group::students
.
У группы есть Id
и смножество студентов students
, учащихся в группе. Указываем, что у студентов ссылка хранится в поле group
.
В данном примере выражена связь один ко многим: студент зачислен в одну группу, в каждой группе есть несколько студентов.
class Student { int Id; string Name; Group group inverse Group::students; } class Group { int id; Set<Student> students inverse Student::group; }