Ограничения это часть схемы

Можно подумать, что БД существует только определенное время, и оши- бочно рещеть, что атрйб)т явл.чется ключом, так как никакие два объекта ие t имеют идентичных значений этого атрибута. Например, создавая БД фильмов, мы могли некоторое время не вводить в нее фильмы с одинаковыми названиями, и сит1ация выглядела бы так, что title ~ это ключ лля класса Movie. Од)1ако, положившись на очевидность того, title является ключом, и спроектировав для БД структуру памяти, которая предполагает, что title -- ключ, мы лишились бы возможности ввести в БД второй фильм Кинг Конг .

Таким образом, ограничения ключа и ограничения вообще -это часть схемы БД. Они описываются проектировщиком вместе со структурной схемой (например, атрибутами и связями). Если ограничение определено, нарушающие его вводы в БД или ее изменения запрещеньь

Следовательно, даже если отдельный пример БД удовлетворяет определенным ограничениям, единственно истинными являются ограничения, определенные проектировщиком для всех примеров БД и корректно модели-} рующие реальный мир. Такие ограничения MoriT предполагаться пользовате-I лем и структ1рами, которые используются для хранения БД.

2.5.1 Ключи

в ODL ключ класса это такое множество атрибутов К, что при наличии в данном классе двух различных объектов О, и ft они не могут иметь идентичных значений для любого атрибута в ключе К. В E/R-модели ключ определяется так же, только слово класс заменяется на множество сущностей , а объекты - на сущности -

Пример 2,23. Рассмотрим класс Movie из примера 2.1. Сразу можно предположить, что сам атрибут ttle является ключом. Однако есть названия, которые можно использовать для двух и даже более различных фильмов, например Кинг Конг . Поэтому неразумно объявлять ключом атрибут title: тогда невозможно будет включить в БД информацию об обоих фильмах с названием Кинг Конг .

Лучше принять в качестве ключа множество, состоящее из двух атрибутов: title и year. Правда, остается риск, что существует два фильма, выпущенных в одном и том же году с одинаковым названием, однако это маловероятно.

Ключи для двух других классов, Star и Stud о, введенных в примере 2.1, тоже нужно подбирать внимательно. Разумно предположить что нет двух студий с одним и тем же названием, поэтому пате принимается в качестве ключа лля класса Studio. Кинозвезды же совсем не обязательно идентифицируются своими именами: у многих людей могут быть одинаковые имена. Однако кинозвезды обычно выби рают себе сценические имена , поэтому name может служить ключом для класса Star Если же нет, то в качестве ключа вполне подойдет пара атрибутов пате и address, если только нет двух кинозвезд с одинаковыми именами, живущих по одному и тому же адресу. □

Пример 2.24. Из примера 2.23 может создаться впечатление, как это проблематично найти ключи или быть уверенным в том, что множество атрибутов формирует ключ. Однако на практике все гораздо проще. В реальных ситуациях, обычно моделируемых с помощью БД, для важных классов часто специально создаются эффективные ключи. Например, компании обычно присваивают всем своим сотрудникам идентификаторы ID, которые тщательно отбираются в виде

унмкапьных номеров. Одно из назначений ID -служить гарантией, что в БД компании каж-юго сотрудника можно отличить от всех остальных, даже если одно и то же имя носят несколько сотру-ивжов. Поэтому атрибут ID сотрудника может служить ключом для сотрудников Q БД.

в корпорациях США принято гакже, что у каждого сотрудника есть номер стра*ового полиса. Сели в БД есть такой атрибут, как номер страхового полиса, он тоже может быть юпючом для сотрудников. Заметим, что нет ничего плохого, если существует несколько вариантов ключа для класса, как. например, для класса сотрудников, имеющих и ID, и номер страхового полиса.

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

2.5-2 Описание ключей в ODL

в ODL один или несколько атрибугов описываются как ключи класса с по-\юшью ключевого слова key или keys (любого из них), за которым указываются атриб)ты, формирующие ключ. Еали в ключе больше о.аного атрибута, список атрибутов заключается в круглые скобки. Описание юноча должно стоять непосредственно за описанием интерфейса, перед открывающей фигурной скобкой или любыми атрибутами либо связями. Само описание ключа заключается в круглые скобки.

пример 2.25. Чтобы показать, что множество, состоящее из атрибутов title и year является ключом для класса Movie, строка I на рис. 2.6 заменяется на:

interface Movie (key (title, year))

Вместо key можно применять keys, даже если описывается только один ключ. Лналогично. если name -ключ для класса Star,

(key name)

добавляется перед фигурной скобкой в строку 8 на рис. 2.6. □

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

Пример 3.26. Чтобы проиллюстрировать ситуацию, в которой уместно иметь более одного ключа, рассмотрим класс Employee. Не будем описывать здесь все множество его атрибугов и связей, но предположим, что его ат-рибугами являются empID - илстифнкатор сотрудника и ssNo - номер страхового полиса. Тогда эти агрибуты люжно описать как ключ:

(key empID, ssNo)

Ри 2.24. АЛножество сущноаей Movies с отмеченным ключом

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

Возможна необычная ситуация, когда ключ для множества сущностей не принадлежит самому этму множеству. Такой случай называется слабыми множествами сущностей и рассматривается в разделе 2.6.

2.5.4 Ограничения по единственнол1у значению

Часто основной особенностью проекта БД является то, что отдельную роль в нем играет только одно значение. Например, предполагается, что объект фильм имеет уникальные название, год, длину, тип и фильмом влштеет единственная СТУДИЯ. В ODL легко описать эти допущения, поскольку каждый атрибут имеет тип. Если он не является множеством, то для атрибуга может быть только одно значение или только один связанный объект для каждой связи. Если же определено, что атрибут или связь имеет тип множества, например тип Set<Star> для связи stars в строке 6 рис. 2.6, тогда с данным фильмом может быть связано несколько звегм. Данная свизь называется многозначной

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

Поскольку список атрибутов здесь не заключен в скобки, в ODL это означает, что каждый из атрибутов сам является ключом. Если заключить и скобки пару (empID, ssNo), в ODL считается, что эта два атрибута вместе формируют один юмоч. Из записи

(key (emplD. ssNo))

следует именно то, что никакие два сотрудника не могут иметь один и тот же ID и один и тот же номер страхового полиса, хотя два сотрудника могут совпадать по одисму из этих атрибутов. □

2.5.3 Представление ключей в E/R-модели

Множество сущностей может иметь ключи точно в том же смысче, в каком их имеют классы ODL. Если множество атрибутов формирует ключ для множества сущностей, в нем не может быть двух сущностей, чьи значения совпадают для каждого атрибута ключа. В нотации E/R-днаграммы подчеркиваются атрибуты, принадлежащие ключу для любого множества сущностей. Например, на рис. 2.24 показано множество сущностей Movies из рис. 2.8 с атрибутами liile и year, которые вместе служат ключом.