Monthly Archives: March 2013

How the OBIEE RPD Relates to the Data Warehouse

March 29, 2013

In the beginning of OBIEE, there was the RPD.  What does that stand for?  Repository Database?   Repository Protocol Design? Repository Project Design? The reality is, it doesn’t stand for anything.  Really. Take it from Kurt Wolf, one of the foremost experts on OBI – who worked on the original project team for nQuire (the predecessor of Siebel Analytics, now OBI).

Look, when you’re building a product and need a file in a proprietary format, you look at all the file extensions out there (there are databases for this) and try to find something that’s unique, obsolete, or very rare. “RPD” met those criteria at the time (1998). But no one ever said what RPD was an acronym for — so you can make something up, if you like (“Repository Definition” — sure, why not? “Repository Protocol Design” — if that sounds better to you. “Repository Product Detail” — whatever). The fact is that none of these are really historically accurate.” (Source:

All trivia aside, the Oracle Business Intelligence RPD is a file with the extension “.rpd,” which contains data definitions and business rules known as “metadata.”  It is composed of three tiers known as “layers.”

  • The physical layer: Represents the actual tables and columns of a database/data source.  It also contains the connection definition to that database, or data source.  You will also find that it has join definitions including primary and foreign keys.   At this point, OBIEE knows where the tables are and how they join.  Keep in mind, this is a very over simplistic explanation, and that there are many other features in the physical layer I could write several other blogs on.
  • The business model mapping layer: Here we start to simplify the model that is defined in the physical layer, perhaps collapsing snowflake schemas into the parent dimension.  We also have to tell OBIEE how these business model objects join together.  Why is this, you say?  Because this is where we set the parity of the join (i.e. inner, left outer, right outer, etc.).  This is where business logic is added in to the mix in the form of formulas.  You can also build logical structures that are based on physical or other logical structures.  Your aggregation rules are defined here as well.  All-in-all, the business model mapping layer is really the heart of OBIEE in terms of understanding how it “thinks”.
  • The presentation layer:  Presents the tables and columns to end users.  There is no additional logic, other than security rules, being applied at this layer.  The main purpose of the presentation layer is to organize content for users in a way that is most meaningful.  It also gives the OBI developer an easy way to see how the output will look without having to toggle between the RPD and the OBI user interface.

But what does all this really mean?   It means the activity of developing an RPD is very similar to building a data mart.  In fact, the RPD developer is usually the one to design the data mart in the database.  In many cases they are also an ETL developer.  That means an understanding of data warehousing and data modeling is needed for building a proper RPD.  If you work within a large OBIEE shop, you may only build in the RPD and take the information you need from other people.  But in this economy you will find that most experts, like myself, have a deep understanding of the complete process and wear all the hats involved from data source to target in the RPD.

This means you should treat RPD with the same, if not more, respect as you do your data warehouse and/or data marts.  Remember also that OBIEE can federate many sources of data.  Which means that the RPD will most likely account for more than just the warehouse.  It can easily sit atop of a transactional database, communicate with Oracle Hyperion Essbase, and a number of other file types.

Any project involving the implementation of OBIEE must involve your data warehouse team.  You should plan to get the time of those resources that are responsible for data modeling within your organization and assess the readiness of the warehouse for OBIEE.  This is an activity we perform a great deal at Performance Architects – because we understand the value this brings to the project during the RPD build phase of the project.    People are often surprised to hear this because they think that OBIEE has some way of correcting data quality issues.  There is also a perception that OBIEE can just query from any data in any form.  This is simply not true.

It is very important to understand that OBIEE mandates a fact and dimension structure in the business model layer of the RPD and that at some point OBIEE can only do so much in the physical layer to accommodate deficiencies of the data.  So while I’m not saying a star schema is mandatory, I think building a dimensional model in the underlying database is a short-to-mid-term goal that should be established at the onset of any OBI project, depending on the level of funding and available IT resources you have.

Want to learn more about OBIEE? Join the Performance Architects Learning Center™! The Learning Center™ is a community and forum that provides on-demand business education related to the business intelligence (BI) and enterprise performance management (EPM) arenas. To register and learn more, go here.

Author: John McGale, Performance Architects

© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.