What is Referential Integrity?
Referential integrity defines relationships between tables based on primary and foreign keys. It describes the columns in the referencing table, which are a
foreign key in the referenced table.
Referential integrity is a robust mechanism to ensure data consistency in a database.
What is Soft Referential Integrity?
Soft Referential Integrity hints to the Optimizer that a relationship between tables exists. The Optimizer will rely on this information; it will not enforce referential integrity but assumes that the user ensures it.
How is Soft Referential Integrity used?
Soft Referential Integrity is used for INNER JOIN Elimination in views.
Suppose we select only columns from the referencing table (primary key side) of a view containing an inner join with soft referential integrity defined between two tables. In that case, the Optimizer can avoid the inner join. Here is an example:
REPLACE VIEW TradeInfo AS
t01.TraderId = t02.TraderId
We assume a primary key (Trader) / foreign key (Trades) soft referential integrity defined in column TraderId.
If we execute the below SQL statement, the Optimizer will not join to table “Trades”, as all referenced columns are from table “Trader”, and the defined soft referential integrity ensures that each row in “Trades” will be available in “Trader”. Therefore, there is no need to “filter” non-matching rows with the INNER JOIN.
We could use “hard” referential integrity to achieve the join elimination, but enforcing “hard” referential integrity causes performance overhead we may want to avoid. Teradata soft referential integrity helps to improve performance.
One important fact about “soft” referential integrity has to be pointed out: The Optimizer trusts that we ensure the integrity of the relationship!
The syntax to define soft referential integrity is as follows. The column’s data type has to be the same for both tables, and the referenced column has to be indexed uniquely:
REFERENCES WITH NO CHECK OPTION TradeAccount(TraderId),
) UNIQUE PRIMARY INDEX (TraderId)
How can we identify if table has soft or Hard RI using DBC tables?
The explain plan will only show what it is going to do, the explain will not show what is considered but left behind.
1) Soft RI requires that the fields are EXACTLY the same. Physical design is important. I ran across a STORE_ID CHAR(4) and STORE_ID VARCHAR(4). That was not allowed…
2) Soft RI is a must for Join Indexes (JI). Maybe only certain types, but see here for an example: https://developer.teradata.com/blog/mtmoura/2011/01/lets-talk-about-aggregate-join-indexes-aji
Either I skipped large parts of Teradata manuals, or this subject is not so covered. It took me some time to figure out why an (A)JI was not used in a query.
2 points from the site above:
– The parent key columns must be either a unique primary index (UPI) or a unique secondary index (USI).
– The foreign and parent keys must have the same number of columns and their data types must match.
I am not sure if there is a special “hint” in the execution plan that the soft RI is used. Maybe somebody else can answer this?
Of course, you can see that soft RI is used, as the join steps are missing in the plan. But of course, this can be difficult to find out for huge plans.
Thanks for the Article, My question is is there any keyword in the Explain Plan to see if the soft RI is being used for join elimination? Trying to find if it’s possible to know soft-RI being used by Optimizer for JOIN elimination for a query with complex join involving many tables with soft RIs on it. I appreciate the help.