Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
coolerbob
Aged Yak Warrior
841 Posts |
 Posted - 2008-05-21 : 06:37:49
|
| I only see a need for a PK in a dimension table, not a fact table. Do you agree? |
|
|
rmiao
Master Smack Fu Yak Hacker
7266 Posts |
Posted - 2008-05-21 : 22:03:12
|
| Yes in most case. |
 |
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2008-05-29 : 12:43:22
|
| Thinking about it a little more, in most cases, while the table may not need its own PK, you'd want to store the PK from the source table (So, in Kimball language, that's the business or natural key). Otherwise you'll have trouble singling out a fact for add/update/delete in the data warehouse. |
|
|
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2008-05-29 : 12:50:49
|
quote:
Originally posted by coolerbob
Thinking about it a little more, in most cases, while the table may not need its own PK, you'd want to store the PK from the source table (So, in Kimball language, that's the business or natural key). Otherwise you'll have trouble singling out a fact for add/update/delete in the data warehouse.
Most cases it wont be the PK from source but it would be a surrogate key generated in respective dimension that would be stored in fact. |
|
|
|
coolerbob
Aged Yak Warrior
841 Posts |
Posted - 2008-05-29 : 17:45:47
|
| Yes, that's a given. I mean in addition to that, you may want to store the transaction id for example in the fact table. That's got nothing to do with the dimension surrogate key. |
|
|
|
|
|
|
|
|
PK in fact table