BO XIR3 Universe Designer

BO Designer: Overview
Introduction:
Designer is a BO component that is used to build universes.
A universe is a semantic layer between database and end users.
The role of a universe is to provide an easy to use and

understand interface for non technical Business Objects and

Web Intelligence users to run queries against a database to
create reports and perform data analysis.

BO Designer: Objective
Objective:
After completing this chapter, you will be able to:

Define connection to universe

Design universe
Insert tables and joins
Resolve loops
Create classes and objects
Check universe integrity
Manage universe
Overview of Security
3

Universe
A universe:
Is a semantic layer between database and end users.
Is a business-oriented mapping of the data structure found in

databases: tables, columns, joins, and so on.

Can represent any specific application, system, or group of
users. For example, a universe can relate to a department in a
company such as marketing or accounting.
Can also pertain to a section within a department or just about
any set of organized procedures such as a payroll or inventory
system.
Consists of a set of objects, grouped by classes.
4

Role of a Universe
The following diagram shows the role of objects as the mapping layer between a

database schema and the Query panel in BusinessObjects or the Query work
area in WebIntelligence, that users use to create queries to run against database
tables.

The Semantic Layer

The semantic layer may consist of one or more separate

universes. Each universe is a partial representation of a

database, in the form of business vocabulary.
Sales/Marketing

Human
Resources

Employee Salary
Bene.its...

Sales Revenue Sales

Executive Customer
Product Price Order
Date ...

The Universe Development Process

Prepare

Know the data source

HR on
Sybase

Financials
on Oracle

Analyze

Identify the needs of the

end user population

Plan

Design the universe(s)

The Universe Development Process (Contd.)

Implement

Create the universe(s)

Test

Using a test team (including end

users)
Deploy

Distribute the universe to end

users
Evolve

Adapt and extend universe

over time
8

The Universe Development Process (Contd.)

80
20

Involve users in all steps of the

project

Creating a Universe
De.ine the Parameters
Resolve the Loops
Insert Tables
Create Classes and Objects
Make the Joins
Set up Hierarchies

10

Creating a Universe (Contd.)

For creating a new universe:
Select File > New

11

Universe Connection
Definition:
A connection is a link from the universe to the target database
The link is achieved using middleware (for example ODBC)
An existing connection may be used or a new connection

created for a universe

There are three different types of BO connection

12

Types of Connection
Personal: Can only be used on the client

Shared: Can be used by more than one user to send queries to the target

database from a shared server

Secured: This connection is used when you wish to distribute the completed

universe to the user population via the repository

13

Setting up Universe Parameters

Definition Tab: Name, description, and

connection to the database.

Summary Tab: Author and statistics about the

universe.
Strategies Tab: Internal or personal wizards to

make creating a universe easier.

Controls Tab: Manages access and control of

resources.
SQL Tab: Queries and SQL parameters.
Links Tab: Enables dynamic links with other

universes.

14

Setting up Universe Parameters (Contd.)

Controls tab:
These allow you to limit the

size of results and restrict

the time allowed for
executing queries.

15

Setting up Universe Parameters (Contd.)

SQL tab:
SQL parameters are used to

define the limits of the SQL

that may be generated by the
universe.

16

Inserting Tables
Use the Table Browser:
Double-click on the background of the

Structure
Click on
Choose Insert -> Tables from the menu

The Table Browser displays all the tables and

views of the database.

You can select multiple tables using the Shift

key or Ctrl key.

17

Classes and Objects

BO presents the data in three hierarchical collections or

categories:
Universe
Classes
Objects

18

Class
Universe:
A BO universe is a collection of classes that is intended for a

particular group of users.

Class:
A class is a logical grouping of objects within a universe. It

represents a category of objects. The name of a class should

indicate the category of the objects that it contains. A class can
be divided hierarchically into subclasses.
19

Object
Object:
An object is a named component that maps to data or a

derivation of data in the database. The name of an object should

be drawn from the business vocabulary of the targeted user
group. For example, objects used in a universe used by a
product manager could be Product, Life Cycle, or Release
Date. A universe used by a financial analyst could contain
objects such as Profit Margin and Return on Investment.
20

Object Types
Dimension:
Parameters for analysis. Dimensions typically relate to a

hierarchy such as geography, product, or time. For example Last

Name and City_Id.
Detail:
Provide a description of a dimension, but are not the focus for

analysis. For example Phone Number.

Measure:
Convey numeric information which is used to quantify

dimension object. For example Sales Revenue.

21

Using List Of Values

Allows you to view and modify the data values in the list of values assigned to

the selected object.

You can view the list of values in a tabular form or in a hierarchical form.
The options to manage lists of values are:

Edit
Display
Purge
Refresh
Properties
You can specify a text file, a Dbase file or a spreadsheet file to be used for the

selected object's list of values.

22

Using List Of Values (Contd.)

23

23

Creating Joins
What do joins achieve in SQL?
The SQL will give a cartesian product which gives an incorrect

result

24

Creating Joins (Contd.)

What is Join?
A join is a condition that restricts the result set of a query
There are several different kinds of join:
Equi-join (otherwise known as a standard or inner join)
Outer join
Theta join
Shortcut Joins
Self join

25

Creating Joins (Contd.)

Equi - Join

26

Creating Joins (Contd.)

Creating a Join in Designer:
A join can be entered manually using two

methods:
Graphically

With the menu option Insert,

Joins and the Edit Join box

To delete a join, click on the join line and

press Delete

27

Creating Joins (Contd.)

Automatic join detection:

The Strategy for automatic detection of joins is based on

common column names between tables.

You can choose from one of three specific strategies for join
detection:
Smart matching column names (no key info.)
All matching column names
All matching numeric column names

28

Creating Joins (Contd.)

Theta join:
A theta join contains an expression that is based on something

other than equality:

Theta Join
Theta Join Result Set:

29

Creating Joins (Contd.)

Creating theta join:
A theta join is created by converting an existing equi-join.

30

Creating Joins (Contd.)

Shortcut joins:
Join providing an alternative path between two tables, bypassing

intermediate tables, leading to the same result, regardless of

direction.
Optimizes query time by cutting long join paths as short as
possible.

31

Creating Joins (Contd.)

Self restricting join:
This is not really a join at all. It is a method used to set a

restriction on a table in the universe structure.

32

Creating Joins (Contd.)

Adding cardinalities:

Manually using the Edit Join dialog box

Automatically using (but can take a long time)

33

Creating Joins (Contd.)

Join problems: The three major join problems that could be

encountered in the schema are:

Loops (resolved using alias/contexts)
Chasm traps (resolved using contexts)
Fan traps (resolved using alias/contexts)

34

Creating Joins (Contd.)

Loops:
A loop is a set of joins that defines a closed path through a set of

tables in a schema. Loops occur when joins form multiple paths

between lookup tables. An example of a loop is shown below:

35

Creating Joins (Contd.)

The schema contains two linked sets of information:
For each

The following information is linked

Resort

Available service lines, services for each service line, invoice

information for each service and the country where the resort is
situated.

Customer

The city, region and country where the customer lives, the sales for
the customer and the invoice information for each sale.

These two sets of information are linked in a common join path

forming a loop. The lookup table Country can be the country

where a resort is situated, or the country in which a customer
lives.
36

Creating Joins (Contd.)

Chasm Trap
A chasm trap is a type of join path between three tables when

two "many-to-one joins converge on a single table, and there is

no context in place that separates the converging join paths.

37

Creating Joins (Contd.)

Fan trap:
A fan trap is a type of join path between three tables when a

one-to-many join links a table which is in turn linked by

another one-to-many join. The fanning out effect of one-tomany joins can cause incorrect results to be returned when a
query includes objects based on both tables.

38

Creating Joins (Contd.)

Always check integrity after defining joins:

39

Resolving Loops
Loops can be resolved using:
Alias
Context

Alias:
An alias breaks a loop by using the same table twice in the same

query for different purpose. The alias is identical to the base

table with a different name. The data in the alias table is exactly
the same as the original table, but the different table name
generates a modified SQL, referring to two tables and two sets
of joins and the loop is broken.

40

Resolving Loops: Alias

The two one ended joins are now separated as follows:
Country keeps a join to the Resort table.
Country_Region is joined to the Region table.

The schema now appears as shown below:

41

Resolving Loops: Context

Context:
A context resolves a loop by defining a set of joins that specifies one

specific path through tables in a loop. It ensures that joins are not
included from different paths within the same SQL query.
You often use contexts in the schema that contain multiple fact tables
(multiple stars) that share lookup tables.

42

Resolving Loops: Context (Contd.)

In the example, you can follow two different paths from the

Customer table to the Service table:

For this path

Designer detects these contexts

Reservations and
Reservation_Line

Reservation_Line

Sales and
Invoice_Line

Sales_Line

43

Resolving Loops: Context (Contd.)

The Reservation_Line context appears below:

44

Resolving Loops: Context (Contd.)

The Sales_Line context appears below:

You then create different sets of objects from the tables in the different contexts. Users

can then run either Reservation queries or Sales queries, depending on the objects they
select.
45

Hierarchies
Object hierarchies can be created to perform multidimensional analysis.
Multidimensional analysis is the analysis of dimension objects organized in

meaningful hierarchies.
Multidimensional analysis allows users to observe data from various viewpoints.
This enables them to spot trends or exceptions in the data.
A hierarchy is an ordered series of related dimensions. An example of a
hierarchy is Geography, which may group dimensions such as Country, Region,
and City.

46

Functions
SQL editor is used to define the Select statement or a Where

clause for an object. Functions can be used in an object definition.

Database functions, for example number, character, and date
functions.
@Functions specific to BO products.
The available @functions are:
@Aggregate Aware
@Prompt
@Script
@Select
@Variable
@Where
47

Conditions
A restriction is a condition in SQL that sets criteria to limit the data returned by

a query.
Two types of restrictions can be defined in a universe:
Restriction type

Description

Forced

Restriction de.ined in the Where clause for an object. It cannot be

accessed by users and so cannot be overridden in Web
Intelligence.

Optional

Restriction de.ined in special condition objects that users can

choose to use or not use in a query. A condition object is a
prede.ined Where clause that can be inserted into the Select
statement inferred by objects in the Query pane.

A condition object is a predefined Where clause that can be inserted into the

Select statement inferred by objects in the Query pane.

48

Conditions (Contd.)

Using condition objects has the following advantages:

Useful for complex or frequently used conditions
Gives users the choice of applying the condition
No need for multiple objects
Condition objects do not change the view of the classes and

objects in the universe pane

49

Aggregate Awareness
Aggregate awareness is the ability of a universe to make use

of aggregate tables in a database.

Aggregate Tables:
Contains Pre-calculated data
Speeds up the execution of queries, improving the performance

of SQL transactions.
Set up aggregate awareness as follows:
Define the Select statement for an object using the

@AggregateAware function.
Specify which objects are incompatible with the aggregate table
and can not be used in a query that is run against that table.
50

Derived Tables
Derived tables are tables defined in the universe schema.
A derived table is defined by an SQL query at the universe level that can be used as a

logical table in Designer.

The columns returned by the queries to build objects can be used as the columns of a

normal database tables.

51

Derived Tables ( Contd.)

Derived tables have the following advantages:
Reduced amount of data returned to the document for analysis
Include complex calculations and functions in a derived table. These operations are performed before

the result set is returned to a document, which saves time and reduces the need for complex analysis
of large amounts of data at the report level.
Reduced maintenance of database summary tables
Derived tables can, in some cases, replace statistical tables that hold results for complex calculations

that are incorporated into the universe using aggregate awareness. Derived tables can return the same
data and provide real time data analysis.

52

Derived Tables ( Contd.)

Steps for creating a derived table:
a)

Right-click the mouse over the Designer table schema and select
Derived Table from the menu to view the Derived Tables dialog
box. Or go to Insert->Derived Tables.

53

Derived Tables ( Contd.)

b) Type the derived table name in the Table Name box.
c)

Type the derived table SQL in the SQL Expression box or use the
objects in the Tables and Columns, Operators and Functions boxes
to build the SQL.

54

Derived Tables ( Contd.)

d) Click SQL to validate the SQL.
e) Click OK to close the dialog box. The derived table appears

as a regular table in the Designer table schema.

f) Use the columns in the derived table to build objects as you
do with a normal database table.

Derived tables can be edited or deleted.

55

Linking Universes
Linked universes are universes that share common components such as

parameters, classes, objects, or joins.

An active universe can be linked to one or more universes.
Among linked universes, one universe is said to be the kernel while the others

are the derived universes.

The kernel universe represents a re-useable library of components.
Derived universes may contain some or all of the components of the kernel, in

addition to any components that have been added to it.

While connecting an active universe to other universes, the active universe

becomes the derived universe, and the linked universe becomes the core
universe.

56

Linking Universes (Contd.)

Components from the core universe are inherited by the derived universe.
To link a universe to a core universe, the core universe must have been

exported to the repository at least once. Otherwise, DESIGNER does not allow
the link.
Advantages of linking universes:

Reduce development and maintenance time. While modifying a

component in the core universe, Designer propagates the

change to the same component in all the derived universes.
Centralize often used components in a core universe, and then
include them in all new universes. No need to re-create
common components each time while creating a new universe.
57

Linking Universes (Contd.)

To Link two universes:
Goto Edit-> Links. Click the Add Link button.

Shows the names

of the universes to
which the active
universe is linked.

Shows the user who

last modified the
universe.
It lets you indicate the
new location of the
kernel universe if u
have changed its
location.

Displays the
Universe to Link
dialog box from
which you can link
the kernel universe
to other universes.

Other than linking

universes, you can
include the
components of the
kernel universe in a
derived universe.

Remove a link to a
kernel universe only if
the active universe no
longer contains objects
based on components
or joins from the kernel
universe.
Displays the path of the linked universe.

58

58

Linking Universes (Contd.)

The Universe to Link dialog box appears.

Browse to the universe to link.

Click the Open button.
The selected universe appears in the list.

Click OK. The link is created. The tables of this core universe

can be visible in the universe schema.

59

Securing Universes
A restriction is a named group of constraints that apply to a universe.
When users connect to a universe, the objects, rows, query types, and connection that

they use in the universe are determined by their applied restriction.

60

Securing Universes (Contd.)

Apply restrictions to defined user and groups who use a universe

at two levels:
CMC Level - From the Central Management Console set

restrictions that apply to universes stored in a CMS. Set what

universes users can access, and depending on the rights defined for a
user group, restrict viewing, editing, deleting, and other actions in a
universe.
Universe Level - Define restrictions for users allowed to use a
universe. A group of restrictions that correspond to a user group is
called a restriction set. A restriction set can include object access,
row access, query and SQL generation controls, and connection
controls.
61

Securing Universes (Contd.)

To create a restriction set
Select Tools > Manage Security > Manage Access Restrictions.

The Manage Access Restrictions box appears.

62

Securing Universes (Contd.)

Click New. The Edit Restriction dialog box appears.
Click on each tab in the dialogue box and apply the restrictions to be

imposed in the universe and click OK.

63

Managing Universes
Reason for universe maintenance:
New tables added to database
Tables deleted, changed, or renamed in database
Users request new classes or objects
Note:Your primary concern when you introduce a new version of a universe should be what effect it
will have on existing end user reports.

Tip: Do not distribute new versions of universes too frequently!

64

Managing Universes (Contd.)

Changes to target database:
The implications of modifying the underlying database for BO universes varies in severity:

No Impact:
Adding new columns
Adding new tables

65

Severe Impact:
Renaming/moving database
Changing existing column and
table names
Deleting tables and columns

Managing Universes (Contd.)

Detecting changes to database:
Choose View > Refresh

Structure
Changed tables are
highlighted in the Structure
A message on the screen
indicates that tables have
been deleted

66

Managing Universes (Contd.)

Effect of changes to existing objects:
Changes to existing Objects in a universe can have an impact on existing Documents

created from the universe.

No Impact:
Rede.ining Object SQL
Renaming an Object
Copying to different Class
Moving in same Class or to a
different Class
Adding new Objects

67

Impact:
Deleting an existing Object
Deleting and then recreating
an object with exactly the same
de.inition

Managing Universes (Contd.)

Adding new tables to universe
The workflow is:

Add tables to the universe structure

Insert joins and set cardinalities
Delete existing contexts
Detect aliases
Detect contexts
Create new objects
Set up hierarchies

68

Best Practices
1.

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.

2.

All objects should have help text or usage information corollary from above.

3.

Object formatting should preferably be done at the universe level.

4.

Pre-build condition objects in the universe rather than forcing users to build
conditions for reports.

5.

Build logic into objects translate code, common calculations etc rather than forcing
users to do it in report variables.

69

Best Practices (Contd.)

6.

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 are
included in the result set, due to combined restrictions imposed by the multiple
WHERE clauses.

7.

Use aggregation in all measure objects to push the aggregation to the database
wherever the performance bottleneck is likely to be BO server.

8.

All measure objects should include aggregation functions for projection. When this is
not included, BO will not automatically roll-up the data in the report, which could
result in incorrect data and analysis.

9.

Integrity checks on the universe structure, parsing of objects, joins, contexts,

detecting loops etc is mandatory.
70

Best Practices (Contd.)

10. Use aggregate tables /materialized views with aggregate awareness set up to improve
query performance.
11.

Turn off LOVs for all dimension and detail objects that are redundant or not required.

71

New Features
1.

Database Delegated : A new projection for measure objects which will roll-up data in
BO report. For e.g. average calculation.

2.

Optional Prompts : User can refresh report without entering value in optional
prompt.

3.

Mandatory Filters : Forcing predefined conditions/filters on the whole universe or on

a universe class.

72

Test Your Understanding

1.

What are the steps to create a universe?

2.

Define the different types of connection.

3.

What are the different types of objects?

4.

What is a loop and how do you resolve it?

5.

List the types of @Functions.

73

BO Designer: Summary
Designer is a BO component that is used to build universes. A universe is a semantic

layer between database and end users.

A universe consists of a set of objects, grouped by classes.
A connection is a link from the universe to the target database.
There are three types of connection:
Personal
Shared
Secured
The types of objects are:
Dimension
Detail
Measure

74

BO Designer: Summary (Contd.)

A join is a condition that restricts the result set of a query.
A loop is a set of joins that defines a closed path through a set of tables in a schema.
Loops can be resolved using Alias or Context.
A hierarchy is an ordered series of related dimensions.
@Functions can be used in object definition in the Select statement or Where clause.
A condition object is a predefined Where clause that can be inserted into the Select

statement inferred by objects in the Query pane.

75

BO Designer: Source
http://help.sap.com/businessobject/product_guides/
Business Objects XI Release 3 Designers Guide

76