Если же описать данное ограничение как откладываемое, то Огас!е8 сможет подождать с проверкой до фиксации транзакции. В этот момент ограничение будет соблюдено, ибо заказ уже будет создан. Отложенная проверка ограничений предполагает именно то, что говорится в названии: можно переносить срок проверки ограничений, но нельзя откладывать выполнение триггеров. Рассматривая приведенный выше пример, некоторые могут сказать, что хотя мы и разорвали замкнутый круг "курица-яйцо", но сделали это неправильно, потому что целесообразнее сначала создать заказ. Мы не согласны с таким мнением. Для нас единственный яо-настоящему логичный подход — создать заказ и его строки одновременно, действием, которое моделируется в Oracle и других средах с помощью предложений COMMIT и ROLLBACK.
Примечание:
Как вы узнаете из главы 5, где рассматриваются средства поддержки объектов в OracleS, в этой СУБД вполне можно прийти к схеме, которая позволила бы создать и новый заказ, и все его строки одним SQL-предложением INSERT (и, возможно, потребовала бы этого). Однако наличие такой возможности еще не означает, что ее использование является разумным.
Для обеспечения отложенной проверки ограничений каждое ограничение имеет два дополнительных атрибута — ограничение может быть:
•    откладываемым или неоткладываемым;
•    изначально отложенным или проверяемым немедленно. Так, оператор
ALTER TABLE emp ADD CONSTRAINT emp_dept_check FOREIGN KEY deptno REFERENCES dept DEFERRABLE INITIALLY DEFERRED;
добавляет ограничение, которое по умолчанию будет проверяться только во время завершения. Это ограничение и тот факт, что оно проверяется во время фиксации, инкапсулированы в определении таблицы emp. Пользователь с достаточным знанием словаря данных может обнаружить, что это отложенное ограничение существует, но код, который манипулирует таблицей emp, о существовании этого ограничения знать не обязан. Следовательно, с точки зрения проектирования, для нас не имеет особого значения то, что OracleS позволяет приложениям выдавать SQL-предложение такого вида:
SET   CONSTRAINTS   emp_dept_check   IMMEDIATE;
Это синтаксис SQL-92 и вполне вероятно, что его поддержка включена просто для обеспечения соответствия данному стандарту. Мы полагаем, однако, что у прикладного кода и без того достаточно проблем, чтобы думать об именах ограничений, примененных к таблицам, которыми этот код
40	Orach-Я