ЧАСТЬ 1

Безусловно, не все домены можно определить, просто перечислив допустимые значения. Например, домен Age (возраст) содержит около сотни значений, если речь идет о человеке, и несколько тысяч -если мы говорим о музейных экспонатах. В подобныхcлyчaгxв определении домена, как правило, используются правила, проверяюшие принадлежность конкретного значения к области допустимых значений. Например, домен Аг.адпД1,е(1юзрист физического лица) можно определить ка тое число в интервале от 0 до 120, а ЫtAge(воз-раст выставочного экспоната) - просто как неотрицательное келое

число, большее 0.

Значит, домен - это тип данных и логические правила, определенные для данной сушмости Почти правильно. Но необходимо одно уточнение: логические правила - это один из механизмов реализации №Т1 юс j и данных, а отнюдь не элемент их описания. Например, логическое правило, реализующее срку допустимых значений для почтового индекса, может ссылаться на атрибут Ла?е, в то время как домен Zip Со(/( (почтовый индекс) представляет собой строку, длина которой не превышает шести символов.

Вы, очевидно, уже заметили, что все эти определения ссылаются на вид хранимых данные 1сло или строка), Это описание очень похожа : тип данных тако между ними существуют различия. Как я уже упоминала, типы данных - это физические аднции, они определяются и реализуются в терминах механизма СУБД. Если при разработке модели данных вы определите ен какаг(ЗО) (символьную константу переменной длины, с числом символов, не пре-восхоляшнм 30) или Хой/ /ес/(длинное целое), это будет ошибкой, поскольку г(ЗО), Integer - это описания, относящиеся к механизму СУБД.

Для любых двух доменов можно сравнивать определенные для них агрибутьг, и более того лня гь логические ации, например, соединения (будут подробно обсуждаться в глипе 5). Если над атрибутами двух доменов можно выполнять логические операции, то перед вами домены, имеющие совместимый типы данных (type-compatibie). Если рассматривать два отношения, представленных на рис-5, то несомненно, имеет смысл связать их по Employee!D= SalespersonJD (например, чтобы получить список счетов конкретного сотрудника). Домены ЕтрЬуееЮи имеют совместимые типы. Но по-

пытавшись соединить отношения D= OrderDate, вы вряд ли получите гй результат, даже если в определения :)тих двух доменов заложен один и тот же тип данных.

Employees

i ;2 .FUHeL .....-.A.ndieW

;....... ЩШвАЩ ...Janet

4 Peacock Margaret ,! 5: Buchanan Steven

. .. В Eujama Michael

...Sales Represent alive yicB President, Sales

Sales Representative Representative

Sales Manager

Sales Hepresenialive

Puc. 1-5. Отношения Employees и Orders

К сожалению, механизмы СУБД Microsoft Jet и SQL Server не предоставляют более строгой внутренней поддержки доменов, чем типы данных. Однако даже там, где речь идет о типах данных, ни один из упомянутых механизмов СУБД не строгой проверки.

оба они выполняют преобразования данных незаметно для пользователя. Рассмотрим конкретный пример, обратившись к базе данных IVorthwind, поставляемой Microsoft Access в качестве примера. Если вы определили EmployeelUB таблице Employees как длинное целое, а 1пуокеТо1а1в таблица o/cti - как currency (валюта), то можете написать запрос, соединяющий эти две таблицы при помощи критерия WHERE EmployeelD = InvoiceTotal. Microsoft Jet успешно выполнит этот запрос и вернет вам результат - список сотрудников, идентификационный номер {Employeeтыоторых будет совпадать с суммой, указанной в счете (InvoiceTotal). Совершенно очевидно, что два эти атрибута не являются совместимыми по типу данных, однако мы никак не можем объяснить это механизму СУБД Microsoft Jet,

Итак, стоит ли вообще иметь дело с доменами? Ответ однозначный: да, стоит. Во второй части книги мы рассмотрим домены более подробно, и увидим, что это чрезвычайно мощные и эффективные инструменты. При разработке баз данных часто возникают вопросы: Являются ли эти атрибуты ит rvoaтtilя(vil,lми> или .Определены ли правила, применимые к одному атрибуту, но не применимые к другому. . Анализ доменов позволяет получить ответы.

Связи

Кроме атрибутов каждой сущности модель данных должна определять связи между сущностями. На концептуальном уровне связи представ-

ляют собой простые ассоциации между сущностями. Например, утверждение Покупатели покупают одукты* указывает, что между сущностями Customers (ПокушJсяп) и Products (Продукты) существует связь, и такие сущности называются участниками этой связи. Число участников адеднет размерность связи. Определение размерности связи похоже на определение размерности отношения, но они между собой не эквивалентны.

Больщинство связей - двойные, в нихдва участника. Пример такой связи - связь между сущностями Cusfomers (Покупатели) и Products (Продукты). Однако существуют и другие виды связей, например, на существование неявной тройной связи указывает утверждение Сотрудники фирмы продают товары покупателям . Определение двух двойных связей не позволяет определить, кто именно из сотрудников продал товары покупателям, и какие именно товары каким именно покупателям он продал. Для этого нужно определять

тройные связи.

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

Существует несколько типов связей между двум стями: это связи один к один ко многим и многие ко многим .

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

к одному .

Связи один ко многим более часты. В счете перечислено множества шров , Торговый агент выписывает много счетов - вот примеры таких связей,

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

1 И м- невозможно непосредственно реализовать в реляционной модели, однако ннил реализация вполне проста и однозначна (об этом будет подробно рассказано в главе 3).