1: Universe
Design
Learners Guide
BOU310
Copyright
C O N T E N T S
About this Course
Course introduction..................................................................................................xvii
Course description...................................................................................................xviii
Course audience.......................................................................................................xviii
Prerequisites..............................................................................................................xviii
Level, delivery, and duration...................................................................................xix
Applicable certifications and designations.............................................................xix
Course success factors................................................................................................xix
Course setup................................................................................................................xix
Course materials.........................................................................................................xix
Learning process..........................................................................................................xx
Lesson 1
iii
Lesson 2
Lesson 3
iv
Lesson 4
Lesson 5
Lesson 6
vi
Lesson 7
vii
Lesson 8
Lesson 9
Lesson 10
Using Hierarchies
Lesson introduction...................................................................................................235
Understanding hierarchies and universes ............................................................236
Hierarchies..........................................................................................................236
Working with hierarchies ........................................................................................238
Default hierarchies ............................................................................................238
Custom hierarchies............................................................................................241
The effect of custom hierarchies on default hierarchies ..............................242
Time hierarchies ................................................................................................244
Testing automatic time hierarchies .................................................................247
Advantages and disadvantages of automatic time hierarchies ..................248
viii
Lesson 11
Lesson 12
ix
Lesson 13
Linking Universes
Lesson introduction...................................................................................................287
Understanding linked universes ............................................................................288
What are linked universes?...............................................................................288
Using linked universes......................................................................................288
Possible linking strategies ................................................................................289
Advantages and limitations to linking............................................................291
Creating links between universes............................................................................292
Linking universes ..............................................................................................292
Including one universe within another...........................................................294
When to link and when to include?.................................................................295
Activity: Linking universes ..............................................................................296
Quiz: Linking universes............................................................................................298
Lesson summary........................................................................................................299
Lesson 14
Lesson 15
Managing Universes
Lesson introduction...................................................................................................325
Documenting universes ...........................................................................................326
Printing universe details...................................................................................326
Printing options: General..................................................................................328
Printing options: List Components..................................................................328
Printing options: Full Description...................................................................329
Deploying universes..................................................................................................330
About deploying a universe ............................................................................330
What happens when you export a universe?.................................................330
Importing a universe.........................................................................................334
Working with multiple designers....................................................................335
Appendix A
End-of-Course Challenge
Completing the end-of-course challenge...............................................................351
Customer scenario.....................................................................................................352
Activity: Completing the end-of-course challenge - part 1..................................353
Activity: Completing the end-of-course challenge - part 2..................................354
Appendix B
Appendix C
Answer Key
Quiz: Understanding BusinessObjects universes.................................................371
Quiz: Creating the course universe.........................................................................372
Quiz: Building the universe structure....................................................................373
xi
xii
Universe Design
Introductions, Course Overview...........................................30 minutes
Lesson 1
AgendaLearners Guide
xiii
Lesson 7
xiv
Lesson 15
Documenting universes
Deploying universes
Maintaining universes
Deploying universes in multiple languages
AgendaLearners Guide
xv
xvi
xvii
Course description
This core three-day instructor-led course is designed to give you the comprehensive skills
needed to design, build and maintain BusinessObjects 6.5, BusinessObjects XI R1/R2, and
BusinessObjects XI 3.0/3.1 universes.
You should attend this course to understand universe design concepts and terminology, as
well as the role of universes in relation to BusinessObjects reporting tools. The course provides
an overview of the process for planning, designing and creating a universe and then walks you
through the process of designing a universe that responds to identified requirements.
The business benefit of this course is that you learn best-practice methodology for creating
universes that respond to your reporting requirements. Through well-designed universes,
report designers and business users are able to create reports without having to know anything
about the underlying data source or structure.
Course audience
This course is designed to teach you how to design BusinessObjects universes using Universe
Designer; using BusinessObjects 6.5, BusinessObjects XI R1/R2, or BusinessObjects XI 3.0/3.1.
New features covered in the XI 3.0/3.1 course that are not applicable to BusinessObjects 6.5 or
XI R1/R2 learners include:
Creating a cascading list of values associated with a hierarchy of objects in a universe
Creating delegated measures
Creating nested derived tables
Using Translation Manager
Testing universe results in Web Intelligence Rich Client
The target audience for this course is anyone responsible for creating and designing universes
using Universe Designer, using BusinessObjects XI 3.0/3.1.
Prerequisites
If you want to learn BusinessObjects Web Intelligence Rich Client reporting skills and concepts,
this course is recommended:
BusinessObjects Web Intelligence XI 3.0/3.1: Report Design
If you want to increase your skill level and knowledge of BusinessObjects Web Intelligence
XI reporting skills and concepts, this course is recommended:
BusinessObjects Web Intelligence XI R2: Report Design
To be successful, you must have working knowledge of:
SQL and relational database management systems concepts and structures
Familiarity with the type of data and the logical structure of the databases in their
organization
Familiarity with BusinessObjects Web Intelligence report building
xviii
Course setup
Refer to the setup guide for details on hardware, software, and course-specific requirements.
Course materials
The materials included with the course materials are:
Name card
Learners Guide
The Learners Guide contains an agenda, learner materials, and practice activities.
The Learners 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.
Evaluation form
At the conclusion of this course, you will receive an electronic feedback form as part of our
evaluation process. Provide feedback on the course content, instructor, and facility. Your
comments will assist us to improve future courses.
Additional resources include:
Sample files
The sample files can include required files for the course activities and/or supplemental
content to the training guide.
Online Help
Retrieve information and find answers to questions using the online Help and/or users
guide that are included with the product.
xix
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.
Introduction
Why am I here? Whats 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.
xx
Lesson 1
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 information is stored.
For the ease of the end user, universes are made up of objects and classes that map to data in
the database, using everyday terms that describe their 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.
End users select the universe they are authorized to access in order to build queries in Web
Intelligence, Web Intelligence Rich Client, and/or other BusinessObjects reporting tools. 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 data structures in the database.
Star Schemas
The star schema is the simplest data warehouse schema. It is called a star schema because the
diagram resembles a star, with points radiating from a center. The center of the star consists
of one or more fact tables and the points of the star are the dimension tables.
A star schema consists of fact tables and dimension tables:
Fact tables: A fact table typically has two types of columns: numeric facts and foreign keys
to dimension tables. Facts can become measure objects in a BusinessObjects universe file.
Dimension tables: Dimension tables contain the qualitative descriptions that can be applied
to the facts. Hierarchies may also be built into dimension tables. Dimension table data can
become dimension or detail objects in a BusinessObjects universe file.
Snowflake schemas
The snowflake schema is a variation of the star schema used in a data warehouse. It is more
complex than the star schema because the tables which describe the dimensions are normalized.
Data modeling
The traditional entity relationship (ER) model uses a normalized approach to database design.
Database normalization is a technique for designing relational database tables to minimize
duplication of information and to avoid data anomalies. Higher degrees of normalization
typically involve more tables and create the need for a larger number of joins, which can reduce
performance.
Denormalization is the process of taking a normalized database and modifying table structures
to optimize the performance by keeping a minimum relationship between tables; one dimension
table versus one fact table. Another method is to use prebuilt summarized data in the schema.
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 subclasses.
Objects
An object is a named component that maps to data or derived data in the database. The name
of an object should be drawn from the business vocabulary of the targeted 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 allows you to create a universe in 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 locally.
A universe is available to end users once it has been exported to the repository. Importing a
universe, making changes, then exporting the updated universe to the repository is the most
common way of working with Universe Designer.
Note: You can save a universe to the file system. You do this when you are in 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 importing it from or exporting it to the Business
Objects repository for maintenance.
Login information
Description
System
User Name
Password
Authentication
Authentication method
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 Universe 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.
Note: You can also import a universe by clicking the Browse button to select the universe
folder location you would like to import from.
3. Click the universe name that you want to import.
This is the universe that you want to import.
Note: If you want to lock the universe, double-click the universe name. A locked universe
appears with a padlock symbol. Locking a universe prevents other designers from importing
or exporting this universe. The locked universe can still be read by users and other designers.
To unlock a universe, double-click it again.
4. Verify the file path for the import folder in the Import Folder box.
This location is where the universes are exported.
5. Click OK.
Menu options
You can perform most tasks by choosing options from the menu. The Universe Designer menu
bar looks like this:
Toolbar buttons
The toolbar gives you quick access to many tasks. Universe Designer has three toolbars: the
Standard toolbar, the Editing toolbar, and the Formula Bar toolbar.
Right-click menus
Right-click menus display on your screen when you click the right mouse button. These menus
usually give you access to options related to the task you are currently performing. For example,
if you right-click in the Universe pane, a drop-down menu for creating classes and objects is
displayed:
Zoom
Often it is not possible to view the entire schema at normal magnification due to its size. Zoom
in or out using the drop-down list on the toolbar to choose your percentage view for the schema.
Arrange tables
You can select this button to have Universe Designer automatically organize your tables
sequentially and horizontally.
Note: You can undo only the last command. If you do not like the arrange tables results, choose
Undo from the Edit menu.
10
Double-clicking
Dragging and dropping
Right-clicking
For example:
Procedure
Action
To mark a join
Click it.
Ctrl-A.
To move a table
To roll up a table
11
Procedure
Action
12
If you choose to browse to a copy of that universe file on your local file system and open it
directly in Universe 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, do not open a
universe file directly using File Open menu. Instead, use File Import to ensure that you
are viewing the most recent version. Make your modifications and export your universe again
to make your changes available in the repository.
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.
13
Instructions
1. Open Universe Designer.
2. In Universe Designer, click File Import. Browse to the eFashion.unv sample universe
file in the location specified by the instructor.
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 View Arrange Tables to automatically organize tables.
7. Click View List Mode 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. Select Tools Options and click the Graphics menu tab.
10.Select the Show row count check box, and click OK.
11.Right-click the Article_Color_Lookup table to view the number of rows in the table (Refresh
row count for all tables).
14
15
The analysis of user requirements and design are the most important stages in the process.
Users must be heavily involved in the development process if the universe is going to fulfill
their needs both with the business language used to name objects and the data that can be
accessed.
Implementation will be successful if the first three stages are carried out properly. It is advisable
to spend 80% of the time allocated to the development of a universe on the first three stages:
Preparing.
Analyzing.
Planning.
16
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 Universe Designer to build your universe
will be much more productive.
Preparation phase
During the preparation phase, the scope of a BusinessObjects universe is defined. The production
and development architectures are identified and reviewed. Project teams are assembled and
the initial task plan is defined.
The definition and communication of project scope eliminates risk associated with deploying
the universe to pilot users during the Implementation phase. The scope is defined in terms of
intended functionality of the universe. Identification of target users of the universe also helps
create a shared understanding of project objectives.
Key managers should be involved in the scoping process. Once formulated, the objectives of
the project are communicated to everyone involved, directly or indirectly.
In designating the team members, individuals must be chosen to fill the following roles. One
person may fill multiple roles.
Role
Task
Sponsor
Project Leader
Analyst
Data Expert
Key User
17
Role
Task
Pilot Users
Users who work with the universe during the universe build and
development phase.
QA Reviewer
In most cases, a single person is responsible for the bulk of the work, filling the roles of Analyst,
BusinessObjects Administrator, and Data Expert.
In designing and building the universe, this person maintains a relationship with the Key User,
who should also be one of the Pilot Users.
This developer usually reports to a Manager or IS Director, who serves as Project Leader. The
Leader maintains a close relationship with the Sponsor.
Other roles that will be impacted by the project include the Database Administrator, the System
Administrator, and the Data Administrator.
Adopt standards
Universe names.
Object definition guidelines.
Names for objects.
Class names.
Alias names.
Help text.
The standards may be revised during the course of the first universe development project as
the team becomes more familiar with the product.
Conduct a meeting
Communicate the preparation phase strategy in a meeting. This is your opportunity to gather
all interested parties (developers, users, the sponsor) to ensure that everyone understands the
scope of the endeavor.
18
You can use this meeting to demonstrate BusinessObjects products and to help set expectations
of the user community.
Analysis phase
The primary objective of analysis activities is to identify user requirements for the ad hoc query
environment.
These requirements are captured in the form of candidate classes and objects.
There are many places to look for candidate objects. The best way to identify them is by talking
to the end users. When interviewing end users, the type of questions to ask are: What type of
information do you need to do your job?, How do you know you are doing well?, How
does your boss know you are performing well?, or What kind of information do others ask
you for?
As users answer these questions, document their answers in terms of class and object
requirements. For example, if a user states, We need to retrieve information on employees by
department and hire date you have identified a potential class (information about employees)
and an object or two (department and hire date). When you identify a potential class, probe
for objects. For example, What kind of information about employees do they want?
Candidate classes and objects can also be identified by reviewing existing reports.
Document your classes and objects. For example:
Type
Name
Class
Customer
Object
Total
(Measure)
Revenue
Description
Source
Interview #1
Interview #3, #4
You should also try to document the qualification of objects (dimension/detail/ measure) and
any potentially identified hierarchies.
19
The questions asked during BusinessObjects interviews are similar to those asked in the
development of OLTP applications. What is done with the answers is very different.
When conducting Analysis for an OLTP application, analysts document data requirements in
entity relationship diagrams. Rules of normalization are applied to the items that users request,
breaking them down to an atomic level, or eliminating calculated objects. These activities
optimize the data for storage in a relational database.
By contrast, requirements for an ad hoc query environment should be expressed in terms that
are optimized for retrieval of the information.
A successful BusinessObjects universe presents information to a business person using user
specific business terminology. The developer must unlearn analysis techniques used for the
development of application systems. User requirements must be taken at face value, remaining
in business terms.
Basic rules of thumb:
Do not normalize
Do not eliminate objects that can be derived from other objects
Do not try to figure out where this data can be found in the database
For example: in an interview, a user states I need to look at annual sales figures by region.
Document this at face value; identify the requirements, but do not attempt to transform them
in a manner appropriate for storage in a relational database. You can identify three candidate
objects: Year of Sale, Sales Amount, and Region. Do not eliminate Year of Sale because
you have already documented a Date of Sale object. Do not reduce Sales to the components
from which it is calculated (perhaps quantity multiplied by price). Instead of normalizing
object requirements, identify how they will support on-line analysis by end users.
Identifying candidate objects as dimensions, details or measures facilitates end user reporting
and analysis flexibility. You can also plan for scope of analysis (drill-down and drill-up options)
by identifying dimensional hierarchies.
Once you have gathered and documented requirements in the form of candidate objects, you
are ready to begin to plan the BusinessObjects universe requirements.
Planning phase
The planning phase is used to identify a project strategy and determine resource requirements.
The project plan is the key to timely implementation. For each task, the plan should assign
responsibility and target dates. Creation of the plan and the tracking of progress against the
plan are the primary responsibilities of the project leader.
20
Technical architecture requirements may have been looked at in general in the preparation
phase. A review of the technical architecture should take place during the planning phase of
the project. Items to review include:
Development
environment
Production
environment
Computers
Connectivity
Configuration
Security
Support plan
Develop support policy for when the universe goes into production.
Change
management plan
Training plan
Implementation phase
The implementation phase can be split up into two stages:
1. Designing the schema.
2. Building the universe.
21
The first task during schema design is to determine and document the data source for each
candidate object. If requirements were gathered in a tabular format, add a column to the table
where you can indicate the SQL fragment and source tables that are used to retrieve the object.
Type
Class
Name
SQL fragment
Customer
Description
Source
Information on a customer,
including location, credit
ratings, and shipping
preferences.
Interview
#1
Interview
#3,4
SQL:
Object
(Measure)
Total
Revenue
sum(order_lines.quantity*
products.price)
Any candidate classes that were captured as general requirements without specific objects
must be expanded now. For example, suppose there was a candidate class called Customer
and the specific objects within this class were not identified. During the schema design stage,
the developer must fill out this class. The developer might fill it out based on knowledge of
the business by including all columns from one or more tables, or the developer might go back
to users for more detail.
There are several ways that objects can be mapped to enterprise data. Simple objects map back
to a single column in the database. An example would be "Customer First Name", which maps
back to the First_Name column in the Customers table. Complex objects make use of SQL to
manipulate data that comes from one or more columns. For example, a "Customer Full Name"
object might connect the First_Name and Last_Name columns from the Customers table.
Aggregate objects involve SQL GROUP functions. Counts, sums, and averages are all aggregate
objects. The Total Revenue object is an aggregate object; it uses the SQL SUM function.
22
Similarly, you need to identify hierarchies within your dimensions. These hierarchies later
enable users to drill-down and drill-up.
23
Once the schema design stage is complete, the development team is ready to begin using the
BusinessObjects Universe Designer software to build the universe.
Tip: Remember that it is better to have several smaller less complex universes than one large
universe. This reduces maintenance, avoids potential security impacts and will improve overall
usability.
Pilot users then begin to use the universe. They provide feedback to developers who refine the
universe until build is completed.
24
Testing phase
The pilot testing and refinement phase follows universe design implementation.
Once an initial universe is built, it is deployed to the pilot users. These users work with the
universe and provide feedback to the developers.
Types of feedback include:
Better names for classes and objects.
Objects not in the universe that should be added.
Objects that can be removed.
Better ways to organize objects (for example, move an object from one class to another,
reclassifying a dimension as a detail, and so on).
Objects or queries that do not behave as expected.
Based on this feedback, the universe is modified. The modified universe is made available to
the pilot users for further evaluation. The testing phase can also address potential performance
issues. As a developer you can look at implementing performance enhancements to the universe.
Quality assurance
After the build is finalized, the universe is reviewed for quality assurance.
An independent reviewer makes the following checks:
Corporate standards for universe, object, class, and alias naming are followed.
Objects are only defined with tables that are referenced in the SELECT or WHERE clauses
Objects return results without syntactic error.
Objects return intended business results.
Objects are correctly classified as dimensions, details or measures.
Defined hierarchies make sense.
Objects have help text.
Aliases are used appropriately.
Join syntax and foreign keys are accurate.
Standard and outer joins are used appropriately.
These checks are best made by an individual who was not part of the development of the
universe, guaranteeing an objective perspective. Any issues that are identified are reported to
the developers for correction and review.
25
Deployment phase
The universe has been built, and has passed all quality assurance checks. It is now ready for
deployment.
The final deployment of the universe cannot begin until any architectural issues identified
during planning phase have been addressed. These issues include the establishment of user
connectivity, planning the installation configuration, preparation of a training program, and
identification of support and change management processes.
Architecture
Architectural considerations identified during the planning phase are reviewed. Any issues
that have not been resolved delay the deployment phase.
Production environment
The production environment has been set up in accordance with the architecture and security
plans identified during preparation and planning. The universe is modified to access data from
production systems, rather than from development systems and is exported to the production
repository.
Any database accounts that are required for BusinessObjects users should be created by the
database administrator. These accounts should be given appropriate access privileges to the
data objects used by the universe.
Users are also added to the Central Management System (CMS) and granted access to the
universe.
Conduct training
The release of the BusinessObjects universe to production users is coordinated with system
and database administrators as appropriate. The user training program is executed in conjunction
with the roll-out of the universe. Without appropriate training, users will not derive benefits
from BusinessObjects, regardless of the quality of the universe.
26
Prepackaged solutions
If you are designing a universe for Business Objects developers for developing precreated/
prepackaged reports, then the following items should be taken into consideration:
Predefine all filters and calculations that are used in standard documents, to remain consistent
throughout.
The universe can cover more than one business function, to allow cross functional reporting.
Precreated reports tend to cross reference reports against different business functions. The
universe, therefore, has to cover multiple business functions to provide end-to-end business
reporting.
Prepackaged solutions
If you are designing a universe for Business Objects developers for developing precreated/
prepackaged reports, then the following items should be taken into consideration:
Predefine all filters and calculations that are used in standard documents, to remain consistent
throughout.
The universe can cover more than one business function, to allow cross functional reporting.
Precreated reports tend to cross reference reports against different business functions. The
universe, therefore, has to cover multiple business functions to provide end-to-end business
reporting.
Instructions
1. Launch the Planning_universe_activity.html file, from the course resources, to familiarize
yourself with the universe development cycle and to complete the activity questions.
2. Use this 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?
27
28
29
Lesson summary
After completing this lesson, you are now able to:
Define BusinessObjects universe concepts
Use the universe development cycle
30
Lesson 2
31
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).
No new models have been brought out during the period.
These are required to list the cars for sale and rent.
32
Such reports may include the following: manufacturer, model, trim, engine size, available
colors, and, sale/rental price.
Reports may be grouped by price range and style (for example, sport, or estate.)
These reports are used to show potential customers model availability and for general
management reporting.
2. A report is required which lists the showrooms, their location and which manufacturers
they have a dealership agreement with.
3. Ad hoc reports are required on car sales.
Reports may be grouped according to customer, showroom, sale, model, and manufacturer
dimensions.
These reports are 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,
or by car.
4. Ad hoc reports are required on car rentals.
These reports are 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, or by car.
Reports related to 2, and 3 are used by sales staff, finance department staff, and managers.
5. Ad hoc reports on employees.
The employee reports are only be available to Managers and the Personnel Department
staff.
Therefore, a different universe is used so that only these people have access to this data.
Note: Most users are required to run reports on both sales and rentals.
Development plan
The remainder of this course is spent developing universes for this imaginary deployment. In
accordance with the iterative approach, the development is phased as indicated below.
1. Design and develop a universe which enables end 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 requires the introduction of loops, chasm and fan traps into the universe
structure which need to be resolved. This constitutes a fairly complex universe structure.
33
3. Further extend the universe to refine and enhance the universe for end users by introducing
conditions, LOVs, and hierarchies for drilling.
4. Design and develop a universe for end users that enables them to build reports which meet
requirements 5 (ad hoc reporting on employees).
34
35
Hyperion
Generic ODBC
With the new XI architecture, connections can now be made to MS Analysis Services 2000,
MySQL, and SAP.
OLE DB connectivity
OLE DB (Object Linking and Embedding, Database) is an API, based on a set of interfaces
implemented using the Component Object Model (COM), designed by Microsoft for accessing
different types of data stored in a uniform manner. These interfaces support the amount of
36
DBMS functionality appropriate to the data store, enabling the data store to share its data. OLE
DB was designed as a higher-level replacement for, and successor to, ODBC, extending its
feature set to support a wider variety of non-relational databases, such as object databases and
spreadsheets that do not necessarily implement SQL.
OLE DB is part of the Microsoft Data Access Components (MDAC) stack, a group of Microsoft
technologies that interact together as a framework allowing programmers a uniform and
comprehensive way of developing applications for accessing almost any data store.
37
38
39
16.In the Wizard Connection dialog box, click the Test button to test the connection.
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.
17.Click Finish to exit the wizard.
Note: Avoid creating two different secured connections with the same name. For example,
one connection named "Status" and the other named "status", which may lead to a conflict
in the repository.
40
To edit a connection
1. Click Tools Connections.
The Wizard Connection dialog box appears.
2. Select the connection that requires editing from the list of available connections.
3. Click Edit.
The Login Parameters page for the connection appears.
4. Modify the login parameters or select a different data source for the connection.
5. Click Next.
6. Modify the configuration parameters as required, and click Next.
7. Modify the custom parameters as required, and click Finish.
8. Click the Test button to verify the modified connection.
9. Click Finish to apply the changes to the connection.
To delete a connection
1. Click Tools Connections.
The Wizard Connection dialog box appears.
2. Select the connection you want to delete from the list of available connections.
41
Note: Ensure the Universe Parameters dialog box displays with the Definition tab active.
2. In the Name field, enter a name for the universe.
3. In the Description field, enter a brief description for the universe.
This description is intended to help the end user. It needs to accurately describe the content
of the universe by using terminology the end user easily understands.
42
Used by
File name
Long name
Description
File names
A file name is created when you save the universe. The length of the name is dependent on
your operating system maximum. Windows allows approximately 156 characters. The file
name extension is .unv.
43
The local file system is the server on which Universe Designer is installed. Your universes are
saved by default in the universes folder in your user profile path, for example: \\Documents
and Settings\<user>\Application Data\Business Objects\Business Objects
12.0\Universes\<universe>.unv
Note: Do not change the universe file name after reports have been created on that universe
or the report files no longer point to the universe.
Long names
The universe long name is set in the Name field on the Definition tab. You can enter up to 200
characters and there are no character restrictions.
Universe descriptions
The universe description is an optional field. Information in this field can provide useful details
about the universes role and is viewable by end users.
Universe parameters
Universe parameters are definitions and restrictions that you define for a universe. Universe
Designer allows designers to define several different parameters using the different tabs available
in the Universe Parameters dialog box.
Note: For more detailed reference information about these parameters, refer to Chapter 2 - Doing
Basic Operations, Setting Universe Parameters in the Business Objects XI 3.0/3.1 Designers Guide.
Description
Definition
Summary
44
Parameter
Description
Strategies
Controls
SQL
Links
Parameter
Definition tab
On the Definition tab you can set the universe name and a meaningful description. There is
no character limitation. End users see these in their Business Objects querying tool when they
select the universe.
The Connection field displays the connection name defined against the database.
45
Select the Click here to choose stored procedure universe option to connect to stored procedures
available in the data source. The available stored procedures are displayed in the Table Browser.
Summary tab
Description
Created
Modified
Revision
Comments
46
Information
Description
Statistics
Strategies tab
A strategy is a script that automatically extracts structural information from a database or flat
file. Default 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 SQL 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 quickly, and
you want to use metadata information that already exists in a database or database design 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 probably not use the
automatic creation possibilities that this tab offers.
Built-in strategies are the default strategies that are shipped with Universe Designer. You can
select them by clicking the drop-down menus in this strategies parameters tab. There are built-in
47
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 only select on matching column names, ignoring
all other column names, and may create unnecessary joins.
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 any query
generated via the universe for queries generating more than one SQL statement.
The time limit that you specify for query execution is the total execution time for a query. If
the query contains multiple SQL 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 does not correspond to its allotted execution time within the query.
When you specify an execution time limit for multiple SQL 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.
48
SQL tab
You can set controls on the types of queries that end users can build in Business Objects querying
tools.
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 option is selected by default. Accepting this
default value could potentially impact query performance.
49
Links tab
Links 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 optimizes
maintenance where some objects are used in many universes.
Note: Universes need to be exported to the repository before linking.
Parameters tab
50
In Universe Designer, you can configure certain SQL parameters that are common to most
databases to optimize the SQL generated. These parameters apply only to the active universe,
and are saved in the .unv file.
Instructions
1. Start a Universe Designer session and log on using the credentials provided by the instructor.
2. Create a new universe called Motors_xx, where "xx" stands for your initials.
3. Add the following description: This universe provides information on the Prestige
Motor Cars Database for Showrooms, Models sold, Rental and Sales Business.
4. Create a new OLE DB connection called MotorsOLEDB_xx, where "xx" stands for your
initials.
5. Save your new Motors universe via File Save As.
The universe is saved in the local universe directory.
6. Create another new universe and define the following parameters:
Name = Staff_xx (Where "xx" stands for your initials.)
Description = This universe provides information on the personnel of Prestige
Cars.
Connection: MotorsOLEDB_xx (Where "xx" stands for your initials.)
Tip: Use the same connection that you created in Step 4.
7. Save your Staff universe locally using File Save As.
51
52
Lesson summary
After completing this lesson, you are now able to:
Describe the course database and universe
Create the course universes
53
54
Lesson 3
55
Designing a schema
The schema contains tables and joins. Objects are mapped to columns in tables 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 multiple tables.
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. Define
the objects according to a user needs analysis. Examine the database for tables that allow you
to create these necessary objects.
Adding tables
The Structure pane of the Universe Designer interface is used to create a visual representation
of the physical data structure to which the universe is mapped. 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
56
you want to insert into your schema. Expand the + box next to a table name to display the
columns for the table.
1. You can open the Table Browser using one of the following methods:
Click the Table Browser button on the Editing toolbar.
Double-click the background area of the Structure pane.
Select Insert Tables from the menu bar.
Right-click the Structure pane and choose Tables from the drop-down menu.
The Table Browser displays:
From the Table Browser you can select tables to include in the universe schema. You can
insert a single table or multiple tables simultaneously.
57
58
You can use various commands to manipulate tables within the Structure pane.
You can move, copy, or delete tables in the Structure pane, as well as organize and change the
table display.
To select tables
Usually the first step in moving, copying, or deleting tables is to select them.
1. To select a single table, click the table header.
2. To select several tables, press Ctrl and click the table header of each table you want to select
in turn.
3. To select all tables, press Ctrl+A or choose Edit Select All from the menu bar.
Tip: You can also select multiple tables by:
1. Clicking on the Structure pane.
2. Holding the left mouse button down.
3. Dragging the mouse across the tables you want to select.
A line appears when you do this and boxes in your selection.
59
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.
60
2. If you select View Change Table Display, Ctrl+T, or double-click a second time, only
the join columns display in the table.
Join columns only display:
If you repeat one of those actions a third time, the original table view appears again.
61
3. Click Close.
Instructions
1. Insert the tables listed below into your blank Motors universe.
CLIENT
COLOUR
62
COUNTRY
FINANCE_PERIOD
MAKER
MODEL
REGION
SALE
SALES_PRICE_RANGE
SALE_MODEL
SHOWROOM
STYLE
2. Order the tables so that they are laid out in the same way as the illustration below.
63
64
Creating joins
You have several approaches to creating joins in Universe Designer:
Defining 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.
65
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.
66
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, and then click Insert Join. The two tables are
automatically entered in the Edit Join box and you can edit the join properties as required.
Description
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
Outer Join
Cardinality
When selected, allows you to define the cardinality for the join.
Shortcut Join
Expression
Join operators
You can select an operator for a join from the drop-down list between the Table1 and Table2
selection 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:
Operator
Description
equal to
!=
not equal to
67
Operator
Description
>
greater than
<
less than
>=
<=
Between
Complex
complex relationship
Edit
The Edit button opens an SQL 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 SQL syntax of the join expression.
If the parse is successful, you receive a result is OK message. If Universe Designer encounters
an error, you receive an error message indicating the source of the problem.
68
Then...
69
Detecting joins
Joins can also be created automatically. This procedure can be applied to multiple tables or, if
none are selected, all tables in the Structure pane.
Note: The automatic detection of joins assumes that all columns with matching names are to be
joined, and other columns are ignored. This may not be appropriate, in which case it is better to
insert the joins manually.
About cardinality
Cardinality is the means by which Universe Designer identifies the relationships between tables
in the universe structure. The cardinality can be:
One-to-one (1-1).
One-to-many (1-N).
70
Many-to-one (N1).
Many-to-many (N-N).
For example, a country can have many regions, so the relationship between a Country and a
Region table is 1-N.
Universe Designer uses cardinality to detect and resolve loops.
Note: It is very important that all cardinalities are set correctly for loop and context detection.
You can choose to set cardinality manually or by using an automatic detection tool.
71
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: 1 = one end of join; N = many end of join.
Tip: 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. Select the 1 or N radio button for Table1.
4. Select the 1 or N radio button for Table2.
72
5. Click OK to accept your changes and close the Edit Join dialog box.
Displaying cardinalities
You can display cardinalities in the Structure pane using the following symbols:
Cardinality symbol
Example
Description
Arrow
Arity
73
Cardinality symbol
Example
1,N
Description
Cardinality is shown as a
ratio at each end of the join.
To display cardinalities
1. Select Tools Options from the menu bar.
2. The Options dialog box opens to the General page.
3. Click the Graphics tab.
The Graphics page appears.
74
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).
75
Universe Designer requests confirmation because executing the detection tool takes a long
time if it is being applied to a large database.
3. If you are sure you want to use the automatic detection tool, click OK to detect the
cardinalities.
76
The system inserts the cardinality symbols on the many ends of the joins.
4. Universe 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.
77
Join types
Join Type
Description
Outer join
Shortcut join
Self-restricting join
Equi-joins
An equi-join is a restriction that conforms to the syntax set out below:
Table1.column_a = Table2.column_a
An equi-join is a join based on column values 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 of a relational table uniquely identifies each record in the table.
Primary keys may consist of a single attribute or multiple attributes in combination. A foreign
key is a field in a relational table that matches the primary key column of another table.
78
When a SELECT statement is run, the SELECT and FROM clauses are now properly defined and
prevent a Cartesian product.
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 only show information on US and UK.
However, you may wish to show all three countries irrespective of equivalent foreign key
values in the Region table. To achieve this, use an outer join.
In specifying an outer join in a standard SQL SELECT statement, you are required to identify
which of the two tables is the outer. Using straight SQL (as opposed to generating it using a
universe), the problem is that different RDBMS define outer differently and the syntax of the
79
statement also differs. For example, depending on the underlying RDBMS, the outer join may
be on the left or right.
In a universe, the outer join is always placed on the table that contains all the data. That is, on
Country in the example above. To do this, place a check against the table that contains all the
data in the Edit Join dialog box.
Tip: A good way to find out where to place your outer join is by reading the description that shows
up in the Cardinality zone. If you select the outer join check box for Country the description reads:
Each Country has ZERO or more Regions, AND each Region has one and only one Country.
When you check the outer join box for the Country table, you retrieve all countries whether
they have a region or not.
Once this is done, the correct outer join is inferred when used in the generated query, and the
syntax is correctly inferred for the appropriate RDBMS (assuming you have the correct SQL
inference driver).
An outer join is shown by a small circle on the join line in the universe structure at the end that
points to the table that may have missing values.
80
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.
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 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 the 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.
81
Note: The operand changes to Between automatically, and indicates that the join expression
is dynamically built as a BETWEEN syntax.
6. Click the Parse button to test for the validity of the join.
If you receive an error message, check to see that you have correctly selected the columns.
7. Set the correct cardinality.
8. Click OK.
The theta join now appears between the two selected tables.
Shortcut joins
A common use of shortcut joins is to link a shared lookup table to another table further along
a join path. The join path is comprised of several different tables in the same context.
A shortcut join is a join that provides an alternate path between two tables. It improves the
performance of a query by not taking into account intermediate tables, and shortening a normally
longer join path.
82
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.
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. Without the self-restricting
join, the results set of the query would produce rows where the sale type column is equal to
either car sales ('S') or car rental ('R'). With the self-restricting join expression set to sale type
equal to S, any object based on the table or joins passing through that table would produce
query results covering only car sales.
83
5. Click the same column that you selected in the Table1 column list box.
The expression for the join appears in the Expression text box.
6. Replace the operand value in the join expression with the restriction value that you want
to set on the join column.
For example, if you want to restrict the returned values from the sale type column to car
sales values only, you replace SALE.SALE_TYPE after the = sign with 'S' as shown below.
Tip: This can also be done directly in the Expression field.
Note: It is recommend that you set the cardinality of a self-restricting join to 1:1. Otherwise,
when running detect contexts, you get an error that not all cardinalities have been detected.
7. Click OK
The self-restricting join now appears as an unconnected join line.
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 Join dialog box.
84
List Mode
You can use List Mode to list the tables, joins, and contexts used in the active universe. In List
Mode, Universe Designer adds three panes above the display of the Structure pane; tables,
joins, and contexts. You can view the join expression underlying a join line or all join expressions
for a table using List Mode as well as the Edit Joins dialog box.
85
Note: Ensure you clear 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 the Check Integrity option to detect any errors in the structure and joins of a universe.
Be careful of checking cardinality automatically for all the reasons mentioned previously. As
a general rule, never select the Check Cardinalities check box when you are checking the
integrity of your universe.
86
Instructions
1. Insert the following equi-join using the drag-and-drop technique:
COUNTRY.COUNTRY_ID to REGION.COUNTRY_ID
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 CLIENT.REGION_ID
4. Check integrity for:
Universe structure and joins
5. Notice the divergences found in the integrity check of your Motors universe, which is the
result of having unjoined tables.
87
6. Complete the universe and ensure the following joins and cardinalities are included in the
universe structure:
Joins
Type
Cardinality
MODEL.MODEL_PRICE BETWEEN
SALE_PRICE_RANGE.PRICE_RANGE_MIN AND
SALE_PRICE_RANGE.PRICE_RANGE_MAX
Theta
N:1
SALE.SALE_TYPE ='S'
Self
1:1
CLIENT.CLIENT_ID = SALE.CLIENT_ID
Equi
1:N
SHOWROOM.SHOWROOM_ID = SALE.SHOWROOM_ID
Equi
1:N
SALE_MODEL.MODEL_ID = MODEL.MODEL_ID
Equi
N:1
MODEL.STYLE_ID = STYLE.STYLE_ID
Equi
N:1
MODEL.MAKER_ID = MAKER.MAKER_ID
Equi
N:1
SALE_MODEL.COLOUR_ID = COLOUR.COLOUR_ID
Equi
N:1
SALE.SALE_DATE BETWEEN
FINANCE_PERIOD.FP_START AND
FINANCE_PERIOD.FP_END
Theta
N:1
SALE.SALE_ID = SALE_MODEL.SALE_ID
Equi
1:N
88
89
Lesson summary
After completing this lesson, you are now able to:
Populate the universe structure
Define joins in a universe
90
Lesson 4
91
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 often
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.
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.
In Universe Designer, you can qualify an object as being one of three types:
Object qualification
Examples
Description
Dimension
Detail
92
Object qualification
Examples
Measure
Description
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.
Note: 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
in end-user querying tools.
Objects
In Business Objects products, an object is a named component in a universe that represents a
column or function in a database.
In Universe Designer, objects appear as icons in the Universe pane. Each object represents a
meaningful entity, fact, or calculation used in an end users business environment. The objects
that you create in the Universe pane in Universe Designer are the objects that end users see
and use in the Business Objects end-user querying tools.
For example, in the Web Intelligence Rich Client Query Panel, 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 Query Panel, the object infers a SELECT statement. When multiple objects are combined,
a SELECT statement is run on the database which includes the SQL inferred by each object and
a default WHERE clause.
93
As a universe designer, you use Universe Designer to create the objects that end users select
to build and run their queries.
You can also create objects for use only in Universe Designer, so that they are hidden in the
Business Objects end-user querying tools.
94
Creating 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 subclasses.
There are two ways to create a class in the Universe pane:
Manually defining a class.
Automatically by dragging a table from the Structure pane into the Universe pane.
To create a class
In Universe Designer, classes are created in the Universe pane. If the Universe pane is not
activated, it can be opened via View Universe Window.
1. Open your universe file in Universe Designer, and in the Universe pane, click an 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, a subclass within
that class is created instead.
2. With the universe file open in Universe Designer, insert a new class. There are three ways
you can insert a class:
Click the Insert Class button from the Editing toolbar.
Select Insert Class from the menu.
Right-click in the Universe pane and choose Class from the right-click menu.
3. The Edit Properties dialog box displays.
4. In the Class Name field, enter a name.
95
5. In the Description field, enter a description of the class content. Use business language that
is meaningful to the users in your description for when they review it. Avoid technical
database language.
6. Click OK.
96
97
4. 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.
5. Click OK to confirm the change.
98
To create a subclass
1. Right-click the class in which you want to create a subclass.
The drop-down menu appears.
2. Choose Subclass.
The Edit Properties dialog box displays.
3. In the Class Name field enter the name of the subclass.
4. Click OK.
The Universe pane should look similar to:
99
As the object is currently defined, there is no SELECT statement defined to reference the Client
table. You need to edit the definition of the SELECT statement so the Client Name object returns
the complete client name using the appropriate columns from the Client table.
Note: The example above shows a concatenation of two columns. Depending on the RDBMS
used the syntax can vary. Consult the documentation provided by your database vendor to
see what types of concatenation functions are supported.
100
It is normally best to use the latter method because it enables you to specify most of the
SELECT syntax 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.
6. Create the SELECT statement so the object references the appropriate table columns.
Note: You can use the fields below the text box to select the columns, operators or functions
you need to use to enter the required SQL syntax.
101
Measure = Selected by default when there is an aggregate function in the SELECT clause.
Note: The Detail qualification check box is 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 zone.
102
In the Security Access Level zone you can assign the following security access levels:
Public
Controlled
Restricted
Confidential
Private
If you assign Public, then all users can see and use the object. If you assign Restricted, then
only users with the user profile of restricted or higher can see and use the object.
In the Can be used in zone, select one of the following options to define how this object can be
used in a query:
The Result check box - use this object to return results in a query.
The Condition check box - use this object to apply a condition or query filter in a query.
The Sort check box - specify the object in the ORDER BY clause of a SELECT statement.
Note: This option can increase the processing speed of a query. However, 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.
103
If you then use Country and the Client Name object in a query, the query does not need to
reference the Country table in the database; the Country data is taken from the Client table
directly.
104
You can specify the following types of information in the Source Information tab:
Technical information: 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.
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.
105
To find a string
1. Ensure the Universe pane of the Universe 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. Select the Universe pane, and click Find from the Standard toolbar.
The Find/Replace dialog box for finding class and objects components in the Universe pane
opens.
106
2. Select the Universe pane, and click Find from the Standard toolbar.
The Find/Replace dialog box for finding class and objects components in the Universe pane
opens. Select the Replace tab.
107
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.
4. Select the check boxes as required.
5. Click Find Next.
6. Click Replace and then move to the next instance of the string by either clicking Find Next
or the Standard toolbar option.
108
109
Testing objects
As you create objects in the universe, test them in Business Objects end-user querying tools 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 SQL appear correct?
Are the results of the query correct?
Note: Remember that you must also test the joins already created in the structure.
Instructions
In this workshop you create classes, subclasses, dimension, and detail objects in your Motors
universe and then test the universes objects and joins.
1. Create the following classes:
Client
Car
Showroom
Sales
Finance_Period
2. Create objects for each of the classes as identified in the tables. Some of the properties for
each object have been specified for you. However, you need to determine the data type,
qualification (dimension or detail), and whether or not an LOV should be associated with
each object:
110
Client class
Object Name
SELECT Statement
Object Description
Country
COUNTRY.COUNTRY_NAME
Region
REGION.REGION_NAME
Region of country in
which client resides
Area
CLIENT.CLIENT_AREA
Area of Region in
which client resides (for
example, county or
state)
Client Town
CLIENT.CLIENT_TOWN
Client Name
Client Address
CLIENT.CLIENT_ADDRESS
Address of client
Area Code
CLIENT.CLIENT_AREA_CODE
Phone Number
CLIENT.CLIENT_PHONE_NO
Client ID
CLIENT.CLIENT_ID
Unique Client ID
Number
Car class
Object Name
SELECT Statement
Object Description
Maker
MAKER.MAKER_NAME
Car Manufacturer
Category of Car
STYLE.STYLE_NAME
111
Object Name
Model
SELECT Statement
MODEL.MODEL_NAME +' ' +
MODEL.MODEL_TRIM +' ' +
MODEL.MODEL_ENGINE
Object Description
Showroom class
Object Name
SELECT Statement
Object Description
Showroom Town
SHOWROOM.SHOWROOM_TOWN
Town in which
showroom exists
Showroom
SHOWROOM.SHOWROOM_NAME
Name of
showroom
Showroom
Address
SHOWROOM.SHOWROOM_ADDRESS
Address of
showroom
SELECT Statement
Object Description
Financial Year
FINANCE_PERIOD.FP_YEAR
For example,
FY03-04
Financial Quarter
FINANCE_PERIOD.FP_QUARTER
For example, Q1
Financial Month
FINANCE_PERIOD.FP_MONTH
For example,
Month 01
112
SELECT Statement
Object Description
Price Range
SALES_PRICE_RANGE.PRICE_RANGE
Description of price
range banding
Model Price
MODEL.MODEL_PRICE
Manufacturer
recommended retail
price
Invoice ID
Number
SELECT Statement
SALE.SALE_ID
Object Description
Unique Invoice ID
Number
Sale Date
SELECT Statement
SALE.SALE_DATE
Object Description
Date of sale
5. Ensure you have defined each object using the appropriate object type.
The Universe pane in Universe Designer should appear similar to this:
113
6. Check the integrity of the objects, and make any alterations required.
Note: Test the validity of the joins also.
7. Save your universe locally.
Test the universe by building queries in Web Intelligence Rich Client using the new objects.
8. Launch Web Intelligence Rich Client and log on using the credentials provided by the
instructor.
Tip: Ensure to maximize the Web Intelligence Rich Client screen to enhance visibility of
menu options.
9. Select the create a new document based on a data source icon.
Select Browse for more data sources.
10.In the Data source selection menu select Universe, and click Next.
11.Select your local Motors universe, and click OK.
Your universe appears italicized. This indicates that this is a local copy of the universe rather
than an exported version.
114
12.Build a new query using the objects you have created. Drag and drop the objects into the
Result Objects pane.
13.Click Run Query to view the final results displayed in the report.
115
116
Lesson summary
After completing this lesson, you are now able to:
Define classes and objects
Create classes and objects
117
118
Lesson 5
119
You create a measure object by using an aggregate function in the SELECT definition of the
object. 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 selection list of the Edit Select Statement dialog box.
120
When a query uses at least one dimension or detail object and a measure, the inference engine
includes a GROUP BY clause with all the objects except the measure in the SQL Statement:
The SELECT clause shows the object(s) and measure selected in the query with the syntax
including the aggregate function.
The GROUP BY clause includes all the objects except the aggregate.
In this example, the query includes the Sales Revenue measure and the Country object so the
inferred SQL statement includes a GROUP BY clause with the Country.
121
In this example, the query includes two dimensions (Country and Region) so the inference
engine includes both dimensions in the GROUP BY clause. As a result, the values returned for
the Sales Revenue measure object are aggregated to a lower level, the Region. This mechanism
in the inference engine allows the measure objects to adapt dynamically to other, associated
objects.
122
However, when you edit the table, for example, by removing a column, and therefore project
only partial data from the microcube, aggregation is required to show measure values at a
higher level. The data in the microcube remains unchanged.
123
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.
Sum
Count
Average
Maximum
Minimum
Sum
Sum
None
Maximum
Minimum
For the reports to present statistically correct results for a measure object both at query and
projection level, the SELECT and projection aggregates need to complement each other.
However, as a universe designer, if you configure a measure differently, the Business Objects
end-user querying tools will not stop you.
Note: With the exception of Average, the correct projected aggregate is selected by default. When
you set the SELECT syntax to Average, for example Avg(SALES.SALES_TOTAL), the projection
aggregation for this object would automatically be placed as a Sum. This would need to be changed
manually to None.
124
Measure objects
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.
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
must 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:
125
126
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.
Instructions
1. Create the following subclass in the Sales class:
Sales Figures
2. Create measure objects in the new Sales Figures subclass as identified in the tables below.
The SQL code for the SELECT properties of each object has been specified for you. However,
you need to determine the appropriate projection function aggregate.
127
SELECT Statement
Object Description
Sales Revenue
sum(SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE *
((100 - SALE.SALE_DISCOUNT) / 100))
sum(SALE_MODEL.SALE_QTY *
MODEL.MODEL_COST)
Number of Cars
Sold
sum(SALE_MODEL.SALE_QTY)
Total Number of
Cars Sold
Tip: When using the Number of Sars Sold, and Cost of Car Sales objects, ensure that the
result is always restricted to Sales data.
3. Create measure objects in the classes as identified in the tables below. The SQL code for the
SELECT properties of each object has been specified for you. However, you need to determine
the appropriate projection function aggregate.
128
SELECT Statement
Lowest Priced
Value
Highest Priced
Value
Object Description
min(MODEL.MODEL_PRICE
max(MODEL.MODEL_PRICE
Client class
Object Name
SELECT Statement
Number of Clients
Object Description
Total number of
clients
129
8. Test the Sales Revenue measure object by creating a third query, using the following steps:
a. Edit the second query and then click Add Query.
b. Create a new query with Country, Region, and Sales Revenue.
c. Check the SQL and note the GROUP BY clause. It should now contain the SQL for country
and region. Click Run Queries.
d. Apply a break to the Country column and apply a sum calculation to the Sales Revenue
column of the new projected block. Does the country group sum match the value of the
noted block row in the second table (for example, USA)?
e. Edit the query. Change the projection to the block from the microcube by removing the
Region column from the block. Does it aggregate to country level correctly?
f. Edit the query again. Change the 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?
g. Edit the query again. Add the Showroom and Maker objects.
h. 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
that the total values remain the same. The final version of the report should look similar
to this:
130
131
132
A new row appears at the bottom of the table and this row displays the average sales total for
all regions.
This appears accurate, but it is not. Web Intelligence Rich Client is adding up the values shown
in the Average Sales Total column and then dividing them up by six, since there are six regions
available. The values in the Average Sales Total column are already calculated averages, so
Web Intelligence is actually calculating the average of averages.
What is required here is a weighted average, as some regions have more car sales revenue returns
than others. The sales total value returned by those regions with more sales returns needs to
count more heavily than those regions with fewer returns.
When adding the Number of Cars sold figure to the query, you see here that the number of
cars sold per region varies considerably. Sixty-eight cars were sold in the West Coast, while
only thirteen in the East Coast.
When Web Intelligence Rich Client calculates the overall average sales total, it cannot take into
account the fact that the West Coast should have more weight in the calculation of the average.
Web Intelligence Rich Client does not have access to the detailed data, just to the regional
average value, returned by the Average Sales Total measure.
133
To calculate a weighted average, you need to create a delegated measure in the universe, which
will delegate this calculation to the database.
To do this, you must modify the universe using BusinessObjects Universe Designer. In properties
of the Average Sale Total measure, setting the function to Database delegated delegates this
calculation to the database and effectively calculates a weighted average.
Running the same query using the Average Sales Total measure with the function set to Database
delegated, results in the correct average total:
134
Use a delegated measure when report users manipulate the measures in reports. When they
only need to refresh, view and print their reports, the calculation may be simpler to perform
in the report.
Use a delegated measure to replace multiple query aggregates.
Use a delegated measure on calculations that could give inaccurate results when calculated
in the report (such as a complex average).
Use a delegated measure for measures requiring division.
When you create the delegated measure in the universe make sure that in the Edit Properties
dialog box for the measure, on the Definition tab, you enter identifying text in the Description
field. This ensures report designers can quickly recognize a delegated measure when they
glide their mouse over it in a query
Instructions
1. In Universe Designer, open your Motors universe file.
2. In the Sales Figures class, create a new measure called Average Sales Total with the following
syntax:
avg(SALE.SALES_TOTAL)
135
5. Select the Average Sales Total column and select the average function from the toolbar.
Activate the sum drop-down list and select average.
Evaluate the result.
6. Edit the query and add Number of Cars Sold.
Evaluate the average value that is shown at the bottom of the Average Sales Total column.
Does this reflect the correct average per Region?
7. Return to Universe Designer and copy the Average Sales Total object and paste it in the
same class. Name the copied object Delegated Sales Total Average.
Ensure the Associate a List of Values option for the Delegated Sales Total Average measure
is cleared.
8. In the Properties tab, set the aggregation function to Database delegated.
Save your universe locally.
9. Return to Web Intelligence Rich Client.
Tip: To ensure that your new version of your universe is available, go to Tools Universes
and refresh the list.
10.Create a new query with the Region, Average Sales Total, and the Delegated Sales Total
Average objects.
11.Add an average to the Average Sales Total column, as done in step 5.
12.Drag the Delegated Sales Total measure object from the Data tab and position it in the cell
at the bottom of the Delegated Sales Total column. Drop the Delegated Sales Total measure
object in the cell at the bottom of this column.
136
You see here that the average calculated by the database does not return the same value as
the value calculated by Web Intelligence Rich Client.
Because the database has access to the detailed data concerning all satisfaction levels in
these regions, the result is based on a weighted average. The database is able to take into
account the difference in numbers of customers per region.
137
138
Lesson summary
After completing this lesson, you are now able to:
Explain measure object concepts
Create measure objects
Create delegated measure objects
139
140
Lesson 6
141
Understanding loops
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.
After completing this unit, you will be able to:
Understand the causes of loops
Detect loops in a universe structure
Recognizing loops
A loop exists when the joins between tables form a closed path.
For example, in the table layout above, the designer has added joins between the tables
Showroom and Country to create two linked sets of information:
One set links the car sale details, the client, the clients region and the clients 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.
142
The designer adds the tables needed to provide this information and creates the joins as shown
in the previous example. 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 was run using the Showroom Country, Client
Country and Sales Revenue objects, the report results would be incorrect. The report would
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. However, the report would not show any clients
from any other countries. When you know that there are clients from other countries, this result
indicates that there is a problem with the report.
Notice that the two joins at the top of the SQL statement 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.
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 infers legitimate SQL, the results do not include all intended values. Therefore, a query
143
on a universe involving such a loop returns misleading data. To avoid this, the loop must be
resolved.
Resolving loops
Loops are an inherent problem when writing SQL statements. There are various techniques
within SQL that you can apply to resolve loops.
144
About aliases
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 SQL into using the same database
table for two different purposes.
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 only has the one end of
the one-to-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 SQL 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 necessary for some relational databases. Today, it is not necessary. However,
some universe designers prefer to alias both tables.
145
2. The Loop 1/1 indicates how many loops have been detected. If there 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.
3. Click Insert Alias in the Loop Detection dialog box.
Universe Designer automatically creates an alias for the required table. You may need to
move the new alias table so that you can see the Structure pane.
Note: The original table name shows up in brackets in the alias table header.
4. Close the Loop Detection dialog box.
The Structure pane look similar to this:
146
In the example diagram, the Country_Showroom alias table has been created in the Structure
pane, 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, Universe Designer might nominate either
of the two as the candidate for the alias table.
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.
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.
5. To create the alias table, click Create.
Universe 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, the Candidate Alias dialog box closes.
Tip: Be careful not to delete the original table. Once you have created one or more alias
tables, its 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.
147
Redefining objects
When you create an alias table, check that any existing objects that are defined from the original
table still refer to the right table. They may need to be defined from the alias table to infer the
correct SQL and get the correct result.
148
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 save the universe.
Advantages
Disadvantages
Detect loops
Detect aliases
Insert alias
Whichever method you choose, you must always redefine objects that now use the alias table.
149
column of the same table. Joining a table to itself can be useful when you want to compare
values in a column to other values in the same column.
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.
Therefore, a self-referencing join is required to report on the hierarchical relationship between
those employees.
For example, in the Motors database there is an employees table that contains columns as shown
below:
Each employee is uniquely identified by the Emp_Id field, and each employee has a manager,
who is identified by the Emp_Mgr_Id 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_Id field to the Emp_Id field, as in this example:
The code used to identify the manager (Emp_Mgr_Id ) is itself an employee code. You can
therefore use it to look up the Emp_Id codes in the Employee table and identify the managers
name.
This is effectively a loop, as the path forms a closed circuit. However, you cannot resolve it by
using the usual method of detecting the cardinalities and then detecting aliases. This is because
the cardinality detection tool cannot work on a self-referencing join. Moreover, a structure
expressed this way does not infer the correct SQL.
150
Instructions
In this activity new tables, new joins, cardinality, are inserted into your Motors universe. These
result in loops in your universe structure. Resolve these loops and test the results in Web
Intelligence Rich Client.
1. Insert the following join and set its cardinality.
COUNTRY.COUNTRY_ID = SHOWROOM.COUNTRY_ID
2. Use the Detect Loop toolbar 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 toolbar button and create two alias tables
called:
COUNTRY_SHOWROOM
COUNTRY_REGION
COUNTRY_MAKER
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_MAKER.COUNTRY_ID = MAKER.COUNTRY_ID
Note: Ensure that the join cardinality for the last join is set to one-to-many (1-N).
4. Create the following object in the Showroom class:
151
Object Name
Showroom
Country
SELECT Statement
COUNTRY_SHOWROOM.COUNTRY_NAME
Object Description
Country in which
showroom exists
Client Country
SELECT Statement
COUNTRY_REGION.COUNTRY_NAME
Object Description
Country in which
client resides
Maker Country
SELECT Statement
COUNTRY_MAKER.COUNTRY_NAME
Object Description
Country of
manufacturer
152
16.In the Staff class, create a Managers dimension object based on the MANAGER alias table.
Concatenate the manager's last name and first name columns.
17.Check the integrity of the Staff universe with all except the cardinality options checked.
Resolve any relevant divergence.
Tip: You should not find any divergences.
18.Save your Staff universe, and test the results in Web Intelligence Rich Client as follows:
1. Run a query using Manager and Employee. Add a count on both columns.
2. Add a query with only the Manager object. Add a count. Is this the correct value?
3. Open your Staff universe in Universe Designer and edit the Manager object. To ensure
that the data is restricted to only manager data, use the Tables button. Select the
EMPLOYEE table, to force the object to use the join between the table and restrict the
data.
4. Test the result, creating a new query with only the Manager object. It returns the correct
number of managers.
5. Edit the query and add Employee. Run and display the count. There are 26 rows. Why?
The join restricts the data to look only for employees that have managers. However, there
is a manager that does not have a manager, and is now excluded.
6. Open your Staff universe in Universe Designer and add an outer join on the MANAGER
table side.
7. Save the changes and test the results in Web Intelligence Rich Client.
153
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 the 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 result
set of the query would produce rows where the Sale_Type column is equal to either S or R.
Previously, 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 need to 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, creates a loop because the
query does not know which table to go through to get to the Model, Sale, or the alias Rental
table.
You can solve this type of loop by creating two contexts which defines the correct route through
the universe structure. These routes link tables together in the structure.
What is a context?
A context is 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.
154
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 an end-user query.
This is because there are two alternate routes around the structure. Contexts are used to specify
those alternate 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:
155
156
Sale_Model Context
COUNTRY_REGION.COUNTRY_ID =
REGION.COUNTRY_ID
COUNTRY_REGION.COUNTRY_ID =
REGION.COUNTRY_ID
REGION.REGION_ID = CLIENT.REGION_ID
REGION.REGION_ID = CLIENT.REGION_ID
CLIENT.CLIENT.ID = RENTAL.CLIENT_ID
CLIENT.CLIENT.ID = SALE.CLIENT_ID
RENTAL.SALE_ID = RENTAL_MODEL.SALE_ID
SALE.SALE_ID = SALE_MODEL.SALE_ID
RENTAL_MODEL.MODEL_ID = MODEL.MODEL_ID
SALE_MODEL.MODEL_ID = MODEL.MODEL_ID
MODEL.MODEL_DAYRENT between
RENTAL_PRICE_RANGE.RENT_RANGE_MIN and
RENTAL_PRICE_RANGE.RENT_RANGE_MAX
MODEL.MODEL_PRICE between
SALES_PRICE_RANGE.PRICE_RANGE_MIN and
SALES_PRICE_RANGE.PRICE_RANGE_MAX
MODEL.STYLE_ID = STYLE.STYLE_ID
MODEL.STYLE_ID = STYLE.STYLE_ID
MODEL.MAKER_ID = MAKER.MAKER_ID
MODEL.MAKER_ID = MAKER.MAKER_ID
MAKER.COUNTRY_ID =
COUNTRY_MAKER.COUNTRY_ID
MAKER.COUNTRY_ID =
COUNTRY_MAKER.COUNTRY_ID
Note: The name of the context is normally defined by the table with only the many (N) 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 or rentals queries, dependent on the objects they select.
Note: Every join (except shortcut joins) must exist in at least one context.
Detect contexts
157
Insert contexts
The first loop is highlighted in the Structure pane, 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.
2. Click the Candidate Context button to see what the tool suggests.
The Candidate Contexts dialog box displays.
3. Highlight the candidate context you want to add and click the Add button.
The context moves across to the Accepted Contexts field. You can click the Rename button
to give each context a more meaningful name.
Note: You may choose to leave the original context name in brackets. This can be useful in
order to remind you that you have changed the joins in the context, while still allowing you
to view the original definition.
4. Repeat the process until you have accepted all the candidate contexts.
158
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.
The Candidate Contexts dialog box closes, and the List Mode window opens in the upper
part of the Structure pane.
5. Click OK.
6. Close the Loop Detection dialog box.
The List Mode window shows the created contexts.
The Joins pane indicates the joins that are involved in the currently highlighted context. The
Structure pane highlights the tables that are involved.
7. When you have created the contexts you require to resolve the loops, save the universe.
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. Click OK to continue because you have set the cardinality for all of the joins.
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 tool.
4. Repeat the process until you have accepted all the candidate contexts.
159
Editing a context
Sometimes, a user creates a query using objects that reference tables from opposite ends of two
contexts, for example, a query using Client Name and Model.
The Client and Model tables are on opposite sides of the Rental and Sales contexts.
As a result, there are two potential routes for the inference engine to use in the SELECT statement
so, when the end users run the query, they receive a prompt message to choose one of those
contexts.
As the term context is not meaningful to end users, you need to ensure that the context names
and the Help descriptions clearly indicate how the choice of context influences the results.
160
Testing contexts
Any end-user query that generates a SELECT statement which spans across the loop fails without
contexts in place. If contexts are in place, the end-user query tool generates the SELECT
statement(s) in one of three ways. To test contexts, 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 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 Sales Revenue objects.
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.
The query infers that the Sales context is the one to use for the query.
161
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, the user is prompted by a dialog box in the Query Panel 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, more than
one context contains all the joins necessary to include the Showroom and Model tables to which
the two objects refer.
The user is prompted 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 Universe 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 need to update all the contexts.
162
If you have made only a simple change to the structure, you can update the joins that are
included in each context manually using the Edit Context dialog box. 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
It is always best to create all your alias tables first, and then create your contexts, because of
the requirement to update contexts. Otherwise, your alias tables are not 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
tool. 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 do not necessarily resolve all the alias
table loops first, followed by all the context loops. It is therefore better to use the alias detection
tool first, and then the context detection tool.
Remember also that you need to redefine any objects that are based on tables for which you
have created aliases. The overall sequence in universe design is as follows:
1. Add tables to the universe.
2. Insert joins.
3. Detect and resolve loops.
4. Create all the classes and objects.
Note: If you want to test your loop resolution in a query, you may need to create some basic
objects 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.
163
This is used when designing universes where it is possible in certain circumstances to make
the inferred SQL more efficient.
For example, in the Motors universe, the geographical information relating to clients comes
from the Client, Region, and Country tables:
If an end user runs a query including Country and Client (but not Region) objects, you find
that the inferred SQL 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 SQL.
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 does not need to
refer to the Region table.
You now have a loop. In this case, you do not have a multipurpose lookup table scenario, and
should therefore not alias.
Instead you would convert the created join to a shortcut join to break the loop.
Shortcut joins can change the results of existing queries and therefore should be used sparingly.
Shortcut joins should only be used when designing universes where it is possible in certain
circumstances to make the inferred SQL more efficient.
164
Instructions
In this activity new tables, new joins, and cardinality, are inserted into your Motors universe.
These result in loops in your universe structure. Resolve these loops and test the results in Web
Intelligence Rich Client.
1. In Universe Designer, create the following aliased tables:
165
RENTAL.SALE_ID = RENTAL_MODEL.SALE_ID
RENTAL.SALE_TYPE = 'R'
RENTAL_MODEL.MODEL_ID = MODEL.MODEL_ID
SHOWROOM.SHOWROOM_ID = RENTAL.SHOWROOM_ID
RENTAL_MODEL.COLOUR_ID = COLOUR.COLOUR_ID
MODEL.MODEL_DAYRENT between
RENTAL_PRICE_RANGE.RENT_RANGE_MIN and
RENTAL_PRICE_RANGE.RENT_RANGE_MAX
166
Ensure the following self-restricting join is added to the context (if the cardinality is set
to 1:1, this join is automatically added to the context):
RENTAL.SALE_TYPE = 'R'
Ensure the following self-restricting join is added to the context (if the cardinality is set
to 1:1, this join is automatically added to the context):
SALE.SALE_TYPE = 'S'
SELECT Statement
Object Description
Invoice ID
Number
RENTAL.SALE_ID
Unique Invoice ID
Number
Rental Date
RENTAL.SALE_DATE
Rental Revenue
sum(RENTAL.DAYS_RENTED*
RENTAL_MODEL.SALE_QTY*
MODEL.MODEL_DAYRENT*
((100 - RENTAL.SALE_DISCOUNT)/100))
11.Create a subclass called Day Rental Charges in the Car class, and then populate the subclass
with the following objects:
167
Object Name
SELECT Statement
Object Description
RENTAL_PRICE_RANGE.RENT_RANGE
Description of Rental
Charge banding
MODEL.MODEL_DAYRENT
12.A requirement is raised from managers wanting to see which showrooms have which
franchises. Queries made for this requirement should bypass the sales and rentals contexts.
A linking table between SHOWROOM and MAKER, together with a new context, is required
to return these results. 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
13.Create a FRANCHISE context with the following joins:
SHOWROOM.COUNTRY_ID = COUNTRY_SHOWROOM.COUNTRY_ID
MAKER.COUNTRY_ID = COUNTRY_MAKER.COUNTRY_ID
FRANCHISE.MAKER_ID = MAKER.MAKER_ID
FRANCHISE.SHOWROOM_ID = SHOWROOM.SHOWROOM_ID
Franchises
SELECT Statement
MAKER.MAKER_NAME
Object Description
15. Launch the Universe Designer Query Panel via Tools Query Panel.
Add the Showroom and Franchises objects to the Result Objects pane and view the SQL.
Does this query bypass the sales and rentals contexts?
Tip: Use the Tables button for the Franchises object to ensure only the FRANCHISE context
is used.
168
16.Insert the MODEL_COLOURS table and join it to MODEL and COLOUR tables, by inserting
the following joins:
COLOUR.COLOUR_ID = MODEL_COLOURS.COLOUR_ID (1-N)
MODEL.MODEL_ID = MODEL_COLOURS.MODEL_ID (1-N)
Adding this table, allows users to report on models of any color regardless of whether they
are for sale or for rental.
17.Create a new MODEL_COLOURS context.
18.In the Car class, create a new Colors detail object (associated to the Model dimension).
19.Check the integrity of the Motors universe with all options except cardinality checked.
Resolve any relevant divergence.
20.Save your Motors universe and close it.
21.Save your universe and then test the contexts used to resolve the loops by building the
following queries in Web Intelligence Rich Client:
Showroom and Sales Revenue. The inferred SELECT statement for this query should use
the SALES (SALE_MODEL) context.
Showroom and Rental Revenue. The inferred SELECT statement for this query should
use the RENTALS (RENTAL_MODEL) context.
Showroom, Sales Revenue, and Rental Revenue. This query should infer two SELECT
statements, one for each context.
Showroom, Model, and Maker. With this query, a dialog box should appear asking
which context to use.
Showroom and Franchises. With this query, the FRANCHISES context should be used.
169
170
Lesson summary
After completing this lesson, you are now able to:
Understand loops
Resolve loops using aliases
Resolve loops using contexts
171
172
Lesson 7
173
174
Chasm traps
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 all exist simultaneously:
1. There is a many-to-one-to-many relationship between three tables in the universe structure.
2. The query includes objects based on the two many tables.
3. There are multiple rows returned for an object (usually a dimension) based on the "one"
table.
For example, in this diagram there is no loop, but the flow around the three tables is
many-to-one-to-many.
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.
175
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 being multiplied by the
other. The effect is similar to a Cartesian product but is known as a chasm trap.
The chasm trap is resolved by executing separate SELECT statements for object Y and object Z.
176
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.
177
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, you need to examine the rows that are returned by the
queries to make the aggregated figures. In this example, you 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 the first table. There are also two rental transactions
in the second table.
If you add the dates to the combined query as in the third table, you can see why the sale and
rental revenues have doubled.
178
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, and
as 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.
179
With the option Multiple SQL statements for each measure selected, Universe Designer now
makes separate SQL SELECT statements for each measure object in the query.
The results in the report are now correct, as the query has automatically generated two SQL
statements.
Using this option resolves the chasm trap problem. However, there are drawbacks to using
this method to resolve chasm traps.
180
4. Click OK.
5. Save the universe.
6. In Web Intelligence Rich Client, create a new query using a dimension object, and two
measure objects from the many-to-one-to-many table relationship.
7. Access the SQL that is generated in the SQL Viewer. Click View SQL.
This displays the separate SQL Statements.
8. Run the query.
The results in the report are now correct, as the query has automatically generated two SQL
statements.
181
It is not that there is anything inaccurate about the dates, but the multiple occurrences are
confusing to users.
182
When you run a query that includes objects from both contexts, this creates two SELECT
statements that are synchronized at run-time in Business Objects end-user query tools to prevent
the creation of a Cartesian product.
Creating contexts always solves a chasm trap in a universe. When you have a
"many-to-one-to-many" situation, always use a context.
183
Instructions
1. Create a new universe called Chasm_xx, where "xx" stands for your initials.
Use your MotorsOLEDB_xx connection to connect to the Motors database.
2. Select File Parameters from the menu bar or click the Parameters button and select the
SQL tab.
3. Clear the Multiple SQL statements for each measure option by clearing the check box.
4. Add the following tables:
CLIENT
SALE
RENTAL (as an alias of the SALE table)
5. Create the following joins and set the cardinality:
Join
Cardinality
CLIENT.CLIENT_ID = SALE.CLIENT_ID
1:N
CLIENT.CLIENT_ID = RENTAL.CLIENT_ID
1:N
SALE.SALE_TYPE = 'S'
1:1
RENTAL.SALE_TYPE = 'R'
1:1
184
Chasm Objects
Measures
7. Add the following objects with the following syntax:
Chasm Objects class
Object Name
SELECT Statement
Client Name
CLIENT.CLIENT_LASTNAME
+ ' , ' + CLIENT.CLIENT_FIRSTNAME
Sale Date
SALE.SALE_DATE
Rental Date
RENTAL.SALE_DATE
Measures class
Object Name
SELECT Statement
Sales Revenue
sum(SALE.SALE_TOTAL)
Rental Revenue
sum(RENTAL.SALE_TOTAL)
185
12.In the same report add a new table by clicking the Edit Query button. Click Add Query,
and create a new query using the Sales Revenue, Rental Revenue, and Client Name objects.
Select the Client Name object, and click the Apply a Quick Filter button. From the List of
Values, select Brent, Paul.
13.Click View SQL to check the SQL statement generated.
14.Click Run Queries and select the Insert a table in the current report option.
What is the sale amount in the new table?
What is the rental amount in the new table?
What happened to your figures?
15. In Universe Designer, edit the universe by clicking File Parameters SQL tab, and select
the Multiple SQL statements for each measure option.
16.Save your universe locally.
17.In Web Intelligence Rich Client, create a new document using the Sales Revenue, Rental
Revenue, and Client Name objects. Select the Client Name object, and click the Apply a
Quick Filter button. From the List of Values, select Brent, Paul. Click View SQL to check
the SQL statement generated.
Tip: You may need to refresh the universes list to get the latest version of your universe.
Select Tools Universes and click Refresh.
What is the sale amount?
What is the rental amount in the new table?
What happened to your figures?
18.Edit the query by clicking the Edit Query button on the toolbar.
19.Remove the Sales Revenue, and the Rental Revenue objects. Add the Sale Date, and Rental
Date objects. Click Run Query.
What happens to the SQL and to the results?
20. In Universe Designer, edit the universe by clicking File Parameters SQL tab and clear
the Multiple SQL statements for each measure option again (clear the check box).
21.Insert the following contexts:
Context
186
Joins
CLIENT.CLIENT_ID = SALE.CLIENT_ID
Sale
SALE.SALE_TYPE = 'S'
CLIENT.CLIENT_ID = RENTAL.CLIENT_ID
Rental
RENTAL.SALE_TYPE = 'R'
187
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 does 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 using objects Y and Z, the inferred SQL includes tables B and 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.
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.
188
The fan trap problem becomes apparent in a query that aggregates both an object based on the
Sale_Total column in the Sale table, and an object based on the Sale_Qty column in the
Sale_Model table.
189
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.
190
Then...
Three tables in a
one-to-many relationship.
A dimension coming from
the first table and measures
coming from the two
subsequent tables.
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(s).
Create an alias for the table (on the many end of the join)
containing the initial aggregation, joining it back to the
non-aggregation table (on the one end of the join). Use the
Detect Contexts tool 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 works with measure and dimension objects and
does not cause inefficiencies.
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 work with both measure and dimension objects and
do not cause inefficiencies.
Note: However, to be more efficient still, using the
two-table scenario, you could also use the
@aggregate_aware function.
191
The SELECT clause of the Sales Revenue object needs to be edited, so that it refers to the alias
table rather than the original Sale table.
As with resolving a chasm trap problem, two contexts need to be created. In this example, a
context for Sale, and a context for Sale_Model need to be defined. This allows for the results
to be 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 do not get the fan trap, even when that dimension object contains
192
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.
193
In the universe structure shown below, you have created an alias table of the Sale table and
created a join between the alias and the original table. And two separate context have been
defined. This is to separate the dimension in Sale from the measure, which now refers to
Sale_Alias.
194
7. In Web Intelligence Rich Client, test the solution using a dimension object from the original
table, a measure object from the alias table, and a measure from the second table in the
schema.
When you look at the SQL in the SQL Viewer, there are two SELECT statements.
Note: Aggregate awareness provides another solution to this problem.
This is the method used to avoid the fan trap in the Motors universe, when the Sales Revenue
and Number of Cars Sold measure objects are included in the same query.
195
In the Motors universe you have created during this course, the Sales Revenue measure is not
based on the total figure in the Sale table but on a number of columns from the Sale, Sale_Model
and Model tables which are held in the database at the same level of granularity as the number
of cars sold. Therefore, no fan trap exists and the correct result is obtained.
Note: Another method of resolving a less common form of fan trap is by using aggregate awareness.
Instructions
1. Create a new universe called Fan_xx, where "xx" stands for your initials.
Use your MotorsOLEDB_xx connection to connect to the Motors database.
2. Select File Parameters from the menu bar or click the Parameter button and select the
SQL tab.
3. Clear the Multiple SQL statements for each measure option by clearing the check box.
4. Add the following tables:
196
CLIENT
SALE
SALE_MODEL
5. Create the following joins and set the cardinality:
Join
Cardinality
CLIENT.CLIENT_ID = SALE.CLIENT_ID
1:N
SALE.SALE_ID = SALE_MODEL.SALE_ID
1:N
SALE.SALE_TYPE = 'S'
1:1
SELECT Statement
Client Name
CLIENT.CLIENT_LASTNAME
+ ' , ' + CLIENT.CLIENT_FIRSTNAME
Model ID
SALE_MODEL.MODEL_ID
Measures class
Object Name
SELECT Statement
Sales Revenue
sum(SALE.SALE_TOTAL)
sum(SALE_MODEL.SALE_QTY)
197
Tip: To retrieve the sum value, highlight the relevant measure column without highlighting
the header, and select the Insert Sum toolbar icon.
18. In Universe Designer, edit the universe by clicking File Parameters SQL tab and clear
the Multiple SQL statements for each measure option by clearing the check box. Select the
Multiple SQL statements for each context option if it is not already selected.
19.Add an alias to the SALE table (SALE2).
20.Create the following joins:
198
Join
Cardinality
CLIENT.CLIENT_ID = SALE2.CLIENT_ID
1:N
SALE2.SALE_TYPE = 'S'
1:1
Joins
CLIENT.CLIENT_ID = SALE.CLIENT_ID
Sale Model
SALE.SALE_ID = SALE_MODEL.SALE_ID
SALE.SALE_TYPE = 'S'
CLIENT.CLIENT_ID = SALE2.CLIENT_ID
Sale2
SALE2.SALE_TYPE = 'S'
22.Modify the definition of the object that is performing multiple aggregations so that it points
to the alias table:
Object
SELECT
Qualification
Sales Revenue
sum(SALE2.SALE_TOTAL)
Measure
199
200
Lesson summary
After completing this lesson, you are now able to:
Understand SQL traps and universes
Resolve fan traps
Resolve chasm traps
201
202
Lesson 8
203
204
The WHERE clause for the query is created from the SQL inferred from the joins made in the
Structure pane:
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)
Compare this with the following report, which is a restricted block containing data only for
clients from the United Kingdom:
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
205
206
You would apply the condition for each year using the database function that applies IF THEN
ELSE logic.
For Sales Revenue 2003, the SELECT statement looks like this:
207
For Sales Revenue 2004, the SELECT statement looks like this:
Note: Many databases support the CASE function. Consult the documentation provided by
your database vendor to see what types of conditional functions are supported.
After you have created or edited the objects, test them individually and together in a single
query. When you view the SQL to check whether the inferred SELECT statement includes the
conditional SELECT syntaxes, the SQL appears as follows:
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.
208
In Web Intelligence Rich Client, the predefined query filter built into the universe can be viewed
in the Report ManagerData tab, identified as predefined query filters.
When you have created a condition object in Universe Designer, test it in Web Intelligence Rich
Client by making a query that uses the filter. View the SQL to check that the inferred SELECT
statement includes the restriction in the WHERE clause and has the desired effect.
209
With this restriction in place, the data returned is 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 is still
applied in the WHERE clause.
210
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
211
only equi-joins, the object is then guaranteed to only return countries in which showrooms
exist.
Instructions
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.
1. Create a Model for Rental dimension object in the Day Rental Charges subclass.
212
This object has the same SELECT properties as the Model object.
2. Add a WHERE restriction to the Model for Rental object so that only models available for rent
are returned. The restriction is:
MODEL.MODEL_DAYRENT IS NOT NULL
3. 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 syntax:
CLIENT.CLIENT_LASTNAME
+ ', ' + CLIENT.CLIENT_FIRSTNAME
Where syntax:
COUNTRY_REGION.COUNTRY_NAME = 'USA'
213
10.Save your universe locally and test each restriction by building a query in Web Intelligence
Rich Client.
11.Run a query using Showroom Country to see the list of countries that have showrooms.
12.In Universe 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 Edit
Properties Definition of the object.
13.Save your universe locally.
14.In Web Intelligence Rich Client, run the above query again and compare the results.
15.In Universe Designer, ensure that the Client Country object only returns 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.
16.Edit the Maker Country object in the same way to ensure that it only returns the countries
in which car makers exist.
17.Edit the Franchise object so that it automatically infers the FRANCHISE context instead of
prompting the user to choose among the SALES, RENTALS, and FRANCHISE contexts.
This allows end users to report on the franchises and their location regardless of sales or
rentals information.
Use the Tables button to highlight the MAKER and FRANCHISE tables.
18.Check the integrity of your universe.
19.Save your universe locally.
214
215
Lesson summary
After completing this lesson, you are now able to:
Restrict the data returned by objects
216
Lesson 9
217
Using @functions
The @functions are located in the Functions panel of the Edit Select Statement and in the Edit
Where Clause dialog boxes for objects.
After completing this unit, you will be able to:
Define @functions
Use the @prompt function
Use the @select function
Use the @where function
Describe the @aggregate_aware 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 find a list of
@functions.
The most commonly used @functions are:
@prompt(,,,,,,)
@select()
@where()
@aggregate_aware(,)
These functions can be applied in the Select and/or Where fields of objects.
@function
@prompt
@select
@where
@aggregate_aware
@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 which the @prompt is specified.
218
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 not want to
preset the value of the condition. For example:
In the example, 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. Therefore,
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 function, you need only one.
@prompt syntax
The @prompt syntax consists of seven parameters, separated by commas:
Prompt.
Data type (A, N, or D).
LOV pointer or hard-coded list.
Mono or multi.
Free, constrained, or primary_key.
Persistent or not persistent.
'Default value':'key value'.
Note: The first two parameters are mandatory, and the remaining parameters are optional.
The first three parameters must be inside single quotes.
219
Prompt
This is the text, or question, that appears in the prompt dialog box when the query is run. The
text must be enclosed in single quotes.
Data type
Data type refers to a character to specify the type of data that is returned:
'A' for alphanumeric
'N' for numeric
'D' for date
The specified character must be enclosed in single quotes.
220
Note: Make sure the syntax parses OK. When inserting the @prompt function in the Select
field, it automatically inserts seven commas. You may need to remove the remaining two
commas in the @prompt syntax.
@prompt syntax, using mono, constrained, persistent:
SHOWROOM.SHOWROOM_NAME =
@prompt('Enter Showroom Name','A',
'Showroom\Showroom',mono,constrained,persistent)
The above example uses the "persistent" option. When refreshing a document, the last values
used in the prompt are displayed by default.
@prompt syntax, using mono, constrained, not_persistent:
SHOWROOM.SHOWROOM_NAME =
@prompt('Enter Showroom Name','A',
'Showroom\Showroom',mono,constrained,not_persistent)
The above example uses the "not_persistent" option. When refreshing a document, no values
used are displayed by default in the prompt.
@prompt syntax, using multi, constrained, persistent:
SHOWROOM.SHOWROOM_NAME IN
@prompt('Enter Showroom Name','A',
'Showroom\Showroom',multi,constrained,persistent)
The above example uses the "persistent" option. When refreshing a document, the last values
used in the prompt are displayed by default. Combining this with the "multi" option allows
the user to select or enter multiple values from the list of values.
221
The above example uses the "not_persistent" option. When refreshing a document, no values
previously used/selected in the prompt are displayed by default in the prompt. Combining
this with the "multi" option allows the user to select or enter multiple values from the list
of values.
@prompt syntax, using mono, and primary_key:
SHOWROOM.SHOWROOM_NAME =
@prompt('Enter Showroom Name','A',
'Showroom\Showroom',mono,primary_key)
The above example uses the "primary_key" option. When prompted the user enters or selects
one value from the list of values, as the "mono" option is used. If the primary_key parameter
is present, the entered or displayed value is not used to generate the query. The associated
key value from the index awareness column is used instead. The function returns an integer
value (index). The primary_key option in the @prompt function needs to be assigned to an
integer or numeric database field, in this example, SHOWROOM.SHOWROOM_ID. This can be done
using index awareness.
If the user selects "Prestige Sports Cars" from the list of values, the SHOWROOM.SHOWROOM_ID
value is used to generate the query:
SELECT
sum(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *(100 - SALE.SALE_DISCOUNT )/100)
FROM
MODEL INNER JOIN SALE_MODEL ON (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID)
INNER JOIN SALE ON (SALE.SALE_ID=SALE_MODEL.SALE_ID)
INNER JOIN SHOWROOM ON (SALE.SHOWROOM_ID=SHOWROOM.SHOWROOM_ID)
WHERE
(SALE.SALE_TYPE='S')
AND (SHOWROOM.SHOWROOM_ID = 2 )
The above example uses the "primary_key" option. When prompted the user enters or selects
one or more values from the list of values, as the "multi" option is used. If the primary_key
parameter is present, the entered or displayed value is not used to generate the query. The
associated key value from the index awareness column is used instead. The function returns
an integer value (index). The primary_key option in the @prompt function needs to be assigned
to an integer or numeric database field, in this example, SHOWROOM.SHOWROOM_ID. This can
be done using index awareness.
If the user selects all showrooms from the list of values, the SHOWROOM.SHOWROOM_ID value
is used to generate the query:
SELECT
sum(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *(100 - SALE.SALE_DISCOUNT )/100)
FROM
MODEL INNER JOIN SALE_MODEL ON (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID)
INNER JOIN SALE ON (SALE.SALE_ID=SALE_MODEL.SALE_ID)
INNER JOIN SHOWROOM ON (SALE.SHOWROOM_ID=SHOWROOM.SHOWROOM_ID)
WHERE
222
(SALE.SALE_TYPE='S')
AND (SHOWROOM.SHOWROOM_ID IN (1, 2, 3) )
When prompted the user enters or selects one or more values from the list of values, as the
"multi" option is used. If the primary_key parameter is present, the entered or displayed
value is not used to generate the query. The associated key value from the index awareness
column is used instead. Not_persistent is used, and no values previously used/selected in
the prompt are displayed in the prompt. Instead, when refreshing the report, the values
specified in the "default value" option are displayed.
If the user selects all showrooms from the default values in the list, the SHOWROOM.SHOWROOM_ID
value is used to generate the query:
SELECT
sum(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *( 100 - SALE.SALE_DISCOUNT )/100
)
FROM
MODEL INNER JOIN SALE_MODEL ON (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID)
INNER JOIN SALE ON (SALE.SALE_ID=SALE_MODEL.SALE_ID)
INNER JOIN SHOWROOM ON (SALE.SHOWROOM_ID=SHOWROOM.SHOWROOM_ID)
WHERE
(SALE.SALE_TYPE='S')
AND (SHOWROOM.SHOWROOM_ID IN (1, 2, 3) )
@select
The @select function is a pointer to the Select field properties of another object. It is used by
placing the @select in the Select field of the Edit Properties dialog box of an object, using the
following syntax:
@select(path of existing object)
223
This example shows how the @select works. The code in the SELECT properties of the Model
object is:
MODEL.MODEL_NAME+' '
+ MODEL.MODEL_TRIM+' '+MODEL.MODEL_ENGINE
If you wish to create a new object called Model for Rental with the same code, rather than
creating the same code twice, you can refer to the original Model object via the @select function:
@select(Car\Model)
224
The benefit is that a dynamic link is created between the objects. When changes occur in the
SELECT statement of the original object, the changes are reflected in the SELECT statement of
any other objects that refer to it via the @select function. Therefore, when you change the code,
you only change it once in the original object.
@where
The @where function is a pointer to the WHERE 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)
For example:
225
This example shows how the @where works. The code in the WHERE syntax of the Model for
Rental object is:
MODEL.MODEL_DAYRENT IS NOT NULL
AND SHOWROOM.SHOWROOM_NAME = @prompt('Enter Showroom Name',
'A','Showroom\Showroom',mono, constrained)
If you wish to create a new object called Showroom Rental Model that has to contain the same
WHERE syntax, rather than creating the same code twice, you can refer to the original Model for
Rental object via the @where function:
@where(Day Rental Charges\Model for Rental)
226
The benefit is that a dynamic link is created between the objects. When changes occur in the
WHERE clause of the original object, the changes are reflected in the WHERE clause of any other
objects that refer to it via the @where function. Therefore, when you need to change the syntax,
you only change it once in the original object.
Note: You can use the @where function in a condition object to point to an object, but not the
other way around.
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.
There are further benefits for using the @where function. 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
WHERE restriction object strategy to make the most efficient use of that restrictions code.
227
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 original objects,
whenever a restriction is required, you point to the appropriate WHERE restriction object using
the @where function.
In the previous example, you can see that two WHERE clause restriction objects have been created
that contain only a name and WHERE clause restriction, as follows:
Rental model
MODEL.MODEL_DAYRENT IS NOT NULL
Showroom choice
SHOWROOM.SHOWROOM_NAME
= @prompt ('Enter Showroom Name','A',
'Showroom\Showroom',mono, constrained)
Note that each of these restriction 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 the WHERE syntax.
Also, by specifying each restriction in a separate WHERE clause restriction 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 Where clause restriction 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 WHERE clause
restriction objects from end users.
The Where clause restriction 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.
To hide the class containing all the Where clause restriction objects
from end users
1. Click the class or object you want to hide.
2. There are different ways to hide classes and objects:
Select the Show or Hide Item button on the Edit menu.
Right-click the object or class and select Hide Item(s) from the drop-down menu.
Use Ctrl+Shift+H.
Hidden classes and objects appear in italics in the Universe Designer Universe pane.
They are not shown at all in Business Objects end-user querying tools.
228
@aggregate_aware
Some databases contain summary tables. 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 fact/event 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.
Run a SELECT statement for the summary data.
Where possible, it is best to choose the latter method as the statement processes quicker.
In Universe Designer, you can use a function called @aggregate_aware in the SELECT statement
for an object, so that both methods are referenced. This function directs a query to 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 directs the query to run against the
tables containing the non-aggregated data.
A universe that has one or more objects with alternate 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.
When you apply the @aggregate_aware function, be aware of the available levels, and be clear
about the descending order of aggregation.
Each aggregation level SELECT statement is separated by a comma, and the entire expression
is enclosed in brackets. The final SELECT statement must be valid for all queries.
@aggregate_aware(<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>)
229
Instructions
Continue to work with the Model for Rental dimension object that you created in the Day
Rental Charges subclass. This object returns all models available for rental. This is to be used
by sales staff and requires further restriction to a specific showroom.
1. Add the following @prompt syntax in the WHERE clause of the Model for Rental dimension:
SHOWROOM.SHOWROOM_NAME = @prompt
('Select showroom name','A','Showroom\Showroom',mono,constrained)
Note: When inserting the @prompt function, it automatically inserts seven commas. You
may need to remove the remaining two commas in the @prompt syntax, to make the syntax
work correctly.
Note: Parse the syntax. Parse fails as there is no SELECT statement defined in the object.
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 clause 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 a new class called Where Restriction Objects.
5. Create two new objects to go into the Where Restriction Objects class as follows:
Rental Model containing the restriction:
MODEL.MODEL_DAYRENT IS NOT NULL
Note: When inserting the @prompt function, it automatically inserts seven commas. You
may need to remove the remaining two commas in the @prompt syntax to make the syntax
work correctly.
Note: Parse the syntax. Parse fails as there is no SELECT statement defined in the object.
6. Hide the Where Restriction Objects class.
7. Edit the following object and condition object so that the WHERE clause of each contains no
SQL code, but instead uses @where functions to point to the WHERE clause restriction objects.
230
Model for Rental object inherits the Rental Model objects WHERE clause.
Showroom Rental Model condition object inherits the Showroom Choice objects WHERE
clause, and it should also point to the Rental Model object in the same hidden class to
ensure they are rentals that are returned.
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.
Note: The Integrity Check dialog box alerts you regarding the two hidden objects.
10.Save your universe locally.
Note: Remember to test your solution in Web Intelligence Rich Client.
231
232
Lesson summary
After completing this lesson, you are now able to:
Use @functions
233
234
Lesson 10
Using Hierarchies
Lesson introduction
Hierarchies allow you to organize dimension objects so that users can perform multi-dimensional
analysis using drill mode in end-user queries.
After completing this lesson, you will be able to:
Understand hierarchies and universes
Work with hierarchies
235
Hierarchies
A hierarchy is an ordered series of related dimension objects that are used for multi-dimensional
analysis. For example, a geographical hierarchy could group together dimension objects such
as Country, Region, and City.
Multi-dimensional analysis is a technique for manipulating data so that it can be viewed from
different perspectives and at different levels of detail. In Business Objects end-user querying
tools, 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 sees 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 towns. A user can then analyze a measure object, such as Sales Revenue, against
any of the levels in the hierarchy.
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, and Street.
Year, Quarter, Month, Week, and Day.
Logical hierarchies
BusinessObjects hierarchies are not restricted to natural hierarchies. You can construct a
hierarchy from any related group of dimension objects that create a sensible analysis path.
The relationship between the dimension objects in a hierarchy normally are one-to-many as
you descend through the levels.
236
For example, one country has many towns; one town has many showrooms; one showroom
has many franchises.
237
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 Business Objects end-user
querying tools 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.
Using this method of organizing your dimension objects in their classes is the key to setting
up usable default hierarchies.
238
You cannot add or remove objects from classes in the Hierarchies Editor.
You can use the Hierarchies Editor to create custom hierarchies.
2. Click the + box 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.
239
The Scope of Analysis pane allows users to set up the query for drill analysis. All the
dimensions selected for the query are highlighted here, within their default hierarchies. In
order to allow users to drill down the hierarchy from one level to another, without having
to modify the query, you can set the scope of analysis before the query is actually executed.
Note: You can manually drag the objects you want to drill down to in this pane. In this
case, the Custom value appears in the Scope of Analysis level drop-down list.
5. To define default levels of scope of analysis, select the level drop-down list in the Scope of
Analysis, and click the arrow to select the scope of analysis levels.
The levels you define in the scope of analysis determines how many objects from the
hierarchy is included in the query, and therefore how many levels of detailed data is returned
in the Web Intelligence Rich Client document.
240
9. Move the mouse pointer over a value in the dimension object column.
A flag appears indicating the next level of data available from the hierarchy.
10.Double-click to drill down. The data in the measure column is aggregated to reflect next
level drill-down figures.
11.Drill down and up as you wish to explore the data available in the documents microcube.
Custom hierarchies
A custom hierarchy combines objects from default hierarchies to build a custom analysis path.
Default hierarchies are based on the order of the dimension 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 Motors universe wanted to look at Sales Revenue from the point
of view of Client/Area and Financial Period, they would not be able to do this using the default
hierarchies.
241
As universe designer, you can build a permanent custom hierarchy as part of the universe. As
a result, the hierarchy is available across documents to all users.
In the analysis phase of the universe development process, the designer identifies those custom
hierarchies that are to be used regularly and creates them in Universe Designer as permanent
custom hierarchies.
242
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
selection list.
243
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 the user module is the one that is higher
in the list (if dimensions from both hierarchies are included in the query). You can alter this
default priority by changing the order of the hierarchies in the Custom Hierarchies list. 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.
4. Save the universe.
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.
244
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.
When you create a time hierarchy, you are still creating a default hierarchy, in which the levels
depend on the order of the dimension objects. You create the standard time structure by ordering
the objects Year, Quarter, Month, and Week. The only difference with time hierarchies is the
way in which you create the objects.
245
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.
In the Universe pane, the original date object 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 + box to view and check the objects attached to the date object.
Note: You can see that the arrangement of the objects is not as you might expect. The original
date object 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 + box 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.
9. Double-click one of the automatically created time dimension objects (year, quarter, or
month) to view the Edit Properties dialog box for the object.
246
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.
10.Click OK to close the Edit Properties dialog box.
11.Click the Hierarchies toolbar 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, and another bearing the name of the class
appended with the name of the original date object.
12.Click the + box next to 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.
14.Save the universe.
247
This 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
It is a fairly quick and easy way to set up a time hierarchy.
Automatically creates the SQL SELECT statement 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
Universe pane.
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.
An LOV can only be applied to the original date 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.
248
Repeat the remainder of this procedure 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 pane 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.
Change the object name to reflect the scalar function used.
Change the data type if required, depending on the scalar function used.
Change the SELECT statement to the relevant scalar function, string conversion, and
required concatenated string value, depending on the RDBMS used.
Clear the Associate list of values check box, if not required.
5. Click OK to close the Edit Properties dialog box.
6. Repeat steps 2 to 5 for each of the other time objects required within the class based on scalar
functions.
Tip: As 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.
7. The Universe pane now contains a class or subclass as in the following example:
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.
249
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.
Another way of creating time dimension objects is to add a time-range table to the database
with columns and data as in the following example. 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.
250
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 SQL statement.
251
Instructions
1. To view all hierarchies, click the hierarchy button. Remove all custom hierarchies in the
Custom selection list.
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 your universe locally, and then test the default hierarchy in Web Intelligence Rich
Client.
4. Create the following dimension objects using the automatic time hierarchy method: Sale
Year, Sale Quarter, and Sale Month.
5. Save the universe locally, and then test the resulting hierarchy in Web Intelligence Rich
Client.
When you run the query, view the SQL and note the scalar function used.
6. Using the automatic time hierarchy method poses some limitations.
Remove the automatically created Sale Year, Sale Quarter, and Sale Month objects, and
replace them with manually created objects, using numeric database scalar functions:
Sales Year:
{fn year(SALE.SALE_DATE)}
Sales Quarter:
{fn quarter(SALE.SALE_DATE)}
Sales Month:
{fn month(SALE.SALE_DATE)}
7. Create the following dimension objects manually in the Rental Dates subclass, using
alphanumeric database scalar functions and formatting: Rental Year, Rental Quarter, and
Rental Month.
Rental Year:
'Calendar Year ' +
datename(YYYY,RENTAL.SALE_DATE)
Rental Quarter:
'Q ' + datename(Q,RENTAL.SALE_DATE)
Rental Month:
datename(mm,RENTAL.SALE_DATE)
252
8. Check that the order of the dimension objects in the Financial Period class is based on time.
9. Save your universe locally, and test the resulting hierarchies in Web Intelligence Rich Client.
10.Prestige Motors wants to analyze clients geographically (by Country, Region, and Town)
but then further analyze the breakdown of client expenditure by financial year.
Create a custom hierarchy to allow users to do this by including the Country, Region, Town,
and Financial Year objects in the hierarchy.
11.Make the following default hierarchies available to the user:
Car
Day Rental Charges
Showroom
Financial Period
Rental Dates
Sale Dates
12.Save your universe locally, and test the resulting hierarchy in Web Intelligence Rich Client.
13.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
14.Save your universe locally, and then test the resulting hierarchy in Web Intelligence Rich
Client.
253
254
Lesson summary
After completing this lesson, you are now able to:
Understand hierarchies and universes
Work with hierarchies
255
256
Lesson 11
257
258
259
3. If you want to turn off the LOV for this object, click the Associate a List of Values check
box to clear it.
The name of the LOV file is the same name as shown in the List Name field, in the Properties
tab.
As a designer, you can edit the list name to call the file anything you want (over 100 characters
long), provided that the file ends in an .lov extension. Clicking the Restore Default button
changes the name back to the default file name.
260
Delegate search
The delegated list of values search allows you to delegate the search of values in an LOV to
the database.
This feature:
Prevents the LOV from loading automatically.
Restricts the data set returned.
Improves performance by limiting the load time.
Instead, the report user can perform a search for a pattern within the database.
This option can be helpful when using an SAP BW data source. An SAP BW query can contain
more than ten variables, which means that ten or more lists of values can be loaded. Loading
and refreshing lists of values can have an important impact on performance.
261
The Delegate Search option on the list of values properties presents the user with an empty
list of values at query run time. The user enters search criteria to limit the number of values
returned in the list of values.
Note: The Delegate Search option is not supported for cascading lists of values.
262
3. Click the + box next to each class name displayed to see the objects in this universe that
have an LOV associated with them.
4. Select an object from the list.
5. Click Display.
The list of values for the selected object displays.
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.
263
264
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.
Users can create a query that builds one of the objects into a prompted query filter. The Prompts
dialog box displays the list of values for all the objects you placed in the cascading LOV in
Universe Designer, in reverse order.
265
266
Instructions
1. In Universe Designer, create a cascading LOV using the Maker, Category of Car, and Model
objects in the Car class.
2. Save your universe locally.
3. Build a query in Web Intelligence Rich Client 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.
Note: At the end of this activity, please remove the Cascading List of Values using the
following steps:
In Universe Designer, change the object definition to associate a standard list of values
for all objects in the Car class.
Save your universe locally.
267
268
Lesson summary
After completing this lesson, you are now able to:
Create a list of values
Work with LOVs in Universe Designer
Create a cascading LOV
269
270
Lesson 12
271
272
Note: When using an aggregation function, or any other SQL function in the SQL syntax,
it is important to alias the column that contains the calculation. Universe Designer uses
these aliases as the column names in the derived table.
4. Click Check Syntax to parse and validate your SQL.
5. Click OK.
The derived table appears in the schema, below the original physical database table, at the
bottom left corner.
Tip: Use List Mode to locate your derived table.
6. Join the table to a table in the existing schema.
If contexts have been applied to the schema, make sure the newly inserted join is included
in at least one context.
7. Build objects based on the derived table columns in exactly the same way you do with
regular tables.
8. Save the universe.
273
The derived table acts as a shortcut between the Client and Model table. The SELECT, FROM and
WHERE syntax therefore needs to contain the following:
SELECT CLIENT.CLIENT_ID,MODEL.MODEL_ID
FROM CLIENT, MODEL,SALE,SALE_MODEL
WHERE CLIENT.CLIENT_ID = SALE.CLIENT_ID
AND MODEL.MODEL_ID = SALE_MODEL.MODEL_ID
AND SALE_MODEL.SALE_ID = SALE.SALE_ID
The Rental table is in fact an alias table of the Sale table and cannot be referenced in the derived
table. To get the sale and rental values for Sale.Sale_Total, you need to use the Sale.Sale_Type
column that indicates which row is sales and which row is rental data.
274
The data for sales and rentals have been combined into a derived table. After joining the table
as shown in the diagram and creating a new context, and new objects, users can run a new
report in Web Intelligence Rich Client using the Client Name object from the Client table,
together with the Sales Total and Rental Total objects from the derived table. The data is returned
as one SQL statement and displays in one table.
When a query returns a joined SQL statement, the rows where there is no equivalent data are
returned as empty cells. These cells cannot be filtered on, as technically, they do not exist. Using
the derived table method, the cells where there is no data returns a value of zero. This means
that a quick filter can be used.
Allowing the user to return the clients that have both rental and sales values in a single SQL
statement.
Note: If you use derived tables to create different aggregation levels, be careful to consider the
impact on joins, contexts, and many-to-many relationships.
275
276
The Derived Tables editor opens and the center pane at the bottom of the Derived Tables
editor lists the available derived tables.
3. Type the name of your nested derived table.
4. Add the required SQL syntax for the nested derived table using one of the following methods:
Type the SQL expression. You can type the entire text or use the editor assistants.
Double-click on the objects (tables, derived tables, columns, functions). When clicking
on an existing derived table name, the @DerivedTable function is inserted automatically.
Use the @DerivedTable function with the syntax: @DerivedTable(Derived_table_name)
to choose a derived table.
5. Click Check Syntax to check the syntax of your derived table and correct any potential
errors, then validate your nested derived table.
The nested derived table is added to the universe.
6. Click OK to validate your nested derived table.
The nested derived table appears in the universe Structure pane. Derived tables and nested
derived tables are lighter in color than tables that represent actual database tables.
Note: To display the table values, right-click the different tables.
277
Instructions
1. Using your Motors universe, insert a derived table to show the number of transactions per
customer.
2. Name the newly derived table DT_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
7. Add the Number of Transactions object to the Client class. Define the object as a measure
object, and ensure the Associate a List of Values option is cleared.
8. In Universe Designer build a nested derived table, called DT_Nested, using the following
syntax:
SELECT DT_Best_Cust.CLIENT_ID,CLIENT.CLIENT_LASTNAME,
sum(DT_Best_Cust.Number_of_transactions)as Total_Transactions
FROM @DerivedTable(DT_Best_Cust),CLIENT
WHERE DT_Best_Cust.CLIENT_ID=CLIENT.CLIENT_ID
GROUP BY DT_Best_Cust.CLIENT_ID,CLIENT.CLIENT_LASTNAME
278
Tip: Every join (except shortcut joins) must exist in at least one context.
10.Add the Total_Transactions object to the Client class. Define the object as a measure object,
and ensure the Associate a List of Values option is cleared.
11.Save your universe locally.
12.In Web Intelligence Rich Client, build:
A report that shows the number of transactions per customer and the number of
transactions per country.
A report that shows the total transactions and sales revenue, per customer and per
country.
279
280
To build this report in Web Intelligence Rich Client, you would drag the Maker and Highest
Priced Value objects into the Result Objects pane in the Report Panel. Then, drag the Maker
Country object into the Query Filters pane and restrict the countries to the United Kingdom
and the United States.
Without index awareness, Universe Designer generates the following SQL:
SELECT
MAKER.MAKER_NAME,
max(MODEL.MODEL_PRICE)
FROM
MAKER,
MODEL,
COUNTRY COUNTRY_MAKER
WHERE (MODEL.MAKER_ID=MAKER.MAKER_ID)
AND (MAKER.COUNTRY_ID=COUNTRY_MAKER.COUNTRY_ID)
AND COUNTRY_MAKER.COUNTRY_NAME In
( 'United Kingdom','USA' )
GROUP BY
MAKER.MAKER_NAME
In this case, Universe Designer has created a join to the Maker Country table in order to restrict
the countries retrieved.
With index awareness, you can tell Universe Designer that Country_ID is the primary key of
the Country_Maker table and that it also appears in the Maker table as a foreign key. Using
this information, Universe Designer can restrict the countries without joining to the
Country_Maker table.
In this case, Universe Designer is able to generate SQL that restricts the countries simply by
filtering the values of the Country_ID foreign key.
After setting up index awareness for Maker Country, Universe Designer generates the following
SQL, where 44 is the United Kingdom Country_ID value and 1 is the USA Country_ID
value:
SELECT
MAKER.MAKER_NAME,
max(MODEL.MODEL_PRICE)
FROM
MAKER,
MODEL
WHERE (MODEL.MAKER_ID=MAKER.MAKER_ID)
AND
MAKER.COUNTRY_ID In ( 44,1 )
GROUP BY
MAKER.MAKER_NAME
281
awareness option can be used to determine which column to choose as an alternative based
on database schema knowledge and the RDBMS optimizer.
The LOV values that end users select actually tell Business Objects what primary key values
to substitute in final query SQL. The Keys tab tells Business Objects which SQL syntax to
substitute in the final query SQL.
3. Click Insert.
A key line is inserted in the list of keys field.
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.
282
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 SQL Editor to build the primary key
SQL SELECT clause or type it directly.
5. Select Enable.
6. Click OK.
7. Save the universe.
Instructions
1. Using the Client Country object in your Motors universe, enter the following under Keys:
Primary key
COUNTRY_REGION.COUNTRY_ID
WHERE
COUNTRY_REGION.COUNTRY_ID = CLIENT.COUNTRY_ID
283
3. Create a query in Web Intelligence Rich Client with Client Country and Client Name.
4. Apply a query filter, and use the Value(s) from list option to restrict the data to a single
country, such as the United States.
5. View the SQL.
Notice that the WHERE clause no longer uses the COUNTRY_REGION.COUNTRY_NAME
= USA statement (or whichever country you specified). It uses CLIENT.COUNTRY_ID =1.
284
285
Lesson summary
After completing this lesson, you are now able to:
Use derived tables
Apply index awareness
286
Lesson 13
Linking Universes
Lesson introduction
Using Universe Designer, you can choose to link universes so that they share common
components such as parameters, classes, objects, or joins.
After completing this lesson, you will be able to:
Understand linked universes
Create links between universes
287
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.
288
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.
If you need to create the same universe twice with different universe IDs or connections
(master approach).
289
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).
290
Key advantages
The key advantages of linking universes are:
Reduced development and maintenance time.
The universe objects and structure are created only once, and only one instance of an object
needs to be maintained. The derived universe(s) is 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.
Limitations
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.
In a production environment, the core and derived universes must be in the same repository.
The core universe needs to have been exported before the derived universe.
Restrictions
You need to be aware of the following restrictions when linking universes:
You can use only one level of linking. You cannot create derived 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 naming conflicts occur and Universe Designer renames objects from the
source universe.
The two universe structures must be joined to avoid Cartesian products resulting from
end-user queries containing objects from both structures.
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 is used, therefore no aliases are created. All joins will be placed on the new
table, assuming it is coming from the same database.
291
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.
A core universe has to be exported to the Central Management System (CMS), before you can
link it in any derived table. If the core universe has not been exported, it does not appear in
the list of available universes in the Universe Parameters Links tab.
In order to link universes, the derived universe (the universe for which you want to receive
the duplicated objects and structure), has to be open in Universe Designer. Using the Link
feature, you select the core universe file. When the link is established the contents of the core
universe are added to the open derived universe file.
292
4. In Universe Designer, open the universe file that you want to become the derived universe.
5. Access the Parameters menu using one of the following methods:
Click the Parameters toolbar button.
Select File Parameters from the menu bar.
6. Click the Links tab.
7. Click Add Link.
The Universe to Link dialog box opens. It points to the default universe location, (for
example: C:\Documents and Settings\<user_name>\Application Data\Business
Objects\Business Objects 12.0\Universes\@<server_name>\).
8. Select the core universe you want to link.
9. Click Open.
The Links tab of the Universe Parameters dialog box appears.
10.Click OK.
The two universes are now linked. The tables and joins in the structure and the classes and
objects of the linked universe are grayed out, thus indicating that they reside in the source
universe and cannot be edited in the derived universe.
11.Set the joins between the two structures to avoid potential Cartesian products.
12.Remove existing contexts.
13.Detect aliases.
14.Detect contexts and customize them, if required.
15.Hide/create new objects as required.
293
16.If you are using aggregate awareness, be sure to specify whether the objects pointing to the
new tables are compatible with existing summary tables.
17.Save the changes in your universe and export the linked universe to the Central Management
System (CMS).
To include a universe
The procedure for including is the same as for linking except that after selecting the universe
to link, and before confirming the selection in the Links tab, you perform these steps instead:
1. In the Links tab of the Universe Parameters dialog box, click the universe name in the Name
field.
The Include button becomes active.
294
2. Click Include.
The core universe content is copied into the derived universe as shown.
295
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.
Most 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.
Instructions
Business requirement: Prestige Motors management wants to report on the sales performance
of its sales staff and their managers.
Use your Motors and Staff universes for this activity.
1. Export your Staff universe to the Central Management System. Go to File Export and
browse to the location specified by the instructor.
2. Open your Motors universe in Universe Designer. This is your derived universe.
3. Make room in the upper left corner of the Structure pane in the Motors universe.
296
To do this, click in any white space in the Structure pane, click Select All from the Edit
menu and then drag the tables to the right of the pane.
4. Link the structure and objects of your Staff universe in your Motors universe.
5. Place the Staff table structure in the top left-hand corner of your Motors universe structure
and insert a join between the EMPLOYEE and CLIENT tables as follows:
EMPLOYEE.EMP_ID = CLIENT.EMPLOYEE_ID
9. Save your Staff universe, export it to the same location as in step 1, and close it.
10.Open your Motors universe and check that the change in your Staff universe is reflected.
11.Change the Link to Include.
12.Save and export your Motors universe to the same location as in step1.
13.Test the results in Web Intelligence Rich Client.
Note: The exported Motors universe appears as normal text format in Web Intelligence
Rich Client.
297
298
Lesson summary
After completing this lesson, you are now able to:
Understand linked universes
Create links between universes
299
300
Lesson 14
301
302
You assign a restriction set to a Business Objects user or group. This limits the access to universe
objects or resources based on the profile of the user group.
Description
Connection
Query controls
Object access
Row access
303
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.
The options available for managing access restrictions on this universe are described in the
table below:
Restriction option
Description
New
Edit
Priority
Preview
304
Restriction option
Description
Delete
Restriction options
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.
305
The six tabs in this dialog box allow you to define the type of restriction you want to include
in this restriction set.
Caution: The Reset button at the lower left corner resets every change made in any tab. It
resets all options back to the defaults.
4. In the Restriction Name field, type the name you want to apply to the 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.
306
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.
7. Click the SQL tab
The SQL tab displays.
307
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.
8. If you have completed your restriction set, click OK to save the changes, otherwise navigate
the remaining tabs to apply further restrictions.
Note: Changes made in any of the first three tabs, display in red. This helps designers identify
and track any changes made by other designers.
Caution: The Reset button at the lower left corner resets every change made in any tab. It
resets all options back to the defaults.
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.
2. In the Objects tab of the Edit Restriction dialog box, click Add.
308
Note: If you are sure of the name of the object you want to restrict, you can type it in the
Object Name field 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 the + box next to a class folder to view its contents.
The 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. Select the object that you want to restrict and click OK.
309
The name of the subclass and object you selected appears in the New Restricted Object
dialog box.
6. Click OK.
The Objects tab of the Edit Restriction dialog box now displays the object you selected in
the list.
310
10.If you have completed your restriction set, click OK to save the changes, otherwise navigate
the remaining tabs to apply further restrictions.
311
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.
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 Table and Where Clause values, you can type them
directly in the fields. Otherwise, continue to step 3.
3. Click the >> button to the right of the Table field.
The Table Browser displays, listing all the database tables referenced in this universe.
312
6. In the New Row Restriction dialog box, click the >> button to the right of the Where Clause
field.
The Where Clause Definition dialog box displays.
7. Type the appropriate WHERE clause in the text box (or build the statement using the tables,
columns, operators, and functions available) to restrict the data.
8. Click OK to close the Where Clause Definition dialog box.
The table and WHERE clause appear in the New Row Restriction dialog box.
313
The status of the table and WHERE clause you created appears as OK.
11.If you have completed your restriction set, click OK to save the changes, otherwise navigate
the remaining tabs to apply further restrictions.
Note: Plan and test your row restrictions very carefully. Row restrictions are only applied if
the table is actually invoked in the SQL statement generated by the universe. With aggregate
awareness, for example, the resultant SELECT clause of an object might not include the table
with the restricted column.
314
In this tab, you can define the replacement of a table referenced by an object in the universe
by another table for a specific user or group of users.
2. Click Add in the Table Mapping tab.
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.
4. If you have completed your restriction set, click OK to save the changes, otherwise navigate
the remaining tabs to apply further restrictions.
315
Restrictions are applied by assigning a restriction set to selected users or groups. This assignment
is made in the Universe Designer, while the users and groups are created in the Central
Management Console.
316
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 by using the search functions
shown in the bottom left-hand corner of the dialog box.
2. Scroll down in the Available groups and users list until you see the individual user or group
you want to restrict.
Note: Users are identified in this list with an icon representing a single individual head;
groups of users are identified with two individual heads.
3. Double-click the appropriate user/group, or click the user/group and use the >> button to
move the group or user into the Selected users and groups list.
4. Click OK to confirm and close the Select Users and Groups dialog box.
The user/group appears in the Available groups and users list in the Manage Access
Restrictions dialog box.
Note: This list shows that no restriction has been assigned to this group yet. You need to
now assign a restriction to the selected user group.
5. In the Manage Access Restrictions dialog box, ensure that both the appropriate user set
and user group are selected.
6. Click the >>Apply button.
317
The restriction set now appears in the list next to the name of the individual user or user
group.
318
3. Select a user or group, and click the Move Up or Move Down buttons to change the priority
level.
4. Click OK.
319
When selecting the Preview Net Access Restrictions option from the Tools menu, you can
view the net result of combining all security restrictions for a user or a group, and all parent
groups.
320
The same Restriction Preview dialog box displays, allowing you to view the restrictions
for the selected group.
Instructions
1. You must export the universe before you can create security restrictions. Click File Export.
In the Export Universe menu click Browse and select the folder to export to, as specified
by the instructor.
2. In your Motors universe, create a restriction set called Sales_only with the following
restrictions:
Set the value of Limit size of result set to to five rows.
Restrict all objects in the staff class.
Add a row restriction with a WHERE clause definition SHOWROOM.COUNTRY_ID = (44).
3. Apply this restriction set to the sales user. Check with the instructor for the exact user name
to use.
4. Preview the restriction to check that it is correct.
5. Save your universe and export it to the same location as in step 1.
6. Log onto Web Intelligence Rich Client with the sales user account. Check with the instructor
for the exact user name to use.
7. Create a new report based on your Motors universe.
8. Verify that:
Any query only returns 5 rows.
The employees objects are not visible.
No sales data for UK showrooms is returned.
321
322
Lesson summary
After completing this lesson, you are now able to:
Set access restrictions on a universe
323
324
Lesson 15
Managing Universes
Lesson introduction
This lesson describes how to manage universes.
In deploying, managing, and maintaining universes, you ensure that the end users in your
organization have access to the universes they need to build reports.
After completing this lesson, you will be able to:
Document universes
Deploy universes
Maintain universes
Deploy universes in multiple languages
325
Documenting universes
As you build a universe that reflects the reporting needs of the end users in your organization,
you probably want to document the progress of the universe design project.
You can use the print function in Universe 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.
After completing this unit, you will be able to:
Print lists of different universe components
Print details concerning each of the universe components
326
Tip: 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, and print again.
Note: The Scale setting governs 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 occur, you can preview the page layout.
327
Parameters
Linked Universes
Graphical Structure
Scale
328
329
Deploying universes
After you have completed the universe, have a small team of experts test it rigorously before
distributing it 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 end users or other report designers. This is known
as deploying the universe.
After completing this unit, you will be able to:
330
On your local machine, the universe .unv file is transferred to the default universe location,
for example (or if it is already located there, the .unv is updated with the new version):
\\Documents and Settings\<username>\Application Data\ Business
Objects\BusinessObjects 12\universes\@<repository name>\ universe
folder\<universe>.unv
where @<repository name> is the name of the repository the universe is 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 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). In the CMS, a BusinessObjects
administrator can change the universe name and description, move its location, and define
user access rights for 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 BusinessObjects end 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.
LOV files are stored in a folder with the same name as the universe file at the same level as the
universe.
331
The universe is also stored on the CMS, so that other designers can import it, and users can
use it to create reports.
When you import a universe from the CMS, the .unw file stored in the FRS file system. Then
the CMS InfoObject is converted to a .unv file and transferred to the local machine in the same
folder shown above.
332
2. Select a folder from the Domain 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.
3. Click a group in the Groups list dialog box.
This is the user group that is allowed to use the exported universe to create reports. 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 selection list.
The Universes selection list shows the names of the active universes.
333
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.
Note: The universes that are added would need to have a valid secured connection before
being able to export them.
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 designer, 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 designer
in the CMS 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 store in the FRS file system and the
InfoObject from the CMS are then converted to a .unv file and transferred to the default local
machine location, for example:
\\Documents and Settings\<username>\Application Data\
Business Objects\BusinessObjects 12.0\universes\@<repository name>\
universe folder\<universe>.unv
where @<repository 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.
334
2. Select a universe folder from the Folder drop-down list , or click the Browse button to select
a universe using the folder browser.
This is the folder where the universes are exported to.
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 where the universe is copied.
5. Click OK.
335
If you try to export a new universe with the same name as an existing universe, Universe
Designer displays a message asking you if you want to overwrite the existing universe.
You can also lock a universe so that only one designer at a time can make modifications on the
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.
336
A padlock icon appears beside the universe file name to indicate that the universe has been
locked.
337
Maintaining universes
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.
After completing this unit, you will be able to:
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
Greater impact
Renaming/moving database
338
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 options are useful.
The procedure for invoking these functions is set out below. Dont forget the Check Integrity
option. 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 produces 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 also edit the structure.
Again, in both instances, the Refresh Structure, View Associated Objects options, and
Integrity Check are useful.
339
Universe Designer updates the Structure pane, 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.
3. Update the universe as necessary to reflect the changes in the database structure.
340
Minimal Impact
Greater impact
Renaming an object
341
Translation Manager
Translation Manager is a product that allows Web Intelligence report designers and consumers
to build queries and to display content and text strings in Web Intelligence documents using
their preferred language.
This product is most useful in the context of worldwide BusinessObjects deployments. Instead
of having to duplicate universes and documents for each required language, the customer can
use Translation Manager to translate the metadata only once. The translated strings are stored
in the universe and in the resulting documents. This means customers can make significant
savings in development time and maintenance.
Translation Manager allows customers or their translation service providers to translate the
metadata stored in a Business Objects universe. The translated character strings are then stored
in the universe file. When a report designer creates a Web Intelligence document and retrieves
data using this universe, all translatable content is stored in several different languages in the
single Web Intelligence document.
The language chosen to display the document in the end user's web browser is dependent on
the language defined in the user's preferred viewing locale setting in InfoView (My Preferences
General Preferred Viewing Locale ) or in the Internationalization settings in Web
Intelligence Rich Client (Tools Options Locale).
If the user's Preferred Viewing Locale or Internationalization settings are set to a language that
does not exist in the Web Intelligence document, then the data is displayed using the default
language instead. This default language value is defined when the universe data is translated
Note: Translation Manager does not allow you to translate the data retrieved by the query.
This is dependent on the database. A multilingual database is required to display the report
data in multiple languages.
Translation Manager is an application that allows customers to:
Store in a single document all translatable content in several different languages.
Enable end users to display content and strings in Web Intelligence documents according
to their preferred language.
342
343
344
9. By highlighting one of the translated terms in the Category View pane, you can view and
edit the status in the Properties zone.
These values allow you to track the translation process and flag different terms as validated
or not. Select the appropriate status for each edited field.
10.Before you can use the translated universe to build a query in Web Intelligence or Web
Intelligence Rich Client, the translated universe needs to be set to Ready for use status. In
the Selected Languages pane select the Ready for use checkbox for each of the translated
languages.
11.Save the translated universe locally, or save and export the universe back to the CMS.
To save the translated universe locally:
1. Click File Save As and save the universe in the local universes folder.
To save and export the translated universe to the CMS:
1. Click File Save.
2. Click File Export to CMS.
3. In the Export Universe/Webi Document to CMS dialog box, specify the location in
the CMS where the universe is to be exported. Click Export and OK.
12.Close Translation Manager.
345
Instructions
1. In Universe Designer, import your Motors universe and save it locally.
2. Launch Translation Manager.
3. Click File Open.
346
French
German
Client (class)
Client
Kunde
Client Name
Nom de client
Client Country
Pays
Land
Client Town
Ville
Stadt
Sales Revenue
Chiffre d'affaire
Umsatz
347
348
Lesson summary
After completing this lesson, you are now able to:
Document universes
Deploy universes
Maintain universes
Deploy universes in multiple languages
349
350
Appendix A
End-of-Course Challenge
Completing the end-of-course challenge
A customer has called you in to provide a Proof of Concept using a sample of their data to
ensure they are purchasing the correct product. Taking into account the complete product line
of BusinessObjects products, you need to identify which tools would be best for the customer,
not necessarily just the ones used in this challenge, but you do not need to go into any great
detail on additional products.
In this workshop you edit and expand your Motors 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.
Designing a universe is not just about using the Universe Designer module. Careful planning
needs to take place before you as a designer even think about starting up the Universe Designer
module. While working through the challenge, you need to consider each of the five stages in
the Universe Development Cycle process:
Preparation
Examine the database schema, maybe breaking it down into areas which cover particular
departments to identify which tables need to be used to satisfy the HR department's
requirements.
Analysis
You require a detailed analysis of the precise information required by the users in each of the
departments. There are a number of reports that have been identified. The focus must be on
the business language users use to describe the information they require. This can then be used
in the universe design.
351
Maintenance
When a universe has been distributed to the users, the designer is responsible for updating
and maintaining the universe. This means keeping the universe up-to-date with any changes
in user information requirements.
Your task is to work in a group and discuss the findings of some initial analysis with the HR
department of Prestige Motors.
Customer scenario
Prestige motors has a total of 260 employees. Of the 260 employees, there are 12 who work
within HR, few of whom are required to create the reports, most have viewing rights only.
Most of the staff can schedule reports. The management needs to see high-level reports, and
not just straightforward tables. Showroom staff may be required to generate reports.
Reports to detail the following:
1. Hierarchical reporting to be based on time, department, and geographic locations.
2. A list of absences detailing the employee, department, job title, showroom, date of absence,
duration of absence, and reason for absence.
3. Employee listing by manager, by department, and when they were hired
4. A summary of the number of employees by grade and total salary amount, per showroom
for each year.
5. Salary comparison levels versus absence correlation.
6. 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.
7. A summary of the salary costs and absences per showroom and per year.
Sample of objects to provide the above:
Employee Name
Country (ensure the country object produces a list of countries the showrooms are in)
Showroom
Department
Job Title
Number of Employees
Manager Name
Salary Description
Financial Year (for salary and absence analysis only)
Financial Quarter (for salary and absence analysis only)
352
Two custom hierarchies are required: one for geographic drilling, the other for time based on
a financial year.
Items to watch out for:
1. Multipurpose lookup tables.
2. Chasm and fan traps.
3. Additional business requirements.
Instructions
1. Conduct a breakout session where as a group you need to identify the following points:
Strategy: Define the scope of the universe. Identify and review the production and
development architectures. Assemble project teams and define the initial task plan.
Analysis: Identify the ad hoc data access requirements of the user community and record
them in the form of candidate classes and objects. Identify security requirements.
Schema Design: Map objects to corporate data sources. Resolve any circular paths or
loops within the data structures that support the required objects. Plan the architecture
for the project.
Plan the development environment: Identify resources required to support a development
universe area. Identify source for development data. Verify appropriate connectivity and
initiate any changes or purchases required and plan their implementation.
Plan the production environment: Identify resources required for a production universe.
Locate source of production data. Verify connectivity. Initiate any changes or purchases
required and plan their implementation.
Adopt universe standards: Have appropriate naming conventions for universe names,
object definition guidelines, names for simple, complex and aggregate objects, class
names, alias tables, and help text. You may want to incorporate the class name in the
object's name. This may make object names a little long, but it makes it easier for end
users to understand where existing objects in a query come from, especially in reports
353
containing many objects, some of which may have similar names. The object's name
should always precede the class name(s). Example: Rental Date - Rental Dates - Rentals.
Connectivity and configuration: Ensure the infrastructure is in place to support
connectivity between users/developers and the enterprise system, including appropriate
middleware to support the communication between clients and servers. Identify planned
configuration for client software. Ensure appropriate resources are available.
Security and support: Initiate a first look at security requirements - to be refined during
subsequent phases. Develop a support policy that is followed when the universe goes
into production. Identify necessary resources.
Change management and training: Identify procedures for the request, review, approval
and implementation of changes to the production universe. It is essential to educate even
existing users on how to use the universe to meet the business needs.
Identify the best practices to be followed.
Quality Assurance.
Instructions
1. Create a new universe called HRMotors_xx, where "xx" stands for your initials. Use your
MotorsOLEDB_xx connection to connect to the SQL Server database.
2. Using your paper design as a reference, design the universe schema. Insert tables, joins, and
create the appropriate classes and objects.
3. Resolve any potential loops or SQL traps.
4. Check the universe integrity.
5. Test your universe in Web Intelligence Rich Client.
354
Appendix B
355
Data warehouses
A data warehouse is an enterprise-wide centralized storage facility for different types of data.
Data stored in a data warehouse is characteristically subject oriented, time sensitive, and should
be organized in a way that allows data analysis. For example, a data warehouse can contain
customer information and sales details per customer, over the past five years. These customer
details and sales records are often derived from several production systems in the enterprise.
Performing query and trend analysis on this dispersed data can prove to be a difficult task.
This is where data warehousing comes into play. Data warehousing is the process of collecting,
aggregating, storing, and maintaining information so that it may lead to accurate business
decisions. Some characteristics and features of data warehousing are as follows:
Provides a consolidated storage of information from across the enterprise.
Warehoused data is organized by subject area and is populated from many operational
systems.
Can act as a decision support system.
Generally concerned with historical data and aggregates.
Added to regularly, but loaded data is rarely ever directly changed.
Regular schedule of dumps and loads from operational data stores.
All these features differentiate data warehouses from typical operational database systems.
Data warehouses are commonly kept on separate machines that can be tuned for a lower
frequency of users with different querying characteristics. Data warehouses are usually read-only
based systems, aside from the periodic loading of current information.
356
357
Data Marts
A data mart is a repository of data gathered from operational data or other sources and is
designed to serve a particular department or functional group. It is similar to a Data warehouse,
but there would be a difference in size and focus. The emphasis of a data mart is on meeting
the specific demands of a particular group of users. These users can run reports and analyze
data stored in the data mart that is designed to portray information based on their group
requirement needs.
A common approach to using data marts is to keep data at a detail level in the data warehouse
and summarize this information into the data mart for each functional group or department.
Sometimes data marts are designed for each departmental unit, and all departmental data
marts are merged later on into an enterprise-level data warehouse.
Either method offers the benefit of centralizing the information for the end users. Some
characteristics of data marts are as follows:
Data specialized for a particular group of an organization.
Engineered for easy access.
Optimal response from lower volume queries.
Due to the more simplified and specialized nature of data marts, organizations are turning to
data marts, as a quick solution to their decision-support needs.
358
Dimensional Modeling
The traditional entity relationship (ER) model uses a normalized approach to database design.
Normalization removes redundancy from the schema to optimize storage. Data warehousing
is not that concerned with saving space. It is more concerned with meeting the decision support
needs. A small amount of redundancy is usually acceptable.
Fact Tables
The fact table that sits in the center of this star schema usually contains business events recorded
over time. Examples of data that can be found in this table are: sales transactions, orders and
returns, bank transactions, shipments, and so forth.
The fact table normally consists of a set of numeric values and a number of foreign keys that
correspond to primary keys in the various dimension (lookup) tables. The information stored
in the fact tables is usually static as it is historical. The most common example of a fact table in
the star schema is for sales.
Dimensions
The dimension tables consist mainly of descriptive information linked to fact records. Examples
of dimension data are: customer names, product descriptions, suppliers, and vendors. Dimension
tables contain fewer records than the facts table. An important factor is that the information in
dimension tables is not static as records in dimension tables can be updated. For example, a
customer address might be modified in the source system.
359
A typical data warehouse schema always uses dimension tables or tables that deal with periods
of time. These tables are the key element to tracking the time variant information in these types
of databases.
Sometimes a more normalized approach is taken to the dimension tables. When this happens
the star schema changes to a snowflake (or constellation) schema. A snowflake schema is
basically one fact table, connected to a number of dimension tables, and these dimension tables
in turn are connected to additional dimension tables.
360
Appendix C
ORACLE
This section provides solution syntaxes for ORACLE, based on SQL examples used in the
course.
361
Object Name
Oracle
Client Name
CONCAT(CONCAT(
CLIENT.CLIENT_LASTNAME,', '),
CLIENT.CLIENT_FIRSTNAME)
Model
CONCAT(CONCAT(CONCAT
(CONCAT(MODEL.MODEL_NAME,' '),
MODEL.MODEL_TRIM),' '),
MODEL.MODEL_ENGINE)
Sale Year
Sale Quarter
CONCAT('Q',TO_CHAR
(SALE.SALE_DATE,'Q'))
Sale Month
TO_CHAR
(SALE.SALE_DATE,'Month')
Rental Year
Rental Quarter
CONCAT('Q',TO_CHAR
(RENTAL.SALE_DATE,'Q'))
Rental Month
TO_CHAR
(RENTAL.SALE_DATE,'Month')
sum(CASE WHEN
to_char(SALE.SALE_DATE,'YYYY')
='2003'
THEN (SALE_MODEL.SALE_QTY
* MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
sum(CASE WHEN
to_char(SALE.SALE_DATE,'YYYY')
='2004'
THEN (SALE_MODEL.SALE_QTY
* MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
sum(CASE WHEN
FINANCE_PERIOD.FP_YEAR
='FY03-04'
THEN (SALE_MODEL.SALE_QTY
* MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
362
Object Name
Oracle
ELSE 0 END)
sum(CASE WHEN
FINANCE_PERIOD.FP_YEAR
='FY04-05'
THEN (SALE_MODEL.SALE_QTY
* MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
DB2
This section provides solution syntaxes for DB2, based on SQL examples used in the course.
363
Object Name
DB2
Client Name
Model
Sale Year
{fn concat
('Calendar Year ',char(year(
SALE.SALE_DATE)))}
Sale Quarter
{fn concat
('Q',char(quarter(
SALE.SALE_DATE)))}
Sale Month
MONTH(SALE.SALE_DATE)
Rental Year
{fn concat
('Calendar Year ',char(year(
RENTAL.SALE_DATE)))}
Rental Quarter
{fn concat
('Q',char(quarter(
RENTAL.SALE_DATE)))}
Rental Month
MONTH(RENTAL.SALE_DATE)
sum(CASE WHEN
year(SALE.SALE_DATE) = 2003
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END )
sum(CASE WHEN
year(SALE.SALE_DATE) = 2004
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END )
sum(CASE WHEN
FINANCE_PERIOD.FP_YEAR
='FY03-04'
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE *(100 -
364
Object Name
DB2
SALE.SALE_DISCOUNT)/100))
ELSE 0 END )
sum(CASE WHEN
FINANCE_PERIOD.FP_YEAR
='FY04-05'
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE *(100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END )
MySQL
This section provides solution syntaxes for MySQL, based on SQL examples used in the course.
365
Object Name
MySQL
Client Name
Model
Sale Year
Sale Quarter
{fn concat('Q',
QUARTER(SALE.SALE_DATE))}
Sale Month
MONTH(SALE.SALE_DATE)
Rental Year
Rental Quarter
{fn concat('Q',
QUARTER(RENTAL.SALE_DATE))}
Rental Month
MONTH(RENTAL.SALE_DATE)
sum(CASE WHEN
{fn year(SALE.SALE_DATE)}
= 2003
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE * (100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
sum(CASE WHEN
{fn year(SALE.SALE_DATE)}
= 2004
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE * (100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
sum(CASE WHEN
FINANCE_PERIOD.FP_YEAR
='FY03-04'
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE * (100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
366
Object Name
MySQL
sum(CASE WHEN
FINANCE_PERIOD.FP_YEAR
='FY04-05'
THEN (SALE_MODEL.SALE_QTY *
MODEL.MODEL_PRICE * (100 SALE.SALE_DISCOUNT)/100))
ELSE 0 END)
Microsoft Access
This section provides solution syntaxes for Microsoft Access, based on SQL examples used in
the course.
367
Object Name
Microsoft Access
Client Name
Model
Sale Year
Sale Quarter
'Q' + format(SALE.SALE_DATE,'Q')
Sale Month
format(SALE.SALE_DATE,'Mmm')
Rental Year
Rental Quarter
'Q' + format(RENTAL.SALE_DATE,'Q')
Rental Month
format(RENTAL.SALE_DATE,'Mmm')
sum(IIf(FINANCE_PERIOD.FP_YEAR
='FY03-04',(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *
(100-SALE.SALE_DISCOUNT)/100)),0))
sum(IIf(FINANCE_PERIOD.FP_YEAR
='FY04-05',(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *
(100-SALE.SALE_DISCOUNT)/100)),0))
368
Answer Key
This section contains the answers to the reviews and/or activities for the applicable lessons.
369
370
371
372
373
374
375
376
377
378
379
380
381
2. When you insert a derived table and insert joins, what happens if you do not add the new
join to the appropriate context?
Answer:
When you parse the derived tables SQL, it generates an exception.
When you run a query, the derived table creates a Cartesian product.
The objects you create from the derived table are incompatible with objects from any of
the existing contexts.
3. 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.
4. 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.
382
383
384
385
386
Notes
Notes
Notes
Notes