Beruflich Dokumente
Kultur Dokumente
Many times readers send questions about how to handle foreign key constraints, when the
primary key constraints on the parent tables have been altered.
Some readers asked for scripts to disable and re-enable foreign key constraints on all of the
tables in a schema, as full/partial schema refreshes across environments are a regular
requirement in databases.
The primary key constraint manager_pk is enforcing a not null constraint on the
jp.manager.mgr_num column.
1 row created.
SQL> commit;
Commit complete.
By default, a foreign key constraint does not enforce a not null constraint on the child table's
column, jp.employee.mgr_num.
1 row created.
The foreign key constraint employee_fk did not allow us to insert value 2 into the
jp.employee.mgr_num column, instead giving us the error "parent key not found".
However, the said foreign key constraint employee_fk allowed us to insert a null value in the
jp.employee.mgr_num column. How can this be possible?
As per RDBMS definition, the value of null is unknown or undefined. Null is not equal to anything.
A null is not equal to another null.
As such, Oracle does not know how to check for a matching record in the parent table
jp.manager.mgr_num column, that matches with the null value in the child in the
jp.employee.mgr_num column.
To safeguard our data from this scenario, please enable a not null constraint on the
jp.employee.mgr_num column.
Now the prikery key constraint manager_pk on mgr_num and mgr_name of jp.manager table is
enforcing not null constraints on both mgr_num and mgr_name columns.
Now let's recreate the emplyee_fk foreign key constraint on jp.employee table.
Since there is no primary key constraint or unique constraint enabled on the column
jp.manager.mgr_num column exclusively, the employee_fk foreign key constraint could not be
enabled on the jp.employee table.
Let's first add a unique constraint on the jp.manager.mgr_num column and later add the primary
key constraint on jp.manager.mgr_num and jp.manager.mgr_name columns.
Only a primary key constraint enforces a not null constraint on the tables' columns,
a unique constraint does not enforce a not null constraint on the tables' columns.
To safeguard and validate the data, it is a good practice to enable a not null constraint on the
columns, where a unique constraint is created.
Since the primary key constraint on mgr_num and mgr_name columns will enforce not null
constraints, our requirement is met.
alter table jp.manager add (constraint manager_pk primary key (mgr_num,mgr_name));
Now we can add the employee_fk foreign key constraint on the jp.employee table.
Now I want to truncate all the tables in JP's schema and refresh with import from the production
db.
COUNT(1)
----------
1
COUNT(1)
----------
2
The following scripts disable all foreign key constraints and truncate the tables in a particular
schema and re-enable the foreign key constraints.
COUNT(1)
----------
0
COUNT(1)
----------
0
CONSTRAINT_NAME STATUS
------------------------------ --------
SYS_C0032318 ENABLED
EMPLOYEE_FK DISABLED
CONSTRAINT_NAME STATUS
------------------------------ --------
SYS_C0032318 ENABLED
EMPLOYEE_FK ENABLED
COUNT(1)
----------
1
COUNT(1)
----------
2
Taking into consideration reader's views and requirements, I thought that I would revisit my
article "FINDING FOREIGN KEY CONSTRAINTS" and fill in the gaps. Hence this article "FOREIGN
KEY CONSTRAINTS REVISITED".