Business Objects Interview Questions 2

3. What is a context in universe? How are they created?

In an universe, a context defines a particular join path between tables or a specific group of joins for a particular query. Any objects created on a table column which belong to specific contexts is naturally compatible with all other objects from same contexts. When objects from two or more contexts are used, separate SQL is generated and results are then merged in a micro cube. This makes sure that no incorrect result is generated due to loop or any other join path issue.
Contexts may be created using detect contexts feature or manually. They are generally created based on logical calculation and business requirements, hence the detect context method is not very effective. To manually create a context Go to Insert  Context, give the context name and select the joins that should be present in the context. For a universe contexts should be created in a way that all joins(except shortcut joins) fall in at least one context

4. What is a chasm trap? How can it be solved?

In a dimensional schema based universe, we may have one dimension table joined with two fact tables such that both of them are one-to-many joins(F >- D -<F ). In such a scenario, if we drag a measure each from both the fact tables along with dimensions from dimension table, the value of the measures in the fact tables are inflated. This condition is known as chasm trap.
A chasm trap can be solved using 2 methods:

• In the universe SQL parameters, the option, generate multiple queries for each measure needs to be selected. This will generate separate SQL statement for each measure and give the correct results. However, this method would not work, if a dimension (for example date) occurs multiple times in the result set due to chasm trap

• A better approach is to put the two joins in two different contexts. This will generate two synchronized queries, thus solving the problem.

5. What is a fan trap? How can it be solved?

In a universe structure, we may have 3 tables joined in such a way that, the 1st table has a one to many join with the 2nd table, which in turn has a one to many join with the 3rd table(A -< B -< C). In such a scenario, if a measure is present in the 2nd table and it is dragged along with any dimension from the 3rd table, the value of the measure will be inflated. Such a condition is known as a fan trap.
A fan trap is solved by creating an alias of the 2nd table and defining contexts such that, the normal table is joined only with the first table, while the alias is joined with both the 1st and the 3rd table. We would take 2nd table’s measure only from the normal table and other dimensions of the 2nd table from the alias table

6. Should we encounter fan traps in a data warehouse scenario? If so, then how?

If a data warehouse is based on the Kimball model, it is a dimensional schema. In a universe built on that DW, for a fan trap to occur in such a schema, we require direct join between two fact tables, which is against the principles of dimensional modeling.
On the other hand in a data warehouse based on Inmon model, it is a normalized schema. Though in such a case, universes are generally designed on Data Marts, which are dimensional schemas (where fan traps should not occur). However, if a universe is built on the DW (for the purpose of operational reporting), then a fan trap can occur in that universe

7. What is aggregate awareness? What is its advantage?

Aggregate awareness function is used in scenarios where we have same fact tables in different grains. Using this function we can define only one object for the measures in the fact tables as

@aggregate_aware(highest_level,lower level)

We also need to define dimensions for associated granularities and define their incompatibilities with the corresponding facts through the aggregate navigation. This is accesses through Tools -> Aggregate Navigation
The advantage is that in a Webi or Deski report when one drags the measure object with the dimension object of a particular granularity, the measure column from the Fact table of the corresponding granularity is selected in the BO default Query. If we did not use aggregate awareness, we would need to define separate objects for each of the fact tables which would be difficult to understand from a user’s point of view.