НИКОВ организации - типичный пример такого не слишком удачного определения.

Если связь представляется в виде сущности, дать определение труднее, так как связь не отражает напрямую конкретные объекты предметной области. Вот пример: Поставщик может поставлять мl<l жество товаров, и один и тот же товар может поставляться несколькими поставщиками, Сущность моделирует эту связь, также как и свойство присваиваемое любому конкретному поставщику данного товара .

Некоторые понятия предметной области (вероятно лучший пример здесь - торговый моделируются с помощью нескольких сущностей. Я называю эти понятия составными сущностями. Форма торгового заказа представляется в виде сущностей Sales Огег (Форма торгового заказа) и Order ОеГаИ (Информата о заказе).

Я предпочитаю описывать тавныс сущности как единый объект. Например: Сущности Sales Order и Order Detail образуют вместе единый заказ, размещаемый заказчиком. Сущность Sales Order моделирует сам заказ, а элемент Order Detail заказываемые

Рабочие процессы, влияющие на сущности

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

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

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

Большинство аналитиков заносят такую информацию в документацию по анализу рабочих процессов, что весьма удобно, если все изменения касаются только рабочих Но иногда

ния затрагивают и саму модель - непосредственно орга-

низаиия дела в компании) либо косвенно (изменения в рабочих процессах требуют адекватного изменения модели), В этом случае легче просмотреть документацию, описывающую изменяемую сущность,

ЧАСТЬ 2 Проектирование тыхсистем базданнык

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

Связь между сушностями и процессами - эт естная ссылка. Как и все такие ссылки, ее трудно создать и поддерживать, но в перспективе она может быть очень полезна.

Взаимодейие между сущноми

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

Когда модель состоит из множества диаграмм, и одна сущность присутствует в нескольких диаграммах, следует внести в описание сущности список элементов, с которыми она связана. Это очень полезно, если сущность используется в нескольких рабочих процессах. Например, сущность, в которой хранятся заголовки обращения типа Мг. , Mrs. -, Dr. , s. , может использоваться в нескольких различных местах клиентского приложения. Если в описании сущности вы явно перечислите, где она используется, то сэкономите время и силы, когда вам нужно будет изменить сущность.

Бизнес-Правила и ограничения

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

Любые ограничения, относящиеся к атрибутам: например, Атрибуты Shipping Method (Метод доставки) и Special Imtmctjons (Специальные инструкции) не могут одновременно содержать пустые значе-должны быть документированы.

Атрибуты

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

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

ГЛАВА 9 Концептуальная модель дэнных

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

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

Либо атрибут CompanyName (Название компании), либо атрибут individualName (Имя физического лица), но не оба эти атрибута одновременно, должны содержать значение Null

Customer

ompanyName: Name

4ndiviclualName: Name Address 1 :StreetAddress Address2: StreetAddress Suburb:Suburb

State: State

Country; Country PostalCode:PostalCode CredilRatingiCred it Rating

Список атрибутов сущности Corner (Покупатель)

Даже если оставить в стороне вопрос уникальности имен, у нас все равно будут проблемы. Если покупатель - физическое липо, атрибут CompanyName (Название компании) будет содержать Жм . Если покупатель - организация, значение Null будет содержать атрибут Individual Name (Имя физического лица). Один из этих атрибутов всегда будет содержать Поэтому такие поля не могут являться ключами-кандидатами или входить в их состав, даже если бы они уникально идентифицировали запись (хотя это не так).

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

Джоном Смитом-старшим, который проживает в том же доме.

Конечно, Джон Смит-старший (John Smith Sr.) и Джон Смит-младший (John Smith Jr.) - разные люди, и к ним относятся разные записи. Но те данные, которые позволяют их уникально идентифицировать, вряд ли пригодны для использования в качестве первичной информации о клиенте. Можете ли вы вообразить, что вас начнут расспрашивать об обстоятельствах вашей личной жизни, когда вы