Re: Myltiple surrogate keys in one table!

Hi David,

Since both of the "original operational primary keys" allow nulls in the data warehouse, they do not qualify as candidate keys of any kind in that context nor do they qualify as component columns in a compound candidate key. Isn't it true that in this example the only candidate key is the new surrogate key?

Regards,
Bob

David Cressey wrote in message <9C_37.34$x4.2007_at_petpeeve.ziplink.net>...
>Joe,
>
>Ralph Kimball uses the merger of two companies as one reason to use
>surrogate keys for dimension tables in a warehouse, even when the
>operational system is getting along just fine with primary keys drawn from
>the subject matter.
>
>Unless, I'm misreading Kimball, the idea is that, after the merger, the
>warehoused records from each of the two source companies will have two
>columns for the "original operational primary key" from each source, with
>a NULL in the column that doesn't apply, and a single surrogate key for
 the
>dimension table.
>
>That way, the warehouse can survive the merger more readily.
>
>
>--
>Regards,
> David Cressey
> www.dcressey.com
>"--CELKO--" <JOE.CELKO_at_TRILOGY.COM> wrote in message
>news:33254b33.0107121048.6879a40_at_posting.google.com...
>> >> table with more than one surrogate key ... I'm unable to come up
>> with any reasonable justification for 2 surrogate keys in one table.
>> <<
>>
>> The one case I remember was two different catalog numbering systems
>> when two companies in the same industry merged...
Received on Sat Jul 14 2001 - 15:01:57 CDT