Loops in Context

[Former Member]

Hi All,

I'm just starting to use Business Objects Designer recently and I have a question about loops.

Consider the following situation:

------------      a    --------------    c
| Case     | ----------| Category | -----------\    -------------
------------           --------------           ----|Durability |
      |           b     -------------    d      ----|           |
      | ---------------| Status     |----------/     ------------
                        -------------
Cardinality from left to rigth:
Join A : N - 1 
Join B : N - 1
Join C : 1 - N
Join D : 1 - N

So, a Case has a Status and a category. Depending on the category the status has a durability.

I designed my universe as above and when i create a Web Intelligence Document in InfoView it picks both join C an D which is intended. However the Integrity Check comes up with this as being a loop.

Can I keep my design like this, even though it would be marked as unresolved loop or should I try another aproach (derived table probably?)

I hope my question is clear enough, Please Advice,

TIA

[arijit_das · Accepted solution]

You can create 2 contexts to avoid loops: one with a and b and another with c and d.

pls refer to the designer guide for details of procedures to avoid loops.

[Former Member · Accepted solution]

pumpactionshotgun , thanks your reply. However, your answer is not what I am looking for. I understand loops can either be solved by using a context or aliasing.

What I'm trying to find out is if loops are always bad or if there are cases in which they can be allowed.

I my case all joins that make up the loop should always be made so I think it's ok to keep my design like this In this particular case... What I want to know is if there are any caveats that i might be overlooking

Cheers

[MariannevL · Accepted solution]

You don't want loops!

Seriously, that means that you will always get ALL joins in the query if you need just one...

So in this case only combinations that are both in the left and and in the right hand table.

There are only very limited situations in OLTP schema's when you want that and even then it is better to hide the loop using derived tables.

My personal approach in any schema after you solved these difficulties in OLTP schema's

1) Look for functionally different uses of tables. Like address that is joined to customer three times because they have more than one addres. Or calendar that is joined to different dates. For these cases use aliases.

Another pointer can be that the users want two different objects for the same table.column.

2) Doublecheck your cardinalities, not by using the check, but by making testqueries or just using your brains.

A product can be sold more than once so product to sales is 1:N, duh...

3) Hit the detect context button and let BO generate the contexts for you.

Rename if you want (but its easier to work with an alias on the context driving table that has the name of the context ;).

Done!

Hope this helps,

Marianne

[Former Member · Accepted solution]

Hmm..I was overlooking the obvious I think. I can join durability table directly to the case table, which already has a status and category id ofcourse...duh...Problem Solved.

Thanks for helping.

[Former Member · Accepted solution]

Loops are not always bad. I have delivered more than one universe where loops were not only included they were required. One such example was a medical reporting universe where there were three main "core" tables: the patient, the service, and the provider. At any given point in time any provider could deliver any service to any patient. So all three tables were required in order to generate a valid answer, and therefore we had a loop.

I have also seen loops in effective-dating strategies.

So to answer the original question: no, you do not always have to resolve loops. But behavior has changed from version to version. In earlier versions, if I had unresolved loops in my universe I could not run a query. Instead I would get an "Incompatible combination of objects" for every single query. The fix was to highlight the entire universe (it was small) and add every join to one big context. That way I told Web Intelligence that I knew I had a loop, but do it anyway. It worked fine after that.