bo - designer

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

Objects and

Classes

Formula Bar

Standard Toolbar

Editing Toolbar

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

Insert Tables

Make the Joins

Resolve the Loops

Create Classes and Objects

Set up Hierarchies

Select File, Parameters

To begin creating a new universe:

• Select File, New

To access the Universe Parameters dialog box for an existing universe:

or

Click on

Creating a Universe

•A universe is identified with a user name and a connection to the database

•A detailed description can also be added

Setting up Parameters : Definition Tab

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

• PersonalCan only be used on the client

• SharedCan be used by more than one user to send queries to the target database from a shared server

• SecuredThis connection is used when you wish to distribute the completed universe to the user population via the repository

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

Creating a New Connection

2. Choose the middleware

1. Click on New.

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

Advanced Connection Properties

• Choose File, Save or click

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

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

• Access the Connections dialog box by selecting Tools, Connections

Displaying Existing 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

• 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

• Use the Table browser:• Double-click on the background of the

Structure

Joins

• Set equi-joins manually

• Delete and modify joins

• View joins in List Mode

• Set cardinalities

• Be able to set outer, theta and self-restricting joins

• Set strategies for automated joins

What do Joins Achieve in SQL?

Joins

A join is a condition that restricts the result set of a multi-relational query

• Equi-join (otherwise known as a standard or inner join)

There are several different kinds of join:

• Theta join

• Self restricting join

• Outer join

Equi-Joins

Automatic Join Detection

• The Strategy for automatic detection of joins is based on common column names between tables

• Smart Matching Column Names (no key info.)

• All Matching Column Names

• All Matching Numeric Column Names

• You can choose from one of three specific strategies for join detection:

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 Result Set:

Theta Join

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

List Mode displays tables, joins and contexts

Using List Mode

It is possible to identify joins related to a specific table

• Shows the relationship between tables on the basis of the join

Join Cardinalities

Cardinality:

• 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

• Automatically using (but can take a long time)

Adding Cardinalities

• Manually using the Edit Join dialog box

• Always check integrity after defining joins

Checking Integrity

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

DimensionsProjects columns from the database

which are keyto a queryDetailsProjects columns from the database

that provide detailed information related to a dimension

MeasuresContains aggregates to project

statistics

Classes

39 Copyright © 2002 Business Objects SA - All Rights Reserved

Used to group related objects

Used to provide subsets of related objects

The Classes and Objects Window


• Order of dimensions in a class hierarchically

• Details are attached to dimensions

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

• Use to create a class

• Use the Description field to provide information for users

Creating and Editing Classes


• 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

Creating a Sub-Class


Creating a Class from a Table

• Use Drag and Drop


• This wizard will create one object for each field

• Different Ways:• Manually with


• Drag and drop from a database column into a class

• Insert objects from another universe (copy and paste)

Creating an Object

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

The Select and Where Edit Windows


• Inferred SQL

• Pick Lists

Object Properties : The Properties Tab

• Define the type of

object


• Associate a List of

Values for end users’

conditions if

appropriate

Object Properties : The Advanced Tab

Uncheck the Sort option


• You can copy objects from one universe to another

Copying and Pasting Objects

• Remember to check integrity after creating objects

Checking Integrity


Testing Objects

While developing a universe, observe the following production cycle

Save UniverseTest Universe

Modify Universe

• Perform as many tests as possible in REPORTER:

Check objects are displayed

View the SQL for each object

Run queries and check the results

Testing Objects in REPORTER


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

Maximum

Average

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

database

Project

Query Results

Aggregation

Aggregation

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

• There are three elements to testing a dimension or detail object :

Testing Measure Objects

• Measure objects need more thorough testing :

1 Check objects exist.

2 Check inferred SQL.

3 Check query results.

1 Check objects exist. 2 Check inferred SQL.3. Check query results.4. Repeat with other dimensions.

5 Make a query with a minimum of two dimensions and a measure.6. Check projection with Slice & Dice.

GROUP BY Country.country

GROUP BY Country.country, Region.Region_Name

Testing Measure Objects at Select Level

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

N N

N

N

N

1 1

1

1

1

• A lookup table only has the ‘one’ end of joins attached to it

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

• Use the Alias Detection routine

• Manually insert an alias

• Use the Loop Detection routine

• To create an alias table to break a loop, you can:

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

Customers

Sales SalLines

Loans LoansLines

Country

There are two possible routes through the structure:

Sale_Model context

Rental_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

Sale_Model context

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

A context is detected for each route on which there is a table with just “many” cardinality.

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.

• But joining Country to Client directly creates a loop

• Ineffecient!

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.

• Loop2 Routes = 2 Contexts

Context 1

Context 2

• Fork

Context 1

Context 2

2 Routes = 2 Contexts

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• The forward flowing joins form the Sale context• No joins flowing

back from one to many are included

Why Apply Contexts

• To resolve Fan Traps

• To avoid Chasm 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.

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.

The Chasm Trap

• For a Chasm Trap to occur, there must be:

A

B C

X

Y Z

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

Multiple instances of a single dimension in results

a query with objects from each of the ‘many’ tables

Step 2 Step 1

Deny Multiple SQL Statements for each measure

Step 3

‘many to one to many’

Chasm Trap Proof : Effect

Test 1

Test 2

Test 3

Chasm Trap Proof : SQL

Test 1

Test 2

Test 3

The problem on test 3 arises because the processing of a single SELECT statement produces a single virtual logical table to

apply aggregation.

Chasm Trap Proof : SQL Logical TableTest 3Test 1

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

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.

• To infer two separate SELECT statements from a single BusinessObjects query you can either:-

Altering the Universe SQL Parameters

• Click

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

• Check

• Click

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:

• Conclusion: Always use contexts to resolve Chasm Traps

Measures

Dimensions

The Classic Fan Trap

• For a Fan Trap to occur, there must be:

X

Y

Z

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!

A

B

C

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.

Classic Fan Trap Proof : Scenario

• For a Fan Trap to occur, there must be:

Step 1

‘one to many to many’

a query with a measure object from the Sale & another from the Sale_Model table

Step 2

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

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.

Test 1 Test 2

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

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 infer two separate SELECT statements from a single BusinessObjects query you can either:-

• 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

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

• Check

• Click

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.

Column from the Sale_Model table.

2) IN-EFFICIENT

The parameter will force a SELECT statement for each measure, even when it is not necessary to do so!

3) Set Contexts C and Ba.

BaC

Recommended Solution 1: The Theory

X

Y

Z

A

B

C

1) Create an Alias of Table B.

Ba

2) Create a join between the alias Ba and table A and set cardinality.

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

Y

Alias & Context Fan Trap Solution

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

X

Y

Z

A

B

C

1) This is only possible where the measure on table B is a pre-aggregation of more detailed data which exists in table C.

Avoiding a Fan Trap in the First Place

2) Code measure object Y so that it refers to the more detailed data in table C.

YNOTE : This will be less efficient but at least it is accurate.

Recommended Solution 2: The Practice

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.

Avoiding a Fan Trap in the First Place

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

Free or constrained (to value in LoV).. Constrained

‘Enter Showroom Name’,The prompt……………………………….

‘A’,Data Type (A, N or D)..………………….

‘Showroom\Showroom’,LoV Pointer..……………………………..

Or hardcoded list : {‘A’,‘B’,‘C’}

Mono,Mono or multi (LoV selection)………..

(

)

Operator dependent on operand

@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 don’t 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 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

• A list of the distinct values from the column or

columns to which the object refers

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

don’t 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