BO XI Designer RC

Universe Design XI
Module 1: Introduction to Designing Universes
What You Will Be Able To Do
Understand the role of a Designer
Know what is meant by the Semantic Layer
Know more about the way BusinessObjects

generates SQL
Be familiar with the different types of database

schemas you can use
Discover the recommended universe development

process
Know what is meant by the 80/20 concept
2 Business Object XI R3 Designer
Extracting Information from a Database
Many different attempts have been made to resolve

issues surrounding reporting:
The Bureau Approach:
Developers
SQL
End Users
The SQL Education

Approach:
Developers
SQL
End Users
The BusinessObjects Solution

Corporate Database
Database and Security
Design
Information accessed
via a semantic layer
Sales
Universe Design
Designer
Stock
Finance
End Users
IS Needs
End-User Needs
Security and control
Ease of use
Maintainability
Reliability
Cost-effective set-up
Integrated reporting and
Enterprise-wide
analysis tools
interoperability
Advantages of Using BusinessObjects
Business
Knowledge
Users can access data in an easy

way using their own terminology
Users can make queries without

knowing SQL
Users can analyze data locally
The organization has a shared

business content
Advantages of Using BusinessObjects

BusinessObjects allows the user to access data from
different sources using a single tool
Specific
OLTP
OLAP
Servers
Data Mart/
Warehouse
Personal
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
Benefits...
Sales Revenue
Sales Executive
Customer
Product
Price
Order Date ...
Generating SQL using Desktop

Intelligence
Generating SQL Using Desktop

Intelligence

Intelligence

Intelligence
Tables to be included in the From clause and Joins to be included in

the Where clause of a Select statement are inferred via.

Intelligence
Generating SQL using Desktop

Intelligence
Normalized
Aggregate
Tables
Production
Schema
Star
Schema
Snowflake
Data
Warehouses
Multiple
Stars
Using the Designer Module

Graphic Conception
Drag and Drop

Intuitive Editor
Quick Design wizard

Automatic Import of
Meta Data
The Universe Development Process (1)

Prepare
Know the data
source
Analyze
Identify the needs
of the end user
population
Plan
Design the
universe(s)
HR on
Sybase
Financials
on Oracle
The Universe Development Process (2)

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
Universe Development Process
80
20
Involve users in all the

steps of the project
The Universe Development Process
Implementation Sub Process:
Create Universe file & set parameters

Create Structure
Add tables > create joins > check integrity >
sort loops and other problems as required
Test
Create and categorize objects.

Sort default / create custom hierarchies
Create Condition Objects 5. (2,3,4)
What You Have Learned
The advantages of using BusinessObjects

The role of a universe Designer
How BusinessObjects generates SQL
The types of data source which BusinessObjects can
interrogate
The recommended design process
Universe Design XI
Module 2: The Designer Module
Log in to the Designer module
Be familiar with the Designer module and its

commands
Be able to manipulate the Universe Structure
Business Objects Designer
Logging in to BusinessObjects Designer
Opens DESIGNER
with the specific
access rights of the
user.
23
Designer Module
Standard Toolbar
Formu
la Bar
Editing
Toolba
r
Objects
and
Classes
Structure
24
How to log in to the Designer module
What the Designer windows look like
How to manipulate the universe structure
Universe Design XI
Module 3: 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 ...
Custom Connection Properties
Summary of all connection parameters
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:
c:\Program Files\Business Objects\BusinessObjects 5.0\universe
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
Setting up Parameters : Summary Tab
The Summary tab displays general information about

the universe
Setting up Parameters : Strategies Tab

Provides automated
strategies for:
Creating objects
Setting joins
The Table browser
listing
Setting up Parameters : Controls Tab
These allow you to limit

the size of results and
restrict the time allowed
for executing queries
The Supervisor
can change these
parameters for
specific groups or
users
Setting up Parameters : SQL Tab
SQL parameters
are used to define
the limits of the
SQL that may be
generated by the
universe
The Supervisor
can change these
parameters for
specific groups
and users
Setting up Parameters : Links Tab
Enables
dynamic links
with other
universes
The two compulsory parameters to begin creating a

universe are :
A user name
A connection to the database
A universe is connected to a single database

There are many parameters that you will learn more
about later in the course
The Supervisor can modify some parameters for
specific groups and users
Universe Design XI
Module 4: 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
Organizing Your Tables
A lot of options allow a better view of the tables:
Use drag and drop to move the tables around the Structure
Click on
to arrange the tables to fit in the window
Click on
and
Use the View, Change Table Display option
Use the Speedmenu on a table or row
to zoom in and out
Customizing Table Insertion
Select Tools, Options then click on the Database tab
From here you can select and

deselect options related to
table insertion
You can set internal
strategies
to:
automatically extract joins

detect cardinalities
create objects when
inserting tables
Universe Design XI
Module 5: 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
Creating and Deleting Inner Joins

Manually
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
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 equijoin

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
Beware!
Testing
REMEMBER: Once you have created the objects for

your universe you must make extensive multirelational queries to check that the joins are
producing the SQL output intended
How to set different types of joins taking into account

users needs and technical constraints
How to set cardinalities
To always check integrity after defining joins and

cardinalities
Universe Design XI
Module 6: Creating and Testing 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
An object is the most refined component in a
universe. It maps to data or a derivation of data in the
database.
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
A class is a logical grouping of
objects within a universe. In
general, the name of a class
reflects a business concept that
conveys the category or type of
objects.
A class can be further divided into
subclasses.
As designer, you are free to define
hierarchies of classes and
subclasses into a model that best
reflects the business concepts of
your company.
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
Creating and Editing Classes
Use
to
create a class
Use the
Description field
to provide
information for
users
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
Creating a Class from a Table
Use Drag and Drop
This wizard will create one object for each field
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)
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
Copying and Pasting Objects

You can
copy objects
from one
universe to
another
Find and Replace

You can use the Find
function to locate
character strings in
objects and there
definitions
You can also use the
Find function in
conjunction with the
Replace function to
edit strings
Checking Integrity
Remember to check integrity after creating objects
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
Organizing the universe into classes and sub-classes

to reflect the business usage
Creating classes and sub classes
Create objects manually and automatically
Creating dimension and detail objects
Understanding and editing object properties
Copying objects from one universe to another
Testing objects
Universe Design XI
Module 7: Creating and Testing Measure Objects
Understand what a measure object is
Create measure objects
Know how to test measure objects
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
Setting Select / Projection Aggregates
Statistically, only certain select / project aggregates

are compatible.
Select Aggregate
Project
Recommended
Aggregate
Sum
Sum
Count
Sum
Average
recommended)
None or Average (not
Maximum
Maximum
Minimum
Minimum
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
Viewing Object Parent Table(s)
You can view the parent tables of an object by rightclicking on an object and selecting the View Associated
Table option
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
5 Make a query
exist.
with a
SQL.
minimum of
3. Check query
two dimensions
results.
and a measure.
4. Repeat with
6. Check
other
projection with
dimensions.
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
An Aggregation Problem
The Group By clause groups each distinct dimension attribute and
produces a single measure value for that group. If you are not careful
when creating a query with dimensions and measures, this can result
in misleading information.
A measure always has an SQL aggregate function in

the Select statement
A projection function can be associated with a

measure to ensure local aggregation in the microcube
Extensive testing of measure objects is required
Universe Design XI
Module 8: Resolving Loops in a Universe
Define what a Loop is
Detect and recognize loops in a universe
Use Designer tools to resolve loops using Aliases and

Contexts
Identify when in the design process you resolve loops
Be able to use Shortcut joins and know when to use

them as an alternative for resolving loops
Be able to resolve recursive table structure loops
What is a loop?
A loop exists when the joins between tables form a continuous path
How to deal with loops

One of two routines can be used to resolve most loop
situations in the universe structure window.
Set Cardinality
Manually for All Joins
Alias Detection
Routine
...and...
Must be done prior to

using detection
routines and done
correctly. Otherwise,
routines may
recommend incorrect
solution.
Context
Detection
Routine
Cardinality Detection
Cardinality
Set
Cardinalities:
not set:
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
1
N
N
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
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
Choosing which Alias Method to Use

Method
Advantages
Disadvantages
Detect Loops
Can view loops before

applying them
May show other loops to

be resolved by contexts
Detect Aliases
Finds all candidate

aliases exclusively
No visual check prior to

acceptance
Insert Alias
Choose table to alias minimizing object

redefinition
Must understand how to

identify the need for a
candidate analysis
Whichever method you choose, you must always

redefine objects that now use the Alias table
Listing & Renaming Aliases

You can list all aliases in a universe via the Tools >
List of Aliases. Drop down menu option.
You can also rename an alias via this panel.
Aliases : Tidying Up Loose Ends
A single object query specifying either the Country of

Client, Showroom or Maker will include all countries
(Client, Showroom and Car Maker countries).
To avoid this you can force a join to the sub-sequent

table (client, showroom or maker) and thereby force
the query to restrict its output to the relevant
countries for that object.
Forcing Additional Joins
You can restrict the data that is returned for an object

by specifying additional tables in the object properties.
You do this in the

Tables box
Select the relevant

table:
The restriction is created

from the joins between
the tables
Only when this is done for each object relating to a multilookup table will they return the correct results if used in a
single object query
Using Aliases in a Multi Star situation?
Normalized dimensions are not amenable to loop

resolution using Aliases
Candidates for Aliases
If you try to resolve the loop using Aliases:
All candidates for

there Aliases
is still a loop
and you get duplication of objects
The effective result is two universes:
Sales
Universe
Rentals
Universe
Resolving Loops using Contexts

Sales
Country
Sal
Lines
Customers
There are twoLoans

possible routesLoans
Lines
through 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
Sale_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
Detecting and Creating Contexts
Loop Detection routine: suggests

candidates for both aliases and contexts
Detect Contexts detects and

proposes a list of contexts to create
Insert Contexts inserts a context

manually
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
Loop Detection routine - the drawback
When you use Loop Detection and detect a number of

loops:
Loop 1 of 10
The routine does not offer the Alias candidates first,

so you may have to update the Contexts after you
have added the Alias tables
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
What a Loop is
How and when to resolve a loop using aliases and

contexts
The sequence for resolving loops
How to apply shortcut joins
How to resolve a self-join
Universe Design XI
Module 9: Contexts, Chasm & Fan Traps
Understand the purpose of using contexts in a

universe
Recognize and be able to resolve Chasm Traps
Recognize and be able to resolve Fan Traps
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 manyend 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.
2) IN-EFFICIENT
The parameter will
force a SELECT
statement for each
measure, even when
it is NOT necessary
to do so!
The report contains a single block

with the results displayed as a
Cartesian product - unclear for
Users.
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
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
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
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.
What contexts are used for in a Universe
How to recognize and resolve a Chasm Trap
How to recognize and resolve the classic Fan Trap
Universe Design XI
Module 10: Restrictions
Be able to apply restrictions to objects
Be able to create condition objects
Be able to apply restrictions to tables
Be able to restrict objects using additional joins
Know when it is appropriate to use each of these

techniques
Universe Design XI
Module 11: Using @ Functions
How The Course is Organized: Day 2

8. Resolving Loops in a Universe
9. Restrictions
10. Using @ Functions
11. Lists of Values
12. Hierarchies
Know what @ Functions are available
Know what @ Functions do
Be able to apply them
Note: @AggregateAware is covered later in the course
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.
@Variable - with Personal Files
The @Variable function can be used in conjunction with

a text file to define User-specific conditions in an object:
C:\BusinessObjects\Busobj.exe -vars Bovars.txt
COUNTRY = JAPAN
@Variable - with Personal Files:

Drawbacks
Requires localized administration of the text file by the

Designer / Supervisor
The command string must be changed on every

User s PC to include the -vars <textfile.txt> argument
Security can be a problem, as a text file on a PC is

open to local amendment
Conclusion: Better to use the options in the

Supervisor module
@Variable - with BusinessObjects

Variables
The @Variable function can also be used with the

BusinessObjects variables to define User-specific
conditions in an object:
BOUSER
BOPASS
Where clause:
Employees.Employee_Name = @Variable(BOUSER)
Restricts data returned to that relating to the Users login name
@Script
Allows use of a variable declared in a VBA script
The script smotors runs the country selection process
What @ functions are available
What each @ functions does
How to apply @ functions to enhance the flexibility of

a universe
How Data is Restricted
The Where clause in an SQL statement restricts the

number of rows returned in the result set:
WHERE
... join definitions ...
WHERE
... join definitions ...
AND Country=United Kingdom
Methods of Restricting Data in

BusinessObjects
Designers and Users are able to influence the SQL

Where clause in different ways:
Designers:
Where clause in objects:
Users:
Creating a
condition object:
Additional Join
Information:
Self-Restricting Joins:
Using a condition
object:
Filtering a report:
Defining a condition:
Restricting Objects
Adding a restriction to an object allows you to give a

more precise definition:
Restricting Objects: the Drawbacks
You have to add a new object for each separate

restriction.
Multiple objects prevent you from building logical
default hierarchies.
The restrictions are not obvious to the end user.
If a combination of similarly restricted objects is

included in a query, no results are produced because
the conditions conflict:
For
example:
The User expects data for both French and

German clients, but gets no results, because
no client is both French and German
Restricting Objects: Advantages
The one advantage of applying restrictions to objects

is that the User is automatically forced to apply the
restriction - no choice.
This assists with ease of use.
On balance, it is better to avoid applying restrictions to

an object unless this is absolutely necessary.
Restricting Objects - a Workaround
If you apply restrictions to objects for Sales Revenue

1998 and 1999:
These drawbacks apply: multiple objects, conflicting

restrictions.
Restricting Objects - a Workaround
Use conditional Select clauses rather than restrictions

on objects:
Multiple objects, but no conflicting restrictions

Condition Objects
Useful for complex conditions and for frequently used

conditions
Better than applying restrictions to Objects because

the User can choose to add the condition
No multiple objects
Condition objects do not change the User view of the

Dimension objects in the Classes and Objects window
Condition Objects
Select Condition Object View
Insert a Condition Object
Condition object name
Description
Where clause
Applying Restrictions to Tables
If a table in your database has a flag which it uses to

switch between 2 or more domains, you can apply a
restriction to the table using a Self Restricting Join
The Advantage of using Table

Restrictions
The restriction is applied whenever the table is inferred

in the SQL, irrespective of where in the SQL statement
the table is inferred.
For example, if the table only appears in the FROM

clause, the restriction still applies in the WHERE
clause.
Multi Purpose Lookup Tables
A query Which countries do our clients come from?

may also include countries that are Showroom
countries or Car Maker countries.
Additional Joins
You can restrict the data that is returned for an object

by specifying additional tables in the object properties.
You do this in the

Tables box
Select the relevant

table:
The restriction is created

from the joins between
the tables
When to Use each Restriction Method
Apply Restrictions to Objects when you need to force

a restriction which is not automatically inferred
whenever the table is included in the SQL.
Use Condition Objects when you want to assist the

end users by predefining optional conditions.
Use Table Restrictions (Self-Restricting Joins) when

you want the restriction to be applied whenever the
table is inferred in the SQL.
Use Additional Joins when a lookup table serves more

than one purpose in the universe.
How to use conditional Select statements rather than

restrictions on objects
How to use predefined Condition Objects to provide

optional restrictions for end users
How to use Self-Restricting Joins to put restrictions

directly on a table in the Universe Structure
How to restrict objects using Additional Joins
When to use each of these methods
Universe Design XI
Module 12: List of Values
Associate or remove a List of Values (LoV) for an

object
Control how LoVs are refreshed
Modify a LoV using a condition
Modify a LoV by creating a hierarchy
Base a LoV on a personal file
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
How to associate or remove a LoV for an object
Controlling how LoVs are refreshed
How to modify a LoV using a condition
How to modify a LoV by creating a hierarchy
How to base a LoV on a personal file
Universe Design XI
Module 13: Hierarchies
Organize Default Hierarchies for optimum usability
Create Custom Hierarchies
Create Time Dimension objects and Hierarchies
Test Hierarchies in the User module
What Is a Hierarchy?
Level in Hierarchy
Data Returned
U.K.
North
Liverpool Manchester Newcastle
South
London Southampton Bristol
What Is a Default Hierarchy?
A Default Hierarchy is the hierarchy based on the

order of the Objects within the Class
Default Hierarchies are

represented in the User
module by the order in which
Dimension Objects are
organized in the Classes and
Objects box of the Query
Panel
The Key to Creating Default Hierarchies
The designer must ensure, wherever possible, that

Dimension Objects are organized from the most
general to the most specific within the Class
How are Hierarchies used in Analysis?
Dimension Objects represent the levels in a hierarchy:
Top Level
Level 1
Level 2
Level 3
A Measure can be analyzed at each level
What Is A Custom Hierarchy?
A Custom Hierarchy combines Objects from Default

Hierarchies to build a Custom Analysis Path
Custom Hierarchy
Default Hierarchies
Creating Custom Hierarchies
(or Tools,
Hierarchies)
Add Objects from Default Hierarchies to build a new

Custom Hierarchy
The Effect of Custom on Default

Hierarchies
User module Scope of Analysis after a Custom

Hierarchy has been created:
No Default Hierarchies are shown
The Effect of Custom on Default

Hierarchies
Selected Default Hierarchies can be added to the

Custom Hierarchies in Designer module
Why Is Time A Special Case?
Sale Date
25/11/07
Day
Month
Quarter
Year
Creating Time Hierarchies
Automatic Time Hierarchies
Using Database Functions
Table Based Time Hierarchies
How to organize Default Hierarchies for optimum

usability
How to create Custom Hierarchies
How to create Date objects and Automatic Time

Hierarchies
How to test Hierarchies in the User module
Universe Design XI
Module 14: Aggregate Awareness
Understand the reasons for using Aggregate

Awareness
Know when to apply Aggregate Awareness
Be able to apply Aggregate Awareness
What is Aggregate Awareness
Some databases have Summary Tables which contain

figures aggregated to a high level.
These are used to speed up queries which contain

statistics (for example, Revenue) reported at, for
instance, year rather than event level.
Aggregate Awareness is the BusinessObjects

process by which these higher level aggregates are
incorporated into a universe.
Summary Tables
Check the columns in the Summary Table:
Foreign Key columns

are used for the joins
The other columns relate

to objects that require
@AggregateAware
definitions
Note that Summary Tables without Foreign Keys do

not need joins - they can be free floating tables.
How Summary Tables are used in SQL
Aggregates of a normalized database are based on event / fact level

data.
Model
Sale
Sale_Model
226 rows
233 rows
33 rows
Sales Revenue = sum(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *

((100 - SALE.SALE_SALE_DISCOUNT) / 100))
Summary tables may be added to a database which hold data at a

higher level of aggregate.
Annual_Figures
26 rows
Sales Revenue = sum(ANNUAL_FIGURES.ANNUAL_SALE_VALUE)
Making use of summary table data speeds up response times.
Procedure for Applying Aggregate Awareness

1 Insert the Summary Table(s) in the universe structure;
set joins and cardinality
2 Set the contexts

3 Redefine objects using @AggregateAware
4 Define incompatible objects using Aggregate
Navigation
Step 1: Inserting a Summary Table & Setting

Joins
Set the joins and the

cardinality
Add the Summary Table to the structure
Step 2: Detecting Contexts
The
Annual_Figures
Set the
contexts
context
Step 3: Redefining Objects
Edit the objects affected by the Summary Table.
@AggregateAware Syntax:
@AggregateAware(Definition1,Definition2,,DefinitionN)
From the most to the least Aggregated

The last definition must be valid for all the queries
Step 4: Incompatible Objects
Aggregate aware objects can only be compatible with objects derived

from tables in the same context as the summary table
Incompatible objects are specified using Aggregate Navigation
Step 4: Aggregate Navigation
The Aggregate Navigation box is opened from the

Tools menu
Check
object for
Selecteach
the Summary
compatibility
against the
Table:
context and the select of
the object .
Individual objects are
checked to define them
as incompatible
Testing Aggregate Awareness
As with any universe element, you must always test

the results in the User module.
Run queries using the aggregated measures from the

Summary Table.
Use both compatible objects and incompatible

objects in different queries to make sure all levels of
Aggregate Awareness are operating correctly.
Aggregate Awareness as Preferential

Coding
The aggregate awareness functionality in

BusinessObjects can be viewed simply as a method
of specifying preferential or conditional coding.
When viewed from this perspective you can begin to

see the true potential of aggregate awareness
functionality within the Designer module.
Aggregate awareness functionality can be used for

purposes other than taking into account summary
tables to improve the efficiency of a universe.
Using Agg. Awareness to resolve a Fan

Trap
Fan traps are generally resolved using the alias and

context method explored in the Contexts, Chasm &
Fan Traps section of this course. However, there is a
scenario where aliases and contexts alone will not
resolve the issue satisfactorilly due to efficiency
issues.
The Fan Trap Issue

The Fan Trap Scenario
Unlike the classic fan trap this
structure only involves two tables,
instead Xof three.
A
Y
The Efficiency Issue

Whilst this standard fan tarp
solution resolves the fan trap
issue should objects Y and Z are
used in the same query, if a query
involves only objects X and Y no
trapObject
exists
yet table A will
246fan
Business
XI R3and
Designer
still be processed twice (once as
The Standard Fan Trap

Solution
Using the standard method of
resolving a fan trap we would
have to alias table A, create a
join from the alias An to table
A and set cardinalities, set
contexts B and An; edit object
YB
so thatAn
it refers to columns
in the alias
X An rather then
A
An
table A.
Recommended Solution
1) Create an Alias of Table A.
B
An
X
Y
An
2) Create a join between the alias

An and table A and set
cardinality.
3) Set Contexts An and B.
4) Make the Y object

@aggregateaware (first choice
referring to table A and then the
@aggregateaware(sum(tableA.column),
alais An).
sum(tableAn.column))
5) Make the Z object incompatible
with table A.
Z
Aggregate awareness has been used to resolve an

issue other than one involving levels of aggregation.
Summary Tables containing aggregate values will denormalize the structure, but will speed up queries.
As the designer, you must make BusinessObjects

aware of the correct level of aggregation to use.
It is important that you follow the procedure in the

correct sequence:
1
2
3
4
Add the ST, set joins and cardinalities.

Set the contexts.
Apply @AggregateAware to affected objects.
Set Aggregate Navigation.
Aggregate awareness functionality can also be used

to resolve issues other than that for which it was
originally intended.
Universe Design XI
Module 15: Documenting, Distributing &
Maintaining a Universe
Print information about the universe
Understand the Universe Distribution Process
Be able to export a universe to the Repository
Know how changes to the target database affect a

universe
Know how changes to objects will affect existing end

user reports
250 Copyright 2007 Business Objects SA - All Rights Reserved
Issue 23, August 2007
Documenting a Universe
Select the Tools, Options menu then click on the Print

tab to select what to print
Select the File, Print menu to print
Universe Design Cycle

Phase 3
Phase 1-2
Phase 4
Phase 5
Phase 7
Phase 6
Tthere are two types of distribution: small and large scale
Small Scale Universe Distribution

Small Scale Distribution
User Effort
Send .unv via E-Mail
Copy to Server and advise users to change the

default path for universes in BusinessObjects
Small & Large Scale Distribution
Insecure
Secure
Export to Repository and leave the Supervisor to

distribute
Scalable
Controlled
Unsecured Distribution
Work Group Mode
Via E-Mail
1) Load .unv
S:\Test
S:\Designer
File server
Access controlled
By network security
Save for All Users
Business Objects
Universe
(Shared Connection)
2) Create
Middleware
Driver
Create
Middlewar
e
Driver
Motors2k.unv
Business Objects
Universe
(Personal
Connection)
Motors2k.unv
Enterprise Distribution (Secured)

Full Client
Webi server
Business Objects
Universe
Universe Domain Name
Motors2k.unv
.unv flags
checked
when used
BusinessObjects
repository
Export
Flags created /
incremented
Business Objects
Universe
(Secured Connection)
Supervisor in control
User based security
allocated to user groups
Universe
Motors2k.unv
Domain Name
Motors2k.unv
Exporting a Universe
The Designer exports a universe to the universe domain and allocates

universe access to one of the groups of users he or she belongs to
Repository
Universe Domain
Document Domain
Security Domain
Designer
The flags attached to the universe are incremental. This guarantees the user
will use the most recent version of the universe
Full Client Query Process

Universe Designer
\ BusinessObjects\Business
Objects 5.0\LocData
Full Client User

.lsi
Repository
.unv
.unv
BOMain.key
.unv
\BusinessObjects \Business Objects 5.0\Universe \<Universe

Domain Name>
SQL
Database
.rep
Thin Client Query Process

Universe Designer
Repository
.unv
.unv
Thin Client user
WebI Server
HTTP
Bomain.key
.unv
<Profile>.lsi
Program Files\Business
Objects\BussinessObjects
5.0\Universe\<Universe Domain Name>
\Program Files\BusinessObjects\Business
Objects
5.0\Locdata
SQL
\Program Files\BusinessObjects\Business
Objects 5.0\Temp\sessions\EN.
.html
Database
.html
Reasons 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!
Changes to the Target Database

The implications of modifying the underlying
database for BusinessObjects universes varies in
severity:
Minimal Impact:
Adding new columns
Adding new tables
Greater Impact:
Renaming/moving database
Changing existing column
and table names
Deleting tables and columns
Detecting Changes to the Universe

Choose View, Refresh Structure
Changed tables are highlighted
in the Structure
A message on the screen
indicates that tables have been
deleted
The Effect of Changing Objects
Changes to existing Objects in a Universe can have

an impact on existing Documents created from the
Universe:
Minimal Impact:
Redefining Object SQL
Renaming an Object
Copying to different Class
Moving in same Class or to
a different Class
Adding new Objects
Greater Impact:
Deleting an existing
Object
Deleting and then
recreating an object with
exactly the same
definition
Adding New Tables to an Existing

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
How to print information about a universe
Understand the Universe Distribution Process
How to export a universe to the Repository
How changes to the target database affect a universe
How changes to objects will affect existing end user

reports
Universe Design XI
Module 16: Linking Universes
Know when it might be appropriate to consider linking

one universe to another
Be able to link universes
Be able to include universes
Linking Universes
Within a universe (B) it is possible to dynamically link to another
universe (A).
Universe
A
Universe A
Universe B
This has the effect of making it appear as though the classes,

objects and structure of universe A are part of universe B.
However, they are just a lookup (signified by the fact they are
greyed out) to universe A and can not be edited in universe B.
Why Link Universes : The Kernel

Approach
One possible reason for linking universes is where you have a

number of universes, each of which contains the same core set
of objects. By creating each universe as a separate entity you
are effectively coding the same objects several times over. By
linking you could avoid this.
Edit objects/structure in
Holds core
objects
Kernel A
Universe
A
Derived B
Kernel universe and changes

are automatically reflected
in the Derived universes B
and C.
Universe
A
Derived C
Linking Universes : Things to Watch

Out For
You can only link to a universe if that universe has been

exported to the repository first.
The linked structure will have to be joined to the native structure

of the derived universe to avoid Cartesian products.
Linking only links in classes, objects and structure from one

universe to another. It does not link contexts. The contexts of
the derived universe will have to be altered to accommodate the
linked tables joins.
Only ever contemplate linking universes which are part of the

same universe domain in the BusinessObjects repository and
will remain so.
You can only use one level of linking.
Making a Link
Click
and click on the Links tab

Click Add Link...
Choose universe to
link and click Open
The Derived Universe
The linked universe structure and objects cannot be edited in the

derived universe
The linked universe should be treated as though they were new
tables inserted in the derived universe. The same procedure
should be applied (i.e.insert new joins and edit contexts).
Why Link Universes : Include (Copy)
Another possible reason for linking universes is that you wish to

copy all the classes, objects and structure from one universe to
another. You could do this by first linking from universe B to A
and then use the Include function to sever the link thus making
the classes, objects and structure of universe A part of universe
B. In effect this is a way of quickly copying everything in one
universe to another,
Universe
A
Include
LINK
Universe A
Universe B
Included Universes
Included universes become part of the new universe
Designers must be aware of changes to the

underlying databases and the implications these have
for their universes
Linking universes can make maintenance easier
There are several different approaches to linking
universes
You can also include universes
Questions ?

BO XI Designer RC

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BO XI Designer RC

Hochgeladen von

Copyright:

Verfügbare Formate

Universe Design XI

Module 1: Introduction to Designing Universes

What You Will Be Able To Do

Understand the role of a Designer

Know what is meant by the Semantic Layer

Know more about the way BusinessObjects

Be familiar with the different types of database

Discover the recommended universe development

Know what is meant by the 80/20 concept

2 Business Object XI R3 Designer

Extracting Information from a Database

Many different attempts have been made to resolve

The SQL Education

The BusinessObjects Solution

Advantages of Using BusinessObjects

5 Business Object XI R3 Designer

Users can access data in an easy

Users can make queries without

Users can analyze data locally

The organization has a shared

Advantages of Using BusinessObjects

6 Business Object XI R3 Designer

The Semantic Layer

The semantic layer may consist of one or more

Each universe is a partial representation of a database, in the

7 Business Object XI R3 Designer

Generating SQL using Desktop

8 Business Object XI R3 Designer

Generating SQL Using Desktop

9 Business Object XI R3 Designer

Generating SQL Using Desktop

10 Business Object XI R3 Designer

Generating SQL Using Desktop

Tables to be included in the From clause and Joins to be included in

11 Business Object XI R3 Designer

Generating SQL Using Desktop

12 Business Object XI R3 Designer

Generating SQL using Desktop

13 Business Object XI R3 Designer

Using the Designer Module

Drag and Drop

Quick Design wizard

14 Business Object XI R3 Designer

The Universe Development Process (1)

The Universe Development Process (2)

Universe Development Process

Involve users in all the

The Universe Development Process

Implementation Sub Process:

Create Universe file & set parameters

Create and categorize objects.

18 Business Object XI R3 Designer

What You Have Learned

The advantages of using BusinessObjects

19 Business Object XI R3 Designer

What You Will Be Able To Do

Log in to the Designer module

Be familiar with the Designer module and its

Be able to manipulate the Universe Structure

21 Business Object XI R3 Designer

Business Objects Designer

Logging in to BusinessObjects Designer

What You Have Learned

How to log in to the Designer module