Before we embark on developing a new repository, let's have a look at how the RPD is structured. The fundamental structure of an RPD is made up of three layers for modeling data:
- Physical layer: This contains the information, for example table/column names and keys, for your data sources, as they exist in their database along with their connectivity details. No data is actually stored in the RPD, just references to your data sources, that is, it is metadata that is stored in it.
If needed, we can also connect to other data sources, for example, Flat files and Excel spreadsheets.
- Business layer: The main purpose of this layer is to create an abstract and simplified model of the physical layer objects. This is especially valuable if we need to combine data from varying data sources. The business layer allows us to integrate these different sources and then present them to an end user as a coherent and unified whole.
OBIEE supports federated querying, so we can query and stitch together data from multiple data sources. For example, we may need to combine multiple data sources into one logical object, such as Geography or Business Department.
We can add business logic to the set of objects that we have described in the physical layer. We can also restructure them as necessary and enhance them via OBIEE server-based calculations and functions.
The final business model that we produce in this layer should be organized as per your business requirements. It should reflect how your business sees and organizes itself.
- Presentation layer: In this layer, we can choose how we present the business layer objects to end users when they actually create reports. We can customize the view of the business layer for those end users, for example, renaming data objects as they pertain to the end user's business requirements.
That was a brief overview of the RPD structure. As we will proceed to actually develop a new project, you will gain more clarity on the role of each metadata layer in the RPD. The example project that we will be developing is that of a fictitious bicycle manufacturer called Adventure Works. This scenario is provided by Microsoft (yes, we know!) and covers an organization that has sales, purchasing, manufacturing, and HR data amongst others. It is typical of the type of project that you yourself will be developing in the BI industry, and provides us with a workable data warehouse structure. We will use this DW schema to create aggregated measures that are reported across multiple dimensions. The tools and techniques that we will teach you in the next chapters can be used in any environment that has a requirement of being able to mine data and generate intelligent insight. So let's start!