Oracle Bi 11g r1 Build Repositories Ed 1.1 Student Guide - Volume 2 d63514gc11_sg2

8/11/2019 Oracle Bi 11g r1 Build Repositories Ed 1.1 Student Guide - Volume 2 d63514gc11_sg2

1/449

Oracle BI 11gR1: Build

Repositories

Volume II - Student Guide

D63514GC11

Edition 1.1

June 2011

D73310


2/449

Copyright 2011, Oracle and/or it affiliates. All rights reserved.

Disclaimer

This document contains proprietary information and is protected by copyright and

other 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. 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, transmit, or distribute this document in whole or in part without

the express authorization of Oracle.

The information contained in this document is subject to change without notice. If you

find any problems in the document, please report them in writing to: Oracle University,

500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not

warranted to be error-free.

Restricted Rights Notice

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

applicable:

U.S. GOVERNMENT RIGHTS

The U.S. Governments rights to use, modify, reproduce, release, perform, display, or

disclose these training materials are restricted by the terms of the applicable Oracle

license agreement and/or the applicable U.S. Government contract.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names

may be trademarks of their respective owners.

Author

Jim Sarokin

Technical Contributors

and Reviewers

Marla Azriel

Roger BolsiusBob Ertl

Alan Lee

Monica Moore

Kasturi Shekhar

Aneel Shenker

Scott Silbernick

Nick Tuson

Krishnan Viswanathan

Graphic Designer

Rajiv Chandrabhanu

Editors

Aju Kumar

Daniel Milne

Richard Wallis

Publishers

Syed Ali

Giri Venugopal


3/449

iii

Contents

1 Course Introduction

Lesson Agenda 1-2

Instructor and Class Participants 1-3

Training Site Information 1-4

Course Audience 1-5

Course Prerequisites 1-6

Course Goal 1-7

Course Objectives 1-8

Course Methodology 1-12

Course Materials 1-13Course Agenda 1-14

Summary 1-19

2 Repository Basics

Objectives 2-2

Oracle BI Server Architecture 2-3

Oracle BI Presentation Services 2-4

Oracle BI Server 2-5

Data Sources 2-6

Oracle BI Repository 2-7

Oracle BI Administration Tool 2-8

Physical Layer 2-9

Objects in the Physical Layer 2-10

Business Model and Mapping Layer 2-11

Objects in the Business Model and Mapping Layer 2-12

Business Model Mappings 2-13

Measures 2-15

Presentation Layer 2-16

Presentation Layer Mappings 2-17

Presentation Layer Defines the User Interface 2-18

Repository Directory 2-19

Repository Modes 2-20

Publishing a Repository 2-21

Using FMW Control to Manage OBI Components 2-22

Reloading Server Metadata 2-23


4/449

iv

Sample Analysis Processing 2-24

Summary 2-25

Practice 2-1 Overview: Exploring an Oracle BI Repository 2-26

3 Building the Physical Layer of a Repository

Objectives 3-2

Physical Layer 3-3

Physical Layer Objects 3-4

Database Object 3-5

Database Object: General Properties 3-6

Database Object: Features 3-7

Connection Pool 3-9

Schema Folder 3-10

Physical Table 3-11

Physical Table Properties 3-12Physical Column 3-14

Key Column 3-15

Physical Table: Alias 3-16

Joins 3-17

ABC Scenario 3-18

Implementation Steps 3-19

Create a New Repository File 3-20

Provide Repository Information 3-21

Select the Data Source 3-22

Select Metadata Types for Import 3-23Select Metadata Objects for Import 3-24

Verify and Edit Connection Pool Properties 3-25

Verify Objects for Import 3-26

Verify Import in the Physical Layer 3-27

Verify Connectivity 3-28

Create Alias Tables 3-29

Define Keys and Joins 3-30

Define Keys by Using the Table Properties Dialog Box 3-31

Open the Physical Diagram 3-32

Define Foreign Key Joins 3-33

Use the Joins Manager 3-35

Design Tips for the Physical Layer 3-36

Summary 3-37

Practice 3-1 Overview: ABC Business Scenario 3-38

Practice 3-2 Overview: Gathering Information to Build an Initial Business

Model 3-39


5/449

v

Practice 3-3 Overview: Creating a Repository and Importing a Data Source 3-40

Practice 3-4 Overview: Creating Alias Tables 3-41

Practice 3-5 Overview: Defining Keys and Joins 3-42

4 Building the Business Model and Mapping Layer of a Repository

Objectives 4-2

Business Model and Mapping (BMM) Layer 4-3


Business Model Mappings 4-5


Business Model Object 4-8

Logical Tables 4-9

Logical Table Sources 4-10

Logical Table Source: Column Mappings 4-11

Logical Columns 4-12Logical Primary Keys 4-13

Logical Joins 4-14

Measures 4-15

ABC Example 4-16


1. Create the Logical Business Model 4-18

2. Create the Logical Tables and Columns 4-19

3. Define the Logical Joins 4-20

4. Modify the Logical Tables and Columns 4-21

5. Define the Measures 4-22Design Tips 4-23

Summary 4-24

Practice 4-1 Overview: Creating the Business Model 4-25

Practice 4-2 Overview: Creating Simple Measures 4-26

5 Building the Presentation Layer of a Repository

Objectives 5-2

Presentation Layer 5-3

Subject Areas 5-4

Presentation Tables 5-5

Presentation Columns 5-6

Presentation Layer Mappings 5-7

Defining the User Interface in the Presentation Layer 5-8

Nesting Presentation Tables 5-9

Aliases 5-10

ABC Example 5-11


6/449

vi


1. Create a New Subject Area 5-13

2. Rename Tables 5-14

3. Reorder Tables 5-15

4. Delete Columns 5-16

5. Rename Columns 5-17

6. Reorder Columns 5-18

Considerations 5-19

Design Tips 5-20

Summary 5-21

Practice 5-1 Overview: Creating the Presentation Layer 5-22

6 Testing and Validating a Repository

Objectives 6-2

Validating a Repository 6-3ABC Example 6-4

Consistency Check 6-5

Checking Consistency 6-6

Consistency Check Manager 6-7

Using the validaterpd Utility to Check Repository Consistency 6-8

Marking a Business Model Available for Queries 6-9

Confirming a Consistent Repository 6-10

Publishing a Repository 6-11

Using FMW Control to Start OBI Components 6-12

Query Logging 6-13Setting a Logging Level 6-14

Logging Levels 6-15

Validating by Using the Analysis Editor 6-16

Inspecting the Query Log 6-17

Viewing Log Messages 6-18

Oracle BI SELECTStatement: Syntax 6-19

Oracle BI SELECTStatement Compared with Standard SQL 6-20

Summary 6-21

Practice 6-1 Overview: Testing a Repository 6-22

7 Managing Logical Table Sources

Objectives 7-2

Table Structures 7-3

Business Challenge 7-4

Business Solution 7-5

ABC Example: Adding Multiple Sources to a Logical Table Source (LTS) 7-6


7/449

vii

Implementation Steps: Adding Multiple Sources to an LTS 7-7

1. Import Additional Product Tables 7-8

2. Create Aliases 7-9

3. Define Keys and Joins 7-10

4. Identify Physical Columns for Mappings 7-11

5. Add Sources to an LTS 7-12

5a. Manual Method: Create New Logical Column 7-13

5a. Manual Method: Add New Physical Source 7-14

5a. Manual Method: Create Column Mapping 7-15

5a. Manual Method: End Result 7-16

5b. Drag Method 7-17

5b. Drag Method: Logical Columns Added 7-18

5b. Drag Method: Physical Tables Added 7-19

5b. Drag Method: Column Mappings Added 7-20

6. Rename Logical Columns 7-217. Add Columns to the Presentation Layer 7-22

ABC Example: Adding a New Logical Table Source 7-23

Implementation Steps: Adding a New Logical Table Source 7-24

1. Examine Existing Column Mappings 7-25

2. Identify a Single Table That Stores Both Columns 7-26

3. Add a New Logical Table Source 7-27

4. Define the Content of the Logical Table Source 7-28

5. Verify Your Work 7-29

Summary 7-30

Practice 7-1 Overview: Enhancing the Product Dimension 7-31Practice 7-2 Overview: Creating Multiple Sources for a

Logical Table Source (Manual) 7-32

Practice 7-3 Overview: Creating Multiple Sources for a Logical Table

Source (Automated) 7-33

Practice 7-4 Overview: Adding a New Logical Table Source 7-34

8 Adding Calculations to a Fact

Objectives 8-2

Business Problem 8-3

Business Solution 8-4

Creating Calculation Measures by Using Existing Logical Columns 8-5

1. Create a New Logical Column 8-6

2. Specify Logical Columns as the Source 8-7

3. Build a Formula 8-8

Creating Calculation Measures by Using Physical Columns 8-9

1. Create a New Logical Column 8-10


8/449

viii

2. Map the New Column 8-11

3. Build the Formula 8-12

4. Specify an Aggregation Rule 8-13

Steps for Using the Calculation Wizard 8-14

1. Open the Calculation Wizard 8-15

2. Choose the Columns for Comparison 8-16

3. Select the Calculations 8-17

4. Confirm the Calculation Measures 8-18

5. New Calculation Measures Are Added 8-19

Add New Measures to the Presentation Layer 8-20

Examining a Query Using Physical Columns 8-21

Example: Using Physical Columns 8-22

Examining a Query Using Logical Columns 8-23

Example: Using Logical Columns 8-24

Examining a Query Using the Calculation Wizard 8-25Using Functions to Create Expressions 8-26

Summary 8-27

Practice 8-1 Overview: Creating Calculation Measures 8-28

Practice 8-2 Overview: Creating Calculation Measures by

Using the Calculation Wizard 8-29

Practice 8-3 Overview: Creating a RANKMeasure 8-30

9 Working with Logical Dimensions

Objectives 9-2

Logical Dimensions 9-3Logical Dimensions: Types 9-4

Level-Based Measures 9-5

Share Measures 9-6

Logical Dimension: Example 9-7

ABC Example 9-8

Creating a Level-Based Logical Dimension 9-9

1. Create a Logical Dimension Object 9-10

2. Add a Parent-Level Object 9-11

3. Add Child-Level Objects 9-12

4. Specify Level Columns 9-13

5. Create Level Keys 9-15

6. Set the Preferred Drill Path 9-16

7. Create Level-Based Measures 9-17

8. Create Additional Level-Based Measures 9-19

9. Create Share Measures 9-20

10. Add Measures to the Presentation Layer 9-21


9/449

ix

11. Create Presentation Hierarchies 9-22

12. Test Measures and Hierarchies 9-23

Parent-Child Logical Dimensions 9-24

Parent-Child Hierarchy: Example 9-25

Parent-Child Logical Table 9-26

Parent-Child Relationship Table 9-27

Creating a Parent-Child Logical Dimension 9-28

1. Create a Logical Dimension Object 9-29

2. Set the Member Key 9-30

3. Set the Parent Column 9-31

4. Open the Parent-Child Relationship Table Settings Dialog Box 9-32

5. Enter Parent-Child Relationship Table Script Information 9-33

6. Enter Parent-Child Relationship Table Details 9-34

7. Preview Scripts 9-35

8. Confirm Parent-Child Relationship Table Settings 9-369. Confirm Changes to the BMM Layer 9-37

10. Confirm Changes to the Physical Layer 9-38

11. Modify the Physical Layer 9-39

12. Modify the BMM Layer 9-40

13. Create the Presentation Hierarchy 9-41


Calculated Members 9-43

Summary 9-44

Practice 9-1 Overview: Creating Logical Dimension Hierarchies 9-45

Practice 9-2 Overview: Creating Level-Based Measures 9-46Practice 9-3 Overview: Creating Share Measures 9-47

Practice 9-4 Overview: Creating Dimension-Specific Aggregation Rules 9-48

Practice 9-5 Overview: Creating Presentation Hierarchies 9-49

Practice 9-6 Overview: Creating Parent-Child Hierarchies 9-50

Practice 9-7 Overview: Using Calculated Members 9-51

10 Using Aggregates

Objectives 10-2


Business Solution: Aggregate Tables 10-4

Oracle BI Aggregate Navigation 10-5

Aggregated Facts 10-6

Modeling Aggregates 10-7

ABC Example 10-8

Steps to Implement Aggregate Navigation 10-9

1. Import Tables and Create Aliases 10-10


10/449

x

2. Create Joins 10-11

3. Create the Fact Logical Table Source and Mappings 10-12

4. Specify the Fact Aggregation Content 10-13

5. Specify Content for the Fact Detail Source 10-14

6. Create the Dimension Logical Table Source and Mappings 10-15

7. Specify the Dimension Aggregation Content 10-16

8. Specify Content for the Dimension Detail Source 10-17

9. Test Results for Levels Stored in Aggregates 10-18

10. Test Results for Data Above or Below Levels 10-19

Setting the Number of Elements 10-20

Aggregate Persistence Wizard 10-22

Aggregate Persistence Wizard Steps 10-23

1. Open the Aggregate Persistence Wizard 10-24

2. Specify a File Name and Location 10-25

3. Select the Business Model and Measures 10-264. Select Dimensions and Levels 10-27

5. Select the Connection Pool, Container, and Name 10-28

6. Review the Aggregate Definition 10-29

7. View the Complete Aggregate Script 10-30

8. Verify That the Script Is Created 10-31

9. Run the Aggregate Persistence Script 10-32

10. Verify Aggregates in the Physical Layer 10-33

11. Verify Aggregates in the BMM Layer 10-34

12. Verify Aggregates in the Database 10-35

13. Verify Your Work 10-36Troubleshooting Aggregate Navigation 10-37

Considerations 10-38

Summary 10-39

Practice 10-1 Overview: Using Aggregate Tables 10-40

Practice 10-2 Overview: Setting the Number of Elements 10-41

Practice 10-3 Overview: Using the Aggregate Persistence Wizard 10-42

11 Using Partitions and Fragments

Objectives 11-2


Business Solution: Oracle BI Server 11-4

Partition 11-5

Partitioning by Fact 11-6

Partitioning by Value 11-7

Partitioning by Level 11-8

Complex Partitioning 11-9


11/449

xi

ABC Example: Value Based (Order Date) 11-10


Specify Fragmentation Content 11-12

Summary 11-13

Practice 11-1 Overview: Modeling a Value-Based Partition 11-14

12 Using Repository Variables

Objectives 12-2

Variables 12-3

Variable Manager 12-4

Variable Types 12-5

Repository Variables 12-6

Static Repository Variables 12-7

Dynamic Repository Variables 12-8

Session Variables 12-9System Session Variables 12-10

Non-System Session Variables 12-11

Initialization Blocks 12-12

Initialization Block: Example 12-13

Initialization Block Example: Edit Data Source 12-14

Initialization Block Example: Edit Data Target 12-15

ABC Example 12-16


1. Create a Dedicated Connection Pool 12-18

2. Open the Variable Manager 12-193. Create an Initialization Block 12-20

4. Edit the Data Source 12-21

5. Edit the Data Target 12-22

6. Test the Initialization Block Query 12-23

7. Use the Variable to Determine Content 12-24


Summary 12-26

Practice 12-1 Overview: Creating Dynamic Repository Variables 12-27

Practice 12-2 Overview: Using Dynamic Repository Variables as Filters 12-28

13 Modeling Time Series Data

Objectives 13-2

Time Comparisons 13-3

Business Challenge: Time Comparisons 13-4

Oracle BI Solution: Model Time Comparisons 13-5

Time Dimensions 13-6


12/449

xii

Time Series Functions 13-7

Time Series Grains 13-8

ABC Example 13-10

Steps to Model Time Series Data 13-11

1. Identify a Time Dimension and Chronological Keys 13-12

2. Create a Measure by Using the AGOFunction 13-13

3. Use a Column with the AGOFunction to Create Additional Measures 13-14

4. Create a Measure by Using the TODATEFunction 13-15

5. Create a Measure by Using the PERIODROLLINGFunction 13-16

6. Add New Measures to the Presentation Layer 13-17

7. Test the Results 13-18

Summary 13-19

Practice 13-1 Overview: Creating Time Series Comparison Measures 13-20

14 Modeling Many-to-Many RelationshipsObjective 14-2

Business Challenge and Solution 14-3

Bridge Table 14-4

ABC Example 14-5

Steps to Model a Bridge Table 14-6

1. Import Tables 14-7

2. Create the Physical Model 14-8

3. Create the Logical Model 14-9

4. Map the Bridge Table 14-10

5. Create a Calculation Measure 14-11

6. Map Objects to the Presentation Layer 14-12

7. Verify the Results 14-13

Summary 14-14

Practice 14-1 Overview: Modeling a Bridge Table 14-15

15 Localizing Oracle BI Metadata

Objective 15-2

Business Challenges and Solution 15-3

Oracle BI Multilingual Support 15-4

Configuring Oracle BI Metadata 15-5

WEBLANGUAGESession Variable 15-6

LOCALEConfiguration Setting 15-7

Changing Localization Preferences 15-8

ABC Example 15-9

Steps to Localize Metadata 15-10


13/449

xiii

1. Externalize Metadata Objects 15-11

2. Run the Externalize Strings Utility 15-12

3. Modify the Translation File 15-13

4. Load the Translation Table 15-14

5. Import the Translation Table 15-15

6. Create a Dedicated Connection Pool 15-16

7. Create an Initialization Block 15-17

8. Modify My Account Preferences 15-18

9. Verify the Translations 15-19

Summary 15-20

Practice 15-1 Overview: Localizing Repository Metadata 15-21

16 Localizing Oracle BI Data

Objective 16-2

Business Challenges and Solution 16-3Oracle BI Multilingual Data Support 16-4

What Is Multilingual Data Support? 16-5

Required Translation Tables 16-6

Available Language Table 16-7

Lookup Tables 16-8

Designing Translation Lookup Tables 16-9

ABC Example 16-10

Steps for Localizing Data 16-11

1. Create a Physical Lookup Table 16-12

2. Create an Available Language Table 16-133. Import Tables into the Physical Layer 16-14

4. Create a Session Variable Initialization Block 16-15

5. Create a Logical Lookup Table 16-16

6. Set Keys for the Logical Lookup Table 16-17

7. Create a Logical Lookup Column 16-18

8. Add the Logical Lookup Column to the Presentation Layer 16-19

9. Test Your Work 16-20

Summary 16-21

Practice 16-1 Overview: Localizing Oracle BI Data 16-22

17 Setting an Implicit Fact Column

Objectives 17-2

Business Challenge: Dimension-Only Queries 17-3

Business Solution: Implicit Fact Column 17-4

ABC Example 17-5

Steps to Configure an Implicit Fact Column 17-6


14/449

xiv

1. Set an Implicit Fact Column 17-7


3. Clear the Implicit Fact Column 17-9

Summary 17-10

Practice 17-1 Overview: Setting an Implicit Fact Column 17-11

18 Importing Metadata from Multidimensional Data Sources

Objective 18-2

Overview 18-3

Multidimensional Versus Relational Data Sources 18-4

Overview: Importing Multidimensional Data Sources 18-5

ABC Example 18-6

Creating a Multidimensional Business Model 18-7

1. Set Up an Essbase Data Source 18-8

2. Import Metadata 18-93. Verify the Import 18-10

4. Choose Options to Control the Model 18-11

5. View Members and Update Member Count 18-12

6. Create the Business Model 18-13

7. Create the Presentation Layer 18-14


Horizontal Federation 18-16

Vertical Federation 18-17

Summary 18-18

Practice 18-1: Importing a Multidimensional Data Source into a Repository 18-19Practice 18-2: Incorporating Horizontal Federation into a Business Model 18-20

Practice 18-3: Incorporating Vertical Federation into a Business Model 18-21

Practice 18-4: Adding Essbase Measures to a Relational Model 18-22

19 Security

Objectives 19-2

Business Challenge: Security Strategy 19-3

Business Solution: Oracle BI Security 19-4

Managing Oracle BI Security 19-5

Oracle BI Default Security Model 19-6

Default Security Realm 19-7

Default Authentication Providers 19-8

Default Users 19-9

Default Groups 19-10

Default Application Roles 19-11

Default Application Policies 19-13


15/449

xv

Default Security Settings in the Repository 19-14

Default Application Role Hierarchy: Example 19-15

ABC Example 19-16

Create Groups 19-17

Create Group Hierarchies 19-18

Create Users 19-19

Assign Users to Groups 19-20

Create Application Roles 19-21

Map Application Roles 19-22

Application Role Hierarchies 19-23

Verify Security Settings in Oracle BI 19-24

Verify Security Settings in the Repository 19-26

Set Up Object Permissions 19-27

Permission Inheritance 19-28

Permission Inheritance: Example 19-29Set Row-Level Security (Data Filters) 19-30

Set Query Limits 19-31

Set Timing Restrictions 19-32

Summary 19-33

Practice 19-1 Overview: Exploring Default Security Settings 19-34

Practice 19-2 Overview: Creating Users and Groups 19-35

Practice 19-3 Overview: Creating Application Roles 19-36

Practice 19-4 Overview: Setting Up Object Permissions 19-37

Practice 19-5 Overview: Setting Row-Level Security (Data Filters) 19-38

Practice 19-6 Overview: Setting Query Limits and Timing Restrictions 19-39

20 Cache Management

Objective 20-2


Business Solution: Oracle BI Server Query Cache 20-4

Advantages of Caching 20-5

Costs of Caching 20-6

Query Cache: Architecture 20-7

Monitoring and Managing the Cache 20-8

Cache Management Techniques 20-9

Using Fusion Middleware Control to Configure Caching 20-10

Using NQSConfig.inito Manually Edit Cache Parameters 20-11

Setting Caching and Cache Persistence for Tables 20-12

Using the Cache Manager 20-13

Inspecting SQL for Cache Entries 20-14

Modifying the Cache Manager Column Display 20-15


16/449

xvi

Inspecting Cache Reports 20-16

Purging Cache Entries Manually Using the Cache Manager 20-17

Purging Cache Entries Automatically 20-18

Using Event Polling Tables 20-19

Seeding the Cache 20-20

Cache Hit Conditions 20-21

Summary 20-22

Practice 20-1 Overview: Enabling Query Caching 20-23

Practice 20-2 Overview: Modifying Cache Parameters 20-24

Practice 20-3 Overview: Seeding the Cache 20-25

21 Managing Usage Tracking

Objectives 21-2

Business Challenges 21-3

Business Solution: Oracle BI Usage Tracking 21-4Oracle BI Usage Tracking Methods 21-5

ABC Example 21-6

Steps to Enable Usage Tracking 21-7

1. Create the Usage Tracking Table 21-8

2. Import the Usage Tracking Table 21-9

3. Build a Usage Tracking Business Model 21-10

4. Enable Usage Tracking 21-11

5. Enable Direct Insertion 21-12

6. Set the Physical Table Parameter 21-13

7. Set the Connection Pool Parameter 21-148. Set Additional Parameters 21-15

9. Test the Results 21-16

Analyzing Usage Tracking Data 21-17

Summary 21-18

Practice 21-1 Overview: Setting Up Usage Tracking 21-19

22 Setting Up and Using the Multiuser Development Environment

Objectives 22-2


Business Solution: Oracle BI Multiuser Development Environment (MUDE) 22-4

Oracle BI Repository Development Process 22-5

SCM Three-Way Merge Process 22-6

Oracle BI Repository Three-Way Merge Process 22-7

Multiuser Development Projects 22-8

Overview: Oracle BI Multiuser Development 22-9

ABC Example 22-10


17/449

xvii

Steps to Set Up an Oracle BI MUDE 22-11

1. Create Projects 22-12

2. Edit Projects 22-13

3. Set Up a Shared Network Directory 22-14

4. Copy the Master Repository to the Shared Directory 22-15

Making Changes in an Oracle BI MUDE 22-16

1. Point to the Multiuser Directory 22-17

2. Check Out Projects 22-18

3. Administration Tool Tasks During Checkout 22-19

4. Change Metadata 22-20

5. Multiuser Options During Development 22-21

6. Merge Local Changes 22-22

7. Make Merge Decisions 22-23

8. Publish to Network 22-24

9. Track Project History 22-25History Menu Options 22-26

Deleting History Items 22-27

Summary 22-28

Practice 22-1 Overview: Setting Up a Multiuser Development

Environment 22-29

Practice 22-2 Overview: Using a Multiuser Development Environment 22-30

23 Configuring Write Back in Analyses

Objectives 23-2

Write Back in Analyses 23-3Steps to Configure Write Back 23-4

1. Create a Physical Table with Write Back Columns 23-5

2. Import the Write Back Table 23-6

3. Enable Write Back for the Connection Pool 23-7

4. Enable Write Back for Logical Columns 23-9

5. Set Write Back Permissions in the Presentation Layer 23-10

6. Enable Write Back in instanceconfig.xml 23-11

7. Create a Write Back XML Template 23-12

8. Store the Write Back Template 23-14

9. Grant Write Back Privileges 23-15

10. Create an Analysis with Columns Enabled for Write Back 23-16

11. Override Default Data Format 23-17

12. Enable Write Back in the Table View 23-18

13. Verify Results 23-19

Summary 23-20

Practice 23-1 Overview: Configuring Write Back 23-21


18/449

xviii

24 Performing a Patch Merge

Objectives 24-2

Patch Merge 24-3

Creating a Patch 24-4

Applying a Patch 24-5

Steps to Perform a Patch Merge 24-6

1. Compare Current and Original Repositories 24-7

2. Equalize Objects 24-8

3. Create a Patch 24-9

4. Apply the Patch 24-10

5. Make Merge Decisions 24-11


Summary 24-13

Practice 24-1 Overview: Performing a Patch Merge 24-14

25 Configuring Logical Columns for Multicurrency Support

Objectives 25-2

Overview 25-3

Steps to Configure Multicurrency Support 25-4

1. Modify the User Preferences Currency File 25-5

2. Create a PREFERRED_CURRENCYSession Variable 25-6

3. Create Logical Columns with Currency Conversions 25-7

4. Edit a Logical Column to Use a Conversion Factor 25-8

4. Add Logical Column to the Presentation Layer 25-95. Verify the My Account Page 25-10

5. Verify Analysis Results 25-11

Summary 25-12

Practice 25-1 Overview: Defining User-Preferred Currency Options 25-13

26 Using Administration Tool Utilities

Objectives 26-2

Wizards and Utilities 26-3

Accessing Wizards and Utilities 26-4

Managing Sessions 26-5

Querying Repository Metadata 26-6

Replacing Columns or Tables 26-7

Documenting a Repository 26-8

Generating a Metadata Dictionary 26-9

Creating an Event Table 26-10

Updating the Physical Layer 26-11


19/449

xix

Removing Unused Physical Objects 26-12

Summary 26-13

27 Oracle BI 11gR1: Build Repositories Quizzes

A Optimizing Query Performance

Objective A-2

Business Challenge A-3

Business Solution A-4

Oracle BI Features That Optimize Performance A-6

Optimizing Query Performance A-7

Using Aggregates A-8

Using Aggregate Navigation A-9

Constraining Results by Using a WHEREClause A-10

Caching A-11Limiting the Number of Initialization Blocks A-12

Limiting Select Table Types A-13

Modeling Logical Dimension Hierarchies Correctly A-14

Turning Off Logging A-15

Setting Query Limits A-16

Pushing Calculations to the Database A-17

Exposing Materialized Views in the Physical Layer A-18

Using Database Hints A-19

Summary A-20

B Model First Development Methodology

Model First Development Methodology: Overview B-2

Central Tenets of the Model First Development Methodology B-3

Baseline Performance Analysis B-4

Defining the Business Model: Dimensional Matrix B-6

Dimensional Matrix: Example B-7

Drill to Levels for More-Detailed Performance Requirements B-8

Focus on the Business Model B-9

Leverage Oracle BI Legless Applications B-10

Use Oracle BI Data Mart Automation B-11


20/449


21/449

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

Security


22/449Oracle BI 11gR1: Build Repositories 19 - 2


Objectives

After completing this lesson, you should be able to:

Identify and describe default security settings for Oracle BI Create users and groups

Create application roles

Set up permissions for repository objects

Use query limits, timing restrictions, and filters to control

access to repository information


23/449

Business Challenge: Security StrategyAn organizations business needs guide its security strategy. Every organization has unique

information-protection requirements, and each security strategy must be individually designedto match. Many security strategy designs start with answers to the questions listed in the

slide.

Oracle BI 11gR1: Build Repositories 19 - 3


Business Challenge: Security Strategy

Security strategy designs for a business start with answers to

these basic questions: Who will have access to company data and business resources?

Under what conditions will access be limited or denied?

How will access be enforced?

How will users authenticate themselves?

Where will credentials be stored?


24/449

Business Solution: Oracle BI SecuritySecuring Oracle Business Intelligence can be divided into two broad areas: controlling access

to the components within the BI domain (resource access security) and controlling access tobusiness source data (data access security).

Controlling access to system resources is achieved by requiring users to authenticate at login

and by restricting users to only those resources for which they are authorized. The Oracle BIdefault security model is available for immediate implementation after installation. This model

includes controls for managing user identities, credentials, and permission grants. This allowsyou to control system access by validating identity at login (authentication) and control access

to specific Oracle BI components and features according to a users permission grants

(authorization).

Note: This course highlights the security components that relate to building and managing an

Oracle BI repository. However, Oracle BI Security is a complex subject that involves

installation and configuration tasks that are beyond the scope of this course. For more

detailed information, please refer to the Security Guide for Oracle Business Intelligence

Enterprise Edition.



Business Solution: Oracle BI Security

Controls access to system resources:

Requires users to authenticate at login Restricts users to only those resources for which they are

authorized

Manages user identities, credentials, and permission

grants


25/449

Managing Oracle BI SecurityOracle BI software integrates seamlessly with the Oracle Fusion Middleware platform. They

share a common security framework and features. This common security configuration usesOracle WebLogic Server as the default administration server. However, these implementation

details are largely hidden while performing daily administrative tasks and are exposed only by

the tools used to manage your Oracle BI security configuration.



Managing Oracle BI Security

Oracle BI integrates with Oracle Fusion Middlewares security

platform. Oracle WebLogic Server Administration Console

Management of users and groups for the embedded LDAP

server that serves as the default identity store

Oracle Fusion Middleware Control

Management of policy store application roles that grant

permissions to users, groups, and other application roles

Oracle BI Administration Tool

Management of permissions for Presentation layer objects

and business model objects in the repository


26/449

Oracle BI Default Security ModelThe security controls include:

An embedded directory server functioning as an identity store designed to hold all user

and group definitions that are required to control authentication

A file-basedpolicy store designed to hold the application-role and permission-grant

mappings to users and groups that are required to control authorization

A file-basedcredential store designed to hold user and system credentials

When operating in a development or test environment, you may find it convenient to use thedefault security model because it comes preconfigured. You then add user definitions and

credentials that are specific to your business as well as customize the default applicationroles and permission grants that your business security policies require. After the identity,

policy, and credential stores are fully configured and populated with data that is specific toyour business, they provide all user, policy, and credential information needed by the Oracle

BI components during authentication and authorization.

The following slides cover the key components of the default security model.



Oracle BI Default Security Model

During installation, three Oracle BI security controls are

preconfigured with initial (default) values to form the defaultsecurity model:

Identity store

Contains the definitions of users, groups, and group

hierarchies required to control authentication

Policy store

Contains the definition of application roles, the permissions

granted to the roles, and the members (users, groups, and

applications roles) of the roles

Credential store

Stores security-related credentials, such as user name and

password combinations, for accessing an external system

(such as a database or LDAP server)


27/449

Default Security RealmThe screenshot shows the default setting for the Oracle BI WebLogic security realm in the

Oracle WebLogic Server Administration Console. Using a browser, you can access theAdministration Console with the following URL: http://:7001/console.

On the left side of the console, under Domain Structure, notice that there is a single WebLogicdomain named bifoundation_domain into which all of the BI applications are deployed.

Notice also 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 WebLogicresources. This includes users, groups, security roles, security policies, and security

providers. Whereas multiple security realms can be defined for the BI domain, only one canbe active (that is, only one can be designated as the default realm at any given time).

Click myrealm to view its default settings.



Default Security Realm

BI domain

Default security realm

Select to view

security realms.


28/449

Default Authentication ProvidersThis screenshot shows the default settings for authentication providers in the defaultmyrealm security realm. Note 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 from which components can retrieve identity

information.

Oracle BI is configured out of the box to use the directory server embedded in Oracle

WebLogic Server as the default security provider. When a user logs in to a system with a username and password combination, Oracle WebLogic Server validates identity based on the

combination provided. Alternative security providers can be used if desired and managed in

the Oracle WebLogic Administration Console, but the WebLogic Authentication Provider isused by default.

Note: There is a default WebLogic Identity Assertion Provider, which is used primarily for

Single Sign On and is not covered in this training.



Default Authentication Providers

Default

authentication

provider


29/449


30/449


31/449

Default Application Roles

An application role defines a set of permissions that are granted to a user or group.Application roles are defined in Fusion Middleware Control which can be accessed viahttp://:7001/em. To access the Application Roles page, right-clickcoreapplication in the left pane and select Security > Application Roles (not shown here).

The file-based policy store contains a default application role hierarchy that includespreconfigured permissions grants and role membership definitions. Application role memberscan include users or groups from the identity store or other application roles from the policystore.

Default application roles include:

BISystem: Grants the permissions necessary to impersonate other users. This role isrequired by Oracle BI system components for intercomponent communication.

BIAdministrator: Grants the administrative permissions necessary to configure andmanage the Oracle BI installation. Any member of the BIAdministrators group isexplicitly granted this role and implicitly granted the BIAuthor and BIConsumer roles.

BIAuthor: Grants the permissions necessary to create and edit content for other usersto use (or to consume). Any member of the BIAuthors group is explicitly granted this roleand implicitly granted the BIConsumer role.

BIConsumer: Grants the permissions necessary to use (or to consume) content createdby other users



Default Application Roles

Default

application roles


32/449

Default Application Roles (continued)

These default application roles map to default groups in the default WebLogic LDAP. The

groups are listed in the Members column. Application roles are independent of LDAP groups.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. The default naming convention is that

application role names are singular and group names are plural.



33/449

Default Application PoliciesApplication policies are the authorization policies that an application relies upon for controlling

access to its resources. Application policies are defined in Fusion Middleware Control. Toaccess the Application Policies page, right-click coreapplication in the left pane and

select Security > Application Policies (not shown here).

The default file-based policy store contains the Oracle BI permissions. All Oracle BIpermissions are provided; you cannot create additional permissions. These permissions are

granted by the default application roles in the default security configuration. Each defaultapplication role has a predefined set of permissions. The screenshot shows only a partial list

of permissions for the BIAdministrator application role.

An example of permission is oracle.bi.server.manageRepositories, which grants

permission to open repositories in online mode in the Oracle BI Administration Tool. This

permission is granted to the BIAdministrator role.

Note: These policy store permissions are not the same as those used to define access to BI

objects (metadata, dashboards, reports, and so on). Policy store permissions are used only to

define the BI functionality that assigned roles can access. You learn more about objectpermissions later in this lesson.



Default Application Policies


34/449

Default Security Settings in the RepositoryOpen the repository in online mode to see the default security settings. Repository security

should be managed in online mode. Select Manage > Identity to open the Identity Manager.

On the Users tab you can see the same set of users as those listed in the WebLogic ServerAdministration Console. The key point is that users are no longer managed in the repository,

as they were in prior releases. They are managed in the WebLogic LDAP, or whatever identifystore your system is configured with. If you need to add a new user to the system, you must

do it in the identity store, not the repository (as you learn later in this lesson).

The Application Roles tab shows all application roles in the policy store. Later in this lessonyou learn that you can use the application roles to set access control permissions for

repository objects. The recommended practice is to use application roles, not individual users,to set access control permissions for repository objects.

If you create new users in the identity store, or new application roles in the policy store, they

appear in the repository after BI Server is restarted. The repository holds a cache of the

identities, so users and application roles are visible in offline mode as well as online mode.



Default Security Settings in the Repository


35/449

Default Application Role Hierarchy: ExampleThis example is provided to illustrate the relationships among users, groups, application roles,

and permissions. In Oracle BI, the members of a default application role include both groupsand other application roles. The result is a hierarchical role structure in which permissions can

be inherited in addition to being explicitly granted. A group that is a member of a role is

granted both the permissions of the role and the permissions for all roles descended from that

role. When you construct a role hierarchy, you should notintroduce circular dependencies.

The graphic in the slide shows these relationships among the default application roles and theways in which permissions are granted to members. The result is that, because of the role

hierarchy, a user who is a member of a particular group is granted both explicit permissions

and any additional inherited permissions. Note that, by themselves, groups and grouphierarchies do not allow a privilege to perform an action in an application. Those privileges

are conveyed through the application roles and their corresponding permission grants.

The table shows the role and permissions granted to all group members (users). The default

BIAdministrator role is a member the BIAuthor role, and BIAuthor role is a member of the

BIConsumer role. The result is that members of the BIAdministrators group are granted all thepermissions of the BIAdministrator role, the BIAuthor role, and the BIConsumer role. In this

example, only one of the permissions granted by each role is used for demonstration

purposes.



Default Application Role Hierarchy: Example




ABC Example

1. Create groups.

2. Create group hierarchies.3. Create users.

4. Assign users to groups.

5. Create application roles.

6. Assign groups and roles to application roles.

7. Verify new users and application roles in Oracle BI.

8. Set up object permissions.

9. Set row-level security (data filters).

10. Set query limits and timing restrictions.


37/449


38/449

Create Group HierarchiesYou use the security realm in the WebLogic Server Administration Console to create group

hierarchies. On the Users and Groups tab in the security realm, click a group on the Groupssubtab to view settings for the group. On the Membership subtab, you can assign groups to

other groups. The Membership subtab shows the groups of which a group is already a

member and available groups to which a group can be assigned. To assign a group, use the

buttons to move a group (or groups) from the Available list to the Chosen list.

The example in the slide shows the group membership settings for theSalesSupervisorsGroup group. The SalesSupervisorsGroup group is a member of the

SalesAssociatesGroup group. This means that any privileges or permissions assigned to the

Sales Associates group are inherited by the Sales Supervisors group.



Create Group Hierarchies

Add groups to other groups to create group hierarchies.

Settings for the group

The group is a

member of this group.

Available groups to

which the group can

be assigned

Click a group to open

the Settings dialog box.


39/449

Create UsersYou use the WebLogic Server Administration Console to create users. The default identity

store provided for managing users is Oracle WebLogic Servers embedded directory server.In this example, two new users are added: AZIFF and JCRUZ.

When you click the New button, a dialog box opens to create a new user. In the dialog box,

you provide the user name, description, and password. (The dialog box is not shown here.)



Create Users

Use the security realm in the WebLogic Server Administration

Console to create users.

Click the New button to add new users.


40/449

Assign Users to GroupsOn the Users and Groups tab in the security realm, click a user on the Users subtab to view

settings for the user. On the Groups subtab, you can assign users to groups. The Groupssubtab shows the groups of which a user is already a member and available groups to which

a user can be assigned.

The example in the slide shows the group settings for the JCRUZ user. JCRUZ is a member of

the Sales Managers and Sales Supervisors groups.

Oracle BI 11g R1: Build Repositories 19 - 20


Assign Users to Groups

Use the security realm in the WebLogic Server Administration

Console to assign users to groups.Settings for user

The user is a member

of these groups.

Available groups

to which the user

can be assigned

Click a user to open the

Settings dialog box.


41/449

Create Application RolesAn application role conveys its permission grants to the users, groups, and application roles

that are mapped to that role. Being mapped to an application role establishes membership inthe role. Binding the permission grants to the application role streamlines the process of

granting system privileges. Once 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 and other application roles to application roles and

not to individual users. Once mapped, all members of the groups and roles are granted thesame rights. Controlling membership in a group reduces the complexity of tracking access

rights for multiple individual users.



Create Application Roles

Use Fusion Middleware Control to create application

roles.

Click Create to create anew application role.

New application roles


42/449

Map Application RolesOnce an application role is created, you can map the application role to users or groups

defined in the LDAP server, or you can map the application role to other application roles.

In this example, the SalesAssociatesRole application role is mapped to the Sales Associatesgroup, the Sales Managers application role, and the Sales Supervisors application role. This

means that any user who is a member of the selected group or application role is mapped tothis application role and receives any privileges or permissions assigned to the application

role. It is possible to add individual users to a role, but a best practice is to add groups orapplication roles, not individual users, to application roles.



Map Application Roles

Map application roles to groups or other application roles.

Click an application role to edit.

Application roles can be

mapped to both groups and

other application roles.


43/449

Application Role HierarchiesSimilar to the groups you created in the WebLogic identity store, you now have an application

role hierarchy in the policy store. Mapping application roles to other application roles createsapplication role hierarchies. In this example, this means that any privileges or permissions

assigned to the Sales Associates application role are inherited by the Sales Supervisors role

and the Sales Managers 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 independentof any

particular LDAP server and the users and groups within that LDAP server. Security rules arebuilt using application roles. If the underlying LDAP environment changes, the security rules

persist. In a different LDAP environment, where group or user names might be different, youcould remap the application roles to different groups or users, and the BI security structure

(built with application roles) would not be affected.



Application Role Hierarchies

Mapping application roles to other application roles creates

application role hierarchies


44/449

Verify Security Settings in Oracle BITo make policy store changes visible throughout Oracle BI, you must restart Oracle BI Server.

Typically, you have a steady set of application roles, so the frequency of adding and deletingapplication roles in the policy store should be quite low. What is more common is mapping

those roles to new groups and users in the identity store, which does not require a server

restart. Oracle BI Server must be restarted only when application roles are added or deleted.

In this example, JCRUZ has logged in to Oracle BI and selected My Account. On the Roles

and Catalog Groups tab, he sees all of the application roles to which he is assigned. JoseCruz is a member of the Sales Managers group (which is a member of the Sales Managers

Role application role) and 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 theSales Associates Role application role, he is also a member of that role. By default, all BI

users are also members of the default application roles, Authenticated User and BI ConsumerRole.



Verify Security Settings in Oracle BI

Restart Oracle BI Server to make policy store changes visible

throughout Oracle BI.


45/449

Verify Security Settings in Oracle BI (continued)

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 theroles. One approach is to build roles that are eventually used in production, and then map

developers to those roles for administering, building, and testing the development

environment.

As you learn later in this lesson, 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 bothobjects and functionality in the product.

The value of using application roles comes from the fact that you can move the system you

have built between environments without having to rewire all of the security. For example, youwould not have to change security settings in your presentation catalog or repository. You can

just remap your application roles to the target environment.



46/449

Verify Security Settings in the RepositoryAfter you restart Oracle BI Server, changes in security settings are visible in the Identity

Manager in the repository.



Verify Security Settings in the Repository


47/449

Set Up Object PermissionsYou set object permissions by using the Administration Tool. There are two approaches to

setting object permissions. You can set permissions for particular users or application roles inthe Identity Manager, or you can set permissions for individual objects in the Presentation

layer. 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. It is considered a best

practice to set up object permissions for application roles rather than for individual users.

In this example, permissions are set for the Customer presentation table object. Access to

this object is restricted for the AuthenticatedUser, BIConsumer, and SalesAssociatesRoleapplication roles. The user AZIFF is a member of these application roles. Therefore,AZIFF

does not have access to the Customer presentation table when he logs in to Oracle BI andselects the SupplierSales subject area.



Set Up Object Permissions

Set up object permissions in your repository to control access

to Presentation layer and BMM layer objects.1. Open object properties.

2. Click Permissions.

3. Set permissions.

4. User logs in.

5. User sees objectsbased on permissions.


48/449

Permission InheritanceUsers can have explicitly granted permissions. They can also have permissions granted

through membership in application roles, which in turn can have permissions granted throughmembership in other application roles, and so on. Permissions granted explicitly to a user

take precedence over permissions granted through application roles, and permissions

granted explicitly to the application role take precedence over any permissions granted

through other application roles.

If there are multiple application roles acting on a user or application role at the same levelwithconflicting security attributes, the user or application role is granted the least-restrictive

security attribute. Any explicit permissions acting on a user take precedence over any

permissions on the same objects granted to that user through application roles.

Filter definitions, however, are always inherited. For example, if User1 is a member of Role1

and Role2, and Role1 includes a filter definition but Role2 does not, the user inherits the filter

definition defined in Role1.



Permission Inheritance

Permissions granted explicitly to a user take precedence

over privileges granted through application roles. Permissions granted explicitly to an application role take

precedence over any privileges granted through other

application roles.

If security attributes conflict at the same level, a user or

application role is granted the least-restrictive security

attribute.


49/449

Permission Inheritance: Example User1 is a direct member of Role1 and Role2, and is an indirect member of Role3,

Role4, and Role5.

Because Role5 is at a lower level of precedence than Role2, its denial of access toTableA is overridden by the READ permission granted through Role2. The result is thatRole2 provides READ permission on TableA.

The resultant permissions from Role1 are NO ACCESS for TableA, READ for TableB,

and READ for TableC.

Because Role1 and Role2 have the same level of precedence and because thepermission in each cancel the other out (Role1 denies access to TableA, Role2 allows

access to TableA), the less-restrictive level is inherited by User1. That is, User1 hasREAD access to TableA.

The total permissions granted to User1 are READ access for TableA, TableB, and

TableC.



Permission Inheritance: Example

User 1

Member Role 1

Member Role 2

Role 1

NO ACCESS Table A

Member Role 3

Member Role 4

Role 2

READ Table A

Member Role 5

Role 3

READ Table B

Role 4

READ Table C

Role 5

NO ACCESS Table A


50/449

Set Row-Level Security (Data Filters)Data filters are a security feature that provides a way to enforce row-level security rules in the

repository. Data filters are set up in the repository using the Administration Tool and areapplied for a particular user or application role. You do not set up data filters if you have

implemented row-level security in the database, because in this case, your row-level security

policies are being enforced by the database rather than by Oracle BI Server.

Data filters can be set for objects in both the BMM layer and the Presentation layer. Applying

a filter on a logical object affects all Presentation layer objects that use the object. If you set afilter 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 forindividual users.

In this example, you set a filter on the Customer presentation table for the

SalesSupervisorsRole application role so that customer data is visible for only those records

in which Jose Cruz or his direct reports are the sales representatives. Jose Cruz is a member

of the SalesSupervisorsRole application role. After setting this filter, if Jose Cruz creates andruns an analysis that includes the Sales Rep column, he sees only his records and those of

his direct reports (in this example, Alan Ziff and Betty Newer).



Set Row-Level Security (Data Filters)

"SupplierSales"."Dim-Customer"."Sales Rep" = 'JOSE CRUZ' OR

"SupplierSales"."Dim-Customer"."Sales Rep" = 'ALAN ZIFF' OR

"SupplierSales"."Dim-Customer"."Sales Rep" = 'BETTY NEWER'

Filter set on Sales Rep object

for application role members


51/449

Set Query LimitsOracle BI Server enables you to exercise varying degrees of control over the repository

information that users and roles can access. You can manage the query environment bysetting query limits (governors) in the repository for users or application roles. You can

prevent queries from consuming too many resources by limiting how long a query can run

and how many rows a query can retrieve.

Note: It is a recommended practice to set query limits for application roles rather than for

individual users.

Use the Query Limits tab to control the following activities:

Control runaway queries by limiting queries to a specific number of rows received by auser or role.

Limit queries by maximum run time or to time periods for a user or role.

Allow or disallow the populate privilege (this is primarily used for Marketing applications

and is beyond the scope of this course).

Allow or disallow execution of direct database requests for specific database objects.

To access the Query Limits tab, open the Identity Manager, click the Application Roles tab,

double-click an application role to open the Application Role dialog box, and click

Permissions.



Set Query Limits

Use the Query Limits tab to:

Control the number of rows accessed by a user or role Control the maximum query run time

Enable or disable Populate Privilege

Enable or disable Execute Direct Database Requests


52/449

Set Timing RestrictionsYou can regulate when users can query databases to prevent users from querying when

system resources are tied up with batch reporting, table updates, or other production tasks.

To restrict access to a database during particular time periods, click the ellipsis () button inthe Restrict column to open the Restrictions dialog box. Then perform the following steps:

1. To select a time period, click the start time and drag it to the end time.

2. Access:

- To explicitly allow access, click Allow.

- To explicitly disallow access, click Disallow.



Set Timing Restrictions

Restrict access to a database during particular time periods.




Summary

In this lesson, you should have learned how to:

Identify and describe default security settings in Oracle BI Create users and groups

Create application roles

Set up permissions for repository objects

Use query limits, timing restrictions, and filters to control

access to repository information


54/449

Practice 19-1 Overview: Exploring Default Security SettingsDuring installation, three Oracle BI security controls are preconfigured with initial (default)

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 that are required to control authentication

A file-based policy store designed to hold the application role and permission grantmappings to users and groups that are required to control authorization

A file-based credential store designed to hold all user and system credentials that are

required to control authentication or authorization

Before you implement data access security in the Oracle BI repository, you explore thesedefault security settings.



Practice 19-1 Overview:

Exploring Default Security Settings

This practice covers Oracle BI default security settings in the

identity store, policy store, and credential store.


55/449

Practice 19-2 Overview: Creating Users and GroupsGroups 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 BIusers into groups that make sense for your organizations goals and map application roles to

the groups to convey system privileges. The default identity store provided for managing

users and groups is Oracle WebLogic Servers embedded directory server.

In this practice, you use the WebLogic Server Administration Console to create users and

groups.




Creating Users and Groups

This practice covers using the WebLogic Server Administration

Console to create users and groups.


56/449

Practice 19-3 Overview: Creating Application RolesAn 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 to application roles and not to individual users. After

they are mapped, all members of the group are granted the same rights. Controllingmembership in a group reduces the complexity of tracking access rights for multiple individual

users.

In this practice, you use Fusion Middleware Control to create application roles.




Creating Application Roles

This practice covers using Fusion Middleware Control to create

application roles in the policy store.


57/449


58/449

Practice 19-5 Overview: Setting Row-Level Security (Data Filters)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 useror application role.

Data filters can be set for objects in both the BMM layer and the Presentation layer. Applying

a filter on a logical object affects all Presentation layer objects that use the object. If you set afilter 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 particularapplication roles rather than for individual users.

In this practice, you set a filter on the Customer presentation table so that customer data is

visible for only those records in which Jose Cruz or his direct reports are the salesrepresentatives.




Setting Row-Level Security (Data Filters)

This practice covers setting row-level security in the repository.


59/449

Practice 19-6 Overview: Setting Query Limits and Timing RestrictionsYou can manage the query environment by setting query limits (governors) in the repository

for users or application roles. You want to prevent queries from consuming too manyresources by limiting how long a query can run and how many rows a query can retrieve. You

also 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 ofany query to one minute, and restricted access to a database on Sunday from 12:00 AM to

7:00 AM.




Setting Query Limits and Timing Restrictions

This practice covers managing the query environment by

setting query limits and timing restrictions in the repository.


60/449


61/449


Cache Management




Objective

After completing this lesson, you should be able to manage the

Oracle BI Server query cache.


63/449

Business ChallengeDecision support queries sometimes require a large amount of database processing.

Requests for the same information require frequent trips to back-end databases to retrieve thequery results. Such trips can increase query response time and result in poor performance

from the users perspective.

Oracle BI 11g R1: Build Repositories 20 - 3


Business Challenge

Decision support systems require a large amount of

database processing. Frequent trips to back-end databases to satisfy query

requests can result in:

Increased query response time

Poor performance


64/449

Business Solution: Oracle BI Server Query CacheOracle BI Server can save the results of a query in cache files and then reuse them later

when a similar query is requested. By using the cache, the database needs to be processedonly once for the initial time a query is executed. For subsequent times that a similar query is

executed, the results are satisfied by the cache and not the database.

Oracle BI administrators can configure Oracle BI Server to maintain a local, disk-based cacheof query result sets (the query cache). The query cache enables Oracle BI Server to satisfy

many subsequent query requests without having to access back-end databases. Thisreduction in communication costs can dramatically decrease query response time.



Business Solution: Oracle BI Server Query Cache

Oracle BI Server can be configured to maintain a disk-based

cache of query result sets (query cache): Saves the results of queries in cache files

Enables Oracle BI Server to satisfy subsequent query

requests without having to access back-end databases

Improves query response time


65/449

Advantages of CachingThe fastest way to process a query is to skip the bulk of the processing and use a pre-

computed answer. With query caching, Oracle BI Server stores the pre-computed results ofqueries in a local cache. If another query can use those results, all database processing for

that query is eliminated. This can result in dramatic improvements in the average query

response time. Not running the query on the database also frees the database server to do

other work.

In addition to improving performance, being able to answer a query from a local cacheconserves network resources and processing time on the database server. Network

resources are conserved because the intermediate results do not have to come over the

network to Oracle BI Server. Administrators can take additional steps to improve cachingperformance. Such measures might include tuning and indexing databases, optimizing data

source connectivity, leveraging aggregate tables, and constructing metadata efficiently.



Advantages of Caching

Eliminates unnecessary database processing because

pre-computed results are stored in a local cache Improves query performance by fulfilling a query from the

cache rather than searching through the database

Conserves network resources by avoiding a connection to

the database server


66/449

Costs of CachingDisk Space

The query cache requires dedicated disk space. The amount of space depends on the query volume,the size of the query result sets, and the amount of disk space you choose to allocate to the cache. Forperformance purposes, a disk should be used exclusively for caching, and it should be a high-performance, high-reliability disk system.

Administrative Tasks

There are a few administrative tasks associated with caching. You need to set the cache persistencetime for each physical table appropriately, knowing how often data in that table is updated. When thefrequency of the update varies, you need to keep track of when changes occur and purge the cachemanually when necessary.

Keeping the Cache Up to DateIf the cache entries are not purged when the data in the underlying databases changes, queries canpotentially return results that are out of date. You need to evaluate whether this is acceptable. It mightbe acceptable to allow the cache to contain some stale data. You need to decide what level of staledata is acceptable and then set up (and follow) rules to reflect those levels. For applications in whichdata is updated yearly or quarterly, it may be acceptable to keep stale data in the cache. Forapplications in which data is updated frequently, it may be necessary to purge the cache more often.It is also possible to purge the entire cache as part of the extraction, transformation, and loading (ETL)process for rebuilding the data mart, making sure that there is no stale data in the cache.



Costs of Caching

Disk space

The query cache requires dedicated disk space.

Administrative tasks:

Set the cache persistence time appropriately.

Purge the cache when necessary.

Keeping the cache up to date:

Evaluate what level of noncurrent information is acceptable.

Remove stale data.


67/449

Query Cache: ArchitectureA query cache is a facility that stores the results from queries. If a query is fulfilled by the

results stored in the cache, it is called a cache hit. A cache hit means that the server was ableto use the cache to answer the query and did not go to the database at all.

A cache is used to eliminate redundant queries. For example, if 10,000 users always look at

the same dashboard, getting the data once and storing it in the cache helps with scalability.

This graphic in the slide depicts the basic architecture of the query cache. The process of

accessing the cache metadata occurs very quickly. If the metadata shows a cache hit, the

bulk of the query processing is eliminated, and the results are immediately returned to theuser. The process of adding the new results to the cache is independent of the results being

returned to the user; the only effect on the running query is the resources consumed in theprocess of writing the cached results.



Query Cache: Architecture

The query cache consists of:

Cache storage space Cache metadata

Cache detection

Query

cache

Server

database

Cache

metadata

(cache hit?)

Logical request

Yes

No

Results

sent to

user.

Oracle BI ServerUsers query request is

translated into logical request.

The metadata issearched to identify

a match (cache hit).

If it is a cache

miss, the request

is queried against

the database;

results are stored

in cache and sent

to the user.

If there is a match, results are

retrieved from the cache and

sent to the user.


68/449

Monitoring and Managing the CacheCache files always produce the same results, even after a database has been updated.

Issues with retaining cache files may arise. For example, not purging outdated caches (knownas stale caches) can potentially return inaccurate results over time and consume disk space.

Therefore, you need a cache management strategy to manage changes to the underlying

databases and to monitor cache entries. The choice of a cache management strategydepends on the volatility of the data in the underlying databases and the predictability of the

changes that cause this volatility. It also depends on the number and types of queries thatcomprise your cache, as well as the usage those queries receive. Cache management

techniques are provided in the following slides.



Monitoring and Managing the Cache

Requires an overall cache management strategy:

Invalidate the cache entries when underlying data haschanged.

Monitor, identify, and remove undesirable cache entries.


69/449

Cache Management TechniquesThis slide lists some of the techniques you can use to manage the query cache. Each

technique is discussed in detail in subsequent slides.



Cache Management Techniques

Using Fusion Middleware Control to configure caching

Using NQSConfig.ini to manually edit cacheparameters

Setting caching and cache persistence for tables

Using the Cache Manager

Inspecting SQL for cache entries

Modifying the Cache Manager column display

Inspecting the cache reports

Purging cache entries manually using the Cache Manager

Purging cache entries automatically

Using event polling tables

Seeding the cache


70/449

Using Fusion Middleware Control to Configure CachingYou can use Fusion Middleware Control to enable or disable query caching. The query cacheis enabled by default. To use Enterprise Manager to enable or disable query caching, go tothe Business Intelligence Overview page, display the Performance tab of the CapacityManagement page, click Lock and Edit Configuration, and select Cache enabled. Todisable query caching, deselect Cache enabled. Apply and activate your changes.

You also can use Fusion Middleware Control to set the maximum size for a single cacheentry, as well as the maximum number of cache entries in the query cache. When the cachestorage directories exceed the number specified in the Maximum cache entriesparameter, the entries that are least recently used

Documents

Oracle Bi 11g r1 Build Repositories Ed 1.1 Student Guide - Volume 2 d63514gc11_sg2