Right now you are still missing what make OBIEE .... OBIEE: the RPD.
The Subject Areas are only the last step of modelling in OBIEE, you first define your physical objects (tables, columns, databases etc.), you set joins and the required info. From there you build a logical model by using physical objects.
In a subject area you expose all or part of a logical model, and OBIEE will do the smart job of generating queries thanks to the model you defined in the RPD.
I'm quite sure there was an Oracle tutorial on building an RPD, let me see if I still manage to find it ...
I would say you better stay away of direct database requests (DDR), mainly because you would be bypassing most of what OBIEE is and you will be left with not much more than what a free SQL Developer or a free APEX app could do ....
Easier than expected to find the links.
Check all the OBIEE 11g tutorials at https://www.oracle.com/middleware/technologies/bi-enterprise-edition/tutorials-11g/ .
In your case you have to follow "Creating a Repository Using the Oracle BI 11g Administration Tool".
It will take you from an empty (or existing) RPD through the steps of defining the physical objects, build a logical model and expose it as a subject area.
Thanks for that feedback.
I have been trying to figure out exactly where RPD fits in the puzzle. It seemed to me that I had to have that modeling layer in there somewhere, but the tutorials I have read and viewed all gloss over that part. They pickup with the data already exposed in OBIEE as a subject area.
So, I will investigate further on that front. If you find that good tutorial, please post it. In any case, thanks for the guidance.
The link to the tutorial is just in the reply above, in the list of tutorials one is named "Creating a Repository Using the Oracle BI 11g Administration Tool", and it's the one you look for.
It's quite long as it covers all the steps (as far as I remember), it takes you through the whole RPD creation process.
You are in OBIEE 11g, so the brain of OBIEE is really all in the RPD, without it you just have an extremely expensive "SQL Developer" not even being as friendly as SQL Developer.
In OBIEE 12c and OAS there is, in addition to the RPD, an alternative way to the modelling in the RPD which is the self-service approach in Data Visualization (it isn't like the OBIEE you saw in 11g).
Thank you very much!
Will get started right away.
Thanks for the guidance.
I was able to walk through the RDP process and get everything working nicely. Once you understand the ODI/OBIA/OBIEE relationship, things make a lot more sense.
This link was very well done.
The only thing I would have done differently was show how to "add" a new subject area into an existing repository. She shows all the steps, creating the repository from scratch, then activates it. This effectively "swaps out" the current repository on the OBIEE site. Well, that's not good if you have lots of stuff already deployed. So, the take away would be how to develop the model and then import it or to add it into an existing repository.
With that said, it is a great primer.
Just to make some things clear:
A 20mim YouTube video will hardly teach you how to develop a good RPD. More explicitly: that video will most definitely not show you that.
It is an absolute violation of the RPD concepts to not create dimensional hierarchies.
You never ever keep the technical names of source objects as-is in technical terms and upper case to SCREAM AT YOUR USERS.
Facts contain measures, calculations and nothing else as of the BMM layer. No attributes.
And about 50 other things.
It's an extremely basic primer at best which covers about 2% of what the RPD is and does. Be careful not to fall into the trap of thinking "this is how it works"
"So, the take away would be how to develop the model and then import it or to add it into an existing repository."
If you are talking about real development processes with for etc, then you anyways have a much much more elaborate process, but simply put: you normally don't develop each model in a separate RPD and then combine them but you work in one RPD and just keep adding things. It's just metadata. There is no harm in having 50 business models for trying out things in your sandbox as long as you develop cleanly and kill things that are unnecessary before deploying to a real environment like dev or test.
Like I said, it was well done. What I didn't explicitly say was "for its purpose."
It wasn't trying to address all the points you made. It was showing you how to take some tables that you have and make them visible. It wasn't trying to make us experts.