SCD's type 2 conflict with Oracle Dimension Object

Question

Hi everybody.
I have a little problem understanding Oracle Dimension Objects and how to use it with SCD type 2.
Oracle's documentation says: There must be a 1:n relationship between a parent and children. A parent can have one or more children, but a child can have only one parent.
This makes me think that if i have, for example, a department 1 and zone 'A', this department ALWAYS have to map the same zone, the zone 'A' can have more than one department but one department have to map every time to the same zone.
This is a correct example: department 1 maps to zone 'A' everytime
Employee Department Zone
1 1 A
2 1 A
This is an incorrect example: department 1 DOES NOT MAP to zone 'A' everytime
Employee Department Zone
1 1 A
2 1 B
Oracle's documentation says: You must not create dimensions in any schema that does not fully satisfy the dimensional relationships. Incorrect results can be returned from queries otherwise.
OK, but what can we do if the department's zone actually change???
In SCD type 2 we use the following technique:
ID Employee Department Zone Start End
1 1 1 A 2010-01-01 2010-01-02
2 1 1 B 2010-01-03 null
Now we can see that SCD type 2 does not follow the requirements that ORACLE recommends for the creation of Dimension Objects, I mean department 1 now maps to the older zone A and the newer zone B.
Is it correct?
Can somebody clarify this? I think is a conflict.
Thanks.

Answer 1

Hi,
Is it correct?No, you are wrong. You mixed dimension attribute historization and hierarchy relationship.
Behaviour of mapping for loading SCD2 dimension depends on how did you implement Department and Zone entities in your dimension -
as a general attributes of lowest dimension level (EMPLOYEE) or as a higher levels in dimension hierarchy.
If you define Department and Zone as attributes of EMPLOYEE level than behaviour of loading algorithm will be as you described -
it is because OWB doesn't know that Department and Zone attributes compose hierarchy.
But when you define additional levels Department and Zone - OWB tries to resolve conflicts over hierarchy in very simple way -
for each child dimension value it choose single parent with minimal business key value.
In your case loaded data will be:
ID Employee Department Zone Start End
1 1 1 A 2010-01-01 2010-01-02
2 1 1 A 2010-01-03 null
Since 10.2.0.4 patchset there is also Hierarchy Versioning feature (so configured for versioning level also contains EFFECTIVE_DATE, EXPIRATION_DATE columns).
Regards,
Oleg