Universe and Report Design Guidelines and Practices

The document is a compilation of learnings that can be used as Guideline and Best Practices for Report & Universe 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.

Class

--> Define Universe Classes / Subclasses as per the business logic & Naming Convetion.
--> 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.
--> Avoid having dupicate Object names (in different classes).

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.

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.

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.

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

Introduction

Gives the basic guidelines/practices that could be followed in any Report Design.

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 <> 0 THEN