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 (SCDs). 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 1s in the reporting layer. With the flexibility that OBIEE provides, I should be able to make a go of it. First, Ill 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.

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, theyd 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.

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 PCs they are selling no wonder!), discontinuing all the products in the Hardware category.

So this change from the inventory system makes its 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, its 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:

Im 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:

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

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 its 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 doesnt exist. But with our new OBIEE approach its 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

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

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

> 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