OBIEE Subject Area Planning (Part 1)

As the stating point for any content creation with Oracles BI platform, Subject Areas, also called
Presentation Catalogs, require a good deal of thought and planning to properly match what each
user communitys 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, Ill 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 isnt 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.
OBIEE Subject Area Planning (Part 2)
In the previous blog entry, I discussed ideas about which Subject Areas you may want to have in
your system. This follow up post will discuss some thoughts on what the insides of a Subject Area
might look like.
Now that youve identified which areas you are going to have, lets talk about how to organize
them. As before, there is no one right way of doing things, but Ill cover some ideas to consider
that might work for your system.
I think there are a few things you should strive to achieve directional goals when doing your
design in other words. As such, it doesnt mean that you will achieve it, but it may help you make
a better decision when doing your design. The primary goal of a Subject Area is to allow a user in
Answers to easily construct a report. To achieve this, your Subject Areas must be organized into
an easily usable format for your target audience.
Not too big: Try not to let your tables get too large. Employ the capability of table folders to
organize a long list of fields into meaningful subsets. Perhaps for a large Customer table you
might have a subfolder for Geographical fields and another for Demographic fields.
Not too small: Frequently this means abstracting away from what your Business Model looks like
by combining several smaller logical tables into one larger one that to a user is the same thing,
but due to how the BM was built you had to alter that view. An example of this would be the
need to have several small dimension tables that are on a similar topic, but had to be broken up
to make the RPD work correctly. Perhaps these could all be merged into one Presentation table
to make things easy to use.
Alphabetical vs. Most Commonly Used: Withing a table, will you order your fields alphabetically
or put the most commonly used ones at the top? Perhaps subfolders can be used to remove all of
the lesser used fields into subfolders while leaving the most commonly used fields in the main
folder.
Poor Use of Subfolders: I have seen some deployments where a single table holds all facts, but
has several subfolders for each grouping of fact tables. This is a waste of a layer (you only have
2!) and eliminates any further organizational capabilities such as the ones discussed in this post.
Ive also seen this done with Dates or Geography or People. Instead, use the proper name of the
table, in the case of dimensions it would be the role of the dimension. For example, dont do a
Dates folder with subfolders for Open Date and Close Date instead just have two top level
folders for Open Date and Close Date.
Identify the Land Mines: Although it would be great if it were true, there are nearly always
some special fields that dont work well within the model. They may require special usage and
only work in certain cases, and will blow up a report if used incorrectly or at all. If you are
unable to separate them out from the subject area completely, then one trick Ive used is to
create a special folder or subfolder to store the Land Mines in. I also make sure to clearly
identify the folder with a warning label, such as for internal use only do not use.
Maintainability: All of these things will mean more work for the development team. Try to find
a balance between usability and maintenance effort. However, in the majority of circumstances
usability should win out.
Consistency: Be as consistent as possible with your Subject Area layouts. If you have decided to
put all Metrics at the bottom of the Catalog, then always do so.
Finally, when you have completed your Subject Area layout and filled it up with fields, part of
your deployment to any ad-hoc user community should include Subject Area Documentation. This
is effectively a road map to the area how it works, where it comes from, what works with what,
which tables or fields require special usage and any Land Mines to be aware of.
There is a process for determining what these areas look like, and it begins during the
requirements gathering process. If done in a good, top-down fashion, a highly organized and
usable Subject Area will come relatively easily. Over the years Ive developed techniques and
processes to ensure that there is a tight relationship between the requirements we gather, our
supporting designs, and the resultant Subject Areas.