You have to take a step back here. It’s not about “what can I throw against the Universe to solve this problem” … you should know why this is happening and based on experience, know what the right solution is.
An Alias or Context aren’t technical work arounds for the Universe - they are functional tools to help you convert a logical design into a physical model.
Let’s say you have a date dimension in your data warehouse and you use this to connect to the various facts, such as:
- purchase date
- shipping date
- customer signup date
- customer date of birth
- warrenty period start date
- warrenty period expire date
- service desk date
- repair date
…etc etc
All these dates can be serviced through the same physical date dimension. You implement this table ONCE and you refer to it when populating your data warehouse.
However, in your logical design - these are all DIFFERENT dates and would, logically speaking, all require seperate “Date Dimensions”. Thus you are implementing a role playing dimension - a single physical table that logically represents totally different dimensions… like “a repair date dimension” and “purchase date dimension” etc.
To implement this, you would use an alias to re-create the logical model you are after.
A Context is used differently. You often end up with loops if you create a single universe spanning multiple fact tables within the same subject area or sometimes spanning multiple subject areas.
When using conformed dimensions, you allow your users to query your data warehouse using common aspects of your business across multiple subject areas - or across different parts of a single subject area.
With this I mean that you can perform analysis between customer purchase behaviour (from the “Sales” area) in relation to the number of service calls a customer makes and the number of repairs on products, to determine how the quality of your product has an immediate impact on the buying behaviour of your customers.
In such a “wide model”, a query can end up in a loop because there are several ways to nagivate your model as customer is related to many facts, which all loop back to customer again (and sometimes through other dimensions if one opts for a model in which dimensions are also related to eachother, either directly or through factless fact tables).
In this case, you shouldn’t be using aliasses but you provide context - as predefined query paths to ensure that, depending on the context of the query asked, BO can use the right path to navigate the Universe to find the right information. Using the Context functionality, you allow Business Objects to ask the user “in what context do you want me to consider your question about this customer? Is it sales? service calls? warrenty?”.
Too often contexts or aliasses are seen as work arounds to “make Business Objects” work but there’s nothing wrong with Business Objects at all.
Fully understanding why this situations occur and what the right solution is, helps you to have a good conversation with your end users. If users want to have a single universe spanning multiple subject areas, you should be able to clearly explain to them - without using database or SQL jargon - why an alias or context may be required.
ErikR
(BOB member since 2007-01-10)