Tuesday, September 24, 2013

[OBIEE 11g] Conditional Formatting Of Calculated Items In OBIEE 11g


 



Conditional Formatting of Calculated Items in OBIEE 11g




Calculated items in OBIEE Pivot tables can be very useful in certain reporting circumstances, either for ease of development, or to meet specific report requirements. While calculated items in OBIEE are easy, and flexible, they do have one important drawback: they take on the data and display formatting of the fact column they are calculated against.



The most common case is the calculation of a % change across a time dimension in financial reporting ( Year over Year, Quarter over Quarter, etc.). 1   This type of calculation usually takes the form of a percent change calculation similar to below:



 (( $2 - $1 ) / $1) *100




By default, if you perform this calculation against a numerical fact ( sales, customers) you will run into the problem of how to display the % change in the correct format, since the calculated % will want to take the form of the fact it is calculated against, as can be seen in the example 2 below:



                                                                              Pivot Table




 


                                                               Calculated item



 


                                                             Results



Not very pretty at all.




As people searched for a work around to this problem 3 common solutions have arisen:



1.   Use HTML formatting tricks to “hide” trigger text in the results, then conditionally format off those triggers. While inventive, as the comments note, this solution falls flat if the report is ever printed, as the PDF engine will pick up and display all of the hidden characters.

2.   Convert the pivot table to a regular table with some complex column formulas. Very time consuming and cumbersome, would also not solve the requirement of showing the dimension values noted as noted in Footnote1.

3.    Convert the calculated result to text and manually add your formatting characters. I don’t think this actually works since the calculated fields won’t accept logical SQL functions, and this would be very cumbersome.



Now with 11g providing conditional formatting that allows you to override the default data format, this is possible via the following steps:



1.   Add a column that is a COUNT DISTINCT on the dimension that you are calculating across ( in the displayed example, “Time T05 Per Name Year”. This column will serve as your “trigger” to apply your conditional formatting.


                                 Column Formula




2.   For each of your facts, apply a conditional format that is triggered when the above column value is zero. In the formatting, apply whatever visual and data formats you desire. In this example we will format the data as a percent, with one decimal place.


                                               Condition



 Format when condition is met




3.   Exclude the “trigger” column from your pivot view. View your results and be satisfied:
 Correct formatting of calculated item




* Note that this would also allow you to apply visual formatting if you wanted to distinguish this row/column as a total.


Why it works


The use of conditional formatting that applies a data type as part of the format is a straightforward leap of logic, but what to use as the trigger? Most people will try to use the dimension they have setup the calculation in. However, if you try to use the text description given to the calculated item you will find that the condition is never applied:


 Condition on dimension


 
 Condition never met, format never applied

       
                      


If you try to setup a filter that is true when the dimension is not in reasonable range of values ( in this example we try to format off all years not in the 2000s ) you will find that your calculated item is skipped as well (this has the added vulnerability of being very explicit):

 Condition on dimension values

 Condition never met, format never applied





The reason for all this is that the calculated item “borrows” EACH of the dimension values it operates against. Hence, no matter how inventive your filter is, as long as you are trying to somehow separate the calculated member away from the members it is operating on, you will never succeed. This member “borrowing” is apparent if you add the dimension it operates against to the query a 2nd time, and look at the table view.

 Calculated item "borrows" members



But since the “member value” given to the calculated item does not actually exist in the dimension, if you try to perform a count distinct against it, you will always get zero.

 Count distinct against dimension














No comments:

Post a Comment