ГЛАВА 1 даяОйТ!1!0СТй Saai; данных

Определяя правила, старайтесь исключить использование разных вариантов Например, такое правило: если в

названии компании встречается слово Company , оно сокращается

о.>, а все остальные символы ющпе за этим словом, отбрасываются. Тем самым вы исключите вероятность, что название компании The Really, Really Long Name Company, Incorporated будет введено разными пользователями раз как Really, Really Long Name . адругой - как Really, Really Long, . Ведь подобные ошибки могут привести к тому, что одна и та же компания будет учтена в базе дважды.

Значения Null

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

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

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

информации может потребоваться прежде, чем определенная задача

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

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

если новый сотрудник не сразу сообщит полную информацию о себе

и своем банковском счете вводящему в систему эти

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

ЧАСТЬ 3 Провоир 5ба и& гтпьзойатЕльского иигт©(1феЙСЛ1,

Помимо неудобств для информацию от-

сутствие в системе данных о новом сотруднике может

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

ка на работу они, скорее всего, не понадобятся.

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

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

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

Другой способ - предоставить пользователю возможность выбрать один из нескольких вариантов значений, например Unknown (Неизвестно). Not Applicable (Яе исиодьзуется) и Yef То Соте (Будет введено позже). В некоторых случаях система может сгенерировать подходящее значение но умолчанию самостоятельно.

Ограничения, налагаемые на диапазон возможных значений

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

ных камней.

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

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

активно работают с системой - необходимо на время приостановить работу.

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

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

Ограничения на уровне сущностей и ссылочная целостность

Как я уже говорила, ограничения на уровне сущностей гарантируют

возможность уникальной идентификации каждой записи в таблице, а

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

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

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

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