Business Objects and the use of contexts

[Thys]

Hi
I have a BOBJ universe that contain four contexts. These contexts essentially contain all the joins in the universe. This results in a single SQL query being generated.
My understanding is that this is not optimal. It also increases maintenance when adding new tables.

Reducing the structure down to five tables all joined in a straight line and adding a context to the inner three tables results in :
Three queries being generated.
No connection between the context and the outer tables,
No context prompt.

Adding a context for the two outer tables on either end :
The queries are reduced to two, still no context prompt.

Adding an alternate path and a second context : Same result.

The context seems to be isolated from the rest of the table structure.

My question is : Must all tables needed in a query be inside a single context ?
Is there a specific way to determine how contexts would join up ?

[ngalemmo]

Is this a 3NF data model or a star schema?

If you are dealing with star schema, a context should include one fact table and its related dimensions (and bridges if there are any). That's it. If you need to combine measures from different facts, BOBJ will correctly generate two aggregate queries across common dimensions and combine the results. If you include a dimension that is not common between the two contexts, it will generate an error... as it should.

If it is a 3NF model, you just need to figure it out, as there is no clear pattern. There isn't much point to have four contexts that include all tables, since the purpose of a context is to encapsulate which tables to use.

[Thys]

This is a 3NF and no amount of posturing on my side brings the contexts together in one query.
Apparantly there is a white paper on the rules of how contexts connect in a query. Any idea how I can get hold of this ?

[Sponsored content]