For example, someone asked a question along the lines of the following:

I have a document with three data providers but there are four reports. How can I know which data provider goes with which report, and why are there more reports than data providers?

That wasn’t the exact question, but that was essentially what they were asking. For someone that is new to BusinessObjects it’s a reasonable question to ask. Especially if they come from a spreadsheet background where everything is right up in front. I thought it might be interesting to set up an Entity – Relationship Diagram for the various document components to help clarify how things work together.

Entities In A Web Intelligence Document

First I want to identify the various entities (components) of a document. A brief note before I start: the concepts in this post apply equally to Desktop Intelligence and Web Intelligence, but not to Crystal.

• Document
  This is the container object. Everything starts here. The parallel for Excel would be the workbook.
• Report
  This is the page or “tab” in a document. The parallel for Excel would be a worksheet. In Web Intelligence a report tab starts out as a blank canvas. I can include various other report structure items as required.
• Block
  Here is where the spreadsheet comparison starts to fall apart a bit. A report is a canvas that starts out empty, whereas a spreadsheet starts out with rows and columns. For Web Intelligence the canvas is completely blank and the structure only comes into existence when I create a block. More on that below, but for now let me close by saying there are different types of blocks such as tables, crosstabs, and charts. Is there a parallel with Excel? Sort of. Data in a sheet goes into the existing row / column structure. But it is possible to create a chart that “floats” above the worksheet. BusinessObjects uses this floating concept for every block on a report, not just charts.
• Cell
  I use this term to refer to two things: it can either be a stand-alone cell on a report, or it can be a cell that participates in a block structure. Either way, a cell is something I can click on. With a stand-alone cell I can click on a single cell. In a table I can also, even if it doesn’t look that way. It may look like I am clicking on an entire column but that’s not what happens. Viewing the report in Structure Mode helps explain that; more below.
• Variable
  Ah, variables. Variables are like named formulas in Excel. Variables might be included (displayed) in a cell on a report, but then again, they might not. Crystal does a good job of showing which variables are currently being used. Desktop Intelligence will try to warn me if I try to remove a variable that is in use, but it’s not always correct. Web Intelligence happily allows me to delete the variable and find out for myself. In any case, a variable is a local calculation of some kind. It is not tied to a specific block or report, but it does exist in a single document.
• Data Source
  There is a subtle difference between a data provider (see below) and a data source. The source is, well, the actual source of the data. It could be a universe. In XI 3.x and earlier versions, a universe generally points to a single database. (There could be exceptions to this statement if Data Federator or techniques like database links are involved, but generally this is a true statement.) In a personal data provider it could be a workbook or a text file.
• Data Provider
  A data provider, on the other hand, is an “instance” of a data source. I can use the same source more than once in the same document simply by creating more than one data provider. To make life really interesting, each data provider can contain more than one SQL statement depending on how your universes are created and configured. Life is never simple, is it?

Relationships In A Web Intelligence Document

Now that I have established my list of entities I need to show how they are related to each other. There is essentially a “many-to-many” relationship between data providers and blocks. (Please forgive the “ASCII Art” version of the ER Diagrams; I wanted to leave everything as text.) The overall structure of a document looks like this:

Document -< Report -o< Block -< Cell
                   -o< Cell

-< is a one to many join
-o< is a one to many outer join, where the right side of the relationship can be missing

What does the above diagram tell me? Each document has to include at least one report (much like a workbook has to include at least one worksheet). One document can have 1 or more reports, and a report can have zero or more blocks. A document can also have (but is not required to have) free-standing cells. A block, if it exists, must contain at least one cell (if it is a tabular format) or chart.

There are various block types, but each block must be exactly one type. These include tables (horizontal or vertical), crosstabs, charts, and forms.

For data it looks like this:

Document -< Data Source -< Data Provider -< SQL Statement

What this means is that a document can have one or more data sources. Each source can be used in one or more data providers. And each data provider might generate one or more SQL statements. (I'm not really going to talk about why I might see multiple SQL statements per data provider in this post.)

Finally:

Data Provider >o-o< Block

This is what I talked about earlier. Each block can have show results from zero or more data providers, and each data provider can be used in zero or more blocks. Meaning a data provider does not *have* to be used in a block, and a block can consist entirely of made up data (constants, formulas, or variables) and not reference a data provider at all.

What About Crystal?

Crystal is a more structured report writing tool. In fact, there is no concept of report blocks in Crystal at all. Instead Crystal uses what I have seen called a "banded" report structure, similar to the way Microsoft Access worked year ago when I last used it for anything. However, there are also similarities in that Crystal can also have more than one data provider, more than one data source, and those sources can be merged onto a single report.

Conclusion

I hope this helps new Web Intelligence users understand more about the structure of a document. Some of the concepts are similar to spreadsheets, others are frustratingly different. It all gets better with a little experience.

Related Links

• Wikipedia on ASCII Art

Problem Definition

When building a universe there are three types of result objects that I can build: dimensions, details, and measures. All dimensions are by default drillable, and the order of the objects in the class determines the default hierarchy. (That’s one of many reasons why trying to order objects in alphabetical order just does not work.) I can eliminate the default hierarchies (and allow my objects to be ordered alphabetically if I really need to) by creating custom hierarchies. That’s a subject for another blog post.

What I want to talk about today is how to eliminate all drill opportunities on a report, no matter whether I have used default or custom hierarchies. I want to be able to include dimension objects, put my report into drill mode, but not be able to drill on every possible dimension. Here’s how to do that.

Demote the Dimension Using a Variable

When I use a dimension object in my block and that dimension participates in a drill hierarchy and my report is in drill mode I will see the drill indicators. In the Web Intelligence Rich Client they look like this:

The “up arrow” implies that I can drill up. The underline format on the resort names implies that I can drill down. Here is a very simple fix if I don’t want either of those interface elements to appear. Create a variable that references the dimension, and use the variable instead. For this example, I will create a variable called Resort Name that has the simple formula =[Resort]. Once I do that, and I replace the original Resort object with my new variable, here is what the block looks like when the report is in drill mode:

Problem solved. The reason this works is that variables – even simple ones like this – are not drillable. Only dimension objects that come from the universe can be drilled. By converting a dimension to a variable it will no longer show any drill indicators when a report block is in drill mode. Why would I want to do that? As mentioned in the first paragraph of this post, I showed a trick several years ago that allows me to switch measures on a block by changing a selection in a drill filter. In order to do that, the report has to be in drill mode. I will write up that one soon, or you can read about it in Tales of a Universe Ninja, Part II, found on my conference presentations page.

Defining the Problem

I am going to create a couple of very simple queries from the Island Resorts universe to demonstrate this feature. Each query is specifically structured so that it is missing some data found in the other query. For example, here is my first query.

And the data returned by this query.

And here is my second query.

And the data returned by this query.

I am going to call the first query my “left” query and the second query is my “right” query for the rest of this post. I have specifically restricted my left query to 2007-2008 years of data, and my right query to 2006-2007. That means the two queries have one year (2007) in common and each query also has unique data (left has 2008 and right has 2006).

Since both queries are from the same source I do not have to do anything to merge the shared dimensions. Both the Resort and Year are automatically merged as shown here.

And finally here is the resulting block of data shown in my Web Intelligence report. This is the most common presentation for the data. Note that it shows data from all three years of sales results that I selected.

Using the Left Query to Drive The Results

In Desktop Intelligence (more details below) this is as far as I can go. I don’t have any options that let me control the merge process. In Web Intelligence I do. What if I want my first query (left) to drive the results? All I have to do is open up each merged dimension object and use the dimensions that come from the left query. If I do, here’s what the block looks like.

What is going on here? The left query had 2007-2008 data only. I see annual data for both of those years for all three resorts. However, the 2008 rows are missing the Number of guests values. They don’t exist, because the right query only goes up to 2007. In this case I have told Web Intelligence that my “left” data is more important, and to show right data only where it exists.

Using the Right Query to Drive The Results

Next I will turn things around and use the “right” dimensions instead. Here is the block that results from that operation.

Now my revenue column is sparse (has missing values) while the Number of guests column is completely populated. That is what I expect given that I am using the right dimension objects this time.

Those are the three options that I have in Web Intelligence. I can use the merged dimensions (the most typical requirement) or I can use the dimensions from a specific data provider. If I compare the three blocks (merged, left, and right) I can see exactly how Web Intelligence is working. How does Desktop Intelligence work?

Merging Data in Desktop Intelligence

In my example Web Intelligence report I have selected the Resort object in two different queries. After the automatic merging process has run I end up with three different ways to reference the Resort values on a report. Specifically I can reference Resort(left), Resort(right), or Resort. The last option is the merged result. In Desktop Intelligence I am missing that last choice. Is that a problem?

I have a screen shot that shows what the merging process looks like in Desktop Intelligence. One complaint that I have is that I have to click on each dimension object individually to see if it is linked or not. In the screen shot shown below I am only showing that the two year values are linked.

Next I notice that I have no way to refer to the merged result set as I do in Web Intelligence. I have to pick either the left or right value. Does it matter? It turns out that it does not, as shown here. I have selected the right version of the Year object, yet all three values are showing up.

In Desktop Intelligence the results from the left and right queries are merged together. Every value from the left query appears on the right, and every value on the right appears on the left. It is a union of the two data providers. As a result of this union operation, it doesn’t matter which side I pick. I can swap the left and right dimension values and still get the same result. It is always a full outer join.

Is it possible for me to reproduce the way Web Intelligence behaves in Desktop Intelligence? In the example I am using today, the answer is yes. However, I need to look at the measure values instead of the dimensions since I cannot alter the merged dimension behavior. If I want to show the left data, I can create a filter so that only those rows that include a Revenue value will be displayed. Here is how that filter looks.

Dimension values will never be NULL in Desktop Intelligence because of the way the values are shared as a result of the merging process. If I can identify a measure, as I did in this case, I can essentially create a left or right block based on my requirements. The process is not intuitive, nor is it effective in every case.

Extend Merged Dimension Values

So now to the point of this post: what if I would like Web Intelligence to act more like Desktop Intelligence? That’s exactly what the setting “Extend merged dimension values” does for me. Remember in my description of Desktop Intelligence I said that merged dimensions result in a union, where every value from my left query appears in my right dimension and vice versa. That means that I will always see data from either side, no matter which dimension I pick. Here is one way to invoke this setting. I am right-clicking on a report tab and I see this menu.

After selecting Document Properties the following menu appears on the side of my document.

The setting is off by default. What happens if I turn it on?

Here is what my left block looked like before the setting was turned on.

And here is what it looked like afterwards.

And here is the right block.

They look exactly the same. And that’s how Desktop Intelligence would have behaved in this situation. Each dimension has been extended to include the values from the other. My left year includes right values, and my right year includes left values. I have recreated the Desktop Intelligence behavior in Web Intelligence. I am not sure this is a good thing, but I can do it.

Conclusion

If I only use the merged dimension (meaning I use Resort instead of Resort(Left) or Resort(Right)) then this setting doesn’t do anything for me. The results will be the same with the setting on or off. But if I need to pick the specific values from either the left or right, this setting allows me to recreate the behavior found in Desktop Intelligence.

One caveat: this setting is a document setting, not a report setting. That means if I turn it on (or off) it affects the entire document. That may or may not be an issue. It all depends on what I am trying to do.

This post was written in response to a specific topic on BOB. I started to write the answer there but realized it would make much more sense with screen shots and more text.

I now imagine blog readers who have been working with the tools for a while have started nodding their heads in agreement, only to stop and say, “Hey, wait a second, is Dave talking about universe contexts or report calculation contexts?”

And the answer is, of course, yes.

Both concepts can be quite complicated and take a while to fully understand. Since I have already written a number of blog posts about universe contexts I thought it was time to turn my attention to the report technique of calculation contexts. Note that this concept is used in Desktop Intelligence and Web Intelligence but not in Crystal. This post is intended to be an overview only. I have plans for a detailed post on each of the various context operators where I will go into much more depth. For this post my goal is to introduce the concept and provide some basic definitions.

Introducing Calculation Context

The default calculation context is defined by the dimensions that participate in a report block. It is this feature that makes the dynamic nature of measures possible. When dimensions are removed from or added to a block the context changes and the measure amounts also change. This is controlled by the projection function set on each measure by the universe designer.

However, a report writer sometimes wants a measure to be fixed at a particular value. Percentages are a really simple example. To calculate a contribution percentage I need to divide each individual value by the overall grand total. In order to do that, I need to know how to generate the grand total anywhere I want it. In order to do that, I need to understand how to use the various calculation context operators.

Context Operators

There is a simple (but powerful) set of context operators that I can choose from. I intend to briefly define each one in this blog post and then dive into more detail in future posts. As I mentioned when I started, the default context for a measure is based on the dimension values present in the block structure. I can alter which of those dimensions impact the calculation using one of the following three context operators.

• In is used to specify exactly which dimensions to include in a context. Other dimensions in the block are ignored. Adding / removing elements from the block does not impact this calculation unless a removed dimension was specified in the context. In that case a #MULTIVALUE error is displayed.
• ForEach is used to include a dimension in a context. The calculation context is still affected by other values in the block.
• ForAll is used to exclude a dimension from a context. Other dimensions of the block will still be considered. Adding or removing values from a block might change the value, but it will always ignore the ForAll items.

The operators listed above all require one or more dimensions as part of their syntax. However, calculation context can be specified by more than a set of dimension values. There are a series of report structure keywords that can be used as well.

• In Report sets the context at the report or “grand total” level. Any formula with these keywords for the context will return an overall total. Note that the total may still be affected by report filters.
• In Block sets the context for each block section. For years I have been waiting for this setting to be renamed to reflect how it really works, but it hasn’t. I suppose it’s for backwards compatibility. If there is only one block on a report then “In Block” and “In Report” are going to be the same. But when a block is broken up into sections, then this context will generate a total for each section value. For that reason I submit that a better name might have been “In Section” instead, but as long as I know what it does the specific word does not really matter.
• In Body is the standard default context for each row of data.

With Desktop Intelligence we have the option of In CurrentPage which can be quite useful and unfortunately not yet available in Web Intelligence. I probably don’t have to explain how the “CurrentPage” total is derived.

Finally, these keywords can appear in several places in a formula. The most common are the “input” and “output” context settings, but certain functions (like RunningSum() for example) also have a “reset” context.

• Input context is used to determine the input values for the formula.
• Output context is used to determine the output scope of the formula.
• Reset context is used to determine when a running function starts over at zero.

Dimensions referenced in the input context do not have to appear in the block. Output and reset dimensions must appear in the block in order to function correctly. For many calculations the default input context works just fine. I will show an example where it’s crucial to understand input context later on. For now I would like to move on to a simple example.

Simple Calculation Context Example

It’s hard to fully grasp some of the subtleties of calculation context without good examples. For this post I will provide one simple but common example that I mentioned earlier: contribution percent. I will start with a simple block with one dimension (resort), one measure (revenue), and a grand total as shown here.

This block already has a total on it. If this were a typical spreadsheet I could reference the total value using a row/column address, but that doesn’t work in Web Intelligence. That means I have to use another technique to generate the grand total. I mentioned the solution earlier… all I have to do is create a simple formula that looks like this:

Here’s the formula again:

=[Revenue] / [Revenue] In Report

Remember that the In Report context projects the measure up to the overall report total. By using that calculation context operator in the denominator of my division I ensure that I will always be dividing by the grand total in this formula. The results?

What’s Next?

This post barely scratched the surface of the calculation context question. It provided a few brief definitions and one simple example. I have several other posts planned that will dive into much greater detail about this often confusing subject. First I plan to talk more about In versus ForEach versus ForAll and how they are different. Next I plan to cover input versus output context and when each should be used. As I write this post neither of those two are much more than an outline for now, so I don’t have an estimated publish date.

But they’ll get published. Eventually.

I am going to show screenshots from Web Intelligence 3.0 for this blog post but the same process works in XI R2 as well.

Setting Up The Scenario

To start I need to make sure that my preferences are set for viewing Web Intelligence documents via Infoview in the “interactive” viewer. This is done by clicking on the preferences option (in XI R2 it’s an icon, in 3.x it’s a text link in the menu bar) and selecting the proper viewer under the Web Intelligence configuration area.

Next I created two documents from the eFashion universe. Or rather I created one document, saved it, made a small change to one formula, and saved it under a new name. Now I have two very similar documents and need to find out what is different. The formula in question is simple enough for this scenario: I take the Sales Revenue and multiply by some factor to get a projection. I specifically did this as a formula rather than a variable for this demonstration. For the second version of the report I changed the projection factor.

Interactive Viewing Sidebar

Here’s the trick that Joe shared with me. While viewing the document in interactive mode there are a number of choices that can be made as far as what to show on the left sidebar. The sidebar for 3.0 is shown in the screenshot to the right. It starts out in “Document Summary” mode. (Before I go too much further I should note that the same features in XI R2 are selected with a drop-down selector instead of buttons as shown here, but the results are the same.) Document summary shows the name, author, keywords, and other information that can be updated from the “save” dialog box or the document properties. It’s interesting enough, but it doesn’t help me check for document changes.

But before I go further, look very carefully at what appears just under the sidebar heading… there is a printer icon. And just in case that isn’t clear enough, the word “Print” also appears. Clicking the print icon doesn’t actually print the data shown on the sidebar, at least not right away. What it does is invoke the print process so you can determine how much of the data you want printed.

I will come back to that in a moment. But first, I want to review each of the options presented here as icons and in XI R2 as drop-down selection options.

Here are the rest of the icons from 3.0 enlarged to show detail.

The icons are (from left to right):

• Document Summary
  This pane shows overall document properties, keywords, and other summary information
• Data Summary
  This pane shows data provider details as well as formulas and variables.
• Chart and Table Types
  This pane shows templates for various block types. This information is available when creating documents too, of course, but having it available here allows an interactive viewer to change how a report is displayed. Cool stuff.
• Available Objects
  This pane allows an interactive viewer to see (and therefore drag-and-drop) available objects from a data provider, formulas, or variables onto the report. An interactive viewer can even create new variables on this pane.
• Document Structure and Filters
  This pane allows an interactive viewer to see the document in “outline mode” which shows both page and block layout configuration settings.
• Navigation Map
  This pane allows a user to navigate through sections on a report. This is driven by the content of the report rather than the structure pane listed above.
• User Prompt Input
  This pane will allow a user to review prompt selections.
• Find
  This pane is probably self-explanatory. It’s nice to know that it’s there and I expect to talk more about how it works in a later blog post.

So which one of these is the “magic button” as far as deciphering document differences?

Data Summary

The second button (Data Summary) is where I want to spend the rest of my time for this blog post. When I click that button the outline for my simple document looks like this:

Data source
 Query 1 

	Universe: eFashion (Oracle)
	Last execution time: 5 s.
	Nb of rows: 1016 

 Objects 

 Query 1 

 	Lines
 	Product line. Each line contains a set of categories. 

 	Quarter
 	Quarter number: Q1, Q2, Q3, Q4. 

 	State
 	State located. 

 	Year
 	Year 1999 - 2001. 

 	Sales revenue
 	Sales revenue $ - $ revenue of SKU sold 

 Formulas 

 	=[Sales revenue] * 1.025 

Now did I sit here and type all of that into my blog post? Nope.

What I did was click the “print” icon. I mentioned this earlier when talking about the Document Summary panel, but it appears on the Data Summary panel as well. Clicking the print icon generates this popup window.

If I leave everything turned on and click the OK button the following content shows up in another window.

Now here’s the best part. Clearly I can print from this screen. But I can also grab everything and copy / paste into another application. This is very cool stuff.

Comparing Reports

I use a text editor called UltraEdit that I am very happy with. One of the many features it has is I can compare two different files. I’m not saying you have to run out and purchase the same tool I have. All you need is some sort of program that will let you compare the contents of two different files. (If you run unix you have one built in; see the manual page for the diff command for more information.)

I copied the entire contents of the data summary output for version one of my document and saved it as document_v1.txt. Then I did the same to version two and saved it as (of course) document_v2.txt. Finally I ran the compare tool against these two files. I mentioned earlier that the only thing I changed was a single value in one formula. Here’s what the compare results showed.

The only difference between these two Web Intelligence documents is clearly shown. This is nice.

What About More Complex Changes?

There was only one change made for this simple scenario. I added some new objects and a new variable to version 2 of the document and reran the compare using the same steps outlined above and here’s what I got.

6	 <! Last execution time: 14 s.
7	 <! Nb of rows: 10272
	 !> Last execution time: 5 s.
	 !> Nb of rows: 1016
22	 <!  Store name
23	 <!  Name of store.
24	 <!
28	 <!  Quantity sold
29	 <!  Quantity sold - number of SKU sold
30	 <!
34	 <!  Document Variables
35	 <!
36	 <!  Test
37	 <!  =[State]
38	 <!
41	 <!  =[Sales revenue] * 1.035
	 !>  =[Sales revenue] * 1.025

It captured the different run times and row counts. It showed that the Store name object had been added to the second version. It showed that a new variable existed in the second version, and of course it still captured the fact that the constant value was changed from 1.025 to 1.035 in the second version of the document. The way I know this is everything with <! is from the newer “v2″ version, and everything tagged with !> is from the older “v1″ text file. That’s how UltraEdit works. Other tools will likely be different.

Now imagine if I were working with a complex document with hundreds of variables and formulas and maybe a dozen or more data providers. I am told that there is “something different” about the two documents but I can’t tell exactly what just from a quick look. I now have a process that will identify exactly what is different as far as data providers, variables, and formulas. That’s a huge savings in time and effort.

So thanks, Joe, for sharing your tip.

As a final note, doesn’t Joe have a great name for working as a Business Objects consultant? His brother Frank won a drawing at one of the Insight conferences in Florida a few years back and the emcee had fun calling out his name. Frank… ZABO? Is Frank here? Frank Full-Client maybe?

What About Desktop Intelligence?

One of the advantages of Desktop Intelligence is that it’s open to manipulation via VBA. It’s outside of the scope of this post to provide full details, but I have in the past written code to extract information from various full-client reports and save it into various formats. It would not be a major stretch to apply the same text compare process in order to determine differences between two versions of the same desktop report.

Conclusion

Usually when I learn something new I immediately try to see how far I can take it. It turns out that this trick doesn’t go much further. Of the eight icons on the sidebar only two of them have a print feature: Document Summary and Data Summary. The same techinques could be applied to the output from the document summary but I think the data tab is much more useful.

I should also remind folks that the text editor UltraEdit is not required; it’s just a tool that I have available. There are many free or inexpensive tools for comparing the contents of two text files. The output from UltraEdit is handy in that it can be color coded (as I showed in the first screenshot) or saved to a text file (which is what I used for the second set of output) instead.

Finally, I hope that I have accomplished one last but important thing with this blog post. Joe seemed really surprised that I had not encountered this feature before. To be honest, I do not spend much time in Infoview. I am usually using the java panel for report development or debugging efforts. Since I don’t spend much time in Infoview I haven’t spent that much time checkout out all of the features, and therefore had never seen the “print” icon that was available even back in XI R2.

My point is this: everyone has something to share. Some of the techniques that you may use every day without thinking twice about them might be new and exciting to someone else. For every person who read this blog post and thought to themself, “I already knew about that” I bet there are a dozen or more that are going to say, “Wow, I never knew I could do that!” So go ahead and do a presentation for your local user group. Write a blog post. Share something on BOB. Pay it forward. Pass it on. Your mileage may vary. Batteries not included. All that stuff.

You might just save someone else a lot of time, and feel good doing it.

Filling Out A Calendar

My report requirement states that all months – whether they have sales data or not – must appear in my output. Because Web Intelligence cannot make up data to fill out the missing months, I need to have an alternative source. In the first post in this series I showed how to do that with a personal data provider as I built out the data in a spreadsheet. This time I am going to show how to do the same thing using only a universe. In order to provide a complete (clean) solution I am going to have to make a new object in my universe.

The first step is to create a query that returns some data. I am going to use the same data that I started with on the last post, which is six months of sales revenue data from the eFashion database. I am also limiting the data to the year 2001 in order to match the example from the last post.

Next I will create a second data provider from the calendar table that includes all of my month values. Since this query has no restrictions (conditions) and no measures (no joins to any fact table) it will be guaranteed to return every month. At this point in the last post I detailed how to merge (link) two data providers together. This time that step is not required. That’s the first advantage of using universe data to perform this step: the dimension objects that are shared across my two queries are already merged (linked). When I used personal data, I had to do the merge step myself.

Once I drag the merged month into my report block I will see all 12 month names. As I did last time I will also replace the existing Month Name detail object with the one that comes from my calendar data provider. The results from these operations are shown in the screenshot below. The “Discontinued” value comes from a custom format used in the eFashion universe. The universe was designed with the assumption that if any cell was empty (as opposed to zero) then there were no sales for that item, and it must have been discontinued.

I would like to insert a zero value into those “Discontinued” cells. I could make it look like it has a zero by changing the format. But if I want an average of that column to be impacted by the fact that I had zero sales for six months out of the year, I need to have an actual zero in the cell, not just a custom format. It’s at this point that I have gone as far as I can without talking to my universe designer.

Creating and Using Placeholder Objects

As a universe designer I can help solve this problem. I might create a special class called “Placeholder Objects” that includes new objects used to solve this type of problem. (I have also seen these objects called “dummy” objects because they are only going to work in very specific situations. They’re not “smart enough” to be used by themselves.) When I used personal data to solve this issue I created a new column in my spreadsheet and put a zero in for every month. In my universe I will create just one object with a zero value in the select clause and nothing in the tables. Note that this object will not parse; that is expected.

Since this object does not have a table associated with it I will need to make sure that it’s used with at least one “real” object in a query. As a universe designer I can’t enforce this. But if a report writer tried to use this object by itself the query would not run. I have seen some folks suggest that objects like this should be pointed to the DUAL table (in Oracle) or something similar. I disagree. The only benefit to doing this is that the object will parse. But at the same time I am fixing that issue I would be introducing an entirely new set of issues because the DUAL table isn’t typically going to join to any other table. It’s much more effective to leave this object in a state where it won’t parse than to deal with all of that mess.

Rebuilding the Query

Once I have created my dummy object and exported the updated universe I can fix the problem. In fact I can fix it a couple of different ways. First, I could mimic the solution from the last post by adding the zero object to my calendar-only data provider. Since I have already covered all of those steps I thought I would show a different technique for this post. I am going to use a UNION query.

A union requires that all of the queries (you can have two or more) match. Each query has to include the exact same number of objects, and the object types (character, date, number) have to match as well. For the scenario I am using for this post each query will have three objects. Both queries will include the Month and Month Name. The first query will also include the new Zero object. The second query will include the regular revenue object. Here are the two screen shots showing what this query looks like.

Query Panel Union Part 1

Query Panel Union Part 2

Notice that the first query does not have any conditions at all? The second query includes the condition that I created to drop out months (it only shows months with an “e” in their name) as well as a limit to show data only for 2001 as mentioned earlier. When I run the combined queries I see this output.

At this point the data looks great, and it was obtained with a minimal amount of fuss. All of the months show up as required. There are no merged dimensions here since everything is returned in a single data provider. However, there is one item that needs to be fixed. Check out the column headers… they’re not exactly “user friendly” at this point. What happened? It turns out that column headers from a union query are taken from the first pass of the data provider. As a result my column header says “Zero” instead of “Sales revenue” as I would expect. Fortunately Web Intelligence (the Rich Client in this case) makes this process extremely simple. All I have to do is open the query panel and drag “Query 2″ in front of “Query 1″ in the union area of the query panel and rerun. After rerunning the query I am left with a report block that is missing a measure. This is okay, because the object named “Zero” has been removed from the query, and a new object “Sales revenue” has appeared. All I have to do is drag that new measure onto the block and I see these results.

Notice that I have added an Average calculation in the footer to show that the zero values are being included during the calculation. The result obtained via this process is now essentially identical to that shown in the first post about making up data.

Conclusion

So far I have shown two different techniques that can be used to “make up” data for a report: personal data and universe data. Which is better? As with many questions the answer is “It depends.” Personal data has an advantage in that it can be built on the fly by a report user and does not require any universe maintenance. Universe data has an advantage in that the extra objects are reusable and are available to anyone. With proper training users can build queries that can include extra data that does not exist in the database.

Personal data requires me to know how to merge the results. With universe data the merge step (as long as I use the same objects) is performed automatically.

In this post I also showed two different techniques for getting the “filler data” into my report. With personal data I have to create two data providers and merge the results. With universe objects I have the option of creating a single data provider using a Union technique and my placeholder object.

The placeholder measure object that I created is not limited to this particular report. I can use (and reuse) it for any other report with similar requirements. Since the object is not tied to the calendar (or any other dimension) I can use it anywhere. It can be used to merge data providers or in a union query. I can create similar “dummy” objects for dates or text fields as needed. Ultimately I can decide if I want these special objects to be visible to all users or to a selected subset of “power user” report writers using the standard security process.

Next Time

For Part III of this post I am going to create a more complex example where data might be missing from more than one dimension (instead of just month as I have used in the last two posts.) I am also going to show cross tab and a section output because each of those can cause some interesting challenges as well. Maybe I’ll even do a sectioned cross tab.

Related Posts

• Making Up Data Part I: Personal Data Providers

How can I display each individual value selected in the UserResponse() function on its own row in a table?

I believe the reason for wanting this behavior is fairly clear. If you have a bunch of complex data it would be much easier for the report consumer to read this:

XYZ123ABC
DEF456HIJ
BOB111BOB

Instead of this:

XYZ123ABC;DEF456HIJ;BOB111BOB

As is often the case, the strict answer to the question is “you can’t do it that way” with Web Intelligence. Despite the “you can’t…” answer I am going to show how it can be done.

Printer History Lesson aka Carriage Return + Line Feed To The Rescue

Before I show my solution, I have a history lesson to share. In the old days (and I mean really old, like before laser printers) most business printing was done with impact printers. An impact printer was essentially a typewriter connected to a computer. It would print one character at a time. Some really expensive printers could write an entire line at a time. Some even more expensive ones would be able to write forwards and backwards to save time. Fancy stuff. But the point is, everything was characters and lines. If a program needed to print something bold, the printer would back up and print the same characters more than once on the same line. That’s where special printer control characters came in.

The print head or “carriage” was where the next character would be printed. Normally it would flow across the page printing one character at a time. At the end of the line, a carriage return signal was sent. This would tell the printer to send the carriage all the way back to the beginning of the line. If the printer started printing again at that point, it would overwrite the existing line of output. (As mentioned above, that’s one way that bold type was done.) To avoid this, another special printer instruction character was sent just before the printing started: the line feed. This character told the paper to roll the paper forward one line so that the new output would be on the next line.

To recap: carriage return sends the print head back to the left side of the page, and line feed moved the paper forward one line. Carriage return was (and still is) character 13 in the ASCII sequence, and line feed is character 10. (These are also often abbreviated CR and LF.) There are plenty of others. If my memory is correct a tab is character 9 and the “bell” if you wanted the printer to make a noise was character 7. But I digress.

Fast forward to today. The characters still retain some of their meanings, even if we don’t use impact printers anymore. So if I want to push some content down and start on a new line, I can include these characters as part of my output and they will behave the same way. Web Intelligence offers the function Char() which will allow me to introduce a specific character using the proper number. Web Intelligence also offers the Replace() function which will allow me to replace one character (or string) with another character (or string). You might see where all of this is heading…

Prompt Processing

I created a simple query using the Prestige Motors universe. The query includes a prompt that asks the user to select one or more automobile manufacturers when the report is refreshed. The text of the prompt is “Car Makers.” I can easily display the results of the prompt (the values the user selected) on my report using the UserResponse() function. What I want to do is display each selected value on its own line.

How am I going to accomplish this? I’m not going to put each value on an individual row in a table. As I already said that can’t be done. Instead, I’m going to make them show up on different rows in a single cell. The readability should be the same, even if the applied technique is different.

The final piece of the puzzle is to observe just how Web Intelligence captures and displays prompt responses. Here is a screen shot showing the prompt after I have selected four different car makers. Notice that the four values are separated by the semicolon ; character.

With a simple formula I can echo the prompt selections in my report title cell like this:

Notice that the exact same format is used in both the prompt window and the output in the title cell. Each selected value is separated by a semicolon. I can work with this.

The Solution

I created a variable named “Picked Cars” with this formula:

=Replace(UserResponse("Car Makers");";";Char(13)+Char(10))

The inside portion of the formula looks like this:

UserResponse("Car Makers")

That bit captures the selections and returns them in the format shown above, where each car name is separated by a semicolon. The outer portion of the formula uses the Replace() function to find those semicolon characters and replace them with the combination of character 13 (CR) and 10 (LF). The net result?

Everywhere there is a ; it gets replaced by the CR+LF and therefore the output moves down to a new line and back to the left side of the page. Strictly speaking there is no page nor is there any paper to “line feed” but the functionality is the same. Simple enough. Here’s what the results looked like after I created this variable and used it in my header.

What about the formatting? It turns out I didn’t need to do too much. I made sure that my cell was set to automatically fit the content (since it could grow or shrink based on how many cars were selected) using the “Autofit Height” setting as shown here.

The next item I planned to update turned out to be set for me by default. (This example was documented using the Web Intelligence Rich Client so other tools may require this step.) I clicked on the edge of the block and made sure that if the title cell above it grew too big that the block would move down the page. This is done by setting the relative positioning of the block, as shown here.

As I mentioned, this dialog box did not require any changes for this scenario. It was already set the way I needed it to be. Since the block is positioned relative to the cell that contains my [Picked Cars] variable it will move up or down the page based on the size (height in this case) of the cell.

Conclusion

Can I split out each individual user response and display it on a separate row in a table? No. Can I achieve the same visual result using other techniques? Sure. That’s what it’s all about, finding a different way to answer a question. This solution does have one problem… it will not work cleanly if there are semicolon characters in the data returned from the prompt. I did not test this with Desktop Intelligence, but since it includes all of the functions used in this example I am confident that it would work the same way.

I was challenged when I posted this solution on BOB as to why I used both CR and LF characters in my formula. To be honest, when I changed the formula so that it only included one or the other, either seemed to work just fine individually. Despite this, I opted to leave both in my formula.

What can I say… old habits die hard.

I have only six months of data, but I have to show all twelve months in my report. How can I show the missing data?

The trick is to understand that Business Objects does not make up data. It just doesn’t have that capability. And you can’t edit the report directly in order to add those extra values to the result set. However, there are a couple of tricks that I can share that will help solve this issue.

Special Note to Blog Readers: This post is fairly long because it has quite a few screen shots to illustrate the process. As a result it will be presented in several pages. When you get to the bottom of a page just click on the next page number from the links provided to continue reading the post. Since this is the first time I have used this feature I thought I would warn you about that. Now on with the solution.

Using Personal Data

One of the easiest ways to make up data for a report is to use a personal data provider. This technique can be used in all versions of Desktop Intelligence and also in the newer “rich client” version of Web Intelligence. While the specific steps are unique to each tool the general concept is the same, so I will only show how to do this using the rich client. Screen shots for this blog post were taken from version 3.0 of the Web Intelligence Rich Client.

The first step is to determine what is missing and therefore what you need to make up as filler information. It’s also important to know that the format of your personal data has to match what is coming from your enterprise data source or the data won’t merge properly. For this scenario I will show some data coming from the eFashion database. I am going to restrict the data to months that include an “e” in their name, just to make sure that I have holes in my data. If you’re wondering, that includes February, June, September, October, November, and December. Why did I pick that? No reason, really, just thought it would be fun.

After applying that condition (along with another to restrict to one specific year) I see the following data on my report.

In the eFashion universe the Month is a dimension object and is a numeric value. The Month Name is a character string containing the month name spelled out (October rather than just Oct) and is configured as a detail object. This is important. When I want to merge two different data providers together I have to perform that process (the merge or link step) using only dimension objects. I cannot use detail objects. That means my personal data provider will have to include the month number as a dimension, and it should also include the month name as a detail.

After building up this query I have six months of data, as described in my original scenario. To meet the report requirements I have to show all twelve months, including those that don’t have sales that meet my current criteria. How can I make this happen?

Making Up Data

I am going to use a spreadsheet to make up my data, but I could just as easily use a delimited text or CSV file created with any text editor. The trick is that I have to structure my personal data so that it matches what I already have from the universe. To solve the scenario I am currently working on that means that I need the month number and the month name in my personal data. Here’s how that looked when I was done.

I saved this data on my computer as a standard spreadsheet file. I could also have used a comma separated values (CSV) or other structured text file just as easily. The next step is to import this data into my document.

Adding Personal Data

In order to add personal data to my document I open the query panel, right click on the current query tab, and select the option to add a new data provider. After I do that I see this dialog box.

After making sure I select “Local data source” I move on to the next step, which is to browse my computer and find the spreadsheet file I saved earlier. Once I find the file I am presented with a few configuration options as shown here.

The filename is there, of course. Since I am using a spreadsheet I can pick which sheet from the workbook contains my data. I can also determine whether to use a named range, to enter the range myself, or to let the client try to figure out where all of the data is for me. For this simple case I mark “All fields” and let the client do just that. Finally, I confirm that the box for “First row contains column names” is checked and click the Next button. Here is what I see at this point in the process.

There are a couple of problems with this result. The client is trying to be helpful, but it’s making the wrong decisions for me. The Month column contained all numeric values so it was imported as a measure. The Month Name contained character data so it was imported as a dimension. Both of these assumptions are wrong. I need the month number to be a dimension so I can link it to the value I already have, and I need the name to be a detail in order to match the existing structure on the report. Fortunately, since this is my own personal data, I am allowed to make changes to the configuration.

This presentation covers slides 10 through 12 from my 2009 GBN presentation titled “Return of the Variables” which can be downloaded from my conference page.

Constant, Formula, or Variable?

A constant is a value that is never going to change. Constants are probably quite rare, to be honest. I could hard-code a sales tax rate into my report but it is far more likely that the tax rate will come from the database. Same for commission percentage or project deadline dates or any other data along those lines. In any case, they’re not really complex and they’re certainly not calculations so I will move on.

That leaves formulas and variables. How are they different? How are they the same?

Both can use the full range of report engine functions. Both can be used just about anywhere on the report. Is there any reason to select one technique over the other?

Yes, yes there is.

The Four Cs

Years ago when I wrote my first Variables presentation I came up with what I called “The Four Cs” to describe why variables are better than formulas. They are:

• Convenience
  A variable can be used with every report feature. I can’t build an Alerter using a formula, as shown here:

  

  I can’t rank on a formula. In Web Intelligence I get a list of query objects and a list of variables, but not formulas. The list probably goes on from there but that’s probably enough important features to prove the point. Variables can be used in places where formulas cannot be used.

• Clarity
  Simply put, a variable is a formula with a name. A name defines the purpose of the calculation. It is much easier to understand a complex calculation like this:

  =((100-[Discount Rate])/100)*[List Price]*[Qty Sold]

  … when that formula is also named “Sale Value After Discount” and saved as a variable.

• Complexity
  Sometimes it’s hard to figure out the syntax for a complex calculation. I will often break something down into simple steps and store the results as variables. Because variables can be reused (formulas cannot since they don’t have a name and therefore cannot be referenced) I can check my work at various points and make sure I am seeing the expected results. In another post related to this conference presentation I showed an alternative way to calculate the number of business days between two dates. If you review that post you will see that the formulas get quite complex indeed! You can bet that I didn’t come up with the final version without working carefully through each step. Using variables, of course.
• Consistency
  Once a variable is built it appears on the list of report “components” saved as part of the document. I have touched on this aspect of variables already in this post. Because variables appear on this list they are reusable throughout the report. Because I can reuse them throughout the report I can edit them in one place and have the changes propagate everywhere I use that particular calculation. If I spend the time and effort to create and test a complex calculation, it’s nice to know that it is reusable and will therefore provide consistent results throughout my document.

Wish List: Universe (or Universal) Variable Repository

At one point I had started writing a VBA script that would allow me to create report variables and check them into a “variable repository” that I stored in a Microsoft Access database. The idea was that once a variable was created I could then easily reuse it in other documents. This worked fine for desktop documents. Web Intelligence documents were not supported at all since the utility was based on VBA. It would be nice if we could see this feature supported directly in the universe framework.

Building Variables

Building variables in a document is fairly simple. I can click the proper button on the toolbar (shown below).

After clicking this button I am presented with the following screen that allows me to create my local calculation. (Note: this screen is from XI 3.0 and is different from what you will see in prior versions.)

This screen allows me to enter a name for my variable, set the qualification (dimension, detail, or measure), and access the full range of report functions.

There is another way that I can create a calculation; I can use the formula bar much like I can in a spreadsheet. Here I have activated the formula bar using the appropriate button and have clicked inside the edit area and started to create my formula.

Is this a problem?

Formula Challenges

For this demonstration I have created the following simple formula.

=[Revenue] / 100

I can use this formula in a report block. In fact I can copy it to multiple report blocks. The problem is, after I have done this I have three (or more) different copies of the same formula. If I click on the initial cell where I created the formula and edit it (perhaps I meant to type 1000 instead of 100 earlier) then only that instance of the formula is changed. The rest of the formulas are stored elsewhere in the document and are not affected by the edit.

This is a problem.

Converting a Formula to a Variable

If I made this mistake and want to convert my wayward formula into a variable I can do that. There is a button on the formula toolbar here:

When I click that button I am presented with the following dialog box that allows me to assign a name to my formula.

Once a formula has a name it becomes a variable and shows up in the document data tab.

Summary

This part of the presentation was probably considered to be fairly basic by most (if not all) of the folks in the room. However, I always repeat this same information every time I deliver a variables presentation. Why? Because of what happened years ago when I presented “Variables and More… Fourth Edition” at the conference in Las Vegas. I thought that by then everyone knew about the toolbar button that provided a way to convert a formula into a variable but it seems that was not the case. The very last question that I took from the audience was from a woman who wanted to know what to do with a formula she had created by mistake. I quickly created a formula and then showed how to convert it into a variable using the process I outlined here. I then found out just how many folks didn’t know about this technique, as it seemed the entire audience went “oooh, aaaah” and proceeded to give me the highest rated presentation marks that I have ever received.

It just goes to show that anything and everything that you know is probably worth sharing. It is very likely that there is somebody, somewhere that doesn’t know what you consider to be basic information. Share those simple tricks and they are much better off. Plus you earn some good karma.

So go ahead, answer a few questions on BOB. Start a blog. Share what you know.

This post covers slides 6 through 9 from my 2009 GBN presentation titled “Return of the Variables” which can be downloaded from my conference page.

Push it Back, Push it Back, Way Back!

I can’t help but hear some football cheerleaders calling out inspirational words to their team as I write that heading. But the reality is that the concept is quite appropriate for this discussion. There are quite a few advantages to putting calculation logic into your ETL (extract / transform / load) tool. For example…

• Build on core data
  ETL tools or other scripts working on core data have an advantage… they’re working on the core data. (That’s almost a recursive definition, which is another presentation. ) What I mean by that is there isn’t anything getting in the way between the process and the data. My scripts can do whatever they want because everything they need should be available. If it’s not immediately available I can build it in a temporary table and move on from there. ETL tools are very powerful in this regard.
• Procedural languages / scripts
  Even in a simple ETL environment where no formal tool is being used I can still write procedural scripts. I can write procedural SQL (PL/SQL) or even C scripts. The only limits are my imagination and the grammar of the selected tool.
• Consistency across all access paths
  This is a real key advantage of pushing calculations back to the ETL layer. Since this process is generally responsible for filling your data warehouse tables, and the calculations are done during that load, it means that any tool used to access that database inherits the results. It means I can use any query tool and still gain the benefits of the calculation results.
• Calculate and store once, retrieve many times
  This is my primary differentiator between putting a calculation in the universe versus doing it in the ETL. I was recently given a block of code and asked to create a predefined condition in the universe to handle the logic. The problem was it was extremely complex and included a number of case statements and outer join requirements… and it was going to impact the fact table. I pushed back and requested that the logic be placed into the ETL. The end result was I got a simple Boolean flag (zero or one value) on the fact table that was much easier to use. An added benefit? If the logic required to populate that field ever changed it could easily be done in the ETL.

Unfortunately there are other issues to consider before putting a calculation into the ETL.

• Change Management
  Not all of the aspects of doing calculations in the ETL are good. For example, most companies seem to have far stricter controls and change management processes around their ETL than they do for reports. Getting a change pushed through the ETL team can have a far wider impact and therefore can take longer and require more justification. Sometimes it is easier to keep a calculation closer to the report to avoid development delays.
• Complexity
  ETL scripts can already be quite complex. Adding new calculations might slow the scripts down and cause them to run beyond their available load window.
• Impact Analysis
  One of the primary advantages of including calculations in the ETL is that the results are shared by everyone. One of the disadvantages of including calculations in the ETL is that a change in that area will impact everyone as well. That means more teams to talk to in order to get a consensus that the change is appropriate and approval to start the process.

In my opinion, despite the potential for slower turn-around time on development requests and the need for greater impact analysis, complex calculations should be pushed back to the ETL if at all possible. This is especially true if the calculations impact join logic, affects security profiles, or needs to be performed on the fact where it will impact nearly every single query that is executed.

Using Universe Objects

The next possible location for calculations is the universe. There are quite a few advantages to putting something into the universe as opposed to having it done in the report. Such as…

• Build once – use many times
  Universe objects are designed to be reusable. Once an object is built it can be used / reused in any number of reports. This is one of the primary reasons we even build universes (that and providing the abstraction layer so business users don’t need to know technical terms.)
• Use full range of database functions
  There is a wide range of functions available inside each of the different report engines, but you can’t access the power of the database. I can use almost any function available from my database to build an object. And if there isn’t a function available to do what I want, I can build one.
• Ensure consistency from report to report
  For quite a long time Business Objects used the slogan “Single version of the truth” when talking about their products. This was based on the concept of reusable objects that I already covered above. Since every business user will be using the same object for Sales Revenue, they should all get the same result when they ask the same question.
• Updates automatically propagate
  Reports built on a universe will automatically get updates when they are published. This means if I discover a bug in one of my objects and fix it, every report that uses that object will get the updated code the next time the report is refreshed. This was a big advantage of the “classic” Business Objects tools over Crystal reports for many years. Any tool that requires a developer to manually write their own SQL code is subject to the same limitation.

That’s a nice list of advantages for universe objects. What about the disadvantages?

• Limited to information from a single universe
  Universe calculations cannot combine objects from two different universes. In fact it’s worse than that; you can’t combine objects from two different contexts in the same universe! This can be a very limiting factor depending on how complex your universe models are.
• Maintenance required by universe designer
  Getting universe work done should be less traumatic than changing the ETL, but it can still be a roadblock depending on the availability of your developer. Notice I said “developer” as it is very difficult to manage a process where more than one person works on the same universe at the same time.
• Some aggregation issues can be tricky
  Percentages and ratios and average calculations are all difficult to do in a universe. There is a new feature called “smart” or “database delegated” measures that started in XI 3.0 that helps some but it’s still an issue to be considered.
• Some functionality might be missing from the database
  It’s less likely today then when I wrote the very first Variables presentation back in 1997, but it might be that the functionality you want or need just isn’t available in your database. Rather than writing a custom database function it might be easier simply to create report calculations instead.

Report Structure Items

There are three basic options available in the report engines provided by Web Intelligence (and Desktop Intelligence as well if you’re using that tool.) They include constants, formulas, and variables. I will talk more about these three choices in the next post. For now I would like to consider the pros and cons of this option.

• Available on all platforms
  As mentioned both Desktop Intelligence and Web Intelligence offer this feature. Crystal goes even further and provides a language that includes scripting features. A report writer can pick the appropriate tool for the job without worrying about losing a calculation engine.
• Independent of SQL restrictions
  The grammar for local calculations comes from the report engine, not the SQL database. That means if you are using a database with limited functions (Sybase IQ comes to mind) you can still accomplish complex tasks in the report by using the available report functions instead. The first time I worked with Sybase IQ was years ago, and it didn’t even offer a way to retrieve the current system date from the host.
• Calculations based on document data
  When you refresh a query you download a microcube into your report. The calculations are then done on that smaller summarized dataset rather than applied to the entire rowset processed during the query process. It could be a performance benefit to be able to do the calculations locally.

That all sounds great, but there are disadvantages as well.

• Stored in a single document
  In the ETL and Universe section I talked about being able to reuse calculation results. I can do that with report variables too, but only in different reports (tabs) within the same document. If I want to use a complex formula in a new document I have to copy / paste or recreate from scratch.
• Require some level of technical expertise
  Most report writers can build simple calculations, especially operations found on the toolbar buttons like sum and count. However, getting complex calculations correct can be a struggle even for seasoned developers. It took a long time for the concept of calculation context to “click” for me, and even today it can sometimes be a challenge.
• Volume of data could impact performance
  Earlier I said that calculations at the report level might improve performance, and now I am saying that the volume could impact performance. Is this a contradiction? No, not really. What I said earlier was that if the report calculations are done on data already summarized by the database engine they should be fast. If the data is not summarized, meaning if the microcube present in the report has a large number of rows, then having additional calculations can certainly slow things down.

Summary

Wow, that was a lot of text. It’s easier to say all of this stuff than to write it down. Can you all do me a favor and just come to the conference next time so I don’t have to write so much?

In all seriousness, what I tried to do with these few slides in my presentation was to outline some of the general thoughts that go into deciding where to put a calculation. Is there a clear and obvious choice as to which to use? No, not really. I apologize if that’s what you were hoping for at this point. Each of these three areas (ETL, universe, report) has clear advantages. In general I prefer to push complex calculations as far back as possible. But if needed we have quite a few options available.

The next post in this series will focus on the different types of report calculations (specifically formulas and constants) and discuss which of those is better. In this case (unlike this post) there is a very clear choice. You can probably guess what it is… after all the presentation title was Return of the Variables.