Snowflake scenarios
3 posters
Page 1 of 1
Snowflake scenarios
Had seen a few places where dimensions were snowflaked.
But how do we figure out that these snowflaked dimensions are justified?
Specify scenarios where snowflaking is acceptable.
Thanks in advance,
bi_at_nj
But how do we figure out that these snowflaked dimensions are justified?
Specify scenarios where snowflaking is acceptable.
Thanks in advance,
bi_at_nj
bi_at_nj- Posts : 14
Join date : 2009-10-31
RE: Snowflake scenarios
Snowflaking happens when one dimensional attribute is linked to a fact through an intermmediate dimension.
For Eg: Consider AdventureWorksDB(SQLServer) as an example and take DimCustomer,DimGeography,DimProduct,DimProductCategory,DimTime as Dimensions and FactInternetSales as Fact table.
There you can find DimGeography is linked to DimCustomer through a Foreign Key. However if you want to fetch data like how is the sales spread over different geographies, there will not be any direct foreign Key in FactInternetSales table associated to DimGeography. However the requirement can still be catered by have DimCustomer as a referenced Dimension which acts as an intermmediate/referenced dimension to look at Sales performance over geographies.
In simpler mathematical example say
we have Ax + By = 0 and Ax + C = 0,
we can get a equation relating y,z variables (By - C = 0). Same is the case here (Ignore this example if it is confusing you). Through a reference dimension that is possible with Snowflake schema, we can establish a relationship to fact table.
In the same above example, DimProductCategory is linked to FactInternetSales only though DimProduct. Thus by having DimProduct as referenced dimension we can achieve the sales of each product category also.
For Eg: Consider AdventureWorksDB(SQLServer) as an example and take DimCustomer,DimGeography,DimProduct,DimProductCategory,DimTime as Dimensions and FactInternetSales as Fact table.
There you can find DimGeography is linked to DimCustomer through a Foreign Key. However if you want to fetch data like how is the sales spread over different geographies, there will not be any direct foreign Key in FactInternetSales table associated to DimGeography. However the requirement can still be catered by have DimCustomer as a referenced Dimension which acts as an intermmediate/referenced dimension to look at Sales performance over geographies.
In simpler mathematical example say
we have Ax + By = 0 and Ax + C = 0,
we can get a equation relating y,z variables (By - C = 0). Same is the case here (Ignore this example if it is confusing you). Through a reference dimension that is possible with Snowflake schema, we can establish a relationship to fact table.
In the same above example, DimProductCategory is linked to FactInternetSales only though DimProduct. Thus by having DimProduct as referenced dimension we can achieve the sales of each product category also.
Prasanna- Posts : 6
Join date : 2009-10-20
Re: Snowflake scenarios
Generally speaking, snowflaking should be avoided. It's easy enough to do. There are, however, some situations where snowflaking makes sense. Ralph has written a few articles on those situations. I suggest you search this site for his thoughts on the subject.
Similar topics
» Specify acceptable Snowflaking scenarios
» master-detail scenarios
» Snowflake issue
» Snowflake & Factless fact
» Dimensions Directly Tied to Facts vs. Snowflaking
» master-detail scenarios
» Snowflake issue
» Snowflake & Factless fact
» Dimensions Directly Tied to Facts vs. Snowflaking
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum