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

SALESORDER

26 Miy99

Obsreair 57

Bert- maa

К HMD H)i Ю11ла

I

Рис-/. Форма торгового рующаярабочий процесс

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

iinjproK>oro заказа Omnpa&uitib счет

к ТорГо&ый агент Способ c)OOrt13&KU

j Дата заказа (р Срок поставки g rtlpotlyKtri о J IhaHa продукта

Рис. 9-2. Первоначальный список элементов данных дл рмы торгового заказа

ГЛАВА 9 tiOHURfii-уальнаЯ: моде/г*, данных

Список составлен - можете выделять сущности, атрибуты и связи. Для каждого элемента списка нужно определить, является ли он самостоятельным объектом или свойством объекта. Объекты становятся сущностями, а свойства - атрибутами сущностей (рис. 9-3).

tfopMa гпорго&ого за

Omnpa&umb счет

Aocma&umb -

-Агент по продажам

Гг\<1< < i- доставки Дата заказа Срок .iocniaki>KU

озаказе

Продукт -

и,ена продукта Киэличестбо СкиВка \Пересчитанная

ценз , стоимость akaja -1/

. ТТокупэгпель Наимеио&ание компании К*зитакшиое лицо

:?аказ Доставка

Улица

Область

UJmawiAlpo&uMuufl Страна

Почтовый индекс

Продукт

Наименование Поста&шик - - Категория

Количество еЭинии

В упаковке

Поста&шик,

упако&ок нз склзде

Рас. 9-3. Предварительноеление элементов формы заказа на сущности и атрибуты

Элементы Bill To (Отправите ет) и Ship To (Доставить) определены ка таенты сущности toomer (Покупатель). Тем не менее, не очевидно, относятся ли два только к сущности толь-

ко к сущности Sale.s Order (Форма торгового заказа) или к обеим сущностям. который используется здесь, аналогичен тому, что применялся пр ении атрибута Unit Price (Цена продукта) к сущности Order detail рмания о заказе). Ка шая цена отличается от цены, по которой товар был продан, так же и адреса заказа и поставки покупателя логически отличаются от адресов, на которые были отправлены счет-фактура и заказ.

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

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

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

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

Предоставьте пользователям возможность обновлять данные, относящиеся к сущности Customer, в процессе обработки заказа. Если адреса нет или пользователь вводит новый адрес, система может выводить на экран запрос о необходимости добавить этот адрес в данные о клиенте, Здесь есть некоторые &1емы. связанные не с моделью данных, а с пользовательским интерфейсом.

Из факта существования элемента данных person (Торговый агент) вытекает, что в модели может присутствовать сущность Employee (Сотрудник). Но мы пока не располагаем необходимой для ее создания информацией, поэтому отметим это как вопрос, требующий разрешения. Существует вероятность, что эту сущность используют другие процессы. Если это так, добавьте пеобходимые атрибуты. Если нет, оставьте sperson в качестве атрибута сущности \-v/i-- Order. Помните: зависит от семантики системы. Если эти данные

используются только в сущности Sales Order, нет никаких причин создавать сложную по структуре

Элемент Product (Продукт) определен как сущность, и несколько элементов объединены в повторяющуюся группу: Product (Продукт), ШгРпсе( Цена продукта), Ог/дя/гг (Количество) и ДйсомиГ (Скидка). Эта группа определена как сущность Order (Информация о за-

казе). Для сущности Product определено первоначальное множество атрибутов, предположительно на основании ряда других документов, и на основании этого же списка выделены сущности (Постав-