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

Updating Historical Information Expand / Collapse
Author
Message
Posted Tuesday, November 5, 2013 11:02 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Wednesday, January 29, 2014 2:58 PM
Points: 1,141, Visits: 944
I have to create a slowly changing dimension with the caveat that any of the data attributes can change for any of the records (even the historical one's). There is a surrogate key from the source system that i could store locally but i was wondering if anyone has run in to this situation and used a different option / design.
Post #1511570
Posted Sunday, December 15, 2013 9:49 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, April 17, 2014 8:28 AM
Points: 2, Visits: 140
I haven't implemented this kind of situation but I think that the most elegant way is to store surrogate key of the source table to data warehouse table and use this as a business key in slowly changing dimension component.
I have used surrogate key of the source table as a business key many times in different situations.
Post #1523049
Posted Sunday, December 15, 2013 12:32 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:55 PM
Points: 35,618, Visits: 32,214
SA-1 (11/5/2013)
I have to create a slowly changing dimension with the caveat that any of the data attributes can change for any of the records (even the historical one's). There is a surrogate key from the source system that i could store locally but i was wondering if anyone has run in to this situation and used a different option / design.


I'm always amazed by such things. Historical table data is NOT supposed to change. By definition, it's supposed to be historical and, therefor, never change. Changing historical information may keep your company from getting ISO, SOX, and SEC certifications and, if something really bad happens, could even land everyone involved in jail.

I strongly recommend that the company get out of the nasty habit of changing historical information whereever it is kept.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1523058
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse