25BR_RepositoryDesignPrinciples.pdf

Copyright 2008, Oracle. All rights reserved.

Oracle BI Repository Design Principles

Copyright 2008, Oracle. All rights reserved.25 - 2

Objectives

After completing this lesson, you should be able to identify and

apply Oracle BI repository design principles.


Lesson Structure

This lesson is presented in three sections:

Physical Layer Design Principles

Business Model and Mapping Layer Design Principles

Presentation Layer Design Principles


Physical Layer Design Principles

Using the File > Import option

Creating aliases for physical tables

Creating aliases to avoid circular joins

Creating canonical time

Using multiple time dimension tables

Setting the physical table caching property

Setting connection pool properties

Creating additional connection pools


Using the File > Import Option

Recommended method to create table objects in the Physical layer (as opposed to manual creation)

Use the appropriate connection type (ODBC, OCI, and so on)

Import options

Import only the tables

needed to build the

business model.


Creating Aliases for Physical Tables

For star schema data sources, create aliases for all physical

tables in the Physical layer.


Creating Aliases to Avoid Circular Joins

Create additional aliases to avoid circular joins for dimension

tables that are joined to more than one table.


Creating Canonical Time

Create a common time dimension alias table that joins to multiple fact tables.

Enables reporting across multiple facts

Create secondary time dimension alias tables that join to one fact table on other time dimension columns.

Common time dimension

Secondary time dimension


Setting the Physical Table Caching Property

Set the caching property on the master physical table, not on the alias tables.

Enable caching for

all physical tables

used in reporting.

Set cache persistence

time based on a refresh

schedule.


Setting Connection Pool Properties

Set the most efficient connection pool properties.

Use native drivers

when available.Set maximum

connections to a

reasonable level.

Enable connection

pooling.


Creating Additional Connection Pools

Create additional physical models and connection pools to

control security and restrict access to write back and usage

tracking.

Separate physical

model and connection

pool for usage tracking

Separate physical

model and connection

pool for write back

Different physical models can use tables from the same physical schema.


BMM Layer Design Principles

Multi-user development

Consistency check

Separate business models

Logical tables

Time dimension logical levels

Time dimension logical structure

Logical dimension table columns

Logical fact table columns

Logical joins

Calculated measures


BMM Layer Design Principles

Logical levels

WHERE clause filters

Avoiding snowflaking

Dimension hierarchies: General

Dimension hierarchies: Levels

Dimension hierarchies: Number of elements

Dimension hierarchies: Drilldown

Aggregates


Multi-User Development

Use the multi-user development (MUD) facility if there are multiple developers.

Do not allow multiple developers to connect online to the same repository.

Select presentation catalogs or logical

fact tables within the catalogs.

Selected objects are added to project.

Create project.


Consistency Check

Always run a global consistency check before releasing a

repository.

Use Consistency Check Manager to identify

and debug consistency check messages.


Separate Business Models

Even if you have only a single physical source or schema, you

should create separate business models for independent areas

of functionality.

Multiple business models may

map to the same physical source.


Logical Tables

Group facts and dimensions into logical tables according to

functional areas, or according to how users build their queries.

Build separate logical tables

for each dimension.

Build separate logical

tables for facts.

Build separate logical

tables for compound facts.

Use prefixes to identify

logical table function.

Compound facts are based

on existing logical columns.


Time Dimension Logical Levels

Ensure that the logical level of each time-logical table source is

set correctly.


Time Dimension Logical Structure

For consistency, make sure that all time-logical dimension

tables contain the same columns and general structure.


Logical Dimension Table Columns

Do not bring physical primary key columns into the BMM layer unless absolutely necessary.

Assign a logical primary key that makes sense from a reporting perspective.

Create meaningful logical column names.

Bring in only the columns you need from the Physical layer.

Meaningful

primary key

Meaningful

column namesDo not automatically

use as logical key.


Logical Fact Table Columns

Do not assign logical primary keys for logical fact tables.

Create meaningful names for measures.

Set aggregation rule for every logical fact column.

Create dummy measures to group facts.

Use dummy measures to group facts.

Set aggregation rule.

Create meaningful names.


Logical Joins

Use only logical joins in the BMM layer.

Accept defaults when creating joins.

Driving table =

None

Cardinality =

0,1 to N

Join type =

Inner


Calculated Measures

Be careful when building calculated measures:

Use logical columns for calculations that require an aggregation rule that is applied before the calculation.

Use physical columns for calculations that require an aggregation rule to be applied after the calculation.

SQL applies the

aggregation rules to

the columns first

and then calculates the difference.

Query uses Cuts, a calculation measure based on logical columns.


Logical Levels

Explicitly define logical levels for every fact and dimension

logical table source.


WHERE Clause Filters

Use WHERE clause filters to help avoid using opaque views or

complex joins in the physical layer.

Use WHERE clause.


Avoiding Snowflaking

Add tables to the logical table source to avoid snowflaking.

To avoid snowflaking

in the BMM layer

add tables to logical table source.


Dimension Hierarchies: General

Create a dimension hierarchy for every logical dimension table

in the business model.

Create dimensions for every

logical dimension table.


Dimension Hierarchies: Levels

Dimensions must have at least two levels: Total and Detail.

Check Grand total level for the Total level.

Create key columns for each level except the Total level.

Drag in columns that are applicable to a particular level.

Create identical detail levels if there are multiple drill paths.

Set preferred drill path if more than one drill path exists.

No key for

Total level

Identical base

detail levels


Dimension Hierarchies: Number of Elements

Use Update Row Counts or Estimate Levels to set the number

of elements for every level of every dimension hierarchy.

Numbers do not have to be exact as long as ratios between levels are accurate.


Dimension Hierarchies: Drilldown

Think about the experience of the user when enabling drilldown.

Do not enable automatically.


Aggregates

Try to ensure that each aggregate table has an effective summary ratio with the underlying detail table.

Ensure that the logical level of every aggregate logical table source is set correctly.

Always test to ensure that aggregate tables are being used as expected. (Check the log to see the Physical SQL

produced.)

If an aggregate is not being used, try changing the number of elements on one of the related dimension logical levels.


Presentation Layer Design Principles

Subject areas

Development with end users in mind

Role-based subject areas

Presentation tables

Rule of seven

Fact tables

Implicit fact columns

Canonical time

Secondary time dimensions

Nesting presentation folders

Presentation object names

Presentation object descriptions


Subject Areas

Do not include all Presentation layer objects in a single

presentation catalog (subject area).

Security is more

complicated.

Meaning of dimensions

is ambiguous.

Which dimensions are

tied to which facts?

Which fact table is the

implicit fact table?

Use multiple

presentation catalogs.

Group related facts and

dimensions together.


Development with End Users in Mind

Always develop the Presentation layer so that end users are able to understand and use it.

Even if there is no current requirement for users to run their own reports, users may be asked to do so in the future.


Role-Based Subject Areas

Configure multiple presentation catalogs that are specific to

each type of user.

Role-based presentation catalogs contain

different content to suit individual needs.

Sales Representative

Sales Manager


Presentation Tables

Presentation tables should be

consistent across presentation

catalogs:

List dimension tables first.

Do not mix dimension and fact columns in the same table.

Apply consistent ordering and naming conventions for tables

and columns across catalogs.

Include the words measures or facts in the names of the fact presentation tables.


Rule of Seven

Keep presentation catalogs small and easy to understand by limiting the number of tables to seven.

Keep presentation tables small and easy to understand by limiting the number of columns to seven.


Fact Tables

Limit the number of fact tables in each presentation catalog.

Helps to eliminate multiple join paths in the catalog


Implicit Fact Columns

If you have multiple fact tables in a presentation catalog, assign an implicit fact column.

Helps Oracle BI Server identify the join path that should be used in dimension-only requests


Canonical Time

Include canonical time presentation tables to enable users to build time reports across multiple star schemas.

Should be the first table in a catalog

Should have a generic name (such as Time)

Should be consistent across catalogs

Canonical time Canonical time


Secondary Time Dimension

Enables users to build time reports for specific star schemas

Should be listed below the canonical time dimension

Include in separate

presentation

tables

or group into a single

presentation table

Canonical time Canonical time


Nesting Presentation Tables

Prefix presentation table names with a hyphen to group

common objects together into subfolders.


Presentation Object Names

Use the Aliases tab to keep track of prior names.

Use the default option that synchronizes the presentation column name with the underlying logical column name.

Use only logical, business-oriented names (rather than physical object names) in the Presentation layer.


Presentation Object Descriptions

Add descriptions to presentation catalogs to explain the purpose of each subject area in Oracle BI Answers.

Add descriptions to presentation tables to appear with mouse roll-over in Answers.

Add descriptions with examples to presentation columns to explain the data content with mouse roll-over in Answers.


Summary

In this lesson, you should have learned how to identify and

apply Oracle BI repository design principles.


Practice 25-1:

Exploring Applied Design Principles

In the practice, you explore best practices and applied design

principles in an Oracle BI repository.

25BR_RepositoryDesignPrinciples.pdf

Documents

Transcript of 25BR_RepositoryDesignPrinciples.pdf