crm issue in The DataWareHouse Toolkit 2nd edition
Page 1 of 1
crm issue in The DataWareHouse Toolkit 2nd edition
hi,
I'm a newcomer in the world of BI and I have recently started to read The Datawarehouse Toolkit : a guide to dimensional modelling (2nd Edition).
In Chapter 6, page 158, there is something that puzzles me.
A dimensional model for a CRM-system is diagrammed as follows :
Table FactTable ( ContactKey FK, ExtendedCustomerKey FK, more foreign keys ..... )
Table ContactDimension ( Contact Key PK, ..........., ExtendeCustomerKey FK )
Table ExtendedCustomerDimension ( ExtendedCustomerKey PK, ............... )
To me it seems this example is modelled wrong.
What puzzles me is the foreign key in the table ContactDimension which points to the ExtendedCustomerDimension table.
Why is it there ?
Personally, i would follow it as follows :
FactTable ( ContactKey FK, ExtendedCustomerKey FK, ......)
ContactDimension ( ContactKey PK FK, .......)
ExtendedCustomerDimension ( ExtendedCustomerKey PK, ........)
By setting a foreign key constraint on the primary key of ContactDimension I would create a 1 on 0-1 relation.
So 1 row in ContactDimension equals 1 particular row in ExtendedCustomerDimension but not the other way around.
Is there any reason why Ralph Kimball opts to not model this example in this way ?
Because now he uses a plain old Foreign Key which renders the relation a 1 on many relation.
I'm a newcomer in the world of BI and I have recently started to read The Datawarehouse Toolkit : a guide to dimensional modelling (2nd Edition).
In Chapter 6, page 158, there is something that puzzles me.
A dimensional model for a CRM-system is diagrammed as follows :
Table FactTable ( ContactKey FK, ExtendedCustomerKey FK, more foreign keys ..... )
Table ContactDimension ( Contact Key PK, ..........., ExtendeCustomerKey FK )
Table ExtendedCustomerDimension ( ExtendedCustomerKey PK, ............... )
To me it seems this example is modelled wrong.
What puzzles me is the foreign key in the table ContactDimension which points to the ExtendedCustomerDimension table.
Why is it there ?
Personally, i would follow it as follows :
FactTable ( ContactKey FK, ExtendedCustomerKey FK, ......)
ContactDimension ( ContactKey PK FK, .......)
ExtendedCustomerDimension ( ExtendedCustomerKey PK, ........)
By setting a foreign key constraint on the primary key of ContactDimension I would create a 1 on 0-1 relation.
So 1 row in ContactDimension equals 1 particular row in ExtendedCustomerDimension but not the other way around.
Is there any reason why Ralph Kimball opts to not model this example in this way ?
Because now he uses a plain old Foreign Key which renders the relation a 1 on many relation.
bermic- Posts : 1
Join date : 2012-02-24
Similar topics
» Indexing option on numeric fact referred to in DW Toolkit 2nd edition
» Halfway through the Data Warehouse Toolkit 3rd Edition book. Should I get the other books as well?
» The great SQL query "template" from edition 1 of Data Warehouse Toolkit
» Ebook The Data Warehouse Lifecycle Toolkit, 2nd Edition: Practical Techniques for Building Data Warehouse and Business Intelligence Systems
» Business Requirements Document
» Halfway through the Data Warehouse Toolkit 3rd Edition book. Should I get the other books as well?
» The great SQL query "template" from edition 1 of Data Warehouse Toolkit
» Ebook The Data Warehouse Lifecycle Toolkit, 2nd Edition: Practical Techniques for Building Data Warehouse and Business Intelligence Systems
» Business Requirements Document
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum