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

ГЛАВА

Представьте себе такую вы, владелец небольшой компа-

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

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

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

ЧАСТЬ 3

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

ров, должны быть но это отнюдь не означает, что они

должны быть абсолютно верными в момент их ввода.

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

в том порядке, который для них наиболее удобен или который они

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

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

Классы ограничений целостности

В главе 4 мы определили шесть различных видов ограничений

относящихся к различным логическим уровням в реляционной модели. В этой главе мы рассмотрим вопросы реализации целос-данных под другим углом зрения и воспользуемся иной классификацией, Разделим все ограничения целостности на два класса: внутренние тинения (intrinsic constraints) и ограничения, определяемые особенностями веления бизнеса, называемые также билнёс-правилами (business rules).

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

запрещающее удалять запись из таблицы Customers (Покупатели), если в Orders (Заказы) имеются связанные с ней записи, - это

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

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

Но и когда возможность повторного использования значения первичного ключа полностью осиротевшие записи могут причиной большой путаницы и причинить немало неприятностей. Например, запросы, в которых вычисляется общее количество продуктов, проданных компанией за период времени, могут выдавать разные результаты в зависимости от того, ся ли в процессе выполнения запроса соединение таблиц Orders и Customer-:. Чтобы получить полный список проданные vkioli, содержащий информацию о том, какие продукты и в каком количестве приобрел каждый из покупателей, используется естественное соединение таблиц и Orders. В этот список войдут только те записи из таблицы для которых имеются записи в таблица .wm, и, следовательно, только эти данные будут использованы при вычислении общих объемов продаж. Осиротевшие записи в таблице Orders отсутствуют в наборе результатов, получившемся в результате соединения Customers и Orders, и, следовательно, не будут учтены в вычислениях. Однако если при вычислении объемов продаж использовано соединение таблиц Pro-ducix. осиротевшие записи будут присутствовать в наборе результатов и учитываться в вычислениях. Таким образом, на вопрос Какое количество товаров бхло продано в июне? система даст два разных ответа, в зависимости от способа выполнения запроса. Что, разумеется, недопустимо.

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