June 30, 2014 at 5:04 am
Im in the process of building my first product dimension for a star schema and not sure if im doing this correctly. A brief explanation of our setup
We have products (dresses) made by designers for specific collections each of which has a range of colors and each color can come in many sizes. For our UK market this equates to some 1.9 million product variants. Flattening the structure out to Product+designer+collection gives about 33,000 records but when you add all the colors and then all the colors sizes it pumps that figure up to 1.9million. My “rolled own” incremental ETL load runs ok just now, but we are expanding into the US market and our projections indicate that our products variants could multiple 10 fold. Im a bit worried about performance of the ETL just now and in the future.
1)Is 1.9m records not an awful lot of records to incrementally load (well analyse) for a dimension table nightly as it is never mind what that figure may grow to when we go to US?
2)I thought of somehow reducing this by using a snowflake but would this not just reduce the number of columns in the dimensions and not the row count?
3)I then thought of separating the colors and size into their own dimension, but this doesn’t seem right as they are attributes of products and also I would lose the relationship between products, size & color I.e. I would have to go through the fact table (which ive read is not a good choice.) for any analysis.
Am I correct in thinking these are big numbers for a dimension table? Is it even possible to reduce the number somhow?
Still learning so welcome any help.
Thanks
June 30, 2014 at 5:38 am
1. Yes, 1,9M rows is quite a lot for a dimension table (especially if you are going tenfold in the US). If you are going to use SCD type 2, this can get even worse.
2. Snowflaking will not help, as you already concluded.
3. This type of modelling is actually not that uncommon and is called mini-dimensions[/url]. They are well documented by Kimball and can reduce the complexity of your set-up enormously.
However, as you already mentioned - the link between the actual dimension and the mini dimension is through the fact table.
This can lead to other issues, such as dresses that have not sold anything. How can you analyze on dresses that have not sold a single piece, because there is not a transaction?
As mentioned in the article I linked to, you can create a factless fact table or something similar to track all the possible products.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 30, 2014 at 5:44 am
Thanks Koen
I was actual reading about these but was not sure if i was on the correct path. In my case would i have a product dimension of granularity Product+designer+collection and then a minidimension holding all the possibly combinations of size and color? what if these combinations change frequently ie. size can be added and removed from color. i guess these would need to be calculated nightly also.
June 30, 2014 at 6:32 am
ps_vbdev (6/30/2014)
Thanks KoenI was actual reading about these but was not sure if i was on the correct path. In my case would i have a product dimension of granularity Product+designer+collection and then a minidimension holding all the possibly combinations of size and color? what if these combinations change frequently ie. size can be added and removed from color. i guess these would need to be calculated nightly also.
Yes and yes.
If you want to do product analyses (not linked to sales/productions/...), then you need to create a factless fact table that just lists all possible combinations.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 30, 2014 at 6:37 am
Excellent, back on track now 🙂
Cheers
June 30, 2014 at 8:46 am
Additionally
If i have one mini-dimension for both color and size this would still give about 5million combinations so could i split this further down to having two mini-dimensions, one for size and one for color feeding into the fact table. otherwise its just sort of moving the problem isnt it?
June 30, 2014 at 2:00 pm
ps_vbdev (6/30/2014)
AdditionallyIf i have one mini-dimension for both color and size this would still give about 5million combinations so could i split this further down to having two mini-dimensions, one for size and one for color feeding into the fact table. otherwise its just sort of moving the problem isnt it?
5 million combinations for sizes and colors? How many colors and sizes are there?
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 30, 2014 at 3:30 pm
I know, i know its crazy, the problem is the colors relay. you see designers have always been allowed to set up there own products so when they are setting up each product the can enter there own flavor of black or they can can get really creative with colors like "Firecracker" or "Valentine".
so there are multiple black, reds, blues etc ontop
the sizes are similar but not as bad but i have seen things like "Up to 6 months" or "5 year old" for childs clothing.
If i group the sizes i can get the 300,000 down to 1000, with the colors 400,00 down to 5000ish but not sure how feasible this would be. Im investigating getting this changed and controlling the color and size creation at our end but this is what ive inherited.
from a knowledge point of view though is it possible to have two or more mini dimension in r.e. my last post?
June 30, 2014 at 3:49 pm
ps_vbdev (6/30/2014)
from a knowledge point of view though is it possible to have two or more mini dimension in r.e. my last post?
It is possible, sure.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
June 30, 2014 at 3:55 pm
ok Koen, ill investigate further, thanks for the help mate..
August 12, 2014 at 6:56 am
Ive been reading a bit further into my kmibal book. in this scenario could the color and size be considered as degenerate dimension ie. not bother have them in the product dimension or in there own dimension but jst load them as degenerates into the fact table?
if so what advantage would this give other than avoiding building and maintaining them as separate dimension?
many thanks.
August 12, 2014 at 7:00 am
ps_vbdev (8/12/2014)
Ive been reading a bit further into my kmibal book. in this scenario could the color and size be considered as degenerate dimension ie. not bother have them in the product dimension or in there own dimension but jst load them as degenerates into the fact table?if so what advantage would this give other than avoiding building and maintaining them as separate dimension?
many thanks.
A degenerate dimension is usually something that does not really belong into a dimension (such as an OrderID or a ticket number) and chances are small it is ever going to be used in an analysis. However, color and size are going to be used in your analyses, so they should be included in some sort of dimension.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply