ЧАСТЬ 3 Пр К1П!р<11*ан е полл>э4)вател1*с1квго йщ-ерфекся

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

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

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

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

Внутренние ограничения

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

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

Ограничения, налагаемые на тип данн1х

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

надцать вместо числа Поэтому правильности выбора элементов

интерфейса следует уделять особое внимание. Ограничения, налагаемые на формат данных

Как правило, такие нарушения не слишком заботят пользователей и разработчиков, поскольку формат данных можно изменить, сразу после того, как они введены (в Microsoft Access есть средства, позволяющие это сделать). Можно также задать маску ввода, гарантирующую правильный формат вводимых данных. Однако не следует налагать ком строгие ограничен на формат вводимых данных там, где этого не требуется. Если введенные данные не соответствуют мату, определенному ограничениями, то возможно, лучше оставить окончательное решение за пользователем. Предложите ему вариант форматирования, близкий к правильному, и предоставьте возможность повторно ввести данные в том формате, в котором он сочтет нужным. Конечно, не исключено, что введенные данные будут просто неверны, но все же это бывает редко. Например, пользователь, который ввел в базу данных телефонный номер 9-9999-99999-99, возможно, просто пользовался новой системой офисной связи.

Ограничения, налагаемые на длину данных

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

Максимальная длина записи, которую можно ввести в такое ноле, составляет 255 символов, Используя тин данных неременной длины, вы, несомненно, решите большинство проблем, с такими огра-

ничениями. В SQ rver можно явн ать тин данные НАкдля ноля таблицы базы данных. И SQL Server, и Microsoft Jet. сохраняя данные этих типов, место на диске только для символов,

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

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

Кроме того, SQL Server обновляет данные неременной длины гораздо медленнее, что может снизить производительность системы, впрочем, в большинстве случаев незначительно. Но в где

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

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

та либо название компании. Пользователь пытается ввести в это поле длинное название компании, но оно не умещается полностью. И тог-

разумеется, пользователь решит название сократить. Он может опустить артикли, заранее оговоренные сокращения:

Со. , означающее Сотрапу или Inc. , означающее Incorporated ,