D95501GC10 Ag

Oracle Internal & Oracle Academy Use Only
Oracle BI 12c: Build Repositories
Activity Guide
D95501GC10 | D97687
Learn more from Oracle University at education.oracle.com

Author Copyright © 2020, Oracle and/or its affiliates.
Jim Sarokin Disclaimer
This document contains proprietary information and is protected by copyright and other
Technical Contributors intellectual property laws. You may copy and print this document solely for your own use
in an Oracle training course. The document may not be modified or altered in any way.
and Reviewers Except where your use constitutes "fair use" under copyright law, you may not use,
share, download, upload, copy, print, display, perform, reproduce, publish, license, post,
Phil Scott
transmit, or distribute this document in whole or in part without the express authorization
Craig Harding of Oracle.
The information contained in this document is subject to change without notice and is not
Editors warranted to be error-free. If you find any errors, please report them to us in writing.
Vijayalakshmi Narasimhan Restricted Rights Notice
Raj Kumar If this documentation is delivered to the United States Government or anyone using the
documentation on behalf of the United States Government, the following notice is
Kavita Saini applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system,
Graphic Designer integrated software, any programs embedded, installed or activated on delivered
hardware, and modifications of such programs) and Oracle computer documentation or
Maheshwari Krishnamurthy other Oracle data delivered to or accessed by U.S. Government end users are
"commercial computer software" or "commercial computer software documentation"
pursuant to the applicable Federal Acquisition Regulation and agency-specific
Publishers supplemental regulations. As such, the use, reproduction, duplication, release, display,
disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle
Syed Imtiaz Ali programs (including any operating system, integrated software, any programs embedded,
Srividya Rameshkumar installed or activated on delivered hardware, and modifications of such programs), ii)
Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and
Joseph Fernandez limitations specified in the license contained in the applicable contract. The terms
Asief Baig governing the U.S. Government's use of Oracle cloud services are defined by the
applicable contract for such services. No other rights are granted to the U.S.
Government.
1011042020 Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All
SPARC trademarks are used under license and are trademarks or registered trademarks
of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered
trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open
Group.
Third-Party Content, Products, and Services Disclaimer
This documentation may provide access to or information about content, products, and
services from third parties. Oracle Corporation and its affiliates are not responsible for
and expressly disclaim all warranties of any kind with respect to third-party content,
products, and services unless otherwise set forth in an applicable agreement between
you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss,
costs, or damages incurred due to your access to or use of third-party content, products,
or services, except as set forth in an applicable agreement between you and Oracle.
Table of Contents
Practices for Lesson 1: Course Introduction ................................................................................ 7
Practices for Lesson 1 .................................................................................................................... 8
Practices for Lesson 2: Repository Basics ................................................................................... 9
Practices for Lesson 2: Overview ................................................................................................... 10
Practice 2-1: Exploring an Oracle BI Repository ............................................................................ 11
Practices for Lesson 3: Building the Physical Layer of a Repository ........................................ 25
Practice 3-1: Exploring the Sample Application .............................................................................. 27
Practice 3-2: Creating a Repository and Importing a Data Source................................................. 32

Practice 3-3: Creating Alias Tables ................................................................................................ 40
Practice 3-4: Defining Keys and Joins ............................................................................................ 43
Practices for Lesson 4: Building the Business Model and Mapping Layer of a Repository .... 49
Practice 4-1: Creating the Business Model..................................................................................... 51
Practice 4-2: Creating Simple Measures ........................................................................................ 58
Practices for Lesson 5: Building the Presentation Layer of a Repository ................................. 61
Practice 5-1: Creating the Presentation Layer ................................................................................ 63
Solution 5-1: Creating the Presentation Layer ................................................................................ 70
Practices for Lesson 6: Testing and Validating a Repository ..................................................... 71
Practice 6-1: Testing the Repository ............................................................................................... 73
Practices for Lesson 7: Managing Logical Table Sources ........................................................... 83
Practice 7-1: Importing Additional Dimension Tables ..................................................................... 85
Practice 7-2: Adding a New Mapping to an Existing Logical Table Source .................................... 88
Practice 7-3: Adding a New Logical Table Source ......................................................................... 92
Practices for Lesson 8: Adding Calculations to a Fact ................................................................ 101
Practice 8-1: Creating Calculation Measures ................................................................................. 103
Practice 8-2: Creating Calculation Measures by Using the Calculation Wizard ............................. 106
Practice 8-3: Creating a Rank Measure.......................................................................................... 109
Practice 8-4: Testing and Validating the Repository Measures ...................................................... 112
Practices for Lesson 9: Working with Logical Dimensions ......................................................... 117
Practice 9-1: Creating Logical Dimension Hierarchies ................................................................... 119
Copyright © 2020, Oracle and/or its affiliates.
Oracle BI 12c: Build Repositories – Table of Contents iii

Practice 9-2: Creating Level-Based Measures ............................................................................... 130
Practice 9-3: Creating Share Measures.......................................................................................... 134
Practice 9-4: Creating Dimension-Specific Aggregation Rules ...................................................... 136
Practice 9-5: Creating Presentation Hierarchies............................................................................. 138
Practices for Lesson 10: Working with Logical Dimension Hierarchies .................................... 147
Practices for Lesson 10: Overview ................................................................................................. 148
Practice 10-1: Creating Parent-Child Hierarchies ........................................................................... 149
Practice 10-2: Creating Logical Dimensions with Ragged and Skipped-Level Hierarchies ........... 160
Practices for Lesson 11: Managing Usage Tracking .................................................................... 165
Practice 11-1: Setting Up Usage Tracking...................................................................................... 167

Practices for Lesson 12: Using Model Checker and Aggregates ................................................ 175
Practice 12-1: Using Aggregate Tables .......................................................................................... 177
Practice 12-2: Using the Aggregate Persistence Wizard ................................................................ 186
Practices for Lesson 13: Using Partitions and Fragments .......................................................... 201
Practice 13-1: Modeling a Value-Based Partition ........................................................................... 203
Practices for Lesson 14: Using Repository Variables .................................................................. 213
Practice 14-1: Creating Dynamic Repository Variables .................................................................. 215
Practice 14-2: Using Dynamic Repository Variables as Filters ...................................................... 227
Practices for Lesson 15: Modeling Time Series Data ................................................................... 235
Practice 15-1: Creating Time Series Calculation Measures ........................................................... 237
Practices for Lesson 16: Modeling Many-to-Many Relationships ............................................... 247
Practice 16-1: Modeling a Bridge Table.......................................................................................... 249
Practices for Lesson 17: Setting an Implicit Fact Column ........................................................... 261
Practice 17-1: Setting an Implicit Fact Column ............................................................................... 263
Practices for Lesson 18: Importing Metadata from Multidimensional Data Sources ................ 271
Practices for Lesson 18 .................................................................................................................. 272
Practices for Lesson 19: Security ................................................................................................... 273
Practice 19-1: Exploring Default Security Settings ......................................................................... 275
Practice 19-2: Creating Users and Groups ..................................................................................... 281
Practice 19-3: Creating Application Roles ...................................................................................... 286
iv Oracle BI 12c: Build Repositories – Table of Contents

Practice 19-4: Setting Up Object Permissions ................................................................................ 293
Practice 19-5: Setting Row-Level Security (Data Filters) ............................................................... 303
Practice 19-6: Setting Query Limits and Timing Restrictions ......................................................... 306
Practices for Lesson 20: Cache Management ............................................................................... 311
Practice 20-1: Enabling Query Caching.......................................................................................... 313
Practice 20-2: Modifying Cache Parameters .................................................................................. 327
Practice 20-3: Seeding the Cache .................................................................................................. 333
Practices for Lesson 21: Setting Up and Using the Multiuser Development Environment ...... 339
Practice 21-1: Setting Up a Multiuser Development Environment.................................................. 341

Practice 21-2: Using a Multiuser Development Environment ......................................................... 346
Practices for Lesson 22: Performing a Patch Merge .................................................................... 357
Practice 22-1: Performing a Patch Merge....................................................................................... 359
Practices for Lesson 23: Managing Metadata and Working with Service Instances ................. 371
Practices for Lesson 23 .................................................................................................................. 372
Copyright © 2020, Oracle and/or its affiliates. All rights reserved.
Oracle BI 12c: Build Repositories – Table of Contents v

vi Oracle BI 12c: Build Repositories – Table of Contents

Practices for Lesson 1:
Course Introduction
Practices for Lesson 1
There are no practices for this lesson.
8 Practices for Lesson 1: Course Introduction

Repository Basics

Practices for Lesson 2: Overview
Practices Overview
In these practices, you will explore an existing Oracle Business Intelligence (BI) repository.
10 Practices for Lesson 2: Repository Basics

Practice 2-1: Exploring an Oracle BI Repository
Overview
In this practice, you explore the three layers of an Oracle BI repository.
Assumptions
Before beginning the development of a repository, you use the Administration Tool to explore an
existing repository to gain an understanding of its three layers and how the layers relate to one
another, and to understand the link between the physical data sources and the information that
is presented in the Oracle BI user interface.
Time

25 minutes
You need to START the BI Instance.

1. Open a Command Line Window and
2. Change directories to D: then cd
D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bitools\bin
3. Type start.cmd
It will take several minutes to start all the servers within the BI Instance. Once all the servers
are up your screen should look like the following.
Tasks
1. Copy the repository for this practice to another directory.
a. Create a new directory D:\repository.
b. Navigate to D:\PracticeFiles.
c. Copy the ClassStart.rpd file.
d. Paste the file in D:\repository.
Practices for Lesson 2: Repository Basics 11

2. Start the Oracle BI Administration Tool and open the ClassStart repository in offline mode.
a. Double-click the Administration Tool shortcut on the Desktop to open the
Administration Tool.
b. Select File > Open > Offline.
c. In the Open dialog box, navigate to D:\repository and double-click ClassStart.rpd to
open the repository.
d. Type welcome1 as the repository password and click OK to open the repository in
offline mode.
3. Examine the properties of the ORCL database object.
a. In the Physical layer, double-click the ORCL database object to view its properties.
b. Click the General tab.
c. Notice that the database type is Oracle 12c.

d. Click the Features tab. Each database comes with a set of features that determine the
SQL that the Oracle BI Server will issue for this database. Features can have a
Boolean value (on or off), integer value, or a string value.
e. Scroll to the right to view the Value and Default columns. A check mark in the Default
column indicates that the feature is supported by this database type and a check mark
in the Value column indicates that the feature is enabled.
f. Click the Connection Pools tab. This tab identifies all the connection pools associated
with this database. In this example, there is only one connection pool, Sample Apps
Connection Pool.
g. Click the Display Folders tab. Physical layer objects can be organized into display
folders. When there are display folders in the Physical layer, they are listed here.
h. Click Cancel to close the Properties dialog box.
4. Explore the properties of a connection pool object.
a. In the Physical layer, expand the ORCL database object.
b. Double-click the Sample Apps Connection Pool connection pool object.
c. Notice that the call interface type for this connection pool is Default (OCI 10g/11g) and
the data source name is orcl. The call interface is the application programming
interface (API) that is used to access the data source. Some databases may be
accessed by using native APIs and some by using ODBC.
d. Click Cancel.

5. Examine the properties of a physical schema and its physical table objects. You examine
the alias tables for each of the physical tables.
a. Expand the BISAMPLE schema folder to display the physical tables and their alias
objects in the Physical layer. These table objects map to tables in the physical
database.

There are more tables in the physical database. The tables that are displayed in the
screenshot are the tables that have been imported into the Physical layer. You learn
more about importing tables in the lesson titled “Building the Physical Layer of a
Repository.”
b. Expand F1 Revenue to view the physical columns for this table. F1 Revenue is the
“fact” table in this business model. These columns correspond to columns in the
physical database.

c. Right-click F1 Revenue and select View Data. The first 100 rows of data for this table
are displayed.
d. Click Close.
e. Double-click the F1 Revenue table object to view its properties.
f. Click the Columns tab to view the columns in this table. This is another way to create,
view, and modify physical columns.
g. Click the Foreign Keys tab.
h. Notice that three tables have join relationships with F1 Revenue: D1 Time, D2
Products, and D3 Customers.

i. Double-click one of the foreign keys. The Physical Foreign Key dialog box opens and
displays the join relationship in the Expression field.

j. Click Cancel to close the Physical Foreign Key dialog box.
k. Click Cancel to close the Physical Table dialog box.

l. Right-click F1 Revenue and select Physical Diagram > Object(s) and Direct Joins.
The Physical Diagram opens and displays the physical join relationships.

m. Double-click the connector between D3 Customers and F1 Revenue. The Physical
Foreign Key dialog box opens and displays the join relationship in the Expression field.
This is another way to view, build, and modify joins between tables in the Physical
layer.
n. Click Cancel.
o. Close the Physical Diagram.
6. Examine the properties of a physical column object.
a. Expand the D2 Products table object.
b. Double-click the BRAND physical column to view its properties.
c. Click Cancel.
7. Examine the properties of a logical table in the Sample Apps business model.
a. Expand the Sample Apps business model in the Business Model and Mapping layer.
b. Notice that there are four logical table objects in the Sample Apps business model: F1
Revenue, D1 Time, D2 Products, and D3 Customers.
c. Expand the F1 Revenue logical table to view the logical columns for this table. F1
Revenue is the logical “fact” table in this business model. These logical columns map
to columns in the Physical layer.
d. Double-click the F1 Revenue logical table object.

e. Click the General tab. Notice that the logical columns and their corresponding
properties are listed. On this tab, you can change the name of the logical table, reorder
the columns, and add, edit, or remove a column.
f. Click the Sources tab. The logical table source, LTS1 F1 Revenue, is mapped to the
same F1 Revenue table that you explored in the Physical layer. In a more complex
business model, there may be many physical sources for a logical table.
g. Click the Keys tab. Typically, no keys are defined for a logical fact table.
h. Click the Foreign Keys tab. Foreign key joins are typically not used in the Business
Model and Mapping layer. All joins in the Business Model and Mapping layer are
logical joins that do not require primary key–foreign key relationships.
i. Click Cancel to close the Logical Table properties dialog box.
j. Right-click F1 Revenue and select Business Model Diagram > Whole Diagram. The

Business Model Diagram opens and displays the logical join relationships.

k. Double-click the connector between D3 Customers and F1 Revenue. The Logical Join
dialog box opens. Notice that there is no join expression in the Expression field and
that there is a one-to-many relationship between the D3 Customers logical dimension
table and the F1 Revenue logical fact table. You learn more about logical joins in the
lesson titled “Building the Business Model and Mapping Layer of a Repository.”

l. Click Cancel to close the Logical Join dialog box.
m. Close the Business Model Diagram.
8. Examine the logical table source for the F1 Revenue logical table.
a. Expand F1 Revenue > Sources to display the LTS1 F1 Revenue logical table source
for this logical table. In this example, the logical table source has been renamed and
there is only one logical table source. However, it is possible to have many logical table
sources for a single logical table.
b. Double-click the LTS1 F1 Revenue logical table source to view the properties.
c. Click the General tab.
d. Notice that the LTS1 F1 Revenue logical table source maps to the F1 Revenue
physical table.

e. Click the Column Mapping tab. This tab shows the mappings between the logical
columns and the physical columns.
f. If necessary, scroll to the right to view the Physical Table column. Notice that both the
columns in the F1 Revenue logical table map to the same physical table: FI Revenue.

g. Notice that logical columns may have names that are different from the physical
columns to which they map. This is because the logical column names can be changed
in the Business Model and Mapping layer. You learn how to rename logical columns in
the lesson titled “Building the Business Model and Mapping Layer of a Repository.”
h. Click the Content tab. Currently, there is no information on the tab. You learn how to
use this tab to identify aggregation content and fragmentation content in the lesson
titled “Using Model Checker and Aggregates.”
i. Click Cancel to close the Logical Table Source dialog box.
9. Examine the properties of a logical column in the F1 Revenue logical table.
a. Double-click the Revenue logical column to open the properties window. Revenue is a
measure in this business model.
b. Click the General tab. This tab provides general information about the column, such as
the column name, the table it belongs to, and a description of the column.
c. Click the Column Source tab. This tab provides information about the physical table
and the physical column that the logical column maps to, or whether the logical column
is derived from other existing logical columns.
d. Double-click the LTS1 F1 Revenue logical table source in this dialog box. Notice that
this is another way to access the Logical Table Source properties dialog box.
e. Click Cancel to close the Logical Table Source properties dialog box.
f. Click the Aggregation tab. Notice that the default aggregation rule is set to Sum. It is
common to apply aggregation rules to measures in business models. Open the
“Default aggregation rule” drop-down list to see the other available aggregation rules.
g. Make sure that the Sum aggregation rule is still selected and click Cancel to close the
Logical Column dialog box.
10. Examine the properties of the Sample Sales presentation catalog object.
a. In the Presentation layer, double-click the Sample Sales subject area to open the
Subject Area properties dialog box.
b. Click the General tab. Notice that the subject area name is different from the business
model name. This is because the subject area was created by dragging the business

model from the Business Model and Mapping layer to the Presentation layer, and then
the subject area was renamed. The subject area and its description appear in the
Analysis Editor user interface. Many subject areas can map to a single business
model, but each subject area can map to only one business model.
c. Click Permissions to open the Permissions dialog box. This shows the permissions for
all users and application roles in the repository. Currently, no permissions are defined
for users or application groups, so the default is to give everyone read permission for
this subject area. You learn more about setting object permissions in the lesson titled
“Security.”
d. Click Cancel to close the Permissions dialog box.
e. Click the Presentation Tables tab to display a list of presentation tables. You can use
this tab to add, remove, edit, or change the display order of the presentation tables in
the subject area.

f. Click the Aliases tab. Because the name of the subject area was changed, the tool
automatically created an alias based on the previous name. You can use this tab to
specify or delete an alias.
g. Click Cancel to close the Subject Area dialog box.
11. Examine the properties of a presentation table in the Sample Sales subject area.
a. In the Presentation layer, expand Sample Sales to view the presentation tables.
b. Double-click the Base Facts table to view the properties. The F1 Revenue logical
table name has been renamed to Base Facts.
c. Click the General tab. You can use this tab to change the name of the presentation
table. A description will appear as a “tool tip” in the Oracle BI user interface. You can
also hide the object based on some conditions. In this example, permissions are set to
read-only, so you cannot make changes.
d. Click the Columns tab to see a list of columns and their mappings in the Base Facts
presentation table. You can use this tab to add, remove, edit, or change the display
order of the presentation columns.
e. Double-click Revenue to open the Presentation Column properties dialog box. This is
one method for viewing and modifying presentation column properties.
f. Click Cancel to close the Presentation Column properties dialog box.
g. Click the Hierarchies tab. Currently no hierarchies are defined for this presentation
table. You learn about presentation hierarchies in the lesson titled “Working with
Logical Dimensions.”
h. Click the Child Presentation Tables tab. You can nest presentation tables. You learn
about nested folders in the lesson titled “Building the Presentation Layer of a
Repository.”
i. Click Cancel to close the Presentation Table properties dialog box.
12. Examine the properties of a presentation column in the Base Facts table.
a. Expand the Base Facts presentation table.

b. Double-click Revenue to open the Presentation Column properties dialog box. Notice
that this is the same dialog box that you saw earlier. This is another method for viewing
and modifying presentation column properties.
c. Click Cancel to close the Presentation Column properties dialog box.
d. Click File > Close to close the repository without saving any changes.
e. Leave the Administration Tool open.
13. Use the uploadrpd command to upload the repository to BI Server.
a. Open a command window.
b. Type cd
D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bitool
s\bin and press the Enter key to change the directory.
c. Run the datamodel.cmd utility with the following uploadrpd parameters:

datamodel.cmd uploadrpd -I D:\repository\ClassStart.rpd -W
welcome1 -U weblogic -P welcome1 -SI ssi
Note:
I specifies the location and name of the repository.
W specifies the repository’s password.
U specifies a valid user’s name to be used for Oracle BI EE authentication.
P specifies the password corresponding to the user’s name that you specified for U.
SI specifies the name of the service instance.
d. Confirm that you receive the following message:

Operation Successful.
RPD upload completed successfully.
e. Leave this command window open. You will run this uploadrpd command often
throughout this course.
14. Examine the relationship between the columns in the Presentation layer and the columns
displayed in Oracle BI Analysis Editor.
a. Return to the Administration Tool, which should still be open.
c. Double-click ClassStart.rpd to open it in offline mode.
d. Enter welcome1 as the repository password and click OK. The ClassStart repository
opens in offline mode.

e. Open a browser and enter the following URL to open Oracle BI:
http://localhost:9502/analytics.
f. Sign in as weblogic with the password welcome1.
g. Select New > Analysis.
h. Click the Sample Sales subject area to open the Analysis Editor.
i. Size the windows of the browser and the Administration Tool so that you can see the
two applications side by side. Notice that the Sample Sales subject area in the
Presentation layer of the repository corresponds to the Sample Sales subject area in
the Analysis Editor.

The key point to understand is this: What you see in the Analysis Editor is driven by
what is defined in the Presentation layer of the repository in the Administration Tool.
15. Create a simple analysis.
a. In the Analysis Editor, expand the Products table and double-click the Brand column
to add it to the Selected Columns in the right pane.

b. Expand Base Facts and double-click the Revenue column to add it to the request.
c. Click the Results tab. The table displays the total revenue for each brand.
d. Sign out of Oracle BI.

e. Click Leave Page when prompted.
f. Leave the browser open.
g. In the Administration Tool, close the ClassStart repository without saving.
h. Leave the Administration Tool open.


Building the Physical Layer
of a Repository
Practices Overview
In these practices, you explore the Sample Application schema that is used in this course, and
build the Physical layer of an Oracle Business Intelligence repository.
26 Practices for Lesson 3: Building the Physical Layer of a Repository

Practice 3-1: Exploring the Sample Application
Overview
In this practice, you learn about the Sample Application for Oracle Business Intelligence.
Time
5 minutes
Background
The Sample Application (Sample App) for Oracle Business Intelligence Suite Enterprise Edition
(OBIEE) is a comprehensive collection of examples designed to demonstrate the capabilities
and design best practices of Oracle BI. It brings together several integrated Oracle BI products

and technologies, and illustrates how they can seamlessly work together in solving functional
problems. These examples include the latest OBIEE functionalities and OBIEE architecture
examples, including semantic layer modeling, multi-source federation, integration with Essbase,
and more.
Sample App includes a prebuilt schema and a prebuilt Oracle BI metadata repository that
provide the underlying structure for the Sample App reports and dashboards that are used to
demonstrate Oracle BI capabilities and best practices. In the practices for this course, you use a
prebuilt Sample App schema to build an Oracle BI repository that replicates a subset of the
functionality that is included in the prebuilt Sample App repository.
Sample App is available at Oracle Technology Network (OTN) > Middleware > Business
Intelligence Foundation > Oracle Business Intelligence Enterprise Edition Samples:
http://www.oracle.com/technetwork/middleware/bi-foundation/obiee-
samples-167534.html
Note that the Sample App content, documentation, schema, and code are distributed free on
OTN for demonstrative purposes only. Sample App is neither maintained nor supported by
Oracle as a licensed product.
Practice Strategy and Requirements

The initial repository that you build includes revenue fact data analyzed across the time,
product, and customer dimensions. To build the initial repository, you import the necessary
tables from the Sample App schema, create physical aliases, design and build the logical
business model, and expose the business model in the Oracle BI user interface. In the process
of constructing the initial repository, you learn how to build physical joins, logical joins, and
simple measures. You also learn how to validate your work by creating and running analyses,
and verifying query results by using the query log.
As the course progresses, you extend the initial repository and learn how to model more
complex business requirements, such as logical dimension hierarchies, multiple logical table
sources, aggregate tables, partitions, multidimensional sources, and time series data. You also
learn how to implement Oracle BI Server security, manage Oracle BI Server cache, set up a
multiuser development environment, and use the Administration Tool wizards and utilities to
manage, maintain, and enhance repositories. Finally, you incorporate more advanced
Practices for Lesson 3: Building the Physical Layer of a Repository 27

functionality into your repository, such as implicit fact columns, many-to-many relationships,
usage tracking, and patch merge.
Source Data
The following screenshots show a subset of the data in the tables that are used to build the
initial repository:
SAMP_REVENUE_F

SAMP_CUSTOMERS_D

SAMP_PRODUCTS_D

SAMP_TIME_DAY_D

Training Objective
The primary objective of this training is to build Oracle BI repository metadata that will allow you
to build interactive reports that can be used to analyze the data in the Sample App schema. The
recommended strategy for building metadata is to use an iterative approach. You begin by
building a relatively simple repository by using the following guidelines:
• Minimize the number of imported source tables.
• Expose only stored measures with simple aggregation rules.
• Create presentation objects and test with Oracle BI Analysis Editor.
• Use the query log to check query results.
After the initial repository is built and tested, you expand the repository metadata by performing
the following tasks:
• Import any additional physical tables that are needed to support the business model.
• Add logical table sources.
• Add calculated measures that involve operations on existing columns.
• Add more complex calculated measures (for example, level-based measures and
share measures).
• Create dimension hierarchies.
• Enable and manage usage tracking.
• Add aggregate table data sources to improve performance.
• Incorporate partitions and fragments into your business model.
• Utilize initialization blocks and repository variables.
• Add time series calculations (for example, percentage change in a measure compared
to that in the same period in the previous year).
• Configure many-to-many relationships.
• Configure implicit fact columns.
• Import metadata from multidimensional data sources, such as Essbase.
• Implement Oracle BI security.
• Manage Oracle BI cache.

• Use Administration Tool utilities.
• Set up a multiuser development environment.
• Perform a patch merge.
In the lessons that follow, you follow this strategy to build the repository by using an iterative
approach. At first, the repository metadata includes only the basic set of physical tables that are
needed to support the initial business model. You then add more tables and modeling
complexity in future iterations as the course progresses.

Practice 3-2: Creating a Repository and Importing a Data Source
Overview
In this practice, you create a new repository and import tables from an external data source.
Assumptions
You use the Import Wizard of the Administration Tool to create a new repository and import
tables from the BISAMPLE schema into the Physical layer of the repository. When you complete
this practice, you will have a new repository file, bisample.rpd, which will contain the
SAMP_TIME_DAY_D, SAMP_PRODUCTS_D, SAMP_CUSTOMERS_D, and SAMP_REVENUE_F
tables and the corresponding alias tables in the Physical layer of the repository.

Time
15 minutes
Tasks
1. Use the Import Wizard to create a new repository file.
a. Return to the Administration Tool, which should still be open. If not, double-click the
Administration Tool shortcut on the Desktop.
b. Select File > New Repository to open the Import Wizard. The Import Wizard guides
you through the steps to create a new repository and import metadata.
c. Leave Create Repository set to the default: Binary.
d. Enter BISAMPLE in the Name field.
e. In the Location field, you have the option to accept the default location or Browse to a
new location. Change the location to D:\repository.
f. For Import Metadata, accept the default selection: Yes. When Yes is selected, the
Import Wizard continues with windows for importing metadata. When No is selected,
an empty repository is saved to the selected location.
g. Enter welcome1 as the repository password.
h. Retype the password.
i. Click Next to open the new BISAMPLE repository and the Select Data Source window.
2. Use Import Wizard to import metadata.
a. In the Select Data Source window, select OCI 10g/11g from the Connection Type
drop-down list. The window displays connection fields based on the connection type
that you selected.
b. Select a data source. In this environment, the data source name is ORCL.
c. Enter a username and password for the data source. In this example, the username
and password are both BISAMPLE.
d. Click Next to continue to the Select Metadata Types window.

e. In the Select Metadata Types window, accept the defaults: Tables, Keys, and Foreign
Keys. The check boxes allow you to select the information to import. You can import
tables, keys, foreign keys, system tables, aliases, synonyms, and views. As a general
rule, import only those objects that are needed to support your business model. If you
do import extra objects at this point, you can delete them later if you determine that
they do not support your business model.
f. Click Next to open the Select Metadata Objects window.
g. In the Data source view pane, expand the BISAMPLE schema.
h. Scroll to view the tables in the BISAMPLE schema.
i. Select the SAMP_TIME_DAY_D table. This automatically deselects any higher-level
container objects in the tree.
j. Press and hold Ctrl and select the remaining three tables to import into the Physical

layer to build the initial business model:
SAMP_CUSTOMERS_D
SAMP_PRODUCTS_D
SAMP_REVENUE_F
k. Scroll to ensure that no higher-level container objects are selected, and that only the
four tables for import are selected.
l. Click the Import selected button to move the metadata objects to the Repository
View pane. The Connection Pool dialog box opens automatically.
m. Change the Connection Pool name to Sample Apps Connection Pool.
n. Ensure that the call interface is set to Default (OCI 10g/11g).

o. Ensure that the data source name is ORCL. The username and password fields are
automatically populated. The data source name, ORCL, is the same as the
tnsnames.ora entry for this Oracle database instance.

p. Click OK. The Connection Pool dialog box closes, the import process runs, and the
metadata objects are visible in the Repository View pane. Expand BISAMPLE in the
Repository View pane to see the objects.
q. Click Finish to complete the import process.

r. Notice that the metadata is imported into the Physical layer of the BISAMPLE
repository and that the ORCL database object appears in the Physical layer. Recall
that every repository contains three layers. The Physical layer is where information
about the physical data sources is stored. The Business Model and Mapping layer is
where the measurements and terms that are used in business are mapped to the
physical data sources. The Presentation layer is where the business model is
customized for presentation to users. You can work on each layer at any stage in
creating a repository, but the typical order is to create the Physical layer first, then the
Business Model and Mapping layer, and then the Presentation layer.

s. To display the tables in the Physical layer, expand the ORCL database object, and
then expand the BISAMPLE schema folder.
t. Ensure that the four tables are imported successfully and that the connection pool
name is changed to Sample Apps Connection Pool.
Recall that SAMP_TIME_DAY_D contains time information, SAMP_CUSTOMERS_D

contains customer information, and SAMP_PRODUCTS_D contains product
information for the business model. SAMP_REVENUE_F contains the revenue
information that is needed to create measures in the business model.
SAMP_TIME_DAY_D, SAMP_CUSTOMERS_D, and SAMP_PRODUCTS_D are the
dimension tables and SAMP_REVENUE_F is a fact table. In the next practice, you
create keys and joins so that the four tables form a star schema.
3. Examine the connection pool for the ORCL data source.
a. Double-click the Sample Apps Connection Pool connection pool object. Recall that
you provided this name for the connection pool during the import process. Connection
pools regulate access to the data source. Every data source must have at least one
connection pool. A connection pool provides connections for multiple, concurrent data
source requests (queries), reducing the immediate overhead of connecting to a data
source. Connection pools automatically queue connection requests when they exceed
connection pool limits. You can create more than one connection pool for a single data
source to give certain users more immediate access to data over others.
b. “Call interface” is the application program interface with which to access the data
source, Oracle Call Interface (OCI) in this example.
c. “Maximum connections” is the maximum number of connections allowed for this
connection pool. The default is 10. Each connection consumes about 1 MB of memory.
d. “Data source name” is configured to access the database to which you want to
connect. This value is set automatically when you import the tables to the physical
layer.
e. Username and password are also configured automatically during import depending on
the parameters set for the data source.
f. “Enable connection pooling” allows a single database connection to remain open for a
specified time (in minutes) for use by future query requests. Connection pooling saves
the overhead of opening and closing a new connection for every query. If you do not
select this option, each query sent to the database opens a new connection.

g. For more information about connection pool parameters, consult System
Administrator's Guide for Oracle Business Intelligence Enterprise Edition or click the
Help button.
h. Click OK to close the Connection Pool dialog box without making any changes.
4. Examine the properties of the database object in the Physical layer.
a. Right-click the ORCL database object and select Properties. You can also double-
click the object.
b. Click the General tab, if it is not selected by default. This tab provides general
information about the data source, such as the database name and database type. Set
the database type to Oracle 12c.
c. Click the Features tab. This tab lists features that, when selected or deselected,
determine the SQL that Oracle BI Server will issue for this database. This features

table is set to the database’s default values during the schema import process. You
can turn off any of these features if there is a reason to do so. Oracle BI Server will
adjust the SQL that it sends to the database accordingly, and will compensate for the
deselected features with its own functionality. Notice that turning a feature on when the
default is “off” may or may not cause that feature to be used in the generated SQL. To
use a feature, Oracle BI Server needs to know how the feature is implemented in that
database platform. If it does not know, it will not use it, even though the feature is
selected.

d. Click the Find button.
e. In the Find field, enter INTERSECT and click OK.
f. Notice that the INTERSECT_SUPPORTED feature is supported on this database
platform.
g. Click the Connection Pools tab. This tab displays all the connection pools that are
associated with this data source. In this example, there is only one connection pool,
Sample Apps Connection Pool.
h. Click the Display Folders tab. You could use this tab to create folders to organize the
information in the Physical layer.
i. Click OK to close the Database properties dialog box.
5. Examine the properties of a physical table object in the Physical layer.
a. Right-click SAMP_TIME_DAY_D and select Properties. The Physical Table properties
dialog box opens.
c. Notice that it is possible to rename the object by using the Name field. Do not rename
the object now.

d. Notice that the Cacheable check box is selected by default. This determines that
queries that hit this table will be cached. You could also select “Cache persistence
time” and use the field and drop-down list to determine the cache persistence time.
This determines how long the cached queries that include this table as a source should
be used to provide information to users. Ensure that the default, “Cache never expires,”
is selected. You learn more about caching in the lesson titled “Cache Management.”
e. Notice that you can select a table type from the Table Type drop-down list. Physical
Table is the default, and means that the object represents a physical table. You can
also select Stored Proc or Select. Stored Proc is used to call a stored procedure.
Select can be used when you want to create a SQL statement to represent a physical
table. Leave the table type set to Physical Table.
f. Notice that the Hint box is editable. This box is editable only when the database is
Oracle. A hint that is specified here is included in all SQL that references this table.

g. Notice that it is possible to add a description of the physical object.
h. Click the Columns tab.
i. Notice that all columns and the corresponding column properties are listed on this tab.
It is also possible to add new columns or delete existing columns.
j. Click the Keys and Foreign Keys tabs. Notice that no keys or foreign keys have been
created yet for this table. If keys and foreign keys are already defined in the source,
they are imported with the tables during import. In this example, the keys and foreign
keys were not defined in the BISAMPLE data source. You learn how to create keys
and foreign keys in the Physical layer later in this practice.
k. Click Cancel to close the Physical Table properties dialog box.
6. Examine the properties of a physical column object in the Physical layer.
a. Expand the SAMP_TIME_DAY_D table object.
b. Double-click any column to open the Physical Column properties dialog box. The
physical column properties include the data type of the column and whether the column
is nullable, that is, the column can contain NULL values. The Administration Tool
automatically selects compatible data types based on the data types of the source
database.
c. Click Cancel to close the Physical Column properties dialog box.
7. Update row counts and view data. It is a good idea to update row counts or view data after
an import to verify connectivity. Viewing data or updating row count, if successful, tells you
that you have everything configured correctly.
a. Update the row count for all tables by selecting Tools > Update All Row Counts. This
may take a moment. In this practice, you imported a small number of tables. Note that
updating row counts for all tables can take a long time if you have imported many large
tables. It is also possible to update row count for a single physical layer object by right-
clicking the object and selecting Update Row Count.
b. When Update All Row Counts completes, move the cursor over the tables and columns
and observe that row count information is now visible, including when the row count
was last updated.

c. Right-click any table and select View Data to view data for the table.
d. Close the View Data dialog box.
8. Save the repository.
a. Select File > Save or click the Save button on the toolbar. If the toolbar is not visible,
select Tools > Options > General > Show Toolbar.
b. Click No when prompted to check global consistency. Checking global consistency
checks for errors in the entire repository. Some of the more common checks are done
in the Business Model and Mapping layer and Presentation layer. Because these
layers are not defined yet, bypass this check until the other layers in the repository are
built.
c. Leave the repository open and remain logged in to the Administration Tool for the next
practice.

Practice 3-3: Creating Alias Tables
Overview
In this practice, you assign aliases to physical tables before mapping them to the Business
Model and Mapping layer.
Assumptions
You create aliases for the metadata objects that you imported into the Physical layer of the
repository. It is recommended that you use table aliases frequently in the Physical layer to
eliminate extraneous joins and to include best-practice naming conventions for physical table
names.

Time
20 minutes
Tasks
1. Create an alias for the SAMP_CUSTOMERS_D table.
a. Right-click SAMP_CUSTOMERS_D and select New Object > Alias. The Physical
Table dialog box opens.
b. Name the alias D3 Customers. This is a simple naming convention that identifies the
table as a dimension table and the data contained in the table.
c. Click the Columns tab. Notice that alias tables inherit all column definitions from the
source table.
d. Double-click any of the columns listed to open the Physical Column properties dialog
box. Notice that the column is read-only and cannot be modified.
e. Click Cancel to close the Physical Column dialog box.
f. Click OK to close the Physical Table dialog box. The alias table is added to the
Physical layer.
2. Create a new column in the source table and observe the results.
a. Right-click the SAMP_CUSTOMERS_D source table and select New Object >
Physical Column. The Physical Column dialog box opens.
b. Name the column ALIAS_COLUMN.

c. Leave the type set to UNKNOWN and click OK. The column is added to the
SAMP_CUSTOMERS_D source table.
d. Expand the D3 Customers alias table and confirm that the column was automatically
added. Creating a new column in a source table automatically creates the same

column in all its alias tables.
e. Double-click ALIAS_COLUMN in the D3 Customers alias table. The Physical Column

dialog box opens.
f. Confirm that the type is UNKNOWN.
g. Click Cancel.
h. Return to the SAMP_CUSTOMERS_D table and double-click ALIAS_COLUMN.
i. Change the type to VARCHAR.
j. Click OK.
k. Return to the D3 Customers alias table and double-click ALIAS_COLUMN.
l. Confirm that the type is changed to VARCHAR. Modification of a source column forces
the same changes to be reflected in the alias columns.
m. Click OK to close the Physical Column dialog box.
n. Return to the SAMP_CUSTOMERS_D table, right-click ALIAS_COLUMN, and select
Delete.
o. Click Yes to confirm the deletion.

3. Create alias tables for the three remaining physical tables:
Original Table Name Alias Table Name
SAMP_TIME_DAY_D D1 Time
SAMP_PRODUCTS_D D2 Products
SAMP_REVENUE_F F1 Revenue
4. Verify your work. The Physical layer should look similar to the following screenshot:

5. Click the Save button to save the BISAMPLE repository.
6. Click No when prompted to check global consistency.
7. Return to the D3 Customers alias table and confirm that ALIAS_COLUMN is deleted.
Deletion of a source column automatically deletes the corresponding alias column.
8. Leave the Administration Tool open for the next practice.

Practice 3-4: Defining Keys and Joins
Overview
In this practice, you define primary keys, foreign keys, and joins in the Physical layer of the
repository.
Assumptions
You have created a new repository, imported the initial tables from the BISAMPLE schema into
the Physical layer of the repository, and created alias tables. Now you define keys and joins in
the Physical layer of the repository. If the imported database already had primary key–foreign
key relationships defined and the primary keys and foreign keys were imported into the
repository, the join conditions would be set up automatically. But that is not always what you

want, because foreign key relationships are set in a database for only one purpose, referential
integrity, which may not correspond to the purpose of the Administration Tool and BI Server,
which is knowing which joins to include in SQL queries. In the BISAMPLE schema, primary
keys, foreign keys, and joins are not defined and were not imported into the repository.
Therefore, you need to define the keys and join conditions manually. You can create physical
keys and joins by using either Physical Diagram or Joins Manager.
Time
20 minutes
Tasks
1. In this step, you define joins and keys by using the Physical Diagram feature of the
Administration Tool.
a. Expand the ORCL database object so that all the physical objects are visible.
b. Select all four alias tables.
c. Right-click one of the four highlighted alias tables and select Physical Diagram >
Object(s) and All Joins to open the Physical Diagram dialog box. Alternatively, you
can click the Physical Diagram button on the toolbar.
d. If necessary, rearrange the alias table objects so that they are all visible in the Physical
Diagram.
e. Click the New Join button on the toolbar.
f. Click the F1 Revenue table, and then click the D1 Time table. The Physical Foreign
Key dialog box opens. Joins in the Physical Diagram and Business Model Diagram are
represented by a line with an arrow at the “one” end of the join. When creating joins in
Physical or Business Model diagrams, you select the “many” end of the join first, and
then select the “one” end of the join.

g. Select the columns that join the tables. Select the D1 Time.CALENDAR_DATE
column, and then select F1 Revenue.BILL_DAY_DT. Ensure that the Expression edit
box (at the bottom) contains the following expression:
"ORCL".""."BISAMPLE"."D1 Time"."CALENDAR_DATE" =
"ORCL".""."BISAMPLE"."F1 Revenue"."BILL_DAY_DT"

h. Click OK.
i. Observe the 1:N relationship between D1 Time and F1 Revenue represented in the
Physical Diagram view:

j. Repeat the process to create joins and keys for the other tables. Create the joins by
using the following expressions as a guide:
"ORCL".""."BISAMPLE"."D2 Products"."PROD_KEY" =
"ORCL".""."BISAMPLE"."F1 Revenue"."PROD_KEY"
"ORCL".""."BISAMPLE"."D3 Customers"."CUST_KEY" =
"ORCL".""."BISAMPLE"."F1 Revenue"."CUST_KEY"
k. You may want to adjust the objects in the Physical Diagram. If so, use the toolbar
buttons to zoom in, zoom out, fit the diagram, collapse or expand objects, select
objects, and so forth:

l. Observe the Physical Diagram and check your work. Your diagram should look similar
to the following screenshot:
m. Close the Physical Diagram window.

2. Observe the additional options for viewing the physical table diagram.
a. Right-click the D1 Time table and select Physical Diagram > Object(s) and Direct
Joins.

b. Observe the Physical Diagram. The diagram shows only those objects with direct joins
to D1 Time.
c. Close the Physical Diagram window.

d. Repeat this process for the F1 Revenue table by selecting Physical Diagram >

Object(s) and Direct Joins for the F1 Revenue table. Notice that all the tables are
visible in the diagram because all the tables have a direct join relationship with F1
Revenue.
e. Close the Physical Diagram window.
3. Observe the changes to the physical table properties.
a. Expand D1 Time. Notice that the CALENDAR_DATE column now has a key icon. The
key was defined when you created the join in the Physical Diagram. Similar keys are
defined for the D2 Products and D3 Customers tables.
b. Double-click the F1 Revenue table to open the Physical Table properties dialog box.
c. Click the Foreign Keys tab. Notice that the foreign key information is visible. This
information was created automatically when you created the join expressions in the
Physical Diagram.
d. Double-click any of the foreign key expressions and notice that the Physical Foreign
Key dialog box opens, displaying the join information.
e. Click Cancel to close the Physical Foreign Key dialog box.
f. Click Cancel to close the Physical Table properties dialog box.
4. Explore Joins Manager, which allows you to examine, edit, and delete all the joins, both
physical and logical, in a repository.
a. Select Manage > Joins. The Joins Manager opens. The joins displayed in the right
pane vary depending on the leaf that you select in the left pane. You can view all the
joins in the repository, in a particular business model, in the Business Model and
Mapping layer, in the Physical layer, in the Business Model and Mapping layer for a
particular business model, and in the Physical layer for a particular business model.
Joins are further divided into logical foreign key, logical join, physical foreign key, and
complex join.
b. In the left pane, select Business Model and Mapping. Notice that no joins are
displayed, because you have not yet created any logical joins in the Business Model
and Mapping layer. You do that later in the practices for the lesson titled “Building the
Business Model and Mapping Layer of a Repository.”

c. In the left pane, select Physical > Physical Foreign Key to see all physical foreign
key joins in the Physical layer. These are the joins that you created earlier in this
practice. Joins Manager displays the join name, the tables in the join, and the join
expression.
d. Double-click any of the foreign key expressions and notice that the Physical Foreign
Key dialog box opens, displaying the join information. Alternatively, you can right-click
any join in the list and select Properties to open the Physical Foreign Key dialog box.
You can edit the join properties by using this dialog box.
e. Click Cancel to close the Physical Foreign Key dialog box.
f. Click any column headings in the right pane to sort the joins by that column.
g. Select Action > New. Notice that you can create new joins by using Joins Manager.
However, most users tend to create joins with the physical or logical diagrams, as you

do in this course.
h. Select Action > Close to close Joins Manager.
5. Save the repository without checking global consistency.
6. Leave the repository and the Administration Tool open for the next practice.
Congratulations! You have successfully created a new repository, imported tables from an
external data source into the Physical layer, and defined keys and joins.


Building the Business Model
and Mapping Layer of a
Repository
Practices Overview
In these practices, you will create the Business Model and Mapping layer of a repository.
50 Practices for Lesson 4: Building the Business Model and Mapping Layer of a Repository
Practice 4-1: Creating the Business Model
Overview
In this practice, you create a business model in the Business Model and Mapping layer of the
repository.
Assumptions
In the previous practice, you created the Physical layer of the repository. You are now ready to
begin building the business model in the Business Model and Mapping layer of the repository.
The Business Model and Mapping layer of the Administration Tool defines the business model
of the data, and specifies the mapping between the business model and the Physical layer
schemas. Business models are also referred to as logical models or dimensional models.

Business models are always dimensional, unlike objects in the Physical layer, which reflect the
organization of the data sources. The Business Model and Mapping layer can contain one or
more business models. Each business model contains logical tables, columns, and joins.
There are two main categories of logical tables: fact and dimension. Logical fact tables contain
the measures by which a company gauges its business operations and performance. Logical
dimension tables contain the data that is used to qualify the facts. This practice assumes that a
business model has already been designed on paper. You know what measures are important,
which dimensions are used to qualify the measures, and how the company likes to analyze its
data. The goal of this practice is to capture this information in a business model in the Business
Model and Mapping layer of the repository.
Outcome
In the Business Model and Mapping layer, the Sample Apps business model is created with the
following logical tables: D1Time, D2 Products, D3 Customers, and F1 Revenue.
Time
20 minutes
Practices for Lesson 4: Building the Business Model and Mapping Layer of a Repository 51
Current State of the Repository
The initial business model that you build will be defined based on the revenue, product,
customer, and time data. In the previous set of practices, you built the Physical layer of the
repository, which now looks like the following:

Tasks
1. Return to the BISAMPLE repository, which should still be open in offline mode in the
Administration Tool. If the repository is not open, perform the following steps to open it.
a. Double-click the Administration Tool shortcut on the Desktop.
c. Navigate to D:\repository.
d. Double-click BISAMPLE.rpd to open the repository file.
e. Enter welcome1 as the repository password.
2. Create a business model in the Business Model and Mapping layer.
a. Right-click the white space of the Business Model and Mapping layer and select New
Business Model.
b. Name the business model Sample Apps.
c. Click OK. The Sample Apps business model folder appears in the Business Model and
Mapping layer. The red symbol on the business model indicates that it is not yet
enabled for querying. You enable the business model for querying later in this course
after the Presentation layer is defined and the repository passes a global consistency
check.
3. Create the logical tables.
a. In the Physical layer, expand the ORCL database object and expand the BISAMPLE
schema.
b. Drag the following four alias tables simultaneously from the Physical layer onto the
Sample Apps business model.
D1 Time
D2 Products
D3 Customers
F1 Revenue
This action creates the logical tables with the logical columns in the business model.
The logical joins are automatically inherited from the joins defined in the Physical layer.
c. Notice that the logical tables have different table icons. In the Business Model and
Mapping layer, a hash symbol (#) indicates a fact table.

d. Expand the logical tables and notice that a Sources folder is created for each logical
table. In each Sources folder, there is a logical table source. For example, the logical
table source for the D1 Time logical table is the D1 Time physical table.
4. Rename the logical source tables manually.

a. Double-click the D1 Time logical source table under the Sources folder for the D1
Time logical table. The Logical Table Source dialog box opens.
b. If necessary, click the General tab.
c. In the Name field, enter LTS1 D1 Time.
d. Click OK.
e. Repeat the renaming process for the logical source tables for the other logical tables:
LTS1 D2 Products, LTS1 D3 Customers, and LTS1 F1 Revenue.
5. Use the Rename Wizard to rename the logical columns in all the logical tables. You can
use the Rename Wizard utility for renaming the Business Model or Presentation layer
objects. You can use it to replace text strings, change all letters to lowercase, use
uppercase for the first letter of words, and so on. You can preview the new names before
committing the changes. It is primarily used on Business Model logical columns after
importing physical objects into the middle layer. The names that you give logical columns in
the business model can be exposed via the Presentation layer to end-user tools such as
the Analysis Editor. However, it is also possible to override logical column names in the
Presentation layer, as you will see later in this course. You can also rename logical objects
manually or right-click the object and select Rename.
a. Select Tools > Utilities > Rename Wizard and click Execute.
b. At the bottom of the middle pane, click Business Model and Mapping.
c. In the middle pane, expand Sample Apps > D1 Time logical table.

d. Use Shift + click to select all the D1 Time columns and click Add to add the columns
to the right pane.
e. Repeat the steps for the three remaining logical tables, so that all the logical columns
from the Sample Apps business model are added to the right pane.
f. Click Next. Notice that Logical Column is selected.
g. Click Next again to open the Select Rules screen.
h. Select All text lowercase and click Add to add the rule to the lower pane.
i. Select Change each occurrence of ‘_‘ into space and click Add.
j. Select First letter of each word capital and click Add.
k. Click Next.
l. In the Rename Wizard – Finish window, preview the changes before committing them.
m. Click Finish.
n. Examine the changes in the repository and verify that they are as expected.
o. Save the repository.
p. Do not check global consistency.
6. Delete unnecessary logical columns.
a. In the Business Model and Mapping (BMM) layer, expand Sample Apps > F1
Revenue.
b. Use Ctrl + Click to select all the F1 Revenue logical columns, except Revenue and
Units.
c. Right-click any one of the highlighted logical columns and select Delete. Alternatively,
you can select Edit > Delete or press the Delete key on your keyboard.
d. Click Yes to confirm the delete.
7. In this step, you verify the logical table keys. For a business model to be valid, each logical
dimension table must have a logical key. Logical keys can be composed of one or more
logical columns. The logical key defines the lowest level (the most detailed level) of
information of any source in the logical table. In this example, the logical table keys were
built automatically when you dragged the tables from the Physical layer to the business
model.
a. Double-click the D2 Products logical table in the business model to open the Logical
Table dialog box.
b. Click the Keys tab.
c. Confirm that the Prod Key column is defined as the key for this table.
d. Click OK to close the Logical Table dialog box.
e. Repeat these steps and ensure that the Calendar Date column is defined as the
logical table key for the D1 Time table and Cust Key is defined as the logical table key
for the D3 Customers table.
8. In this step, you verify the logical table joins. Another requirement for a valid business
model is that the logical tables must be joined via logical joins. Logical joins express the
cardinality relationships between logical tables. Logical fact tables are always at the “many”
end of these cardinality relationships. Logical joins help Oracle BI Server understand the
relationships between the various pieces of the business model. When a query is sent to
Oracle BI Server, the server determines how to construct physical queries by examining
how the logical model is structured. Examining logical joins is an integral part of this
process.

a. Right-click the Sample Apps business model and select Business Model Diagram >
Whole Diagram. The Logical Table Diagram window opens.
b. If necessary, rearrange the table icons so that they are all visible. Adjust the zoom
factor, if desired. Recall that the logical joins are automatically inherited from the joins
defined in the Physical layer. Later in this course, you learn how to build logical joins by
using the Business Model Diagram. The Business Model Diagram should look similar
c. Double-click one of the join connectors to open the Logical Join dialog box.
d. Leave the default values as they are, but notice which properties you can set in the
Logical Join dialog box: name, business model, tables, driving table, join type, and
cardinality. Also, notice which properties you cannot set: the join expression and the
join columns.
e. Do not change the default values. Click Cancel. Typically, when defining logical joins,
you leave the defaults as they are.
f. Close the Business Model Diagram window. The join relationships determine which
tables are the logical dimension tables and which is the logical fact table. Recall that a
fact table is always on the “many” side of a logical join. You now have a logical star
schema consisting of one logical fact table, F1 Revenue, and three logical dimension
tables: D1 Time, D2 Products, and D3 Customers.
11. Leave the repository open for the next practice.
Practice 4-2: Creating Simple Measures
Overview
In this practice, you examine the logical-to-physical column mappings and create simple
measures.
Assumptions
The Sample Apps business model is now defined in the Business Model and Mapping layer. In
this practice, you review the logical-to-physical table and column mappings to better understand
the relationships that exist between the logical tables and their logical table sources. You then
create measures by setting aggregation rules for logical columns. Then you check the physical
tables referenced by the business model.

Outcome
Measures are defined in the F1 Revenue logical table.
Time
5 minutes
Tasks
1. In this step, you examine a logical table source (LTS). Each logical table in a business
model has a subfolder called Sources that contains the logical table sources. Logical table
sources contain the mappings from the logical columns in the Business Model and Mapping
(BMM) layer to the physical columns in the Physical layer. Every logical column maps
directly (or indirectly via another logical column) to a column or columns in the Physical
layer.
a. Expand the Sources folder of the F1 Revenue logical table. This logical table source
was created automatically during the process of dragging the F1 Revenue physical
table to the business model. Notice that the name of the logical table source for the F1
Revenue table is LTS1 F1 Revenue. Recall that you renamed the logical table source
in the previous practice.
b. Double-click the LTS1 F1 Revenue logical table source to open the Logical Table
Source dialog box.
c. Click the General tab. By default, the logical table source name corresponds to the
name of the physical table that was dragged from the Physical layer, but this name was
changed to LTS1 F1 Revenue. Notice also that the path to the physical table is
identified in the “Map to these tables:” area.
d. Click the Column Mapping tab to review how the logical columns are mapped to the
Physical layer. If necessary, adjust the column widths or drag the entire dialog box
window to make it larger or smaller. You should see three column headings: Logical
Column, Expression, and Physical Table. For example, the Revenue logical column is
mapped to the REVENUE physical column in the F1 Revenue physical table.

e. The Content tab is discussed later in this course. Click Cancel to close the dialog box.
2. In this step, you create some measures by defining default aggregation rules on the logical
columns defined in the F1 Revenue logical table. Measures are typically data that is
additive, such as total revenue or total quantities. The F1 Revenue logical fact table
contains the measures in your business model. You aggregate some of its logical columns
by summing the column data.
a. Double-click the Revenue logical column in the F1 Revenue logical table. The Logical
Column dialog box opens.
b. Click the Aggregation tab.
c. Set the default aggregation rule for Revenue to Sum.
d. Click OK. Notice that the Revenue logical column icon has changed to a yellow icon to
indicate that an aggregation rule is defined.
e. Repeat the same for Units and set the default aggregation rule to Sum. Note that you
could use Ctrl + click to set the same aggregation rule for multiple columns at once.
f. Notice that the logical column icons are changed for both columns.
3. In this step, you check which physical tables are referenced by a business model. In some
situations, there may be tables that are included in the Physical layer, but not in the
Business Model and Mapping layer. Only the tables that are referenced in the Business
Model and Mapping layer, that is, only the tables that are included in logical table sources,
are used in queries. All other physical tables are ignored when Oracle BI Server queries the
physical database.
a. Select the Sample Apps business model.
b. Click the Physical Diagram icon on the toolbar.
c. The Physical Diagram displays all the physical tables that are currently referenced by
the Sample Apps business model.
d. Double-click the connector between the D3 Customers and the F1 Revenue tables.
Notice that the physical join is displayed. You can determine that this is a physical join

because there is a foreign-key join expression.
e. Click Cancel to close the join dialog box.
f. Close the Physical Diagram.
5. Do not check global consistency.
Congratulations! You have successfully built a business model in the Business Model and
Mapping layer of a repository and created business measures with aggregation rules.
Building the Presentation
Layer of a Repository
Practices Overview
In these practices, you will create the Presentation layer of an Oracle Business Intelligence
repository.
62 Practices for Lesson 5: Building the Presentation Layer of a Repository

Practice 5-1: Creating the Presentation Layer
Overview
In this practice, you create the Presentation layer of a repository.
Assumptions
You have created the initial Sample Apps business model in the repository. You now create the
Presentation layer of the repository. The Presentation layer exposes the business model objects
in the Oracle BI Analysis Editor so that users can build analyses to analyze data.
Outcome
In the Presentation layer of the repository, there is a Sample Sales subject area.

Time
10 minutes
Tasks
1. In this step, you create the Presentation layer for the Sample Apps business model. The
Presentation layer has three types of objects: subject area, presentation table, and
presentation column. In the Oracle BI Analysis Editor, the subject area appears as a subject
area, the presentation table appears as a folder, and the presentation columns appear as
columns in the folders. The BISAMPLE repository should still be open in the Administration
Tool from the previous practice.
a. Ensure that the Presentation layer is visible. If it is not, select View > Presentation.
b. Drag the Sample Apps business model into the Presentation layer. A subject area is
created with the name Sample Apps.
c. Expand Sample Apps in the Presentation layer. When you create presentation objects
by dragging a business model to the Presentation layer, the business model becomes
a subject area, the logical tables become presentation tables, and the logical columns
become presentation columns. All objects within a subject area must derive from a
single business model.
2. In this step, you examine the properties of a subject area.

a. Select Tools > Options to open the Options dialog box.
Practices for Lesson 5: Building the Presentation Layer of a Repository 63

c. Select Edit presentation names and click OK.
d. Double-click Sample Apps in the Presentation layer to open the Subject Area dialog
box.
e. Click the General tab. You use this tab to create or edit a subject area.
f. Notice that it is possible to change the name of the subject area. Change the subject
area name to Sample Sales. This is the name that appears as a subject area in the
Analysis Editor. Also, as you will see in later lessons, the name of the subject area is
used in the FROM clause of a logical SQL statement. Therefore, short names are
desirable. The tool prevents you from giving the same name to a subject area and a
presentation table. It is also advisable to avoid using characters ($, %) that may cause
illegal SQL syntax with particular client tools.
g. Click the Permissions button. This dialog box is used to assign user and application

role permissions to this repository object. Permissions are discussed in more detail in
the lesson titled “Security.”
h. Click Cancel to close the Permissions dialog box.
i. The custom display name is used if you are planning to present the name in local
languages. Leave it deselected.
j. Notice that the business model is disabled and cannot be modified. This is because all
the objects within a subject area derive from a single business model and cannot span
multiple business models. After the business model is set, it cannot be changed and
the tool prevents you from including objects from other business models.
k. Notice that “Export logical keys” is deselected by default. This is irrelevant to users of
the Analysis Editor, but may be advantageous to some third-party query and reporting
tools. If selected, columns in the Presentation layer that are key columns in the
Business Model and Mapping layer will be presented as key columns to an ODBC
client and will have a key icon in the Presentation layer.
l. Notice that the implicit fact column is not assigned. If you set an implicit fact column,
this column is added to a query when it contains columns from two or more dimension
tables and no measures. It is used to specify a default join path between dimension
tables when there are several possible alternatives. You learn more about configuring
implicit fact columns in the lesson titled “Setting an Implicit Fact Column.”
m. In the Description field, enter Analyze Revenue Data. This information is visible under
the corresponding subject area in Analysis Editor. You confirm this in the next set of
practices.
n. Click the Presentation Tables tab.
o. Use the Up and Down buttons or drag objects to rearrange the presentation tables in
the following order:
D1 Time
D3 Customers
D2 Products
F1 Revenue

p. Click the Aliases tab. Because the name of a subject area was changed, the tool
automatically creates an alias by using the previous name. You can use this tab to
specify or delete an alias for a subject area.
q. Click OK to close the Subject Area dialog box.
r. Expand the Sample Sales subject area and notice that the order of the presentation
tables is now changed in the Presentation layer.
3. Rename the presentation tables.

a. Rename the dimension presentation tables:
Presentation table Rename
D1 Time Time
D2 Products Products
D3 Customers Customers
F1 Revenue Base Facts
b. Double-click the Customers presentation table to open the Presentation Table
properties dialog box.
c. Click the Columns tab and notice that changing the presentation table name does not
impact the column mappings.
d. Click the Aliases tab and notice that the previous name for the presentation table has
been stored.

e. Click OK to close the Presentation Table dialog box.
f. Expand the Sample Apps business model in the Business Model and Mapping layer
and notice that changing the presentation table names in the Presentation layer has no
impact on the logical table names in the Business Model and Mapping layer.
4. In this step, you simplify the content by deleting unnecessary presentation columns. You
may not want to expose all the logical columns of a business model in a subject area. You
can delete columns from the Presentation layer safely without affecting the existence of the
corresponding logical columns in the Business Model and Mapping Layer. For example, key
columns in presentation tables can be deleted unless the client tools require that key
information be provided.
a. In the Presentation layer, in the Time table, delete all columns, except:
Calendar Date

Per Name Half
Per Name Month
Per Name Qtr
Per Name Week
Per Name Year
b. From the Customers table, delete all presentation columns, except Cust Key and
Name.
c. From the Products table, delete all presentation columns except Brand, Lob, Prod
Dsc, and Type.
d. In the Presentation layer, expand the presentation tables and confirm the deletions.
(Hint: Right-click the Sample Sales subject area and select Expand All.)

5. In this step, you explore the properties of a presentation table. You can use presentation
tables to hold columns from multiple logical tables, thereby reducing the number of
apparent logical tables. You can also use presentation tables to organize logical columns
into smaller groupings, thereby increasing the number of apparent logical tables. For
example, you might have a hundred measures in a logical fact table. You may want to
create multiple presentation tables as containers for those measures and thus present them
in an organized way (for example, all revenue measures in one folder and all unit measures
in another folder). These measure folders could be nested within a single folder in Analysis
Editor.
a. Double-click the Time presentation table in the Presentation layer. The Presentation
Table dialog box opens.
c. For presentation tables that are displayed in the Analysis Editor, the name can be
anything, except that it should not contain single quotation marks, double quotation
marks, or the “%” symbol. For client tools that generate SQL, it is advisable to avoid
names that might violate valid SQL syntax. For example, avoid SQL key words,
spaces, single and double quotation marks, and other characters such as “$” or “%.” A
presentation table name cannot be the same as the subject area name or any logical
column name in that catalog. As in a subject area, changing a presentation table name
does not have any effect on the logical table name in the Business Model and Mapping
layer. The Alias tab keeps a record of any changes.
d. Enter Time Data in the Description field. This will show up as a “tool tip” in the Analysis
Editor when the user places the cursor over the object. You confirm this in the next set
of practices.
e. Click the Columns tab.

f. Change the order of the columns by using the Up and Down buttons or by dragging the
columns, into the following order:
Columns
Per Name Year
Per Name Half
Per Name Qtr
Per Name Month
Per Name Week
Calendar Date
g. Click OK to close the Presentation Table dialog box.

h. Visually confirm that the column order is changed for the Time presentation table.
6. In this step, you explore the properties of presentation columns. Presentation columns can
come from multiple logical tables in a business model. By default, a presentation column
uses the same name as its corresponding logical column in the Business Model and
Mapping layer. If you rename the columns in the Business Model and Mapping layer, the
corresponding presentation columns are automatically renamed wherever they appear in
the Presentation layer. However, the reverse is not true. If you rename a presentation
column, it does not impact the corresponding logical column in the Business Model and
Mapping layer. However, as with subject areas and tables, the repository stores an alias for
the column by using the previous name.
a. Expand the Products presentation table.
b. Double-click the Lob column. The Presentation Column dialog box opens.
d. Deselect Use Logical Column Name. The Name field can now be edited.
e. Change the column name by entering Line of Business in the Name field.
f. Click the Aliases tab and observe that the original logical column name is stored for
this presentation column.
g. Return to the General tab.
h. Which logical column does this presentation column map to?

i. Which business model does this presentation column map to?
j. Which logical table does this presentation column map to?
k. Click the Edit button. The Logical Column dialog box opens.
l. Click the Column Source tab.
m. Which physical table and column does this presentation column map to?
n. Is this the original physical table that you imported, or the alias table that you created?

o. Click OK to close the Logical Column window.
p. Click OK to close the Presentation Column window.
Congratulations! You have successfully built the Presentation layer of a repository.

Solution 5-1: Creating the Presentation Layer
Answers
6.h. Which logical column does this presentation column map to?
Lob
6.i. Which business model does this presentation column map to?
Sample Apps
6.j. Which logical table does this presentation column map to?
D2 Products

6.m. Which physical table and column does this presentation column map to?
D2 Products.LOB
6.n. Is this the original physical table that you imported, or the alias table that you created?
Alias table

Testing and Validating a
Repository
Practices Overview
In these practices, you will test and validate a repository and make it available for queries.
72 Practices for Lesson 6: Testing and Validating a Repository

Practice 6-1: Testing the Repository
Overview
In this practice, you test the repository by creating some analyses, retrieving the results, and
examining the query log.
Assumptions
You have finished building the initial business model, and now you test the repository before
continuing. You begin by checking the repository for errors by using the consistency check
option. You then test the repository by using the Analysis Editor to create and run analyses.
Finally, you examine the query log file to verify the SQL generated by Oracle BI Server.

Time
45 minutes
Tasks
1. Modify the business model to generate an inconsistent business model due to a missing
logical join.
a. In the Business Model and Mapping layer, right-click Sample Apps and select
Business Model Diagram > Whole Diagram.
b. Select the join connection between the D1 Time and F1 Revenue logical tables.
c. Right-click the join and select Delete to create a condition in the business model where
an undefined join condition exists.
d. Click Yes to confirm the delete.
e. Close the Business Model Diagram window.
f. In the Business Model and Mapping layer, right-click Sample Apps and select Check
Consistency. The Consistency Check Manager appears, and displays an error
message for the Sample Apps business model. The error description explains that the
logical table, D1 Time, does not join to any other logical table.
The consistency check provides two types of messages:

Error messages indicate errors that must be fixed to make the repository consistent.
Warning messages indicate conditions that may or may not be errors, depending on
the intent of the Oracle BI Server administrator. For example, a warning message
about a disabled join may be the result of the administrator intentionally disabling a join
(for example, by eliminating a circular join condition).
Practices for Lesson 6: Testing and Validating a Repository 73

Notice that there are buttons that allow you to perform other tasks, such as going to the
object in the repository or copying the error message.
g. Click Close to close Consistency Check Manager.
2. Use the Business Model Diagram to repair the logical join.
a. Right-click the Sample Apps business model and select Business Model Diagram >
Whole Diagram.
b. Click the New Join icon on the toolbar.
c. Select F1 Revenue, and then D1 Time in the diagram. The order is important. The
Logical Join dialog box opens. Recall that you examined this dialog box in the practices
for the lesson titled “Building the Business Model and Mapping Layer of a Repository.”
d. Click OK to close the Logical Join dialog box.
e. The logical join between D1 Time and F1 Revenue is restored in the Business Model

Diagram.
f. Close the Business Model Diagram.

3. Set the system logging level. You do this so that you can check query logs after running
analyses later in this practice.
a. Select Tools > Options.
b. Click the Repository tab.
c. Set the system logging level to 2 and click OK.
4. Perform a global consistency check to check the repository for inconsistencies. A consistent
repository has met the following requirements:
• All logical columns are mapped directly or indirectly to one or more physical columns.
• All logical dimension tables have a logical key.
• All logical tables have a logical join relationship to another logical table.
• There are at least two logical tables in the business model: one is a logical fact table,
the other is a logical dimension table. Both tables may map to the same physical table.
• There are no circular logical join relationships.
• A presentation catalog exists for the business model.

a. Select File > Check Global Consistency. A message appears indicating that the
Sample Apps business model is consistent, and asks whether you want to mark it as
available for queries.
b. Click Yes. You should receive the following message: “Consistency check didn’t find
any errors, warnings or best practice violations.”

c. Click OK to close the message. The Sample Apps business model folder has changed
from unavailable for queries (red icon) to available for queries (green icon).
d. Save the repository. (Click No if prompted again to check global consistency, because
you just checked it.)
e. Select File > Close to close the repository.
f. Leave the Administration Tool open.
5. Use Oracle Enterprise Manager to disable cache. Caching is typically not used during
development, except to test the cache. You learn more about caching in the lesson titled
“Cache Management.”
a. Open a browser and enter http://localhost:9500/em to open Oracle Enterprise
Manager.
b. Log in as weblogic with the password welcome1.
c. In the top-left corner, select Target Navigation.
d. In the Target Navigation pane, expand Business Intelligence and select biinstance.

e. Click Configuration, and then the Performance subtab.
f. Locate the Enable BI Server Cache section. Cache is enabled by default.
g. In the upper-right corner, select Change Center (lock icon) > Lock and Edit.

h. You should receive the following confirmation message:
The edit session lock has been acquired. No pending changes exist.
i. Deselect Cache enabled.
j. Click Apply.
k. Select Change Center > Activate Changes.

l. Allow the Activate Changes processing to complete. You should receive the following
confirmation message:
All changes have been activated. The edit session lock has been released.
m. Click the Availability tab, and then the Processes subtab.

n. Select BI Servers.
o. Click Restart Selected. You must restart BI Server for the changes to take effect.
p. Click Yes to confirm the restart.
q. You should receive a confirmation message that the component restarted successfully.
r. Sign out of Enterprise Manager.

6. Use the uploadrpd command to upload the BISAMPLE repository to BI Server.
a. Return to the command window where you ran the uploadrpd command in an earlier
practice.
b. Confirm that the directory is set to
D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bitools\bin.
c. Run the datamodel.cmd utility with the following uploadrpd parameters:
datamodel.cmd uploadrpd -I D:\repository\BISAMPLE.rpd -W
Hint: Use the up arrow on the keyboard to return the most recent command and
change the repository name from ClassStart.rpd to BISAMPLE.rpd.
Note:
d. Confirm that you receive the following message:

e. Leave the command window open.
7. In this step, you enable query logging for the weblogic user. To test a repository, you
must build some analyses, retrieve the results, and examine the query log. You log query
activity at the individual-user level. Logging is intended for testing, debugging, and technical
support. In production mode, logging is normally disabled because query logging can
impact performance by producing very large log files.
a. Return to the Administration Tool.
b. Select File > Open > Online to open the BISAMPLE repository in online mode.
c. Enter weblogic as the user and welcome1 as the password.

d. Click Open to open the repository in online mode.

e. Select Manage > Identity to open Identity Manager.
f. In the left pane, select Identity Management > BI Repository.
g. Click the Users tab. In online mode, by default, no users are retrieved automatically,
because the list of users might be very large.
h. Select Action > Set Online User Filter to specify the set of users that you want to
retrieve. The filter is empty by default, which means that no users are retrieved. You
can enter an asterisk (*) to retrieve all users, or enter a combination of characters for a
specific set of users, such as A*, to retrieve all users whose names begin with the
letter A. The filter is not case-sensitive.
i. Enter an asterisk *.

j. Click OK to retrieve all users. A list of users appears in the right pane.

k. In the right pane, double-click weblogic. The User dialog box opens.
l. On the User tab, in the “Logging level” field, set the value to 2.
m. Click OK to close the User dialog box.

n. Click Check Out.
o. Select Action > Close to close the Identity Manager window. Additional security topics
are addressed in more detail in the lesson titled “Security.”
p. Select File > Check In Changes or click the Check In Changes icon on the toolbar.
q. Click Yes to check global consistency. You can ignore the Warning User "weblogic"
is not defined in the Enterprise Manager.
r. Close Consistency Check Manager.
s. Save the repository.
t. Select File > Close to close the repository.

u. Leave the Administration Tool open.
8. Open the Analysis Editor to build and execute analyses to test the Sample Sales business
model.
a. Open a browser and enter localhost:9502/analytics to open the Analysis Editor.
b. Sign in as weblogic with the password welcome1.
c. Select New > Analysis to open the Select Subject Area window. Notice that the
“Analyze Revenue Data” description that you created for the Sample Sales subject
area is visible.
d. Click the Sample Sales subject area to open the Analysis Editor.
e. Place the cursor over the Time folder and ensure that the “Time Data” description that
you entered in the practices for the previous lesson (the lesson titled “Building the
Presentation Layer of a Repository”) appears as a tool tip.

f. Select Show More Buttons > Refresh > Reload Server Metadata. When you make
changes to a repository in online mode, you must reload the server metadata in the
Analysis Editor.
9. Create a new analysis and format the columns.

a. Expand Time and double-click the Per Name Year column to add the column to the
analysis.
b. Expand Products and double-click the Type column to add the column to the analysis.
c. Expand Base Facts and double-click the Revenue column to add it to the analysis.
d. For the Revenue column, select Column Properties to open the Column Properties
dialog box.
e. In the Column Properties dialog box, click the Data Format tab.
f. Select Override Default Data Format.
g. In the Treat Number As field, select Currency.
h. In the Currency Symbol field, select $.
i. In the Decimal Places field, select 2.
j. Select the Use 1000’s Separator check box.
k. In the bottom-right corner of the Column Properties dialog box, select Save as
Default > Save as the system-wide default for ‘Base Facts.Revenue’.
l. In the Per Name Year column, select Sort > Sort Ascending.

m. Click the Results tab to view the results. Verify that the Revenue column is formatted
correctly and the Per Name Year column is sorted. Results show yearly revenue for
each product type.

10. Examine the query log.
a. Click Administration.
b. Click Leave Page.
c. In the Session Management section, click Manage Sessions to open the Manage
Sessions page.
d. In the Cursor Cache section, locate your query. It should look similar to the following
screenshot:
e. Click View Log.

f. Locate the query executed by the weblogic user. The log file should look similar to the
following screenshot:

g. Locate the SQL Request section. This section contains the logical SQL issued by the
query.
h. Just below the SQL Request section is the General Query Info section. This section
identifies the repository, subject area, and presentation catalog from which the query
was run. You may need to scroll right to see the General Query Info text.
i. Below the General Query Info section is the “Sending query to database named ORCL”
section. This section identifies the physical SQL issued by the query, the connection
pool, and the data source to which Oracle BI Server connects. Scroll right to see the
“Sending query to database named ORCL” text and the connection pool name.
j. Click the browser Back button to return to the Manage Session page.
k. Click the Back button to return to the Administration page.
l. Click Home to return to the Home page.
m. Sign out of Oracle BI.
Congratulations! You have successfully used the Consistency Check Manager, Oracle BI
Analysis Editor, and the query log to test and check the repository.

Managing Logical Table
Sources
Practices Overview
In these practices, you will manage the logical table sources in an Oracle BI repository.
84 Practices for Lesson 7: Managing Logical Table Sources

Practice 7-1: Importing Additional Dimension Tables
Overview
In this practice, you import dimension tables with additional customer information into the
Physical layer of the repository.
Assumptions
There are tables in the BISAMPLE source schema that store additional information about
customers. You want to add these tables to the customer dimension in the Business Model and
Mapping layer. You import these tables into the repository, create aliases, and then create keys
and foreign key joins for the tables. You also enable logging for the repository to allow you to
check the query log.

Outcome
The SAMP_ADDRESSES_D and SAMP_CUST_SEGMENTS_D tables are imported into the
Physical layer with associated keys and joins, and the D31 Customer Segments and D32
Customer Addresses physical alias tables are created.
Time
10 minutes
Tasks
1. In this step, you import additional customer tables that store customer address and
customer segment information. The customer dimension is an example of information
stored physically in a normalized table structure. In data warehouse design, this is referred
to as “snowflaking” a dimension. Many database administrators regard this as good
database design, so this is a very common practice. So far, you have included only the
information in the root customer table in the logical subject area. After import, you can
include related information from the other customer tables.
a. Return to the Administration Tool and open the BISAMPLE repository in offline mode
with the password welcome1.
b. In the Physical layer, expand the ORCL database object.
c. Right-click Sample Apps Connection Pool and select Import Metadata.
d. Accept the defaults in the Select Metadata Types window (Tables, Keys, and Foreign
Keys) and click Next.
e. In the “Data source view” pane, expand the BISAMPLE schema.
f. Use Ctrl + click to select the SAMP_ADDRESSES_D and
SAMP_CUST_SEGMENTS_D tables. Confirm that only the two tables are selected
and that no higher-level objects are selected.
g. Click the Import Selected button to move the tables to the Repository View pane.
Practices for Lesson 7: Managing Logical Table Sources 85

h. Expand BISAMPLE in the Repository View and verify that the two new customer tables
are visible. Deselect “Show complete structure” in the Repository View to see only the
tables for import.

i. Click Finish.
j. Verify that the tables are imported into the Physical layer.
k. Update row counts for the new tables to confirm connectivity.

2. Create aliases for the imported customer tables:
Table Alias
SAMP_CUST_SEGMENTS_D D31 Customer Segments
SAMP_ADDRESSES_D D32 Customer Addresses
3. Use the Physical Diagram to define joins and foreign keys.
a. In the Physical layer, select all the alias tables.
b. Right-click any one of the highlighted alias tables and select Physical Diagram >
Selected Object(s) Only to open the Physical Diagram view.
c. Click the Collapse All button on the toolbar.
d. Drag the table objects so that they are visible in the diagram and use the zoom buttons
as needed.

e. Use the New Join button on the toolbar to create the following join relationships:
"ORCL".""."BISAMPLE"."D31 Customer Segments"."SEGMENT_KEY" =

"ORCL".""."BISAMPLE"."D3 Customers"."SEGMENT_KEY"
"ORCL".""."BISAMPLE"."D32 Customer Addresses"."ADDRESS_KEY" =

"ORCL".""."BISAMPLE"."D3 Customers"."ADDRESS_KEY"
f. Check your results.

g. Close the Physical Diagram.
h. Save the repository. Do not check consistency.

Practice 7-2: Adding a New Mapping to an Existing Logical Table
Source
Overview
In this practice, you add information from the customer segments table to the customer
dimension.
Assumptions
You have imported dimension tables that store additional information about customers into the
Physical layer of the repository, created aliases, and configured keys and joins for the tables. So
far, the D3 Customers logical table in the Business Model and Mapping layer has information
only from the root customer table: SAMP_CUSTOMERS_D. You now add information from the

customer segments table, SAMP_CUST_SEGMENTS_D, to the D3 Customers logical table.
Outcome
In the Business Model and Mapping layer, the SAMP_CUST_SEGMENTS_D physical table is
added to the existing logical table source for the D3 Customers logical table. A segment
description logical column is added to the D3 Customers logical table, mapped to the
appropriate physical column, and added to the Presentation layer.
Time
10 minutes
Tasks
1. In this step, you add the information from the customer segments table to an existing logical
table source for the D3 Customers logical table. This practice and the next illustrate two
methods to map new information to a logical table. In this practice, you use the properties
window of an existing logical table source, which is a manual process, and requires several
steps. In the next practice, you use a more automated process to add a new logical table
source.
a. In the Business Model and Mapping layer, expand the D3 Customers logical table,
and then the Sources folder. At this point, there is only one logical table source, LTS1
D3 Customers, for this logical table. This logical table source was created when you
initially created the D3 Customers logical table and its corresponding columns.
b. Double-click LTS1 D3 Customers to view its properties.
c. Click the Column Mapping tab. Notice that all the logical columns map to physical
columns in the D3 Customers physical alias table.
d. Click the General tab and notice that LTS1 D3 Customers currently maps to only the
D3 Customers table in the Physical layer.
e. Click the Add icon to add a new table to the logical table source. In the Browse
window, Query Only Selectable Objects is selected by default. As a result, only those
tables that are already joined directly to the table in the logical table source are visible.

In this case, it includes all tables that join to the D3 Customers physical table. Only
tables that join to tables that are included in the logical table source can be added to
the logical table source. For example, notice that D2 Products is not visible in the
browse list. This is because it does not have a direct join relationship with D3
Customers in the Physical layer.

f. In the Browse window, select the D31 Customers Segments table and click the
Select button. The table is added to the logical table source and the join is displayed in
the Joins section on the General tab.

g. For the purpose of these practices, leave the join type as Inner. To change a join to an
outer join, you could use the drop-down list in the Type column. This allows you to
change the join type from inner to three kinds of outer joins. You can think of the tables
in a logical table source as being similar to a database view. When it formulates
physical SQL, Oracle BI Server will leave out the tables in this “view” that are not
needed to satisfy the logical query (join elimination), but only if the join type is Inner.
When the join type is Outer, however, Oracle BI Server will always include the tables.
One of the main reasons to include multiple tables in a single logical table source is to
control join behavior. Using a single logical table source allows for a wide range of join
configurations (which rely on BI Server join trimming rules), whereas multiple logical
table sources use an inner join by default and there is no opportunity to create an outer
join.
h. Click OK to close the Logical Table Source dialog box.

2. In this step, you create a new logical column based on the modified logical table source. In
the previous step, you used the manual method to add a physical table to a logical table
source. This method does not add any logical columns to the logical table, nor does it
change the logical-to-physical mapping of any existing column. Now that the physical table
that stores the customer segment information has been added to the LTS1 D3 Customers
logical table source, you create a new logical column and map it to the appropriate physical
table and column.
a. In the Business Model and Mapping layer, right-click D3 Customers and select New
Object > Logical Column.
b. Enter Segment in the Name field and click OK. The Segment logical column is added
to the D3 Customers logical table in the Business Model and Mapping layer.
c. Double-click the LTS1 D3 Customers logical table source to open its properties dialog
box.
d. Click the Column Mapping tab.
e. If necessary, select the Show unmapped columns check box. Notice that the column
that you just created, Segment, is not mapped to any physical column.

f. Use the drop-down list in the Expression field to map the Segment logical column to
the SEGMENT_DESC physical column in D31 Customer Segments.

g. Click OK to close the Logical Table Source dialog box.
h. Drag the Segment column to the Customers table in the Presentation layer.
i. Save the repository without checking consistency.

Practice 7-3: Adding a New Logical Table Source
Overview
In this practice, you add the information from the customer address table to the D3 Customers
logical table.
Assumptions
You have manually added information from the customer segments table to the D3 Customers
logical table. Now you add information from the customer addresses table to the D3 Customers
logical table by using a more “automated” method. This automated method adds a new logical
table source for the D3 Customers logical table, and simultaneously adds logical columns and
associated physical mappings.

Outcome
In the Business Model and Mapping layer, the D32 Customer Addresses physical table is added
to the LTS2 D3 Customer Addresses logical table source for the D3 Customers logical table.
Also, logical columns with customer address information are added to the D3 Customers logical
table and automatically mapped to the appropriate physical columns.
Time
10 minutes
Tasks
1. In this step, you use an automated method to add a new logical table source and logical
columns to the D3 Customers logical table.
a. In the Business Model and Mapping layer, expand D3 Customers > Sources.
b. In the Physical layer, expand ORCL > BISAMPLE.

c. Drag the D32 Customer Addresses table from the Physical layer to the Sources
folder for D3 Customers. This automatically creates a new logical table source named
D32 Customer Addresses, and automatically creates new logical columns for D3
Customers.
d. Double-click the new D32 Customer Addresses logical table source to open the
Logical Table Source dialog box.
e. On the General tab, rename the logical table source to LTS2 D3 Customer
Addresses.

f. Notice in the “Map to these tables” section that this logical table source is automatically
mapped to the D32 Customer Addresses physical table.
g. Click the Column Mapping tab.
h. Select Show mapped columns and deselect Show unmapped columns. Notice that
the new logical columns are automatically mapped to the appropriate columns in the
D32 Customer Addresses physical table.

i. Click OK to close the Logical Table Source properties dialog box and confirm that the
logical table source is renamed to LTS2 D3 Customer Addresses.
j. Delete the ADDRESS_KEY (all caps) logical column because it is a duplicate key.

2. Use the Rename Wizard to rename the new customer address logical columns in the D3
Customers logical table by using the following renaming rules.
Hint: Select the columns, and then right-click one of the selected columns and select
Rename Wizard.
All text lowercase
Change each occurrence of ‘_’ into a space
First letter of each word capital

3. Add new customer address information to the Sample Sales subject area.
a. Drag the following new logical columns from the Business Model and Mapping layer to
the Customers table in the Sample Sales subject area.
Column Name
Address 1
Address 2
City
Country Name
Estab Name
Postal Code
Region
State Province
State Province Abbrv

b. Order the columns in the Customers table in the Presentation layer as follows:
Cust Key
Name
Estab Name
Region
Address1
Address2
City
Postal Code
State Province
State Province Abbrv
Country Name
Segment

c. Save the repository.
d. Check consistency. You should receive a valid consistency check message.
e. Click OK to close the consistency check message. If you receive any error or warning
messages, fix them before proceeding.
f. Close the repository.

a. Return to the open command window where the directory is set to
b. Run the datamodel.cmd utility with the following uploadrpd parameters:
Note:

D removes all the existing customization on the server, and uploads only the metadata
for this repository.
c. Confirm that you receive the following message:
d. Exit the command window.
5. Open the Analysis Editor to execute queries and test the Sample Sales subject area.
a. Return to the browser with Oracle BI open and sign in as weblogic with the password
welcome1.
b. Select Create… > Analysis to open the Select Subject Area window.
c. Click Sample Sales to open the Analysis Editor.
d. Select Show More Buttons > Refresh > Reload Server Metadata.
e. Create the following analyses:
Customers.Name
Customers.City
Customers.Segment
Base Facts.Revenue

f. Click the Results tab to view the results. The following screenshot shows partial
results:

6. Examine the query log to determine which table or tables have been accessed for this
query.
a. Click the Administration link.
b. Click Leave Page when prompted.
c. On the Administration page, under Session Management, click Manage Sessions.
d. Under Cursor Cache, locate your analysis and click View Log.
e. Examine the query log. Notice that the three customer tables, SAMP_ADDRESSES_D,
SAMP_CUSTOMERS_D, and SAMP_CUST_SEGMENTS_D, have all been accessed.
The log should look similar to the following screenshot:

f. Why are all three customer tables included in the query? All the three tables are
included because you added multiple logical table sources to the D3 Customers logical
table. The two logical table sources map to a total of three physical tables. The Name,
City, and Segment logical columns that are included in the query each map to physical
columns in their respective tables.
g. Click the browser Back button to return to the Manage Sessions page.
h. Click the Back button to return to the Administration page.
i. Sign out of the Analysis Editor.


Adding Calculations to a Fact
Practices Overview
In these practices, you will create calculation measures in an Oracle BI repository.
102 Practices for Lesson 8: Adding Calculations to a Fact

Practice 8-1: Creating Calculation Measures
Overview
In this practice, you create calculation measures.
Assumptions
You use two different methods to create measures that contain calculations. First, you create a
measure that is derived from other existing logical columns as a way to apply post-aggregation
calculations to the measure. Then you create a measure by using physical columns as a way to
apply pre-aggregation calculations to the measure. In both cases, you use analyses and the
query log to verify your results.

Outcome
Your model includes the Actual Unit Price logical column with post-aggregation calculations
derived from existing logical columns, and the Net Costs logical column with pre-aggregation
calculations based on physical columns.
Time
35 minutes
Tasks
1. In this step, you define a new logical measure that is derived from other existing logical
columns as a way to apply post-aggregation calculations to the measure.
a. Return to the Administration Tool, which should still be open, and open the BISAMPLE
repository in offline mode with the repository password welcome1.
b. In the Business Model and Mapping layer, right-click the F1 Revenue logical table and
select New Object > Logical Column.
c. On the General tab, name the column Actual Unit Price.
d. Click the Column Source tab.
e. Select Derived from existing columns using an expression.
f. Click the Edit Expression button to open the Expression Builder.
g. Under Category, select Logical Tables.
h. Under Logical Tables, select F1 Revenue.
i. Under Columns, select Revenue.
j. Click the Insert selected item arrow to add Revenue to the expression.
k. Click the division sign on the toolbar.
l. Under Columns, double-click the Units logical column to insert it in the formula.
Practices for Lesson 8: Adding Calculations to a Fact 103

m. Check your results:

n. Click OK to close the Expression Builder. Notice that the expression is now displayed
in the text edit box of the Logical Column dialog box.
o. In the “Derives from” field, observe the calculation that will be sent to the data source in
the physical SQL.
p. Click OK to close the Logical Column dialog box. The Actual Unit Price calculation
measure is added to the business model.
2. Create a new folder in the Presentation layer.
a. In the Presentation layer, right-click Sample Sales and select New Presentation
Table.
b. On the General tab, name the table Calculated Facts and click OK.
c. Drag the new Actual Unit Price column to the Calculated Facts table in the Sample
Sales subject area.
3. Create a measure by using physical columns as a way to apply pre-aggregation
calculations to the measure.
a. In the Business Model and Mapping layer, expand F1 Revenue > Sources.
b. Double-click LTS1 F1 Revenue.
c. Click the Column Mapping tab.
d. Click the Add New Column button to open the Logical Column dialog box.
e. Name the column Net Costs.
f. Click the Aggregation tab and set the aggregation to Sum.
g. Click OK to close the Logical Column dialog box.
h. Select the Show unmapped columns check box to see the Net Costs logical column
in the Logical Table Source dialog box.
i. Select Net Costs and click the Edit Expression button to open the Expression
Builder.

j. Under Category, select Physical Tables.
k. Under Physical Tables, select F1 Revenue.
l. Under Columns, double-click COST_FIXED to add it to the formula.
m. Click the addition icon on the toolbar to add it to the formula.
n. Double-click COST_VARIABLE to add it to the formula.

o. Click OK to close the Expression Builder.
p. Notice that you can see the formula in the Expression column for Net Costs on the
Column Mapping tab. You may need to adjust the column width to see the entire
formula.
q. Click OK to close the Logical Table Source properties dialog box.
r. Double-click the Net Costs logical column.
s. Click the Column Source tab and notice that Net Costs is not derived from existing
columns by using an expression, but rather from physical mappings. In the “Derives
from” field, notice that the formula adds the physical columns first, and then sums the
result.
t. Click OK to close the Logical Column properties dialog box.

u. Add Net Costs to the Calculated Facts presentation table in the Sample Sales
subject area in the Presentation layer.
v. Save the repository.
w. Click Yes to check global consistency. Fix any errors or warnings before proceeding.

Practice 8-2: Creating Calculation Measures by Using the Calculation
Wizard
Overview
In this practice, you create calculation measures by using the Calculation Wizard.
Assumptions
Using the Calculation Wizard, you create two calculation measures named Profit and Profit
Percent. The Profit measure calculates the difference between revenue and net costs. The
Profit Percent measure calculates the percentage of profit for net costs. The calculation
measures that are created by the Calculation Wizard are based on existing logical columns.

Outcome
In the Business Model and Mapping layer, the Profit and Profit Percent calculated columns are
added to the F1 Revenue logical table. In the Presentation layer, Profit and Profit Percent are
added to the Calculated Facts presentation table.
Time
20 minutes
Tasks
1. In this step, you create two calculation measures by using the Calculation Wizard.
a. In the Business Model and Mapping layer, expand the F1 Revenue table.
b. Right-click the Revenue column and select Calculation Wizard.
c. In the Calculation Wizard – Introduction dialog box, click Next.
d. In the Choose columns pane, F1 Revenue is selected. The columns that are available
to include in the calculation appear in the right pane.
e. Select the Net Costs check box.
f. Click Next.
g. In the Generate Calculations section, ensure that both the Change and Percent
Change check boxes are selected. It may be necessary to enlarge the dialog box to
see the selections.

h. In the Generate Calculations section, ensure that Change is highlighted.
i. In the Calculation Name field, enter Profit.

j. Notice the results that are returned when Profit is NULL:
k. In the Generate Calculations section, select Percent Change so that it is highlighted.

l. Change the Calculation Name to Profit Percent.
m. Notice the results that are returned when Net Costs is not available (NULL) or is zero
by using the following parameters. The following screenshot shows only partial results:
n. Click Next to view the Finish window.

o. Review the two calculations measures that will be created by the Wizard: Profit and
Profit Percent.
p. Click Finish.

q. In the Business Model and Mapping layer, confirm that the two new columns created
by the Calculation Wizard, Profit and Profit Percent, are visible in the F1 Revenue
table.
r. Drag the Profit and Profit Percent logical columns to the Calculated Facts
presentation table in the Sample Sales subject area.
s. Save the repository and check consistency.

Practice 8-3: Creating a Rank Measure
Overview
In this practice, you create a rank measure.
Assumptions
You use the RANK function to calculate rank for the Revenue logical column.
Time
20 minutes
Tasks

1. Create a new rank measure that references existing logical columns.
a. In the Business Model and Mapping layer, right-click the F1 Revenue logical table and
select New Object > Logical Column.
b. On the General tab, name the column Rank Revenue.
c. On the Column Source tab, select Derived from existing columns using an
expression.
d. Open the Expression Builder.
e. Select Functions > Display functions > Rank.
f. Double-click Rank or click Insert to add the Rank function.
g. Select <<numeric expression>> in the right pane.

h. Select Logical Tables > F1 Revenue and double-click Revenue to add it to the
formula.

i. Click OK to close the Expression Builder.

j. Check your work:

k. Click OK to close the Logical Column dialog box. Rank Revenue is added to the
business model.
l. Add the Rank Revenue measure to the Calculated Facts presentation table in the
Presentation layer.
m. Save the repository and check consistency. Fix any errors or warnings before
proceeding.
n. Close the repository.
o. Leave the Administration Tool open.

Practice 8-4: Testing and Validating the Repository Measures
Overview
In this practice, you test the repository by generating some queries, retrieving the results, and
examining the query log.
Assumptions
You created five new measures in earlier practices: Actual Unit Price, Net Costs, Profit, Profit
Percent, and Rank Revenue. You now test the repository by using the Analysis Editor to run
queries with these measures. Finally, you examine the query log file to verify the SQL generated
by Oracle BI Server.

Time
20 minutes
Tasks
a. Run the datamodel.cmd utility with the following uploadrpd parameters:
b. Confirm that you receive the following message:
2. Open the Analysis Editor to execute queries and test the Sample Sales business model.
a. Return to the browser and sign in to Oracle BI Analysis Editor as weblogic with the
password welcome1.
b. Select Create… > Analysis to open the Select Subject Area window.
c. Click Sample Sales to open Analysis Editor.
d. Select Show More Buttons > Refresh > Reload Server Metadata.
e. Create the following analysis:
Products.Brand
Base Facts.Revenue
Base Facts.Units
Calculated Facts.Actual Unit Price
f. Select Column Properties for Actual Unit Price.

g. On the Data Format tab, override the default data format, set the data format to
Currency with the $ currency symbol, set decimal places = 2, and select Use 1000’s
Separator.

h. Save the data format as the system-wide default for Actual Unit Price.
i. Click Results.
j. Click the Administration link, and then click Leave Page when prompted to open the
Administration page.
k. Under Session Management, click Manage Sessions to open the Manage Sessions
page.
l. Locate your query and click View Log in the Action field.

m. Examine the query log, which should be similar to the following:
n. Notice that UNITS and REVENUE are summed first in the query, and then the division
of Actual Unit Price is calculated in the outer query block (D1.c2 / nullif (D1.c1,
0) as c5 in this example). Because you defined the Actual Unit Price calculation by
using logical columns, the columns are summed first, and then the division is
calculated.

3. Check your work for the Net Costs column.
a. Return to the Analysis Editor and create a new analysis in the Sample Sales subject
area with the following columns:
Products.Brand
Base Facts.Revenue
Base Facts.Units
Calculated Facts.Net Costs
b. Override the default data format for Net Costs to display the data as currency.
c. Click Results.

d. Examine the query log. Your results should resemble the following screenshot:
e. Notice that the addition of COST_FIXED and COST_VARIABLE is calculated first, and
then summed: (sum(T7.COST_FIXED + T7.COST_VARIABLE) as c1 in this
example). Compare these results with the query results for the prior calculation that
used existing logical columns in the formula, where the columns were summed first,
and then calculated. What are the advantages and disadvantages of defining a logical
column in terms of other logical columns, rather than in terms of the physical sources
directly? The advantage of defining a logical column formula based on existing logical
columns is that you have to define it only once. When you create formulas based on
physical columns, you have to map to each physical source from which they could be

derived. However, sometimes you have no choice if you have to use physical columns
to apply an aggregation rule after a calculation. What would happen if you deleted a
logical column that is used to define the formula of another logical column? The
derived column would not be deleted automatically. However, the tool would display an
icon that warns you about this condition. Don’t do this! This is only for informational
purposes.
4. Check your work for the Profit and Profit Percent columns.
a. Return to the Analysis Editor and create the following new analysis in the Sample
Sales subject area:
Products.Brand
Base Facts.Revenue
Calculated Facts.Net Costs
Calculated Facts.Profit

Calculated Facts.Profit Percent.
b. Override the default data format for Profit to display the data as currency.
c. Override the default data format for Profit Percent to display the data as percentage.
d. Click Results.
e. Examine the query log. Your results should resemble the following screenshot:

f. Notice that Net Costs and Revenue are summed first as c1 and c2, and then Profit
and Profit Percent are calculated as c5 and c6. This is because the Calculation
Wizard used logical columns to build the calculations.
5. Check your work for Rank Revenue.
a. Return to the Analysis Editor and create the following new analysis in the Sample
Sales subject area:
Products.Brand
Base Facts.Revenue
Calculated Facts.Rank Revenue.

b. Click Results.
The results show total revenue for each brand and how each brand ranks in the total
revenue.
c. Sign out of the Analysis Editor.

Working with Logical
Dimensions
Practices Overview
In these practices, you build logical dimensions with level-based hierarchies.
118 Practices for Lesson 9: Working with Logical Dimensions

Practice 9-1: Creating Logical Dimension Hierarchies
Overview
In this practice, you add logical dimension hierarchies to the business model.
Assumptions
In this set of steps, you add logical dimension hierarchies to the business model. A logical
dimension represents a hierarchical organization of logical columns belonging to a single logical
dimension table. Logical dimensions can exist in the Business Model and Mapping layer and in
the Presentation layer. Adding logical dimensions to the Presentation layer exposes them to
users, which enables users to create hierarchy-based queries. In this practice, you build three
logical dimensions: Time, Product, and Customer. Creating logical dimensions with hierarchies

allows you to build level-based measures, define aggregation rules that vary by dimension,
provide drilldown on charts and tables in analyses and dashboards, and define the content of
aggregate sources.
Outcome
In the Business Model and Mapping layer, there are Time, Product, and Customer logical
dimensions.
Time
35 minutes
Tasks
1. Create a logical dimension for products.
a. Return to the Administration Tool, which should still be open, and open the BISAMPLE
repository in offline mode with the repository password welcome1.
b. In the Business Model and Mapping layer, right-click Sample Apps and select New
Object > Logical Dimension > Dimension with Level-Based Hierarchy. The Logical
Dimension dialog box opens.
c. Name the logical dimension H2 Product.
d. Click OK. The new logical dimension appears in the Business Model and Mapping
layer. Notice the three-arrow icon.
2. Add the parent level of the hierarchy.

a. Right-click the H2 Product logical dimension and select New Object > Logical Level.
Practices for Lesson 9: Working with Logical Dimensions 119

b. Name the logical level Product Total.
c. Because this level represents the grand total for products, select the Grand total level
check box. Notice that when you do this, the “Supports rollup to higher level of
aggregation” field is disabled and protected.
d. Click OK to close the Logical Level dialog box. The Product Total level is added to the
H2 Product logical dimension.
3. Add the child levels of the hierarchy.
a. Right-click the Product Total level and select New Object > Child Level to open the
Logical Level dialog box.
b. Name the logical level Product Brand.
c. Click OK to close the Logical Level dialog box. The Product Brand level is added to the
logical dimension as a child of the Product Total level.

d. Repeat the steps to add the following child levels:
Product LOB as a child of Product Brand
Product Type as a child of Product LOB
Product Detail as a child of Product Type
Your hierarchy should appear as follows:
4. In this step, you associate columns from the logical dimension table with levels in the logical
dimension hierarchy, starting from top to bottom. Some guidelines for associating columns
with levels are as follows:
• Not all columns in the dimension table must be associated explicitly with a level; the
ones that are not will be associated with the lowest level implicitly.
• No columns can be associated with more than one level (although it may be part of the
level key of a lower level).
• If a column pertains to more than one level, associate it with the highest level that it
belongs to.
• No level except the Grand Total level can exist without at least one column being
associated with it.
• The detail level (lowest level) must have the column that is the logical key of the
dimension table associated with it and it must be the key for that level.
a. In the Business Model and Mapping layer, expand the D2 Products table.
b. Drag the Brand column from D2 Products to the Product Brand level in H2 Product.

c. Continue dragging logical columns from the D2 Products logical table to the H2
Product logical dimension levels:
Logical Column Level
Lob Product LOB
Type Product Type
Prod Dsc Product Detail
Prod Key Product Detail
d. Check your work.

Any column that is not associated explicitly with a level is associated implicitly with the
detail level. In this example, Type Key and Brand Key (among others) are, by default,
associated with the Product Detail level. The logical dimension table key column, Prod
Key in this example, must be associated explicitly with the lowest level, Product Detail.
e. Double-click the Type column in the D2 Products logical table. The Logical Column
dialog box opens.
f. Click the Levels tab. This tab identifies the logical dimensions and logical levels
associated with this logical column. These values were set when you dragged the
column into the Product logical dimension hierarchy.
g. Click the drop-down list for the Product Type logical level. Notice that this is another
method for associating logical columns with dimensions and logical levels. You use this
method in the next practice. Leave the logical level set to Product Type.
h. Click Cancel to close the Logical Column dialog box.

5. In this step, you specify the level keys for the Product Brand level in the hierarchy. Each
logical level (except the top level that is defined as the Grand Total level) must have one or
more attributes that compose a level key. The level key defines the unique elements in
each logical level. The logical key for a logical table must be associated with the lowest
level of a logical dimension hierarchy, and must be the level key for that level.
a. In the H2 Product logical dimension, double-click the Product Brand logical level to
open the Logical Level dialog box. On the General tab, notice that the Product LOB
child level is displayed.
c. Enter Brand in the Key Name field.
d. In the Columns field, use the drop-down list to select D2 Products.Brand.
e. Leave the Description field blank.

f. Select Use for Display. When this is selected, users can drill down to this column from
a higher level.
g. Set Brand as the Primary key.
h. Click OK to close the Logical Level dialog box. In the H2 Product logical dimension, the
icon changes for Brand to show that it is the key for the Product Brand level.
6. Set the level keys for the Product LOB level by using a different method.
a. In the H2 Product logical dimension, right-click the Lob column for the Product LOB
level and select New Logical Level Key to open the Logical Level Key dialog box.
b. Ensure that the Lob check box is selected.
c. Ensure that the Use for Display check box is selected.
d. Click OK to close the Logical Level Key dialog box.
e. In the H2 Product logical dimension, the icon changes for Lob to show that it is the key
for the Product LOB level.
7. Use either method to set the remaining keys for the H2 Product logical dimension:
Logical Level Logical Level Key Use for Display
Product Type Type Yes
Product Detail Prod Dsc Yes
Product Detail Prod Key No

8. Check your final results. Note that the Detail level (lowest level of the hierarchy) must have
the column that is the logical key of the dimension table associated with it and it must be
the key for that level (Prod Key in this example).

9. Set Prod Key as the primary key for the Product Detail level. Hint: Double-click the level
and click the Keys tab.
10. In this step, you use another method to create a Time logical dimension.
a. Right-click the D1 Time logical table and select Create Logical Dimension >
Dimension with Level-Based Hierarchy. A new logical dimension, D1 TimeDim, is
automatically added to the business model.
b. Rename D1 TimeDim to H1 Time.
c. Expand H1 Time. Notice that two levels were created automatically: D1 Time Total and
D1 Time Detail. D1 Time Detail is populated with all the columns from the D1 Time
logical table.
d. Rename D1 Time Total to Time Total, and rename D1 Time Detail to Time Detail.
e. Right-click Time Detail and select New Object > Parent Level to open the Logical
Level dialog box.
f. On the General tab, name the logical level Week, and select Supports rollup to
higher level of aggregation.
g. Click OK to close the Logical Level dialog box. The Week level is added as a parent
level to the Time Detail level in the H1 Time logical dimension.

h. Repeat the steps to add the remaining logical levels:
Month as a parent of Week
Quarter as a parent of Month
Half as a parent of Quarter
Year as a parent of Half
Your final results should look similar to the following screenshot:

11. Use another technique to associate the D1 Time logical columns with the H1 Time logical
levels.
a. Add columns to the hierarchy by dragging the logical columns from the Time Detail
logical level (not from the D1 Time logical table) to their corresponding levels in the H1
Time logical dimension. This is a useful method when business models are large and
logical columns are buried deep in the business model. It eliminates the need to scroll
through logical tables to locate columns.
Logical Column Logical Level
Per Name Year Year
Per Name Half Half
Per Name Qtr Quarter
Per Name Month Month
Per Name Week Week

b. Check your work:

c. Delete all the remaining columns from the Time Detail level, except Calendar Date so
that only Calendar Date is associated with the Time Detail level. Notice that deleting
objects from the hierarchy does not delete them from the logical table in the business
model.
d. Set the logical keys for the H1 Time logical dimension according to the following table:
Logical Level Level Key Use for Display
Year Per Name Year Yes
Half Per Name Half Yes
Quarter Per Name Qtr Yes
Month Per Name Month Yes
Week Per Name Week Yes
Time Detail Calendar Date Yes

e. Check your work:

12. Create a logical dimension for D3 Customers.
a. Use either technique to create a logical dimension with a level-based hierarchy named
H3 Customer for the D3 Customers logical table with the following levels, columns,
and keys.
Hint: Create the levels first, and then double-click a logical column to open the Logical
Column dialog box. Use the Levels tab to associate the logical column with a logical
level.
Logical Level Logical Column Level Key Use for Display
Customer Total <none> <none> <none>
Customer Region Region Region Yes
Customer Area Area Area Yes
Customer Country Country Name Country Name Yes
Customer State State Province State Province Yes
Customer City City City Yes
Customer Postal Code Postal Code Postal Code Yes
Customer Detail Name Name Yes
Customer Detail Cust Key Cust Key No
b. Set Customer Total as the Grand Total level.
c. Set Cust Key as the primary key for the Customer Detail level.
d. Remove all columns from the Customer Detail level, except Cust Key and Name.

e. Check your work:

13. Create a preferred drill path for the Customer Detail level. You can use a preferred drill path
to identify the drill path to use when users drill down through data in analyses. You should
use this only to specify a drill path that is outside the normal drill path defined by the
dimensional level hierarchy. It is most commonly used to drill from one dimension to
another.
a. Double-click the Customer Detail level in the H3 Customer logical dimension to open
the Logical Level dialog box.
b. Click the Preferred Drill Path tab.
c. Click Add.
d. In the Browse dialog box, double-click Product Type in the right pane to add it as the
preferred drill path in the Logical Level dialog box.
e. Click OK.
14. Set aggregation content for the logical table sources.
a. Expand D1 Time > Sources.
b. Double-click the LTS1 D1 Time logical table source to open the Logical Table Source
dialog box.
c. Click the Content tab.

d. Confirm that Aggregation content, group by is set to Logical Level and set the logical
level to Time Detail for the H1 Time logical dimension.
e. Click OK to close the Logical Table Source dialog box.

f. Repeat to verify or set content settings for the remaining logical table sources by using
the following table as a guide:

Logical Table Source Logical Dimension Logical Level
LTS1 D2 Products H2 Product Product Detail
LTS1 D3 Customers H3 Customer Customer Detail
LTS2 D3 Customer H3 Customer Customer Detail
Address
LTS1 F1 Revenue H1 Time Time Detail
H2 Product Product Detail
H3 Customer Customer Detail
g. Save the repository and check global consistency. Fix any errors or warnings before
proceeding. Notice that you did not have to make any changes to the Presentation
layer.
h. Close the repository. Leave the Administration Tool open.
a. Run the datamodel.cmd utility with the following uploadrpd parameters:
b. Confirm that you receive the following message:
c. Leave the command window open.
16. Create analyses to test the logical dimension hierarchies.
a. Return to the browser and sign in to Oracle BI as weblogic with the password
welcome1.

b. Create the following new analysis in the Sample Sales subject area to test the Product
hierarchy:
Products.Brand
Base Facts.Revenue
c. Click Results.
d. Click a brand and verify that you can drill down through the hierarchy to see revenue
data at each level.
e. Create the following new analysis to test the Time hierarchy:

Time.Per Name Year
Base Facts.Revenue
f. Click Results and verify that you can drill down through the Time hierarchy.
g. Create the following new analysis to test the Customer hierarchy:

Customers.Region
Base Facts.Revenue
h. Click Results and verify that you can drill down through the Customers hierarchy.
Notice that when you drill on Name, product type is displayed. This is because you set
a preferred drill path for the Customer Detail level.
i. Sign out of Oracle BI.

j. Leave the Oracle BI browser page open.

Practice 9-2: Creating Level-Based Measures
Overview
In this practice, you create level-based measures.
Assumptions
Now that you have created level-based logical dimension hierarchies, you create level-based
measures that can be used to calculate total revenue at various levels in a hierarchy.
Time
30 minutes

Tasks
1. Create level-based measures for the H2 Product logical dimension.
with the repository password welcome1.
b. In the Business Model and Mapping layer, right-click the F1 Revenue table and select
New Object > Logical Column.
c. Name the logical column Product Total Revenue.
d. Click the Column Source tab.
e. Select Derived from existing columns using an expression.
f. Open the Expression Builder.

g. In the Expression Builder, add Logical Tables > F1 Revenue > Revenue to the
expression. Recall that the Revenue column already has a default aggregation rule of
Sum.

h. Click OK to close the Expression Builder.
i. Click the Levels tab.
j. For the H2 Product logical dimension, select Product Total from the Logical Level
drop-down list to specify that this new measure, Product Total Revenue, should be
calculated at the Grand Total level in the product hierarchy.

k. Click OK to close the Logical Column dialog box. Notice that the Product Total
Revenue measure appears in the Product Total level of the H2 Product logical
dimension and the F1 Revenue logical fact table.

l. Repeat the steps to create a second level-based measure:
Name Logical Dimension Logical Level
Product Type Revenue H2 Product Product Type

m. Check your work:

n. Expose the new columns to users by dragging Product Total Revenue and Product
Type Revenue from the F1 Revenue logical table to the Calculated Facts
presentation table in the Sample Sales subject area in the Presentation layer.
p. Check consistency. Fix any errors or warnings before proceeding.
q. Leave the repository open. You check your work in the Analysis Editor later in Practice
9-5.

Practice 9-3: Creating Share Measures
Overview
In this practice, you create a share measure by using level-based measures.
Assumptions
Now that you have created level-based measures, you use them to create a share measure for
products.
Time
10 minutes

Tasks
1. Create a new share measure that is derived from existing logical columns.
a. In the Business Model and Mapping layer, right-click F1 Revenue and select New
Object > Logical Column to open the Logical Column dialog box.
b. On the General tab, name the logical column Product Share.
expression.
e. Select Functions > Mathematic Functions and double-click Round to add the
expression.
f. Click <<Source Number>> in the expression.
g. Enter 100* followed by a space.
h. Insert Logical Tables > F1 Revenue > Revenue.
i. Using the toolbar, click the Division button . Another set of angle brackets appears:
<<expression>>.
j. Click <<expression>>.
k. Insert Logical Tables > F1 Revenue > Product Total Revenue. Recall that this is the
level-based measure at the total level for the H2 Product logical dimension hierarchy.
l. Click the last set of angle brackets, <<Digits>>, and enter 1. This represents the
number of digits of precision with which to round the integer.
m. Check your work:
Round(100* "Sample Apps"."F1 Revenue"."Revenue" /
"Sample Apps"."F1 Revenue"."Product Total Revenue", 1)
This share measure allows you to run an analysis to show how the sales of a specific
product compare to the overall sales for all products.

n. Click OK to close the Expression Builder. The formula is visible in the Logical Column
dialog box.

o. Click OK to close the Logical Column properties dialog box. The Product Share logical
column is added to the F1 Revenue logical table in the business model.
p. Add the Product Share measure to the Calculated Facts presentation table.
q. Save the repository.
r. Check consistency. If there are errors or warnings, correct them before you proceed.
s. Leave the repository open. You check your work in the Analysis Editor in Practice 9-5.

Practice 9-4: Creating Dimension-Specific Aggregation Rules
Overview
In this practice, you create a measure with dimension-specific aggregation rules.
Assumptions
You create a measure called Average Daily Revenue, which sums dollar amounts over the
customer and product dimensions, and divides by the number of days in the time dimension.
This measure can be used to compare the average daily dollar amount from month to month
when the number of order days in each month varies.
Time

15 minutes
Tasks
2. Create a new measure with dimension-specific aggregation rules.
a. In the Business Model and Mapping layer, right-click F1 Revenue and select New
Object > Logical Column.
b. On the General tab, name the logical column Average Daily Revenue.
c. Click the Column Source tab.
d. In the Column Source Type section, select Show all logical sources.
e. Double-click the LTS1 F1 Revenue logical table source.
f. Click the Column Mapping tab.
g. Ensure that Show unmapped columns is selected.
h. Use the Expression column to map Average Daily Revenue to the REVENUE column
in the F1 Revenue physical table.
i. Click OK to close the Logical Table Source dialog box.

j. In the Logical Column dialog box, click the Aggregation tab.
k. Select Based on dimensions to open the Browse dialog box.
l. In the Browse dialog box, select the H1 Time dimension and click OK.

m. In the Formula field, select the AVG aggregation rule from the drop-down list.
n. Click the Add button.

o. Select Other and click OK.
p. Select the SUM aggregation rule for Other.
q. With Other selected in the Logical Dimension column, use the Up button to change the
aggregation rule order.

r. Click OK to close the Logical Column dialog box.
s. Drag the Average Daily Revenue measure to the Calculated Facts presentation
table.
t. Save the repository.
u. Check global consistency. Fix errors and warnings before you proceed.
v. Leave the repository open. You check your work in the Analysis Editor in Practice 9-5.

Practice 9-5: Creating Presentation Hierarchies
Overview
In this practice, you create presentation hierarchies that expose logical dimension hierarchies in
Oracle BI analyses.
Assumptions
Presentation hierarchies and presentation levels provide an explicit way to expose the
multidimensional model in Oracle BI analyses and dashboards. When presentation hierarchies
and levels are defined in the Presentation layer, roll-up information is displayed in the Analysis
Editor’s navigation pane, providing users with important contextual information. Most
importantly, users can create hierarchy-based queries by using these objects.

Outcome
Presentation hierarchies are added to the Customers, Time, and Products presentation tables.
Time
15 minutes
Tasks
1. Modify the customer logical dimension to include multiple hierarchies.
a. Expand the H3 Customer logical dimension.
b. Right-click the Customer Total level and select New Object > Shared Level as Child.
c. In the Browse dialog box, de-select Show Qualified Names, select Customer City,
and click OK. This creates a second hierarchy named Customer City in the H3
Customer logical dimension:

2. Create presentation hierarchies.
a. Drag the H3 Customer logical dimension from the Business Model and Mapping layer
to the Customers presentation table. Notice that two separate presentation hierarchies
are created, one for each logical dimension hierarchy. For logical dimensions that
contain multiple logical hierarchies, multiple separate presentation hierarchies are
created:

b. Expand the presentation hierarchies and notice that each contains the drill path defined
in the logical dimension.

c. Drag Area from the D3 Customers logical table to the Customers presentation table.
d. Double-click the Customer Area level in the H3 – Customer Region presentation
hierarchy to open the Presentation Level dialog box.
e. Click the Display Columns tab.
f. Click Add and select the Area presentation column. This is to ensure that the
Customer Area level displays correctly in the hierarchy.
g. Click OK to close the Presentation Level dialog box.
h. Drag the H2 Product logical dimension to the Products presentation table.

i. Drag the H1 Time logical dimension to the Time presentation table. Notice that only
one presentation hierarchy is created for the H2 Product and H1 Time logical
dimensions. For logical dimensions that contain one logical hierarchy, one presentation
hierarchy is created.

j. Save the repository.
k. Check consistency. Fix any errors or warnings before proceeding.
l. Close the repository.
m. Leave the Administration Tool open.
3. Create an analysis to test the level-based measures.
a. Use the uploadrpd command to upload the BISAMPLE repository to BI Server.
b. Return to the browser, sign in to Oracle BI as weblogic with the password
welcome1, and create a new analysis for the Sample Sales subject area.
c. Create the following analysis:
Products.Prod Dsc
Base Facts.Revenue
Calculated Facts.Product Type Revenue
d. Set the Data Format column properties to Currency for the Product Type Revenue
column and save it as the system-wide default.

e. Click Results. Notice that Product Type Revenue returns revenue grouped by
product type even though the query is at a different level than product type [product
description (Prod Dsc) in this example].

4. Create an analysis to test the share measure.
a. Create the following new analysis:
Products.Prod Dsc
Base Facts.Revenue
Calculated Facts.Product Share
b. Set the Data Format column properties to Percentage for the Product Share column
and save it as the system-wide default.
c. Sort Product Share in descending order.

d. Click Results.

The results show total revenue for each product and the percent of total sales for each
product sorted in descending order.
e. Create a similar analysis to view results for Product Type:
Products.Type
Base Facts.Revenue
Calculated Facts.Product Share

f. Click Results.

The results show total revenue for each product type and the percent of total sales for
each product type sorted in descending order. The same share measure (Product
Share in this example) can be used for different hierarchy levels.
5. Create an analysis to test the Average Daily Revenue measure with the dimension-specific
aggregation rule.
a. Create the following analysis and filter:
Customers.Region
Base Facts.Revenue
Calculated Facts.Average Daily Revenue
Per Name Month is equal to / is in 2009 / 01
b. Set the Data Format column properties to Currency for the Average Daily Revenue
column.
c. Click Results.
d. Click the Edit View button for the Table view.

e. In the Layout area, click the Total button for Columns and Measures and select After.
f. Click Done to return to results:

g. Considering that there are approximately 26 order days in the first month of 2009, you
can use a calculator to check that the total results of the analysis are correct for
average daily revenue.
6. Create analyses to test presentation hierarchies.
a. Create the following analysis by using the H3 Customer – Customer Region
presentation hierarchy:
Customers.H3 Customer – Customer Region
Base Facts.Revenue
b. Click Results.

c. Expand the hierarchy levels to view data at different levels.

d. Build another analysis by using the H3 Customer – Customer City presentation
hierarchy and Base Facts.Revenue, and view the results. Notice that the drill path is
different than the drill path for the Customer Region hierarchy.
e. Sign out of the Analysis Editor.

Working with Logical
Dimension Hierarchies
Practices Overview
In these practices, you build logical dimensions with parent-child hierarchies, and logical
dimensions with ragged and skipped-level hierarchies.
148 Practices for Lesson 10: Working with Logical Dimension Hierarchies
Practice 10-1: Creating Parent-Child Hierarchies
Overview
In this practice, you create a parent-child hierarchy.
Assumptions
A parent-child hierarchy is a hierarchy of members that have the same type. This contrasts with
level-based hierarchies, where members of the same type occur only at a single level of the
hierarchy. The most common real-life occurrence of a parent-child hierarchy is an organizational
reporting hierarchy chart, where the following apply:
• Each individual in the organization is an employee.
• Each employee, apart from the top-level managers, reports to a single manager.

• The reporting hierarchy has many levels.
In relational tables, the relationships between the different members in a parent-child hierarchy
are implicitly defined by the identifier key values in the associated base table. However, for each
Oracle BI Server parent-child hierarchy that is defined on a relational table, you must also
explicitly define the intermember relationships in a separate parent-child relationship table.
Outcome
A parent-child hierarchy is added to the business model.
Time
40 minutes
Tasks
1. Import employee tables into the repository.
b. In the Physical layer, expand ORCL.
d. Accept the defaults in the Select Metadata Types window and click Next.
e. In the Select Metadata Objects window, expand the BISAMPLE schema in the Data
source view pane.
f. Select the following tables and add them to the Repository view pane:
SAMP_EMPL_D_VH
SAMP_EMPL_PARENT_CHILD_MAP
SAMP_EMPL_POSTN_D
Practices for Lesson 10: Working with Logical Dimension Hierarchies 149
g. When the import completes, deselect Show complete structure and expand
BISAMPLE in the Repository View pane to verify that the tables are added.
h. Click Finish to close the Import Wizard and add the tables to the repository.
i. Expand BISAMPLE in the Physical layer and verify that the tables are imported.
j. Update row counts to confirm connectivity.
2. Explore the new tables.

a. Right-click SAMP_EMPL_PARENT_CHILD_MAP and select View Data. This is an
example of a parent-child relationship table with rows that define the intermember
relationships of an employee hierarchy. It includes a MEMBER_KEY column, which
identifies the member (employee); an ANCESTOR_KEY column, which identifies the
ancestor (manager) of the member; a DISTANCE column, which specifies the number
of parent-child hierarchy levels from the member to the ancestor; and an IS_LEAF
column, which indicates if the member is a leaf member.
b. Close the View Data dialog box.

c. Expand the SAMP_EMPL_D_VH table. Each row in the table contains two identifying
keys, one to identify the member itself (EMPLOYEE_KEY) and the other to identify the
“parent” of the member (MGR_ID). It also contains a position key (POSTN_KEY) to
identify the employee position. To see the data for this table, right-click the table and
select View Data.
d. Expand the SAMP_EMPL_POSTN_D table. This table contains employee position
information. To see the data for this table, right-click the table and select View Data.
3. Create aliases for the tables:
Table Alias
SAMP_EMPL_D_VH D50 Sales Rep
SAMP_EMPL_PARENT_CHILD_MAP D51 Sales Rep Parent Child
SAMP_EMPL_POSTN_D D52 Sales Rep Position
4. Use the Physical Diagram to create the following physical joins for the alias tables:
"orcl".""."BISAMPLE"."D52 Sales Rep Position"."POSTN_KEY" =

"orcl".""."BISAMPLE"."D50 Sales Rep"."POSTN_KEY"
"orcl".""."BISAMPLE"."D50 Sales Rep"."EMPLOYEE_KEY" =

"orcl".""."BISAMPLE"."D51 Sales Rep Parent Child"."ANCESTOR_KEY"
"orcl".""."BISAMPLE"."D51 Sales Rep Parent Child"."MEMBER_KEY" =

"orcl".""."BISAMPLE"."F1 Revenue"."EMPL_KEY"

5. Add logical tables and columns for the Sales Rep dimension to the Sample Apps business
model.
a. Right-click the Sample Apps business model and select New Object > Logical Table.
b. Name the logical table D5 Sales Rep and click OK to add the table to the business
model. Notice that the D5 Sales Rep icon has a # sign. This is because you have not
yet defined the logical join relationship. When you define the logical join later in this
practice, the icon will change accordingly.
c. Drag all six columns from D50 Sales Rep in the Physical layer to D5 Sales Rep in the
BMM layer. This action creates logical columns, and adds a D50 Sales Rep logical
table source to D5 Sales Rep.
d. Rename the D50 Sales Rep logical table source to LTS1 D5 Sales Rep.
e. In the Physical layer, expand D52 Sales Rep Position.
f. Drag POSTN_DESC and POSTN_LEVEL from D52 Sales Rep Position to LTS1 D5
Sales Rep. Note that you are dragging the columns to the logical table source, not the
logical table. Dragging to the logical table would create a second logical table source.
This action adds two new logical columns to D5 Sales Rep.
g. Drag DISTANCE from D51 Sales Rep Parent Child to LTS1 D5 Sales Rep. Again,
drag the column to the logical table source, not the logical table.
h. Double-click the LTS1 D5 Sales Rep logical table source to open the Logical Table
Source properties dialog box.
i. Click the General tab and notice that the LTS1 D5 Sales Rep logical table source now
maps to the three physical alias tables.
j. Click the Column Mapping tab to view how the columns are mapped.

k. Click OK to close the Logical Table Source dialog box.
l. Rename the logical columns:
Logical column Rename to:
POSTN_KEY Position Key
TYPE Sales Rep Type
EMPL_NAME Sales Rep Name
EMPLOYEE_KEY Sales Rep Number
HIRE_DT Hire Date
MGR_ID Manager Number
POSTN_DESC Position
POSTN_LEVEL Position Level
DISTANCE Closure Distance
6. Create a logical join for the D5 Sales Rep table.
a. In the Sample Apps business model, select D5 Sales Rep and F1 Revenue.
b. Right-click either of the highlighted tables and select Business Model Diagram >
Selected Tables Only to open the Business Model Diagram.
c. Create a logical join between D5 Sales Rep and F1 Revenue with F1 Revenue at the
“many” end of the join.
d. Close the Business Model Diagram. Notice that creating the logical join changed the
icon for the D5 Sales Rep logical table.
7. Create a logical dimension with a parent-child hierarchy based on the D5 Sales Rep logical
table.

a. Right-click the D5 Sales Rep logical table and select Create Logical Dimension >
Dimension with Parent-Child Hierarchy to open the Logical Dimension dialog box.
b. In the Logical Dimension dialog box, on the General tab, name the logical dimension
H5 Sales Rep.
c. Click Browse next to Member Key. The Browse window shows the logical dimension
table in the business model with its corresponding keys.
d. Click View to open the Logical Key dialog box. Confirm that the Sales Rep Number
column is selected for D50 Sales Rep_Key.
e. Click Cancel to close the Logical Key dialog box.

f. Click OK to close the Browse window.
g. Click Browse next to Parent Column. The Browse window shows the columns, other
than the primary key, in the logical table that you selected in the previous step.
h. Deselect Show Qualified Names and select Manager Number as the parent column
for the parent-child hierarchy.
i. Click OK to close the Browse window, but do not close the Logical Dimension dialog
box.
8. Define the parent-child settings. For each parent-child hierarchy that is defined on a

relational table, you must explicitly define the intermember relationships in a separate
parent-child relationship table. In the process of creating the parent-child relationship table,
you may choose one of the following options: 1. Select a previously created parent-child
relationship table. 2. Use a wizard that generates scripts to create and populate the
parent-child relationship table. In the next set of steps, you select a previously created and
populated parent-child relationship table.
a. Click Parent-Child Settings to display the Parent-Child Relationship Table Settings
dialog box. Note that at this point, the Parent-Child Relationship Table is not defined.
For your information only: To start the wizard, you would click the Create Parent-Child
Relationship Table button. The wizard would create the appropriate repository
metadata objects and generate SQL scripts for creating and populating the parent-child
relationship table. At the end of the wizard, Oracle BI Server stores the scripts in
directories that were chosen during the wizard session. The scripts can then be run
against the database to create and populate the parent-child relationship table. Do not
start the wizard. Running the wizard is not necessary in this practice because the
parent-child relationship table is already created and populated.
b. Click the Select Parent-Child Relationship Table button to open the Select
Parent-Child Relationship Table dialog box.
c. Select the D51 Sales Rep Parent Child alias that you created.
d. The D51 Sales Rep Parent Child alias is now displayed in the Parent-Child
Relationship Table field in the Parent-Child Relationship Table Settings dialog box.
e. In the Parent-Child Table Relationship Column Details section, set the appropriate
columns. Member Key identifies the member. Parent Key identifies an ancestor of the

member. The ancestor may be the parent of the member or a higher-level ancestor.
Relationship Distance specifies the number of parent-child hierarchical levels from the
member to the ancestor. Leaf Node Identifier indicates if the member is a leaf member
(1=Yes, 0=No).
Member Key MEMBER_KEY

Parent Key ANCESTOR_KEY
Relationship Distance DISTANCE
Leaf Node Identifier IS_LEAF
f.
g. Check your work:

h. Click OK to close the Parent-Child Relationship Table Settings dialog box.
i. Click OK to close the Logical Dimension dialog box.
j. Right-click H5 Sales Rep and select Expand All. Note that a parent-child logical
dimension has only two levels: Total and Detail.
k. Delete all columns from the Detail level, except Sales Rep Name and Sales Rep
Number.
l. Double-click the Detail level to open the Logical Level dialog box.
m. On the Keys tab, create a new key named Display Key that maps to the Sales Rep
Name column.
n. Deselect Use for Display for the Sales Rep Number column and select Use for
Display for the Sales Rep Name column.
o. Make sure that Member Key is still set to D50 Sales Rep_Key.
p. Click OK to close the Logical Level dialog box.
q. Expand F1 Revenue > Sources and double-click LTS1 F1 Revenue to open the

r. On the Content tab, set the logical level to Detail for the H5 Sales Rep logical
dimension.
s. Click OK to close the Logical Table Source dialog box.
9. Make the parent-child logical dimension available for queries.
a. Drag the D5 Sales Rep logical table from the BMM layer to the Sample Sales subject
area in the Presentation layer.
b. Rename the D5 Sales Rep presentation table to Sales Reps.
c. Move the Sales Reps presentation table above the Base Facts table.
d. Expand the Sales Reps presentation table and notice that the H5 Sales Rep parent-
child logical dimension is automatically included as a presentation hierarchy.
e. Double-click the H5 Sales Rep presentation hierarchy to open the Presentation

Hierarchy dialog box.
f. On the Display Columns tab, confirm that Sales Rep Name is set as the display
column.
g. Click OK to close the Presentation Hierarchy dialog box.
h. Save the repository.
i. Check consistency. Fix any errors or warnings before proceeding.
j. Close the repository.
k. Leave the Administration Tool open.
b. Return to the browser, sign in to Oracle BI as weblogic with the password
welcome1.
c. Select New > Analysis to open the Select Subject Area window.
d. Select the Sample Sales subject area.

e. Select Show More Buttons > Refresh > Reload Server Metadata.
f. Create the following analysis to test the parent-child hierarchy:
Sales Reps.H5 Sales Rep
Sales Reps.Position
Base Facts.Revenue
g. Click Results. Expand the pivot table to view data at different levels of the hierarchy.
Notice that the Revenue measure rolls up through each level.
h. Sign out of Oracle BI.
Practice 10-2: Creating Logical Dimensions with Ragged and Skipped-
Level Hierarchies
Overview
In this practice, you create logical dimensions with ragged and skipped-level hierarchies.
Assumptions
An unbalanced (or ragged) hierarchy is a hierarchy where the leaves (members with no
children) do not necessarily have the same depth. A skipped-level hierarchy is a hierarchy
where there are members that do not have a value for a particular ancestor level.
Time

15 minutes
Tasks
1. Import metadata and define the Physical Layer objects.
c. Right-click Sample Apps Connection Pool and select Import Metadata to open the
Import Wizard.
d. On the Select Metadata Types screen, accept the defaults and click Next.
e. On the Select Metadata Objects screen, in the Data source view, expand BISAMPLE.
f. In the Data source view, select the SAMP_PRODUCTS_DR table for import.
g. Click the Import Selected button to move the table to the Repository View.
h. Expand BISAMPLE in the Repository View and confirm that the
SAMP_PRODUCTS_DR table is visible.
i. Click Finish to close the Import Wizard.
j. Confirm that the SAMP_PRODUCTS_DR table is visible in the Physical layer of the
repository.
k. Create a D20 Product alias for the SAMP_PRODUCTS_DR table.
l. Use the Physical Diagram to create the following physical join for the alias table:
"orcl".""."BISAMPLE"."D20 Product"."PROD_KEY" =
"orcl".""."BISAMPLE"."F1 Revenue"."PROD_KEY"
m. Close the Physical Diagram.
n. Right-click D20 Product and select View Data. Notice that there are skipped levels in
the hierarchy. For example, A - Brand2 has a NULL value for LOB for the product D -
Product 8.
o. Close View Data.
2. Create the logical table and logical columns.
a. Drag D20 Product from the Physical layer to the Sample Apps business model in the

BMM layer to create a D20 Product logical table. The logical key and the logical join to
F1 Revenue are created automatically based on the join in the Physical layer.
b. Rename the D20 Product logical columns:
Old Name New Name
BRAND Brand
LOB LOB
PROD_DSC Product
PROD_KEY Product Number
Type Product Type
c. Rename the D20 Product logical table source to LTS1 Product (Ragged).
3. Create a logical dimension hierarchy with ragged and skipped level structures.
a. Right-click the D20 Product logical table and select Create Logical Dimension >
Dimension with Level-Based Hierarchy to automatically create a logical dimension
named D20 ProductDim.
b. Rename D20 ProductDim to H20 Product.
c. Double-click the H20 Product logical dimension to open the Logical Dimension dialog
box.
d. On the General tab, select both Ragged and Skipped Levels.

e. Click OK to close the Logical Dimension dialog box.
f. Expand H20 Product. By default, the hierarchy has a D20 Product Total level and a
D20 Product Detail level with associated columns.
g. Modify H20 Product to create the following hierarchy. Hint: Create the hierarchy from
the bottom to the top, starting with the detail level.
Level Column Key Use for Display

Product Total <none> <none> <none>
Product Brand Brand Brand Yes
Product LOB LOB LOB Yes
Product Type Product Type Product Type Yes
Product Product Product Yes
Product Detail Product Number Product Number Yes
4. Define the logical levels.
a. Expand D20 Product > Sources and double-click LTS1 Product (Ragged) to open
the Logical Table Source dialog box.
b. On the Content tab, set the logical level to Product Detail and click OK.
c. Expand F1 Revenue > Sources and double-click LTS1 F1 Revenue to open the
d. On the Content tab, set the logical level for H20 Product to Product Detail and click
OK.
5. Create the Presentation layer objects.
a. Drag the D20 Product logical table to the Sample Sales subject area in the
Presentation layer.
b. In the Presentation layer, rename D20 Product to Products (Ragged) and move

Products (Ragged) to appear after Products.
c. Expand Products (Ragged) and notice that the H20 Product logical dimension is
automatically added to the Presentation layer.
d. Save the repository and check consistency. Fix and errors or warnings before
proceeding.
e. Close the repository.
f. Leave the Administration Tool open.
b. Return to the browser and sign in to Oracle BI as weblogic with the password
welcome1.
c. Select New > Analysis to open the Select Subject Area window.
e. Select Show More Buttons > Refresh > Reload Server Metadata.
f. Create the following analysis to test the ragged or skipped level hierarchies:
Products (Ragged).Brand
Products (Ragged).LOB
Products (Ragged).Product Type
Products (Ragged).Product
Base Facts.Revenue
g. Click Results. The results display correctly even though there are skipped levels
(levels with NULL values) and ragged levels (leaves with varying depth).

h. Sign out of Oracle BI.
Managing Usage Tracking
Practices Overview
In these practices, you will set up and administer usage tracking.
166 Practices for Lesson 11: Managing Usage Tracking

Practice 11-1: Setting Up Usage Tracking
Overview
In this practice, you set up and administer usage tracking.
Assumptions
Oracle BI Server supports the accumulation of usage tracking statistics that can be used in a
variety of ways, such as for database optimization, aggregation strategies, or billing users or
departments based on the resources they consume. Oracle BI Server tracks usage at the
detailed query level. You can monitor the queries generated to help identify performance
improvement areas. You use the recommended usage tracking approach, which is to track
statistics by loading them directly into a database table rather than a log file. You use the usage

tracking database table, S_NQ_ACCT, which was created by the RCU utility during the
installation of Oracle BI.
Time
30 minutes
Tasks
1. Create a usage tracking database object.
a. Open the BISAMPLE repository in offline mode with the password welcome1.
b. Right-click inside the Physical layer white space and select New Database to open the
Database properties dialog box.
c. Click the General tab and name the database Usage Tracking Database.
d. In the Database Type drop-down list, select Oracle 12c.
e. Click the Connection Pools tab.
f. Click Add to open the Connection Pool dialog box.
g. Name the connection pool Usage Tracking Connection Pool.
h. Set call interface to Default (OCI 10g/11g).
i. Enter ORCL for the data source name.
j. Enter BISAMPLE for username and password.
k. Click OK.
l. Confirm the password, and click OK.
m. Click OK to close the Database properties dialog box.
n. Right-click Usage Tracking Connection Pool and select Import Metadata.
o. Accept the default metadata types and click Next.
p. Expand BISAMPLE and import S_NQ_ACCT into the Usage Tracking Database
object. This creates a new BISAMPLE schema with the S_NQ_ACCT table in the
Usage Tracking Database object in the Physical layer.
q. In the Physical layer, rename the BISAMPLE schema to Usage Tracking Schema.
Practices for Lesson 11: Managing Usage Tracking 167

r. Check your work.

2. Create a usage tracking business model.
a. Right-click in the Business Model and Mapping layer white space and select New
Business Model.
b. Name the business model Usage Tracking and click OK.
c. Right-click the Usage Tracking business model and select New Object > Logical
Table.
d. Name the table Measures and click OK.
e. Repeat and add three more tables, Time, Topic, and User, to the Usage Tracking
business model.

f. Drag the following physical columns from Usage Tracking Schema > S_NQ_ACCT to
the Measures logical table in the Usage Tracking business model and rename them:
Physical Column Rename
QUERY_TEXT Query Count
ROW_COUNT Row Count
TOTAL_TIME_SEC Total Time Seconds
g. Apply the following aggregation rules:
Logical Column Aggregation Rule
Query Count Count
Row Count Sum

Total Time Seconds Sum
h. Drag the following physical columns from Usage Tracking Schema > S_NQ_ACCT to
the Time logical table in the Usage Tracking business model and rename them:
START_DT Start Date
START_HOUR_MIN Start Hour Minute
END_HOUR_MIN End Hour Minute
i. Set Start Date as the logical key for the Time logical table.
j. Drag the following physical columns from Usage Tracking Schema > S_NQ_ACCT to
the Topic logical table in the Usage Tracking business model and rename them:
QUERY_TEXT Logical SQL
REPOSITORY_NAME Repository
SUBJECT_AREA_NAME Subject Area
k. Set Logical SQL as the logical key for the Topic logical table.
l. Drag the USER_NAME physical column from Usage Tracking Schema >
S_NQ_ACCT to the User logical table in the Usage Tracking business model and
rename to User Name.
m. Set User Name as the logical key for the User logical table.

n. Use the Business Model Diagram to create logical joins from Measures to Time,
Topic, and User.

o. Drag the Usage Tracking business model to the Presentation layer to create the
Presentation layer objects.
p. Save the repository.
q. Check consistency. You should get the message “Business model ‘Usage Tracking’ is
consistent. Do you want to mark it as available for queries?”
r. Click Yes.
s. Click OK when you get the consistency check message.
t. Close the repository.
v. Use the uploadrpd command to upload the BISAMPLE repository to BI Server.
3. Set the direct insertion parameters for usage tracking in the NQSConfig.ini configuration
file.
a. Open a command window and change the directory to:

b. At the command-line prompt, run stop.cmd to stop all the BI components. Allow
processing to complete. You should see the message Finished stopping managed
servers and system components.

c. Leave the command window open.
d. In Windows Explorer, navigate to
D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\config\fmwconfig\
biconfig\OBIS.
e. Make a backup copy of NQSConfig.ini before editing.
f. Open NQSConfig.ini for editing.
g. Navigate to the [USAGE_TRACKING] section.
h. Set ENABLE to YES.
i. Confirm that DIRECT_INSERT is set to YES.
j. Set PHYSICAL_TABLE_NAME to the name of the fully-qualified database table for
collecting query statistic information, as it appears in the Physical layer of the Oracle BI
repository. In this example, the name of the fully-qualified database table is:
“Usage Tracking Database”.”Usage Tracking Schema”.”S_NQ_ACCT”;

k. Set CONNECTION_POOL to the name of the fully-qualified connection pool for the
query statistics database, as it appears in the Physical layer of the Oracle BI
repository. In this example, the name of the fully-qualified connection pool is:
“Usage Tracking Database”.”Usage Tracking Connection Pool”;

l. Save and close the NQSConfig.ini file.
m. Return to the command window where you ran stop.cmd earlier with the directory set
to:

n. At the command-line prompt, run start.cmd to start all the BI components. Allow
processing to complete. It will take a few minutes. Verify that you receive the message
Finished starting servers and the status for all components is RUNNING.

o. Leave the command window open.
4. Create and run analyses to load the S_NQ_ACCT table.
a. Sign in to Oracle BI as weblogic with the password welcome1.
b. Create and run the following analysis in the Sample Sales subject area:
Customers.Name
Base Facts.Revenue
c. Create and run another analysis in the Sample Sales subject area:
Time.Calendar Date
Base Facts.Revenue
Base Facts.Units
5. Create and run analyses to check usage tracking.
a. Create a new analysis in the Usage Tracking subject area. Be sure to select the
Usage Tracking subject area.
User.User Name
Topic.Subject Area
Topic.Logical SQL
Measures.Row Count

b. Click Results. Your results should look similar to the following screenshot:
c. Check the query log and verify that the Usage Tracking Database, Usage Tracking
Connection Pool, S_NQ_ACCT table, and the expected columns are accessed in the
query.

d. Sign out of Oracle BI.
6. Disable usage tracking. Usage tracking is resource intensive. Enabling it can impact BI
Server performance. Usage tracking is not used in the remainder of this course, so in this
set of steps, you disable it.
a. Return to the command window where the directory is set to:
b. Run stop.cmd to stop all the Oracle BI components.
c. Navigate to
biconfig\OBIS.
d. Open NQSConfig.ini for editing.
e. Navigate to the [USAGE_TRACKING] section.
f. Set ENABLE to NO.
g. Save and close NQSConfig.ini.
h. Return to the command window where the directory is set to:
i. Run start.cmd to start all the Oracle BI components.
j. Allow processing to complete and verify that status for all components is RUNNING.

Using Model Checker and
Aggregates
Practices Overview
In these practices, you will set up and use aggregate tables to improve query performance.
176 Practices for Lesson 12: Using Model Checker and Aggregates
Practice 12-1: Using Aggregate Tables
Overview
In this practice, you set up and use aggregate tables to improve query performance.
Assumptions
Aggregate tables store pre-computed results, which are measures that have been aggregated
(typically summed) over a set of dimensional attributes. Using aggregate tables is a popular
technique for speeding up query response times in decision support systems. This eliminates
the need for runtime calculations, and delivers faster results to users. The calculations are done
ahead of time and the results are stored in the tables. Aggregate tables typically have much
fewer rows than the non-aggregate tables and, therefore, processing is faster.

Time
45 minutes
Tasks
1. Import tables with aggregated time and revenue data into the Physical layer of the
repository. You need both aggregate fact and aggregate dimension tables because you
must create logical dimension sources at the same level of detail as the fact sources.
b. Given that you will not be using usage tracking for the remainder of the course, delete
the Usage Tracking subject area in the Presentation layer, the Usage Tracking
business model in the Business Model and Mapping layer, and the Usage Tracking
Database in the Physical layer.
c. In the Physical layer, expand ORCL.
d. Right-click Sample Apps Connection Pool and select Import Metadata to open the
Import Wizard.
e. On the Select Metadata Types screen, select Tables, Keys, Foreign Keys, and
Views, and then click Next.
f. On the Select Metadata Objects screen, in the data source view, expand BISAMPLE.
g. In the data source view, select the following for import:
SAMP_REVENUE_FA2
SAMP_TIME_QTR_D
h. Click the Import Selected button to move the objects to the Repository View.
i. Deselect Show complete structure, expand BISAMPLE in the Repository View, and
confirm that the objects are visible.
j. Click Finish to close the Import Wizard.
k. Confirm that the objects are visible in the Physical layer of the repository.
Practices for Lesson 12: Using Model Checker and Aggregates 177
l. Create the following aliases:
Table Alias
SAMP_REVENUE_FA2 F2 Revenue Aggregate
SAMP_TIME_QTR_D D1 Time Quarter Grain
m. Right-click F2 Revenue Aggregate and select View Data. F2 Revenue Aggregate
stores aggregated fact information for revenue and units at the quarter and product
grain.

n. Close View Data.
o. Right-click D1 Time Quarter Grain and select View Data. D1 Time Quarter Grain
stores time data at the quarter grain. It stores one record for each quarter, beginning
with 2004 Q4 and ending with 2011 Q4.
p. Close View Data.
q. Use the Physical Diagram to create the following physical joins:
"orcl".""."BISAMPLE"."D2 Products"."PROD_KEY" =
"orcl".""."BISAMPLE"."F2 Revenue Aggregate"."PROD_KEY"
"orcl".""."BISAMPLE"."D1 Time Quarter Grain"."QTR_KEY" =

"orcl".""."BISAMPLE"."F2 Revenue Aggregate"."BILL_QTR_KEY"
2. Create new logical table sources.
a. In the Physical layer, expand D1 Time Quarter Grain.
b. In the BMM layer, expand Sample Apps > D1 Time.
c. Drag the following columns from D1 Time Quarter Grain to their corresponding
columns in D1 Time:

D1 Time Quarter Grain D1 Time
CAL_HALF Cal Half
CAL_QTR Cal Qtr
CAL_YEAR Cal Year
DAYS_IN_QTR Days in Qtr
JULIAN_QTR_NUM Julian Qtr Num
PER_NAME_HALF Per Name Half
PER_NAME_QTR Per Name Qtr
PER_NAME_YEAR Per Name Year
d. Notice that this action creates a new logical table source named D1 Time Quarter
Grain for D1 Time.
e. Rename the D1 Time Quarter Grain logical table source to LTS2 D1 Time Quarter
Grain.
f. Double-click LTS2 D1 Time Quarter Grain to open the Logical Table Source dialog
box.
g. On the Column Mapping tab, make sure that “Show mapped columns” is selected and
“Show unmapped columns” is deselected. Note the column mappings. The logical
columns now map to columns in two physical tables: D1 Time and D1 Time Quarter
Grain.

i. In the Physical layer, expand F2 Revenue Aggregate.
j. In the BMM layer, expand F1 Revenue.
k. Drag the following physical columns from F2 Revenue Aggregate to their
corresponding logical columns in F1 Revenue:
F2 Revenue Aggregate F1 Revenue
UNITS Units
REVENUE Revenue
l. Notice that this action creates a new logical table source named F2 Revenue
Aggregate for F1 Revenue.
m. Rename the F2 Revenue Aggregate logical table source to LTS2 F2 Revenue
Aggregate.
n. Double-click LTS2 F2 Revenue Aggregate to open the Logical Table Source dialog
box.
o. On the Column Mappings tab, make sure that the check box to show mapped columns
is selected and notice the column mappings. The Revenue and Units logical columns
now map to columns in two physical tables: F1 Revenue and F2 Revenue Aggregate.
p. Leave the Logical Table Source - LTS2 F2 Revenue Aggregate dialog box open.
3. Set aggregate content.
a. Click the Content tab.
b. Set the following logical levels for the logical dimensions:
Logical Dimension Logical Level
H1 Time Quarter
H2 Product Product Total
H20 Product Product Total
H3 Customer Customer Total
H5 Sales Rep Total
c. Check your work.
Explanation: You are setting aggregation content for the fact table to the
corresponding levels in the dimension hierarchies. In a subsequent step, you set
similar levels for the aggregate logical table source for the Time dimension. Note that
all levels are set to the total level except the H1 Time logical dimension, which is set to
Quarter. The result is, when a user queries against a particular level, Oracle BI Server
accesses the aggregate tables instead of the detail tables.
For example, if a user queries for total sales by product by quarter, the server
accesses the F2 Revenue Aggregate fact table and the corresponding aggregate
dimension table, D1 Time Quarter Grain. If a user queries for a level lower than the
level specified here (such as, Month instead of Quarter), the server accesses the detail
tables (F1 Revenue and D1 Time). If a user queries for a higher level (such as, Year
instead of Quarter), the aggregate tables are used because whenever a query is run
against a logical level or above, the aggregate tables are used.
d. Click OK to close the Logical Table Source dialog box.
e. Double-click the LTS2 D1 Time Quarter Grain logical table source to open the Logical
Table Source dialog box.

f. On the Content tab, set the logical level to Quarter.
g. Click OK to close the Logical Table Source dialog box.
h. Save the repository and check global consistency. Fix any errors or warnings before
proceeding.
i. Close the repository. Leave the Administration Tool open. Note that you did not need to
change the Presentation layer. You made changes in the business model that impact
how queries are processed and which sources are accessed. However, the user
interface remains the same, so there is no need to change the Presentation layer.
Oracle BI Server will automatically use the appropriate sources based on the user
query.
4. Test your work.
a. Use the uploadrpd command to upload the BISAMPLE repository.
b. Return to Oracle BI and sign in by using weblogic as the username and welcome1
as the password.
c. Create the following analysis in the Sample Sales subject area to test the aggregate
tables.
Time.Per Name Qtr
Base Facts.Revenue
d. Click Results.

e. Check the query log. Notice that the query uses the expected alias tables: D1 Time
Quarter Grain and F2 Revenue Aggregate.
f. Create another new analysis in the Sample Sales subject area to test the aggregate
tables:
Time.Per Name Year
Base Facts.Revenue
g. Click Results.
h. Check the query log. Notice that the query uses the same aggregate tables: D1 Time
Quarter Grain and F2 Revenue Aggregate. This is because Per Name Year is at a
higher level than Per Name Quarter in the logical dimension hierarchy and, therefore,
the aggregate tables are still used.

i. Create one more new analysis in the Sample Sales subject area to test the aggregate
tables:
Time.Per Name Month
Base Facts.Revenue
j. Click Results.
k. Inspect the query log. Notice that this time the query uses the detail tables: D1 Time
and F1 Revenue. This is because the requested data (revenue by month) is at a lower
level than what is contained in the aggregate tables. The aggregate tables do not
contain the data and, therefore, the detail tables are used in the query. This aggregate
navigation is controlled by the aggregate content levels that you set in the logical table
sources.

l. Sign out of Oracle BI.
Practice 12-2: Using the Aggregate Persistence Wizard
Overview
In this practice, you use the Aggregate Persistence Wizard to automate the creation of
aggregate tables and their corresponding objects in the repository.
Assumptions
The traditional process for creating aggregates for Oracle BI Server queries is manual, requiring
the writing of data definition language (DDL) and data manipulation language (DML) scripts to
create tables in the databases that are involved. Additionally, as shown in the previous practice,
these aggregated tables must be mapped to the repository metadata to be available for queries.
This is a time-consuming and possibly error-prone process. The Aggregate Persistence Wizard

allows an administrator to automate the creation of aggregate tables and their corresponding
objects in the repository. In this practice, you use the Model Check Manager to check for
modeling issues, and then use the Aggregate Persistence Wizard to create two new fact
aggregate tables with corresponding dimension aggregates for time and product.
Time
30 minutes
Tasks
1. Before you use the Aggregate Persistence Wizard to create aggregate tables, use the
Model Check Manager to check for modeling issues.
a. Return to the Administration Tool and select File > Open > Online to open the
BISAMPLE repository in online mode with weblogic as the user and welcome1 as
the repository password.
b. In the Business Model and Mapping layer, right-click the Sample Apps business
model and select Check Model > Complete. The Model Check Manager opens with a
list of errors and warnings.
c. Make sure that both Errors and Warnings are checked and scroll to view the
messages. The warning messages identify logical columns that are not assigned to a
level. You can ignore the warning messages. You should not see any error messages.
If you do, ask your instructor for assistance.
d. Close the Model Check Manager.
2. In this step, you use the Aggregate Persistence Wizard to build a script that is used to
create aggregate tables and the corresponding repository metadata.
a. Select Tools > Utilities > Aggregate Persistence and click Execute.
b. On the Select File Location screen, in the File Name field, enter Create_AGG. This
specifies the file where the output script is saved. This file stores the aggregate
specifications, and is updated if more aggregates are specified.
c. Click Browse. Navigate to D:\PracticeFiles and click OK.
d. Click Next.
e. In the top pane, select the Sample Apps business model. When there are multiple
business models, only one business model can be selected.
f. In the bottom pane, expand the F1 Revenue fact table. When there are multiple fact
tables, only one fact table can be selected.
g. Select the Revenue measure.

h. Click Next.
i. Select the following levels. Leave the “Use Surrogate Key?” field check box
deselected.
H2 Product: Product Type
H1 Time: Month

j. Click Next.
k. In the top pane, select the ORCL database.
l. In the second pane, expand ORCL and select the BISAMPLE schema. Sample Apps
Connection Pool is selected by default.
m. In the Aggregate table name field, enter ag_F3_Revenue for the aggregate table
name.

n. Click Next.
o. Review the aggregate definition. The screen displays the logical SQL that generates
the aggregate tables based on the parameters defined in the previous steps.
p. Select Define another aggregate and click Next.
q. Repeat the steps to create another aggregate named ag_F4_Revenue with the
measure Revenue and the levels: H1 Time: Month and H2 Product: Product Brand.
r. Select I am done.

s. Click Next. The Finish Script dialog box appears confirming that the script has been
generated and stored in the location that was identified in an earlier step.
t. Click Finish.
u. On the title bar of the Administration Tool, notice the BISERVER data source name
(DSN) for the Oracle BI Server to which you are connected. You will need this DSN
later in this set of practices.
v. Close the repository.

w. Navigate to D:\PracticeFiles and confirm that the Create_AGG script file was
generated.
x. Open the Create_AGG file in Notepad to view its contents:
y. Close the file.

3. Use nqcmd to run the aggregate persistence script. nqcmd is a utility that you can use to
execute queries against Oracle BI Server.
a. Open a command window.
b. Change the directory to
c. At the prompt, type nqcmd.
d. The first argument that you must enter is the data source name for the Oracle BI
Server to which you want to connect. Recall that you identified BISERVER as this data
source name in the previous set of steps. After nqcmd, type –d, and then enter the
BISERVER data source name.
e. To enter the user argument, type –u weblogic.
f. To enter the path to the file, enter –s D:\PracticeFiles\Create_AGG.
g. Press Enter to execute nqcmd.

h. Enter welcome1 as the password and press Enter.
i. Wait until you receive the “Statement execute succeeded.” message.

j. Close the command window.
4. Verify that the aggregates are created in the Physical layer of the repository.
a. Return to the Administration Tool and select File > Open > Online to open the
BISAMPLE repository in online mode. Use welcome1 as the repository password and
the user password.
b. In the Physical layer, ensure that the aggregates were created in the BISAMPLE
schema. There should be two new fact aggregates, ag_F3_Revenue and
ag_F4_Revenue, and three new dimension aggregates beginning with SA_ in the
Physical layer. Your results should resemble the following screenshot:

c. Update row counts for the new aggregates and confirm that you see the following row
counts. Check out objects when prompted.
ag_F3_Revenue: 392 rows
ag_F4_Revenue: 108 rows
SA_Month*: 55 rows
SA_Product*: 3 rows
SA_Product*: 11 rows
d. Expand the new aggregate physical tables and note the column names created by the
Aggregate Persistence Wizard. Your results should look similar to the following
screenshot:
5. Verify that the aggregates are created in the Business Model and Mapping layer of the
repository.
a. In the Business Model and Mapping layer, open the Sources folder for the F1
Revenue logical table and confirm that new logical table sources are created for the
aggregates. Your results should look similar to the following screenshot:

b. Rename the logical table sources. Check out objects when prompted.
Old Name New Name
ORCL__BISAMPLE_ag_F3_Revenue LTS3 F3 Revenue Aggregate
ORCL__BISAMPLE_ag_F4_Revenue LTS4 F4 Revenue Aggregate
c. Double-click the LTS3 F3 Revenue Aggregate logical table source.
d. Click the General tab and confirm that the LTS3 F3 Revenue Aggregate logical table
source maps to the ag_F3_Revenue physical table.
e. Click the Column Mapping tab and confirm that the Revenue logical column maps to
the corresponding physical column in the ag_F3_Revenue physical table.
f. Click the Content tab and confirm that the logical levels are set correctly. H1 Time
should be set to Month and H2 Product should be set to Product Type.

g. Click Cancel to close the Logical Table Source dialog box.
h. Repeat steps c–g for the LTS4 F4 Revenue Aggregate logical table source. Verify
that the H1 Time logical level is set to Month and the H2 Product logical level is set to
Product Brand.
i. Open the Sources folders for the D1 Time logical table and confirm that a new logical
table source is created for the aggregate. Your results should look similar to the
j. Rename the new logical table source to LTS3 D1 Time Month Grain. Check out
objects when prompted.
k. Confirm that the column mappings are mapped correctly, and that the logical level is
set correctly to Month for the LTS3 D1 Time Month Grain logical table source that was
generated by the Aggregate Persistence Wizard. Your results should look similar to the

l. Open the Sources folder for the D2 Products logical table and confirm that two new
logical table sources are created for the aggregates. Your results should look similar to
the following screenshot:
m. Recall that one product dimension aggregate was generated for the Product Type
logical level, and one was generated for the Product Brand logical level. Determine
which aggregate is for Product Type and rename it to LTS2 D2 Product Type.
Rename the other aggregate to LTS3 D2 Product Brand.
n. Confirm that the columns and logical levels are set correctly for the new logical table
sources generated by the Aggregate Persistence Wizard. Your results should look
similar to the following screenshots:
o. Close all open dialog boxes.

p. Check in changes.
q. Check consistency. Fix any consistency check errors before proceeding. You can
ignore the warning User “weblogic” is not defined in the Enterprise Manager.
r. Save and close the repository. Notice that you do not have to make any changes to the
Presentation layer.
s. Leave the Administration Tool open.
6. Use the Analysis Editor to test your work.
a. Sign in to Oracle BI as weblogic with the password welcome1.
b. Create a new analysis for the Sample Sales subject area.
c. Reload server metadata. Because you implemented all your changes in online mode,
there is no need to upload the repository.
d. Create the following analysis:
Products.Type

Base Facts.Revenue
e. Click Results.
f. Inspect the query log and confirm that the query used the ag_F3_Revenue fact
aggregate table and the related SA_Product* dimension aggregate. Oracle BI Server
uses the most economical sources to satisfy the query. Your log should resemble the

g. Create and run another query with the following columns:
Products.Brand
Base Facts.Revenue
h. Inspect the query log and confirm that the query used the ag_F4_Revenue fact
aggregate table and the related SA_Product* dimension aggregate. Your log should
resemble the following screenshot:
Using Partitions and
Fragments
Practices Overview
In these practices, you model partitions in an Oracle BI repository.
202 Practices for Lesson 13: Using Partitions and Fragments

Practice 13-1: Modeling a Value-Based Partition
Overview
In this practice, you model a value-based partition.
Assumptions
You want to store fact data in two separate partitions, one for recent data and one for historical
data. Each partition contains the same columns. Only the data values are different. The
historical data partition stores revenue fact data up to and including December 31, 2009. The
recent data partition stores fact data after December 31, 2009.
Time

30 minutes
Tasks
1. Import two value-based partitioned sources with fact data into the Physical layer.
d. Accept the defaults in the Select Metadata Types window and click Next to open the
Select Metadata Objects window.
e. Expand the BISAMPLE schema.
f. In the “Data source view” pane, select the SAMP_REVENUE_F_RECENT and
SAMP_REVENUE_F_HISTORICAL tables for import.
g. Click the Import selected button to add the tables to the Repository View pane.
h. Expand BISAMPLE in the Repository View pane and confirm that the
SAMP_REVENUE_F_RECENT and the SAMP_REVENUE_F_HISTORICAL tables
are added.
i. Click Finish to add the tables to the repository.
j. Expand BISAMPLE in the Physical Layer and confirm that the
SAMP_REVENUE_F_RECENT and SAMP_REVENUE_F_HISTORICAL tables are
added to the repository. SAMP_REVENUE_F_HISTORICAL has fact data for 2007‒
2009. SAMP_REVENUE_F_RECENT has fact data for 2010.
k. Update row counts for the two new tables to ensure connectivity.
SAMP_REVENUE_F_RECENT: 7342 rows
SAMP_REVENUE_F_HISTORICAL: 12658 rows
F11 Revenue Recent
F12 Revenue Historical
Practices for Lesson 13: Using Partitions and Fragments 203

m. Use the Physical Diagram to create the following physical joins:
"ORCL".""."BISAMPLE"."F11 Revenue Recent"."BILL_DAY_DT"
"ORCL".""."BISAMPLE"."F11 Revenue Recent"."PROD_KEY"
"ORCL".""."BISAMPLE"."F11 Revenue Recent"."CUST_KEY"
"ORCL".""."BISAMPLE"."F12 Revenue Historical"."BILL_DAY_DT"

"ORCL".""."BISAMPLE"."F12 Revenue Historical"."PROD_KEY"
"ORCL".""."BISAMPLE"."F12 Revenue Historical"."CUST_KEY"
2. Create two new logical table sources for the F1 Revenue logical table.
a. Expand Sample Apps > F1 Revenue > Sources in the Business Model and Mapping
layer.
b. Expand F11 Revenue Recent in the Physical layer.
c. Drag the REVENUE column from F11 Revenue Recent to the Revenue column in F1
Revenue. This creates a new logical table source named F11 Revenue Recent, and
maps the column.
d. Repeat the steps for the REVENUE column in F12 Revenue Historical. This creates a
new logical table source named F12 Revenue Historical, and maps the column.
e. Rename the F11 Revenue Recent logical table source to LTS3 F11 Revenue Recent.

f. Rename the F12 Revenue Historical logical table source to LTS4 F12 Revenue
Historical.

3. Create a new logical column.
a. Right-click F1 Revenue and select New Object > Logical Column.
b. Name the column Order Date.
c. Drag the ORDER_DAY_DT column from F11 Revenue Recent to the Order Date
column in F1 Revenue.
d. Drag the ORDER_DAY_DT column from F12 Revenue Historical to the Order Date
column in F1 Revenue.
e. Drag Order Date to the Base Facts presentation table in the Sample Sales subject
area.
4. Create fragmentation content for the two new logical table sources.
a. Double-click LTS4 F12 Revenue Historical in the Sources folder.
b. Click the Content tab.
c. Click the button next to the “Fragmentation content” field to open the Expression
Builder.

d. Select Logical Tables > F1 Revenue, and then double-click the Order Date column.
The expression is added to the Expression Builder.
e. Click “<=” on the toolbar to add it to the formula, and then add '31-DEC-09' to the
formula. You are hard-coding this formula so that this logical table source will be used
for queries in which Order Date is less than or equal to December 31, 2009.
Note: In the next lesson titled “Using Repository Variables,” you learn how to use
variables to dynamically populate formulas.

f. Click OK to close the Expression Builder. Notice that the expression is added to the
“Fragmentation content” field.

g. Select This source should be combined with others at this level.
h. Click the Column Mapping tab and verify the mappings.
i. Click OK to close the Logical Table Source dialog box.

j. Double-click LTS3 F11 Revenue Recent in the Sources folder.
k. Click the Content tab.

l. Open the Expression Builder and create the following expression:
"Sample Apps"."F1 Revenue"."Order Date" > '31-DEC-09'.
You are hard-coding this formula so that this logical table source will be used for
queries in which Order Date is greater than December 31, 2009.

m. Click OK.
n. Select This source should be combined with others at this level.
o. Click the Column Mapping tab and verify the mappings.
p. Click OK to close the Logical Table Source dialog box.

q. Notice that you did not have to change the Presentation layer, except to add the Order
Date column to the Base Facts presentation table. The Order Date column is added
for testing analyses in the next set of steps.
r. Save the repository.
s. Check consistency. Fix any errors or warnings before you proceed.
u. Keep the Administration Tool open.
5. Create and run analyses to test your work.
b. Return to the Analysis Editor and create the following analysis in the Sample Sales
subject area:
Base Facts.Order Date

Base Facts.Revenue
c. Click Results.
Notice that Order Date records are returned for dates that are both before and after
31-DEC-09. The screenshot shows only a partial display of the total records returned.

d. Inspect the query log. Confirm that the query references both partition tables. Both
partition tables are used because you did not apply a filter in the query. Notice that a
separate SELECT statement is sent to each table and Oracle BI Server performs a
union all to combine the results.

Partitioning can create complexity in the query environment. Queries must access
multiple tables, and then consolidate the results. One of the important benefits of
Oracle BI Server is that it can perform this type of navigation and consolidation
automatically and invisibly to the end user.

e. Return to the Analysis Editor and create the same analysis, but with a filter in which
Order Date is less than or equal to 12/31/2009.

f. Run the analysis again.
g. Verify that your result displays only those records in which Order Date is less than or
equal to 12/31/2009.
h. Inspect the query log and confirm that the query accessed only one partition: F12
Revenue Historical.
6. Verify that your results are correct when Order Date is greater than 12/31/2009.
a. Return to the Analysis Editor and create the same analysis, but with a filter in which
Order Date is greater than 12/31/2009.
b. Run the analysis.
c. Verify that your result displays only those records in which Order Date is greater than
12/31/2009.

d. Inspect the query log and confirm that the query being issued accesses the correct
partition, F11 Revenue Recent.

e. Sign out of Oracle BI.

Using Repository Variables
Practices Overview
In these practices, you create and use dynamic repository variables with initialization blocks.
214 Practices for Lesson 14: Using Repository Variables

Practice 14-1: Creating Dynamic Repository Variables
Overview
In this practice, you create and use dynamic repository variables with initialization blocks.
Assumptions
Dynamic repository variables are useful for defining the content of logical table sources. In the
practice for the previous lesson titled “Using Partitions and Fragments,” you created two
sources for information about orders: one source containing recent orders and the other source
containing historical data. You described the content of these sources on the Content tab of the
Without using dynamic repository variables, you would have to describe the content of the

source containing recent data with a static expression such as Sample Apps."F1
Revenue"."Order Date" <= '31-DEC-09', as you did in Practice 13. This content statement
becomes invalid when new data is added to the recent source and older data is moved to the
historical source. To accurately reflect any new data, you would have to modify the
fragmentation content description manually.
To avoid modifying the fragmentation content description manually, you can set up dynamic
repository values to do this automatically. To use a dynamic repository variable, you must also
set up an initialization block to refresh the variable on a continuing basis.
Outcome
A new initialization block called OrderSplit is created with a variable named EndHistoricalData.
In the Business Model and Mapping layer, the sources of logical tables are modified for the F1
Revenue logical table.
Time
25 minutes
Tasks
1. Create a dedicated connection pool for the variable initialization block.
Note: It is recommended that you create a dedicated connection pool for initialization
blocks. This connection pool should not be used for queries.
b. In the Physical layer, right-click the ORCL database object and select New Object >
Connection Pool to open the Connection Pool dialog box.
c. On the General tab, name the connection pool Variables.
d. Confirm that the call interface is set to Default (OCI 10g/11g).
e. Enter ORCL as the data source name.
f. Enter BISAMPLE as the username and password.
Practices for Lesson 14: Using Repository Variables 215

g. Click OK to close the Connection Pool dialog box.
h. Enter BISAMPLE to confirm the password and click OK. The Variables connection
pool is added to the ORCL database object.
2. In this step, you create an initialization block. Initialization blocks contain SQL statements
that initialize variables. The variables are repository variables and their values persist until

the initialization block resets them the next time it runs. Repository initialization blocks
execute whenever Oracle BI Server starts up, and thereafter according to any schedule that
is applied.
a. Select Manage > Variables to open Variable Manager.
b. Select Action > New > Repository > Initialization Block to open the Repository
Variable Initialization Block dialog box.
c. Name the initialization block OrderSplit.
d. Leave the schedule set to the default.
e. Click Edit Data Source.
f. Click the Browse button.
g. Double-click the Variables connection pool object to select it. The connection pool is
added to the Repository Variable Initialization Block Data Source dialog box.
h. Select Default initialization string.

i. Enter the following SQL in the “Default initialization string” field to capture the most
recent order date from the SAMP_REVENUE_F_HISTORICAL table:
SELECT MAX(ORDER_DAY_DT) from BISAMPLE.SAMP_REVENUE_F_HISTORICAL

j. Click OK to close the Repository Variable Initialization Block Data Source dialog box
and return to the Repository Variable Initialization Block dialog box.
3. Create the variable.
a. Click Edit Data Target to open the Repository Variable Initialization Block Variable
Target dialog box.
b. Click the New button to open the Dynamic Repository Variable dialog box.
c. In the Name field, enter EndHistoricalData.

d. Enter '31-DEC-09' in the Default Initializer field.

e. Click OK to close the Dynamic Repository Variable dialog box.
f. Click OK to close the Repository Variable Initialization Block Variable Target dialog
box.
g. Click Test to test the variable and check your results:
h. Click Close.

i. Check your work:

j. Click OK to close the Repository Variable Initialization Block dialog box. The OrderSplit
initialization block and the EndHistoricalData dynamic repository variable are visible in
the Variable Manager.
k. Select Action > Close to close the Variable Manager.

4. Use the variable to dynamically determine the fragmentation content of the LTS6 F12
Revenue Historical logical table source.
a. In the Sample Apps business model, expand F1 Revenue > Sources.
b. Double-click LTS4 F12 Revenue Historical.
c. Click the Content tab.
d. Open the Expression Builder by clicking the Edit Expression button next to the
Fragmentation content field.
e. Delete '31-DEC-09' from the expression after the <= operator.

f. In the left pane, under Category, select Repository Variables and double-click the
EndHistoricalData variable to add it to the expression.
g. Click OK to close the Expression Builder.

h. Ensure that the This source should be combined with other sources at this level
check box is selected.

i. Check your work.

j. Click OK to close the Logical Table Source dialog box.
5. Use the variable to dynamically determine the content in the LTS5 F11 Revenue Recent
logical table source.
a. Double-click LTS3 F11 Revenue Recent.
b. Click the Content tab.
c. Open the Expression Builder.

d. Modify the existing expression by replacing '31-DEC-09' with the EndHistoricalData
variable:

e. Click OK to close the Expression Builder.
f. Ensure that the This source should be combined with other sources at this level
check box is selected.
g. Check your work.

i. Save the repository.
j. Check consistency. Fix errors or warning messages before you proceed.
k. Close the repository.
l. Keep the Administration Tool open.
6. Test your work.
a. Use the uploadrpd command to upload the BISAMPLE repository to BI Server:
b. Return to the Analysis Editor.
c. Create the following analysis by using the Sample Sales subject area:
Base Facts.Order Date
Base Facts.Revenue

d. Click Results.

Notice that Order Date records are returned for dates that are both before and after
12/31/2009 because no filters are applied. The screenshot shows only a partial view of
the data.

e. Inspect the query log. Confirm that the query references both partition tables. Both
partition tables are used because you did not apply a filter in the query. Notice that a
separate SELECT statement is sent to each table and Oracle BI Server performs a
UNION ALL to combine the results.

f. Return to the Analysis Editor, create the same analysis, but add a filter in which Order
Date is less than or equal to 12/31/2009.
g. Click Results and verify that your results display only Order Dates that are less than or
equal to 12/31/2009.
h. Check the query log and verify that the query accessed only one partition:
SAMP_REVENUE_F_HISTORICAL.
i. Create the same analysis and edit the filter to show records in which Order Date is
greater than 12/31/2009.

j. Click Results and verify that your result displays only records in which Order Date is
greater than 12/31/2009.
k. Check the query log and confirm that the query being issued accesses the correct
partition: SAMP_REVENUE_F_RECENT.


Practice 14-2: Using Dynamic Repository Variables as Filters
Overview
In this practice, you create and use dynamic repository variables as filters.
Assumptions
Rather than creating hard-coded column filters such as Year = 2009 in analyses, you want to
use variables that always return the current year, current month, and current day. You create
these dynamic repository variables, and then use them in column filters in Oracle BI analyses.
Outcome
You create a new initialization block (Current Periods) and three new dynamic repository

variables (CurrentYear, CurrentMonth, and CurrentDay).
Time
15 minutes
Tasks
1. Create a new initialization block that will initialize three variables named CurrentYear,
CurrentMonth, and CurrentDay. The variables will get their values from the initialization
block SQL according to the schedule that you set. In this example, the system determines
the value of the current day by finding the maximum value of the order date
(ORDER_DAY_DT) in the SAMP_REVENUE_F table, and then determining the month and
year that correspond to that value in the SAMP_TIME_DAY_D table.
b. Select Manage > Variables.
c. Select Action > New > Repository > Initialization Block.
d. Name the initialization block CurrentPeriods.
e. Click Edit Data Source to open the Repository Variable Initialization Block Data
Source dialog box.
f. Click the Browse button.
g. Double-click the Variables connection pool object to select it.
h. Make sure that Default initialization string is selected.

i. Enter the following SQL in the block to determine the value of the current day by
finding the maximum value of the order date (ORDER_DAY_DT):
SELECT PER_NAME_MONTH, PER_NAME_QTR, PER_NAME_YEAR FROM
BISAMPLE.SAMP_TIME_DAY_D WHERE CALENDAR_DATE = (SELECT
MAX(ORDER_DAY_DT) FROM BISAMPLE.SAMP_REVENUE_F)

j. Click OK to close the Repository Variable Initialization Block Data Source dialog box.
2. Create the variables.
a. Click Edit Data Target to open the Repository Variable Initialization Block Variable
Target dialog box.
b. Create three new variables: CurrentMonth, CurrentQuarter, and CurrentYear. The
order is important. The value returned from the first column in the initialization block
SQL, PER_NAME_MONTH, is assigned to the CurrentMonth variable. The value of the
second column, PER_NAME_QTR, is assigned to CurrentQuarter (the second
variable), and the value of the third column, PER_NAME_YEAR, is assigned to
CurrentYear (the third variable). If necessary, use the up and down buttons to arrange
the variables.

c. Click OK to close the Repository Variable Initialization Block Variable Target dialog
box.

d. Leave the default refresh interval set to every hour. This means that the variables will
be reinitialized every hour.

e. Click the Test button and check the results.
Note that in this example, the results are determined based on the data in the
BISAMPLE database that is used for this course, which holds data only through
December 2010.
f. Click Close to close the Results window.

g. Click OK to close the Repository Variable Initialization Block dialog box. The new
initialization block and variables are visible in the Variable Manager:

h. Close the Variable Manager.
j. Check consistency. Fix any errors or warnings before proceeding.
l. Keep the Administration Tool open.
3. Test your work.
b. Sign in to Oracle BI and create the following analysis in the Sample Sales subject area:
Time.Per Name Year
Time.Per Name Qtr
Time.Per Name Month
Base Facts.Revenue
c. Select Filter for the Per Name Year column. The New Filter dialog box opens.
d. Select Add More Options > Repository Variable.

e. In the Repository Variable field, enter CurrentYear.

f. Click OK.
g. Repeat to add the CurrentQuarter and CurrentMonth repository variables as filters
for the Per Name Month and Calendar Date columns, respectively.
h. Click Results and ensure that only data for the current year, current month, and
current day (2010 based on this data set) is returned.

i. Check the query log. In the SQL Request section, notice the logical request filters for
the variables, for example, "Time"."Per Name Year" = VALUEOF("CurrentYear").
The following screenshot shows only a partial view of the log file:

j. Sign out of Oracle BI.


Modeling Time Series Data
Practices Overview
In these practices, you model time series data by using Oracle BI time series functions.
236 Practices for Lesson 15: Modeling Time Series Data

Practice 15-1: Creating Time Series Calculation Measures
Overview
In this practice, you create time series calculation measures by using Oracle BI time series
functions.
Assumptions
You use Oracle BI time series functions to create new measures to enable users to compare
current revenue performance to previous time periods. You then add the new measures to the
subject area and test the measures by using analyses.
The time series functions include AGO, TODATE, and PERIODROLLING. These functions let
you use the Expression Builder to call a logical function to perform time series calculations

instead of creating aliases for physical tables, and then logically modeling the time series
calculations. The time series functions create time series calculation measures based on the
calendar tables in your data warehouse, rather than on the standard SQL date manipulation
functions.
Time
25 minutes
Tasks
1. In the Sample Apps business model, set the H1 Time logical dimension as a time
dimension.
b. In the Sample Apps business model, double-click the H1 Time logical dimension.
Practices for Lesson 15: Modeling Time Series Data 237

c. On the General tab, select the Time check box. Time series functions operate on time-
oriented dimensions. To use these functions on a particular dimension, you must
designate the dimension as a Time dimension.

d. Click OK to close the dialog box.
2. Identify level keys as chronological keys. It is a best practice to designate a chronological
key for every level of a time dimension hierarchy.
a. Expand the H1 Time logical dimension and double-click the Time Detail level to open
the Logical Level dialog box.
c. Select the Chronological Key check box for Calendar Date. It may be necessary to
scroll to the right.
d. Click OK to close the Logical Level dialog box.

e. Repeat and set chronological keys for the following levels:
Logical Level Chronological Key
Year Per Name Year
Half Per Name Half
Quarter Per Name Qtr
Month Per Name Month
Week Per Name Week
3. Create a measure that calculates revenue for the previous month by using the Ago function.
a. Right-click the F1 Revenue logical table and select New Object > Logical Column.
b. On the General tab, name the column Month Ago Revenue.

expression.
d. Click the Edit Expression button to open the Expression Builder.
e. Select Functions > Time Series Functions > Ago.
f. Click Insert selected item to add the Ago function to the Expression Builder.
g. Click <<Measure>> in the expression.

h. Select Logical Tables > F1 Revenue, and then double-click Revenue to add it to the
expression.
i. Click <<Level>> in the expression.
j. Select Time Dimensions > H1 Time, and then double-click Month to add it to the
expression.
k. Click <<Number of Periods>> and enter 1. The Ago function will calculate the
revenue value one month before the current month.
l. Click OK to close the Expression Builder.
m. Check your work.

n. Click OK to close the Logical Column dialog box. The Month Ago Revenue time
series measure is added to the F1 Revenue logical table.
o. Drag the Month Ago Revenue logical column to the Calculated Facts presentation
table.
4. Create a measure that calculates the difference in revenue between the current month and
the previous month.
a. Right-click the F1 Revenue logical table and select New Object > Logical Column.
b. On the General tab, name the new logical column Change Month Ago Revenue.
expression.

e. Select Logical Tables > F1 Revenue, and then double-click Revenue to add it to the
expression.
f. Insert a minus sign.
g. Select Logical Tables > F1 Revenue, and then double-click Month Ago Revenue.
h. Click OK to close the Expression Builder.
i. Check your work.

j. Click OK to close the Logical Column dialog box. The Change Month Ago Revenue
logical column is added to the F1 Revenue logical table.
k. Drag the Change Month Ago Revenue logical column to the Calculated Facts
presentation table.
5. Create a measure that calculates the percentage change in revenue between the current
month and the previous month.
b. Name the new logical column Percent Change Month Ago Revenue.
expression.
d. Open the Expression Builder and create the following expression:
100 * ("Sample Apps"."F1 Revenue"."Change Month Ago Revenue" /

"Sample Apps"."F1 Revenue"."Month Ago Revenue")
e. Click OK to close the Expression Builder.

f. Check your work.

g. Click OK to close the Logical Column dialog box.
h. Drag the Percent Change Month Ago Revenue logical column to the Calculated
Facts presentation table.
6. Create a measure that calculates a running sum of revenue over the past year on a monthly
basis by using the TODATE function.
b. Name the new logical column Year To Date Revenue.
expression.
e. Select Functions > Time Series Functions and double-click ToDate to insert the

expression.
f. Click <<Measure>>.
g. Select Logical Tables > F1 Revenue, and then double-click Revenue to add it to the
expression.
h. Click <<Level>>.
i. Select Time Dimensions > H1 Time, and then double-click Year to add it to the
expression.
j. Click OK to close the Expression Builder.
k. Check your work.

l. Click OK to close the Logical Column dialog box.
m. Drag the Year To Date Revenue logical column to the Calculated Facts presentation
table.
7. Create a measure that calculates a three-period rolling sum for revenue by using the
PeriodRolling function.
b. On the General tab, name the logical column Revenue 3-Period Rolling Sum.
expression.
e. Select Functions > Time Series Functions, and then double-click PeriodRolling to
insert the expression.
f. Click <<Measure>>.
g. Select Logical Tables > F1 Revenue, and then double-click Revenue to add it to the
expression.
h. Click <<Starting Period Offset>>.

i. Enter ‒2. This identifies the first period in the rolling aggregation.
j. Click <<Ending Period Offset>>.
k. Enter 0. This identifies the last period in the rolling aggregation. These integers
represent the relative number of periods from a displayed period. In this example, if the
query grain is month, the three-month rolling sum starts two months in the past (‒2),
and includes the current month (0).
l. Click OK to close the Expression Builder.
m. Check your work.
n. Click OK to close the Logical Column dialog box. Oracle Internal & Oracle Academy Use Only
o. Drag the Revenue 3-Period Rolling Sum logical column to the Calculated Facts
presentation table.
p. Save the repository.
q. Check consistency. Fix errors or warnings, if any, before you proceed.
r. Close the repository.
s. Keep the Administration Tool open.

8. Create analyses to check your work for the AGO and TODATE functions.
c. Sign in to Oracle BI as the weblogic user with the password welcome1.
d. Create the following analysis and filter in the Sample Sales subject area:
Time.Per Name Month
Base Facts.Revenue
Calculated Facts.Month Ago Revenue
Calculated Facts.Change Month Ago Revenue
Calculated Facts.Percent Change Month Ago Revenue
Calculated Facts.Year to Date Revenue
Per Name Year is equal to / is in 2008

e. Change the data format of the *Revenue* columns to Currency and the data format of
the *Percent* columns to Percentage.
f. Click Results. Your results should look similar to the following screenshot:
9. Create analyses to check your work for the PeriodRolling function.

a. Create the following analysis and filter.
Time.Per Name Month
Base Facts.Revenue
Calculated Facts.Revenue 3-Period Rolling Sum
b. Change the data format of the *Revenue* columns to Currency.

c. Click Results.

d. Create a similar analysis for Calendar Date.
Time.Per Name Quarter
Base Facts.Revenue
Calculated Facts.Revenue 3-Period Rolling Sum
e. Click Results.
The Revenue 3-Period Rolling Sum measure displays results based on the query
grain.
f. Sign out of Oracle BI.

Modeling Many-to-Many
Relationships
Practices Overview
In these practices, you model many-to-many relationships in an Oracle BI repository.
248 Practices for Lesson 16: Modeling Many-to-Many Relationships

Practice 16-1: Modeling a Bridge Table
Overview
In this practice, you configure a bridge table for office and channel data.
Assumptions
You can use logical mappings to address dimensions that have a many-to-many relationship
with one another. In the example in this practice, a bridge table provides correspondence
between offices and channels. An office can have multiple channels, and each channel belongs
to more than one office. The logical model leverages the bridge table to show revenue from
each dimension grain.

Time
25 minutes
Tasks
1. Import tables into the repository.
d. Accept the defaults on the Select Metadata Types screen and click Next to open the
Select Metadata Objects screen.
e. Scroll to the BISAMPLE schema and expand it.
f. In the “Data source view” pane, select the following tables for import:
SAMP_BRIDGE_TABLE
SAMP_CHANNELS_D
SAMP_OFFICES_D
g. Add the tables to the Repository View pane.
h. Expand BISAMPLE in the Repository View pane and confirm that the tables are
added.
i. Click Finish to add the tables to the repository.
j. In the Physical layer, expand ORCL > BISAMPLE and ensure that the tables are
visible.
k. Update row counts on each table to check connectivity.
SAMP_BRIDGE_TABLE : 27 rows
SAMP_CHANNELS_D : 5 rows
SAMP_OFFICES_D : 20 rows
Practices for Lesson 16: Modeling Many-to-Many Relationships 249

SAMP_BRIDGE_TABLE > D63 Channel Office Bridge (Rev)
SAMP_CHANNELS_D > D62 Channels (Rev)
SAMP_OFFICES_D > D6 Offices
2. Create the physical joins.
a. Select the following alias tables:
D6 Offices
D62 Channels (Rev)
D63 Channel Office Bridge (Rev)
F1 Revenue
b. Right-click any one of the highlighted tables and select Physical Diagram > Selected
Object(s) Only.

c. Create the following foreign key joins:
"ORCL".""."BISAMPLE"."D6 Offices"."OFFICE_KEY" =
"ORCL".""."BISAMPLE"."D63 Channel Office Bridge
(Rev)"."OFFICE_KEY"
"ORCL".""."BISAMPLE"."D62 Channels (Rev)"."CHNL_KEY" =

"ORCL".""."BISAMPLE"."D63 Channel Office Bridge
(Rev)"."CHNL_KEY"
"ORCL".""."BISAMPLE"."D6 Offices"."OFFICE_KEY" =
"ORCL".""."BISAMPLE"."F1 Revenue"."OFFICE_KEY"
d. Notice the many-to-many relationship among D6 Offices, D62 Channels (Rev), and
D63 Channel Office Bridge (Rev).

e. Close the Physical Diagram window.
3. Create the logical model.
a. Drag D6 Offices from the Physical layer to the Sample Apps business model in the
Business Model and Mapping layer. This action creates a new logical table named D6
Offices with a new logical table source named D6 Offices and the associated column
mappings.
b. Rename the D6 Offices logical table to D6 Offices and Channels.
c. Rename the D6 Offices logical table source to LTS1 Offices (Direct to Revenue).
d. Use the Rename Wizard to rename the logical columns according to the following
rules:

e. Check your work:
f. Right-click LTS1 Offices (Direct to Revenue) and select Duplicate to create a copy of
the logical table source named LTS1 Offices (Direct to Revenue)#1.

g. Rename LTS1 Offices (Direct to Revenue)#1 to LTS2 Channels (Bridged to
Revenue).
h. Double-click LTS2 Channels (Bridged to Revenue) to open the Logical Table Source
dialog box.
i. On the General tab, click the Add button to open the Browse dialog box.
j. In the right pane, select the D63 Channels Office Bridge (Rev) alias table, and then
click the Select button to add the table to the logical table source.
k. Repeat the preceding step to add the D62 Channels (Rev) table to LTS2 Channels
(Bridged to Revenue).

l. On the Column Mapping tab, use the Add New Column button to create the following
logical columns and mappings:
Logical Expression Physical Table
Column
Channel CHNL_ATTRIBUTE_ D62 Channels (Rev)
Attribute 1
Channel Name CHNL_NAME D62 Channels (Rev)
Channel Key CHNL_KEY D63 Channel Office Bridge (Rev)
Channel CHNL_WEIGHTING D63 Channel Office Bridge (Rev)
Weighting
m.

n. Check your work:

o. Click OK to close the Logical Table Source dialog box.
p. Select the D6 Offices and Channels and F1 Revenue logical tables.
q. Right-click either of the highlighted tables and select Business Model Diagram >
Selected Tables Only.
r. Notice that the logical join between the D6 Offices and Channels and F1 Revenue
tables is already created. This is because you joined D6 Offices and F1 Revenue in the
Physical layer before adding the tables and columns to the Business Model and
Mapping layer.
s. Close the Business Model Diagram.

4. Create a calculation measure by using the channel weighting and revenue physical
columns.
a. Expand F1 Revenue, right-click Sources, and select New Logical Table Source.
b. On the General tab, name the logical table source LTS5 Revenue (Bridged to
Channels).
c. Map LTS7 Revenue (Bridged to Channels) to the following tables:
D6 Offices
D63 Channel Office Bridge (Rev)
F1 Revenue

d. Click the Column Mapping tab.
e. Click the Add New Column button to open the Logical Column dialog box.
f. On the General tab, name the logical column Bridge Weighted Revenue.
g. Click OK to close the Logical Column dialog box and return to the Logical Table
Source dialog box.
h. Make sure that Show unmapped columns is selected.
i. Select the Bridge Weighted Revenue column and open the Expression Builder.
j. Create the following expression:
"ORCL".."BISAMPLE"."F1 Revenue"."REVENUE" *
"ORCL".."BISAMPLE"."D63 Channel Office Bridge
(Rev)"."CHNL_WEIGHTING" / 100

k. Click OK to close the Expression Builder, which adds the expression to the Bridge
Weighted Revenue logical column.
l. Click OK to close the Logical Table Source dialog box.
m. Set the Bridge Weighted Revenue aggregation rule to SUM.
5. Add objects to the Presentation layer.
a. Drag the D6 Offices and Channels logical table to the Sample Sales subject area in
the Presentation layer.
b. Rename D6 Offices and Channels to Offices and Channels in the Sample Sales
subject area.
c. Reorder the presentation tables so that the Offices and Channels table is above
Products.
d. Drag Bridge Weighted Revenue to Calculated Facts in the Sample Sales subject
area.
e. Save the repository.
f. Check consistency. Fix any errors or warnings before proceeding.
g. Close the repository.
h. Keep the Administration Tool open.
6. Create and run an analysis to check your work.
c. Return to Oracle BI and sign in as weblogic with the password welcome1.

d. Create the following analysis by using the Sample Sales subject area:
Offices and Channels.Office dsc
Offices and Channels.Channel Name
Calculated Facts.Bridge Weighted Revenue
e. Change the column format for Bridge Weighted Revenue to Currency.
f. Click Results. The default view is a table view that shows Office dsc, Channel Name,
and Bridge Weighted Revenue.

g. Select New View > Pivot Table to add a pivot table to the compound layout.

h. Scroll to the pivot table and click the Edit View button to open the Layout pane.

i. In the Layout pane, drag Measure Labels from Columns to Sections.

j. Click Done. Your pivot table should now look similar to the following screenshot:

In this example, a bridge table provides correspondence between offices and channels.
An office can have multiple channels, and each channel belongs to more than one
office. The logical model leverages the bridge table to show revenue from both
dimension grains.

k. Check the log file and confirm that the expected tables are accessed in the query.


Setting an Implicit Fact
Column
Practices Overview
In these practices, you set an implicit fact column for a subject area.
262 Practices for Lesson 17: Setting an Implicit Fact Column

Practice 17-1: Setting an Implicit Fact Column
Overview
In this practice, you set an implicit fact column for a subject area.
Assumptions
You track product revenue facts and product return facts in separate fact tables. You want to
ensure that users obtain the expected results if they run dimension-only queries with columns
from more than one dimension. To ensure that users obtain the expected results, you set an
implicit fact column for the Sample Sales subject area.
Time

20 minutes
Tasks
1. Import a new fact table into the Physical layer.
d. Accept the defaults in the Select Metadata Types screen, and click Next to open the
Select Metadata Objects screen.
e. Scroll to the BISAMPLE schema and expand it.
f. In the “Data source view” pane, select the SAMP_RETURNS_F table for import.
g. Add the table to the Repository View pane.
h. Expand BISAMPLE in the Repository View pane and confirm that the table is added.
i. Click Finish to add the table to the repository.
j. In the Physical layer, expand ORCL > BISAMPLE and ensure that the
SAMP_RETURNS_F table is visible.
k. Update row count for SAMP_RETURNS_F to verify connectivity. You should see 259
rows.
2. Create an alias and physical joins.
a. Create an alias for SAMP_RETURNS_F and name it F3 Returns.
Create the following physical joins:
"ORCL".""."BISAMPLE"."F3 Returns"."PROD_KEY"
"ORCL".""."BISAMPLE"."F3 Returns"."CUST_KEY"
Practices for Lesson 17: Setting an Implicit Fact Column 263

b. Close the Physical Diagram.
3. Build a new business model to demonstrate the use of the implicit fact column.
a. Right-click the white space in the Business Model and Mapping layer and select New
Business Model to open the Business Model dialog box.
b. On the General tab, name the business model Implicit Fact.
c. Click OK to close the Business Model dialog box. The Implicit Fact business model is

added to the Business Model and Mapping layer.
d. In the Physical layer, select D1 Time, D2 Products, D3 Customers, F1 Revenue, and
F3 Returns.
e. Drag all five tables to the Implicit Fact business model. You now have a business
model in which F1 Revenue and F3 Returns are joined to the same two dimensions
(D2 Products and D3 Customers) and F1 Revenue is also joined to D1 Time.
Note: In step 4 that follows, you explore the effect that this model has on dimension-
only queries.
f. Drag the Implicit Fact business model to the Presentation layer to create the Implicit
Fact subject area.
g. Save the repository.
h. Check consistency.
i. You should receive the message ‘Business model “Implicit Fact” is consistent. Do you
want to mark it as available for queries?’ Click Yes.
j. Close the repository.
k. Leave the Administration Tool open.
4. Create an analysis to test your work.
b. Return to Oracle BI and sign in as weblogic with the password welcome1.

c. Create the following analysis by using the Implicit Fact subject area to show products
that were purchased by customers. Notice that this is a dimension-only query that
includes columns from two dimensions. No fact columns are included in the query.
D3 Customers.NAME
D2 Products.PROD_DSC
d. Click Results.
e. Click the Edit View icon for the Table view.

f. Click the Table View Properties icon to open the Table Properties dialog box.

g. Select Content paging.

h. Click OK to close the Table Properties dialog box.
i. Click Done to return to the Compound Layout.
j. Scroll to the bottom of the Compound Layout.
k. Click the Display maximum icon to view all the records.
l. Verify that 258 rows are returned.

m. Examine the query log.
Notice that the query returns data from the expected dimensions, D3 Customers and
D2 Products, and that the F3 Returns table was accessed instead of the F1 Revenue
table. In a dimension-only query with columns from multiple dimensions in which

common dimensions are joined to multiple fact tables, BI Server must choose a fact
table to include in the query. If no implicit fact column is set, Oracle BI Server chooses
the most economical fact table. In this case, it chooses the fact table with the least
number of joins. However, this is “incorrect” data if the user expects to see all products
for all customers. This query shows product data for only those customers who have
returned products.
n. Sign out of Oracle BI.
5. Set an implicit fact column for the Implicit Fact subject area to point to a measure in the F1
Revenue fact table.
b. In the Presentation layer, double-click Implicit Fact to open the Subject Area dialog

box.
d. In the Implicit Fact Column section, click Set.
e. In the Browse dialog box, expand F1 Revenue, select the REVENUE column, and click
OK. The implicit fact column is set to "Implicit Fact"."F1 Revenue"."REVENUE".
f. Click OK to close the Subject Area dialog box.

g. Save the repository.
h. Check consistency. Fix any errors or warnings before proceeding.
i. Close the repository.
j. Keep the Administration Tool open.
6. Create an analysis to test your work.
b. Return to Oracle BI and sign in as weblogic with the password welcome1.
c. Select New > Analysis and select the Implicit Fact subject area.

d. Reload server metadata.
e. Create the same dimension-only request in the Implicit Fact subject area to show
products that were purchased by customers:
D3 Customers.NAME
D2 Products.PROD_DSC
f. Click Results. This is “correct” data because it shows all products for all customers.

g. Examine the query log.

h. Notice that the query again returns data from the expected dimensions, D3 Customers
and D2 Products. But now the F1 Revenue table is accessed instead of the F3 Returns
table. Setting the implicit fact column forced Oracle BI Server to join the dimensions
through this fact table. The implicit fact column (REVENUE) is visible in the query log,
but it is not visible in the analysis results. It is used to specify a default join path
between dimension tables in dimension-only queries when there are several possible
alternatives.


Importing Metadata from
Multidimensional Data
Sources
272 Practices for Lesson 18: Importing Metadata from Multidimensional Data Sources
Security

Overview
In these practices, you will learn how to implement Oracle BI security.
274 Practices for Lesson 19: Security

Practice 19-1: Exploring Default Security Settings
Overview
In this practice, you explore the default security settings for Oracle Business Intelligence.
Assumptions
During installation, three Oracle Business Intelligence security controls are preconfigured with
initial values to form the default security model. The security controls include:
• An embedded directory server functioning as an identity store designed to hold all user
and group definitions, required to control authentication
• A file-based policy store designed to hold the application role and permission grant
mappings to users and groups, required to control authorization

• A file-based credential store designed to hold all user and system credentials, required
to control authentication or authorization
Before you implement data access security in the Oracle BI repository, you explore these
default security settings.
Time
10 minutes
Tasks
1. Log in to the WebLogic Server Administration Console to explore the identity store. This
console is used to manage users and groups for the embedded LDAP server that serves as
an out-of-the-box identity store.
a. Open a new tab on the browser and enter the following URL:
http://localhost:9500/console.
b. Log in as weblogic with password welcome1. During installation, you are prompted
for a username and password to use as an Oracle BI Administrator. In this training
environment, the Administrator user created during installation is weblogic. This is an
arbitrary choice and there is nothing special about the name. This user has
administrative privileges across the Oracle Business Intelligence (OBI) stack. This
includes the OBI repository, the OBI presentation catalog, BI Publisher, RTD, Essbase,
the identity store in WebLogic, and the policy store in Fusion Middleware.
2. Explore default settings for providers in the WebLogic security realm.
a. On the left side of the console, under Domain Structure, notice there is a single
WebLogic domain named bi into which all the OBI applications are deployed.
b. Click Security Realms.
c. Notice in the right pane that there is a single default security realm named myrealm.
The OBI installer installs a single domain with a single security realm in it. A security
realm is a container for the mechanisms that are used to protect WebLogic resources.
This includes users, groups, security roles, security policies, and security providers.
Practices for Lesson 19: Security 275

Although multiple security realms can be defined for the OBI domain, only one can be
active, meaning designated as the default realm, at any given time.
d. Click myrealm to view the default settings.
e. Click the Providers tab.
f. Notice that there is a default WebLogic Authentication Provider. An authentication
provider establishes the identity of users and system processes, transmits identity
information, and serves as a repository for identity information from which components
can retrieve it. Oracle Business Intelligence is configured to use the directory server
embedded in Oracle WebLogic Server as the default security provider. If desired,
alternate security providers can be used and managed in the Oracle WebLogic
Administration Console, but the WebLogic authentication provider is used by default.
g. Notice that there is a default WebLogic Identity Assertion Provider and a Trust Service

Identity assertion Provider. These authentication providers are used primarily for Single
Sign On and establishing trust for incoming requests, and are not covered in this
training.
3. Explore default settings for users.
a. Click the Users and Groups tab.
b. Click the Users sub tab. The default identity store is pre-seeded with usernames
specific to Oracle Business Intelligence. The two BI default users are an administrative
user (weblogic in this example) and OracleSystemUser.
c. Notice the weblogic user. This is the administrative user created during the installation
process. A single administrative user is shared by Oracle Business Intelligence and
Oracle WebLogic Server. As stated earlier, this username created during installation,
can be any desired name and, therefore, does not need to be “Administrator.” The
password is likewise provided during installation. In the default security configuration,
an administrative user is a member of the Administrators group and has all rights
granted to the Oracle Business Intelligence Administrator user in earlier releases, with
the exception of impersonation. An administrative user cannot impersonate other
users. An administrative user is also a member of the Oracle WebLogic Server default
Administrators group, which enables this user to perform all its administration tasks,
including the ability to manage Oracle WebLogic Server’s embedded directory server
and policy store.
4. Explore default settings for groups.
a. Click the Groups sub tab. Groups are logical ordered sets of users. Creating groups of
users who have similar system resource access needs enables easier security
management. Managing a group is more efficient than managing a large number of
users individually. Oracle recommends that you organize your users into groups for
easier maintenance. As you will see later in this practice, groups are then mapped to
application roles in order to grant rights.
b. Click the Users sub tab again.
c. Click the weblogic user.
d. Click the Groups tab.

e. Notice that the weblogic user is a member of the Administrators group. The
Administrators group is the WebLogic administrators group, which gives rights to
administer WebLogic and FMW enterprise manager. Membership in this administration
group gives this user a single unified administration account for the entire product
stack.
f. Sign out of the Administration Console, but leave the browser tab open.
5. Log in to Fusion Middleware Control Enterprise Manager to explore the default settings for
application roles and the policy store. An application role defines a set of permissions
granted to a user or group.
a. Open a new tab in the browser, enter http://localhost:9500/em, and log in as
weblogic with password welcome1.
b. From the WebLogic Domain drop-down list, select Security > Application Roles to

navigate to the Application Roles page.
c. Select the obi application stripe and click the search arrow to the right of Role Name.
The default BI application roles are displayed. Notice there are three default application
roles specific to Oracle BI: BIServiceAdministrator, BIContentAuthor, and
BIConsumer. These default application roles are provided as a convenience so that
you can begin using the Oracle Business Intelligence software immediately after
installation, but you are not required to maintain the default names in your deployment.
Read the descriptions to understand each application role. Members of the
BIContentAuthor application role have the permissions necessary to create content for
others to consume. Members of the BIConsumer application role have the permissions
necessary to consume content created by others.

d. Notice also that the default BI application roles are mapped to other application roles
and nested in a hierarchy in the default WebLogic LDAP. For example, the
BIContentAuthor application role is a member of the BIConsumer application role. This
means that users and groups assigned to the BIContentAuthor application role inherit
all of the permissions and privileges associated with the BIConsumer application role.

If you moved to a different LDAP server, rather than the default WebLogic LDAP
server, you could map these roles to groups in the new LDAP server. Application roles
are in the policy store, whereas groups are in the identity store.
6. Explore default settings for application policies.
a. From the WebLogic Domain drop-down list, select Security > Application Policies.
b. Select the obi application stripe.
c. Select Application Role as the Principal Type.
d. Click the Search application security grants button. The default application policies
(permissions) are displayed for each application role. The default file-based policy
store is pre-seeded with the Oracle BI–specific permissions. All Oracle Business
Intelligence permissions are provided and you cannot create additional permissions.

These permissions are granted by the default application roles in the default security
configuration. The default application role hierarchy and permission grants can be
changed as needed. Also notice that these permissions are not the same as those
used to define access to BI objects (metadata, dashboards, reports, and so on). Policy
store permissions are only used to define what BI functionality the assigned roles can
access. Notice, for example, that the BIServiceAdministrator role has been granted the
permission to manage repositories.
e. Log out of Enterprise Manager, but leave the browser tab open.

7. Explore default Presentation Services privileges. The catalog for your service instance
includes security policy for Presentation Service privileges. These privileges confer
permissions for accessing specific Presentation Services functionality such as access to
answers, access to dashboards as well as permissions on catalog objects such as folders
and analyses. The service administrator (weblogic in this environment) can modify the
catalog security policy.
a. Sign in to Oracle BI as weblogic with password welcome1.
b. Select Administration to open the Administration page.
c. In the Security section, select Manage Privileges.
d. Notice that the default application roles are assigned to Presentation Service
privileges. For example, members of the BI Consumer application role have Access to
Dashboards. Members of the BI Content Author application role have Access to

Answers, and so forth.
e. Sign out of Oracle BI without making any changes to the Presentation Service
privileges.

Practice 19-2: Creating Users and Groups
Overview
In this practice, you create users and groups in the WebLogic identity store.
Assumptions
Groups are logical ordered sets of users. Managing a group is more efficient than managing a
large number of users individually. Oracle recommends that you first organize all Oracle
Business Intelligence users into groups that make sense for your organization’s goals and then
map application roles to the groups in order to convey system privileges. The default identity
store provided for managing users and groups is Oracle WebLogic Server’s embedded directory
server. You use WebLogic Administration Server Console to create users and groups.

Time
10 minutes
Tasks
1. Create new groups.
a. Return to the WebLogic Server Administration Console, which should still be open in a
browser tab. If not, enter http://localhost:9500/console and log in as
b. Click Security Realms.
c. Click myrealm.
d. Click the Users and Groups tab.
e. Click the Groups sub tab.
f. Click the New button and create the following three groups:
Name Description Provider
SalesManagersGroup Sales Managers Group DefaultAuthenticator
SalesSupervisorsGroup Sales Supervisors Group DefaultAuthenticator
SalesAssociatesGroup Sales Associates Group DefaultAuthenticator

h. Verify that the new groups are visible in the Groups list.

2. Create a group hierarchy.
a. Click SalesSupervisorsGroup.
b. Click the Membership tab.
c. In the Available list, select SalesAssociatesGroup.

d. Move SalesAssociatesGroup to the Chosen list.

e. Click Save. This means that any privileges or permissions assigned to the Sales
Associates group will be inherited by the Sales Supervisors group.
f. Use the browser back button to return to the settings page for myrealm, or click the
Users and Groups link:
g. Click SalesManagersGroup in the Groups list.

h. Click the Membership tab.
i. In the Available list, select SalesAssociatesGroup.
j. Move SalesAssociatesGroup to the Chosen list.
k. Click Save. This means that any privileges or permissions assigned to the Sales
Associates group will be inherited by the Sales Managers group.
3. Create new users.
a. Return to Users and Groups click the Users tab.
b. Click the New button and create the following users and passwords:
Name Description Provider Password
mlombardo Michele Lombardo DefaultAuthenticator mlombardo1
hmayes Helen Mayes DefaultAuthenticator helenmayes1

d. Verify that the new users are visible in the Users list.

4. Assign users to groups.
a. Click hmayes in the Users table to open the settings page.
b. Click the Groups tab.
c. Move SalesAssociatesGroup from the Available list to the Chosen list.
d. Click Save.

e. Repeat to assign mlombardo to SalesSupervisorsGroup and
SalesManagersGroup.

f. Click Save.

Practice 19-3: Creating Application Roles
Overview
In this practice, you create application roles in the policy store.
Assumptions
An application role conveys its permission grants to the users, groups, and application roles
mapped to that role. Being mapped to an application role establishes membership in the role.
Binding the permission grants to the application role streamlines the process of granting system
privileges. After the application role and permission grant definitions are established, you control
system rights by managing membership in each role. Oracle recommends that you map groups,
not individual users, to application roles. After they are mapped, all members of the group are

granted the same rights. Controlling membership in a group reduces the complexity of tracking
access rights for multiple individual users. You use Oracle Enterprise Manager to create
application roles.
Time
20 minutes
Tasks
1. Create new application roles.
a. Return to Enterprise Manager, which should still be open in a browser tab. If not, enter
http://localhost:9500/em and log in as weblogic with password welcome1.
b. From the WebLogic Domain drop down, select Security > Application Roles to
navigate to the Application Roles page.
c. Select the obi application stripe and click the search arrow to the right of Role Name.
The default BI application roles are displayed.
d. Select the BIContentAuthor application role in the list.

e. Click Create Like to create a new application role based on the BIContentAuthor
application role. The new application role will inherit all of the privileges and
permissions assigned to BIContentAuthor. Notice that the Members section displays
the same application roles, groups, or users that are assigned to the original role. In
this example, the BIServiceAdministrator application role is a member.
f. In the Role Name field, enter SalesManagersRole.
g. In the Display Name field, enter Sales Managers Role.
h. In the Members section, click Add to open the Add Principal dialog box.
i. In the Type field, select Group.
j. In the Principal Name field, enter Sales.
k. Click the arrow next to the Display Name field to see a list of available groups that
begin with Sales.

l. In the Searched Principals list, select SalesManagersGroup and click OK to close the
Add Principal dialog box. SalesManagersGroup is now a member of
SalesManagersRole.

m. Click OK to close the Create Application Role Like page. You should see the message
A new application role SalesManagersRole has been added. The
SalesManagersRole application role is visible in the Application Roles list. Notice that
the descriptions for SalesManagersRole and BIContentAuthor are the same. Select
SalesManagersRole in the list and confirm that SalesManagersGroup is listed as a
member.

This means that any user who is a member of SalesManagersGroup is assigned to this
application role and receives any privileges or permissions assigned to the application
role. It is possible to add individual users to a role, but best practice is to add users to
groups, and then add groups, not individual users, to application roles. In this example,
Michele Lombardo is a member of SalesManagersGroup and, therefore, receives any
privileges or permissions assigned to the SalesManagersRole application role. In this
case, they are the same privileges or permissions as those assigned to the
BIContentAuthor application role.
n. Repeat the steps to create two additional application roles such as BIContentAuthor
with the members listed in the following table. Please notice that you are adding a
group as a member of SalesSupervisorsRole, and two application roles and a group as
members of the SalesAssociatesRole application role.
Application Role Members
SalesSupervisorsRole SalesSupervisorsGroup
SalesAssociatesRole SalesAssociatesGroup
SalesSupervisorsRole
SalesManagersRole

o. Check your work. Your application roles should look similar to the following screenshot:

As with the groups that you created in the WebLogic identity store, you now have an
application role hierarchy in the policy store. This means that any privileges or
permissions assigned to the SalesAssociatesRole application role will be inherited by
the SalesSupervisorsRole role and the SalesManagersRole role. What is the difference
between users and groups created in the identity store in the WebLogic LDAP Server
and application roles created in the policy store? In the WebLogic LDAP server, you
have users and groups. An application role is a logical role that can be used within the
application to secure content in a way that is independent of any particular LDAP
server and the users and groups within that LDAP server. Security rules are built using
application roles. If the underlying LDAP environment changes, the security rules
persist. In a different LDAP environment, where group or usernames might be different,
you could remap the application roles to different groups or users and the BI security
structure, which is built with application roles, would not be affected.

2. Set Presentation Services privileges for the new application roles. When you create an
application role, you must set appropriate Presentation Services privileges to enable users
with the application role to perform various functional tasks.
b. Select Administration to open the Administration page.
c. In the Security section, select Manage Privileges.
d. Locate the Access to Answers privilege and click BI Content Author to open the
Privilege dialog box.
e. Click the Add button to open the Add Application Roles and Users dialog box.
f. In the Name field, enter Sales*.
g. In the List field, select Application Roles.
h. Click Search.

i. Add Sales Associates Role, Sales Managers Role, and Sales Supervisors Role to
Selected Members.
j. Set Permission to Granted and click OK to close the Add Application Roles, Catalog
Groups and Users dialog box.
k. Click OK to close the Privilege dialog box. The application roles and their members
now have access to Answers.
l. Repeat the steps to give all three application roles access to the Sample Sales subject
area.
m. Sign out of Oracle BI.
3. Verify that the new application roles are now visible in Oracle BI and that privileges have
been applied.
a. Sign in to Oracle BI as mlombardo with password mlombardo1.
b. In the upper-right corner, select mlombardo > My Account.
c. Click the Roles and Catalog Groups tab.
d. Verify that the new application roles are visible.

Michele Lombardo is a member of the Sales Managers group, which is a member of
the Sales Managers Role application role. Michele Lombardo is also a member of the
Sales Supervisors group, which is a member of the Sales Supervisors Role application
role. Because both of these roles are members of Sales Associates Role, she is also a
member of that role. By default, all BI users are also members of the default application
roles Authenticated User and BIConsumer. All users who are able to log in are given a
basic level of operational permissions conferred by the built-in Authenticated User
application role.
e. Click OK to close the My Account dialog box.
f. Sign out and sign back in as hmayes with password helenmayes1.
g. Select hmayes > My Account.
h. Click Roles and Catalog Groups.
i. Verify that Helen Mayes is a member of the Sales Associates Role application role.
Helen Mayes is a member of the Sales Associates group, which is a member of the
Sales Associates Role application role. Because the Sales Associates Role application
role is the highest role in the hierarchy, she is not a member of the other two
application roles in the hierarchy.
j. Click OK to close the My Account dialog box.

k. Sign out of Oracle BI. Application roles serve a variety of purposes in both
development and production environments. In a development environment, developers
can be granted one or more of the roles. One approach is to build roles that will
eventually be used in production, and then map developers to those roles for
administering, building, and testing the development environment. As you will see in
the next practice, you also use the logical application roles to secure access to
repository objects and data. Therefore, application roles can be used to control access
to both objects and functionality in the product. The value of using application roles
comes from the fact that you can move the system that you have built between
environments without having to rewire all the security. For example, you would not
have to change security settings in your presentation catalog or repository. You can
just remap your application roles to the target environment.

Practice 19-4: Setting Up Object Permissions
Overview
In this practice, you set up object permissions in the repository.
Assumptions
You can set up object permissions in your repository to control access to Presentation layer and
Business Model and Mapping layer objects. You set object permissions using the Administration
Tool. There are two approaches to setting object permissions: you can set permissions for
particular users or application roles in the Identity Manager, or you can set permissions for
individual objects in the Presentation layer. In this practice, you use both approaches. Setting up
object permissions for individual users or application roles is useful when you want to define

permissions for a large set of objects at one time. Although it is possible to set up object
permissions for individual users, the recommended practice is to set up object permissions for
particular application roles rather than for individual users.
Time
30 minutes
Tasks
1. Add the application roles to the repository.
a. Open the BISAMPLE repository in offline mode with password welcome1.
b. Select Manage > Identity to open Identity Manager.
c. Click the Application Roles tab.
d. Select Action > New > Application Role to open the Application Role dialog box.
e. Enter SalesManagersRole as the name and Sales Managers Role as the display
name.
f. Click OK to close the Application Role dialog box. The SalesManagersRole
application role is displayed in the list.
g. Repeat the steps to add SalesSupervisorsRole with Sales Supervisors Role as the
display name, and SalesAssociatesRole with Sales Associates Role as the display
name.

h. Close Identity Manager.
j. Check global consistency. Fix any errors or warnings before proceeding.
2. Synchronize the repository application roles and users with the policy store.
b. Open the repository in online mode using welcome1 as the password. It is strongly
recommended that you perform data access security tasks in the Administration Tool in
online mode. If you must apply data access security in offline mode, be aware that
users and application roles do not appear in the Administration Tool in offline mode
unless you have first modified them in the Administration Tool in online mode.
c. Select Manage > Identity.

d. Select Identity Management > BI Repository in the left pane.
e. Select Action > Set Online User Filter.
f. Enter an asterisk in the field and click OK.
g. On the Users tab, verify that the users you created in the identity store are now visible.
h. Click the Application Roles tab and verify that the application roles you created are
displayed.

i. Right-click each of the Sales* application roles you created earlier and select Check
Consistency to confirm that the application roles are synchronized with the policy
store. You should not receive any errors or warnings.
3. Set permissions for a repository object.
a. Double-click the SalesAssociatesRole application role and check out objects when
prompted.
b. Notice that the users assigned to this role are visible as members.

c. Click Permissions to open the Application Role permissions dialog box and check out
objects if prompted.
d. Select the Object Permissions tab.
e. Click the Name field to open the Browse dialog box.
f. In the left pane, verify that Presentation is selected at the bottom of the left pane.
g. Expand Sample Sales.

h. Select the Customers presentation table and then click Select. You can also double-
click the object to select it.

i. The Customers presentation table is added to the Name field in the Application Role
permissions dialog box.
j. Click No Access.
k. Click OK to close the Application Role permissions dialog box.

l. Click Check Out.
m. Click OK in the Application Role dialog box.
n. Close Identity Manager.
o. In the Presentation layer, expand Sample Sales.
p. Double-click the Customers presentation table.
q. On the General tab, click Permissions to open the Permissions dialog box.
r. Set the permission for Authenticated User to No Access.

s. Click OK to close the Permissions dialog box.
t. Click OK to close the Presentation Table dialog box.
u. Right-click the Customers presentation table and select Permission Report. Your
report should look similar to the screenshot. Users assigned to SalesAssociatesRole
application role do not have access to the Customers presentation table.
v. Click Cancel.
w. Check in changes.
x. Check consistency. You should see the warning The object "Sample
Sales".."Customers" is not available for query by any user due to permission
setup. Fix any other errors or warnings before proceeding. You can ignore the warning
User "weblogic" is not defined in the Enterprise Manager.
y. Close the Consistency Check Manager.
z. Save the repository.
aa. Close the repository.
bb. Leave the Administration Tool open.

4. Check your work in Analysis Editor.
b. Select Administration > Reload Files and Metadata. Only users with administrative
privileges can reload server metadata.
c. Sign out of Oracle BI.
d. Sign in to Oracle BI as hmayes with password helenmayes1.
e. Select hmayes > My Account.
f. Select Application Roles.
g. Helen Mayes is a member of the following application roles:
Authenticated User
BI Consumer
Sales Associates Role

Recall that you restricted access to the Customer presentation table for the
SalesAssociatesRole and Authenticated User application roles. Given that, do you
expect that Helen Mayes will have access to the Customer presentation table?
Continue with the next step to verify your answer.
h. Click OK to close the My Account dialog box.
i. Click New > Analysis.
j. Select the Sample Sales subject area.
k. Notice that the Customers table is not visible.
l. Sign out of Oracle BI and log back in as mlombardo with password mlombardo1.
m. Select mlombardo > My Account.
n. Click Application Roles.
o. Michele Lombardo is a member of the Sales Associates Role application role as well
as the Sales Managers Role and Sales Supervisors Role application roles, in addition
to the BI Consumer and Authenticated User application roles.

Recall that you restricted access to the Customers presentation table for the Sales
Associates Role application role, but not for Sales Managers Role or Sales Supervisors
Role. Given that, will Michele Lombardo have access to the Customers presentation
table? Continue with the next step to verify your answer.
p. Click OK to close the My Account dialog box.
q. Select New > Analysis.
r. Select the Sample Sales subject area.
s. Notice that the Customers table is not visible.
Explanation: Michele Lombardo is a member of the Sales Managers Role and Sales
Supervisors Role application roles, which are members of the Sales Associates Role
application role. When you restricted access for Sales Associates Role, the
permissions were inherited by the other two roles. In the next set of steps, you give
Sales Supervisors Role explicit access to the Customers table.
t. Sign out of Oracle BI.
5. Set permissions to give members of SalesSupervisorsRole explicit access to the
Customers presentation table.
a. Return to the Administration Tool and open the BISAMPLE repository in online mode
with password welcome1.
b. Open Identity Manager.
d. Double-click SalesSupervisorsRole to open the Application Role dialog box. Check
out objects when prompted.
e. Click Permissions.
f. Click the Object Permissions tab.
g. Click the Name field to open the Browse dialog box.
h. Expand Sample Sales in the left pane.

i. Double-click the Customers presentation table to add it to the User/Application Role
Permissions dialog box.
j. Verify that the permission is set to Read (this is the default).
k. Click OK to close the Application Role permissions dialog box.

l. Click Check Out.
m. Click OK to close the Application Role dialog box.
n. Close Identity Manager.

o. In the Presentation layer, expand Sample Sales.
p. Right-click Customers and select Permission Report. Verify that Sales Supervisors
Role has explicit Read access for the Customers table. Your report should look similar
q. Click Cancel.
r. Check in changes.
s. Check consistency. Fix any errors or warnings before proceeding. You can ignore the
warning User "weblogic" is not defined in the Enterprise Manager.
t. Close the Consistency Check Manager.
u. Save the repository.
v. Close the repository.
w. Leave the Administration Tool open.
b. Select Administration > Reload Files and Metadata.
c. Sign out and then sign back in as mlombardo with password mlombardo1.
d. Click New > Analysis.
e. Select the Sample Sales subject area.

f. Verify that the Customers table is visible. In this example, Michele Lombardo is a
member of both the Sales Associates Role and Sales Supervisors Role application
roles. You restricted access to the Customers presentation table for Sales Associates
Role, but gave explicit read access for Sales Supervisors Role. Permissions granted
explicitly to an application role take precedence over any permissions granted through
other application roles.

g. Sign out of Oracle BI.
7. Set conflicting permissions for application roles at the same level in a hierarchy.
a. Return to the Administration Tool and open the BISAMPLE repository in online mode.
b. In the Sample Sales subject area, double-click the Customers presentation table to
open the Presentation Table dialog box.
c. Click Check Out.
d. On the General tab, click Permissions to open the Permissions dialog box.
e. If necessary, select Show all users/application roles.
f. Select No Access for the SalesManagersRole application role.
g. Deselect Show all users/application roles. Permissions for the Customers
presentation table should look similar to the following screenshot:
h. Click OK to close the Permissions dialog box.

i. Click Yes when prompted to check out objects.
j. Click OK to close the Presentation Table dialog box.
k. Right-click Customers and select Permission Report. Verify that SalesManagersRole
has No Access for the Customers table. Your report should look similar to the following
screenshot:

Michele Lombardo now has conflicting permissions across two application roles.
SalesSupervisorsRole gives her read access to the Customers table.
SalesManagersRole gives her no access to the Customers table. Given that, will
Michele Lombardo have access to the Customer presentation table? Continue with the
next steps to verify your answer.
l. Click Cancel.
m. Check in changes.
n. Check consistency. Fix any errors or warnings before proceeding.
p. Close the repository.
q. Leave the Administration Tool open.
a. Sign in to Oracle BI as weblogic with password welcome1 and reload server
metadata.
b. Sign out and then sign back in as mlombardo with password mlombardo1.
c. Click New > Analysis.
e. Verify that the Customers table is still visible for Michele Lombardo. If multiple
application roles act on an object at the same level, but with conflicting security
attributes, the user or application role is granted the least restrictive security attribute.
In this case, the least restrictive security attribute is read access for the Customers
table.
f. Sign out of Oracle BI.

Practice 19-5: Setting Row-Level Security (Data Filters)
Overview
In this practice, you set row-level security (data filters) in the repository.
Assumptions
Data filters provide a way to enforce row-level security rules in the repository. Data filters are set
up in the repository by using the Administration Tool and are applied for a particular user or
application role.
Data filters can be set for objects in both the Business Model and Mapping layer and the
Presentation layer. Applying a filter on a logical object will affect all Presentation layer objects
that use the object. If you set a filter on a Presentation layer object, it is applied in addition to

any filters that might be set on the underlying logical objects. It is a best practice to set up data
filters for particular application roles rather than for individual users.
In this practice, you set a filter on the Customers presentation table so that only specific
customer data is visible for users assigned to the Sales Supervisors Role application role.
Time
15 minutes
Tasks
1. Set a data filter for the Customer presentation table.
d. Double-click SalesSupervisorsRole to open the Application Role dialog box.
e. Click Check Out.
f. Click Permissions to open the Application Role permissions dialog box.
g. Click the Data Filters tab.
h. Click the Name field to open the Browse dialog box.
i. Select the Sample Sales > Customers presentation table to return to the Application
Role permissions dialog box.
j. Click the Data Filter field.
k. Click the Edit Expression icon to open the Expression Builder.

l. Build the following expression. This sets a filter on the Customers presentation table so
that only specific customer data is visible for users assigned to the
SalesSupervisorsRole application role:
"Sample Apps"."D3 Customers"."Name" = 'Alexis Smith'
OR
"Sample Apps"."D3 Customers"."Name" = 'Betsy Speer'
OR
"Sample Apps"."D3 Customers"."Name" = 'Carla Edison'
m. Click OK to close Expression Builder to return to the Application Role dialog box. The
expression is added to the Data Filter field. The following screenshot shows only a
partial view.

n. Click OK to close the Application Role Permissions dialog box.
o. Click OK to close the Application Role dialog box.
p. Close Identity Manager.
q. Check in changes.
r. Check consistency.
s. Save the repository.
metadata.
b. Grant the following privileges to Sales Associates Role:
View Compound Layout
View Table
View Title
c. Sign out and sign back as mlombardo with password mlombardo1.
d. Select the Sample Sales subject area and create the following analysis:
Customers.Name
Base Facts.Revenue
e. Click Results.

f. Verify that only the customer data specified in the data filter is visible to Michele
Lombardo, who is assigned to the Sales Supervisors Role application role.
g. Sign out of Oracle BI.

Practice 19-6: Setting Query Limits and Timing Restrictions
Overview
In this practice, you manage the query environment by setting query limits in the repository.
Assumptions
You can manage the query environment by setting query limits (governors) in the repository for
users or application roles. You may want to prevent queries from consuming too many
resources, by limiting how long a query can run and how many rows a query can retrieve. You
also may want to regulate when individual users can query databases to prevent users from
querying when system resources are tied up with batch reporting, table updates, or other
production tasks. In this practice, you set the maximum rows of any query to five rows, the

maximum time of any query to 1 minute, and restrict access to a database on Sunday from
12:00 AM to 7:00 AM.
It is a best practice to set query limits for particular application roles rather than for individual
users.
Time
20 minutes
Tasks
1. Set query limits for the Sales Supervisors Role application role to disallow queries that may
consume too many system resources.
d. Double-click SalesSupervisorsRole to open the Application Role dialog box.
e. Click Check Out.
f. Click Permissions.
g. Click the Query Limits tab.
h. Locate the ORCL database and change its Max Rows value to 5. This specifies the
maximum number of rows that each query can retrieve from the ORCL database for
members of the SalesSupervisorsRole application role.
i. In the Status Max Rows column, select Enable from the drop-down list.

2. Restrict the time period for which users can access specified repository resources.
a. Click the ellipsis button in the Restrict column of the ORCL database.
b. Highlight the blocks from Sunday at midnight to 7 AM.
Hint: Click the first box and drag to the last block.
c. Click the Disallow button.

If a time period is not highlighted, the access rights remain unchanged. If access is
allowed or disallowed explicitly to one or more groups, the user is granted the least
restrictive access for the time periods that are defined.
d. Click OK to close the Restrictions dialog box.
e. Click OK to close the Application Role permissions dialog box.
f. Click OK to close the Application Role dialog box.
g. Close Identity Manager.
h. Check in changes.
i. Check consistency.
j. Save the repository.
l. Leave the Administration Tool open.
metadata.
b. Sign out and sign back in to Oracle BI as mlombardo with password mlombardo1.
c. Select the Sample Sales subject area and create the following analysis:
Time.Per Name Month
Base Facts.Revenue
d. Click Results.

e. Expand Error Details to view message. The error message states that the maximum
row limit is exceeded.

f. Click the Criteria tab.
g. Set the filter to is ranked first 5 for the Per Name Month column and click Results.

h. Verify that results are now returned.
Because of the filter, the query returned only five rows, which does not exceed the

maximum query limit.
4. Deactivate the restrictions you set.
a. Return to the Administration Tool and open BISAMPLE repository in online mode.
d. Double-click the SalesSupervisorsRole application role.
e. Click Check Out.
f. Click the Permissions button.
g. Click the Query Limits tab.
h. In the ORCL row, set Max Rows to 100000 and select Ignore for Status Max Rows.
i. Click Restrict and clear the restriction.
j. Click OK.
k. Close all dialog boxes and Identity Manager.
l. Expand Sample Sales subject area in the Presentation layer.
m. Double-click the Customers presentation table.
n. Click Check Out.
o. Return the permissions you changed to Default.

p. Change all permissions to default and set Authenticated User to Read.

q. Click OK.
r. Click Check Out.
s. Click OK to close the Presentation Table dialog box.
t. Check in the changes.
u. Check consistency.
v. Save the repository.
w. Close the repository.
x. Leave the Administration Tool open.

Cache Management

Practices Overview
In these practices, you will enable query caching and inspect cache entries by using Cache
Manager in the Administration Tool.
312 Practices for Lesson 20: Cache Management

Practice 20-1: Enabling Query Caching
Overview
In this practice, you enable query caching and inspect cache entries using Cache Manager.
Assumptions
You use Oracle Enterprise Manager to enable query caching and then use Cache Manager in
the Administration Tool to inspect cache entries and analyze cache hits and nonhits.
Time
25 minutes

Tasks
1. Set logging levels for users to allow you to track queries in query logs.
a. Open the BISAMPLE repository in online mode with password welcome1.
b. Select Manage > Identity to open Identity Manager.
c. In the left pane, select Identity Management > BI Repository.
d. Click the Users tab.
e. Double-click mlombardo to open the User properties dialog box.
f. Check out objects when prompted.
g. Set the logging level to 2 and click OK.
h. Click Check Out.
i. Repeat to set the logging level to 2 for hmayes.
j. Close Identity Manager.
k. Check in the changes.
l. Check global consistency. You can ignore the warning messages that weblogic,
mlombardo, and hmayes are not defined in Enterprise Manager.
m. Save the repository.
n. Close the repository.
o. Leave the Administration Tool open.
2. Enable query caching.
a. Enter http://localhost:9500/em in a browser to open Enterprise Manager and log in as
b. Select Target Navigation > Business Intelligence > biinstance.
c. Click the Configuration tab.
d. Click the Performance subtab.
e. Select Lock and Edit (in the upper-right corner).
Practices for Lesson 20: Cache Management 313

f. Select Cache Enabled.
g. Click Apply.

h. Select Lock and Edit > Activate Changes.

i. Allow Activate Changes processing to complete. You should receive the following
confirmation message:
All Changes have been activated. The edit session lock has been released.
j. Click the Availability tab and then the Processes subtab.

k. Select BI Servers.
l. Click Restart Selected. You must restart BI Server for the changes to take effect.
m. Click Yes to confirm the restart.
n. You should receive a confirmation message that the component restarted successfully.
o. Log out of Enterprise Manager.
3. Create and run an analysis.
a. Sign in to Oracle BI as mlombardo with password mlombardo1.
b. Create the following analysis in the Sample Sales subject area:
Products.Brand
Products.Line of Business
Products.Type

c. Click Results.

d. Sign out of Oracle BI and click Leave Page when prompted.
4. Open the Cache Manager and verify that the query is listed as a cache entry.
a. Open the BISAMPLE repository in online mode as weblogic/welcome1.
b. Select Manage > Cache to open Cache Manager.
c. In the left pane, expand ssi > Sample Apps. By selecting the appropriate leaf of the
tree in the left pane, you can limit the cache entries that appear in the right pane. The
Cache Manager allows you to view cache entries by repository, subject area, and user.

d. Click mlombardo in the left pane. All cache entries associated with this user appear in
the right pane.

e. Select the cache entry (there should only be one).
f. Select SQL > Show. By inspecting the SQL you can verify that this is the cache entry
for the query that you just executed.
g. Click Close to close the SQL.

h. With this entry still selected, scroll to the right to view the columns. Notice that values
for the Created and Last used columns are not the same. The Created column shows
the date and time that the cache entry was created. Write down this date and time. The
Last used column shows that the cache entry has never been used. This indicates that
the results for this query were returned directly from the database and not derived from
an existing query.
i. Leave the Cache Manager open.
j. Leave the BISAMPLE repository open in online mode.
5. Inspect the cache file and ensure that the results of the query were stored as a file in the
cache directory. The modified time of the file should coincide with the time that you
originally created the request (the time you recorded above).
a. Navigate to D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\servers

\obis1\cache\resultscache. The file in this directory is the cache file that resulted from
your query.
b. Do not open the file, but verify that the modified time of this file is the same as the time
that you created the request.
6. Create and run the same analysis logged in as a different user.
a. Sign in to Oracle BI as hmayes with password helenmayes1.
b. Create the same analysis in the Sample Sales subject area that you created earlier:
Products.Brand
Product.Line of Business
Products.Type
c. Click Results.
7. In response to hmayes’ request, determine whether a new cache entry was made in the
Cache Manager and filed in the Cache directory. If a new entry was made in the Cache
Manager and filed in the directory, then an existing cache was not used to satisfy this
request.
a. Return to the BISAMPLE repository open in online mode.
b. Select Action > Refresh in the Cache Manager.
c. Notice that no cache entry is listed with hmayes as the user. Notice, however, that the
Last used date for mlombardo’s cache entry has changed.

The query executed by hmayes was fulfilled by the cache entry that resulted from the
earlier query by mlombardo. Because the request by hmayes was identical to the
query in the cache, the server used the cache (cache hit) instead of processing against
the database. The Last Used date is updated to reflect this.
d. Leave Cache Manager open.
e. Leave the repository open in online mode.
f. Navigate to D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\servers
\obis1\cache. Notice that no new cache file is created as a result of the request by
hmayes. This is because the request by hmayes was satisfied by an existing cache
entry.
8. Create and run a new analysis to illustrate a noncache hit using a dimension-only query. In
all of the steps that follow, be sure to create a new analysis when instructed to ensure

correct cache results.
a. Return to Analysis Editor where you should still be logged in as hmayes with password
helenmayes1.
b. Create the following new analysis in the Sample Sales subject area:
Products.Brand
Products.Type
Notice that this is a dimension-only query, meaning that no fact or measure is included
in the query. Notice also that this query contains a subset of the columns in the
previous query.
c. Click Results.
d. Leave Oracle BI open.

9. Determine whether a new cache entry was made in the Cache Manager.
a. Return to the BISAMPLE repository open in online mode.
b. Select Action > Refresh in the Cache Manager.
c. Select ssi > Sample Apps in the left pane.
d. Notice the new cache entry listed for hmayes. The presence of a new entry indicates
that there was no cache hit against the original query.

Explanation: If a query is dimension only, meaning that no fact or measure is included
in the query, only an exact match of the projection columns of the cached query will hit
the cache. This behavior prevents false positives when there are multiple logical
sources for a dimension table. In this example, only two columns, Brand and Type,
matched the columns of the cached query, which included three columns: Brand, Type
and Prod Dsc.
e. Leave Cache Manager open.
f. Leave the BISAMPLE repository open in online mode.

10. Create and run a new analysis.
a. Return to Analysis Editor and create and run the following new analysis as hmayes in
the Sample Sales subject area:
Customers.Country Name
Products.Type
Base Facts.Revenue
Base Facts.Units

b. Refresh the Cache Manager and verify that a new cache entry is created for this
analysis, indicating that there was no cache hit.

c. Return to Analysis Editor and create and run the following new analysis. Notice that
this analysis contains all the columns from the previous query, plus one additional table
and column, Time and Per Name Year.
Time.Per Name Year
Products.Type
Base Facts.Revenue
Base Facts.Units

d. Return to Cache Manager and select Action > Refresh. Notice that a new cache entry
is listed for hmayes, indicating there was no cache hit against the previous query.

Explanation: The set of logical tables must match. To qualify as a cache hit, all
incoming queries must have the same set of logical tables as the cache entry. In this
example, the Time logical table did not exist in the cached query.
e. Return to Analysis Editor and create and run the following new analysis as hmayes in
the Sample Sales subject area:
Products.Type
Calculated Facts.Actual Unit Price

f. Refresh Cache Manager and notice that the “Last used” column is updated for the
second query by hmayes, indicating a cache hit.

Explanation: Columns in the SELECT list can be composed of expressions on the
columns of the cached queries. Oracle BI Server can calculate expressions on cached
results to answer the new query, but all the columns have to be in the cached result. In
this example, Actual Unit Price (revenue/units) can be computed from Revenue and
Units in the cached query that was hit.
g. Return to Analysis Editor and create and run the following new analysis and filter in the
Sample Sales subject area where Revenue is less than or equal to ten thousand:
Products.Type
Base Facts.Revenue
Base Facts.Units
Revenue is less than or equal to 10000

h. Refresh Cache Manager and watch the “Last used” column for the second hmayes
query. The column is updated, indicating a cache hit.

Explanation: The WHERE clause constraints are a subset of the cached results. In this
example, the WHERE clause contains a logical subset of a literal comparison.
i. Return to Analysis Editor and create and run the following new analysis, which
removes the filter and adds a new column, Name, to the previous query:
Customers.Name
Products.Type
Base Facts.Revenue
Base Facts.Units

j. Refresh Cache Manager. Notice that a new cache entry is created.

Explanation: All of the columns in the SELECT list of a new query have to exist in the
cached query in order to qualify for a cache hit, or they must be able to be calculated
from the columns in the query. In this example, the Name column did not exist in the
cached query.
k. Sign out of Oracle BI.

l. Leave Cache Manager and the repository open for the next practice.
m. Navigate to D:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\servers
\obis1\cache and verify there are now files for each cache entry.

Practice 20-2: Modifying Cache Parameters
Overview
In this practice, you use Oracle Enterprise Manager and the NQSConfig.ini file to modify
cache parameters.
Assumptions
You use the Cache Manager to inspect the cache parameters. Then you modify the number of
rows per cache, as well as the number of cache entries allowed. In addition to modifying cache
parameters, you make some tables noncacheable.
Time

20 minutes
Tasks
1. Display global cache information in the Cache Manager.
a. In the Cache Manager, select Action > Show Info to display global cache information.
Your results should look similar to the screenshot:
“Number of entries currently in cache” displays the current number of entries in your
global cache. These entries may relate to multiple repositories.
“Maximum allowable number of entries in cache” displays the maximum number of

entries that can be in the cache.
“Amount of space still available for cache storage use” displays the amount of space, in
megabytes, still available for cache storage.

“Amount of space used on disks containing cache related files” displays the total
amount of space, in megabytes, used on the disk containing cache-related files (not
just space used for the cache-related files). In this case, the amount of used space is
less than 1 MB.
“Maximum allowable number of rows per cache entry result set” displays the maximum
number of rows allowed for each cache entry's result set. This number is set in the
MAX_ROWS_PER_CACHE_ENTRY parameter in the NQSConfig.INI file.
“Number of queries satisfied from cache since startup of Oracle BI Server” displays the
number of cache hits since the last time the Oracle BI Server was started.
“Number of queries not satisfied from cache since startup of Oracle BI Server” displays

the number of cache misses since the last time the Oracle BI Server was started.
b. Click Close.
c. Close the Cache Manager.
d. Close the repository.
2. Use Enterprise Manager to set query cache parameters. You can use Enterprise Manager
to set the maximum number of cache entries in the query cache, as well as the maximum
size for a single cache entry.
a. Return to Enterprise Manager and sign in as weblogic with password welcome1.
b. Select Target Navigation > Business Intelligence > biinstance.
c. Click the Configuration tab.
d. Click the Performance sub tab.
e. Select Lock and Edit.
f. Change Maximum cache entries from 1000 to 10000.
g. Apply and activate your changes, but do not restart Oracle BI Server to apply recent
changes at this time.
h. Leave Enterprise Manager open.

3. Use NQSConfig.ini to view and manually edit additional query cache parameters.
a. Navigate to
biconfig\OBIS.
b. Before making changes to NQSConfig.ini, make a copy of the file and paste it in the
same directory.
c. Open NQSConfig.ini.
d. Navigate to the CACHE section.
e. Make the following modifications:
f. Modify the MAX_ROWS_PER_CACHE_ENTRY parameter as follows:
MAX_ROWS_PER_CACHE_ENTRY = 5000
This parameter controls the maximum number of rows for any cache entry. Limiting the

number of rows is a useful way to avoid using up the cache space with runaway
queries that return large numbers of rows. If the number of rows a query returns is
greater than the value specified in the MAX_ROWS_PER_CACHE_ENTRY parameter, the
query is not cached.
g. Notice the DATA_STORAGE_PATHS parameter. This parameter specifies one or more
directories for query cache storage, and the maximum size for each storage directory.
These directories are used to store the cached query results and are accessed when a
cache hit occurs.
h. Notice that the MAX_CACHE_ENTRIES parameter is changed to 10000. Changes made
to cache configuration in Enterprise Manager are written to this file.
i. Save and close NQSConfig.INI.
j. Return to Enterprise Manager and restart Oracle BI Server.
4. Validate your changes in the Administration Tool.
a. Return to the Administration Tool and open the repository in online mode.
b. Select Manage > Cache. The cache entries are gone because you restarted Oracle BI
Server.

c. Select Action > Show Info and confirm that changes are applied. “Maximum allowable
number of entries in cache” should now equal 10000. “Maximum allowable number of
rows per cache entry result set” should now equal 5000. Your results should look
similar to the following screenshot:

d. Click Close.
e. Close the Cache Manager.
5. Make some tables “noncacheable.” That is, if a request is made against them, there are no
cache entries.
a. In the Physical layer, expand ORCL > BISAMPLE and double-click the
SAMP_CUSTOMERS_D table to open the Physical Table dialog box.
b. Click Check Out.
d. Deselect the Cacheable check box.
e. Click OK.
f. Repeat this process for the SAMP_REVENUE_F table.
g. Check in the changes and save the repository. You do not need to check consistency.
h. Leave the repository open.
6. Test your work.
a. Log in to Oracle BI as mlombardo with password mlombardo1.
b. Create the following analysis in the Sample Sales subject area:
Customers.Name
Base Facts.Revenue
c. Click Results.
d. Leave Analysis Editor open.
e. Return to the repository open in online mode in the Administration Tool and open the
Cache Manager.

f. Verify that you do not see a cache entry for the analysis you just executed.
Hint: Right-click inside the white space for the cache entries and select Show Info.
g. Close the Cache Manager.
7. Make the tables cacheable.
a. In the Physical layer, double-click the SAMP_CUSTOMERS_D table.
b. Click Check Out.
c. Select the General tab.
d. Select the Cacheable check box.
e. Click OK.
f. Repeat this process for the SAMP_REVENUE_F table.
g. Check in the changes and save the repository. You do not need to check for

consistency.
h. Leave the repository open.
8. Test your work.
a. Return to Analysis Editor.
b. Sign out and sign back in as weblogic with password welcome1.
c. Reload Files and Metadata.
d. Create and run a new analysis in the Sample Sales subject area using the same
columns:
Customers.Name
Base Facts.Revenue
e. Return to the repository open in online mode in the Administration Tool and open the
Cache Manager.
f. Verify that there is a new cache entry for the analysis executed by weblogic. (If you
do not see the cache entry, try closing and reopening the repository in online mode.)

g. Right-click the new entry and select “Show SQL” to verify that it is the expected query:

h. Click Close.
9. Alter how the Cache Manager displays information.
a. Select Edit > Options.
b. Notice that you can deselect columns and use the Up and Down buttons to change the
column order.
c. Click Cancel.
10. Purge the cache entry.
a. Right-click the cache entry for weblogic and select Purge, or select Edit > Purge. In
this pane, it is possible to purge a single cache entry, multiple entries, or all entries.
b. Click OK to confirm the cache purge.
c. Close the Cache Manager.

d. Leave the repository open in online mode.

Practice 20-3: Seeding the Cache
Overview
In this practice, you create an analysis and an agent to seed the Oracle BI Server cache.
Assumptions
You have identified requests that are used frequently by sales representatives. To improve
performance, you want to seed the cache with this data. In this practice, you create and save a
query to populate the cache, and then create an agent to seed the cache. During this process,
you use a programmatic ODBC call to purge the cache.
Time

15 minutes
Tasks
1. Create a query to seed the cache.
a. Return to Analysis Editor where you should still be signed in as weblogic with
password welcome1.
b. Create the following new analysis in the Sample Sales subject area:
Customers.Name
Base Facts.Revenue
c. Save the analysis as Cache Seed in My Folders.
2. Use an ODBC procedure to purge the cache before seeding the cache. The Oracle BI
Server provides ODBC-extension functions for the Oracle BI Administrator to use for
purging cache entries. Some of these functions are particularly useful for embedding in an
Extract, Transform, and Load (ETL) task. For example, after a nightly ETL is performed, the
entire Oracle BI Server cache can be purged. If only the fact table was modified, only cache
related to that table can be purged. In some cases, you may need to purge the cache
entries associated with a specific database.
3. Note: Only Oracle BI Administrators have the right to purge the cache. Therefore, scripts
that call these ODBC-extension functions must run under an Oracle BI Administrator login
ID. Also, this is not a required step for seeding the cache. It is provided here for training
purposes only.
a. Click Administration.
b. Under Maintenance and Troubleshooting, click Issue SQL to issue SQL directly to the
Oracle BI Server.

c. Enter the following command:
Call SAPurgeAllCache()

d. Click Issue SQL.
e. Verify that the operation succeeded.
f. Click Home to navigate to the Oracle BI Home page.

g. Return to the BISAMPLE repository, which should still be open in online mode.
h. Open the Cache Manager and verify that there are no cache entries.

i. Leave the Cache Manager open.
4. Create and schedule an Agent to seed the cache with the saved query. It is common to
schedule an Agent to run immediately after a daily load to reseed the cache. For example,
the data warehouse is loaded at midnight and the cache is purged during or after the load,
then the cache is reseeded by an Agent. In this example, you run the Agent immediately.
a. Return to the Oracle BI Home page.
b. Under Actionable Intelligence, click Agent.
c. Click the Schedule tab.
d. Set Frequency to Once.

e. Click the Delivery Content tab.
f. Enter Cache Seed in the Subject field.
g. Verify that Content is set to Analysis.
h. Click Browse.

i. Select the Cache Seed analysis under My Folders and click OK. The request is added
to the Agent.

.
j. Click the Destinations tab.

k. Select the check box for Oracle BI Server Cache (For seeding cache).
l. Deselect all other check boxes.
m. Save the Agent in My Folders as Cache Seed Agent.

n. Click Run Agent Now.

o. Click OK when you receive the “Agent Successful” message.

5. Check your work.
a. Return to the Administration Tool. The BISAMPLE repository should still be open in
online mode.
b. In the Cache Manager, select Action > Refresh.
c. Ensure that there is an entry in the cache for the weblogic user. Right-click the entry
and select Show SQL to verify that it is the expected query.
You have successfully seeded the cache using an Agent. The only difference between
cache seeding agents and other agents is that they clear the previous cache
automatically and do not appear on the dashboard as Alerts. Notice that cache-seeding
agents only purge exact match queries, so stale data may still exist. Your caching
strategy should always include cache purging, because agent queries do not address
ad hoc queries or drills.
d. Click Close to close the SQL window.
e. Close Cache Manager.

f. Close the repository.
g. Leave the Administration Tool open.

Setting Up and Using the
Multiuser Development
Environment
Practices Overview
In these practices, you set up and use an Oracle BI multiuser development environment.
340 Practices for Lesson 21: Setting Up and Using the Multiuser Development Environment
Practice 21-1: Setting Up a Multiuser Development Environment
Overview
In this practice, you set up a multiuser development environment to support two developers.
Assumptions
In Oracle Business Intelligence (BI), multiuser development facilitates the development of
application metadata in enterprise-scale deployments. Application metadata is stored in a
centralized metadata repository (RPD) file. The Administration Tool is used to work with these
repositories. In this practice, you set up the Oracle BI multiuser development environment. This
includes defining projects and setting up the multiuser development directory.

Time
15 minutes
Tasks
1. Verify that only one user at a time can modify a repository before you set up the multiuser
development environment.
a. Return to the Administration Tool and open the BISAMPLE repository in offline mode.
b. Double-click the Administration Tool shortcut on the Desktop to open a second
instance of the Oracle BI Administration Tool.
c. Select File > Open > Offline.
d. Select the BISAMPLE repository.
e. Click Open. Notice that you can open the file only as read-only. This is because a
multiuser development has not been set up, so only one user can edit the repository at
a time.
f. Click No.
g. Select File > Exit to close this second instance of the Oracle BI Administration Tool.
Practices for Lesson 21: Setting Up and Using the Multiuser Development Environment 341
2. In this step, you create projects in the master repository. The primary reason to create
projects is to support multiuser development. During the development process, you can
split up the work between different teams within your company by extracting the metadata
into projects so that each project group can access a different part of the metadata.
Typically you create projects to contain all the subject areas in the repository, broken down
in a reasonable manner. In this practice, you create only two projects.
a. Return to the Administration Tool instance with the BISAMPLE repository open in
offline mode.
b. Select Manage > Projects. The Project Manager window is displayed.
c. Select Action > New Project.
d. Enter Sample Sales Fact Table Project as the name.
e. Expand Business Models in the left pane.

f. Expand Sample Apps.
g. Select F1 Revenue.
h. Click Add. Notice that a Business Models folder appears in the right pane.
i. Expand Business Models in the right pane. Notice that the Sample Apps business
model is automatically included in the project.
j. Expand Sample Apps in the right pane and notice that F1 Revenue also has been
included in this project.
k. Click OK to save the project and close the Project window.
3. Create a second project that contains the Sample Sales subject area. This project also
contains the F1 Revenue logical fact table. You are adding a second project to demonstrate
that it is possible for projects to overlap, and to demonstrate how to select from multiple
projects during project check out.
a. Select Action > New Project.
b. Enter Sample Sales Presentation Project as the name.
c. Expand Business Models in the left pane.
d. Expand Sample Apps in the left pane.
e. Double-click F1 Revenue to add it to the right pane. Notice that Business Models >
Sample Apps > F1 Revenue is added to the right pane.
f. Expand Presentation in the left pane.
g. Double-click Sample Sales to add it to the right pane. Notice that a Presentation folder

appears in the right pane.
h. Expand Presentation in the right pane. Notice that the Sample Sales subject area has
been added to the project.
i. Expand Sample Sales in the right pane and notice that the presentation tables have
been added to the project.
j. Click OK to save the project and close the Project window. Your Project Manager
should look like the following screenshot:
k. Select Action > Close to close the Project Manager.

l. Save your changes to the repository. It is not necessary to perform a global

consistency check.
m. Close the repository.
n. Leave the Administration Tool open.
4. Copy your master repository to a shared directory. This allows all the developers on the
development team to access the repository.
a. Open Windows Explorer.
b. Create a new folder on the C: drive, and name it multiuser.
c. Right-click multiuser and select Share with > Specific people to open the File
Sharing dialog box.
d. In the drop-down list, select Everyone.
e. Click Add.
f. Set the Permission Level to Read/Write for Everyone.
g. Click Share.
h. Click Done to close the File Sharing dialog box.
i. Copy BISAMPLE from D:\repository to C:\multiuser.
j. In the C:\multiuser folder, rename the BISAMPLE repository BISAMPLEMaster.
5. Set the multiuser directory in the Oracle BI Administration Tool to point to the shared
repository that you just created.
a. In the Oracle BI Administration Tool, select Tools > Options.
b. Click the Multiuser tab.
c. Click Browse next to the “Multiuser development directory” field.
d. Browse to C:\multiuser and click OK.
e. In the Full Name field, enter Administrator. Before checking out projects, each
developer must set up his or her Administration Tool to point to the multiuser
development directory on the network. The Administration Tool stores this path in a
hidden Windows registry setting on the workstation of the developer and uses it when

the developer checks out and checks in objects in the multiuser development directory.
When setting up the pointer, the developer can also complete this Full Name field.
Although the field is optional, it is recommended that the developer complete this field
to allow other developers to know who has locked the repository. In this training
environment, Administrator is used as the developer name for both developers
because it is not possible to demonstrate using multiple users on multiple machines in
this practice.
f. Click OK to close the Options dialog box.
g. Leave the Administration Tool open. You are ready to perform multiuser development.
Practice 21-2: Using a Multiuser Development Environment
Overview
In this practice, you check out, modify, and check in projects in a multiuser development
environment.
Assumptions
Two developers work in the Oracle BI multiuser development environment and modify the same
project simultaneously, including checking out and checking in projects, and merging metadata.
Time
25 minutes

Tasks
1. Connect to the shared repository and check out a project as the first developer.
a. In the Oracle BI Administration Tool, select File > Multi-User > Checkout. The
“Extract from the BISAMPLEMaster.rpd” dialog box opens.
b. Enter welcome1 as the repository password and click OK. Notice that the two projects
that you created are listed in the Browse dialog box.
c. Select Sample Sales Presentation Project.
d. Click OK. The “Create new subset repository” dialog box opens.
e. In the “File name” field, change the file name to dev1. The file name is arbitrary. Notice
that this repository file is being saved to the default repository directory
C:\obi_client12c\bi\bifoundation\server and not the shared repository directory you
created earlier. Also, notice that a copy of the shared master repository,
BISAMPLEMaster, has been temporarily copied to the default repository directory.

f. Click Save. The dev1.rpd repository is displayed with the subset of data from the
Sample Sales Presentation Project. Notice that it only contains the Sample Sales
subject area and the Sample Apps business model. The other subject areas and
business models from BISAMPLE.rpd are not part of the project.
g. Leave the dev1 repository open.
2. Review the files that were created or modified by the checkout process.
a. Using Windows Explorer, navigate to C:\multiuser. Notice that there are two new files:
BISAMPLEMaster.000 and BISAMPLEMaster.mhl.
b. Navigate to C:\obi_client12c\bi\bifoundation\server. Notice that there are two new
files:
dev1.rpd
originaldev1.rpd
The dev1.rpd.rpd file is a subset of the repository. It contains the Sample Sales
Presentation Project metadata. This is the file you will modify. The
originaldev1.rpd is the original repository file, which is used to track your changes
or revert to the original.
3. As a second developer, check out the same project by using a second instance of the
Oracle BI Administration Tool. This demonstrates that multiple users can work with the
same repository and the same project simultaneously.
a. Double-click the Administration Tool shortcut on the Desktop to open a new instance
of the Administration Tool.
b. Select File > Multiuser > Checkout.
c. The “Extract from BISAMPLEMaster.rpd” dialog box opens.
d. Enter welcome1 as the password and click OK. The Browse dialog box opens. Notice
that both projects are still shown. There is no indication that another developer has the
Sample Sales Presentation Project open. This is an intentional feature of the product.
Multiple developers can work on a single project, and changes are merged during the
check-in process.

e. Select Sample Sales Presentation Project.
f. Click OK to open the “Create new subset repository” window.
g. Enter dev2 as the file name.
h. Click Save. The dev2.rpd repository is displayed with the same subset of data from
the Sample Sales Presentation Project. Notice that it also contains only the Sample
Sales subject area and Sample Apps business model. Two developers are now
simultaneously working on the Sample Sales Presentation Project.
i. Navigate to C:\obi_client12c\bi\bifoundation\server and notice that the same set of
files has been added for the second developer: dev2.rpd and originaldev2.rpd.
Typically, each developer would see his or her own set of files on his or her own
development machine. Both sets of files for both developers are located in the same
multiuser directory because there is only one directory available in this training
environment.
4. Modify the project as the first developer.
a. Return to the Administration Tool that has dev1.rpd open. The repository name is
displayed in the title bar of the application.
b. In the Presentation layer, expand Sample Sales.
c. Rename the Customers presentation table to CustomersNew. This is an obvious
change that will be easy to track.
d. Save the repository and check global consistency.
e. Select File > Multiuser > Compare with Original. This action compares the working
extracted local repository to the original extracted repository. When this option is
selected, the “Compare repositories” dialog box opens and lists all the changes made
to the working extracted repository since you checked out the projects. This dialog box
identifies all of the objects in the dev1 repository that have been deleted or modified as
compared to the originaldev1 repository.

f. Click Cancel to close the “Compare repositories” dialog box.
5. Commit the local changes to the master repository.
a. Select File > Multiuser > Publish to Network. A Lock Information window is
displayed. The shared repository is locked until checkin is complete.
b. In the comment section, enter Changed the name of the Customers
presentation table in the Sample Sales subject area in the
Presentation layer.

c. Click OK. The Merge Repository Wizard opens. When there are any conflicts, the
Merge Repository Wizard opens and the Define Merge Strategy screen is displayed.
You then use the wizard to make merge decisions about whether to include or exclude
conflicting objects.
d. Notice that the CustomersNew presentation table is listed in the Conflicts section.
Select the CustomersNew listing to highlight it.
e. In the bottom-right corner of the Merge Repository Wizard, click the ellipsis button next
to the Differences field to view the details of which objects were modified in the Current
repository.

f. Click Cancel to close the details.
g. Notice that the bottom panes display the original dev1 repository (originaldev1.rpd),
the local dev1 repository (dev1.rpd), and a local version of the current master
repository (originaldev1.rpd). Notice that the differences between the projects are
displayed. In this case, the original and current repositories have a Customers
presentation table and the modified repository has a CustomersNew presentation
table. At this point, a decision must be made about how to proceed with the merge.
h. Under Conflicts, expand CustomersNew.
i. Choose Modified from the options. This chooses the modified repository over the
current repository, which means that the Customers table in the master repository will
be renamed to CustomersNew as it is in the local repository.
j. Click Finish.
k. The local copy of the master repository (dev1.rpd) is merged with the master repository
in the shared folder and then closed and deleted from

C:\obi_client12c\bi\bifoundation\server.
l. Leave this instance of the Administration Tool open.
6. View the multiuser history.
a. Select File > Multiuser > History. The BISAMPLEMaster.rpd Multi User History dialog
box opens with the history of multiuser changes displayed. Notice that Conflict
Resolutions is checked for Version 1.
b. Right-click the Version 1 entry and select View > Conflict Resolution.
c. Enter welcome1 as the password and click OK. The Merge Repository Wizard opens
and displays the merge strategy that was applied.
d. Click Cancel to close the Merge Repository Wizard.
e. Right-click the Version 1 entry and select View > Details. The event details for the
project are displayed:
f. Close the Version 1 details window.

g. In the Multi User History dialog box, select Action > Close.
7. Confirm that changes have been made to the shared master repository.
a. In the Administration Tool, select File > Open > Offline.
b. Navigate to C:/multiuser and select BISAMPLEMaster to open the shared master
repository.
c. Click Open.
d. Click Yes to acknowledge that it can only be opened as read-only.
e. Enter welcome1 as the password and click OK. The BISAMPLEMaster repository
opens.
f. Expand the Sample Sales subject area and confirm that the Customers presentation
table has been renamed to CustomersNew.

g. Close the repository.
h. Select File > Exit to close this instance of the Administration Tool.
8. Return to the instance of the Administration Tool for the second developer, refresh the local
project extract with any changes made to the master repository, make changes to the local
project extract, and then merge the latest changes with the master repository.
a. Return to the remaining instance of the Administration Tool with the dev2.rpd
repository open.
b. Confirm that the original Customers table is still visible in this local checked-out copy
of the repository.
c. Select File > Multiuser > Refresh Subset. This refreshes the local project extract with
any changes that were made to the master repository. The changes from the master
are merged with your local changes. You typically perform this task as an incremental
step during development before publishing your final changes at the end of your
development session. It is a best practice to refresh your local project extract frequently
so that conflicts during merge can be identified and dealt with on an incremental basis.
If too many changes are merged at one time, making the appropriate merge decisions
for conflicts can be confusing and error-prone. Because there is a conflict with the
master repository, the Merge Repository Wizard is displayed.
d. Expand the conflict for the Customers presentation table.
e. Select Current to accept the changes in the master repository.

f. Click Finish.
g. Click Yes when prompted to check global consistency.
h. Expand the Sample Sales presentation table and confirm that the Customers table is
renamed to CustomersNew, confirming that the change from the master repository is
merged with your local repository.
9. As the second developer, make a change to the local repository and publish it.
a. Double-click the Sample Sales subject area to open its properties dialog box.
b. Select the Presentation Tables tab.
c. Add a new presentation table name Product Facts and then click OK to close the
Subject Area dialog box.
d. In the Business Model and Mapping layer, expand the Sample Apps business model
and the F1 Revenue logical table.
e. Drag Product Total Revenue, Product Type Revenue and Product Share from the
F1 Revenue logical table to the Product Facts table in the Presentation layer.

f. Save the repository.
g. Check global consistency.
h. Select File > Multiuser > Publish to Network. This option publishes changes made to
the local project extract or the entire repository to the master repository. A Lock
Information window is displayed. The shared repository is locked until checkin is
complete.
i. In the comment section, enter Added the Product Facts presentation
table and measures to the Sample Sales subject area in the
Presentation layer.
j. Click OK. The local copy of the master repository (dev2.rpd) is merged with the master
repository in the shared folder and then closed and deleted from
C:\obi_client12c\bi\bifoundation\server. Why are there no conflicts and
why is the Merge Repository Wizard not displayed? Inserts (created objects) are
applied automatically. Because a subset of the master repository is being used as the
original repository, most objects in the master repository appear to be new. This would
result in many unnecessary prompts that the developer would have to manually
approve. Therefore, new objects are created without a prompt during a multiuser
development merge.
k. Open the BISAMPLEMaster repository in offline mode and confirm that the Product
Facts presentation table and measures have been added to the repository.

l. Close the repository.
m. Leave the Administration Tool open.
Performing a Patch Merge
Practices Overview
In these practices, you will perform a repository patch merge in a development-to-production
scenario.
358 Practices for Lesson 22: Performing a Patch Merge

Practice 22-1: Performing a Patch Merge
Overview
In this practice, you perform a repository patch merge in a development-to-production scenario.
Assumptions
In a patch merge, you create a patch that contains the differences between the current
repository file and the original repository file, and then you apply the patch file to the modified
repository file. In a development-to-production scenario, you have an original parent file, a
current file that contains the latest development changes, and a modified file that is the
deployed copy of the original file. To generate a patch, you open the current file and select the
original file, and then create the patch. To apply the patch, you open the modified file and select

the original file, and then apply the patch.
Time
15 minutes
Tasks
1. Before creating and applying a patch merge, explore the repositories that you will use in
this practice.
a. Navigate to D:\PracticeFiles.
b. Copy the original, modified, and current repository files and paste them into
D:\repository.
c. In the Administration Tool, open original.rpd in offline mode with password
welcome1. For the purpose of this training, assume that this is the original repository
that you created during development.
d. Update row counts to check connectivity.

e. Select Tools > Query Repository to open the Query Repository utility.
Practices for Lesson 22: Performing a Patch Merge 359

f. In the Name field, enter Units after the asterisk.
g. Change the Type to Presentation Column.
h. Click Query.

i. Notice the ID for the object (4010:591, in this example). The Administration Tool tracks
the history of each repository object by using the upgrade ID of the object. The
upgrade ID is a unique identifier for each object.
j. Close the Query Repository utility.
k. Close original.rpd without saving any changes.
l. Open modified.rpd in offline mode with welcome1 as the password. For the purpose
of this training, assume that this is the production repository. Before applying the patch
in the steps that follow, the contents of the original and modified repositories are the
same.
m. Update row counts to verify connectivity.

n. Select Tools > Query Repository to open the Query Repository utility.
o. In the Name field, enter Units after the asterisk.

p. Change the Type to Presentation Column.
q. Click Query.

r. Notice the ID for the object (4010:630, in this example). Although the Units
presentation column object exists in both repositories, the object ID is different. This is
because Units was deleted and then re-created in this modified repository. The
significance of this becomes apparent in the steps that follow.
s. Close the Query Repository utility.
t. Leave the modified repository open.
2. Use the Equalize Objects option in the “Compare repositories” dialog box to compare and
equalize the original and modified repositories. Objects may need to be equalized because
the Administration Tool tracks the history of each repository object by using the upgrade ID
of the object. Sometimes, the upgrade ID can change because of user actions or during
merge. When this occurs, and a subsequent comparison is done, the Administration Tool
treats the new upgrade ID as a new object, and the missing original upgrade ID as a
deleted object.
a. Select File > Compare.
b. Use the Select button to select the original repository.
c. Enter welcome1 as the password and click OK to populate the “Compare repositories”
dialog box.

d. Notice that the tool compares the two repositories and marks objects as modified,
deleted, or created.

− “Created” means the object was created in the current repository and does not exist
in the original repository.
− “Deleted” means the object exists in the original repository but has been deleted
from the current repository.
− “Modified” means the object exists in the original repository but has been modified in
the current repository.
e. In this example, notice that the Units presentation column and logical column are
marked as both deleted and created. This is because the object was deleted and then
re-created in the modified repository. The Base Facts presentation table, F1 Revenue
logical table, and LTS1 F1 Revenue logical table source are marked as modified
because the Units object is in these objects.
f. Click Equalize to display the Equalize Objects dialog box. Notice that only Logical
Column and Presentation Column are available in the drop-down list. This is because,
in this example, only logical columns and presentation columns have been deleted. If
more object types had been deleted, they would be displayed in this list (Logical Table,
Logical Column, and so forth).
g. Make sure that Logical Column is selected in the drop-down list.

h. In the Deleted pane, select “Sample Apps"."F1 Revenue"."Units".
i. In the Created pane, select "Sample Apps". "F1 Revenue". "Units".

j. Click Add to add the columns to the Equated pane.

k. Select Presentation Column in the drop-down list.
l. In the Deleted pane, select "Sample Sales"."Base Facts"."Units".
m. In the Created pane, select "Sample Sales". "Base Facts". "Units".
n. Click Add to add the columns to the Equated pane.

o. Click OK to close the Equalize Objects dialog box. You should receive a message that
the repositories are identical.

p. Click Close to close the “Compare repositories” dialog box.
q. Save the modified repository.
r. Check consistency. Make sure that there are no errors.
s. Click OK.
t. Close the modified repository.

3. Generate a repository patch.
a. In the Administration Tool, navigate to D:\repository and open current.rpd in offline
mode with welcome1 as the password. This is the repository that contains the
changes that you want to put in the patch. Assume that this is a repository that you
have updated after rolling out the original repository (original.rpd) to production
(modified.rpd).

b. Update row counts to check connectivity.
c. Select File > Compare.
d. Select the original repository.
e. Enter welcome1 as the password and click OK. The “Compare repositories” dialog box
appears, compares the two repositories, and marks objects as modified, deleted, or
created.
f. In this example, the changes are:

− A Rank Revenue logical column has been created and added to the F1 Revenue
logical table in the Business Model and Mapping layer.
− A Rank Revenue presentation column has been created and added to the Base
Facts presentation table in the Presentation layer.
− The Prod Dsc presentation column has been deleted from the Products
presentation table in the Presentation layer.

g. Click Equalize to open the Equalize Objects dialog box. Notice that the objects listed in
the Deleted and Created columns are not the same, and, therefore, there is no need to
equate the objects.
h. Click Cancel to close the Equalize Objects dialog box.

i. In the “Compare repositories” dialog box, review the changes between the repositories,

and then click Create Patch.
j. In the Create Patch dialog box, enter my_patch as the name for the XML patch file
and click Save. The file is saved to the D:\repository directory.
k. Click Cancel to close the “Compare repositories” dialog box.
l. Close the current repository without saving any changes.
4. Apply the repository patch.
a. In the Administration Tool, navigate to D:\repository and open the modified Oracle BI
repository in offline mode with welcome1 as the password. This is the repository on
which you want to apply the patch.
b. Select File > Merge to open the Merge Repository Wizard.
c. For Merge Type, select Patch Repository Merge.
d. Click Select > Repository next to the Original Master Repository field.
e. Browse to select the original repository. Notice that the original repository cannot be
the same as the modified (currently open) repository.
f. Enter welcome1 in the Repository Password field.
g. Click Select > Select XML Patch next to the Patch File field.
h. Browse to select the my_patch.xml patch file, and then click Open.
i. Leave the Patch Password field blank.
j. Click Select > Repository next to the “Save Merged Repository as” field.

k. Accept modified_patched as the file name and click Save.

l. Click Next. The Merge Repository Wizard opens.
m. Under Conflicts, notice that the description of the conflict for Prod Dsc is “Deleted from
Current.”
n. Click the Decision field for Prod Dsc. Notice the two choices:
− Choosing “Current” would keep the repository as it is without adding the object to
the merged repository.
− Choosing “Modified (A)” would add the object into the merged repository.

o. Select Current. In this example, Prod Dsc was deliberately deleted from the current
repository and, therefore, you do not want it added to the merged repository.

p. Click Finish. The modified_patched repository opens in offline mode. Verify that the
expected changes have been applied. A Rank Revenue logical column and
presentation column have been created, and the Prod Dsc presentation column has
been deleted.

q. Close the repository. Leave the Administration Tool open.


Managing Metadata and
Working with Service
Instances
372 Practices for Lesson 23: Managing Metadata and Working with Service Instances

D95501GC10 Ag

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D95501GC10 Ag

Uploaded by

Copyright:

Available Formats

Oracle Internal & Oracle Academy Use Only

Oracle BI 12c: Build Repositories

Learn more from Oracle University at education.oracle.com

Jim Sarokin Disclaimer

Vijayalakshmi Narasimhan Restricted Rights Notice

Oracle Internal & Oracle Academy Use Only

1011042020 Trademark Notice

Third-Party Content, Products, and Services Disclaimer

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

Oracle BI 12c: Build Repositories – Table of Contents iii

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

iv Oracle BI 12c: Build Repositories – Table of Contents

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates. All rights reserved.

Oracle BI 12c: Build Repositories – Table of Contents v

Copyright © 2020, Oracle and/or its affiliates.

vi Oracle BI 12c: Build Repositories – Table of Contents

There are no practices for this lesson.

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

8 Practices for Lesson 1: Course Introduction

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

10 Practices for Lesson 2: Repository Basics

Oracle Internal & Oracle Academy Use Only

You need to START the BI Instance.

Copyright © 2020, Oracle and/or its affiliates.

Practices for Lesson 2: Repository Basics 11

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

12 Practices for Lesson 2: Repository Basics

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

Practices for Lesson 2: Repository Basics 13

Copyright © 2020, Oracle and/or its affiliates.

14 Practices for Lesson 2: Repository Basics

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

Practices for Lesson 2: Repository Basics 15

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

16 Practices for Lesson 2: Repository Basics

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

Practices for Lesson 2: Repository Basics 17

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

18 Practices for Lesson 2: Repository Basics

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

Practices for Lesson 2: Repository Basics 19

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.

20 Practices for Lesson 2: Repository Basics

Oracle Internal & Oracle Academy Use Only

d. Confirm that you receive the following message:

Copyright © 2020, Oracle and/or its affiliates.

Practices for Lesson 2: Repository Basics 21

Oracle Internal & Oracle Academy Use Only

Copyright © 2020, Oracle and/or its affiliates.