How to handle a Type I or II dimension with a snowflaked customer sub dimension (kimball book page 337, 338)
Page 1 of 1
How to handle a Type I or II dimension with a snowflaked customer sub dimension (kimball book page 337, 338)
Hello,
Within Ralph his new book he describes recommanded situations for snowflaking a dimension. His example is a large customer (visitor) dimension. (page 337, 338 and figure 10-6). I find the artical good, but there is missing one part of this solution -> how to implement this within the ETL boundaries described by kimball.
Im very interested how to manage the type I and / or type II mutations within this construction. Are there any limitations to this constructions (for example in the snowflake sub dimension there cannot be any type II fields etc..)
In which sequence will the data arrive in the dimension (sub) tables, first load the customer dimension and the insert all the records based on the sub snowflake key within the snowflake sub dimension? There is not much information on how to ETL this kind of constructions.
Hope the writers of the book can clear this out for me :-)
Thanks in advantage!
Regards
Joey Moelands.
Within Ralph his new book he describes recommanded situations for snowflaking a dimension. His example is a large customer (visitor) dimension. (page 337, 338 and figure 10-6). I find the artical good, but there is missing one part of this solution -> how to implement this within the ETL boundaries described by kimball.
Im very interested how to manage the type I and / or type II mutations within this construction. Are there any limitations to this constructions (for example in the snowflake sub dimension there cannot be any type II fields etc..)
In which sequence will the data arrive in the dimension (sub) tables, first load the customer dimension and the insert all the records based on the sub snowflake key within the snowflake sub dimension? There is not much information on how to ETL this kind of constructions.
Hope the writers of the book can clear this out for me :-)
Thanks in advantage!
Regards
Joey Moelands.
J.Moelands- Posts : 2
Join date : 2010-05-09
Similar topics
» dimension attribute denormalisation in fact table
» Kimball or not Kimball type 2 dimension (sk as primary key)
» bridge table and junk dimension on customer dimension (bank/credit union)
» Merging customer data from disparate sources to create a master customer dimension
» De-normalizing Customer Information to create a Customer Dimension
» Kimball or not Kimball type 2 dimension (sk as primary key)
» bridge table and junk dimension on customer dimension (bank/credit union)
» Merging customer data from disparate sources to create a master customer dimension
» De-normalizing Customer Information to create a Customer Dimension
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum