1. ○ Home
○ About
○ Clients
○ Consulting
○ Training
○ Support
○ Articles
○ Events
○ Blog
Rittman Mead - Delivered Intelligence
Hybrid SCDs using OWB and OBIEE
July 6th, 2009 by Stewart Bryson
If you attended my ODTUG Kaleidoscope presentation on Oracle Warehouse Builder (feel free
to view the presentation), then you know that certain aspects of the product leave me scratching
my head, especially as a follower of the dimensional modeling approach popularized by Ralph
Kimball. One of the subjects covered was dimensional operators and the lack of support for
hybrid slowly-changing dimensions (SCD’s). For an enterprise data warehouse, this is a real
deal-breaker. When you look at the Customer Dimension, for instance, why would we ever want
to track historical changes to attributes such as Birthdate or Ethnicity? Changes to these
attributes can only be seen as corrections, and these corrections would need to be made to ALL
rows for that particular customer: the current row, and all other rows inserted as a result of Type
2 changes through the life of that customer. There are other examples that might not be so black
and white: sometimes, the end user simply needs to see both Type 1 and Type 2 changes in the
same table.
So what are we left with? We have two choices really. First, we can choose an alternative for our
SCD processing. This could entail custom coding our SCD handling so that we can represent
both Type 1 and Type 2 changes, or possibly using a third-party add-in, such as the Transcend
Framework, which I developed to handle situations such as these (Transcend will hopefully be
available as an option from Rittman Mead, so watch the blog for news). The other more
interesting option would be to go ahead and use OWB for our SCD processing and then attempt
to represent some of our Type 2 changes as Type 1′s in the reporting layer. With the flexibility
that OBIEE provides, I should be able to make a go of it.
First, I’ll use OWB to create a fact table based on SH.SALES called SALES_FACT, a dimension
table based on SH.PRODUCTS called PRODUCT_DIM, and the necessary operators and
mappings to load the two. For the PRODUCT_DIM table, I used a standard dimension operator
with two levels.

2. You can see that I configured all my attributes as Type 2 attributes, including the VALID
column. For the purposes of this example, imagine this to be a kind of Discontinued Flag, set to
(A)vailable or (N)ot Available. Currently, all the products in my warehouse are available for
purchase… at least they are right now. The business informed me that they would like this
attribute represented as a Type 1 column. When forecasting sales for the coming year, they’d like
to see how their discontinued products performed in the last year or two to make sure
adjustments for these products are made.
I created a mapping to load the data, pulling all the rows from SH.PRODUCTS initially… using
the PROD_EFF_FROM and PROD_EFF_TO dates to populate the effective dates in our
dimension.

3. After running this mapping, we can see a small data set from the PRODUCT_DIM table,
specifically, the Photo and Hardware categories.
Suppose that our client decides to get out of the Hardware business (did you look at the specs for
the PC’s they are selling… no wonder!), discontinuing all the products in the Hardware category.

4. So this change from the inventory system makes it’s way to our source table in the form of the
following two rows:
Now, I run the PRODUCT_DIM mapping again, and have the following rows in the
PRODUCT_DIM table for the Hardware category:
If we are triggering history for all the attributes in the PRODUCT_DIM table, what value will
these two new rows provide? Currently, no rows from the SALES_FACT table reference them,
and seeing as this change designates that these products are no longer available, it’s unlikely that
any new sales are going to be associated with them either. Furthermore, we want to see how our
discontinued products stack up with our current product line… and the only way to address this
kind of reporting is with Type 1 attributes.
So now I have to try and address this issue using OBIEE. When I create the Physical Layer, I
bring the SALES_FACT table in verbatim from the database, but I adjust the PRODUCT_DIM
slightly, using a Table Type of “Select” instead of “Physical”. Basically, this means that the table
in the Physical Model will actually be the results of a SELECT statement from the database:

5. I’m using the Oracle analytic function LAST_VALUE to represent all values for the VALID
attribute across each natural key (PRODUCT_SOURCE_ID) according to the most recent value,
using PRODUCT_EFFECTIVE_DATE as the ordering mechanism. Now, whenever we update
our product table to discontinue a particular product, we can use this attribute to provide impact
reports on how those products affected our sales in the past. Below is a quick Answers report that
demonstrates the behavior of this new Type 1 attribute, starting first with the criteria:

6. and then the results:
When you consider the modeling effort that goes into assigning Type 1 and Type 2 attributes,
you might say that this approach is not merely a replacement for a feature that OWB lacks, but it

7. might actually be the preferred approach. Consider the case when the business decides, after
analyzing their reports for several months, that they would like to change the SCD Type of a
particular column. While it’s relatively easy to go from a Type 2 to a Type 1, the reverse is
nearly impossible.
Depending on the environment, there would be rows and rows of historical changes never
inserted. We would have to tell the business that we can affect that change going forward, but the
historical data of all those Type 2 changes simply doesn’t exist. But with our new OBIEE
approach… it’s as simple as making a few changes to the Physical Model in our repository. You
can also see that I brought the VALID column in as well, and mapped it in the Business Model to
an attribute called Historical Valid. This gives me the ability to report on it as a Type 1 when
necessary, and the standard Type 2 manner in other reports.
inShare0
Posted in Data Warehousing, Dimensional Modelling, Oracle BI Suite EE, Oracle Warehouse
Builder | Comments Off
Comments are closed.
•
Top of Form
Search
Bottom of Form
•
• Recent Posts
○ Sydney to Host BI/EPM Conference Nov-2011
○ Rittman Mead Shortlisted for BI Partner of the Year Awards
○ Recruiting: UK-based Business Development Manager
○ Opportunities in Training Development with Rittman Mead
○ OBIEE Online Training
• Recent Comments

8. ○ srikrishna on OBIEE Online Training
○ Mastan Basha on OBIEE Online Training
○ Mastan Basha on OBIEE Online Training
○ Miguel Escaja on OBIEE 11.1.1.5 SampleApp Now Available for Download
○ srikrishna on OBIEE Online Training
• Categories
○ Apple
○ Application Server
○ BI (General)
○ BI (General)
○ BI 2.0
○ BI 2.0
○ BI Suite Developer Book
○ Conferences
○ Courses
○ Data Mining
○ Data Quality
○ Data Warehousing
○ Dimensional Modelling
○ Discoverer
○ Exadata
○ FMW
○ General
○ Hyperion
○ Hyperion Essbase
○ Hyperion Smart View
○ Linux
○ Methodology
○ Oracle BI Apps
○ Oracle BI Apps
○ Oracle BI Suite EE
○ Oracle Data Integrator
○ Oracle Database
○ Oracle Discoverer
○ Oracle EPM

9. ○ Oracle GoldenGate
○ Oracle News
○ Oracle OLAP
○ Oracle Reports & XML Publisher
○ Oracle Warehouse Builder
○ Professional
○ rant
○ Real-Time Decisions
○ Rittman Mead
○ Seminar Series
○ Technology
○ The Great Blog Disaster
○ Uncategorized
○ User Groups & Conferences
Call us now to talk about your BI project:
+44 (0) 8446 697 995 (UK) or (888) 631-1410 (USA)
or +61 (0) 407 701 537 (Australia & New Zealand) or +91 997 256 7970 (India)
Home
About Us
> About us
> About our team
> Contact us
> Our clients
Services
> Consulting
> Training
> Support
Consulting Services
> Projects
> Expert Services
> OBIEE 11g
> Sustainability
> On Discoverer?
> Oracle DW
Training
> OBI10g Developer
> OBI11g Training Days
> OBI10g End-User
> BI Publisher
> Oracle BI Apps
Resources
> Articles

10. > Blog
> OBIEE 11g
Blog Authors
> Mark Rittman
> Venkat J
> Stewart Bryson
> Peter Scott
> Borkur S
> Mike Vickers
> Adrian Ward
> Jon Mead
Rittman Mead Consulting ltd.
Registered Office : Preston Park House,
South Road, Brighton,
East Sussex, BN1 6SB, United Kingdom
United Kingdom
Company No. : 6032852
VAT No. : 900 3839 48
Rittman Mead America, Inc.
Registered Office : 3605 Sandy Plains Road,
Suite 240-404, Marietta, GA 30066, USA
Rittman Mead Oceania Pty Ltd.
Registered Office : 8/196, North Road,
Brighton East,
Victoria, 3187, Australia
Australian Company No. : 149 458 935
Rittman Mead Consulting Pvt Ltd.
#101 Evoma Business Center,
82, Borewell Road, Whitefield
Bengaluru, Karnataka 560066 INDIA
© 2010-2011 Rittman Mead Consulting. | Privacy Policy | E: info@rittmanmead.com
Website Design & Build: tymedia.co.uk