15.00 - Scenario for Data Corruption With Referential Constraints - Teradata Database

Teradata Database SQL Data Definition Language Detailed Topics

Product
Teradata Database
Release Number
15.00
Content Type
Programming Reference
Publication ID
B035-1184-015K
Language
English (United States)

Scenario for Data Corruption With Referential Constraints

Always exercise caution when manipulating data within an unenforced Referential Constraints environment. If you define referential relationships using unenforced Referential Constraints, then INSERT, DELETE, and UPDATE requests can corrupt data in the parent tables of those relationships if the DML request contains a redundant RI join and the PK‑FK row pairs for the eliminated join do not match. The RI join is eliminated based on the assumption that PK=FK, and non‑valid results are returned in SELECT results or incorrect updates are made to the database.

For example, suppose you have the following 2 tables related by means of a Referential Constraint between col_2 in child table table_2 and col_1 in parent table table_1.

    CREATE TABLE table_1 (
     col_1 INTEGER NOT NULL, 
     col_2 INTEGER
    UNIQUE PRIMARY INDEX (col_1));
 
    CREATE TABLE table_2 (
     col_1 INTEGER, 
     col_2 INTEGER, 
    FOREIGN KEY (col_2) REFERENCES WITH NO CHECK OPTION table_1(col_1));

Insert some rows into table_1 and table_2. Assume that the populated tables now look like this.

 

table_1

 

table_2

PK

 

 

 

FK

col_1

col_2

 

col_1

col_2

1

2

 

5

6

2

2

 

6

7

3

2

 

7

8

The defined referential relationship between the tables specifies that each value for col_2 in table_2 should correspond to an identical value in col_1 of table_1.

Because the system is instructed not to enforce referential integrity for this relationship, the unpaired table_2.col_2 values are accepted for insertion even though they violate the defined constraint on the relationship. At this point, referential integrity errors have been introduced, but equally importantly, the preconditions for further data corruption have been set.

Suppose you now want to update table_2 using the following UPDATE request.

    UPDATE table_2 
    SET col_1=1 
    WHERE table_1.col_1=table_2.col_2;

Because table_2.col_2 references table_1.col_1 WITH NO CHECK OPTION, this update eliminates the table_1.col_1 = table_2.col_2 join, thus ignoring the specified WHERE clause condition filter, and then incorrectly updates all rows in table table_2 with a col_1 value of 1, corrupting the database.