Тема 2.1. Введение в информационные системы. ER – диаграмма

Теория №2. Раздел 2. Основы информационных систем

Тема 2.1. Введение в информационные системы. ER – диаграмма.

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

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

Рис. 1 иллюстрирует, каким образом ER-модели используются при проектировании баз данных. Обычно принято начинать с изучения понятий и описаний информации, под­лежащей моделированию, а затем пытаться отобразить их в рамках ER-модели. Затем ER-проект преобразуется в реляционную схему, выраженную средствами языка определения данных для конкретной СУБД.

 

Рис. 1. Процесс моделирования и реализация баз данных.

 

Элементы ER-модели Наиболее распространенным средством абстрактного представления структур баз данных является ER-модель, или модель "сущность— связь" (entity-relationship model). В ER-модели структура данных отображается графически, в виде диаграммы сущностей и связей (entity-relationship diagram), состоящей из элементов трех основных типов:

a) множеств сущностей;

b) атрибутов;

c) связей.

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

 

Множества сущностей

Сущность (entity) — это абстрактный объект определенного вида. Набор однород­ных сущностей образует множество сущностей (entity set). Понятие сущности обладает определенным сходством с понятием объекта (object) (если трактовать последнее так, как это принято делать в объектно-ориентированном проектировании). Примерно та­ким же образом соотносятся множество сущностей и класс объектов.ER-модель, од­нако, отображает статическиеобъекты — она имеет дело со структурамиданных, но не с операцияминад данными. Поэтому предполагать, что в ней могут содержаться описания неких "методов", соответствующих множествам сущностей и аналогичных методам класса, нет никаких оснований.

Пример 1. На протяжении многих тем мы будем рассматривать и развивать пример, касающийся базы данных о кинофильмах, участвующих в них актерах, студиях, осуществивших съемку, и т.п. Каждый из фильмов представляет собой сущность, а кол­лекция всех фильмов образует множество сущностей. Актеры, снимающиеся в фильмах, также являются сущностями, но другого вида, и их множество — это множество сущно­стей. Киностудия — это сущность еще одного вида, а перечень киностудий формирует третье множество сущностей, которое будет использоваться в дальнейших примерах.

Разновидности ER-модели

В некоторых версиях ER-модели атрибуты могут относиться к следующим типам:

1) атомарный, как в версии, рассматриваемой нами;

2) "struct", как в языке С, или кортеж с фиксированным числом атомарных ком­понентов;

3) множество значений одного типа — атомарного либо "struct".

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

Атрибуты

Множеству сущностей отвечает набор атрибутов(attributes), являющихся свойст­вами сущностей множества. Например, множеству сущностей Movies("кинофильмы") могут быть поставлены в соответствие такие атрибуты, как title("название") и length("продолжительность" — значение периода времени воспроизведения, выраженное в минутах). В версии ER-модели, рассматриваемой в этой лекции, мы предполагаем, что атрибуты представляют собой атомарные значения (например, строки, целые или вещественные числа и т.д.). Существуют и такие варианты модели, в которых понятие типа атрибута трактуется иным образом.

Связи

Связи (relationships) — это соединения между двумя или большим числом множеств сущностей. Если, например, Movies ("кинофильмы") и Stars ("актеры") — это два множества сущностей, вполне закономерно наличие связи Stars-in ("актеры - участники", снявшиеся в фильме), которая соединяет множества сущностей Movies и Stars', сущность m множества Movies соединена с сущностью s множества Stars по­средством связи Stars-in, если актер s снялся в фильме т. Хотя наиболее распростра­нена разновидность бинарных связей (binary relationships), соединяющих два множества сущностей, ER-модель допускает наличие связей, охватывающих произвольное коли­чество множеств сущностей. Обсуждение вопросов, касающихся многосторонних связей (multiway relationships).

Диаграммы сущностей и связей

Диаграмма сущностей и связей (entity—relationship diagram), или ER-диаграмма (ER-diagram), — это графическое представление множеств сущностей, их атри­бутов и связей. Элементы названных видов описываются вершинами графа, и для задания принадлежности элемента к определенному виду используется специаль­ная геометрическая фигура:

• прямоугольник — для множеств сущностей;

• овал — для атрибутов;

• ромб — для связей.

Ребра графа соединяют множества сущностей с атрибутами и служат для представле­ния связей между множествами сущностей.

Пример 2 На рис. 2 приведена ER-диаграмма, представляющая структуру простой базы данных, содержащей информацию о кинофильмах. В составе диаграммы имеется три множества сущностей: Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии").

 

рис. 2 Диаграмма сущностей и связей для базы данных о кинофильмах

 

Экземпляры ER-диаграммы

ER-диаграммы представляют собой инструмент описания схем (schemata), или структур, баз данных. Базу данных, соответствующую определенной ER-диаграмме и содержащую конкретный набор данных, принято называть экземпляром базы данных (database instance). Каждому множеству сущностей в экземпляре базы данных отвечает некоторый частный конечный набор сущностей, а каждая из таких сущностей облада­ет определенными значениями каждого из атрибутов. Уместно отметить, что инфор­мация о сущностях, атрибутах и связях носит строго абстрактный характер: содержи­мое ER-модели не может быть сохранено в базе данных непосредственно. Однако представление о том, что такие данные будто бы реально существуют, помогает на на­чальной стадии проекта — пока мы не перейдем к отношениям и структуры данных не приобретут физическую форму.

 

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

Movies	Stars
Basic Instinct	Sharon Stone
Total Recall	Arnold Schwarzenegger
Total Recall	Sharon Stone

 

Члены множества данных связи — это строки таблицы. Например,

("Basic Instinct", "Sharon Stone") представляет собой кортеж множества данных для текущего экземпляра связи Stars-in.

Множественность бинарных связей

Бинарная связь (binary relationship) в общем случае способна соединять любой член одного множества сущностей с любым членом другого множества сущностей. Однако весьма распространены ситуации, в которых свойство "множественности" связи неко­торым образом ограничивается. Предположим, что R — связь, соединяющая множест­ва сущностей Е и F. Тогда возможно выполнение одного из нескольких условий, пе­речисленных ниже.

· Если каждый член множества Е посредством связи R может быть соединен не более чем с одним членом F, принято говорить, что R представляет связь типа "многие к одному" (many-one relationship), направленную от Е к F. В этом случае каждая сущность множества /'допускает соединение с многими членами Е. Ес­ли же член F посредством связи R может быть соединен не более чем с одним членом Е, мы говорим, что R — это связь "многие к одному", направленная от F к Е (или, что то же самое, связь типа "один ко многим" (one-many relationship), направленная от £ к F).

· Если связь Rв обоих направлениях, от Ек Fи от Fк Е, относится к типу "мно­гие к одному", говорят, что R—это связь типа "один к одному"(one-one relationship). В этом случае каждый элемент одного множества сущностей допус­кает соединение не более чем с одним элементом другого множества сущностей.

· Если связь й ни в одном из направлений — ни от Ек Fи ни от Fк Е —не от­носится к типу "многие к одному", имеет место связь типа "многие ко многим"(many-many relationship).

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

Пример 4. Если следовать рассмотренной логике, связь типа "один к одному" между множествами сущностей Е и F должна представляться на диаграмме двунаправленной стрелкой, один конец которой обращен в сторону множества £, а другой — в сторону F. На рис. 3 показаны два множества сущностей, Studios ("киностудии") и Presidents ("президенты"), соединенные связью Runs ("возглавляет") (атрибуты сущностей для краткости опущены). Уместно предположить, что каждый президент вправе руково­дить только одной студией, а каждая студия может возглавляться только одним прези­дентом. Поэтому связь Runs следует отнести к типу "один к одному" и соединить на диаграмме с множествами сущностей Studios и Presidents посредством двух стрелок, по одной на каждое множество (так, как показано на рис. 3).

 

Рис.3 Связь типа «один к одному»

 

Следует помнить: стрелка означает, что в связи участвует "не более чем один" элемент множества сущностей, на которое она указывает. При этом обязательное на­личие такого элемента в составе множества не гарантируется. Рассматривая диаграмму рис. 3, мы вправе полагать, что некий "президент" обязательно связан с определен­ной студией — иначе на каком основании он мог бы величать себя президентом? Од­нако студия в какой-то период времени может обходиться без руководителя, так что стрелка, направленная от Runs к Presidents, на самом деле означает именно "не более чем один", но не "в точности один".

Многосторонние связи

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

Пример 5. На рис. 4 изображена связь Contracts ("контракты"), которая соединяет между собой множества сущностей Studios ("киностудии"), Stars ("актеры") и Movies ("кинофильмы"). Связь отображает факт заключения контракта между киностудией и определенным актером, обязующимся принять участие в съемках конкретного кино­фильма. Значение некоторой связи в ER-модели, вообще говоря, можно восприни­мать в виде соответствующего множества кортежей, компонентами которых являются

 

 

Рис. 4. Тернарная связь

 

Взаимоотношения типов связей

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

сущности из множеств, соединяемых этой связью. Таким образом, связь Contracts может быть описана набором кор­тежей вида

(studio, star, movie).

В многосторонних связях стрелка, обращенная к некоему множеству сущностей Е, означает следующее: если мы выберем по одной сущности из всех остальных мно­жеств сущностей, охватываемых связью, эти сущности могут быть связаны не более чем с одним элементом множества £. (Обратите внимание, что это правило является обобщением того, которое относится к бинарным связям типа "многие к одному".) На рис. 4 стрелка направлена к множеству сущностей Studios, свидетельствуя о том, что для каждой пары актеров и кинофильмов существует только одна студия, с кото­рой этот актер заключил контракт на участие в съемках определенного кинофильма. Однако стрелки, которые были бы обращены к множествам сущностей Stars и Movies, не заданы: любая студия вправе пригласить для участия в фильме несколько актеров, а любой актер может быть связан со студией контрактом, предусматривающим уча­стие в съемках нескольких кинофильмов. □

Связи и роли

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

Пример 6. На рис. 5 изображена связь Sequel-of ("продолжение кинофильма"), соединяющая множество сущностей Movies ("кинофильмы") само с собой. Каждый конкретный экземпляр связи соединяет два кинофильма, один из которых служит продолжением другого. Чтобы раз­личить два фильма, участвующих в связи, одна из ее линий помечена ролью Original ("исходный"), а другая — Sequel ("продолжение"). Мы подразумева­ем, что некий фильм может иметь несколько про­должений, но для каждого продолжения существует только один "исходный" фильм. Таким образом, связь Sequel-of, соединяющая фильмы Sequel с филь­мами Original, относится к типу "многие к одному рис. 5 отмечен стрелкой). (этот факт на диаграмме 5 отмечена стрелкой

		Original

 

 

Sequel

Рис. 5. Связь и ее роли

Стрелки в многосторонних связях

Если связь охватывает три или более множеств сущностей, для адекватного описа­ния каждой возможной ситуации средствами ER-диаграмм уже не достаточно отве­тить на вопрос, снабжать стрелкой соответствующую линию или нет. Для примера вновь обратимся к диаграмме рис. 4. Некоторая студия напрямую связана с определенным кинофильмом, а не с актером и кинофильмом, рассматриваемыми совместно, поскольку производством фильмов занимается именно студия. Однако используемая нами система обозначений не позволяет отличить эту ситуацию от случая, когда в тернарной связи одно множество сущностей в действительности яв­ляется функцией двух других множеств.

Имеется в виду, что студия "studio2" заключает контракт со студией "studiol", огова­ривающий условия привлечения актера студии "studio 1" на съемки фильма "movie", который выпускается студией "studio2".

Стрелки, изображенные на рис. 6, характеризуют две роли киностудии, отно­сящейся к множеству сущностей Studios: "студия-владелец актера" (Studio-of-Star) и "студия-продюсер кинофильма" (Ptvducing-Studio). Доводы таковы. Для каждого определенного актера, фильма и студии, которая занимается съемкой этого фильма, существует только одна студия, "владеющая" актером. (Предполагается, что актер заключил долговременный кон­тракт только с одной студией.) Аналогич­но, конкретный фильм снимается только одной студией, так что обладая информа­цией об актере, фильме и студии, к кото­рой относится этот актер мы сможем определить уникальную сущность соответствующую студии,

	Рис. 6. Четырехсторонняя связь

 

 

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

Стрелок, которые были бы обращены к множествам Movies ("кинофильмы") и Stars ("актеры"), однако, не существует. Заданной тройке значений — имени актера и названиям студии-владельца и студии-продюсера — может соответствовать несколько контрактов, позволяющих актеру сниматься в различных фильмах. Поэтому такой набор данных кортежа не обязательно соответствует уникальному кинофильму. Аналогично, студия-продюсер вправе заключить контракт с другой студией на привлечение к съемкам фильма сразу нескольких актеров, так что имя актера в общем случае не может быть определено на основании данных трех других компонентов связи. □

Связи и атрибуты

Подчас бывает удобно или даже, как кажется, настоятельно необходимо ассоции­ровать атрибут со связью, а не с некоторым множеством сущностей, охватываемых этой связью. Вновь вернемся к примеру связи, показанной на рис. 4, ко­торая представляет множество контрактов между актерами и студиями.³ Пусть нам не­обходимо зафиксировать на диаграмме атрибут "размер заработной платы" (salary) ак­тера (Stars), установленный в соответствии с контрактом (Contracts). Мы не вправе связывать подобный атрибут непосредственно с актером: последний за участие в съем­ках различных фильмов может получать различные суммы вознаграждения. Исходя из подобных соображений, не имеет смысла ассоциировать атрибут "размер заработной платы" и с множествами сущностей "киностудии" (Studios) (студии по-разному оплачи­вают работу различных актеров) и "кинофильмы" (Movies) (различные актеры за уча­стие в съемках одного и того же фильма могут получать различную зарплату).

Однако уместно ассоциировать атрибут salary с кортежем

(star, movie, studio)

из множества данных, соответствующего связи Contracts. На рис. 7 приведена диа­грамма рис. 4, дополненная атрибутами множеств сущностей Movies, Stars и Studios (эти атрибуты приводились на рис. 2), а также атрибутом salary, соединенным со связью Contracts.

 

 

 

Рис. 7. Связь с атрибутом

 

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

³ Здесь мы рассматриваем исходную, тернарную, редакцию связи Contracts, соответствующую примеру 2.5 на с. 56, а не ее четырехстороннюю версию, упоминавшуюся в примере 2.7 на с. 58.

Пример 7. Давайте исправим ER-диаграмму рис. 7, на которой атрибутом salary ("размер заработной платы") снабжена связь Contracts ("контракты"). Создадим мно­жество сущностей Salaries ("заработная плата") с одноименным атрибутом salary. Salaries станет четвертым множеством сущностей, соединенным со связью Contracts. Результат показан на рис. 2.8.

 

10. Преобразование многосторонних связей в бинарные

Существуют некоторые модели представления данных, такие как язык ODL (Object Definition Language — язык определения объектов), которые ограничивают число "сторон", охватываемых связью, до двух, т.е. предполагают использование только бинарных связей (binary relationships). Поскольку ER-модели подобные ограничения не присущи, полезно знать о том, что любая связь, соединяющая более двух множеств сущностей, может быть преобразована в набор би­нарных связей типа "многие к одному" (many-one relationships). С этой целью вводится новое множество сущностей, элементы которого являются кортежами множества дан­ных для рассматриваемой многосторонней связи. Множество сущностей, подобное вводимому, называют соединяющим множеством сущностей (connecting entity set). За­тем в диаграмму включаются связи типа "многие к одному", "сплачивающие" соеди­няющее множество сущностей с каждым из множеств сущностей, элементы которых служат компонентами кортежей множества данных для исходной многосторонней связи. (Читатель, если вы это поняли, вы поймете и все остальное. — Прим. перев.) Если некоторое множество сущностей в контексте связи обладает несколькими роля­ми, каждая роль преобразуется отдельно.

 

 

Рис. 8. Передача атрибута связи множеству сущностей

Пример 8. Четырехсторонняя связь Contracts ("контракты"), изображенная на рис. 6, может быть заменена соединяющим множеством сущностей, кото­рое уместно назвать тем же именем, Contracts. Результат показан на рис. 9. Множество сущностей Contracts принимает участие в четырех связях. Если в составе множе­ства данных, соответствующего связи Contracts, имеется кортеж

(studio 1, studio2, star, movie),

можно считать, что множество сущностей Contracts содержит некоторую сущность е, соединенную связью Star-of с сущностью star множества сущностей Stars ("актеры"), связью Movie-of— с сущностью movie множества сущностей Movies ("кинофильмы"), а также с сущностями studio 1 и studio2 множества сущностей Studios ("киностудии") посредством связей Studio-of-Star и Producing-Studio соответственно.

Здесь мы подразумеваем, что соединяющее множество сущностей Contracts не со­держит атрибутов. Однако ничто не мешает снабдить подходящими атрибутами — например, таким как date-of-signing ("дата подписания") — и множество Contracts.

 

Подклассы в ER-модели

Нередки ситуации, когда множество сущностей содержит определенные сущности, которые обладают специальными свойствами, не присущими остальным членам мно­жества. В подобных случаях подчас оказывается полезным создавать специальные множества сущностей — или подклассы (subclasses) — каждое из которых обладает соб­ственными набором атрибутов и/или связями. Для соединения "полного" множества сущностей — базового класса (superclass) — с его подклассами используются связи, на­зываемые isa (от "is а" — есть) (например, утверждение "Л есть /?" выражает наличие связи isa₉ направленной от множества сущностей А к множеству сущностей В).

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

 

 

 

Рис. 9. Замена многосторонней связи со­единяющим множеством сущностей и набо­ром бинарных связей

 

Пример 9. В "кинематографической" базе данных, рассматриваемой нами, может храниться информация о фильмах, относящихся к различным жанрам: мультиплика­ция, "боевик", приключения, комедия и т.д. Для каждого из жанров вполне право­мерно определить соответствующий подкласс множества сущностей Movies ("кинофильмы"). Рассмотрим для примера два подкласса — Cartoons ("мультипликация") и Murder-Mysteries ("боевики"). Множество сущностей "мультипликация", помимо атрибутов и связей, унаследованных от базового класса "кинофильмы", участвует в дополнительной связи Voices ("голоса"), которая опреде­ляет подмножество актеров, участвовавших в озвучивании фильма, но не появляв­шихся на экране непосредственно. Фильмы, не относящиеся к жанру мультиплика­ции, не обладают подобной связью. Для кинофильмов-"боевиков" характерно нали­чие атрибута weapon ("оружие"). Взаимоотношения множеств сущностей Movies, Cartoons и Murder-Mysteries иллюстрируются диаграммой рис. 2.10.

К множеству сущностей

Stars

 

 

Рис. 10. Связи isaна ER-диаграмме

 

Хотя, вообще говоря, набор множеств сущностей, соединенных связями /sa, может обладать структурой любой топологии, мы сосредоточим внимание на гораздо более распространенных древовидных (tree-like) isa-структурах, обладающих одним корневым (root) множеством сущностей (таким как Movies на рис. 2.10), из которого "произрастают" и "ветвятся" множества более частного характера.

Рассмотрим дерево множеств сущностей, соединенных связями isa. Некоторая сущность состоит из компонентов (components), относящихся к одному или несколь­ким указанным множествам сущностей, если эти компоненты принадлежат поддереву (subtree) исходного дерева, включающему корневую вершину. Другими словами, если некоторая сущность е обладает компонентом с из множества сущностей Е и родитель­ским по отношению к Е в дереве является множество F, то е обладает также некото­рым компонентом d из F. Кроме того, с и d должны быть представлены в виде пары во множестве данных для связи isa, направленной от Е к F. Сущность е имеет те же атрибуты, которыми обладает любой из ее компонентов, и участвует в тех же связях, к которым имеет отношение любой из этих компонентов.

 

Пример 10. Обратимся к рис. 10. Сушность-"кинофильм", которая не относится ни к жанру мультипликации {Cartoons),, ни к числу "боевиков" (Murder-Mysteries), бу­дет обладать только таким компонентом, который принадлежит корневому множеству сущностей Movies ("кинофильмы"). Всем сущностям Movies поставлены в соответствие четыре атрибута (length ("продолжительность"), title ("название"), year ("год производ­ства") и filmType ("тип пленки")) и две связи (Stars-in ("актеры-участники") и Owns ("владеет") — последние на рис. 2.10 не показаны).

 

Различия параллельных связей

На рис. 10 иллюстрируется одна тонкая особенность ER-связей, требующая до­полнительного разъяснения. Диаграмма содержит две различные связи, Studio-of-Star ("студия-владелец актера") и Producing-Studio ("студия-продюсер кинофиль­ма"), и каждая из них соединяет одни и те же множества сущностей — Contracts ("контракты") и Studios ("киностудии"). Мы, однако, не вправе ожидать, что из факта "параллельности" связей следует идентичность множеств данных, соответ­ствующих этим связям. Действительно, в рассматриваемом здесь случае совершен­но неправомочно полагать, что обе связи представляют один и тот же "контракт", относящийся к некоторой сущности-"киностудии", поскольку иначе студия долж­на заключать контракт сама с собой.

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

Сущность-"мультфильм", не являющаяся "боевиком", обладает двумя компонен­тами, один из которых относится к множеству Movies, а другой — к Cartoons. Поэтому она получит не только четыре упомянутых выше атрибута множества Movies, но и связь Voices ("голоса"). Аналогичным образом, сущность-"боевик", не являющаяся "мультфильмом", также обладает двумя компонентами, один из которых относится к множеству Movies, а другой — к Murder-Mysteries, и поэтому характеризуется пятью атрибутами, включая weapon ("оружие").

Наконец, сущности-"кинофильмы" (подобные "Roger Rabbit"), которые относятся к жанрам мультипликации и "боевика" одновременно, обладают компонентами всех трех множеств — Movies, Cartoons и Murder-Mysteries. Компоненты соединяются в це­лостную сущность благодаря связям isa. Рассматриваемые совместно, эти компоненты поставят в соответствие тому же "Roger Rabbit" все четыре атрибута множества сущ­ностей Movies плюс атрибут weapon множества Murder-Mysteries плюс связь Voices мно­жества Cartoons.

 

Принципы проектирования

 

1. Достоверность

Прежде всего, проект обязан достоверно представлять спецификацию базы дан­ных. Другими словами, множества сущностей и их атрибуты должны соответствовать реальным требованиям. Вы не вправе, например, ассоциировать с множеством сущно­стей Stars ("актеры") атрибут number-of-cylinders ("количество цилиндров"), хотя по­следний вполне применим по отношению к множеству Automobiles ("автомобили"). Прежде чем вводить в модель новое множество сущностей, атрибут или связь, надле­жит задаться вопросом, а все ли доподлинно известно о той части реального мира, ко­торая должна быть смоделирована.

 

Пример 10. Если вновь присмотреться к связи Stars-in ("актеры-участники"), соеди­няющей множества сущностей Stars ("актеры") и Movies ("кинофильмы"), станет оче­видным, что она должна относиться к типу "многие ко многим". Причины бесспор­ны: здравый смысл, основанный на элементарном понимании моделируемых сущно­стей, подсказывает, что актеры вправе участвовать в съемках нескольких фильмов, а в каждом фильме могут быть заняты одновременно несколько актеров. Совершенно неправомерно считать, что связь Stars-in в любом направлении может представлять отношение "многие к одному" или, более того, "один к одному".

 

Пример 11. Подчас, однако, далеко не очевидно, как именно те или иные объекты реального мира должны соотноситься в рамках ER-модели. Рассмотрим для примера множества сущностей Courses ("учебные курсы") и Instructors ("преподаватели"), со­единенные связью Teaches ("обучает"). Действительно ли Teaches представляет связь типа "многие к одному" в направлении от Courses к Instructors! Ответ зависит от кор­поративной политики и традиций конкретного учебного заведения. Вполне возможно, что за каждым курсом закреплен в точности один преподаватель. Даже в том случае, если несколько преподавателей ведут курс совместно, не исключено, что в соответст­вии с внутренними требованиями организации в базе данных должен быть указан только один из преподавателей, "ответственный" за курс. В любом из подобных слу­чаев мы имеем право утверждать, что связь Teaches, соединяющая множества сущно­стей Courses и Instructors^ должна относиться к типу "многие к одному" (если рассмат­ривать ее в указанном направлении).

 

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

 

Отсутствие избыточности

Мы обязаны тщательно следить за тем, чтобы объекты структуры не повторяли друг друга. Пусть, например, сущности Movies ("кинофильмы") и Studios ("киностудии") соединены связью Owns ("владеет"). Мы можем также снабдить мно­жество сущностей Movies атрибутом studioName ("название студии"). Хотя такое реше­ние на первый взгляд вполне приемлемо, оно таит в себе ряд опасностей.

1. Повторение описания студии-владельца кинофильма приводит к дополнитель­ному расходу памяти при хранении атрибута в базе данных.

2. При продаже кинофильма мы можем изменить название студии, которая им владела, на новое, определяемое связью Owns, но забыть исправить содержимое атрибута studioName — или умудриться сделать наоборот. Конечно, можно ут­верждать, что подобные ошибки вряд ли вероятны, но на практике они, к не­счастью, случаются, и, пытаясь описать некий объект несколькими различными способами, мы заранее ставим себя, мягко говоря, в невыгодное положение.

 

 

Простота

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

Пример 12. Предположим, что вместо непосредственной связи между множествами сущностей Movies ("кинофильмы") и Studios ("киностудии") мы считаем целесообраз­ным использовать новое "промежуточное" множество сущностей Holdings ("права вла­дения"), описывающее факт принадлежности конкретного фильма определенной сту­дии. Между каждым фильмом и сущностью "права владения" может быть установлена связь Represents ("представляет") типа "один к одному". Общую картину, иллюстри­руемую рис. 11, завершает связь типа "многие к одному", соединяющая множества сущностей Holdings и Studios.

 

 

Рис. 11. Неудачный пример: в диаграмму включено избыточное множество сущностей

 

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

 

Выбор подходящих связей

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

 

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

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

Пример 2.15. Вернемся к диаграмме рис. 7, на которой множества сущно­стей Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии") соединены с помощью тернарной связи Contracts ("контракты"). Здесь опущены две бинарные связи, Stars-in ("актеры-участники") и Owns ("владеет"), введенные в диаграмму ра­нее, на рис. 2. Возникает закономерный вопрос, действительно ли связи Stars-in (между Movies и Stars) и Owns (между Movies и Studios) все еще необходимы при наличии связи Contracts? Ответ таков: "не известно; решение зависит от того, ка­кой смысл мы вкладываем в каждую из трех рассматриваемых связей".

Вполне возможно получить связь, аналогичную Stars-in, на основании связи Contracts. Если актер появляется в фильме только при наличии соответствующего кон­тракта, в котором упоминаются сам актер, студия и производимый ею фильм, тогда дей­ствительно необходимость в использовании связи Stars-in отпадает: для определения всех пар вида "актер—кинофильм" для заданных сущностей "актер" и "кинофильм" достаточно просмотреть кортежи "актер—кинофильм—киностудия" множества данных, отвечающего связи Contracts, и выбрать нужные, ограничившись компонентами "актер" и "кинофильм". Если, однако, актер может сниматься в фильме, не подписав кон­тракт — или, что более вероятно с практической точки зрения, не имея контракта, кото­рый был бы зафиксирован в нашей базе данных, — тогда во множестве данных связи Stars-in могут существовать такие пары вида "актер—кинофильм", которые не являются ча­стью кортежей "актер—кинофильм—киностудия" множества данных связи Contracts. В этой ситуации связь Stars-in обладает самостоятельным значением и должна быть сохранена.

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

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

Пример 2.16. Давайте вновь обратимся к диаграмме рис. 2. На ней нет ка­ких-либо прямых связей между множествами сущностей Stars ("актеры") и Studios ("киностудии"). Но мы можем получить необходимую соединяющую цепочку, ис­пользуя свойства связей Stars-in ("актеры-участники") и Owns ("владеет"), поскольку некоторый "актер" связан посредством Stars-in с определенными "кинофильмами", а те, в свою очередь, благодаря связи Owns соединены с соответствующими сущностями-"киностудиями". Таким образом, можно говорить, что актер связан со студией, владеющей фильмом, в котором этот актер снимался.

Имеет ли смысл включать в диаграмму дополнительную связь — что-то вроде Works-for ("работает" на киностудию) — между множествами сущностей Stars и Studios, как показано на рис. 12? И вновь, как и прежде, мы не можем ответить на этот вопрос однозначно, не обладая нужными сведениями. Самое главное, каково истинное назначение этой связи? Если ее смысл таков, что "актер снялся, по меньшей мере, в одном фильме, выпушенном студией", тогда, вероят­но, веских причин для использования подоб­ной связи нет, так как аналогичная информа­ция может быть получена на основе сущест­вующих связей, Stars-in и Owns.

Однако вполне вероятна ситуация, что име­ется некая иная информация (возможно, со­вершенно уникальная) об особенностях работы актеров со студиями, которая не отражена в цепочке связей Stars-in и Owns. В этом случае связь, соединяющая множества сущно­стей Stars и Studios напрямую, может оказаться полезной и не восприниматься как избыточ­ная. Например, такая связь должна представить тот факт, что актер связан со студией неким общим контрактом, который не имеет отношения к конкретному кинофильму. Кроме того, как мы упоминали в примере 7, отнюдь не невероятно, что актер, заключивший контракт с одной студией, принимает участие в фильме, выпускаемом другой студией. В подобных ситуациях новая связь Works-for никак не зависит от связей Stars-in и Owns и определенно не бу­дет считаться излишней.

 

 

Рис. 12 Включение в диаграмму дополнительной связи.

 

Использование элементов адекватных типов

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

 

Пример 2.17. Обратимся к рис.2 и рассмотрим одну частную проблему. На­сколько здравым было наше решение о представлении объектов "киностудия" отдель­ным множеством сущностей Studios? Может быть, следовало передать атрибуты "название студии" и "адрес студии" множеству сущностей Movies ("кинофильмы") и исключить Studios вовсе? Если поступить так, как мы сказали, придется повторять ад­рес студии в наборе данных о каждом кинофильме. Это еще один пример избыточности, подобный тем, которые упоминались в двух предыдущих разделах. Помимо издержек, связанных с избыточностью данных, мы столкнемся со следующей опасностью: если в базе данных будут отсутствовать сведения о каких бы то ни было фильмах, снятых определенной студией, информация об этой студии как таковой окажется утраченной.

С другой стороны, если потребность в хранении адреса студии не возникает, ника­кого вреда не принесет то, что наименование студии в качестве атрибута будет по­ставлено в соответствие каждому фильму. Теперь об избыточности из-за многократ­ного повторения адреса студии речь не идет, а то, что наименование студии, такое как, скажем, "Disney", указывается для каждого фильма, снятого этой студией, не может рассматриваться как излишняя информация, поскольку авторские права студии должны быть отражены так или иначе. □

Теперь попробуем абстрагировать выводы, к которым мы пришли, рассматри­вая пример 2.17, чтобы более строго описать обстоятельства, позволяющие пред­почесть атрибут множеству сущностей. Пусть £ — это некоторое множество сущ­ностей. Ниже перечислены условия, которым должно удовлетворять множество Е, чтобы его было целесообразно заменить атрибутом или набором атрибутов не­скольких других множеств сущностей.

1. Все связи, в которые вовлечено множество £, обладают стрелками, указываю­щими на Е. Другими словами, множеству Е должна отводиться роль компонен­та "один" во всех связях типа "многие к одному" или их обобщениях для слу­чаев многосторонних связей.

2. Атрибуты множества Е в совокупности обязаны однозначно определять любую сущность множества. Чаще всего имеется только один такой атрибут, и в этом случае условие определенно удовлетворяется. Если же множество обладает не­сколькими атрибутами, ни один из них не должен зависеть от остальных (таким образом, как, например, атрибут address ("адрес") множества сущностей Studios ("киностудии") зависит от атрибута пате ("название") того же множества).

3. Ни в одной из связей множество Е не должно участвовать многократно.

Если все указанные условия удовлетворены, множество сущностей Е может быть за­менено другими элементами одним из следующих способов:

a) если существует связь R типа "многие к одному", направленная от некото­рого множества сущностей F к множеству Е, следует удалить R и передать атрибуты Е множеству F, выполнив при необходимости их переименование, если F уже содержит атрибуты с теми же именами; в результате каждая сущ­ность множества F получит в качестве атрибута наименование уникальной связанной с ней сущности множества Е ⁴ (как, например, в случае, когда сущностям "кинофильм" передается атрибут "название студии", а атрибут "адрес студии" исключается).

b) если существует многосторонняя связь R, содержащая стрелку, направлен­ную к £, целесообразно передать атрибуты Е связи R и удалить стрелку, со­единяющую R с Е примером может служить возврат от диаграммы рис. 8, где было введено новое множество сущностей Salaries, к исход­ной версии диаграммы с аналогичным атрибутом salary, относящимся к элементу связи Contracts (см. рис. 7).

Пример 2.18. Проанализируем ситуацию, предполагающую выбор компромиссного решения — использовать многостороннюю связь или предпочесть соединяющее мно­жество сущностей и набор из нескольких бинарных связей. В разделе 2.1.8 на мы рассматривали четырехстороннюю связь Contracts ("контракты"), соединяющую сущ­ности "актер" (из множества Stars), "кинофильм" (Movies) и две сущности "киностудия" (Studios) (см. рис.6). На диаграмме рис. 9 в пре­дыдущем разделе эта структура была "механически" преобразована в одноименное со­единяющее множество сущностей Contracts с несколькими дополнительными бинар­ными связями. Возникает вопрос, насколько принципиален подобный выбор.

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

 

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

 

Чтобы модель адекватно описывала условия поставленной задачи, множество дан­ных связи Contracts должно состоять из кортежей вида

(star, movie, set-of-studios),

и связь Contracts как таковая будет охватывать не только привычные множества сущ­ностей Stars и Movies, но и новое множество сущностей, элементами которого являют­ся множества студий ("set-of-studios"). Хотя в рассматриваемой ситуации такого ре­зультата, как кажется, избежать нельзя, похоже, не совсем естественно воспринимать множества студий в виде элементарных сущностей, и поэтому мы не рекомендуем применять указанный подход.

Более предпочтительным представляется решение, в котором контракты описываются множеством сущностей. На диаграмме рис. 9 сущность "контракт" соединяет­ся с сущностями "актер", "кинофильм" и двумя сущностями "киностудия", но сейчас ог­раничение на количество киностудий, подписывающих контракт, должно быть снято. Связь между множествами Contracts и Studios приобретает свойство "многие ко многим", а не относится к типу "многие к одному", как в том случае, когда Contracts является "подлинным" соединяющим множеством сущностей. Новая версия диаграммы приве­дена на рис. 13. Еще раз подчеркнем, что теперь контракт соединяет по одной сущно­сти вида "актер" и "кинофильм" с произвольным числом сущностей "киностудия". □

 

 

Рис. 13. Контракт соединяет актера и кинофильм с произвольным множеством киностудий

 

Упражнения к разделу 2.2

Упражнение 2.2.1. На рис. 2.14 представлена диаграмма, описывающая структуру базы данных банка, в которой предусматривается хранение информации о клиен­тах {Customers) и их счетах {Accounts). Поскольку в общем случае клиент вправе от­крыть в банке несколько счетов, а счетом могут совместно распоряжаться несколь­ко клиентов, клиентам ставятся в соответствие "наборы счетов" (AcctSets), и каж­дый счет может быть членом (Member-of) одного или нескольких "наборов счетов". Мы полагаем, что смысл всех остальных связей и атрибутов, приведенных на диа­грамме, внятно определяется их названиями (owner-address — "адрес владельца", Has — "обладает", пате — "имя", number — "номер счета", balance — "размер ос­татка на счете", Lives-at — "проживает", Addresses — "адреса", address — "адрес"). Изучите схему и попытайтесь выдвинуть собственные критические замечания. Ка­кие правила проектирования, по вашему мнению, нарушены? Почему? Какие из­менения вы предложили бы внести?

Упражнение 2.2.2. При каких условиях два множества сущностей — Studios ("киностудии") и Presidents ("президенты") — и связь Runs ("возглавляет"), обра­зующие диаграмму рис. 3 (с учетом атрибутов, которые для краткости опущены), могут быть заменены единственным множеством сущностей с соответ­ствующими атрибутами?

Упражнение 2.2.3. Предположим, что атрибут address ("адрес") множества сущно­стей Studios ("киностудии") на диаграмме рис. 7 удален. Покажите, ка­ким образом множество Studios теперь может быть заменено некоторым атрибутом. Как именно следовало бы расположить этот атрибут?

 

 

Рис. 2.14. Неудачный пример: диаграмма банковской базы данных

 

Упражнение 2.2.4. Выберите атрибуты для перечисленных ниже множеств сущно­стей диаграммы рис. 2.13, что позволит заменить каждое из этих множеств некото­рым атрибутом:

a) Stars ("актеры");

b) Movies ("кинофильмы");

c) ! Studios ("киностудии").

Упражнение 2.2.5. В этом и следующих примерах мы рассмотрим два альтернативных проектных решения, касающихся возможности описания события рождения челове­ка. С фактом рождения связана одна сущность "младенец" (событие рождения близ­нецов может быть отображено набором отдельных кортежей данных), сущность "мать" и произвольные наборы сущностей "медсестра" и "врач". Предположим да­лее, что имеются множества сущностей Babies ("младенцы"), Mothers ("матери"), Nurses ("медсестры") и Doctors ("врачи"), а также связь Births ("роды"), соединяющая названные множества сущностей так, как показано на диаграмме рис. 2.15. При­мите к сведению, что кортеж множества данных связи Births имеет следующий вид:

(baby, mother, nurse, doctor).

Если родовспоможением занимается более одной медсестры и/или врача, будут су­ществовать несколько кортежей для одних и тех же компонентов данных "младенец"

("baby") и "мать" ("mother") — по одному на каждую комбинацию компонентов "медсестра" ("nurse") и "врач" ("doctor").

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

 

Рис. 15. Представление события "ро­ды " с помощью многосторонней связи

 

а) Каждой сущности "младенец" соответ­ствует уникальная сущность "мать".

b) Каждому сочетанию сущностей "младенец", "медсестра" и "доктор" соот­ветствует уникальная сущность "мать".

 

Рис. 16. Представление события "роды" посредством множества сущностей

 

с) Каждой комбинации сущностей "младенец" и "мать" соответствует уни­кальная сущность "доктор".

Упражнение 2.2.6. Другой подход к решению проблемы, описанной в упражнении 2.2.5, состоит в соединении множеств сущностей Babies ("младенцы"), Mothers ("матери"), Nurses ("медсестры") и Doctors ("врачи") с множеством сущностей Births ("роды") посредством четырех отдельных связей, как показано на рис. 2.16. Используя стрелки (с целью констатации, что соответствующая связь относится к типу "многие к одному"), обеспечьте реализацию следующих условий:

d) каждая сущность "младенец" связана с уникальной сущностью "роды" и каждая сущность "роды" связана с уникальной сущностью "младенец";

e) в дополнение к условию (а), каждой сущности "младенец" соответствует уникальная сущность "мать";

f) в дополнение к условиям (а) и (Ь), каждой сущности "роды" соответствует уникальная сущность "врач".

Какие ошибки дизайна вы можете назвать в каждом из случаев?

Упражнение 2.2.7. Изменим постановку задачи, добавив требование о том, что модель должна отображать факт рождения близнецов непосредственно, а не в виде набора кортежей, по одному на каждую сущность "младенец". Каким об­разом представить условие, что каждой сущности "младенец" соответствует уникальная сущность "мать", используя подходы, рассмотренные в упражне­ниях 2.2.5 и 2.2.6?

 

2.3. Моделирование ограничений

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

Классификация ограничений

Следующий перечень представляет некую грубую классификацию наиболее рас­пространенных ограничений. В этом разделе мы не намереваемся давать их исчерпы­вающее описание. Дополнительный материал, касающийся ограничений, изложен в разделе 5.5 на с. 241 в терминах реляционной алгебры, а в главе 7 на с. 317 — в кон­тексте модели программирования на языке SQL.

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

2. Ограничение уникальности (single-value constraint): определенное значение в не­котором контексте должно быть уникальным. Ключи — это основной "постав­щик" ограничений уникальности, поскольку наличие ключа предполагает, что каждая сущность во множестве сущностей обладает уникальными значениями ат­рибутов, в совокупности образующих ключ. Есть и другие источники, "порож­дающие" ограничения уникальности, — например, связи типа "многие к одному".

3. Ограничение уникальности (single-value constraint): определенное значение в не­котором контексте должно быть уникальным. Ключи — это основной "постав-шик" ограничений уникальности, поскольку наличие ключа предполагает, что каждая сущность во множестве сущностей обладает уникальными значениями ат­рибутов, в совокупности образующих ключ. Есть и другие источники, "порож­дающие" ограничения уникальности, — например, связи типа "многие к одному".

4. Ограничение ссылочной целостности (referential integrity constraint): некоторое значение, на которое ссылается другой объект, должно существовать в базе данных. Ограничение ссылочной целостности аналогично запрету на использо­вание в обычных программах "висящих" указателей или иных элементов, ссы­лающихся на нечто отсутствующее.

5. Ограничение домена (domain constraint): значение атрибута должно выбираться из некоего конечного множества значений или принадлежать определенному диапазону изменения.

6. Ограничение общего вида (general constraint): произвольное требование, которое должно быть зафиксировано в базе данных, — например, такое как "каждой сущности кинофильм должно быть поставлено в соответствие не более десяти сущностей актер".

 

Назовем несколько причин, обусловливающих важность механизма задания огра­ничений в рамках модели базы данных. Ограничения дают возможность выразить не­которые особые свойства моделируемых сущностей реального мира. Так, например, ключи позволяют однозначно распознавать элементы множества однородных сущно­стей. Если, скажем, мы знаем, что атрибут пате ("название") служит ключом для множества сущностей Studios ("киностудии"), тогда при обращении к сущности "киностудия" по ее названию обеспечиваются гарантии выбора уникального элемента множества. Помимо того, при сохранении уникального значения экономятся время и дисковое пространство; отдельное значение занести в базу данных проще, нежели множество значений — даже в том случае, если множество состоит из единственного члена.⁵ Применение ключей и ограничений ссылочной целостности также способству­ет оптимизации структур данных, что приводит к увеличению скорости доступа к ин­формации (об этом мы расскажем в главе 13 на с. 583).

 

2.3.2. Ключи и ER-моделирование

Говоря более строго, ключ (key) для множества сущностей Е — это множество К, состоящее из одного или более атрибутов множества Я, такое, что при выборе из Е любых двух различных сущностей е_х и е₂ последние не могут обладать одинаковыми значениями атрибутов, относящихся к множеству К. Если К состоит из нескольких элементов, допустимо равенство отдельных, но не всех, атрибутов сущностей е_х и е_г. Надлежит запомнить важные положения, перечисленные ниже.

Каждое множество сущностей должно обладать определенным ключом.

Ключ может состоять более чем из одного атрибута (соответствующая иллюст­рация приведена в примере 2.19).

Для каждого множества сущностей допускается наличие нескольких ключей (мы обсудим подобную ситуацию в примере 2.20). Целесообразно, однако, вы­брать один их них в качестве "первичного ключа" (primary key) и далее обра­щаться с множеством таким образом, словно оно обладает единственным ключом.

Если некоторое множество сущностей вовлечено в иерархию связей isa₉ следует обеспечить, чтобы корневое множество сущностей обладало всеми атрибутами, необходимыми для формирования ключа, и ключ для каждой сущности мог быть найден на основе ее компонентов, относящихся к корневому множеству сущностей, — независимо от того, какое число множеств, участвующих в ие­рархии, располагает соответствующими компонентами.

Пример 2.19. Рассмотрим множество сущностей Movies ("кинофильмы"). На первый взгляд, на роль ключа подходит атрибут title ("название"). Однако нетрудно привести целый ряд примеров названий, которые употреблялись для обозначения двух и более различных кинофильмов (скажем, "King Kong"). Поэтому выбор атрибута title в каче­стве самодостаточного ключа — это, очевидно, не самое дальновидное решение. Если все же поступить именно так, в дальнейшем мы не сможем различить в базе данных те кинофильмы, которые волею случая получили одно и то же название.

Более уместно создать ключ на основе двух атрибутов — title и year ("год производ­ства"). Разумеется, вероятность выхода в одном и том же году двух кинофильмов с одинаковым названием (в базе данных нельзя будет представить сведения об одном и другом одновременно) все еще существует, но она, надо признать, довольно мала.

Решение о выборе ключей для двух других основных множеств сущностей, пред­ставляющих рассматриваемую нами "кинематографическую" базу данных, должно быть не менее взвешенным. Функции ключа для множества сущностей Studios ("киностудии") имеет смысл возложить на атрибут пате ("название"), поскольку двух студий с одинаковым названием определенно быть не может. Однако столь же катего­рично утверждать, что сущность "актер" однозначно определяется атрибутом "имя", мы бы не стали, поскольку различить людей только по имени-фамилии в общем слу­чае нельзя. Впрочем, актеры довольно часто выбирают для себя броские "сценические" псевдонимы, поэтому атрибут пате ("имя") может рассматриваться как претендент на роль ключа множества сущностей Stars ("актеры"). Более универсальным, однако, могло бы оказаться решение, предполагающее создание ключа на основе пары атрибутов, пате и address ("адрес"), — если, конечно, вы не столкнетесь с тем редким случаем, когда два актера с одинаковым именем проживают по одному и тому же адресу. □

 

⁵ Аналогично, в программе на языке С, например, гораздо проще представить отдельное це­лочисленное значение, чем связанный список таких значений, пусть даже этот список состоит из единственного элемента.

 

Ограничения как часть схемы базы данных

При изучении содержимого некоторой базы данных легко впасть в заблуждение и принять решение о выборе ключевых атрибутов лишь на том, довольно зыбком, основании, что в данный момент времени никакие из сущностей рассматриваемого множества не обладают одинаковыми значениями этих атрибутов (скажем, в базу данных до сих пор не заносились сведения о кинофильмах с одинаковыми назва­ниями). Таким образом, для множества сущностей Movies ("кинофильмы") ключ может быть ошибочно сформирован, например, из единственного атрибута title ("название"). К чему это способно привести, подробно пояснять, вероятно, не нужно: если база данных проектируется с учетом того, что title является уникаль­ным ключом множества сущностей Movies, в дальнейшем в нее нельзя будет внести информацию о нескольких одноименных кинофильмах (таких как "King Kong").

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

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

 

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

В США является нормой, когда каждый сотрудник компании обладает также соб­ственным номером полиса социального страхования (Social Security number). Если в базе данных предусмотрен соответствующий атрибут для отображения номера полиса социального страхования служащих, он также вполне пригоден для использования в качестве ключевого. Заметим, что в наличии нескольких альтернативных вариантов ключей для одного и того же множества сущностей — например, самостоятельных ключевых атрибутов идентификационного кода и номера полиса социального страхо­вания служащих — нет ничего предосудительного.

Практика создания специальных атрибутов, единственным назначением которых является поддержка ключевых признаков сущности во множестве однородных сущно­стей, достаточно распространена. Аналогично идентификаторам служащих, во многих университетах каждому студенту также присваивают уникальный идентификационный код. В базах данных Государственной автомобильной инспекции в качестве ключевых атрибутов множеств сущностей, представляющих сведения о водителях и транспорт­ных средствах, используются, соответственно, номера водительских удостоверений и регистрационные номера транспортных средств. Любой читатель при желании сможет привести и другие примеры определения специальных атрибутов, предназначенных для использования в качестве ключевых.

2.3.3. Представление ключей в ER-модели

Используемая нами система обозначений предусматривает, что атрибуты множеств сущностей, объявленные как ключевые, на ER-диаграмме выделяются подчеркиванием. На рис. 17 воспроизведена диаграмма рис.2, которая отображает струк­туру базы данных, содержащей сведения о кинофильмах (Movies), киностудиях (Studios) и актерах (Stars). Ключевые атрибуты названных множеств сущностей подчерк­нуты. В качестве ключевых атрибутов для множеств Stars и Studios выбраны атрибуты пате ("имя" или "название") — это решение мы обсуждали в примере 19.

 

Рис. 17. На ER-диаграмме атрибуты-ключи отмечаются под­черкиванием

 

Ключ для множества сущностей Movies сформирован на основе совокупности ат­рибутов title ("название") и year ("год производства"). Атрибуты, наименования кото­рых подчеркнуты, являются членами ключа. Для описания ситуации, когда множество сущностей снабжено несколькими альтернативными ключами, специальных обозна­чений, однако, не существует; мы подчеркиваем только первичные ключи (primary keys). Следует упомянуть и тот довольно необычный случай, когда атрибуты, обра­зующие ключ для некоторого множества сущностей, не обязательно принадлежат это­му множеству (подобные вопросы, имеющие отношение к так называемым слабым множествам сущностей (weak entity sets), мы обсудим в разделе 2.4).

 

2.3.4. Ограничения уникальности

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

Существует несколько ситуаций, в которых ограничения уникальности (single-value constraints) проявляют себя в рамках ER-модели.

1. Некоторый атрибут множества сущностей обладает единственным значением. Иногда допускается отсутствие значения атрибута для отдельных сущностей мно­жества, и в подобных случаях приходится "изобретать" какое-то "нулевое" значе­ние, используемое по умолчанию. Для примера можно представить ситуацию, когда для некоторых кинофильмов, сведения о которых занесены в базу данных, информация о продолжительности их воспроизведения неизвестна. Значением атрибута length в таком случае могло бы быть, скажем, — I. С другой стороны, допускать отсутствие значений ключевых атрибутов, таких как title ("название") и year ("год производства"), нельзя. Требование о том, что некоторый атрибут не может иметь неопределенных значений вида null, в ER-модели не имеет специальных средств представления. Если необходимо описать подобное огра­ничение, можно снабдить атрибут дополнительным текстовым пояснением.

2. Связь R типа "многие к одному", соединяющая множества сущностей Е и F в направлении от Е к F, подразумевает наличие ограничения уникальности. Другими словами, для каждой сущности е множества Е имеется не более одной связанной с ней сущности / множества F. Или, в общем случае, если R пред­ставляет собой многостороннюю связь, тогда каждая из стрелок, "выходящая" из Я, выражает ограничение уникальности. В частности, если существует стрел­ка, соединяющая связь R с множеством сущностей £, в составе Е имеется не более одной сущности, ассоциированной с определенным набором сущностей из всех остальных множеств, охватываемых связью R.

 

2.3.5. Ограничения ссылочной целостности

Если ограничения уникальности (single-value constraints) декларируют возможность существования не более одного значения, выступающего в определенной роли, огра­ничения ссылочной целостности (referential integrity constraints) подразумевают наличие в точности одного такого значения. Требование о том, чтобы атрибут обладал единст­венным возможным значением, отличным от null, можно рассматривать как разно­видность ограничений ссылочной целостности, но чаше последние используются для описания свойств связей между множествами сущностей.

Рассмотрим связь Owns ("владеет"), соединяющую множества сущностей Movies ("кинофильмы") и Studios ("киностудии") так, как показано на рис. 2.2. Связь Owns относится к типу "многие к одному" и предполагает только то, что ни один из кинофильмов не может принадлежать нескольким студиям одновременно. Связь — в том виде, как она задана — отнюдь не подразумевает, что кинофильмом определенно должна владеть какая-либо студия, а если это даже и так, студия вовсе не обязана быть представлена во множестве сущностей Studios.

Ограничение ссылочной целостности в контексте связи Owns предусматривает, что для каждой сущности "кинофильм" в базе данных должна присутствовать соответст­вующая сущность "киностудия", на которую "кинофильм" ссылается. Существует не­сколько способов поддержки условий ссылочной целостности. Мы рассмотрим их ниже на примере связи Owns.

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

2. Следует запретить удаление сущностей множества Studios, адресуемых сущно­стями множества Movies. Другими словами, некоторая сущность "киностудия" не может быть удалена до тех пор, пока имеются сущности "кинофильм", ко­торые на нее ссылаются.

3. Если сущность множества Studios подлежит принудительному удалению, должны быть удалены также все сущности множества Movies, ссылающиеся на нее.

Аспекты практической реализации ограничений ссылочной целостности относятся к компетенции определенной СУБД или конкретного проекта базы данных, поэтому здесь мы не будем останавливаться на них подробно.

2.3.6. Ссылочная целостность и ER-диаграммы

Правила применения стрелок в ER-диаграммах могут быть расширены с целью обеспечения возможности отображения ограничений ссылочной целостности связей в одном или нескольких направлениях. Предположим, что R — это связь, соединяю­щая множества сущностей Е и F в направлении от Е к F. Тогда полукруглая стрелка, указывающая на F, не только свидетельствует о том, что связь, соединяющая множе­ства Е и F, относится к типу "многие к одному" или "один к одному", но и отобража­ет требование обязательного наличия в F сущности, на которую ссылается определен­ная сущность из Е. Те же соображения применимы и к случаю, когда R соединяет ме­жду собой более двух множеств сущностей.

Пример 2.21.На рис. 18 обозначены несколько ограничений ссылочной целостно­сти, заданных для связей Owns ("владеет") и Runs ("возглавляет"), которые соединяют множества сущностей Movies ("кинофильмы"), Studios ("киностудии") и Presidents ("президенты"). Названные связи и множества сущностей были впервые введены на диаграммах рис. 2 и 3. Полукруглая стрелка, соединяющая связь Owns с множеством сущностей Studios, выражает ограничение ссылочной цело­стности, которое подразумевает, что каждым кинофильмом должна владеть одна определенная студия и соответствующая сущность "киностудия" обязана присутст­вовать в составе множества Studios.

 

 

Рис. 18. ER-диаграмма с обозначениями ограничений ссылочной целостности

 

Аналогично, полукруглая стрелка, указывающая на множество Studios со стороны свя­зи Runs, обозначает ограничение ссылочной целостности, которое заключается в том, что каждый президент возглавляет одну студию и соответствующая сущность "киностудия" должна наличествовать во множестве Studios.

Обратите внимание, связь Runs по-прежнему соединена с множеством сущностей Presidents обычной (а не полукруглой) стрелкой, поскольку она отображает вполне ес­тественную закономерность взаимоотношений сущностей "президент" и "киносту­дия". Если студия прекращает свое существование, ее президент более не может за­нимать свой пост, и поэтому резонно ожидать, что соответствующая сущность "президент" должна быть удалена из множества Presidents; здесь проявляет себя огра­ничение ссылочной целостности. С другой стороны, удаление сущности "президент", как подсказывает здравый смысл, не должно оказывать влияния на содержимое мно­жества Studios, поскольку в какие-то периоды времени студия может обходиться без руководителя. Поэтому связь Runs и множество сущностей Presidents соединены обыч­ной стрелкой: каждая студия может возглавляться не более чем одним президентом, а в каких-то случаях президента может не быть вовсе.

 

2.3.7. Ограничения других видов

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

Ограничения домена (domain constraints) предполагают, что значения атрибута должны выбираться из определенного конечного множества или принадлежать огра­ниченному диапазону изменения. Простой пример использования ограничений доме­на связан с объявлением типа атрибута. Более строгое ограничение предусматривает определение некоторого перечислимого типа атрибута либо диапазона значений. Так, например, значение атрибута length ("продолжительность") множества сущностей Movies было бы уместно задавать в виде целого числа, выраженного в минутах и при­надлежащего интервалу от 0 до 240. ER-модель не содержит специальных выразитель­ных средств, позволяющих описать ограничения домена, но не запрещает размещать на диаграмме вместе с атрибутом необходимые текстовые примечания.

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

 

Рис. 19. Так обозначается ограничение на количество сущностей- "актеров", свя­занных с определенной сущностью- "кино­фильмом "

 

Пример 2.22.На рис. 19 показан пример ограничения на число сущностей множест­ва Stars ("актеры"), связанных с определенной сущностью множества Movies ("кинофильмы"). Развивая мысль, мы могли бы сказать, что обычная стрелка между связью типа "... к одному" и множеством сущностей равнозначна ограничению вида "<= 1", а полукруглая стрелка, применяемая для обозначения условий ссылочной целостности, — ограничению "= 1". □

Упражнение 2.3.2.Вполне допустимо представить, что связи в ER-модели способ­ны обладать ключами точно так же, как и множества сущностей. Пусть R является связью, соединяющей множества сущностей Е₁ Е₂,Е_п. Тогда ключ для R — это множество К атрибутов, выбранных из наборов атрибутов множеств Е₁ Е₂ Е_п таким образом, что если (е₁е₂, ...,е_п) и (ƒ₁ƒ₂, ...,ƒ_п) представляют собой два различных корте­жа множества данных связи /?, то совпадение этих кортежей во всех атрибутах К не­возможно. Пусть также для каждого i K_i представляет множество атрибутов, служа­щих ключами множества сущностей Еi. Теперь предположим, что n = 2, т.е. R являет­ся бинарной связью. Создайте наименьший возможный ключ для R при условии, что

a) R относится к типу "многие ко многим";

* b) R представляет связь типа "многие к одному" от Е₁ к Е₂

c) R представляет связь типа "многие к одному" от Е₂ к Е₁

d) R относится к типу "один к одному".

Упражнение 2.3-3. Вновь рассмотрим задание упражнения 2.3.2, но теперь позволим параметру n принимать произвольные значения, а не только значение 2. Об­ладая информацией о том, какие линии от R к E_i снабжены стрелками, покажите каким образом найти наименьший возможный ключ К для R в терминах К_i.

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

 

2.4. Слабые множества сущностей

Изредка обстоятельства складываются так, что ключ для некоторого множества сущ­ностей (его называют слабым — weak entity set) приходится формировать на основе атри­бутов, которые полностью или частично принадлежат другому множеству сущностей.

 

2.4.1. Примеры использования слабых множеств сущностей

Существуют два основных источника, порождающих необходимость использования слабых множеств сущностей. Во-первых, иногда множества сущностей участвуют в иерархии, построенной на принципах, не имеющих отношения к связям isa. Если сущности множества Е представляют собой единицы более "крупных" сущностей множества F, вполне вероятна ситуация, когда атрибуты сущ­ностей E, претендующие на роль ключевых, не будут обладать свойством уникально­сти до тех пор, пока во внимание не приняты атрибуты сущностей F, которым "подчиняются" сущности Е. Проблема иллюстрируется несколькими примерами.

 

Пример 2.23.Киностудия может состоять из нескольких творческих объединений. Пусть объединениям (назовем их Crews) в рамках киностудии даны условные назва­ния, такие как, скажем, "crew 1","crew 2"и т.д. Но в другой киностудии для нумера­ции объединений может быть принята совершенно такая же схема, так что атрибут number ("номер") уже нельзя считать ключевым. Чтобы обеспечить уникальность на­звания объединения среди подразделений всех киностудий, необходимо, наряду с его номером, учесть и наименование (пате) студии, которой это объединение принадле­жит. Ситуация смоделирована на рис.20.Ключом для слабого множества сущностей Crews служит совокупность двух атрибутов — собственного атрибута number множества Crews и атрибута пате уникальной сущности-"киностудии", с которой сущность-"объединение" соотносится посредством связи Unit-of ("подразделение").⁶ □

 

Рис. 2.20. Так отображаются слабые множества сущностей и соответствующие связи

 

⁶ Правила употребления в ER-диаграммах двойных прямоугольников и ромбов разъяснены в разделе 2.4.3

 

 

Пример 2.24. Биологический вид принято обозначать совокупностью имен рода, к кото­рому принадлежит этот вид, и собственного имени вида. Например, человек как био­логическое существо относится к виду Homo sapiens,где Homo("человек") — название рода, a sapiens("разумный") — название вида. Род в общем случае состоит из несколь­ких видов, и полное наименование каждого из них включает название рода и уточня­ется названием вида. Названия видов, рассматриваемые отдельно, к сожалению, не уникальны. В составе двух или нескольких родов могут встретиться виды с одинако­выми собственными названиями. Поэтому для обеспечения уникальности сущности "вид" во множестве сущностей Species("биологические виды") необходимо пользовать­ся полными именами видов, состоящими из собственного имени вида и названия соот­ветствующей сущности "род" из множества сущностей Genera("биологические роды"), с которой "вид" соединен связью Belongs-to("принадлежит"). Таким об­разом, Species— это слабое множество сущностей, в состав ключа которого введен атри­бут множества Genera,находящегося на более "высокой" ступени иерархии.

 

Пример 2.24. Биологический вид принято обозначать совокупностью имен рода, к кото­рому принадлежит этот вид, и собственного имени вида. Например, человек как био­логическое существо относится к виду Homo sapiens, где Homo ("человек") — название рода, a sapiens ("разумный") — название вида. Род в общем случае состоит из несколь­ких видов, и полное наименование каждого из них включает название рода и уточня­ется названием вида. Названия видов, рассматриваемые отдельно, к сожалению, не уникальны. В составе двух или нескольких родов могут встретиться виды с одинако­выми собственными названиями. Поэтому для обеспечения уникальности сущности "вид" во множестве сущностей Species ("биологические виды") необходимо пользовать­ся полными именами видов, состоящими из собственного имени вида и названия соот­ветствующей сущности "род" из множества сущностей Genera ("биологические роды"), с которой "вид" соединен связью Belongs-to ("принадлежит") (см. рис. 21). Таким об­разом, Species — это слабое множество сущностей, в состав ключа которого введен атри­бут множества Genera, находящегося на более "высокой" ступени иерархии. □

 

 

Рис. 21. Еще одна ER-диаграмма, представляющая слабое множество сущностей

Другая причина применения слабых множеств сущностей связана с механизмом соединяющих множеств сущностей (connecting entity sets), который позволяет преобразовать ER-диаграмму, устраняя многосторонние связи.⁷ Соединяющие множества сущностей зачастую не содержат собственных атрибутов, поэтому ключи для таких множеств формируются на основе ключевых атрибутов других, связанных с ними множеств.

Пример 2.25. На рис. 22 изображено соединяющее множество сущностей Contracts ("контракты"), заменяющее собой одноименную тернарную связь, которая была рассмотрена в примере 2.5. Множество Contracts обладает собственным ат­рибутом salary ("размер заработной платы"), который, однако, не участвует в фор­мировании ключа. Уникальная сущность "контракт" определяется совокупностью значений ключевых атрибутов пате ("имя" или "название") множеств Stars ("актеры") и Studios ("киностудии"), а также title ("название") и year ("год произ­водства") множества Movies ("кинофильмы"). □

 

2.4.2. Требования к слабым множествам сущностей

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

1) подмножества (возможно, пустого) собственных атрибутов;

ключевых атрибутов множеств сущностей, которые могут быть достигнуты по­средством цепочки связей типа "многие к одному", соединяющих множество Е с другими множествами; подобные связи принято называть поддерживающими связями (supporting relationships) для множества Е

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

 

 

 

 

Рис. 2.22. Соединяющие множества сущностей "слабы"

 

 

Чтобы некоторую связь R типа "многие к одному", соединяющую множества сущно­стей Е и F в направлении от Е к F, можно было отнести к числу поддерживающих связей для множества Е, должны выполняться условия, перечисленные ниже.

1. Связь R должна быть бинарной связью типа "многие к одному"⁸, направлен­ной от Е к F.

2. Связь R обязана предусматривать реализацию ограничения ссылочной целост­ности в направлении от Е к F. Другими словами, для каждой Е-сущности следу­ет обеспечить наличие в базе данных соответствующей F-сущности, с которой -сущность соотносится посредством связи R, т.е. присутствие на диаграмме по­лукруглой стрелки, соединяющей R с F, должно быть подтверждено фактически.

3. Атрибуты, предоставляемые множеством F для образования ключа множества Е, должны быть ключевыми для F.

4. Если F, в свою очередь, также является слабым множеством сущностей, тогда некоторые или все ключевые атрибуты, поставляемые множеству £*, должны быть ключевыми атрибутами одного или нескольких множеств сущностей G, с которыми множество F соединено посредством поддерживающих связей. Если и G относится к числу слабых множеств, ключевые атрибуты по цепочке связей заимствуются у других множеств и т.д.

Если существует несколько различных поддерживающих связей, направленных со стороны Е к F, каждая связь для формирования ключа множества Е поставляет собственную копию ключевых атрибутов множества F. Заметим, что некоторая сущность е множества Е может быть связана с несколькими различными сущно­стями множества F посредством различных поддерживающих связей, направленных от Е к F. Таким образом, сущность е множества Е может определяться ключевы­ми значениями, полученными от нескольких различных сущностей множества F.

Заметим, что связь "один к одному" является частным случаем связи типа "многие к од­ному". Когда мы говорим о том, что некоторая связь должна относиться к типу "многие к од­ному", мы подразумеваем и равную возможность существования связи "один к одному".

Интуитивные доводы в пользу необходимости принятия названных условий тако­вы. Рассмотрим некоторую сущность, принадлежащую слабому множеству сущностей, такому как, скажем, Crews ("объединения") (см. пример 23). Каждая сущ­ность "объединение" должна быть уникальной, чтобы ее можно было отличить от другой даже в том случае, если "объединения" обладают одним порядковым номером, но относятся к разным "киностудиям". Одного номера для решения задачи, однако, не достаточно. Следует провести поиск дополнительных значений, способных обеспе­чить уникальность сущностей множества Crews. К числу уникальных значений, тем или иным образом связанных с сущностями "объединение", относятся:

1) значения атрибутов самого множества Crews;

2) значения, которые можно получить на основе связей множества Crews с други­ми множествами; каждая подобная связь должна относиться к типу "многие к одному" (или, в частном случае, "один к одному") и соединять множество Crews с некоторым множеством F, а заимствованные множеством Crews атрибу­ты обязаны участвовать в образовании ключа множества F.

Система обозначений слабых множеств сущностей

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

1. Если множество сущностей является слабым, его принято изображать в виде двойного прямоугольника. Примерами могут служить множества сущно­стей Crews ("объединения") (см. рис. 20) и Contracts ("контракты") (см. рис. 22).

2. Поддерживающие связи типа "многие к одному" для слабых множеств сущностей обозначают двойными ромбами. В качестве примеров можно упомянуть связь Unit-of ("подразделение") (см. рис. 20) и все три связи диаграммы рис. 22.

3. Если в формировании ключа слабого множества сущностей участвуют его соб­ственные атрибуты, их наименования подчеркиваются. На диаграмме рис. 20 атрибут number ("номер") является частью ключа множества сущностей Crews, хотя этим состав ключа не исчерпывается.

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

• "Если множество Е на диаграмме обозначено двойным прямоугольником, оно является слабым. Атрибуты множества £, отмеченные подчеркиванием (если та­ковые есть), в совокупности с ключевыми атрибутами тех множеств сущностей, с которыми Е соединено посредством связей типа "многие к одному", обозна­ченных двойными ромбами, образуют ключ множества Е

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

Пример 2.26. Изображенную на ER-диаграмме рис. 22 связь Studio-of не обязательно следует считать поддерживающей связью для множества сущностей Contracts ("контракты"), поскольку каждой сущности "кинофильм" соответствует строго определенная сущность "киностудия", определяемая не показанной здесь свя­зью Owns ("владеет"), которая соединяет множества сущностей Movies ("кино­фильмы") и Studios ("киностудии"). Поэтому для каждой конкретной пары сущностей "актер—кинофильм" существует не более одного контракта с любой студией, оговари­вающего условия участия актера в съемках фильма, и для обозначения связи Studio-of более уместно было бы вместо двойного ромба использовать обычный, одинарный. □

 

2.4.4. Упражнения

* Упражнение 2.4.1.Один из способов представления сведений о студентах и оцен­ках, полученных ими по завершении изучения тех или иных курсов, связан с соз­данием множеств сущностей "студенты", "курсы" и "регистрационные записи". Сущности "регистрационные записи" формируют множество, "соединяющее" множества "студенты" и "курсы", которое может быть использовано не только для регистрации того факта, что определенный студент сдал экзамен по конкретному курсу, но и для хранения данных о полученных студентами оценках. Начертите ER-диаграмму, представляющую описанную ситуацию, и отметьте на ней слабые множества сущностей и ключи для всех множеств. Является ли атрибут "оценка" частью ключа для множества сущностей "регистрационные записи"?

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

 

Упражнение 2.4.3. Обратившись к ER-диаграммам, представляющим решения за­даний упражнения 2.2.6 (а)—(с), отметьте слабые множества сущностей, поддерживающие связи и ключи.

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

а) Даны множества сущностей Courses ("курсы") и Departments ("факультеты"). Каждый курс читается на строго определенном факультете, но обладает единственным атрибутом number ("номер"). Различные факультеты вправе предлагать курсы с одинаковыми номерами. Каждому факультету соответст­вует уникальное значение атрибута пате ("название").

b) Даны множества сущностей Leagues ("лиги"), Teams ("команды") и Players ("игроки"). Лиги обладают уникальными названиями. В составе лиги нет двух команд с одинаковыми наименованиями, а в команде — игроков с од­ним и тем же номером. Однако в пределах нескольких команд могут совпа­дать номера игроков, а в нескольких лигах допускается наличие команд с одинаковыми наименованиями.

2.5. Резюме

♦ Модель "сущность—связь ", или ER-модель, используется для представления мно­жеств сущностей, связей между ними, а также атрибутов множеств и связей.

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

♦ Множественность связей. Бинарные связи могут относиться к типам "один к одному", "многие к одному" или "многие ко многим". Связь "один к одно­му" соединяет некоторую сущность множества не более чем с одной сущностью другого множества. Связь "многие к одному" соединяет любую сущность мно­жества, указанного на стороне "многие", не более чем с одной сущностью множества, заданного на противоположной стороне соединения. Связи типа многие ко многим" не ограничивают свойство множественности взаимоотно­шений соединяемых множеств сущностей.

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

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

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

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

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