There is a “readme” file that contains notes on how to get everything working. The reports and universes were originally built in version 5, but should be usable in any current version (up through XI 3.1 as I type this). The demonstration reports were all built in Desktop Intelligence.

No, it is not.

Contexts are designed to show which joins can be used together. If you have a multi-fact datawarehouse then almost certainly your fact tables contain different information, and therefore should not be linked (joined) together. Thus, you separate them out with contexts. Unfortunately that’s an incomplete explanation at best, and misleading at worst. The implication that some folks might take away from this is that if they don’t have “fact” tables then they don’t need contexts.

That is a very dangerous assumption. To see why, let’s look at some of the math behind some relational database concepts.

Cartesian Products

Wikipedia defines a cartesian product as follows:

Specifically, the Cartesian product of two sets X (for example the points on an x-axis) and Y (for example the points on a y-axis), denoted X × Y, is the set of all possible ordered pairs whose first component is a member of X and whose second component is a member of Y (e.g. the whole of the x-y plane):

For example, the Cartesian product of the thirteen-element set of standard playing card ranks {Ace, King, Queen, Jack, 10, 9, 8, 7, 6, 5, 4, 3, 2} and the four-element set of card suits {â™ , ♥, ♦, ♣} is the 52-element set of playing cards {(Ace, â™ ), (King, â™ ), …, (2, â™ ), (Ace, ♥), …, (3, ♣), (2, ♣)}. The Cartesian product has 52 elements because that is the product of 13 times 4.

Hm. Well. Ok. What does that mean?

It essentially means that you match every element from one set with every element of the next set, resulting in a dramatic increase in the number of combinations or tuples. A tuple in database terms is a result row that can be obtained via a query.

If you replace the word “set” with “table” and the word “element” with “row” you get an application of a Cartesian Product that is associated with database queries. In this case you get every row from the first table related (joined) to every row in a second table. This is generally not a desirable result.

What About Partial Cartesian Products?

The SQL generator used by Business Objects allows you to check for and prevent (or warn against) Cartesian Product queries. This means that a user will likely never end up with a true Cartesian Product without at least being warned about it. But the SQL generator will not detect what I will call a “partial” product without help. Here’s an example.

Note: This simple ERD is from a database I use for a number of presentations, and eventually you’ll be able to download it from the site.

In this diagram you can see relationships from customers to orders, from orders to lines, from lines to items, and from items to prices. Each item can have multiple prices over time. Each item can also appear on more than one order line. A customer can have many orders, which can have many lines, and so on.

There are no loops in this diagram. There are no fact tables. Do I need any contexts?

Presenting the Correct Picture

The answer is “Yes”, I need a context in a universe that contains this simple model. There is a relationship between items and prices, and another relationship between items and lines. But those two relationships are separate and distinct from each other and as a result cannot be used together.

Let’s assume for a moment that there is an item with item_id of 100. Let’s assume that the items has had only one price throughout its history, and that it’s $10. Finally, let’s assume that this item has appeared on 10 different order lines. If I run this SQL I will get the correct result:

SELECT	items.item_name
,	prices.price
,	lines.qty
FROM	items i
,	prices p
,	lines l
WHERE	items.item_id = prices.item_id
AND	items.item_id = lines.item_id

I should get ten rows of data back from this query, and I will.

The problem is that if the item changes prices halfway through my ten orders I will get two results from the price table. Those two rows will be combined with ten rows from the lines table because the relationship through the items table is a partial Cartesian product. This error will not be detected or prevented by the SQL generator, and the user will be presented with incorrect results. There will be two price values for each and every item row, with a net of 2 * 10 or 20 result rows instead of the expected 10. I don’t get a full Cartesian product between every line and every price because of the joins through the items table, but I still have an inflated set of rows.

I might try to solve this by creating a join from lines to prices and matching by price but that has then created a loop from lines to prices to items and back to lines. And frankly it’s not the correct thing to do.

Fixing The Partial Cartesian Product

The proper solution is to isolate the incompatible relationships. The tool that we have to do that is a context. Since the item table has two functions in this universe I will separate out those two functions using two contexts:

• First Context:
  Customers – Orders – Lines – Items
• Second Context:
  Items – Prices

The first context is designed to let me report on order history. The second context is designed to let me report on item price history. The pricing history is a completely separate subject area from order history, and by splitting them out with contexts I can ensure that a user will never be provided with an incorrect or misleading result set.

That should always be the goal of a universe designer.

Conclusion

I don’t have any fact tables in the ERD I showed above. I don’t have any loops. Yet despite this I need to set up contexts in order to generate the correct query results from my universe. Now here’s the fun part: you could provide me the exact same set of tables but number them one through five rather than give me the table name and some indication as to the purpose. If you do that, I can still set up the universe correctly, even though I don’t have a clue what is stored in each table.

How is that possible?

It’s all driven by the relationships between the tables. As long I know the type of relationship (one – one, one – many, many – many) I can create a correct universe. That’s the subject for my next post on Contexts where I will explain how it works and why the name “chasm trap” is appropriate.

Related Links

• Wiki on Cartesian Products

Just the Facts

One of the comments that you will see quite frequently on BOB is that you need one context for each fact table. That assumes that you have fact tables. It turns out that the statement is, in fact (heh, pun intended ), true, but why is that? What is it about a fact table that requires a context?

Universe Structure

A universe is a combination of two things: the structure (map) of the tables and the required joins, and the classes and objects that are presented to the user as the interface to the data. For the most part contexts are associated with the first part (structure) although they do have a user interface component as well. In the last post on this subject I included this quote:

As a designer you cannot control which objects a user selects to use on a query. You are not building a specific query, you are building a framework for any query.

What this means is that as a designer you include all of the potential joins in your universe structure without knowing in advance which query path a user is going to require for any given report. In most cases that isn’t a problem. But in some cases it might be, and that’s where contexts become valuable.

Context Definition

A context is nothing more than a set of joins. That’s it. If you were expecting something more complicated, I’m afraid that you’re going to be disappointed. The complicated part is how that set of joins is identified and then utilized, and I will talk more about that a bit later. For now, let me talk about getting home from work.

There is a train station at your office building. There is another train station at your house. Think about tables in your universe as stops you might make on the train. The joins are the routes that the train system offers. Each trip that you take has a specific starting point (a table), an ending point (another table), and a route in between (zero or more tables). Normally you take the route home that includes a stop at your neighborhood store for milk and other groceries. But occasionally you don’t need milk and instead you stop at the news stand to pick up a magazine or something else to read that evening. That stop requires you to take a different route home. Something like this:

Both trips end up with you getting home, but each trip provides different information. You either come home with a gallon of milk or a magazine.

Making Two Trips

So what do you do if you need both a magazine and some milk to go with it? In that case you have to make two stops. But the only way you can do it is to take the first route, and then return back to work and take the second route to pick up the magazine. Or you could clone yourself and take two trips at the same time. That is essentially what happens if the “Multiple SQL Statements for Each Context” option is enabled in your universe; you have the option to make more than one trip. If that option is not enabled, then you simply are not allowed to pick up both milk and a magazine.

What if you are at work, and you are ready to take the train home, and you don’t need either of those? The choice before you at that point is: Which route do you want to take to get home? Since you have not made a decision that eliminates one route (context) or the other you have to decide before you start your trip which way to go. (Maybe you’ll take a shortcut, but that’s a different technique. ) This type of query is called an “ambiguous query” because there is nothing about your trip that predetermines the route to take based on the end points (work and home). In this case the user (either the person riding the train or the user writing the query) will have to make the selection manually. In the case of a query writer the decision is done by answering a prompt with a list of available contexts (routes).

In theory, the route doesn’t matter, because you just want to get home and aren’t stopping to pick anything up on the way. Either route will work, but there is nothing about your trip plan that identifies or requires a specific route. There is an option for “Allow selection of multiple contexts” that is off by default. This really a strange option, as it allows you to make two (or more) trips on an ambiguous query.

Using the same scenario as earlier it would be like taking two trips home (both routes) without making any stops along the way just because you can’t make up your mind which way to go. Doesn’t make much sense when riding a train, and it doesn’t make much sense for a database query either. If you don’t need anything along the way, don’t make two trips. You just end up wasting time.

How Do I Define My Routes?

If a context is nothing more than a set of joins, why is it such a big deal? The first reason is that it allows you to make one larger universe rather than two smaller ones. I can make a “Milk and Magazine” universe instead of having two separate universes. Without contexts I would have to take both routes everytime I wanted to get home from work. Not only is that a waste of time, it would quite probably end up generating the wrong results. The train analogy is starting to fall apart at this point, I think.

But how do I know which routes (joins) to include in a trip (context)? There are certain signals that you can read (think of them as traffic lights) that will tell you which routes can be used together. These signals are given by the cardinality of the joins, which essentially provides information about how far you can travel on the route before changing trains. Erm. Contexts. I intend for that to be my next post in this series, as this post was intended to define what a context is and provide some examples of the concept.

Summary

Here are the most important points for this post, as I see them:

• A context is nothing more than a set of joins
• The setting Multiple SQL Statements for each Context allows you to split a single query into two or more passes based on the contexts in your universe.
• The setting “Allow selection of multiple contexts” is off by default and probably should stay off. It doesn’t really seem to help anything.

The next post will talk about how to identify the set of joins that will be used to make up a context in your universe, and it will also explain why every join has to be in at least one context.

What is a Fan Trap?

A fan trap occurs when joins “fan out” over multiple one -< many relationships in a row. For example:

A -< B -< C

This is one of the reasons why it is important to set cardinalities in your universe design. If you don’t set the cardinalities it becomes more difficult to identify fan traps (and other design issues). I frequently get asked in Designer training classes if the cardinality changes the way the joins are written. The answer is that it will not. But it could change how many joins are included in a single query.

Sample Fan Trap Data

It’s a subtle issue, so let me demonstrate with a simple example. I will use two hypothetical tables for this example. First is a table used to store order information, and the second is used to store details about the items for the order.

create table orders
(order_id number(8) not null
,order_date date not null
,order_budget decimal(11,2) not null);

create table order_lines
(order_line_id number(11) not null
,order_id number(8) not null
,item_id number(11) not null
,order_qty number(5) not null);

These are very simple tables, and the syntax may not be exactly correct for all databases. There will be an order number object built from the orders.order_id column. I will build a Total Order Budget measure object from the orders.order_budget column. And I will also create a measure object called Total Order Quantity using the formula sum(order_lines.qty). This gives me one dimension object and two basic measure objects.

Here is what the raw data will look like:

Before We Go On, A Brief Aside…

One of the statements that I make frequently in the Designer training class is this:

As a designer you cannot control which objects a user selects to use on a query. You are not building a specific query, you are building a framework for any query.

Great. Now what does it mean?

It means that the objects I have created above will generate the wrong result if they are not used correctly. Since I cannot control how they are used, I need to fix the mistake before it occurs. The mistake in this case is the Fan Trap.

A Simple Query

If I write this sql using the data above I will get the results shown below. Everything looks fine.

select orders.order_id
, sum(orders.order_budget)
from orders
group by order_id

It all works because of the “group by” clause that is automatically generated in my SQL. And it only works because I have not included anything from the order lines table. What happens if I (or a user) were to select all three of my objects?

Fan Trap Demonstrated

If I included all three of the objects from my imaginary universe I would get this sql code, and the following results:

select orders.order_id
, sum(orders.order_budget)
, sum(order_lines.order_qty)
from orders
, order_lines
where orders.order_id = order_lines.order_id
group by orders.order_id

Anybody see a problem with this?

The issue is that the line item total (sum) is correct, but the header total budget (also a sum) is way too high. If you look back at the raw data shown earlier, you might notice that the budget amount has been multiplied by the number of line items in the second table. This is a fan trap in action. The number of lines in the detail table has an impact on the measures from the header table.

Simple Fan Trap Solution

In this case where I only have measure objects from the detail table there is a very simple solution. I would open my universe and mark the “Multiple SQL Statements for each Measure” checkbox. And here is where the cardinality settings become important. Back at the beginning of this post I said this, or something along these lines:

Cardinality won’t change the logic of how joins work, but it might change which joins are included in your query.

What this means it when the SQL generator sees the measures and notes that they are spread across a one-many join, it will split the query into two passes and then merge the results back together. So instead of the infated results shown above I will get these two sets of data:

Order Number	Total Order Quantity
1	65
2	25

There were only two rows processed by the first query, and seven rows processed by the second query. There are two rows in each result set because of the “group by” clause. And when the query results are merged back together (in a process that is completely transparent to the user, by the way) they will be correct.

So Far, So Good…

The problem is this is not a complete solution. As long as I only have measure objects from the lower (more detailed) table then this shortcut will work. And as long as I never ever add a new table to the universe, or add a new dimension or detail object, it will continue to work. But it’s a fragile solution, because nothing has really been fixed.

To solve this issue in the most robust and correct way possible requires setting up a couple of contexts and an alias. But before I go through that process I want to talk about Chasm Traps, and I’m out of time for today.

But Do I Have a Fan Trap?

I will conclude this post by answering the question I started with. You have a fan trap if you:

• Have two (or more) tables in a one-many chain of joins
• Have measure objects at more than one level

You can solve a fan trap with a single checkbox if you have only measure objects from your detail table(s). Otherwise you will get inflated values, confused users, and irritated management.

Related Links

• Blog Post: Designer SQL Traps

What is a Chasm Trap

Simply put: A chasm occurs when a series of joins crosses a many >- one -< many relationship. For example:

A >- B -< C

If I were to write a query that spanned all three of those tables the data from table A and C would be duplicated and measure values would be inflated. The inflation factor can be determined by counting the number of rows from the left that match a particular key and multiplying by the number of rows on the right. For example, a chasm with 3 rows from the left and 2 rows from the right will have 6 total result rows. Any measures taken from this set of data will be inflated. Table A rows will be doubled (from the 2 rows in table C) and table C rows will be tripled (due to the 3 rows from table A).

If you’re having trouble visualizing this at the moment, don’t worry. I will have some specific data to talk about when I provide solutions to this issue.

What is a Fan Trap?

Again, to put this simply: A fan trap occurs when joins “fan out” over multiple one -< many relationships in a row. For example:

A -< B -< C

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. However, if you are not careful then it is possible to return inflated measure values from a fan trap just like in a chasm trap.

How do you recognize these situations? How do you fix them? Stay tuned, as I plan to cover each trap in detail along with various solutions in coming blog posts.