Best Practices for BOXI R2 Universe Designer

Best Practices for BO XI R2 Universe Designer

Wipro Confidential Page 1 of 40

Best Practices for BO XI R2 Universe Designer An a technical paper

Written by Sivakanth Panchagnula

Business Objects Enterprise Architect -Center of Excellence for BI & IM

Wipro Technologies



Preface

This section of the document outlines the Objective, Audience & brief overview of the content of the document.

Purpose of the Best Practices for Universe Designer XI document:

The universe is the starting point for any Business Objects reporting

development. A good universe can save a lot of development time later. This

document will guide the universe developers and IT users to follow the best

practices while creating and using Universe Designer in Business Objects XI R2.

Content of Best Practices for Universe Designer XI R2 document:

• Overview of the Universe Designer XI R2 • New features Introduced in XI R2 • Best Practices in Universe Design and Development • Best Practices to be followed while Migrating Universes

Intended Audience & Expected behaviour for the Best Practices for Universe Designer XI R2 document

• Architect – Use this document as a reference to review the solution & designs

• Universe Developer – Use this document as guideline to develop the Business Objects Universes

Symbols used in this document to dedifferentiate between Standards, Guidelines & Methods

S Standards – These are the enforced policies which need to be followed with out any deviation.

G Guidelines – These are the recommendations

M Methods – This is the only way/standard procedure to do this



Table of Contents Introduction ................................................................................................................. 4 New features in Universe Designer XI R2 ................................................................. 5

Cascading list of values ........................................................................................... 5 SQL generation new features.................................................................................. 5 Ability to create universes against OLAP databases ............................................ 6 Retrieving Unicode data with Desktop Intelligence or Web Intelligence........... 6

Universe Development................................................................................................ 7 Universe development cycle ................................................................................... 7 Universe Connection ............................................................................................... 8 Universe Parameters.............................................................................................. 10 Table Structure ....................................................................................................... 13 Joins ......................................................................................................................... 14 Database Loops ...................................................................................................... 17 Aggregate Awareness............................................................................................ 22 List of Values .......................................................................................................... 22 Class / Object Organization.................................................................................. 23 Hierarchies.............................................................................................................. 28 Integrity Check....................................................................................................... 28 Cardinalities ........................................................................................................... 29 Optimizing universes ............................................................................................ 30

Managing Universes.................................................................................................. 31 Working in Multiple Designers environment ..................................................... 31 Linked Universes ................................................................................................... 33

Universe promotion................................................................................................... 35 Appendix .................................................................................................................... 38

Universe Design Checklist .................................................................................... 38 References ............................................................................................................... 40



Introduction

Business Objects Product suite has two semantic layers (an abstraction layer on

top of the data source which gives an user friendly interface to do reporting &

analysis) known as Universe & Business Views. Universe is the semantic layer

which was available in Business Objects from the initial versions of the tool &

Business Views got added later on after Business Objects acquired Crystal

Decisions.

Till this version (BOE XI) of the business objects, Universes were primarily

intended to act as the semantic layer for the Business Objects Reports & Metrics

(Web intelligence Reports, Full Client Reports, Dashboard Metrics etc) and

Business Views were intended to act as the semantic layer for the crystal reports.

In the current version of the Business Objects, it is possible to write crystal

reports on top of Universe Semantic layer, but keeping in mind the features

available in Business Views & the reporting functionality features of Crystal, it’s

not recommended to use Universe as the semantic layer for Crystal Reporting. It

will be wise to wait for sometime till Business Objects bridges the functionality

gap between Business Views & Universes and comes up with an unified

Semantic layer for all the kind of reporting available in Business Objects tool.

Business Objects has the future plan to merge the features of Business Views

with Universe & come up with a single, powerful semantic layer which will be

called as Universe.

The universe is created by the designer in order to mask the complexity of the

database from the Business users, and to create a consistent and convenient

storage mechanism for commonly used objects. This document outlines the

guidelines and best procedures for designing universe.



New features in Universe Designer XI R2

The following are the new features introduced in Universe Designer XI R2.

• Cascading list of values

• SQL generation new features

• Ability to create universes against OLAP databases

• Building universe against databases with Unicode Data

Cascading list of values

R A cascading list of values is a sequence of ‘lists of values’ associated with

a hierarchy of objects in a universe. This feature enables to select

sequential prompt values depending on the values selected in the

prompts.

SQL generation new features

R Index awareness is the ability to take advantage of the indexes on key

columns to speed data retrieval. This helps in increasing the report

Performance.

R An End_SQL parameter in the universe properties allows inserting a

string at the end of the SQL generated by a query. The variables are

stated in the common field and evaluated when running a query. This

feature is useful for testing & debugging.

R The JOIN_BY_SQL feature is used in universe to take advantage of the

RDBMS ability to generate derived tables and the full outer join SQL.

This will generate one global SQL flow instead of generating multiple

SQL flows. This will contribute towards the better performance of the

Reports.



Ability to create universes against OLAP databases

R An OLAP universe is a Business Objects universe that is generated from

an OLAP cube or query. The universe is created automatically from a

selected connection to an OLAP data source using an OLAP query

flattering driver that is installed as an add-in to Designer XI R2. This

feature will be helpful only when the organisation have OLAP cube data

sources like Oracle Express, Essbase Cubes etc.

Retrieving Unicode data with Desktop Intelligence or Web Intelligence

R The ability to retrieve the display Unicode data by building queries with

universes is available in Designer module of XI R2. This can be used to

create documents and run queries against data sources with Unicode

data, such as data in Japanese, Chinese etc.



Universe Development

The Universe Designer Interface enables the IT Universe Designer to develop the

Universe & all its content like Objects, Classes etc. Universes are usually

developed for standard & adhoc Reporting Requirements.

Universe development is a cyclic process which includes planning, designing,

building, distribution, and maintenance phases. The usability of any universe is

directly related to how successfully the different phases in the development cycle

interact with each other.

Universe development cycle

G The table below outlines the major phases in a typical universe development

cycle & it is recommended that the IT Universe Designers follow the below

phases:

Development phase Description

Prepare

• Identify the target data source and become

familiar with its structure

• Know what data is contained within each table of

each of the target databases

• Understand the joins

• Identify the cardinality

• Know what is possible

Analyze

• Understand the Business Users & their Business

functions & how they are organised

• Identify the key business questions that they

need to answer

• Identify what standard reports they require

• Familiarize IT Universe Designers with the



business functions & terminology

Plan

• Identify a project strategy. For example, how

many universes should be created and which

ones should have the capacity to be linked and to

what level.

Implement

• Build the universe using Designer.

• Test frequently during the build process for

validity and reliability of inferred SQL.

Test

• Form a small group of key Business users, who

have some knowledge of what information they

expect to get from the universe? Ask the key

Business users to perform thorough tests

simulating live usage of the universe(s)

Deploy

• Distribute the universe by exporting universe to

the Central Management Server (CMS), where it

can be accessed by the Business users.

Evolve

• Update and maintain the universe as the data

sources and user requirements change and grow.

Universe Connection

Connection defines the data sources for Universe. It will specify which physical

data source is made available to the system and how these data source is made

available. The connections are generally created by the IT Administrators &

made available to the IT Universe Designers.

R S You should never duplicate the connections for the same data source.



o This will make sure that you have all the connections unique.

R S You must always select the connection Type as Secured.

o Only secured connections can be exported to the Central

Repository & used by different Universe Designers. This also

always a standard for enterprise implementations.

R S You must provide a meaningful name to the connection & the standard

for that are outlined in the example below.

o By using the connection name, the IT Universe Designer will be

able to select/identify the appropriate data source.

o For example

• <DATASOURCE NAME>_<ENV IDENTIFIER>

• ABC_D (ABC is the source database & D stands for

Development Environment).

R G It is recommended to select the check box ‘Use database credentials

associated with Business Objects Users Accounts’ if you have all the

business objects users are defined as the database users also.

o This helps in leveraging the database level security defined for the

different Business Objects Users & better for tracking of usage &

solving support issues.

R S You must Test the Connectivity

o After creating the connection, it is a must for you to always test the

connection for any errors in the connection. This can avoid any

connection related issues that IT Business View Designer may face

for any incorrect parameters in the connection.

R S The IT Administrator must assign user access rights for different IT &

Business user groups in the CMC.

o This will ensure the access criteria for the IT users like IT Universe

Designers who will use this connection for Universe Development



& also will give the criteria for the Business users when they will

use these connections through Universes & reports.

o The following Screenshot depicts the different types of Access

levels that an IT Administrator can set on Universe connections

(Screenshot of the CMC interface to configure different access rights for Connections)

Universe Parameters

Universe parameters are certain parameters & options that the IT Universe

Designer can set for the Universe.

R S You must always give a meaningful name to the Universe.

o The Name of the Universe will be visible to the IT Report Designers

& the Ad – hoc Business users. Please refer to the Naming

Standards document for standards & guidelines on Names.

R S You must provide a meaningful ‘Description’ for the Universe.

o The description should be well defined & understandable to the IT

/ Business users of the Universe. Always give the description in the

Business terms & also mention a purpose of the Universe.



R G It is recommended to keep the connection alive to be no more than 10

minutes.

o This avoids repeatedly opening and closing connections and also

avoids keeping connections open for excessively long period.

R G It is advised to keep connection mode as asynchronous.

o Asynchronous mode will allow queries to be cancelled when user

presses ESC, which kills the query on the database and releases the

resources of database which are hold by the query.

R G It is recommended to set array fetch size maximum. Business Objects

allow max of 1000.

o Higher the number, the less fetches, the faster the query results are

passed back through database. If you have a good network

R G It is recommended to clear these check boxes in the universe

parameters, if you are using contexts to resolve chasm traps, fan traps.

The occurrence of chasm traps & fan traps are very rare if you have a

proper database design.

o To resolve the chasm traps & fan traps you need a common query

to retrieve data which can be achieved by un-checking these

options.



R G It is recommended to check the option Use Multiple SQL statements

for each context, if you are expecting to use contexts in the universe. It is

a good practice to check this option from the beginning.

o This will enable the Business / IT users to create queries that

contain multiple SQL statements when using a context. This option

is useful if you have any contexts in the universe.

R G It is recommended to check the Use Multiple SQL statements for each

measure

o This Splits SQL into several statements whenever a query includes

measure objects derived from columns in different tables. If the

measure objects are based on columns in the same table, then the

SQL is not split, even if this option is checked.

R G It is recommended to use Allow selection of multiple contexts

o This will enable the IT / Business users to create queries on objects

in more than one context and to generate one set of results from



multiple contexts.

R G It is recommended to check the option of Warn for the Cartesian

product.

o This will warn the IT Universe designer for any probable Cartesian

products & the IT Universe Designer can resolve it. If you will

choose prevent option then some times it will be difficult to debug

for any Cartesian issues.

Table Structure

This is the interface where the IT Universe Designers will bring the tables in to

the Universe & carry out all the other activities in creating the Universe.

R G It is recommended to insert tables one at a time. Don’t use quick

design wizard.

o This will avoid the confusion and will help the IT Universe

designers to put appropriate joins & check the cardinalities etc in

ease.

R G It is always recommended to include only the tables that the Universe

required which are going to be used in the queries. Don’t bring in tables

which are not required.

o This avoids confusion in maintenance & also keeps the universe

clean.

R G It is a best practice not to have isolated tables (which are not joined) in

the universe & create minimum objects from these tables.

o The isolated tables are static in nature as they are not joined to

other tables. It also helps in avoiding Cartesian product. If you are

using any field from isolated table with other fields, it gives a

Cartesian product.



R G It is always recommended to use derived tables where ever possible.

o This helps in maintaining a statistical table which involves complex

calculations. It reduces the load on maintenance of the database

summary tables. But only thing you need to keep it in mind that it

costs you on your performance front.

R G It is always recommended to provide tables weights for the tables.

o This helps in performance by ordering the tables. Table weight is a

measure of how many rows there are in a table. Lighter tables have

fewer rows than heavier tables. By default Business Objects sorts

the tables from the lighter to the heavier tables (those with the least

amount of rows to those with the most). This determines the table

order in the FROM clause of the SQL statement.

Joins

Once IT Universe designers have inserted more than one table in the schema,

they need to create joins between related tables. Joins are as important as the

tables in a schema, as they allow combining data from multiple tables in a

meaningful way. You can either detect the joins manually or can use the

automatic join detection. Detecting joins automatically is useful in quickly create

joins in our schema. However, you need to be aware of the limitations of

automatic join detection when designing schema.

R G It is recommended to trace the Joins manually.

o This will ensure that all the joins are valid & can avoid any wrong

joins.

R S You must always create joins in the structure pane.

o Joins that are not created from the structure pane, for example a

join manually defined in the Where clause for an object, are created



at run time, are not considered by Universe Designer for integrity

checks and context detection.

R G It is recommended to optimize database performance by using shortcut

joins where ever possible.

o Shortcut joins provide an alternative path between two tables.

Shortcut joins can improve query performance by using shorter

paths and bypassing intermediate tables.

R G It is a best practice to avoid outer joins where ever possible.

o Outer joins may have a negative effect on performance since more

rows are returned. Additionally, some databases will not use

indexes when outer joins are involved.

R G It is recommended to verify that the target database supports ANSI 92

before using this option.

o This gives a better performance by adding the joins in the FROM

clause.

o Designer supports ANSI 92 syntax for joins. ANSI 92 is not

supported by default and ensures that we verify that the target

RDBMS supports ANSI 92 before using the syntax in joins.

o IT Universe designer must activate support by setting the SQL

universe parameter ANSI 92 to YES. This parameter is listed on the

Parameter page of the universe parameters dialog box (File >

Parameters > Parameter). Once activated, we can choose to use

ANSI 92 syntax for joins in the universe.

Automatic join detection



As mentioned in the beginning of this section, automatic join detection is not

recommended, but still if you are using it then please follow the below guideline.

R G It is recommended to always verify manually each join that you accept

to be created that has been automatically detected.

o As there may be other joins necessary that have not been detected.

M Manual join tracing

Please use the below steps to trace the joins manually. IT Universe Designer can

graphically create individual joins between tables by using the mouse to trace a

line from a column in one table to a matching column in another table.

Step -1: Position the pointer over a column that is wanted to be one end of a join.

The pointer appears as a hand symbol.

Step -2: Click and hold down the left mouse button. The column is highlighted.

Step -3: Drag the mouse to the column in another table that IT user wants to be

the other end of the join. While dragging, the pointer is transformed into a pencil

symbol.

Step -4: Position the pencil symbol over the target column. The target column is

highlighted. Release the mouse button. The join between the two tables is

created.



Step -5: Double click the new join. The Edit Join dialog box appears. It lists join

properties.

Step -6: Enter and select properties for the join and Click OK.

Database Loops

Join path problems can arise from the limited way that lookup and fact tables are

related in a relational database. A loop is created when two or more paths exist

between tables. Loops are cause in a universe when tables are joined together in

such a way as to create a circular join path, as shown in the below screen shot:

(Screenshot of a loop in tables in the structure pan)

The problem with a loop is that the SQL cannot figure out which path to take

between two or more tables, because there are multiple options. Therefore, it

throws an error at the time of query execution. The loops can be resolved in 2

ways in Universe & they are Aliases & Contexts.



Aliases

Aliases are references to existing tables in a schema. An Alias is a table that is an

exact duplicate of the original table (base table), with a different name. Just to

make it very clear, if you look at the previous screenshot of the loop, it is caused

because it is using a dimension, or lookup, table (COUNTRY), for two different

purposes. It is using the COUNTRY table to determine the country of the client,

and also to determine the country of the showroom. To avoid loops like this, you

can create an alias table for each purpose. An alias is simply an alternate name

for a table. In this case, we can create two aliases of the COUNTRY table, one to

connect to the REGION table, and one to connect to the SHOWROOM table as

shown in the below screenshot.

(Screenshot for alias of table)

Notice that the original table, COUNTRY, has been placed off to the side, and

will not be used directly. However, if we delete it from the universe, the aliases

will be deleted as well. And by only using aliases, we can give them names that

make it clear what they are being used for.



R S You must always alias the base tables which you want to alias as it is

inserted into Schema – then build the schema using the alias tables, not

the original base tables. Place the base tables together away from the

main universe structure & put a text around it as ‘ALISED TABLE, DO

NOT DELETE’ as shown in the above screenshot. Base tables are the

original tables from the database schema.

o This allows to give meaningful names to tables, and prevents the

need to rebuild major sections of a universe structure should a base

table need to be aliased at a later stage.

R G It is a best practice to give a meaningful name that can better describe a

table’s purpose than some original cryptic name.

o This avoids confusion & helps in understating the purpose of the

alias table. For Example, in the above screenshot the alias table

names are COUNTRY_SHOWROOM & COUNTRY_REGION

which gives a good meaning that they are used as SHOWROOM &

REGION respectively in the Universe.

NOTE: It is recommended to create aliases in the following Scenarios.

• To use the table more than once in a query.

• To solve loops and fan traps. Logically separates the trap into

pieces

• To abbreviate the table name to save typing when writing

freehand SQL.

• Generic lookup tables can be resolved by alias.

• Recursive relationships can be resolved.

Contexts

If a loop is caused by having multiple fact tables access common dimension

tables, we resolve these loops with contexts. ‘. Contexts are a collection of joins



which provide a valid query path for Business Objects to base its SQL generation.

Contexts are nothing but the multiple query paths that the Universe users (IT &

Business) can use.

R S You must always give a meaningful name to the context.

o This help in the use of the context for the end Users (IT / Business).

R G It is a best practice to give a meaningful description to the context.

o This is the help text that an end user (IT / Business) sees when they

run a query that takes the context path. This text will be useful to

them.

M Standard method for creating a context manually

Step-1: Select Insert > Context. Or Click the Insert Context button. Insert

Context

The New Context box appears

Step-2: Type a name for the context in the Context Name text box.

Step-3: Select all the joins defining the context in the Current Context Joins list.

Step-4: Click the Detect button to show the joins making up a suggested context

with context name.



Step-5: Select the Show Selected Only check box to see only selected joins. Click

the Check button.

Step-6: Type a description of the data the context returns. This is the help text

that a Web Intelligence user sees when they run a query that takes the context

path. This text should be useful to the end user.

Step-7: Click OK.

NOTE: Contexts are used for the following purposes:

• To solve chasm traps and in some solutions to fan traps

Chasm traps can occur when two many-to-one join paths converge on a

single table. Multiple rows can be returned for a single dimension causing

inflated results. Contexts can split out the query so that the correct numbers

of rows are returned for the dimension. Contexts can also be used with

aliases to solve fan traps.

• To solve loops

The most common use of contexts is to separate two query paths, so that one

query returns data for one fact table, and the other query returns data for

another fact table. We use contexts to direct join paths in a schema which

contains multiple fact tables. Aliases are not appropriate in such schema.

• To assist in detecting incompatibility for aggregate awareness

objects

Contexts are used to exclude objects that are not compatible with an object

using the @AggregateAware function in its definition, from being used in a

query with the aggregate aware object. The following section talks about the

aggregate awareness.



Aggregate Awareness

Aggregate Awareness is the ability, within a universe to take advantage of

aggregate or summary tables within a database, without having to create a set of

objects for each aggregate table. Aggregate Awareness in the universes gives the

following advantages:

• It allows the IT Universe Designers to add intelligence to existing

objects that will allow them to access the appropriate table based on

the level of detail needed for the query.

• Queries run against aggregate tables will run much faster than

queries run against transaction tables, simply because the tables are

significantly smaller that the transaction table, depending on the

level of aggregation in the table.

R G It is recommended to test the aggregate awareness using the Web

Intelligence.

o This will ensure the accuracy of the aggregate awareness.

R S You must always provide a right order of aggregation in the aggregate

aware function.

o This will determine the right aggregation orders for different

aggregate tables. You should start from the highest aggregation to

lower aggregation. For Example: YEAR should be followed by

QUARTER & then MONTH.

List of Values

When IT Universe designer creates a dimension or detail object in Designer, it is

automatically assigned an associated list of values. This list does not physically

populated when we create an object, but by default, the object has the ability to

query the database to return a list of its values when used in the Query pane.

There won’t be any default list of values is assigned to measure objects.

R G It is a good practice to restrict the LOV to a smaller number of values.



o If the field for LOV points to a large table (number of rows) then

refreshing the LOV may be slow. You can a condition to edit the

LOV to restrict it to contain only the required values.

R G It is recommended to combine code and description in the LOV.

o This gives a good meaning to the LOV.

o For example: An object returns a 'sales type code' which may

not have a meaningful value to some users. Editing the LOV to

display the 'sales type description' will help them when viewing

the LOV. The opposite can be done for the 'sales type

description' object to display the code along with the

description.

Class / Object Organization

Classes & object organisation is the very important part of the Universe

development as this is the layer with which the IT Report Designers & the Ad

Hoc Business Users interact most. As the organisation of the classes & objects

will be driven by the respective requirements that the Universe is expected to

address, but there are certain standards & guidelines need to be followed

through out the organisation for better usability & maintainability.

Classes

Classes are the folders & sub folders that are used to organise the objects which

can be a dimension, detail, measure or even a condition.

R S You must always give meaningful Name & Description to the Classes.

Try to avoid very long names also. The name should be concise & context

oriented.

o This helps the end users (IT & Business) while using this in

creating reports & queries. Long names will occupy more space

in the pane which can reduce the user friendliness of the

Universe.



R G Always use classes to logically group the objects. The class should

contain the related objects in it.

o This will help the end user (IT & Business) in finding the

required objects with ease. For Example: if you have a customer

class, the have all the customer related objects in that class.

R G It is recommended not to cluster class with too many objects and sub-

classes

o It’s difficult for end users (IT & Business) to navigate through

classes.

R G It is a best practice is to arrange classes in alphabetic order or with

some business context. Always have the dimension classes at the

beginning followed by the measures.

o Navigation through classes would be easy for end users (IT &

Business).

R G It is recommended to hide the classes & Objects which are not required

by the Business end users.

o This will avoid the confusion for the Business users. You should

only hide the class which contains the objects which are not

required by the Business users. Generally the classes/Objects

which need to be hidden are:

• Components from linked universes and are not

needed in the active universe.

• Objects used only to optimize SQL syntax and should

be hidden from end users.

• Components need to be disabled temporarily without

deleting them.



Objects

Objects are generally the components that are mapped to one or more database

table column (s) with some appropriate syntax. An object can also be a map to

the function defined on one or more columns.

R S You must always give a meaning full name to each object.

o It helps in identifying the object.

R S You must always give a meaning full description to each object.

o The description of the objects appears as a tool tip for the end

user (IT & Business). This helps in understanding the use of the

objects. Most of the cases, this description should be the

business definition of that object. The organisation data

dictionary also can be leveraged for giving a meaningful

description.

R G It is a best practice to define the index awareness for the objects

(dimensions & details).

o This increases the query performance by taking the advantage

of indexes on the key columns. You can define the index

awareness using the key tab.

R G It is recommended to avoid the use ‘Where’ clauses in the objects

where ever possible.

o This has performance implications & can contribute towards

creation of multiple objects. The below table gives different

scenarios, where you can avoid using ‘Where clause’ and use

‘Create Condition objects for each restriction instead’.



Problem Description Solution

Proliferation

of similar

objects.

If you restrict data for an object by creating several objects, each inferring a Where clause for one part of the data, you can end up with multiple objects with similar names. For example, French clients, US clients, and Japanese clients. This can be confusing for users to see multiple objects that appear similar.

Create condition objects for

each

Restriction.

Difficulty creating hierarchies.

If you have multiple objects inferring Where clauses on the same data, it will be difficult for users to construct a logical default hierarchy to use for drill down.

Create condition Objects for each restriction.

Confusion between object name and applied restriction.

Unless your objects are very precisely named, then a restriction may not be obvious to the user simply from the name of the object. A Business user can see the Where clause by viewing the SQL for a query, but not all users will view the SQL before running a query.

Create condition objects for each restriction. Name each object appropriately.

Conflict between Where clauses.

If two or more similarly restricted objects are included in the same query, the conflict between the Where clauses will result in no data being returned.

Create condition objects for each restriction, and ensure that users (IT & Business) do a union or synchronization of the



Queries at the report level.

R G It is a best practice to create separate class/sub class for conditional

Objects.

o This will help easy identification of the conditional objects.

R G It is recommended to format objects and measures within the

universe.

o This prevents end users (IT & Business) having to spend

valuable time formatting data from within the reporting tool

every time they create a report. Also this will ensure a generic

formatting across the organisation.

R G It is recommended that to specify the way the aggregate function will

be projected onto a report for the measure objects.

o This helps in the appropriate aggregations which can increase

the report performance.

o Returned values for a measure object are aggregated at two

levels of the query process, Query level when Data is

aggregated using the inferred Select statement and Micro cube

to block level when data is projected from the microcube to the

block in a report. This projection function of measures allows

local aggregation in the microcube.

R G It is recommended no to define measures that are averages at the

Universe level, but do this at the report level.

o It will avoid incorrect results.



Hierarchies

Hierarchies are used by the end users (IT & Business) to do the multidimensional

analysis. This allows end users to observe the data from various view points.

This is required for performing the drill function in the Web Intelligence

Reporting. There are two kinds of hierarchies are there & they are default

hierarchies & Custom hierarchies. By default, Designer provides a set of default

hierarchies for multidimensional analysis. These are the classes and the objects

arranged in the order that they appear in the Universe pane. When you create

objects, you should organize them hierarchically, to ensure that default

hierarchies have a sense to the end users (IT & Business). Custom hierarchies are

the hierarchies that you build in the Designer.

R G It is recommended to have at least one custom hierarchy in the

Universe.

o It will facilitate the use of ‘Drilling facility’ and ‘Cascading list

of values’.

R G It is best practice to have the certain standard hierarchies like Time,

Geography etc always in the universe.

o These are the standard hierarchies which is required in most of

the multidimensional analysis.

Integrity Check

Integrity checking is a built in feature of Business Objects Designer tool available

via TOOLS / CHECK INTEGRITY.

R S You should always avoid using the CHECK CARDINALITIES option.

o This will usually take a very long time and can return

inaccurate results due to incomplete or misleading data on the

database.



R G It is recommended to use ‘Quick parsing’ in the development cycle.

o This will ensure that all the objects are parsed & checked for any

possible error.

R G It is recommended to test measures by starting with 1 dimension + 1

Measure, then 2 dimensions + 1 Measure, etc. Confirm/check SQL

generated as each new dimension or additional Measure is added during

unit testing to ensure accuracy.

o This ensures that the objects are error free.

R S You must always check the ‘Send check integrity’ option.

o This will compel the designer to display a warning if you are

exporting an unchecked Universe. This will make sure that you

check the Universe before exporting.

Cardinalities

The cardinalities feature is dependent on the Quality and quantity of data – if the

2 tables contain data that is inconsistent with the true cardinality, Business

Objects will report the cardinality incorrectly e.g. if the many side of a one-to-

many has limited rows i.e. only one row per row in the other table, Business

Objects might detect the cardinality as a one-to-one. In general the cardinality

detection takes a longer time since both tables are accessed and those tables

could contain a lot of data. If several simple joins are used instead of a single

complex join across the tables, then the cardinality detection will always be

incorrect. A complete join is needed for accurate cardinality detection

The built in cardinality detection can be used as a way of confirming users

separate determination of cardinality but it is strongly suggested that it is not

used as IT Universe Designers sole knowledge of cardinality.

M The below bullets are the standard ways to detect the cardinalities for

different joins.



• Self joins – set their cardinalities to a constant value. It doesn’t matter

what but it is suggested to be one-to-one. Self joins cardinalities are

never used by context detection but the absence of a cardinality will

trigger the ‘not all cardinalities are set’ warning

• Short cut joins – ideally set their cardinalities to represent the same

cardinality of the path they are replacing. Short cut joins cardinalities

are never used by context detection but the absence of a cardinality

will trigger the ‘not all cardinalities are set’ warning

• All other types of joins – their cardinality must be determined on a

case-by-case basis. Knowledge of cardinalities is mainly dependent on

knowledge of the primary and foreign keys within a table:

Optimizing universes

Query time can often be shortened by optimizing a universe. There are several

ways we can optimize a universe:

• Optimizing the Array Fetch parameter in the Universe Parameters.

• Allocating a weight to each table.

• Using shortcut joins.

• Creating and using aggregate tables in our database.

• Index awareness

All the guidelines & standards around this have already been covered in the respective section of the documents.



Managing Universes

Working in Multiple Designers environment

Universe Designer can be used in a multiple user environment in which several

IT universe designers can work on the same universes without causing conflicts

between versions. This scenario can happen in a case where one universe is used

across multiple project groups. The IT Universe Designers can lock the universe

so that only one IT universe designer at a time can make modifications on the

universe, and a universe can also be assigned a version number to keep track of

changes. When stored in a universe folder, a universe can be shared by several

designers provided that they have the necessary user rights.

NOTE: Only one IT universe designer can work on a given universe at a time.

An IT universe designer who wants to work on a universe, can do so only if the

universe has not been locked by another designer.

R S You must always lock universe on import feature to control export of

the Universe to the Repository.

o When several developers are working on one universe, this

option will prevent people from exporting over the universe in

the repository.

o This feature will not prevent someone from importing the

universe and making changes in their local environment,

although they will not be able to export those changes back to

the repository until the lock has been removed. Therefore if

several developers have the ability to import and export the

same universe, coordinate their efforts to avoid development on

a universe that is out of date.

o You can lock the universe by double-click on the universe name.

A locked universe appears with a padlock symbol. To unlock a



universe, double-click it again. The below screenshot shows the

interface.

R S You must always use appropriate text in the comments of the Universe

to mention the version of the Universe.

o This will ensure that the appropriate version of the universe is

available & will avoid any universe corruption.

NOTE: Each time Universe designer export a universe to a universe folder,

Designer increments the revision number of the universe. This allows us to

determine, which the latest version of the universe (it’s a default feature

available). Use the comments text box (File > Parameters > Summary >

Comments) to record the status and changes of a universe for other developers.

This text is only visible in DESIGNER, whereas the description text (shown on

the Definition tab) is visible to end users when they select an available universe.

The interface is shown in the below Screen shot.



Linked Universes

Linked universes are universes that share common components such as

Parameters, classes, objects, or joins. When we link two universes, one universe

has the role of a core/master universe, the other a derived universe. When

changes are made in the core/master universe, they are automatically

propagated to the derived universes. Linked Universes would be very helpful in

case you have the subject areas shared across the business functions & have an

enterprise wide data warehouse. In this scenario this can be leveraged to create

master universe containing the common subject areas & then use derived

universes for each business functions. This gives a single point control for

maintainace & enhancement to the Universes.

R S You must always make sure that your both Master & derived universes

are pointing to the same database.

o The linked universes will work only when they are from the

same database.



NOTE: Pre-requisite for the Linked Universe.

• The core universe and derived universe use the same data account, or

database, and the same RDBMS. Using the same connection for both

the core and the derived universe makes managing the universes

easier, but this can be changed at any time.

• The core and derived universes must be in the same repository.

• The core universe was exported and re-imported at least once. The

derived universe does not need to have been exported before creating

a link.

• Exported derived universes are located in the same universe domain

as the core universe.

• Designers are authorized to link the given universe.

Restrictions when linking universes

• Universe Designers can use only one level of linking. Users cannot

create derived universes from a universe which is itself derived.

• All classes and objects are unique in both the core universe and the

derived universes. If not conflicts will occur. The two universe

structures must allow joins to be created between a tables in one

universe to a table in the other universe. If not, then Cartesian products

can result when a query is run with objects from both structures.

• Only the table schema, classes and objects of the core universe are

available in the derived universe. Contexts must be re-detected in the

derived universe.

• Lists of values associated with a core universe are not saved when you

export a derived universe with the core universe structures.



Universe promotion

A typical organization will have four 4 different environments (Development

(DEV), Integration (ITG), Quality Assurance (QA), Production (PROD). Dev and

ITG may potentially reside on the same server.

It’s a good practice to have at least four copies of Universes across different

environments like- DEV, ITG, PROD and ideally a QA where the entire tests

Universes are stored. If the Universe in one Server gets corrupted or if the state

becomes unknown the only resource is for the administrator to make a new copy

of the universe in a different Server and use it.

M The following is the sequence of steps to be followed in migration of

Universes.

Step–1: Log in to the Business Objects Enterprise in the client Box and start the

import wizard.



Step–2: Select the Source environment

Step–3: Select the Destination environment



Step–4: Finally Import all the Universes to the required Environment.

The same procedure needs to be followed for promoting the Universe from one

environment to another.



Appendix

Universe Design Checklist

This checklist can be used by the IT Universe Designer to make sure that he/she

has covered all the necessary aspects of the Universe Designing. BI CoC architect

or the Universe approving authority can use this checklist in the approval

process.

The below checklist contains the standards (S), guidelines (G) that need to be

followed during the universe development cycle. Apart from Standards &

guidelines, you will also find some general points in the checklist which can be of

great value.

Universe Name: Reviewer: Review Date:

Item OK? Comments/Recommendations

Universe Parameters S Is name of the universe as per organization standard?

S Is meaningful description provided for universe? S Is secured connection used? G Is SQL (Cartesian product) set to prevent? G Is SQL (Multiple Path) – “Allow selection of multiple contexts” set?

Class S Is class name meaningful and understandable? S Is a meaningful description provided for each class and sub class?

Does the universe have any incompatibilities within a class such as objects from multiple contexts?

When a query is run on all the objects of the class, does they return the same number of rows as they return at the table level?




Objects S Does the object have proper name & description? Object type matches with tables column definition Objects are qualified correctly as dimension, detail or measure

Are columns of numbers right justified? G Format set for measure objects to display correct decimal places

Did you test the measure object extensively with all dimension objects related to hierarchies?

Is aggregate function set for each measure object? Is parsing of objects successful? Joins G Parsing of the joins are successful? G Is cardinality set for each joins? Is cardinality matches with physical database design?

Is the column used in joins matched with physical database design?

Context and Alias G Is a name & description provided for each context?

G Is Alias used to resolve loops? Item OK? Comments/Reco

mmendations Universe Evaluation criteria Does the universe have proper connectivity to the database?

Are there any cardinalities in the universe? Are there any loops in the universe?

Does the universe contain alias tables? Does the universe have contexts? Does the universe contain LOV’s from a static file (Word or Excel file)?




Does the universe use Nested Prompts? Are there any aggregate aware functions in the Universes?

Does the universe get tested for hierarchies? Does the universe contain the conditions? Is thorough parsing done for the universe? Are there any aggregate builds from OLTP processing system?

References

Businessobjects Documentation

Documents

Best Practices for BOXI R2 Universe Designer