"Perfect" design vs. Time to Implement
3 posters
Page 1 of 1
"Perfect" design vs. Time to Implement
How difficult would it be to implement a new dimension on an existing fact table?
I have a situation where the time I have to launch a business process is shorter than the time I need to get a new dimension designed and pushed. I'm thinking about implementing the process without that new dimension and adding it later.
What are the pitfalls I can expect if I choose this rout?
Thanks in advance!
Dan
I have a situation where the time I have to launch a business process is shorter than the time I need to get a new dimension designed and pushed. I'm thinking about implementing the process without that new dimension and adding it later.
What are the pitfalls I can expect if I choose this rout?
Thanks in advance!
Dan
DanColbert- Posts : 11
Join date : 2009-02-03
Age : 55
Re: "Perfect" design vs. Time to Implement
It can be very time consuming to add a new dimension after the fact. Normally you would need to reprocess all historical facts to get the dimension keys right on what was already there. It may not be practical.
A better solution is to simply stub the dimension table. Assuming your fact data feed has the natural key you need for the dimension, why not design the table to contain just the primary and natural keys? Then the fact process can infer dimension rows as new natural keys come in, and the fact foreign key will contain the appropriate surrogate key value to reference the proper row. Later, when the dimension itself is properly designed and the data feed resolved, you just need to implement the dimension update process... no need to go back and re-key the facts.
A better solution is to simply stub the dimension table. Assuming your fact data feed has the natural key you need for the dimension, why not design the table to contain just the primary and natural keys? Then the fact process can infer dimension rows as new natural keys come in, and the fact foreign key will contain the appropriate surrogate key value to reference the proper row. Later, when the dimension itself is properly designed and the data feed resolved, you just need to implement the dimension update process... no need to go back and re-key the facts.
Re: "Perfect" design vs. Time to Implement
It is certainly a bridge you will have to cross sooner or later. As ngalemmo pointed out, the most difficult aspect is dealing with history. If you don't need to populate history, which is often not even a choice, the enhancement is not difficult.
BoxesAndLines- Posts : 1212
Join date : 2009-02-03
Location : USA
Similar topics
» Best way to implement date ranges in schemas (fact 1 valid "from" date1 "to" date 2)
» Time dimension design for cross time zone and custom calendar warehouse, 1min granularity
» Reasons to use a 3NF design over a Dimensional Model design for an EDW - Discussion
» ETL Design Problems for Real time
» Loading and cleaning "randomly" updated, timestamped data from a 3rd party
» Time dimension design for cross time zone and custom calendar warehouse, 1min granularity
» Reasons to use a 3NF design over a Dimensional Model design for an EDW - Discussion
» ETL Design Problems for Real time
» Loading and cleaning "randomly" updated, timestamped data from a 3rd party
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum