You are on page 1of 289

OBIEE10g

OBIEE10g Metadata Modeling Basics Training


Michal Zima Killorglin, 8.10.2013

Training Introduction/Logistic

Get Introduced (trainer, participants) Training : Audience Prerequisites Objectives Agenda

Lesson Agenda

OBIEE10g Metadata Modeling Basics

Training Introduction/Logistic

Trainer introduction : Over 10 years of experience with DWH/BI Oracle technologies and building solution using those technologies 6 years of experience with OBIEE (past Siebel Analytics) technology (implementations, training) Worked for global companies (Siebel, Oracle) in consulting practice A few words about you (participants) : Name Role Prior experience with BI (particularly OBIEE) and DWH

Trainer, participants introduction

OBIEE10g Metadata Modeling Basics

Training Introduction/Logistic

Training is aimed mainly to: Business Intelligence developers DWH/Data designers BI Architects Business analysts

Training Audience

OBIEE10g Metadata Modeling Basics

Training Introduction/Logistic

Desirable experience/knowledge for participants: Some BI/DWH experience Knowledge of Data modeling principles, ideally Kimball Dimensional Modeling Knowledge (at least basic) of SQL language

Training Prerequisites

OBIEE10g Metadata Modeling Basics

Training Introduction/Logistic

Gain basic knowledge of OBIEE10g architecture and its components Gain knowledge of metadata structure (layers) Gain basic knowledge of BI Administration Tool (client sw, used for designing metadata) Learn basic administration routines and best practices Gain (using practical labs) essential basic knowledge for being able to
independently build OBIEE10g on top of relational data sources

Training Objectives

OBIEE10g Metadata Modeling Basics

Training Introduction/Logistic

Day 1: Training Introduction/Logistic OBIEE10g architecture/Repository Introduction Physical Layer of a Repository Business Model and Mapping Layer of a Repository Presentation Layer of a Repository Day 2: Testing and Validating a Repository Adding Multiple Logical Table Sources Adding Calculations to a Fact Creating Dimension Hierarchies and Level-Based Measures

Training Agenda

OBIEE10g Metadata Modeling Basics

Training Introduction/Logistic

Day 3: Using Aggregates Using Repository Variables Modeling Time Series Data Security Basics

Training Agenda

OBIEE10g Metadata Modeling Basics

OBIEE10g architecture / Repository Introduction

Become familiar with OBIEE10g architecture and its components Become familiar with 3 layers of OBIEE10g repository (metadata) Learn about BI Administration Tool

Lesson Objectives

OBIEE10g Metadata Modeling Basics

OBIEE10g architecture / Repository Introduction


OBIEE10g architecture
Interactive Dashboards

Reporting & Publishing

Ad-hoc Analysis

Proactive Detection and Alerts

Disconnected Analytics

MS Office Plug-in

Web Services

Single Logical SQL passed to Oracle BI Server

Enterprise Business Model and Abstraction Layer Intelligent Caching Services Multidimensional Calculation and Integration Engine

Oracle BI Server
Oracle BI server generates one or more Physical SQL queries

Physical Layer

OLTP & ODS Systems

Data Warehouse Data Mart

SAP, Oracle PeopleSoft, Siebel, Custom Apps

Files Excel XML

Business Process

OBIEE10g Metadata Modeling Basics

10

OBIEE10g architecture / Repository Introduction


OBIEE10g architecture

Main OBIEE10g architecture components: Clients BI Presentation Services BI Server Data sources

OBIEE10g Metadata Modeling Basics

11

OBIEE10g architecture / Repository Introduction


Clients

Provide access to BI content (requests, dashboards) within OBIEE10g UI: Answers tool for creation/modification/view of requests (synonym for a report Interactive Dashboards for displaying Answers requests along with other
content on dashboard pages (also allowing interactivity for exposed requests filtering, navigation.)

OBIEE10g Metadata Modeling Basics

12

OBIEE10g architecture / Repository Introduction


BI Presentation Services

Takes care of rendering OBIEE10g web based UI : Answers Interactive Dashboards Delivers Administration Takes care of catalog for storage of user created content (requests, dashboards..) Presentation Catalog Gets the data from Oracle BI server and provides it to the clients

OBIEE10g Metadata Modeling Basics

13

OBIEE10g architecture / Repository Introduction


BI Server

Core component of OBIEE10g architecture (heart of the system) Uses metadata (repository) during data processing Communicates with underlying data sources For relational data sources it generates dynamic SQL select statement to get the data It is using native connectivity (OCI for Oracle) or generic ODBC connectivity to connect to data sources It provides results of the queries (eventually enriched by its own calculations) to its clients (main client is BI Server) Acts as a virtual data source to its surroundings (accessible via ODBC interface)
OBIEE10g Metadata Modeling Basics 14

OBIEE10g architecture / Repository Introduction


BI repository (metadata)

Contains metadata used by BI Server It has physically the form of binary file with RPD extension It maps particular data sources used for reporting and transforms them into semantic model (business model) Repository is created/modified by client tool BI Administration Tool (available on
Windows platform only)

OBIEE10g Metadata Modeling Basics

15

OBIEE10g architecture / Repository Introduction


Data sources

Contains data/information relevant to business users for analysis/reporting BI Server is getting data from the data sources BI Server can work with different data sources: Relational databases (RDBMS) most common OLAP data sources (Essbase, MSAS, SAP BW..) XML files Excels (on Windows platform only, mainly for demonstration purposes) BI Server knows about the capabilities of individual relational data sources to be able to generate most effective SQL statements The most suitable data source for BI is DWH (integrated data with data model
of suitable form Kimball dimensional model)
OBIEE10g Metadata Modeling Basics 16

OBIEE10g architecture / Repository Introduction


Request Execution Data Flow

1 - User submits a request (report) 2 - BI Presentation Services asks for a data (in form of logical SQL) to BI Server 3 - BI Server uses a metadata (repository) to address correct data source and generates optimized SQL to get the data 4 - BI Server receives the data from the data sources and perform any post-processing if needed (internal calculation, internal joins of data sets....) 5 - BI Server passes the data to Presentation Services (result of logical SQL send to BI Server) 6 - BI Presentation Services formats the data and sends it to the client (Answers, Dashboards)
OBIEE10g Metadata Modeling Basics 17

OBIEE10g architecture / Repository Introduction


BI Administration Tool

Tool for building BI Server metadata divided into 3 layers: Physical Business Model and Mapping (BMM) Presentation
OBIEE10g Metadata Modeling Basics 18

OBIEE10g architecture / Repository Introduction


Metadata Layers
Presentation Layer Simplified view Logical SQL interface Semantic Object Layer

Dimensions Hierarchies Measures Calculations Aggregation Rules Time Series Physical Layer
Map Physical Data Connections Schema

OBIEE10g Metadata Modeling Basics

19

OBIEE10g architecture / Repository Introduction


Physical Layer
DB2 Supply Chain DM

Physical Layer Intelligent Request Generation


Multiple sources Optimized SQL generation Regardless of Schema Function ship to appropriate data sources/Compensation

Teradata OLAP Oracle ERP.

XML Data Source


SQL Server Acxiom

Siebel Operational

OBIEE10g Metadata Modeling Basics

20

OBIEE10g architecture / Repository Introduction


Physical Layer

Contains objects representing physical data sources used for reporting/analysis by BI Server Can map multiple (even disparate) data sources First layer built in the repository
OBIEE10g Metadata Modeling Basics 21

OBIEE10g architecture / Repository Introduction


Physical Layer Objects
Data Source Connection Pool

Schema folder Canonical time dimension Aliases with specific prefixes

Extra aliases to prevent circular joins Extra aliases for time series reporting

Actual tables

OBIEE10g Metadata Modeling Basics

22

OBIEE10g architecture / Repository Introduction


Business Model and Mapping Layer
Business Model Layer
Calculation Engine Physical complexity converted to logical subject areas Drill-Paths Complex/Derived Measures (Level-based, time series, dimension-specific, nested) Aggregate/Fragment Aware

OBIEE10g Metadata Modeling Basics

23

OBIEE10g architecture / Repository Introduction


Business Model and Mapping Layer transformation into dimension model
OLAP

OLTP

Dimensions Facts

ODBC CSV XML

OBIEE10g Metadata Modeling Basics

24

OBIEE10g architecture / Repository Introduction


Business Model and Mapping Layer

Layer, where transformation of physical data model into business model (semantic layer) understandable by end/business users is performed It has a form of logical star schemas according to dimensional modeling
methodology (R. Kimball) OBIEE10g Metadata Modeling Basics 25

OBIEE10g architecture / Repository Introduction


Business Model and Mapping Layer Objects
Business Model Dimensions (Hierarchies) Logical Table Sources Dimension Logical Tables Logical Columns Fact Logical Tables

Measures (Fact Logical Columns )

OBIEE10g Metadata Modeling Basics

26

OBIEE10g architecture / Repository Introduction


Business Model Mappings

BMM layer objects map to data objects in the Physical layer Mappings is usually not one-to-one: Business models may map to multiple data sources Logical tables may map to multiple physical tables. Logical columns may map to multiple physical columns
OBIEE10g Metadata Modeling Basics 27

OBIEE10g architecture / Repository Introduction


Presentation Layer
Presentation Layer Role-based, in context, personalized presentation Oracle Answers

OBIEE10g Metadata Modeling Basics

28

OBIEE10g architecture / Repository Introduction


Presentation Layer

Only metadata layer directly exposed to end users Contains objects, providing view to a business model for end users Exposes just objects, relevant to users (simplification)
OBIEE10g Metadata Modeling Basics 29

OBIEE10g architecture / Repository Introduction


Presentation Catalog

Presentation Layer Objects

Subject Area

Presentation Folder

Folder

Column Presentation Column

OBIEE10g Metadata Modeling Basics

30

OBIEE10g architecture / Repository Introduction


Presentation Layer Mappings

Presentation layer objects map to objects in BMM layer Subject area/Presentation Catalog maps to Business Model Presentation Folder may map to logical table Presentation Column maps (strict mapping) to logical column
OBIEE10g Metadata Modeling Basics 31

OBIEE10g architecture / Repository Introduction


Repository Directory

Repository file (RDP) is located in folder \OracleBI\server\Repository

OBIEE10g Metadata Modeling Basics

32

OBIEE10g architecture / Repository Introduction


Repository Modes

Repository files can be opened for editing in offline or online mode Offline Mode: Repository file (RPD) is open from file system Online Mode: Connection is made (via ODBC driver) to live BI Server We are working against repository loaded into Oracle BI Server memory Administrators can perform tasks not available in offline mode: Manage scheduled jobs Manage user sessions Manage the query cache Manage clustered servers Stop Oracle BI Server

OBIEE10g Metadata Modeling Basics

33

OBIEE10g architecture / Repository Introduction


NQSConfig.ini configuration file

One entry in configuration file NQSConfig.INI (\OracleBI\server\Config) instructs


BI server, which RPD file to use for its operation

OBIEE10g Metadata Modeling Basics

34

OBIEE10g architecture / Repository Introduction


Summary

In this lesson, we have learned about : Key components of OBIEE10g architecture Three layers of BI Server repository and their relations BI Administration Tool and its purpose

OBIEE10g Metadata Modeling Basics

35

OBIEE10g architecture / Repository Introduction


Labs - Overview

This lesson is accompanied with following labs: Exploring BI Server repository

OBIEE10g Metadata Modeling Basics

36

Physical Layer of a Repository

Learn about the objects in Repository Physical layer Create Repository Physical layer

Lesson Objectives

OBIEE10g Metadata Modeling Basics

37

Physical Layer of a Repository


Physical Layer

Contains objects representing physical data sources used for reporting/analysis by BI Server Can map multiple (even disparate) data sources First layer built in the repository
OBIEE10g Metadata Modeling Basics 38

Physical Layer of a Repository


Physical Layer Objects
Database object Connection Pool

Schema folder Canonical time dimension Aliases with specific prefixes

Extra aliases to prevent circular joins Extra aliases for time series reporting

Actual tables

OBIEE10g Metadata Modeling Basics

39

Physical Layer of a Repository

Represents the highest-level object in Physical layer Specifies data source, which is used by BI Server for querying (database type,
etc...)
Database object

Database Object

OBIEE10g Metadata Modeling Basics

40

Physical Layer of a Repository

Name does not need to represent the physical data source name (like Oracle DB instance name) Database type of the data source (influences queries generated by BI server) :

Relational Multidimensional File based (XML)

Database Object General tab

OBIEE10g Metadata Modeling Basics

41

Physical Layer of a Repository

You can set the SQL features, BI Server can leverage when querying this data source OBIEE has "knowledge base" for default features for registered data source types (like Oracle Db) Be careful when overwriting the default values (can considerably influence generated SQL statements) You can "Ask DBMS" for setting DB features while working in online mode

Database Object Features tab

OBIEE10g Metadata Modeling Basics

42

Physical Layer of a Repository

Defines connection of BI Server to a data source Could be either generic ODBC or native connectivity (Oracle Db) Uses principle of "connection pooling" - multiple users share pool of connection
to a data source
Connection Pool Name Connectivity Type (Native/ODBC) Max no of connections Data source name (ODBC name or connect descriptor) Connection Pooling Enabled

Connection Pool

For querying Db objects in different owner schemas Shared logon username/password

OBIEE10g Metadata Modeling Basics

43

Physical Layer of a Repository

Optional object Container object for definitions of tables, columns For Oracle Db it represents Db schema, owning imported database objects
definitions (tables, views) its name is used in generated SQL - <<schema name>>.<<Db object name>>
Physical Schema

Physical Schema

OBIEE10g Metadata Modeling Basics

44

Physical Layer of a Repository

Corresponds to a table (or view) in a physical data source Most typically the definition is imported from a database or other data source (although can be created manually as well) Provides metadata needed for BI Server to access the tables/views with SQL
queries
Physical Table

Physical Table

OBIEE10g Metadata Modeling Basics

45

Physical Layer of a Repository

Table Type:

Physical Table Properties

Physical Table (most common) Stored Proc (never used from my experience) Select (glasses) also called opaque view (SQL SELECT statement, specific to Db source) - better to implement view on Db level then using this opaque view functionality

Name

Table Type

Dynamic Name (using variables)

Caching Properties

OBIEE10g Metadata Modeling Basics

46

Physical Layer of a Repository

Represents "pointer" to physical table definition (created by right-clicking on physical table definition) Used mainly to avoid circular join definition in physical layer (for example role playing dimensions in Kimball methodology) Alias structure (columns) is "read-only", always reflects structure of original table definition Appears with different icon in physical layer
Alias Name Source Table

Alias

OBIEE10g Metadata Modeling Basics

47

Physical Layer of a Repository

Object that corresponds to a column in a physical database Child object of physical table It has data type (internal BI Server, corresponding to Db data types) and nullable
property

Physical Column

Columns

OBIEE10g Metadata Modeling Basics

48

Physical Layer of a Repository

Defines relationships between tables Primary key: Uniquely identifies a single row of data Consists of a column or set of columns Is identified by a key icon Foreign key: Refers to the primary key columns in another table Is composed of a column or set of columns
Key Column

Key Column

Foreign Keys within table definition

OBIEE10g Metadata Modeling Basics

49

Physical Layer of a Repository

Represent primaryforeign key relationships between tables in the Physical layer Usually defined in Physical diagram Join Properties define:

Tables joined Cardinality Join Expression
Physical Diagram Join Properties

Joins

OBIEE10g Metadata Modeling Basics

50

Physical Layer of a Repository

Fictional company XYZ Selling Tigers data are in a relational database (Oracle) in a schema SH containing data about : Sales figures (amount, quantity) by day, product, promotions, channels and customers Unit price and costs by day , product, promotions, channels

Labs Scenario

OBIEE10g Metadata Modeling Basics

51

Physical Layer of a Repository

1. Import the physical schema from data source 2. Select tables (and columns) to be imported 3. Import keys and joins (optional) 4. Check the import 5. Edit connection pool properties 6. Define physical keys and joins

Physical Layer Implementation Steps

OBIEE10g Metadata Modeling Basics

52

Physical Layer of a Repository

Using BI Administration Tool menu File -> Import -> From Database

Import the physical schema

Connection Type (OCI for Oracle Db)

Credentials for connection to Db

Connect descriptor from tnsnames.ora

OBIEE10g Metadata Modeling Basics

53

Physical Layer of a Repository

In import wizard (next step) select tables/columns needed for building physical
model in physical layer (you can add tables later on)
Filtering tables for import

Select tables (and columns) to be imported

Tables selected for import

Objects for import

OBIEE10g Metadata Modeling Basics

54

Physical Layer of a Repository

You can import keys, foreign keys and corresponding joins, if they are defined in a data source This selection is optional, you can define keys, joins "manually" later on (to have
better control over the build physical data model)

Import keys and joins

OBIEE10g Metadata Modeling Basics

55

Physical Layer of a Repository

Check, whether correct schema, tables, columns, and keys has been imported You can use View Data option to check the connection to data source

Check the import

OBIEE10g Metadata Modeling Basics

56

Physical Layer of a Repository

After import (or during import when importing for the first time), you check or
modify the connection pool properties using the Connection Pool properties dialog box Connection
Pool Name Connectivity Type (Native/ODBC) Max no of connections Data source name (ODBC name or connect descriptor) Connection Pooling Enabled

Edit connection pool properties

For querying Db objects in different owner schemas Shared logon username/password

OBIEE10g Metadata Modeling Basics

57

Physical Layer of a Repository

In case keys and joins has not been imported automatically (either intentionally
or they do not exists in Db) from data source (Db), you can define them in Admin Tool:

Define physical keys and joins

Define keys (and also joins) using the Physical Table properties dialog box Define joins and keys using the Physical Diagram

OBIEE10g Metadata Modeling Basics

58

Physical Layer of a Repository


Defining Keys Using the Table Properties

Key Name

Select columns, constituting a key

OBIEE10g Metadata Modeling Basics

59

Physical Layer of a Repository

Physical Diagram can be open by selecting tables in physical layer and then

Right-click selected tables and choose Physical Diagram Or use Physical Diagram icon in a toolbar

Using the Physical Diagram

OBIEE10g Metadata Modeling Basics

60

Physical Layer of a Repository

Select New foreign key icon in a toolbar Drag from table with cardinality 1 and drop to table with cardinality N Define join property (name, join expression) in Physical Foreign Key dialog
window
FK Name

Physical Diagram Foreign Key

Join Expression

OBIEE10g Metadata Modeling Basics

61

Physical Layer of a Repository


Summary

In this lesson, we have learned : About objects constituting Physical layer of a repository How to create Physical layer of a repository

OBIEE10g Metadata Modeling Basics

62

Physical Layer of a Repository


Labs - Overview

This lesson is accompanied with following labs: Become familiar with XYZ Selling Tigers data, which will be used to build BI solution (metadata) Create empty repository and import tables Define keys and joins

OBIEE10g Metadata Modeling Basics

63

Business Model and Mapping Layer of a Repository

Learn about the objects in Repository Business Model and Mapping (BMM) layer Create a business model Create measures in a business model

Lesson Objectives

OBIEE10g Metadata Modeling Basics

64

Business Model and Mapping Layer of a Repository

Layer, where transformation of physical data model into business model (semantic layer) understandable by end/business users is performed It has a form of logical star schemas according to dimensional modeling methodology (R. Kimball) Measures and (Dimensional) attributes are clearly defined in this layer

Business Model and Mapping (BMM) Layer

OBIEE10g Metadata Modeling Basics

65

Business Model and Mapping Layer of a Repository


Business Model and Mapping Layer Objects
Business Model Dimensions (Hierarchies) Logical Table Sources Dimension Logical Tables Logical Columns Fact Logical Tables

Measures (Fact Logical Columns )

OBIEE10g Metadata Modeling Basics

66

Business Model and Mapping Layer of a Repository

BMM layer objects map to data objects in the Physical layer Mappings is usually not one-to-one: Business models may map to multiple data sources Logical tables may map to multiple physical tables. Logical columns may map to multiple physical columns Mapping of logical columns can also include transformations/formulas

Business Model Mappings

OBIEE10g Metadata Modeling Basics

67

Business Model and Mapping Layer of a Repository

Business model Logical tables (logical dimensions/logical facts) Logical table sources Logical columns Measures (Special form of logical column) Logical primary keys Logical joins

BMM Layer Objects

OBIEE10g Metadata Modeling Basics

68

Business Model and Mapping Layer of a Repository

Is the top-level object in the BMM layer Contains the business model definitions (logical star schemas) and the mappings from logical to physical tables Business Model uses terminology familiar to business users (not "cryptic"
physical object names)
Business Model

Business model

Business Terms

OBIEE10g Metadata Modeling Basics

69

Business Model and Mapping Layer of a Repository

Logical Table contains logical columns that can be mapped to one or more physical columns from the physical layer Represents logical fact or logical dimension Can be created:

Automatically by dragging tables from Physical layer Manually by right-clicking business model and selecting New Object > Logical Table

Logical Table

OBIEE10g Metadata Modeling Basics

70

Business Model and Mapping Layer of a Repository

Define the mappings from a logical table to a physical table



Logical tables may have multiple logical table sources One logical table source may map to many physical sources

Logical Table Source (LTS)

OBIEE10g Metadata Modeling Basics

71

Business Model and Mapping Layer of a Repository

Within Logical Table Source (LTS), you define mapping between logical columns of logical table and physical columns from tables, constituting LTS Column Mapping tab within LTS dialog box is intended for building, viewing or
modifying logical to physical column mappings

Logical Table Source - Column Mappings

OBIEE10g Metadata Modeling Basics

72

Business Model and Mapping Layer of a Repository

Represent the business element (attribute, measure) of the data Can map to many columns in the Physical layer Can be defined by referring other logical columns in formula (calculation) Can be created:

Automatically by dragging tables or columns from the Physical layer Manually by right-clicking a logical table and selecting New Object > Logical Column (and then defining mapping to physical column within LTS)

Logical Column

OBIEE10g Metadata Modeling Basics

73

Business Model and Mapping Layer of a Repository

Define unique identifiers (logical columns) for logical tables (but from business point of view, not for example "surrogate, generated DWH keys) Define the lowest level of detail of a logical table Logical Keys are only required for logical dimension tables (for repository to be
valid), not for logical fact tables

Logical Table Primary Key

OBIEE10g Metadata Modeling Basics

74

Business Model and Mapping Layer of a Repository

Defines the cardinality relationship between logical tables (derives the logical table role in model - dimension or fact) Is required for a valid business model Help Oracle BI Server understand the relationships between various objects of the business model Examining logical joins is an integral part of how Oracle BI Server figures out how to construct the physical queries There is no "join expression" defined as part of logical join definition (as
opposed to join definition on physical layer - FK)

Logical Join

OBIEE10g Metadata Modeling Basics

75

Business Model and Mapping Layer of a Repository


Logical Join

OBIEE10g Metadata Modeling Basics

76

Business Model and Mapping Layer of a Repository

Represents calculations with measurable quantity Special form of logical columns placed in logical fact tables Have aggregation rule defined in metadata

Measure

OBIEE10g Metadata Modeling Basics

77

Business Model and Mapping Layer of a Repository

Create a dimensional model to represent XYZ Selling Tigers business Logical dimensions:

XYZ Selling Tigers Scenario

Time (Periods) Products Customers Channels Promotions Logical Facts : SALES - main fact table containing total sales measures (amount, quantity) by day, product, promotions, channels and customers COSTS - "supporting" fact table with unit price and unit cost measures by day,
product, promotions, channels

OBIEE10g Metadata Modeling Basics

78

Business Model and Mapping Layer of a Repository


XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

79

Business Model and Mapping Layer of a Repository

1. Create business model 2. Create logical tables and columns 3. Define logical joins 4. Modify logical tables and columns 5. Define measures in logical fact tables

BMM Layer Implementation Steps

OBIEE10g Metadata Modeling Basics

80

Business Model and Mapping Layer of a Repository

Right-click in the BMM layer and select New Business Model (more control over the process) Or Dragging selected physical tables into BMM layer

1. Create business model

OBIEE10g Metadata Modeling Basics

81

Business Model and Mapping Layer of a Repository

Drag physical table objects from the Physical layer into BM definition fast, but

2. Create logical tables and columns

less control over the process (creates automatically also logical columns for all physical columns) Or right-click BM object and select New Object > Logical Table (logical columns needs to be defined afterwards)

OBIEE10g Metadata Modeling Basics

82

Business Model and Mapping Layer of a Repository

Similar to definition of foreign key joins in physical layer Business Model Diagram used for it and complex join used instead of foering key
join (with no join expression defined, just cardinality)

3. Define logical joins

OBIEE10g Metadata Modeling Basics

83

Business Model and Mapping Layer of a Repository

In objects properties window you can:


4. Modify logical tables and columns

Rename tables and columns Reorder columns Add or delete tables and columns Add, delete and modify logical table sources (LTS) Cut, copy and paste objects (but with caution)

OBIEE10g Metadata Modeling Basics

84

Business Model and Mapping Layer of a Repository

Special form of logical columns placed in logical fact tables (with aggregation rule) Right-click the logical column (numeric) in logical fact table and select Properties
> Aggregation

5. Define measures in logical fact tables

OBIEE10g Metadata Modeling Basics

85

Business Model and Mapping Layer of a Repository

Use only complex joins in BMM layer !!!!!!! Rename logical columns to have meaningful names by end user community (business dictionary) Use (if possible) short enough names (due to the space in requests) Use unique names for logical columns to avoid ambiguity

Recommended practice

OBIEE10g Metadata Modeling Basics

86

Business Model and Mapping Layer of a Repository


Summary

In this lesson, we have learned :



About objects constituting BMM layer of a repository How to create BM layer of a repository (including simple measures)

OBIEE10g Metadata Modeling Basics

87

Business Model and Mapping Layer of a Repository


Labs - Overview

This lesson is accompanied with following labs: Creating Business Model Creating Simple Measures

OBIEE10g Metadata Modeling Basics

88

Presentation Layer of a Repository

Learn about the objects of Presentation layer of a repository Modify the properties of Presentation layer objects Create Presentation layer

Lesson Objectives

OBIEE10g Metadata Modeling Basics

89

Presentation Layer of a Repository

Only metadata layer directly exposed to end users Contains objects, providing view to a business model for end users Exposes just objects, relevant to users (simplification)

Presentation Layer

OBIEE10g Metadata Modeling Basics

90

Presentation Layer of a Repository

Organize and simplify business model for a set of users Single presentation catalog must be populated from a single business model (presentation catalog cannot "span" across business models) But multiple Presentation catalogs can reference the same business model
(pretty common scenario)

Presentation Catalog

OBIEE10g Metadata Modeling Basics

91

Presentation Layer of a Repository

Organize presentation columns into groups that make sense to the users May contain columns from one or more logical tables Can be modified independently of logical tables (no strict "mapping" between logical table and presentation table) Can be created:

Automatically by dragging logical tables from BMM layer Manually in the Presentation layer

Presentation Tables

OBIEE10g Metadata Modeling Basics

92

Presentation Layer of a Repository

Define the columns used to build requests in the OBIEE user interface Map to logical columns in the BMM layer (strict 1:1 mapping) Usually derive their names from corresponding logical column name (best practice) Can be created: Automatically by dragging logical tables or columns from BMM layer Manually in the Presentation layer

Presentation Columns

OBIEE10g Metadata Modeling Basics

93

Presentation Layer of a Repository

Presentation layer objects map to objects in BMM layer Subject area/Presentation Catalog maps to Business Model Presentation Table may map to logical table Presentation Column maps (strict mapping) to logical column

Presentation Layer Mappings

OBIEE10g Metadata Modeling Basics

94

Presentation Layer of a Repository

Presentation layer objects define the content (Subject Areas), which end users
see to query the data from the data sources

Defining User Interface in the Presentation Layer

OBIEE10g Metadata Modeling Basics

95

Presentation Layer of a Repository

Give the appearance of nested folders in Answers tool In Description of presentation table put following characters ate the beginning : -> Place presentation table after the table in which you would like to nest it

Nested Presentation Folders/Tables

OBIEE10g Metadata Modeling Basics

96

Presentation Layer of a Repository

Keep track of any changes to Presentation layer objects Used in Answers when referencing renamed presentation layer object in Answer request Have additional overhead for BI Presentation Server Avoid renaming after BI outputs has been intensively created (rather perform
replacing in Web Catalog)

Presentation Layer Object Aliases

OBIEE10g Metadata Modeling Basics

97

Presentation Layer of a Repository

Build Presentation layer to present users with a customized view of XYZ Selling
Tigers data

XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

98

Presentation Layer of a Repository

1. Create new presentation catalog 2. Rename tables 3. Reorder tables 4. Delete columns 5. Rename columns 6. Reorder columns

Presentation Layer Implementation Steps

OBIEE10g Metadata Modeling Basics

99

Presentation Layer of a Repository

Drag SH business model from BMM layer to Presentation layer to automatically


create Presentation layer objects (the simplest method)

1. Create a New Presentation Catalog

OBIEE10g Metadata Modeling Basics

100

Presentation Layer of a Repository

There are a few methods for renaming tables in Presentation layer:



Use the General tab in the properties dialog box Right-click a table and select Rename Double-click a table slowly to make the name editable and then enter a new name

2. Rename tables

OBIEE10g Metadata Modeling Basics

101

Presentation Layer of a Repository

For reordering of presentation tables in Presentation Catalog, open the Presentation Catalog properties and use the Up and Down buttons or drag/drop Recommendation for ordering : Place dimension presentation tables at the top
and measure (fact) presentation tables at the bottom

3. Reorder tables

OBIEE10g Metadata Modeling Basics

102

Presentation Layer of a Repository

Delete unnecessary columns to simplify the content and make it more


understandable to users (don't overcomplicate structure of Presentation Catalog for end users)

4. Delete columns

OBIEE10g Metadata Modeling Basics

103

Presentation Layer of a Repository

Presentation columns use the logical column name by default - this is the
recommended approach to "inherit" logical column names in presentation layer to have consistent naming of a single logical column across different Presentation Catalog If there is a special need for renaming presentation column, use General tab in the column properties dialog box to deselect the Use Logical Column Name check box and enter custom name

5. Rename columns

OBIEE10g Metadata Modeling Basics

104

Presentation Layer of a Repository

For reordering of presentation columns, open Presentation Table properties box


and use the Up and Down buttons or drag/drop

6. Reorder columns

OBIEE10g Metadata Modeling Basics

105

Presentation Layer of a Repository

Presentation catalogs can map to only one BM Multiple presentation catalogs can map to the same BM Presentation columns in single presentation table can come from multiple logical tables in BM Presentation columns are automatically renamed when corresponding logical column is renamed (with alias created for previous name) Presentation tables cannot have the same name as presentation catalogs Presentation objects can be modified or deleted without affecting corresponding logical objects Be careful with modification/restructuring of presentation objects in case BI
"outputs" are already using them

Consideration

OBIEE10g Metadata Modeling Basics

106

Presentation Layer of a Repository

Use meaningful names Names cannot contain single quotation marks (); the Administration Tool prevents it (also avoid spaces at the beginning/end) Keep presentation object names unique: Naming presentation columns the same as presentation tables can lead to inaccurate results Uniqueness allows SQL statements to be shorter because qualifiers are unnecessary Group objects in meaningful ways (grouping in presentation tables) Eliminate unnecessary objects to reduce confusion (KISS principle) Use object description fields to convey information to users (displays as tooltip in Answers) Keep names short to save space on reports
OBIEE10g Metadata Modeling Basics

Recommendation/Best Practice

107

Presentation Layer of a Repository


Summary

In this lesson, we have learned :



About objects constituting Presentation layer of a repository How to crete Presentation layer of a repository How to modify the properties of Presentation layer objects

OBIEE10g Metadata Modeling Basics

108

Presentation Layer of a Repository


Labs - Overview

This lesson is accompanied with following labs: Creating Presentation layer objects Modifying Presentation layer objects

OBIEE10g Metadata Modeling Basics

109

Testing and Validating a Repository

Learn about execution of steps for testing and validating a repository

Lesson Objectives

OBIEE10g Metadata Modeling Basics

110

Testing and Validating a Repository

The following steps validate whether the repository is constructed correctly and whether it produces expected query results: Checking repository for consistency Enabling logging Loading/Deploying a repository Checking a repository using BI Answers front end tool Inspecting the query log

Validating a Repository

OBIEE10g Metadata Modeling Basics

111

Testing and Validating a Repository

Validate and test SH business model before making it available for using by end
users

XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

112

Testing and Validating a Repository

It is a feature of BI Administration Tool that checks whether a repository has met certain requirements, such as: 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: logical fact table and logical dimension table. Both can map to the same physical table. There are no circular logical join relationships. At least one Presentation Catalog exists for business model. Does not guarantee that the business model is constructed correctly

Consistency Check

OBIEE10g Metadata Modeling Basics

113

Testing and Validating a Repository

Check consistency for the entire repository or for individual repository objects by
using either of the following menus (you are also asked when saving RPD):
File Menu Tools Menu BMM layer object right-click menu

Checking Consistency

OBIEE10g Metadata Modeling Basics

114

Testing and Validating a Repository

Displays consistency check messages: Errors: Must be fixed to make the repository consistent Warnings: Condition that may or may not be an error Best Practices: Condition does not indicate an inconsistency (disabled by
default)

Consistency Check Manager

OBIEE10g Metadata Modeling Basics

115

Testing and Validating a Repository

The Options tab in the Consistency Check Manager allows to enable or disable
consistency messages

Disabling/Enabling Consistency Check Messages

OBIEE10g Metadata Modeling Basics

116

Testing and Validating a Repository

BI Server provides a facility for logging query activity at the individual user level (driven by variable LOGLEVEL set for individual users) Logging is intended for quality assurance testing, debugging, and use by Oracle Support Query logging is normally disabled in production mode (turning logging on

Enabling Logging

causes additional overhead on OBIEE server infrastructure - log file can extensively grow) Query log file is named NQQuery.log and is located in the \OracleBI\server\Log directory Various levels of query logging enables various degree of details logged

OBIEE10g Metadata Modeling Basics

117

Testing and Validating a Repository

Use the Security Manager to enable logging level for individual users Or set LOGLEVEL session variable using Initialization Block (session variables are
covered in Using Repository Variables lesson)

Setting a Logging Level

OBIEE10g Metadata Modeling Basics

118

Testing and Validating a Repository

There are 7 log levels (higher levels are intended just for communicating issues with Oracle support) Logging level 2 allows you to see the SQL generated (sufficient for
testing/debugging)

Logging Levels

OBIEE10g Metadata Modeling Basics

119

Testing and Validating a Repository

After you build a repository and it is consistent, you need to "point" BI Server to
use this RPD - add/modify an entry in the NQSConfig.ini file

Adding a Repository Entry to an Initialization File

OBIEE10g Metadata Modeling Basics

120

Testing and Validating a Repository

If the repository was edited in offline mode (recommended practice), start or restart BI Server process to load new/modified repository If the repository was edited in online mode (just for small changes, not
recommended), check in changes and reload the server metadata in Answers

Loading Repository

OBIEE10g Metadata Modeling Basics

121

Testing and Validating a Repository

Use Oracle BI Answers to validate Presentation layer by creating testing request


(report) and displaying query results

Validating by Using BI Answers

OBIEE10g Metadata Modeling Basics

122

Testing and Validating a Repository

Use the query log to check query results:


Inspecting the Query Log

Either directly looking at NQQuery.log file on the OBIEE server(located in \OracleBI\server\Log) Or by going into Manage Session in Administration page of OBIEE UI

OBIEE10g Metadata Modeling Basics

123

Testing and Validating a Repository


Inspecting the Query Log

OBIEE10g Metadata Modeling Basics

124

Testing and Validating a Repository


BI Server Logical SQL SELECT
Basic syntax for an Oracle BI SELECT statement :
SELECT <<Presentation Table>>.<<Presentation column>> list FROM <<Presentation Catalog>> WHERE <<filtering conditions>> GROUP BY <<(optional, special use)>> ORDER BY <<Presentation Table>>.<<Presentation column>> list (optional)

Example of logical SQL :


SELECT Calendar."Calendar Year" , Products."Prod Category" , "Sales Facts"."Amount Sold" FROM SH WHERE Calendar."Calendar Year" = 2000 ORDER BY Calendar."Calendar Year" , Products."Prod Category"

OBIEE10g Metadata Modeling Basics

125

Testing and Validating a Repository

BI Server Logical SQL SELECT statements are different from standard SQL in the following ways: No join information is required (SQL is constructed against Presentation layer
objects)

BI Server Logical SQL SELECT comparison with physical SQL SELECT

No aggregation functions are required (since measures have their aggregation


rule defined in repository and thus performed for them automatically), although aggregation function can be defined in logical SQL No GROUP BY clause is required by default

Join conditions are predefined in the repository Any join conditions supplied in a query are ignored

No DISTINCT keyword is required

If aggregated data is requested in the SELECT statement, a GROUP BY clause is automatically assumed by the server BI Server always issues SELECT DISTINCT to eliminate duplicate rows automatically

OBIEE10g Metadata Modeling Basics

126

Testing and Validating a Repository


Summary

In this lesson, we have learned : How to execute the steps to test and validate a repository

OBIEE10g Metadata Modeling Basics

127

Testing and Validating a Repository


Labs - Overview

This lesson is accompanied with following labs: Testing and validating new repository (along with deployment) Generating inconsistent repository (business model) and fixing consistency
errors

OBIEE10g Metadata Modeling Basics

128

Adding Multiple Logical Table Sources

Describe normalized and de-normalized table structures in database designs Add multiple sources to a logical table source (LTS) for a dimension/fact in business model Topic : Adding a second logical table source to logical table - will be covered in
Aggregation lesson

Lesson Objectives

OBIEE10g Metadata Modeling Basics

129

Adding Multiple Logical Table Sources

Normalized table structures (usually transactional systems - OLTP): Consists of many tables where data has been split or normalized Are used for inserts and updates Does not work well for queries that perform business data analysis Could occur also in dimensional model (snowflake) De-normalized table structures (DWH - dimensional model): Follows more a business model and is easier to understand Has data that may be duplicated in several locations in a database Can take the form of a star schema Provides better query performance

Table Structures

OBIEE10g Metadata Modeling Basics

130

Adding Multiple Logical Table Sources

Data may be spread across several physical tables and needs to be mapped to a
single logical table

Business Challenge

OBIEE10g Metadata Modeling Basics

131

Adding Multiple Logical Table Sources

Model multiple physical sources for the logical table: Add multiple sources/tables to an LTS Where data is not duplicated across tables Add a new logical table source Where data is duplicated across tables (aggregated tables, fragmented
data....)

Business Solution

OBIEE10g Metadata Modeling Basics

132

Adding Multiple Logical Table Sources

Add normalized table that store geographical attributes for customer (country,
subregion, region) to Customers dimension in SH business model

XYZ Selling Tigers Scenario: Adding Additional Table to an existing Logical Table Source (LTS)

OBIEE10g Metadata Modeling Basics

133

Adding Multiple Logical Table Sources

1. Import additional tables 2. Define keys and joins 3. Identify physical columns for mappings 4. Add sources/tables to a logical table source: Manual method Drag method 5. Rename logical columns 6. Add columns to the Presentation layer

Implementation Steps: Adding Multiple Sources to an LTS

OBIEE10g Metadata Modeling Basics

134

Adding Multiple Logical Table Sources

Import additional table, that contains geographical attributes for Customers

1. Import additional tables

OBIEE10g Metadata Modeling Basics

135

Adding Multiple Logical Table Sources

Define the keys and joins for the imported table(s)

2. Define Keys and Joins

OBIEE10g Metadata Modeling Basics

136

Adding Multiple Logical Table Sources

Identify columns in the Physical layer with the additional geographical


information for customer

3. Identify Physical Columns for Mappings

OBIEE10g Metadata Modeling Basics

137

Adding Multiple Logical Table Sources

There are alternative methods , how you can add sources to an LTS: Manual: Use the Properties dialog box of Logical Table Source (LTS) to map tables and columns Drag: Drag columns from the Physical layer to LTS to automatically map
tables and columns

4. Adding Sources to an LTS

OBIEE10g Metadata Modeling Basics

138

Adding Multiple Logical Table Sources

Create a new logical column for a logical dimension table

4a. Manual: Create New Logical Column

OBIEE10g Metadata Modeling Basics

139

Adding Multiple Logical Table Sources

Use the Properties dialog box of a logical table source to add a new physical
table to the source

4a. Manual: Add New Physical Source

OBIEE10g Metadata Modeling Basics

140

Adding Multiple Logical Table Sources

Use the Properties dialog box of a logical table source to map a new logical
column to a physical column in the new table within LTS

4a. Manual: Create Column Mapping

OBIEE10g Metadata Modeling Basics

141

Adding Multiple Logical Table Sources

LTS CUSTOMERS now maps to two physical tables: CUSTOMERS and COUNTRIES Logical column Country maps to COUNTRY_NAME physical column in
COUNTRIES physical table

4a. Manual: End Result

OBIEE10g Metadata Modeling Basics

142

Adding Multiple Logical Table Sources

Drag physical columns to a logical table source

4b. Drag Method

OBIEE10g Metadata Modeling Basics

143

Adding Multiple Logical Table Sources

Dragging physical columns to LTS automatically creates logical columns in BMM


layer

4b. Drag Method: Logical Columns Added

OBIEE10g Metadata Modeling Basics

144

Adding Multiple Logical Table Sources

Dragging physical columns to LTS automatically adds physical tables to LTS

4b. Drag Method: Physical Tables Added

OBIEE10g Metadata Modeling Basics

145

Adding Multiple Logical Table Sources

Dragging physical columns to LTS automatically adds column mappings to LTS

4b. Drag Method: Column Mappings Added

OBIEE10g Metadata Modeling Basics

146

Adding Multiple Logical Table Sources

Rename new logical columns with names that are meaningful to users (not
necessary for manual method)

5. Rename Logical Columns

OBIEE10g Metadata Modeling Basics

147

Adding Multiple Logical Table Sources

Drag new logical column(s) to Customer presentation table to make it(them)


available to users

6. Add Columns to Presentation Layer

OBIEE10g Metadata Modeling Basics

148

Adding Multiple Logical Table Sources


Summary

In this lesson, we have learned : Describe normalized and de-normalized table structures in database designs Add multiple sources to LTS for a dimension in the business model

OBIEE10g Metadata Modeling Basics

149

Adding Multiple Logical Table Sources


Labs - Overview

This lesson is accompanied with following labs: Importing normalized table that contain additional geographical information for customer to Physical layer, defining physical keys and joins Creating multiple sources (adding table) to LTS using manual method

OBIEE10g Metadata Modeling Basics

150

Adding Calculations to a Fact

Describe a calculation measure and its use in a business model Create new calculation measures based on logical columns Create new calculation measures based on physical columns Create new calculation measures by using the Calculation Wizard

Lesson Objectives

OBIEE10g Metadata Modeling Basics

151

Adding Calculations to a Fact

Physical schema may not have everything required for your analysis Adding columns into physical tables may require additional integration or ETL work Deriving a metrics in such scenario may be more efficient than storing values in the database Average Order Size: Divide Revenue by Number of Orders

Derived Metrics

OBIEE10g Metadata Modeling Basics

152

Adding Calculations to a Fact

BI Server provides utilities to create calculation measures in the business model Use the Expression Builder to create new logical columns with a calculation formula Use existing logical columns or physical columns as objects in the formula Use the Calculation Wizard to create calculation measures based on existing logical columns Expose calculation measures to the Presentation layer so that users can
formulate business questions in Answers by using familiar terminology

OBIEE solution

OBIEE10g Metadata Modeling Basics

153

Adding Calculations to a Fact

"XYZ Selling Tigers" wants to track a calculated measure Gross Profit, that
calculates the difference between Amount Sold and Unit Cost (stored in table COSTS) multiplied by Quantity Sold : Gross Profit = Amount Sold - (Unit Cost * Quantity Sold)

"XYZ Selling Tigers" Scenario

OBIEE10g Metadata Modeling Basics

154

Adding Calculations to a Fact

Calculation measures can be created using 2 different methods: Existing logical columns as objects in a formula Physical columns as objects in a formula You can use as well Calculation Wizard to automate the process of creation of
comparison measures (comparing 2 existing measures/logical columns)

Implementation Methods

OBIEE10g Metadata Modeling Basics

155

Adding Calculations to a Fact

1. Create a new logical column 2. Specify logical columns as the source 3. Build a formula

Steps for Using Existing Logical Columns

OBIEE10g Metadata Modeling Basics

156

Adding Calculations to a Fact

Right-click the fact table and select New Object > Logical Column

1. Create a New Logical Column

OBIEE10g Metadata Modeling Basics

157

Adding Calculations to a Fact

Select "Use existing logical columns as the source" check box

2. Specify Logical Columns as the Source

OBIEE10g Metadata Modeling Basics

158

Adding Calculations to a Fact

Open the Expression Builder and build the calculation formula using existing
logical columns (from logical tables)

3. Build a Formula

OBIEE10g Metadata Modeling Basics

159

Adding Calculations to a Fact

1. Create a new logical column 2. Map the new column 3. Build the formula 4. Specify an aggregation rule

Steps for Using Physical Columns

OBIEE10g Metadata Modeling Basics

160

Adding Calculations to a Fact

Use the Column Mapping tab of LTS dialog box to open the Expression Builder
for the new column

2. Map the New Column

OBIEE10g Metadata Modeling Basics

161

Adding Calculations to a Fact

Build the calculation formula using physical columns

3. Build the Formula

OBIEE10g Metadata Modeling Basics

162

Adding Calculations to a Fact

Click the Aggregation tab and set the aggregation rule for new calculated logical
column

4. Specify an Aggregation Rule

OBIEE10g Metadata Modeling Basics

163

Adding Calculations to a Fact

1. Open the Calculation Wizard 2. Choose the columns for comparison 3. Select the calculations 4. Confirm the calculation measures 5. New calculation measures are added

Steps for Using the Calculation Wizard

OBIEE10g Metadata Modeling Basics

164

Adding Calculations to a Fact

Right-click a logical column that you want to use in the calculation and select
Calculation Wizard

1. Open the Calculation Wizard

OBIEE10g Metadata Modeling Basics

165

Adding Calculations to a Fact

You can choose more columns to compare with

2. Choose the Columns for Comparison

OBIEE10g Metadata Modeling Basics

166

Adding Calculations to a Fact

You can choose different comparison calculations (Change, Percent Change,

3. Select the Calculations

Index, Percent), by default Change (absolute difference) and Percent Change selected You can name the calculation measures You can also choose NULL value handling

OBIEE10g Metadata Modeling Basics

167

Adding Calculations to a Fact

Final screen of an wizard with summary of what measures will be created

4. Confirm the Calculation Measures

OBIEE10g Metadata Modeling Basics

168

Adding Calculations to a Fact

New calculation measures are automatically added to the logical fact table

5. New Calculation Measures Are Added

OBIEE10g Metadata Modeling Basics

169

Adding Calculations to a Fact

Expose new calculation measures to Presentation layer regardless of the method


used to create the measures

Expose New Measures to Presentation Layer

OBIEE10g Metadata Modeling Basics

170

Adding Calculations to a Fact

Expression builder allows you to select various expressions, operators and


repository variables and use them to build the column formula

Advanced Functions Expression Builder

Using functions

Variables can be built and used in building formula, e.g. Current Month, Last ETL Run Date etc.

OBIEE10g Metadata Modeling Basics

171

Adding Calculations to a Fact

Use physical columns for building calculations that require an aggregation rule
(such as sum or average) that is applied after the calculation
select T82.ItemType as c1, sum(T55.UnitOrdd - T55.UnitShpd) as c3

Best practice for measures calculated from physical columns

from
D1_products T82, D1_Orders2 T55 where

Calculates the difference between units ordered and units shipped

T55.ProdKey = T82.ProductKey and


group by T79.ItemType

Applies aggregation rules on top of the calculated values

OBIEE10g Metadata Modeling Basics

172

Adding Calculations to a Fact

Example: To accurately calculate total revenue you would multiply the unit price
by the number of units sold and then sum the totals

Example of measures calculated from physical columns

OBIEE10g Metadata Modeling Basics

173

Adding Calculations to a Fact

Use logical columns for calculation formulas that require an aggregation rule
that is applied before the calculation
Select distinct D1.c1 as c1, D1.c2 as c2. D1.c3 as c4, (D1. c2 D1.c3) as c4 From (

Best practice for measures calculated from logical columns

select
T82.ItemType as c1, sum(T55.UnitOrdd) as c2, sum(T55.UnitShpd) as c3 from

And then final calculation (difference) is used with aggregated measures

First partial measures are aggregated

D1_products T82,
D1_Orders2 T55 where T55.ProdKey = T82.ProductKey and group by T79.ItemType ) D1

OBIEE10g Metadata Modeling Basics

174

Adding Calculations to a Fact


Example of measures calculated from logical columns
Example: To accurately calculate unit price, sum Total Price and Units Sold first and then divide Total Price by Units Sold to determine Unit Price

OBIEE10g Metadata Modeling Basics

175

Adding Calculations to a Fact


Summary

In this lesson, we have learned : About a calculation measure and its use in a business model How to create new calculation measures based on existing logical columns How to create new calculation measures based on physical columns How to create new calculation measures by using the Calculation Wizard

OBIEE10g Metadata Modeling Basics

176

Adding Calculations to a Fact


Labs - Overview

This lesson is accompanied with following labs: Creating Calculation Measures by Using Physical Columns Creating Calculation Measures by Using Physical Columns

OBIEE10g Metadata Modeling Basics

177

Creating Dimension Hierarchies and Level-Based Measures

Create dimension hierarchies Create level-based measures Create rank and share measures

Lesson Objectives

OBIEE10g Metadata Modeling Basics

178

Creating Dimension Hierarchies and Level-Based Measures

Defines parent-child relationships within a dimension Establishes levels for data groupings and calculations Provides paths for drilldown
Period Dimensional Hierarchy

Dimension Hierarchies

Years Quarters Levels Months

Days

OBIEE10g Metadata Modeling Basics

179

Creating Dimension Hierarchies and Level-Based Measures

Level-based hierarchy, general hierarchy style where a dimensional column act as the parent to a child level column Unbalanced (or ragged) hierarchy, is a hierarchy where the leaves (members with no children) do not necessarily have the same depth. Skip-level hierarchy, is a hierarchy where there are members that do not have a value for a particular ancestor level. Value-based hierarchy (Parent Child Hierarchy), uses the same dimension
column for all levels but based on relational tables (parent-child relationship table) in the data model to identify the parent-child relationship. In OBIEE10g metadata, only level-based (balanced, not ragged) hierarchy is supported for modeling

Types of Hierarchies

OBIEE10g Metadata Modeling Basics

180

Creating Dimension Hierarchies and Level-Based Measures

Are columns whose values are calculated (aggregated) always at a specific level
of hierarchy
Period Dimensional Hierarchy Levels Measures

Level-Based Measures

Grand Total
Years Quarters Months Days

All Period Revenue


Year Revenue Quarter Revenue Month Revenue Day Revenue

OBIEE10g Metadata Modeling Basics

181

Creating Dimension Hierarchies and Level-Based Measures

Are calculated by dividing a measure by a level-based measure to calculate a


percentage contribution of a measure to its upper level aggregation

Share Measures

OBIEE10g Metadata Modeling Basics

182

Creating Dimension Hierarchies and Level-Based Measures

This is an example of a dimension hierarchy based on Products dimension table

Dimension Hierarchy: Example

OBIEE10g Metadata Modeling Basics

183

Creating Dimension Hierarchies and Level-Based Measures

XYZ Selling Tigers Scenario wants to implement dimension hierarchies for all logical dimensions : Dim - Channels Dim - Customers Dim - Products Dim - Promotions Dim - Times

XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

184

Creating Dimension Hierarchies and Level-Based Measures

1. Create a dimension object 2. Add a parent-level object 3. Add child-level objects 4. Determine the number of elements 5. Specify level columns 6. Create level keys 7. Set the preferred drill path 8. Create a level-based measure 9. Create additional level-based measures 10. Create share measures 11. Add measures to the Presentation layer 12. Test share measures

Steps to Create a Dimension Hierarchy

OBIEE10g Metadata Modeling Basics

185

Creating Dimension Hierarchies and Level-Based Measures

Alternative methods are: Right-click the business model object and select New Object> Dimension (recommended) Right-click the logical dimension table and select Create Dimension

1. Create a Dimension Object

OBIEE10g Metadata Modeling Basics

186

Creating Dimension Hierarchies and Level-Based Measures

Create the highest (top) level of the hierarchy first

2. Add a Parent-Level Object

OBIEE10g Metadata Modeling Basics

187

Creating Dimension Hierarchies and Level-Based Measures

Add subsequent(child) levels in the hierarchy

3. Add Child-Level Objects

OBIEE10g Metadata Modeling Basics

188

Creating Dimension Hierarchies and Level-Based Measures

Part of previous step (3. Add Child-Level Objects) There are two methods for determining the number of elements for a dimension
level:

4. Determine the Number of Elements

Using result from "Update Row Counts" operation (this operation is usually used just for small amount of data) Estimate Levels - only accessible when working in online mode
Estimate Levels

Update Row Counts

OBIEE10g Metadata Modeling Basics

189

Creating Dimension Hierarchies and Level-Based Measures

Specify which columns in the logical dimension table are associated with
particular level in the dimension hierarchy

5. Specify Level Columns

OBIEE10g Metadata Modeling Basics

190

Creating Dimension Hierarchies and Level-Based Measures

Level keys: Define the unique identifier for the level Provide context for drilldown (specifies the subset of data to include from
the next level down)

6. Create Level Keys

OBIEE10g Metadata Modeling Basics

191

Creating Dimension Hierarchies and Level-Based Measures

Use Preferred Drill Path to specify a drill path outside the normal drill path
defined by the dimension level hierarchy (quite rarely used)

7. Set the Preferred Drill Path

OBIEE10g Metadata Modeling Basics

192

Creating Dimension Hierarchies and Level-Based Measures

Example: Create a level-based measure for the Grand Total level of particular
dimension (Product) that refers to an existing logical fact column

8. Create Level-Based Measures

OBIEE10g Metadata Modeling Basics

193

Creating Dimension Hierarchies and Level-Based Measures

How level-based measure appears in Answers request

8. Create Level-Based Measures

OBIEE10g Metadata Modeling Basics

194

Creating Dimension Hierarchies and Level-Based Measures

Create other level-based measures to make measures from various levels of


various dimensions (and for various "based" measures) available simultaneously in queries using same process as in previous point

9. Create Additional Level-Based Measures

OBIEE10g Metadata Modeling Basics

195

Creating Dimension Hierarchies and Level-Based Measures

Create a new logical fact column that calculates the share by dividing the appropriate measure by a total measure (level-based measure) this is an example of measure, calculated from logical columns

10. Create Share Measures

OBIEE10g Metadata Modeling Basics

196

Creating Dimension Hierarchies and Level-Based Measures

Expose new measures to Presentation layer so they can be used by end users

11. Add Measures to the Presentation Layer

OBIEE10g Metadata Modeling Basics

197

Creating Dimension Hierarchies and Level-Based Measures

In Answers, select measures to test (share measure along with corresponding


level-based measure) and then drill down to check relative recalculations

12.Test share measures

OBIEE10g Metadata Modeling Basics

198

Creating Dimension Hierarchies and Level-Based Measures


Summary

In this lesson, we have learned : How to create dimension hierarchies How to create level-based measures How to create share measures

OBIEE10g Metadata Modeling Basics

199

Creating Dimension Hierarchies and Level-Based Measures


Labs - Overview

This lesson is accompanied with following labs: Creating Dimension Hierarchies Creating Level-Based Measures Creating Share Measure

OBIEE10g Metadata Modeling Basics

200

Using Aggregates

Describe aggregate tables and their purpose in dimensional modeling Model aggregate tables Use the Aggregate Persistence Wizard to create aggregates

Lesson Objectives

OBIEE10g Metadata Modeling Basics

201

Using Aggregates

Data in fact and dimension sources is stored at the lowest level of detail Data often needs to be rolled up or summarized during analysis (example: users often requests total products by region by year ) Based on the amount of data, performing calculations at the time of the query
can be resource intensive and can delay results to the user (thus leads to end user dissatisfaction with BI application)

Business Challenge

OBIEE10g Metadata Modeling Basics

202

Using Aggregates

Create physical tables that store pre-computed aggregates at required levels Use these "aggregate" tables to process user queries Eliminates run-time calculations Delivers faster results to the users
Id 122222 133333 144444 155555 166666 Office Key 1001 1001 1002 1002 1005 Time Key Product Dollars Key 100000 200000 10000 20000 20000 Summarized Office Year 19980102 100 19990105 200 19980505 300 19980601 400 19980101 600 Total Dollars

Business Solution: Aggregate Tables

West
West Central

1998
1999 1998

100000
200000 50000

OBIEE10g Metadata Modeling Basics

203

Using Aggregates

Enables queries to use the information stored in aggregate tables automatically BI Server decides which tables provide the fastest answers Metadata must be configured for aggregate navigation

BI Server Aggregate Navigation

OBIEE10g Metadata Modeling Basics

204

Using Aggregates

Aggregated sales fact table columns store precomputed results at a given set of
levels
Time Hierarchy

Aggregated Facts

Total

Total

Total

Dimension Hierarchies

Brand

Company

Year

Product Hierarchy
LOB Organization

Office Hierarchy

Month

Type

Department

Week

Detail

Day

OBIEE10g Metadata Modeling Basics

205

Using Aggregates

Model aggregate tables in the same way as other source data Physical layer: Import physical table Create physical joins BMM layer: Add sources to logical tables Specify aggregation content - identifies the level of aggregation in the table so BI Server can determine when to use it for queries Presentation layer: No changes: Aggregate navigation is independent of Presentation layer objects Test the results
New step

Modeling Aggregates

OBIEE10g Metadata Modeling Basics

206

Using Aggregates

Uses prebuilt aggregate tables to improve performance Must have matching levels of aggregation for fact and dimensions Simplified scenario: Materialized View CAL_MONTH_SALES_MV aggregates Amount Sold by Month This MV will serve as LTS for aggregated fact and as well as aggregated
dimension (Dim Times)

XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

207

Using Aggregates

1. Import tables 2. Create joins 3. Create fact logical table source and mappings 4. Specify fact aggregation content 5. Specify content for the fact detail source 6. Create dimension logical table source and mappings 7. Specify dimension aggregation content 8. Specify content for the dimension detail source 9. Test results for levels stored in aggregates 10.Test results for data above or below levels

Steps to Implement Aggregate Navigation

OBIEE10g Metadata Modeling Basics

208

Using Aggregates

Import fact and dimension aggregates For XYZ Selling Tigers Scenario, MV will serve as aggregated fact and
dimension (so no join between fact and dimension at physical layer will be defined see next step)

1. Import Tables

OBIEE10g Metadata Modeling Basics

209

Using Aggregates

Use the Physical Diagram to create joins between aggregate fact table and aggregate dimension tables For XYZ Selling Tigers simplified scenario, MV will serve as aggregated fact and
dimension - thus no join between fact and dimension at physical layer will be defined)

2. Create Joins

OBIEE10g Metadata Modeling Basics

210

Using Aggregates

Create new aggregate LTS in the existing logical fact table and map the columns

3. Create Fact Logical Table Source and Mappings

OBIEE10g Metadata Modeling Basics

211

Using Aggregates

Specify the aggregation content of the new fact LTS, so that BI Server knows
what level of data is stored in the aggregate tables (to make optimal decision, which source to use for query)

4. Specify Fact Aggregation Content

OBIEE10g Metadata Modeling Basics

212

Using Aggregates

Set the levels of the fact detail LTS to the lowest levels in hierarchies

5. Specify Content for the Fact Detail Source

OBIEE10g Metadata Modeling Basics

213

Using Aggregates

Create new aggregate LTS in the existing logical dimension tables and map the columns For XYZ Selling Tigers simplified scenario, MV will serve also as aggregated
dimension LTS

6. Create Dimension Logical Table Source and Mappings

OBIEE10g Metadata Modeling Basics

214

Using Aggregates

Specify the aggregation content of the new dimension LTS, so that BI Server
knows what level of data is stored in the aggregate tables (to make optimal decision, which source to use for query)

7. Specify Dimension Aggregation Content

OBIEE10g Metadata Modeling Basics

215

Using Aggregates

Set the level of the dimension detail source to the lowest in the hierarchy

8. Specify Content for the Dimension Detail Source

OBIEE10g Metadata Modeling Basics

216

Using Aggregates

Run queries and inspect the query log to ensure that the aggregate tables are
accessed as expected

9. Test Results for Levels Stored in Aggregates

OBIEE10g Metadata Modeling Basics

217

Using Aggregates

Run queries with lower granularity and inspect the query log to ensure that the
detailed tables are accessed (and opposite also for higher granularity)

10. Test Results for Data Above or Below Levels

OBIEE10g Metadata Modeling Basics

218

Using Aggregates

Automates the creation of physical aggregate tables and their corresponding objects in the repository from Admin Tool Just FYI I personally dont use this feature (rather prefer manual creation of
aggregate tables, registering them manually in metadata and let ETL take care of aggregate table content freshness Real demo follows

Aggregate Persistence Wizard

OBIEE10g Metadata Modeling Basics

219

Using Aggregates

If aggregate navigation is not working, the cause might be one of the following: Aggregation content is not specified correctly for one or more sources Aggregate dimension sources are not physically joined to aggregate fact table sources at the same level Dimensional source does not exist at the same level as a fact table source Aggregate dimension sources do not contain a column that maps to the primary key of the dimension hierarchy level The number of elements is not specified correctly for dimension hierarchy
levels

Troubleshooting Aggregate Navigation

OBIEE10g Metadata Modeling Basics

220

Using Aggregates

Using aggregates comes with a price: Additional time is required to build and load these tables (ETL process) Additional storage is necessary Build only the aggregates you need: Look at query patterns and build aggregates to speed up common queries that require summarized results Ensure that enough data is combined to offset the cost of building aggregates Monitor and adjust to account for changing query patterns

Aggregates Considerations

OBIEE10g Metadata Modeling Basics

221

Using Aggregates
Summary

In this lesson, we have learned : Describe aggregate tables and their purpose in dimensional modeling How to model aggregate tables How to use the Aggregate Persistence Wizard to automatically create
aggregates

OBIEE10g Metadata Modeling Basics

222

Using Aggregates
Labs - Overview

This lesson is accompanied with following labs: Using Aggregates tables (simplified scenario with MV usage)

OBIEE10g Metadata Modeling Basics

223

Using Repository Variables

Create session variables Create repository variables Create initialization blocks Implement a dynamic repository variable

Lesson Objectives

OBIEE10g Metadata Modeling Basics

224

Using Repository Variables

Contain values in memory that are used by the Oracle BI Server during its processing Are created and managed using the Variable Manager feature in BI Administration Tool Consist of types: Session variables (system/non-system) Repository variables Static Variables Dynamic Variables

Variables

OBIEE10g Metadata Modeling Basics

225

Using Repository Variables

Utility in BI Administration Tool that is used to define variables.

Variable Manager

OBIEE10g Metadata Modeling Basics

226

Using Repository Variables

Repository: Static Dynamic Session: System Non-system

Variable Types

OBIEE10g Metadata Modeling Basics

227

Using Repository Variables

Persist from the time BI Server is started until it is shut down Can be used instead of literals or constants in the Expression Builder in BI Administration Tool (or in Answers as filter conditions as well) 2 types of repository variables: Static Dynamic

Repository Variables

OBIEE10g Metadata Modeling Basics

228

Using Repository Variables

Are repository variables whose values are constant (literal) and do not change while BI Server is running Have values that are initialized in the Static Repository Variable dialog box

Static Repository Variables

OBIEE10g Metadata Modeling Basics

229

Using Repository Variables

Are repository variables whose values change according to a refresh schedule Values are initialized and refreshed using an initialization block

Dynamic Repository Variables

OBIEE10g Metadata Modeling Basics

230

Using Repository Variables

Persist only while a users session is active Receive values when users establish their sessions 2 types of session variables: System Non-system

Session Variables

OBIEE10g Metadata Modeling Basics

231

Using Repository Variables

Predefined session variables reserved for specific purposes Have reserved names, which cannot be used for other kinds of variables Example: USER Refer to BI Server Administration guide for complete list and description

System Session Variables

OBIEE10g Metadata Modeling Basics

232

Using Repository Variables

Are application-specific variables that are created by the implementation team Example: Capture the users Region and limit the records the user sees to only
those for that Region

Non-System Session Variables

OBIEE10g Metadata Modeling Basics

233

Using Repository Variables

Are used to initialize system and non-system session variables, as well as dynamic repository variables Specify SQL to be run to populate one or more variables by accessing data sources Are invoked at BI Server startup and are periodically rerun to refresh values for
dynamic variables according to an established schedule

Initialization Blocks

OBIEE10g Metadata Modeling Basics

234

Using Repository Variables

Determine the latest dates contained in the source data and store it in variables

Initialization Block: Example

OBIEE10g Metadata Modeling Basics

235

Using Repository Variables


Initialization Block Example: Edit Data Source

OBIEE10g Metadata Modeling Basics

236

Using Repository Variables


Initialization Block Example: Edit Data Target

OBIEE10g Metadata Modeling Basics

237

Using Repository Variables

Use a variable (dynamic repository variable) to dynamically determine latest


month loaded into SALES fact table.

XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

238

Using Repository Variables

1. Open the Variable Manager 2. Create an initialization block 3. Edit the data source 4. Edit the data target 5. Test the initialization block query 6. Verify the initialization 7. Test in query filter

Implementation Steps

OBIEE10g Metadata Modeling Basics

239

Using Repository Variables

In BI Administration Tool, select Manage > Variables

1. Open the Variable Manager

OBIEE10g Metadata Modeling Basics

240

Using Repository Variables

In the Variable Manager, select Action > New > Repository > Initialization Block
to open the Repository Variable Init Block dialog box

2. Create an Initialization Block

OBIEE10g Metadata Modeling Basics

241

Using Repository Variables

Click the Edit Data Source button to navigate to the Repository Variable Init
Block Data Source dialog box

3. Edit the Data Source

OBIEE10g Metadata Modeling Basics

242

Using Repository Variables

Click the Edit Data Target button to navigate to Repository Variable Init Block
Variable Target dialog box

4. Edit the Data Target

OBIEE10g Metadata Modeling Basics

243

Using Repository Variables

Click the Edit Data Source button to navigate to Repository Variable Init Block
Data Source dialog box

5. Test the Initialization Block Query

OBIEE10g Metadata Modeling Basics

244

Using Repository Variables

Check the query log to verify that the variable is initialized and is used properly
on BI Server startup

6. Verify the Initialization

OBIEE10g Metadata Modeling Basics

245

Using Repository Variables

Check the query log to verify that the variable is initialized and is used properly
on BI Server startup

6. Verify the Initialization

OBIEE10g Metadata Modeling Basics

246

Using Repository Variables

Test dynamic repository variable in Answers - using in request filter condition

7. Test in query filter

OBIEE10g Metadata Modeling Basics

247

Using Repository Variables


Summary

In this lesson, we have learned : How to create session variables How to create repository variables How to create initialization blocks How to implement a dynamic repository variable

OBIEE10g Metadata Modeling Basics

248

Using Repository Variables


Labs - Overview

This lesson is accompanied with following labs: Using Dynamic Repository Variables as Filters

OBIEE10g Metadata Modeling Basics

249

Modeling Time Series Data

Describe the use of time comparisons for business analysis Implement time comparison measures in the business model using the time
series functions

Lesson Objectives

OBIEE10g Metadata Modeling Basics

250

Modeling Time Series Data

Provide the ability to compare business performance (measures) with prior time periods Allows you to analyze data spanning multiple time periods Example: Compare this years Revenue and last years Revenue

Time Comparisons

OBIEE10g Metadata Modeling Basics

251

Modeling Time Series Data

There is no direct way in SQL to do this type of analysis in a single SQL query Requires three separate queries to be sent to the database

Business Challenge: Time Comparisons

OBIEE10g Metadata Modeling Basics

252

Modeling Time Series Data

Use Oracle BI repository to model time series data

Oracle BI Solution: Model Time Comparisons

OBIEE10g Metadata Modeling Basics

253

Modeling Time Series Data

BI Server provides Ago and ToDate functions for time series comparisons: Ago function Calculates aggregated value as of some time period shifted from the current time ToDate function Aggregates a measure attribute from the beginning of a specified time
period to the currently displayed time

Oracle BI Solution: Time Series Functions

OBIEE10g Metadata Modeling Basics

254

Modeling Time Series Data

BI Server provides Ago and ToDate functions for time series comparisons: Ago function Calculates aggregated value as of some time period shifted from the current time ToDate function Aggregates a measure attribute from the beginning of a specified time
period to the currently displayed time

Oracle BI Solution: Time Series Functions

OBIEE10g Metadata Modeling Basics

255

Modeling Time Series Data

XYZ Selling Tigers wants to implement new measures in the business model to compare Amount Sold performance this month to performance a month ago Show Amount Sold a month ago Show Month Ago absolute change for Amount Sold Show Month Ago percentage absolute change for Amount Sold Show to date (Year To Date - YTD) value for Amount Sold

XYZ Selling Tigers Scenario

OBIEE10g Metadata Modeling Basics

256

Modeling Time Series Data

1. Identify time dimension and chronological keys 2. Create the Ago measure 3. Use existing columns to create additional Ago measures 4. Create the ToDate measure 5. Add new measures to the Presentation layer 6. Test the results in Answers

Steps to Model Time Series Data/Calculations

OBIEE10g Metadata Modeling Basics

257

Modeling Time Series Data

Mark Time dimension and set chronological keys for all levels in Time dimension

1. Identify Time Dimension and Chronological Keys

OBIEE10g Metadata Modeling Basics

258

Modeling Time Series Data

Use the Expression Builder to build the Ago function with the form:
Ago(<measure>,<time level>,<number to shift>)

2. Create the Ago Measure

OBIEE10g Metadata Modeling Basics

259

Modeling Time Series Data

Use the existing Ago measure to build Change and Percent Change measures
(you can use Calculation Wizard to automate creation of comparison measures)

3. Use Existing Columns to Create Additional Ago Measures

OBIEE10g Metadata Modeling Basics

260

Modeling Time Series Data

Use the Expression Builder to build the ToDate function with the form:
ToDate(<measure>,<time level>)

4. Create the ToDate Measure

OBIEE10g Metadata Modeling Basics

261

Modeling Time Series Data

Add new time series measures to the Presentation layer so that users can
include them in query criteria

5. Add New Measures to the Presentation Layer

OBIEE10g Metadata Modeling Basics

262

Modeling Time Series Data

Create requests in Answers and verify the results

6. Test the Results in Answers

OBIEE10g Metadata Modeling Basics

263

Modeling Time Series Data


Summary

In this lesson, we have learned : How to describe the use of time comparisons for business analysis How to implement time comparison measures in the business model using
the time series functions

OBIEE10g Metadata Modeling Basics

264

Modeling Time Series Data


Labs - Overview

This lesson is accompanied with following labs: Creating Time Series Comparison Measures

OBIEE10g Metadata Modeling Basics

265

Security Basics

Define users and groups Set permissions for users and groups to control access to repository objects Explain group inheritance This training does not cover Advanced security topics (different authentication methods, row-level security, query limits) Security for OBIEE front-end (permissions to web catalog objects, privileges
to end-use functionalities)

Lesson Objectives

OBIEE10g Metadata Modeling Basics

266

Security Basics

Only qualified persons should have access rights to data analysis applications Data needs to be protected so that only authorized employees can access sensitive information Employees should automatically see the information that is relevant to their
roles

Business Challenge

OBIEE10g Metadata Modeling Basics

267

Security Basics

Provides ability to authenticate users through logon Controls user access to data Secures access control on object and data levels

Business Solution: Oracle BI Security

OBIEE10g Metadata Modeling Basics

268

Security Basics

Is a utility in the Administration Tool that displays all the security information for
a repository

Security Manager

OBIEE10g Metadata Modeling Basics

269

Security Basics

User accounts can be defined explicitly in: BI Server repository External source (such as a database table or an LDAP server) additional work needed not covered within this training Users must be authenticated by BI Server for a session to take place.

Working with Users

OBIEE10g Metadata Modeling Basics

270

Security Basics
Adding a User to a Repository

OBIEE10g Metadata Modeling Basics

271

Security Basics

You can set repository permissions for: Catalogs, Tables or Columns in the Presentation layer Connection pools in the Physical layer Permissions can be undefined, read, or access explicitly denied

Setting User Permissions

OBIEE10g Metadata Modeling Basics

272

Security Basics

Is a default, permanent user account in every BI Server repository Cannot be deleted or modified other than to change the password and setting logging level Belongs to Administrators group by default

Administrator Account

OBIEE10g Metadata Modeling Basics

273

Security Basics

Group is a set of security attributes Use Security Manager to create groups and then grant membership in them to users or other groups Used for simplification of permission/privileges maintenance Administration of group membership can be externalized (not covered in this
training)

Working with Groups

OBIEE10g Metadata Modeling Basics

274

Security Basics

Is a predefined group with authority to access and modify any object in a repository Administrator user is automatically a member

Administrators Group

OBIEE10g Metadata Modeling Basics

275

Security Basics

You can create an unlimited number of groups in a repository Each group can contain: Explicitly granted privileges Implicitly granted privileges through membership in another group

Defined Groups

OBIEE10g Metadata Modeling Basics

276

Security Basics
Group Inheritance

OBIEE10g Metadata Modeling Basics

277

Security Basics
Adding a New Group

OBIEE10g Metadata Modeling Basics

278

Security Basics

Click the hierarchy icon in the left pane of the Security Manager, and then
expand the tree in the right pane

Viewing Member Hierarchies

OBIEE10g Metadata Modeling Basics

279

Security Basics

Is the process by which a system verifies (with a user ID and password) that a user has the necessary permissions and authorizations to log on and access data BI Server authenticates each connection request that it receives

Authentication

OBIEE10g Metadata Modeling Basics

280

Security Basics

BI Server supports the following authentication types: Operating system External table LDAP Database Internal

Authentication Options

OBIEE10g Metadata Modeling Basics

281

Security Basics

BI Server supports Windows Unified Logon If a user is configured on a trusted Windows domain, BI Server user of the same name does not need to be authenticated by BI Server The user ID in the repository must match the user ID in the trusted Windows domain Rarely used in practice

Operating System Authentication

OBIEE10g Metadata Modeling Basics

282

Security Basics

Instead of storing IDs and passwords in a repository, maintain lists of users and passwords in an external database table Use Oracle BI session variables to get values Could be potential security danger external table stores users passwords

External Table Authentication

OBIEE10g Metadata Modeling Basics

283

Security Basics

Very common method in OBIEE implementations Instead of storing IDs and passwords in a repository, BI Server passes the user ID and password entered by the user to an LDAP server for authentication Use Oracle BI session variables to get authentication values Active Directory could be used as an LDAP

LDAP Authentication

OBIEE10g Metadata Modeling Basics

284

Security Basics

Authenticates users through database logons To set up database authentication: Store user IDs (without passwords) in a repository Import database to the repository Specify authentication database in NQSConfig.ini

Database Authentication

OBIEE10g Metadata Modeling Basics

285

Security Basics

Maintain lists of users and passwords in the repository using BI Administration Tool Oracle BI Server authenticates against this list unless: Another authentication method has already succeeded Database authentication is specified in NQSConfig.ini User IDs are non-encrypted and non-case-sensitive Passwords are encrypted and case-sensitive Users can access any business model if they have the necessary access privileges Users do not span repositories

Internal Authentication

OBIEE10g Metadata Modeling Basics

286

Security Basics

1. Operating system (OS): No logon name Turned on in NQSConfig.ini 2. LDAP or external database table Populates session variables 3. Internal or database

Order of Authentication

OBIEE10g Metadata Modeling Basics

287

Security Basics
Summary

In this lesson, we have learned : How to define users and groups How to set permissions for users and groups to control access to repository objects Explain group inheritance Identify and describe the authentication methods used by Oracle BI Server

OBIEE10g Metadata Modeling Basics

288

Security Basics
Labs - Overview

This lesson is accompanied with following labs: Creating Users and Groups Setting Permissions for Users and Groups

OBIEE10g Metadata Modeling Basics

289

You might also like