In any universe design project I strive for the following goals:

• Deliver the correct result
  In my opinion, this is always the number one goal in any universe design.
• User friendly
  This is quite important but secondary to correctness
• Easy to maintain
  Universe maintenance is always allowed to suffer in order to provide the first two attributes on this list, but it is a worthwhile goal to strive for nonetheless

In this post I will show how all three of these goals are ultimately met by this implementation. When I am done I will have a completed universe. This post will cover slides 26 through 30 from my 2008 GBN Conference presentation. There is a link to download the file at the end of this post.

A Brief Recap

The overall goals of this project were listed in the prior posts in this series. The most important ones for this post are:

• Each report is expected to have multiple time-sliced measures
• The process of splitting each time-slice time period into its own SQL statement should be completely transparent

Current Year and Prior Year are different time slice attributes. Every report is expected to have month-to-date and year-to-date measures that cover both the current and the prior year. That means I expect to see four different measures used in each document. The month and year date ranges are obviously different, as are the current and prior year ranges. In the last post on this topic I described a special time-slice calendar table and set up different aliases for each required time-slice. I set up contexts to keep queries from hitting more than one time-slice at the same time.

That’s how we got here. Where to next? It’s time to build some measures.

Bits and Pieces

I subscribe to the thought that anything that makes the universe designer’s job easier while making the user’s life harder is the wrong approach. However, if I can do something to make my life easier without impacting the user, then whatever I come up with is fair game. That’s how I arrived at the strategy that I am going to outline next.

Normally a “bit” is either a one or a zero. Many of the bit objects used in this solution will be just that. However, I am also going to create some special measure bits that make use of the @Select() function. As a general rule I am not in favor of using this function, but in this case I will and I will justify why in a bit. (heh, pun )

I am going to focus on creating time-sliced objects for the revenue object. In order to do this, I am going to create a measure bit called “Revenue” that contains only the table / columns required to calculate this value. I am not going to include an aggregation function for this measure which violates another one of my universe design rules. Again, I will justify why. The other bit objects will be used to select (or mark) which context is used for each time slice.

Using Measure Bits

In my time-sliced solution everything is made up of combinations. Imagine a cartesian product between measures and time periods, something like this:

Each time-slice on the left is combined with each measure on the right. Rather than create six different references to the revenue formula shown here…

INVOICE_LINE.DAYS * INVOICE_LINE.NB_GUESTS * SERVICE.PRICE

…I am going to create just one. Notice that the code shown above does not have an aggregate function? This is by design… I am going to use the @Select() function to build my visible measure objects. Here’s the initial part of the object definition for the CY MTD Revenue object.

sum(@Select(Measure Bits\Revenue))

By leaving the aggregate function out of the source measure I can also create a minimum, maximum, or other aggregate version of the sales revenue. This is because the code referenced by the @Select() doesn’t have an aggregate… and why is this important? Because I can’t nest aggregate functions. If my source measure included the sum() function then that’s all I can do with it. By keeping it generic (no aggregate) I can reuse it with any aggregate function as needed. So that’s why I am breaking the rule that says every measure must have an aggregate function.

Ultimately the measure bits are going to be hidden from view so they will never be viewable / usable by report writers. They are only used as building blocks in the Designer application.

Time Slice Bits

Now I need to build some time-sliced bits. These are really simple. Here’s what the object definition looks like for the CY MTD bit object.

The select clause contains the number 1 and that’s it. Notice what the help text says? In big CAPITAL letters it says “DON’T FORGET THE TABLE!!!” I wonder what that means?

Here’s what it means. The 1 is just a placeholder to put something in the Select clause. The Where clause is empty. The From clause comes from the table list, and here’s what that looks like.

Stick with me just a little bit longer and this will all make sense. Remember that in the earlier posts I set up aliases for my time-slice calendar table. Each alias became part of its own context. A context is a series of joins that make up a particular path through a universe. What I am working towards is a set of time-sliced objects that a user can drag onto their query panel without having to worry about where they come from or how they’re put together. Here’s what my schema looks like as a reminder. All of the aliases are on the right side.

This structure gives me a way to automatically split out each time-sliced measure into its own path so that a user can combine CY MTD and PY MTD and any of the other options onto one query and run it.

Here are some real comments that were posted on BOB.

I already have around 18 contexts in Universe and hence I dont want to add any extra

The last two companies I have worked at, forbade the use of contexts

I only create contexts when I’ve got no other choice.

And this one wins the prize:

Here’s a list of what I cannot do (client requirements)

1. Cannot use contexts in the universe.
…

If you recognize one of your comments, please understand I am not ranting about you as a person, but about the sentiment or opinions expressed in the comment itself.

As a consultant, my job was sometimes to deliver a solution. At other times my job was to provide advice. My advice was based on my assessment of two things: what the client told me they wanted, and what I felt like they really needed. As a worst-case scenario I was always prepared to walk away from a job rather than work under rules and restrictions that I knew were incorrect and that would prevent me from delivering the proper solution.

So there is really nothing more frustrating to me than to see comments like what I posted above. If I had a client tell me that I could not use contexts, then my job was to find out why they had that opinion, and then do my best to educate them. Sometimes it was because of a bad experience. Sometimes it was because of a lack of proper understanding of what contexts were supposed to be used for. When building a universe, the number one goal should always be to deliver the correct result. Speed and ease of use are secondary. Contexts are frequently a critical component of a successful universe.

So to the next person who gets a job where the client says to them, “You cannot use contexts,” here is my advice: first try to educate the client as to the proper use of contexts. If that fails, walk away, and take another job. To a client who has a consultant tell them, “You really don’t want to use contexts, they’re much too complicated,” here is my advice: hire another consultant. As a client you’re under no obligation to educate the consultant.

Contexts have a purpose. They’re not a necessary evil, they’re just necessary.

• Each report is expected to have multiple time-sliced measures
• Users must be able to select the type of calendar during the refresh process; calendar types include Monthly and Fiscal
• Users can provide any possible date as the “to date” for the time slices
• The process of splitting each time-slice time period into its own SQL statement should be completely transparent
• The resulting SQL should be as efficient as possible

In this post I am going to cover the design of a special table that we built in order to support our solution for these requirements. After I talk about the table design I will cover how I use it in the universe, as well as provide a few pros and cons about this solution as I have outlined it so far. Just to prepare you, this post is a bit longer than most that I write, and gets fairly detailed. This post will cover slides 23 through 25 from my 2008 GBN Conference presentation. There is a link to download the file at the end of this post.

Time Slice Calendar Table Definition

Each time slice has a start date and an end date. The actual dates will change based on whether I am looking at a fiscal quarter or a calendar quarter. I need to be able to provide any reference date as my “to date” or input date for each time slice. Finally, I want to be able to compare the current year values with the matching prior year values. All of these requirements can be solved with the following table structure:

The ref_cal_dt is the reference calendar date. Every time I use this table I need to provide that date, either via a prompt or condition of some kind. If you don’t need the flexibility of redefining the “to date” value in your environment this can be removed. The next two columns are codes for the time slice and calendar type. The last four columns contain the starting and ending dates for each time slice; the first two for the current year and the last two are the matching dates for the prior year. I will talk about each of these columns in a bit more detail in the following paragraphs. I am going to save the reference date for last.

The cal_tmslc_mn_val contains values like MTD, QTD, YTD, FM, FQ, and FY. Each of these codes represents a time slice. For example, QTD is Quarter To Date and FQ is Full Quarter. The type of quarter (monthly or fiscal) is determined by the next column.

The cal_nm or Calendar Name column is used to differentiate between the different types of calendars stored in the table. For our implementation we had two calendars, but there is nothing that says I could not create more if needed. I had to create fiscal time slices and calendar type slices to solve my requirement, and the names became Month Calendar and Period Calendar. I was asked at one point why we stored the full text representation rather than a code. If my memory is correct, we configured this column as a compressed character column in Teradata. Since there are only two values, the compression algorithm was very effective.

Here is some sample data from my table. I mentioned earlier that in order to use this table I have to provide an input or “reference” date. For the sample data shown below, the reference date was August 15, 2008. The resulting rows show the start date and end date for all of the available time slices for each calendar type (Month or Period). Both the current year (CY) and prior year (PY) date ranges are retrieved on the same row.

What does this tell me? I see that for August 15, 2008, using the Month Calendar, the month to date (MTD) range starts on 8/1/2008 (all dates in this blog post are in MM/DD/YYYY format) and ends on 8/15/2008. The full month starts on 8/1/2008 and runs until 8/31/2008. If I switch to the Period Calendar instead, I see that the MTD range runs from 8/10/2008 to 8/15/2008, and the full month (fiscal month rather than calendar month at this point) runs from 8/10/2008 to 9/6/2008.

Now, about that reference date… in our requirements we had to allow the user to redefine the “to date” for any time slice. It is fairly standard for the “to date” to be the last warehouse refresh date. Since we had to be able to run any report for any “to date” our table starts with the reference date. In the sample data posted above, the reference date was always 8/15/2008. I would see another set of rows for 8/16/2008, for 8/17/2008, for 8/18/2008, and so on. Every single possible date value was stored in the time slice table, and the starting / ending date ranges for all time slices and calendar types were computed and stored for each one.

There is one important note about performance that is appropriate at this point. Because we had to be able to roll values up by multiple calendars, we were required to store all of our data at a daily grain in our fact table. Since weeks do not fall on month boundaries, and since fiscal and monthly calendars do not share the same date ranges, the only possible way to solve the issue was to leave things at the daily grain. As you can imagine, this caused some challenges with query performance.

Join Fact Table to Time Slice Table

Now that I have thoroughly explained my special calendar table and its contents, how am I going to use it? This table is going to be the “driver” for my time-sliced measures, and drivers need roads. (That is, unless you have a nuclear powered DeLorean. ) I’ve posted before about contexts being paths or routes through a universe, and that’s what I need here too. But with only one calendar table and one fact table, where will I get different roads? First I need aliases.

I will create an alias of my special calendar table for each time slice definition. That means since I have six time slices (MTD, QTD, YTD, FM, FQ, and FY) and two years (Current Year CY and Prior Year PY) I need to create 12 aliases. After I do that, I create joins from each of these aliases to my fact table. Normally having multiple dimensions per fact is going to be fine, but in this case I want to ensure that every different time slice forces a separate SQL path… and now I’m back to where I need to create the contexts.

Here’s what a slightly simplified version of the universe looks like. I only created the “To Date” slices and left the “full” versions out for now.

Yes, that is a picture of the venerable Island Resorts Marketing universe, but with some aliases of my time-sliced calendar table added. Each of those aliases is joined to the “fact” table called SALES. The original CAL_TIMESLICE table is in the universe in the lower left corner. The six aliases are outlined in red on the right. Each alias has a join that looks like this:

SALES.INVOICE_DATE between cy_mtd.CURR_YR_TMSLC_STRT_DT and cy_mtd.CURR_YR_TMSLC_END_DT AND cy_mtd.CAL_TMSLC_MN_VAL = 'MTD' AND cy_mtd.CAL_NM = @Prompt('Please select Calendar Type','A','Time Slice Calendar\Calendar Name',mono,free) and cy_mtd.REF_CAL_DT = @Prompt('Please select Calendar Date','D',,mono,free)

I will break this down into steps.

The most direct part of the join takes the invoice date and compares it to the time slice start date and end date, using the BETWEEN operator.

SALES.INVOICE_DATE between cy_mtd.CURR_YR_TMSLC_STRT_DT and cy_mtd.CURR_YR_TMSLC_END_DT

Next, I want to make sure I get exactly one date range, and that is done first by hard-coding the time slice mnemonic value…

cy_mtd.CAL_TMSLC_MN_VAL = 'MTD'

… and then prompting the user to select the calendar type.

cy_mtd.CAL_NM = @Prompt('Please select Calendar Type','A','Time Slice Calendar\Calendar Name',mono,free)

As an aside, I created a join with a prompt for time-slice code as well. This is a nice enhancement that lets the user pick a single measure for their report and on-the-fly swap it from MTD to QTD or YTD or any other defined time-slice. Of course they can only use one at a time, so that is a limitation of that technique.

The final part of the join in my case was a date prompt for the reference date. This is the “to date” that I talked about earlier in this post. Please note that there is no LOV for the reference date; I rarely provide a list of values for dates since there is not much value added by that overhead.

cy_mtd.REF_CAL_DT = @Prompt('Please select Calendar Date','D',,mono,free)

The join logic is the same for every alias except for the hard-coded mnemonic code for time slice.

Checking Join Structure

In this scenario as I have built it so far, have I introduced any loops? any fan traps? The answer to both of those questions is “No, I have not.” However, I have introduced incompatible joins.

For example, suppose that a user picked a MTD and YTD object at the same time. The SQL (abbreviated here) would include this:

cy_mtd.CAL_TMSLC_MN_VAL = 'MTD'
AND cy_mtd.CAL_TMSLC_MN_VAL = 'YTD'

This is a problem but one that I anticipated. At the beginning of this process I said I wanted to create a way to dynamically and transparently generate separate SQL passes for each time slice. I explained the structure and data for my table, and now I have shown how I join that table to my sales fact. The last step is to isolate each one of these aliases into a separate context. Using my shortcut for copying a universe context this step takes only a few minutes to complete for the initial configuration. Each context includes all of the tables from the original Sales context plus exactly one alias of my special calendar table. Here are the joins for the current year MTD alias:

And then I create a context for each of the others as well; here is a list of the contexts from my universe at this point:

Why This Strategy?

As I have been sharing this design concept at various conferences or with other universe designers I invariably get questions like “What made you go this route?” or “Why not alias the fact table instead?” and so on. They are fair questions, and I don’t have time to answer all of them in this post. I will try to quickly point out a few advantages to this technique.

If I alias a fact table I can almost certainly guarantee that I will introduce additional loops in my universe structure. There is a limit to the number of loops that can be detected / displayed by Designer, so adding extra loops when I don’t have to is not in my best interest. Plus, as blog readers will see soon when I start building objects on this structure, there is a big benefit to having all of my measures come from a single fact.

This technique does not add any new chasm or fan traps to the universe.

This technique allows me to support a potentially infinite number of time slices without doing any date calculations on the fly.

This technique allows me to support a potentially infinite number of calendar types. Here I have shown both fiscal and calendar types, but I could easily add more.

On the negative side, there are complexities associated with creating contexts in the universe. I mentioned above that creating the initial contexts is simple. Any future maintenance will be more complex as a result of all of the contexts in the universe. However, I submit that the complexities of the universe are more than paid for by the advantages to the users who will be creating reports. And whether I chose to alias the fact or the calendar table I would still have this issue so it’s really a moot point.

Next Steps

At this point I have accomplished the following:

• Created and populated my special calendar table
• Created aliases for each time slice / year combination (only “to date” versions are shown in this post, but I did create the “full” aliases and contexts as well in production)
• Created joins that link each time-slice calendar alias to my fact
• Created contexts to ensure that each time slice will appear in a separate query pass

What’s next? I have to create some objects so my users can make use of all of my hard work so far. That’s my next post in this series, which will cover slides 26 through 30 of my talk. Stay tuned.

Related Links

• Conference presentation download: Universe Designer Essentials and Beyond
• Prior post in this series: Time-Sliced Measures Part I: Defining the Problem
• Other supplemental information: Teradata Compression Explained

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.

This post is related to slides 13 through 17 from my 2008 conference presentation.

What is an Alias?

The alias technique has been around far longer than Business Objects has. Whenever a SQL script needs to access the same table more than once an alias is used. One of the easiest examples is an employee table that contains a key to the employee’s manager. In order to return a list of employees and who they work for I might write SQL code something like this:

SELECT emp.name
, mgr.name
FROM employees emp
, employees mgr
WHERE emp.mgr_id = mgr.emp_id

There is only one table in the code: the employees table. However, in order to get the employee name and the manager name, I need to join the table back to itself. In order to accomplish that, I have to give each side of the relationship a unique name. That is the SQL alias for each table, and the same technique is used in building universes.

Aliases are more typical in a universe environment with lookup tables. For example, in the screen shot shown below (taken from my presentation) the COUNTRY table has two unique purposes. In one case it is used to show where a Resort is located. In the other case it contains the Region for each customer. An alias is indicated by the fact that the COUNTRY table is always on the “one” side of a one-to-many join. This issue (and solution) can be found in the Island Resorts universe.

To summarize so far: an alias is used when the same table is used more than once, and is typically indicated by that table always being on the “one” side of a one-to-many join.

What is a Context?

A context, on the other hand, is a concept that probably originated within a universe. If a SQL developer decides that he or she needs two scripts to get the job done, then that’s what they write. But a universe is supposed to be able to generate SQL for a non-developer. So how can it have the intelligence to know when to split something into multiple SQL passes? That is the role of a context.

Here is another screen shot borrowed from my presentation.

In the diagram shown above, the two end points are CUSTOMER and SERVICE. There are two ways to figure out which service a customer is related to. The first relationship goes through the reservations tables and is used to show which services a customer has requested. The second relationship goes through the sales tables and is used to bill the customer for services used. These relationships are equally important.

A context is indicated in this case because there is a loop. (Please note, however, that contexts also solve fan and chasm traps which do not involve loops.) A loop in a universe is found when a sequence of joins can be selected that start and end at the same table. In this case, I could map from the CUSTOMER table through the INVOICE_LINE table, the SERVICE table, back through the reservations tables and end up back where I started. That’s a loop. If the loop is not resolved in some way, Desktop Intelligence and Web Intelligence will issue an “incompatible combination of objects” message rather than run the invalid SQL.

An alias was indicated by tables on the “one” side of every join. Contexts are indicated by tables appearing only on the “many” side of a one-to-many join. In this loop, those are the RESERVATION_LINE and INVOICE_LINE tables. Those tables will ultimately drive my context creation process.

To summarize contexts: they are used to resolve loops (and other SQL traps) and are indicated by tables always appearing on the “many” side of a one-to-many join.

Context Versus Alias

I have shown examples of where each technique would be appropriate. Is it possible to use an alias to solve a context issue, or a context to solve an alias challenge? To be honest, yes. But you would end up creating more problems than you solve. Here’s a summary of the two features:

• Alias Features
  • Aliases are simple to create
  • Objects for each alias can be created, for example Resort Country and Customer Country from my example given above
  • Once created no further maintenance is required
  • Aliases eliminate (break) loops
• Context Features
  • Contexts are more complex to create
  • Every join must exist in at least one context; if not, it becomes an isolated join
  • Loops are not eliminated; two (or more) paths are identified and used but the loop remains
  • Contexts can also resolve fan or chasm traps

I have seen more than one post on BOB where people say things like, “… my client doesn’t allow contexts…” or “… won’t use contexts because they are too complicated…” and I cringe. You would not use a hammer to put in a screw because a screw-driver is “too complex” so why would you use the wrong tool to resolve an issue in a universe? It doesn’t make sense.

Conclusion

Aliases and contexts are not substitutes for each other: each has a unique purpose and a place in universe design. I tried to show that in my brief overview slides in my presentation, and hopefully have added some value by including more detail in this post. I have other posts on contexts and aliases and other universe design issues published, and a few more in draft form that I hope to finish as time allows. The complete presentation can be downloaded from my presentations page, linked below.

Related Links

• Conference presentations page
• Universe Designer Essentials and Beyond conference presentation

But I have yet to figure out how the contexts are ordered on the same screen. Has anyone ever noticed a pattern as to how the order of contexts is determined? If so, I would love to hear it.

How can I copy a context?

There are a number of reasons why you might want to do this. In a semi-complex universe you might have a bunch of snowflake tables and a series of fact tables. After building the first context, the second (third, fourth…) are essentially the same but with a different fact table. As far as I know there is no way to copy / paste a context, but there is a fairly simple way to source a new context from an existing one. Here’s what I do:

1. Create the first context
2. After saving the first context, make sure List Mode is activated (it will be on by default if this is the first context in the universe)
3. Click (not double-click) the first context to highlight it; this will select all of the joins that you included in that first context
4. With the CTRL key and your mouse, deselect joins to the first fact and add (select) joins to the second fact; when you are done you will have all of the joins that were created in the first context except for the fact table joins
5. Click the “Add Context” button on the toolbar, or make the equivalent selection from the menu

When you’re done, you will have created a second context based on the first context, even if you cannot copy and paste a context definition. It works very well.

I have a universe for my current project that has 22 extremely similar contexts. There is only one table that is different from one context to the next, and each context contains a large number of joins. It would have been a real nightmare to try to create each context manually (and I suspect prone to error). Using this technique made the context creation step very easy.

Related Links

• Topic on BOB where I originally answered this question

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.