Business Objects Designer

Purpose of this Course

To introduce and work with BusinessObjects Designer To introduce the key concepts and features of the Designer module. To learn how to design, create universes for full client Business Objects reporting

How The Course is Organized: Level 1

The Designer module Setting Parameters Populating the structure with tables Joins Creating and testing classes and objects Creating and testing measure objects Resolving loops in a universe Contexts and chasm and fan traps Using @ functions New Features in BO XI

What You Will Be Able To Do

Log in to the Designer module Be familiar with the Designer module and its commands Be able to manipulate the Universe Structure

Logging in to BusinessObjects Designer

Opens DESIGNER with the specific access rights of the user

Designer Module
Standard Toolbar Formula Bar Editing Toolbar

Objects and Classes

Structure

Setting Parameters
Create and save a .unv file in which you can build a universe Name a universe Create a Help description for the universe Set up a connection Be aware of other universe parameters

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

Creating a Universe
To begin creating a new universe: Select File, New To access the Universe Parameters dialog box for an existing universe:


Select File, Parameters

or


Click on

Setting up Parameters : Definition Tab

A universe is identified with a user name and a connection to the database A detailed description can also be added

What Is a 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 BusinessObjects connection

Different 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

Creating a New Connection

1. Click on New. 2. Choose the middleware

3. Identify the driver to be used to access the target database

Advanced Connection Properties

These options allow you to set up the session parameters and the connection mode ...

Saving a Universe
Save the universe using a maximum of eight characters with up to three characters as an extension This makes it possible to distribute the universe across different kinds of computers

Choose File, Save or click By default the universe is saved in the folder:
\\Documents and Setting \<User Name>\Application Data\BusinessObjects \BusinessObjects 11.0universe\<SystemName>\<Folder>

Universe Default Save Settings

You can change the default folder where universes are saved You can also set up Designer to automatically save at specified intervals

Choose Tools, Options:

Displaying Existing Connections

Access the Connections dialog box by selecting Tools, Connections All the available connections can be displayed, modified or removed with the Connections dialog box

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 Parameters:

Populating the Structure with Tables

Add tables to the Structure Move tables Know about different ways of viewing tables Be aware of how to optimize tables

Adding 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

Joins
Set equi-joins manually Delete and modify joins Set strategies for automated joins Be able to set outer, theta and self-restricting joins View joins in List Mode Set cardinalities

What do Joins Achieve in SQL?

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

Equi-Joins

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

Outer Joins

Creating Outer Joins

An outer join is created by converting an existing equi-join

Warning: Outer joins should ideally only be specified at the end of a table path. If specified in the middle of a table path all subsequent joins in the path will also have to be specified as outer.

Theta Join
A theta join contains an expression that is based on something other than equality:

Theta Join Theta Join Result Set:

Creating Theta Joins

A theta join is created by converting an existing equi-join

CTRL-CLICK

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.

Creating Self Restricting Join

Using List Mode

 

List Mode displays tables, joins and contexts It is possible to identify joins related to a specific table

Join Cardinalities

Cardinality: Shows the relationship between tables on the basis of the join Should only be one to many or one to one. It should never be many to many Is not needed to infer SQL in Business Objects Is only required to resolve loops and alternative routes in the Structure

Adding Cardinalities
Manually using the Edit Join dialog box

Automatically using

(but can take a long time)

Checking Integrity
Always check integrity after defining joins

Testing

REMEMBER: Once you have created the objects for your universe you must make extensive multi-relational queries to check that the joins are producing the SQL output correctly

Creating Classes and Objects

Organize the universe into classes and sub-classes

Create dimension and detail objects Understand and edit object properties Copy objects from one universe to another Test objects

Objects
Dimensions Projects columns from the database which are key to a query Details Projects columns from the database that provide detailed information related to a dimension Measures Contains aggregates to project statistics

Classes
Used to group related objects Used to provide subsets of related objects

39 Copyright 2002 Business Objects SA - All Rights Reserved

The Classes and Objects Window

Order of dimensions in a class hierarchically Details are attached to dimensions

40 Copyright 2002 Business Objects SA - All Rights Reserved

The Classes and Objects Window

Measures are grouped in a separate class Except where they can only be used with objects from a given class
41 Copyright 2002 Business Objects SA - All Rights Reserved

Creating and Editing Classes

Use to create a class

Use the Description field to provide information for users

42 Copyright 2002 Business Objects SA - All Rights Reserved

Creating a Sub-Class
Sub-classes allow a better organization of objects Avoid too many levels of sub-classes Use the Speedmenu on a class to create a sub-class

43 Copyright 2002 Business Objects SA - All Rights Reserved

Creating a Class from a Table

Use Drag and Drop This wizard will create one object for each field

44 Copyright 2002 Business Objects SA - All Rights Reserved

Creating an Object
Different Ways:
Manually with Drag and drop from a database column into a class Insert objects from another universe (copy and paste)

45 Copyright 2002 Business Objects SA - All Rights Reserved

Object Properties : The Definitions Tab

By default the type is the same type as used by the database Add a description to the object Inferred SQL for Select statement
46 Copyright 2002 Business Objects SA - All Rights Reserved

The Select and Where Edit Windows

Inferred SQL Pick Lists

47 Copyright 2002 Business Objects SA - All Rights Reserved

Object Properties : The Properties Tab

Define the type of object

Associate a List of Values for end users conditions if appropriate

48 Copyright 2002 Business Objects SA - All Rights Reserved

Object Properties : The Advanced Tab

Uncheck the Sort option

49 Copyright 2002 Business Objects SA - All Rights Reserved

Copying and Pasting Objects

You can

copy objects from one universe to another

Checking Integrity
Remember to check integrity after creating objects

51 Copyright 2002 Business Objects SA - All Rights Reserved

Testing Objects


While developing a universe, observe the following production cycle Modify Universe

Test Universe

Save Universe

Testing Objects in REPORTER

Perform as many tests as possible in REPORTER:
Check objects are displayed View the SQL for each object Run queries and check the results

53 Copyright 2002 Business Objects SA - All Rights Reserved

What is a Measure Object?

A measure object returns numeric information A measure object is created by using aggregate functions The five basic aggregate functions are: Sum  Count  Average  Maximum  Minimum

A Measure is Dynamic
Measure objects are semantically dynamic

How a Measure Works at Select Level (1)

How a Measure Works at Select Level (2)

Levels of Aggregation in Business Objects

Select Aggregation

Query Results database Aggregation Project

Aggregation at Projection Level

When projecting all variables in the microcube no aggregation takes place

When projecting only some variables from the microcube aggregation occurs

Measure Object Properties : Definitions

Data Type must be a number

Select must be an aggregate

Measure Object Properties : Properties

Object Type must be a measure Aggregate Function must be appropriate for the Select aggregate Measures should not have an Associated List of Values

Testing Measure Objects

There are three elements to testing a dimension or detail object : 1 Check objects exist. 2 Check inferred SQL. 3 Check query results. Measure objects need more thorough testing : 1 Check objects 2 Check inferred SQL. 5 Make a query with exist. a minimum of two 3. Check query results. dimensions and a 4. Repeat with other measure. dimensions. 6. Check projection with Slice & Dice.

Testing Measure Objects at Select Level

GROUP BY Country.country

GROUP BY Country.country, Region.Region_Name

Testing Measure Objects at Project Level

What is a loop?

A loop exists when the joins between tables form a continuous path

Cardinality Detection
Cardinality not set: Set Cardinalities:

Do this manually:

What is an Alias ?
An Alias is an exact duplicate of the original table with a new name. The data in the table is exactly the same. The Alias is used only to resolve the loop in the structure of the universe. There is no impact on the schema of the database
Easy to define Easy to maintain Easy to use

When to Alias
A loop with a single lookup table should be resolved by an alias A lookup table can be identified by its cardinality A lookup table only has the one end of joins attached to it
N N

1 N 1 N 1 1 1 N

Alias needed here

How to Alias
Designer routines detect loops and candidates for aliases Break the loop by creating an alias of the lookup table for each side of the loop Some designers like to create an alias for both sides of the loop.

Do not remove the original table

Detecting and Creating Aliases

To create an alias table to break a loop, you can: Use the Loop Detection routine

Use the Alias Detection routine

Manually insert an alias

Using automatic loop detection

Click the Detect Loops button The routine checks the structure for loops

The Loop Detection window identifies each loop The window suggests candidate contexts or aliases

Using Detect Aliases Routine

Click the Detect Aliases button

The routine lists candidate Alias tables You can rename the Alias tables if required

Inserting an Alias Manually

Select the table and click the Insert Alias button

Name the Alias table and click OK Then reset the joins manually

Resolving Loops using Contexts

Sales Sal Lines

Country

Customers

There are two possible routes through Loans Loans Lines the structure:
Rental_Model context Sale_Model context

A context is merely a collection of ALL the joins on a single route. Context name = table name on a route with only many cardinality.

Resolving Loops using Contexts

Rental_Model context A context is detected for each route on which there is a table with just many cardinality. Each context represents what may be inferred in a single SELECT statement. Any query which infers some SQL code exclusive to one context and some exclusive to the other will infer two separate SELECT statements

Sale_Model context

Display the contexts : View List Mode

Editing Contexts
Double click the context in the List Mode window

The context name The highlighted joins are included in the context The description appears in the User module Help panel

Sequence for resolving loops

1. Set cardinality on all joins (best to do this manually) 2. Use Detect Aliases to detect candidates for aliases 3. Insert all required alias tables and joins 4. Use Detect Contexts to detect candidates for contexts 5. Create the required contexts 6. Test in the User module

Shortcut Joins
If a query includes Client and Country but NOT Region, the Region joins are still needed in the SQL. Ineffecient! But joining Country to Client directly creates a loop

Shortcut Joins - the solution

Edit the join to create a Shortcut join:

This is not a Loop! Be aware of existing Contexts when you add the join: Shortcut joins are not automatically added

Recursive table structures

These occur when a table acts as a lookup for itself Each Employee has a Manager, who is also an Employee But adding a Self Join creates a single table loop where the cardinality is unknown These loops must be resolved manually

Recursive table structures - the solution

Create an Alias of the lookup table

Manually set the cardinality Test the results in the user module

Test the structure of a universe

Check the syntax

Test in the User Module

Chasm Trap and Fan Trap

What are Contexts

A context is simply a list of joins denoting a path between tables. Contexts are set to identify alternative routes in the universe structure. BusinessObjects detects a context for each alternative route on which there is a table with just the many end of joins attached to it. Contexts identify joins (and therefore tables) which are compatible within the same SELECT statement

Alternative Routes
Alternative routes do NOT only exist in loop scenarios.
Context 1

Loop
2 Routes = 2 Contexts

Context 2

Context 1

Fork
2 Routes = 2 Contexts

Context 2

How Contexts are Detected

A separate context is identified for each table with only the many end of joins attached:

The joins in a context are identified by working back from the table with only the many end of joins attached - many-one, many-one.

Identifying how many Contexts are required

 You can arrange your universe structure so that all joins are flowing from the many ends at the left to the one ends at the right.

Number of contexts required = 2

Identifying the joins that make up a Context

No joins flowing The forward flowing joins form the Sale context back from one to many are included

Why Apply Contexts

To avoid Chasm Traps
By detectiing and setting contexts you will avoid the possibility of experiencing a chasm trap. This assumes that you have engineered cardinality correctly before detecting contexts.

To resolve Fan Traps

You can also use contexts as part of the means to resolve fan traps. However, unlike chasm traps, you must identify them first before they can be resolved.

The Chasm Trap

For a Chasm Trap to occur, there must be:
When a query is run which uses objects Y and Z the inferred SQL includes tables B, C and A which have a many-one-many relationship respectively. This results in the values for each object to be multiplied by the other. The effect is similar to a cartesian product but is known as a chasm trap.

The chasm trap is resolved by executing a separate SELECT statement for object Y and object Z.

Chasm Trap Proof : Scenario

Step 2
a query with objects from each of the many tables

Step 1

many to one to many

Step 3
Deny Multiple SQL Statements for each measure

Multiple instances of a single dimension in results

Chasm Trap Proof : Effect

Test 1


Test 2


Test 3

Chasm Trap Proof : SQL

Test 1

The problem on test 3 arises because the processing of a single SELECT statement produces a single virtual logical table to Test 2 apply aggregation.

Test 3

Chasm Trap Proof : SQL Logical Table

Test 1 Test 3

Where you have a many-one-many relationship for tables in the FROM clause the resulting logical table produces something akin to a Cartesian Product. Only then is aggregation applied. This is the reason for the chasm effect.

Chasm Trap : Solution

How can we avoid the chasm trap?

By inferring two separate SELECT statements and only then combining the results of each one into microcube(s) for projection into block(s).

Chasm Trap : Universe Solutions

To infer two separate SELECT statements from a single BusinessObjects query you can either:1 Alter the SQL parameters for the Universe 2 Use Contexts The first method is NOT recommended as it only works with measures and will result in certain inefficiencies in processing. The second method works every time and will not result in inefficiencies.

Altering the Universe SQL Parameters

Click

Click

Check

The Chasm Trap query will now make one query for each measure and combine the results - correctly.

SQL Parameter Method : the Drawbacks

1) IN-ACCURATE The parameter only works for measures. It does NOT separate queries containing only dimension objects.

The report contains a single block with the results displayed as a Cartesian product - unclear for Users.

2) IN-EFFICIENT The parameter will force a SELECT statement for each measure, even when it is NOT necessary to do so!

Recommended Solution : Use Contexts

Apply a context to each leg of the Chasm Trap:

Recommended Solution : Use Contexts (2)

With the contexts in place, both measure object queries and dimension object queries display correctly:
Measures

Dimensions

Conclusion: Always use contexts to resolve Chasm Traps

The Classic Fan Trap

For a Fan Trap to occur, there must be:
X A
This is a common structure and will not normally result ina fan trap. The trap only occurs where (due to DB design) a column in table B holds data values which are already a sum of those values held at table C. When a query is run which uses objects Y and Z the inferred SQL includes tables B and C which have a one-many relationship. This results in a value for the Y object being multiplied by the number of values of the Z object related to that Y object value. Like the chasm trap, the effect is similar to a cartesian product.

Like the chasm trap, the fan trap can be resolved by executing a separate SELECT statement for object Y and object Z. The alternative solution is to avoid it in the first place!

Classic Fan Trap Proof : Scenario

For a Fan Trap to occur, there must be:
Step 2
a query with a measure object from the Sale & another from the Sale_Model table

Step 1

one to many to many

Multiple Sale_Model rows related to a single Sale row

Classic Fan Trap Proof : Effect

Test 1

Test 2

Classic Fan Trap Proof : SQL

Test 1

Test 2
The problem on test 2 arises because the processing of a single SELECT statement produces a single virtual logical table to apply aggregation.

Classic Fan Trap Proof : SQL Logical Table

Test 1 Test 2

Where you have a one-many-many relationship for tables in the FROM clause the resulting logical table produces something akin to a Cartesian Product. Only then is aggregation applied. This is the reason for the fan effect.

Classic Fan Trap : Solution

How can we avoid the fan trap? By inferring two separate SELECT statements and only then combining the results of each one into microcube(s) for projection into block(s). By avoiding the fan trap scenario in the first place!

Classic Fan Trap : Universe Solutions

To infer two separate SELECT statements from a single BusinessObjects query you can either:1 Alter the SQL parameters for the Universe 2 Use a combination of Aliases and Contexts
NOTE: The first method is NOT recommended as it only works with measures and will result in certain inefficiencies in processing. The second method works every time and will not result in inefficiencies.

To avoid placing a measure on anything other than the last table in a table path (i.e. the table with only many cardinality attached to it).

Altering the Universe SQL Parameters

Click

Click

Check

The Fan Trap query will now make one query for each measure and combine the results - correctly.

SQL Parameter Method - the Drawback

1) IN-ACCURATE The parameter only works when the object on the Sale_Model table is a measure. It may NOT separate queries where the object on the Sale_Model table is a dimension or detail object. 2) IN-EFFICIENT The parameter will force a SELECT statement for each measure, even when it is not necessary to do so!

Column from the Sale_Model table.

Recommended Solution 1: The Theory

Alias & Context Fan Trap Solution
X C A Ba

1) Create an Alias of Table B. 2) Create a join between the alias Ba and table A and set cardinality.

Ba

3) Set Contexts C and Ba. 4) Change the SELECT clause of object Y so that it refers to the alias Ba rather then table B.

Recommended Solution 1: ThePractice

Alias & Context Fan Trap Solution 1) Create an Alias of the Sale Table. 2) Create a join between the Sale alias & Client table and set cardinality. 3) Set Contexts. 4) Change the SELECT clause of the Sale Revenue object so that it refers to the Sale alias rather than the Sale table.

Recommended Solution 1: The Result

Now a query involving a measure and another object from a subsequent table in the table path of a universe structure. .results in 2 SELECT statements..

.which are then merged in a single microcube to produce the correct result.

Recommended Solution 2: The Theory

Avoiding a Fan Trap in the First Place
X A

1) This is only possible where the measure on table B is a preaggregation of more detailed data which exists in table C. 2) Code measure object Y so that it refers to the more detailed data in table C. NOTE : This will be less efficient but at least it is accurate.

Recommended Solution 2: The Practice

Avoiding a Fan Trap in the First Place
1) In the universe below the Sales Revenue measure is not based on the total figure in the Sales table but on a number of columns from the Sales, Sale_Model and Model tables which are held in the DB at the same level of granularity as the number of cars sold. Hence, no fan trap exists and the correct result will be obtained.

The @ Functions
The @ Functions available are:

These Functions are applied in the Select and Where boxes of objects They are used to provide flexible methods of specifying SQL

@Prompt
 @Prompt is placed in an object as part of the Select or Where properties

 When a query is run that includes the object, the @prompt of the object forces a prompt box to appear

@Prompt Syntax
SHOWROOM.SHOWROOM_NAME = @PROMPT Operator dependent on operand ( The prompt. Enter Showroom Name, Data Type (A, N or D)... A, LoV Pointer.... Showroom\Showroom, Or hardcoded list : {A,B,C} Mono or multi (LoV selection).. Mono, Free or constrained (to value in LoV).. Constrained )

@Select
 @Select function acts as a pointer to the Select box of another object: @Select (Class_Name\Object_Name)

 Creates a dynamic link between objects, so that update of the original object Select statement automatically updates the other objects

@Where
 The @Where function acts as a pointer to the Where box of another object

 Creates a dynamic link between objects, so that update of the original object Where clause automatically updates the other objects or condition objects

@Where - Designer Strategy

 You can create a Class containing only Where clause objects, and hide the Class from end Users - other objects use the Where clauses, but the Users dont see the base objects.

@Script
Allows use of a variable declared in a VBA script

The script smotors runs the country selection process

What is a List of Values?

A list of the distinct values from the column or columns to which the object refers A LoV is used on the operand side of a condition in the query panel of the User module

This is only available if set by the designer

How do Lists of Values work?

A designer can create a LoV which is based on: A query of the target database A constant set of values held in a file In both cases, the result is stored locally in a file on the User s PC.

Creating a List of Values

A LoV is created within the Properties tab of an object By default, Associate a List and Allow Users to edit are checked: It is important to uncheck this box for objects that dont need a List

Controlling How Lists are Refreshed

Normally, the first time a LoV is used in a User login session, the system fires a query at the target database. The results of this query are used to populate the list, and are stored in the .lov file. Thereafter, the .lov file from this query is used each time the List is required.

Controlling How Lists are Refreshed

Not normally used uncheck this box Check this box for frequently changing lists Check this box for edited lists

Modifying the Content of a List of Values

You can limit the values returned by applying a condition to the LoV You can simplify the process of choosing a value for Users by creating a hierarchy for the LoV You can supply a personal data file containing the values for the list, instead of using the results of the query

Applying a Condition to a List of Values

Click Edit in the Properties box: Apply the condition in the Query Panel:

Creating a Hierarchy for a List of Values

Click Edit in the Properties box: Place the hierarchy objects (which must be sorted) to the right of the LoV object in the Query Panel:

Creating a Hierarchy for a List of Values

The resulting Hierarchical View of the LoV makes it easier to select the required value: Country: Town: Showroom:

Basing a LoV on a Personal File

Select Tools, Lists of Values from the Menu bar:

Select the object:

Select Personal Data:

Basing a LoV on a Personal File

Click OK to acknowledge the message:

Specify the file that contains the values for the list and click OK