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.