OBIEE

Development Standards
&
Best Practices

Name of the project : Global Data Warehouse

Name of the author : Satya Swarup Choudhury
Date Created : 11-JAN-2010
 CONTENT

OBIEE DEVELOPMENT STANDARDS & BEST PRACTICES........................................................... 2

PROJECT DESCRIPTION......................................................................................................................... 2
PROCESS ADOPTED ................................................................................................................................. 2
RPD STANDARDS ....................................................................................................................................... 2
Naming standards ................................................................................................................................. 2
Physical Layer ...................................................................................................................................... 2
Business Mapping Model Layer............................................................................................................ 3
Presentation Layer................................................................................................................................ 4
REPORTS & DASHBOARD STANDARDS ....................................................................................................... 5
Naming standards ................................................................................................................................. 5
Development Standards ........................................................................................................................ 5
PERFORMANCE IMPROVEMENT BEST PRACTICES & SUGGESTION ............................................................... 7
OBIEE Standpoint................................................................................................................................. 7
Data Warehouse Standpoint ................................................................................................................. 8
WHY THIS IS A BEST PRACTICE:......................................................................................................... 8
BENEFITS:................................................................................................................................................... 8
HOW THIS MAY BE ADAPTED ELSEWHERE:................................................................................... 9
REPLICATION .............................................................................................................................................. 9
CONTACT INFO ........................................................................................................................................... 9

1
OBIEE Development Standards & Best Practices
Project Description
ROLAP solution was build on top of Global Data Warehouse using OBIEE (Oracle Business Intelligence
Enterprise Edition) for specific Line of Businesses. Below mentioned standards were followed while
building the solution.

Process Adopted
1. Followed the RPD and Report Naming Standards while building the application.
2. Incorporated best practices in OBIEE to make it more user-friendly.
3. Incorporated Performance improvement techniques in OBIEE as well as Data
Warehouse.

RPD Standards
Naming standards
All object naming will follow business friendly conventions (except the Physical Layer):
• Mixed-case (Sales Revenue vs {SALES REVENUE or sales_revenue})
• Objects will follow standard abbreviation principles

The BMM/presentation layer should use the following conventions:

• No underscores or other database style naming conventions will be used.
• All elements will have the first letter of major words capitalized. No element should be displayed in
all capital letters.
• Minimize overly descriptive column names.
• Names of Fact and Dimension tables should be preceded by with ‘Fact’ and ‘Dim’ respectively in
BMM.

Physical Layer
• Foreign Key joins between tables is the standard
• Aliases may be created of physical tables to facilitate join requirements.
The following is a list of the main reasons to create an alias table:
o To reuse an existing table more than once in your physical layer (without having to import it
several times).

2
 o To set up multiple alias tables, each with different keys, names, or joins.
o To help you design sophisticated star or snowflake structures in the business model layer
• OBIEE “views” should be pushed to the database when possible
• Connection pools should leverage repository variables in the DSN and database user fields for ease
of migration.
• Unless specified it’s advised to set maximum connections for a connection pool as 100.
• Separate connection pools should be created for write back and Auto-provisioning (init blocks)
• Always require fully qualified table names
• Always input descriptions where available.
• Do not duplicate tables in the physical layer to satisfy the rule that every table must be joined to at
least one other table. This can be very well handled in BMM layer.
• Repository will not include physical column if it is not mapped to logical column. This Improves
performance by only issuing SQL for what is needed

Business Mapping Model Layer

• Complex joins between tables is the standard
• Always try to follow star-schema design even if the physical layer is not a star.
• Time Dimension should be placed at the Top followed all other dimension tables followed by Fact
tables in a logical folder.
• Never delete logical columns that map to keys of physical dimension tables
• Avoid assigning logical column same name as logical table or subject area
• Dimension tables are expected to store columns that can not be aggregated
• When joining tables, ensure the Fact tables show up with Yellow icon to the left of the table.
• When an ‘additional’ logical column is needed from another source table, don’t use the field from
the BMM. Instead, add the Physical table as a separate source in the BMM and use the physical
column.
• Fact to fact join is strongly disagreeable. If there is a requirement to run a query across multiple fact
tables, a join should be defined between these fact tables through using a common dimension table
(Bridge Table).
• Arrange the fields in a Fact logical folder as per following order.
o Keys
o Calculated Measures
o Attributes
You can add separator columns (headers) for better visibility of the above categories. But these
shouldn’t be moved to presentation layer.
• If any logical column needs to be created in a folder, then always try to use physical layer columns
for a better performance.
• All hierarchies should have a Total level; a total level column is only required if reporting/dashboard
requirements dictate.
• Dimensional Hierarchy: While building hierarchy please follow the rules given below:

1. A hierarchy should only have one grand total level and it should be checked.
2. A grand total level should not have a level key. The OBI Administration Tool enforces
this.
3. All the columns in a hierarchy should come from one logical table.

3
 4. All hierarchies should have a single root level and a single top level. The OBI
Administration Tool enforces this. If a hierarchy has multiple branches, all branches must
have a common beginning point and a common end point.

Total US
Region
District
Customer
State
County
Customer
5. The level key of the root level (the lowest level of the hierarchy) should match the key of
the logical dimension table upon which the hierarchy is built.
6. Not all columns in the logical table need be associated with a level. If not explicitly
associated with a level, a column is associated with the lowest level automatically.
7. No column can be associated with more than one level.
8. If a column pertains to more than one level, associate it with the highest level it belongs
to.
9. No level except the grand total level can exist without at least one column being
associated with it.
10. All levels except the grand total level must have level keys.
11. The columns used to make up a level key should reference a unique value. If the level
value is not unique, columns need to be added to the key to guarantee uniqueness.
• Logical Fact tables should only have a single base fact table and any aggregates in the logical table
sources. Specific requirements that require deviation from this standard should be approved.
• Logical Dimension tables should include all “snowflakes” in the logical table sources and all
columns should be mapped to each table accordingly. For example, Year, Month, Date dimension
sources as one logical dimension instead of individual.
• Logical levels must be defined for all Fact sources at a minimum, and may be required on individual
columns based on reporting requirements. This will help with aggregations and assist multitask SQL
with determining the level of the fact tables and what table to use.
• Always input descriptions where available.
• Add the aggregate fact tables into sources detail fact table as separate sources and use Aggregate
Navigation feature for performance improvement. Don’t create separate fact tables for aggregated
facts if there is no specific requirement other than performance improvement.

Presentation Layer
• Presentation columns should leverage Business Model column names except in instances where a
repository variable is used to dynamically name a column.
• Aliases should not be leveraged unless absolutely necessary and should not appear on an initial
rollout of a new subject area.
• Group attributes into sub-folders (by putting “- “ before the folder name) if the parent folder
contains a large number of attributes or where columns can be naturally grouped. This is typical of
Fact/Metric/Measure parent folders, which can often be grouped.
• The Measure/Metric folder(s) should always appear at the bottom of the parent folder list within a
presentation layer; other folders can either be sorted alphabetically, or by prominence/importance.

4
 • Remove Key columns from this layer because it would mean nothing to the users.
• Time dimension should be placed at the top.
• Always input descriptions where available.
• Presentation layer objects should not be granted to “Everyone”. Only the correct Groups will have
access to the respective object.

Reports & Dashboard Standards

Naming standards

• Report names should be concise, descriptive, and fit into a single display row when placed in a
dashboard or when used as a section title.
• All reports should contain a report description
• Create shared folders structures using two major groupings; user roles and subject areas (or
dashboards).
The most useful convention is to group common reports into subject area folders only; and group
role- specific reports into subject area folders first, and role folders second.
• All prompt names should begin with the word “Prompt:” which should be followed by an
abbreviated list of the attributes included in the prompt.
o “Prompt: Year, Region Name, Store Name”
• All filters should be preceded by the word “Filter:” and provide a business description of the items
being filtered
o “Filter: Year, Region Name, Store Name”

Development Standards

• Columns should be set with their system-wide data format before building reports.
• When including a legend within any charted report, place the legend above the chart
data.

This will allow the user to see the legend more clearly and will also ensure that the user
isn’t required to scroll down to locate a hidden legend. Our eyes naturally scan from top
to bottom, so the legend will be the first thing a user sees, making the chart colors more
understandable.
• Data labels within charts shown only on rollover.

A good rule of thumb is to set the “Show data labels” option to “Default (On Rollover)” if
more than ten bars are being displayed.

If there are too many data labels, then data labels will overlap and result in the chart being
impossible to read.
• When a report containing a chart is likely to be printed, and data labels are displayed on
rollover, a tabular or pivot table view should be made available by placing it beneath the chart
view within the report. It will assist users in interpreting the data.

5
• The same colors, background colors, and fonts should be used when designing any chart view.

Although a report may seem more pleasing to the eye with a new color scheme or title font when
viewed independently, a dashboard page full of reports with differing colors and fonts will look
unprofessional and may prove to be distracting to the user. A dashboard should always have a clean,
consistent look.
• Bar charts should be two-dimensional and use the cylinder style.

2D charts are more easily interpreted than 3D charts with regards to their exact data representation.
• Column selectors allow users to manipulate a report by replacing columns with other columns,
generating a completely different view of a report.
• The filters view is one of the objects that can be added to the compound layout of a report. The
filters view explains the entire filter criteria used in the report.
• A border added to the filters view to make it stand out from the rest of the report.
• When displaying a report on a dashboard, the report title should go in the dashboard section heading
instead of displaying a title object within the report.
• Displaying the report title as the section heading instead of displaying the title object enables the
user to collapse and expand the contents of each report/section without losing the report title.
• When using a dashboard prompt, the prompt should have its own column and section at the top of
the dashboard layout, and the column width should be set to 100%.
• Guided navigation that allows us to display or hide a section within a dashboard. This technique can
come in handy when you have specific dashboard sections and reports which you would like to keep
hidden unless certain criteria are met.
• Each Report is to be dropped into its Own Section.
• Place Links on Report to external reports or to internal dashboard reports.
• Unless specified by customers please add “No Results” view to each report with a specific custom
message.
• It is a good practice that “Prompts” display some default value. If no specific value is decided we
can make use of “All choices” value provided by OBI.
• Ensure global filters have a default value. Setting value to nothing or all will return all the data and
impact performance
• Unless specified it is recommended to keep “print, download” links for historical reports and “print,
download & refresh” for interval reports.
• Use conditional formatting to focus attention on data outside given parameters
• Use green-bar display on tables and pivot tables for easier viewing.
• Stretch tables and pivot tables to 100% of their available width.
• Use consistent data formats on a dashboard page. Use system wide defaults. In Answers prior to
report development, create table dump and set default before you start developing
• Don’t default to pivot tables; make proper use of table views vs. pivot table views based on the
requirements.
• Apply saved filters vs. filter contents for ease of maintenance. Saving filter content saves it with the
report. If the filter changes later, the content in the report will not change.
• Consider using pivot table charts alongside pivot tables instead of separate chart views for
synchronization with drilling.

6
 • Avoid the use of HTML when possible since it will not translate to reports/dashboards printed to
PDF. Try to find other ways to solve a design problem.
• Please avoid creating measures in Answers & also putting processing statements (like Case) in
Answers as this will degrade performance.

Performance Improvement Best practices & Suggestion

OBIEE Standpoint
• Create separate Connection Pools for Initialization Blocks.
• Set the LOGLEVEL to 0 for the end users in production. Since there is only one Query Log per BI
Server, it would degrade the performance of the report if everyone would try to access/write the
same file.
• Try to avoid creating views in the physical layer. If at all the view is needed, create it in database.
• Always try to follow the Star-Schema design in BMM layer.
• Always try to create Logical fields using physical columns.
• Do not duplicate tables in the physical layer to satisfy the rule that every table must be joined to at
least one other table. This can be done by creating another logical table in the BMM and using
complex joins.
• Try to avoid creating aggregations in the reports. Always use aggregated navigation technique for
any type of Aggregated Facts/measures in RPD.
• Avoid creating calculations in the Reports. All the necessary calculations should be done in BMM if
needed. The best would be creating those in database where possible.
• Try to leverage presentation variable and repository variable whenever possible.
• Caching would improve the performance to quite extent. But the data quality shouldn’t be
compromised for caching. So proper cache management techniques should be followed.
• Most often the area that is left without any focus is the SQL that is written for the reports. A poorly
constructed SQL could amount to serious damage to the performance. SQL Tuning factors could
include

o To ensure that the tables are being scanned based on the primary key
indexes. Also not to forget that Full table scans are not always detrimental.
Discretion can be made on researching the data to be restricted and
retrieved.
o The order of tables placed for JOIN or the FROM clause play a vital role
depending on the optimizer mode of the database, ideally the most
selective table first. The order of predicates in the WHERE clause also
could be beneficial if placed in the right order with the most restrictive
predicate in the beginning followed by the rest. Again, there are no
generalizations in this to be followed. The choice can be made depending
on the situations.
o To minimize or optimize the number of tables that is joined. This of
course would depend on the database design and the schema being used
.But an efficient star schema could give you optimum number of tables
and thereby unnecessary tables that are joined could be avoided. The
fewer the number of table, the more efficient is the query

7
 o Like mentioned before, avoiding not only unnecessary tables but also
unwanted columns could prove beneficial. Since wider the data, more
memory and disk storage is required for any operations such as sorting,
ranking etc.
o Minimizing the data retrieved becomes the key to faster data retrieval.
o Usage of proper where clauses, operators such as GROUP BY that can
replace a DISTINCT for eliminating duplicates, usage of IN operators to
replace OR wherever possible could help in constructing a more optimized
SQL
o Usage of SQL Hints could help at situations, where the type of data
retrieval is exactly known.
o Knowing the database optimizer could be helpful at large since the
appropriate statistics analysis can be done on the underlying tables and
indexes, that in turn will enable the database to estimate the most efficient
method of executing the query in terms of run time and the resource
availability

Data Warehouse Standpoint

• Create Materialized Views or Summary tables for the Aggregate Navigation Reporting.
• Query Rewrite can be enabled for the Materialized Views.
• Range-Hash Partitions with proper partition keys can be created on Facts and large dimensions.
• The older partitions (if static) can be moved to Read-Only tablespaces so that query would work
faster.
• Always keep Table statistics up to date for better query performance.
• Row Chaining should be avoided in the fact tables. Gathering Statistics should remove row chaining.
If not, then the table should be moved to a bigger data block tablespace.
• Enable Star Transformation in the database level.
• Bitmap indexes should be created on Fact tables on the Key columns.
• Also as part of Oracle 10g performance improvement techniques, Bitmap Join indexes on some of
the costly predefined joins can be of huge value addition to the performance.
• Parallelism in the huge tables can add value to the performance. But the degree of parallelism should
be chosen intelligently for better performance.

Why this is a Best Practice:

Customers were very much impressed with the whole application in terms of usability and performance.
They were able to navigate through Dashboards with ease. Also the required data elements were easily
accessible for the users to build their own Ad-hoc Reports.

Benefits:
1. The dashboards were very much user-friendly for the users to use it and navigate across the
application.
2. Customer Satisfaction in terms of Usability and Performance.
3. Following the Standards and best practices would streamline the maintenance activities of the
application.

8
How this may be adapted elsewhere:
Replication
This OBIEE Standards and best practices can be used as a guideline to build an application.

Contact Info
Satya Swarup Choudhury
Tata Consultancy Services
Pittsburgh, PA
Mailto: satya.choudhury@tcs.com