BusinessObjects Board

Resolving loops .....

Hi all,

I am facing some suituation where we need to break up loop with out context and if we go for alias we have to create sepereate class in the universe where the user dont want this so can any one help out me to solve this problem…may be if any one has worked on this suituation using index awareness…i have gone thru daves adventures but i am unable to get the proper results…

Thanks In Advance,

Naga Bhusanam.D


babu_272 :india: (BOB member since 2010-07-28)

Why don’t you want to use a context? You really need to provide more information.

Joe


joepeters :us: (BOB member since 2002-08-29)

Hi,

In that case,you can go with Shortcut Join.

Regards
Siva.M


looksmee :uk: (BOB member since 2006-02-08)

You don’t get to choose whether to use a context or not, some problems demand contexts as the proper answer. :slight_smile: There is an entire topic dedicated to loops (contexts, aliases, etc) at the top of this forum. Have you had a look there?

Shortcuts are not a loop resolution technique.


Dave Rathbun :us: (BOB member since 2002-06-06)

Hi i am very much thankfull to all you guys for replying to my post but the thing what i am trying to say is there any possiblity to break the loop using Index awarness —i used alasis but this needs to be not shown in the seperate class…

Thanks in advance


babu_272 :india: (BOB member since 2010-07-28)

Loops are broken through aliases or contexts.

If the dimension table is used for two different purposes (date dimension being used for sales and shipping date for example) then use an alias.

If the dimension table has the same meaning, e.g. product, then you need to use aliases. Don’t be afraid of them. As Dave said, you must learn how to use them if you are to improve as a universe designer. In fact, you won’t last long without them.

Hi,

To answer your question, No. You can’t use Index awareness functionality for resolving loops.

Regards
Siva.M


looksmee :uk: (BOB member since 2006-02-08)

How about explaining the problem that you’re trying to solve?


joepeters :us: (BOB member since 2002-08-29)

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 :new_zealand: (BOB member since 2007-01-10)

Great post ErikR :+1:


Andreas :de: (BOB member since 2002-06-20)

Hi,

Try creating an alias and use Aggregate Awarness to switch the objects based upoon the object selection.You need to be a lit bit carefull while doing this and as said by Erik you should have your functionality of the universe defined before using any techinque


kumar446 :india: (BOB member since 2006-01-23)