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
Sales Revenue Sales Executive Customer Product Price Order Date ...

Human Resources

Employee Salary Bene.its...

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 Resort The following information is linked Available service lines, services for each service line, invoice information for each service and the country where the resort is situated. The city, region and country where the customer lives, the sales for the customer and the invoice information for each sale.

Customer

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 Reservations and Reservation_Line Sales and Invoice_Line Designer detects these contexts Reservation_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 Forced Description Restriction de.ined in the Where clause for an object. It cannot be accessed by users and so cannot be overridden in Web Intelligence. 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.

Optional

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:
Shows the names of the universes to which the active universe is linked.

Goto Edit-> Links. Click the Add Link button.

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

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

65

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

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

67

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. 3. 4.

All objects should have help text or usage information corollary from above. Object formatting should preferably be done at the universe level. 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. 2. 3. 4. 5.

What are the steps to create a universe? Define the different types of connection. What are the different types of objects? What is a loop and how do you resolve it? 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