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

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

Гарантировать, что плановый объем продаж офиса будет всегда в точности равен сумме плановых объемов продаж его служащих:

CREATE ASSERTION quota totals CHECK ((OFFICES.QUOTA = SUM(SALESREPS.QUOTA)) AND (SALESREPS.REP OFFICE = OFFICES.OFFICE))

Если не откладывать проверку до завершения транзакции, данное ограничение вообще не позволит добавить в базу данных информацию о новом служащем. Почему? Да потому что для того, чтобы плановые объемы продаж офиса и всех его служащих оставались равными, нужно одновременно добавить запись для нового служащего с некоторым плановым объемом продаж (с помощью инструкции insert) и увеличить на ту же сумму плановый объем продаж офиса (с помощью инструкции update). Если вы попытаетесь сначала выполнить инструкцию insert для таблицы salesreps, таблица offices еще не будет обновлена, и утверждение окажется не выполненным, поэтому инструкция insert будет отменена. Подобным же образом, если вы попытаетесь сначала выполнить инструкцию update для таблицы offices, таблица salesreps еще не будет обновлена, и утверждение снова окажется не выполненным. Единственное решение этой проблемы - отложить проверку утверждения до тех пор, пока не завершатся обе инструкции, и уже после этого убедиться, что вместе эти операции перевели базу данных в допустимое состояние.

Предлагаемый стандартом SQL2 механизм отложенной проверки офаничений обеспечивает такую возможность и не только ее. Каждое создаваемое в базе данных Офаничение (любого типа) может быть определено с атрибутом deferrable или not deferrable.

Проверка офаничения, заданного как deferrable, может быть отложена до конца фанзакции. Именно так должно быть определено утверждение, описанное в предыдущем примере. В нем для обновления плановых объемов продаж или добавления информации о новых служащих нужно обязательно отложить проверку Офаничения.

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

Поскольку Офаничения типа not deferrable обеспечивают более жесткий конфоль целостности дгнных, этот оежим используется по умолчанию. Если же вы

хотите создать ограничение, которое может быть отложено, включите в его объявление ключевое слово deferrable. Обратите также внимание на одну важную особенность этих двух атрибутов: они определяют только то, может ли быть отложена проверка данного Офаничения. Будет ли она на самом деле отложена для очередной операции, определяет СУБД. Для офаничения может быть определено начальное состояние.

Офаничение, определенное как initially immediate, начинает свою жизнь как безотлагательное , т.е. проверяется после выполнения каждой нсфукции.

Офаничение, определенное как initially deferred, начинает свою жизнь как отложенное , т.е. оно проверяется только по окончании транзакции. Конечно, этот афибут не может использоваться совместно с афибутом not deferrable. Начальное состояние офаничения вступает в силу сразу после его создания.

Кроме того, Офаничение переводится в это состояние перед началом каждой фанзакции. Поскольку афибут initially immediate обеспечивает более жесткий кон-фоль целостности данных, он используется по умолчанию. Если же вы хотите, чтобы перед началом каждой транзакции офаничение автоматически переводилось в отложенное состояние, вам нужно включить в его определение афибут initially deferred.

SQL2 допускает также динамическое изменение способа обработки Офаничений с помощью инструкции set constraints. Пусть, к примеру, наша база данных содержит следующее офаничение:

create assertion quota totals check ((offices.quota = sum(salesreps.quota)) and (salesreps.rep 0ff1ce = offices.office)) deferrable initially immediate

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

set constraints quota totals deferred

insert into salesreps (empl num, name, rep office,

hire date, quota, sales) values (:num, :name, :office num, :date, :amount, 0) .

update offices set target = target + :amount where (office = ;office num)

commit

После поступления инструкции commit, завершающей фанзакцию, офаничение quota totals переводится в режим immediate, поскольку оно определено как initially immediate, И В ЭТОМ режимс оно будет оставаться до тех пор, пока не поступит новая инструкция set constraints. Если ВЫ захотите, чтобы офаничение quota totals было проверено до окончания фанзакции, например в случае, если между инструкциями update и commit должны выполняться еще какие-то действия, не влияющие на данное ограничение, вы можете вручную перевести офаничение в режим immediate такой инструкцией:

set constraints quota totals immediate

Инструкция set constraints допускает установку одного и того же режима сразу для нескольких ограничений - их нужно просто перечислить через запятую:

ЗЕТ CONSTRAINTS quota totals, rep totals IMMEDIATE

И наконец, можно одной инструкцией установить режим обработки всех офаничений базы данных:

SET CONSTRAINTS ALL DEFERRED

Определенные стандартом SQL2 средства проверки офаничений значительно расширяют возможности обеспечения целостности баз данных. Принципы управления отложенной проверкой офаничений, как и многое другое, стандарт SQL2 частично перенял у существующих СУБД, другая же их часть была реализована в некоторых СУБД уже после публикации стандарта. Например, СУБД DB2 фирмы IBM поддерживает возможность отложенной проверки офаничений, причем в соответствии с синтаксисом SQL2. Однако ее инсфукция set constraints отличается от стандарта. Она оперирует отдельными таблицами базы данных, включая и отключая режим отложенной проверки офаничений, связанных с содержимым этих таблиц.

Деловые правила

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

клиентам не разрешается размещать заказы на сумму, превышающую их лимит кредита;

если клиенту назначается лимит кредита, превышающий $50000, то об этом должен быть уведомлен вице-президент по продажам;

заказы хранятся в бухгалтерских книгах в течение шести месяцев; затем они аннулируются.

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

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

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

В стандарте SQLI определено, что эти правила выходят за рамки языка SQL. СУБД отвечает за хранение, организацию и обеспечение целостности данных, а за реализацию деловых правил отвечает прикладная профамма, осуществляющая дос- Уп к базе данных.