Dimensional modelingowb11gr2 paper

Dimensional Modelling with OWB 11gR2

Maren Eschermann
Trivadis AG
Zürich

This document describes the features of the Oracle Warehouse Builder for dimensional
modeling, their functionality but also their limitations.

1. Introduction
Oracle Warehouse Builder 11.2, but as well as earlier releases, offer many features and support
for implementing data marts and their corresponding loading processes. Slowly changing
dimensions, orphan management, time dimension with several hierarchies and tact tables are
realized quickly and in a standardized way while applying best practices. Dimension and cube
operator allow implementing loading mappings very efficiently. Even materialized views
(relational as well as cube based materialized views) can be generated by Oracle Warehouse
Builder with only a few mouse clicks. But what are the limitations of these features? Are there
reasons for not using them and manually implementing the star schema structures and the loading
processes? This paper gives answers to these and similar questions and offers decision support
when, where and how to use the dimensional features most efficiently.

2. Building a Dimensional Model with Warehouse Builder
2.1 Dimensional Modeling Basics

The dimensional model of a data mart consists of dimensions, hierarchies, facts and aggregation
rules and can be described, for example, by an ADAPT model. It represents the interface between
the business and the IT department, a common understanding of that model is crucial for the
success of the project.
When moving from the dimensional to the relational model very often the “dimensional
semantics” are lost. To derive the hierarchy of a dimension from the corresponding relational
table is hard or even impossible. To avoid this metadata should be enhanced to include the
dimensional model as well. That is exactly what happens when using the Oracle Warehouse
Builder and its dimensional features.
Oracle Warehouse Builder allows realizing the relational as well as the multidimensional
implementation of a data mart. In the following we focus on relational data marts.

2.2 Modeling a Dimension

A dimension consists of levels, hierarchies, and
attributes. Each level has a number of attributes,
the relation between levels is defined by
hierarchies. A dimension can have more than
one hierarchy. The time dimension might have a
week or fiscal year hierarchy besides the
standard hierarchy. With support of the OWB

info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 11.01.2012 . Seite 2 / 8

dimension wizard the specification of a dimension can be done in a few steps. Not only the
dimension is created but also the dimension table and a sequence are created as OWB meta-
objects.
A dimension table has the following properties:
 Table name = <DIMENSION NAME>_TAB
 A primary key on the DIMENSION_KEY column
 A number of columns for each level
 An index on the business key of each level
If dimension properties are modified, you have to
perform an “automatic binding” to propagate these
modifications to the underlying dimension table. If you
have manually modified this table beforehand, all your
modifications (comments, additional constraints, …) will
be overwritten. Moreover the primary key of the dimen-
sion table gets a new name, this results in an error if you
already have fact tables referencing the dimension.

If project specific guidelines exist, which are not compatible with automatic binding and the
resulting dimension table properties, you can disable the auto binding feature and do the binding
between the dimension and its table manually. This way you have all freedom concerning the
naming, definition of constraints and other properties of the dimension table.

A dimension object has properties which are only applicable if the dimension operator is used as
target operator in a mapping. This is true for configurations concerning historization (Slowly
Changing Dimension) and orphan management. In chapter 3.2 we will elaborate on that topic in
more detail.

OWB 11.2 offers some advanced possibilities concerning the modeling of dimensions. In 11.2 it
is possible to create a dimension without surrogate key, which allows having degenerate
dimensions for example.

2.3 Time Dimension

Effectively each fact table references the time dimension at least once, very often the fact table is
partitioned by time. In earlier versions the time dimension table had a surrogate key like all other
dimension tables, which have been referenced by the fact tables. With this the partitioning by
time was difficult. OWB 11.2 realizes the time dimension table with a date column as primary
key. This way also the fact table has a date column and partitioning can be easily done.

2.4 Modeling a Cube

A cube consists of measures (facts), dimensions
and aggregation rules, which define how the
measures can be aggregated along the
hierarchies of the dimensions.
With the cube wizard the user can define a
cube and all its properties.


The fact table, which is automatically generated, has the following properties:
 Table name = < CUBE NAME>_TAB
 One column per dimension with foreign key constraint and optionally a bitmap index
 One column per measure
 Optionally a composed unique key constraint consisting of the combination of dimension
columns
The fact table can be manually created and bound to a cube. Again, this is required if project
specific requirements cannot be reconciled with the default properties of the automatically
created fact table. For example, the fact table will be very often partitioned or foreign keys are
disabled to load more efficiently.

3. Implementing the Loading Processes
3.1 Loading a Dimension

Implementing the loading process for a di-
mension is very easy and efficient when using
the dimension operator. This operator realizes
the following functionality:
 Populating the surrogate key
 Lookup of the business key
 Deduplicating of level elements
 Realizing Slowly Changing Dimensions
 Orphan Management

The dimension operator supports two different
loading types: LOAD and REMOVE. Generally
the LOAD type is used, while the REMOVE type
is only applied if SCD2 is implemented (for
more details see chapter 3.2).
If deduplication of level elements is necessary,
you can apply the Enable Source Dedup
property, which is the default configuration.
When applying this property, the elements of all
levels are deduplicated. If the source data is
already unique and deduplication is not necessary, you can disable this feature, especially if large
sets of data are loaded and performance is an issue. Please note that in this case the dimension
operator no longer guarantees the uniqueness of the business key.
When mappings using the dimension operator are deployed an OWB$TEMP table is created in
the target schema for each dimension level. The creation of these tables cannot be switched off,
they are necessary to provide some of the hierarchy management and loading functionality. They
are not truncated after mapping execution, you would have to implement that manually (e.g. by
using a post-mapping operator) if this is necessary.


With the exception of the time dimension Warehouse Builder realizes dimensions always as
“solved dimensions”, i.e. the dimension tables do not only contain records for the lowest level
elements but also for the higher level elements (“control rows”). This allows that fact tables
referencing elements of higher levels, i.e. you can implement a fact table that stores facts not on
the product level but on the
product category level.
When deploying a dimen-
sion, OWB creates a view
for each dimension which
filters all control rows.
Applications that might
have problems handling the
control rows can access the view instead of the dimension table.

3.2 Slowly Changing Dimensions

Very often it is required to keep historical data of a
dimension, this is realized by implementing this
dimension as Slowly Changing Dimension, SCD.
Mostly SCD type 2 is used, which means that the
complete history is preserved in the database. For
relational dimension tables two additional attributes
of type date are needed, which define the validity of a
record:
 EFFECTIVE_DATE defines the „valid from” date
 EXPIRATION_DATE defines the „valid to” date
The properties Type2 Gap and Type2 Gap Units of
the dimension operator allow specifying how
effective and expiration date are set.
The user can specify which attributes trigger the creation of a new record. For all other attributes
only the current record is overwritten with the new value. This is in contrast to Kimball’s Hybrid
SCD, see Kimball Design Tip #15: “Combining SCD Techniques”.
Oracle Warehouse Builder allows the implemen-
tation of Hierarchy Versioning. Whereas Kimball
only describes the historization of elements of
the lowest level, OWB also provides the
functionality of versioning elements of higher
levels.
If you want to logically delete a dimension
record the expiration date is set to the current
date. The dimension operator implements this
behavior, if you are using the load type REMOVE
and the Type2 Extract/Remove Current Only=Yes. Please note that the higher levels of this
dimension operator must not be connected, since they would be deleted physically.
If you have multiple modifications of the same dimension record between two loads, you can use
Support Multiple History Loading. In this case more than one record for the same business key is
created within a single load.


Loading historical data out of order can be achieved by the Out of Order History Loading
property. This might become necessary if you want to load record becoming valid BEFORE the
version of the current record became valid. Assume the current record of a customer is valid since
January 1st 2012 and another record of the same customer valid since December 1st 2011 has to
be loaded afterwards. In this case the Out of Order History Loading property would be required
to load that record. Please be aware, that the facts already loaded for December 2011 will
reference the “wrong” record, which previously has been valid until December 31st 2011 and
which is now only valid until November 30th 2011.
Both properties, the Support Multiple History Loading as well as the Out of Order History
Loading property are switched off by default due to the possible performance overhead.

3.3 Orphan Management

When loading dimensions a level ele-
ment might have an invalid parent
element (Invalid parent key value) or nor
parent specified at all (Null parent key
value). Such records are called “orphans”.
If you try to load such an orphan, you
have the choice between three different loading options:
 No Maintenance: The orphan record is neither rejected nor stored in any error table nor
corrected. No Maintenance is the default behavior and will result into having level
elements in the dimension table without any parent specified (the parent level attributes
are all set to NULL). When aggregating values these orphans are not considered which
might lead to inconsistent reports. If you are using that option (for example due to
licensing restrictions) it is strongly recommended to implement the orphan management
outside the dimension operator.
 Default Parent: The orphan record is loaded and the parent level attributes are set to
default values, which can be specified by the Default Level Row settings.
 Reject Orphan: The orphan record is not loaded into the dimension table but logged into
an error table. This way you have the possibility to reload the record later, when the
missing parent element exists.
All three options are available for invalid or missing parent elements, you can have different
orphan strategies for both scenarios. In pre 11.2 OWB releases, orphans have just been rejected
but without logging them into an error table.
The dimension operator offers a broad range of options how to load the dimension table. This
functionality, which otherwise has to be implemented by the development team with quite some
effort, is available in a standardized manner and with high quality. The user can understand how
the operator is implemented, it is a pluggable mapping which can be expanded (but not
modified).
The complexity of the operator becomes obvious if you count the number of basic mapping
operators which are used to realize a dimension operator for a dimension with three levels: It
consists of
 28 basic operators, when neither SCD nor orphan management is specified
 34 basic operators, when SCD2 is implemented
 54 basic operators, when SCD2 as well as orphan management is implemented


3.4 Loading a Cube

Loading processes for fact tables can
be realized by using the cube
operator. Its functionality encom-
passes the lookup for the dimension
business keys (depending on the SCD
type) and orphan management. For
the lookup of SCD2 dimensions the
ACTIVE_DATE attribute of the cube
operator is crucial. It represents the
point in time that is used to
determine which record in a Type 2
SCD is the active record. The default
value of that attribute is SYSDATE.
The cube operator has the following loading types:
 INSERT LOAD: allows the modification of already loaded facts, which is realized with a
MERGE statement.
 LOAD: only new facts are loaded (inserted). For big data sets this is the fastest loading
option.
 REMOVE: allows removing already loaded facts.
The cube operator offers orphan management functionality for
loading facts with missing or invalid dimension business keys.
The options correspond to those of the dimension operator. If
you choose the “Default Parent” option, remember to enable
source aggregation. Otherwise you might get an ORA-30926
(“unable to get a stable set of rows in the source tables”)
execution error because multiple fact rows are produced with
the same default dimension references.
A loading policy for handling “early arriving facts” can be implemented with this orphan
management functionality. Early arriving facts are those which are loaded BEFORE some of the
referenced dimensions values are loaded.

4. Materialized View Creation
The query performance of a data mart is crucial. Very often when aggregation at query time is too
slow, pre-aggregation by
implementing materialized
views will help. Oracle
Warehouse Builder allows to
automatically create and deploy
materialized views; the user can
create relational materialized
views as well as cube-based
materialized views, which are
stored in an analytical work-
space. The user can specify
which dimension and which levels are pre-computed.


The relational materialized views do not exist as meta-objects in the OWB design repository, but
only in the target user of the database. Whenever you deploy a cube’s aggregation (this can be
specified in the configuration properties of the cube object), a new set of materialized views is
created. The user has to delete the previously deployed set of materialized views manually.
Partitioning of materialized views, the creation of MView Logs to allow Fast Refresh or the
implementation of partition change tracking have to be done manually.
If the user selects the option ROLAP with MViews, not only the cube based materialized view but
also the analytic workspace and all necessary multidimensional elements in that workspace are
created. When using this feature significant functionality is implemented automatically in the
background. Nevertheless a good knowledge and understanding of the underlying technology is
necessary for debugging and maintaining such solutions.

5. Summary
The dimensional functionality of Oracle Warehouse Builder is many-faceted and offers a wide
support for implementing data marts and their loading processes. Modeling dimensions and cubes
inside OWB provides the advantage of having the dimensional model in your metadata (you
avoid the “loss of dimensional semantics”) and of following best practices for the design of
dimension and fact tables. Furthermore the implementation of loading processes with the
dimension and cube operator is very efficient, of high quality, bug-free and standardized. The
realization of slowly changing dimensions or orphan management is consistent throughout the
whole project.
The dimensional features of the Oracle Warehouse Builder are like a tool box; every project team
can take those “tools”, which are suitable. You can use the dimension operator and at the same
time dispense with the cube operator, if your cubes are loaded by a partition exchange strategy.
Some prototyping at the beginning of the project will help to decide which features shall be
applied and which not. Whatever the decision is, the focus should be to have a standardized and
flexible solution at the end, which can be easily maintained and extended.

Contact Details:

Maren Eschermann
Trivadis AG
Europa Strasse 5
CH-8153 Glattbrugg

Telefon: +41 (0) 44-808 7020
Fax: +41 (0) 44-808 7021
E-Mail: maren.eschermann@trivadis.com
Internet: www.trivadis.com


Dimensional modelingowb11gr2 paper

More Related Content

What's hot

Viewers also liked

Similar to Dimensional modelingowb11gr2 paper

Recently uploaded

Dimensional modelingowb11gr2 paper