BO XIR3 Universe Designer

2
BO Designer: Overview
! Introduction:
! Designer is a BO component that is used to build universes.
! A universe is a semantic layer between database and end users.
! The role of a universe is to provide an easy to use and
understand interface for non technical Business Objects and
Web Intelligence users to run queries against a database to
create reports and perform data analysis.
3
BO Designer: Objective
! Objective:
After completing this chapter, you will be able to:
! Define connection to universe
! Design universe
! Insert tables and joins
! Resolve loops
! Create classes and objects
! Check universe integrity
! Manage universe
! Overview of Security
4
Universe
! A universe:
! Is a semantic layer between database and end users.
! Is a business-oriented mapping of the data structure found in
databases: tables, columns, joins, and so on.
! Can represent any specific application, system, or group of
users. For example, a universe can relate to a department in a
company such as marketing or accounting.
! Can also pertain to a section within a department or just about
any set of organized procedures such as a payroll or inventory
system.
! Consists of a set of objects, grouped by classes.
5
Role of a Universe
! The following diagram shows the role of objects as the mapping layer between a
database schema and the Query panel in BusinessObjects or the Query work
area in WebIntelligence, that users use to create queries to run against database
tables.
6
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 Salaiy
Benefits...
Sales Revenue Sales
Executive Customei
Piouuct Piice 0iuei
Bate ...
7
The Universe Development Process
Piepaie
Know the uata souice
BR on
Sybase
Financials
on 0iacle
Plan
Besign the univeise(s)
Analyze
Iuentify the neeus of the
enu usei population
8
The Universe Development Process (Contd.)
Test
0sing a test team (incluuing enu
useis)
Implement
Cieate the univeise(s)
Evolve
Auapt anu extenu univeise
ovei time
Beploy
Bistiibute the univeise to enu
useis
9
The Universe Development Process (Contd.)
80
20
Involve useis in all steps of the
pioject
10
Creating a Universe
Befine the Paiameteis
Inseit Tables
Nake the }oins
Resolve the Loops
Cieate Classes anu 0bjects
Set up Bieiaichies
11
Creating a Universe (Contd.)
! For creating a new universe:
! Select File > New
12
Universe Connection
! Definition:
! A connection is a link from the universe to the target database
! The link is achieved using middleware (for example ODBC)
! An existing connection may be used or a new connection
created for a universe
! There are three different types of BO connection
13
Types of Connection
! Peisonal: Can only be useu on the client
! Shaieu: Can be useu by moie than one usei to senu queiies to the taiget
uatabase fiom a shaieu seivei
! Secuieu: This connection is useu when you wish to uistiibute the completeu
univeise to the usei population via the iepositoiy
14
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.
15
Setting up Universe Parameters (Contd.)
! Controls tab:
! These allow you to limit the
size of results and restrict
the time allowed for
executing queries.
16
Setting up Universe Parameters (Contd.)
! SQL tab:
! SQL parameters are used to
define the limits of the SQL
that may be generated by the
universe.
17
Inserting Tables
! Use the Table Browser:
! Double-click on the background of the
Structure
! Click on
! Choose Insert -> Tables from the menu
! The Table Browser displays all the tables and
views of the database.
! You can select multiple tables using the Shift
key or Ctrl key.
18
Classes and Objects
! BO presents the data in three hierarchical collections or
categories:
! Universe
! Classes
! Objects
19
Class
! Universe:
! A BO universe is a collection of classes that is intended for a
particular group of users.
! Class:
! A class is a logical grouping of objects within a universe. It
represents a category of objects. The name of a class should
indicate the category of the objects that it contains. A class can
be divided hierarchically into subclasses.
20
Object
! Object:
! An object is a named component that maps to data or a
derivation of data in the database. The name of an object should
be drawn from the business vocabulary of the targeted user
group. For example, objects used in a universe used by a
product manager could be Product, Life Cycle, or Release
Date. A universe used by a financial analyst could contain
objects such as Profit Margin and Return on Investment.
21
Object Types
! Dimension:
! Parameters for analysis. Dimensions typically relate to a
hierarchy such as geography, product, or time. For example Last
Name and City_Id.
! Detail:
! Provide a description of a dimension, but are not the focus for
analysis. For example Phone Number.
! Measure:
! Convey numeric information which is used to quantify
dimension object. For example Sales Revenue.
Using List Of Values
22
! Allows you to view and modify the data values in the list of values assigned to
the selected object.
! You can view the list of values in a tabular form or in a hierarchical form.
! The options to manage lists of values are:
" Edit
" Display
" Purge
" Refresh
" Properties
! You can specify a text file, a Dbase file or a spreadsheet file to be used for the
selected object's list of values.
Using List Of Values (Contd.)
23
23
24
Creating Joins
! What do joins achieve in SQL?
! The SQL will give a cartesian product which gives an incorrect
result
25
Creating Joins (Contd.)
! What is Join?
! A join is a condition that restricts the result set of a query
! There are several different kinds of join:
! Equi-join (otherwise known as a standard or inner join)
! Outer join
! Theta join
! Shortcut Joins
! Self join
26
Creating Joins (Contd.)
Equi - }oin
27
Creating Joins (Contd.)
! Creating a Join in Designer:
! A join can be entered manually using two
methods:
! Graphically
! With the menu option Insert,
Joins and the Edit Join box
! To delete a join, click on the join line and
press Delete
28
Creating Joins (Contd.)
! Automatic join detection:
! The Strategy for automatic detection of joins is based on
common column names between tables.
! You can choose from one of three specific strategies for join
detection:
! Smart matching column names (no key info.)
! All matching column names
! All matching numeric column names
29
Creating Joins (Contd.)
Theta }oin Result Set:
Theta }oin
! Theta join:
! A theta join contains an expression that is based on something
other than equality:
30
Creating Joins (Contd.)
! Creating theta join:
! A theta join is created by converting an existing equi-join.
31
Creating Joins (Contd.)
! Shortcut joins:
! Join providing an alternative path between two tables, bypassing
intermediate tables, leading to the same result, regardless of
direction.
! Optimizes query time by cutting long join paths as short as
possible.
32
Creating Joins (Contd.)
! Self restricting join:
! This is not really a join at all. It is a method used to set a
restriction on a table in the universe structure.
SS
Cieating }oins (Contu.)
" Automatically using (but can take a long time)
" Nanually using the Euit }oin uialog box
! Adding cardinalities:
34
Creating Joins (Contd.)
! Join problems: The three major join problems that could be
encountered in the schema are:
! Loops (resolved using alias/contexts)
! Chasm traps (resolved using contexts)
! Fan traps (resolved using alias/contexts)
35
Creating Joins (Contd.)
! Loops:
! A loop is a set of joins that defines a closed path through a set of
tables in a schema. Loops occur when joins form multiple paths
between lookup tables. An example of a loop is shown below:
36
Creating Joins (Contd.)
! The schema contains two linked sets of information:
! These two sets of information are linked in a common join path
forming a loop. The lookup table Country can be the country
where a resort is situated, or the country in which a customer
lives.
Foi each. The following infoimation is linkeu
Resoit Available seivice lines, seivices foi each seivice line, invoice
infoimation foi each seivice anu the countiy wheie the iesoit is
situateu.
Customei The city, iegion anu countiy wheie the customei lives, the sales foi
the customei anu the invoice infoimation foi each sale.
37
Creating Joins (Contd.)
! Chasm Trap
! A chasm trap is a type of join path between three tables when
two "many-to-one“ joins converge on a single table, and there is
no context in place that separates the converging join paths.
38
Creating Joins (Contd.)
! Fan trap:
! A fan trap is a type of join path between three tables when a
“one-to-many” join links a table which is in turn linked by
another “one-to-many” join. The fanning out effect of “one-to-
many” joins can cause incorrect results to be returned when a
query includes objects based on both tables.
39
Creating Joins (Contd.)
! Always check integrity after defining joins:
40
Resolving Loops
! Loops can be resolved using:
! Alias
! Context
! Alias:
! An alias breaks a loop by using the same table twice in the same
query for different purpose. The alias is identical to the base
table with a different name. The data in the alias table is exactly
the same as the original table, but the different table name
generates a modified SQL, referring to two tables and two sets
of joins and the loop is broken.
41
Resolving Loops: Alias
! The two “one” ended joins are now separated as follows:
! Country keeps a join to the Resort table.
! Country_Region is joined to the Region table.
! The schema now appears as shown below:
42
Resolving Loops: Context
! Context:
! A context resolves a loop by defining a set of joins that specifies one
specific path through tables in a loop. It ensures that joins are not
included from different paths within the same SQL query.
! You often use contexts in the schema that contain multiple fact tables
(“multiple stars”) that share lookup tables.
43
Resolving Loops: Context (Contd.)
! In the example, you can follow two different paths from the
Customer table to the Service table:
Foi this path. Besignei uetects these contexts.
Reseivations anu
Reseivation_Line
Reseivation_Line
Sales anu
Invoice_Line
Sales_Line
44
Resolving Loops: Context (Contd.)
The Reservation_Line context appears below:
45
Resolving Loops: Context (Contd.)
The Sales_Line context appears below:
! You then create different sets of objects from the tables in the different contexts. Users
can then run either Reservation queries or Sales queries, depending on the objects they
select.
46
Hierarchies
! Object hierarchies can be created to perform multidimensional analysis.
! Multidimensional analysis is the analysis of dimension objects organized in
meaningful hierarchies.
! Multidimensional analysis allows users to observe data from various viewpoints.
This enables them to spot trends or exceptions in the data.
! A hierarchy is an ordered series of related dimensions. An example of a
hierarchy is Geography, which may group dimensions such as Country, Region,
and City.
47
Functions
! SQL editor is used to define the Select statement or a Where
clause for an object. Functions can be used in an object definition.
! Database functions, for example number, character, and date
functions.
! @Functions specific to BO products.
! The available @functions are:
! @Aggregate Aware
! @Prompt
! @Script
! @Select
! @Variable
! @Where
48
Conditions
! A restriction is a condition in SQL that sets criteria to limit the data returned by
a query.
! Two types of restrictions can be defined in a universe:
! A condition object is a predefined Where clause that can be inserted into the
Select statement inferred by objects in the Query pane.
Restiiction type Besciiption
Foiceu Restiiction uefineu in the Wheie clause foi an object. It cannot be
accesseu by useis anu so cannot be oveiiiuuen in Web
Intelligence.
0ptional Restiiction uefineu in special conuition objects that useis can
choose to use oi not use in a queiy. A conuition object is a
pieuefineu Wheie clause that can be inseiteu into the Select
statement infeiieu by objects in the Queiy pane.
49
Conditions (Contd.)
! Using condition objects has the following advantages:
! Useful for complex or frequently used conditions
! Gives users the choice of applying the condition
! No need for multiple objects
! Condition objects do not change the view of the classes and
objects in the universe pane
Aggregate Awareness
50
! Aggregate awareness is the ability of a universe to make use
of aggregate tables in a database.
! Aggregate Tables:
• Contains Pre-calculated data
• Speeds up the execution of queries, improving the performance
of SQL transactions.
! Set up aggregate awareness as follows:
• Define the Select statement for an object using the
@AggregateAware function.
• Specify which objects are incompatible with the aggregate table
and can not be used in a query that is run against that table.
Derived Tables
51
! Derived tables are tables defined in the universe schema.
! A derived table is defined by an SQL query at the universe level that can be used as a
logical table in Designer.
! The columns returned by the queries to build objects can be used as the columns of a
normal database tables.
Derived Tables ( Contd.)
! Derived tables have the following advantages:
! Reduced amount of data returned to the document for analysis
! Include complex calculations and functions in a derived table. These operations are performed before
the result set is returned to a document, which saves time and reduces the need for complex analysis
of large amounts of data at the report level.
! Reduced maintenance of database summary tables
! Derived tables can, in some cases, replace statistical tables that hold results for complex calculations
that are incorporated into the universe using aggregate awareness. Derived tables can return the same
data and provide real time data analysis.
52
Derived Tables ( Contd.)
53
! Steps for creating a derived table:
a) Right-click the mouse over the Designer table schema and select
Derived Table from the menu to view the Derived Tables dialog
box. Or go to Insert->Derived Tables.
Derived Tables ( Contd.)
54
b) Type the derived table name in the Table Name box.
c) Type the derived table SQL in the SQL Expression box or use the
objects in the Tables and Columns, Operators and Functions boxes
to build the SQL.
Derived Tables ( Contd.)
55
d) Click SQL to validate the SQL.
e) Click OK to close the dialog box. The derived table appears
as a regular table in the Designer table schema.
f) Use the columns in the derived table to build objects as you
do with a normal database table.
! Derived tables can be edited or deleted.
Linking Universes
56
! Linked universes are universes that share common components such as
parameters, classes, objects, or joins.
! An active universe can be linked to one or more universes.
! Among linked universes, one universe is said to be the kernel while the others
are the derived universes.
! The kernel universe represents a re-useable library of components.
! Derived universes may contain some or all of the components of the kernel, in
addition to any components that have been added to it.
! While connecting an active universe to other universes, the active universe
becomes the derived universe, and the linked universe becomes the core
universe.
Linking Universes (Contd.)
57
! Components from the core universe are inherited by the derived universe.
! To link a universe to a core universe, the core universe must have been
exported to the repository at least once. Otherwise, DESIGNER does not allow
the link.
! Advantages of linking universes:
! Reduce development and maintenance time. While modifying a
component in the core universe, Designer propagates the
change to the same component in all the derived universes.
! Centralize often used components in a core universe, and then
include them in all new universes. No need to re-create
common components each time while creating a new universe.
Linking Universes (Contd.)
! To Link two universes:
! Goto Edit-> Links. Click the Add Link button.
58
58
Shows the names
of the universes to
which the active
universe is linked.
Displays the
Universe to Link
dialog box from
which you can link
the kernel universe
to other universes.
Other than linking
universes, you can
include the
components of the
kernel universe in a
derived universe.
Shows the user who
last modified the
universe.
It lets you indicate the
new location of the
kernel universe if u
have changed its
location.
Remove a link to a
kernel universe only if
the active universe no
longer contains objects
based on components
or joins from the kernel
universe.
Displays the path of the linked universe.
Linking Universes (Contd.)
! The Universe to Link dialog box appears.
Browse to the universe to link.
! Click the Open button.
The selected universe appears in the list.
! Click OK. The link is created. The tables of this core universe
can be visible in the universe schema.
59
Securing Universes
! A restriction is a named group of constraints that apply to a universe.
! When users connect to a universe, the objects, rows, query types, and connection that
they use in the universe are determined by their applied restriction.
60
Securing Universes (Contd.)
61
! Apply restrictions to defined user and groups who use a universe
at two levels:
! CMC Level - From the Central Management Console set
restrictions that apply to universes stored in a CMS. Set what
universes users can access, and depending on the rights defined for a
user group, restrict viewing, editing, deleting, and other actions in a
universe.
! Universe Level - Define restrictions for users allowed to use a
universe. A group of restrictions that correspond to a user group is
called a restriction set. A restriction set can include object access,
row access, query and SQL generation controls, and connection
controls.
Securing Universes (Contd.)
62
! To create a restriction set
! Select Tools > Manage Security > Manage Access Restrictions.
The Manage Access Restrictions box appears.
Securing Universes (Contd.)
63
! Click New. The Edit Restriction dialog box appears.
! Click on each tab in the dialogue box and apply the restrictions to be
imposed in the universe and click OK.
64
Managing Universes
! Reason for universe maintenance:
! New tables added to database
! Tables deleted, changed, or renamed in database
! Users request new classes or objects
Note: Your primary concern when you introduce a new version of a universe should be what effect it
will have on existing end user reports.
Tip: Do not distribute new versions of universes too frequently!
65
Managing Universes (Contd.)
! Changes to target database:
! The implications of modifying the underlying database for BO universes varies in severity:
No Impact:
! Auuing new columns
! Auuing new tables
Seveie Impact:
! Renaming¡moving uatabase
! Changing existing column anu
table names
! Beleting tables anu columns
66
Managing Universes (Contd.)
# Betecting changes to uatabase:
" Choose view > Refiesh
Stiuctuie
" Changeu tables aie
highlighteu in the Stiuctuie
" A message on the scieen
inuicates that tables have
been ueleteu
67
Managing Universes (Contd.)
! Effect of changes to existing objects:
! Changes to existing Objects in a universe can have an impact on existing Documents
created from the universe.
No Impact:
! Reuefining 0bject SQL
! Renaming an 0bject
! Copying to uiffeient Class
! Noving in same Class oi to a
uiffeient Class
! Auuing new 0bjects
Impact:
! Beleting an existing 0bject
! Beleting anu then iecieating
an object with exactly the same
uefinition
68
Managing Universes (Contd.)
Auu tables to the univeise stiuctuie
Belete existing contexts
Betect aliases
Betect contexts
Cieate new objects
Set up hieiaichies
Inseit joins anu set caiuinalities
! Adding new tables to universe
! The workflow is:
69
Best Practices
1. Object and class naming should be in business terms – so that it makes sense to the
end-user. This also reduces development overhead since reports can use descriptions
out-of-the-universe, instead of editing headers or creating report level variables.
2. All objects should have help text or usage information – corollary from above.
3. Object formatting should preferably be done at the universe level.
4. Pre-build condition objects in the universe rather than forcing users to build
conditions for reports.
5. Build logic into objects – translate code, common calculations etc rather than forcing
users to do it in report variables.
70
Best Practices (Contd.)
6. Avoid using WHERE clauses in the object definitions; use CASE statement instead. In
most cases, using WHERE clause will return incorrect results when similar objects are
included in the result set, due to combined restrictions imposed by the multiple
WHERE clauses.
7. Use aggregation in all measure objects – to push the aggregation to the database
wherever the performance bottleneck is likely to be BO server.
8. All measure objects should include aggregation functions for projection. When this is
not included, BO will not automatically roll-up the data in the report, which could
result in incorrect data and analysis.
9. Integrity checks on the universe structure, parsing of objects, joins, contexts,
detecting loops etc is mandatory.
71
Best Practices (Contd.)
10. Use aggregate tables /materialized views with aggregate awareness set up to improve
query performance.
11. Turn off LOVs for all dimension and detail objects that are redundant or not required.
72
New Features
1. Database Delegated : A new projection for measure objects which will roll-up data in
BO report. For e.g. – average calculation.
2. Optional Prompts : User can refresh report without entering value in optional
prompt.
3. Mandatory Filters : Forcing predefined conditions/filters on the whole universe or on
a universe class.
73
Test Your Understanding
1. What are the steps to create a universe?
2. Define the different types of connection.
3. What are the different types of objects?
4. What is a loop and how do you resolve it?
5. List the types of @Functions.
74
BO Designer: Summary
! Designer is a BO component that is used to build universes. A universe is a semantic
layer between database and end users.
! A universe consists of a set of objects, grouped by classes.
! A connection is a link from the universe to the target database.
! There are three types of connection:
! Personal
! Shared
! Secured
! The types of objects are:
! Dimension
! Detail
! Measure
75
BO Designer: Summary (Contd.)
! A join is a condition that restricts the result set of a query.
! A loop is a set of joins that defines a closed path through a set of tables in a schema.
! Loops can be resolved using Alias or Context.
! A hierarchy is an ordered series of related dimensions.
! @Functions can be used in object definition in the Select statement or Where clause.
! A condition object is a predefined Where clause that can be inserted into the Select
statement inferred by objects in the Query pane.
76
BO Designer: Source
! http://help.sap.com/businessobject/product_guides/
! Business Objects XI Release 3 Designer’s Guide