SMART MEASURES (DATABASE DELEGATED MEASURES IN THE UNIVERSE) Business Objects XIR3 New Feature

- By Nitin Galande

Web Intelligence XI 3.0 universes contain smart measures, which provide an alternative to classic Web Intelligence universe measures by delegating calculation of the measure values to the database. Smart measures allow Web Intelligence to display calculations not directly supported by the Web Intelligence universe, to work with non- or semi-aggregative measures, and to leverage the calculation capabilities of any database accessible through a Web Intelligence universe. A BO universe has three basic types of result objects i.e. dimension, details and measures. Measures hold analytical values like Amounts, dollars, quantities. It also has two extra settings that dimensions and details dont have i.e. SQL Aggregate function and Report Projection Function. SQL Aggregate function is performed by database server and Report Projection Function is used by report engine. Certain calculations cannot be done by database server because there is no valid projection function.

How Report Projection works The projection function is an extension to the SQL Aggregate function used in measures. Lets see it with an example. I ran one query in BOXI Webi returning customer number, customer name, month-year and sales amount. Sales_Amount object also has projection function SUM associated with it.

Diagram 1.1

After a drag-drop technique I removed Month_Year column and then the projection function causes Sales_Amount data to roll-up. Output looks like below Diagram 1.2

Diagram 1.2

This is controlled via Projection Function which is a part of object properties. (Diagram 1.3) Diagram 1.3

How Projection Fails This works very well until function like Average is considered for projection. Sum function for projection can be applied recursively whereas average cannot. This means if we use Sum projection on below datasets it will return same result

Dataset 1: 1, 2, 3 Dataset 2: 1, 5 SUM Projection will return 6 for both datasets But AVERAGE Projection will be different for both datasets i.e. 2 and 3 respectively. The problem here is that average needs to work with source data. We cannot apply average projections to an average and expect correct result. In order to deliver correct results for average or percentage we need to work with source data.

Average Projections to an average deliver incorrect results. As discussed earlier the only way to generate correct result for an average is to recalculate average from source data. In order to demonstrate we have created Average Sales Amount Object in universe. (See Diagram 1.4) Diagram 1.4

Diagram 1.5 shows Average object in two different scenarios. Scenario 1 shows Average Sales Amount by Month-Year and Customer. Scenario 2 shows Average Sales Amount by Customer only.

Diagram 1.5

Scenario 1 has projection function Average. Now using the same drag-drop technique I am removing the column Month_Year from Scenario 1 query and both scenarios return output as follows (Refer Diagram 1.6)

Diagram 1.6

The results are wrong because Scenario 1 s query generates average on report data (its Average projection on Average aggregation) whereas Scenario 2s query generates average directly from the source data which has no projection. The true results are based on database calculation shown in Scenario 2.

Delegated Measures This is where the delegation process comes in. As a universe designer I can now create an object that will project correctly at the expense of running a database query. Instead of projecting my average calculation using the Average function, I will use the Database Delegated option instead. Heres how it looks (Now Scenario 1 in diagram 1.5 is having object with projection function as Database delegated). Diagram 1.7 shows how to assign database delegated measure.

Diagram 1.7

When I ran query with new measure definition, the initial output looked like below diagram 1.8 which is exactly same as Diagram 1.5 Diagram 1.8

The difference become apparent (Diagram 1.9) when I drag-drop Month_Year column away from Scenario 1 of Diagram 1.7 Diagram 1.9

The note #TOREFRESH is telling me that before I can see the numbers for that column I have to refresh my document. When I click the refresh button the results are displayed as below (Diagram 1.10)

Diagram 1.10

Conclusion This is another great new feature for Designer. It provides with better control over how measure objects are handled. In this case, the solution is not without a cost. There is 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. Ultimately it may still be easier to do this type of calculation on the report.