Explain RPD Three-Layer Architecture in Oracle BI

11 / 55

RPDbeginner

RPD Three-Layer Architecture

Explain the Physical, Business Model & Mapping (BMM), and Presentation layers that make up the OBIEE repository and why the separation matters.

The repository is what turns a database schema into something a business user can query. It has three layers, and almost every OBIEE interview starts here.

It's like a restaurant menu (Presentation layer) that lists "Grandma's Roast Chicken" — simple and appealing — while the recipe card (BMM layer) defines the actual technique and ingredients, and the walk-in fridge inventory (Physical layer) tracks the raw chicken, herbs, and vegetables exactly as delivered.

Key Concepts

    Physical      the database as it actually is
    Business Model & Mapping   the star schema you want it to be
    Presentation  what the user sees

Physical mirrors reality. Tables, columns, keys, joins and connection pools exactly as the source database has them — including the awkward parts: a join on three columns, two physical tables holding the same conceptual data, a lookup that is really a view.

BMM is where the modelling happens. Physical tables become logical facts and dimensions. Logical joins describe the star schema. Calculations are defined. Hierarchies and levels are set up.

This is the layer that does the work, and the one that takes the skill.

Presentation is a curated view of BMM. Renamed, reorganised, and subsetted into subject areas and folders for the people who will use them.

Why three rather than one. Changes flow in a controlled direction:

    a source table is replaced      -> change Physical, remap the LTS.
                                       BMM and Presentation unchanged.
                                       Every report still works.
    the business wants different
    names and folders               -> change Presentation only.
                                       No model change.

One BMM can also feed several presentation catalogues — finance sees its vocabulary, sales sees theirs, over the same model.

The dependency chain runs one way.

    Physical -> BMM -> Presentation

Which answers the question interviewers ask: why does a physical join error break a dashboard that never touched the physical layer?

Because the presentation column maps to a logical column, which maps through a logical table source to physical tables, joined by physical joins. The user selected something three layers up, and the query is generated all the way down.

Renaming, traced through. Rename a physical column and the BMM mapping follows it, and nothing visible changes — the logical column keeps its name. Rename a presentation column and only the label changes; existing analyses referencing the old name break unless it is renamed rather than replaced.

That difference — rename against delete-and-recreate — is what determines whether saved reports survive.

What the interviewer is probing.1. "Name the three layers and their purpose." Probing: the foundation. Stalls: "Layers." Moves up: physical mirrors the sources, business model and mapping defines the dimensional model and logic, presentation exposes a user-friendly subject area.

2. "Why not expose the physical layer directly?" Probing: the argument. Stalls: "It is untidy." Moves up: the business model is where conformed dimensions, calculations and aggregate navigation live — without it every analysis repeats that logic.

3. "What does the business model layer hide?" Probing: the value. Stalls: "Table names." Moves up: physical complexity — multiple sources, aggregates, fragmentation and snowflakes all collapse into simple star-shaped logical tables.

4. "What is the usual beginner mistake?" Probing: experience. Stalls: "None." Moves up: modelling the physical schema straight through, so the presentation layer inherits snowflakes and users must know the joins.