Professional Documents
Culture Documents
OBIEE Standards and Best Practices
OBIEE Standards and Best Practices
Development Standards
&
Best Practices
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
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
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.
• 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.
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
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: [email protected]