The Mechanisms of Constraint Checking

in the condition of the CHECK constraint evaluating to false, then the statement is rolled back.

The Check Condition

CHECK constraints enable you to enforce very specific integrity rules by specifying a check condition. The condition of a CHECK constraint has some limitations:

It must be a Boolean expression evaluated using the values in the row being inserted or updated, and

It cannot contain subqueries; sequences; the SQL functi

SYSDATE, UID, USER, or USERENV; or the pseudocolumns LEVEL or ROWNUM.

In evaluating CHECK constraints that contain string literals or SQL functions with globalization support parameters as arguments (such as TO_CHAR, TO_DATE, and TO_NUMBER), Oracle uses the database globalization support settings by default. You can override the defaults by specifying globalization support parameters explicitly in such functions within the CHECK constraint definition.

See Also: Oracle9i Database Globalization Support Guide for more information on globalization support features

Multiple CHECK Constraints

A single column can have multiple CHECK constraints that reference the column in its definition. There is no limit to the number of CHECK constraints that you can define on a column.

If you create multiple CHECK constraints for a column, design them carefully so their purposes do not conflict. Do not assume any particular order of evaluation of the conditions. Oracle does not verify that CHECK conditions are not mutually exclusive.

The Mechanisms of Constraint Checking

To know what types of actions are permitted when constraints are present, it is useful to understand when Oracle actually performs the checking of constraints. To illustrate this, an example or two is helpful. Assume the following:

The employees table has been defined as in Figure 21–7 on page 21-15.

The self-referential constraint makes the entries in the manager_id column dependent on the values of the employee_id column. For simplicity, the rest

Data Integrity 21-21

The Mechanisms of Constraint Checking

of this discussion addresses only the employee_id and manager_id columns of the employees table.

Consider the insertion of the first row into the employees table. No rows currently exist, so how can a row be entered if the value in the manager_id column cannot reference any existing value in the employee_id column? Three possibilities for doing this are:

A null can be entered for the manager_id column of the first row, assuming that the manager_id column does not have a NOT NULL constraint defined

on it. Because nulls are allowed in foreign keys, this row is inserted successfully into the table.

The same value can be entered in both the employee_id and manager_id columns. This case reveals that Oracle performs its constraint checking after the statement has been completely executed. To allow a row to be entered with the same values in the parent key and the foreign key, Oracle must first execute the statement (that is, insert the new row) and then check to see if any row in the table has an employee_id that corresponds to the new row’s manager_id.

A multiple row INSERT statement, such as an INSERT statement with nested SELECT statement, can insert rows that reference one another. For example, the first row might have employee_id as 200 and manager_id as 300, while the second row might have employee_id as 300 and manager_id as 200.

This case also shows that constraint checking is deferred until the complete execution of the statement. All rows are inserted first, then all rows are checked for constraint violations. You can also defer the checking of constraints until the end of the transaction.

Consider the same self-referential integrity constraint in this scenario. The company has been sold. Because of this sale, all employee numbers must be updated to be the current value plus 5000 to coordinate with the new company’s employee numbers.

Because manager numbers are really employee numbers, these values must also increase by 5000 (see Figure 21–10).

21-22 Oracle9i Database Concepts

The Mechanisms of Constraint Checking

Figure 21–10 The EMP Table Before Updates

EMPNO MGR

210

211210

212211

UPDATE employees

SET employee_id = employee_id + 5000, manager_id = manager_id + 5000;

Even though a constraint is defined to verify that each manager_id value matches an employee_id value, this statement is legal because Oracle effectively performs its constraint checking after the statement completes. Figure 21–11 shows that Oracle performs the actions of the entire SQL statement before any constraints are checked.

Figure 21–11 Constraint Checking

The examples in this section illustrate the constraint checking mechanism during INSERT and UPDATE statements. The same mechanism is used for all types of DML statements, including UPDATE, INSERT, and DELETE statements.

The examples also used self-referential integrity constraints to illustrate the checking mechanism. The same mechanism is used for all types of constraints, including the following:

Data Integrity 21-23