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.

Ordering of objects

When you have objects of the same class grouped together, it makes it much clearer to the business user to view when they see it in a hierarchal form instead of alphabetically. Lets take for example date objects. We have a year, quarter, month, and day object. The largest increment or grouping should always appear at the top and the most detailed at the bottom. Having this ordering will facilitate drilldowns. If these were sorted alphabetically, a business user would have to do more work in order to come up with a drilldown hierarchy.

Naming of objects

Universe Designers should always follow the 4 Cs (Customer Oriented, Clear, Consistent, Concise)

Customer Oriented
Objects created from the universe should be business oriented; anything that the business user does not need to see should never be created.

Clear
Objects should always have a clear name. For example if there are multiple types of month names (ie: Jan, 01, January), to be clear a designer should create detail objects for all 3 depending on what the business user wants to see and name them accordingly. If we just had the name “Month”, a business user would not know if it was either Jan, 01, or January.

Consistent
Object names should always have consistent formatting, this is usually a general rule so that users are familiar with the object names

Concise
Sometimes names can have a shortform ie: Article Code could be named SKU. If the article code is only 4 characters long, it would be a waste of column space on the report to have Article Code on the column heading, thus SKU would serve a better purpose unless you would want the business user to manually change report name each time.

I hope that this article will help designers put these 2 items in their good practices checklist so that it will eliminate business user’s headaches in the long run.

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.