3

Teradata Surrogate Keys Guidelines

What are Teradata Surrogate Keys?

Surrogate keys are used in Teradata to map the natural keys of source systems to a unique key.

Usually, one or more natural key columns are mapped to a surrogate key that is worth an INTEGER. Often a consecutive number is generated.

In Teradata, the ROW_NUMBER() function can be used, or an IDENTITY column.

The advantage of an IDENTITY column is that a new surrogate key is generated by the system as soon as a row is inserted into the key table.

However, it is important to define the IDENTITY column so that no duplicates are created.

For this, the IDENTITY column must be defined with GENERATED ALWAYS and NO CYCLE.

GENERATED always prevents the surrogate key column from being updated, NO CYCLE prevents the reuse of values – If the highest possible number for an integer data type is reached, no new surrogate keys can be generated and an error is reported.

Detailed information about IDENTITY columns is available in table DBC.IdCol

Disaster Reload of Key Tables with IDENTITY columns

If a key table that uses IDENTITY columns has to be reloaded, please pay attention to the following to avoid duplicates:

  • The key table needs to be re-created with a new START and MINVALUE numbers to exclude the numbers that were generated before to avoid the same number to be generated again.
  • The definition of the identity column needs to be changed from “GENERATED ALWAYS” to “GENERATED BY DEFAULT” to be able to reload the keys that were generated before.
  • New surrogate keys will be generated only when NULL values are passed to the identity column.

Here is an example where the highest value of the IDENTITY column is 200,000:

CREATE MULTISET TABLE TheKeys 
(
   NATURAL_KEY VARCHAR(500) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
   SURROGATE_KEY BIGINT GENERATED ALWAYS AS IDENTITY
   (START WITH 1 INCREMENT BY 1 
    MINVALUE -999999999999999 
    MAXVALUE 999999999999999 
    NO CYCLE),
)
UNIQUE PRIMARY INDEX (NATURAL_KEY);

If we need to reload the key table the following DDL is required:

CREATE MULTISET TABLE TheKeys 
(
   NATURAL_KEY VARCHAR(500) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL,
   SURROGATE_KEY BIGINT GENERATED BY DEFAULT AS IDENTITY
   (START WITH 1 INCREMENT BY 1 
    MINVALUE 200000 
    MAXVALUE 999999999999999 
    NO CYCLE),
)
UNIQUE PRIMARY INDEX (NATURAL_KEY);

Why should you use Surrogate Keys?

There are several reasons why it is a good idea to replace the natural keys with Teradata surrogate keys.

Different source systems deliver the same natural key for different information.

You may have more than one source system delivering the same value in the natural key for the same target table but with a different meaning.

This fact requires you to use surrogate keys because keeping the natural key from both sources would not allow you to distinguish the objects.

Different source systems deliver a different natural key for the same information.

But it can also be that the same information comes from different source systems with different natural keys. For example, the customers of a bank may be kept in different source systems. If it is necessary to represent these as a single customer in the data warehouse, surrogate keys are perfectly suited for this.

Unfortunately, many Teradata data warehouse implementations decide against surrogate keys and put the effort of integrating the information into the reports.

This approach will ultimately cause more costs than having a right surrogate key design from the begin (don’t forget, such an approach requires to repeat the logic of combining object information into each and every single report).

Exchange of Source System leads to the Delivery of new Natural Keys.

If the natural keys of the source system are used, and you undergo a replacement of the original system you end up in a bad situation.

In this case, let’s compare the effort caused by it.

If we have surrogate keys available, only the mapping table (Natural Keys -> Surrogate Keys) has to be adjusted, all surrogate keys have to be assigned once to the new natural keys.

If we only have the natural keys available in our data warehouse, this usually means a complete re-design. The old natural keys must be replaced everywhere by the new natural keys!

In general, you never should tightly couple your data model to the source system structures. An invoice table should be called Invoice and not something like SAP-Invoice. Data Warehousing is not the 1:1 storage of operational data.

At the begin of a project, it is always more agile to avoid surrogate keys and integrate source system tables 1:1.

However, this only shifts costs to the end of the chain. Changes that have to be made afterward are many times more expensive!

Teradata Surrogates Keys and Performance

Surrogate keys, if properly used, may increase your performance as you can replace several natural key columns by an integer column.

Often, natural key columns are character columns. From a performance point of view, this makes no difference for the hashing of the primary index. Where there is a negative effect on performance, however, is with joins, since Teradata must take character sets, etc. into account here.

Depending on the number of columns and data types of the natural key, this can have a negligible impact on performance or a noticeable effect.

Roland Wenzlofsky
 

Roland Wenzlofsky is a graduated computer scientist and Data Warehouse professional working with the Teradata database system for more than 15 years. He is experienced in the fields of banking and telecommunication with a strong focus on performance optimization.

  • Avatar naga says:

    can you please let me know about bkey and bmap genearation? and waht they a re

  • Avatar Naushad says:

    Terdata and few td consultants have fooled organisations with this concept and complicated simple things. Simple surrogate key is to maintain slowly changing dimensions and not for integration of different sources as said in this post. If integration was purpose like example of customer lifecycle then its a separate topic of master data management, dont try to mix all master data , metadata(gcfr) and all things in one and complicate things. I have seen organisations sufferinf becoz of such design and majorly some pakistani consultants have been ruling these confusions and securing their jobs and sucking clients money.
    Honestly teradata is amazing product but design it right way and keep it simple

    • I give you an example, and would kindly ask you to tell me how you would design the model without surrogate keys: You have two billing systems, invoices have to be stored in the same entity (“Invoice”). Natural keys of both billing systems are overlapping. How would you design the “Invoice” table without surrogate keys?

  • >