Best Practices - OBIEE

7/31/2019 Best Practices - OBIEE

1/26

Best Practice


2/26

January 14, 2011

OBIEE Best PracticesDC/ SC/ Geo/Practice: OBIEE

Name of the project : Novo Nordisk

IO SELAS

Name of the author: Sangeeta

Basavaraju

Date Created:

14/01/2011


3/26

January 14, 2011

Description

PurposeThe Purpose of the document is to highlight the best practices followed in OBIEE.

Project / ContextNNIO SELAS Application is developed using Seibel and OBIEE technology.

OBIEE is used for creating standard KPI reports and Ad-Hoc reports for thesales group.


4/26

January 14, 2011

How we did it

Highlights

Better PerformanceEasy MaintenanceIncreased Usability

Process adopted

1. Repository physical Layer

Connection Pool

Use individual database for every project and

also specify the meaningful name for it

Follow proper naming convention to thedatabase object & connection pool as per the

project/business unit

Use optimized number of connection pools,

maximum connections for each pool , sharedlogon etc


5/26

January 14, 2011

How we did it

Process adopted

Do not have any connection pools which

are unable to connect to the databases asthis might lead to BI server crash as it

continuously ping to the connection

Others

Define proper keys in physical layer

Do not import foreign keys from Database


6/26

January 14, 2011

How we did it

Process adopted

2. Repository Design BMM

Hierarchy

Ensure each level of hierarchy has an

appropriate number of elements and level

key

No level key should be at Grand total level

A hierarchy should only have one grand

total level


7/26

January 14, 2011

How we did it

Process adopted

Lowest level of the hierarchy should be same as

lowest grain of the Dimension Table. Lowest

level of a dimension hierarchy must match theprimary key of its corresponding dimension

logical tables

All the columns in a hierarchy should come from

one logical table

All hierarchies should have a single root level

and a single top level


8/26

January 14, 2011

How we did it

Process adopted

If a hierarchy has multiple branches, all

branches must have a common beginning

point and a common end point

If a column pertains to more than one level,

associate it with the highest level it belongs

to

All levels except the grand total level must

have level keys


9/26

January 14, 2011

How we did it

Process adopted

Aggregation

All aggregation should be performed from a

fact logical table and not from a dimensionlogical table

All columns that cannot be aggregated

should be expressed in a dimension logical

table and not in a fact logical table

Nonaggregated columns can exist in a

logical fact table if they are mapped to a

source which is at the lowest level of

aggregation for all other dimensions


10/26

January 14, 2011

How we did it

Process adopted

Arrange dimensional sources in order of

aggregation from lowest level to highest level

Logical Joins

If foreign key logical joins are used, the

primary key of a logical fact table should then

be comprised of the foreign keys. If the

physical table does not have a primary key, thelogical key for a fact table needs to be made

up of the key columns that join to the attribute

tables

Look at the foreign keys for the fact table and

find references for all of the dimension tablesthat join to this fact table


11/26

January 14, 2011

How we did it

Process adopted

Create the logical key of the fact table as a

combination of those foreign keys

Others Modeling should not be any report specific,

it should be model centric

Joins between logical facts and logicaldimensions should be complex (intelligent)

i.e. 0,1:N not foreign key joins

It is advised to have a logical star in the

business model


12/26

January 14, 2011

How we did it

Process adopted

Combine all like attributes into single

dimensional logical table. For e.g. Never put

product attributes in customer dimension

Every Logical Dimension should have a

hierarchy declared even if it only consists of

a Grand Total and a Detail Level

Never delete logical columns that map to

keys of physical dimension tables

Explicitly declare content of logical table

sources


13/26

January 14, 2011

How we did it

Process adopted

Proper naming convention to be followed

for logical tables and columns

Avoid assigning logical column same name

as logical table or subject area

Configure the content/levels properly for all

sources to ensure that OBI generatesoptimized SQL

Avoid to apply complex logic at the Where

Clause filter


14/26

January 14, 2011

How we did it

Process adopted

Level based or derived calculations should

not be stored in Aggregated tables

Explicitly declare the content of logical

table sources, especially for logical fact

tables

Explicitly declare the content of logicaltable sources, especially for logical fact

tables

Create separate source for dimension

extensions Combine Fact extension into main fact

source


15/26

January 14, 2011

How we did it

Process adopted

Each logical table source of a fact logical

table needs to have an aggregation content

defined. The aggregation content ruledefines at what level of granularity the data

is stored in this fact table. For each

dimension that relates to this fact logical

table, define the level of granularity,

ensuring that every related dimension isdefined

Delete unnecessary physical column from

here


16/26

January 14, 2011

How we did it

Process adopted

Rename logical column here so that all

referenced presentation column would

changes cascaded

3. Presentation Layer

It should be simple Break out complex

logical models into simple, discrete, andmanageable subject areas.

All columns should be named in business

relevant terms, NOT in physical

table/column terms


17/26

January 14, 2011

How we did it

Process adopted

Expose most important facts and dimensions

Proper Naming Convention for all tables

and columns by Initial cap Labeling.

Do not combine tables and columns from

mutually incompatible logical fact and

dimension tables

Ensure that aliases for presentation layer

columns and tables are not used unless

necessary. Verify that reports do not use thealiases


18/26

January 14, 2011

How we did it

Process adopted

End Users should not get any errors when

querying on any two random columns in a

well designed presentation layer

Each Catalog should have the description

which will be visible from Answers

Each Presentation column should havedescription visible from answers on mouse

hover to it

Delete unnecessary columns of BMM in

presentation layer


19/26

January 14, 2011

How we did it

Process adopted Avoid naming catalog folders same as

presentation tables

If the presentation catalog is in Tree like

folder structure( main and sub folders), then

place a dummy measure in the main catalog

folder

Avoid to set permissions to tables or groups

unless necessary

If presentation table is in tree like structure

then place a dummy column as _ to

enforce proper table sorting . This also help

in merging activities


20/26

January 14, 2011

How we did it

Process adopted

Separate numeric and non numeric

quantities into separate folder sets. Mark

Facts or Measures for column havingAggregation rules

4. Others

RPD Security Use Externalized security for user group

association to roll out large number of users

Use template groups (i.e. security filters

with session variables) to minimize groupproliferation


21/26

January 14, 2011

How we did it

Process adopted

Users should not be stored inside the

repository

Limit online repository updates to minor

changes

For major editing take backup copy of the

repository, and edit the repository in Offlinemode

Use naming convention for initialization

block and variable for ease of maintenance

Follow proper migration strategies


22/26

January 14, 2011

How we did it

Process adopted

5. Performance Should have no Global Consistency Errors

and Warnings

Meta data Repository size to be Reduced to

the possible Extent by removing the unused

Objects

Optimized settings for BI server and Web

server configuration file parameters

Applying Database hints for a table in the

Physical layer of the Repository


23/26

January 14, 2011

How we did it

Process adopted

Reduce the SELECT statements executes by

the OBIEE Server

Limit the generation of lengthy physical

SQL queries by Modeling dimension

hierarchies (Hierarchy ( Drill Key and Level

Key)

Disable or remove the unused initialization

blocks and also reduce the number of init

blocks in the Repository


24/26

January 14, 2011

How we did it

Process adopted

Set the correct and recommended log level

in the Production, setting the Query Limits

and turn off logging

Push the complex functions to be performed

at the database side

Good Caching and Purging strategy (Webserver cache and Siebel Analytic Server

Cache)


25/26

January 14, 2011

Why this is a best practice

Benefits Customer Satisfaction in terms of Usability and

Performance. Following the practices mentioned will streamline the

maintenance activities of application.

Justification

Customers were impressed with the whole application in

terms of Usability and Performance.


26/26

January 14, 2011

How this may be adapted elsewhere

Contact Info

Sangeeta BasavarajuMailto: [email protected]

Replication

The OBIEE best practices can be used in any project that

uses OBIEE technology.

Documents

Best Practices - OBIEE