Начиная с Oracle 8.0, мы также имеем возможность отложить проверку огра­ничений, что может оказаться довольно-таки выгодно для различных операций. Первое, что немедленно приходит в голову — это требование каскадного оператора UPDATE первичного ключа и его дочерних ключей. Многие люди возразят, что этого делать никогда не нужно, поскольку первичные ключи неизменны (я тоже принад­лежу к их числу). Но многие другие настаивают на своем желании использовать каскадные UPDATE. Отложенные ограничения предоставляют такую возможность. 

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

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

ops$tkyte@ORA10G> create table p

2 ( pk int primary key )

3 /

Table created. 

ops$tkyte@ORA10G> create table c

2 ( fk constraint c_fk

3 references p(pk)

4 deferrable

 5 initially immediate

6 )

7 /

Table created. 

ops$tkyte@ORA10G> insert into p values ( 1 );

1 row created. 

ops$tkyte@ORA10G> insert into c values ( 1 );

1 row created. 

У нас есть родительская таблица P и дочерняя таблица C. Таблица C ссылается на таблицу P, и ограничение, используемое для обеспечения этого правила, назы­вается C_FK (child foreign key —  дочерний внешний ключ). Ограничение описано как DEFERRABLE, но установлено в INITIALLY IMMEDIATE. Это значит, что мы мо­жем отложить проверку ограничения до COMMIT или до некоторого другого момен­та. Однако по умолчанию оно будет проверяться на уровне оператора. Это наиболее распространенный случай применения отложенных ограничений. Большинство существующих приложений не проверяют нарушение ограничений по оператору COMMIT, и лучше не менять этого. Согласно определению таблицы C, она ведет себя таким же образом, как всегда должны вести себя таблицы, но при этом предостав­ляет нам возможность изменить ее поведение. Попробуем воспользоваться некото­рым DML для таблиц и посмотрим, что произойдет: 

ops$tkyte@ORA10G> update p set pk = 2;

update p set pk = 2

* 

ERROR at line 1: 

ORA-02292: integrity constraint (OPS$TKYTE.C_FK) violated - child record found 

Поскольку ограничение находится в режиме IMMEDIATE, оператор UPDATE завер­шился неудачей. Изменим режим и попробуем снова: 

ops$tkyte@ORA10G> set constraint c_fk deferred;

Constraint set. 

ops$tkyte@ORA10G> update p set pk = 2;

1 row updated.

Теперь порядок. В демонстрационных целях я покажу, как явно проверить от­ложенное ограничение перед фиксацией, чтобы увидеть, согласуются ли моди­фикации с бизнес-правилами (другими словами, проверить, не нарушаются ли ограничения). Будет хорошей идеей сделать это перед фиксацией или передачей управления какой-то другой части программы (которая может не ожидать отло­женных ограничений): 

ops$tkyte@ORA10G> set constraint c_fk immediate;

set constraint c_fk immediate 

* 

ERROR at line 1: 

ORA-02291: integrity constraint (OPS$TKYTE.C_FK) violated - parent key not found

Попытка завершается неудачей и немедленно возвращает ошибку, как и ожида­лось, поскольку мы знали, что ограничение нарушается. Оператор UPDATE табли­цы P не откатывается (поскольку это нарушило бы атомарность уровня операто­ра); он по-прежнему отложен. К тому же обратите внимание, что наша транзакция по-прежнему работает с отложенным ограничением C_FK, поскольку команда SET CONSTRAINT завершилась неудачей. Продолжим каскадным оператором UPDATE для таблицы C: 

ops$tkyte@ORA10G> update c set fk = 2;

1 row updated.

ops$tkyte@ORA10G> set constraint c_fk immediate;Constraint set. 

ops$tkyte@ORA10G> commit;

Commit complete.

Вот так это работает. Следует отметить, что для того, чтобы отложить ограни­чение, вы должны создать их именно таким образом — удалить и создать заново, чтобы изменить его с неотложенного на отложенное.