ADVANTAGES OF SURROGATE KEYS

This is referred from The Data Warehouse Toolkit, Kimball

One of the primary benefits of Surrogate keys is that they buffer the data warehouse environment from operational changes. Surrogate keys allow the warehouse team to maintain control of the environment rather than being whipsawed by operational rules for generating, updating, deleting, recycling, and reusing production codes. In many organizations, historical operational codes (for example, inactive account numbers or obsolete product codes) get reassigned after a period of dormancy. If account numbers get recycled following 12 months of inactivity, the operational systems don’t miss a beat because their business rules prohibit data from hanging around for that long.

The data warehouse, on the other hand, will retain data for years. Surrogate keys provide the warehouse with a mechanism to differentiate these two separate instances of the same operational account number. If we rely solely on operational codes, we also are vulnerable to key overlap problems in the case of an acquisition or consolidation of data. Surrogate keys allow the data warehouse team to integrate data from multiple operational source systems, even if they lack consistent source keys.

Finally, surrogate keys are needed to support one of the primary techniques for handling changes to dimension table attributes.

What is Surrogate key in OBIA AND Advantage of surrogate keys

Surrogate key is the primary key for the Dimensional table. Surrogate key is a substitution for the natural primary key.It is just a unique identifier or number for each row that can be used for the primary key to the table.The only requirement for a surrogate primary key is that it is unique for each row in the table. 

Data warehouses typically use a surrogate,(also known as artificial or identity key), key for the dimension tables primary keys.They can use sequence generator, or Oracle sequence, or SQL Server Identity values for the surrogate key.It is useful because the natural primary key (i.e. Customer Number in Customer table) can change and this makes updates more difficult.

Some tables have columns such as AIRPORT_NAME or CITY_NAME which are stated as the primary keys (according to the business users) but ,not only can these change, indexing on a numerical value is probably better and you could consider creating a surrogate key called, say, AIRPORT_ID. This would be internal to the system and as far as the client is concerned you may display only the AIRPORT_NAME.

Also read about ADVANTAGES OF SURROGATE KEYS