Alias Vs Context

[Former Member]

Hi,

which one is the better way to resolve the loops either alias or context.

Regards,

G

[arijit_das · Accepted solution]

Context is a better option though we may need to use alias and context together to resolve some join path problems. Using alias, you will have duplicate objects which may be confusing. Later if you need to join another new table with the aliased table, you need to create alias of the new table as well to avoid loop.

** Please note that before posting such elementary questions, you need to go through the documentations provided by SAP. The universe designer guide explains this part very clearly.

For your reference: http://help.sap.com/businessobject/product_guides/boexir4/en/xi4_universe_design_tool_en.pdf : Page 252

[Former Member]

It depends on the circumstances of your loop.

If the dimensions in your loop all have the same business meaning then contexts is the correct way.

If any dimensions in your loop have different business meanings then you must use aliases.

For example:

You have a loop of:

Customer_Dim

Sales_Fact

Delivery_Fact

Date_Dim

Product_Dim

You would alias Date_Dim twice - create a Sales_Date alias and a Delivery_Date alias

However, you still have a loop because the "journey" from Customer_Dim to Product_Dim could go through Sales_Fact or Delivery_Fact. Therefore you would need two contexts - a Sales context containing three joins and a Delivery context containing three joins.

The general rule is to have a context for each table from which you are deriving measures - in data warehouses, this equates to one context for each fact table.

Using aliases means a lot more work for the report developer with merging data providers. In the example above, if you had aliased Customer and Product to have different aliases server the two fact tables, the user would have to create two queries to see sales and delivery data in the same report. Using contexts they would only need to bring back one lot of customer and product objects and BusinessObjects would automatically separate the data request into two pieces of SQL, which is one of the tool's key strengths.

[Former Member]

I would say Alias works better for join path problem and are easier to maintain...  If a join path can be handled by a Alias then I would always go with alias as context will prompt a popup box to be selected for the user which users some times have not clue which one to select..