BMM Layer Vs Physical layer

Sangeeta Pandey

Hello Experts,

May I ask one very basic query please, just for my curiosity:

Though we can create joins, tables etc in physical layer itself, what is need of BMM layer in RPD.

I am sure that there would be some limitations with physical layer and some unique and additional stuffs associated with BMM layer.

It would be great if I can listen about those key stuffs from experts as a help to gain my understanding.

Thanks,

Gianni Ceresa

That's a key element of OBIEE and also a main difference with many other tools.

The physical layer defines the objects (tables and columns) and where they are (database, XML file etc.) and the technical condition connecting them (the join formulas like colA = colB or more complex rules).

The BMM layer defines the role and meaning of things. You can't set an aggregation in the physical layer because it doesn't make sense. But in the BMM layer you can say that a column has to be aggregated using a SUM, and then you define which attributes can be used to describe that measure.

It's like in development when you separate the various layers of your application (the model-view-controller pattern for example): by separating things into different layers, each with a specific role, give you more flexibility and power.

You can have a business model which doesn't change, but you can decide to move the whole physical part from an Oracle database to XML files. If you had only the physical model this would mean trashing everything and starting from scratch, thanks to the split between physical and BMM you don't lose all the business rules, business names and the whole design you did while fully replacing the source of data.

You can't do all the things the BMM layer does in the physical layer, and in the same way you can't do all that the physical layer does in the BMM layer.

Also joins and keys are different.

Sangeeta Pandey

Thanks Gianni, very helpful !!!

May I ask some examples for -Also joines and keys are different.

Thx

Gianni Ceresa

Examples for the joins?

In the physical layer you only provide formulas about how one table relate to another one. The simple one is Table1.ColumnA = Table2.ColumnB, but you can also have more complex formulas like Table1.ColumnA = Table2.ColumnB AND Table1.Date BETWEEN Table2.DateFrom AND Table2.DateTo .

It's really only a formula defining the relationship.

In the logical model you define joins, not as formulas but only between logical objects and defining if it's an inner or outer join. OBIEE will look at the physical objects behind the logical objects and will try to find a physical join which can be used when generating a query.

The physical keys aren't much important. They can be imported from your DB or OBIEE define them when you set physical joins, but you generally don't really spend time looking at the physical keys.

The logical keys really act as keys for the logical table you defined. Because a logical table can be the result of multiple physical tables joined together you need to tell OBIEE what column(s) are a key of the logical object.

The most common example for the difference between logical and physical key is, for example, a products dimension. In the physical layer the PRODUCT_ID, a technical column in the database being a unique number, is the physical key.

But once you look at the logical table for products the key must have a business meaning. Your users couldn't care less about the numeric unique column of your database, they probably identify products by name or by product code. So your logical key will be the product code + product name (to make sure it's unique), and your users will recognize they products by seeing "#PC02 A great laptop" (logical key) instead of "32232" (physical key).

It's also about names: a database often has uppercase column names without spaces but with _, in the BMM layer you must rename the column to make them understandable by your business users: uppercase, lowercase, spaces etc.