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.

• 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

In each case I was able to tell the person that we had considered and perhaps even tested their suggestion and found it lacking in some way. I didn’t have time to present all of the different options during the one hour slot that I had at the conference, but I have unlimited time to explain options here on my blog. But before I go back and detail things that we tried that did not work out so well, I am going to have a few posts (it’s too long for just one) about the solution we did implement.

This blog post will cover slides 19 through 22 from the 2008 GBN Conference presentation.

What is a Time-Sliced Measure?

Measures are analytical values defined in a universe. Time can be “sliced” into intervals like period (or month), quarter, and year. The combination of phrases as “time-sliced measures” is generally used to describe special measure objects built in a universe that automatically get associated with a specific time interval. So the measure “Period to Date Revenue” would provide a total of revenue for the period to date. In most cases the “to date” is the last load date for the database, but it does not have to be so.

Why are Time-Sliced Measures a Challenge?

Once time-sliced measures are created, users often want to combine them. A simple query might include Period to Date (PTD) and Year to Date (YTD) for both the Current Year (CY) and the Prior Year (PY) all at the same time. If the time-sliced measures are created with hard-coded date ranges, then each would be incompatible with the rest. A YTD measure has a different date range than a PTD measure. Using both together without some sort of mechanism to split them out would result in the YTD value being impacted by the PTD restriction.

Of course with Web Intelligence users can create multiple data providers. A user could be knowledgable enough to split the various measures into different queries. There are several problems with this approach.

First, it requires the user to know and understand and implement the solution. This requires training and still doesn’t prevent a user from making a mistake. It’s also a very repetitive process. Every time a user wants to retrieve more than one time-slice they would be doing the same process over and over. What if there was a way to force Web Intelligence to split the queries into multiple passes for each time-slice instead?

Contexts Create Multipass SQL Statements

In the conference presentation I spent a few minutes prior to this topic talking about contexts. Contexts are used to split SQL into multiple passes based on loops, fan, or chasm traps in a universe. At this point I have a problem that requires me to generate multiple SQL statements, and a universe design technique that does just that. It’s time to put the two together in a solution.

Business Requirements

Here are the requirements that I was presented with:

• 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

The typical time-slices used include CY PTD, CY YTD, PY PTD, and PY YTD. However, the “P” in PTD could be Month (MTD) instead of Period based on the result of a prompt. The users on this project needed to be able to see the daily data rolled up my month or period, by calendar or fiscal quarter, and so on. They wanted this to happen automatically so casual adhoc users would be able to use the universe, and of course they wanted the answers in five seconds or less. This from a fact table that was expected to grow into the billions of rows.

In the next post for this series I will cover slides 23 through 25 and provide details about the special calendar table we created in our database to support our solution.

Related Links

• Universe Designer Essentials and Beyond conference presentation

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

It was certainly different for me. Presenting to a live audience is not stressful to me at all anymore. I have enough experience that it just doesn’t bother me. Whether I am delivering a training class to an audience of ten, or a conference presentation to an audience of hundreds, it doesn’t make me nervous at all. But today on the call was a different story. I was quite nervous! I had all sorts of worries. What if my Internet connection goes down? What if my dog barks, or my doorbell rings? (I was doing the presentation from home to avoid the background noise from being in an office.) None of those things happened, which is good.

What I didn’t realize until going through the presentation was how much I “feed” off of and react to the audience during a live presentation. When I am delivering live content I get a feel for whether people are interested in what I have to say. As long as their eyes are open and facing forward, and heads nod in appropriate places, I figure things are going okay.

On a webinar, that wasn’t possible.

I logged in to the webinar website as the presenter from my laptop. I also logged in as an attendee from my desktop. By doing that, I was able to monitor exactly what everyone else was seeing. I think that helped because it was easy to make sure I didn’t get ahead of the screen refresh. I also tried to keep an eye on the chat room and watch for questions. When I could, I tried to incorporate answers from chat questions into my talk. I think that process went okay, but I know that I would do a better job next time.

In any case, if you’ve joined the GBN you’ll soon be able to review the webinar online and judge for yourself. I don’t have an estimated time for publication, but as soon as I find out that the session is available I will be sure to post it here.

There are other speakers from the GBN conference that will be delivering their presentations in this format as well. I just get to go first and iron out all of the bugs in the process.

A universe has three basic types of result objects: dimensions, details, and measures. Measure objects are analytical values like dollars or quantities. Measure objects have two extra settings that dimensions and details do not have: a SQL aggregate function and a report Projection function. The SQL aggregate function is not enforced by the application, but it should always be present. (That’s a subject for another blog post. Or two.)

The SQL aggregate function is performed by the database server, and the projection function is used by the report engine. This is what makes measures “roll up” when you slice and dice or drill on a report. The problem is, certain calculations cannot be done by the database because there is no valid projection function. Designer 3.x gives me a way to address that by introducing a new projection function setting of Database delegated. This post will explain why that’s important and how it works.

How Projection Works

The projection function is designed to complement the SQL aggregation operation. For example the Revenue object from Island Resorts has the following SQL formula:

sum(INVOICE_LINE.DAYS * INVOICE_LINE.NB_GUESTS * SERVICE.PRICE)

The object also has a Sum projection function. If I run a query that returns the Resort and the Year and the Revenue the output looks like this:

Using a simple drag-and-drop technique I can remove the Year from the output block and the projection function causes the data to roll up to this result:

This is all controlled via the projection function which is a part of the object properties screen as shown here:

When Projection Fails

This all works very well until a special function like Average is considered. Averages cannot easily be projected because the source data could be very skewed. A sum operation can be applied recursively. What this means is that 1 + 5 generates the same result as 1 + (2 + 3). An average is not recursive. An average of 1 and 2.5 is not the same as an average of 1, 2, and 3. For the record, and average of 1 and 2.5 is 1.75, and an average of 1, 2, and 3 is 2. Even with a very small set of data the results of an average projection can be very wrong.

The basic problem here is that averages have to work with the source data. I cannot apply an average to an average and expect to get the correct result. It is for this reason that report developers have had to create average and percentage calculations on their reports rather than reusing an object from a universe. In order to deliver the correct result I have to work with the source data.

Averages Do Not Average Well

As I said in the prior paragraph, the only way to generate the correct result for an average is to recalculate it from the source data. In order to demonstrate this I have created an Average Revenue object in my universe. For this screen shot I have used the average object in two different queries. The first shows Average Revenue by Resort and Year, and the second shows Average Revenue by Resort only.

The object is created with the following SQL:

avg(INVOICE_LINE.DAYS * INVOICE_LINE.NB_GUESTS * SERVICE.PRICE)

… and the projection function is set to Average. As I did before I can apply a simple drag-and-drop operation to remove the Year object from the first block, allowing the report engine to project the Average Revenue using the selected projection function of Average. Are the results correct?

The results are wrong because the projection in the first block is taking three years of data, summing them up, and then dividing the total by three to get the new average value. The true result based on a database calculation is shown in the right block. The second block was not affected by the Year values since the query did not include that object in the result set.

Delegated Measures

This is where the delegation process comes in. As a universe designer I can now create an object that will project correctly (yay) at the expense of having to run a database query (boo). Instead of projecting my average calculation using the Average function, I will use the Database Delegated option instead. Here’s how that looks:

When I run the same query with my new measure definition here is what the initial output looks like:

The difference becomes apparent when I drag-and-drop the Year object away from my block:

The note #TOREFRESH is telling me that before I can see the numbers for that column I have to refresh my document. I think that it’s nice that it doesn’t refresh right away, as it gives me the opportunity to make more adjustments. Perhaps on a more complex report I want to remove (or add) more than one object from the block. In any case, when I click the refresh button the results are displayed.

Note that the two blocks are 100% the same now. The option to delegate the average calculation to the database has given me the power to create an entirely new type of object that I could not have done before.

Conclusion

This is another nice new feature for Designer. It will provide me with better control over how my measure objects are handled. In this case, the solution is not without a cost… I may have to refresh the report in order to force the data to be updated. If the query takes a long time to run, there is a cost involved. It may ultimately still be easier to do this type of calculation on the report.

Here is another challenge that is not solved by this technique: I can’t do calculations that cross contexts in the universe. Suppose that I have one context for current year measures, and a second context for prior year measures. If I want to compare current to prior year values, that has to be done on the report. Delegating that calculation to the database is not possible because the values come from two different contexts.

But it’s nice to have options.

This feature was one of several mentioned in my Designer Essentials presentation delivered at the 2008 GBN conference. This particular feature was on page 10.

However this strategy had one major flaw in that if the table was not referenced in the query then the security would not be applied. I now have a much more flexible (and powerful) option in Designer 3: Class Restrictions.

Stub Join Review

Here is what a stub join looks like in the structure window.

The extra stub hanging off of the table includes the following syntax:

RESORT_COUNTRY.COUNTRY_ID = 1

The intent of this simple restriction is to apply a restriction so that the only country allowed to be displayed in this universe is the US, or Country ID of 1. Does it work? Sort of.

If I create this query:

… here is the SQL code generated:

SELECT
RESORT.resort,
SERVICE_LINE.service_line,
SERVICE.service
FROM
SERVICE,
SERVICE_LINE,
RESORT
WHERE
( RESORT.RESORT_ID=SERVICE_LINE.RESORT_ID )
AND ( SERVICE_LINE.SL_ID=SERVICE.SL_ID )

If I include the country object in the query, then this is the SQL code generated:

SELECT
RESORT_COUNTRY.country,
RESORT.resort,
SERVICE_LINE.service_line,
SERVICE.service
FROM
SERVICE,
SERVICE_LINE,
COUNTRY RESORT_COUNTRY,
RESORT
WHERE
( RESORT_COUNTRY.COUNTRY_ID=RESORT.COUNTRY_ID )
AND ( RESORT.RESORT_ID=SERVICE_LINE.RESORT_ID )
AND ( SERVICE_LINE.SL_ID=SERVICE.SL_ID )
AND ( RESORT_COUNTRY.COUNTRY_ID = 1 )

The important difference is that the first query does not include the intended restriction. Why not? Because the stub join is only included when the affected table is included in the query. This is a fairly substantial drawback to this technique.

Class Restrictions

Here is where this new feature shines. I can create a class restriction that is applied to every object from the class. The philosophy is similar; a stub join is applied to every element from a table; the class restriction extends the concept to a universe class. Is this powerful?

If I create the same query as above:

… here is the SQL generated:

SELECT
RESORT.resort,
SERVICE_LINE.service_line,
SERVICE.service
FROM
SERVICE,
SERVICE_LINE,
COUNTRY RESORT_COUNTRY,
RESORT
WHERE
( RESORT_COUNTRY.COUNTRY_ID=RESORT.COUNTRY_ID )
AND ( RESORT.RESORT_ID=SERVICE_LINE.RESORT_ID )
AND ( SERVICE_LINE.SL_ID=SERVICE.SL_ID )
AND
( RESORT_COUNTRY.COUNTRY_ID = 1 )

Look carefully, and you will see that the RESORT_COUNTRY table is not included in the SELECT clause at all, yet the restriction is still applied to the query. How was this done?

Building a Class Restriction

I start the process using the same technique that I would use to build a standard predefined condition in the universe. I create the new condition with the appropriate logic, as shown in the screen here. The new features are configured using the options on the lower corner of the dialog box.

All I have to do is check the “manditory” box and select Apply on Class and the condition is applied to every object from that class. If I create additional objects and insert them into that class, these new objects will automatically inherit the same condition restriction without additional work from me.

And it gets better.

Building a Universe Filter

Here is a closer view of the options on the dialog box:

There are two choices: Apply on Universe and Apply on Class. Hmm.. I wonder what the first choice does?

I selected the Apply on Universe option and created a query that referenced several different tables in order to derive the sales revenue. Here is the SQL that was generated:

SELECT
sum(INVOICE_LINE.DAYS * INVOICE_LINE.NB_GUESTS * SERVICE.PRICE)
FROM
INVOICE_LINE,
SERVICE,
SERVICE_LINE,
COUNTRY RESORT_COUNTRY,
RESORT
WHERE
( RESORT_COUNTRY.COUNTRY_ID=RESORT.COUNTRY_ID )
AND ( RESORT.RESORT_ID=SERVICE_LINE.RESORT_ID )
AND ( SERVICE_LINE.SL_ID=SERVICE.SL_ID )
AND ( SERVICE.SERVICE_ID=INVOICE_LINE.SERVICE_ID )
AND
( RESORT_COUNTRY.COUNTRY_ID = 1 )

This is powerful stuff. I could create a hidden class in my universe, create any number of predefined conditions as universe filters, and leverage the @variable(’BOUSER’) restriction to apply security to the entire universe. No matter which objects a user selects for their query, my security would get applied 100% of the time. I like it.

Conclusion

Stub joins were often used to apply security via a reference to the BOUSER variable. The problem with this solution is that the security was only applied to that table. If the query did not reference that table, the security didn’t get applied. The work required by the designer at this point was substantial… he or she would have to work through the entire universe and add that table to every object reference.

As a universe designer I now have the option to create a special condition at a class level. I can even create a condition that will be applied accross the entire universe. This is good stuff, and a feature that I am sure will be well received by universe designers everywhere.

This feature was one of several mentioned in my Designer Essentials presentation delivered at the 2008 GBN conference. This particular feature was on page 11.

Documentation is Good

Designer 3.0 is the first time that I have been able to find the extended prompt syntax documented. It even mentions the primary_key attribute which was apparently present (and usable) in XI R2. This feature allows me to create prompts in the Universe Designer that will still leverage Index Awareness, assuming I have set that up.

Here is the prompt syntax shown in the XI 3 Designer manual:

@Prompt(’message’,'type’,[lov],mono/multi,free/constrained/primary_key,per
sistent/not_persistent, [{'default value':'default key'[,'default value':'default
key',...]})

I’ve covered the prompt syntax before so I won’t review everything. But the new features are interesting. The new feature primary_key was used in my “Ninja” presentation from last year with a disclaimer about it being an “undocumented feature” and the note of being a bit risky to use as a result. Now it is not only documented but there is a modifier for the default value option as well.

Using Index Aware Objects With Prompts

Recall that index awareness is designed to create more efficient SQL. Instead of

RESORT.RESORT = 'Bahamas Beach'

I would see

RESORT.RESORT_ID = 2

With the new prompt parameter I can specify the default value in a value:key pair, like this:

RESORT.RESORT_ID = @Prompt('Please select Resort', 'A', 'Resort\Resort', mono, primary_key, not_persistent,{'Bahamas Beach':'2'})

The option mono of course means I will only select one value. That is not new. The option primary_key tells the SQL generator that this object is index aware, and that I want the key to be used rather than the value. The option not_persistent is used to tell the SQL generator that I don’t want to retain the last user selected value. And finally, the string 'Bahamas Beach':'2' is used to show that the default value shown to the user is Bahamas Beach but the default value provided to the prompt is the key value 2 instead.

Special note: if I want to use a default value, then I have to specify not_persistent. If I don’t, then the default value is only good the first time the query is refreshed. From that point forward the last user selection will be used instead.

What About Those {}?

A reader with extremely good attention to detail will notice that the syntax I posted above does not match what was shown in the user manual. In order to get the object to parse I had to follow the exact syntax shown in the function help in Designer rather than what is in the documentation. What’s different? The code I used has curly braces { } around the value:key pair at the end. The curly braces are also used when providing a hard-coded list of values, so I guess that’s not too surprising.

Conclusion

The primary_key and default:key additions to the @prompt() syntax are quite powerful, and should be well-received by universe designers. I feel much more comfortable using something that is documented (even with slight errors) than using a feature that isn’t detailed in the documentation or help files anywhere. The concept of index awareness just became a lot more attractive with this addition.

This feature was one of several mentioned in my Designer Essentials presentation delivered at the 2008 GBN conference. This feature was covered on page 9.

I have been asked by a few different folks about evaluations for the conference, both from an attendee perspective and for speakers as well. For previous conferences conference attendees filled out evaluation forms before leaving the site (that’s how you got your conference t-shirt). For the GBN conference we didn’t do that. From what I hear, conference attendees will be soon receiving an email with a link to an online survey, at which point you will be able to provide any feedback about the overall conference.

I don’t know how much of the details for the conference feedback will be made public. Business Objects did not release the overall conference evaluation numbers to the public. I do know that every single comment will be read, categorized, and evaluated. This was the first year for a GBN-run conference and I think everyone recognized that there were some differences. The opportunity before us will be to sort out which differences were important, which should be repeated, and which should be fixed.

For example, one bit of feedback that I intend to provide is related to the room configuration. The room I was scheduled to speak in was quite large, and fairly deep. I don’t know how many rows of chairs there were, but it was more than a few. Yet there was no raised platform for the speaker in the front of the room. I am sure that impacted how visible I was in the back of the room. I imagine everyone could hear me, but hearing is not the same as hearing + seeing at the same time. I think for larger rooms we want to make sure we have elevated platforms next year.

Speakers, on the other hand, will be waiting a bit longer to get our feedback. I don’t have exact dates, but I am told that each speaker should be getting an email soon with more details on when we can expect to see our results. I know I look forward to seeing the numbers. I have had some great comments over the years, and I do strive for the best overall ratings that I can get.

Survey response percentages are typically very low. If you attended the conference and you’re reading this, I would encourage you to fill out the survey once you get the link. The function of the steering committee is to “steer” or guide in the desired direction. It is your voice that should determine that direction. Let’s hear it.