Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Extend or migrate a Fact Table? Expand / Collapse
Author
Message
Posted Monday, July 22, 2013 6:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 12, 2014 12:07 PM
Points: 120, Visits: 489
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,


Paul Hernández
http://hernandezpaul.wordpress.com/
https://twitter.com/paul_eng
Post #1475983
Posted Monday, July 22, 2013 9:47 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, January 28, 2014 8:15 AM
Points: 3,065, Visits: 4,639
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.
Post #1476095
Posted Tuesday, July 23, 2013 1:13 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 12, 2014 12:07 PM
Points: 120, Visits: 489
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,


Paul Hernández
http://hernandezpaul.wordpress.com/
https://twitter.com/paul_eng
Post #1476373
Posted Thursday, August 22, 2013 8:55 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 28, 2014 7:12 PM
Points: 2,148, Visits: 487
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.
Post #1487324
Posted Thursday, August 22, 2013 8:56 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 28, 2014 7:12 PM
Points: 2,148, Visits: 487
Also, I would implement the product map in the staging area of the dimensional load.
Post #1487329
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse