ЧАСТЬ 3 Пробктир аани пользовотельссагй иитерЫкШ

ляюшии вводить или изменять дату вручную; но умолчанию нодстав-ляется текущая дата.

d PeliveiiiDdte Ueluie UiJui Dale

the >Н !гу (W*ri4M£tflli*iriiim ttWi

&illvitf*i t tfa i ad aaKdm Utt iiiiitiNity МЛггсч К tiicot {M.uiiш.зЛ

Рис. 16-5. Это диалоговое окно позволяем .митъзаказ задним числом

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

(рис. 16-6).

В данном случае пользователь, вводивший информацию в базу данных, не имел прав отменить Одна-

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

ГЛАВА

Поддержка тносги базы данных

imum Number of EmphfK&t EHceded

e default, ei*f rivclAIOtocmi (111 iRpoil to н lunnaiw. ThP rmplnyee you : (П1).№<1 would fi>;t?<MlthaS: iwniier, нпЛ you do not hvettte inithertty tft :

ijaJ№ (Sftejastj лгчШад.

. г . .. иа I т

?:Fixti;5--1- r- i-

Рис. 16-6, Диалоговое окнняет, что только авторизованное .зицо может отменить действующее бизнес~правило

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

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

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

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

ЧАСТЬ 3 npoesTHf Ежзтае тшьжжиеяьск&гоинтягйса

влияние, которое они могут оказать на систему в зачас-

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

несомненно, поскольку именно они позволяют

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

Если неавторизованные записи (или некоторые из них, отобранные но специальному признаку) должны быт ючень! из отчетов, нуж-

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

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

учесть, прежде чем возможность обойти

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

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

Итоги

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

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

В следующей главе мы подробно lunonopiwi о процессе создания отчетов на основа шикся в системе данных.