The table above shows an entity in the source system that contains time variant values but they don’t change daily. The values are valid over a period of time; then they change.
1 .What the table structure should be used in the data warehouse?
Maybe Ralph Kimball or Bill Inmon can come with better data model! 
But for ETL developers or ETL leads the decision is already made so lets look for a solution.
2. What should be the ETL design to load such a structure?
Design A
- There is one to one relationship between the source row and the target row.
- There is a CURRENT_FLAG attribute, that means every time the ETL process get a new value it has add a new row with current flag and go to the previous row and retire it. Now this step is a very costly ETL step it will slow down the ETL process.
- From the report writer issue this model is a major challange to use. Because what if the report wants a rate which is not current. Imagine the complex query.
Design B
- In this design the sanpshot of the source table is taken every day.
- The ETL is very easy. But can you imagine the size of fact table when the source which has more than 1 million rows in the source table. (1 million x 365 days = ? rows per year). And what if the change in values are in hours or minutes?
- But you have a very happy user who can write SQL reports very easily.
Design C
- Can there be a comprimise. How about using from date (time) – to date (time)! The report write can simply provide a date (time) and the straight SQL can return a value/row that was valid at that moment.
- However the ETL is indeed complex as the A model. Because while the current row will be from current date to- infinity. The previous row has to be retired to from date to todays date -1.
- This kind of ETL coding also creates lots of testing issues as you want to make sure that for nay given date and time only one instance of the row exists (for the primary key).
Which design is better, I have used all depending on the situtation.
3. What should be the unit test plan?
There are various cases where the ETL can miss and when planning for test cases and your plan should be to precisely test those. Here are some examples of test plans
a. There should be only one value for a given date/date time
b. During the initial load when the data is available for multiple days the process should go sequential and create snapshots/ranges correctly.
c. At any given time there should be only one current row .
d. etc
NOTE: This post is applicable to all etl tools or databases like Informatica, DataStage, Syncsort DMExpress, Sunopsis or Oracle, Sybase, SQL Server Integration Services (SSIS)/DTS, Ab Initio, MS SQL Server, RDB, etc.
