BOBJ - Loops

About
Loop is a BOBJ - Join Path (or Query Path) problem which is a set of joins that defines a
closed path through a set of tables in a schema.

You often use BOBJ - Context in schema that contain multiple fact tables (multiple stars)
that share lookup tables.

Articles Related

BOBJ - Alias

dat:bobj:bobj_alias

dat:bobj:bobj_aliases

BOBJ - Chasm Traps (converging many to one joins)

BOBJ - Joins (Home)

BOBJ - Join Path (or Query Path)

Data Modeling - Issue (SQL Trap)

How Does a Loop Affect Queries?

If you created a universe based on the above structure, any query run against the tables in
the loop would return only results where the country values for resorts and the country
values for customer origin are equivalent. This double restriction on the shared lookup
Country table returns fewer rows than expected.
Result Expected

Result received

Country is serving two purposes:

Lookup for the resort country.

Lookup for the customer country of origin.

This creates a restriction so that data is returned only when the resort country is the same
as the customer country. The resulting report shows only the number of visitors from the US
who visited resorts in the US.

Breaking a loop
Depending on the nature of the loop, you can resolve the loop in Designer using either an
alias to break the join path, or a context to separate the two join paths so that a query can
only take one path or the other.

With an alias

You create an BOBJ - Alias for Country and rename it Country_Region. The two one ended
joins are now separated as follows:

Country keeps a join to the Resort table.

Country_Region is joined to the Region table.

The schema now appears as shown below:

Alias are not appropriate in such schema. See Context section for the explanation.

With a context
After the creation of an alias, the addition of a new table can create a new loop join as
shown
below

You must continue creating aliases for each new table you add to the schema. This is
difficult to maintain, and also ends up proliferating the number of similar objects using each
table in the universe.
The only way to resolve this loop is to leave the loop in place, and create a context that
specifies one or the other path around the schema. This ensures that queries answer
questions for one transaction or the other, such as: Is the customer information needed
from the perspective of sales or reservations?
You then create different sets of objects from the tables in the different contexts. Users can
then run either :

Reservation queries

or Sales queries,

You often use BOBJ - Context in schema that contain multiple fact tables (multiple stars)
that share lookup tables.

Detected by

Detect Aliases (Tools > Automated Detection > Detect Aliases)

Detect Contexts (Tools > Automated Detection > Detect Context)

Detect Loops (Tools > Automated Detection > Detect Loops)

Check Integrity

Visual analysis of schema

Solved by
Creating BOBJ - Alias and BOBJ - Context to break loops.

BOBJ - Alias
About
Aliases are references to existing tables in a schema. An Alias is a table that is an exact
duplicate of the original table (base table), with a different name.

Articles Related

BOBJ - Fan Trap (serial many to one joins)

BOBJ - Joins (Home)

BOBJ - Loops

BOBJ - Context

BOBJ - Join Path (or Query Path)

Why using alias ?

You use aliases for two main reasons:

To solve BOBJ - Loops and BOBJ - Fan Trap (serial many to one joins) join path
problem

To use the table more than once in a query.

To abbreviate the table name to save typing when writing freehand SQL.
The example Beach universe contains 2 aliases; Resort_Country for Country, and Sponsor
for Customer.
Another possible use of aliases is to create an alias for each table as it is inserted into the
schema. You then build the schema using the alias tables, not the original base tables. You
place the base tables together away from the main universe structure. This allows you to
give meaningful names to tables, and prevents the need to rebuild major sections of a
universe structure should a base table need to be aliased at a later stage.

Managing Alias
Creation

Select the table in Business Object - Universe Designer

Menu > Insert > Alias

Delete

Click an alias and select Edit > Clear.

List

Menu > Tools > List of Aliases

Structure Pane
To avoid confusing base tables with aliases, you can display the alias with the name of the
base table it represents in the table title as follows: Select Tools > Options > Graphics, and
then select the Aliased Name check box

BOBJ - Context
About
Contexts are a collection of joins which provide a valid query path for SAP BO - Web
Intelligence to generate SQL.

Articles Related

BOBJ - Cardinalities

BOBJ - Chasm Traps (converging many to one joins)

BOBJ - Fan Trap (serial many to one joins)

BOBJ - Joins (Home)

BOBJ - Loops

BOBJ - Join Path (or Query Path)

Use

You use contexts to resolve join problems that can return too many or too few rows because
of the way that tables are linked in the target database.
You need to verify that cardinalitiy are correctly set for all joins in your schema to ensure
that you have the correct contexts, and that you have valid join paths.
Setting cardinalitiy can also help you understand how tables are related in the database,
and to graphically identify potential join path problems in your schema.

To solve loop
The most common use of contexts is to separate two query paths, so that one query returns
data for one fact table, and the other query returns data for another fact table. You use
contexts to direct join paths in a schema which contains multiple fact tables. Alias are not
appropriate in such schema.
You often use context in schema that contain multiple fact tables (multiple stars) that
share lookup tables.

To solve chasm and fan traps

Contexts are also used to solve potential BOBJ - Chasm Traps (converging many to one
joins). These can occur when two many-to-one join paths converge on a single table.
Multiple rows can be returned for a single dimension causing inflated results. Contexts can
split out the query so that the correct number of rows are returned for the dimension.
Contexts can also be used with BOBJ - Alias to solve BOBJ - Fan Trap (serial many to one
joins).

Using contexts to determine AggregateAwareness incompatibility

You can use contexts to exclude objects that are not compatible with an object using the
@AggregateAware function in its definition, from being used in a query with the aggregate
aware object.

Managing Context
Creation

Automatically with Detect Context

Tools > Automated Detection >Detect Contexts

Detect Contexts examines the many to one joins in the schema. It picks up the table that
receives converging many to one joins and proposes contexts to separate the queries run on
the table.

Manually

Insert > Context

Edit

View > List Mode

Double click a context name in the Contexts list pane. The Edit Context box appears

Delete

Ensure that List mode is active (Select View > List Mode).

Right click a context name in the Contexts list box and select Clear from the

contextual menu.

Rename
Click a context and click the Rename button.

Support
One-to-one cardinality preventing context detection
A one-to one-cardinality positioned at the end of a join path can prevent Context Detection
in Designer from detecting a context. You resolve this problem by changing the cardinality
of the table at the end of the join path to one-to-many.

Incompatible query
Objects from two different contexts are combined in a query. The two Select statements are
synchronized to display returned data in separate tables.
To allow incompatible queries to be run in Web Intelligence, you must select the
Multiple SQL statements in Designer for each context option.

File > Parameters.

Click the SQL tab.

Select the Multiple SQL statements for each context check box

BOBJ - Chasm Traps (converging many to one joins)

About
Chasm Traps is see as

a Join Path problem or

data modeling issue

(convergence type ) which returns more data than expected by returning a cartesian
product.

A chasm trap is a type of join path between three tables when two many-to-one joins
converge on a single table, and there is no context in place that separates the converging
join paths.

A chasm trap inflates results without warning

Articles Related

BOBJ - Joins (Home)

BOBJ - Context

BOBJ - Join Path (or Query Path)

Example
The chasm trap causes a query to return every possible combination of rows for one
measure with every possible combination of rows for the other measure.
Measure only
on the first
fact table

Measure only
on the second
fact table
Measures on
the two fact
tables return
incorrect result
(cartesian
product) :
The query
returns every
possible
combination
of Number of
Guests
rows with ever
y possible
combination

of Number of
Future Guests
rows: the
Number of
Guests
transactions
each appears
twice, and the
Number of
Future Guests
transactions
each appears
three times.

Detected by
Visual analysis of table schema.
Unlike BOBJ - Loops, chasm traps are not detected automatically by Business Object Universe Designer, however, you can use Detect BOBJ - Context (Tools > Detect Contexts)
to automatically detect and propose candidate contexts in your schema.

Solved by

Creating a BOBJ - Context.

Using the feature Multiple SQL statements for each measure. (File > Parameters
> SQL tab )

Creating multiple SAP BOBJ - Universe (SAP BO - Web Intelligence only).

BOBJ - Fan Trap (serial many to one joins)

About
This BOBJ - Join Path (or Query Path) problem return too many rows.
A fan trap is a type of join path between three tables when a one-to-many join links a
table which is in turn linked by another one-to-many join. This type of schema is
commonly use to define a Many-to-many relationship.
The fanning out effect of one-to-many joins can cause incorrect results to be returned
when a query includes objects based on both tables.
A simple example of a fan trap is shown below:

The many-to-many relationship For one sale_id, you have more than one model_id and for
one model_id, you can have more than one saled_id. This rule is also true for the colour.

Articles Related

BOBJ - Alias

dat:bobj:bobj_alias

dat:bobj:bobj_aliases

BOBJ - Joins (Home)

BOBJ - Context

BOBJ - Join Path (or Query Path)

Example
Report without sale model column

Report with sale model column

Solved by
The original query which returned the Cartesian product for Wendy Craig, must return the
following table when run with the above solution:

Using an alias and context

The fan trap using dimension objects in the query is solved by using an BOBJ Alias and BOBJ - Context.

And multiple SQL Statements for Each Context checked (File > Parameters > SQl Tab)

Using Multiple SQL Statements for each measure

If you have only measure objects defined for both tables at the many end of the serial oneto-many joins, then you can use the Universe Parameters option Multiple SQL Statements
for Each Measure.
Multiple SQL Statements for Each Measure checked (File > Parameters > SQl Tab)

This forces the generation of separate SQL queries for each measure that appears in the
Query pane.
You cannot use this method to generate multiple queries for dimensions. If an end user can
include dimensions from any of the tables that reference the measure objects in the query,
then you must use an alias and context to resolve the fan trap.

Detected by
Visual analysis of table schema.
You cannot automatically detect fan traps. You need to visually examine the direction of the
cardinalities displayed in the table schema.

http://gerardnico.com/wiki/dat/bobj/bobj_loops
http://gerardnico.com/wiki/dat/bobj/alias
http://gerardnico.com/wiki/dat/bobj/context
http://gerardnico.com/wiki/dat/bobj/bobj_chasm_traps
http://gerardnico.com/wiki/dat/bobj/bobj_fan_traps