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

Щик) и Category (Категория продукта), хотя подробности их структуры еще не известны.

Так как сущности определяются туальном уровне, нас не волнует, являются ли атрибут Extended Price (Пересчитанная цена) сущности Order Detail или атрибут Units In Stock (Количество упаковок на складе) сущности Product (Продукт) хранимыми величинами или они вычисляются по мере необходимости. Мы еще не знаем, можно ли их вычислить и решим этот вопрос позднее.

Интересен атрибут Ship Via (Способ доставки продукта). Большинство форм заказов предоставляют возможность выбрать способ доставки: например, Parcel Post (посылкой) или 2nd Day Air (авиапочтой). Это атрибуты или сущности? Ответ зависит от семантики системы (вы этого ожидали, не так Как много вариантов существует? Если более двух, введите специальную сущность для этого элемента данных.

Насколько постоянны используемые при заполнении формы значения? Существует что вы имеете дело с внешними поставщиками услуг. Может ли организация сменить поставщика или привлечь еще одного? Насколько зависит деятельность организации от конкретного метода поставки? Возвратят ли транспортные компании заказ назад, если им нужно будет нанять альпинистов и забросить товар на вершину Эвереста? Ответы на эти вопросы также нужно учесть при создании модели.

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

Если компания, выполняя применяет нестандартные ме-

тоды доставки товара, нужно учесть и это. Вы должны пройти по лезвию ножа между гибкостью и эффективностью. Для нашего примера наилучшее решение - ввести дополнительный атрибут Special Instruction (Специальная инструкция), но это должно быть обязательно учтено в модели данных и при анализе рабочих процессов.

Такое решение может неожиданным образом повлиять на системные ограничения. Хотя организации нужно точно знать, как доставить товар заказчику, трудно будет детально определить специфический метод доставки. Система должна следить за тем, чтобы атрибуты Shipping Method (Способ доставки) и Special Instructions (Специальные инструкции) не оказались пустыми одновременно, поэтому в модель придется добавить достаточно сложные правила проверки.

ЧАСТЬ 2 Пшшкрляии* рйлй14Ийяяы)( систем баз данных

Если в рамках проекта автоматизируется процесс реальной поставки товара, трактовка Shipping Ш11ин1 как отдельной сущности нолез-на, но потребует значительно усложнить систему. Как определить сведения о метоле доставки, который может появиться в будущем? Либо создать общую сущность, содержащую типичные для методов поставки атрибуты например, помер дока и время погрузки), либо определить только известные методы поставки и завершить на работу - исключительные случаи не будут обрабатываться системой.

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

Нужно последствия решений, которые вы принимаете,

Легко не заметить недостатки решения, когда вас озаряет какая-то идея: Разве это не хорошо? Это сэкономит много времени . Допустим, вы обрабатываете какую-либо часть информации. Подумайте, не используется ли она еще где-то, либо как значение по

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

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

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

Определение связей

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

глава 9 Коцептуаг!,нн-л iiitejib данных

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

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

привести ее к ясной и понятной форме.

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

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

Первый черновой вариант диаграммы сущности - связи для процесса обработки заказа приведен на рис. 9-4. Эт стой при-и диаграмма легко читается. Допустим, вы решили, что

является атрибутом только сущности Sales Order для него не существует специальных сущностей.

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

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

мощность;

обязательность присутствия каждого участника;

связываемые атрибуты;

налагаемые ограничения.

Проанализировав диаграмму процесса обработки заказа, вы получите результат (рис. 9-5).