Business Objects with Multiple Facts and Contexts

We are finally using a dimensional model for reporting on a widespread basis. These universes have multiple fact tables. These fact tables have shared dimensions. Unfortunately, we have users now creating reports without pulling measures that would trigger which context to be used. In these cases, the user receive a prompt to select a context. Our users are having a really hard time with this, and I was wondering if anyone had experience with this and what, if anything, you've done to help with either user understanding or how we could design the universe to reduce the context prompting?

In our universe, we have created multiple alias of shared dimensions in universe and linked the alias dimension with corresponding fact table and have entered into the required contexts hence avoiding context selection.

yes .........go with creating aliases of the Dimensssions you have taken into Contexts.
Dont forget to rename the alise tables properly so that you can easily distinguish which object can be offered to user to reflect required result.

AKVK wrote:In our universe, we have created multiple alias of shared dimensions in universe and linked the alias dimension with corresponding fact table and have entered into the required contexts hence avoiding context selection.

Aliase's are usually used if dimensions play different roles (ie: different date types).

So let's say you had 10 shared dimensions and 5 fact tables.
Then you would create 50 alias dimensions? That would be unreasonable.

Please read this post to understand alias vs context in Dave's Adventues in Business Intelligence
You can google "context vs alias business objects"

Thanks

Dlai has a point. Aliases would not solve the problem unless you want to present the user with a universe containing multiple folders for the same dimension. You then have the issue of training the users to understand which set of folders can be used together... it basically turns into a manual implementation of contexts.

The underlying issue is: What does it mean to report on dimensional attributes only? If I create a query that has customer name and product name, what does it mean and how is the system expected to join the tables? If I wish to get a list of product the customer has purchased, there is an implied context: sales. The user must explain to the system what the context is. By default, BOBJ lists the potential contexts and the user must choose.

An alternate way to do this is to provide a set of filters that reference the fact tables and label them in such a manner that allows the user to specify the context. You would have one filter per fact table with a condition that uses one column in that table and always evaluates to true (such as checking to see that one of the FK columns is not null). Using the filter will not alter the results but will define the context to the BOBJ code generator so it does not need to ask. Train the users to include one of these filters for dimension only queries. If they happen to use them for queries using measures, that is fine as well. Such queries will still perform as expected.