Business Intelligence Perspectives

By M
New Features in OBIEE 11gR1 for Data Modelling
rk

a
R ittman
The 11g Release of Oracle Business Intelligence intro-
duces a number of data modelling enhancements to allow
more complex hierarchies, the use of lookup tables, double-
columns, and other features. This article describes these
new features and how you might use them when creating an
Oracle Business Intelligence 11g repository.

1. Enhanced support for logical dimensions, including skip-

level, ragged, and parent-child hierarchies.
When creating level-based hierarchies (the only option
with Oracle Business Intelligence 10g), the situation may
arise where the hierarchy that you need to create is either
“ragged” (where each leaf member is not necessarily at the
same level in the hierarchy), or “skip-level” (where some
members may not have an immediate parent, instead “skip-
ping” to the level above). Figure 1 below shows a level-based
hierarchy that is both ragged, and skip-level.

Figure 2: Specifying Ragged and Skip-Level

Dimension Structure

should be used as the key for the logical dimension table, and
used as the lowest level in the logical dimension, as shown in
Figure 3 below.

Figure 1: A Sample Ragged, and Skip-Level Dimension Hierarchy


Ragged and skip-levels are represented in the underlying
dataset through NULLs at either what would normally be the
leaf level, or at levels that would normally hold a dimension
member ID.
The 11g release of Oracle Business Intelligence gives
developers the ability to specify dimensions as having ragged,
and/or skip-level hierarchies, when editing the properties of
the logical dimension, shown in Figure 2.
Specifying Ragged and/or Skip-Level means that the BI
Server will anticipate NULLs for dimension member IDs, Figure 3: Adding a Surrogate Key Level to the
and when used in combination with hierarchical columns Logical Dimension Hierarchy
(described below), either stop drilling down at that point (for
ragged hierarchies) or jump up or down two levels (for skip- When creating an associated hierarchical column for
level hierarchies). the logical dimension, as mentioned in point 2 below, this
One point should be noted when working with ragged additional level can be deleted as a presentation level from
and skip-level hierarchies. When working with a ragged hier- the hierarchical column, so that the user can only drill down
archy, as each leaf member of the ragged dimension may not as far as the immediate level above, which is the maximum
be at the lowest level of the hierarchy, it is necessary to add a depth at which a leaf member could normally exist.
surrogate key to the dimension table to provide a consistent The 11g Release of Oracle Business Intelligence also in-
column on which to join to the fact table. This surrogate key troduces support for parent-child or value-based hierarchies.
Now, when a developer chooses to create a logical dimen-

Fourth Quarter 2010 | ODTUG Technical Journal | 11

 sion within the business model, the option is given to create
the logical dimension as either level-based or parent-child, as
shown in Figure 4 below:
Business Intelligence . . . (Continued)
2. Hierarchical Columns
The 11g Release of Oracle Business Intelligence allows you
to drag and drop logical dimensions from the business model
into presentation layer subject areas, to create hierarchical col-
umns. These columns are made up of presentation layers, and
when included in an analysis, allows the user to perform “in-
column” drilling on their data set. Hierarchical columns can ex-
ist alongside regular dimension columns (now called attribute
columns) and measure columns. Figure 6 shows a hierarchical

Figure 4: Specifying a new Logical Level as Having a

Parent-Child Hierarchy

Then, when the new logical dimension’s properties are

specified, the developer has to specify the logical column that
contains the Parent ID to go with the Member ID, creating the
parent-child link. Once this is done, a closure table has to be
created, which contains, for each dimension member, a recur-
sive list of which members are its parents, grandparents, etc.,
avoiding the need for the BI Server to issue recursive SQL when
the dimension is traversed. Figure 21 shows the wizard that can
be used to create this closure table, which generates two SQL Figure 6: Creating a Hierarchical Column
scripts, one to create the closure table, and one to populate it,
the second of which needs to be re-run whenever the underly-
ing dimension data is refreshed, as shown in Figure 5. column being created from a logical column in the business
So, one question that developers new to the 11g release of model.
When included in an analysis, the hierarchical column
allows the user to drill into the hierarchy within the same col-
umn, coping with ragged, parent-child and skip-level members
without problems, as shown in Figure 7.
As shown
in the previous
item regarding
ragged hierarchies,
these hierarchi-
cal columns can
implement all, or
a subset, of the
logical levels in
their related logical
Figure 5: Creating the Closure Table dimension, and
each hierarchical
column represents
Oracle Business Intelligence may have, is when to use a ragged a single hierarchy,
level-based hierarchy, or in fact a parent-child hierarchy, if they so that two are cre-
wish to create a ragged hierarchy within the business model (as ated, for example,
parent-child hierarchies are by their nature, naturally ragged)? when a logical
The answer to this question is determined by the nature dimension with
of the data in the source dimension table. If the table naturally two hierarchies
has levels (e.g., columns that hold clearly identifiable levels of is dragged into a
data), then you should create the dimension hierarchy as level- presentation layer
based and ragged. If the underlying source data does not subject area.
naturally have named levels (perhaps in an organizational hi- Figure 7: Displaying a Hierarchical
erarchy, or a hierarchy of trading books) then it would be better Column in an Analysis
suited to a parent-child dimension hierarchy.

12 | Fourth Quarter 2010 | ODTUG Technical Journal

3. Lookup Tables
Whilst most lookup data will be referenced in a semantic
model by extending logical table sources to reference associ-
ated data, in some cases developers may wish to import the
metadata for standalone, lookup tables that may, or may not,
contain lookup values for a particular dimension member, as
shown in Figure 8.
Figure 8: Defining a Logical Lookup Table
Typical scenarios where this may be useful, include:
• Currency conversions that you wish to perform as a separate,
standalone calculation
• Accessing datatypes such as CLOBs that cannot be included
in a GROUP BY clause
• Avoiding the mandatory including of joins and tables in an
SQL query relating to a logical table source that uses an outer
join
The 11g release of Oracle Business Intelligence allows develop-
ers to either reference lookup data in a physical table, through
a logical table source mapping, through a new LOOKUP
function, or to define a logical table as being a lookup table
and again reference it through the new LOOKUP function. In
both cases, the lookup can be specified as being either DENSE
(where there will always be a corresponding lookup value for a
dimension member), or SPARSE (where values may not be pres-
ent, analogous to a left outer join in SQL).
The syntax for SPARSE and DENSE LOOKUPs is as follows:
Lookup(DENSE <<lookupColumn>>, <<sourceKeyorExpres-
sion>>)
Lookup(SPARSE <<lookupColumn>>, <<alternateColumn>>,
<<sourceKeyorExpression>>)
When a physical table is referenced through the LOOKUP
function, the BI Server will generally push the inner or outer
join required to access it into the general SQL statement used
for the query. For logical tables accessed via a LOOKUP func-
tion, the BI Server will generate a separate SQL statement for
the lookup, which it will join back to the main data set using an
in-memory join.
To create a lookup involving a physical table, first import
the physical table’s metadata into the physical layer for the
semantic model, ensuring that you define a primary key for the
table. Then, extend the relevant logical table source to include
an entry for the new lookup column. Finally, using the new
LOOKUP function, use it to reference the lookup column, using
a function call such as:
Lookup(DENSE “orcl”.””.”GCBC_SALES”.”Lkp_
Business Intelligence . . . (Continued)
SEASONS”.”SEASON_DESC”, “orcl”.””.”GCBC_SALES”.”Dim_
TIMES”.”MONTH_YYYYMM” )
where SEASON_DESC is the column being looked up, and
MONTH_YYYYMM is the column in the logical table that cor-
responds to the key of the lookup table.
To define a logical table as being a lookup table, tick the
Lookup Table tickbox (as shown in Figure 24, above) to define it
as such in the business model. It will then pass repository con-
sistency checks even though it does not have a logical join to a
fact table, and you can reference it using the regular LOOKUP
function syntax.
4. ID and Descriptive Double Columns
Another new feature introduced with OBIEE 11g is the
ability to associate ID columns with descriptive columns in the
repository, so that filters applied to analyses can use these IDs.
This is useful, for example, when you wish to display product
descriptions as text, but filter on the ID, and is also useful when
you wish to create multiple logical columns containing transla-
tions but filter on a common ID column.
To define this feature, called Double Columns in the OBIEE
documentation, edit the properties of the descriptive column
in the repository and use the Descriptor ID setting to select the
associated ID column, as shown in Figure 9 below.
To make use of the new ID column, create a dashboard
prompt as normal, and you will see the ID column listed as the
Figure 9: Setting an ID Column for a Descriptive Column
Included Code Column under the Prompt For Column setting,
as shown in Figure 10 on next page.
Fourth Quarter 2010 | ODTUG Technical Journal | 13

Business Intelligence . . . (Continued)
Figure 10: Creating a Dashboard Prompt using
Double Columns
The Enable user to select by Code Column tickbox then allows
the user to optionally display the code alongside the descrip-
tions when using the dashboard prompt. Figure 11 shows a
typical dashboard prompt where the user has chosen to display
the IDs (this is optional, and the feature still works without the
ID being displayed).
Figure 11: Displaying the ID along with Description in a
Dashboard Prompt
To make use of the double column, create the analysis as nor-
mal using the Is Prompted filter, and create the filter against the
description column as normal. Then, when a column is defined
14 | Fourth Quarter 2010 | ODTUG Technical Journal
as having an associated column, regardless of whether the user
chose to display the ID values alongside the descriptive values
in the dashboard prompt, the SQL issued by the BI Server will
still filter against the ID values only.
5. Logical Table Source Priority Group Ordering
When a situation arises where more than one logical table
source could provide data for a logical column, the source that
is chosen is typically determined by the level in the logical
dimension that the source is mapped in at, so that for example,
a logical table source mapping to aggregated data is chosen
in preference to a detail-level one when an analysis involves
aggregation. In circumstances where there are multiple source
mapped in that refer to aggregated data, the Number of Ele-
ments at This Level value is considered, for each applicable
dimension, to determine which source is used.
As it can sometimes be unclear which source will be used
in these circumstances, the 11g release of Oracle Business
Intelligence introduces a feature called priority group order that
allows the developer to explicitly prioritise data sources in this
situation. This setting is then generally the favoured determinant
in selecting a logical table source for a logical column. Figure
12 shows this setting, with an aggregate logical table source
initially being set to Priority Group 0 (so that it is considered as
high priority as the detail-level logical table source, and there-
fore used), and then being set to 1 (making it lower priority than
the detail-level source, leading to it not being used even though
otherwise it would qualify).
Figure 12: LTS Priority Group Settings, and affect on Generate SQL
6. Changes to Repository Handling and Maintenance
The final major change to data modelling with Oracle Busi-
ness Intelligence 11g is in handling of the actual RPD file. As
users and groups are no longer stored in the repository (instead,
moving to, in the current release, the WebLogic server), there is
now no mandatory Administrator account with an Administra-
tor group. So that repository files can still be opened offline,
securely, RPD files now are encrypted and have a repository
password, which can be set using the BI Administration tool
menu.
In addition, Oracle Fusion Middleware Control is now used
to take repositories online, rather than the developer editing by
hand the NQSConfig.INI file, as shown in Figure 13 on next
page.
When a new repository needs to be taken online, Fusion
Middleware Control is used to browse to the required RPD file,
 Summary
The 11g release of Oracle Business Intelligence introduces
a number of new features that can be useful for data modelers,
and introduces new ways to manage and upload repository files
using Oracle Fusion Middleware Control. These new features
can be particularly useful when working with complex hierar-
chies, with currency conversions, and when needing to filter
data on IDs when selections are presented as descriptions,
among other scenarios.

Business Intelligence . . . (Continued)

Figure 13: Uploading a new Repository
and then these changes are activated, which in turn moves a
copy of the file to the relevant instance directory, and updates
the NQSConfig.INI file. After this file has been applied, the
Restart to apply recent changes button is pressed which then
gives the developer the option to restart all services, or just the
BI Server, so that the changes in the configuration file are then
made active.
er
emb
About The Author M
Mark Rittman has worked with Oracle Business Intelligence,
in both the previous Oracle Discoverer form and now
Oracle Business Intelligence Enterprise Edition, for over
thirteen years, is an ODTUG Director and an Oracle ACE
Director, a regular writer on business intelligence for Oracle
Magazine, and is co-founder of Rittman Mead.

Technical Calendar
January 2011 June 2011

Northwest Florida Computer Tech Conference OHUG Global 2011 Conference

January 29, 2011 June 19-23, 2011
Niceville, FL Orlando, FL
www.cfcs.org JW Marriott
www.ohug.org
february 2011
ODTUG Kscope11
Rocky Mountain Oracle Users Group (RMOUG) June 26-30, 2011
Training Days & University Sessions Long Beach, CA
February 15-17, 2011 Long Beach Convention Center
Denver, CO www.Kscope11.com
Colorado Convention Center
www.rmoug.org

Fourth Quarter 2010 | ODTUG Technical Journal | 15