New answers tagged

0

I highly recommend the 1st option of a bridge table. If you make sure the you capture the historical change on all three tables that would work fine, though I'd agree with you that the JOIN'ing is an issue. Just make sure that (in the JOIN clause) that the DateInserted and ValidTill match the ones that are in the fact table. More about bridge tables in here ...


0

If you want to capture historical changes on the three tables you need change hierarchies tables (i.e. [Area], [Region]) into sub-dimensions of the dimension table (i.e. [Location]) by adding an effective_date and expire_date (in the three tables )and you can track changes in dimension and sub-dimension attributes in order to report historical data using ...


4

Based on your sample data it looks like there are 6 columns in total. COL1, COL2, COL4, COL5, COL6 = All fixed width . COL3 = This is a fixed width for a given day, but it is variable day to day (based on my understanding). You should be able to calculate COL3's width each day based on the length of any given line. You know COL1,2,4,5,6 are all fixed ...


0

For date key you might prefer a number. So for April 7th 2016 201604 (Or 20160407 in case of extended requirements) might be best for your date. I don't think that in a DW you need an IDENTITY column for a primary key; After all, you're more aggregating then asking to see a specific value. What I do is make sure the index avoids duplication of values: for ...



Top 50 recent answers are included