Re: Surrogate Keys
Date: Sat, 30 Sep 2000 17:34:15 GMT
Message-ID: <rupB5.859$q4.75057_at_petpeeve.ziplink.net>
Use surrogate keys only when needed. But they are needed in a wide variety
of
situations. In general, whenever the entity that issues the "real" keys
might screw up,
you need a surrogate key.
Two examples:
Don't use Social Security numbers to identify employees. Once in a blue
moon,
the Social Security Administration screws up, and issues the same number
twice.
Also, you won't be able to register an employee who has no SSN, or whose
SSN is unavailable. So you use a key like "employee id". In this case, the
employee id is, arguably, not a surrogate key. It's probably issued by HR
and
not by IT.
Another case is when you have a star schema in a data warehouse or a data
mart.
Always use surrogate keys to link the dimension tables to the fact tables.
If the
star schema is loaded from a well built relational OLTP system, you may be
tempted
to use the same keys that it uses.
Resist the temptation. The warehouse or mart may outlive the source system,
and the replacement system may have a completely different keying scheme.
Also, you can't make your dimension tables time varying if the source
system
keys don't permit that.
dhussein_at_my-deja.com wrote in message <8qrd0t$n9j$1_at_nnrp1.deja.com>...
>Hi,
>
>I need to know your opinion on using Surrogate
>Keys.
[snip]
Received on Sat Sep 30 2000 - 19:34:15 CEST