parent child dimension model
Page 1 of 1
parent child dimension model
What is the best option for the parent child dimension model in the below scenario.
Option 1:
* Keep the dimension tables similar to source tables and include dimension key
Option 2:
* Keep the dimension tables similar to source tables and include dimension key
* Repeat the higher level attributes in lower level tables.
Option 3:
* Snow flaking dimension.
Option 4:
* Snow flaking dimension.
* Repeat the higher level attributes in lower level tables.
Option 1:
* Keep the dimension tables similar to source tables and include dimension key
Option 2:
* Keep the dimension tables similar to source tables and include dimension key
* Repeat the higher level attributes in lower level tables.
Option 3:
* Snow flaking dimension.
Option 4:
* Snow flaking dimension.
* Repeat the higher level attributes in lower level tables.
Guest- Guest
Re: parent child dimension model
How about option 5: A single Product dimension table that contains category and subcategory attributes?
Re: parent child dimension model
Thanks for the new option ngalemmo.
I think you mention the "Product" table in Option2 or Option4.
But we have facts in Category and Sub Category levels as well.
Could you suggest which option is suitable in this case.
I think you mention the "Product" table in Option2 or Option4.
But we have facts in Category and Sub Category levels as well.
Could you suggest which option is suitable in this case.
Guest- Guest
Re: parent child dimension model
Option 2... sorry I did not look that close and was thinking just a single dimension table.
However, since you have other facts that are at one of these other grains, you need dimension tables for those as well. There would be no relationship between these tables. Different facts would reference the dimension appropriate for its grain. Facts would be combined based on conforming attribute values.
The other thing is the alternate key designation is confusing. The only alternate key a dimension should have is it's natural key. So, in the Product table, the alternate key is the product code (natural key). Category and subcategory codes are attributes, not part of any key to the table.
However, since you have other facts that are at one of these other grains, you need dimension tables for those as well. There would be no relationship between these tables. Different facts would reference the dimension appropriate for its grain. Facts would be combined based on conforming attribute values.
The other thing is the alternate key designation is confusing. The only alternate key a dimension should have is it's natural key. So, in the Product table, the alternate key is the product code (natural key). Category and subcategory codes are attributes, not part of any key to the table.
Similar topics
» hierarchical or parent child dimension?
» Dimension hierarchies having One child multiple parent
» Self referencing dimension - How to store Parent Key/Id as type II change
» Dimension with hierarchical data - how to handle parent with no children
» How to Model Single-Table Parent-Child Relational Table in a Dimensional Schema
» Dimension hierarchies having One child multiple parent
» Self referencing dimension - How to store Parent Key/Id as type II change
» Dimension with hierarchical data - how to handle parent with no children
» How to Model Single-Table Parent-Child Relational Table in a Dimensional Schema
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|