nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

RPD solution

3663358

Hi everyone,

I have some question about approach to model schema in RPD.

OBIEE 11.1.1.9

In physical layer I have model like:

One fact table -> join with product dimension --> vehicles dimension has multiple others dimension.

Bussines Model and Mapping

How to model it in BMM? Which solution should I use?

1. Create model like physical model: Fact table -> Vehicles --> Vehicles User

--> Vehicles K Group

--> Vehicles R Group

2. Create model where I have only Fact Table --> Vehicles. And in Vehical Tables Source and in General Tab/Map to these table - others source like Vehicles Users, K Group, R Group ... and add columns to one table (Vehicle).

In this model in BMM i have only: Fact Table --> Vehicles

Thanks for any suggestions.

Find more posts tagged with

Accepted answers

All comments

Joel Acha

solution 2 is the way to go. you join the vehicle tables in the physical layer and create a Vehicle logical table with each of the 4 vehicle related tables as logical table sources.

Gianni Ceresa

1. isn't a solution as the logical model needs to be a perfect start, so no snowflake allowed there ...

You can also use solution 1/2:

Fact table -> Vehicles

Fact table -> Vehicles User

Fact table -> Vehicles K Group

Fact table -> Vehicles R Group

(remember here it's a logical view, so the source of each dim will actually go through "Vehicles" to join the end table with the fact)

It's all about the meaning and usage of your attributes related to the facts ...

Just keep it as a perfect star and no snowflake.

3663358

Thanks for response.

I have 2-years experience in OBIEE, I changed job and when I analize models in RPD I saw in BMM model like snowflake.

And thats my question which solution should be better. In my recent job I always used solution 2 with multiple logical source or multiple mapping table.

I think that I should change this model(solution 1) to solution 2?

[Deleted User]

I am really surprised at both @Joel Acha and @Gianni Ceresa this morning

While logically the entity relations (yes, entity relations are still a thing) have to be a perfect star visually, the path to get to those can be snowflaked.

So what you have physically on top there can be represented logically on two ways:

1.) Fact table -> Vehicles

Here Vehicles will contain the base "Vehicles" attributes plus all from the other 3 snowflaked tables.

The "Vehicles Dim" table will join to all 3 snowflake tables.

2.) 4 logical dimensions with the relationships

Fact table -> Vehicles

Fact table -> Vehicles User

Fact table -> Vehicles K Group

Fact table -> Vehicles R Group

No here each logical dimension table will have the main "Vehicles Dim" as a source but the last 3 will join in the snowflaked tables and hence change the grain of the query.

So the question becomes: What are you actually trying to achieve? Think about it in analytical terms. If you cram all into one logical dimension versus several ones - what will you eliminate in terms of possibilities? What will 4 logical dimensions give you as options?

Only your NEEDS can tell you the precise answers. And I am talking about needs and not "requirements" since those mostly boil down to "I want this field red and then an export to Excel button with 3 espressos on the side".

Joel Acha

Hi @Christian Berg

I think we're saying the same thing here and I totally agree with your summary which consolidates what @Gianni Ceresa and I originally posted and as you so eloquently described, the preferred option really does depend on what the OP's requirements are.

[Deleted User]

Just wanted to make a joke Joel

Gianni Ceresa

Stop being me: I'm generally the one writing lot of blabla and getting the "right answer" and you writing just few words. In this thread we apparently switched, I better go back to my previous role

Joel Acha

I know.