Context and universe performance

[system]

Hi ,

I have to create a new report for which i need to join a fact table with 4 dimension tables in the universe.The universe already has 3 fact table joined with the same dimension tables. For each fact table there is a separate alias for each dimension table.There is no context defined. So the basic rule is violated.
1.Does this mean that contests are not required if there is alias.?
2.Will defining context give beter performance in this case ?

I am confused whether to follow the existing model or define a context for the new fact table.

Please advise considering that i am relatively a beginer in universe design.

Thanks for the help in advance.

---

sreeleshc (BOB member since 2012-01-16)

[system]

Hi,

This sticky topic (relatively long discussion) can get you started in terms of using either aliases or contexts:

Read Me: Best Way to Resolve Loops Context? Alias?

Hi all, I am new to Business Objects , and a FAQ in BO is which is the best way to resolve loops , SO Guys can anyone clarify me …which is the best way , Aliases or Contexts… Thank you, Chowdary [Edited title and made sticky - Dave Rathbun] rajchowdary81 (BOB member since 2007-02-01)

---

Marek Chladny (BOB member since 2003-11-27)

[system]

If the aliased dimensions mean semantically the same (= they do not play different roles), then the universe designer made the wrong choice.
If your dimension tables are conformed dimensions, then universe contexts are the only proper and correct way to do things.

For example:
Consider the two dimensions “Costcenter” and “Month” and the two fact tables “Budget Fact” and “actual Revenue Fact”

Correct solution:
Join Dimension “Costcenter” to both fact tables (it plays the same role in both fact tables). Join Dimension “Month” to both fact tables (it plays the same role in both fact tables)
and create 2 universe contexts:
Context 1: Join Costenter to “Budget fact”, Join Month to “Budget Fact”
Context 2: Join Costcenter to “actual Revenue Fact”, Join Month to “actual Revenue Fact”

Result:
You will have ONE Month object, ONE Costcenter Object, and 2 measures (Budget & Actual Revenue). Loops and chasm traps will be resolved “magically” through the universe contexts you set up.

Note:
If a dimensions plays multiple, separate roles such as: Address Ship FROM, and Address Ship TO, then the Address dimension table must be aliased.

---

Andreas (BOB member since 2002-06-20)

[system]

Search here on BOB for “context” and “alias” and you’ll find a bunch of existing topics. But in a nutshell:

Either approach will work. There are many considerations but one of the most important is usability. With aliased dimension tables, you will create multiple universe objects for the same source field. With contexts, the dimensions will only be associated with a single object.

For example, you may have a “customer” dim table with a “customer name” field. And three fact tables: sales, quotes, shipments. Using the alias method, you’d have three copies of the “customer” table, each one joined to one fact table. You’d then have a class associated with each of the three fact tables. Each class would have the respective measures from the fact table, and their own “Customer Name” object.

To illustrate:
Sales
–Sale date
–Sale amount
–Customer name
–Customer address
Quotes
–Quote date
–Quote amount
–Customer name
–Customer address
…

With the context method, dimensions are only represented once, so you may end up with:
Sales
–Sales date
–Sale amount
Quotes
–Quote date
–Quote amount
Customer info
–Customer name
–Customer address

The context method generally results in fewer objects, but the alias method can be cleaner since all related objects are together.

Another consideration is whether you want to allow querying multiple fact tables in the same query. The context example above would allow you to create a report with “Sales amount”, “Quote amount”, and “Customer name”. BO will build two queries and join the results in the report. This would not be possible with the alias method.

So, to answer your question, you’re probably best off leaving the structure of the universe as-is, and adding your new fact table with a new set of aliased dimension tables. Changing to a context approach would mean consolidating the replicated dimension objects, which would screw up existing reports. And it’s not necessarily better than what it is currently.

As to performance, there’s generally no difference between the two methods. The two examples I described above would produce the same SQL (with aliased table names, of course, but no change to the query logic).

Joe

---

joepeters (BOB member since 2002-08-29)

[system]

Thanks guys for the quick help.

Thanks Joe for the detailed explanation. I think I will go with your suggestion.

---

sreeleshc (BOB member since 2012-01-16)