Teradata Surrogate Keys Guidelines

Roland Wenzlofsky

November 19, 2019

minutes reading time

What are Teradata Surrogate Keys?

A surrogate key in Teradata maps the natural keys of source systems to a unique key, usually an integer value.

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

We can use the ROW_NUMBER() function for a surrogate key in Teradata or an IDENTITY column. Click below for the article about identity columns:

An IDENTITY column’s advantage is that the system generates a new surrogate key when a row is inserted into the key table.

However, it is essential to define the IDENTITY column to create no duplicates.

We must define the IDENTITY column with GENERATED ALWAYS and NO CYCLE.

GENERATED always prevents the surrogate key column from being updated. NO CYCLE precludes the reuse of values. If the highest possible number for an integer data type is reached, Teradata can generate no new surrogate keys, 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 new START and MINVALUE numbers to exclude the numbers generated before to avoid the same number being generated again.
  • The identity column definition needs to be changed from “GENERATED ALWAYS” to “GENERATED BY DEFAULT” to be able to reload the keys that Teradata 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:

    MINVALUE -999999999999999 
    MAXVALUE 999999999999999 
    NO CYCLE),

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

    MINVALUE 200000 
    MAXVALUE 999999999999999 
    NO CYCLE),

Why should you use Surrogate Keys?

There are several reasons why replacing the natural keys with Teradata surrogate keys is good.

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 requires using 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 other natural keys. For example, the customers of a bank may be kept in different source systems. Surrogate keys are ideally suited if it is necessary to represent these as a single customer in the data warehouse.

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

This approach will ultimately cause more costs than having the right surrogate key design from the beginning (don’t forget, such an approach requires repeating the logic of combining object information into every report).

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

If the source system’s natural keys 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, we must adjust only the mapping table (Natural Keys -> Surrogate Keys). 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. The old natural keys must be replaced everywhere by the new natural keys!

You should never 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 beginning 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

If properly used, surrogate keys may increase your performance as you can replace several natural key columns with 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. However, there is a negative effect on performance with joins since Teradata must take character sets, etc., into account here.

The number of columns and data types of the natural key can negatively impact performance or have a noticeable effect.

  • Avatar
    Aleksey Svitin says:


    It’s another excellent article. Thank you.

    I would also add
    – Surrogate ids are important elements for Data vault modeling
    – Surrogate ids are must have for tables with complex natural key or for combining different sources(like Original_Id + Source_Id) as Roland says.
    – For many cases, the performance is better with surrogate id because they could be smaller in size (e.g. one INT column vs a couple of varchar columns + source_id), thus joining/grouping is faster.
    – The most important performance benefit is related to”attribute” or dimension tables which is used by “fact” tables. It’s not obvious. Let’s assume we have “small” Country table. Every country has unique string code. We can use this code as a primary key.
    Let’s assume that we have a “big” fact table (translations, mobile calls or anything else) which should have reference to Country table.
    If we use Country_Code as PK when we will use it in dependent fact table as well. But string Country_Code will be always bigger in size than alternative numeric surrogate key. So this difference will be multiplied by number of rows in fact table ( which could be in billions). So it’s very important to have as small PK as possible for dimensions and surrogate keys help a lot here.
    – Personally, I like the approach, when a system should use own “small” internal entity identifiers (generated internally) everywhere inside and GUIDs or natural keys for External communication. It gives both flexibility, strong performance and solid data model.

    It’s just my experience.

    Have a good day!

    Best regards,
    Aleksey Svitin.

    • Hi Aleksey,

      Thanks for your comment.

      Right now I am “eyewitnessing” a total misdesign of a data mart where not using surrogate keys leads to significant problems.

      The data is both delivered from the source system and sent back to it and re-sent a second time. But the format is changed when the data is sent a second time. This is really about little things like spaces etc.

      Since the information from the source system has not been normalized (more than one piece of information is stored in a column), the result is that every join in every SQL must be done with string functions. From a performance point of view a disaster. The optimizer cannot use statistics and fights with full table scans. An elegant solution with surrogate keys at the beginning of the ETL chain could have prevented this.

      – Roland

  • 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”). The natural keys of both billing systems are overlapping. How would you design the “Invoice” table without surrogate keys?

      • Avatar
        Boris Mogilevsky says:

        Conceptually, surrogate keys have a say but using Identity columns for this purpose is a big problem. Their definitions are tied to Hash map which will change in case if the Box needs to be re-configured, for example when there is an upgrade. I personally was in a project where everything has been built using Surrogate Keys based on Identity and there were lots of issues.

        • Avatar
          Алексей Свитин says:

          Hi Boris,

          As a solution, I can suggest to generate Ids during ETL stage instead of relying on Identity column ( which has many side effects) . We use Informatica for that purpose. It works pretty well.

          With best regards,
          Aleksei Svitin

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

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

    You might also like