8/6/2019 Universe Desing Best Prac

1/3

BusinessObjects universe design best practices

Posted on July 19, 2009 by biguru| 15 Comments

Having relocated from the Silicon Valley to Bangalore a year back, Im now working in an MIS strategic reporting role. In my role to evangelize the use of BI best practices and tools, one of the

foremost is that of universe design. As a matter of fact, Im currently being involved informalizing a BI policy around the tools we use most Oracle, Informatica and SAP BusinessObjects (along with migration from our legacy BO to the XI platform!) so a lot of my current

work is related to best practices, design guidelines and preparing unit test checklists for my teamof developers.

So here goes my list of universe design best practices. Being the cornerstone of the BusinessObjects semantic layer, the universe design becomes one of the most important (next only to thedata warehouse design if there is one, and foremost if there is none) aspects of getting the rightdata out there in time for analysis and decision making.

The best practices are grouped by the reporting area they belong to.

Universe design: object creation

Object and class naming should be in business terms so that it makes sense to the end-user. This also reduces development overhead since reports can use descriptions out-of-the-universe, instead of editing headers or creating report level variables.

All objects should have help text or usage information corollary from above. Object formatting should preferably be done at the universe level. Pre-build condition objects in the universe rather than forcing users to build conditions for

reports. Build logic into objects translate code, common calculations etc rather than forcing users

to do it in report variables. Avoid using WHERE clauses in the object definitions; use CASE statement instead. In

most cases, using WHERE clause will return incorrect results when similar objects areincluded in the result set, due to combined restrictions imposed by the multiple WHEREclauses.

U se aggregation in all measure objects to push the aggregation to the database whereverthe performance bottleneck is likely to be BO server and the database performance isoptimal. Generally the database is much more powerful at doing aggregation calculations,and this also reduces the volume of data to be transported over the network.

All measure objects should include aggregation functions for projection. When this is notincluded, BO will not automatically roll -up the data in the report, which could result inincorrect data and analysis. Note that in the 3.0 version of Designer, a new feature Database Delegated projection function is available to take care of these anomalies whiledoing averages for instance.

U se Custom LOVs or cascading prompts to display LOVs where hierarchies and numerous

values are involved. U se relative date objects for scheduling e.g. Today, Yesterday, Previous Month etc. Create aseparate class to contain these reporting objects this helps in improving maintainability.

U se dynamic HTML in objects where required to avoid users having to build it in report variables end users wouldnt like to code hyperlinks themselves, but would love to havean object which when clicked can lead them to Google Maps for example.

U se contexts in universes having multiple fact tables this helps in getting your measures(built from multiple fact tables) right.

U se derived tables to define measures dependent on multiple fact tables.

8/6/2019 Universe Desing Best Prac

2/3

U se derived tables to reduce complexity of queries to be written by users or in place of views or procedures. A note of caution here: U se derived tables sparingly. If you haveaccess to the database or DBA and can get views or tables created for the same purpose, go

with it rather than using derived tables. This is not only to push the logic and work closerto the database, but also to take care of the performance and maintainability aspects.Exceptions to this include cases where your derived table may include a prompt which

would restrict the number of rows returned and thus improve performance over a

conventional view. Reuse code with @Variable. Reuse interactive objects with @Where (if you use them at

all). U se @Prompt syntax for conditions and interactive objects where input values are likely to

change or absence of prompt would lead to inaccurate values or unacceptable query response times. Also make sure regularly used conditions e.g. current year / latest dateshould not have prompts to avoid annoying users.

To limit the number of objects created to avoid user confusion, build interactive objects with @Prompt syntax followed by additional OR clause to include All" condition.

E.g. ALL IN @Prompt(Enter Value or ALL,'A, Class \Object,multi,)

OR

Table.Column IN @Prompt(Enter Value or ALL,'A, Class\Object,multi,)

Universe design: resolving join and performance problems

To resolve a chasm trap, define a context for each table at the many end of the joins. To resolve a fan trap, create an alias table for the table producing the multiplied

aggregation. Create a 1:1 join between the original and the alias tables. Modify the selectstatement to use the columns from the alias table instead of the original table.

U se of contexts should be evaluated w.r.t. use of aliases for resolving join issues, to takecare of maintainability of code.

Integrity checks on the universe structure, parsing of objects, joins, contexts, detectingloops etc is mandatory. If you wish to use Business Objects to help you detect fan traps orchasm traps you must set the cardinality on the joins. Do not rely on BO to suggest thecardinality this is often erroneous, based on the records sample that BO fetches for eachtable.

U ncheck the Multiple sql statements for each measure option in universe parameters, if this is not required for resolving any join problems. This option should be checked if themeasures being retrieved in the same query involve different tables. Prevent Cartesianproduct should be checked, as should there be limits placed on the number of recordsreturned and the time for the sql connection to prevent runaway queries which can bringthe database down to its knees and cause an outage for all users.

Universe design: optimization / miscellaneous

U se shortcut joins wherever possible to reduce number of tables used in a query U se aggregate tables /materialized views with aggregate awareness set up to improve query

performance U se keys instead of labels where possible to take care of index awareness benefits of

performance and uniqueness U se the JOIN_BY_SQL parameter to shift process from BO server to database wherever

the bottleneck for performance is the BO server and the database performance is optimal. U pdate the .prm files to enable access to custom SQL functions and improve help text Do not use derived tables instead of aggregate tables.

8/6/2019 Universe Desing Best Prac

3/3

Turn off LOVs for all dimension and detail objects that are redundant or not required. Thisprevents performance problems when users inadvertently click on the Values and thequery sets to return all the IDs or other irrelevant data.

Consider using linked universes with a master kernel universe to ensure consistentdimensions across multiple universes

This list is certainly not an exhaustive one but a work-in-progress. Id update it as and when Icompile more; meanwhile if you feel anything has been left out, drop in a line.