Hi Swetha,
Chasm trap
The Chasm trap occurs when two “many to one” joins converge on a single table. For example a customer can place many orders/and or place many loans.
Fan trap
The Fan trap occurs when a “one to many” join links a table which is in turn linked by another “one to many” join.
For example when you run a query that asks for the total orders by each order line, for a particular customer, an incorrect result is returned as you are performing an aggregate function on the table at the “one” end of the join, while still joining to the “many” end.
Chasm Trap example:
For example:
A >- B -< C
( Employees >-- Showroom --< Salary)
- Each showroom has many employees
- Each showroom has many annual salary figures
The number of employee records should not impact the total salary on the report.
If a query is written that spanned all three of those tables the data from table A and C, there would be duplicated and the measure values would be exaggerated. For example,
- X rows on the left
- Y rows on the right
- X * Y rows in the combined set
Solution 1:
Define a context for each table at the “many” end of the joins.
Context = Meaning
- A context is a sub-set of joins in a universe
- That sub-set of joins has a particular meaning
In our example you could define a context from A to B and from A to C. A context contains each join in the path. This creates two SQL statements and two separate tables in Business Objects, avoiding the creation of a Cartesian product. Using contexts is the most effective way to solve Chasm traps.
Solution 2:
Select the option ‘Multiple SQL Statements for Each Measure’ from the Universe Parameters dialog box in the tool. Only applies to measures. You force the SQL generation engine in Reporter to generate SQL queries for each measure that appears in the Query panel.
Fan Trap example:
For example:
A -< B -< C (Ex: Customer --< Orders --< Order_Lines)
A fan trap is not quite as severe as a chasm trap. In fact there are many fan traps that can occur in a universe design that can be ignored as long as you control which types of objects you use.
There are two ways to solve a Fan trap problem.
• Using an alias and the aggregate awareness function. This is the most effective way to solve the Fan trap problem.
• Altering the SQL parameters for the universe. This only works for measure objects.
Both of these methods are described below.
Solution 1:
Aliases can resolve chasm traps
- Known as table aliases when writing SQL statements
- Used by BusinessObjects to logically separate the trap into pieces.
You create an alias table and use the aggregate awareness function. You cannot use this option if you have incompatible objects. You can do this as follows:
1. Create an alias for the table that is producing the multiplied aggregation.
2. Create a one to one join between the original table and the alias table.
3. Modify the select statement for the columns that are summed so that the columns in the alias table are summed and not the original table.
4. Apply the @AggregateAware function to the select statement. for example:
@AggregateAware(SUM(ORDERS.TOTAL_VALUE) , SUM(ORDERS_2.TOTAL_VALUE))
Solution 2:
- Create a separate SQL statement per aggregation.
- Aggregations on the same table require only 1 SQL statement.
You select the option ‘Multiple SQL Statements for Each Measure’. You force the SQL generation engine in Reporter to generate separate SQL queries for each measure that appears in the Query panel. You find this option on the SQL page of the Universe Parameters dialog box in the tool.
Hope this info helps...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.