Building a valid SCD type 2

Question

Hi,
has anybody ever designed a mapping to fill a scd type 2 with more than one level? I know the example from the transformation guide and the whitepaper and it works fine with one level. But you can't use it with dimensions with more levels in my opinion:
The problem is how to fill the id from the not base levels.
1) If I use a sequence for that, Oracle can't use query rewrite on this dimension for aggregating higher levels, can it?
2) If I use let's say the id from the enterprise model for the higher levels, that dimension becomes invalid as soon as a higher level attribute changes (check this with dbms_dimension.validate_dimension). So query rewrite will fail again, won't it?
All examples found in oracle docs are using just one level except for one example, and this doesn't fill the id from the second level.
A solution? Comments?
Regards,
Torsten

Answer 1

Hi Patrick!
You've problably defined a number of trigger columns
which determines the loading action, so
NUMBER_OF_CITIZENS would be one of them. As soon as
this changes, on the next load all persons that live
in Köln would be SCD'd (i.e. have their current
record closed and a new one inserted with the new
number of citizens).Correct. Let's use this as an example.
You are making it sound like you have two completely
different source sets which you offer 'independently'
to the dimension (since you want to make use of the
key on the city-level). No. I don't want to use the city-level-key. But when defining a dimension, there is one key (called id in the owb) and some more dependend attributes.
CREATE DIMENSION dim_person
LEVEL person IS (dim_person.pers_id)
LEVEL city IS (dim_person.city_id)
HIERARCHY std (
person CHILD OF
city
JOIN KEY (dim_person.city_id) REFERENCES city
ATTRIBUTE city DETERMINES (dim_person.population)
But in the end it does not matter whether you have a
unique identification of the city level, since
records are inserted on person-level, and that is
where you have defined that extra MATCHING column on,
yes?No. The unique identification on city level is for validating the dimension. Of course the table which holds the dimension data is always valid whatever the data is. But the data has to be well formed for a valid dimension. If I use the example from above with dbms_dimension.validate_dimension(...) the result will be an invalid dimension.
If I'm completely missing the point here, I guess I'm
not understanding your problem and its approach
then.The approach would be building your changed/unchanged transformation for each level. But I am asking here if I am the only person who sees this problem? Or maybe here is no problem.
My bottom line is: when you're loading a dimension
you have only one source set that is compared to the
current dimension, and your point of view is the
lowest level, unregarding any of its higher level
attributes unless they are part of the natural key.
Clarifying this using your example, there are two
source tables:
-ODS_PERSON with attributes PERSON_ID (surrogate
key), PERSON_NAME, PERSON_TAX_NUMBER (natural key),
MARITAL_STATUS, CITY_ID (FK to ODS_CITY)
-ODS_CITY with attributes CITY_ID (SK), NAME (NK),
POPULATION.
The dimension would have the following attributes:
ID, PERSON_NAME, PERSON_TAX_NUMBER,
PERSON_MARITAL_STATUS, CITY_NAME, CITY_POPULATION
(divided over 2 levels).
The JOIN would then compare values from joined
ODS_PERSON-ODS_CITY with the existing dimension
values.
Trigger columns would be PERSON_MARITAL_STATUS,
CITY_NAME, CITY_POPULATION and the overall natural
key (for matching purposes) for the dimension would
be PERSON_TAX_NUMBER.
As you can see, in this example there is no need for
any unique identification on any other level than the
lowest.But you have to give the dimension the unique key. This is what you are doing when renaming the id of the city level to the city_name.
LEVEL city IS (dim_person.city_name)
ATTRIBUTE city DETERMINES (dim_person.population)
Cheers, PatrickI hope I could point to the problem a little bit more.
Regards,
Torsten