DM 310 Ig

l
I
i
i"-,,
\
'---' BusinessObjects XI R1/R2:
Universe Design
''-../
Instructor's Guide
DM310R2
/
Copyright
Patents
Business Objects owns the following U.S. patents, which may cover
products that are offered and sold by Business Objects: 5,555,403,
6,247,008 B1, 6,578,027 B2, 6,490,593 and 6,289,352.
Trademarks
Business Objects, the Business Objects logo, Crystal Reports, and

Crystal Enterprise are trademarks or registered trademarks of
Business Objects SA or its affiliated companies in the United States
and other countries. All other names mentioned herein may be
trademarks of their respective owners. Product specifications and
program conditions are subject to change without notice.
Copyright
Copyright © 2005 Business Objects SA. All rights reserved.
~
(
{~
I~
~
i
I
"
"'-J
c o N T E N .T s
About this Course
Course objectives xvi
Course audience xvi
Prerequisite education xvi
Prerequisite knowledge/experience xvi
Course success factors xvii
Training facility setup xvii
Course materials xvii
Learning process xviii
Recommended education xix
Facilities Setup
Introduction xxii
Facilities Setup xxii
Setting up for the activities xxiv
Before class begins v-xxiv
Getting Help xxxii
Lesson 1
Understanding BusinessObjects Universes
Understanding BusinessObjects universes 1-2
Introduction 1-2
What is a universe? 1-2
Universes are used to query the database 1-2
Classes and objects 1-3
How universes are used 1-3
Advantages of a universe 1-3
Metadata and the semantic layer 1-4
BusinessObjects Universe Designer components 1-5
Using the Quick Design Wizard 1-7
Using Designer module commands 1-8
Saving and exporting a universe 1-11
Opening, importing, and exporting universes 1-11
Importing a universe 1-11
Giving all users access to a universe 1-13
Activity: Viewing a universe in Designer 1-14
Copyright © 2005 Business Objects. All rights reserved. iii I
I
)
Using the Universe Development Cycle 1-15
The Universe Development Cycle 1-15
Activity: Plan a universe 1-17
Lesson summary 1-18
Quiz: Understanding BusinessObjects Universes 1-18
Lesson 2
Creating the Course Universe
The course database and universe 2-2
Introduction 2-2
Course database description 2-2
Assumptions 2-2
Analysis of reporting requirements 2-3
Development plan 2-4
Creating the universe 2-5
Introduction 2-5 (~
Defining universe parameters 2-5

Setting the database connection
Viewing available connections
2-6
2-12 I"
Universe parameters 2-13
Universe Parameters dialog box
Summary tab
2-13
2-14
"
I
Strategies tab 2-15

Controls tab
SQL tab
2-16
2-17
"
I
Links tab 2-18
Parameters tab 2-19
(~
Lesson summary 2-21
Quiz: Creating the Course Universe 2-21 (
~
Lesson 3
Building the Universe Structure
Populating the universe structure 3-2
Designing a schema 3-2
Schema design and the universe creation process 3-3
(~
Adding tables 3-4
Viewing data from the Table Browser 3-5 (~
Organizing your tables 3-7

Changing table display 3-7
Viewing table values 3-7
Activity: Building the universe structure 3-9
Defining joins in a universe 3-10
About joins and SQL Where clauses 3-10
Creating joins _ 3-11
Tracing joins manually in the schema 3-11
Creating the join by defining properties 3-12
Editing the join expression 3-14
Detecting joins 3-16
Setting join cardinalities 3-17
About cardinality 3-17
Detecting cardinality automatically 3-21
iv Universe Design-instructor's Guide

Best practice for setting join cardinality 3-23
Join types 3-24
Equi-joins 3-25
Outer joins 3-26
Theta joins 3-27
Shortcut joins 3-28
Self-restricting joins 3-28
Using List Mode 3-29
Checking integrity 3-30
Activity: Building the universe structure 3-32
Lesson summary 3-34
Quiz: Building the Universe Structure 3-34
Lesson 4
Creating Dimension Obj eets
Objects and classes 4-2
Introduction 4-2
Objects 4-2
Classes 4-4
Creating classes and objects 4-5
Introduction 4-5
Creating classes 4-5
Creating an object 4-6
Defining a new object as a detail object 4-7
Creating classes or objects by dragging tables or columns 4-8
Working with classes and sub-classes 4-10
Editing the object properties 4-11
Copying and pasting objects 4-18
Find and replace 4-18
Checking integrity 4-20
Viewing parent tables 4-20
Testing objects 4-21
Activity: Creating and testing classes and objects 4-22
Objectives: 4-22
Lesson summary 4-27
Quiz: Creating Dimension Objects 4-27
Lesson 5
Creating Measure Obj eets
What are measure objects? 5-2
Defining measure objects 5-2
Levels of aggregation 5-3
Creating measure objects 5-7
Creating measure objects 5-7
Testing measure objects 5-8
Activity: Create and test measure objects 5-10
Lesson summary 5-12
Quiz: Creating Measure Objects 5-12
Table of Contents-instructor's Guide v

Lesson 6
Using Lists of Values
Creating a list of values 6-2 I.~
What is a List of Values? 6-2
Using a LOV 6-2
Working with LOVs in Designer 6-5
Creating a cascading LOV 6-13
Setting up a cascading LOV 6-13
Using the cascading LOV in Web Intelligence 6-15
Activity: Using LOV 6-17
Lesson Summary 6-18
Quiz: Using Lists of Values 6-18
Lesson 7
Resolving Loops in a Universe
Understanding loops 7-2
Introduction 7-2
Recogni~ng~ops 7-2
Problems caused by loops 7-3
Loops in a universe schema and not in the database 7-3
What is the loop doing? 7-3
Resolving loops 7-4 (~
How Designer deals with loops 7-4

Resolving loops using aliases 7-5
Introduction 7-5
About aliases 7-5
Detecting loops and inserting aliases 7-6 I~
Inserting an alias manually 7-9

Redefining objects 7-9
Listing and renaming aliases 7-10
Choosing which alias method to use 7-10
Resolving self-join loops using aliases 7-11
Resolving loops using shortcut joins 7-14
Introduction 7-14
Using a shortcut join 7-14
~
I
Activity: Resolving loops with aliases 7-16
Resolving loops using contexts 7-18
Introduction 7-18
About contexts 7-18
Detecting and creating contexts 7-22
Creating objects for each context 7-25
Editing a context 7-25
Testing contexts 7-27
Updating contexts 7-29
Activity: Resolving loops using contexts 7-30
Lesson summary 7-33
Quiz: Resolving Loops in a Universe 7-33
~.
I
vi Universe Design-instructor's Guide

""
\
Lesson 8
Resolving SQL Traps
Understanding SQL traps and universes 8-2
Resolving chasm traps 8-3
Chasm traps 8-3
Detecting chasm traps 8-4
The Chasm trap scenario 8-4
Resolving chasm traps 8-6
Using multiple SQL statements for each measure to resolve chasm traps .. 8-7
Using contexts to resolve chasm traps 8-10
Activity: Resolving chams traps 8-11
Resolving fan traps 8-14
Fan traps 8-14
Detecting fan traps 8-15
The fan trap scenario 8-15
Resolving fan traps 8-17
Using aliases and contexts to resolve fan traps 8-18
Another solution using aliases and contexts 8-21
Avoiding fan traps altogether 8-23
Activity: Resolving fan traps 8-24
Lesson summary 8-27
Quiz: Resolving SQL Traps 8-27
Lesson 9
Applying Restrictions on Objects
Restricting the data returned by objects 9-2
Defining data restrictions 9-2
, Methods of restricting data in Web Intelligence 9-4
--.../
Applying restrictions to objects 9-5
Applying restrictions to objects 9-5
An alternative to applying restrictions to objects 9-7
Applying restrictions using condition objects 9-9
Restrictions using condition objects 9-9
Applying restrictions to tables 9-11
Applying restrictions using the tables button 9-12
Applying each type of restriction 9-14
Activity: Applying restrictions 9-15
Lesson Summary 9-17
Quiz: Applying Restrictions on Objects 9-17
'-..../
Table of Contents-Instructor's Guide vii

Lesson 10
Using Functions with Objects
Using @ Functions 10-2
Defining @Functions 10-2
@Prompt 10-3
@Prompt syntax 10-3
@Select 10-5
@Where 10-7
Activity: Using @Functions 10-10
Lesson Summary 10-12
Quiz: Using Functions with Objects 10-12
Lesson 11
Using Hierarchies
Understanding hierarchies and universes 11-2
Hierarchies 11-2
Natural hierarchies 11-3
Logical hierarchies 11-3
Working with hierarchies 11-4
Default hierarchies 11-4
Viewing default hierarchies 11-5
Creating custom hierarchies 11-8
Creating a custom hierarchy 11-9
The effect of custom hierarchies on default hierarchies 11-10
Editing types of hierarchies 11-12
Time hierarchies 11-13
Creating time hierarchies 11-13
Time hierarchies based on database functions 11-17
Table-based time hierarchies 11-19
Activity: Using hierarchies 11-21
Lesson summary 11-23
Quiz: Using Hierarchies 11-23
Lesson 12
Aggregate Awareness
Understanding aggregate awareness and universes 12-2
What is Aggregate Awareness? 12-2
Summary Tables 12-3
Summary Tables and SQL 12-4
Applying aggregate awareness to objects 12-5
Setting up Aggregate Awareness _ 12-5
Step 1: Insert a summary table and set joins cardinality 12-5
Step 2: Set the contexts 12-6
Step 3: Redefine the objects 12-7
Step 4: Define incompatible objects _ 12-9
Using aggregate awareness to resolve fan traps 12-12
Testing aggregate awareness 12-13
Activity: Aggregate awareness 12-14
Quiz: Aggregate Awareness 12-16
viii Universe Design-instructor's Guide

-
Lesson 13
Derived Tables and Indexes
Using derived tables 13-2
What is a derived table? 13-2
Advantages of using derived tables 13-2
Adding derived tables 13-3
Activity: Derived tables 13-6
Applying index awareness 13-7
What is index awareness? 13-7
Setting up index awareness 13-8
Activity: Index awareness 13-12
Quiz: Derived Tables and Indexes 13-13
Lesson 14
Linking Universes
Understanding linked universes 14-2
What are linked universes? 14-2
Using linked universes 14-3
Possible linking strategies 14-3
Advantages and limitations to linking 14-4
Creating links between universes 14-5
Linking universes 14-5
Editing the derived structure 14-7
Including one universe within another 14-8
When to link and when to include? 14-10
Activity: Linking universes 14-11
Quiz: Linking Universes 14-12
Lesson 15
Securing Universes
Setting access restrictions on a universe 15-2
About security and universes 15-2
What is a restriction set? 15-2
Creating a restriction 15-4
Applying a restriction set to users 15-14
Setting restriction group priority 15-17
Viewing user and group restrictions 15-18
Activity: Setting access restrictions 15-19
Quiz: Securing Universes 15-20
Table of Contents-instructor's Guide ix

Lesson 16
Managing Universes
Documenting universes 16-2
Printing universe details 16-2
Printing options: General section 16-4
Printing options: List components section 16-4
Printing options: Full description section 16-5
Deploying universes 16-6
About deploying a universe 16-6
How do other users access the universe? 16-6
What happens when you export a universe 16-7
Exporting a universe 16-10
Importing a universe 16-11
Working with multiple designers 16-13
Understanding version control 16-13
Locking a universe 16-14
Maintaining universes
Reasons for universe maintenance
16-15
16-15 r
Changes to the target database 16-15
Adding new tables to an existing universe 16-18
The effect of changing objects 16-18
Activity: Managing universes 16-20
Lesson Summary 16-21
Quiz: Managing Universes 16-21
,--
I
Lesson 17
Creating Universes from Metadata
Creating a universe from an XML metadata file 17-2
Which metadata sources are supported? 17-2
Working in the Metadata Exchange panel 17-3
Creating a universe from metadata 17-4
Activity: Creating universes from metadata 17-9
Quiz: Creating Universes from Metadata 17-10
Appendix A
End of Course Challenge
The Challenge A-2
x Universe Design-Instructor's Guide

A G E N D A
Universe Design
Introductions, Course Overview 30 minutes
Lesson 1
Understanding BusinessObjects Universes 30 minutes

o Understanding BusinessObjects universes
o Using the Universe Development Cycle
o Lesson summary
Lesson 2
Creating the Course Universe 45 minutes

o The course database and universe
o Creating the universe
o Lesson summary
Lesson 3
Building the Universe Structure 1 hour

o Populating the universe structure
o Defining joins in a universe
o Lesson summary
Lesson 4
Creating Dimension Objects 2 hours
o Objects and classes
o Creating classes and objects
o Lesson summary
Lesson 5
Creating Measure Objects 30 minutes

o What are measure objects?
o Creating measure objects
o Lesson summary
Copyright © 2005 Business Objects. All rights reserved. xi

Lesson 6
Using Lists of Values 30 minutes
o Creating a list of values
o Working with LOVs in Designer
o Creating a cascading LOV
o Lesson Summary
Lesson 7
Resolving Loops in a Universe 3 hours
o Understanding loops
o Resolving loops using aliases
o Resolving loops using shortcut joins
o Resolving loops using contexts
o Lesson summary
Lesson 8
Resolving SQL Traps 1.5 hours
o Understanding SQL traps and universes
o Resolving chasm traps
o Resolving fan traps
o Lesson summary
Lesson 9
Applying Restrictions on Objects 1 hour
o Restricting the data returned by objects
o Lesson Summary
Lesson 10
Using Functions with Objects 45 minutes
DUsing @ Functions
o Lesson Summary
Lesson 11
Using Hierarchies 45 minutes
o Understanding hierarchies and universes
o Working with hierarchies
o Lesson summary
Lesson 12
Aggregate Awareness 1 .5 hours
r
o Understanding aggregate awareness and universes
o Applying aggregate awareness to objects
o Lesson summary
xiiUniverse Design-instructor's Guide

./
Lesson 13
Derived Tables and Indexes 1 hour
o Using derived tables
o Applying index awareness
o Lesson summary
Lesson 14
Linking Universes 30 minutes
o Understanding linked universes
o Creating links between universes
o Lesson summary
Lesson 15
Securing Universes 45 minutes
o Setting access restrictions on a universe
o Lesson summary
Lesson 16
Managing Universes 45 minutes
o Documenting universes
o Deploying universes
o Maintaining universes
o Lesson Summary
Lesson 17
Creating Universes from Metadata 30 minutes
o Creating a universe from an XML metadata file
o Lesson summary
o The Challenge
Agenda-instructor's Guide xiii

xivUniverse Design-instructor's Guide
About this Course
This section explains the conventions used in the course and in this training
guide.
Copyright © 2005 Business Objects. All rights reserved. xv

Course objectives
BusinessObjects XI R1/R2 Universe Design is a classroom-based course
where participants learn to design and maintain BusinessObjects universes .
. The course includes presentation of concepts, demonstration of features,
facilitated discussions, practice activities, and reviews.
After completing this course, learners will be able to:
Understand BusinessObjects universes
Set universe parameters
Populate the universe structure
Define joins and set their cardinalities
Create universe classes, and create dimension, detail and measure
objects
Create a list of values
Resolve loops in a universe
Resolve SQL chasm and fan traps
Apply restrictions to objects
Create hierarchies, use aggregate awareness, derived tables and index
awareness features
Link universes
Manage universes and apply security
Create universes from metadata sources
Course audience
The target audience for this course is universe designers.
Prerequisite education
To be successful, learners who attend this course must have attended the
following offerings:
Not applicable for this offering
Prerequisite knowledge/experience
To be successful, learners who attend this course must have working
knowledge of:
Good working knowledge of SQL and/or relational database
management systems.
Familiarity with the type of data and the logical structure of the databases
in their organization.
Familiarity with BusinessObjects Web Intelligence, Desktop Intelligence
and report building.
xvi Universe Design-instructor's Guide

Course success factors
Your learning experience will be enhanced by:
Activities that build on the life experiences of the learner
Discussion that connects the training to real working environments
Learners and instructor working as a team
Active participation by all learners
Training facility setup

Refer to the Facility Setup section of this training guide for details on hardware,
software, classroom, course material, and course-specific requirements.
These items must be set up before the first day of class.
Course materials
The materials included with the course materials are:
Name card
Instructor's Guide
The Instructor's Guide contains an agenda, lessons, and practice
activities. The Instructor's Guide outlines detailed contents as well as
instructor notes, which do not appear in the Learner's Guide, for teaching
this course.
Learner's Guide
The Learner's Guide contains an agenda, learner materials, and practice
activities.
The Learner's Guide is designed to assist students who attend the
classroom-based course and outlines what learners can expect to achieve
by participating in this course.
Point out the Evaluation form
feedback At the conclusion of this course, instruct the learners to provide feedback
form located on the course content, instructor, and facility through the evaluation
at the back of process. Their comments will assist us to improve future courses.
the training
Additional information for the course is provided on the resource CD or as a
guide to the
learners as hard copy:
part of the Sample files
course intro- The sample files on the resource CD can include required files for the
duction and course activities and/or supplemental content to the training guide.
again at the
end of last Overview webinar(s)
day of class. Additional resources include:
Online Help and User's Guide
As an instructor, encourage the learners to retrieve information and find
answers to questions using the online Help and/or the User's Guide that
are included with the product.
About this Course-Instructor's Guide xvii

Learning process
Learning is an interactive process between the learners and the instructor. By
facilitating a cooperative environment, the instructor guides the learners
through the learning framework.
What's specific to BusinessObjects XI Release 2?
The audience for this course may consist of BusinessObjects XI Release 1and
BusinessObjects XI Release 2 customers. This icon has been placed
throughout the guide to identify features that are specific to BusinessObjects
XI Release 2.
Introduction
Why am I here? What's in it for me?
The learners will be clear about what they are getting out of each lesson.
Objectives
How do I achieve the outcome?
The learners will assimilate new concepts and how to apply the ideas
presented in the lesson. This step sets the groundwork for practice.
Practice
How do I do it?
The learners will demonstrate their knowledge as well as their hands-on skills
through the activities.
Review
How did I do?
The learners will have an opportunity to review what they have learned during
the lesson. Review reinforces why it is important to learn particular concepts
or skills.
Summary
Where have I been and where am I going?
The summary acts as a recap of the learning objectives and as a transition to
the next section.
xviii Universe Design-Instructor's Guide

Recommended education
This course is not part of a certification path.
About this Course-instructor's Guide xix

xx Universe Design-instructor's Guide
"
Facilities Setup
This section lists the facilities setup requirements for the course.
Duration: approximately two and a half hours per machine

(duration varies depending on whether the operating system
is already installed).
Recommendation for Business Objects training customer

Begin setting up the facility two days before training is scheduled to start.
Copyright © 2005 Business Objects. All rights reserved. xxi

Introduction
The purpose of this setup guide is to provide the information necessary to
correctly set up the environment for this course, and ensure the necessary
course files are installed on each computer.
This document provides:
Hardware and software requirements for Business Objects training
Guidance for facilities setup for Business Objects training
It is the responsibility of the training customer to ensure the training
classroom is set up according to these requirements.
Assuming that all sections must be completed, the approximate time to
complete this facilities setup for 12 students and one instructor is between 4-8
hours. Less time will be necessary if the operating systems are already
installed.
Facilities Setup
The classroom should have the following:
This section Learners' Guides, one per student
is to be
Note: Learners' Guides should be delivered to the training site three business
completed by
the Business days before the training class is scheduled to begin.
Objects An overhead display panel/projector connected to the instructor's
training computer
customer.
A whiteboard and a variety of erasable markers and eraser
A flip chart and a variety of markers
A non-laser pointer
Allow 8-12 One computer for the instructor and one computer for each learner taking
hours to the course (maximum of 12 learners in a classroom) with the minimum
complete this hardware and software requirements
section.
The minimum hardware requirements are:
Pentium3 700 MHz or higher processor required
512 MB RAM, 1 GB Recommended
CD-ROM or DVD drive Software
The software required for this course is:

Operating system = Microsoft 2000,2003, or XP
Note: For a complete list of supported operating systems for servers
and client components, refer to the Platforms.txt with your product
installation.
Microsoft Office 2000, 2003 or XP
Microsoft SOL Server 2000 SP 3a or higher
A web application server
Note: For a compiete list of supported web servers, refer to the
Platforms.txt with your product installation.
xxii Universe Design-instructor's Guide

BusinessObjects Enterprise XI Release 2 Professional Edition
including:
InfoView (portal to Web Intelligence)
Web Intelligence (application used for reporting in this course)
BusinessObjects Designer (application used to create universes
in this course)
To install required software

1 Install one of the following operating systems:
Windows 2000 (SP2)
Windows NT 4 Server (SP6a)
Windows XP Pro (SP1)
2 Install Microsoft Office 2000 or higher (Microsoft Word, Excel,
PowerPoint, Access).
3 Install one of the following web servers:
Microsoft Internet Information Server (liS) 5.0 (ISAPI and CGI for
Windows)
Microsoft liS 4.0 (NT 4 Workstation)
4 Install one of the following applications for your web server:
Java J2EE environment, 1.4 or higher
.NET framework 1.0 or higher
WARNING: If you opt to install the .NET framework, there are
multiple activities in the course that will not be possible. This course
REQUIRES that the Java environment be installed.
Note: A prepackaged version of Tomcat with Apache web server is
provided during the BusinessObjects Enterprise XI R2 installation.
5 Follow the installation procedures listed in the installation guide for
BusinessObjects Enterprise XI R2.
The directions in the BusinessObjects Enterprise XI R2 Installation
Guide should be followed accepting the defaults whenever possible.
Note: It is preferred that the classroom is set up with stand-alone
installations however it is possible to install one server and have all
students connect to that server.
Facilities Setup-instructor's Guide xxiii

Setting up for the activities
Before class begins

This section The following setup needs to be completed prior to the instructor arriving on-
is to be site. The universes and reports below will be used during the classroom
completed by activities. The following setup instructions are NOT part of the course and must
the be completed prior to the course. If the items below are not completed prior to
Business the instructor arriving on-site it WILL cause a delay in the delivery ofthe course
Objects and you may be charged for the additional setup time required.
training
customer. The directions below are step by step and can be followed with little knowledge
Allow 1 hour of the BusinessObjects Enterprise XI development environment.
to complete Upon completion of these items please contact your on-site instructor to let
this section.
them know that the setup is complete.
Deployment of Universes
This course uses the following universes:
Motors2004
Staff2004
eFashion
The first two universes listed will be created during this course. Both universes
access data that is stored in the Microsoft Access database, Motors2004.mdb.
This database file, plus the final version of the Motors2004.unv and
Staff2004.unv files are available on the course Resource CD.
The third universe, eFashion is installed by the Enterprise Setup program to

the following location:
C:\Program Files\Business Objects\BusinessObjects Enterprise
11.5\Samples\en\Universes
In order to make the universes available to the users you must first redefine
their connections to the appropriate data sources (Microsoft Access database
files), then export the universes to the repository.
Before doing this, you first need to ensure that valid ODBC connections are
present on the workstation.
The following instructions describe how to define a connection and export the
eFashion universe. Once you complete this procedure, you must repeat the
procedure for each of the other two universes, if you want to deploy the final
versions of the universes that will be built during the course.
To create an ODBC connection:

1 Click Start> Programs> Administrative Tools> Data Sources (ODBC).
2 Click the System DSN tab.
xxiv Universe Design-instructor's Guide

Note: In order to deploy a universe, the connection to the data source must
use a system DSN.
THEN
Go to Step 3.
10.
IF
n for
foreFashion
eFashion already
already exists
exists.
Start here if an eFashion ODBC connection already exists.

3 Click eFashion.
4 Click Configure.
5 Click Select.
Note: The correct database mayor may not be selected. If a previous
version of BusinessObjects ever existed on the machine, the
connection may be left over from that version. Continue through
steps 5 - 8 to verify the correct database is selected. The eFashion
database in BusinessObjects Enterprise 11 is different than the
database in previous versions.
6 Browse to the directory you installed BusinessObjects Enterprise 11 in
... \Business Objects\BusinessObjects Enterprise
11\Samples\En\Databases.
7 Select eFashion.mdb. Click OK.
8 Click OK to close the ODBC Microsoft Access Setup window.
9 Click OK to accept the ODBC changes.
10 Skip to step 18.
Start here if a new eFashion ODBC connection is required.

11 Click Add.
12 Select Microsoft Access Driver (*.mdb). Click Finish.
13 Type eFashion as the Data Source Name.
14 Click Select.
15 Browse to the directory you installed BusinessObjects Enterprise XI R2 in
11.5\Samples\En\Databases.
16 Select eFashion.mdb. Click OK.
After creating I verifying the eFashion ODBC connection, continue to

the instructions below.
To define the connection in the universe

1 Click Start> Programs> BusinessObjects 11 > BusinessObjects
Enterprise> Designer. Log into BusinessObjects Designer. If you are
using the default installation, you can use the username Administrator
with NO password.
If the wizard opens, click Cancel.
2 Click File> Open.
Facilities Setup-Instructor's Guide xxv

3 Browse to the directory where BusinessObjects Enterprise XI R2 was
installed
11.5\Samples\En\Universes.
4 Click eFashion.
5 Click Open. The universe will open in Designer.
6 Click File> Parameters.
7 On the Definition tab, click on New to add a new connection.
Note: The connection must be a "secured" connection prior to publishing
to the repository.
8 The New Connection Wizard appears. Click on Next.
9 Double-click Microsoft.
10 Double-click MS Access 2002. (Or the appropriate MS Access version)
11 Click ODBC Drivers. Click Next.
12 Verify the Type: is Secured.
13 Type Secured eFashion as the Name.
14 Select eFashion as the Data source name.
Your new connection window should look like this.
15 Click Next.
16 Click Test Connection. Verify that the test was successful.
If you do not see the message 'The server is responding!" Click the <
Back button and resolve the issue.
xxvi Universe Design-instructor's Guide

17 Click Next.
18 Click Next.
19 Click Finish.
The secured eFashion connection is now shown.
20 Click OK.
21 Click Tools> Check Integrity.
22 Select the checkbox for Check All.
23 Click OK. The integrity check runs.

24 Verify that the Check Integrity Results match exactly as shown below.
e'c 2ai"",~g~~
?,:»:~Objebtt: OK
'Pl!lwJ~ OK
. p&ti> C~8m'$: OK
[#O_k loop:OK
:£ffIJI\'m\1iIdi~
25 Click OK to close the window.

26 Click File> Export.
Facilities Setup-Instructor's Guide xxvii

The export universe window appears asking for confirmation of saving.
27 Click Continue.
28 Select the Folder.
29 Select the Groups (leave default if you are not sure).
30 Click OK.
The Universe successfully exported message appears.
31 Click OK.
32 Close BusinessObjects Designer.
33 Repeat this procedure for the two remaining universes used in this
course.
Note: As stated previously, the final versions of the Motors2004 and
Staff2004 universes and the Motors2004 database (used as data for
both universes) are provided on the course Resource CD.
Testing the hardware and software setup

After exporting the eFashion universe, follow the steps below to verify that all
files are in place for the training class.
Verify users can log into the J5P version of BusinessObjects Enterprise
11.
1 Click Start> Programs> BusinessObjects XI Release 2>

BusinessObjects Enterprise> BusinessObjects Enterprise Java InfoView.
2 Log in as a valid user. If running only the samples, log in as Administrator.
Administrator does not have a password.
Verify eFashion universe is available.

3 Click Web Intelligence Document from the New menu.
4 Verify that eFashion is listed as an available universe.

S Click eFashion to create a new Web Intelligence document.
xxviii Universe Design-Instructor's Guide

6 If the security warning appears, click Yes to trust the applet.
7 Double-click Year.
S Double-click Sales Revenue (in the Measures class).
9 Click Run Query.

The results should match the image below.
10 Close the document without saving (click X in top right corner).
Verify sample Web Intelligence document is available.

11 Click + to expand Public Folders.
12 Click Web Intelligence Samples.
Verify that the Web Intelligence Sample report is listed.
13 Click Web Intelligence Sample to open the report.
Facilities Setup-Instructor's Guide xxix

The report opens
14 Close the report without saving.

15 Repeat similar procedures for the remaining universes.
16 Log out of BusinessObjects Enterprise.
The setup is now complete.
Creating users and user groups in the CMS

During this course, in order to apply universe restrictions sets on users and
groups of users authorized to access universes, you need to create users and
user groups in the Business Objects Enterprise Central Management System
(CMS).
To create users in the CMS

1 Click Start> Programs> BusinessObjects XI Release 2>
BusinessObjects Enterprise> BusinessObjects Enterprise Java
Administration Launchpad.
2 Click Central Management Console.
3 Log in as Administrator. Administrator does not have a password.
4 In the CMC, click Users.
5 Click New User.
6 Type Mary Manager in the Account Name field.
7 Select the Password never expires option.
8 Clear the User must change password at next log~n option.
9 Click OK.
·The CMC will autofill the Password text boxes with blank characters.
10 Click the Users link at the top of the page to return to the page where you
create new users.
11 Create two other new users with the following names:
Hank HR
Stan Sales
xxx Universe Design-instructor's Guide

12 Return to the All Users page and verify that the three new users are in
the list.
13 Return to the CMC Home page.
Now you need to assign these users to appropriate groups.
To create user groups in the CMS

1 From the Home page, click Groups.
2 In the right corner of the All Groups page, click the New Groups button.
3 Type Managers_Group in the Group Name text box and click OK.
4 Create two other groups with the following names:
Employees_Group
Sales_Group
To assign users to groups

1 Return to the All Groups page
2 In the All Groups page, click the Managers link to display the properties
of this group.
3 Click the Users tab.
At present, there are no users assigned to this group because you just
created it.
4 Click the Add Users button.
S Add the Mary Manager user to this group and click OK.
6 Return to the All Groups page.
7 Assign the Hank HR user to the Employees group, following the same
procedure.
S Assign the Stan Sales user to the Sales group, following the same
procedure.
9 Return to the CMC Home page.
To authorize the new users to use Web Intelligence

1 From the CMC Home Page, click BusinessObjects Enterprise
Applications.
2 Click Web Intelligence.
3 Click Add/Remove.
4 For each new group, click the Advanced link to the far right of the group
name on the Web Intelligence page.
S Explicitly grant all Web Intelligence rights to these groups.
To test the new users

1 Log off the Central Management Console.
2 Log onto InfoView and try to create a new Web Intelligence document, to
be sure that the new users are authorized to use Web Intelligence.
Facilities Setup-Instructor's Guide xxxi

If the new users do not appear to have been authorized to use Web
Intelligence:
1 Log on to the CMC again.
2 Return to the BusinessObjects Enterprise ApplicationslWeb
Intelligence page.
3 For each new user, click the Advanced link to the far right of the user
name on the Web Intelligence page.
4 For each user, select the <User name> will inherit rights from it parent
groups option.
This ensures that all new users are authorized to use all Web Intelligence
features.
Getting Help
If you encounter difficulties while setting up your facility, contact your Business
Objects Training Coordinator.
xxxii Universe Design-Instructor's Guide

Lesson 1
!,
'-/ Understanding BusinessObjects
Universes
i To design effective and efficient universes for your business users, you need a
',---,
general understanding of their structure and application. It is also important to
become familiar with the process involved in building a successful universe.
In this lesson you will learn how to:
Understanding BusinessObjects universes
Using the Universe Development Cycle
Duration: 30 minutes
Copyright © 2005 Business Objects. All rights reserved. 1-1

Understanding BusinessObjects universes
Introduction
This lesson gives a general introduction to universes.
After completing this unit you will be able to:
Describe a universe
Describe BusinessObjects Universe Designer interface elements
Save, export and import universes
What is a universe?
The BusinessObjects universe is the semantic layer that isolates business
users from the technical complexities of the databases where their corporate
intormation is stored. -
,"
Universes are made up of objects and classes that map to data in the
database, using everyday terms that describe the business environment. This
means that by using a universe to create a query, users can retrieve exactly
the data that interests them using their own business terminology.
A BusinessObjects universe is a file that contains the following:
Connection parameters to a single data source.
SQL structures called objects that map to actual SQL structures in the
database such as columns, tables, and database functions. Objects are
grouped into classes.
A schema of the tables and joins used in the database. Objects are built from
the database structures that you include in your schema.
Web Intelligence, Desktop Intelligence or Crystal Reports users select the
universe they are authorized to access in order to build queries. They build a
query by selecting objects defined in the universe, and in this way, they are not
required to see or know anything about the underlying da!a structures in the
database.
BusinessObjects Designer XI Release 2 now gives universe designers the
ability to build universes from OLAP and metadata sources. It also offers the
ability to build universes against Unicode databases and run reports that
display data in multiple languages.
Universes are used to query the database

The purpose of the universe is to provide an easy-to-use interface for non-
technical business users to:
run queries against a database
create reports
perform data analysis
As the universe designer, you use Designer to create objects and classes that
represent database structures.
1-2 Universe Design-Instructor's Guide

-..../
J0
'-./
'--/
'--./
'--'"
'--'"
'''-./
-./
'-.../
---../
-..../
---../
---../
-.../
tV
The objects you create in the universe must be relevant to the·end user's
business environment and vocabulary. The role of objects is to present a
business-focused front end to the SQL structures in the database.
Classes and objects

A universe contains the following structures:
Classes
Objects
Classes
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 sub-classes.
Objects
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. Objects and classes are discussed in
more detail in Lesson 4.
How universes are used

Universes are used by Web Intelligence, Desktop Intelligence or Crystal
Reports users. The connection to the database is defined in the universe. By
selecting a universe when they create new documents, or edit existing
documents, business users are automatically given access to the data. The
access to data, in turn, is restricted by the objects that are avaiiable in the
universe. These objects have been created by you, the universe designer,
based on the needs profile for a defined user group.
Advantages of a universe
The advantages of a universe are:
Only the universe designer needs to know how to write SQL and
understand the structure of the target database.
The interface you use to create a universe is an easy-to-use graphical
environment.
Data is secure. Users can see only the data exposed by the universe.
Users can only read data, not edit it.
The results are reliable and the universe is relatively easy to maintain.
Users can use a simple interface to create reports.
All users work with consistent business terminology.
Users can analyze data iocally.
Understanding BusinessObjects Universes-instructor's Guide 1-3

(~
Metadata and the semantic layer

Metadata and semantic layer are two terms that relate to universes.
Essentially, a universe contains metadata and is considered the semantic
layer.
The semantic layer is made up of a number of different types of objects that
are named using end-user business terminology. For the ease of the end user,
these objects are grouped into universes and sub-grouped into classes.
Human
Resources
~
I
('
('
('
(~
('
r
('
~
I
('
('
('
('
('
('

BusinessObjects Universe Designer
components
Before You create, modify, and update universes with Universe Designer. Designer
launching provides a connection wizard that allows you to connect to your database
Designer, it is middleware. You can create multiple connections with Designer, but only one
a good idea connection can be defined for each universe. This database connection is
to launch saved with the universe.
Web
Intelligence Designer provides a graphical interface that allows you to select and view
and build a tables in a database. The database tables are represented as table symbols in
query against a schema diagram. You can use this interface to manipulate tables, create
the eFashion joins that link the tables, create alias tables, contexts, and solve loops in your
universe. schema. Users do not see this schema.
Select at
Designer provides an object explorer view. You use the explorer tree to create
least one
objects that map to the columns and SQL structures that are represented in
dimension
the schema view. Users select these objects to run queries against a
and measure
database.
object, and
use a
predefined Starting Designer
query filter as
well. Explain Designer can only be used with a BusinessObjects repository. You must log
that this is into the repository before starting Designer.
what the
learners will After you start Designer, you can open a universe in one of the following ways:
soon be Create a new universe.
building Import a universe from the repository.
using Open a universe directly from the file system.
Designer,
and that A universe is available to Web Intelligence, Desktop Intelligence and Crystal
users will use Reports users once it has been exported to the repository. Importing a
their universe universe, making changes, then exporting the updated universe to the
to create repository is the most common way of working with Designer.
reports like Note: You can save a universe to the file system. You do this when you are in
this.
the process of developing the universe locally and when you want to
share the universe with other users who may not have connection
rights to the target repository.
Note: You can lock and secure a universe before sending it to the central
repository.
/
To start Designer:
1 Click the Start button on the taskbar.
2 Select the Programs menu.
3 Click the Designer program from the StartlPrograms/BusinessObjects
11/BusinessObjects Enterprise program menu.
The login dialog box for the repository appears.
The default
user name is
Administrator
The default
password is
left blank.
authentication
your
name repository level
of the repository
user name
server
passwor.
thentication Login information
I
User
Password
Name
System
I~
I~
(
~
Note: This information is normally provided to you by the Business I

~
Objects Enterprise administrator.
4 Click the OK button.
The Designer start-up screen appears, and an empty Designer session
opens. The user name and repository name appear in the title bar.
Note: Depending on options set for Designer, the Quick Design Wizard
r ~
can start automatically when you start in Designer. Click Cancel to
r
close the wizard. I

~
Ir--

U sing the Quick Design Wizard
When you start a Designer session for the first time, the Quick Design Wizard
appears by default. You can use the wizard to quickly create a universe or to
familiarize yourself with Designer. However, unless your data source is a very
simple model, it is not an appropriate tool for creating a complete universe that
responds to end-user reporting requirements.
Once you are familiar with Designer, you will probably decide to disable the
wizard and and not use it to design universes. All the universe design, building,
maintenance information, and procedures in this training manual are
structured with the assumption that you have disabled the Quick Design
Wizard.
Deactivating the Quick Design Wizard

You can prevent the wizard from appearing automatically when you create a
new universe as follows:
1 Select Tools> Options
The Options dialog box opens to the General page.
2 Clear the Show Welcome Wizard check box.
Note: This check box is already cleared if you have cleared the Run this
wizard at startup check box from the Startup Wizard Welcome
page.
3 Clear the File/New Starts Quick Design Wizard check box.
4 Click OK.
Note: You can activate the Quick Design Wizard at any time by selecting
the above check boxes from the General page of the Options
dialog box.
Understanding BusinessObjects Universes-Instructor's Guide 1-7

/
Using Designer module commands
There are three ways to issue commands in Designer:
Menu options
Toolbar buttons
Speed menus ~
I
Menu options
You can perform most tasks by choosing options from the menu. The Designer
menu bar looks like this:
Toolbar buttons
The toolbar gives you quick access to many tasks. Designer has three tool bars:
the Standard toolba, the Editing toolbar, and the Formula tool bar..
Right-click menus
Drop-down menus display on your screen when you click the right mouse
button. Drop-down menus usually give you access to options related to the
task you are currently performing. For example, if you click the right mouse
button in the Universe pane, a drop-down menu for creating classes and
objects is displayed:

,---,' Open theand
Designer
universe
parts of the
window.
show
eFashion
-~
'---'
-./
the two
'---'
Designer window
The Universe window is made up of two segments.
On the right- hand side is the pane in which you insert the database
tables and then view the universe structure that infers the FROM and
SELECT clauses into a SELECT statement.
This is known as the Structure pane.
On the left-hand side is the pane in which you create the classes and
objects that users will see when they build queries using this universe.
The objects physically point to the tables you see in the Structure pane.
This is known as the Universe pane.
Manipulating the structure view

There are three ways to manipulate the Structure pane in the Designer
window: toolbar buttons, drag and drop, and by using the Options panel.
Zoom
Often it is not possible to view the whole of the schema at normal magnification
due to its size. Zoom in or out using the drop-down list to choose your
percentage view for the schema.
Arrange tables
You can select this button to have Designer automatically organize your tables
sequentially and horizontally.
Note: You can undo only the last command. If you do not like the results,
choose Undo from the Edit menu.
Drag and Drop

Different views of the universe structure can be achieved by a number of
means using drag-and-drop technology. Generally, this involves pointing to an
item or marking it and then applying a command by double-clicking and
dragging and dropping or right-clicking. For example:
Ctrl-A.
Action
Click it. the
the
Ctrl-click
you want header of the
to highlight.
header table.
of table
each and
tabledrag and
(or join)
Procedure
table or join drop the table to the desired position.
To
To mark
To mark more
move
mark aa join
a
all than
table
tables
single onejoins
and
table

appears
Action
the
View View
columns
If
Bythe
segment view
Right-click
Click the
default,
Table on the
Column
contained
of
the
header
the
the right
Values
acolumn
table
Values
background ofifrequired
within
does
header
ofoption.
table the
header the table.
option.
that
not
table;
you (orshow
table,
aand
and
and
want all
this
structure
scroll
choose
the bar
a choosethe
specified
number is
the
data firstProcedure
,CLIENT_AREA
'CLIENT_ADDRESS
;,CLlENTJIRSTNPME
CLIENT_TOWN
:,CLlENT_AREA_CODE
CLlENT_PHONE_NO
'CLlENT_LASTNPME
100
,CLlENT_ID
times
tables to rows
contained
return
,,.
,
of the
to in
antable.
the
unrolledThis
universe number
view can
structure
of the be
for
umns
a a content
table table
single columnof the
in the table
database columns
table.
number
table
notexpanded
time
of Number
arrow
base, be
Note: this
signified
Note:
as
Options>Database
header.
Alternatively,
soclick rows
margin it
individual
key
segment.
that of
shown
takes
columnsfor
of
appears;
twice of
only
Bydown
To
If by its
indicated
or
highlighted.
all
Rows
the
table
This
sothe
may to
three
achieve
youdefault,
j:'iiBiiii@~i§ffi@;t;ii@ are
columns
reduced
Double-click in
process.
tables)
place
table
areyou
that
view
by
tonot the
below.
tab.
in
this
data
front
table.
Table
the
headercan
and
shown,
only and
bethe
expand
dots are
using
once shown
the
to
then Tools>
roll
option. for
up
double-headed
double-clicking
can pointer
then
a
the
isbe
isadvisable
ending the
atonly
table drag
Double-click
shown.
tableonchoose
altered
number the a
header all
Double-
the
for
due data-
the displayed
abottom
header
large to
of
oftable
the
bottom
three
table
anand
forthe
must the
To
To view
To view
gain the
athe
roll up number
data
partial
a table ofof
ofrows
values
columns
view for
athe
To view the remaining col-
I~
1-10 Universe Design-instructor's Guide

Saving and exporting a universe
You should regularly save your universes during a work session. When you
save a universe, Designer stores it as a file with a .unv extension in your local
file system. This is usually a universe folder in the BusinessObjects installation
path. Any changes you have made to the universe file are saved locally but are
not propagated to the universe version in the repository until you choose to
export it.
When you export the universe, the updated version is also saved on the local
file system, but it is copied to the BusinessObjects Enterprise repository as
well. This version is then available to Web Intelligence, Desktop Intelligence
and Crystal Reports users connecting to the universe.
It is also made available to other universe designers who are authorized by the
Enterprise Administrator to access it.
You should regularly save your changes to a universe locally. Then when you
have finished updating the universe, export the latest saved version to the
repository.
Opening, importing, and exporting universes

If a universe has been previously exported to BusinessObjects Enterprise, the
universe file is associated with the Enterprise repository. The universe is
deployed and available to other universe designers who are authorized to
import it.
If you choose to browse to a copy of that universe file on your local file system
and open it directly in Designer, the file may not be the latest version of the
universe. If you want to make changes to a universe that has already been
exported to the repository, you should not open a universe file directly using
File> Open menu. Instead, you should use File>lmport to ensure that you are
viewing the most recent version.
When you import a universe, the repository automatically copies the latest
version of the universe to the local file system. This file is then opened in
Designer. It is the latest version of the universe contained in the repository. You
should always import a universe and then export it again when you have
finished modifying it, if you want your changes to be available to the repository.
Importing a universe
When you import a universe, you import the latest version of the universe from
the repository. The universe is copied to the local file system, and this file is
opened in Designer.
You can import one or more universes stored in a universe folder in the
repository.
To import a universe:
1 Select the Import command from the File menu.
The Import Universe dialog box appears.
2 Select a universe folder from the drop-down list

OR
Click the Browse button and select a universe using the folder browser.
You want to import a universe from this folder.
3 If you want to lock the universe, double-click the universe name.
A locked universe appears with a padlock symbol. To unlock a universe,
double-click it again.
4 Click the universe name.
This is the universe that you want to import.
S Verify the file path for the import folder in the Import Folder box.
The universe is exported to this folder.
6 Click OK.
Universe file names as identifiers

You should not change the universe file name after reports have been created
based on that universe. If you change the file name, any report built on the
universe with the old name does not point to the universe after its name has
been changed.
To save a universe:
The universe name can be different from the .unv file name.
Designer XI When you use Save As to save the universe under a new name, the new
no longer universe is not associated in the repository. You must export the new universe
requires that to the repository to create a version of the new universe.
the universe
file name be You can use the following methods to save a universe:
8 characters 1 Select File> Save from the menu bar.
or less. 2 Click the Save icon.
3 Press CTRL+S on the keyboard.
Note: Do not save two different universes with the same file name. This leads
to conflicts when you attempt to export these universes to the
repository.
Saving a universe definition as PDF

You can also save the universe information in Adobe PDF format. This allows
you to save to a PDF file the same attributes that are defined for printing
purposes.
Note: You can view the default attributes by selecting the Tools>Options
menu and selecting the PrinUPDF tab. The Options dialog box will be
presented in detail in a later lesson.
The attributes that you can print or save to a PDF file include:
General information - parameters, linked universes, and the graphical
table schema.
Component lists - lists of components in the universe including objects,
conditions, hierarchies, tables, joins, and contexts.
Component descriptions - descriptions for the objects, conditions,
hierarchies, tables, joins, and contexts in the universe.
Saving these attributes as a PDF file may be helpful for troubleshooting or
maintenance purposes.
J
To save universe information as a PDF file:
1 Select File> Save As.
2 Select Portable Document Format (PDF) from the Save as type drop-
down list.
3 Click Save.
Giving all users access to a universe

If you want to make a universe available to universe designers who may not
have access to your Central Management System, you must save the universe
with an unsecured connection. Different types of connections are presented in
a later lesson in this course.
To make a un!verse accessible to all Designer users:

1 Verify that the universe that you want to make available to all users does
not have a secured connection.
Secured connections are required to export universes to the repository. If
a universe has a secured connection, select or create a new personal or
5 shared connection.
4
-...../
23 Note: Creating connections is discussed in detail in a later lesson.
Select File> Save As.
J'-./
'--/
'--/
'-./
'---'
'---./
---./
'-../
'-.../
-...../
A File Save dialog box appears.
Select the Save For All Users check box.
Click OK.

Practice
Activity: Viewing a universe in Designer
Objectives
By the end of this activity, you will be able to:
Open a universe and identify universe elements in Designer.
Instructions
1 Open Designer.
2 Open the eFashion.unv file found in the default installation folder:
C:\Program Files\Business Objects\BusinessObjects Enterprise
11.5\Samples\en\Universes
Or, find the same file on the Resource CD for this course.
3 Explore the menu options, toolbar buttons, and right-click drop-down
menus.
4 Select View>Toolbars, and ensure that all three toolbars are selected.
5 Zoom to 125% (type directly into the field instead of using the drop-down
list).
6 Click the Arrange Tables button to automatically organize tables.
7 Click the View List Mode button to list all Tables, Joins, and Contexts.
8 Click the Article_Color_Lookup table in the Tables list and to see it
highlighted in the structure below.
9 Right-click the Article_Color_Lookup table to view Number of Rows in
Table (Refresh row count for all tables).
10 Right-click the Article_Color_Lookup table to view a sample of Table
Values.
11 Open the Product class to view the objects it contains.
12 Double-click the Color object (notice the name, description, and select
fields).
13 Select Parameters on the File menu and change the universe long name
to New eFashion.
14 Close the universe.

Using the Universe Development Cycle
Introduction
Universe development is a cyclical process that includes planning, designing,
building, distribution, and maintenance phases. Use Designer to design and
build a universe. However, the usability of any universe is directly related to
how successfully the other phases in the development cycle interact with each
other.
After completing this unit, you will be able to:

Use the Universe Development Cycle.
The Universe Development Cycle

This unit presents an overview of a universe designing methodology that you
can use to plan and implement a universe development project.
The table below outlines the major phases in a typical Universe Development
Cycle:
Know what
Understand
Familiarize
Identify what ·
data
limitations.
theproject
a target is
yourself
user
the contained
standard
information
joins.
population
strategy.
withreports
cardinality.
data within
company
the
For
90urce and
users
users each
example,
andhow
business
need. table
require.
it isthe
become of
structured.
number
familiar
Phase
Analysis
Planning
· ofDevelopment
with
level.
For
each
shouldits
departmentstructure.
universes
example,
ofhave
terminology
Preparation
orthat
isby
the target
the
so the
Description
should be
username
capacity
you task?
can created
group
databases. and
structured
to beobjects
linked and which
by
to what
sensibly. ones
Understanding BusinessObjects Universes-Instructor's Guide 1-15

Test
Buildfrequently .
the universe during
using
the Designer.
build
theprocess
This guide
for validity
covers
Phase
tion Maintenance
Deployment
Updating!
Testing
. Development
they
power
form expect
thorough
actual users to
and reliability
where use
it canof
Implementa-
whoget
tests
the
beof
Form
and
have
from
this
Update a small
user
Distribute part
and
Description
simulating
some
thetool.
inferred
design
accessed
group
ofuniverse
requirements
themaintain
universe.
byknowledge
SQL. live use
of
Universe
Ask
end-users.
users,
thechange
by
ofofthe
what
preferably
Development
universe
users
and
exporting asgrow.
universe(s).
information
to per-
Web
it the
to Cycle,
Intelligence
data
the the
sources
repository,
Stress with The analysis of user requirements and design are the most important stages
learners the in the process. Users must be heavily involved in the development process if
importance of the universe is going to fulfill their needs both with the business language used
using a to name objects and the data that can be accessed.
phased or
iterative Implementation will be successful if the first three stages are carried out
approach properly. It is advisable to spend 80% of the time allocated to the development
during of a universe on the first three stages:
universe preparing
design and analyzing
development.
planning
If you have spent the appropriate amount of time in laying the foundation for
your universe, the remaining 20% of the time spent actually using Designer to
build your universe will be much more productive.
r---
I

Practice
Activity: Plan a universe
Objectives
By the end of the activity, you will be able to:
Use the first three stages of the Universe Development Cycle
Instructions
Familiarize yourself with the following checklist of questions you need to ask
when you begin designing a universe:
What are the target data sources for your universes?
What is the schema/structure of each of these data sources?
Do you know the contents of each of the tables?
Do you know how each of the tables are interrelated?
Are you familiar with all of the necessary joins?
Are you familiar with the cardinality of each of these joins?
Have you procured database schemas from the database administrators
who administrate the data sources?
Are you familiar with your different user populations and how they are
structured?
Do you know what standard reports are required?
Do you know what the users' ad-hoc information needs are?
Are you familiar with their business terminology and formats?
Have you considered how many universes need to be created to address

users' needs?
Have you considered how long universe development may take?
Have you considered which universes should be developed before
others?
Have you considered who should test your universes for you?
_____
I Have you considered how data sources and/or user requirements may
change over time?
Do you already have all of the information necessary to implement your
universes?

Lesson summary
Review
Quiz: Understanding BusinessObjects Universes

1 What are the two main windows in Designer?
Answer:
Universe pane, Structure pane
2 What are the three ways to issue commands in Designer?
Answer:
menu options, tool bar buttons, right-click drop-down menus
3 Where can you define what specific information about the universe gets
printed?
Answer:
Under Tools>Options>Print
Summary
Recap the After completing this lesson, you are now able to:
lesson Describe a universe
objectives
with the Describe BusinessObjects Universe Designer interface elements
learners as a Save, export and import universes
check that all Use the Universe Development Cycle.
learners have
acquired the
required
skills before
moving on to
the next
section.

Lesson 2
Creating the Course Universe
This lesson introduces you to the database that is used in this course. It teaches
you how to create a new universe and define a connection from the universe to
the course database.
To create a new universe and maximize its potential, it is necessary to learn
about parameters. Parameters allow you to set the structure of your universe,
including setting up a database connection.
In this lesson you will learn about:
The course database and universe
Creating the universe

The course database and universe
Introduction
In order to create a SusinessObjects universe, you must first be very familiar
with the data and structure of the database to which the universe will be
connected.
You also need to fully understand the users' reporting requirements.

Understand the database you will use during this course
Know the specification of the universes you will build during the course
Course database description

During this course, you are going to build universes to report on a database for
a fictional car sales and rentals organization called Prestige Motors. The
database has the following characteristics:
It has three showrooms, two in the US and one in the UK.
Each showroom has the franchise for a number of different car makers,
who all manufacture a number of different models, available in a range of
colors.
No new models have been brought out during the period.
Customers may either rent or buy cars.
Customers will usually rent or buy from the showroom in their own
country but this is not always the case.
The database contains data for two financial years 2003/2004 and 2004/
2005. Each year begins on April 6 and ends on April 5 in the subsequent
year.
Information about employees who work within the organization is also
available in the database.
There are summary tables for quarterly and annual revenue and numbers
to speed up queries.
The data is stored in an Microsoft Access database.
Connections to the database are to be made using ODSC.
Assumptions
There has been no inflation over the different years for which data is held.
There is no stock data. All manufacturers are able to supply on demand.
Users in all countries use the same currency (the US dollar).

Analysis of reporting requirements
Following an analysis of the company's reporting needs, the following
specification has been identified.
1 Ad hoc reports are required on Models.
These are required to list the cars for sale and rental.
Such reports may include the following:
Manufacturer, Model, Trim, Engine Size, Available Colors, Sale/
Rental Price.
Reports may be grouped by price range and style (for example,
sport, estate, etc.)
These reports will be used to show potential customers model
availability and for general management reporting.
2 A report is required which will list the showrooms, their location and which
manufacturers they have a dealership agreement with. This report will be
created by the universe designer and distributed as a corporate
document for all to read and refresh.
3 Ad hoc reports are required on car sales.
These are required to list car, sale and customer details.
Reports may be grouped according to customer, showroom, sale,
model and manufacturer dimensions.
These reports will be used to analyze results at all levels from sales
specific details to general high level reports such as sales revenue
per annum, per showroom, by manufacturer, by car and so on.
4 Ad hoc reports are required on car rentals
These are required to list car, rental and customer details.
Reports may be grouped according to customer, showroom, rental,
model and manufacturer dimensions.
These reports will be used to analyze results at all levels from
specific rentals details to general high level reports such as rentals
revenue per annum, per showroom, by manufacturer, by car, and so
on.
Reports related to 2, 3 and 4 above will be used by Sales Staff,
Finance Department and Managers.
5 Ad hoc reports on employees.
The employee reports will only be available to Managers and the
Personnel Department staff.
Therefore a different universe will be used so that only these people
have access to this data.
The specification for this universe will be given to you as part of the
Final Challenge for this course.
Note: Most users will be required to run reports on both sales and rentals.
Creating the Course Universe-instructor's Guide 2-3

· .Development plan
The remainder of this course will be spent developing universes for this
imaginary deployment. In accordance with the iterative approach, the
development will be phased as indicated below.
1 Design and develop a universe which enables Web Intelligence users to
build reports which meet requirements 1 (model reporting) and 3 (sales
reporting). The universe needed to do this can be regarded as relatively
simple to create.
2 Extend the universe to meet reporting requirements 2 (franchise
reporting) and 4 (rental reporting). This will require the introduction of
loops, chasm and fan traps into the universe structure which need to be
resolved. This will constitute a fairly complex universe structure.
3 Further extend the universe to refine and enhance the universe for end
users by introducing conditions, LOVs and hierarchies for drilling.
4 Optimize the processing speed of universe queries via the introduction of
summary/aggregate tables.
5 Design and develop a universe for Web Intelligence users that enable
them to build reports which meet requirements 5 (ad hoc reporting on
employees). The universe needed to do this will encompass a lot of the
universe design techniques covered in the previous phase and will
constitute the Course Challenge exercise.
6 Deploy all universes to BusinessObjects Enterprise and consider
maintenance of those universes once deployed.

Creating the universe
Introduction
In this unit, we will begin to create the course universe, based on the analysis
of business requirements and the development plan above.
To create a new universe, you must first define a number of parameters, such
as the parameters to be used to connect to the data source.
Create a new universe
Create a new data source name
Create a new connection in Designer
Describe the universe parameter settings
Defining universe parameters

When you create a new universe, first you define a number of parameters to
identify the universe and its database connections, specify the type of queries
that can be run using the universe, and set the controls on the use of system
resources.
An important element of this setup process is selecting the kind of database

connection you will use.
To begin creating a new universe:

1 In Designer, select New from the File menu.
The Universe Parameters dialog box displays:
Creating the Course Universe-Instructor's Guide 2-5

Note: Make sure the Universe Parameters dialog box displays with the
Definition tab active.
2 In the Name field, enter a name for the universe.
For the purposes of this course, name the universe Motors2004_XX,
where XX stands for the initials of your first and last name.
Note: You can enter over 100 characters and there are no character
restrictions.
3 In the Description field, enter a brief description for the universe.
This is used as a help description for the end user. It needs to accurately
describe the content of the universe using terminology the end user will
easily understand.
4 Set the connection, as described in the next unit.
Select an existing connection or create a new one. The other parameters
can be set at this point but are better done at a later point in the universe
building process.
Setting the database connection

In order to connect to the database for which you intend to build a universe,
you need to create a BusinessObjects connection. The BusinessObjects
connection defines the Data Source Name and the middleware that is required
to access the data source.
If you are building several universes to front-end the same database, then the
connection may already exist. Therefore, you only have to select it from the
available connections. However, if the connection does not exist, you will have
to create one.
To create an ODBC connection:

1 Click Start> Programs> Administrative Tools> Data Sources
(ODSC).
2 Click the System DSN tab.
3 Click Add.
4 Select Microsoft Access Driver (*.mdb). Click Finish.
5 In the Data Source Name field, type a name that identifies the database
to which you want to connect.
For the purposes of this course, make the data source name:
MotorsDSN.
6 Click Select to specify the location of the data source.
For the purposes of this course, browse to the course Resource CD and
select the Motors2004.mdb file:
7 Click OK.
You have created a new system data source name. Now you can proceed to
define a connection to the data source in Designer.

To define the connection in Designer
1 In the Universe Parameters dialog box, verify that the Definition tab is
selected.
2 Click New.
Note: You can also create a new connection from the Connections dialog
box. Select Tools> Connections and click the Add button in the
Connections list.
The Welcome page of the Connection Wizard appears.
3 Click Next.
The Database Middleware page appears. It lists the database and
middleware that correspond to your Data Access driver key.
4 Expand the node for the target database for the connection.
The supported middleware for that database appears under the node. In
this case, select Microsoft 2002 DDSC middleware.
5 Expand the node for the target middleware for the connection.
The Data Access driver for the middleware appears.
dJotit IBM
iJ.;:1I Informix
E}··.i'ID Microsoft
. ffi @MS Access 2000
6 .@ MS Access 2002
,....~ . ODBC Drivers
1£ .. @.MS Analysis Services 2000
1£ . @ MS SQL Server 2000
!£ . @ MS SQL Server 7,x
11,,,,,% ~1ySQL
I£.§} NCR
l£i1l Oracle
f:B.@ SAP
l£·it'3 Sybase
6 Select a driver name (DDSC in this case) and click Next.

The Login Parameters page appears.

To define the connection parameters:
In the Define a new connection box:

1 Select the connection type from the Type list box.
Note: In order to deploy a universe to the BusinessObjects Enterprise
server, you must define this connection Type as "Secured". See
further explanation below.
2 Type Motors2004_conn to define a name for the connection.
You can enter up to 35 characters.
A user name and password is not required for this database connection.
These are normally assigned by your database administrator.
3 In the Data source name field, select the DSN you created in Windows,
in this case, MotorsDSN.
4 Once you have entered this information, click Next.
Note: For more information about defining the login parameters, refer to the
text below.

--,
More about connection types

The connection type determines who can use the connection to access data.
You can create three types of connections with Designer: personal, shared,
and secured.
Personal connections
Use personal connections to restrict data access to the universe creator and
the computer on which it was created.
You do not use personal connections to distribute universes. Use personal
connections:
to access personal data on a local machine
to access specific database accounts to test an SOL sample through the
Free-hand SOL option in BusinessObjects
Shared connections
Allow access to data for users. These connections are unsecured. Shared
connections can be useful in a universe testing environment.
Secured connections
Secured connections centralizes and control access to data. They are the
safest type of connection. Used secured connections to protect access to
sensitive data.
You can create secured connections with Designer.
Connections are stored in BusinessObjects Enterprise. These can be shared
with other designers with the appropriate privileges.
You must use secured connections if you want to distribute universes through
BusinessObjects Enterprise. Secured connections can be used and updated
at any time. To define a secured connection you must be using
BusinessObjects products in Enterprise mode.
After you have chosen your connection type and clicked Next, the Perform a
test page appears. It summarizes the information for your connection and
allows you to verify that the connection is valid.

To test the new connection
I'~
Perform a test
A connection can now be created. You can perform a test to verify the
data source server. .
In the Perform a test dialog box:

1 Click the Test connection button.
If the connection is valid, a message dialog box appears indicating that
the connection is correct. If you receive an error message, check that you
entered all the parameters correctly. If the error persists, refer to the
section of your RDBMS documentation relating to error messages.
2 Click Next.
The Advanced Parameters page appears.

3 Set the connection time and array fetch.
You can accept the default advanced settings or select from the advanced
options.
4 Click Next.
The Custom page appears.
5 Customize the settings for listed parameters or accept the default
settings.
Custom Parameters
Define custom parameters to access your middleware
6 Click Finish.
If you created the connection from the Universe Parameters dialog box,
the Universe Parameters dialog box appears with the new connection
listed in the Connection box.

If you created the connection from the Connections dialog box, the new
connection is now in the list. Click Finish to close the list.
Note: Avoid creating two different secured connections with the same
name. For example, one connection named Status and the other
named status. This leads to a conflict in the repository.
Viewing available connections

You can view all available stored connections in the Connections list. You can
edit existing connections, and create new connections.
To view available connections

1 Select Tools> Connections.
The Connections list appears. It displays all the connections available to
the current universe.
You can add new connections or edit existing connections from the
Connections dialog box. You cannot modify the name of an existing
connection.
2 Click Cancel to close the dialog box.
To edit a connection
The Connections list appears.
2 Click a connection name in the list of available connections.
3 Click Edit.
The Login page for the connection appears.
4 Type a new data source or database name in the Data Source box if
required.
5 Type modifications to login parameters as required.
6 Click Next.

The Perform a Test page appears.
7 Click the Test Data Source button to verify the modified connection.
S Click Next to move to the Advanced and Custom pages. You can modify
parameters as required. You can also accept the default or existing
values.
9 Click Finish from the Custom page to apply the changes to the
connection.
Note: When you edit an existing connection, you cannot change the name or
the type of connection.
To delete a connection
The Connections list appears.
2 Select a connection name in the list.
3 Click the Remove button.
A confirmation dialog box appears.
4 Click Yes.
The connection is removed from the list.
Universe parameters
This unit describes the parameters that you can define using the different tabs
available in the Universe Parameters dialog box.
For more detailed reference information about these parameters, refer to the
Business Objects Designer's Guide.
Universe Parameters dialog box

There are seven tabs on the Universe Parameters dialog box that allow you to
change different parameters. This lesson provides a brief introduction to these
tabs. They are discussed in more detail later in the course.
This table provides a quick snapshot of the different tabs:
universe
Settings
SQL
Strategiesstatistics.
Limitations
Description
Types set
parameters
ofand
Universe
Version defined
queries
used
name, for
by the
for
that
that
revisionthe use
linked
the of system
universe.
canend
description, is resources.
universes.
be user
dynamically
Adesigner
strategy
allowed
connection
information, isconfigured.
a
toscript
run. and
parameters,
comments, used
and
toParameter
extract structural
information. information identify
These parameters from a database.
the universe.
Information
Parameter
Links
Controls
SQL
Strategies
Definition
Summary

Summary tab
The Summary page displays universe administration information.
Revision
Date
Universeofofthe
Information
List
Description last
number
modification
creation
number
about indicates
date
the and andthe
of classes,
universe the
the number
name
name
objects,
for ofthe
times
the
oftables,
yourself modifier.
orcreator.
another
aliases,
Information
Include
universe.
joins,
the
that
designer.
Description
and information
universe
you
bycontexts,
whom,
can
This
field
has
use about
information
ifand
you
on
been
it tothe the
hierarchies
so
track
exported universe
Identification
desire.
ischanges
only
contained for in
toavailable
themade
page. users
repository.
tointhe
the in the
Designer.
universe
Revision
Modified
Statistics
Comments
Created You can print the text contained in this box, which means

Strategies tab
Selecting strategies
A strategy is a script that automatically extracts structural information from a
database or flat file. Strategies have two principle roles:
Automatic join and cardinality detection
Automatic class, object, and join creation
Strategies are useful if you want to automate the detection and creation of
structures in your universe based on the SOL structures in the database.
Strategies that automate the creation of universe structures are not
necessarily an essential part of universe design and creation. They are useful
if you are creating a universe uickl, and you want to use metadata --.--
information at already exists in ::!n::!t::!h::!seor database desiqn tool.
However, if you are building a universe by creating objects and joins that are
based on relationships that come directly from a user needs analysis, then you
will probably not use the automatic creation possibilities that the Strategies tab
offers.
Built-in strategies are the default strategies that are shipped with Designer.
You can select them by clicking the drop-down menus in this Strategies
Parameters tab. There are built-in strategies for all supported databases,
which cannot be modified. You can, however, create custom strategies, which
are known as external strategies. Built-in strategies appear by default before
external strategies in the drop-down lists.
Note: The built-in strategies for detecting joins will only select on matching
column names, ignoring all other column names, and may create
unnecessary joins.
Note: For detailed information about selecting built-in strategies, as well as

creating external strategies, refer to the Business Objects Designer's
Guide.

Controls tab
On the Controls tab, you can limit the result size and execution times for
queries that use this universe.
The Limit execution time option allows you to restrict the execution time for
queries generating more than one SOL statement.
The time limit that you specify for query execution is the total execution time
for a query. If the query contains multiple SOL statements, then each
statement is given an execution time equal to the total query execution time
divided by the number of statements. The result is that each statement in the
query has the same execution time.
If one statement requires a lot more time than others to run, it may not
complete as its execution time will not correspond to its allotted execution time
within the query.
When you specify an execution time limit for multiple SOL statements, you
need to take into account the normal execution time of the single statement
that takes the longest time to run, and multiply this value by the number of
statements in the query.
If you set the Warn if cost estimate exceeds option, a message informs the
user if the query is likely to take more than the number of minutes you specify
here. This mechanism is dependent on whether the database statistics are up-
to-date.
\ 2-16 Universe Design-Instructor's Guide

SQL tab
Indicating SQL restrictions

You can set controls on the types of queries that end users can build in Web
Intelligence and Desktop Intelligence.
You can indicate controls for the following areas of query generation:
Use of subqueries
Use of operators and operands in individual queries
Generation of multiple SQL statements
Selection of multiple contexts
Prevent or warn about the occurrence of a Cartesian product
Note: The "Multiple SQL statements for each measure" optionis selected by
default. Accepting this default value could potentially impact query
performance. This issue will be described in later lessons.

Links tab
Links parameters are used to specify dynamic links between universes related
to the same database. This allows a universe and its content to be embedded
in another universe. Embedding universes saves on maintenance where some
objects are used in many universes.
'-

Parameters tab
In Designer, you can dynamically configure certain SOL parameters that are
common to most databases to optimize the SOL generated when utilizing
them. These parameters apply only to the active universe, and are saved in
the .unv file. The parameters that are available from this page are no longer
listed in the PRM file for the target database.

Practice
Activity: Create a new universe and define its connection
Objectives
Create a new universe and define its connection to the database.
Instructions
1 Copy the Motors2004.mdb file from the resource CD into a folder on the
C:\ drive.
2 Create a DSN called MotorsDSN.
3 Start a Designer session.
4 Log into the Enterprise server.
S Create a new universe and define the following parameters:
Name = Motors2004
Description = This universe provides information on the Prestige
Motor Cars Database for Showrooms, Models sold, Rental and Sales
Business
Connection = Motors2004
Tip: Use the New Connection Wizard to create the Motors2004 connection
against the Motors2004.mdb.
6 Save the new universe in a file called Motors2004.unv.
7 Create another new universe and define the following parameters:
Name = Staff2004
Description = This universe provides information on the personnel of
Prestige Cars.
Connection: Motors2004
8 Save the second universe in a file called Staff.unv and close it.

Lesson summary
Review
Quiz: Creating the Course Universe

1 Information about universe administration appears on the Universe
Parameters dialog box. Under which tab can you find this information?
Answer:
Summary
2 Can a universe and its content be embedded in another universe?
Answer:
Yes, you can set this up in the Links tab of the Universe Parameters
dialog box. Remember that both universes must reference the same
database account or targeted data source.
3 If you want to distribute the completed universe to the user population
using BusinessObjects Enterprise, which type of connection should you
use?
Answer:
asecured connection
Summary
After completing this lesson, you are now able to:
Understand the database you will use during this course
Know the specification of the universes you will build during the course
Create a new universe
Create a new data source name
Create a new connection in Designer
Describe the universe parameter settings

Lesson 3
Building the Universe Structure
This lesson describes how to add tables to the universe structure and how to
customize the way you work with tables.
Populating the universe structure
Defining joins in a universe
Duration: 1 hour

Populating the universe structure
Introduction
A schema is a graphical representation of a database structure. In Designer
you create a schema for the part of the database that your universe represents.
Design a schema
Add tables in the Structure pane
Organize your view of tables
Designing a schema
The schema contains tables and joins. The tables contain columns that you
eventually map to objects that end users use to create reports. The joins link
the tables so that the correct data is returned for queries that are run on more
than one table.
Design the schema in the Structure pane by selecting tables from the target
database using the Table Browser. You create joins to link the tables. When
you have designed the schema for your universe, you can verify the schema
using an automatic integrity check.
Good schema design is essential to good universe design. Populate the
schema with tables based on the columns that correspond to the objects that
end users need to create reports. These objects should be defined from a user
needs analysis. Examine the database for tables that allow you to create these
necessary objects.

Schema design and the universe creation process
Creating a schema is the first phase of the implementation stage of the
Universe Development Cycle. The user analysis and planning phases can be
done without using Designer, however, creating your schema is the first step
in which Designer is used to build your universe.
The following diagram indicates where the schema design phase appears in a
typical universe development cycle:
Imp I e mentation I User

~ ~ Preparation feedback
I
using Designer Maintenance
~
'-.J
'-.J
loops
Building the Universe Structure-Instructor's Guide 3-3

Adding tables
The Structure segment of the Universe window is used to create a visual
representation of the part of the database that the universe represents. When
you create a new universe the Structure is empty and you need to populate it
with the appropriate tables. Database tables are placed in the Structure using
the Table Browser, which provides a list of tables in the database.
The Table Browser is an independent window that shows a tree view of the
tables and columns in your target database. Use the Table Browser to view and
select tables in your database that you want to insert into your schema.
Expand the node next to a table name to display the columns for the table.
To open the Table Browser

The Table Browser is not visible by default. You must activate the Table
Browser when you want to add tables to the Structure pane. You can activate the
Table Browser using any of the methods listed below.
1 Verify that the Motors2004 universe is open in Designer.
1 Click Table Browser button on the Editing tool bar.
OR
Double-click the background area of the Structure.
OR
Select Insert> Tables from the menu bar.
The Table Browser displays:.
D:\Universe Design\Sour
rBu ABSENCE
I±JL;! ..6.NNUALJIGURES
'u ANNUAL_SALARY
.w CLIENT
rBL;!' COLOUR
ffiL;! COUNTRY
$u DEPARTMENT
ffiL;! EMPLOYEE
$pL;! FINANCE_PERIOD
EBw FRANCHISE
$·0 JOB
['flu LOOKUP
$r;:J'MAKER
lEw MODEL
MODEL COLOURS
From the Table Browser you can select tables to include in the Universe
schema. You can insert a single table or multiple tables simultaneously.

To insert a single table
1 Click a table and drag it into the Structure pane.
OR
Double-click the background area of the Structure.
The table appears in the Structure pane.
To insert multiple tables

1 Hold the Shift key while you click the first table and last table to select a
continuous block of tables.
Multiple tables are selected.
Note: The Ctrl key also can be used here to select multiple tables.
2 Click Insert.
Each table including all of its columns appears in the Structure pane. In the
Table Browser, any table that you insert in the universe displays with a check mark
beside its name.
Note: Columns cannot be selectively chosen. When you select a table, all
columns will be included in the structure.
Viewing data from the Table Browser

You can use the Table Browser to view the data contained in a table, or in an
individual column.
To view data from the Table Browser

1 Expand a table node in the Table Browser and right-click a column or the
entire table.
2 Select View Table Values from the contextual menu.
A dialog box appears listing the data contained in the table or column.
'---' 10 .4
637829452.5
.8
.5
911
.4
Bentley
Forrester
Cherokee
V70
1199755
98763Carrera
64805
18225
21920
16995
26525
22800
19500
145005
71605
55005 ••..
. j! ----
IUOI ,
'u,
,,·qlU:1l
:::::::~
1052
V70
'---'
'--./
'---'

When a table has been placed in the Structure, it shows the names of the
columns it contains and their data types.
CLIENT _10
CLIENT _LASTNAME
CLIENT JIRSTNAME
CLIENT_ADDRESS
CLIENT _ TOIJN
CLIENT_AREA
CLlENT_AREA_CODE
CLIENT _PHONE_NO
REGION_ID
EMPLOYEE_ID
CLIENT_AGE
COUNTRY_ID
You can use various commands to manipulate tables within the Structure.
These are described in the sections that follow.
To select tables
Usually the first step in moving, copying, or deleting tables is to select them.
To select a single table, click the table header.
To select several tables, press Ctrl and click the table header of each
table you want to select in turn.
To select several tables that are graphically close together, use click and
drag to select multiple tables.
To select all tables, press Ctrl + A or choose Edit> Select All from the
menu bar.
To deselect a table
1 Click the background of the Structure.
To move tables
1 Select the tables you want to move.
2 Drag the tables to a new position.
To delete tables
1 Select the tables you want to delete.
2 Press the Delete key.

Organizing your tables
There are several options that enable you to obtain a better view of your tables:
Use drag and drop to move the tables around the Structure.
Click the Arrange Tables button to arrange tables horizontally.
Select from the Zoom drop-down list to minimize or magnify

the Structure.
Changing table display

You can change tables so that they display all columns of a table, the table
name only, or the primary and secondary keys Goin columns) only.
Select View> Change Table Display from the menu bar.
OR
Press Ctrl + T.
Table name displays:

CLIENT
Join columns only display:

CLIENT
i REGION 10
rCOUNTW)O
EMPLOYEE~IO
j,1'-'LlENT 10
Viewing table values

You can view the data for a database table or column in the same way as in
the Table Browser.
To view table values

1 Right-click the header of the table whose values you want to see.
The following menu displays:
Building the Universe Structure-instructor's Guide 3-7

2 From the menu, choose View Table Values.
Gregory The
Don
Sarah
Neil
Osaka
34
Bedfordshir
Berkshire
Hertfordshil
'w'atford
D Satoru
T
London
Keith
Bob59
Isao
Steve
12
Reading
High
M 32435
Kenii
Tokyo
94 Gables
Leith
atsuo
unstable
45
10
190 Kawasaki
Downs
Hamilton
Sutton
asayuki
'w'yco Road
Yamamoto
Yorkshire
Toyota
Toyota
Apple
Toyota...Row
Ave
Grove ......
Road
P...
A
Blvd ...
'w'atts
Smith
Okumura
Thomas Johnson
Kamimura
Mukumoto
Makino
Oneda
Philips
Armstrong
3 Click Close.

Practice
Activity: Building the universe structure
Objectives
Insert tables into the Motors2004 universe.
Instructions
1 Insert the tables listed below into the Motors2004 universe.
COUNTRY
REGION
CLIENT
SALE
SALE_MODEL
COLOUR
MODEL
MAKER
STYLE
-
SALES PRICE RANGE -
SHOWROOM
FINANCE_PERIOD.
2 Order the tables so that they are laid out in the same way as the
illustration below.
~t~~~ro~~~bb
FP START
FP ::END
: FP YEAR
: FP -QUARTER
: FP :MONTH
mE}:::::·:·:····
SAlE.JD
CLIENT-ID
SALE-DATE
SHOWROOt-LID
SAlE.....SAL.E.....DISCOUNT
SALE-TYPE
<;:;:;:;:;:::t:W#Rytm SALE-TOTAL
:::OUNTRY_ID SALE-RENT AL-PERIOD
:OUNTRY_NAME
3 Save the changes to the universe.

Defining joins in a universe
Introduction
After you have inserted more than one table in the schema, you need to create
joins between related tables. Ajoin is a condition that restricts the result set of
a multi-relational query. Joins are as important as tables in a schema because
they allow you to combine data from multiple tables in a meaningful way.
Understand why you need joins in the universe structure
Create joins
Set join cardinalities
Explain the join types
View the join expression using List Mode
Check the integrity of the universe structure and joins
About joins and SQL Where clauses

SQL specifies a join implicitly in a WHERE clause through a reference to the
matching or common columns of the tables. Normally there is one WHERE
clause for each pair of tables being joined. For example, if four tables are being
combined, three WHERE conditions are necessary.
If you run a query in Web Intelligence that involves inferring a SELECT
statement on two tables that have not been joined in the universe structure, the
resulting report will produce a Cartesian product, that is, a nonsensical
question resulting in nonsensical data, as illustrated below. In other words, it
will output a report that joins every column in the first table to every column in
the second table.
To prevent this from happening, you need to specify a join between the tables
in the Structure pane in Designer.

Creating joins
You have several approaches to creating joins in Designer:
Tracing joins manually in the schema
Defining join properties directly in the Edit Join dialog box
Using the Join SQL Editor to specify the join expression
Each of these approaches is described in detail below.
Tracing joins manually in the schema

You can graphically create individual joins between tables by using the mouse
to trace a line from a column in one table to a matching column in another table.
To create a join by tracing manually

1 Position your mouse over the COUNTRY _ID column in the COUNTRY
table. This is the column you want to be at one end of the join.
The pointer appears as a hand symbol.
2 Click and hold down the left mouse button.
The COUNTRY _ID column the COUNTRY table is highlighted.
3 Drag the mouse to the COUNTRY _ID column in the REGION table.This
is the column that you want to be at the other end of the join.
As you drag, the pointer changes into a pencil symbol.
REGION_IO
REGION_NAME
COUNTRVJO
4 Position the pencil symbol over the COUNTRY _ID column in the
REGION table.
The target column is highlighted.
5 Release the mouse button.
The join between the two tables is created. Note that the definition of the
join appears in the Formula toolbar.
6 Double-click the new join.
The Edit Join dialog box appears. It lists join properties.
Note: The properties that you can set for a join, including cardinality and
join type, are described in this or the following section. The Edit
Join dialog box displays the default properties of the join.
7 Click OK to close the Edit Join dialog box.
8 Click the new join and press the Delete key to continue the exercise.

Creating the join by defining properties
You can also create a join by directly defining the join properties in the Edit Join
dialog box.
To create a join using the Edit Join dialog box

1 Select Insert> Join.
OR
Click
The Edit Join dialog box appears.
2 Select the COUNTRY table from the Table1 drop-down list.
The columns for the COUNTRY table appear in the list under the table
name.
3 Click COUNTRY _ID, the column that you want to be at one end of the
new join.
4 Select the REGION table from the Table2 drop-down list.
The columns for the REGION table appear in the list under the table
name.
S Click COUNTRY _ID, the column that you want to be at the other end of
the new join.
The join expression is dynamically built in the zones below and can be
modified as necessary.
Note: The properties that you can set for this join, including the join
operator, cardinality, and join type are described in the following
sections of this lesson.
6 Click OK.
The new join appears in the schema linking the two tables and columns
that you specified in the Edit Join dialog box.

Note: Another method for inserting a join is to click the first table in the
Structure pane, hold down the Ctrl key, click the other table, then click
Insert Join. The two tables are automatically entered in the Edit Join
box and you can edit the join properties as required.
About join properties

You can define the following properties for a join.
Table1 Table at the left end of the join. Columns are listed
for the table selected in the drop-down list.
Table2 Table at the right side of the join. Columns are listed
for the table selected in the drop-down list.
Operator Operator that defines how the tables are joined. The
operators available to a join are described in the
section.
Outer Join When selected, determines which table contains

unmatched data in an outer join relationship. Outer
joins are described fully in the section.
Cardinality When selected, allows you to define the cardinality

for the join. Defining and using cardinalities is
described in the section.
Shortcut Join Defines the join as a shortcut join. Shortcut joins are
described in the following section.
Expression WHERE clause used to restrict the data that is

returned when the two joined tables are included in
a query.
This clause can be edited as necessary.
Join operators
Select an operator for a join from the drop-down list between the Table1 and
Table2 boxes. The operator allows you to define the restriction that the join uses to
match data between the joined columns.
You can select the following operators for a join:
<
>=
<=
>
=
--- I is equal
less
is greatertothan
than
not equal or
to equal to to
or equal
!=

Between is between (theta joins)
Complex complex relationship
Editing the join expression

Use the Edit Join dialog box to define and edit join properties. You can also
access the Join SQL Editor to edit join syntax directly from this dialog box.
Edit and parse

The Edit Join dialog box also has two features available that allow you to edit
and verify the join syntax:
Edit
The Edit button opens an SOL editor. Use this graphic editor to modify the
syntax for tables, columns, operators, and functions used in the join.
Parse
The Parse button starts a parsing function that verifies the SOL syntax of the
join expression. If the parse is successful, you receive a result is OK message. If
Designer encounters an error, you receive an error message indicating the
source of the problem.
Using the Join SQL Editor

You can use a graphical editor to directly modify the SOL expression for a join.
You access this editor from the Edit Joins dialog box.
To modify a join using the Join SQL Editor:

1 Double-click the join you just created between the COUNTRY and
REGION tables.
The Edit Join dialog box appears with the join expression already
defined.
2 Below the Expression text box, click the Edit ... button.
The Join SOL Definition dialog box appears. The SOL expression for the
join appears in the text box.
~
I

--------,
3 Click the join expression in the text box at the place where you want to
add or modify the SQL syntax.
You can use the editing features to modify or add SQL syntax as follows:
Change a column at 1 Expand a table node in the Tables

either join end and Columns box.
2 Double-click a column name.
Change an operator Double-click an operator in the Operators box.

used by the join
Use a function in the 1 Expand a function family node.

join 2 Double-click a function.
The column, operator, or function appears in the join definition.

4 Click OK to validate your changes.
5 Verify that the join expression in the Expression text box has been
modified.
6 Click OK to close the Edit Join dialog box.

Detecting joins
Joins can also be created automatically. This procedure can be applied to
selected tables or, if none are selected, all tables in the Structure.
Note: The automatic detection of joins assumes that all columns with
matching names are to be joined, and other columns will be ignored.
This may not be appropriate, in which case it is better to insert the joins
manually.
To detect joins automatically:

1 Click the table you want to select joins for.
2 Click from the Editing tool bar.

A Candidate Joins dialog box displays that lists all the joins detected.
3 Click the join or joins you want to accept in the Candidate Joins dialog
box.
Note: You can accept and insert several joins at the same time using
Shift-click or Ctrl-click.
4 Click Insert.
The join or joins are inserted in the Structure.
S Click Close.

because
Stress the
automatically
the
andloops.
uses tothem
aliases andto
'-../
cardinalities
will resolve
contexts
detect that
loops,
importance
propose
Designer
'-../ of Setting join cardinalities
Cardinality is the term used for expressing the relationship between tables
based on joins. Cardinality information is not related to creating SQL, but it can
be a useful aid to understanding database structures.
About cardinality
Cardinality is the means by which Designer identifies the relationships
between tables in the universe structure. The cardinality can be one-to-one (1-
1), or one-to-many (1-N). For example, a country can have many regions, so
the relationship between the Country and Region tables is 1-N. The cardinality
information has nothing to do with inferring the SQL. It is used only to give the
other detection routines the information they need to detect and resolve loops.
Note: It is very important that all cardinalities are set correctly for the loop
detection and resolution routines to work correctly. These routines will
be presented in detail later in this course.
You can choose to set cardinality manually or by using an automatic detection
routine.
Setting cardinality manually or with the automatic

detection routine?
Cardinality in universe design is based on logical cardinality. The automatic
detection routine method algorithm uses a physical count. The automatic
detectioQ routine only works properly if the database is populated with realistic
data in a completely normalized structure (for example, no multiple loo~up
tables or other tricks that are sometimes applied by database administrators).
Also, it is important to understand that because the detection routine runs three
queries on every join, it can take a long time to complete the routine.The
cardinality detection routine works by runs the following queries:
acount of the rows in each of the two tables that are joined
acount of the rows output when applying a query with the join specified in
the WHERE clause
For these reasons, you are strongly advised to apply cardinality manually for
efficiency and accuracy.
To set cardinality manually

It is recommended that you systematically set the join cardinality when you first
create a join, using the following manual method.
1 Double-click the join you just created between the COUNTRY and
REGION tables.
The Edit Join dialog box appears with the join expression already
defined. In the center of the dialog box is the Cardinality zone.

2 To set the cardinality manually, click the appropriate 1 and N option
buttons in the Cardinality zone.
Note: As you click the different options in the Cardinality zone, a
message appears below the buttons to describe the relationship
between the tables, based on the settings you select.
3 Click the 1 or N option buttons for the COUNTRY and REGION tables so
that the message appears as follows:
Each COUNTRY has one or more REGION
Each REGION has one and only one COUNTRY
Note: 1 = one end of join; N = Many end of join

'-.../
~
'-.../
'-.../
4
Click OK to validate your changes and close the Edit Join dialog box.
Changing the graphical display of joins to indicate

cardinality
You can modify the way joins between two tables are displayed in the Structure
pane. You can:
modify the display of the graphical lines so "crow's feet" are used to
indicate which end of the join is one and which end of the join is many
modify the display so that the cardinality expression appears next to the
join
modify the display so that the lines appear diagonal, curved, straight and
so on.
To control how cardinality is displayed in the Structure

window
1 Select Tools> Options from the menu bar.
2 In the Options dialog box, click the Graphics tab.

3 Select the Arity option button.
4 Click OK.
The many ends of joins will show as "crow's feet" in the Structure pane

importance
Detecting cardinality automatically
'-../ manually
automatic
taught
Stress to asof
theset
routine.
cardinality
should be You can set Designer to detect cardinality automatically as you insert joins,
Learners
'the
create
detection
join. aseach
'soon
not
~-../
'-../
-../ they
-.../ using the however it is recommended that you use the manual method described
previously, to ensure accurate results.
You can detect cardinality for a single join by selecting that join and then
running the cardinality detection routine. If no join is selected, the system
warns you before continuing with the detection. This is due to the fact that, if
the database is large, running the cardinality detection queries for every join
can take considerable time.
.How is cardinality detected?

To detect the cardinality of a join between two tables, the following three
queries are run:
SELECT count (*)
FROM tablel, table2
WHERE tablel.column table2.column
SELECT count (*)

FROM tablel
SELECT count (*)

FROM table2.
The results of the three queries are then compared in an attempt to determine
which query is the end of the join with one entity and which is the end with
many (if there is one).
Detecting cardinality on a single join

Cardinality can be detected on a single join using one of two methods.
To detect a single join using the Edit Join box

1 Double-click the join in the Structure pane to open the Edit Join dialog
box.
2 In the Cardinality section of the Edit Join dialog box, click the Detect
button.
3 Check the cardinality statement to make sure that the one to many
relationship proposed makes logical sense.
4 Click OK to accept the proposed cardinality and close the Edit Join dialog
box.
In the Structure pane, Designer applies the arity symbol to the
appropriate end of the join, based on the cardinality proposed by the
detection routine.
To detect a single join using the Detect Cardinality button

1 Select the join.
2 Click the Detect Cardinalities button.
The automatic routine detects the cardinality of the join and applies the
arity symbol to the appropriate end of the join.
3 Check the arity symbols displayed between the tables to make sure that
the one to many relationship proposed makes logical sense.

4 Edit the cardinality proposed in the Edit Join dialog box if necessary.
Detecting cardinality on all joins

You can also detect cardinality all at the same time, although this is not
recommended procedure to ensure accurate results.
To detect cardinality for all joins

1 Click the Structure background to ensure no join is selected.
2 Click Detect Cardinalities on the Editing toolbar.
Note: Cardinality is detected by automatically running three subsequent
queries at the target database per join.You are therefore advised to
avoid automatic detection of cardinalities on large databases. Use
the manual method whenever cardinality is known.
A message appears.
Designer requests confirmation because executing the detection routine

will take a long time if it is being applied to a large database.
3 If you are sure you want to use the automatic detection routine, click OK
to detect the cardinalities.
The system inserts the arity symbols on the many ends of the joins.
CUENT FIRSTNAME
CUENT ADDRESS
CUENT TOWN
CUENT AREA
ICUENT LASTNAME
UENT AREA CODE
UENT PHONE NO
IREGION 10
EMPLOYEE 10
CUENT AGE
'COUNTRY 10
UENT 10
SHOWROOM 10
SALE SALE
ISALE DATE DISCOUNT
SALE TYPE
~~m ~~~'i-~L PERIOD
Designer offers yet another method for detecting cardinalities automatically:

1 Select Tools> Options from the menu bar.
2 Click the Database tab.
3 Select the Detect cardinalities in joins check box.
4 Click OK.

Best practice for setting join cardinality
As mentioned previously, there are three reasons why using the automatic
detection routine to set join cardinalities is not recommended:
Cardinality is based on logic. It is logical that every country has more than
one region; it is not logical that a region may have more than one country.
The automatic detection routine uses physical cardinality, and runs a
physical count on the values in both columns being joined. You may get
wrong results if the physical count does not return the same result as a
logical analysis of the data.
Secondly, the algorithm used by the automatic detection routine assumes
that you have sufficient quantity of data in both tables to be
representative in ratio to the database in a live environment. If you are
designing against a test database, for example, with only a
representative sampling of data, because the routine runs a physical
count, it could give you the wrong answer.
Thirdly, the automatic detection routine runs three subsequent queries at
the target database per join.You are therefore advised to avoid automatic
detection of cardinalities on large databases.

Join types
Equi-joins Link tables based on the equality between the

values in the column of one table and the values
(includes
in the column of another. Because the same col-
complex equi-joins)
umn is present in both tables, the join synchro-
nizes the two tables.
You can also create complex equi-joins, where
one join links multiple columns between two
tables.
Outer joins Link two tables, one of which has rows that may
not match those in the common column of the
other table.
Theta joins Link tables based on a relationship other than

(conditional equality between two columns, as in for exam-
joins) ple, a BETWEEN join.
Shortcut joins Join providing an alternate path between two

tables, bypassing intermediate tables, leading to
the same result regardless of direction. Opti-
mizes query time by cutting long join paths as
short as possible.
Self restricting Single-table join used to set a restriction on the

joins table.

Equi-joins
An equi-join is a restriction that conforms to the syntax set out below:
Tablel.column_a = Table2.column_a
It is a join based on column values in a column between two tables. In a
normalized database, the columns used in an equi-join are often the primary
key from one table and the foreign key in the other. A primary key is a column
(or columns) that uniquely identifies each row in a table, and a foreign key is
the same column as the primary key in another table.
When a SELECT statement is run, the SELECT and FROM clauses are now
properly defined and prevent a Cartesian product
~-_ __ .._---.........,
I COUNTR'(COUNTRY __
REGION.REGlON_NAME • !
rROM
COUNTR~ ',
IwHERE
REGION !'
,!COUNTRY.COUNTR'CIP-REGlON,COUNTRY_IQ ) I

Outer joins
An outer join is a join that links two tables, one of which has rows that may not
match those in the common column of the other table.
You define an outer join by specifying which table is the outer table in the
original equi-join. The outer table contains the column for which you want to
return all values, even if they are unmatched. You specify the outer table from
the Edit Join dialog box for the selected join.
For instance, the example illustrated above shows the Country and Region
tables from a database. Note that there are three different values in the primary
key of the Country table and only two distinct values in the corresponding
foreign key of the Region table. If you were to apply an equi-join, the result set
of a query would on~yshow information on US and UK. However, you may wish
to show all three countries irrespective of equivalent value in the foreign key of
the Region table. To achieve this you should use an outer join.
In specifying an outer join in a standard SOL Select statement, you are
required to identify which of the two tables is the outer. Using straight SOL (as
opposed to generating it using a universe), the problem is that different
RDBMS define outer differently and the syntax of the statement also differs.
For example, depending on the underlying RDBMS, the outer join may be on
the left or right.
In a universe, you can get around this problem by always defining the outer
join on the opposite table to the one you want all values from, irrespective of
the RDBMS. The outer join is always placed on the table that contains all the
data, that is for, Country, in the example above.To do this, you place a check
against that table in the Edit Join box. Once this is done, the correct outer join
is therefore inferred when used in the generated query, and the syntax is
always correctly inferred for the appropriate RDBMS (assuming you have the
correct SOL inference driver).
Using an outer join would return all countries, including those without regions.
An outer join is shown by a small circle on the join line in the universe structure.
Good Practice with Outer Joins

It is recommended that outer joins be placed at the end of the flow of data,
otherwise outer join errors may occur. Potentially, this could cause the SOL to
try to match on the equality of a NULL value, which it cannot do.
I~b
I
If you do place outer joins in the middle of a table path, the subsequent joins
in the path may also have to be made outer to avoid errors.
Always remember that outer joins may cause the query to run slower than a
query with no outer joins.
This problem can be resolved by using aliases and aggregate aware, both of
which are covered in later lessons of this course.
Theta joins
A theta join is a "between-type" join that links tables based on a relationship
other than equality between two columns. It is used to demonstrate ranges,
such as start date and end date, or minimum and maximum. A theta join can
use any operator other than the equal operator.
For instance, there is a table in the Motors 2004 database called

Sales_Price_Range. This contains a number of rows defining fixed price
ranges by which you may wish to analyze data as illustrated above.
To do this, the table needs to be included in the universe structure and a join
set. The obvious table to join it to is the Model table which includes the price
of a model. However, there is no common column between
Sales_Price_Range and Model tables so an equi-join cannot be used. Instead
you need to infer that a join exists where the value in a row of the Model_Price
column in the Model table is between the values in a row for the
Price_Range_Min and Price_Range_Max columns of the Sales_Price_Range
table.

Shortcut joins
A shortcut join is a join that provides an alternate path between two tables. It
is best used to span existing contexts. Shortcut joins improve the performance
of a query by not taking into account intermediate tables, and shortening a
normally longer join path.
A common use of shortcut joins is to link a shared lookup table to another table
further along a join path. The join path comprises several different tables in the
same context.
In such a case, the shortcut join is only effective when the value being looked
up has been denormalized to lower levels in a hierarchy of tables, so the same
value exists at all the levels being joined.
Shortcut joins will be discussed in more detail later in the course.
Self-restricting joins
A self-restricting join is not really a join at all, but a self-restriction on a single
table, usually a transaction table. You can use a self-restricting join to restrict
the results returned by a table using a fixed value.
The table in the example above contains rows of data for cars both sold and rented.
The Sale_Type column is used as a flag to indicate the type of transaction (S = car
sale, R = car rental). Without the self-restricting join, the results set of the query
would produce rows where the Sale_Type column is equal to either'S' or 'R'. With
the self-restricting join in place, any object based on the table or joins passing
through that table would produce query results covering only car sales.
There are several other ways of restricting data, which are covered in a later lesson
of this course.

Using List Mode
You can view the join expression underlying a join line or all the join
expressions for a table using List Mode as well as the Edit Joins dialog box.
To use List Mode
1 Click the View List Mode button

After List Mode opens, you can view tables and join information and
expressions in various ways. For example:
._.Car MDDELMODEL PRICE between SALES PRICE RANGE.PRICE RANGE ANNUAL fiGURES
;t:··:.iBsnov..oom SALE.SALE DATE between FINANCE PERIOD.FP START and FINANCE; MODELS-
SHOWAOOM.SHO'W'ROOM ID=SALE~SHOWROOM ID . RENTALS
&~Client FRANCHISE
CUENT .CUEHT ID-SALE.WENT ID -
· (:~
i·..·1I!J Area
SALE.5ALE ID=5ALE
SALE MODELMODEL
SALE-MODELCOLOUA
MODELSAlE
ID=MODELMODEl
ID
lD=COlDUR.COLDUA
10
ID
SAliS
!.. jII Town

k~.~~[;j.,I:'~:v!.!;,_ln",C:TY1-C"cTV_I_~
__II"o_ -
:···111 Area Code

: f:!J.£j CieoI:N3ITte
; :.,. G Number of Cients-
$:i!Fin~Period
;:;':'~Aent~s
· ttJ.~RentaiDetai$
~ ttH1ii!t Rental Dates
· HH:iietRenl:alFigur~
$'~Sales
$'~ £kmfJ?f/Re.~bi"./;i-r)Of~:
~.sa Pefronnel
2 Click a join in the graphical Structure.

The expression for the join is highlighted in the Joins panel in the List
Mode.
3 Click a table in the Tables panel of List Mode, and click the arrow pointing
to the Joins panel.
Only the joins for the selected table are shown in the Joins panel.
4 Deselect the highlighted arrow to view all the joins and tables again.
5 Click the View List Mode button to return to normal view.

Note: Make sure you deselect any arrows in List Mode before returning to
normal view. The restricted view of tables could interfere with
operations that you perform in normal view, such as detecting contexts.

Checking integrity
Use Integrity Check to detect any errors in the structure and joins of a universe.
However, you should be careful of checking cardinality automatically for all the
reasons mentioned previoulsy. As a general rule, never select the Check
Cardinalities check box when you are checking the integrity of your universe.
1 Click the Integrity Check button

The Integrity Check dialog box displays:
2 Select the Check Universe Structure and Parse Joins check boxes.
3 Click OK.
Designer checks the universe and displays the Integrity Check Results
dialog box.

,. ·Structure: OK
l'i!'UlffillnE.
4 If there are no errors, click OK.

Otherwise, you need to return to your Structure and correct any errors as
indicated in the Integrity Check Results dialog box.
Note: Some divergences in integrity results are acceptable.

Practice
Activity: Building the universe structure
Objectives
Insert joins between tables in the Motors2004 universe and set
cardinalities.
Instructions
1 Insert the following equi-join using the drag-and-drop technique:
COUNTRY COUNTRY _10 to REGION.COUNTRY _10
2 Set the cardinality for the join manually in the Edit Join dialog box.
3 Insert the following equi-join using the Edit Join dialog box and set the
cardinality.
REGION.REGION_ID to CLlENT.REGION_ID
4 Insert the following theta join and set cardinality.
MODEL.MODEL_PRICE BETWEEN
SALE_PRICE_RANGE.PRICE_RANGE_MIN AND
SALE_PRICE_RANGE.PRICE_RANGE_MAX
5 Insert the following self restricting join and set cardinality.
SALE.SALE TYPE='S'
6 Check integrity for:
Universe structure and joins
7 Notice the divergences found in the integrity check of the Motors2004
universe. This is the result of having un-joined tables.
8 Check that the universe structure includes all of the joins in the table
below:
The joins
should be
- defined with 1:N
N:1
Cardinality Theta
Self
Type
Equi
GE.PRICE_RANGE_MIN
_ID AND following
Joins
SALE_PRICE_RANGE.PRICE_RANGE_MAX
theSHOWROOM.SHOWROOM_id =
D
YICE
= CLiENTREGION_ID
IENT
_IDBETWEEN
=ID=SALE.CLlENT IDcardinalities:
REGION.COUNTRY_ID SALE.SALE_TYPE='S'
SALE_MODEL.MODEL_ID = MODEL.MODEL_ID

---------,
.
Equi N:1
1:N
Cardinality Theta
Type
Equi
_START AND Joins
FINANCE_PERIOD.FP _END
BETWEEN
==
R_ID=COLOUR.COLOUR_ID
MAKER.MAKER_ID
STYLE.STYLE_ID SALE.SALE_ID = SALE_MODEL.SALE_ID
9 Save the changes to the universe.

~
"
~
Lesson summary
Review
Quiz: Building the Universe Structure

1 A schema contains two elements. What are they?
Answer:
'I:, 1 Tables
~~'
'/ 2 Joins
2 What are three reasons that using the automatic detection routine for
setting join cardinalities is not recommended?
Answer:
1 Cardinality is based on logic. The automatic detection routine uses

physical cardinality, and runs a physical count on the values in both
columns being joined. You may get wrong results if the physical
count does not return the same result as a logical analysis of the
data.
2 The algorithm used by the automatic detection routine assumes that

you have sufficient quantity of data in both tables to be
representative in ratio to the database in a live environment. If you
are designing against a test database, for example, with only a
representative sampling of data, because the routine runs a physical
count, it could give you the wrong answer.
3 The automatic detection routine runs three subsequent queries at the
target database per join, which may take a very long time for large
databases.
3 What type of join is created by default between two tables?
Answer:
The default join type is equi-join.
Summary
lesson
Design a schema
objectives
with the Add tables in the Structure pane
learners as a Organize your view of tables
check that all
Understand why you need joins in the universe structure
learners have
acquired the Create joins
required Set join cardinalities
skills b~fore Explain the join types
moving on to
the next View the join expression using List Mode
section. Check the integrity of the universe structure and joins

Lesson 4
Creating Dimension Objects
This lesson describes how you can create classes and objects that are used by
Web Intelligence users to run queries and create reports.

Objects and classes
Creating classes and objects
Duration: 2 hours

Objects and classes
Introduction
Because universes are made up of objects and classes, it is important to
understand exactly how each of these elements is used.
Explain what universe objects are
Explain what universe classes are
Objects
In Business Objects products, an object is a named component in a universe
that represents a column or function in a database.
In Designer, objects appear as icons in the Universe pane. Each object
represents a meaningful entity, fact, or calculation used in an end user's
business environment. The objects that you create in the Universe pane in
Designer are the objects that end users see and use in the reporting tools, for
example, in Web Intelligence.
In the Java Report Panel, Web Intelligence users drag objects from the Data
tab into the Result Objects pane to run queries and create reports that display
the data returned by the query.
Each object maps to a column or function in the target database, and when an
object is selected in the Web Intelligence Java or HTML report panel, the
object infers a SELECT statement. When multiple objects are combined, a
SELECT statement is run on the database which includes the SOL inferred by
each object and a default WHERE clause.
As a universe designer, you use Designer to create the objects that Web
Intelligence users select to build and run their queries.
You can also create objects for use only in Designer, so that they are hidden
in Web Intelligence, Desktop Intelligence or Crystal Reports.

In Designer, you can qualify an object as being one of three types:
pare that
a dimension. map is
dimensions.
A detail to always
statistics in the
o i. Costof
Sales
.q. -CarSales
Revenue
Model
Colour Description
columns
database
attached dimension
query.
rics by a or
that
towhich functions
maps
are
dimension.
oryou key
wanttoItinone
to
totheProvides
Focus
or more
acom- descriptive
of analysis
Contains adata about
aggregatein functions
query. A
ualification $.
in .. 8J
[t}.
I~HiliiiJ CarModel
2L Category
8JMaker of Car o Object
or Number
database. of CarsSold
functions
tion
that related
provide These
in
to athe maps
are Examples
database
the
dimension.
detailed
to one
met-
informa-
more columns
Measure !~J:i&!J Sales
Figures Dimension
etail
g.~ISalesl
(~ Sales Details
9~ Sales Dates
r i!.iI Sale Month
:n.i!.iI Sale Quarter

au IiJ Sale Year
: ;. 2005
: l'.2004
$~ Sales Figures
'.m Number of Cars Sold
@
: u' @Cost of Car Sales
: •• Sales Revenue
L~ Annual Revenue
Dimension objects, where possible, tend to be organized hierarchically within

a class. This is important if you intend to make use of default hierarchies for
drilling. ,
~
Detail objects are organized below their associated dimension objects. Npte
that detail objects cannot be included in a drill path. '
Measure objects may be grouped in a separate class. This makes them easier
for the user to find and also emphasizes the fact that they can be used with any
dimension or detail object.
Note: Only dimension objects can be merged to synchronize queries from
multiple data sources.
Creating Dimension Objects-Instructor's Guide 4-3

Classes
Within a universe, objects are grouped into classes. :This is done to provide a
structure for the universe and makes it easier for users to locate particular
objects. The strategy most otten employed is to group related dimension and
detail objects into one class and place measure objects into a unique and
single measures class.
This strategy can be extended by introducing subclasses to break down the
objects into further subsets.
B~ Class
:"li8 Sub class
:...i.2I Sub class 2
Each object in a universe must be contained within a class. You can create
new classes and edit the properties of existing classes. Classes are
represented as folders on a tree hierarchy in the Universe pane.

Creating classes and objects
Introduction
Now that we have defined classes and objects, the next step is to understand
how to employ these elements. This unit will focus on classes.
Create a class
Create objects
Create classes and objects automatically
Create classes and objects by copy and paste from another universe
Edit object parameters
Check integrity
Test the objects in Web Intelligence
Creating classes
To create a class:
1 Click the existing class below which you want the new class to appear.
Note: If this is the first class you are creating, ignore this step.
Note: If you create a class when an object within a class is highlighted,
you will create a subclass within that class.
2 i~~
Click @,«ifrom the Editing tool bar.
OR
Select Insert> Class from the menu bar.
OR
Right-click in the Universe pane and choose Insert Class from the
speedmenu.
The Class Edit Properties dialog box displays.
3 In the Class Name field, enter a name.
4 In the Description field, enter a description of the class content. This will
be reviewed by users, so it should be written in their business language.
Avoid technical database language.
Creating Dimension Objects-instructor's Guide 4-5

5 Click OK.
Creating an object
To manually create an object
1 Click the class in which you want the new object to be placed.
In this example, click the Client class.
2 Click IIMI from the Editing toolbar.

OR
Select Insert> Object from the menu bar.
OR
Right-click the class and choose Insert Object from the speed menu.
The Edit Properties dialog box displays.

The following sections in this lesson describe how to complete the Edit
Properties tabs to define the object and its content.
3 In the Definition tab, type Client Name in the Name field.
4 Validate that the default object type is selected, Dimension.
S Click OK.
The Universe pane of the Universe window appears as below:
9 ,i;j Car
, l. iu Sales Prices
8~ Client
' .. %1. -~I-ie-nt-N-a-m~el
6 Follow the procedure to create a second object in the Client class, and
name the object Client ID.
Defining a new object as a detail object

The Properties tab in the Edit Properties dialog box allows you to define the
object qualification. An object can be qualified as a dimension, detail or
measure type object.
To define the object as a detail object:

1 Double-click the Client ID object.
The Edit Properties dialog box appears.
2 Click the Properties tab in the Edit Properties dialog box.
The Properties tab of the Edit Properties dialog box appears.
3 In the Qualification zone, select the Detail button.
The Associated Dimension field appears in the Qualification zone.

Click the Associated Dimension field, and from the drop-down list of
available dimension objects, select the one with which this detail object is
to be associated.
In this case, the Client ID object will be assigned as a detail of the Client
Name object, and in the Client class.
4 Click OK to confirm the change.
The Universe pane in Designer appears as follows:
!?,~ Car
i :m.~ Sale Prices

8~ Client
8-!\iI Client Name
i..., •• IClient IDI
Creating classes or objects by dragging

tables or columns
You can also create classes and objects simply by dragging the entire table
from the Structure pane into the Universe pane in Designer. This is particularly
useful if you are sure that you want all the columns in the table to correspond
to objects in the universe.
To automatically create a class from a table

1 Click the header of the REGION table in the Structure pane to highlight it.
2 Click the header of the REGION table again and drag it to the Universe
pane.
The Universe pane should then appear as illustrated below:

ftI"liII Client
EH~IRegionl
i(!J Region Id
i· fijI Region Name
L .. fijI Country Id
Note: The class is automatically populated with an object for every

column in the table. It is not advisable to do this because you are
creating a universe based on the database structure, not on the
requirements of the users.
To automatically create an object from a column

You can also drag and drop just a column from a table in the Structure pane to
create a single object.
1 In the Universe pane, click the Client class where you want the object to
be included.
2 In the Structure pane, click the CLIENT_TOWN column in the CLIENT
table.
3 Drag the CLIENT_TOWN column to the Universe pane, and drop it over
the Client class.
The Universe pane displays the object.
8·~ Client
f"~$J -r:-lie-n-t-T-ow-n~1
8·· ill Client Name
0.. '* Client Id
Note that the name of the object is based on an adaptation of the column
name. This is based on a strategy that is set in the Strategies tab of the
Parameters dialog box. The default strategy used replaces underscores with
spaces and the initials of each character string are altered to upper case and
the remainder becomes lower case.
The key advantage of this object creation method is that it automatically places
the column in the SELECT field of the object properties as illustrated below.

Note: Whenever you create an object automatically, you should then edit the
properties of the object to:
Change the name where appropriate.
Enter a description.
Change the object qualification from the default where necessary.
Alter or remove the Associated List of Values settings where
appropriate.
Change other settings as required.
(These settings are described in detail later in this lesson.)
Working with classes and sub-classes

Creating a sub-class
1 Right-click the class in which you want to create a subclass.
The drop-down menu appears.
2 Choose Insert Subclass.
3 In the Class Name field, enter Sales Price, the name of the sub-class.
4 Click OK.
The Objects and Classes window will now look similar to:
-~
: l..~ Sales Prices
GH~ Client
Note: It is recommended that you do not create too many levels of sub-
classes (more than three) because too many levels make it difficult
for users to find the objects they need.
To delete a class
1 Click the Sales Price subclass.
2 Press the Delete key.
OR
Right-click the sub-class and then choose the Clear option from the drop-
down menu.

Editing the obj eet properties
The example below shows the properties of the dimension object you created
previously, called "Client Name". As the object is defined right now, the
SELECT statement will return only the first name of the clients referenced in
the CLIENT table. You need to edit the definition of the SELECT statement so
that the Client Name object will return the complete client name.
To edit the object definition:

1 In the Definition tab, type in the Name field if you want to edit the object
name.
2 Click the Type arrow, and from the drop-down list, select the appropriate
data type for the database column or columns that the object references.
3 Click the Description text box and type help text for the end user. This
text will appear in Web Intelligence or Desktop Intelligence when a user
selects the object to build a query. The text should describe the data that
will be returned if the user adds this object to a query.
4 Click the Select text box and enter the SELECT statement that will be
inferred when a user builds a query using this object.
This can be done in one of two ways:
Type the SELECT clause code in the Select field to define the
columns that will be referenced.
OR
ClickifJ!M to open the Edit Select Statement dialog box as displayed

below.
The Edit Select Statement dialog box appears.

It is normally best to use the latter method because it enables you to
specify most of the SELECT clause code from pick lists in the lower half
of the screen by double-clicking the item required. This minimizes typing
and averts syntax errors due to typing mistakes.
5 Modify the SELECT statement so that the object references both the
CLlENT_FIRSTNAME and CLlENT_LASTNAME columns in the CLIENT
table.
Use the fields below the text box to select the columns, operators or
functions you need to use so that the following SOL statement appears in
the text box:
CLIENT. CLIENT ]IRSTNAME + ',' + CLIENT.CLIENT _ LASTNAME
Note: Remember to insert a comma between first and last names,
surrounded by single quotes.
6 Click the Parse button to validate the statement syntax.
7 Click OK to close the Edit Select Statement dialog box.
The Edit Select Statement dialog box closes and the Definition tab of the
Edit Properties dialog box displays the SOL statement in the SELECT
test box.
8 If required, enter a WHERE clause in the Where text box to restrict the
data returned by this object with a condition. You can enter the WHERE
clause here in the same way you did when you modified the SELECT
statement.
Note: You should avoid specifying conditions against an object unless
absolutely necessary. Conditions are discussed later in this
course.
9 Click the Parse button.
Note: You can also parse the SELECT statement and WHERE clause in
the individual Edit dialog boxes.

The Definition tab should now appear as shown below:
The remaining tabs in the Edit Properties dialog box are described in the
following sections.
Edit Properties: Properties

The example below shows the properties defined for the "Client Name" object.

To edit the Properties tab
1 Select one of the object types in the Qualification panel.
Note: By default, the object type selected will be either a dimension or
measure dependent on the data type chosen on the Definitions
tab.
Dimension=Character, Date or Number
Measure=Selected by default when there is an aggregate function in the
SELECT clause
Note: The Detail qualification check box will be grayed out if no
dimension objects exist to which to attach a detail object.
2 Select the appropriate options in the Associate a List of Values panel.
Note: List of Values (LOVs) are presented in detail in a later lesson in this
course.
What is a list of values?
When you create an object, Designer automatically associates a list of values

(LOV) with the object. The list of values is not created until a user, or you the
designer, choose to display a list of values for the object in the Query panel. A
SELECT DISTINCT query is then run against the column or columns inferred
by the object.
The returned data is stored in a file with a .LOV extension in the universe sub
folder created under the same folder that stores the universe file.The.LOV file
is then used as the source for values for the list. This allows the SELECT
DISTINCT query to be run only once for an object.
This folder also stores the .LOV files created in Designer which are used to
restrict the list of values returned for objects for which the designer wants to
control access to the data.
When do you use a list of values?

A LOV should only be used with an object if it will provide something useful for
the user. LOVs are very useful where there is a limited set of distinct values for
the database columns underlying the object.
Note: If the object is likely to refer to a large number of distinct rows in
the database, it is advisable not to associate a LOV.
Setting LOV options

In the Associate a List of Values panel, the Display button allows you to view
all the values in the database returned by this object.
To restrict the object so that some of the values are not returned when an end-
user uses this object in a Web Intelligence or Desktop Intelligence query, you
can click the Edit button to create a filter (or condition) in the Query Panel that
appears.
The options available in the Associate a List of Values panel are described in
detail in a later lesson in this course.

Edit Properties: Advanced
The example below shows some advanced properties defined for the "Client
Name" object. This tab allows you to set the security access level of the object
and how it can be used in a query or in a report.
To edit the Advanced panel

1 Click the Security Access Level arrow, and from the drop-down list,
select the appropriate security level for the object.
2 In the Can be used in zone, select options to define how this object can
be used in Web Intelligence or Desktop Intelligence:
Select the Result check box if users will be able to use this object to
return results in a query
Select the Condition check box if users will be able to use this object
to apply a condition or query filter in a query.
Select the Sort check box if users will be able to specify the object in
the Order By clause of a SELECT statement.
Note: You are advised to clear the Sort check box. If used, this option
often increases the processing speed of a query. Except in certain
edited LOV situations, it is not useful to sort at query level because
block-level sorting overrides any row order of data that is stored in
the microcube.

Edit Properties: Keys
The Keys tab allows you to define index awareness for an object. Index
awareness is the ability to take advantage of the indexes on key columns in
the database to speed data retrieval.
The objects that you create in Designer are based on database columns that
are meaningful to an end user. For example, a Customer object retrieves the
field that contains the customer name. In this situation, the customer table
typically has a primary key that is not meaningful to the end user, but which is
very important for database performance. When you set up index awareness
in Designer, you tell Designerwhich database columns are primary and foreign
keys. This can have a dramatic effect on query performance.
In the example below, primary and foreign keys have been defined on the
Client Country object. The complete Where clause for the primary key is:
country.countryjd = client.country_id
If you then use Client Country in a query with the Client Name object, the query
will not need to reference the Country table in the database; the Country data
will be taken from the Client table directly.

The SOL from this query looks like this:
':ELECT
COUNTRY,GOUtrR\'_~H\ME"
CUENT.CUENTJASTI'P,i-J'E " ',' " CLiENTCLlENTJ;RSTNAi-AE
-ROM
CCI)NTRY
CUE!,,(
F~EGiCf',!
HERE
((·;C~UNTR'r-';COUh!TF~'(~)D;::REGJON.C:JUt~iTi,{_10. -)
l~ND (REGIO~J.F{EC~iOH ...tD " CUEi,jT.REG;C~N...,iU)
Note: Index awareness is presented in more detail in a later lesson in this

course.
Edit Properties: Source Information

For universes generated from Data Integrator, technical descriptions and
formulas used to calculate target tables from source tables are displayed in
this tab.
You can specify the following types of information in the Source Information
tab:

Technical description: Technical descriptions that are available in
universes generated from Data Integrator.
Mapping information: The mapping applied within Data Integrator
between the source tables and the target tables. The goal is not to
provide the expression of the mapping, but to display it as a descriptive
comment to inform the user of the source columns used in the object
definition.
Data Lineage information: List of source columns involved in a target

column. This information facilitates the impact analysis through Data
Integrator and Web Intelligence reports.
Copying and pasting objects

It is possible to copy objects from one universe to another. This is useful if you
want to create objects that are similar to those already existing in another
universe. You can copy those objects or classes of objects and edit them as
required.
Note: When you copy an object from one universe into another, be sure to
validate the object definition against the new universe structure and
data source connection.
To copy and paste objects

1 Open the universe from where you want to copy objects.
2 Select the object(s) you want to copy.
3 Click copy from the standard toolbar.
4 Open the universe to which you want to copy the objects.
5 Click paste from the standard toolbar.
Find and replace

The Find and Replace functions can be very useful when editing. You can use
the Find function to locate character strings in objects and their definitions.
You can also use the Find function in conjunction with the Replace function to
edit strings.
To find a string
1 Ensure the Objects pane of the Designer window is active.
Note: If the Structure pane of the universe is active, the Find function
searches for table names containing the specified string.
2 Click Find from the standard toolbar.
The Find/Replace dialog box opens.

3 Enter the character string for which to search.
4 Select the check box options as required.
5 Click Find Next. The appropriate object or part of the object definition will
be displayed and the string will be highlighted.
6 To move to the next instance of the string, click Find Next or click the
Find Next icon.
To replace as you find

1 In the Find/Replace dialog box, select the Replace tab.
'-.-/
245
'-../
'-.-/
---../
---../ 3
Enter the string to search for in the Find What field and the string with
which it is to be substituted in the Replace field.
Select the check box as required.
Click Find Next.
Click Replace and then move to the next instance of the string by either
clicking Find Next or the standard toolbar option.

Checking integrity
Always check the integrity of your universe after defining classes and objects.
1 Click
The Integrity Check dialog box displays.
2 Select the P~rse Objects check box:
"'
/'
/~'
3
4 Designer checks the universe and displays the Results dialog box.
5 Identify the reason for any reported errors and resolve them.
Viewing parent tables

You can view the tables associated with an object at any time.
To associate a table:
1 Right-click the object.
2 Select the View Associated Table option.
The associated tables of the object will be highlighted in the Universe Structure
pane and the list mode display (if open).

Testing objects
As you create objects in the universe, you should test them in Web
Intelligence, Desktop Intelligence or Crystal Reports by building and running
queries. There are three things you need to test:
Do the objects exist? If not, you may have forgotten to save and export
your universe since the object you are testing was created.
Does the SOL appear correct?
Are the results of the query correct?
Remember that you must also test the joins already created in the structure.

Practice
Activity: Creating and testing classes and objects
Objectives:
Create and test classes and objects.
Instructions
In this workshop you will create classes, subclasses and dimension and detail
objects for the Motors2004 universe and then test the universe's objects and
joins.
1 Create the following class:
Client
2 Create the following class and subclass:
Car
Sale Prices (subclass of Car)
3 Create a Client Name dimension object manually with the settings:
Type = Character
Description = Last name, First name
SELECT = CLlENT.CLlENT_LASTNAME +', '+
CLlENT.CLlENT FIRSTNAME
Associate a LOV
4 Create a Client 10 detail object automatically with the settings:
Type = Number
Description = Unique Client 10 Number
SELECT = CLlENT.CLlENT _10
No Associated LOV
5 Check the integrity of the objects.
6 Create the Showroom class.
7 Create objects for each of the classes as identified in the tables below.
Some of the properties for each object have been specified for you.
However, you will have to determine the data type, qualification, and
whether or not a LOV should be associated with each object.

Car class
MAKER.MAKER Object
StatementNAME
SELECT STYLE_NAME Car
MODEL.MODEL_NAME
STYLE. The Manufacturer
Model
and &" name,
engine
style trim, into which a car
size
&group
MODEL.MODEL
MODEL.MODEL_ ENGINE
TRIM & ' ,& fits (for estate)
Description
salon,
Object example,
Name
Sale Prices class (a subclass of Car)

Description of Object
SELECT
MODEL.MODEL
SALES -
StatementPRICE
Manufacturer
_PRICE_RANGE.PRICE rec-
price range band-
RANGE ommended
price
ing
Description retail
Object Name
Showroom class
SELECT
SHOW- Statement Object inofwhich
Name
Address
showroom
Town of
show- showroom
ROOM.SHOWROOM_ADDRESS
SHOWROOM.SHOWROOM_
SHOWROOM.SHOWROOM_NAME TOWN
room
exists
Description
Object Name

Client class
Object
CLIENT CLIENT_AREA_CODE
SELECT CLIENT AREAArea
Statement Address
Phone of
number of client
REGION.
COUNTRY
CLIENT CLIENT
REGION_NAME
CLIENT _TOWNPostal
T
Regionoror
Country
own of
_ADDRESS
COUNTRY_NAME
_PHONE_NO ofZip
in
Region
city
coun-
in
client
which
ent
in
resides
Codewhich
inresides
resides client
Description
try
example,
or state)
Object client
(for
whichcounty
Namecli-
8 Modify the properties of the following objects so that they are qualified as
detail objects, and associated with the Client Name dimension object:
Client Address
Area Code
Phone Number
9 Modify the properties of the Showroom Address object so that it is
qualified as a detail object, and associated with the Showroom dimension
object.
10 Create a class called Sales and two sub-classes in the Sales class:
Sales Details
Sales Dates

Sales Details class (a sub-class of Sales)
SELECT Statement Object 10 Number
SALE.SALE_ID Unique Invoice
Description
Object Name
Sales Dates class (a sub-class of Sales)

SELECT
SALE.SALE
Statement
DATE Objectof sale
Date
Description
Object Name
11 Drag the FINANCE_PERIOD table from the Structure pane and drop it in
the Universe pane.
12 Edit the objects that have been created automatically in the new Finance
class, according to the table below.
Financial class
- - SELECT
FINANCE Statement
PERIOD.FP
FINANCE_PERIOD.FP
Object
YEAR
FY03-04 For example, Q1 Month 01
_QUARTER
_MONTH
Description
Object Name
Financial
13 Make sure you have defined each object using the appropriate object
type.
The Class and Objects pane in Designer show appear like this:

·<8iJ Client
r .. · m. Country.
:..··11 Region
~.--m Area
m ..Client Town
['}: 11 Client Name
Client ID
Client Address
Area Code
Phone Number
GJ·:®J Car
;.;;J "Maker
: ... 11 Category of Car
:.• 11" Model

e·-@aSale Prices
r'" m Price R:ange

L .. ill· Model Price
$'~ ~howrQoml
. :.:.:11 Showroom Town
ffi· 1'1 . Showroom
!~1:',®J Sales
S·.€iJ Sales Details
',. m Invoice ID Number
EhE:! Sales Dates
: '... ;;J Sale Date
EJ":~ Finan.Gal Period

:... :m Financial Year,
>- m Finand31 Quarter

:.... ~, .Financial Month
14 Save the universe.

15 Check the integrity of the objects, and make any alterations required.
Note: Test the validity of the joins also.
16 Save the universe again and export to BusinessObjects Enterprise.
17 Test the universe by building queries using the new objects:
In InfoView, create a new Web Intelligence document and select the
Motors2004 universe that you have exported.
Build a query in the Java Report Panel using the objects you have
created and test the results.

Lesson summary
Review
Quiz: Creating Dimension Objects

1 Which of the three types of objects contains aggregate functions that map
to statistics in the database?
Answer:
Measure objects
2 When you are testing objects, what are the three things for which you
need to test?
Answer:
Do the objects exist? If not, you may have forgotten to save your universe
since the object you are testing was created.
Does the SQL appear correct?
Are the results of the query correct?
3 If each object maps to a column or function in a target database, when
used in a query, what kind of statement does the object infer?
Answer:
A SELECT statement.
Summary
Explain what universe objects are
I;:xplain what universe classes are
Create a class
Create objects
Create classes and objects automatically
Create classes and objects by copy and paste from another universe
Edit object parameters
Check integrity
Test the objects in Web Intelligence

Lesson 5
Creating Measure Objects
This lesson describes how to create measure objects and test that they produce
the correct results when used in queries.
What are measure objects?
Creating measure objects

What are measure objects?
Introduction
Define measure objects
Determine levels of aggregation
Defining measure objects

A measure object returns numeric information. Measure objects are very
flexible because they are semantically dynamic. This means that the values
they return in a query will vary depending on the dimension and detail objects
that are used with them.
You can see from the illustration that two separate queries using the same
Sales Revenue measure object but different dimension objects results in the
measure returning different values.

Measure objects are created by using aggregate functions. The five basic
aggregate functions are:
Sum
Count
Average
Maximum
Minimum
A measure object returns numeric data from the database that aggregates up
or down according to the dimension objects in the query. The most regularly
used aggregates are listed above. However, there are others that can be used.
The full set of aggregate functions is held in the Number Functions pick list of
the Edit Select dialog box.
Levels of aggregation
How a measure infers SQL
If an aggregate function was used in the Select definition of the object, it
automatically infers a Group By clause in the Select statement if it also
includes other types of objects.
Inference of the Group By clause is dependent on the SOL rule:
If the Select clause line contains an aggregate, everything outside of that
aggregate in the clause must also appear in the Group By clause.
That is why dimension and detail objects must not contain aggregates. Any
dimension or detail that is used in the same Web Intelligence query as a
measure object will always be included in an automatically inferred Group By
clause.
In the example above, you can see that the Country dimension object is
inferred not only in the Select clause, but in the Group By clause.
Creating Measure Objects-Instructor's Guide 5-3

$EtEn
tOU!I"W.tt1L!1tiRY)1.4M£ ,
REQ!QN.RWIQti nOME.
,"~$Al£" MOOfIs,AtfJJTY' h!1){)fLMODEl)'RICf 'IJlOO' tALESAl£_$Alf_mSmUtH t/100jj
fA1:iM
WEIlL
rowmRv,
m:mO~t
MOtR,
~tE
&~r~M{)t'H,
"''HERr
r mUNTRymUMt
¢fNO f REGlaN.!\E~ __
AND P,,<\LE_MDPol.MQD[LJD_MODEl.MCJ)[l)n )
AND [5AL£SAtE,)D.1'AlE_MODELSAl£)D 1
I
AND tlIEN1":1.!ENi Jo.tAi.£,CUEH1·.31 1
!
ANO [SAl£.$.IJ;t.\L 'Yf'1i:·'1;i'
tmmJP1N
Cl.JUNtRvwumfW NAME.
REGtDNI1SGlQtij{tJlr .
How a measure works at the select level

You can see in the second example query illustrated above that it now includes
two dimensions (the Country and Region objects). In accordance with the
inference engine, both of these appear in the Group By clause. Hence the
values returned for the Sales Revenue measure object are aggregated to a
lower level. It is through this mechanism of the Web Intelligence inference
engine that measure objects are said to be dynamic.
Note: If a query is made that only includes measure objects, no Group By
clause is inferred.

The Query Process
Client Servers
I
I
User asks I
I
a business I
question Corporate
database
"ki
/
II Server Query (SQL)
Enterprise
..•
~ I
I
I ~.
Results
I provider
I
Report . I
I
,
Consider the query process:

The user creates a query in the Web Intelligence Java Report Panel, or
the HTML Report Panel, and the data is sent to the BusinessObjects
Enterprise server as HTML.
The data is inferred as SQL and passed via the middleware to the
database.
The data is returned and stored in the data provider on the Enterprise
server.
The data is passed back as HTML to the user via the web browser, and
projected in a Web Intelligence report in the form of a table or chart.
There are two levels of aggregation in the Web Intelligence query process.
at query level using the inferred Select statement
when projecting Select statement results from the microcube to the report
When you create a measure, you specify the way the aggregate function will
be projected into the report. The projection function allows report level
aggregation in the microcube.
Aggregation at projection level

When you initially make a query, the results set of the Select statement is
stored in the microcube. All data then held in the microcube is projected into a
block (the table or chart in the report). Therefore, because data is projected
from the lowest level held in the microcube, no projection aggregation takes
place.
However, when you edit the report in the Web Intelligence report panel (for
example, by removing a variable or by filtering the values returned by a
variable), and therefore project only partial data from the microcube,
aggregation is required to show measure values at a higher level.
For instance, if you do not project the region data into the block, the·four rows
related to USA need to be reduced to one to show the overall Sales Revenue
for that country. In this instance, a sum aggregation is required.

When projecting all variables in the microcube, no aggregation takes place.
When projecting only some variables from the microcube, aggregation occurs.
Projection aggregation is separate from Select aggregation and is set in the

Designer module on the properties of a measure object.
Setting selection and projection aggregates

Statistically, only certain selecUproject aggregates are compatible.
Minimum
Sum
Count
Maximum
Average
None or Average (not
·· Recommended Projected
·· · Select Aggregate
recommended)
Aggregate
For Web Intelligence to present statistically correct results for a measure

object both at query and projection level, the Select and project aggregates
need to complement each other.
However, as a universe designer, if you configure a measure differently, Web
Intelligence will not stop you. With the exception of Average, the correct
projected Aggregate will be selected by default.
Note: It is recommended that you do not create measures based on an
average aggregate because an average of an average is not an
average. It would be more accurate to process this at report level by
applying a calculator average on another measure.

Introduction
Create measure objects
Test measure objects in Web Intelligence

You create measure objects in the same way that you create a dimension or
detail object. They can be created using the automatic or manual method
described in the previous lesson in this course.
It is recommended that you group measure objects together in separate
classes from dimension and detail objects, if they are generic. In other words,
if they can be used in the same query as any dimension and detail object in the
universe, then they are considered generic, and you should group them in
separate classes.
If they are only compatible with certain objects, however, then you may want
to place them in the same class as those objects, to indicate this fact to the
report designers.
It is important to remember the following when you create measure objects:
In the Definition tab

The Data Type field must be set to Number.
The Select field should include an aggregate function.
The
aggregate
placed in the
SELECT
clause is the
aggregate
sent to the
database.
Tip: It is best to use the Select Edit box to insert the Select clause content of
a measure as you can then use the Function and Columns pick lists.
Creating Measure Objects-instructor's Guide 5-7

In the Properties tab:
The qualification must be set as a Measure type.
In the Function field, make sure the function you use is compatible with
the aggregate used in the Select statement.
A measure object should not have a list of values associated with it.
Therefore, the Associate a List of Values check box should be
unchecked.
Testing measure objects

When you test a measure, you must be far more rigorous in your checks than
with a dimension or detail object. This is because you have to check that the
values of the measure aggregate correctly both at Select and projection level.
The three elements to testing a dimension or a detail object are:
1 Check that the objects exist.
2 Check the inferred SOL.
3 Check the query results.
For measure objects, the additional elements are:
1 Repeat with the other dimensions.
2 Make a query with a minimum of two dimensions and a measure.
3 To validate the accuracy of the measure aggregate, it is recommended
that you test it with at least three separate queries.

Testing measures at select level
To test the inferred Select statements for a measure object, you must make at
least two separate queries using different dimension objects to produce
different levels of aggregation. Three or more queries are preferable.
In each instance, you must check the following:
The inferred SQL of the query
In particular, you should check the Group By clause has been inferred
correctly.
Note: If it has not been inferred at all, it is likely that you have set a
calculation and not an aggregate in the Select field of the measure
object properties.
The results of the query
Check that the query produces the correct results.
Testing measures at project level

To test for projected aggregation, you need to build a query containing at least
two dimension objects, as well as the measure object you are testing. This
allows you to project from other than the lowest level of data held in the
microcube and therefore test aggregation.

Practice
Activity: Create and test measure objects
Objectives
Create and test measure objects.
Instructions
1 Create the following subclass in the Sales class:
Sales Figures
2 Create a Sales Revenue measure object with the settings:
Type = Number
Description = Total Sale Invoice Revenue
Select = SUM(SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE * ((100 - SALE.SALE_SALE_DISCOUNT) /
100»
Function = SUM
No Associated LOV
3 Test the Sales Revenue object as follows:
Save the universe. Export the universe and log into InfoView. Create
a new Web Intelligence document and select the universe you just
exported.
Build a query containing only the Sales Revenue object. Note the
value returned.
Edit the query by adding the Country dimension object. Check the
SQL and note the GROUP BY clause. It should contain the SQL for
the Country object. Run the query. Apply a SUM calculation to the
Sales Revenue column of the projected block. Does the sum match
the value of the previous query? Note the value of the Sales
Revenue in a row of the block (for example, USA).
Edit the query by adding the Region dimension object. Check the
SQL and note the GROUP BY clause. It should now contain the SQL
for the Country and Region objects. Run the query. Apply a break to
the Country column and reapply the sum calculation to the Sales
Revenue column of the projected block. Does the Country group
sum match the value of the noted block row from the previous query
(e.g. USA)?
Change the projection to the block from the microcube by removing
the Region column from the block. Does it aggregate to Country level
correctly?
Edit projection to the block from the microcube by removing the
Country column from the block. Does it aggregate to the total Sales
Revenue level correctly?
Edit the query again to remove all objects except Sales Revenue.
Add the Showroom and Maker objects, and run the query. Using drag

and drop, insert two new tables, one to show Showroom and Sales
Revenue, and the other to show maker and Sales Revenue, and
apply a sum to both tables. Note the total values remain the same.
The final version of the report should look something like this:
4 In Designer, create the following measure objects in the Sales Figures

subclass and test them. The SQl code for the Select properties of each
object has been specified for you. However, you will have to determine
the appropriate projection function aggregate.
Object
SalesCost
Select StatementTotal ofQTY)
NumberCar
of Cars Sold
SUM(SAlE_MODEL.SAlE_ QTY
* MODEL. MODEL_COST) Description
Object Name
sles
5 Create the measure objects listed below.

In the Car class and Sale Prices sub-class: lowest Priced Value
based on Manufacturers recommended retail price
In the Car class and Sale Prices sub-class: Highest Priced Value
based on Manufacturers recommended retail price
In the Client class: Number of Clients
6 Save and export the universe and test the new objects by using them in
queries in Web Intelligence.

Lesson summary
Review
Quiz: Creating Measure Objects

1 Measure objects are very flexible because they are semantically
dynamic. What does this mean?
Answer:
This means that the values they return in a query will vary depending on
the dimension and detail objects that are used with them.
2 Measure objects are created in the same way as you create a dimension
or detail object. However, the object properties will differ in two ways.
What are they?
Answer:
The object properties will differ as follows:
The Data Type field must be set to Number.
The Select field should include an aggregate function.
Summary
lesson
Define measure objects
objectives
with the Determine levels of aggregation
learners as a Create measure objects
check that all Test measure objects in Web Intelligence
learners have
acquired the
required
skills before
moving on to
the next
section.

Lesson 6
Using Lists of Values
This lesson explains how you can add, modify, or remove a list of values (LOV)
for an object. It also introduces how to create cascading list of values in Designer
and how to use them in Web Intelligence.
In this lesson, you will learn about:
Creating a list of values
Working with LOVs in Designer
Creating a cascading LOV

Creating a list of values
Introduction
A list of values is a list that contains the distinct data values associated with an
object.
Explain what a list of values (LOV) is
Use a list of values in Web Intelligence
What is a List of Values?

When you create a dimension or detail object in Designer, it is automatically
assigned an associated list of values, or LOV. This list does not physically exist
when you create an object, but by default the object has the ability to query the
database to return a list of its values when used in Web Intelligence or Desktop
Intelligence to build a query.
Lists of values are based on the results of a SELECT DISTINCT query on the
column or columns held in the Select Statement in the object's Edit Properties
dialog box. If you select the "Export with Universe" option in the Associate a
List of Values pane of the Properties tab, the list of values is converted to XML
when you export the universe, and then stored in a .UNW file in the
BusinessObjects Enterprise Central Management Server (CMS).
The first time a list of values is used to filter results returned by a query, the
LOV is stored in an encrypted file on the Web Intelligence server in the
sessions folder.
As you create objects in the universe, you should use the following questions
as a guide to help you decide if you should associate a LOV to an object or not:
Do the users need to see a list of values for this object? Are they
likely to want to apply query filters or condition on this object?
Is the data dynamic or static? Will the data be updated frequently?
How long will it take to run the SELECT DISTINCT query?
What does the list need to include?
Using a LOV
When users build queries in Web Intelligence or Desktop Intelligence, they can
define query filters (or conditions, in Desktop Intelligence) to restrict the
amount of data returned by a specific object used in the query. To do this, they
view the list of values for that object in order to specify which value(s) will be
returned. The LOV for the object appears in the Web Intelligence Filter Editor,
which helps the user choose the terms for the filter.
For example, in the Maker object with the SELECT clause
MAKER.MAKER_NAME, the LOV will contain all the distinct car
manufacturer's names in the MAKER table. A user who wants to limit the query

to a single maker could select that name for the query filter by choosing it from
the LOV.
To use a LOV in Web Intelligence

1 In Web Intelligence, create a new document and build a query with the
Financial Year and Sales Revenue objects.
2 Drag and drop the Maker object in the Query Filters pane.
3 In the Filter Editor that appears, verify that the In List operator is selected
in the drop-down list. .
MotOls2004 L5 Final
'0' i~~, IB!I

; n.1) Category of Car
!· .. ·m Model
ffin~ Sales: Prices:
~}.@;J Client
;±j .. r.&J ShowlOom
~~J,.,@J Fmancial Period
. L<1 FinancialYear
l'. m ,Financial Qualte.
: ·· .. TI' Financial Month
[3·,;~'Sares
~ .. ~ SaleS': Details
~~-'WJ,Sales Dates
4 Click the bulleted list to the far right of the query filter definition and select
the Value(s) from list operand from the Operand Type list.
This list of values returned by the Maker name object appear in the Filter
Editor, as shown below:
5 Choose a value(s) from the displayed list by double-clicking it.

6 Click OK.
Using Lists of Values-instructor's Guide 6-3
/
The query filter appears as in this example:
7 Click Run Query to display the report.

Only the data concerning cars manufactured by Jaguar are displayed in
the report:

Working with LOVs in Designer
Introduction
A list of values is a list that contains the distinct data values associated with an
object.
Associate a LOV with an object
View the contents of a LOV '.
Set options for generating a LOV
Modifying the contents of a LOV
Create a hierarchical view of a LOV
Associating a LOV with an object

By default, a LOV is attached to every dimension and detail object that is
created in Designer.
To view an object's default LOV properties:

1 Double-click the object to open the Edit Properties dialog box for the
object.
2 Click the Properties tab.
The example below shows the default properties for the Maker object.
3 If you want to turn off the LOV for this object, click the Associate a List
of Values check box to clear it.
....J
There are three things that a universe designer should keep in mind when
deciding whether or not to associate a LOV to an object:
Because a LOV is based on a SELECT DISTINCT query that is fired at
the target database, associating a LOV will have implications for the
efficiency of Web Intelligence or Desktop Intelligence.
The only purpose for creating a LOV is to assist the end user in choosing
an operand value for a query filter. If the LOV does not do this, there is no
point in associating it with the object.
The LOV only holds values that exist within the database.
It is therefore recommended that you do not provide a LOV for the following
types of object:
All measure objects
Any object where the LOV will consist of a large number of values
Any object where the list on its own would be meaningless
To view the contents of a LOV in Designer

1 Double-click the relevant object to open the Edit Properties dialog box.
2 Click the Properties tab.
3 In the Associate a List of Values zone, click the Display button.
A SELECT DISTINCT query is fired at the target database and the LOV
displays, as in the example below:
Aston Martin
Caterham
Ferrari
Jaguar
Jeep
Lotus
Porsche .
Rolls Royce
Subaru
Volvo
4 Click the Cancel button to close the window.
To create a file to hold the contents of the LOV query in Designer, use the same
procedure, but instead of clicking Cancel at step 4, click OK. In that case, the
list is saved as a .LOV file in the universe subfolder on the file system.
The default location is the Universe subfolder of the default installation folder:
C:\Documents and Settings\<user_name>\Application

Data\Business Objects\Business Objects
11.5\Universes\@<server_name>\<universe_name>

The name of the LOV file is the same name as shown in the List Name field,
in the Properties tab:
The default name for the list is taken from the first five characters of the object
name, followed by digits that refer to the order in which objects are displayed
in the Classes and Objects window. The file has an .LOV extension.
As a designer, you can edit the list name to call the file anything you want (with
an .LOV extension). Clicking the Restore Default button changes the name
back to the default file name.
Setting options for generating LOV s

By default, the first time that a LOV is used in a user login session, the system
fires a query at the target database and uses the results to populate the list.
Thereafter, the .LOV file from this query is referred to each time the LOV is
used.
However, you can alter the strategy for refreshing the list by selecting options
in the Edit Properties dialog box.
Allow users to edit this list of values

If you select this check box, you allow Desktop Intelligence users to alter the
contents of the LOV. This feature is not available for Web Intelligence users.
Normally, you will not want to allow this. The purpose of the LOV is to offer the
user a limited set of valid, known values for an object. If you allow users to edit
this list, you have no control over the values they choose.
It is recommended that you always clear the Allow users to edit this LOV check
box.
Automatic refresh before use

If you select this check box, the system will send the Select Distinct query at
the target database every time the user selects the LOV. This refreshes the
contents of the list much more frequently than the default strategy, where the
list is refreshed only the first time it is used in a user login session.
It is recommended that you select the Automatic refresh before use check
box if the contents of the list are dynamic and frequently changing. If the
contents of the list are stable and unchanging, you can increase speed and
efficiency by clearing this check box.
/ '-oJ
Hierarchical display
If you select the third check box, Hierarchical Display, the list of values will be
displayed in the hierarchical order that you as a universe designer have
defined.
The hierarchical display of LOVs is discussed in the next section of this lesson.
Export with universe

If you select the Export with universe check box, the list of values is
converted to XML when the universe is exported, and stored in an .UNW file.
This file is stored in the BusinesObjects Enterprise Central Management
Server (CMS).
Modifying the contents of the LOV

In Designer, you can modify the contents of the list in two ways:
Apply a condition to the Select Distinct query that generates the list.
Create a hierarchy to simplify for users the process of choosing a value
from the list.
In this To apply a condition to the LOV
exercise, use
1 In Designer, in the object's Edit Properties tab (in the Associate a List of
the Category Values pane), click Edit to the left of the Display button.
of Car object
The Designer Query Panel displays, showing the default query for the
to modify the
LOV for LOV, as in the following example:
Maker.
Check that
both Maker
and Category Ca,
of Car have a . -m Maker
LOV :g,' j:ategory

. u:& Model
of Car!
associated ill·~ Sales Prices

$',:£]dient
with their ~t:·QM Showroom
ff'@} Financial Period
object a-; @j Sales
definition in
order to do
this.
2 Edit the list of values by dragging and dropping the Category of Car name
object into the Conditions pane, and applying a condition as shown
below:

. :iiJcar
, '····m Maker
!-- j···m ~.I.].~III.

: '.uTI Model
)._$. ~ Sales Prices
$"&ii!Client
$. &ii! Showroom
$"~ Financial Period
8:1. @!J Sales
3 Click Run to save the condition and close the Query Panel.
To test the edited LOV

1 Click Display to see the LOV.
The list displays only 4X4 category vehicles.
2 If the list is blank initially, click Refresh to refresh the list.
3 Click OK to accept the modified list.
The .LOV file in the universe subfolder is updated with the modified list.
This is the LOV that will be presented to Web Intelligence and Desktop
Intelligence users when they use the Maker object in a query.
Editing the LOVs for the entire universe

If you want to view all the objects in the universe that have LOVs associated
with them, and possibly edit some of these LOVs at the same time, you can
edit the lists from the Designer Tools menu.
To edit the LOVs from the Tools menu

1 From the Tools menu In Designer, select List of Values.
2 Select Edit a List of Values from the drop-down menu.
The List of Values ad-lib box appears:
H:;'~Client
a:i~ Showroom
The List of Values dialog box displays all the objects in this universe that
have an LOV associated with them. From here, you can select any of
these objects, display, edit, purge and refresh the LOV.

3 Click + next to each class name displayed to see the objects in this
universe that have a LOV associated with them.
4 Click Maker.
The options at the bottom of the dialog box become active. These options
indicate where the values in the LOV are originating, from corporate data
via Designer's Query Panel, or from an external Personal Data file.
Note: Web Intelligence does not support Personal Data files asa data source.
If a LOV is retrieving data from a personal data file, only Desktop
Intelligence users will be able to see the values retrieved by this object.
5 Click Display.
As in the previous exercise, the list displays only 4X4 category vehicles.
Jeep
Subaru
6 Click OK to close the List of Values dialog box.

The Tools>List of Values>Edit List of Values option is useful if you want to
edit all the LOVs in the universe at the same time, instead of displaying the Edit
Properties dialog box for each object separately.

Creating a hierarchy for the LOV
The second way you can modify the LOV is to create a hierarchical structure
so that it is easier for users to find the value they want. This is an appropriate
method to use if you have a LOV that will contain a lot of values.
Note: It's important to be aware that a hierarchical view that you define in the
Properties tab of the object definition (or by selecting Edit List of Values
from the Tools menu) is only supported in Desktop Intelligence. To
create a hierarchical view that is supported by Web Intelligence, refer
to the next unit in this lesson, "Creating a cascading LOV" ,
To create a hierarchy for the LOV for Desktop Intelligence

1 In the object's Edit Properties tab (in the Associate a List of Values zone),
click Edit to the left of the Display button.
The Designer Query Panel displays, as in this example using the Client
Name object:
2 Drag the objects you want to place in the hierarchy into the Result
Objects pane to the right of the existing object and place the respective
sorts on them, as shown below:
o Country
Region
3~
Area
, Client Name
Client Id
Note: Other than the original object, which must be listed first, the other
objects should be listed in hierarchical order, one-to-many, left to
right, and each object should be sorted.
3 Click Run to save the LOV query and close the Query Panel.
Using Lists of Values-Instructor's Guide 6-11

To test the hierarchical view of a LOV in Designer
1 In the Properties tab of the object's Edit Properties dialog box (in the
Associate a List of Values zone), click the Display button to see the LOV.
2 If the list is blank, click the Refresh button to refresh the list.
Boneparte•... France North , Fontainbleau

Latian, Jean France North FontBinbleau
Monet Jean France North Fontainbleau
Piaget Luc France North Fontainbleau
Robert,Chris, .. France North Fontainbleau
Rouseau, Je... , France North Fantainbleau
Ginola, David ,France North .versailles
LeBoufe, Fra... , France, North .v ersaillei
Michaud, Ph.." France North Versailles
Sartois, Jean France North Versailles
Bleu;'Jean France South Nice
BourgoiniJe ... France South Nice
Cantona; Eric France South Nice
Cezanne, Ja,_ Fiance South Nice
Edwards, Ca .. France South Nice
GentiLMichele' France South Nice
Note: This example displays the Tabular View of the LOV,

3 Click the Hierarchical View option button,
The list display changes to show the hierarchy you created.
Note: Only Tabular View is supported when you create queries in Web
Intelligence.
4 You can click the + by each hierarchy level to open it.
_ Germany
41·GiliI Japan
!±1-!jJ)jJ United Kingdom
81;ZS USA
Gill East Coast
gj' Northern States
l?ifi!I Chicago
, iii Baker, Tom
·1iI Baker, William
iii Brown, Nick
iii D~lan; Bob
iii Getz, Stan
iii Jones, Tom
Iii Lee-Curtis,Jamie
5 Click OK to set the hierarchical view as the default display of the LOV for
Desktop Intelligence users.
Continue to the next unit to discuss hierarchical view and cascading LOVs in
Web Intelligence,

----
I
Creating a cascading LOV
Introduction
A cascading LOV is a feature in Designer that allows you to associate a LOV to a
series of objects defined in a hierarchy.When a user applies a prompted query filter
to one of the objects used in the cascading LOV,Web Intelligence prompts the user
to select a value for each level of the hierarchy.
Note: You remove a cascading LOV in the same way that you remove an
ordinary LOV, by editing the object properties and deleting the
condition in the object definition.
Set up a cascading LOV
Use the cascading LOV in Web Intelligence
Setting up a cascading LOV

~j
A cascading LOV is a sequence of lists of values associated with a hierarchy

of objects in a universe. As universe designer, you define prompts for each
hierarchy level and when the user adds one of the objects to a query, the query
prompts the user to select a value for each level.
Universe designers build the prompt(s) in the object definition, and report
designers and power users use it when they create and refresh reports using
queries.
A universe designer defines the universe so that the user is always required to
answer a series of prompts to specify the values in a hierarchy of dimensions
to be displayed in the report. Only the data concerning the selected values is
returned to the microcube.
To build a cascading LOVan an object

1 From the Tools menu in Designer, select List of Values.
2 Select Create cascading Lists of Values from the drop-down menu.
The Create Cascading List of Values dialog box appears:

3 Open the Client class and double-click the Country object to move it into
the Cascading List of Values list.
By default, text appears in the Prompt Text zone to set the text that users
will see if this object is used in a prompted query filter.
4 Double-click one after another the Region, Town and Client name
objects.
Replace the default prompt text "Enter value for Country" with a shorter
text string, for example, "Enter Country", as shown below:
_Car
[~.@]Client
• :n' n Country
;...:fj Region
··..m Town
>:. ill. Area
[fj··ml!lllm!lll!l
: ..4 Address
~.,.' Area Code
\. ·4 PhoneNumber
~ -CBent Id
; Number of dients
$'~5howroom
5 Verify that the Hierarchical View check box is selected.

6 Click Generate LOVs to create the list of values.
Because we generated a LOV for some of these objects in the previous
exercise, a message appears asking whether you want to overwrite the
existing values.
7 Click OK.
The Create Cascading List of Values dialog box closes.
8 Save and export the universe.

Using the cascading LOV in Web
Intelligence
Now that you have assigned LOVs to objects that are grouped together in a
hierarchy as a cascading LOV, you will create a query that builds one of the
objects into a prompted query filter.
To test the cascading LOV in Web Intelligence

1 In Web Intelligence, build a query and create a prompt on one of the
objects in the cascading LOV, for example, the lowest in the hierarchy,
Client Name.
In the example below, the query includes the Model and Cost of Car
Sales objects, and a prompted query filter on the Client Name object:
2 Click Run Query.

The Prompts dialog box appears.

The Prompts dialog box displays the list of values for all the objects you
placed in the cascading LOV in Designer, in reverse order. The Country
values appear first, and as you select each geographical area that
interests you, the values for the next georgraphical area in the hierarchy
appears in the list.
If you are sure you know the exact name of the client that interests you,
you can always type in the "Type a value" text box.
3 Scroll down the list of values and click + next to the US country value to
open that folder.
4 Scroll down and click + next to the East Coast region.
5 Click + next to New York.
6 Double-click Black,Karen.
The little arrow displayed next to the Select Client Name prompt at the
top of the Prompts dialog box changes to a green check mark and the
Client Name value you have chosen appears in the prompt.
a·- New York

. Black.Karen
;.... Dark.Peter
- Clark,Stanley
. Coilirn::.PhiI
j .. Edwards...lane
l·..·F~her,Canie
.: Lee.JoneScPelel
;... PetersLou
.-. Petea,Martin
i-' Smilh.John
7 Click Run Query to create the report.

The report displays the model and cost of the car that Karen Black from
New York bought.

Practice
Activity: Using LOV
Objectives
Associate LOVs to objects.
Instructions
Use the 1 Edit the Maker object so that it only lists cars bought by clients from the
following UK.
objects in 2 Save and export the universe and then build a query in Web Intelligence
these
using the Maker object.
queries:
Maker, 3 Run the query to verify that only data from cars bought in the UK displays
Category of in the report.
Car, Model Tip: Use Maker when you create the query filter.
4 In Designer, create a cascading LOV using the objects in the Car class.
6 Build a query in Web Intelligence that shows the number of cars sold per
showroom and prompts the users to select the Category of Car that
they want to see in the report.
7 In Designer, change the object definition to associate a standard List of
Values for all objects in the Car class.

Lesson Summary
Review
Quiz: Using Lists of Values

1 By default what values are contained in a list of values (LOV)?
Answer:
A LOV is a list associated with an object that, by default, contains all the
distinct values from the fields in the database for that object.
2 What are three things that a universe designer should keep in mind when
deciding whether to associate a LOV with an object?
Answer:
Because a LOV is based on a SELECT DISTINCT query that is sent
to the target database, associating a LOV will have implications for
the efficiency of Web Intelligence.
The only purpose for creating a LOV is to assist the end user in
choosing an operand value for a condition. If the LOV does not do
this, there is no point in associating it with the object.
Unless the LOV is based on a personal file and not a query, the list
will only hold values that exist within the database.
3 For what types of objects is it recommended not to provide a LOV?
Answer:
It is recommended that you do not provide a LOV for the following types
of objects:
All Measure objects
Any object where the LOV will consist of a large number of values
Any object where the list on its own would be meaningless
Summary
lesson
Explain what a list of values (LOV) is
objectives
with the Use a list of values in Web Intelligence
learners to Associate a LOV with an object
check that all View the contents of a LOV
learners have
Set options for generating a LOV
acquired the
required Create a hierarchical view of a LOV
skills before Set up a cascading LOV
moving on to
the next Use the cascading LOV in Web Intelligence
section.

Lesson 7
Resolving Loops in a Universe
This lesson describes loops, a particular type of join issue that can arise as you
create joins between tables in your schema. It explains how you can detect and
resolve loops to ensure that the join paths taken by queries run on the universe
return correct results.
Understanding loops
Resolving loops using aliases
Resolving loops using shortcut joins
Resolving loops using contexts
Duration: 3 hours
'-../ J

Understanding loops
Introduction
A loop is a join path issue that arises from the way that tables are related in a
relational database. Loops can produce instances where a query returns too
few rows of data.

Understand the causes of loops
Detect loops in a universe structure
Recognizing loops
LlENT LASTNAME
LlENT FIRSTNAME
LlENT ADDRESS
LlENT TOWN
. ~LlENT AREA
, LlENT PHONE NO
.•~CLlENT
REGION AREA
ID CODE
MPLOYEE 10
LlENT AGE
OUNTRY ID
ALE I
'LiENT ID
ALE DATE
HOWROOM ID
'ALE SALE DISCOUNT
'ALE TYPE
'ALE TOTAL
'ALE RENTAL PERIOD
A loop exists when the joins between tables form a continuous path.
For example, in the table layout above, the designer has added joins between
the two tables to create two linked sets of information.
One set links the car sale details, the client, and the client's region and
country of residence.
The other set links the car sale details, the showroom, and the country
where the showroom is located.
Together, these joins form a loop.
I
Problems caused by loops
Suppose users of the Motors2004 universe want to produce reports showing
the revenue generated by car sales to clients, including both the location of the
showroom where the cars are sold and the address (including country) of the
clients.
The designer adds the tables needed to provide this information and creates
the joins as shown in the example above. The designer has also created
objects for the Showroom Country, Client Country, and Sales Revenue.
If the loop was allowed to remain and a query could be run using the
Showroom Country, Client Country and Sales Revenue objects, the report
seems to suggest that only clients from the US bought cars in the US
showrooms, and only clients from the UK bought cars in the UK showrooms -
and no clients came from any other countries. When you know that there are
clients from other countries, this result shows that there is a problem.
Loops in a universe schema and not in the database

In a database, multiple paths between tables can be valid and implemented to
meet specific user requirements. When each path is included individually in a
query, it returns a distinct set of results.
However, a schema that you design in Designer often needs to allow queries
that include more than one path, which a relational database may not be
designed to handle. As a result, the information returned can be incorrect.
The rows that are returned are an intersection of the results for the path, so
fewer rows are returned than expected. It is often difficult to determine the
problem when you examine the results.
What is the loop doing?

The joins in the Structure are used to create the WHERE clause in the inferred
SOL of a query. Joins restrict the data that is returned by the query. In a loop,
the joins will apply more restrictions than the designer intended, and the data
returned will be incorrect.
This is the WHERE clause created by the loop:

WHERE
{COUNTRY COUNTRY _ID=SHOWROOM.COUNTRY _ID}
AND {COUNTRY COUNTRY _ID=REGION.COUNTRY _ID }

AND {REGION.REGION_ID=CLIENT.REGION_ID}
AND {CLIENT. CLIENT _ ID=SALE.CLIENT _ ID }
AND {SHOWROOM.SHOWROOM_ID=SALE.SHOWROOM_ID}
AND {SALE.SALE_ID=SALE_MODEL.SALE_ID }
AND {SALE.SALE_TYPE= 'S' }
Notice that the two joins at the top of the SOL are both applying a restriction to
the Country table, which is serving two purposes:
It is being used as the Lookup for the Showroom Country
It is also the Lookup for the Client Country
Resolving Loops in a Universe-Instructor's Guide 7-3

This creates a restriction so that data is returned only when the Showroom
Country is the same as the Client Country. Consequently, the report shows
only the revenue generated by US clients in the US showrooms and by UK
clients in the UK showrooms. In summary, while the above loop does infer
legitimate SOL, the results will not include all intended values. Therefore, a
query on a universe involving such a loop will return misleading data. To avoid
this, the loop must be resolved.
Resolving loops
Loops are a problem inherent in SOL. Nevertheless, you rarely come across
them when writing one-off SOL scripts. It becomes more apparent, however,
because in building a universe you create a permanent model from which all
SOL queries are to be inferred. There are various techniques within SOL that
you can apply to resolve loops. These techniques can also be used to resolve
loops within the Designer module.
How Designer deals with loops

There are automatic routines built into Designer that can be used to identify
and resolve almost all loop problems. The two main methods of resolving loops
are:
Using Aliases
Using Contexts
However, before you use either of these routines, you must ensure that you
have set all join cardinalities correctly. Cardinality is a tool provided by
Designer to help you detect loops. Checking that you have set all join
cardinality is always the first step in resolving loops.

Resolving loops using aliases
Introduction
One way to solve a loop in the universe structure is to create an alias table.
Describe aliases
Resolve loops using aliases
Resolve self-join loops using aliases
About aliases
CUENT LASTNAME
CLIENT FIRSTNAME
CLIENT ADDRESS
CLIENT TOWN
CLIENT AREA
CUENT AREA CODE
CUENT PHONE NO
REGION ID
EMPLOYEE ID
CUENT AGE
COUNTRY ID
SALE DATE
> SHOWROOM ID
SALE SALE DISCOUNT
SALE TYPE
,ICLIENT ID
I§~t~ ~~~'i-~L PERIOD
An alias breaks a loop by using the same table twice in the same query for a
different purpose. The alias is identical to the base table but with a different
name. The data in the alias is exactly the same as the original table, but the
different name tricks SOL into accepting that you are using two different tables.
The Country table has already been identified as a shared lookup table
because it is serving two purposes in the query you are trying to run (providing
data for the Client Country and also for the Showroom Country). In the
example above, you can see the Country table joined to the Region table for
the Client side of the query, the Country table also is the Showroom table for
the Showroom side of the query.
Note: Another way of spotting the problem table in a loop is that it will have
only the one end of the one-fa-many joins going into it. Check the other
tables in the loop. If you find no others with only one end joins, the loop
.can be resolved using an alias, assuming there are no other tables
joined to country.
To resolve the loop, you need to use the same table (the Country table) twice
in the same query when it is being used for different purposes. However, you
cannot do this in SOL unless you create an Alias table.
You can resolve the loop satisfactorily by creating only one alias table in the
/ example we have been using. The Region join uses the original Country table,
while the Showroom join uses the alias table. However, you could create a
separate alias table for each join in the original table. In the past, this was
Resolving Loops in a Universe-instructor's Guide 7-5

necessary for some relational databases. Today, it is not necessary. However,
some universe designers prefer to alias both tables.
Detecting loops and inserting aliases

The Designer module has automatic routines that detects loops and creates
aliases for you.
To detect loops using the automatic routine

1 Click the Detect Loop button.
The system highlights the loop in the Structure window, and displays the
Loop Detection dialog box.
1 The Loop 1/1 indicates how many loops have been detected. Ifthere are
others, you can use the forward and back arrow buttons to check each
loop. The message beneath the buttons indicates (in this case) that the
loop can be resolved with an alias.
2 Click Insert Alias in the Loop Detection dialog box.
Designer automatically creates an alias of the Country table. You may
need to move the new alias table so that you can see the structure.
Note: The original table of which the new table is an alias is shown in
brackets in the title.

3 Close the Loop Detection dialog box.
The Structure dialog box looks like this:
In the above example, the Country_Showroom alias table has been created in
the Structure, the join between this Alias table and the Showroom table has
been made automatically, and the loop has been broken.
Note: When the problem table has two purposes, Designer might nominate
either of the two as the candidate for the Alias table.
To insert the alias automatically

Designer has an automatic routine that detects the tables that could be aliased
to resolve loops.
1 Click the Detect Aliases button.
The system displays the message:
If you have not yet set cardinalities, this message reminds you that you
must do so first. If cardinalities have already been set, the reason for the
message may be a self-restricting join within the universe structure.
Cardinality is not relevant for these types of joins and so designers tend
not to set cardinality for them. However, to avoid the message, you could
make self-restricting joins one-to-one.

2 Click OK.
The Candidate Alias dialog box displays.
All the tables that could be aliased to resolve a loop are listed in the left
panel. The suggested alias names are shown in the right panel. You can
change these, if required.
3 Select a table name and click Rename.
The Rename Table dialog box displays.
4 Enter the new name for the alias and click OK.
The Rename Table dialog box closes and the new alias name is shown in
the right panel.
S To create the alias table, click Create.
Designer displays a confirmation request.
6 Click OK to create the alias table.
Note: If there are several candidates for aliases, you can then repeat the
process for the next table. When there is only one candidate (as in
the example above), the Candidate Alias dialog box closes.
Tip: Be careful not to delete the original table. Once you have created one or
more alias tables, it's a good idea to click beside the original table in the
Structure pane and type Aliased table Do not remove, for example, to
remind you not to delete it.

Inserting an alias manually
Instead of using the Loop Detection or Alias Detection routines, you can create
the alias manually.
1 Select the table for which you want an alias by clicking the table header.
2 Click the Detect Alias button.
OR
Right-click the table and select Alias from the speedmenu.
This opens the Creating an Alias for dialog box.
3 Enter the new name for the alias table and click OK.
This creates an alias table for the selected table.
Note: The original table for which the new table is an alias is shown in
brackets in the title.
4 Remove the appropriate join from the original table.
5 Reset the join to the alias table.
6 Set the cardinality for the join.
The Structure should now look the same as when using the first method,
the Loop Detection routine.
Redefining objects
When you create an alias table, check that any existing objects that are
defined from the original table are still referring to the right table. It may be that
they should be defined from the alias table to infer the correct SQL and get the
correct result.
'---./1
Finding objects defined from a table

'---./
I
In a simple universe, it is not difficult to find the objects that have been defined
from a table. However, in a more complicated universe, it may be quite difficult
to find all the relevant objects.
Designer provides an option to assist in finding the relevant objects.
1 Right-click the header of the original table in the Structure.
2 Choose View associated objects from the speed menu. This highlights
all the objects that were defined from the original table in the Classes and
Objects. Redefine the highlighted objects to make sure they point to the
correct table.
3 Double-click the affected object to open the Object Properties dialog box.
4 Redefine the Select statement to use the alias table instead of the
original table.
5 Click OK and then save the universe.

Listing and renaming aliases
You can list aliases and rename them. To invoke the aliases list:
1 Select the List of Aliases option from the Tools drop-down list.
The List of Aliases panel appears:
To rename an alias from the List of Aliases panel

1 Click the alias you want to rename.
2 Edit the alias name in the New Name field and click OK.
Note: The alias name will be changed in the universe structure, any
object referencing the alias, and context lists.
Choosing which alias method to use

Finds
Choose
Cantance.
the
May all
Advantagestable
resolved
No
Must
view candidate
visual
need
show tocontexts.
understand
loops
by
for
check
Disadvantagesother
candidate
prior
loops
howtoto
to
analysis.
accep-
identify
be
them. Method
aliases
before
objectminimizing
alias, redefinition.
applying
exclusively.
Insert alias Detect aliases
Detect loops
Whichever method you choose, you must always redefine objects that now
use the Alias table.

Resolving self-join loops using aliases
A self join is a join from one column of a table to another column of the same
table.
A classic example of when such a join is required is in a situation whereby you

want to report on the hierarchical structure of an organization via a Personnel
.. database. In such a situation, it is most probable that all employee records are
held in a single table, irrespective of status. Hence, a self join is required to
report on the hierarchical relationship between those employees.
For example, in the Motors2004 database there is an employees table that
contains columns as shown below:
EPT 10
EMP LASTNAME
EMP FIRSTNAME
EMP 008
EMP ADDRESS
EMP AREA CODE
EMP TOWN
EMP PHONE
SHOWROOM 10
EMP START
EMP MGR 10
EMP SEX
08 10
Each employee is uniquely identified by the EMP_10 field, and each employee
has a manager, who is identified by the EMP_MGR_IO field. However, the
managers are themselves employees, and the table therefore contains a
hierarchical structure.
If you want to add a join to link each employee with their respective manager,
the obvious way is to link the EMP_MGR_IO field to the EMP_10 field, as in
this example:
The code used to identify the manager (EMP_MGR_IO) is itself an employee

code. You can therefore use it to look up the EMP_10 codes in the Employee
table and identify the manager's name.
This is effectively a loop, as the path forms a closed circuit. However, we
cannot resolve it by using the usual method of detecting the cardinalities and
then detecting aliases. This is because the cardinality detection routine cannot
work on a self join. Moreover, a structure expressed this way will not infer the
correct SOL.

To resolve a self join with an alias
1 Right-click the table header and choose Alias from the speedmenu.
2 Enter an appropriate alias table name.
In the Employee example, you could call the alias table Manager.
3 Click OK.
4 Draw the join between the original table and its alias.
In the example, you would draw the join between
EMPLOYEE.EMP _MGR_ID and Manager.EMP _10.
5 Double-click the join.
The Edit Join dialog box opens.
6 Set the cardinality for the join.

In the example, each employee has one and only one manager, and
each manager has one or more employees.
The resolved self join now looks like this:
iiE'~RG6¥!i!i@;';;
',EMP ID
!~~~T JPsTNAME D
i~:~~
bl~~TNAME
!EMP ADDRESS
EMP U\STNAME
EMP FIRSTNAME
EMP D08
. EMP AREA CODE EMP ADDRESS
EMP TOWN EMP AREA CODE
EMP PHONE EMP TOWN
SHOWROOM ID EMP PHONE
EMP START SHOWROOM ID
EMP START
EMP MGR ID
EMP SEX
~t~EX=-·· [
When the self join has been resolved, you can create separate objects for both
the manager and the subordinate employees.

----------------
For example, in the Motors2004 universe you can then add a class named
Personnel, containing objects named Manager and Staff. The Select
statement for Manager needs to concatenate the Last name and First name
from the Managers table, while the Select statement for Staff needs to
concatenate the Last name and First name from the Employees table.
Note: This solution only works for situations where the levels in the hierarchy
are known and fixed. Alternative solutions are available for hierarchies
that are either of an unknown number of levels or variable.

Resolving loops using shortcut joins
Introduction
Another way to solve a loop in the universe structure is to use a shortcut join.
Describe how shortcut joins can make a query more efficient
Resolve loops using shortcut joins
Using a shortcut join

A shortcut join is a join that links two tables together but bypasses intervening
tables that exist in the universe. This is used when designing universes where
it is possible in certain circumstances to make the inferred SOL more efficient.
For example, in the Motors2004 universe, the geographical information
relating to Clients comes from the Client, Region, and Country tables:
ID
LASTNAME
FIRSTNAME
COUNTRY ID EGlON ID ADDRESS
COUNTRY NAME EGlON NAME TOWN
OUNTRY ID AREA
AREA CODE
PHONE NO
ID
If an end user runs a query including Country and Client (but not Region)
objects, you will find that the inferred SOL includes the joins to the Region
table. This is necessary because the Region table forms the link between the
Client and Country tables. However, the additional lookup decreases the
efficiency of the SOL.
You can overcome this inefficiency by making a join directly from the Client
table to the Country table. Now if a user builds a query just using Country and
Client, the query will not have to refer to the Region table.
i;HUm::iii;\WI;fu!wf''''
'CLIENT ID ..
CLIENT lJI.STNAME
CLIENT ADDRESS
. CLIENT TOWN
CLIENT AREA
._ •CLIENT AREA CODE
.••.•••
'- .\ • CLlENT
CLIENT PHONE
...•... NO
FIRSTNAME
-',,- ___ ~ REGION ID ID
EMPLOYEE
.••.•••
~...;;;.CLlENT .AGE.
However, you now have a loop. In this case, you can resolve the loop by
specifying the join as a shortcut join as opposed to creating an alias or
contexts.
To convert a standard join to a shortcut join

1 Double-click the join we have added between the Client and Country
tables.

The Edit Join dialog box appears.
'-.-/ 23
'-./
'-.-/
'-../
Click the Shortcut join check box just below the Cardinality zone.
Click OK to close the dialog box.
The join has been redefined as a shortcut join, which appears in the
Structure window like this:
LlENT ID
ICLIENT LASTNAME
CLIENT FIRSTNAME
CLIENT ADDRESS
CLIENT TOWN
CLIENT ,",REA
CLIENT AREA CODE
CLIENT PHONE NO
REGION ID
MPLOYEE ID
LlENT AGE
OUNTRY ID
Now if you were to try detecting loops, you will find that none are
detected. The shortcut join is telling the SOL only to use this join if the
Region table is not included in the query. Therefore, there is no loop, and
the efficiency of the SOL has been improved.
Note: Shortcut joins are not automatically detected for contexts. If you want
to include them in a context you have to manually edit the context.
However, this is not always desirable. In some cases, the efficiency
gains of a shortcut join are based on the fact that it straddles contexts.

Practice
Activity: Resolving loops with aliases
Objectives
Resolve loops by creating alias tables.
Instructions
In this workshop you will add new tables, insert new joins, and set cardinality,
that will create loops in the Motors2004 universe. You will then resolve the
loops and test them.
1 Insert the following join and set its cardinality.
COUNTRYCOUNTRY _ID=SHOWROOM.COUNTRY _ID
2 Use the Detect Loop tool bar button to test for loops in your universe. To
solve the loops that you have detected by creating alias tables, press the
Insert Aliases button in the Loop Detection dialog box, or use the Insert
Alias tool bar button and create two alias tables called:
COUNTRY_SHOWROOM
COUNTRY REGION
3 Disconnect the original COUNTRY table from the other tables and use
the alias tables to redefine the joins as follows:
COUNTRY _SHOWROOM.COUNTRY _ID=SHOWROOM.COUNTRY
ID
COUNTRY _REGION.COUNTRY _ID=REGION.COUNTRY _ID
COUNTRY _REGION.COUNTRY _ID=CLlENT.COUNTRY _ID
Set the new joins cardinalities. In the third join, be sure to select the
Shortcut join check box.
4 Create a Country object in the Showroom class with the settings:
Name = Showroom Country
Type = Character
Description = Country in which showroom exists
Select = COUNTRY _SHOWROOM.COUNTRY _NAME
Associate a LOV
5 Edit the Country object in the Client class as follows:
Name = Client Country
Select = COUNTRY _REGION.COUNTRY _NAME
6 Check integrity.
The check integrity routine will find divergences because the COUNTRY
table is now isolated. Ignore this message and don't delete the original
table.
S In Web Intelligence, test the new objects as below.

Build a query containing Showroom Country, Client Country, and
Sales Revenue objects.
9 Project just the Showroom Country object in a table and note the results.
More than two countries will be shown.
10 In Designer, create an additional alias of the COUNTRY table, called
COUNTRY_MAKER.
11 Insert the following join:
COUNTRY _MAKER.COUNTRY _ID=MAKER.COUNTRY _ID
Make sure that the join cardinality is set to 1 to many.
12 Create a Maker Country object in the Cars class.
13 Save and export the universe and test the new object by building the
following query in Web Intelligence:
Build a query containing Maker Country, Maker and Model objects.

Resolving loops using contexts
Introduction
Another way to solve a loop in the universe structure is to create contexts.
Describe contexts
Resolve loops using contexts
About contexts
A context resolves a loop by defining a set of joins that define 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 schema that contain multiple fact tables that share
lookup tables.
An example of this situation is the SALE table in our Motors universe. The
SALE table contains rows of data for cars both sold and rented. The SALE_TYPE
column is used as a flag to indicate the type of transaction (S = car sale, R = car
rental). Without the self restricting join, the results set of the query would produce
rows where the SALE_TYPE column is equal to either'S' or 'R'.
In Lesson 3, you defined this self-restricting join to'S', so that any object based on
the table or joins passing through that table would produce query results covering
only car sales.
In order to retrieve data concerning rental sales as well, you create an alias of
the SALE table called RENTAL, set the self-restricting join to 'R' and create an
alias table of the SALE_MODEL table called RENTAL_MODEL. Creating the
aliases tables, however, will create a loop because the query will not know
which table to go through to get to the MODEL table, SALE or the alias
RENTAL.
You can solve this type of loop by creating two contexts which will define the
correct route through the universe structure. These routes link together tables
in the structure.
What is a context?
A context is simply a list of joins that define a path for a query. The tables
. involved in the joins are included in the context.
Any objects derived from tables included in a context are compatible with each
other. When a query is made with objects related to separate contexts, more
than one Select statement is inferred and run. The results of the queries are
then merged in the microcube. This avoids incorrect results that might arise
due to a loop or other situation with alternative routes.
Alternative routes can exist without a loop in the universe structure.

Detecting and creating contexts
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-to-one, many-to-one.
Identifying the joins that make up a context

Designer detects contexts by identifying tables that have only the many ends
of joins attached. It does this progressively throughout the structure.
No joins flowing back from one-fa-many are included.
To help to see the flow of contexts within a structure, you can arrange the
tables so that all the joins flow as many-fa-one from left to right across the
structure.
Included in the context are all the tables that can be reached by following the
flow from many-fa-one. Tables that can only be reached by flowing back from
one-fa-many are not included in the context.
Note: If contexts are an important part of your universe structure, it can be
very helpful to arrange your tables in this way, so that you can easily
see the individual contexts.
, ''''''''\;; :eDENI':,:::':'::""
CUEI"T 10
CLIENT LASTNAME
CLIENT FIRSTNAME
CLIENT ADDRESS
CLIENT 'TOWN
CLIENT AREA
CLIENT AREA CODE
CLIENT PHONE NO
REGION 10
When it is not appropriate to resolve a loop by using an alias to break the loop,
the loop must be left in place. However, this results in an error message when
running a Web Intelligence or Desktop Intelligence query. This is because
there are two alternative routes around the structure. Contexts are used to
specify those alternative routes and ensure that a single inferred Select
statement only includes reference to columns from tables in one of those
routes.
In the Sales and Rental example, you can follow two different paths from the
Client table to the Model table:

By way of Rental and Rental_Model:
By way of Sale and Sale_Model:
Each context represents what may be inferred in a single SELECT statement.

Any query that infers some SQL code exclusive to one context and some
exclusive to the other will infer two separate SELECT statements.

This loop can be resolved by two candidate contexts:
and
Sale_Model
Sale.ClienUd
Sale.Sale_ld=
Style.Style_ld
Model.Model_Price
Model.
Sale_Model.
Maker.MakeUd
Sales ModeUd
MakeUd=
Client.Region_ld
Client.ClienUd= Content
Country.Country_ld=
Region.Country_ld
Region.
Sale _Price _Id between
ModeUd=
Region_ld=
_Range.
ModeI.Style_ld=
_Model.Sale Price
Price_Range
_Range_Max
_ Min
Max
Min and
Rental. ClienUd
Client.Region_ld
Sales
Region.Country_ld
_Price
Style.Style_ld_Range. Price_Range_
Rental_Model.Sale_ld
Model.ModeUd
Maker.Maker_ld RentaCModel Context
Sales_Price
Model.Model_Price
RentaI.Sale_ld=
Client.ClienUd=
RentaL
Model. _Range.
ModeI.Style_ld=
Maker
Model._Id=
Region.Region_ld=
Country. Country _Id=between
Price_Range_
ModeUd=
Note: The name of the context is normally defined by the table with only the
many end of joins attached to it.
You then create different sets of objects from the tables in the different
contexts. As a result, users can run either Sales queries or Rentals queries,
dependent on the objects they select.
Note: Every join (excepting shortcut joins) must exist in at least one context.

Detecting and creating contexts
The table below shows the toolbar buttons you can use to detect and create
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.
To detect contexts using the Loop Detection routine

1 Create the RENTAL and RENTAL_MODEL alias tables.
2 Insert the RENTAL_PRICE_RANGE table.
3 Define the joins and cardinalities as you did for the corresponding original
Sale tables.
4 Click the Loop Detection button in the Editing toolbar.
The system displays the Loop Detection dialog box.
In the Motors2004 universe, the routine would detect all the loops that
you created with the two alias Rental tables. The first loop is highlighted
in the Structure window, and the message tells you that this loop is not
covered by any context. If other loops exist, click the forward arrow button
to cycle through the loops. Each loop is highlighted in turn, and a method
of resolution is recommended.
5 Click the Candidate Context button to see what the routine suggests.
The Candidate Contexts dialog box displays.
6 Highlight the Candidate Context you want to add and click the Add
button.

The context is moved across to the Accepted Contexts field. You can
click the Rename button to give each context a more meaningful name.
In the Motors2004 universe, you could rename the Sale_Model context
SALES, and rename the Rental_Model context RENTALS.
'-" Note: You may choose to leave the original context name in brackets.
87 This can be useful in order to remind you that you have changed
.'-"
J
'-"
----'
'-.../
\.~
the joins in the context, while still allowing you to view the original
definition.
Repeat the process until you have accepted all the candidate contexts.
Note: Each candidate context is highlighted in the structure as you
highlight it in the Candidate Contexts field. This enables you to
check the context before accepting it.
Click OK.
The Candidate Contexts dialog box closes, and the List Mode window
opens in the upper part of the Structure window. In the Motors2004
universe, the Loop Detection dialog box now looks like this:
9 Close the Loop Detection dialog box.

The List Mode window shows the two contexts:
COUNTRY
MAKER
MODEL
REGION
RentaJ(SALE)
RENTAL.-MODEL (SAlE~ODEL)
SI'LE
SA.LE...MODEL
SALES_PRfCE.-F'\ANGE
S1YLE
The Joins panel indicates the joins that are involved in the currently
highlighted context. The Structure window highlights the tables that are
involved. If you click the SALES context in the Contexts panel of the List
Mode window, the Joins panel and the Structure window will highlight the
joins and tables in the SALES context.
10 When you have created the contexts you require to resolve the loops,
save the universe.
To detect contexts using the detect contexts routine

1 Click the Detect Contexts button.
The system may display this message:

You may have just set the cardinalities, but you can still get this message
because of self-restricting joins. The system does not set cardinality on
these, and therefore displays this message. Because all the other joins
have their cardinality set, you can click OK to continue.
2 Click OK.
The system displays the Candidate Contexts dialog box.
3 Highlight the Candidate Context you want to add and click the Add
button.
You move contexts across to the Accepted Contexts field. Rename them,
if required, in the same way as when using the Loop Detection routine.
4 Repeat the process until you have accepted all the candidate contexts.
5 Click OK and save the universe.
To insert contexts manually

1 Click the Detect Contexts button.
The New Context dialog box appears.
2 Define a name to identify the context in the Context Name field. In this
example, you might call your contexts SALES and RENTALS.
3 Select the joins that define the path for the context by clicking the
individual joins in the Current context join list. To remove a join from the
selected list, simply click it again to remove the highlight.
Note: You can also add joins to a context in the List Mode window. Select
the context to which you want to add a join, then press the Ctrl key
and click the join you want to add.
4 When you have made a selection of joins, click the Check button to have
Designer check whether there are any loops in the joins you have
selected.

5 In the Description field, enter the text that displays in the User module
Help field.
In this example, you could enter the following help text for the RENTAL
context: Returns information based on vehicle rentals.
6 Click OK to create the context and close the dialog box.
Note: The Detect button initiates the same routine that is used when you
click the Detect Contexts button, or use the Loop Detection dialog
box.
Creating objects for each context

When all the contexts are in place, you can create objects.
Some objects refer to tables that are included in only one of the contexts. In
our example, such objects include Sales Revenue or Rental Revenue. Other
objects refer to tables which appear in both contexts. In our example, such
objects include Client Name.
Editing a context
Sometimes, when a user makes a query containing objects that require the
Select statement to contain tables which straddle a loop, they are requested to
choose a context from a dialog box. As the user has no understanding of what
a "context" is, it is important to ensure that the context names and the Help
descriptions clearly indicate what effect choosing the context will have on the
results.
To edit the name and help description

1 Open the List Mode window by clicking the View List Mode button on the
standard toolbar.
2 In the Contexts panel, double-click the context you want to edit.
The Edit Context dialog box displays. The example below shows the Edit
Context dialog box for the Rentals context in the Motors2004 universe:
The Context Name shows the name you accepted (or altered) when you
created the context. The Join List shows all the joins that are included in
the context path. The highlighted joins are included.

3 Scroll down the list of highlighted joins to verify that all the joins are
included that are required.
In the RENTAL context, you need to add the self-restricting join:
RENTAL. SALE_ TYPE='R'
And remove the following join that is not necessary:
MODEL.MODEL DAYRENT BETWEEN
RENTAL - PRICE - RANGE. RENT --RANGE MIN AND
RENTAL - PRICE - RANGE.RENT RANGE-- MAX
4 Click the Description field and enter a suitable explanation of the

context's purpose.
For example, in our Motors2004 RENTALS context, you could enter:
Returns information based on vehicle rentals.
The Edit Context dialog box would then look like this:
5 Click OK to close the Edit Context dialog box.

6 Click the View List Mode button to close the List Mode window.
7 Save the universe.
The description that you entered appears in the Context Selection Help dialog
box in Web Intelligence and Desktop Intelligence, and the process of selecting
a context is made easier for end users.

Testing contexts
Any query made in Web Intelligence or Desktop Intelligence that generates a
Select statement which involves straddling the loop will fail without contexts in
place. If contexts are in place, Web Intelligence and Desktop Intelligence will
generate the Select statement(s) in one of three ways. To test contexts, you
should make at least three queries, one to test each form of SQL generation
when applying contexts. The three query types are:
Inferred query
Incompatible objects query
Ambiguous query
Inferred query
A Web Intelligence query is run without prompting an end user to choose a
context. The query contains enough information for the correct context to be
inferred. For example, a user runs a query using the Showroom, Model and
When these queries are run, the data is returned without prompting the user to
select a context. The Sales Revenue object is a sum on the Sale_Model table,
which is part of the Sales context. Web Intelligence infers that the Sales
co.ntext is the one to use for the query.
Incompatible objects query

Objects from two different contexts are combined in a query. The two Select
statements are synchronized to display returned data in separate tables.
The SQL generated by Web Intelligence includes joins that require columns
from tables that do not fit a single context.
For example, if you run a query containing the Showroom, Model objects with
both Sales Revenue and Rental Revenue objects, Web Intelligence identifies
that no single context contains all the joins necessary to include the
SHOWROOM, SALE, SALE_MODEL, RENTAL, and RENTAL_MODEL tables
to which the three objects refer. It therefore generates two Select statements
and merges the results in a single microcube in the Web Intelligence
document.
Note: For an incompatible objects query to work, you need two contexts.
Ambiguous query
An end user is prompted to choose between one query path or another. This
occurs when a query includes objects that, when used together, do not give
enough information to determine one context or the other.
When a query is ambiguous, Web Intelligence displays a dialog box that
prompts the user to select the appropriate context. When the user selects a
context, the corresponding tables and joins are inserted into the SQL query.
For example, if you run a query containing only the Showroom and Model
objects, Web Intelligence identifies that more than one context contains all the
joins necessary to include the Showroom and Model tables to which the two
objects refer.
It therefore asks the user to-identify which context to use by displaying the
Context Selection dialog box.

When the user selects one of the contexts and clicks OK, a Select statement
is inferred using the join path for the context chosen.
Note: For a user to select more than one context when running an ambiguous
query, the Allow selection of multiple contexts option in the SQL tab of
the Universe Parameters dialog box in the Designer module must be
selected.

Updating contexts
Contexts are not updated automatically when the universe structure is
changed. If you add or remove any tables or joins to the structure, you will have
to update all the contexts.
If you have made only a simple change to the structure, you can update the
joins that are included in each context manually using either the Edit Context
dialog box or the List Mode tool bar option. However, if you have made
significant changes to the universe structure, it can be safer to remove the
current contexts and recreate them.
Recommended sequence
Because of this requirement to update contexts, it is always best to create all
your alias tables first, and then create your contexts. Otherwise, your alias
tables will not be included in your previously created contexts.
For loop resolution, therefore, the sequence is as follows:
1 Set cardinality on all joins.
2 Use Detect Aliases to detect all the loops that can be resolved with alias
tables.
3 Insert all the required alias tables and their associated joins. Remember
to set cardinality on any new joins.
4 Use Detect Contexts to detect all the contexts that can be used to resolve
the remaining loops that could not be resolved with an alias.
5 Accept the candidate contexts, or create your own contexts manually.
The need to follow this sequence highlights the main drawback of using the
Loop Detection routine. If you detect all loops, and then follow the Loop
Detection dialog box suggestions for resolving them in the order that they are
presented, you will not necessarily resolve all the alias table loops first,
followed by all the context loops. It is therefore better to use the Alias Detection
routine first, and then the Context Detection routine.
Remember also that you will have to redefine any objects that are based on
tables for which you have created aliases. The overall sequence in universe
design is therefore as follows:
1 Add tables to the universe
2 Insert joins
3 Detect and resolve loops
4 Create all the classes and objects
However, if you want to test your loop resolution in the User module, you may
need to create some basic objects just to allow you to run some simple
queries. If you do this, always bear in mind the need to redefine them when
. you have finished resolving loops.
Remember to check the inferred SQL by creating objects and running queries
in Web Intelligence or Desktop Intelligence.

Practice
Activity: Resolving loops using contexts
Objectives
Resolve loops by using contexts.
Instructions
In this workshop you will add new tables, insert new joins, and set cardinality,
that will create loops in the Motors2004 universe. You will then resolve the
loops using contexts, and test them.
1 In Designer, create the following aliased tables:
RENTAL (alias of SALE)
RENTAL_MODEL (alias of SALE_MODEL)
2 Insert the table.
RENTAL_PRICE_RANGE
3 Insert the following joins and set their cardinality.
Joins
- - - -
RENTAL.SALE_ID=RENTAL_ MODEL.SALE_ID
FINANCE_PERIOD.FP
RENTAL_MODEL.COLOUR_ID=COLOUR.COLOUR_ID _START
_END
RENTAL_PRICE_RANGE.RENT and
_RANGE_MAX
_RANGE_MIN and
RENTAL.SALE DATE
CLlENT.CLlENT TYPE='R'
SHOWROOM.SHOWROOM
MODEL.MODEL_DAYRENTbetweenID=RENTAL.SHOWROOM
between
ID=RENTAL.CLlENT
RENTAL_MODEL.MODEL_ID=MODEL.MODEL_ID
10 10
4 View loops using the Loop Detection Routine.

Tip: You should find 10 loops.
5 Resolve the loops by using the Context Detection Routine.
6 Edit the RENTAL_MODEL context as follows:
Change the name of the context to RENTALS.
Enter Returns information on cars rented as a description for the
context.

Remove the "MODEL.MODEL_DAYRENT between
RENTAL_PRICE_RANGE.RENT _RANGE_MIN and
SBEN:rAt_PRICE_RANGE.RENT _RANGE_MAX" join from the
context list.
Add the self-restricting join RENTAL.SALE_ TYPE='R' to the context.
7 Edit the SALE_MODEL context as follows:
Change the name of the context to SALES.
Enter Returns information on cars sold as a description for the
context.
"'") Ii· •.1\.

_, .~"') Remove the "MODEL.MODEL_PRICE between and
X·SALES::PRICE_RANGE.PRICE_RANGE_MIN
( tfJJ'i. ~""" .SAl.:ES_PRICE_RANGE.PRICE_RANGE_MAX" join from the
\ context list.
Add the self-restricting join RENTAL.SALE_ TYPE='S' to the context.
8 Create a class called Rentals above the Sales class.
9 Create the following subclasses in the Rentals class:
Rental Details
Rental Dates
Rental Figures
10 Create the following objects in the appropriate subclass of the Rentals
class.
PERIOD*RENTAL_MODEL.S
Select Date
beenl
returned
Value
Total
Statement
RENTAL.SALE_ID
RENTAL.SALE_DATE
Unique
First rental
isInvoice
to
+ofbe
Rental
SUM(RENTAL.SALE_RENTAL
Objectday car 10 Number
has
Invoice
Rental
Description
e
venue
eNum-
-
00
RENTAL.SALE_RENTAL_PERI
ALE_QTY*MODEL. MODEL_0 Object
UNT Name-
AYRENT*(100
RENTAL.SALE_SALE_DISCO
1100»
11 Create a subclass called Day Rental Charges in the Cars class. Then
populate the subclass with the following objects.
Select Statement
MODEL.MODEL_DAYRENT
T_RANGE Description
RENTAL_PRICE_RANGE.REN
Standard of Rental
Charge banding
Object Day Charge
Description
Charge Object Name
Day
ntal
12 Save and export the universe, then test the contexts used to resolve the
loops by building the following queries in Web Intelligence:

Showroom dimension and Sales Revenue measure objects. The
inferred select statement for this query should use the SALES
context.
Showroom dimension and Rental Revenue measure objects. The
inferred select statement for this query should use the RENTALS
context.
Showroom dimension, Sales Revenue and Rental Revenue measure
objects. This query should infer two select statements, one for each
context.
Showroom, Model, and Maker dimension objects. With this query
Web Intelligence cannot automatically infer which context to use. A
dialog box should appear asking which context to use.
13 Insert the table named FRANCHISE in the universe structure. Insert the
joins specified below and set cardinalities.
SHOWROOM.SHOWROOM_ID=FRANCHISE.SHOWROOM_ID
FRANCHISE.MAKER_ID=MAKER.MAKER_ID
14 Detect contexts using the method of your choice.
Tip: In this instance, it is unnecessary to remove existing contexts and
redetect them as they are not affected by the FRANCHISE table and its
joins.
Create the following object in the Showroom class, and then use it in a
query to test that the context has resolved the loop correctly.
Select Statement
MAKER.MAKER CarNAME
manufacturers
Object Descriptionwith
Object
which the Name
contractedshowroom has a
dealership.
ises
Create a Staff16 Check the

dimension integrity
object basedof on
thethe
Motors2004
EMPLOYEE Universe
table. Design-Instructor's
universe with all options checked.
"r'
/'
/"
/'/'
r' r'/'
Guider-'
S r'
/'
/'
17 Tip: MANAGERS.
table.
You
SaveTo want
Resolve
theget
You to
any report
relevant
Motors2004
the query
should on Managers
divergence.
touniverse
not find infer
any the and and their
closeSQL,
correct
divergences. staff.
it. you will need to resolve the
Lesson summary
Review
Quiz: Resolving Loops in a Universe

1 What is the first step in resolving loops?
Answer:
Detecting cardinalities.
2 What causes a loop?
Answer:
A loop is a join path issue that arises from the way that lookup and fact
tables are related in a relational database. Loops can produce instances
where a query returns too few rows of data.
3 What are the two main methods of resolving loops?
Answer:
aliases and contexts
4 What are the three types of queries you can use to test your contexts?
Answer:
inferred, incompatible, and ambiguous
Summary
Understand the causes of loops
Detect loops in a universe structure
Describe aliases
Resolve loops using aliases
Resolve self-join loops using aliases
Describe how shortcut joins can make a query more efficient
Resolve loops using shortcut joins
Describe contexts
Resolve loops using contexts

Lesson 8
Resolving SQl Traps
This lesson deals with two common SQL Traps: Chasm and Fan. Chasm traps
and fan traps are problems inherent in SQL that are caused by the order in which
the elements of the SELECT statement are processed.
Understanding SQL traps and universes
Resolving chasm traps
Resolving fan traps
Duration: 1.5 hours

Understanding SQL traps and universes
Introduction
In order to avoid common SQL traps in your universe, it is important to
understand how aggregates in queries may result in incorrect data.
Explain how SQL traps can cause queries to return inaccurate results
About SQL traps

Chasm traps and fan traps are problems inherent in SQL that are caused by
the order in which the elements of the SELECT statement are processed.
In SQL, a SELECT statement processes the SELECT, FROM, and WHERE
clauses first (with the exception of any aggregates). In doing so, it creates a
product of all the tables in the FROM clause on the basis of the joins and
restrictions specified in the WHERE clause. This can be thought of as a virtual
table. Normally this does not cause a problem, but if an aggregate is applied
then it may, in particular circumstances, result in wrong output being
generated. This is particularly worrying because SQL does not produce an
error message, it just projects the results.
Unlike loops, that return fewer rows than expected, chasm traps and fan traps
return too many rows.
Fortunately, there are ways of identifying situations in which chasm traps and
fan traps can occur, and there are methods of resolving these situations.

Introduction
This unit explains how chasm traps can occur in the universe structure and
how to resolve them.
Explain what a chasm trap is
Detect chasm traps in a universe structure
Resolve chasm traps
Chasm traps
A chasm trap is a common problem in relational database schemas in which a
join path returns more data than expected.
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.
You only get incorrect results when the following circumstances exist:
1 There is a "many-to-one-to-many" relationship between three tables in
the universe structure
AND
2 The query includes objects based on the two "many" tables
AND
3 There are multiple rows returned for a single dimension value.
For example, in this diagram there is no loop, but the flow around the three
tables is many-to-one-to-many.
x " r:] ';'.1"":;"
.'
/ ..,/
",
"'- .•••..•.
,.~ ~. z
Note: A chasm trap is not dependent on the object types. The query could be
made up of only dimensions, only details, or only measures, or any
combination of the three types with the "many" tables for a chasm to
occur.
When a query that uses objects Y and Z is run, the inferred SQL includes
tables B, C, and A that have a "many-one-many" relationship respectively. The
chasm trap causes a query to return every possible combination of rows for
one measure with every possible combination of rows for the other measure.
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.
\
Resolving SQL Traps-Instructor's Guide 8-3

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

Unlike loops, chasm traps are not detected automatically by Designer.
However, you can use the contexts detection tool (Tools> Detect Contexts) to
automatically detect and propose candidate contexts in your schema.
Detect Contexts examines the "many-to-one" joins in the schema. It picks up
the table that receives converging "many-to- one" joins and proposes contexts
to separate the queries run on the table. This is the most effective way to
ensure that your schema does not have a chasm trap.
You can also detect chasm traps graphically by analyzing the "one-to-many"
join paths in your schema.
If you neither run Detect Contexts, nor spot the chasm trap in the schema, the
only way to see the problem is to look at the detail rows. Otherwise there is
nothing to alert you to the situation.
You can find chasm traps by using Detect Contexts to detect and propose
candidate contexts, and then examining the table where any two contexts
diverge. This point where two contexts intersect is the source of a chasm trap.
Any two tables that have multiple rows converging to a single row in the table
with the "one" relationship may potentially cause a chasm trap.
The Chasm trap scenario

This section demonstrates a chasm trap in the Motors2004 universe, and
propose two solutions to the problem.
In the diagram below, the SALE, CLIENT and RENTAL (SALE) tables are
joined by a "many-to-one-to-many" relationship.
:ALEJD
LlENTJD
ALE..DATE
HOWROOMJD
ALE_SALE.DrSCDUNT
ALE_TYPe
ALE_TOT AL
,ALEFENT AL.PERIOD LlENT JD N
LlENT ..LASTNAME 0
LlENT ..FIRSTNAME 0
LlENT ~ADDRESS . 0
L1ENT _TOWN 0
LlENT .AREA D
LlENT .AREA.DODE D
LlENT YHONEj\lO C

The following objects in Motors2004 reference the tables above:
S'h\ill Client
, S"71 Client Name
i?@j Sales
'i···n Sale Date
i r' >J' Sales Revenue
8 <.\illRentals
j•. 71 Rental Date
t ... ;fJ pental Revenuel
In this scenario, the universe designer has not selected the "Multiple SQL
statements for each measure" option in the Universe Parameters SQL tab.
A user creates a series of queries using these objects and gets inaccurate
results.
Test!
3\ £~I 11 ,('
_ ' o
~ It) ~ ,
Test 2
Test 3
The first two queries return the correct data but combining Sales Revenue and
Rental Revenue in the third query returns inaccurate results.
To understand what is happening here, we need to ~xamine the rows that are
returned by the queries to make the aggregated figures. In our example, we
can do this by adding the Sale Date and Rental Date objects to the queries to
return individual transaction details.
Notice that there are two Sale transactions in query test 1. There are also two
Rental transactions in query test 2.
Resolving SOL Traps-Instructor's Guide 8-5

If you add the dates to the combined query (test 3), you can see why the Sale
and Rental revenues have doubled.
Test 1 Test 3
The query returns every possible combination of Sale rows with every possible
combination of Rental rows. Hence, the Sale transactions each appear twice
as do the Rental transactions, -andas a result of this the aggregates have been
multiplied by the number of related rows on the alternative 'many' table.
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.
The problem with chasm traps is that, unless you look at the detail rows, there
is nothing to alert you to the situation.

To resolve a chasm trap, you need to make two separate queries and then
combine the results. Depending on the type of objects defined for the fact
tables and the type of end-user environment, you can use the following
methods to resolve a chasm trap:
Modify the SQL parameters for the universe so you can generate
separate SQL queries for each measure.
This method is not recommended as it only works with measures and will
result in certain inefficiencies in processing. It does not generate
separate queries for dimension or detail objects.
Create a context for each fact table.
This solution works in all cases and will not result in inefficiencies.
Each of these methods is described in the following sections.
"
~;
..•

Using multiple SQL statements for each measure to
resolve chasm traps
If you have qnly measure objects defined for both fact tables, then you can use
the Universe Parameters option Multiple SQL statements for each measure.
This forces the generation of separate SQL queries for each measure that is
used in the query.
This method is quick and easy, but it is only a partial solution. It does not work
for dimension and detail objects.
The following table describes when you can use Multiple SQL Statements for
each measure and when you should avoid its use:
In universes
one these
object
for
When
In
SQL or
bothis situations
both of the
included
statements
you
fact
have
tables.
that ...
fact tables.
a query
dimension
isin
contain
that
The you If aavoid
based
advantage
only
or
can dimension
measure
detail on
of ordefined
aobjects detail
universe
objects
usingdefined
multiple
contextsfor
You ...
each measure
statements for for
SOL statements returned.
using
creating
and this solution,
produce
contexts
incorrect
toa Cartesian
resolve
results,
the
that you need to maintain later. product
you
chasm
shouldwill
trap. be
consider
Do not
Use use multiple
multiple SQL As the previous solution can slow query response time
To activate multiple SQL statements for each measure:

1 Select File> Parameter's from the menu bar.
The Universe Parameters dialog box appears.
2 Click the SQL tab.
3 Click the Multiple SQL Statements for Each Measure check box in the
Multiple Paths group box to select this option.
Resolving SOL Traps-instructor's Guide 8-7

4 Click OK.
S Save and export the universe.
6 In Web Intelligence, create the query using the Client Name, Sales
Revenue and Rental Revenue.
Designer will now make separate SQL Select statements for each
measure object in the query. This will resolve the chasm trap problem.
7 Run the query.

You can see that the query has now automatically generated two Select
statements. The results in the report are now correct:
However, there are drawbacks to using this method to resolve chasm traps.

Drawbacks to the JJmultiple SQL statements for each
measureJJ method
The results can be confusing.

The SQL Parameter used specifies: "Multiple SQL statements for each
measure". One of the drawbacks is that it does not run separate Select
statements if the query contains only dimension objects.
The report contains a single block with the results displayed as a Cartesian
product.
The report contains a single block

with the results displayed as a
Cartesian product - unclear for
Users.
It's not that there is anything inaccurate about the dates, but the multiple
occurrences will be confusing to users.
The query is inefficient.

Another drawback is that any query including multiple measures will infer a
separate SELECT statement for each measure irrespective of whether it is
required or not.
To find a complete solution to chasm traps, you have to use contexts.

Using contexts to resolve chasm traps
You can define a context for each table at the many end of the joins. In the
example you could define a context from CLIENT to SALE and from CLENT to
RENTAL_(SALE).
When you run a query that includes objects from both contexts, this creates
two SELECT statements that are synchronized to produce two separate tables
in Web Intelligence, avoiding the creation of a Cartesian product.
When do you use contexts?

Creating contexts will always solve a chasm trap in a universe. When you have
a many-to-one-to-many situation, you should always use a context.
To use contexts to resolve a chasm trap:

1 Identify the potential chasm trap by analyzing the many-to-one-to-many
join path relations in the schema.
2 Select Tools> Detect Contexts.
The Candidate Contexts dialog box appears.
3 Select a proposed context in the Candidate Contexts list box and click
Add to add it to the Accept Contexts list box.
4 Repeat for other listed contexts.
The new contexts are listed in the Contexts pane of the List View bar.
S Select File> Parameters.
The Universe Parameters dialog box appears.
The SOL page appears.
7 Select the Multiple SQL for each Context check box to clear the option.
8 Click OK.
When you run queries on the tables in the chasm trap, the query-
separates the SOL into what is compatible for separate select
statements.

Practice
Activity: Resolving chams traps
Objectives
Detect contexts to resolve a chasm trap in the universe structure.
Instructions
1 Create a new universe called Chasms.unv where your connection is to
the Motors2004.mdb.
2 In File Parameters, SQL tab, clear the Multiple SQL statements for
each measure option (deselect the check box).
3 Add the following tables
CLIENT
SALE
RENTAL, as an alias of the SALE table
4 Create the following joins and set the cardinality:
1:N
Cardinality
Join
PE='S'
_ID=RENTALS.CLlENT
_ID=SALE.CLlENT _ID _ID RENTAL.SALE_TYPE='R'
5 Create two classes: one called Chasm Objects, and the other called
Measures.
6 Add the following objects with the following syntax:
DimensionSelect
CLIENT.
SALE. SALE_DATE , + NAME
RENTAL.SALE_DATE
CLIENT_FIRST Dimension
+ '
Qualification
LIENT.CLIENT_LASTNAME Object AND
'BRENDT'
CLIENT.CLIENT_FIRSTNAME = 'PAUL'
Sale Date WHERE CLAUSE
CLIENT.CLIENT_LASTNAME =
Resolving SOL Traps-Instructor's Guide 8-11

SumCSALE.SALE_TOTAL)
Su~CRENTAL.SALE_TOTAL) Measure
Sales Reve-
Rental Reve-
7 Perform an Integrity Check on:

Check Universe Structure
Parse Objects
Parse Joins
Check Cardinalities
9 In Web Intelligence, create a new query using the Client Name and Sale
Revenue objects. What is the sale amount?
316,005
10 Edit the query, and then Add a New query within the same document and
select the Client Name and Rental Revenue objects. What is the sale
amount now?
1,100
11 Edit the query, andthen Add a New query within the same document and
select the Client Name, Sale Revenue and Rental Revenue objects.
What is the sale amount now?
632,010
What is the rental amount?
2,200
What happened to your figures?
They were doubled due to the chasm trap.
12 In Designer, edit the universe: Open the File, Parameters, SQL tab and
select the Multiple SQL statements for each measure option.
14 In Web Intelligence, create a new query with the Client Name, Sale
Revenue and Rental Revenue objects.
What is the sale revenue?
316,005
What is the rental revenue?
1,100
Two select statements generated the correct answers.
15 Edit the query by removing the Sale Revenue and the Rental Revenue
objects from the query; add the Sale Date and Rental Date objects to the
query. What happens to the SQL and to the results?
Single select statement because there are no measures and the
chasm is back. You need to resolve the chasm with a context.
16 In Designer, edit the universe: Open the File, Parameters, SQL tab and
clear the Multiple SQL statements for each measure option again (de-
select the check box).

17 Insert the following contexts:
Context Joins
SALE.CLIENT_IO=CLlENT.CLlENT_10_10
RENTAL.CLlENT_IO=CLlENT.CLlENT
RENTAL.SALE_TYPE='R'
SALE.SALE_TYPE='S'
Rental
Sale

Revenue and Rental Revenue objects.
What is the sale amount?
316,005
What is the rental amount?
1,100
With contexts in place, two select statements ran: one listing the
amount of sales, the other the amount of rentals.

Resolving fan traps
Introduction
This unit explains how fan traps can occur in the universe structure and how
to resolve them.

Explain what a fan trap is
Detect fan traps in the universe structure
Resolve fan traps
Fan traps
Fan traps occur when there is a "one-to-many" join to a table that "fans out"
into another "one-to-many" join to another table,.
This is a common structure and will not normally result in a fan trap. You only
get incorrect results from the fan trap when the query includes a measure
object on the middle table (B) of the table path and an object (of any kind) from
the subsequent table (C). The trap only occurs where (due to the database
design) a column in table B holds data values which are already a sum of those
values held at table C. The results are normally noticeably wrong.
When a query is run useing objects Y and Z, the inferred SOL includes tables
Band C which have a 'one-to-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 alternate solution is to avoid
it in the first place.

Detecting fan traps
You cannot automatically detect fan traps. You need to visually examine the
direction of the cardinalities displayed in the table schema.
If you have two tables that are referenced by measure objects and are joined
in a series of "many-to-one" joins, then you may have a potential fan trap.
The fan trap scenario

This section demonstrates a fan trap in the Motors2004 universe, and propose
solutions to the problem.
In the diagram below, the CLIENT and SALE tables are joined by a "many-to-
one-to-many" relationship, as are the SALE and SALE_MODEL tables:
In this scenario, a user runs a query with a measure object from the SALE table
and another measure object from the SALE_MODEL table:
~ .•~ Clier~
.. n.1ii! C!ieM! N<lov"
r.;;'i:U S,:.!t}$
i .rt::::/j""MooefnJNiXiiJ)ei,·,·,n,!
. 'Iii! Sale Dille
'mO S••!eR~~
; ~ ....'* Nun"£Mrflfr:Ar~·Sdcl!
[£~[Aci1t<lk!
j
In the example above, the fan trap problem becomes apparent in a query that
aggregates both an object based on SALE. SALE_ TOTAL and an object based
on SALE_MOoEL.SALE_QTY.
Test 1
Test 2
What happens in the fan trap

When you run the test 1 query to report the Sales Revenue for a client, the
measure is correctly aggregated. This is a simple aggregate from one table in
the fan trap structure. However, if you also wanted to know the number of
vehicles the client has purchased, and you included the Number of Cars Sold
object in the query, you get an inflated value returned for Sales Revenue.
To understand what is happening, you need to look at the rows that are
returned. Since two different Model 10 Numbers are involved in the Rental
Quantity of 2, there are two rows returned.
As with chasm traps, a single SELECT statement joins each ModeUd row with
the same Rental Value row, which gives you the doubled figure.
However, unless you look at the detail rows, there is nothing to alert you to the
situation.
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.

Resolving fan traps
There are three ways to solve a fan trap problem:
Alter the SQL parameters for the universe.
This method is not recommended as it only works for measure objects
and may result in inefficiencies in processing the query. This resolution
works the same for chasm and fan traps.
Use a combination of aliases and contexts. There are two possible
situations which may require different solutions.
If you have a scenario with:
Three tables in a one-to-many relationship
A dimension coming from the first table and measures coming
from the two subsequent table, then:
Create an alias for the table containing the initial aggregation, and
use Detect Contexts (Tools> Detect Contexts) to detect and propose
a context for the alias table and a context for the original table.
This is the most effective way to solve the fan trap problem because
it will work with measure and dimension objects and does not cause
inefficiencies.
If you have a scenario with:
Two tables in a one-to-many relationship
A dimension and a measure coming from the first table and a
measure coming from the subsequent table, then:
Create an alias for the table containing the initial aggregation, joining
it back to the original table and then use the Detect Contexts tool to
detect and propose a context for the alias table and a context for the
original table.
Both of these methods solve the fan trap problem because they will work
with both measure and dimension objects and do not cause
inefficiencies. You will explore both in the following sections.
Note: However, to be more efficient still, using the two-table scenario,
you could also use the @Aggregate_Aware function. This is
covered in Lesson 12, Optimizing Universes with Aggregate
Aware.
To avoid the scenario in the first place by relating all measure objects in
the universe to the same table in the universe structure. Avoid placing a
measure on anything other than the last table in a table path, which is the
table with the "many" cardinality attached to it.
Resolving SQL Traps-instructor's Guide 8-17

Using aliases and contexts to resolve fan traps
You create an alias table for the table producing the aggregation and then
detect and implement contexts to separate the query. This procedure is
demonstrated in the diagram below:
1) Create an Alias of Table B.
2) Create ajoin between the

I alias Ba and table Aand
set cardinality.
Ba J.•.•
#'
Y
....I1r. 3) Set Contexts C and Ba.
4)Change the SELECT

clause of objectY so that
it refers to thealiasBa
ratherthen tableB,
To use aliases and contexts to resolve a fan trap

1 Identify the potential fan trap by analyzing the one-to-many-to-one-to-
many join path relations in the schema.
2 Create an alias for the table that is producing the multiplied aggregation.
For example, create an alias of the SALE table.
3 Create a join between the new alias table, SALE_ALIAS (SALE), and the
CLIENT table.
4 Set cardinality.
5 Set contexts.
8-18 Universe Design,-Instructor's Guide

6 Change the SELECT clause of the Sale Revenue object so that it refers
to the SALE_ALIAS table rather than the original SALE table.
I
-/ 7 Create a query using a measure object from the alias table and another
measure from the subsequent table in the table path of the universe
structure, in this example, using Sales Revenue and Number of Cars
I Sold.
~
This will result in two SELECT statements:

The results are merged into a single microcube to produce the correct
results:.
Moreover, if you make a query which includes a dimension object on the lower
table in the 'one-many-many' path, you will not suffer the fan trap; even when
that dimension object contains the same value for all rows related to the
measure value. The fact that the measure and dimension objects are in
separate contexts forces two separate Select statements, thus avoiding the
problem.

Another solution using aliases and contexts
The structure shown here involves two tables instead of three. In this example,
both a dimension and measure object are from the same table, and another
measure is from a table in a one-to-many relationship further along the
universe structure:
xfl
y 6)
z 6)
To resolve this type of fan trap, you can:

Create an alias of table A.
Create a join from the alias An to table A and set cardinalities.
Set contexts B and A.
Edit object Y so that it refers to columns in the alias An rather than table A
.y
In the universe structure shown below, you have created an alias table of the
SALES table, and created a join between the alias and the original table. This
is to separate the dimension in SALE from the measure, which will now be
looking at SALE_ALIAS.
S.ALEJD
iCUENT JD
CLIENT ..L.A.STNAME C ISAJ..E..DATE
CLIENT ..FIRSTNAME C
ISHOWROOMJD
CLIENT ...ADDRESS C !SALE.5ALE.DISCOUNT
OLiENT _TOWN 0 :SALE.TYPE
CLIENT ...AREA 0 iSALE.TOT AI...
CLIENT ...AREA-CODE C SALE..RENT ALYERIOD
CLIENT "pHONE.NO C
oND
ALEJD D "" "" -
D-
\
;;~
CLlENTJD
SHOWROOMJD
.ALE.TYPe SAJ..E_QTY
SALE_TOT
SALE..RENT
SAl.E..DATE
"ALEJD
SALE5ALE..DISOOUNT AL AL"pERIODN~
·.'.·,·HH.·.·,·.·,·.·.·.·.·,·.·,·.·.·.·,·,·.WN.·.·.·m.·_·.·N.·.·.·.· MODELJD L;$~b:d~t:f
···N·.·.·.··.",···············
HOWROOMJD
IV?:?\t~¥M*%t?~{:':;:::
ALEJD
ALE.SALE..DISODUNT
COLOURJD
pUENT JD
ALE..DATE AlE_TOT
AlE..RENT AL AL"pERIOD
ALE_TYPe

To use aliases in a fan trap involving only two tables:
1 Create an alias of the SALE table, called SALE_ALIAS.
2 Create a join between the new alias table, SALE_ALIAS and the original
SALE table on SALE_ID.
3 Force the cardinality for this join to N:1.
4 Set contexts.
5 Cchange the SELECT clause of the Sale Revenue object so that it refers
to the SALE_ALIAS table rather than the original SALE table.
7 In Web Intelligence, test the solution using the objects Sale Date,
Number of Cars Sold, Sales Revenue.
When you look at the SQL in the Web Intelligence SQL Viewer, there will be
two SELECTs, one using SALE and SALE_MODEL and the other using SALE
and SALE_ALIAS.
Note: This same fan trap scenario will be presented in Lesson 11, Optimizing
Universes with Aggregate Awareness. Aggregate awareness provides
another solution to this problem. Both solutions return accurate results,
but you will see that the aggregate aware solution is more efficient.

Avoiding fan traps altogether
In certain situations, it is possible to avoid the fan trap completely, as shown in
the diagram below.
To avoid the trap, the database column in table B to which the Y measure
object relates must represent a pre-aggregation of more detailed data in table
C. If this is the case, you can change the code of the Y measure object so that
it refers to table C. Hence, there is no longer a 'one-to-many' relationship
incurred.
1) This is only possible where the

measure on table B is a pre-
aggregation of more detailed
data which exists in table C.
( 2)Codemeasure 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.
This is the method used to avoid the fan trap in the Motors2004 universe,
should the Sales Revenue and Number of Cars Sold measure objects be
included in the same query:
In the Motors2004 universe you have created during this course, 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 database at the same level of granularity as the number of cars
sold. Hence, no fan trap exists and the correct result will be obtained.
Note: Another method of resolving a less common form of fan trap is covered
in the Aggregate Awareness module of this course.

Practice
Activity: Resolving fan traps
Objectives
Detect contexts to resolve a fan trap in the universe structure.
Instructions
1 Create a universe called Fans.unv where your connection is to the
Motors2004.mdb.
2 In File Parameters, SQL tab, clear the Multiple SQL statements for
each measure option (deselect the check box).
3 Add the following tables
CLIENT
SALE
SALE_MODEL
4 Create the following joins and set the cardinality:
1:N
Cardinality
Join
SALE_
PE='S' MODEL.SALE_ID
_ID=SALE.CLlENT _ID
5 Create a class called Fan Objects.

6 Add the following objects with the following syntax:
Dimension Select
CLIENT.
SALE_MODEL.MODEL_ID , + NAMEQualification
CLIENT_FIRST
Sum(SALE.SALE_TOTALJ
Sum(SALE_MODEL.SALE_QTYJ Dimension
Measure
+ '
LIENT.CLIENT_LASTNAME Object
'CRANDALL' AND
CLIENT.CLIENT_FIRSTNAME = 'SEAN'
ModellD WHERE
CLIENT. CLAUSE
CLIENT_LAST NAME =
7 Perform an Integrity Check on:

'--./'
'-"
-.../
'--./' 9
810
Check Universe Structure

Parse Objects
Parse Joins
Save and export the universe.
In Web Intelligence, create a new query using the Client Name and Sale
Revenue objects. What is the sale amount?
57,092
Edit the query and add the Sale Qty object. What is the sale amount
now?
114,184
What is the sale quantity?
2
11 In Designer, edit the universe: Open the File, Parameters, SOL tab and
select the Multiple SQL statements for each measure option.
Revenue and Sale Qty objects.
What is the sale revenue?
57,092
What is the sale quantity?
2
14 Edit the query and add the ModellD object.
What is the sum of the sale revenue?
114,184
What is the sum of the sale quantity?
2
How many different models were purchased?
2
They have doubled due to the fan trap.
15 In Designer, edit the universe: Open the File, Parameters, SOL tab and
clear the Multiple SQL statements for each measure option (deselect
the check box).
16 Add an alias to the SALES table (SALES2).
Create the following joins:
1:N
Cardinality
Join
YPE='S'
SALE2.SALE_ID
Note: Force the cardinality on SALE.SALE_ID=SALE2.SALE_ID join to

1:N.
17 Use the Detect Context function to detect contexts.

Be sure you have the following contexts. You may have to edit the
context by removing or adding joins.
CLlENT.CLlENT_ID=SALE.CLlENT _10
Joins
Context
SALE2.SALE_ID=SALE.SALE_I0
SALE2.SALE_TYPE='S'
SALE.SALE_TYPE='S'
SALE.SALE_ID=SALE_MODEL.SALE_ID
Sale2
Sale Model
18 Modify the definition of the object that is performing multiple aggregations

so that it points to the alias table:
,
Select Measure
Qualification
Sum(SALE2.SALE_TOTA~)
Object

Revenue, Sale Qty, ModellD objects.
What is the sum of the sale revenue?
57,092
What is the sum of the sale quantity?
2
How many different models were-purchased?
2
With contexts in place, two select statements ra9, resulting in two tables:
One listing the sales amount, ttie other details listing the sales models
purchased.

Lesson summary
Review
Quiz: Resolving SQL Traps

1 A chasm trap can occur when:
Answer:
1.) Two joins from many-to-one-to-many converge on a single table.
2.) The query includes objects based on the two "many" tables.
3.) There are multiple rows returned for a single dimension value.
2 Describe two ways to resolve chasm traps.
Answer:
Create a context for each fact table. This solution works in all cases.
Modify the SOL parameters for the universe so you can generate
separate SOL queries for each measure. This solution only works for
measure objects. It does not generate separate queries for
dimension or detail objects.
3 Describe three ways to resolve fan traps.
Answer:
Alter the SOL parameters for the universe. This only works for
measure objects. This resolution works the same for chasm and fan
traps.
Create an alias for the table containing the initial aggregation, and
then use Detect Contexts (Tools> Detect Contexts) to detect and
propose a context for the alias table and a context for the original
table. This is the most effective way to solve the fan trap problem as
it will work with measure and dimension objects.
Avoid the fan trap in the first place by using the same level of
granularity.
Summary
lesson
Explain how SOL traps can cause queries to return inaccurate results
objectives
with the Explain what a chasm trap is
learners to Detect chasm traps in a universe structure
check that all Resolve chasm traps
learners have
acquired the Explain what a fan trap is
required Detect fan traps in the universe structure
skills before Resolve fan traps
moving on to
the next
section.

Lesson 9
Applying Restrictions on Objects
This lesson will help you understand and use restrictions, which are conditions
in SQL that set criteria to limit the data returned by a query.
Restricting the data returned by objects
Duration: 1 hour

Restricting the data returned by objects
Introduction
A restriction is a condition in SQL that sets criteria to limit the data returned by
a query.
You define restrictions on objects to limit the data available to users. Your
reasons for limiting user access to data should be based on the data
requirements of the target user. A user may not need access to all the values
returned by an object. You might also want to restrict user access to certain
values for security reasons.
Define data restrictions
Apply data restrictions to objects
Apply data restrictions using condition objects
Apply restrictions to tables

Apply data restrictions using the Tables button
Apply each type of restriction
Defining data restrictions

The WHERE clause in an SQL statement restricts the number of rows that are
returned by the query.
So far in your universe design work, the WHERE clauses have only been
populated by the joins you made between the tables in the Structure window.
The joins restricted the result set, usually based on equality between tables
and prevented Cartesian products.
You can also use the WHERE clause to further restrict the data that is returned
in a query in circumstances where you' may want to limit certain users to
queries on a subset of the data.

For example, the report below is an unrestricted block containing data for
Clients from all Countries:
The WHERE clause for the query is created from the SQL inferred from the
joins made in the Structure window:
WHERE
CCOUNTRY_REGION.COUNTRY_ID=REGION.COUNTRY_ID)
AND CREGION.REGION_ID=CLIENT.REGION_ID)
AND CSALE_MODEL.MODEL_ID=MODEL.MODEL_ID)
AND CSALE.SALE_ID=SALE_MODEL.SALE_ID)
AND CCLIENT.CLIENT_ID=SALE.CLIENT_ID)
AND CSALE.SALE_TYPE='S')
AND CSALE.SALE_DATE between FINANCE_PERIOD.FP START and
FINANCE_PERIOD.FP_END)
Compare this with the following report, which is a restricted block containing
data only for clients from the United Kingdom:
'J
Gregory, Neil
Applying Restrictions on Objects-instructor's Guide 9-3

The WHERE clause for the query now has an extra line at the bottom. This is
the restriction added by the designer that limits the return of data to UK Clients:
WHERE
(COUNTRY_REGION.COUNTRY_ID=REGION.COUNTRY_ID)
AND (REGION.REGION_ID=CLIENT.REGION_ID)
AND (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID)
AND (SALE.SALE_ID=SALE_MODEL.SALE_ID)
AND (CLIENT.CLIENT_ID=SALE.CLIENT_ID)
AND (SALE.SALE_TYPE='S')
AND (SALE. SALE_DATE between FINANCE_PERIOD.FP START and
FINANCE_PERIOD.FP_END)
AND (COUNTRY_REGION. COUNTRY_NAME = 'United Kingdom'
Methods of restricting data in Web Intelligence

Within the design of a universe, you can either:
Force restrictions, which the end user cannot override: Object, Table,
Conditional Select, Additional Joins
Provide optional restrictions, which the end user can choose to apply:
Condition Objects
Remember that users can apply conditions themselves by way of the Query
Panel. Therefore you should avoid creating optional restrictions that are of a
simple nature, as the end user should be capable of creating such conditions
for themselves on a query-by-query basis.
There are often problems associated with inferred restrictions, as will become
evident during this module. You are therefore advised only to force restrictions
where they are absolutely necessary.

Applying restrictions to objects
To ensure that a restriction is always inferred when a particular object is used
in a Web Intelligence query, the restriction should be placed in the WHERE box
of the Definition tab in the Edit Properties dialog box related to the object. This
can be done at the time of creating the object or added at a later point.
To apply a restriction to an object

1 Open the Edit Properties dialog box for the object and select the
Definition tab.
2 Enter the restriction directly in the WHERE field, or via the Edit WHERE
Clause box.
3 Click OK.
When you have created or edited your object to include a restriction, you
should test it by making a query in the User module. Always view the
inferred SQL to check whether the Select statement includes the
restriction in the WHERE clause and has the desired effect. Remember to
save your universe and export your universe before doing this.
The inferred SQL for our example restriction could look like this:
SELECT
SHOWR OOM.SHOWROOM_NAME.
MODEL.MODEL_NAME&" &MODEL.MODEL_ TRIM&' '&MODEL.MODEL_ENGINE
FROM
SHOWROOM.
MODEL.
SALE_MODEL
SALE
WHERE
(SALE_MODEL.MODELjD=MODEL.MODELJD )
AND (SALE.SALUD=SALE_MODEL.SALUD )
AND (SALE.SALE_ TYPE='S' )
AND (SHOWROOM.SHOWROOMJD=SALE.SHOWROOMJD )
AND (MODEL.MODEL_DAYRENT IS NOT NULL )
The last line of the WHERE clause is taken from the object restriction.
Applying restrictions to objects

You should be very careful to create restrictions against objects only when it is
absolutely necessary.
For example, consider the situation where users of Motors2004 need to make
queries of only those cars that can be rented. The only distinguishing factor in
the underlying Motors2004 database between cars that can be rented and
those that are stocked only for sale is that the Model.Model_Dayrent column
contains data for rental cars and is null for sale-only cars. To create an object
to list cars for rental, the object would have to include the restriction:
Model.Model_Dayrent is not null.
If it is not necessary, it should be avoided.
Applying Restrictions on Objects-Instructor's Guide 9-5

To see why, consider the implications of creating a UK Clients object as
illustrated below:
The drawbacks are as follows:

You would get a confusing proliferation of objects for end users because
you would then need a French Clients object, a German Clients object,
and so on.
As these objects would all represent alternate restrictions, you would not
be able to construct a logical default hierarchy, which end users make
use of when drilling down.
Although the UK Clients example is fairly clear, in many cases the
restriction will not be obvious to the user simply from the name of the
object: the details of the WHERE clause are not shown in the User
module.
If two or more similarly restricted objects are included in the same query,
the conflict between the WHERE clauses will cause no data to be
returned.
Consider the situation if a user wanted data for UK Clients and US Clients.
You might think that including both the UK Clients and US Clients objects
would meet that need. However, the inferred SQL for the query would
include the following two lines:
AND (CLIENT _COUNTRYCOUNTRY _NAME = 'United Kingdo'm') AND
(CLlENT.COUNTRYCOUNTRY _NAME = 'USA')
Because no country would satisfy both these conditions, no data would be
returned.

/
/
An alternative to applying restrictions to objects
There is an alternative to applying restrictions to objects without using WHERE
clauses. You will still have multiple objects, but you will avoid the conflicts that
affect the return of data in queries.
This method involves using a conditional SELECT clause for the object instead
of a WHERE clause.
For example, if you want to force users to select financial results by year, you
could create a series of Sales Revenue objects (one for each year). Each
object would be edited, starting from the standard sum aggregate used in the
basic Sales Revenue Select statement:
You would apply the condition for each year using the Character function
IIF(restriction , action if true, action if false).
For Sales Revenue 2003, the Select statement would look like this:
Note: The Else value 0 is optional.

For Sales Revenue 2004, the Select statement would look like this:
sum(iif( year(SALE. SALE_DA TE)=2004, SALE_MODEL. SALE_ QTV *

fv'ODEU~ODELYRICE * «100-SALE.5ALE_SALE_DISCOUNT)/100),O»

When you have created or edited the objects, you should test them individually
and together in a single query. When you view the SQL to check whether the
inferred Select statement includes the conditional Selects, it should appear as ~
in the following example:
When the query is run, the report should look like this:
Carter, Sue
The conditional Select statements have removed the problem of the conflicting
WHERE clauses. The data correctly shows the 2003 and 2004 Sales Revenue
for each client.

Applying restrictions using condition
objects
Restrictions using condition objects

A condition object, or predefined condition, is a preset restriction created in
Designer that a user can choose whether or not to apply to a query.
When users create queries in Web Intelligence or Desktop Intelligence, they
can create their own conditions, or query filters, to limit the data returned by
the query. Or they can use the predefined condition objects that the universe
designer may have built into the universe to make it easier for them to restrict
the data.
In Web Intelligence, the predefined condition objects built into the universe are
identified in the Edit Query view Data tab with yellow filter icons.
For example, if the designer has created condition objects for French Clients
and UK Clients, the Data tab would contain these condition objects:
B~_
?
i· French Clients
L.? UK Clients
To create a condition object:

1 In Designer, select the Filter option button at the bottom of the Classes
and Objects window.
The Classes and Objects window changes to show the Condition Object
View.
Note: Objects are not shown in the Condition Object View, but classes
are. You add a condition object to a particular Class. Also, be
aware that deleting a class in the Condition Object View will delete
that class from the whole universe, not just from this view.
2 Click the class in which you want to place the condition object. In this
example, click the Client class.
3 Click Insert Condition on the Editing tool bar.
OR
Right-click the class and choose Insert Condition from the drop-down
menu. This opens the Edit Properties dialog box for condition objects.
4 In the Name field, enter a name for the condition object.
5 In the Description field, enter a help message for users describing the
condition and any effect it will have on queries they make.
6 Enter the condition directly in the WHERE field or by way of the WHERE
Clause Editor box.
In our example of a UK Clients condition object, the Edit Properties dialog
box would now look like this:

7 Click OK.
S Save and export the universe.
In our example, the Client class in Web Intelligence now looks like this:
2"'~ Client·
L.. m Client Countr}'
L.....m Region
Lm m Area
' m Town
±m. m Clienl Name
Lm. m Client Id
c @ Number of Clients
_L '" UKClients
When you have created the condition object, you should test it in Web
Intelligence by making a query that uses the condition object. View the SQL to
check that the inferred Select statement includes the restriction in the WHERE
clause and has the desired effect.

The advantages of using condition objects
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 user view of the dimension objects in
the Data tab in the Edit Query view of Web Intelligence
Applying restrictions to tables

If a table in your database has a flag that is used to switch between two or more
domains, you can use this to apply restrictions at the table level.
For example, the Sale table in the Motors2004 database has a column called
Sale_Type, which is used to distinguish between Sales transactions and
Rentals transactions. The flag is set to S for Sales or R for Rentals.
If you do not apply any restriction to this table, users running queries for Sales
(with appropriate objects) will get a resulting report that includes data on
Rentals as well as Sales. Therefore, the results will be wrong.
You can apply a restriction to this table using a self-restricting join.
The self-restricting join appears as a stub join in the Structure window:
LEJD
LIE~T_ID
~LE_DATE
~OW~OOI,jJD
LE3ALE_DISCOLJ~T
LE_TI'PE
SALEJOTAL
LE_~ EtnAL_PE~ kJD
The expression in the Edit Join box is set as follows:
With this restriction in place, the data returned will be restricted to Sales data,
no matter where the table is used in the inferred SQL.
For example, if the Sale table appears only in the FROM clause of the SQL,
the restriction will still be applied in the WHERE clause.
This is the main advantage of applying restrictions at the table level.

Applying restrictions using the tables button
A lookup table in a database can be used to provide a description for more than
one dimension of a database.
For example, in the Motors2004 database, the Country table contains a single
list of countries, but these include the country from which clients come, the
country where a car showroom is located, and the country where a car maker
is located.
As a designer, you can create objects from the Country table for use in the
Client class (for the Client Country), in the Car class (for the car Maker
Country), and in the Showroom class (for the Showroom Country). We have
done this in previous lessons and avoided loops by creating the appropriate
alias tables.
If a user ran a query to answer the question: "Which countries do our

showrooms exist in?", you might think that a simple query using only the
Showroom Country object in the Showroom class would provide the answer.
However, in the current universe, such a query would actually infer SQL that
returns all countries held in the SHOWROOM_COUNTRY table.
SELECT
SHOWROOM_COUNTRY. COUNTRY NAME
FROM
SHOWROOM COUNTRY
To solve this problem, the Showroom Country object in the Showroom class
must be restricted so that it returns only Country data relating to Showrooms.
This is done by specifying that whenever the Showroom Country object is used
in a query, the Showroom table must also be inferred in the FROM clause of
the SELECT statement. Providing that the SHOWROOM_COUNTRY table is
joined to the Showroom table (by intervening tables) using only equi-joins, the
object is then guaranteed to only ever return countries in which Showrooms
exist.

To restrict data by adding tables to the object definition:
1 Double-click the object you want to restrict, in this example, Showroom
Country.
The Edit Properties dialog box displays:
2 Click the Tables button.

The Tables dialog box appears.
3 Scroll down the list of tables until you can see the table that is already
highlighted.
MAKER_COUNTRY
MODEL
REGION
RENTAL
RENTAL_MODEL
RENTAL_PRICE_RANGE
SALE
SALE_MODEL
SALES _PRICE_RANGE
SHOV.ROOM
If you want to view only the tables already referenced by this object,
select the Show selected only option.
4 Hold down the Ctrl key and click the SHOWROOM table to force joins
between the selected tables.
This ensures that when the Country Showroom object is used in a query,
the SQL retrieves only the countries that have showrooms.

5 Click OK to close the Tables dialog box.
6 Click Apply in the Edit Properties dialog box.
7 Click OK.
Applying each type of restriction

Apply restrictions to objects when you need to force a restriction on users.
However, that restriction should not automatically be inferred whenever the
table is included in the SQL. Be aware of the drawbacks of multiple objects and
conflicting restrictions. Use conditional Selects instead.
Use Condition Objects when you want to assist users by providing optional
Predefined Conditions, and when it is important to avoid multiple objects and
changes to the Classes and Objects view.
Use Self-Restricting Joins to apply restrictions to tables when you want the
restriction to apply, irrespective of where the table is used in the SQL. This
method is ideal when a table uses a flag to switch between two or more
domains.
Use Additional Joins when a lookup table serves more than one purpose in the
universe. This methods ensures that the user gets the correct answer to the
question behind the query.

Practice
Activity: Applying restrictions
Objectives
In this activity you will apply enforced restrictions to objects and tables and
create optional restrictions using condition objects.
Instructions
1 The sales staff of Prestige Motors needs to drill from Day Rental Range
through Model Day Rental Charge to Model for Rental to deal with
queries from potential customers. To do this, you need to create the
Model for Rental dimension object in the Rental Figures subclass. This
object will have the same SELECT properties as the Model object but it
will contain a WHERE restriction so that only models available for rental
are returned. The restriction is:
'-./
" MODEL.MODEL_DAYRENT IS NOT NULL
'-./
'-./
'--"~
'-./'
'-..../
'----'
--../
'-..../
" 2 Create a US Clients dimension object in the Client class below the Client
Name object with the settings:
Type = Character
Description = Returns only data for clients in the USA
Select = CLlENT.CLlENT_LASTNAME +', '+
CLlENT.CLlENT _FIRSTNAME
WHERE = CLlEf)lT-"CPUNTRYCOUNTRY _NAME = 'USA'
3 Create another object in the Client class for UK clients.
4 Save and export the universe, then test the two new Client objects in
Web Intelligence:
Build a query containing UK Clients, US Clients, and Sales Revenue
/
objects.
The query should return no data because of the conflict of restrictions.
In Designer, create a new subclass below the Sales class called Annual
Revenue. Populate it with separate Sales Revenue measure objects for
the calendar years 2003 and 2004 as indicated below. Use the IIF
function to do this.
2003 Sales Revenue
2004 Sales Revenue
6 Save and export the universe, then test the two new Sales Revenue
objects in Web Intelligence:
Build a query containing Showroom, 2003 Sales Revenue, and 2004
7 Replace 2003 Sales Revenue and 2004 Sales Revenue object Select
properties IIF function with one related to financial years FY03-04 and
FY04-05, instead of calendar years.

8 Remove the US and UK objects in the Client class that you just created,
and create the following condition objects instead:
A condition object for European Clients (excluding UK)
A condition object for US Clients
A condition object for Other Clients
9 Save and export the universe and test each restriction by building a query
in Web Intelligence.
10 Run a query using Showroom Country to see the list of countries that
have showrooms.
11 In Designer, edit the properties of the Showroom country object by
adding the Showroom table to the list of tables associated with the object.
Use the Tables button in the Edit Properties, Definition tab of the object to
do this.
13 In Web Intelligence, re-run the above query and compare the results.
14 In Designer, ensure that the Client Country object will only return the
countries in which clients exist, whichever query is run. Do this by adding
the Client table to the list of tables associated with the object.
15 Edit the Maker Country object in the same way, to ensure that it only
returns the countries in which car makers exist.
16 Check the integrity of the universe.

Lesson Summary
Review
Quiz: Applying Restrictions on Objects

1 What is a restriction?
Answer:
A restriction is a condition in SQL that sets criteria to limit the data returned
by a query.
2 Explain two drawbacks of using restrictions at the object level.
Answer:
You would get a confusing proliferation of objects for end users
because you would then need a French Clients object, a German
Clients object, and so on.
As these objects would all represent alternative restrictions, you
would not be able to construct a logical default hierarchy (which end
users make use of when drilling down).
Although the UK Clients example is fairly clear, in many cases the
restriction will not be obvious to the user simply from the name of the
object. The details of the WHERE clause are not shown in the User
module.
If two or more similarly restricted objects are included in the same
query, the conflict between the WHERE clauses will cause no data to
be returned.
3 When should you use self-restricting joins?
Answer:
Use self-restricting joins to apply restrictions to tables when you want the
restriction to apply irrespective of where the table is used in the SQL.
This method is ideal when a table uses a flag to switch between two or
more domains.
Summary
lesson Define data restrictions
objectives
with the Apply data restrictions to objects
learners to Apply data restrictions using condition objects
check that all
Apply restrictions to tables
learners have
Apply data restrictions using the Tables button
acquired the
required Apply each type of restriction
skills before
moving on to
the next
section.

Lesson 10
Using Functions with Objects
This lesson will help you use the @Functions to provide more flexible methods for
specifying the SQL for an object.

Using @ Functions

Using @ Functions
Introduction
The @ Functions can be found in the Functions panel of the Edit Select
Statement and in the Edit WHERE Clause dialog boxes for objects.
Define @Functions
Use the @Prompt function
Use the @Select function
Use the @Where function
Defining @Functions
In the Edit Properties dialog box of an object, if you look in the Functions panel
of either the Edit Select Statement dialog box or the Edit WHERE Clause dialog
box, you will find the following functions:
@AggregateAware(,)
@Prompt(",,)
@Script(,,)
@SelectO
@VariableO
@WhereO
These functions can be applied in the Select and WHERE dialog boxes of
objects. They are used to provide flexible methods of specifying SOL.
The most commonly used @Functions are:
@Prompt(",,)
@SelectO
@WhereO
\ \

@Prompt
The @Prompt function is used by the designer to force the end user to enter a
value for a restriction when a query is run which includes the object in that the
@Prompt is specified.
'-" I
This is done by placing a restriction based on the @Prompt in the Where field of
the Edit Properties dialog box of an object. When the user runs a query including
that object, a prompt dialog box appears requesting a value to be entered.
It can be useful when you want to force a restriction in the inferred SQL but do
______
I not want to preset the value of the condition. For example:
TT
/
~.
I
~
--../
i
In the example above, the object Model for Rental is to be used by a salesman
to list the models that can be rented. However, different models are rented from
different showrooms. Hence, you would want to restrict the returned list to cars
rented from a single showroom. If you hard coded the restriction, you would need
a separate object for each showroom in the universe. Using the @Prompt, you
need only one.
@Prompt syntax
The @Prompt syntax consists of five parameters, separa~ed by commas:
Prompt
Data Type (A, N, or D)
LOV Pointer or hard-coded list
Mono or Multi
Free or Constrained
J
J
Using Functions with Objects-Instructor's Guide 10-3
The first two parameters are required. It is a best practice to provide values for
the first two parameters and the last three, as necessary. However, if you leave
out a parameter, you must still include the required commas. For example:
SHOWROOM. SHOWROOM Name = @PROMPT('Enter Showroom Name' ,'A',
'Showroom\Showroom', Mono, Constrained)
The first three parameters must be inside single quotes.

Prompt
This is the text, or question, that will appear in the prompt dialog box when the
query is run. The text must be enclosed in single quotes.
Data Type
A character to specify the type of data that will be returned:
'N for Alphanumeric
'N' for Numeric
'0' for Date
The specified character must be enclosed in single quotes.

List of Values (optional)
There are two methods of specifying a LOV:
A hard-coded list: each value is separately enclosed in single quotes and
separated by a comma; the whole list is enclosed in curly brackets. For
example:
{'Australia', 'France', 'Japan', 'United Kingdom', 'USA'}
A pointer to a list of values from an existing object: This can be invoked
by double-clicking the object whose LOV you want to use in the Classes
and Objects pick list. This gives the Class name and the Object name,
separated by a back-slash. It must be enclosed in single quotes. For
example:
'Client\Country'
Mono or Multi (optional)

Mono: lets the user select or enter only a single value from the LOV.
Multi: lets the user select or enter multiple values from the LOV.
Free or Constrained (optional)
Free: Users can enter a value of their own, or pick one from the list of
values.
Constrained: Users can only choose a value from the list of values.

@Select
Use @Select by placing it in the Select field of the Edit Properties dialog box of
an object, using the following syntax:
@SelectCpath of existing object)
The @Select function allows you to reuse existing code. The advantage of
using this function is that it allows you to specify SOL code only once. This has
two key advantages:
You need to maintain only one instance of the SOL code.
It ensures consistency of the code.
You specify the path in the form Class_Name\Object_Name. In the Edit

Properties dialog box you can see the SOL definition of the original object. For
example:
In the example above, you can see that the code in the Select properties of the
Model object is:
MODEL. MODEL_NAME & ' ,& MODEL. MODEL_TRIM & ' ,&
MODEL. MODEL_ENGINE
The @Select function is a pointer to the Select dialog box properties of another
object.

A dynamic link is created between objects so when changes occur in the
SELECT statement of the original object, the changes are reflected in the
SELECT statement of the other objects.
This same code is used in the object called Model for Rental. Therefore, if you
should need to change the code, you would have to change it twice.
You can avoid this by changing the Select properties code in the Model for Rental
object to:
@Select(Car\Model)

@Where
The @Where function is a pointer to the Where dialog box properties of another
object.
It is used by placing the @Where in the Where field of the Edit Properties dialog
box of an object, using the following syntax:
@Where(path of existing object)
You specify the path in the form Class_Name\Object_Name. For example:
'--/ I
The @Where function acts as a pointer to the Where dialog box of another
object.
It is also a dynamic link between objects, so that updating the original object
WHERE clause automatically updates the other objects or condition objects.
'--/ I

In this example you can see that the code in the Where properties of the Model
for Rental object is:
MODEL. MODEL_DAY RENT IS NOT NULL AND SHOWROOM. SHOWROOM NAME
@Prompt('Enter Showroom
Name' ,'A', 'Showroom\Showroom' ,mono,constrained)
This same code is used in the condition object called Showroom Rental Models.
Therefore, if you should need to change the code, you would have to change it
twice.
You can avoid this by changing the Where properties code in the Showroom
Rental Models condition object to:
@Where(Day Rental Charges\Model)
Note: You can use the @Where function in a condition object to point to an
object, but not the other waya round.
As with @Select, its purpose is to allow you to reuse existing code, and it has the
same advantages:
You need to maintain only one instance of the SQL code.
It ensures consistency of the code.
9-~;!+r~Fr-.'",~i'~ l?·Sjt~
~·..-8 1?~.>''.JfN~~ ~¥·S·M.:i~
: ,t::-~~t::ri1ri!!S:ofV~hd~
?:Qij D;OYR;rl.<l: O1;r9":':
f,-g -Mcdd~JfAtJnK:l
H'~ I~..~'i'.qffli~"'.:<}' 8·~r.-M

fI h'f,J)' ••:~fM/."trfI:o; . 7-St"OYlwc,.nR~)~dIMooet
fj, S·~~7:.••• m'hOi."~
If there are a number of objects and/or condition objects that require the same
restrictions to be placed upon them, you could use a "dummy" object strategy to
make the most efficient use of that restriction's code.
The idea behind the strategy is that you create a new and separate object for
every restriction required, in a separate class to the "normal" object classes.
Then, within the "normal" objects, whenever a restriction is required, you merely
point to the appropriate "dummy" object using the @Where function.
In the example above, you can see that two "dummy" objects have been created
that contain only a name and Where restriction, as follows:
Rental model
MODEL. MODEL_DAY RENT IS NOT NULL
Showroom choice
SHOWROOM. SHOWROOM_NAME = @Prompt
('Enter Showroom Name', 'P;, 'Showroom\Showroom' ,mono,constrained)

/
Note that each of the dummy objects do not have Select properties specified.
The @Where pointer can now be used to specify the restrictions required for the
object called Model for Rental without the need to double up on WHERE clause
code.
Also, by specifying each restriction in a separate dummy object, the strategy has
enabled you to build up the multiple restrictions on the object one step at a time.
This is particularly useful when creating complex restrictions on an object.
Moreover, the individual restrictions can be used for other objects and condition
objects. In the example above, the dummy object called Showroom Choice has
also been used for the Showroom condition object.
For this strategy to work, you need to be able to hide the class containing all the
dummy objects from end users.
The procedure for this is as follows:
1 Click the class or object you want to hide.
2 Select Hide Item(s) on the Edit menu.
Or right-click the object or class and select Hide Item(s) from the drop-
down menu.
Hidden classes and objects appear in italics in the Designer Universe pane.
They are not shown at all in Web Intelligence or Desktop Intelligence.
The "dummy" object strategy has a number of advantages:
Maintenance is easy because only a single instance of each restriction is
required.
The restrictions are easy to find. They are all under a single class.
Restrictions can be mixed and matched without the need for repetition.

'-" I
Practice
Activity: Using @Functions
Objectives
Apply @Functions to objects and condition objects
Instructions
1 In the previous lesson, you created a Model for Rental dimension object in
the Day Rental Charges subclass. This object returns all models available
for rental. This is to be used by sales staff and should be further restricted
to a specific showroom. Use the @Prompt function to achieve this. The
parameters for the @Prompt should be:
Prompt = 'Enter showroom name'
Data type = '{!\
LOV = 'Showroom\Showroom'
Mono
Constrained
2 The select properties of the Model and Model for Rental objects are the
same. Use the @Select in the Model for Rental object to point to the select
properties of the Model object. .
3 Create a new condition object called Showroom Rental Model in the
Showroom class. The WHERE restrictions for this condition already exist in
the Model for Rental object. Use the @Where function in the condition
object to point to the where properties of the Model for Rental object.
4 Create two dummy objects in a new class called Dummy Restriction
Objects as follows:
Rental Model containing the restriction:
MODEL. MODEL DAY RENT IS NOT NUll
Showroom Choice containing the restriction:

SHOWROOM. SHOWROOM_NAME = @Prompt
('Enter showroom name', 'A', 'Showroom\Showroom', mono,

constrained)
5 Hide the Dummy Restriction Objects class.
1 0-1 0 Universe Design-Instructor's Guide

6 Edit the following object and condition object so that the WHERE clause of
each contains no SQL code but uses @Where functions to point to the
dummy objects.
Model for Rental object inherits the Rental Model object's WHERE
clause
Showroom Rental Model condition object inherits the Showroom
Choice object's WHERE clause
7 The select properties of the Rental Date and Return Date objects contain
RENTAL.SALE_DATE. Use the @Select in the Return Date object to point
to the select properties of the Rental Date object to avoid duplication of
SQL code.
8 Create a Maker Choice condition object under the Car class that, when
used in a query, produces a prompt dialog box requesting the user to enter
a single manufacturer.
9 Check the integrity of the universe.
The integrity check alerts on things it doesn't understand as a quick check,
in this case the two hidden objects.
10 Save and export the universe ..
Note: Remember to test your solution in Web Intelligence.

Lesson Summary
Review
Quiz: Using Functions with Objects

1 What parameter does the @Select require?
Answer:
The path of the existing object to be dynamically linked to.
2 True or False? You can use the @Where function in a condition object to
point to an object, but not the other way round.
Answer:
True
3 The function is used to create an interactive object that
causes a message to appear at query runtime, which asks the user for
specific input.
a)@Where
b)@Prompt
c)@Script
d)@Variable
Answer:
b)@ Prompt
4 In the @Prompt two parameters are mandatory and three are optional.
What parameters are optional?
Answer:
LOV Pointer or hard-coded list
Mono or Multi
Free or Constrained
All arguments must exist.
Summary
lesson
Define @Functions
objectives
with the Use the @Select function
learners to Use the @Where function
check that all
learners have
acquired the
required
skills before
moving on to
the next
section.

Lesson 11
Using Hierarchies
Hierarchies allow you to organize dimension objects so that users can perform
multi-dimensional analysis using drill mode in Web Intelligence or Desktop
Intelligence documents.
Understanding hierarchies and universes
Working with hierarchies

Understanding hierarchies and universes
Introduction
Hierarchies in universes allow users to create reports that are enabled for
multi-dimensional analysis with drill mode.
Explain how hierarchies allow users to drill down to different levels of
detail using drill mode in Web Intelligence and Desktop Intelligence
Hierarchies
A hierarchy is an ordered series of related dimension objects that are used for
multidimensional analysis. For example, a geographical hierarchy could group
together dimension objects such as Country, Region and City,
Multidimensional analysis is a technique for manipulating data so that it can be
viewed from different perspectives and at different levels of detail. In Web
Intelligence and Desktop Intelligence, users can analyze data at different
levels of detail using a feature known as drill mode.
The example below shows a hierarchy of the dimension objects Country,
Region and City.
At the highest level, the user will see a Country. At the next level down, the
Country is broken down into more detail: the regions. At the next lower level,
the regions are broken down into more detail: the cities. A user can then
analyze a Measure object, such as Sales Revenue, against any of the levels
in the hierarchy.
/.K.
A l\I:mchestt'l' N t'Wcastlt'
South
LOlUlon Southampton BIistol

Natural hierarchies
A natural hierarchy is one that follows a naturally occurring pattern from the
most general at the highest level to the most detailed at the lowest level.
Examples of natural hierarchies can be found in the geographical definitions of
places and in the measurement of time:
Country, Region, State, City, District, Street
Year, Quarter, Month, Week, Day
Logical hierarchies
Web Intelligence hierarchies are not restricted to natural hierarchies. You can
construct a hierarchy from any related group of dimension objects that will
create a sensible analysis path.
The relationship between the dimension objects in a hierarchy normally will be
one-to-many as you descend through the levels.
For example, one Country has many Towns; one Town has many Showrooms;
one Showroom has many Franchises:
9~ Showroom
'..···1IiII Country
f····1IiII Town
f:1:1"1IiIIShowroom
ffi"1IiII Franchises .
'-./ I
Using Hierarchies-Instructor's Guide 11-3

Working with hierarchies
Introduction
View default hierarchies in a universe
Set the scope of analysis in a Web Intelligence document using a default
hierarchy
Create a custom hierarchy
Create time hierarchies
Default hierarchies
A default hierarchy contains all the dimension objects in a class in the order
they are presented in that class. It is based on the order of the objects within
the class.
As the name suggests, a default hierarchy is automatically inferred by Web

Intelligence whenever you have at least one dimension object in a class.
It is therefore important to organize dimension objects hierarchically in a class.
In this example, you can see that the dimension objects in each class follow
an order from the most general to the most specific.
-;J Area
,TI dient Town
:TI . dient Name
':" .•• Client Address;
t ..•. Client ID
. 1) Area Code
..•.• ' Phone Number
Ji Numberof Clients
;~HanCar
~:";&lShowroom
~..n showroom Country
'··n Showroom Town
9 :TI, Showroom
"ft- Showroom Address
c.. 'TI Franchises
tfJ-·fOOi Sales
ff·@ilRentals
f~:'<f£l Financial Period
. -TI Financial Year
i ...-m ' Financial Quarter
'- . ','1 Financial Month
$..@1ilDummrRest!ktionObjects
Using this method of organizing your dimension objects in their classes is the
key to setting up usable default hierarchies.

Viewing default hierarchies
To view the Default Hierarchies
1 Click the Hierarchies tool bar button.
OR
Select Tools> Hierarchies from the menu bar.
This opens the Hierarchies Editor dialog box:
You cannot add or remove objects from classes in the Hierarchies Editor.
You can use the Hierarchies Editor to create Custom Hierarchies.
2 Click + next to any class if you want to see the dimension objects
organized in these hierarchies.
3 Click Cancel to close the Hierarchies Editor dialog box.
Testing default hierarchies

As with other components of a universe, hierarchies can be tested in Web
Intelligence, to check that they function as expected.
To test a default hierarchy

1 In Web Intelligence, create a new document using the universe from the
previous lesson.
2 In Edit Query view, select an object that is the highest level of one of the
hierarchies that you looked at previously.
For example, double-click Financial Year to move it into the Result
Objects pane.
3 Select a suitable measure object, such as Sales Revenue, and double-
click it to add it to the Result Objects pane.
4 Click the Show/Hide Scope of Analysis Pane button on the Edit Query
view toolbar.
The Scope of Analysis pane appears below the Query Filters pane.
Using Hierarchies-instructor's Guide 11-5

Note: Drag the upper border of the Scope of Analysis pane up too see more
of this zone if you need to.
The Scope of Analysis pane is the zone where you set up the query for
drill analysis. All the dimensions that you have selected for the query
appear here, in this case, Financial Year. This object is the object that is
positioned at the highest level of the Financial Period default hierarchy. In
order to allow users to drill down the hierarchy from one level of the
Financial Period to another, without having to modify the query, you can
set the scope of analysis before the query is actually executed.
The levels you define in the scope of analysis will determine how many
objects from the Financial Period hierarchy will be included in the query,
and therefore how many levels of detailed data will be returned to the
Web Intelligence document.
5 Click the Scope of Analysis drop-down arrow to select the scope of
analysis levels.
't~H~ Client
~ ·@iJ·Shov,l!oom
$-.€il Financial Period
~''''3 FrnatiCialYear
~····m ' Financial Quarter
i. <'1, financial Month
-G.},.~ Rentals
S-€ilSal ••
!tH~ S.a!esDetails
H-}"~ Sales Dates
g..-§] Sales Figures
'._n. Q Aver-age levenu
:•••• -• .@:
;""""" <.)
-
'_n __~
---
Number of Cars
Cost of Car
6 Click Two levels in the drop-down list.

The following two dimensions in the Financial Period default hierarchy
appear in the Scope of Analysis pane. This means that they will be
included in the query, and the sales revenue relevant to these two objects
will be calculated and stored in the document's microcube.
The two dimensions will not immediately appear in the report that is
displayed, but as soon as a user decides to switch to drill mode, the data
will be available for drill analysis.
7 Click Run query to execute the query.
8 In the Edit Report view, click Drill to display the report in drill mode.
9 Click the F903-041ink to drill down from fiscal year to fiscal quarter.
The data in the Sales Revenue column is aggregated to reflect quarterly
sales figures:

10 Drill down and up as you wish to explore the data available in the
document's microcube.
11 Close the document without saving, and return to Designer.

Creating custom hierarchies
A custom hierarchy combines objects from default hierarchies to build a
custom analysis path.
C"ern
Iii Cl)tU"jtfY
Iii Region
Custom Hierarchy
iii .6sea
15'-
ryhm Client I FY
iii T 0'1111'1 , !" tI Cauntly
Ii Client N,aJI'Ie I'''' 111 Region
Default Hierarchies !. 111 Area
.. tI
1'" Town
$)~ Firnmcial Period
1'"111 C1ient N6fOe
L i9 Financial Year
• ) i L,~111 Financial Year
i~M tit Financial Quarter
"~iii Finllncial Month
As you have seen, default hierarchies are based on the order of the objects in
their classes. These default hierarchies may not provide the drill paths that
users need to analyze their data. They may need to follow drill paths that
contain dimension objects from more than one class.
For example, if users of the Motors2004 universe wanted to look at Sales
Revenue from the point of view of ClienUArea and Financial Period, they would
not be able to do this using the default hierarchies. In such cases, there are
two options:
Desktop Intelligence users can create their own one-off custom hierarchy
in Desktop Intelligence (this functionality is not available in Web
Intelligence ).
As universe designer, you can build a permanent custom hierarchy as
part of the universe.
The advantage of creating a custom hierarchy as part of the universe is that it
can be used across documents by any user. If a Desktop Intelligence user
creates a one-off custom hierarchy, it is available only in that document, and
Web Intelligence users cannot create one at all.
In the analysis phase of the universe development process, the designer
should identify those custom hierarchies that are to be used regularly. These
should be created in Designer as permanent custom hierarchies.

'--/ I
Creating a custom hierarchy

To create a custom hierarchy
1 Click the Hierarchies tool bar button.
OR
This opens the Hierarchies Editor dialog box:
'--/ )
2 Click New.
A new folder appears in the Custom Hierarchies panel.
3 Type a name for the custom hierarchy as the folder name, for example,
Custom, and press Enter.
4 In the left panel of the Hierarchies Editor dialog box, click the + of the
default hierarchies that contain the dimension objects you want to include
in the custom hierarchy.
The default hierarchy dimension objects appear.
S Click the object (or multiple objects, using Ctrl-Click) that you want to
appear in the custom hierarchy, and then click Add.
OR
Drag and drop the required objects onto the new Custom hierarchy
folder.
In this example, select all the objects in the Client default hierarchy, plus
Financial Year object. The selected objects appear in the Custom
hierarchy.
Note: The dimension objects may not be in the order you require. You
can move the objects up and down the list by clicking them and
then clicking the Move Up or Move Down buttons. Alternatively,
you can use the drag-and-drop technique.

When you have populated the new Custom hierarchy folder with objects
and ordered them correctly, it should appear as in the example below:
6 Click OK to save the changes to the Hierarchies and close the

Hierarchies Editor dialog box.
The effect of custom hierarchies on default

hierarchies
In the Web Intelligence Java Report Panel, if you click the Hierarchies option
in the Data tab before you create any custom hierarchies, you will see that the
list of hierarchies is the same in both the All Objects pane and the Hierarchies
pane: both show the objects organized in the same order, either in classes, or
in groups of hierarchies (see left-hand image below).
However, if you create a custom hierarchy in the universe using Designer, after
you have saved and exported the universe and then open the Java Report
Panel again in Web Intelligence, the Hierarchies pane in the Data tab now lists
only the custom hierarchies (see right-hand image below).
The All Objects pane still lists the dimension and measure objects in classes,
as before, regardless of the display in the Hierarchies pane.

+~
,;. rt ,,~;;;~t'f
::;i@;f~
<q R@;*~
G A!'f2:ij
>·:31~fi
:..m C:i~t:::Mft3ffilf
-, m:!ZiM~~;:~1 Y~)t
At first, this appears to be a problem. However, the effect of creating a custom

hierarchy is actually very useful because it provides a mechanism for
selectively producing hierarchies for end users.
Because a default hierarchy is always created for any class where a dimension
object exists, it may be that there are some default hierarchies that you do not
want users to use as drill paths. This mechanism can be used to exclude such
default hierarchies.
Once you decide to create custom hierarchies, you must copy any of the
defaults that you want to keep over to the right-hand side list box. Even if you
do not want to create new ones, to exclude the default hierarchies that you do
not want users to use as drill paths, you must copy the useful ones over.
In order to make any change at all in the hierarchies, you either start over by
creating new custom hierarchies or you copy only the useful default
hierarchies into the Custom Hierarchies list box.

Editing types of hierarchies
This topic discusses how to add selected default hierarchies to the list of
custom hierarchies in Designer.
To selectively make default hierarchies available to users

1 In Designer, click the Hierarchies tool bar button.
OR
This opens the Hierarchies Editor dialog box.
2 Drag and drop only the default hierarchy folders you want the users to
use as drill paths from the left panel of the Hierarchies Editor dialog box
to the right panel.
Note: When more than one hierarchy starts with the same dimension
object path but diverges at a lower level of the hierarchy, the
default path in Web Intelligence will be the one that is higher in the
list (if dimensions from both hierarchies are included in the query).
You can alter this defal!lt priority by changing the order of the
hierarchies in the Custom Hierarchies panel. You can do this using
the Move Up and Move Down buttons, or using the drag-and-drop
technique.
Note: When you add default hierarchies to the Custom Hierarchies list, it
is good practice to position the true custom hierarchy, if any, at the
bottom of the list.
3 Click OK to save the changes to the hierarchies and close the
Hierarchies Editor dialog box.

Time hierarchies
One of the most common requirements for data analysis is to provide facilities
for analysis against different time periods.
Time is a special case because all the information for the dimension objects
that make up the hierarchy can come from a single column in a database. In
most other cases, each dimension object infers a separate database column.
This is achieved by using SQL date scalar functions to extract the day, month,
year, and possibly quarter from a single database column of a date type.
Creating time hierarchies

There are three methods of creating a time hierarchy. Each method has
advantages and disadvantages for both the designer and the user. The
three methods are:
Automatic time hierarchies
Using database functions
Table based time hierarchies
Automatic time hierarchies

Using this method, Designer automatically creates the dimension object
definitions needed for a time hierarchy from a single Date Seed object.
To create an automatic time hierarchy

1 In the Sales class and Sales Dates subclass, double-click the Sale Date
object to open the Edit Properties dialog box.
Note that the Type field is set to Date.
2 Click the Properties tab. Because the field type is Date, the Automatic
Time Hierarchy button is shown in the Qualification panel.

3 Click the Automatic Time Hierarchy button to open the Automatic Time
Hierarchy dialog box.
4 Select the check boxes for the time-related dimension objects you want
to create and edit the names of the dimension objects, if required.
5 Click OK to close the Automatic Time Hierarchy dialog box.
6 If necessary, alter other object properties as required.
7 Click OK to close the Edit Properties dialog box.
The Classes and Objects window now looks like this:
Sales Dates
3 Sale Date
Notice that the original date object now has a plus next to it, indicating
that other objects are attached to it. These are the automatically created
time dimension objects.
8 Click the + to view and check the objects attached to the date object.

9
...J
'-"
-..J
...J
....J
...J
-..J
...J
'-.-/
'...../
Sales Dates·
8-ml ~ale Datel

><m Year of Sale Date·
'.-;a Quarter of Sale Date·
...g Month of Sale Date
Note: You can see that the arrangement of the objects is not as you
might expect. The Sale Date is at the top of the hierarchy, and the
other time objects appear to be subsidiary objects to it. From this, it
is apparent that there are two further disadvantages to this method
of creating time dimension objects. First, when a user sees a +
against an object, they will think that detail objects are attached to
it. Second, the objects are not ordered hierarchically in the class,
and, as a consequence, this might lead to confusion as to which is
the highest level object in the class.
Double-click one of the automatically created time dimension objects
(year, quarter, or month) to view the Edit Properties dialog box for the
object.
Note: The object properties cannot be edited. This is another

disadvantage. However, you can also see one of the key
advantages of using this method to create time dimension objects:
the SQL inferred includes the scalar function used to extract the
correct element of the date.
11 Click the Hierarchies tool bar button to open the Hierarchies Editor dialog
box.
Notice that in the Default Hierarchies list, there are two new default
hierarchy classes, an empty one bearing the name of the original class, in
this example Sales Dates, and another bearing the name of the class
appended with the name of the original date object (in this example,
Sales Dates/Sale Date).
12 Click the + next to Sales Dates/Sale Date, the class/object-named
default hierarchy.

You can see that the time hierarchy objects are correctly ordered despite
the order of the dimension objects in the class.
13 Close the Hierarchies Editor dialog box.
Testing automatic time hierarchies

Automatic time hierarchies are tested in the same way as any other hierarchy.
However, there is one thing to note about such a test.
When you drill down to the bottom of the time hierarchy, the Quarters and the
Months are identified simply as numbers, 1 to 4 for the Quarters and 1 to 12
for the Months.
1,184,563.50
Quarter 979,683.00
681,144.00
835,289.00 Sales Value (Re\
3,680,679.50
Sum:43 2 1 SalesValue
231,674.00
333,911.00
269,704.00
835,289.00 (Re\
Month
Sum:
11
12 10
This may can be confusing or unsatisfactory to end users. A better idea is to

precede the numbers with a character string such as Quarter or Month.
However, as you have already seen, it is impossible to edit a time dimension
object that is created using the automated method.
Advantages and disadvantages of automatic time

hierarchies
Advantages
It is a fairly quick and easy way to set up a Time Hierarchy.
Automatically creates SQL SELECT clause using the appropriate scalar
functions for the RDBMS of the target database.
Disadvantages
Does not give the designer any control over the layout of the dimension
objects in the Classes and Objects window.
Does not give the designer any control over the format of the data in the
query report.
The layout of the dimension objects in the universe can be confusing to
users, who normally expect to see detail objects under dimension
objects.
The format of the report can be confusing to users.
A LOV can only be applied to the Date Seed object, not to individual time
dimension objects.
All the negative points listed above can be avoided if another method of
creating time dimension objects is used.

Time hierarchies based on database functions
You can use the scalar date functions to create time dimension objects
manually. However, you should note that the set of scalar functions used to
extract elements of a database varies with the RDBMS.
To create a time hierarchy using database functions

1 Create a new class or subclass with an appropriate name.
The remainder of this procedure should be repeated to create each time
object required within the class that is based on the date scalar functions.
2 Drag the database column from the Structure table that contains the date
required and drop it on the newly created class.
3 Double-click the object to open the Edit Properties dialog box.
4 Edit the properties of the object so that it will infer an element of the date
as required.
For example, to infer a calendar year, you should:
Change the name to Calendar Year
Change the Type to Character
Change the Select statement to:
'Calendar Year' + format(RENTAL.SALE_DATE,'YYYY')
Clear the Associate list of values, if not required. The

properties of the object would then look as follows:

6 Repeat steps 2 to 5 for each of the other time objects required within the
class based on scalar functions.
Tip: Because you are creating a very similar time object to the previous
one, it can be more efficient to edit a copy of the previous object, rather
than creating a new one as suggested in step 2.
Using Hierarchies-':Instructor's Guide 11-17

7 Create a date object (for example, Rental Date) by repeating step 2, and
then editing the properties to clear the Associate list of values.
The Classes and Objects panel should contain a class or subclass as in the
following example:
Calendar Date
;m Calendar Year
Calendar Quarter
;m Calendar Month
A default time hierarchy will now be inferred from the class.
Testing database function time hierarchies

A time hierarchy created using this method is tested in the same way as any
other hierarchy.
Advantages and disadvantages of database function time

hierarchies
Advantages
The layout of the dimension object within the class is as a user would
expect.
Each of the objects can be edited individually.
A separate LOV can be associated with each time dimension object as
required.
The name of the hierarchy and the order of the objects mirror the class
exactly.
Disadvantages
It takes longer to create the objects of the time hierarchy than when using
the Automatic Time Hierarchy method.
The person designing the universe needs to know the relevant scalar
functions and how to use them.
Tip: If you do not know the relevant scalar functions, you could initially create
the time objects within a class using the Automatic Time Hierarchy method.
Then you could note the scalar functions automatically inferred, remove the
automatically created objects, and recreate them using the Database
Function method.

Table-based time hierarchies
The Automatic Time Hierarchy and Database Functions methods of creating a
time hierarchy are appropriate when you want to create calendar-based time
dimension objects. However, they are inappropriate when you want to create
time dimension objects based on different time periods.
2(lJO{l3-(6 co OCt00 200(f04·05 00: 00:00 f1"95-00

2(lJO{l2·(6 COOCtOO 200(fO:J-05 00: 00:00 FY95-00
21))0.01 {o co oCt 00 2001}02-05 00: 00:00 f,(35-00
1399·12·[6 mOQOO 2000-01-05 00:00:00 f1'9S-00
1399·11·(6 COOQOO !985-12-05 00: 00:00 f1'9S-00
1399·10·(6 mOQOO !985-11-05 00: 00:00 f1'9S-00
1939.Q3·ffi In act 00 !999-10-05 00: 00:00 f1'99-00
1939.(J3·ffi In an 00 1 999-09-05 00: 00:00 f1'99-00
1939'(]7·ffi wonoo 1 999-08·115 011:00:00 f1'99-00
1939.(E·[E w on 00 1 999-07-05 00: 00:130 f1'99-110
1939.(]5·[E W on 00 1 999-06·115 00: 00:00 f1'99-110
1939.(}1·l"E wonoo 1 999-05-115 00: 00:00 f1'99-110
1939'(]3·[E won 00 1 999-04·115 00: 00:00 f1'98-99
1939.(]2·[E wonoo 1 999-03-05 00: 00:00 f1'98-99
1939'(]] .[E won 00 1999-02·0500:00:00 f1'98-99
'1933·12·[E wonoo 1999-01-05 011:00:00 f1'98-99
Another way of creating time dimension objects is to add a time range table to
the database with columns and data as in the example below. This table can
then be added to the structure and its columns used to create time dimension
objects. This is a good way of coping with financial periods that do not coincide
with the calendar year.
Note: You may recognize the table. You inserted it into the Motors2004
universe Structure during the Joins lesson of the course, when you
explored theta joins. You then used the table to create time objects
during the Classes and Objects lesson.
To create a Table-Based Time Hierarchy

1 Add the time period table to the universe structure.
2 Insert a theta join between the start and end range columns of the time
period table and an appropriate date column of another table.
An example of this is shown below:
rp ...;"STA'RT
rp E~D
rp :YEA'R
rp _QUAi=!TI:J~
rp _lJotni-l
LEJD
LIEtn JD
/ o.LI:: DATE
i-Io.";j 1=!OOY 10
ALE &(J,LE O"'&::OLl ~T
SALI::)VPE-
''''ALE TOTAL
,O,LI::: 'R E~TAl_PEJtIOD
3 Create a new class with an appropriate name, for example, Financial

Period.

/'
4 Create the time objects required. In each instance, you will not need to
use scalar functions. The SELECT statement of each object needs only
to infer a database column name. Hence, it would be more efficient to use
the automated method of creating objects (drag and drop).
When the objects have been created, the class should appear as in the
example below:
$~ Financial Period
r .... fiI Financial Year
..iii Quarter
fiI Financial Month
;,....1iI Sale Date
A default time hierarchy will now be inferred from the class.

Testing table-based time hierarchies

A time hierarchy created using this method is tested in the same way as any
other hierarchy.
Advantages and disadvantages of table-based time

hierarchies
Advantages
It is a good method of creating time dimension objects for time periods
other than calendar periods. '
The layout of the dimensions within the class is as a user would expect.
Each of the objects can be edited individually.
A separate LOV can be associated with each time dimension object, as
required.
The name of the hierarchy and the order of objects mirror the class
exactly.
Disadvantages
The additional join reduces the efficiency of an inferred SOL statement.
/
11-20 Universe Design-Instructor's Guide ./
/
J,
Practice
Activity: Using hierarchies
Objectives
In this activity, you will infer default hierarchies and create custom hierarchies
for the Motors2004 universe.
Instructions
1 Switch back to default hierarchies if you have followed along during this
lesson.
2 Check that the hierarchical order of the dimension objects in the Client
class is based on geography.
The geographic hierarchy is: Country -> Region -> Area -> Town
3 Save and export the universe, and then test the default hierarchy in Web
Intelligence.
4 Create a Sale Year, Sale Quarter, and Sale Month dimension object using
the Automatic Time Hierarchy method.
5 Save and export the universe again, and then test the resulting hierarchy
in Web Intelligence. When you run the query, view the SQL and note the
scalar function used.
6 Create a Rental Year, Rental Quarter, and Rental Month dimension object
manually in the Rental Dates subclass. Ensure that the quarter and
month dimension object values are preceded by a character string such
as Q and Month respectively.
7 Check that the order of the dimension objects in the Financial Period
class is based on time.
S Save and export the universe again, and then test the resulting
hierarchies in Web Intelligence.
Prestige Motors wants to analyze clients geographically (by Country, Region,
and Town) but then further analyze the breakdown of client expenditure by
financial year.
1 Create a custom hierarchy to allow users to do this by including the
./ Country, Region, Town and Financial Year objects in the hierarchy .
I
2 Make the following default hierarchies available to the user. ..,
Car I
Day Rental Charges

Showroom
Financial Period
Rental Dates
Sale Dates
I
in Web Intelligence. I
1
r'j .•..
1

4 Sales people want to drill down to a model using a specific drill path. In
the bottom of your custom hierarchy list, create a hierarchy to allow this
drill path using the following objects:
Showroom Country
Showroom Name
Maker
Model
in Web Intelligence.
/'

Lesson summary
Review
Quiz: Using Hierarchies

1 A hierarchy is the hierarchy based on the order of the
objects within the class.
a) Default
c) Custom
Answer:
a
2 What are two advantages of Automatic Time Hierarchies?
Answer:
1 It is a fairly quick and easy way to set up a Time Hierarchy.

Automatically creates SQL Select clause using the appropria
Summary
lesson
Explain how hierarchies allow users to drill down to different levels of
objectives detail using drill mode in Web Intelligence and Desktop Intelligence
with the
learners to View default hierarchies in a universe
check that all Set the scope of analysis in a Web Intelligence document using a default
learners have hierarchy
acquired the Create a custom hierarchy
required
skills before Create time hierarchies
moving on to
the next
section.

Lesson 12
Aggregate Awareness
This lesson describes how you can use features in Designer to define an object's
SELECT statement so that you can run a query against aggregate tables in the
database instead of against the base tables.
You can set conditions so that a query will run against aggregate tables if doing
so optimizes the query. If this is not the case, then the query will run against the
base tables.
This ability of an object to use aggregate tables to optimize a query is called

'--/ I aggregate awareness.
Understanding aggregate awareness and universes
Applying aggregate awareness to objects
Duration: 1 .5 hours
'-" I

Understanding
. aggregate awareness and
universes
Introduction
Aggregate awareness is a term that describes the ability of a universe to make
use of aggregate tables in a database. Using aggregate tables speeds up the
execution of queries, improving the performance of SQL transactions.
Understand what is meant by the term aggregate aware
Understand why universes that are aggregate aware allow queries to
process more efficiently
What is Aggregate Awareness?

Some databases contain Summary Tables (STs). These tables are created by
the Database Administrator (DBA) and contain figures such as revenue
aggregated to a high level (year, for example) rather than to the facUevent
level. The summary tables are usually populated and updated regularly by an
automated program that runs SQL against the fact or event data at transaction
level.
This means that there are two methods that you can use to return aggregated
data:
Run a SELECT statement for the fact or event data
OR
Run a SELECT statement for the summary data
Where possible, it is best to choose the latter method as the statement will
process quicker.
In Designer, you can use a function called @AggregateAware in the SELECT
statement for an object, so that both methods are referenced. This function
directs a query to be run against aggregate tables whenever possible. If the
data in the aggregate table is not calculated at the level of granularity required
to run the query, the object will direct the query to run against the tables
containing the non-aggregated data.
A universe that has one or more objects with alternative definitions based on
aggregate tables is said to be aggregate aware. These definitions correspond
to levels of aggregation. For example, an object called Profit can be
aggregated by month, by quarter, or by year.
The reliability and usefulness of aggregate awareness in a universe depends
on the accuracy of the aggregate tables. They must be refreshed at the same
time as all fact tables.

Summary Tables
Each row in a summary table is made up of columns containing:
Aggregated data: Numeric event data aggregated to a higher level.
In the example below, columns containing aggregated data are
Annual_Sale_Value, Annual_Sale_Cost, Annual_Sale_Number,
Annual_Rent_ Value and Annual_Rent_Number.
Dimension data: Attributes defining the level of the aggregated data.
In this example, there is only one column containing dimension data:
FP Year.
Foreign keys (optional): Joins to other tables. If these exist, queries can
be made using summary table aggregated data on the basis of dimension
objects held in other tables of the database, as opposed to just those
contained within the summary table itself.
In this example,
\ there are two columns containing foreign keys:
Showroom_ld and Maker_ld.
SHOWROOMJD
MAKERJD
FP_YEAR
ANNUAL_SALE_ VALUE
ANNUAL_SALE_COST
ANNUAL_SALE_NUMBER
ANNUAL_RENT_VAlUE
ANNUAL_RENT _NUtv1BER
Within Web Intelligence, columns containing aggregated and dimension data

are incorporated into objects using the @Function called @AggregateAware.
Foreign keys are used to set joins in the structure of the universe.
Note: Aggregate awareness works on all tables, not just fact tables. It can
also be applied to all object types with all data types, not just numbers
and measures.
Aggregate Awareness-instructor's Guide 12-3

Summary Tables and SQL
Where possible, it is prudent to use summary table data because the
processing required to return the aggregated data is far quicker.
You can see in the example below that making a query based on event data at
a transaction level requires a more complex SELECT statement and the
processing of more database rows than one based on summary data.
Aggregates of a normalized database are based on evenUfact level data:
Sale Sale_Model Model
1226 rows I 1233

rows I
Sales Revenue = sum(SALE_MODEL.SALE_QTY'"
1-33row-s
MODEL.MODEL_PRICE
I *
((100 - SALE.SALE_SALE_DISCOUNT) /100))
Summary tables can be added to a database that hold data at a higher

level of aggregate:
Annual_Figures
126 rows I
Sales Revenue = sum(ANNUAL]IGURES.ANNUAL_SALE_VALUE)
Making use of summary table data speeds up response times because:

There are fewer rows to process.
Fewer, if any, joins are required.

Applying aggregate awareness to objects
Introduction
The first step in setting up aggregate awareness in a universe is to determine
which objects are to be aggregate aware. You can use either measure objects
or dimension objects.
Set up aggregate aware objects
Use aggregate awareness to resolve fan traps
Test aggregate awareness in the universe
Setting up Aggregate Awareness

Applying Aggregate Awareness to objects in a BusinessObjects universe
involves a four step procedure:
Step 1: Insert the Summary Table(s) in the universe structure. Set joins and
cardinality.
Step 2: Set the contexts
Step 3: Redefine the objects using @AggregateAware
Step 4: Define incompatible objects using Aggregate Navigation
Note: Part of Step 1 (setting joins and cardinality) and Step 2 are not
required if the summary table does not contain foreign keys.
Each of the steps is explained in turn in this unit.
Step 1: Insert a summary table and set joins

cardinality
The procedure for inserting a summary table in the structure of the universe is
the same as for any other table or view.
To insert a summary table

1 Insert the required ST in the structure using the Table Browser.
In this example, insert the Annual_Figures table in the Motors2004
structure.
2 Position it where it will be convenient for the joins you need to make.
3 Add joins from the ST to the existing structure.
You will need to examine the foreign keys in the ST to see where the ST
can be joined to the universe.
4 In the Annual_Figures ST, the foreign keys are Showroom_ID and
MakeUD. This allows you to join the ST to the Showroom table and the
Maker table.

HOWROOMjD
AKERjD
P_YEAA SHOWROOMjD
NUAL_SALE_VALU E SHOWROOM.NAME
NUAL_SALE _COST SHOWROOMjlDDRESS
INUAL_SALE.NUMBER· SHOWROOM_TOWN
NUAL.RENT _VALUE SHOWROOMPRE~CODE
NUAL.RENT .NUMBER COUNTRYjD
5 Set cardinality for the new joins.
Step 2: Set the contexts

After you add the ST, several new loops exist. You will need to resolve these
using contexts.
To detect contexts
1 Click the Detect Contexts toolbar button.
2 Accept the new contexts, renaming them if required.

Step 3: Redefine the objects
The columns in the summary table containing aggregated and dimension data
can be used to define object SELECT properties.
In our example, the ST columns can be used in the SELECT properties of the
following objects:
Financial
Rental
Number
Existing ofYear
Sale Revenue
Cost ofRevenue
Car Cars
Sales
objectsSold
Rented
Summary Table columns
ANNUAL_RENT_NUMBER
ANNUAL_RENT_VALUE
AN
ANNUAL_SALE_VALUE
NUAL_SALE_NUMBER
NUAL_SALE_COST
FP_Year
When you have added the Summary Table, each of these objects will have two
possible sources for returning data:
the original SELECT statement in the existing object
a SELECT statement consisting of Table_Name.Column_Name from the
Summary Table
3 You must now specify which of these methods should be used when a
query is run using these objects. You do this by modifying the SELECT
properties for the affected objects using the @AggregateAware function.
Applying aggregate aware to objects

Before editing any objects, confirm exactly what levels of aggregation are
available. In our example, we have the basic aggregation calculation and the
precalculated Annual Figures from the ST.
If you also had STs for Quarterly Figures and Monthly Figures, you would have
four possible levels altogether.
When you apply the @AggregateAware function, be aware of the available
levels, and be clear about the descending order of aggregation, for example,
·Annual Figures, Quarterly Figures, Monthly Figures, and Basic Aggregation
calculation.
Syntax of @AggregateAware is as follows:

@AggregateAware«SELECT statement for highest agg level>,
<SELECT statement for second highest agg level>,
<SELECT statement for second lowest agg level>,

<original SELECT statement for basic agg calculation»
Aggregate Awareness-Instructor's Guide 12-7

To apply the @AggregateAware function
1 Double-click the object whose properties you want to edit, or click the
Insert Object tool bar button to create a new object.
2 Click the double arrow of the SELECT dialog box to open the Edit
SELECT dialog box.
The current SELECT properties for the object, if any, will be displayed in
the top panel of the dialog box. For example, the existing SELECT
statement for the Cost of Sales object is:
Note: It can make the structure of the SELECT statement clearer if you
keep each level of the @AggregateAware function on a separate
line.
3 Click at the beginning of the existing statement, if necessary.
4 Double-click the @AggregateAware function in the @ Functions list
dialog box.
5 Insert the aggregate" actions within the brackets of the @AggregateAware
function in order, highest to lowest level of aggregation data. Separate
each action with a comma.
6 Click OK to accept the SELECT statement.
In our example, the Edit Properties dialog box now looks like this:
7 Edit other object properties as required.

9 Repeat the process for all the appropriate objects.

The @AggregateAware function is telling Web Intelligence: If you can, use the
sum(ANNUAL_FIGURES.ANNUAL_SALE_COST); if not, use the next
segment in the SELECT statement. The last segment in the
@AggregateAware function should always be the original SELECT that does
not use the Summary Tables.
Similarly, for dimension objects in the Summary Tables (such as Financial
Year, in our example), the @AggregateAware function simply selects the
column from the Summary Tables first (in descending order of aggregation),
and then finally from the normal source. For example:
@AggregateAwareCANNUAL_FIGURES.FP_YEAR, FINANCE_PERIOD.FP_YEAR)
When you have redefined all the objects, the next step is to set when Web
Intelligence can use the Summary Tables, by defining which dimension and
measure objects are or are not compatible with the STs.
Step 4: Define incompatible objects

When all objects requiring @AggregateAware have been set correctly, the final
step in the process is to set which objects are not compatible with which tables
in the Structure of the universe.
All objects that infer columns from tables in the same context as the Summary
Table can automatically be deemed compatible with the Summary Table.
However, a Summary Table that does not contain any foreign keys cannot be
joined to other tables and cannot be part of a context. In that case, any query
that contains objects from the Summary Table and from other tables will
produce a Cartesian product. Therefore, all objects based on columns from
any other table should be deemed incompatible.
You set incompatible objects using the Aggregate Navigation tool.
Using the Aggregate Navigation automatic detection tool

To set incompatibilities, you use an automatic detection tool available in the
Aggregate Navigation dialog box. While the Detect Incompatability tool does a
good job in detecting object incompatibility, you should still check the
automatic settings very carefully.
If the Detect Incompatability tool sets objects to be incompatible erroneously,
then those objects will be incompatible with other tables in the context
containing the Summary Table. This could result in queries that would normally
return valid results returning instead an Incompatible combination of objects
error message or returning a Cartesian product. The automatic detection tool
tool also detects incompatibilities on every table in the universe, and therefore
may stop some legitimate queries from working.
It is therefore recommended that you check each of the incompatible settings
manually.

To set incompatible objects
1 Select the Aggregate Navigation from the Tools menu.
The Aggregate Navigation dialog box displays:
2 Click the Detect Incompatibility button.

3 Select a summary table in the Universe Tables panel.
The right panel shows the list of classes and objects that need to be
checked for compatibility for the summary table you selected. To
distinguish whether an object is compatible or not, the object must either
reference a table included in the same context as the summary table, or
reference a column in the summary table itself.
4 Open each class in turn, and click the check box adjacent to each object
that is incompatible with the Summary Table and its context.

In our example, the ST is the Annual_Figures table. The Client class is
selected, because all the objects in it are derived from tables that are not
in the Annual_Figures context, and no object references the Summary
Table.
'--'
65
'-'
7''~~
'----'
'...J---'
J
Use your familiarity with the universe to check that objects shown as
compatible (that is, not checked) will operate correctly and not produce
Cartesian products or an incompatible combination of objects.
If an object is set incorrectly, select or clear the object by clicking it.
Repeat actions 3 and 4 for each table required.
When you are satisfied with all incompatibility settings, click OK to close
the Aggregate Navigation dialog box.

Using aggregate awareness to resolve fan
traps
The aggregate awareness functionality within BusinessObjects universe
design can be viewed simply as a method for specifying preferential coding
based on the other objects contained within a query.
When viewed from this perspective, it becomes apparent that aggregate
awareness can be used to resolve issues other than those for which it was
originally intended.
For instance, there is a particular fan trap scenario that, while it can be
resolved using the classic fan trap solution, results in certain inefficiencies.
This scenario is described below.
The fan trap scenario

Unlike the classic fan trap, the structure shown here involves two tables
instead of three:
xl1
y •
z •
The standard fan trap resolution

Using the standard method for resolving a fan trap, you would:
Create an alias of table A
Create a join from the alias An to table A and set cardinalities
Set contexts B and An
Edit object Y so that it refers to columns in the alias An rather than table A
.Y

The efficiency problem
This standard fan trap solution resolves the fan trap solution if objects Y and Z
are used in the same query. However, if a query involves only objects X and Y,
then no fan trap exists, and yet table 1 will still be processed twice (once as the
alias An).
You can overcome this inefficiency by applying aggregate awareness to the
problem.
To resolve this fan trap using @AggregateAware

1 Create an alias of table A.
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 (the first choice referring to table A
and then the alias An).
5 Make the Z object incompatible with table A
0a.ggrega tea ware(sum( table A .rolumn),

sum( table An.column))
The solution makes use of aggregate awareness functionality despite the fact
that it does not involve a summary or aggregate table
Testing aggregate awareness

After you have modified the universe by making one or more objects aggregate
aware, as with any universe element, you must always test the results by
exporting the universe and building queries in Web Intelligence.
To test the universe, build a query that uses 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.

Practice
Activity: Aggregate awareness
Objectives
Bu the end of the this activity, you will be able to:
Insert summary tables into the Motors2004 universe and make the
universe aggregate aware.
Business requirement: Prestige Motors management is finding that the
annual and quarterly reports take a long time to run. They have
requested that these reports be produced without any noticeable
processing delay.
Instructions
1 Incorporate the ANNUAL_FIGURES summary table in the Motors2004
universe and apply aggregate awareness as follows:
Insert the ANNUAL_FIGURES table in the structure of the universe,
and insert the following joins and set cardinality.
SHOWROOM.SHOWROOM_ID=ANNUAL_FIGURES.SHOWROOM_ID
ANNUAL_FIGURES.MAKER_ID=MAKER.MAKER_ID
Detect contexts.
Note: In this instance, the new joins and tables do not affect existing
contexts. Do not delete or overwrite the existing contexts.
Redefine the SELECT properties of the objects as indicated below:
Rental Revenue =
@Aggregate_Aware(sum(ANNUAL_FIGURES.ANNUAL_RENT_VALUE
),sum(RENTAL.SALE_RENTAL_PERIOD *
RENTAL_MODEL.SALE_OTY * MODEL. MODEL_DAY RENT * (100 -
RENTAL.SALE_SALE_DISCOUNT) / 100»)
Sales Revenue
@Aggregate_Aware(sum(ANNUAL_FIGURES.ANNUAL_SALE_VAlUE
),sum(SALE_MODEL.SALE_OTY * MODEL. MODEL_PRICE * ((100
- SALE.SALE_SALE_DISCOUNT) / 100»)
Number of Cars Sold

@Aggregate_Aware(sum(ANNUAL_FIGURES.ANNUAL_SALE_NUMBE
R),sum(SALE_MODEL.SALE_OTY»
Cost of Car Sales =

@Aggregate_Aware(sum(ANNUAL_FIGURES.ANNUAL_SALE_COST)
,sum(SALE_MODEl.SALE_OTY * MODEL. MODEL_COST»

Financial Year =
@Aggregate_AwareCANNUAL_FIGURES.FP_YEAR,FINANCE_PERIO
D.FP_YEAR)
Set incompatible objects manually using Aggregate Navigation and

check the results.
Note: The Franchises object should be defined as incompatible.
2 Save and export the universe and test the annual level of Aggregate
Awareness by making two queries containing objects as follows:
Showroom, Financial Year, Sales Revenue, Rental Revenue
Model, Financial Year, Sales Revenue, Rental Revenue
Make sure you view the inferred SQL in each instance.
3 Incorporate the QUARTER_FIGURES summary table in the Motors2004
universe and apply aggregate awareness.
You will have to edit the @AggregateAware in the objects listed above to
include the quarter level. In addition you will have to apply the
@AggregateAware function to the Financial Quarter object.
Set incompatible objects manually using Aggregate Navigation and
check the results.
Note: The Franchises object should be defined as incompatible.
4 Save and export the universe and test the quarter level of aggregate
awareness by making two queries containing objects as follows:
Showroom, Financial Year, Financial Quarter, Rental Revenue
5 Test that the objects that are incompatible with both the
ANNUALJIGURES and QUARTER_FIGURES summary tables infer
SQL at the Fact table level.

Lesson summary
Review
Quiz: Aggregate Awareness

1 How does the @AggregateAware function improve query performance?
Answer:
It directs the query to run against aggregate tables or summary tables,
whenever possible.
2 Why does using summary table data speed up response times?
Answer:
There are fewer rows to process.
Value calculation is not required.
Fewer, if any, joins are required.
3 The window you use in Designer to set incompatibilities between objects
and tables in the structure of the universe is called the
_________ window.
Answer:
Aggregate Navigation
Summary
lesson Understand what is meant by the term aggregate aware
objectives
with the Understand why universes that are aggregate aware allow queries to
learners to process more efficiently
check that all Set up aggregate aware objects
learners have Use aggregate awareness to resolve fan traps
acquired the
Test aggregate awareness in the universe
required
skills before
moving on to
the next
section.

"-./J
Lesson 13
Derived Tables and Indexes
A derived table is a dynamic, virtual table that you create within the universe
structure. It allows you to transfer more of the processing load from the report
server to the database and improve query execution performance.
Using derived tables
Applying index awareness
Duration: 1 hour
"-./
I

Using derived tables
Introduction
This unit explains-what derived tables are and how you create them as
dynamic,. virtual tables in the universe .•
After completing this unit, you will be able. to:
Understand the advantage of adding derived tables to your universe
structure
Insert a derived table in the universe
What is a derived table?

A derived table is a dynamic, virtual table that you create within the universe
structure. It consists of a set of SQL statements that you create in Designer,
and that you can then use as a logical table to create objects.
In the derived table's SQL set, you can put a SELECT statement in place of a
table name in the FROM clause. The SQL set can also contain embedded
prompts, and you can create joins between the virtual derived table and the
physical tables, just as you can with other tables.
Derived tables can be used in place of database views, aggregate tables, or
lookup tables.
Advantages of using derived tables

Creating a derived table within the universe gives you a number of
advantages:
More efficient query execution. Using derived taqles allows you to
transfer more of the processing load from the report server to the
database.
You can 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.
Improved query expressiveness. Derived tables can reduce, or even
eliminate, the number of report variables that end users are required to
create themselves by:
enabling nested SQL statements in the FROM clause in the definition
of universe objects
providing the ability to define logical data sets and reuse them in the
FROM clauses of other queries
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. These aggregate tables are costly to maintain and refresh
frequently. Derived tables can return the same data and provide real-
time data analysis.

'-./
'"
'~
"-'
'-./
-./
"'-.-/
'"----'
,,--,
"--'
"--'
--'
"--'
Adding derived tables

Derived tables appear in your Designer schema in exactly the same way as
normal database tables, but the workflow for creating them is different.
To create a derived table

1 Click Derived Tables on the Insert menu.
The Derived Tables dialog box displays.
2 Type the table name in the Table Name dialog box.

3 In the SQL Expression field, type the following SQL:
select COUNTRY. COUNTRY_NAME,
count(REGION.REGION_ID) as number_of_regions
from COUNTRY,
REGION
where REGION.COUNTRY 10 = COUNTRY. COUNTRY ID
group by COUNTRY_NAME
It is important in this case to alias the column that contains the

calculation. Designer uses these aliases as the column names in the
derived table.
Derived Tables and Indexes-Instructor's Guide 13-3

In this case, the derived table has two columns: country and
number _ oCregions.
4 Click Check Syntax to parse and validate your SQL.

S Click OK.
The derived table appears in the schema next to the physical database
tables.
6 Insert a join between the new derived table and the Country_Region
table.
CLIENTJD
CLlENT_LASTNAME
CLlENT_FIRSTNAME
CLIENT_ADDRESS
CLIENT_TOW'N
CLIENT_AREA
CLlENT_AREA_CODE
CLlENT_PHONE_NO
REGION_ID
EMPLOYEE_ID
CLIENT_AGE
COUr~TRYJD

Add the derived table to the list of classes and objects
1 Click the new table to highlight it.
2 Drag and drop the table into the Classes and Objects pane.
The table name appears as a new class, and Country Name and Number
of Regions appear in the class as objects.
3 Change the object definition for Number of Regions object to a measure
object because it will retrieve calculated data.
, Car
¢"iD Showroom
$121 Client
rtHi!! Financial Period
$"iD Rentals
¢"iD Sales
$"121 Dummy Restriction Obiects
$'\M Personnel
8~IDerived Tabl~
: ... tIi1 Country Name
,,", IiiiII Number Of Regions

S Test the new objects in Web Intelligence.
To edit a derived table

1 Right-click the table in the Designer schema and select Edit Derived
Table from the shortcut menu.
2 Edit the derived table, and then click OK.
I
'-.J

Practice
Activity: Derived tables
Objectives
Create a derived table that shows the number of transactions per
customer.
Instructions
1 Using Motors2004, insert a derived table to show the number of
transactions per customer.
2 Name the new derived table Best_ Cust.
3 Create the SQL statement so that it looks like this:
SELECT
CLIENT.CLIENT_ID, COUNT(SALE.SALE_ID) AS
Number_of_transactions
FROM CLIENT, SALE

WHERE CLIENT.CLIENT ID=SALE.CLIENT_ID
GROUP BY CLIENT.CLIENT_ID
4 Parse the SQL statement to verify your syntax.

5 Insert a join between the Best_Cust and Client tables.
6 Add the new join to the Sales context.
The join between the Best_ Cust and Client tables is from the ClienUd
primary key in the CLIENT table to the ClienUd foreign key in the
Best_ Cust table.
The table schema should look like this.
SALE_tO
LlEr~TJD CLIENT_10
LlENT_LASTNAME SALE_DATE
,.CLIENTJIRSTNAME SHO\oiROOM_ID
: CLIENT_ADDRESS SALE_SALE_DISCOUNT
CLlENT_ TO\oiN 'ISALE TYPE
CLIENT_AREA SALE=TOTAL
, CLlENT_AREA_CODE SALE_RENT AL_PERIOD
CLIENT_PH ONE_NO
••EMPLOYEE 10
r~'REGlmUD
:'-'IIt:'r.IT •••r.::c
7 Build a new class called Best Customers.

8 Add the Number of Transactions object to this class.
9 Define the object as a measure object.
11 In Web Intelligence, build a report that shows the number of transactions
per customer and the number of transactions per country.

Applying index awareness
Introduction
This unit describes how to set up a universe in Designer to take advantage of
primary and foreign keys that may already exist in the data source.
Understand what index awareness is
Set up primary key index awareness
Set up foreign key index awareness
What is index awareness?

Index awareness is the ability to take advantage of the indexes on key columns
to speed data retrieval.
The objects that you create in the universe are based on database columns
that are meaningful to an end user. For example, a Customer object retrieves
the field that contains the customer name. In this situation the customer table
typically has a primary key (for example, an integer) that is not meaningful to
the end user, but which is very important for database performance. When you
set up index awareness in Designer, you tell Designer which database
columns are primary and foreign keys. This can have a dramatic effect on
query performance in the following ways:
Designer can take advantage of the indexes on key columns to speed
data retrieval.
Designer can generate SOL that filters in the most efficient way. This is
particularly important in a star schema database. If you build a query that
involves filtering on a value in a dimension table, Designer can apply the
filter directly on the fact table by using the dimension table foreign key.
This eliminates unnecessary and costly joins to dimension tables.
Designer does not ignore duplicates with index awareness. If two customers
have the same name, Designer retrieves only one unless it is aware that each
customer has a separate primary key.
Derived Tables and Indexes-instructor's Guide 13-7

Setting up index awareness
Report designers in your organization want to build a report using the
Motors2004 universe that returns revenue by customers, for customers in
specific countries, let's say the United States and the United Kingdom.
To build this report in Web Intelligence, for example, you would drag the Client
Name and Sales Revenue objects into the Result Objects pane in the Query
Panel, and then drag the Country object (from the Client class, not Showroom)
into the Query Filters pane and restrict the countries to the US and the UK.
Without index awareness, Designer generates the following SQL:
SELECT
CLIENT.CLIENT_FIRSTNAME + " , + CLIENT.CLIENT_LASTNAME,
sum(SALE_MODEL.SALE_QTY * MODEL. MODEL_PRICE * ((100 -

SALE.SALE_SALE_DISCOUNT) I 100»
FROM
CLIENT,
SALE,
SALE_MODEL,
MODEL,
COUNTRY COUNTRY REGION
WHERE
( CLIENT.CLIENT ID=SALE.CLIENT_ID
AND (SALE.SALE_ID=SALE_MODEL.SALE_ID
AND (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID
AND (SALE.SALE_TYPE='S'
AND (COUNTRY_REGION. COUNTRY ID=CLIENT.COUNTRY 10
AND
COUNTRY_REGION. COUNTRY NAME In ( 'United

Kingdom', 'USA'
GROUP BY
CLIENT. CLIENT_FIRST NAME + " '+ CLIENT.CLIENT_LASTNAME
In this case, Designer has created a join to the Country_Region table in order
to restrict the countries retrieved.
With index awareness, you can tell Designer that COU NTR Y_10 is the primary
key of the Country_Region table and that it also appears in the Client table as
a foreign key. Using this information, Designer can restrict the countries
without joining to the Country_Region table.
In this case, Designer is able to generate SQL that restricts the countries
simply by filtering the values of the COUNTRY _10 foreign key.

· To set up primary key index awareness
1 Right-click the object on which you want to set up index awareness and
select Object Properties from the shortcut menu.
Or
Select the object and click Object Properties on the Edit menu.
The Edit Properties Of dialog box displays.
2 Click the Keys tab.
3 Click Insert.
A key line is inserted in the list of keys box.
4 To define key awareness for the primary key:
Click the drop-down arrow next to Primary Key and select Primary in
the Key Type list.
Click within the line under Select field, and then click the ... button
that appears, to open the SQL editing dialog box.
The Edit Select statement dialog box appears.

In the Edit Select Statement dialog box, use the SOL Editor to build
the primary key SOL SELECT clause or type it directly. For example,
for the Client Country object above, the primary key SOL is
Country_Region.Country_id.
5 Repeat steps 3 and 4 for all columns that make up the primary key.
6 If you want to add a WHERE clause:
Click within the line, under the Where column, then click the ... button
that appears, to open the Edit Select statement dialog box.
The Edit Select statement dialog box appears.

Use the SOL Editor to build the primary key SOL WHERE clause or
type it directly and then click OK. There is no WHERE clause in this
example.
Select Number from the drop-down list of key types.
7 Select Enabled.
8 Click OK.
To set up foreign key index awareness

1 Right-click the Client Country object, the object on which you are setting
up index awareness and select Object Properties from the shortcut
menu.
2 Click the Keys tab.
3 Click Insert.
A key line is inserted in the list of keys box.
13-1 0 Universe Design-Instructor's Guide

To define key awareness for the foreign key:
Select Foreign in the Key Type list
Click in the Select field and then click the ... button.
In the Edit Select Statement dialog box, use the SQL Editor to build
the foreign key SQL SELECT or type it directly.
5 Repeat steps 3 and 4 for all columns that make up the primary key.
6 If you want to add a WHERE clause:
Click the Where column and then click the ... button
Build the foreign key SQL WHERE clause and click OK to close the
dialog box. There is no Where clause in this example.
Select Number from the drop-down list of key types.
7 Select Enabled.
8 Repeat the steps for all columns in the foreign key and then click OK.

Practice
Activity: Index awareness
Objectives
Apply index awareness to improve the performance of SQL generation in
Web Intelligence.
Instructions
1 Using the Client Country object in Motors2004, enter the following under
Keys:
CLiENTCOUNTRY _10
COUNTRY_REGION.COUNTRY_10
COUNTRY_REGION.COUNTRY_ID=CLlENTCOUNTRY _10
Primary key
WHERE
Foreign key

3 Create a query in Web Intelligence including the Client Name object and
Sales Revenue.
4 Apply a query filter to restrict the data to a single country.
5 View the SQL. Notice that in the WHERE clause, it no longer uses the
COUNTRY NAME InUst... statement. It uses
COUNTRY _REGION=CLlENTCOUNTRY _10.

.Lesson summary
Review
Quiz: Derived Tables and Indexes

1 What are the advantages of creating derived tables in a universe?
Answer:
It transfers more of the processing load from the report server to the
database.
It reduces the number of report variables that end users are required to
create themselves.
In some cases, it reduces maintenance of database summary tables.
2 What part of the SQL expression does Designer use to create column
names in the derived table?
Answer:
It uses an alias to the column.
3 When you insert a derived table and insert joins, what happens if you do
not add the new join to the appropriate context?
When you parse the derived table's SQL, it will generate an
exception.
When you run a query, the derived table will create a Cartesian
product.
The objects you create from the derived table will be incompatible
with objects from any of the existing contexts.
Answer:
The objects you create from the derived table will be incompatible with
objects from any of the existing contexts.
4 How do you apply index awareness on a universe object?
Answer:
Go to the Keys tab of the Edit Properties dialog box for the object you
want to make index aware.
5 How can index awareness improve query performance?
Answer:
It can improve query performance by taking advantage of indexes on key
columns in the data source.

Summary
lesson
Understand the advantage of adding derived tables to your universe
objectives structure
with the
learners to Insert a derived table in the universe
check that all Understand what index awareness is
learners have
Set up primary key index awareness
acquired the
required Set up foreign key index awareness
skills before
moving on to
the next
section.

Lesson 14
Linking Universes
Using Designer, you can choose to link universes so that they share common
components such as parameters, classes, objects, or joins.
Understanding linked universes
Creating links between universes

Understanding linked universes
Introduction
Using BusinessObjects Designer, you can dynamically link one or more
universes. This can reduce development and maintenance time. When you
modify a component in the core universe, Designer propagates the change to
the same component in all the derived universes.
Understand what linked uinverses are and why you would choose to use
them
Understand the advantages and limitations of using linking
What are linked universes?

Be careful Linked universes are universes that share common components such as
not to parameters, classes, objects, or joins. When you link two universes, one
confuse the universe has the role of a core, or kernel, universe, the other a derived
meaning of universe. When changes are made in the core universe, they are automatically
the term propagated to the derived universes.
"derived" in
this lesson The linked objects can only be used to infer SQL against the database that the
with the use universe is connected to.
of derived For example, within a universe (B) it is possible to dynamically link to another
tables in the
universe (A), as shown below.
previous
lesson.
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 that they are grayed out) to universe A and cannot be
edited in universe B.
Because the linked objects infer SQL against the same database defined in the
connection for the derived universe, it is not possible to use this functionality
to make a universe query more than one database.

Using linked universes
Linked universes enable you to create a set of objects and structure in a single
.unv (known as the core, or kernel universe) and reuse them in another
universe (known as the derived universe). Because the core universe is
dynamically linked and not copied into the derived universe, there is only one
set of code to maintain for the duplicated objects and structure. If you make a
change in the core universe, the changes are automatically reflected in the
derived universe.
Edit objects:, structm"e in

core universe and ch<Ulges
Holds core objects iU'e ilutOlnaticallv reflected
'il'<t~::.Derived ~1iveT:';es B
and c,_,
Possible linking strategies

"In practice, there are a number of situations where linking can be useful. You
'::'can choose to use linking for any of the following reasons:
If you decide on a strategy for creating several different universes to front
end the target database for different functions within your organization
and certain objects are common to all, this offers a way of creating the
objects once only and maintaining one instance of them (core approach).
If you need to create the same universe twice with different universe IDs
or connections (master approach).
If you need to create a large universe and want to divide the development
between several designers.
Each designer can work on a separate component and then they can all
be linked to a derived universe (multiple core/component approach).
Linking Universes-Instructor's Guide 14-3

Advantages and limitations to linking
The key advantages of linking universes are:
Review this Reduced development and maintenance time.
information The universe objects and structure are created only once, and only one
carefully with instance of an object needs to be maintained. The derived universe(s) is
the learners. automatically updated when the linked universe is changed.
You can centralize often used components in a core universe, and then
include them in all new universes.
You do not have to recreate common components each time you create a
new universe.
Facilitated specialization.
Development can be split between database administrators who set up a
basic core universe and the more specialized designers who create more
functional universes based on their specific field.
You can link the active universe to a core universe, only if the following
requirements are met:
The linked universes must use the same connection and connect to the
same data source.
Using the same connection for both the core and the derived universes
makes managing the universes easier, but this can be changed at any
time. The core universe uses the derived universe connection.
The core and derived universes must be in the same repository.
The core universe needs to have been exported and re-imported at least
once. The derived universe does not need to have been exported before
creating a link.
You are authorized to link the given universe.
You need to be aware of the following restrictions when linking universes:
You can use only one level of linking. You cannot creatJ'de~ived
universes from a universe that is itself derived.
All classes and objects are unique in both the core universe and the
derived universes. If they are not, then conflicts will occur.
The two universe structures must allow joins to be created between a
table in one universe to a table in the other universe. If not, then
Cartesian products can result when a query is run with objects from both
structures. This can lead to unforeseen loops that need to be resolved.
Only the table schema, classes, and objects of the core universe are
available in the derived universe. This means that the contexts have to be
detected again in the derived universe. In some instances, this can be an
advantage because the structure of the two universes is effectively
merged in the derived universe and the old contexts are incomplete.
LOVs associated with a core universe are not saved when you export a
derived universe with the core universe structures.
If there are two tables in the linked universes with a common name, the
table being imported is the table that will be used, therefore no aliases will
be created. All joins will be placed on the new table, asumming it is
coming from the same database.
,/
Creating links between universes
Introduction
There are two methods you can use to link universes. Each are used for
different purposes:
Linking universes
When you link universes, you create a set of objects and structure in a
single core universe and you reuse them in a derived universe.
Including one universe within another
When you include universes, you use linking to copy the contents of the
core universe into the derived one, but then you use the Include feature
to break the link between the two universes.
Strategies for using both these methods are discussed in the following topics.
Link universes
Include one universe within another
Understand the advantages of each method
Linking universes
When you link an active universe to another universe, the active universe
becomes the derived universe, and the linked universe becomes the core
universe. 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.
You begin by opening the .unv file that will become the derived universe. That
is, first you open the universe to which you want to receive the duplicated
objects and structure. Using the Link feature, you then select the core universe
file so that its contents are added to the open .unv universe file.
To create a linked universe

1 Open the universe file that you want to become the derived universe.
2 The universe structure is inserted into the Structure panel.
3 Click the Parameters toolbar button.
OR
Select File >Parameters from the menu bar.
4 Click the Links tab.
5 Click Add Link.

The Universe to Link dialog box opens.

•.
.I
beach Island Resorts Marketing, unv
ef ashion ,..Motors2000.unv
f'/lotors ~ Motors2004.unv
Motors2004 ~ Staff2002, unv
Staf2002
~ eFashion, unv
6 Select the universe you want to link, in this exercise, Staff2004.

7 Click Open.
The Links tab of the Universe Parameters dialog box appears.
8 Click OK.
The two universes are now linked.

Editing the derived structure
The derived universe now appears as shown below.
Note: The tables and joins in the structure and the classes and objects of the
linked universe are grayed out, thus indicating that they cannot be
edited.
B!i&~i~lE:[\tJ1jjM
IH'JP N~JD
~:t$~~ttf;~t~t_ r-r;
DEi'T...w ~JI> [i"

&If ...1As"W'AMH fj.[p .L'\STr-rAME c:
fM'..fIRiTrfPlMEi fi,.[p..FI1;:s1til'tME; I;:
&.II' .J>Q~ EMf .DOft [>;
EW'..J'IOOfS>S a.m>..I\U'mSS c::
&IP~c;olt6 &!P..J'dI£'LCO[)lj c:
ENP.TO'J'l,'N ii.!P~TOwtf c::
e.IP..ftIo\if; ENP.HIONfi 0
!SH0W1\OOMJP ~OWRoo!oUV tf:
=:i~=!p=::-.-·-=:·::)m~=':;·:=':'::::=:···:·:=··:~;"'~::~""- [f~= ~~~~ ~ c
=~
~GE..MI[i f1.!P.SfiX fMP.S6:';. Ci
108JI> .... m ••••••• jj~~~@ %.9 !'f;

DtILl<""'"
DmJ'IiI'"
iTYIJUD
HO'iVROOMliAl.m
HOWROOM..J\[)tft
HOW1\OOM.TO';lltf
HOWROO~I
ICOl.fflm-JP
To complete the linking process

1 Set the joins between the two structures to avoid potential Cartesian
products.
2 Remove existing contexts.
3 Detect aliases.
4 Detect contexts.
5 Hide/create new objects as required.
6 If you are using aggregate awareness, be sure to specify whether the
I
objects pointing to the new tables are compatible with existing summary
'---/ tables.

Including one universe within another
In the last instance cited above, it would be better to include the component
universes in the final derived universe, rather than link them. Linking would
mean that there are several separate universes to maintain, but the Include
feature copies the contents of the component universes into the derived one.
You could then delete the component universes and maintain only the derived
one.
You can choose to use the Include feature instead of linking when you simply
want to copy all the classes, objects and structure from ope universe to
another. You could do this first by linking from universe B to A and then using
Include to sever the link, thus making the classes, objects and structure of the
universe A part of universe B.
In effect, Include is a way of quickly copying every thing in one universe to
another.
To include a universe:
The procedure for including is the same as for linking except that after step 6
(selecting the universe to link) and before step 7 (confirming the selection of
the Universe Parameters, Links tab) of the procedure you:
1 In the Links tab of the Universe Parameters dialog box, click the universe
name in the middle panel.
The Include button becomes active.

2 Ciick Include.
The core universe content is copied into the derived universe as
illustrated below.
I
'-.J
HOWRDOMlfl\i
HO'Jilo'ROOM..Ati
HOWROOH.:rO
HDWROOM..AFI
!:OUl-fTRYJD
When you include, the link to the core universe is broken and the structure,
classes, and objects of the included universe become part of the derived
universe. Note that the structure, classes, and objects of the included universe
are not grayed out. This indicates that they can be edited.
Linking Universes-instructor's Guide 14-9

When to link and when to include?
Advantages of linking
The structure is only created once in a core universe and then reused in
derived universes.
Classes and objects are only created once in a core universe and then
reused in derived universes.
Any maintenance only has to be applied to the core universe.
Derived universes are automatically updated when the core universe is
amended.
Disadvantages of linking
Only applicable for repository-based universes.
Contexts have to be redefined in each derived universe.
Exported lists of values are not available in each derived universe.
The connection parameters have to be similar. For example, it is not
possible to use this technique to query more than one database.
Only one level of linking is allowed.
Advantages of including
It is a quick way of copying one universe into another/others.
Maintaining one universe rather than a number of smaller universes is
simpler.
Disadvantages of including
It is only applicable for repository-based universes.
Contexts have to be redefined in the new universe
If the initial universe changes, the universe does not reflect those
changes.

Practice
Activity: Linking universes
Objectives
Link and then include universes using the Motors2004 universe you have
built during this course, and the Staff2004 universe.
Business requirement: Prestige Motors management wants to report on
the sales performance of its sales staff and their managers.
Instructions
1 Check that you have saved and exported the Staff2004 universe recently.
2 Make room in the upper left corner of the Structure pane in the
Motors2004 universe.
To do this, click in any white space in the Structure pane, click Select All
from the Edit menu, then drag the tables to the right in the pane.
1 Embed the structure and objects of the Staff2004 universe in the
Motors2004 universe.
Place the Staff2004 structure in the top left-hand corner of the
Motors2004 universe structure and insert a join between the employee
and client tables as follows:
EMPLOYEE.EMP ID=CLIENT.EMPLOYEE_ID
Edit the Sales and Rentals contexts to include the newly created join and
the one between the Employee and Manager tables.
2 Save the Motors2004 universe and close it.
3 Open the Staff2004 universe and make the following changes to the staff
object.
Make sure Name = Sales Person
that the Where = EMPLOYEE.JOB_IO = 3
learners use
4 Save the Staff2004 universe, export it and close it.
the JOB_IO
column, and 5 Open the Motors2004 universe and check that the change in the
not the Staff2004 universe is reflected in it.
EMP _10 6 Change the Link to Include.
column.
7 Save the Motors2004 universe.

Lesson summary
Review
Quiz: Linking Universes

1 Which of the following is an advantage of using linked universes:
Contexts do not have to be detected in the derived universe.
You only have to maintain one instance of an object that is used in
the linked universes.
The exported LOV files are available in both the core and derived
universes.
Answer:
You only have to maintain one instance of an object that is used in the
linked universes.
2 T/F: You can use linking to make a universe query more than one
database.
Answer:
False
3 T/F: When two universes are linked, if you make a change in the core
universe, the changes are automatically reflected in the derived universe.
Answer:
True
4 To copy the contents of one universe into another, would it be better to
Link or to Include the universes?
Answer:
Include
Summary
lesson
Understand what linked uinverses are and why you would choose to use
objectives them
with the
learners to Understand the advantages and limitations of using linking
check that all Link universes
learners have Include one universe within another
acquired the
required Understand the advantages of each method
skills before
moving on to
the next
section.

Lesson 15
Securing Universes
In this lesson, you will learn how to create restriction sets in order to apply
security on universes.
Setting access restrictions on a universe

Setting access restrictions on a universe
Introduction
One of most important tasks in managing a universe is applying security in
order to restrict the users or groups of users who are authorized to use
universe objects or resources.
Explain the levels of security available in BusinessObjects Enterprise to
authorize or restrict access to data with universes
Describe the types of restrictions that can be applied to a universe
Describe how restriction sets are managed by Designer
Create a new restriction set
Apply a restriction set to a user or group of users
Set restriction group priority
View user and group restrictions
About security and universes

In BusinessObjects Enterprise, universe security is managed at two levels:
Central Management Server
The BusinessObjects Enterprise system administrator can authorize or
deny access to universes stored in the CMS. The administrator can
define which universes users are authorized to access, and depending
on the rights defined for a user group, the administrator can also restrict
viewing, editing, deleting, and other actions in a universe.
Universe
As universe designer, you can define restrictions for users who are
authorized 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 SOL generation controls, and connection
controls. This unit describes the types of restriction sets you can define
on a universe.
What is a restriction set?

A restriction set is a named group of restrictions that apply to a universe. You
can apply a restriction set to a selected group or user account for 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.
You assign a restriction set to a BusinessObjects user or group. This limits the
access to universe objects or resources based on the profile of the user group.

What kind of restrictions can be applied to a universe?
Access restrictions that apply to a user or group are defined in a restriction set.
You can define multiple restrictions for a universe. Restrictions can be edited,
or deleted at any time.
The following types of restrictions can be included in a restriction set:
universe
You
You
The can
can bycontrol
universe
Options to
to another
define
apply
replace athe table
aWHERE
columntable
connection
limit size
the SQL toin
level
of theresult
clause
referenced database.
that
security.
the
the data
generated in restricts
theand
source.
set
for You
queries.
Description
access Type
can
access
query
a of
universe.
select restriction
an alternative
to row andtime.
execution
query. connection for the
limits the result set returned by
options
Alternative
Connection
Query
SQL accesstable
Row generation
controls Object access
How are restriction sets managed?

In Designer, you manage restriction sets using the Manage Access
Restrictions dialog box, which you access by selecting the Manage Security
option on the Tools menu.
The Available Restrictions pane in the left-hand side of the Manage Access
Restrictions dialog box lists all the restriction sets currently available to the
universe.
The users and groups defined for each restriction set are listed in the Available
Groups and Users pane, in the right-hand side of the dialog box.
Securing Universes-Instructor's Guide 15-3

The options available for managing access restrictions on this universe are
described in the table below:
To
To remove
define
To define
modify
Description aWHERE
aan
userrestriction
add aallwhether
view neworrestriction
ausers
security
and
existing
group set to
clause
youoption
want
groups from
that
set.
from the
restricts
combine
defined
restriction
from the list.
selected
set. inrow
list of access
therestric-
users
CMS.
Busines- or
toRestriction
sObjects
query.
rowusing
groups. andusers
Management
tions the option
limits
and
theor
Server
AND groups
result
(CMS).defined
set returned
OR logical in theby
operator.Central
a
Restriction
Delete
Preview
New
Edit
Remove
Add oroptions
user restriction
Priority group set
Creating a restriction
You can create, edit, and delete a restriction set at any time once the universe
has been exported to the CMS. You can create multiple restrictions depending
on the query needs of a target user group.
To create a restriction set:

1 From the Tools menu, select Manage security ..., and then click Manage
Access Restrictions ...
Note: If you have not yet exported the universe, a message box will
appear to indicate that you must export the universe before you
can create security restrictions.
2 The Manage Access Restrictions box displays.

3 In the Manage Access Restrictions dialog box, click New.
The Edit Restriction Set dialog box displays.
The six tabs in this dialog box allow you to define the type of restriction
you want to include in this restriction set.
The Reset button in the bottom left-hand corner of the Edit Restriction
dialog box allows you to return to the settings that were defined
previously.
4 In the Restriction Name text box, type My Restriction.
5 Verify that the Connection tab is selected.
If you want this restriction set to specify that certain users use a specific
connection to connect to the data source, select the connection from the
drop-down list or create a new one as you would normally.
6 Click the Controls tab.
The Controls tab displays.
Securing Universes-instructor's Guide 15-5
/
In this tab, you can limit the size of the result set and the execution time
of queries for a specific group of users. These are the same settings that
you have used before in the Universe Parameters dialog box.
The SQL tab displays.
In this tab, you can set controls on the types of queries that end users
can formulate for a specific group of users. These are the same settings
that you have used before in the Universe Parameters dialog box.

To restrict access to specific universe objects
1 In the Edit Restriction dialog box, click the Objects tab.
The Objects tab displays.
In this tab, you can specify the objects in this universe that a specific user
or group of users will not be authorized to use in queries.
In this scenario, you will create a new restriction set which will be applied
to the Sales user group. The Sales user group is made up of sales
representatives who are need to access data concerning Prestige Motors
car sales. Because they are not involved in rental transactions, you have
decided that you do not want to authorize them to view data that can be
retrieved by the objects in the Rental class.
2 In the Objects tab of the Edit Restriction dialog box, click Add.
The New Restricted Objects dialog box displays.
Note: If you are sure of the name of the object you want to restrict, you
can type it in the Object Name text box and click OK to continue.
Otherwise, continue to step 3.
3 Click Select.
The Object Browser displays.

In the Object Browser, you can select the universe objects that you want
to restrict for a specific user or group of users.
4 Click + next to the Rentals class.
The Rentals class folder opens, displaying the subfolders organized in
this class. You can choose to select the objects in these classes one by
one, or you can select an entire class or subclass. All the objects in the
selected class will be selected at once.
5 Click + next to the Rentals Details class.
6 Click the Invoice ID Number object to select it.
Car
Ef.HIDJJ Showroom
1±1!iliiJ Client
1±i!iliiJ Financial Period
[i'h~ Rentals
~ ..~ Rental Details
: ;···m j_;Jj,"~!lla8l11111l\!!1
$Hi\§) Rental Dates
. [B··!iliiJ Rental Figures
$!iliiJ Sales
J¥ ..!iliiJ Dummy Restriction Objects
7 Click OK.
The name of the subclass and object you selected appears in the New
Restricted Object dialog box.

8 Click OK.
The Objects tab of the Edit Restriction dialog box now displays the object
you selected in the list.
9 Click the Add button to continue selecting objects to restrict.

10 In the New Restricted Object dialog box, click Select.
11 In the Object Browser, click + next to the Rentals class.
12 This time, click the Rental Dates subclass to select all the objects in that
subclass at the same time.
13 Click OK.
The Rental Dates subclass appears in the New Restricted Object box.
14 Click OK.
15 Follow the same procedure to include the Rental Figures subclass in the
restriction set.
All the subclasses organized in the Rentals class are now listed in the
New Restriction Objects tab.
16 Click the Check All button to validate the object restriction settings.
The status of the objects seiected appears as "OK".

To restrict access to rows in the database
1 In the Edit Restriction dialog box, click the Rows tab.
The Rows tab displays.
In the Rows tab, you can define a WHERE clause on a table in the
database in order to restrict access to specific rows, and limit the results
that can be returned by queries run by specific users or a group of users.
In this scenario, you want to restrict your sales representatives from
querying data concerning sales in 2003.
2 Click the Add button to create a rows restriction.
The New Row Restriction dialog box displays.

If you are sure of the table name and the Where clause statement, you
can type them directly in the text boxes. Otherwise, continue to step 3.
3 Click the» button to the right of the Table text box.
The Table Browser displays, listing all the database tables referenced in
this universe.
l@f:ig6LF..\.(:;g.~·~~ .
CLIENT
COLOUR
COUNTRY
COUNTRY_MAKER
COUNTRY_REGION
COUNTRY_SHOWROOM
EMPLOYEE
FINANCEYERIOD
FRANCHISE
MAKER
MANAGER
4 Scroll down the list and click the SALE table.

S Click OK.
6 In the New Row Restriction dialog box, click the » button to the right of
the Where Clause text box.
The Where Clause Definition dialog box displays.
I
'-../

7 Type the following WHERE clause in the text box (or build the Select
statement using the Tables, Columns, Operators and Functions
available) to restrict all data concerning the year 2003:
Year(SALE.SALE_DATE) = 2003
8 Click OK to close the Where Clause Definition dialog box.
The table and Where clause appear in the New Row Restriction dialog
box:.
9 Click OK to close the New Row Restriction dialog box.

10 In the Rows tab of the Edit Restriction dialog box, click the Check All
button to validate the restriction definition.

The status of the table and Where clause you created appears as "OK".
To map one table to another

1. In the Edit Restriction dialog box, click the Table Mapping tab.
The Table Mapping tab displays.
In this tab, you can specify that for a specific user or group of users, any
time a table is referenced by an object in this universe, the table should
be replaced by another table.
2 In the Table Mapping tab, click the Add button.
3 The New Table Mapping dialog box appears.
If you know the exact names of the tables, you can type them in the text
boxes. Otherwise, use the select button to select the original and
replacement tables.
When you have selected the tables, click the Check All button to validate
the status of the mapping settings.

To confirm the restriction set settings
When you have finished defining the restrictions for the new restriction set,
click the OK button in the Edit Restriction dialog box.
The Manage Access Restrictions dialog box appears and the restriction set
you just created, My Restriction, appears in the list.
Now you are ready to assign this restriction set to a user or group of users.
Applying a restriction set to users

You apply a restriction set to user groups defined for your BusinessObjects
Enterprise system. These users are defined in the Manage Groups and User
Accounts section of the BusinessObjects Central Management Console
(CMC). See the BusinessObjects Enterprise XI V2 Administrator's Guide for
information on setting up users and groups for the BusinessObjects system.
To apply a restriction set to users or a group of users:

1 In the Manage Access Restrictions dialog box, click the Add user or
group button located just below the Available groups and users zone.
The Select Users and Groups dialog box displays.

This dialog box allows you to select the user names and groups to whom
you are going to apply the restriction. You can search for names and
groups using the search functions shown in the bottom left-hand corner of
the dialog box.
In our scenario, you want to apply the restriction set we just created to all
the sales representatives in your organization. They are part of a user
group called "Sales".
2 Scroll down in the Available groups and users list until you see the Sales
group.
Note: Users are identified in this list with an icon representing a single
individual head; groups of users are identified with two individual
heads. In this organization, Sales Rep is an individual sales
representative, and he or she belongs to the group Sales.
3 Double-click the Sales group, OR click it and use the » button to move
the group into the Selected users and groups list.
4 Click OK to confirm and close the Select Users and Groups dialog box.
The Sales group appears in the Available groups and users list, in the
Manage Access Restrictions dialog box.
Note, however, the list shows that no restriction has been assigned to this
group yet. You will now assign the new restriction to the selected user
group.
In the Manage Access Restrictions dialog box, make sure that both the
My Restriction set and the Sales user group are selected.
Click the »Apply button.
The restriction set now appears in the list next to the name of the user
group.

Note: The default priority set for the restriction is '1'. The next section in
this unit describes how to set the restriction priorities.
7 Click OK to close the Manage Access Restrictions dialog box.
To test the restriction sets, log onto InfoView as Sales Rep, a user in the Sales
user group. Create a new Web Intelligence document using Motors2004.
Check to see that the Rental classes and objects do not appear in the list
of objects in the Edit Query view Data tab.
Note: You will see that the Rentals class and the Rental Details subclass
appear in the list of available objects, although no object is visible
in the subclass. This is because for the Rental Details subclass,
you applied a restriction on the Invoice ID Number object itself,
and not on the subclass, as you did for all the other subclasses.
Run a query using the Sale Year and Sales Revenue objects and see that
no data is returned only for 2003.

Setting restriction group priority
You can specify which restriction set to apply to a user that belongs to multiple
groups using a universe. For example a user belongs to two groups, Sales with
a restriction to view 5000 rows of data, and Marketing to view 10000 rows.
When the user refreshes a report, the restriction associated with the lowest
level group is applied. In the example above, if the Sales group had order 1
and Marketing had order 2, the restriction from marketing (10000) would be
used.
You can arrange user groups in order. The restriction for the lowest group in
the listed order is used.
Note: This only applies to exclusive restrictions such as connection, table
mapping, or SQL controls. If object restrictions are set on both groups,
they will ALL be applied.
To set user group priority for multiple restriction use:

1 In the Manage Access Restrictions dialog box, click a user or group in the
Available Groups and Users pane.
2 Click the Priority button.
The Set Group Priority box displays.
3 Select a user or group, and click the Move Up or Move Down buttons to
change the priority level.
4 Click OK.

Viewing user and group restrictions
You can view the restrictions applied to all user and groups.
To preview restrictions for a user or group

1 In the Manage Access Restrictions dialog box, click a user or group in the
Available Groups and Users pane.
2 Click the Preview button.
The Restriction Preview dialog box displays.
The Restriction Preview dialog box displays the settings you defined
when you created the restriction set. In our example, the dialog box
includes two tabs, Objects and Rows, which each correspond to the tabs
in the Edit Restriction dialog box you used to define the restriction
settings.
3 Click each tab to view the settings that you defined.
4 Click Close.
S Click OK to close the Manage Access Restrictions dialog box.
To view restrictions for all universe users and groups

1 From the Tools menu in Designer, click Preview Net Access
Restrictions.
The Preview Net Access Restrictions for users and groups dialog box
displays.
2 Scroll down the list of groups and users and click the Sales group.
3 Click the Preview button.
The same Restriction Preview dialog box displays, allowing you to view
the restrictions for the selected group.

Practice
Activity: Setting access restrictions
Objectives
Create a new restriction set
Apply the restriction set to a user group
Test the restriction set in Web Intelligence
any Instructions
'--" 431
25 will replace
6 This activity In the Motors2004 universe, create a restriction set called ManagersOnly,
7sets that restricts access to the Manager object.
Apply this restriction set to the Sales and Employees group.
Preview the restriction to check that it is correct.
Save and export the universe.
Log onto InfoView using the Hank HR user account.
Create a new document in Web Intelligence
Verify that:
the Employees class is visible.
the Staff object is available.
the Managers object is not visible.

Lesson summary
Review
Quiz: Securing Universes

1 True or false: Using Designer, you can authorize or restrict Web
Intelligence and Desktop Intelligences users from accessing a universe.
Answer:
False. Only BusinessObjects Enterprise system administrators can define
which universes users are authorized to access, and depending on the
rights defined for a user group, the administrator can also restrict viewing,
editing, deleting, and other actions in a universe.
Using Designer, you can define restrictions for those users who are
authorized to use a universe.
2 What are the six types of restrictions that can be included in a restriction
set?
Answer:
Connections
Query controls
SQL generation options
Object access
Row access
Alternative table access
Summary
lesson
Explain the levels of security available in BusinessObjects Enterprise to
objectives authorize or restrict access to data with universes
with the
learners to Describe the types of restrictions that can be applied to a universe
check that all Describe how restriction sets are managed by Designer
learners have Create a new restriction set
acquired the
required Apply a restriction set to a user or group of users
skills before Set restriction group priority
moving on to View user and group restrictions
the next
section.

Lesson 16
Managing Universes
In this lesson, you will learn how to manage universes. In deploying and
maintaining universes, you ensure that the end users in your organization have
access to the universes they need to build Web Intelligence reports.
Documenting universes
Deploying universes

Documenting universes
Introduction
As you build a universe that reflects the reporting needs of the end users in your
organization, you will probably want to document the progress of the universe
design project. You can use the print function in Designer to document the
universe as it is being built, as well as to communicate the components of the
universe to other universe designers after the project is complete.
Print lists of different universe components
Print details concerning each of the universe components
Printing universe details

It is possible to print information about the universe. You can include information
about the objects, conditions, hierarchies, tables, joins, and contexts. You can
also print the universe schema, showing the full graphical structure of the
universe.
This feature is useful for documenting the details of the different components that
make up the universe.
There are several reasons for documenting a universe:
As universe designer, you can take snapshots of the universe at various
points during its development to chart progress against project plans.
You can create a complete breakdown of the universe components on
paper, or in PDF format, for archiving after the design work is finished.
Other universe designers can use this documentation to quickly familiarize
themselves with the major components of a universe.
To select what to print

1 Select Options on the Tools menu.
2 Click the PrintlPDF tab.
The Print IPDF tab displays in the Tools dialog box. This tab is divided into
three sections, listing all the major components of a universe:
General section
List Components section
Full Description section

3 Select or clear the check dialog boxes so that the items you are interested
in are printed.
Note: It is recommended that you select all items except Graphical

Structure and then print in Portrait mode. Then select only Graphical
Structure, scale as required, and, if appropriate, change to
Landscape mode. Print again.
Note that the Scale settinggoverns the display of the tables in the
Structure pane.
To switch between Portrait and Landscape mode, select Page Setup
on the File menu.
4 Click OK to accept the settings.
The universe structure rarely fits one sheet of paper and often extends across
many sheets. To see where page breaks will occur, you can preview the page
layout.
To preview where page breaks will be inserted

1 Right-click anywhere in the background of the Structure window.
2 From the shortcut menu, select Page Breaks.
Horizontal and vertical red lines indicate where page breaks will occur when
the Structure is printed.
Note: The lines will alter in accordance with scale and print format.
To print the universe

1 Select Print from the File menu.
2 Select the printer and define the print properties as usual.
3 Click OK to print the universe structure.
Managing Universes-Instructor's Guide 16-3

Printing options: General section
The options in the left-hand side of the PrinUPDF tab (Options dialog box) allow
you to print overall statistics and general information about the universe you are
viewing.
Parameters Prints information and statistics about the universe

parameters.
Linked Universes Prints the name of any universe to which the active
universe is linked.
Graphical Structure Prints the universe schema.
Scale Sets the scale for printing the contents of the Structure
window. The scale is expressed as a percentage. By
default it is 100%. Other scale values in the Scale List
Box are 80%, 65% and 50%. Or, you can enter the
exact scale you require.
Printing options: List components section

In the middle section of the PrinUPDF tab, you can select the universe
components that you want to print. The names of each component are printed as
a list.

I
-.-/
)
-./ For example, if you choose to print a list of the contexts in this universe, the result
appears like this:
Context List
QUARTER_Ff-1:l;JRES
ANHJ.4i.,;..;:i="IGUR:::'S
RENTALS
M:CO£l.S
fRANCHISE
Printing options: Full description section

In the right-hand section of the PrintlPDF tab, you can choose to print full details
concerning the different universe components.
If you select the Contexts option in both the List Components section and the Full
Description section, the details of each context are printed after the list.
I
~
Canrexr List
Q;JA~TER FIGuRES
ANNUAL RGUHE&
RENTALS
MOO.E::..a
SALES
FR.t.,t·.jCH"SE
Conte-Xl
CQf!~ "'';:.!W1~:QliRRER FG'-iR:.-:S
M.oDEl.~JDEL PRTC.E~':v..~Ef!:5Jo,LES :?RICE RAW3-2:.FR!,cE RA..'\:Ct Mlti< <!fliis..<U..SS PRIG
E R~J.!GE.PR!C:'@: RANC-.E MAX - - - - -
OO')El.Snt,'E jQ;ST't'lE-:-SIT>_= ;;12.
MCOELM.t..K2.:f ;D=WAKER.~"'.KE~ I~
OOLiNTEY:CC1UNF?f ID=SHOW'RCC,MGO;J~ITRY :[}
M~><E'R.C.0Ut1;TRY ::;j;~ou:\:'TR"{ M,I.;!{ERCOUNiRy ![}
~t:C-D=U",,'\OOEl :JAYRENTbe:!>.>JeenRS'<1rAt.. PR!CE RANGE-RENT ;:AN·!2·:' r1.W-<,~mdRENTA
l P~jCE R~NGEBENT R"'f>.i>:3E~.1.;X - - --
r.i,~.~.,HT£.~ FfaU?£S_.Si-iOW'ROOf.1 ;D=3;-K;-:"l~HCQM.sH0NR.DOM:D
Q!JftRTER=RG'.jRESJ .•~Om=L_;~;~:<~ELMOD3..._::O -
CCr.!::Ht I%:f,1e:#-;"N1J:J.l. fiGURES

r.:.aUNTRY:C:OU~iRy 1!:=Si1Oj"v'ROOM.CO:J~f:~Rt ::D
M.M£;;:.u:.~UNTRY i~CO;.JmR~" MAKER.COUNTRy 1D
S?+CWROCM.8f4G'tlRGOM iG=A~TNUAl FGUREl1skm\RG0M >0
AN:NIJ&]IG:JRE5.MM<.ER-=,t:::=M.~.X:ER.~1&~8_1::: -
CCf!~sd: ~~"'1=:'REN1,.t1..S
8EGIQN.REGK>,,'\; ID=CU3..:T.REG-:ON ~D
M;XIEL.STilEJD--STYLE.3T{;';=.)} -
M-~:DEU,4AA.ER. K:t=M.l:.>r.:ER.!'..M.KER. I,;)
CQUNTRY REQJOO.:C:-OUNl"RY I'Q.=REGKo:N.CO;J:\:l'RY :'0
OOUNTF.Y f.:OUN1;:;;'{ ID=SHOWRC<DMCOUN"fRY ;{} -
t;:~"·C=:;:;I ,'"':-r':II~-,":"~Y;:~J'}; 1"-::'"j:)V "-U.K;::'::; ~nll$;:w'<' In
J ,
Managing Universes-instructor's Guide 16-5

Deploying universes
Introduction
After you have completed the universe, it should be rigorously tested by a small
team of expert users before it is distributed to the end-user population.
It is recommended that the universe is tested by a small group of other designers
and expert users independently to ensure that the universe functions correctly
and provides the reports required with accurate results.
When you have completed the design, build, and test phases in creating a new
universe, you are ready to make the universe available to Web Intelligence users
or other report designers. This is known as deploying the universe.
Understand how universes are deployed to other users
Understand how universes are secured
Export a universe to the repository
Import a universe from the repository
Understand how version control is managed
About deploying a universe

Deploying a universe is the action of making the universe available to Web
Intelligence users or other report designers. You deploy a universe by exporting
it to the repository.
You should only deploy a universe to Web Intelligence users after having
completed the design, build, and test phases.
How do other users access the universe?

To distribute a universe to other users, either for test purposes with other
Universe Designer users, or for deployment to the end-user population, you
export the universe to the repository and the Central Management Server (CMS).
When you export the universe, other Universe Designer users can use the Import
.command in Designer to open it. Team members can only import the universe if
it has previously been exported to the repository where it is stored in the CMS.
To test the universe by building Web Intelligence reports with it, an expert user
selects New Web Intelligence document in InfoView and selects the universe
from the list that is available to that user.

~)
~ J
What happens when you export a universe

To deploy the universe for other users, you need to export it.
)
'-../
You can only export a universe that is defined with a secured connection. If the
universe has been locked in the repository by another designer, you cannot
export it.
When you export a universe, three events occur:
On your local machine, the universe .unv file is transferred to the following
I location (or if it is already located there, the .unv is updated with the new
'-../
version):
\\Documents and Settings\<username>\Application
Data\Business Objects\BusinessObjects
11.0\universes\@<repository name>\universe
folder\<universe>.unv
where @<repos ito ry name> is the name of the repository the universe is
I being exported to.
'..../
The universe is also stored in the file system of the Input File Repository
Server (FRS), as a .unw file. This is an object that contains both metadata
'-../
J information for the universe and the link to the corresponding universe
version stored on the repository file system.
A new InfoObject is created in the Central Management Server (CMS). This
object can be managed through the Central Management Control (CMC).
From the Universe page in the CMC, a BusinessObjects Enterprise
~I administrator can change the universe name and description, move its
location, and define user access rights to the universe.
Each time the universe is exported to the CMS, the universe version in the FRS
is updated. This is the version that is available to Web Intelligence users.
Note: Saving a universe is not the same as exporting a universe. Saving
updates the universe on your local file system, but it does not save the
CMS repository version of the universe.
'-.-/}

'-" I
Universes in the local file system
As you work on creating or updating a universe, you work on your own local file
system on the machine where Designer is installed. When you save your
universe, you can save it in any folder you want.
However, after you export the universe to the repository, the universe is
transferred to the default location in your Documents and Settings. In this
example, the user designer1 has rights to the repository named @W2KS-L-
LV472.INTL.BUSINESSOBJECTS.COM. All universe folders for designer1 are
under that subfolder in that user's local file system.
beach
efashion
Motors
Motors2004
Staf2002
eFashion.unv
Island Resorts Marketing.unv
Motors2000.unv
Motors2004.unv
Staff2002.unv
LOV files are stored in a folder with the same name as the universe file at the
same level as the universe.
The universe is also stored on the CMS, so that other designers can import it,
and users can use it to create Web Intelligence reports.
When you import a universe from the CMS, the .unw file stored in the FRS file
system and the CMS InfoObject is converted to a .unv file and transferred to the
local machine in the same folder shown above.
How are universes secured?

There are several security methods available to ensure that only authorized
users are allowed to access the universe, either to update the universe itself or
to actually build reports using the universe and Web Intelligence.
From Universe Designer, you can apply a password to the .unv file itself.
In the BusinessObjects Central Management Console (CMC), the
administrator can give users the right to:
Import the universe files as universe designers.
Create reports using the universe as end users.
Note: As a universe designer, you can also apply a restriction set to a
selected group or user account for a universe.
16-8 Universe Design-instructor's Guide'

To set password protection on the .unv file
1 Select Options from the Tools menu.
Click the Save tab:
2 Click the Protection Password dialog box and type a password.

Users who access the universe using this password now have read-only
access.
3 Click the Write Reservation Password dialog box and type a password.
Users who access the universe using this password have read and write
access. This is only appropriate for users who have access to Universe
Designer.
4 Click OK.

Exporting a universe
To deploy the universe so that other users can test it or use it to build Web
Intelligence reports, you export the universe to the CMS.
To export a universe to the CMS

1 Select Export on the File menu.
The Export Universe dialog box appears.
2 Select a folder from the drop-down list dialog box where you want to export
the universe.
OR
Click the Browse button and select a folder in the folder browser.
16-1 0 Universe Design-instructor's Guide

3 Click a group in the Groups list dialog box.
This is the user group that will be allowed to use the exported universe to
create Web Intelligence documents. The groups proposed in the list dialog
box are the groups in which the universe designer is a member.
4 Click a universe in the Universes list dialog box.
The Universes list dialog box shows the names of the active universes.
5 If you want to export other universes that are not open, click the Add
Universe button, and then use the browser to select the other universes.
6 Click OK.
The universe is exported and the updated version in your local file system is
synchronized with an updated version of the universe in the CMS.
Importing a universe
As a Universe Designer user, you can import one or more universes stored in the
CMS repository.
When you import a universe, the CMS checks the universe version on the
repository file system. If the version is identical, the universe is made available
to you if you are defined as a Universe Designer user in the CMC and you have
the right to access this universe.
If the universe version on the local file system is more recent than the CMS
version, a message dialog box appears asking if you want to replace the
universe in the folder. If you answer Yes, then the universe on the local file
system is replaced by the version in the CMS.
When you import a universe from the CMS, the .unw file stored in the FRS file
system and the CMS InfoObject are converted to a .unv file and transferred to
the local machine in the following location:
\\Documents and Settings\<username>\Application
11.O\universes\@<repository name>\universe
folder\<universe>.unv
where @<repos ito ry name> is the name of the repository the universe is
being imported from.
You can only import a universe that has already been exported to the repository.

To import a universe from the CMS
1 Select Import from the File menu.
The Import Universe dialog box displays.
l,sland Resorts Marketing

Motors2000
Motors2004
S!aff2002
2 Select a universe folder from the drop-down list dialog box.

OR
Click the Browse button and select a universe using the folder browser.
This is the folder used to store universes in the CMS.
3 Click a universe name.
This is the universe that you want to import.
4 Verify the file path for the import folder in the Import Folder field.
This is the folder to which the universe will be copied.
5 Click OK.

Working with multiple designers
You can use Designer in a multiple-user environment in which several designers
can work on the same universes without causing conflicts between versions.
Each time you export a universe, it is assigned a revision number to keep track
of changes. You can also lock a universe so that only one designer at a time can
make modifications on the universe.
Understanding version control

Each time you export a universe to the CMS repository, Designer increments the
revision number of the universe. By looking at the universe file's revision number,
you can determine the latest version of the universe.
To view the universe revision number:
1 In Designer, select Universe Parameters from the File menu.
2 Click the Summary tab.
The Summary tab displays. The Revision number appears in the header
section at the top of the tab:
When you export the universe, the CMS version will always be updated, even if
there are no real changes.
If you try to export a new universe with the same name as an existing universe,
Designer displays a message asking you if you want to:
Update the existing universe with the new universe. Specifically, replace
the contents but keep the ID and all security.
Replace the existing universe, which is equivalent to deleting the
universe and exporting a new one.
Cancel, so that you can rename the universe and export it as a different
universe.

Locking a universe
After a universe has been exported to the repository, it can be shared by several
designers provided that they have the necessary user rights.
Only one designer can work on a given universe at a time. A designer who wants
to work on a universe can do so only if the universe has not been locked by
another designer.
To lock or unlock a universe

1 Select Import or Export on the File menu, depending on whether you are
importing a universe from the repository or exporting it to the repository.
The Import Universe or Export Universe dialog box displays.
2 Double-click the universe file name in the list dialog box to lock the universe
before importing or exporting.
A padlock icon appears beside the universe file name to indicate that the
universe has been locked.
3 To unlock a universe, double-click the file name again.

Introduction
After you have completed the universe and then deployed it to the end-user
population in your organization for report creation, you must maintain the
universe to ensure that it continues to function correctly and provide the reports
with accurate results.

Understand the importance of universe maintenance
Understand how changes to the target database can impact a universe
List which changes have minimal effect on existing end-user reports and
which changes can have greater impact
Reasons for universe maintenance

There are three reasons that you may need to distribute a new version of a
universe to end users. These are:
Changes in the structure of the target database to which the universe is

connected
Change requests from end users
Changes made by the universe designer to expand the universe or
enhance the efficiency of the inferred SQL
Your primary concern when introducing a new version of a universe should be

what effect it will have on existing end-user reports that are refreshed regularly
(as opposed to one-off reports). Testing should be as rigorous as if you were
distributing a completely new universe.
You should treat distributing new versions of a universe as you would any
software update. Distribute new versions in a controlled and regulated fashion.
Changes to the target database

Changes to the underlying database will impact end-user reports to varying
degrees, according to the type of changes that have been made.
Greater
Changingimpact
Renaming/moving
existing column
database
and table names
Minimal Impact
Adding new
Adding new columns
tables Deleting tables and columns

The implications of these changes are:
Additions to the target database
Adding new tables or columns to the database does not impact the reports
that are already created and refreshed regularly by end users. However,
you might want to extend the universe to cover the data in these tables.
Renaming or moving a database
To resolve this situation, you must edit the middleware driver.
Changing the existing table and column names of the target database
This type of change to a database requires some work by the universe
designer, but the situation is retrievable without the user noticing any
difference when they refresh existing reports.
In the case of a table name change, you must reinsert the table in the
structure of the universe as if you were adding a new table, and then edit all
the objects that referred to the original table.
In the case of a column name change, you only need to edit all the objects
that referred to the original column.
In both instances, the Refresh Structure and View Associated Objects
functions are useful. The procedure for invoking these functions is set out
below. Don't forget the Check Integrity function. This is extremely useful in
determining errors.
Deleting existing tables or columns from the target database
This type of change to a database causes problems which are far more
difficult for the universe designer to resolve. More importantly, the situation
is unlikely to be retrievable without the user noticing any difference. Any
report that contains an object that refers to the deleted table or column will
produce an error when refreshed.
Where a column is deleted, you must remove all objects that relate to that
column or alter them so that they do not refer to it.
Where a table or a join column is deleted, you must edit the structure also.
Again, in both instances, the Refresh Structure, View Associated Objects
functions, and Integrity Check are useful.
Detecting changes to the universe

Whenever changes to the database are made, such as columns or tables being
deleted, you need to assess the impact this has had on the universe.
To assess the impact of changes on the universe

1 Select Refresh Structure on the View menu.
Designer updates the Structure window, based on the changes made to the
database. The affected tables are highlighted. Various messages can be
displayed, depending on the changes that have been made.
2 Update the universe as necessary to reflect the changes in the database
structure.

Detecting changes to objects
Changes to the underlying target database can require you to modify the
universe objects as well.
To detect which objects have been affected by the changes

1 Right-click the table header in the Structure of the universe window and
click View associated objects on the shortcut menu.
Objects that are affected by changes to the table are highlighted in the
Objects and Classes window.
2 Check the properties of each object and redefine them to reflect the
changes to the table.
Note: If a table is deleted from the database, then it is no longer possible to
use this process to view the objects that are affected by the change.
If possible, plan the change and view the associated objects for a
table before you delete it.
Alternatively, select Check Integrity on the Tools menu to identify the errors
caused by the changes to the structure.

Adding new tables to an existing universe
If new tables or views are added to the underlying database, you may want to
add them to the universe as well.
As soon as new tables or views are added, they appear in the Table Browser and,
you can add them to the universe structure.
It is important that you follow the workflow illustrated below when you insert new
tables in an existing universe. As an alternative to deleting and re-detecting
contexts you may want to edit the existing ones.
•
Add tables to the univers e structure
Instrt joins and set cardinalities
••
•
D e1ete existing c ontfZls
Detect alias es
••
Detect contexts
••
Create na.v objects
I.
Setup hierarchies
See Lesson 8 Resolving SQL Traps for details on how to determine what joins
make up a context.
Adding new columns

If new columns have been added to tables in the database, Designer adds them
automatically to the tables in the Structure window when you refresh the
structure.
The effect of changing objects

If the underlying database changes, the implications of the changes that you
have to make on objects in the universe and the impact of these changes on
existing reports vary:
the exactand
Changing
Deleting
Greater same
an then
impact definition
existing
existing
recreating
column
object and
antable
object
names
with
ent class toMinimal
a differentImpact
class
Renaming
Copying
Redefining an
Moving inanthe
an object
object
same toclass
object'sa SQL
differ-
or Adding new objects

When you change an object's properties, there is little impact on the end user.
For example, if you:
Redefine object SQL, there is no noticeable effect on the end user. When a
user refreshes or makes a query, the universe is re-imported automatically
if the system detects a difference in the flags for the .unv file on the CMS.
Because this is done in the background, it is a very fast process and as a
consequence, the users will not realize that this is occurring.
Rename an object, this does not affect the data in existing reports when
refreshed. The only difference end users might notice is that the column
header in a tabular report changes as this is based on the object name.
This does not affect the refreshing of a report because the object is
identified by an object ID number and not its name.
Move an object from one class to another, it does not cause any problems
with the refreshing of existing reports. However, remember that it can have
a bearing on default hierarchies.
Copy and add objects, it has no bearing on existing reports because they
are new to the universe and therefore could not be part of any existing
report.
The only change you can make to the objects of a universe that has a major
effect on existing reports is to delete an object. When the report is refreshed an
error will occur.

Practice
Activity: Managing universes
Objectives
Locate the universe in the repository file server.
View the universe in the Central Management Console.
Instructions
1 In the Motors2004 universe you have been building in this course, set the
print options to print the list of tables referenced in the universe and details
of the columns in each table.
2 Export the universe to a new folder in the universe folder, called Motors.
3 Using Windows Explorer, verify the location of the exported universe.
4 Launch the BusinessObjects Enterprise Administration Launchpad and log
into the Central Management Console, using the user name Administrator,
no password.
5 Verify that the new universe folder has been created and that Motors2004 is
listed in that folder.
6 From the Administration Launchpad, log into InfoView and create a new
Web Intelligence document to verify that the new universe is available to
end users.

Lesson Summary
Review
Quiz: Managing Universes

7 Why would you decide to print details about the universe components?
Answer:
To track progress against project plans during universe development and
test phases
To archive after the design work is finished
To communicate the components of the universe to other designers
8 When you export a universe, where is the .unv file stored on your local
machine?
Answer:
By default, in the \Documents and Settings\<username>\Application
11.5\Universes\@<server_name>\universe_name\
9 True/False The universe file's revision number allows you to determine if
you are working with the latest version of the file.
Answer:
True
10 To ensure that you are the only universe designer that can modify a
universe, you can:
Ask your BusinessObjects Enterprise administrator to restrict access to
that universe
Lock the universe when you export it to or import it from the repository.
Set restrictions on elements in the universe.
Answer:
Lock the universe when you export it to or import it from the repository.
11 Which changes to the underlying target database can greatly impact
existing reports when they are refreshed:
Adding new tables or columns to the database
Answer:

Summary
lesson
Print lists of different universe components
objectives
with the Print details concerning each of the universe components
learners to Understand how universes are deployed to other users
check that all Understand how universes are secured
learners have
acquired the Export a universe to the repository
required Import a universe from the repository
skills before
Understand how version control is managed
moving on to
the next Understand the importance of universe maintenance
section. Understand how changes to the target database can impact a universe
List which changes have minimal effect on existing end-user reports and
which changes can have greater impact

Lesson 17
Creating Universes from Metadata
Using Designer, you can create a universe from a metadata source, such as XML
files or Oracle Analytic Workspaces.
Creating a universe from an XML metadata file
17-1
Copyright © 2005 Business Objects. All rights reserved.
Creating a universe from an XML metadata file
Introduction
You can use Designer to create a universe from a metadata source. Once the
universe has been created it can be exported to the Central Management
System (CMS) as any other universe, and is then available to Web Intelligence
and Desktop Intelligence users to run queries and create reports.
Note: The Metadata Exchange is also available in stand-alone mode with
BusinessObjects XI release2. You can create a universe from a
metadata source from within Designer, or by starting the Universe
Builder from the Windows Programs Start bar and selecting Universe
Builder in the Business Objects group of products.
List the metadata sources you can use to create a universe
Describe the Metadata Exchange panel functions
Create a new universe from an XML metadata file
Which metadata sources are supported?

You can create universes from the following metadata sources:
XML metadata sources:
Common Warehouse Model (CWM Relational 1.0)
Common Warehouse Model OLAP (CWM OLAP)
Oracle Warehouse Builder (Oracle WB)
Data Integrator
IBM DB2 Data Warehouse Center (IBM DB2 DWC)
IBM DB2 Cube Views
Oracle Analytic Works paces (Oracle OLAP)
This lesson will present creating universes from the Common Warehouse
Model XML metadata source .
• I

Working in the Metadata Exchange panel
In order to build a universe from a metadata source, you use a panel in
Designer called the Metadata Exchange panel. You access this panel by
selecting the Metadata Exchange option from the File menu in Designer.
Select an option a.nda~ormat; then c1ick.Qk to start.
it}] €! Create a universe from:
C Update a universe from:
-i~! ("J - Expmt a universe to:
In the Metadata Exchange panel, you can:

Select the metadata source format to build the universe.
This is the source XML file or database view that you use to build a
universe. A universe creation wizard takes you through steps to select a
connection for the metadata source, selecting the metadata components
that you want to be mapped to the universe, and finally the generation of
the universe.
Update an existing universe with data from a metadata source that has
been updated.
This is the metadata source that has been used to create a universe. The
source has been updated, and now you want to update the universe with
the same modification. A universe update wizard takes you through the
steps needed to update the universe.
Export a universe to a metadata format.
You select a metadata format to which you can export a universe. For
example, you can select the DB2CV XML standard, then save a universe
in that format.
Creating Universes from Metadata-Instructor's Guide 17-3

Creating a univers~ from metadata
The Metadata Exchange wizard takes you through a three-step process to
create the universe:
Specify the location of the metadata file
Select the tables you want to include in the universe
Define the connection to the original data source
To select the metadata file:

1 From the File menu in Designer, select Metadata Exchange.
The Metadata Exchange panel displays.
2 In the Metadata Exchange panel, click the drop-down arrow next to the
Create a universe from drop-down list.
3 Select the CWM 1.0 Metadata format.
4 Click OK.
The CWM Relational Universe Builder wizard appears.
5 Click Next to continue.
6 In the Universe Creation Step 1 wizard page, browse to the location of
your XML metadata file.
In this example, we will build a universe from the sample_cwm_10.xml
file located on the course Resource CD.
Universe creation - Step 1J5

Select a Xml source file, then click Finish.

The Universe Creation Step 2 wizard page displays:.
Universe .creation - SteP 2J5

Choose database to build universe and then click Next to -continue.
: Database1
To specify the tables to include in the universe:

1 Select Database1 to highlight it and click Next.
The Universe Creation Step 3 wizard page displays.
Universe creatioo - Step 315

Select elements to build universe and then click Next to continue.
1i t; DB20LAP
!j;' ffij FACT
;:ii' ~ TIME_PERIOD
c11 &ill PROMOTION
[*, ~ PRODUCT .
", &ill PRODUCT_CLASS
lfJ ffij CUSTOMER
,£ ~ CHANNEL
This wizard page displays all the tables and columns in this metadata file.
2 Click the + next to the PRODUCT table to view the columns in this table.

The PRODUCT table expands and shows the columns.
Universe cieation - steP 3J5

."SeJectelements to build universe and then click Nextto continue.
~
d t: DB20LAP
tii llii FACT
if!. iliJ TlMCPERlOD
IIi ffij PROMOTION
S iliJ PRODUCT
~PRODUCT
ff1j PRODUCT
lliJ BRAND 2N
PRODUCT
You can select individual tables or columns in the list and use the <
button to move them individually into the list in the right-hand side of the
wizard box.
Or you can use the « button to move all the contents of the file at once.
3 Click the» button.
All the tables are moved into the list on the right-hand side of the wizard
page.
The Universe Creation Step 4 wizard page displays.
Universe creation - Step 4J5

Select elements to· build universe-and then click Nelo:t to continue.
~
)
To specify the connection to the data source:

The Universe Create Step 4 wizard page allows you to select the connection
the universe will use to connect to the data source. For the purposes of this
course, you will not actually connect the universe to a data source, so it is not
important which connection is selected here.
1 Type a name for the new universe in the Universe name text box.
The universe name must be eight characters or less. In this scenario,
type MetaUniv.
2 Select the Advanced button.

The Options dialog box displays.
In the General tab of the Options dialog box, you can specify the location
where trace files can be stored.
3 Click the File Locations tab.
/
../ '-/
iI,
4
'-/
'--./
'-../
'---"
I
The File Locations tab allows you to specify default locations for storing
the source XML files and the parameter files associated with the
metadata.
The default locations are currently set in the BusinessObjects Enterprise
11.5 installation folder.
Click OK to close the Options dialog box.
The Universe Creation Step 5 wizard page appears.
Universe creation· Step 5J5

. S elect elements to build universe and then click Finish to continue.
'-/ I
~\
This page summarizes the connection and file information that will be
used to create the universe.
S Click Finish.
The universe displays with classes, objects and joins automatically
defined:.
Note: You cannot actually check the integrity of this universe, or export
the universe to the CMS, because you have not defined a
connection to the original data source.
6 Save the universe and close Designer.

'-" )
Practice
'-" I
Activity: Creating universes from metadata
Objectives
At the end of this activity, you will be able to:
J Create a universe from an XML database file.
J
Instructions
1 Locate the sample XML files on the course Resource CD.
2 Copy the XML files to a folder on your workstation.
3 Open the Metadata Exchange panel in Designer.
4 Select the Data Integrator format in the Create a universe from drop-
down list.
5 Specify the sample_dLxml file as the source file.
6 Create a new universe called Dluniv.
'-"'I
'-" I

Lesson summary
Review
Quiz: Creating Universes from Metadata

1 What three tasks can you perform in the Metadata Exchange panel?
Answer:
Create a new universe from a metadata file.
Update an existing universe when the metadata has been updated.
Export a universe to a metadata format.
Summary
lesson
List the metadata sources you can use to create a universe
objectives
with the Describe the Metadata Exchange panel functions
learners to Create a new universe from an XML metadata file
check that all
learners have
acquired the
required
skills before
moving on to
the next
section.

Appendix A
End of Course Challenge
In this workshop you will edit and expand the Staff2004 universe so that:
Prestige Motors management and personnel can run reports on number of
employees, absences and salaries by country, showroom department, job type,
date and employee. Salaries should also be able to be reported on by financial
year, quarter, month and date.11 hour and 30 minutes
Copyright © 2005 Business Objects. All rights reserved. A-1

The Challenge
Modify the Staff 2004 universe to satisfy the following:
The management of Prestige Motors requires this universe to be capable of
producing ad-hoc reports of:
General employee information - including Job, Showroom and
Department
Salary information for all employees
Absence information for all employees
Complete the exercise

1 Open the Staf2004.unv and complete the universe structure by:
Inserting aliases as required (This may be required even if not
detected. )
Inserting self-restricting joins as required
Detecting contexts
Note: Do these things in the order presented.
2 Create the following classes:
Salaries
Absences
3 Create the following dimension objects in classes as you deem relevant:
Country
Showroom
~)
Department
Job Title
Salary Item (a description)
Financial Year (for Salary analysis only)
Financial Quarter (for Salary analysis only)
Financial Month (for Salary analysis only)
Date of Payment - no LOV, formatted to dd/mm/yyyy
Start of Absence - no LOV, formatted to dd/mm/yyyy
Duration of Absence (including weekends)

Reason for Absence
4 Create the following measure objects in classes as you deem relevant:
Salary Cost (based on the SALARIES table) - formatted as currency
Number of Employees - formatted with no decimal places
Absence Days - formatted with no decimal places
5 Set up 2 custom hierarchies: one for geographic drilling, the other for time
based on a financial year.
6 Check the following objects:
Ensure that the Manager detail object produces a list of line
managers only when reported on and lists all managers from that
table.
Ensure the Country object does indeed produce a list of countries the
showrooms are in.
A-2 Universe Design-Instructor's Guide

I
'-../
7 Check integrity, save the universe and test it by creating the following
reports. Save each one when it has run successfully.
A Salary Cost Report broken down by financial year and country on
which you can drill down to showroom from country and quarter and
month from year.
A list of absences detailing the employee, job title, showroom, date of
absence, duration of absence and reason for absence. Order by the
reason for absence.
A summary of the salary costs and absences per showroom.
S Insert the ANNUAL_SALARY table and apply aggregate awareness.
9 Check integrity, save the universe and re-test it for aggregate awareness
by:
Viewing the inferred SOL for the existing Salary Cost Report
Editing the query by removing the Month object, viewing the SOL
and then running it
10 Once you have completed the workshop show the instructor your results.
End of Course Challenge-Instructor's Guide A-3

'"'
\
."
'"'
I
.;...
A-4 Universe Design-instructor's Guide

Notes
l..
'--.-1
'-./ )
J,
_____
I
./
(~'O~ t"I~+h~ q~" (c;) ; lI1. t~ /'VJ C'd'V1
(,9,'1{9 1/10.-\-t-. \\ojj'c. p" e Y01 ~y·"O' C'r.IrI\
t -<i ') 0, p, h~ C\{, @ 3-''Mrv "; (. <::.Dm,
e e.,rd;\\0~C/'(\ f=t><1CI:I,,{(\ tC ~ 1\_ \ \5')-

I
,
(.r i I;: )'l!J f': t "".Ir:~i'1 .•i
('"IIIf v':J ",.,.\
f" I).,> '", 1\1
~'J".,'t' ~'J 1c-\ ;~~
~'" ~'o.)
!
p, ~Jif)( Jl"'-,;j
t, t'\ 'r-"~ ../ ()i-'U
~,AiA\ ~ i- A
'\.-
usl o
Training Evaluation
We continuously strive to provide high quality trainers and training guides. To do this, we rely on your feedback.
We appreciate you taking the time to complete this evaluation.
Position: _
Name: _
Company: _~ _
Email: _
Phone: _
Course Information
Date: _ Course: _
Instructor's Name: "--------------------------------------

Location of Training: _
How would you rate the following? Excellent 0Average

0Good
Poor
0
Did the course content
0 needs?
meet your 0
Were the training materials clear and easy to understand?
Was the Learner's Guide complete and accurate?
Were there enough hands-on activities?
Did the instructor have strong presentation skills?
Did the instructor have a technical understanding of the

product?
Was the instructor attentive to the class level, adjusting the

lessons accordingly?
Was the training facility properly equipped?
How would you rate the course overall?

What did you enjoy most about the course?
""
j
What did you enjoy least about the course? ~
J
~I
/
r"\!
Comment on this training guide's completeness, accuracy, organization, usability, and readability.
~.i
How did you find out about the training class?
")
~\
/
~.
)
~.
What changes, if any, would you like to recommend regarding this session? I
~
/ J
~
i
/".
)
r"\
/
")
)
~/
).

DM 310 Ig

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DM 310 Ig

Caricato da

Copyright:

Formati disponibili

l

Business Objects, the Business Objects logo, Crystal Reports, and

Copyright © 2005 Business Objects. All rights reserved. iii I

Defining universe parameters 2-5

Strategies tab 2-15

Organizing your tables 3-7

iv Universe Design-instructor's Guide

Table of Contents-instructor's Guide v

How Designer deals with loops 7-4

Inserting an alias manually 7-9

vi Universe Design-instructor's Guide

Table of Contents-Instructor's Guide vii

viii Universe Design-instructor's Guide

Table of Contents-instructor's Guide ix

x Universe Design-Instructor's Guide

Understanding BusinessObjects Universes 30 minutes

Creating the Course Universe 45 minutes

Building the Universe Structure 1 hour

Creating Measure Objects 30 minutes

Copyright © 2005 Business Objects. All rights reserved. xi

xiiUniverse Design-instructor's Guide

Agenda-instructor's Guide xiii

Copyright © 2005 Business Objects. All rights reserved. xv

xvi Universe Design-instructor's Guide

Training facility setup

About this Course-Instructor's Guide xvii

xviii Universe Design-Instructor's Guide

About this Course-instructor's Guide xix

Duration: approximately two and a half hours per machine

Recommendation for Business Objects training customer

Copyright © 2005 Business Objects. All rights reserved. xxi

The software required for this course is:

xxii Universe Design-instructor's Guide

To install required software

Facilities Setup-instructor's Guide xxiii

Before class begins

The third universe, eFashion is installed by the Enterprise Setup program to

To create an ODBC connection:

xxiv Universe Design-instructor's Guide

Start here if an eFashion ODBC connection already exists.

Start here if a new eFashion ODBC connection is required.

After creating I verifying the eFashion ODBC connection, continue to

To define the connection in the universe

Facilities Setup-Instructor's Guide xxv

xxvi Universe Design-instructor's Guide

23 Click OK. The integrity check runs.

25 Click OK to close the window.

Facilities Setup-Instructor's Guide xxvii

Testing the hardware and software setup

1 Click Start> Programs> BusinessObjects XI Release 2>

Verify eFashion universe is available.

4 Verify that eFashion is listed as an available universe.

xxviii Universe Design-Instructor's Guide

9 Click Run Query.

10 Close the document without saving (click X in top right corner).

Verify sample Web Intelligence document is available.

13 Click Web Intelligence Sample to open the report.

Facilities Setup-Instructor's Guide xxix

14 Close the report without saving.

Creating users and user groups in the CMS

To create users in the CMS

xxx Universe Design-instructor's Guide