Deferred Constraints During large transactions involving multiple dependancies it is often difficult to process data efficiently due to the

restrictions imposed by the constraints. An example of this would be the update of a primary key (PK) which is referenced by foreign keys (FK). The primary key columns cannot be updated as this would o rphan the dependant tables, and the dependant tables cannot be updated prior to the parent table as this would also make them orphans. Traditionally this proble m was solved by disabling the foreign key constraints or deleting the original r ecords and recreating them. Since neither of these solutions is particularly sat isfactory Oracle 8i includes support for deferred constraints. A deferred constr aint is only checked at the point the transaction is commited. By default constraints are created as NON DEFERRABLE but this can be overidden u sing the DEFERRABLE keyword. If a constraint is created with the DEFERRABLE keyw ord it can act in one of two ways (INITIALLY IMMEDIATE, INITIALLY DEFERRED). The default, INITIALLY IMMEDIATE, keyword causes constraint validation to happen im mediate unless deferred is specifically requested. The INITIALLY DEFERRED keywor d causes constraint validation to defer until commit, unless immediate is secifi cally requested. The following code creates two tables with a deferred constrain t. CREATE TABLE tab1 (id NUMBER(10), tab2_id NUMBER(10)); CREATE TABLE tab2 (id NUMBER(10)); ALTER TABLE tab2 ADD PRIMARY KEY (id); ALTER TABLE tab1 ADD CONSTRAINT fk_tab1_tab2 FOREIGN KEY (tab2_id) REFERENCES tab2 (id) DEFERRABLE INITIALLY IMMEDIATE; ALTER SESSION SET CONSTRAINTS = DEFERRED; ALTER SESSION SET CONSTRAINTS = IMMEDIATE; The ALTER SESSION... statements show how the state of the constraint can be chan ged. These ALTER SESSION... statements will not work for constraints that are cr eated as NOT DEFERRABLE. Constraint States Table constraints can be enabled and disabled using the CREATE TABLE or ALTER TA BLE statement. In addition the VALIDATE or NOVALIDATE keywords can be used to al ter the action of the state. ENABLE VALIDATE is the same as ENABLE. The constraint is checked and is guar anteed to hold for all rows. ENABLE NOVALIDATE means the constraint is checked for new or modified rows, but existing data may violate the constraint. DISABLE NOVALIDATE is the same as DISABLE. The constraint is not checked so data may violate the constraint. DISABLE VALIDATE means the constraint is not checked but disallows any modif ication of the constrained columns. ALTER TABLE tab1 ADD CONSTRAINT fk_tab1_tab2 FOREIGN KEY (tab2_id) REFERENCES tab2 (id) ENABLE NOVALIDATE; ALTER TABLE tab1 MODIFY CONSTRAINTS fk_tab1_tab2 ENABLE VALIDATE;

Issues Exception handling has to be coded carefully as statements will not trigger exceptions directly. Often exceptions will only be picked up by the outermost ex ception handler which encloses the commit statement. Converting a NOVALIDATE constraint to VALIDATE may take a long time dependin g on the amount of data to be validated, although conversion in the other direct ion is not an issue. Enabling a unique or primary key constraint when no index is present causes the creation of a unique index. Likewise, disabling a unique or primary key will drop a unique index that it used to inforce it.

=============================== SQL> ALTER TABLE CHILD ADD CONSTRAINT CHILD_FK FOREIGN KEY (ID) REFERENCES MASTE R(ID) DEFERRABLE; Table altered. SQL> SET CONSTRAINT CHILD_FK IMMEDIATE; Constraint set. SQL> SET CONSTRAINT CHILD_FK DEFERRED; Constraint set.