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

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

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

Определение границ создаваемой системы - первый шаг в ходе анализа бизнес-процессов. Прежде чем начинать собственно анализ,

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

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

Беседы с пользователями

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

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

что собираетесь сделать.

Там, где это возможно (и даже там, где невозможно), ностарай-тесь побеседовать с причем не столько с менеджерами

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

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

Во время этих бесед обязательно затроньте вопросы исключений

из правил. Скажем, пользователь говорит: Мы проверяем заказ на полноту заполнения формы . Так вот, вы должны точно знать, что если форма заполнена не полностью. Скорее всего, они просто отправляют ее ну а если наоборот: они за-

полнить форму самостоятельно? Возможно, ваша система позволит

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

происходит при этом дальше.

Нужно четко представлять, что происходит с полученными данными при выполнении Какие элементы информации будут использоваться? Откуда они поступают? В какой форме? Что происходит, если их нет или они представлены неверно? Из ответов складывается прелварителъная грубая картина концептуальной модели

данных, которую мы будем обсуждать в следующей главе.

Большинство задач внутри процесса выполняются разными людьми. Очевидно, вам придется переговорить с каждым. Эта рекомендация относится и к людям, чья деятельность лежит вне рамок проекта. Например, возьмем описанный выше процесс создания торгового заказа. Задача Поставка товара может представлять собой, по сути, операцию Отправить заказ в отдел доставки , а то, что происходит потом в отделе доставки, уже находится вне рамок проекта. Я советую вам все же поговорить с сотрудниками отдела доставки и выяснить, получают ли они всю необходимую информацию и удобна ли

для них форма ее предоставления.

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

Определение задач

После бесед с пользователями, чью работу призвана облегчить ваша

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

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

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

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

задачи.

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

ограничение домена дата . (Это, конечно, наивный пример.) Но Дата поставки товара не может предшествовать дате заказа вытекает из особенностей бизнеса, так что это - бизнес-правило (или, по меньшей мере, может являться таковым). Кстати, термин бизнес-

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

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

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

Давайте рассмотрим один пример. вы

следующий список задач.

1. Проверить, все ли пункты заявки заполнены.

2. Запросить данные о покупателе (если они уже введены в систему).

3. Записать информацию о поставке. 4 ссти сведения о заказе.

5. Присвоить новому покупателю порядковый номер.