If that option is not enabled, then you simply are not allowed to pick up both milk and a magazine. 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. Or you could clone yourself and take two trips at the same time. 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. 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. You either come home with a gallon of milk or a magazine. Something like this:īoth trips end up with you getting home, but each trip provides different information. That stop requires you to take a different route home. 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. Normally you take the route home that includes a stop at your neighborhood store for milk and other groceries. 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). The joins are the routes that the train system offers. Think about tables in your universe as stops you might make on the train. There is another train station at your house. There is a train station at your office building.
For now, let me talk about getting home from work. 🙂 The complicated part is how that set of joins is identified and then utilized, and I will talk more about that a bit later. If you were expecting something more complicated, I’m afraid that you’re going to be disappointed. Context DefinitionĪ context is nothing more than a set of joins. But in some cases it might be, and that’s where contexts become valuable. 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. You are not building a specific query, you are building a framework for any query. In the last post on this subject I included this quote:Īs a designer you cannot control which objects a user selects to use on a query. For the most part contexts are associated with the first part (structure) although they do have a user interface component as well. 🙂 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Ī 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. One of the comments that you will see quite frequently on BOB is that you need one context for each fact table. That is what I hope to do with this post. 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. 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. 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.
#SAP BUSINESS INTELLIGENCE DEFINITION SERIES#
A few days ago I finally got started on what will become a series of posts about fan and chasm traps.
0 kommentar(er)
