P. 1
Best Practices - OBIEE

Best Practices - OBIEE

|Views: 11|Likes:
Published by emailkittu

More info:

Published by: emailkittu on Jun 07, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Best Practice

OBIEE – Best Practices
DC/ SC/ Geo/Practice: OBIEE Name of the project : Novo Nordisk IO SELAS Name of the author: Sangeeta Basavaraju Date Created: 14/01/2011

January 14, 2011

OBIEE is used for creating standard KPI reports and Ad-Hoc reports for the sales group.Description Project / Context NNIO SELAS Application is developed using Seibel and OBIEE technology. 2011 . January 14. Purpose The Purpose of the document is to highlight the best practices followed in OBIEE.

How we did it Process adopted 1. 2011 . Repository – physical Layer Connection Pool Use individual database for every project and also specify the meaningful name for it Follow proper naming convention to the database object & connection pool as per the project/business unit Use optimized number of connection pools. maximum connections for each pool . shared logon etc Highlights Better Performance Easy Maintenance Increased Usability January 14.

How we did it Process adopted Do not have any connection pools which are unable to connect to the databases as this 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 January 14. 2011 .

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 January 14.

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 the primary 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 January 14. 2011 .

associate it with the highest level it belongs to All levels except the grand total level must have level keys 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.

How we did it Process adopted Aggregation All aggregation should be performed from a fact logical table and not from a dimension logical table All columns that cannot be aggregated should be expressed in a dimension logical table and not in a fact logical table Non‐aggregated 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 January 14. 2011 .

If the physical table does not have a primary key. 2011 . the logical 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 tables that join to this fact table January 14.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.

0.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.e. it should be model centric Joins between logical facts and logical dimensions should be complex (intelligent) i. 2011 .1:N not foreign key joins It is advised to have a logical star in the business model January 14.

For e.How we did it Process adopted Combine all like attributes into single dimensional logical table. 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 January 14. 2011 .g.

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 generates optimized SQL Avoid to apply complex logic at the “Where Clause” filter January 14. 2011 .

2011 . especially for logical fact tables Explicitly declare the content of logical table sources. especially for logical fact tables Create separate source for dimension extensions Combine Fact extension into main fact source January 14.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.

define the level of granularity. The aggregation content rule defines at what level of granularity the data is stored in this fact table. 2011 . For each dimension that relates to this fact logical table.How we did it Process adopted Each logical table source of a fact logical table needs to have an aggregation content defined. ensuring that every related dimension is defined Delete unnecessary physical column from here January 14.

NOT in physical table/column terms January 14. 2011 . All columns should be named in business relevant terms. discrete. Presentation Layer It should be simple Break out complex logical models into simple. and manageable subject areas.How we did it Process adopted Rename logical column here so that all referenced presentation column would changes cascaded 3.

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. 2011 . Verify that reports do not use the aliases January 14.

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 have description visible from answers on mouse hover to it Delete unnecessary columns of BMM in presentation layer January 14. 2011 .

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 January 14.

Mark “Facts” or “Measures” for column having Aggregation rules 4.How we did it Process adopted Separate numeric and non numeric quantities into separate folder sets. Others RPD Security Use Externalized security for user group association to roll out large number of users Use template groups (i. security filters with session variables) to minimize group proliferation January 14. 2011 .e.

and edit the repository in Offline mode Use naming convention for initialization block and variable for ease of maintenance Follow proper migration strategies January 14.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. 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 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 January 14. 2011 .

setting the Query Limits and turn off logging Push the complex functions to be performed at the database side Good Caching and Purging strategy (Web server cache and Siebel Analytic Server Cache) January 14.How we did it Process adopted Set the correct and recommended log level in the Production. 2011 .

2011 . Benefits Customer Satisfaction in terms of Usability and Performance. January 14. Following the practices mentioned will streamline the maintenance activities of application.Why this is a best practice Justification Customers were impressed with the whole application in terms of Usability and Performance.

2011 . Contact Info Sangeeta Basavaraju Mailto: sangeeta.How this may be adapted elsewhere Replication The OBIEE best practices can be used in any project that uses OBIEE technology.com January 14.basavaraju@tcs.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->