Guidelines & Best Practices - Universe & Report Design

 

Universe Design: Guidelines & Best Practices

Introduction
Gives the basic guidelines/practices that could be followed in any Universe Design

Connection
--> When using a repository, always define a SECURED Connection to the Database.
--> Use the Universe Property panel to define the Universe Use and Version (last update).
--> Define the Connection Name that helps for Easy Database Identification.
--> Parameters - SQL Tab - Multiple SQL statements for each measure to be unchecked.
--> Parameters - SQL Tab - Cartesian Products - Prevent is checked.

Class
--> Define Universe Classes / Subclasses as per the business logic & Naming Convetion.
--> Involve the business users in defining the classes hierarchy and business names for the classes and objects.
--> AVOID Auto Class generation in the Designer.
--> Give description for the use of each Class/SubClass.
--> Avoid deep level of subclasses as it reduces the navigability and usability.

Objects
--> Object to be used in calculation HAS to be Measure Objects.
--> Object to be used in Analysis HAS to be Dimension Objects.
--> Give description for the use of each Object.
--> Include an Eg. In the description for Objects used in LOV.
--> Do not set LOV Option for each Dimension. Use it only for required Objects, esp. those to be used in Report Prompts.
--> Keep "Automatic Refresh before Use" option clicked for LOV Objects:
--> If LOV is editable by the user, provide a significant name to List Name under object properties.
--> All the measure objects should use aggregate functions. This will ensure that the aggregation happens at the database for the selected dimensions.
--> Avoid having dupicate Object names (in different classes).
--> Format for objects of type Numeric, Currency & Date should be defined.

Predefined Conditions
--> Give description for the use of each pre-defined condition.
--> If Condition is resulting in a Prompt, make sure associated Dimension Object has LOV.
--> Time dimension related predefined conditions such as Current year, Current month,Previous year,Last (x) weeks, etc can be defined to make it easy for scheduling daily/weekly/period based reports.

Tables
--> Alias Tables should be named with proper functional use.
--> Arrange the tables in the Structure as per Business/Functional logic. This helps other Universe users in understanding.
--> It is always best to bring the tables without joins and build them manually. It helps the designer to understand the intricacies of the model.

Joins & Context
--> AVOID keeping hanging (not joined) tables in the structure.
--> AVOID having joins that are not part of any context.
--> Give proper functional naming to the context for easy identification.
--> AVOID having 1:1 joins.

Import/Export
--> Make sure of the path for Import, which usually is always in the Business Objects' Universe folder.
--> LOCK the universe if Administrator/Designer does not want any user to Import/Export.
--> DO "Integrity Check" before Exporting the Universe.
--> Good to have correct folder structure , so that you can have a secured environment.
--> Once exported, never delete any objects from the universe without doing an impact analysis on the object usage

Migration
--> Better take a backup of the repository and then proceed with the migration in BO5.X and BO6.X Version

Report Design: Guidelines & Best Practices

General
--> Give meaningful names for the report tabs --> For complex reports, keep an overview report tab explaining the report --> Use the Report properties to give more information about the report

Dataproviders
--> Each Dataprovider should be given a name that reflects the usage of the data its going to fetch.
--> Select Objects in such a fashion that the resulting SQL gives a hierarchial order of Tables. This helps to achieve SQL Optimisation.
--> Avoid bringing lot of data into the report which will unnecessarily slow down the report performance.

Report Variables
--> Follow the naming convention of "var_" as prefix to each report level variable. This helps to identify Report Variables different from Universe Objects.
--> Each variable that carries a calculation involving division should have IF <Denominator> <> 0 THEN <Object>. This avoids display of #DIV/0 errors in the report.
--> Avoid having deep nested calculations which will slow down the performance of the report.

Report Structure
--> Make use of Report Templates when having most of the report with similar structures. This makes the work to move faster and consistant across.

Report Formats
--> All the reports should have page layout set in a printable manner. (Landscape/Portrait, Fit in 1 page wide or/and 1 page tall are different options).
--> All the reports should have page numbers in the footer.
--> All the reports should have Last Refreshed Timestamp in the header or footer.
--> All the above can be standardized by using templates

Report CELL Formats
--> All Numeric should be given Number format as per the language Eg. For German #.##00 for English #,##00.
--> Number cells should have a Right Alignment while Text cells should have Left Alignment.
--> Cell showing Percentage should carry the % text (either Column Header or in each cell).
--> Indenting should ALWAYS be done using the Indenting Tool and NOT by using " ".