OBIEE 12c repository modeling question

3310714

Hi all,

Many thanks for all your valuable insights into my question.  The concept of the BMM model is something I'm still having trouble grasping.  I need more practice and experience to fully understand how design and develop it.   The Physical Layer is easier since that's just building the SQL joins. 

The user wanted to pull Customer (PURPLE), Accounts (GREEN), and Financial (ORANGE) information from the relational database.  The physical/complex joins goes through the bridge table (BLUE).  Christian's point b) is what I followed to get my repository working.  No errors so far.  I used the bridge table as the Fact and the others kind of like snowflake Dimensions. 

Gianni - Thanks for clarifying about why complex join doesn't show up in the BMM.  Yes, I used the drag and drop method to popular the BMM from Physical.   I only learned to do drag and drop from my training, so didn't know about creating them manually.    You mentioned that we should be manually creating the logical keys instead of using those from drag and drop.  But, won't it be the same thing? 

[Deleted User]

Excellent

Dont worry it's sth many people.have a hard time wrapping their brains around.

Just keep going and ask stuff in here if need be.

Gianni Ceresa

3310714 wrote:You mentioned that we should be manually creating the logical keys instead of using those from drag and drop. But, won't it be the same thing?

It's of course not mandatory to make them by hand like it isn't forbidden to do drag & drop

I always prefer to say you have to create logical keys (and logical joins) by hand as it's the perfect chance to challenge your model and not just keep thinking (or hoping) that what you modelled at a physical level also make sense from a business point of view.

The BMM layer is extremely important and you must totally forget the physical structure of your data and think at the business logic and meaning of what you are doing and how users will use your model.

The point about logical keys not always being the same as a logical key is for example when you had surrogate keys in your tables everywhere. A surrogate key has strictly no meaning for a end user (business meaning). So these keys are even not supposed to exist at all in the BMM layer. Instead you must identify what does make your data unique from a business point of view.

So challenging your model by doing things by hand is a way to give the required importance in the modelling part and not just deliver to your users a physical database structure (think if you report against an operational db being maybe more 3nf than dimensional, or datavault sources).