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)
The best way is whichever way solves your problem 
I use both depending on the situation. If you have a specific problem, try giving us a simple example.
Namlemez 
(BOB member since 2005-03-14)
Start by reading the FAQs here on BOB.
As mentioned, there is no “best” way. There is however, a “right” way.
Steve Krandel 
(BOB member since 2002-06-25)
There are two key rules of thumb:
A context for each fact table
An alias for each different use of a reference table - e.g. multiple uses of calendar_ref for invoice dates, sales dates, delivery dates, etc.
Hi,
Apart from points mentioned by Mark, one other rule. Look at the maintainance point of view also.
I mean if the universe is very large and complex then always try to use contexts. It will reduce the pain of adding redundant aliases.
If universe is a small relatively simple in terms of tables present, joins and other properties of the universe then you can think of aliases.
In my case we have used contexts for derived, complex universe where as aliases in the smaller/simpler one where tables,joins were limited in number.
If your requirements are such that it makes you add aliases regularly then it may cause problem in future as there will redundant aliases in the universe.
Omkar Paranjpe (BOB member since 2006-02-13)
I submit that maintenance doesn’t have anything to do with it either.
Contexts have a purpose. Aliases have a purpose. In every case I can think of, which one you select is based on the problem you are trying to solve, not really what you think will be the best maintenance option. If you need a context, then you need a context.
The only real alternative to creating contexts is to create more than one universe. That’s essentially what a context is, really, by identifying a set of joins that work together you are essentially subdividing a single universe into smaller sub-universes of tables that work together. You could separate them into different universes.
Aliases are not substitutes for contexts, and vice versa. Once you have identified the problem, the solution choice is made for you.
Dave Rathbun (BOB member since 2002-06-06)
I concur with Dave.
There’s no easy way to maintain a wrongly designed universe.
Time for some reading…
It’s in the 2003 or 2004 materials. Yes, I know that seems old, but it hasn’t changed.
Steve Krandel (BOB member since 2002-06-25)
Hi,
I think that the following link may be useful for you: {url=http://support.businessobjects.com/documentation/installation_resources/5i/tips_and_tricks/pdf/universe_design/ut001.pdf]see here[/url]
Good Luck 
BR, Carina
Carina (BOB member since 2007-04-15)
I edited the first post, altered the title, and made this a “Sticky” topic to increase its visibility.
Dave Rathbun (BOB member since 2002-06-06)
Hi Raj Alias and context are to be used depending upon the loop you encounter. Do let us know if you are struck anywhere in resolving the loops. The best way of designing a universe is keep you Logical Data Model with you and go accordingly.
I feel the best way of designing a universe is inserting one fact table at a time.
Hope this helps.
Regards
Sridhar
koilada 
(BOB member since 2007-04-03)
Another reference that contains information on fan traps, chasm traps, and so on, and how to use aliases and/or contexts to resolve them:
http://www.integrasolutions.net/library_presentations.htm#design
There are a number of presentations on that page that will help.
Dave Rathbun (BOB member since 2002-06-06)
Keep in mind that there are context issues in a universe that are not related to loops… a fan or chasm trap does not always include a loop, yet they require contexts, aliases, or a combination to solve.
A chasm trap is a many - one - many chain of tables. You need to use contexts to separate the two ends of that chain, as you cannot get a valid answer by using all three at the same time.
A fan trap is a one - many - many relationship with measures at all levels. You must separate out the measures from the dimension tables using aliases, then use contexts to resolve the resulting chasm traps.
Neither of those situations include loops. 
Dave Rathbun 
(BOB member since 2002-06-06)
And more detailed info on solved fan traps and chasm traps can be found here in our Designer FAQ.
Anita Craig (BOB member since 2002-06-17)
Thank you all for helping me , I have another doubt , Is there any other purpose of setting cardinalities other than for resolving loops. Does the setting of cardinalities effect the report?
Thank you,
rajchowdary81 (BOB member since 2007-02-01)
The setting of cardinalities does not change the SQL generation or report contents whatsoever.
Dwayne Hoffpauir (BOB member since 2002-09-19)
Did you try a Search first? Suggested keyword: cardinality
Here’s one short and sweet discussion from just last week.
Anita Craig (BOB member since 2002-06-17)
Yes, but only where you have the “Multiple SQL Statements for each Measure” turned on, and then only when you have measures spanning a fan trap. In that case you should see seperate sql statements for each measure.
Cardinalities are also used by the detection options, such as the “Detect Contexts” and “Detect Aliases” options.
Dave Rathbun (BOB member since 2002-06-06)
It helps for support and further design.
You can see which way hierarchies are ordered.
I’m sure you’d appreciate cardinalities being set on any universes that you take over the maintenance and development of; it helps you to understand how the data is structured and identify any potential fan traps.
It does not have any impact on the sql generated by the universe and hence the report results
dudeus (BOB member since 2006-05-24)