1
Vote

Does not seem to handle inferred members correctly

description

I have a dimension with mostly SCD2 and one SCD1 column. During a deployment I had a need to add some columns to the dimension table so I set Inferred true on all records as I copied the data into the new table expecting it to update the new columns. But after a run it behaved as if the update was SCD2 and inserted all new rows, however, it did not clear the "CurrentRow" on the existing inferred rows.
 
It was my understanding that an Inferred member makes all SCD2 columns SCD1. I also noticed that InferredMember is "Optional" on the SCD1 output. This does not seem correct since inferred rows should be updated by "Updated SCD1" and the Inferred flag would need to be reset at this point.
 
Am I misunderstanding how inferred is supposed to behave is is there a bug?

comments

tlum wrote Dec 16, 2011 at 1:56 PM

I'd have to amend this as a problem with lack of documentation. Inferred member support requires that Active Date be set and that it be set in the past. There is no documentation - that I can find - on the implementation of Inferred Member records and how they need to be formed so that DMSCD will work with them. I'm still not convinced that I have "discovered" all of the idiosyncrasies of Inferred Member support but can probably get by this one time. An actually spec. would be a good thing.

toddmcdermid wrote Mar 15, 2012 at 11:50 PM

The Inferred feature wasn't meant to handle addition of columns. It's meant to handle "early arriving facts"/"late arriving dimensions". I would handle your situation by performing a manual update after the first processing completes to "fix up" those NULL columns. This "fix" only has to be done once, so it really shouldn't be a part of the ETL process.

Sign in to add a comment or to set email notifications