this was discussed here and there before, but I’d like to open a new topic and find out what you think is (or will become) best practice. It seems SAP thinks that they made life easier with the new joins approach but somehow I don’t get that feeling.
From what I’ve read so far (and I haven’t had much hands-on experience yet) there are 2 approaches for contexts in the new IDT/UNX universes.
only define the “included” and “excluded” joins in the ambiguous part of the universe and leave all other joins neutral (“from the book”)
similar to the old UNV approach: include or exclude joins from contexts and avoid neutral joins
Both variants seem to have fans. I can see that approach 1 makes life easier but some people seem to think it’s not enough and tend to define all joins either included or excluded.
I wonder:
what’s the difference (except for maintenance)? I read about possible performance issues with approach 2 (why?).
And what is in the end the difference of an included and a neutral join as neutral ones seem to be “included” somehow anyway? (they could have gone only with excluded joins in my opinion)
Don’t forget that shortcut joins are no longer figured into the evaluation of contexts. This was always beneficial in the UDT. I’ve found that these joins have to be treated like “Neutral” joins.
I guess I’ve only attempted scenario 2 from your post with the modifications for the shortcut joins.
Maintenance does seem to be a much greater task. I’ve had a lot of trouble clearing up the contexts when there have been join changes. The biggest reason for this is the IDT doesn’t do as good a job of detailing what the loops are as the UDT does.
You are correct, the idea was to simplify joins, and the reality ended up making them considerable more complex. I’ll explain:
In UDT, each join has 2 possible states relative to a context. It is either a member, or not a member, of the context. In IDT, a join has 3 possible states relative to a context (that’s 50% more). It can be explicitly included, explicitly excluded, or neutral. What do these mean?
Explicitly included: The join will always be a member of the context. Explicitly excluded: The join will never be used in the context. Neutral: The join is not a member of the context, but is available to be used with the context.
In my experience, this has made the development process significantly more difficult. I had a universe that I worked on with 66 contexts. We spent over a month, working with SAP, to get the contexts correct. We finally gave up, and rebuilt the entire universe in UDT. Problem solved.
Believe me, I wanted to run away many times. The database had 2 transaction tables, and 64 aggregate tables. I did everything I could to reduce the aggregates, but it just had to be that way.
I still don’t see the difference between included and neutral. When I create a query that doesn’t contain a table, the join won’t be in it even though it’s “included” in the context (so won’t the neutral one). So why do I need “included” joins at all? would it not be enough to define the “excluded” ones and done we are?
There’s only 3 fact tables but they have this weird hierarchy that the database doesn’t support well so the contexts actually aren’t centralized around the fact tables like you normally would. If they would just report off the database more like it was designed, it might not need any contexts at all. There are very few shared dimensions.
The database is a vendor supplied “Data Warehouse” which really isn’t designed as a data warehouse.
I have a universe with hundreds of joins but only a few are context-relevant. Most joins are in all contexts. So much quicker to simply include/exclude half a dozen and ignore the rest.
a clean datawarehouse with clean fact and dimension tables,
a fully normalized schema?
Typical case: I have a deep set of geographical dimensions (continent->town). Do I have to include all dimensions to the contexts or just the join from town to fact table?
I’m wondering if being lazy with option 1 will not backfire at the first quick dirty patch that always appear in the last minute before delivering a project, and force the rebuild all contexts.
In your case, only the join to the fact table needs to be included in a context. The rest would remain neutral. Of course, if you only have one fact table, then you don’t need any context at all.
I believe it’s slightly different, in that it must consider 3 options for each join, rather than 2 as in UDT.
This is a terrible indictment of the product in that gurus like yourself together with SAP support still cannot get IDT to work and have to revert to UDT.
Were you trying to convert a 66 context Universe to IDT, or build it in IDT from scratch? If the latter, what happens if you now try to convert your Universe to IDT; does it now work?
@Michael: Congrats! I’ve checked, I’ve only got 45-50 contexts in my most feared universes (but no aggregate) (Well, I’ve done 140 too, but it was never put into production ).
What was precisely the problem with your 66 contexts? The mess with @Aggregates, crashes, slowness or something else?
If you have a classic star/ snowflake and you set all your cardinalities correctly anyway, presumably the context detection algorithm is just as easy to apply and therefore the contexts are as easy to maintain as they are in UDT. In other words, only having to define star joins and not snowflake joins as well becomes a moot benefit.
The universe was originally built in IDT, and the UDT version has never been converted. I suppose it will eventually be converted, so I’ll know then if it still works.
The problem was that we never were able to get it to generate valid SQL to get the correct results.
It was a context problem. We couldn’t get the contexts to include the correct joins in the SQL. And sometimes, joins would show up in the SQL that shouldn’t be there.
(BOB member since 2010-02-16)
Explicitly included: The join will always be a member of the context.
(BOB member since 2002-08-08)
AAAAHH!!! Run away!!!
(BOB member since 2002-08-08)
(BOB member since 2005-03-01)
(BOB member since 2007-10-16)
(BOB member since 2007-10-16)
(BOB member since 2002-09-13)
).