Column count on dimension table
4 posters
Page 1 of 1
Column count on dimension table
I'm currently modeling a star schema for data mart and fairly new to the process. I have one dimension (dim_Request) that has a lot of columns (276). Is there a breaking point in the number of columns recommended for a dimension? Do I need to normalize this dimension to get the column number down?
Thanks
DMMay
Thanks
DMMay
DMMay- Posts : 1
Join date : 2013-03-08
Re: Column count on dimension table
Column count isn't a determining factor per-se. But, you should go through an exercise to see where you may have embedded useful dimensions in the table.
There is also a common design error where dimensions are misused to record events. That is the domain of a fact table. Is your dimension describing the request or is it recording the request?
There is also a common design error where dimensions are misused to record events. That is the domain of a fact table. Is your dimension describing the request or is it recording the request?
Re: Column count on dimension table
ngalemmo wrote: Is your dimension describing the request or is it recording the request?
Describing vs Recording - I like it. This is an effective way to differentiate the thinking about dimensions versus facts. Recording is more appropriate than "Measuring".
LAndrews- Posts : 132
Join date : 2010-05-13
Location : British Columbia, Canada
Re: Column count on dimension table
Yes, describing vs. recording is interesting.
I have a (type 2) dimension that represents a service agreement. In the OLTP system, this entity has a repeating attributes child table for a rate code and effective date. The rate code is a FK to a rate schedule entity table. So this child table is a M:M join table.
From your description, it sounds like this is recording an event. But in the OLTP system, the application allows them to change the rate code for a historical (not most current) effective date.
How would you model this? Should this repeating data be a) flattened in the service agreement dimension or b) create a snowflaked dimension where these "events" are in a child dimension or c) stored as facts? I'm uncertain how a changed (corrected) historical rate code would work in a fact table. We would want to know that this change was made (and when). So I'd prefer to go with option A since the type 2 model would record the event change. The problem with flattening is deciding on the limit (number of repeating entries) since column changes in a dimension are an expensive change.
Thoughts?
I have a (type 2) dimension that represents a service agreement. In the OLTP system, this entity has a repeating attributes child table for a rate code and effective date. The rate code is a FK to a rate schedule entity table. So this child table is a M:M join table.
From your description, it sounds like this is recording an event. But in the OLTP system, the application allows them to change the rate code for a historical (not most current) effective date.
How would you model this? Should this repeating data be a) flattened in the service agreement dimension or b) create a snowflaked dimension where these "events" are in a child dimension or c) stored as facts? I'm uncertain how a changed (corrected) historical rate code would work in a fact table. We would want to know that this change was made (and when). So I'd prefer to go with option A since the type 2 model would record the event change. The problem with flattening is deciding on the limit (number of repeating entries) since column changes in a dimension are an expensive change.
Thoughts?
pnosko- Posts : 1
Join date : 2013-03-15
Similar topics
» Advice on a single Fact Table Column which could link to more than one different dimension
» Is it possible to get a distinct order count with a transaction line sales fact table?
» Dimensional table design dilemma, Aditional column or Xref table
» Question for count in fact table
» Finding the grain with One-To-Many fact tables.
» Is it possible to get a distinct order count with a transaction line sales fact table?
» Dimensional table design dilemma, Aditional column or Xref table
» Question for count in fact table
» Finding the grain with One-To-Many fact tables.
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum