As I posted elsewhere, I observed that strictly, the activity universe should have contexts for all the derived tables that hang off the event table. However, if you do this, then because there are only dimensions in the derived tables, the contexts are SYNCHRONISED rather than JOINed and that means you cannot place all the results in the same block. This aspect of contexts must be confusing for users because the synchronise activity happens ‘behind the scenes’, but then you get dimension objects which are stated as being incompatible. When you don’t have contexts, as in the supplied activity universe, then the different derived table dimension objects just get replicated. I am not sure why BO didn’t design it so that the same thing happens with synchronised contexts?
The Activity universe has no contexts, and shouldn’t. Only universes with multiple fact tables should have contexts, one for each fact. Since the Activity universe only has one fact table, AUDIT_DETAIL, it should not have any contexts.
Except that in a way it does have multiple fact tables because of the way it has several derived tables hanging off the event table in 1 to many relationships as well as the audit_detail table. See my post
(BOB member since 2008-10-16)
(BOB member since 2002-08-08)
(BOB member since 2010-06-15)
(BOB member since 2003-11-27)