Каждый платеж имеет уникальный номер, выделенный системой.

Все коды валют должны раскрываться, т.е. рядом с кодом при вводе должно указываться полное название валюты.

Обновление записей о платежах не разрешается.

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

Интерфейсный процесс и архитектура клиент/сервер

Поскольку Oracle? поддерживает и хранимые процедуры, и триггеры, то в среде клиент/сервер большая часть логики может (и должна) размешаться в базе данных на сервере. В техническом плане Oracle? использует модель клиент/сервер даже в том случае, когда и клиент (прикладная программа), и сервер (база данных) располагаются на одной машине. Почему? Потому что два этих компонента взаимодействуют друг с другом с помошью сообшений, а не традиционных структур вызовов. Это позволяет двум компонентам - прикладной программе и СУБД - работать как отдельным процессам. Они могут находиться на одной машине (такую архитектуру обычно называют двухзадачной) или на разных машинах, связанных сетью. Именно последний случай обычно имеется в виду, когда говорят о системе клиент/сервер.

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

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

Пол человека должен быть либо F ( Ж ), либо М ( М ).

Это правило для данных, которое можно ввести с помощью огранюгения CHECK. Значение в столбце для пола человека должно присутствовать и равняться либо Ж , либо М . Конечно, может иметь место ошибка анализа или проектирования; возможно, нам потребуется допусп-гть отсутствие этого значения.

Нам приходилось работать с Клиффом Лонгманом, который много лет отвечал в Oracle за архитектуру CASE-средств. На занятиях по стратегии

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

Каждый заказ должен быть предназначен для одного и только одного покупателя. Это правило для данных, которое можно ввести с помощью комбинации ограничений PRIMARY KEY и NOT NULL.

Каждая строка должна быть частью одного и только одного заказа

и относиться к одному и только к одному коду товара.

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

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

превышают $16000.

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

Только руководитель может санкционировать выплату денежного вознаграждения.

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

Все торговые операции, проводимые в воскресенье, учитываются

в бухгалтерских книгах за следующий понедельник.

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

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

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

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

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

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

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

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