ЧАСТЬ 2 Вроенпцаа&нав релкциенных систем баз данных

Shippinti

Produci Category

Sales Order

Order Detail - -

]-e Product

Cuslomsr

Supplier

Рис. 9-4. Первые НОвик диаграммы сущности - связи процесса обработки заказа

Shipping Method

ЭтвдЗi не являетсй обязательной, только если имеются специальные инструкции

SalesOrder

Customer

Кредит необходимо проверить перед принятием заказа

Order DetaH -Т-

Oe Product

Рис. 9-5. Диаграмма процесса обработки заказа после анализа связей между сущностями

ГЛАВА 9 Кйнцептуалы1ай Mfvse.i- йзнкых

Мощность связи

Итак, вы обозначили связи между сущностями на диаграмме (рис. 9-4). Теперь еще раз диаграмму и уточните параметры

связей.

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

сущность и создайте связи один ко между каж-

дой из участвующих в исходной связи сущностей и этой промежуточной сущностью (промежуточная сущность - со стороны Связь между Л/7/) ег(Поставшик)и Ргомс? (Продукт) в нашей модели имеет тип многие ко многим , и чтобы ее реализовать, нужно добавить сущность Product-Supplier. Связь между Sales Order (Форма торгового заказа) и (Продукт) также имеет тип многие ко мно-

но в этом случае в качестве промежуточной сущности ет Order Detail (Информация о заказе).

Обязательность связи

Определив тип связи между двумя сущностями, разберитесь, является ли связь обязательной для каждого из участников. В нашем примере связь между сущностями Смготег (Покупатель) и Shipping Method (Метод доставки) необязательна для обеих сторон - то есть, заказчик не обязательно предпочитает определенный способ доставки (способ по умолчанию), а способ доставки не обязательно связан с

конкретным заказчиком.

Связь между Product Category (Категория продукта) и Product (Продукт) необязательна только для одной из сторон. Категория продукта

не обязательно с конкретным продуктом, но любой продукт

должен относиться к определенной категории товара.

Связь между Sales Orer (Форма торгового заказа) и Shipping Method (Метод доставки) более сложна. Метод доставки может существовать независимо от заказа, так что Sales Order- необязательный участник связи. Shipping тем не менее, не обязан участвовать в связи,

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

связи

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

ЧАСТЬ Ааваше реляционных систем баз Данвш

Когда связь сама но себе имеет атрибуты, ее можно представить в виде сущности. В случае с обработкой заказа мы могли бы присвоить определенному ноставшику статут рованный (Preferred Supplier). Так как у нас уже есть промежуточная ость между сущностями Product (Продукт) и Supplier (Поставщик), атрибут Preferred ЗиррИегможно просто добавить к сущности. В ином случае следует создать новую сущность, чтобы отразить с ее помощью атрибуты связи.

Дополнительные ограничения

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

В нашем примере таким ограничением является условие, согласно которому связь между Sales Order (Форма торгового аза) и Shipping Method (Метод доставки) необязательна, если только существуют специальные инструкции для поставки данного заказа. вило, что заказчик не может разместить если его кредит не

нроверен - другое ограничение. Это правило представлено на диаграмме в виде аннотации. Если ограничений много или ограничение слишком сложно, чтобы представить его в виде аннотации, документируйте его иным способом. Но нужно, по крайней мере, указать на

диаграмме, что такое ограничение существует.

Повторный анализ сущностей

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

как она связана с предметной областью;

какие рабочие процессы ее создают, изменяют, используют и уничтожают;

какие сущности взаимодействуют с этой сущностью, а какие от нее зависят;

какие у нетвуют ограничения и бизнес-правила;

каковы ее атрибуты.

Связь между сущностью и предметной областью

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