Модель сущность-связь — различия между версиями
(→Слабые сущности) |
м (rollbackEdits.php mass rollback) |
||
(не показано 12 промежуточных версий 3 участников) | |||
Строка 33: | Строка 33: | ||
|Дополнительный ключ $n$ (англ. ''key'') | |Дополнительный ключ $n$ (англ. ''key'') | ||
|} | |} | ||
+ | |||
+ | '''Замечания:''' | ||
+ | * Так как любой атрибут обладает либо свойством обязательности, либо свойством необязательности, будем считать атрибуты необязательными по умолчанию, не указывая это свойство явно. | ||
+ | * Основной ключ можно выделить, подчеркнув атрибуты, входящие в него, сплошной линией. | ||
== Связи == | == Связи == | ||
Строка 49: | Строка 53: | ||
! style="background-color:#F0F8FF;" |Обозначение | ! style="background-color:#F0F8FF;" |Обозначение | ||
|- | |- | ||
− | |style="padding: | + | |style="padding: 3px" |Один |
− | |[[Файл:Db | + | |[[Файл:Db mandatory.png|50px]] |
|- | |- | ||
− | |style="padding: | + | |style="padding: 3px" | Много |
− | |[[Файл:Db many.png]] | + | |[[Файл:Db many.png|50px]] |
|- | |- | ||
|Обязательный | |Обязательный | ||
− | |[[Файл:Db mandatory.png]] | + | |[[Файл:Db mandatory.png|50px]] |
|- | |- | ||
− | |style="padding: | + | |style="padding:3px"| Необязательный |
− | |[[Файл:Db optional.png]] | + | |[[Файл:Db optional.png|50px]] |
|} | |} | ||
Строка 70: | Строка 74: | ||
! style="background-color:#F0F8FF;" |По умолчанию | ! style="background-color:#F0F8FF;" |По умолчанию | ||
|- | |- | ||
− | |[[Файл:Many to many.png]] | + | |style="padding: 2px"|[[Файл:Many to many.png|120px]] |
|Многие ко многим | |Многие ко многим | ||
− | |style="padding: | + | |style="padding: 2px"|Единственность, необязательность |
|- | |- | ||
− | |[[Файл:One to many.png]] | + | |style="padding: 2px"|[[Файл:One to many.png|120px]] |
|Один ко многим | |Один ко многим | ||
|Единственность, обязательность | |Единственность, обязательность | ||
|- | |- | ||
− | |[[Файл:One to one.png]] | + | |style="padding: 2px"|[[Файл:One to one.png|120px]] |
|Один к одному | |Один к одному | ||
|Единственность, обязательность | |Единственность, обязательность | ||
|- | |- | ||
|} | |} | ||
+ | |||
+ | '''Замечание:''' В дальнейшем будем считать, что значениями по умолчанию будет «один» и «необязательный». | ||
== Ассоциации == | == Ассоциации == | ||
Строка 91: | Строка 97: | ||
[[Файл:Association contract.png|400px|thumb|right|Графическое обозначение ассоциации]] | [[Файл:Association contract.png|400px|thumb|right|Графическое обозначение ассоциации]] | ||
'''Замечания:''' | '''Замечания:''' | ||
− | * Ассоциация обозначается | + | * Ассоциация обозначается прямоугольником с закругленными краями |
* Может содержать не ключевые атрибуты | * Может содержать не ключевые атрибуты | ||
* Имеет произвольное количество концов с произвольными ролями и типами | * Имеет произвольное количество концов с произвольными ролями и типами | ||
[[Файл:Db erm contract.png|400px|thumb|left|Пример с ассоциацией]] | [[Файл:Db erm contract.png|400px|thumb|left|Пример с ассоциацией]] | ||
− | Проанализируем пример. Контракт заключается | + | Проанализируем пример. Контракт заключается с одним студентом, на одну специальность, которая может быть не указана на момент заключения контракта. У контракта должен быть один или более поручителей. Контракт нагружен информацией о датах, когда контракт был подготовлен (обязательный атрибут) и подписан (опциональный атрибут, поскольку контракт может быть подписан не сразу). |
'''Как понять, что использовать: ассоциацию, связь или сущность?''' | '''Как понять, что использовать: ассоциацию, связь или сущность?''' | ||
Строка 102: | Строка 108: | ||
* Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов | * Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов | ||
* Иначе используется ассоциация | * Иначе используется ассоциация | ||
+ | |||
+ | ===Многосторонние ассоциации=== | ||
+ | [[Файл: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]] | ||
+ | |||
+ | === Выразительная мощность ограничений === | ||
+ | * Для ассоциаций с двумя концами: | ||
+ | ** Чен = Мерис = Обобщенные | ||
+ | * Для ассоциаций с тремя концами: | ||
+ | ** Чен + Мерис = Обобщенные | ||
+ | * Для ассоциации с четырьмя и более концами: | ||
+ | ** Чен + Мерис < Обобщенные | ||
== Слабые сущности == | == Слабые сущности == | ||
Строка 107: | Строка 139: | ||
|definition = | |definition = | ||
'''Слабой сущностью''' называется сущность, у которой недостаточно атрибутов для идентификации.}} | '''Слабой сущностью''' называется сущность, у которой недостаточно атрибутов для идентификации.}} | ||
− | Слабая сущность обозначается | + | Слабая сущность обозначается прямоугольником с двойной границей. |
{{Определение | {{Определение | ||
|definition = | |definition = | ||
Строка 117: | Строка 149: | ||
== Альтернативные нотации == | == Альтернативные нотации == | ||
+ | Выше рассматривалась нотация '''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; }