OBIEE Subject Area Planning (Part 1)

Originally posted 1/8/2007

As the stating point for any content creation with Oracle’s BI platform, Subject Areas, also called Presentation Catalogs, require a good deal of thought and planning to properly match what each user community’s needs with underlying capability.  Although there is no one right way to organize and structure your collection of subject areas, I will discuss some concepts and theories that you should consider for your system.  In this first of a 2 part entry, I’ll go over what your Subject Areas should contain and how many you have, and the next part will discuss how to lay out the insides of the area.

First off, what goes into a Subject Area?  The simple answer is anything that is needed to get a piece of analysis completed.  Frequently I hear questions like, “How do I combine data from two different subject areas into one report?”  Although there are a couple of very limited options for doing so within Answers – Union queries and Sub-queries, the real solution is that the Subject Areas themselves were probably not designed properly.  Everything you need to make your query should be included in the Subject Area to avoid this problem.

Take this concept to the extreme and you end up with a subject area that has everything in the Business Model.  You certainly will not run into any problem of missing fields, but you have now created another problem: complexity.  As your Subject Area grows, its ease of use diminishes.  For projects where only a development team is using Answers (meaning no ad-hoc for Business Users), or where your system is small, this generally isn’t a problem.  However, when users are performing ad-hoc and you have a decently sized system, a balance of size and capability needs to be found.

So, we want to make sure the Subject Area is large, but not too large.  What are some ways you can do this?

Start with the processes that your BI system is supporting – the tasks that users will perform in the BI environment.  Consider making several subject areas, each tailored to support a single process or collection of smaller sub-processes.  Name the Subject Area to be indicative of what processes are being performed on it – what does it support?  This is best illustrated with the Oracle BI Applications (BI Apps).  The Core Business Model in the BI Apps is enormous, but each Subject Area is not – each supports a clearly defined subset of the overall picture that pertains to a topic of analysis.  “Financial Analysis”, “Campaign Effectiveness”, “Sales Pipeline Analysis”, are all examples of how the Subject Areas are ties to a single, often broad, process.  Put whichever elements are needed from the entire Business Model into each area, but leave items out that have no bearing.

Frequently this translates to identifying Stars and including them, but go further to identify portions of Fact tables and subsets or dimensions to help reduce size and complexity.  Ideally, these subject areas will also align tightly with a Dashboard structure – perhaps the “Supplier Quality Analysis” Subject Area also has a corresponding “Supplier Quality Analysis” Dashboard that breaks down the topic into a series of pages and reports.  If you have gathered your requirements in a good top-down fashion, this will be an easier task than you might think as this structure was identified and guided your gathering effort.

There are some other ideas that you may wish to consider to help tailor your Subject Areas to their usage.  One concept is big and small versions of the same Subject Area.  Provide two versions of the same area, but while one has everything needed, the other one only has the most commonly used fields, thus reducing its size.  Perhaps the small one (called ‘Overview’ Subject Areas in the Analytical Apps) can be deployed to an ad-hoc community while the full blown one is used by IT developers.

Another Subject Area planning driver is security – which groups of users have access to which pieces of the business model?  How will your security model be implemented?  If you have external groups of users (external can also include people outside of your group, not just external to your company), perhaps they can be furnished with their own Subject Area.  This makes Security administration easier, and allows you to not only put the precise list of elements in the Catalog, but gives you the flexibility of renaming fields to support a group which may be used to older terms that you are no longer using in  your Business Model.

Sometimes there are external tools that access the Analytics layer.  If another query or reporting tool such as MS Access, BO, Excel, or even a Data Mining engine has specific needs, then consider using a separate subject area for that purpose.

Finally, I strongly recommend “test” areas which are useful for IT and testers to validate the proper functioning of the entire business model.  Here I recommend essentially taking the entire Business Model and creating a subject area for it unaltered – no reorganizing of tables.  This area is for the development team to build admin-only dashboards to assist your system test and regression tests.

In part two of this topic I will discuss layout within a subject area.

Please leave some comments regarding your ideas and experiences on Subject Area Planning.


Posted on July 16, 2009, in BI Theory and Best Practices, Presentation Catalog and tagged , , , . Bookmark the permalink. 8 Comments.

  1. Thank You! Very useful article!

  2. Manohar Mishra

    We have requirements to build KPIs which definitely need data from two different Subject ares (of OBIA). For example one of the kpi formula needs Admin Expenses of a certain departement (which we can get as a cost centerwise gl account balances for a certain period) from General Ledger to be divided by the (sfaff) Head Count of that department for the same period, which comes from HR Subjec area. I am wondering whether building altogether new custom subject area (and the corresponding star schema in BMM layer of BI) as the only solution for this. Appreciate if you can throw some light upon any other easy way out for this requirement.

    – Manohar

    • Yes, or you could simply add your HR fields to your financial Subject Area. Or, even still, the headcount doesn’t need to be there if all you want to show is Balance/Headcount – make a new metric for it and deploy that metric to the financial Subject Area.

  3. Regarding this: “The Core Business Model in the BI Apps is enormous..”, this creates a problem which is working with the repository is very very slow, any change, being adding a logical join, adding a new measure, etc. Also when checking consistency, it takes forever even if all you did was just add a new column because it is validating the whole model. I know how to break down the Core, but I am facing yet another problem discussed here which is when a query needs to go across two different business models, for instance from Finance to any of the other areas. I am still looking for a solution that has a balance. Any more ideas on getting this to work from two different business areas/star schemas?

    • How slow your computer is shouldn’t be a reasons for splitting up your business models. If the information can be used together, and your org and project structure can handle working in an integrated business model, then integrate them.

      Make sure you trim the RPD down to only the items you think you will need – remove a lot of the OOB subject areas and the physical layers that you don’t need. Work in offline mode as it is faster. Trim as many initblocks as you can – they slow down RPD start up time a lot. On top of that tell IT to get you a faster development machine.

  4. I concur with Jeff completely. Have been in too many movies where users were expected to pick and choose what they wanted, only frustrated them and elongated timelines. Oracle put a lot of effort into making sure most data was covered in their BI apps. There is plenty of room to trim down the un-needed data. Great article Jeff !

  5. Another way of organizing the subject areas could be summarized vs detailed data. In this way users are not going to create analysis on details while summarized data could be more efficient.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: