Глава 4: Расширение связей/ Структурные
ограничения
Обзор
В Главах 2 и 3, мы познакомились с некоторыми элементами ER диаграмм, такими как сущности, атрибуты и отношения. Однако на практике для определения связей этого бывает недостаточно, необходимо также ввести понятие структурных ограничений. Структурные ограничения – это информация о том, каким образом две (или более) сущностей связаны между собой. Существует два вида структурных ограничений: количество элементов (мощность) и участие.
В этой главе, помимо рассмотрения структурных ограничений, нам бы хотелось рассмотреть грамматические правила для описания изображений на ER-диаграммах. Грамматические правила смогут помочь в процессе выяснения требований (шаг 1) после того как мы определим шаблон для английского языка, который можно будет применять к диаграммам и который позволит нам четко описать, что означает та или иная диаграмма. В этой главе будут рассмотрены шаги 6 и 7 методологии ER-проектирования. На 6-м шаге природа связей формулируется на структурированном английском, а на 7-м шаге обсуждает презентация базы данных (на данной стадии) пользователю
Также в главе будут рассмотрены правила преобразования связей с примерами данных. В конце главы мы продолжим развивать учебный пример, начатый в Главах 2 и 3.
Числовой коэффициент связи
Числовой коэффициент связи является грубой мерой количества сущностей (одной или нескольких) связанных с другой (другими) сущностями. На пример, существуют 4 способа «численного обозначения» связи между сущностями АВТОМОБИЛЬ и СТУДЕНТ: один-к-одному (1:1), многие-к-одному (M:1), один-ко-многим (1:M), и многие-ко-многим (M:N).
Один-к-одному (1:1)
При таком типе (виде) связи одна сущность ассоциируется с другой сущностью и наоборот. Так, в рассмотренном ранее примере связи «управлять» (см. Рисунок 4.1), мы заявляем, что один автомобиль управляется одним студентом и один студен управляет одним автомобилем. Тогда связь автомобиль/студент будет один-к-одному, или в символьном виде:
СТУДЕНТ:АВТОМОБИЛЬ :: 1:1
Рис 4.1: ER Диаграмма БД СТУДЕНТ-АВТОМОБИЛЬ со связью «управляет» и с указанием числового коэффициента связи.
Графически связь 1:1 можно изобразить следующим образом (Рис. 4A) (Batani, Ceri, and Navathe, 1992).
Рис 4A: Связь один-к-одному. СТУДЕНТ:АВТОМОБИЛЬ::1:1
Многие-к-одному (M:1)
Если бы связь СТУДЕНТ:АВТОМОБИЛЬ, изображенная на Рис 3.6, была бы многие-к-одному, мы могли бы сказать, что несколько студентов ассоциируются с одной машиной и одна машина ассоциируется с несколькими студентами, или в символьном виде:
СТУДЕНТ:АВТОМОБИЛЬ::M:1
Мы намеренно использовали глагольную форму «ассоциируется с» вместо глагола «управлять», поскольку утверждение «много студентов управляют одним автомобилем» имеет несколько толкований. Поэтому употребление специфического глагола для обозначения связи между сущностями не всегда будет корректным( особенно при первом изображении диаграммы), до тех пор пока аналитик не будет абсолютно уверен в том, что глагол правильно отображает концепции (идеи) пользователя. Мы также могли бы использовать глагольную форму «связан с» вместо «ассоциируется с»
…
Итак, мы закрепили язык, с помощью которого описываются связи, но что означает
связь СТУДЕНТ:АВТОМОБИЛЬ::M:1? Она отображает ситуацию, когда например, семья владеет одной машиной и машина управляется разными членами семьи.
Графически связь M:1 можно изобразить следующим образом (Рис 4B) (Batani, Ceri, and Navathe, 1992).
Рис 4B: Связь многие-к-одному. СТУДЕНТ:АВТОМОБИЛЬ::M:1
Один-ко-многим (1:M)
Значение связи СТУДЕНТ:АВТОМОБИЛЬ, изображенной на Рис 3.6, может быть таким: один студент ассоциируется со многими автомобилями, а конкретный автомобиль ассоциируется только с одним Понятно, что определяя связи 1:M или M:1, необходимо четко представлять, какая сущность единична (обозначается как 1), а каких много (обозначаются как М).
В данном случае имеем:
СТУДЕНТ:АВТОМОБИЛЬ::1:M
Графически связь 1:М можно изобразить следующим образом (Рис 4C) (Batani, Ceri, and Navathe, 1992).
Рис 4C: Связь один-ко-многим. СТУДЕНТ:АВТОМОБИЛЬ::1:M
Многие-ко-многим (M:N)
При связях многие-ко-многим, множество записей одной сущности соотносится с множеством записей другой сущности. Связь многие-ко-многим обозначается как M:N, т.е. М записей одной сущности связаны с N записями другой сущности. В ранних изданиях можно встретить обозначение такой связи как M:M, но в более новых книгах используется M:N что бы показать что количество связанных записей может быть не одинаковым (значения M и N скорее всего будут различны).
Если бы связь между СТУДЕНТ:АВТОМОБИЛЬ была бы многие-ко-многим, один студент ассоциировался бы со множеством автомобилей, и один автомобиль ассоциировался бы со множеством студентов:
СТУДЕНТ:АВТОМОБИЛЬ::M:N
В таком случае (если связь SA означает «управляет»), множество студентов может управлять множеством автомобилей, и множество автомобилей может управляться множеством студентов. К примеру, представим семью, у которой есть несколько автомобилей, тогда один член семьи может управлять любым из автомобилей, и любой автомобиль может управляться любым из членов семьи.
Графически связь 1:М можно изобразить следующим образом (Рис 4D) (Batani, Ceri, and Navathe, 1992).
Рис 4D: Связь многие-ко-многим СТУДЕНТ:АВТОМОБИЛЬ::M:N
Выражая численную связь между сущностями, используют отношение x:x, где x = 1 или M(N). Такое отношение называется числовой коэффициент связи. Каким образом отобразить реальную ситуацию с нашими СТУДЕНТами и АВТОМОБИЛями? Это довольно интересный вопрос. Ответ таков: мы моделируем ситуацию, как ее определит пользователь. То есть мы выслушиваем пользователя, делаем некоторые предположения и рисуем модель. После этого мы описываем модель пользователю с помощью структурированного английского языка, и он подтверждает или корректирует ее.
Своеобразной ловушкой при ER-проектировании является попытка смоделировать все возможные ситуации. Такое просто невозможно. Целью создания базы данных как правило является реализация какой-либо частной ситуации, которой можно будет управлять в процессе системного анализа (программного проектирования). В классическом системном анализе, аналитик выслушивает пользователя, разрабатывает спецификацию и предоставляет ее обратно пользователю. Здесь же аналитик (разработчик БД) моделирует реальность которую «ощущает» пользователь, поэтому реализации могут быть различны. Если пользователь с чем то не согласен, аналитик может легко изменить концептуальную модель, и так до тех пор пока они не придут к соглашению по поводу того, что должно быть отражено в модели (что модель должна отображать).
В нашем примере СТУДЕНТ:АВТОМОБИЛЬ выберем ситуацию, при которой один студент ассоциируется с (управляет) одним автомобилем. Суть модели заключается в необходимости выбора того, каким образом установить связь между сущностями и какую информацию вложить в эти сущности. Необходимо помнить, что мы имеем дело с концептуальной моделью, которая может меняться в зависимости от ситуации. Тем не менее, следует выбрать некоторую начальную модель, и в качестве одной из них мы выбираем связь один-к-одному между студентами и автомобилями.
В Chen-модели тип связи на ER-диаграмме изображается добавлением числового коэффициента рядом с линиями, соединяющими сущности. (см. Рис. 4.1)
На Рис 4.1 поставим "1" около линий, соединяющих сущности СТУДЕНТ и АВТОМОБИЛЬ с ромбом, изображающим связь между ними. Проще говоря, единица означает, что студент связан с одним автомобилем и один автомобиль связан с одним студентом. Следует быть предельно осторожным при пояснении того, что означает та или иная связь. Это не означает, что один студент владеет одним автомобилем или что он выплачивает страховку за этот автомобиль. В нашей модели это означает только то, что студент управляет только одним автомобилем. Далее, мы говорим что автомобиль управляется одним и только одним студентом. Совершенствуя нашу базу данных, мы стараемся присвоить связи название (имя), что бы определить концепцию, которую моделируем; и в данном случае мы назовем связь «управляет».
Участие: Полное/Частичное
Вполне вероятно что в некотором студгородке не все студенты управляют автомобилями. Для нашей модели мы можем предположить, что все машины студгородка ассоциируются с одним студентом (то есть мы исключаем возможность вождения персоналом или преподавателями и рассматриваем только связь студент/автомобиль).
Чтобы показать, что каждый автомобиль управляется студентом, но не каждый студент управляет автомобилем, расширим Chen-модель и нарисуем двойную линию между ромбом, изображающим связь, и сущностью АВТОМОБИЛЬ. Другими словами, каждый автомобиль участвует в данной связи. Со стороны студента мы оставляем линию одинарной, чтобы показать, что не каждый студент управляет автомобилем. Некоторые студенты могут не участвовать в связи «управляет», например по причине отсутствия прав. Одинарные/двойные линии называются ограничениями участия или опциональными ограничениями. Пример изображен на Рис 4.2.
Рис 4.2: ER-диаграмма базы данных СТУДЕНТ-АВТОМОБИЛЬ со связью «управляет»
Двойная линия изображает полное участие. Некоторые авторы предпочитают называть такое участие обязательным. Суть заключается в том, что если часть связи имеет ограничение в виде полного (обязательного) участия, нельзя присвоить связывающему атрибуту null-значение. В нашем случае, если АВТОМОБИЛЬ записан в БД, он должен быть связан с некоторым студентом. Одинарная линия означает частичное, или опциональное, участие. Это означает, что могут быть студенты, не связанные ни с одним автомобилем.
Контрольные вопросы 4.1
1. Что такое структурные ограничения?
2. Какую информацию дает нам числовой коэффициент связи?
3. Сколько существует способов связи двух сущностей, отличающихся числовым коэффициентом связи? Приведите примеры.
4. Какую информацию дает ограничение участия?
5. Всегда ли необходимо иметь числовой коэффициент связи и ограничение участия в одной и той же ER-диаграмме? Почему? Объясните.
Описание на структурированном английском
Теперь закрепим грамматические правила, с помощью которых описывается, каким образом накладываемые на связи структурные ограничения влияют на сущности, и определим стандартный способ установления связей между сущностями. Стандартный язык должен появиться вместе с реализацией модели. В дальнейшем использование стандартного языка для описания ER-диаграмм позволит не только общаться с пользователем в процессе системного анализа, но также облегчит обратную связь и позволит закрепить точное значение связи (имеется в виду глагол).
В Chen-модели двойные линии определяют полное участие ("автомобили полностью участвуют в связи «управлять»). Двойные линии предлагают нам установить связь следующим образом:
Автомобили должны управляться одним (и только одним) студентом.
Должны возникает из полного (обязательного) участия, а одним – из числового коэффициента связи.
Грамматика для описания частичной или опциональной связи между сущностями СТУДЕНТ и АВТОМОБИЛЬ должна быть такой:
Студент может управлять одним и только одним автомобилем.
Может соответствует одинарной линии, а «один и только один» следует из числового коэффициента связи. Смысл заключается в том, при выражении сущности ER-диаграммы мы используем язык, который передает точное грамматическое значение той или иной связи (т.е. студенты могут управлять одним автомобилем и автомобили должны управляться одним и только одним студентом).
Пример, иллюстрирующий, как следует «читать» ER-диаграмму, представлен на
рисунке 4.3.
Рис 4.3: ER Диаграмма БД СТУДЕНТ-АВТОМОБИЛЬ. Перевод диаграммы на английский.
Точный Английский
Мы настоятельно рекомендуем, чтобы английские предложения сопровождали (комментировали) каждую диаграмму в целях улучшения наглядности рисунков. Обратимся к Рис 4.3. Английский во многом двусмысленный язык. И утверждение что:
Автомобили должны управляться одним и только одним студентом.
На самом деле значит:
Автомобили, которые внесены в БД, должны управляться одним и только одним студентом.
И оно не значит что:
Один конкретный студент управляет некоторыми автомобилями.
Или выражаясь другими словами:
Автомобили должны управляться одним единственным студентом-водителем. Студенты могут управлять одним и только одним автомобилем.
Что бы исключить неясность при установлении связи, возьмем утверждения на английском для проиллюстрированной выше связи, и определим четыре шаблона возможного выражения данной связи. Все бинарные связи должны быть установлены в обоих направлениях для каждой стороны. Как станет видно, мы постараемся определить шаблоны для выражений, но не стоит забывать, что могут быть случаи не соответствующие ни одному из шаблонов. Нет ничего плохого в уточнении языковых конструкций для того, что бы сделать выражение более понятным, но для это придется повторяться (говорить одни и те же вещи).
Шаблон 1 — x:y::k:1
Со стороны k, полное участие (k = 1 или M):
Все х, записанные в БД, должны быть связаны с одним и только одним y. Не существует таких x, которые связаны с более чем одним y.
Пример:
СТУДЕНТ:Консультант::M:1
Каждый студент должен иметь одного констультанта.
или
Студенты, записанные в БД, должны имеет одного и только одного консультанта. Нет таких студентов, которые имели бы более одного консультанта.
Фраза "записанные в БД» может быть полезной, поскольку некоторые разработчики БД рассматривают вопросы более обобщенно, а не в контексте конкретной БД. Например, кто-то может резонно утверждать что, у студента может быть к примеру два консультанта, но вопрос состоит в том, будет ли такой случай встречаться в нашей конкретной БД?
Шаблон 2 — x:y::k:1
Со стороны k, частичное участие (k = 1 или M):
x, но не обязательно все x (записанные в БД), может быть связаны с одним и только одним y. Некоторые x не связаны с y вообще. Все x не могут быть связаны с более чем с одним y.
Пример:
СТУДЕНТ:Сообщество::M:1
Выражение «Некоторые студенты вступают в сообщество (сообщества)» превращается в:
Студенты, но не обязательно все из них (записанные в БД), могут вступить в сообщество. Некоторые студенты могут не вступать в сообщество. Но все студенты не могут вступить более чем в одно сообщество.
Шаблон 3 — x:y::k:M
Со стороны k, полное участие (k = 1 или M):
x, записанные в БД, должны быть связаны со многими (одним или более) y. Иногда полезно добавлять фразы вроде этой: Не существует x, связанных с не-y (или) Не существует х, не связанных с y.
Пример:
АВТОМОБИЛЬ:СТУДЕНТ::M:N
Автомобили управляются многими студентами, что означает:
Автомобили, занесенные в БД, должны управляться многими (одним и более) студентами.
По этому поводу возникают следующие соображения. Во первых, мы говорим только о транспортных средствах, зарегистрированных в этой школе. Во вторых, в этой БД зарегистрированы только студенческие автомобили. В третьих, если автомобиль из нашей базы данных управляется кем-то, то он должен быть зарегистрирован и управляться студентом. В четвертых, "одним и более” определяется структурными ограничениями (числовым коэффициентом связи). В пятых, имеется соблазн сказать что-то об y, но этого следует избегать, так как он описывается в каком то другом шаблоне. Например, кто-то попытается сказать что все студенты управляют машинами или что все студенты связаны с транспортным средством, но оба этих утверждения будут не верны.
Шаблон 4 — x:y::k:M
Со стороны k, частичное участие (k = 1 или M):
x, но не обязательно все x (записанные в БД), может быть связаны со многими (ноль и более) y. Некоторые x могут быть не связаны с y.
Пример:
Курс:Книга::k:M
Некоторые курсы могут требовать (использовать) множество книг,
или после преобразования:
Курсы, но необязательно все (внесенные в БД), могут использовать много (ноль и более) книг.
Некоторые курсы могут и не требовать книг.
Отметим что из-за частичного участия (одинарные линии) фраза "ноль или более" используется для указания числового коэффициента связи. Если связь моделируется по определенным выше шаблонам, но описание на английском звучит некорректно, то вероятно была выбран неверная модель. Обычно грамматические выражения наиболее полезны в двух случаях: (1) при объяснении проектируемой базы данных пользователю и (2) при обсуждении смысла проектируемой БД между разработчиками.
Полное описание на английском может вызвать некоторые трудности у разработчика, но зато оно позволяет не забывать о том, что выражение "x связаны с одним y" может пониматься по разному до тех пор, пока двусмысленность не будет снята налагаемыми на связь структурными ограничениями.
Далее, отрицательные утверждения могут быть полезны для установления необходимых требований, хотя временами отрицание настолько громоздко, что его вовсе не используют. Мы рекомендуем добавлять отрицания или другую не противоречащую (не вызывающую разночтений) грамматику только в случае, если она помогает передать смысл и смысловые ограничения. Опасность добавления предложений заключается в том что они могут привести к противоречиям (разночтениям) и запутывающим примечаниям.
Итоги по вышеприведенным шаблонам и связям
Шаблон 1: Связь x: y::1 (полное участие) :1 графически представлена на Рис 4E
Рис 4E: Иллюстрация шаблона связи 1(full):1 Chen-модели
Шаблон 1: Связь x: y::M (полное участие) :1 Графически показана на Рис 4F
Рис 4F: Иллюстрация шаблона связи M(full):1 Chen-модели
Наиболее частый тип связи определяется ситуацией, когда сущность СУЩНОСТЬ1 может существовать только для одной сущности СУЩНОСТЬ2.
Шаблон 2: Связь x: y::1 (частичное участие) :1 графически изображена на Рис 4G
Рис 4G: Иллюстрация шаблона связи 1(partial):1 Chen-модели
Шаблон 2: Связь x: y::M (частичное участие) :1 графически изображена на Рис 4
Рис 4H: Иллюстрация шаблона связи M(partial):1 Chen-модели
В таком случае некоторые сущности СУЩНОСТЬ1 и СУЩНОСТЬ2 могут существовать без связей друг с другом.
Шаблон 3: Связь x: y::1 (полное участие) :M графически изображена на Рис 4I
Рис 4I: Иллюстрация шаблона связи 1(full):M Chen-модели
Шаблон 3: Связь x: y::M (частичное участие) :N графически изображена на Рис 4J
Рис 4J: Иллюстрация шаблона связи M(full):N Chen-модели
Шаблон 4: Связь x: y::1 (частичное участие):M графически изображена на Рис 4K
Рис 4K: Иллюстрация шаблона связи 1(partial):M Chen-модели
Шаблон 4: Связь x: y::M (частичное участие):N графически изображена на Рис 4L
Рис 4L: Иллюстрация шаблона связи M(partial):N Chen-модели
Контрольные вопросы 4.2
1. Нарисуйте ER-диаграмму изображающую полную/частичную зависимости и числовые коэффициенты связи для следующих случаев:
a. Студенты должны консультироваться у одного консультанта.
b. Студенты, но не обязательно все, могут вступить в сообщество. Некоторые студенты могут не вступать в сообщество. Студент не может вступать более чем в одно сообщество.
Теперь наша методология ER-проектирования выглядит следующим образом:
Шаг 1: Выбрать из описания требований к базе данных одну первичную сущность и указать атрибуты, которые будут принадлежать данной сущности. При возможности выделить ключ и привести пример данных.
Шаг 2: Для описания базы данных использовать структурный английский язык для сущностей, атрибутов и ключей.
Шаг 3: Исследовать атрибуты в первичной сущности (возможно с помощью пользователя), чтобы выявить нужно ли записывать информацию о каких-либо атрибутах.
Шаг 3a: Если необходима информация об атрибуте, сделать атрибут сущностью и затем
Шаг 3b: Определите ее связь с родительской сущностью.
Шаг 4: Если можно выделить еще одну сущность, изобразить диаграмму для этой сущности и ее атрибутов. Повторить шаг 2 чтобы выяснить, возможно ли дальнейшее выделение сущностей.
Шаг 5: Определить связи между сущностями, если таковые существуют.
Шаг 6: Определить на структурированном английском языке точный характер связей с обеих сторон. Например связь A:B::1:M означает связь A(1) с B(M) с одной стороны и связь B(M) с A(1) с другой.
Шаг 7: Представить «разработанную» базу данных пользователю, дополнив ее английским описанием всех сущностей, ключей, атрибутов и связей. Пересмотреть диаграмму в случае необходимости.
Шаг 8: Приведите пример данных.
Некоторые примеры других связей
В этом разделе мы более детально рассмотрим 3 других типа связей: один-ко-многим, многие-к-одному и многие-ко-многим.
Пример связи один-ко-многим (1:M)
Связи 1:M и M:1 на деле просто разные стороны одной проблемы. Устанавливая связь 1:M и M:1, нужно быть особенно осторожным, решая какая сущность единична, а какая множественна. Решение в сущности зависит от взгляда разработчика на эту проблему. Возьмем в качестве примера связи 1:M сущности комната и студент. Одна комната может иметь несколько студентов, проживающих в ней, и много студентов могут жить в одной комнате. Поэтому будем считать связь между сущностями комната и студент один-ко-многим (1:M::КОМНАТА:СТУДЕНТ). Ситуация отображена на Рис 4.4 (без атрибутов).
Рис 4.4: ER Диаграмма (без атрибутов) связи 1:M
На Рис 4.4 (Chen-like модели), назовем связь между студентами и комнатами «занимает». Отметим, что не все комнатах могут жить студенты, т. е. сущность КОМНАТА имеет частичное участие в связи.
Естественно то, что:
Комнаты могут заниматься несколькими студентами.
Далее, не все студенты могут жить в комнатах, поэтому связь СТУДЕНТа с КОМНАТой так же частичная:
Студенты могут занимать комнату.
Рассмотрим эту связь в короткой и полной форме записи.
В первом случае мы утверждаем:
"Комнаты могут заниматься многими студентами". Такая ситуация подходит под шаблон 4 — x:y::1(partial):M.
Шаблон 4 — связь 1:M, частичное участие со стороны 1
"Некоторые x связаны со многими y."
Поэтому, более точным будет: x, но не обязательно все x, (записанные в БД) могут быть связаны с несколькими (ноль и более) y. Некоторые x могут быть не связанны с y …
Или: Комнаты, но не обязательно все комнаты, (записанные в БД) могут быть заняты несколькими (ноль и более) студентами.
Для обратной связи: студенты могут занимать комнату, подходит Шаблон 2 — M(partial):1.
Шаблон 2 — M(partial):1, частичное участие со стороны М
"Некоторые x относятся к одному y."
Полная форма записи будет такой:
x, но не обязательно все x, (записанные в БД) могут быть связаны с одним и только одним y. Некоторые x могут быть не связаны с y. …
В данном представлении x и y соответствуют x = студент, y = комната, и отсюда:
Студенты, но не обязательно все, (записанные в БД) могут занимать одну и только одну комнату. Некоторые студенты могут не занимать комнат. Не существует студентов, занимающих более одной комнаты.
Пример связи многие-к-одному (M:1)
Предположим что требуется создать БД студенческой автостоянки. Будем считать, что каждый студент имеет свое место на стоянке. Введем сущность СТОЯНКА, которая будет описывать места стоянки автомобилей , например East Area #7, North Area #28, и т.д. Множество автомобилей соотнесены с одной зоной парковки, и одна стоянка соотнесена со многими автомобилями. Поэтому можно решить, что это связь многих-к-одному, M:1::АВТОМОБИЛЬ:ПАРКОВКА. Диаграмма изображена на Рис 4.5 (снова без атрибутов)
Рис 4.5: ER Диаграмма (без атрибутов) связи M:1
Будем предполагать полное участие сущностей в связи, то есть все автомобили имеют одну стоянку и все стоянки закреплены за студенческими автомобилями.
Связь выражается так:
Шаблон 1 — M:1, полное участие со стороны М
x, записанные в БД, должны быть связаны с одним и только однимy. Не существуетxсвязанных более чем с однимy.
x= АВТОМОБИЛЬ,y= парковка, связь = парковаться
Автомобили, записанные в БД, должны парковаться на одной и только одной стоянке. Один автомобиль не может быть припаркован более чем на одной стоянке.
Обратная связь такова:
Шаблон 3 — 1:M, полное участие со стороны 1
x, записанные в БД, должны быть связаны со многими (одним и более)y.
Стоянки, внесенные в БД, должны парковать множество (один или более) автомобилей. Не существует стоянок с не-студенческими автомобилями. Это означает, что в нашей базе данных нет записей о тех стоянках, на которых паркуются не-студенческие автомобили.
Пример связи многие-ко-многим (M:N)
Классический пример, который мы здесь рассмотрим – студенты и курсы, на которые они записаны. Известно, что студенты обучаются (записаны) на многих курсах и что любой курс включает многих студентов. Начальная диаграмма для связи студент–курс изображена на Рисунке 4.6.
Рисунок 4.6: Диаграмма ER (без атрибутов) для связи M:N
Мы выбрали слово «записан» для описания связи. Участие сущности студент в связи «записан» является полным (обязательным); а участие сущности курс – частичным. Такой выбор сделан произвольно, поскольку обе связи могли быть полными или нет, в зависимости от нужд и желаний пользователя. Посмотрите внимательно на точные грамматические выражения и заметьте, каким образом влияет выбор полного или частичного участия.
Грамматические выражения для этой связи:
Шаблон 3 - M:N, полное участие со стороны М
x, записанные в БД, должны быть связаны со многими (одним или более) y. [Никакой x не связан с не y (или) Не x не связаны с y (или) Никакой x не связан с y. (Отрицания будут зависеть от смысла утверждения.)]
x = студенты, y = курсы, связь = «записан»
Студенты, записанные в базе данных, должны быть записаны на множество (один или более) курсов.
Для обратно связи имеем:
Шаблон 4 - M:N, частичное участие со стороны М
x, но не обязательно все x, (записанных в базе данных), могут быть связаны с многими (один или больше) y. Некоторые x могут быть не связаны с y.
x = курс, y = студент, связь = записан
На курсы, но не обязательно на все, (записанных в базе данных) может быть записано много (один или больше) студентов.
На некоторые курсы студенты могут быть не записаны.
Такое частичное участие сущности курс в связи отражает курсы, которые записаны в базе данных, но не отражает те, на которые в настоящее время не записаны студенты. Это могут быть курсы, которые предполагается ввести в будущем или курсы, которые больше не преподаются. Конечно, если в базе данных записаны только те курсы, на которые записаны студенты, то ограничение участия становится полным, и изменяется смысл связи двух сущностей.
Также, база данных сообщает нам, что пока у нас есть курсы без записанных на них студентов, мы можем хранить информацию об активных студентах. Очевидно мы могли бы сделать участие со стороны студента частичным и следовательно хранить информацию о всех студентах, даже неактивных (не записанных ни на один курс – Прим. ред).
Выберем такой метод установления связи, которым мы пользовались при наложении ограничений на участие в связи, и это поможет нам отобразить ту реальность, о которой пользователь и хотел бы хранить данные. Обратите внимание, что все примеры в этой главе оперируют только с двумя сущностями; то есть рассматриваются только двойные связи. Пример в следующем разделе является еще одним примером бинарных связей.
Контрольные вопросы 4.3
1. Приведите пример связи 1 (полное участие):1. Всегда ли такая связь должна быть полной? Поясните на примере.
2. Приведите пример связи 1 (частичное участие):1. Всегда ли такая связь должна быть частичной? Поясните на примере.
3. Приведите пример связи М (полное участие):N. Какой должна быть такая связь – полной или частичной? Поясните на примере.
4. Приведите пример связи М (частичное участие):N. Какой должна быть такая связь – полной или частичной? Поясните на примере.
Один Заключительный Пример
В качестве заключительный примера представим еще одну проблему и методологию ее решения. Рассмотрим упрощённую модель аэропорта, где записывается информация о ПАССАЖИРах и РЕЙСах. Пусть атрибутами ПАССАЖИРА являются имя, багаж, частота полётов, а атрибутами РЕЙСА - номер рейса, пункт назначения, время взлёта, и предположительное время посадки. Изобразим ER-диаграмму данной модели.
Примечание. Мы не учитываем многие атрибуты, которые могли бы рассмотреть о нашем аэропорте; но предположим в качестве примера, что это вся информация, которая была выбрана для записи (хранения)
Решение таково:
Методология ER-проектирования
Шаг 1: Выбрать из описания требований к базе данных одну первичную сущность и указать атрибуты, которые будут принадлежать данной сущности. При возможности выделить ключ и привести пример данных.
Выбирем ПАССАЖИР в качестве первичной сущности. ПАССАЖИР имеет следующие атрибуты: frequent flier#, имя (фамилия, имя, средний инициал), багаж. Далее, изображаем диаграмму, выбрав в качестве ключа frequent flier# и предположив, что имя является составным атрибутом.
Диаграмма изображена на Рисунке 4.7.
Рисунок 4.7: Диаграмма сущности ПАССАЖИР
Шаг 2: Для описания базы данных использовать структурный английский язык для сущностей, атрибутов и ключей.
Сущность
В базу данных записывается информация ПАССАЖИРАХ. Для каждого пассажира, мы делаем следующую запись: frequent flier#, имя [имя, средний инициал, фамилия], багаж.
Атрибуты
Для атомарных атрибутов, att(j):
Каждому ПАССАЖИРУ всегда будет соответствовать один и только один frequent flier#. Значениеfrequent flier#будет неделимо.
Каждому ПАССАЖИРУ всегда будет соответствовать одна и только одна запись о статьях багажа. Значение записи будет неделимо.
Для составных атрибутов, att(j):
Для каждого ПАССАЖИРА будет записываться его имя, состоящее из имени, среднего инициала и фамилии. Имя, фамилия, средний инициал - составные части атрибутов.
Ключи
Для каждого ПАССАЖИРА, будем считать первичным ключом frequent flier#
Заметим, что мы выбрали frequent flier# в качестве первичного ключа для ПАССАЖИРА. Если бы это было неверно, были бы необходимы другие значения для уникальной идентификации. Но в данном случае это вся информация, которой мы располагаем.
Шаг 3: Исследовать атрибуты в первичной сущности (возможно с помощью пользователя), чтобы выявить нужно ли записывать информацию о каких-либо атрибутах.
Шаг 4: Если можно выделить еще одну сущность, изобразить диаграмму для этой сущности и ее атрибутов. Повторить шаг 2 чтобы выяснить, возможно ли дальнейшее выделение сущностей.
Другая сущность в нашем примере – РЕЙС со следующими атрибутами: номер рейса, пункт назначения, время вылета, время посадки. Снова, мы используем структурированный английский язык:
Сущность
В базу данных записывается информация РЕЙСАХ. Для каждого рейса, мы делаем следующую запись: номер рейса, пункт назначения, время вылета, время посадки.
Атрибуты
Для атомарных атрибутов, att(j):
Каждому РЕЙСУ всегда будет соответствовать один и только один номер рейса. Значение номера будет неделимо.
Каждому РЕЙСУ всегда будет соответствовать одна и только одна запись о пункте назначения. Значение записи будет неделимо.
Каждому РЕЙСУ всегда будет соответствовать одна и только одна запись о времени вылета. Значение записи будет неделимо.
Каждому РЕЙСУ всегда будет соответствовать одна и только одна запись о времени посадки. Значение записи будет неделимо.
Ключи
(b) Один потенциальный ключ (сильная сущность):
Для каждого РЕЙСА, мы считать первичным ключом номер рейса. Мы предполагаем, значения номера рейса является уникальным.
Шаг 5: Определить связи между сущностями, если таковые существуют.
Какая связь между Рейсами и Пассажирами?
Все пассажиры будут лететь некоторым рейсом. Все рейсы будут иметь множество пассажиров. Диаграмма для данного случая изображена на Рисунке 4.8 и Рисунке 4.9. Обратите внимание, что нам снова приходится делать выбор: мы изображаем один рейс каждого пассажира в этой базе данных. В спецификации не описано, должна ли быть связь 1 или М., так что мы выбрали 1. Мы также выбрали полное участие в связи с обеих сторон. Было бы нелогично записывать данные о пассажирах, которые не летают, и о рейсах, на которых нет никаких пассажиров. Но если база данных требовала хранения информации о потенциальных пассажирах, которые не могли бы заказать определенный рейс или о рейсах, которыми не летели пассажиры, тогда нам пришлось бы пересмотреть концептуальную модель. Рисунок 4.8 хорошо демонстрирует только сущности и атрибуты. Рисунок 4.9 использует краткую форму описания признаков, а также приводит некоторые примеры данных.
Рисунок 4.8 можно использовать для представления концептуальной модели, а затем преобразовать его в рисунок 4.9 для документального хранения.
Любой Рисунок должен сопровождаться описанием на структурированном английском языке (шаг 6).
Рисунок 4.8: Типовой пример
Рисунок 4.9: Типовой пример: Альтернативный вариант представления атрибутов с
пояснением и примером данных.
Шаг 6: Определить на структурированном английском языке точный характер связей с обеих сторон. Например связь A:B::1:M означает связь A(1) с B(M) с одной стороны и связь B(M) с A(1) с другой.
Шаблон 1 - M:1, полное участие со стороны М
x, записанные в базе данных, должны быть связаны с одним и только одним y. Никакие x не связаны более чем с одним y.
x = пассажир, y = рейс, связи = «летать»
Пассажиры, записанные в базе данных, должнылететь только одним рейсом. Никакой пассажир не летит более чем одним рейсом.
Шаблон 3 - 1:M, полное участие со стороны 1
x, записанные в базе данных, должны быть связаны со многими (одним или
более) y.
x = рейс, y = пассажир, связи = «летать»
Рейсами, записанными в базе данных, должнылетать многие (один или более) пассажиры. Описания атрибутов смотрите в предыдущих примерах.
Шаг 7: Представить «разработанную» базу данных пользователю, дополнив ее английским описанием всех сущностей, ключей, атрибутов и связей. Пересмотреть диаграмму в случае необходимости.
Шаг 8: Привести пример данных.
См. Рисунок 4.9.
Преобразование связей в реляционную базу данных
В этом разделе мы продолжим знакомство с правилами преобразования, которые мы начали обсуждать в конце Главы 2. В Главе 2 мы узнали, как отобразить сущности, сущности с составными атрибутами и сущности с многозначными атрибутами. В этой главе, рассмотрев структурные ограничения, налагаемые на связи, мы можем научиться преобразовывать связи.
1. Идентифицировать сущности: Пассажир, Рейс
2. Определить сущности, выбрать первичные ключи:
Пассажир (имя [имя, фамилия, средний инициал], frequent flier # , количество статей багажа)
Рейс (номер рейса, пункт назначения, время взлёта, время посадки)
3. Определить связь между Пассажирами и Рейсами?
Пассажиры летят рейсами.
Наше первое правило применяется при преобразовании двоичных связей типа М:N
M3a - Для двоичных M:N связей: Для каждой связи типа M:N создать новую таблицу (отношение) с первичными ключами каждой из двух сущностей (родительских сущностей), которые участвуют в связи M:N. Ключом для новой таблицы будет являться совокупность ключей родительских сущностей. Включить в новую таблицу все атрибуты, которые могут участвовать в связи M:N.
Например, обратимся Рисунку 4.6. Если таблицы СТУДЕНТ и КУРС содержат следующие данные:
Перед выполнением правила M3a нужно убедится? что первичные ключи преобразуемых сущностей существуют и установлены. Если номер студента (student_number) и номер курса (c_number) являются соответственно первичными ключами для сущностей СТУДЕНТ и КУРС, то для преобразования связи M:Nсоздаем новое отношение ЗАПИСАН, которое выглядит следующим образом:
Номер студента и номер курса вместе являются первичным ключом отношения ЗАПИСАН.
Следующий набор правил применяется для преобразования двоичных связей типа 1:1
M3b - Для двоичных связей 1:1: Включить первичный ключ сущности А в сущность B в качестве внешнего ключа.
Для ответа на вопрос, какая сущность является сущностью А, а какая В, существуют следующие три правила преобразования: M3b_1, M3b_2, и M3b_3.
M3b_1 – Для двоичной связи 1:1, если одна из сторон имеет полное участие в связи, а другая – частичное участие, следует сохранить первичный ключ сущности с частичным участием в сущности с полным участием. После этого перенести все атрибуты связи на ту сторону, которая получила первичный ключ (первичный ключ теперь становится внешним в новом отношении).
Например, обратимся к рисунку Рисунок 4.2.
Автомобиль, записанный в базе данных, должен управляться одним и только одним студентом.
И
Студент может управлять одним и только одним автомобилем.
Здесь, полное участие в связи проявляется со стороны АВТОМОБИЛЬ т.к. " Автомобиль должен управляться студентом."
Поэтому мы берем первичный ключ со стороны частичного участия, т.е. из СТУДЕНТ, и включаем его в таблицу АВТОМОБИЛЬ. Первичным ключом таблицы СТУДЕНТ является номер студента, поэтому в отношении АВТОМОБИЛЬ он будет являться внешним ключом. Реализация реляционной базы данных, полученной из ER-диаграммы на Рисунке 4.2, с примерами данных, будет выглядеть так:
Поскольку сущность СТУДЕНТ имеет многозначный атрибут школа, требуется изменить таблицу, чтобы преобразовать многозначный атрибут.
В этом случае, если бы данная связь имела какие-либо атрибуты, их следовало бы включить в отношение АВТОМОБИЛЬ.
M3b_2 - Для двоичных связей 1:1, если обе стороны имеют частичное участие в связи, существуют три альтернативных способа создать реляционную базу данных:
M3b_2a - Первая альтернатива – Можно выбрать одно из двух отношений для записи ключа другого отношения (для получения внешнего ключа – Прим. ред.), чтобы хранить ключ другого (даже если некоторые значения ключа станут нулевыми).
M3b_2b - Вторая альтернатива – в зависимости от семантики ситуации, можно создать новое отношение для размещения связи, которое содержало бы ключи двух связанных сущностей (как сделано в M3a).
Снова обратимся к Рисунку 4.1. Предполагаем что с обоих сторон имеет место частичное участие в отношении, и что атрибут школа отсутствует.
Тогда Рисунок 4.1 читался бы так:
Автомобиль может управляться одним и только одним студентом.
и
Студент может управлять одним и только одним автомобилем.
Тогда реализация реляционной БД могла быть такова:
[берется номер_автомобиля (первичный ключ сущности АВТОМОБИЛЬ) и записывается в сущность СТУДЕНТ, как показано ниже]:
В отношении СТУДЕНТ номер_автомобиля является внешним ключом.
M3b_2c – третий способ реализовать двоичную связь 1:1 с частичным участием обеих сторон. Создать новую таблицу (отношение) только с ключами от таблиц СТУДЕНТ и АВТОМОБИЛЬ, в дополнение к таблицам СТУДЕНТ и АВТОМОБИЛЬ. В этом случае можно было бы преобразовать связи, как это делалось в случае двоичной связи M:N; и если бы имелись некоторые пустые значения (null-значения)
В этом случае мы отобразим связи, как мы сделали в бинарном M:N случае; и если бы были любые пустые значения, то они были бы удалены при объединении таблиц, как показано ниже:
В этом случае наши отношения СТУДЕНТ и АВТОМОБИЛЬ преобразовались бы в:
M3b_3 - Для двоичной связи 1:1, если обе стороны имеют полное участие в связи. Следует использовать семантику связи, чтобы определить, какое из отношений будет содержать в себе ключ другого. Было бы неверно включить внешние ключи в обе таблицы, поскольку создалась бы избыточность в базе данных. После этого переносим все атрибуты связи в таблицу, которая получила внешний ключ.
Теперь предположим полное участие в связи обеих сторон на Рисунке 4.1. Тогда две таблицы СТУДЕНТ и АВТОМОБИЛЬ будут:
В случае описанном выше, номер_студента был включен в АВТОМОБИЛЬ, став для этого отношения внешним ключом. Мы могли также взять первичный ключ сущности АВТОМОБИЛЬ – номер автомобиля – и включить его в таблицу СТУДЕНТ. В этом случае, если бы отношение имело некоторые атрибуты, они бы стали храниться в АВТОМОБИЛЬ, наряду с номером_студента.
Следующий набор правил касается преобразования двоичных связей типа 1:N
M3c - Для двоичной связи 1:N , мы должны проверить, какой вид ограничений участия (полное/частичное – Прим. ред.) накладывается на связь со стороны N.
M3c_1 - Для двоичной связи 1:N, если N-сторона принимает полное участие в связи, включите ключ сущности со стороны 1 в отношение со стороны N в качестве внешнего ключа.
Например, рассмотрим Рисунок 4.4, и предположим, что со стороны студента имеется полное участие в связи, то есть:
В комнате может жить ноль или более студентов.
и
Студенты должны жить в одной и только одной комнате общежития.
Реализация реляционной БД будет такова:
Здесь имеет место полное участие со стороны N, то есть со стороны сущности СТУДЕНТ. Поэтому мы берем ключ сущности КОМНАТА, номер_комнаты, и включаем его в отношение СТУДЕНТ. В таком случае, если отношение имеет некоторые атрибуты, они должны быть перенесены на сторону N, то есть в отношение СТУДЕНТ.
M3c_2 - Для двоичной связи 1:N, если N-сторона принимает частичное участие в связи, то такая связь 1:N может быть преобразована подобно двоичной связи N:M с созданием отдельной таблицы для связи. Ключ нового отношения является совокупностью ключей связанных сущностей. Необходимо включить в эту таблицу все атрибуты, участвующие в связи.
Контрольные вопросы 4.4
1. Сформулируйте правила преобразования которые необходимо применить к рисунку 4.5. Преобразуйте рисунок в реляционную БД и приведите пример данных.
1. Сформулируйте правила преобразования которые необходимо применить к рисунку 4.8. Преобразуйте рисунок в реляционную БД и приведите пример данных
Итоги Главы
В этой главе обсуждались структурные ограничения связей – числовой коэффициент связи и ограничения участия и их отображение на ER-диаграммах. Были обсуждены несколько примеров и диаграмм для двоичных связей с структурными ограничениями (развитыми в Chen-модели). Для каждой диаграммы была представлена строгая английская грамматика, и были определены шаги 7, 8 методологии ER-проектирования. В последней части главы обсуждались правила преобразования связей.
Упражнения главы 4
Упражнение 4.1
Обратимся к Рисунку 2.3. Предположим, что единственные атрибуты СТУДЕНТА - номер студента и имя. Теперь предположим, что имеется другая сущность – высшая школа, которую собирается оканчивать тот или иной студент. Для каждой сущности школа высшая школа будем записывать ее название и расположение (город и штат). Изобразите ER-диаграммы, используя Chen-модель. Следуя методологии, дайте подробное описание вашим диаграммам. Преобразуйте ER-диаграмму в реляционную базу данных.
Упражнение 4.2
Предположим, что колледж имеет одно общежитие с множеством комнатам. Общежитие есть сущность, которая является по сути сущностью «комната общежития», так как общежитие всего одно. Данная сущность имеет атрибуты номер комнаты и признак одиночная/двойная. Предположим также, что сущность СТУДЕНТ в данном случае имеет атрибуты номер_студента, имя, домашний номер. Изобразите ER-диаграммы, используя Chen-модель. Следуя методологии, дайте подробное описание вашим диаграммам. Преобразуйте ER-диаграмму в реляционную базу данных.
Упражнение 4.3
Рассмотрим студенческую базу данных с студенческими организациями и студентами. Студенты будут иметь следующие атрибуты: номер студента и имя. Организация будут обладать следующими атрибутами: название организации и тип организации. Изобразите ER-диаграммы, используя Chen-модель. Следуя методологии, дайте подробное описание вашим диаграммам. Преобразуйте ER-диаграмму в реляционную базу данных.
Упражнение 4.4
Рассмотрите базу данных с преподавателями и студентами. Студенты имеют атрибуты – номер и имя. Преподаватели имеют атрибуты – имя, номер офиса, и специализация. Специализация, в которой преподаватель работает, определяется соответствующим кодом (например, Химия - ХИМ, Биология – БИО и т.д.). Изобразите ER-диаграммы, используя Chen-модель. Следуя методологии, дайте подробное описание вашим диаграммам. Преобразуйте ER-диаграмму в реляционную базу данных.
Упражнение 4.5
Вы хотите записывать следующую информацию в БД: название ресторана и его местоположение, имя работника и его номер, вместимость ресторана (для курящих или нет), часы работы, зарплата работников. Служащий может работать только в одном ресторане. Изобразите ER-диаграммы, используя Chen-модель. Следуя методологии, дайте подробное описание вашим диаграммам. Преобразуйте ER-диаграмму в реляционную базу данных.
Упражнение 4.6
Запишите следующую информацию в БД: зарегистрированное имя фирмы, владелец, местоположение, номера телефонов, номер грузовика по доставке товаров, вместимость грузовика, описание маршрута (например, Север, Запад, Центральный, Озеро). Изобразите ER-диаграммы, используя Chen-модель. Следуя методологии, дайте подробное описание вашим диаграммам. Преобразуйте ER-диаграмму в реляционную базу данных.
Упражнение 4.7
Взгляните на Рисунок 4.10. Какие английские предложения могли бы дать о нем описание?
Рисунок 4.10
Упражнение 4.8
Обратитесь к Рисунку 4.9. Дополните диаграмму, добавив точные описания на английском для каждого атрибута. Преобразуйте диаграмму на Рис.9 в реляционную базу данных.
Упражнение 4.9
Каков численный коэффициент связи в следующих случаях:
a. Каждый студент может иметь только один автомобиль
b. Каждый студент имеет много автомобилей
c. Каждый автомобиль может управляться многими студентами
d. Каждый автомобиль должен управляться многими студентами.
В каких случаях проявляется полное участие в связи, а в каких – частичное?
Изобразите диаграммы для данных связей.
Список литературы
Batani, C., Ceri, S., and Navathe, S.B., Conceptual Database Design. Benjamin/Cummings Publishing, Redwood City, CA, 1992.
Earp, R. and Bagui, S., "Extending Relationships in the Entity Relationship Diagram," Data Base Management, Auerbach Publications, Boca Raton, FL, 22-10-42, 1-14, May 2001.
Elmasri, R. and Navathe, S.B., Fundamentals of Database Systems, 3rd ed., Addison-Wesley, Reading, MA, 2000.
Kroenke, D.M., Database Processing, Prentice Hall, Upper Saddle River, NJ, 2000.
McFadden, F.R. and Hoffer, J.A., Modern Database Management, 4th ed., Benjamin/Cummings Publishing, Redwood City, CA. 1994.
Ramakrishnan, R. and Gehrke, J., Database Management Systems, 3rd ed., McGraw-Hill, New York, 2003.
Sanders, L., Data Modeling, Boyd & Fraser Publishing, Danvers, MA, 1995.
Учебный Пример: Западно-Флоридский торговый
комплекс (продолжение)
В прошлых главах мы выбрали наши первичные сущности (согласно информации, полученной от пользователя) и определили связи между первичными сущностями. В этой главе мы продолжаем создание ER-диаграммы для данного учебного примера, применяя шаги 6 и 7 методологииER-проектирования, и преобразуемER-диаграмму в реляционную базу данных (с некоторыми примерами данных).
Шаг 6 определяет структурные ограничения, налагаемые на двоичные связи:
Шаг 6: Определить на структурированном английском языке точный характер связей с обеих сторон. Например, связь A:B::1:M означает связь A с B вида один-ко-многим с одной стороны и связь B с A вида многие-к-одному с другой стороны..
Обратимся к Рисунку 4.11.
Рисунок 4.11: ER-диаграмма БД ТОРГОВЫЙ КОМПЛЕКС с 4 сущностями и структурными ограничениями
Сначала рассмотрим связь расположен_в:
Связь от ТОРГОВОГО КОМПЛЕКСА до МАГАЗИНА соответствует Шаблону 3, 1(полное участие):N
Один торговый комплекс должен иметь несколько (по крайней мере один) магазин, или
Торговые комплексы, записанные в базе данных, должны иметь множество (один или более) магазинов, в них расположенных.
Связь от МАГАЗИНА к ТОРГОВОМУ КОМПЛЕКСУ соответствует Шаблону 1,
М (полного участие):1:
Множество магазинов (один или более) должны находится в одном торговом комплексе,
или
Магазины, записанные в базе данных, должны находится в одном торговом комплексе.
Преобразуем эти связи в таблицы (с некоторыми примерами данных):
Сущность ТОРГОВЫЙ КОМПЛЕКС будет преобразована также, как и в предыдущих главах:
Далее нам требуется преобразовать связи между сущностями ТОРГОВЫЙ КОМПЛЕКС и МАГАЗИН. Это двоичное отношение типа 1:N, следовательно используем правило М3с_1, которое гласит:
М3с_1 – Для двоичной связи 1:N, если N-сторона принимает полное участие в связи, включите ключ сущности со стороны 1 в отношение со стороны N в качестве внешнего ключа.
Таким образом, ключ со стороны сущности ТОРГОВЫЙ КОМПЛЕКС, название комплекса, будет перенесен в качестве внешнего ключа на сторону сущности МАГАЗИН.
Из-за многозначного признака, отделов, в СКЛАД(МАГАЗИН), мы сохраним связь с многозначным признаком (как описано в Главе 3):
Тогда, для связи владеетимеем:
Связь от ВЛАДЕЛЬЦА к МАГАЗИНУ соответствует Шаблону 3,
1(полное участие):M:
Владельцы, записанные в базе данных, должны владеть одним или более магазином,
или
Один владелец должен владеть по крайней мере одним магазином, а может владеть и несколькими.
Связь от МАГАЗИНА к ВЛАДЕЛЬЦУ Шаблону 1, М(полное участие):1:
Магазины, записанные в базе данных, должен иметь одного и только одного владельца,
или
Много магазинов могут иметь одного владельца.
Преобразуем эти связи в таблицы (с некоторыми примерами данных):
Для связи между сущностями ВЛАДЕЛЕЦ и СКЛАД типа 1:N
Аналогично, используя правило M3c_1, возьмем ключ со стороны 1, номер владельца, и внесем его в качестве внешнего ключа на сторону N, тогда МАГАЗИН преобразуется в:
А отношение для сущности ВЛАДЕЛЕЦ остается таким же, каким оно было представлено в предыдущей главе.
Для связи управляет имеем:
Связь от МАГАЗИНА к ДИРЕКТОРУ соответствует Шаблону 1(полное участие):1:
Магазины, записные в базе данных, должны иметь только одного директора,
или
Магазины должны иметь одного директора и могут иметь одного и только одного директора.
Связь от ДИРЕКТОРА к МАГАЗИНУ соответствует Шаблону