With lots of Reports to be made, Universes to be designed and in parallel, Processes to followed for QA Analysys, there would be little things to remember that can help to design which in long terms helps for ease of maintenance, readability and helps to avoid rework for simple mistakes.
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.
-
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
Dhigtana 