Teradata Soft Referential Integrity

Roland Wenzlofsky

March 14, 2017

minutes reading time

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:

Trader t01
TradeAccount t02
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:

TraderName VARCHAR(255),

TraderCountry CHAR(03)

  • How can we identify if table has soft or Hard RI using DBC tables?

  • Avatar
    Johannes Vink says:

    The explain plan will only show what it is going to do, the explain will not show what is considered but left behind.

    Few observations:
    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.

  • Avatar
    Washim Nawaz says:

    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.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    You might also like