July 22, 2013 at 6:35 am
Hi Folks,
I`m facing a Situation, in which the reference data of our data warehouse is changing.
Basically a new System is implemented by our external Provider and there is a new hierarchy of the product Dimension.
The current fact table has the old hierarchy.
My question is, what is the best or more appropriated way to proceed?
The data Provider has offered a Translation table of the old product tables and the new ones.
- An Option is to extend the Fact Details table with the new fields, update them and finally store the new incoming fact Details and leave the value of the old columns to NULL.
- My favorite Option is to create a new fact Details table with the new structure. Migrate the historic records to the new table using the Translation table and then Import the new Transactions.
What do you think of?
Any comment will be appreciated.
Kind Regards,
July 22, 2013 at 9:47 am
Paul Hernández (7/22/2013)
Hi Folks,I`m facing a Situation, in which the reference data of our data warehouse is changing.
Basically a new System is implemented by our external Provider and there is a new hierarchy of the product Dimension.
The current fact table has the old hierarchy.
My question is, what is the best or more appropriated way to proceed?
The data Provider has offered a Translation table of the old product tables and the new ones.
- An Option is to extend the Fact Details table with the new fields, update them and finally store the new incoming fact Details and leave the value of the old columns to NULL.
- My favorite Option is to create a new fact Details table with the new structure. Migrate the historic records to the new table using the Translation table and then Import the new Transactions.
What do you think of?
I think the two options are just different ways to get to the same result which is, add to Fact Details the new columns coming from the source system.
If columns are added on the original table chances are table would get fragmented and a full reorganization would be needed.
If a fresh Fact Details table is created and data gets migrated then the fragmentation issue would be avoided.
It all depends on the Business, if you have the disk space and are allowed to have the downtime needed to migrate your data from the old table - I would do it this way.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.July 23, 2013 at 1:13 am
Hi Pablo,
thanks so much for your answer. I will use the new table option, because at the moment the fact table is only used to generate weekly and monthly reports, therefore I have enough time to migrate the data month pro month.
Kind regards,
August 22, 2013 at 8:55 am
I am never one to let a source system architecture drive an analytical solution.
It sounds as if more work would need to be done on the dimensions than anything else. It is ok to have multiple hierarchies in a dimension--especially a product dimension. The first thing I would do is analyze the product map, see how clean it is, and proceed from there.
Like Paul says, however, it is not uncommon for a new system to introduce new potential facts--just make sure the are ITEMS OF NEW BUSINESS VALUE.
August 22, 2013 at 8:56 am
Also, I would implement the product map in the staging area of the dimensional load.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply