Mar 10 2008
What Is a Context Anyway?
A few days ago I finally got started on what will become a series of posts about fan and chasm traps. The post was “Do I Have a Fan Trap?” and it included a definition of a fan trap in a universe and showed a basic solution. However, it also mentioned that the basic solution would not work in most cases, and that contexts would be required for a more complete solution. If you are new to the Universe Designer, or even if you just have not worked with contexts that much, the first step is understanding exactly what a context does for you. That is what I hope to do with this post.
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.
Great post, I like the train example, it makes it a bit easier to understand!
- Josh
Wait until I start talking about climbing mountains, that’s in a future post.
Great post. Quick question which I am hoping you can help me with…”>
I have a client who is using aliasing way more than I believe they should plus, are replicating over and over the same objects.
I feel like contexts can help BUT one caveat.
The reason for why they chose alias’ over contexts, is that they are joining 4 tables, 1 client, 1 shipment status, 1 event and 1 orders table. The event table (Event Id and name only) are denormalized and represent a slowly changing dimension, in that each client can load their events relative to their individual business. Next, the status table is a derived table, based on the subtraction of two date objects within the 3rd table, orders. It needs to be joined to the Event table to get final status. Orders is joined to Clients in a straightforward join.
Can a context be used to simplify and erradicate aliasing (where appropriate) on that event and status table joins, considering the status table is derived off a join to TWO columns from Orders table and 1 column from Event, considering that events and client are denormalized (for reporting purposes)?
I know this is a confusing question, but after watching all of the manual headache of naming alias’ for each Event, Client and Status, I thought it warrant my exploration into the topic further. Thanks a ton. Sassydatachic (Laura)
Simply put, aliases are not a substitute for contexts and vice versa. The question is simple: do you have multiple paths between tables, or tables with multiple purposes? If you have something like event date that is tied to multiple different types of events, then aliases are indeed the correct technique to use.
Here is another example to help clarify things. In the Island Resorts universe there are two uses for the Country table. One is the location of the resort, and the other is the location of the customer. If you used a context to resolve this issue, you could only pick one of the two values at a time. By using aliases (the correct solution) you can answer the question, “Who visited a resort in their home country?” by applying the proper condition.
In general there is only one correct technique to apply. I intend to provide more details in a future post. Thanks, I hoped this helped some.
Dave, thanks for posting this useful information. I clicked over here from BOB and have been visiting frequently ever since!
Don
Hi, Don, I am glad you are finding some value in my ramblings. Thank you for your comment.
That was gr8 explanation. liked the anology used for context
I am a great fan of you,sir.I get inspiration from ur replies in BOB.I am budding BO developer.My kudos to BOB forum,as it is my guru.I learnt several things and will be learning.
A small request….Can you post an article on “Aggregate Awareness”?
Hi, varuna, and I am quite happy to hear that you find BOB useful.
I do have plans to post about the Aggregate Aware feature of Business Objects, but for now you can find a number of presentations already available on this subject at the Integra Solutions web library. Here is a link that will get you to the design area of the presentations page. I hope you find it useful to get started.
Dave, it is too nice to see you describing things with just a simple scenario. For me, it became a hobby to visit BOB and Dagira to understand concepts better.
Thanks Dave,
Your post really helped understand the Context Concept. Great post I must say !!
Thanks you so much for the great posts!
These are just great.. Helped me a lot…
I simply chanced upon this website and literally speaking you turned out to be my Angel
All the while I was looking for some answers on BO XI R2/R3, I happened to found all of them here.
Thanks a gazillion for sharing such valuable information with us
I am new to Business Objects and learning to work with universes. This is a great post. Great examples. Thank you!!!
how to detect traps in universe?
and how to resolve them?
Hey man, Love the post. The trip home analogy is perfect. I have a question about contexts and their limitations, and i think i can keep your analogy going. What if i needed to go home, grabbing both milk and a magazine along the way. But when i get home, i’d like to know the total amount of $$ i spent on the items. Currently, i cant find a way to create an object that is the sum (or division, subtraction, etc) of 2 other objects from separate contexts. Any suggestions?
Hi, AP, there’s a simple answer. You can’t tell how much you spent until you get home, meaning you have to do this calculation on the report itself rather than in the universe.
There’s no way to combine calculations across contexts because the specific point of contexts is to split things up. Once you have all of the data (from both trips) then and only then can you create the calculations because everything is in one place.
=( not the response but i wanted, but kind of what i expected. Thanks for the fast turn-around!
Dave, this is the first time i am into this site and i am new to BO, the way you explain is amazing, thanks a ton.
Dave, you rock the way you explain things.
Hi Dave,
Beg your pardon if it’s a silly question. If I have 3 contexts in my universe, and if I’m selecting measure objects from tables A, B and C and if A, B and C are in separate contexts, then is it safe to say that ‘BusinessObjects will generate one SQL query per context’? In general, can you please tell me if the statement ‘One SQL per used context’ is correct?
Thanks,
Chandru
great analogy .. the train example works …
excellent edifying info…thanks a lot …
vreddy.chr@gmail.com