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

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