BusinessObjects Board

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

building semantic layer
#9

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 :lol:
BR, Carina

Carina (BOB member since 2007-04-15)

#10

I edited the first post, altered the title, and made this a “Sticky” topic to increase its visibility.

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

#11

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.

  1. Insert one fact table and related dimension tables to that fact table.
  2. Create all the joins.
  3. Check for loops.
  4. See if it can be resolved with an alias.
  5. Create context. Make sure a context doesnt have any loops
  6. Each join must present in atleast one context.

Hope this helps.

Regards
Sridhar

koilada :india: (BOB member since 2007-04-03)

#12

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 :us: (BOB member since 2002-06-06)

#13

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. :slight_smile:

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

#14

And more detailed info on solved fan traps and chasm traps can be found here in our Designer FAQ.

Anita Craig :us: (BOB member since 2002-06-17)

#15

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)

#16

The setting of cardinalities does not change the SQL generation or report contents whatsoever.

Dwayne Hoffpauir :us: (BOB member since 2002-09-19)

#17

Did you try a Search first? Suggested keyword: cardinality

Here’s one short and sweet discussion from just last week.

Anita Craig :us: (BOB member since 2002-06-17)

#18

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 :us: (BOB member since 2002-06-06)

#19

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.

#20

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)

#21

Welcome to BOB, if the loop has multiple fact tables, use contexts to resolve it and if it doesn’t then you can go for aliases. Aliases are not appropriate in situations where there are multiple fact tables.

zack :us: (BOB member since 2007-08-02)

#22

They might not be appropriate as a loop-resolution mechanism, but it doesn’t follow that you can never us aliases in a universe with multiple facts. I don’t expect that is what you were trying to say, but thought I would clarify anyway.

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

#23

I concur with Dave…
You really don’t want fan and prism traps in your universe.

You may need both aliases AND contexts to solve your issue. If it is too complex, use separate universes and link them together if this means it’s easier for you to understand.

But linked universes also has it’s own problem in terms of maintanence down the track…

jcupy :hong_kong: (BOB member since 2004-10-13)

#24

Hi. I am relatively new to Business Objects and have been putting together some universes for our use. Most things I can accomplish well enough. However, I’ve run into an issue that I think fits within this topic.
I’ve got several related tables and I’m looking for the best way to construct the universe to support our queries. The best way to describe them is to say that the database has a table of Person records, and a table of Relationships. One Person may be related to another Person in a number of ways (sibling, spouse, parent, etc).

This can be pictured as

Person Relationship
ID ----< PersonID
-----< RelatedPersonID

or

Person1 —< Relationship >— Person2

where Person1 and Person2 really both point to the same physical table. I believe these tend to lend themselves to Aliases. However, each Person table really has a number of subordinate records in tables (addresses, phone numbers, etc).

Address1 >— Person1 —< Relationship >— Person2 —< Address2

While this can be done (and I’ve done so), it’s difficult to explain to some analysts why this construct is needed in the universe in order to answer a question like:
Give me all of Bob’s Siblings, their ages, and their addresses.

This is a simplification, as our structures actually include other types of Entities (Person, Business, Government, Organizations), all of which can be related to one another.
Is there a way that BO Universes will support this structure?

Thanks.

bradwist (BOB member since 2007-12-06)

#25

HI

I searched the forum and was not able to find the downs is any of using context and alias.
I know the ups but need to know the downs or dis advantages of using them.

can anyone help.

thanks

rajx72 (BOB member since 2006-08-02)

#26

When you use aliases you are required to create additional objects that reference the copied tables. But once you’ve done that, you’re essentially done. When you introduce contexts to your universe the steps required to maintain the universe become longer. Every time you add a new table or join you have to consider which of the contexts should include that join. If not properly designed contexts can make the universe more confusing to users as they could get prompted to select one.

But in my opinion it’s a small price to pay for the power and flexibility that they (contexts) provide. An alternative to contexts is, of course, to create separate universes, and that’s going to generate even more work. :slight_smile:

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

#27

hi Dave

Thanks for the reply. I have few more doubts: 2 contexts means i have 2 fact tables in my Universe. so

  1. Can i make a report using both the contexts.
  2. Can i join both the fact tables and make a report

thanks

rajx72 (BOB member since 2006-08-02)

#28

No, it doesn’t. :slight_smile: It means you have two different sets of joins. It is commonly stated that you need a context for each fact table, but that’s a very simplified explanation.

Yes, if you use separate queries, or enable the “Multiple SQL For each Context” setting.

Only if the joins are correct and valid.

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