The part that I would like to focus on is Cascading List of Values. In a real world Data warehouse for example, we may have thousands of customer codes. As a business user, in order to get to the customer codes I desire, I would probably want to select my customers from a certain region. Using Cascading List of Values, I can first select which regions I want to view and then select my customers from there.

Please note that it is important to think of the most efficient path a business user can take to get to their answer. One blunder that happens with many developers is the lack of planning when creating a Cascading List of Values. Some may include too many levels which in the long run increases the response time of user selection or too few levels which would cause users to spend too much time looking for certain values.

Here is an example on creating a cascading list of values. Let’s use a universe that contains markets inside regions and create a cascading list on markets. At the end of the day we will want to select our markets that belong to a set of regions that we drilldown from. Note that I have used markets instead of customers because it’s easier to display on the webi pic.

First we will need to go into the “edit properties” tab of the market object object. From there click on the edit button.

A query panel will come up with the market object on the Result Objects window. On the conditions window, drag and drop the “Region” object and choose the “in list” option so that we can choose from a list of Regions.

After running the query, it is important to have the Hierarchical View checked in the edit properties tab. The reason is that this view is much more user intuitive than the tabular view when selecting from the prompts. You can test this out to see for yourself.

Once you have become comfortable with creating cascading list of values, you will be able to present business users with user intuitive selections that will increase productivity and reduce response time.

Chasm Traps

Let’s talk about Chasm traps first. In short, a Chasm trap can be imagined as a bottomless pit where some rows may unknowingly fall in and never come back out. So when viewing a report caught in a Chasm trap, one may ask “Hey where did Record X go??”.

Looking at the eFashion Universe (note that this is a modified version of the efashion universe), we see that there are 2 fact tables that join to 2 of the same dimension tables. If we do not set a context for each of the fact tables in the universe, we will only get 1 query when building a report that involves measures from both fact tables.

SELECT
Article_lookup.Article_id,
Shop_facts.Amount_sold
FROM
Article_lookup,
Shop_facts,
product_promotion_facts,
Calendar_year_lookup
WHERE
( product_promotion_facts.Week_id=Calendar_year_lookup.Week_id )
AND ( Article_lookup.Article_id=Shop_facts.Article_id )
AND ( Article_lookup.Article_id=product_promotion_facts.Article_id )
AND ( Shop_facts.Week_id=Calendar_year_lookup.Week_id )

Since the promotion fact table and shop fact table are joined in the same query, we will only get results that are in both the promotion fact and shop fact table. In reality we want all available products even if they are not on promotion. The products that are not on promotion will fall down the bottomless pit and report designers will be wondering where they have gone.

Fan Traps

Fan traps are another common problem and occur when a measure is overstated. So using the same example above, the promotion cost measure is a “sum of promotion costs”. Let’s say for one product we might have 5 entries in the shop fact table and 2 entries in the promotion fact table. Instead of a one-to-many join for the promotion fact table, we now have a many-to-many join which will cause a cartesian product. The promotion cost for that product will be 5 times higher than what its supposed to be since we have 5 entries in the shop fact table.

Prevention
To prevent falling into these traps, we must properly set our contexts in the universe. Here we set a context for both the promotion fact and shop fact. As a rule of thumb we should always set contexts for facts.

Setting contexts for these 2 facts will now produce 2 queries that will be synchronized thus returning the correct results because now we have 2 seperate joins instead of 2 joins in the same table.

You can download the pdf instructions on all the opendoc parameters here opendoc detailed instructions

I’ve also provided instructions on drilling down to a Web Intelligence document from Xcelsius here

And an Xcelsius open doc worksheet template that you can use here

Let’s take an example where we have the following dimensions (year, quarter, product) and measure (revenue).

We can easily build a table to represent the sales revenue for each product in that quarter and year.

Now what if we wanted to display the sales revenue in a different context. For example we might want to display the highest quarter’s revenue each year.

You can add an aggregate row that happens after each year and retreive the highest quarter’s revenue from there.

But what if we want our values combined with the first table? This is where context calculation is important.

To accomplish this we need to take into account 3 points
calculation – maximum revenue
input context – year, quarter
output context – year

The combination of input and output contexts tells web intelligence to sum the revenue for each year/quarter and then output the maximum value for each year.

The formula to accomplish this is as follows “calculation(input context) output context” => Max([Revenue] In ([Year];[Quarter])) In ([Year])

The result will come out as the following

Finally we can insert the formula into the last column of the first table and instead of having 2 tables we can have everything on 1 table.