Yes, it is time for me to stick my foot in the Kimball vs. Inmon debate. Many people have debated these two methods of building a data warehouse, including Kimball himself in this article in the Intelligent Enterprise magazine.

I am not indoctrinated to either approach. The Inmon approach works very well if you have to extract data from many different source systems, and you need an integrated business model to control the common business definitions better. In such cases, it might be very helpful to model the transactions in a third-normal form (3NF) data warehouse (or Corporate Information Factory) to reflect the whole business. In my opinion, Kimball’s overlay on Inmon (build the atomic level dimensional data warehouse with conformed dimensions from this 3NF data warehouse) is a redundant and in most cases, a wasted effort. To succeed with BI from this 3NF data warehouse (or the CIF), you need to build cubes or aggregate-level dimensional data marts. For detail-level atomic data, it is not too difficult to write a report from the CIF.  There are many examples of this, like the pre-built data warehouse solutions for industries like retail or telecom from Oracle.

For data warehouses or marts that are focused on one enterprise or department, and those that are built from ERP systems like Oracle eBusiness Suite, the Kimball approach of building a data warehouse as a collection of data marts linked together with conformed dimensions is more suitable and, is easier and cheaper to build. Here are just a couple of reasons for that:

• Oracle eBS itself is a very well integrated product (Ahem). You have the common business entities like customers, products, employees, accounts etc all in one place. All modules share these definitions – you can call these conformed entities. They are already in an integrated 3NF form with common business definitions.
• All Oracle Apps modules have audit columns in them, so all changes, be it to the master data or to transactions are always stamped with time and the user who modifies it. Capturing changed data from an Oracle eBusiness Suite is simple.

From my experience, I can say with great confidence that if you are trying to build an enterprise scale data warehouse from Oracle eBusiness Suite, Kimball’s methodology will work better. In my discussions going forward, I will restrict my approach to this.

Starting with my next post, I will begin laying out the various subject areas covering Oracle General Ledger, Receivables and Order Management. Some of the design principles I will expand upon:

• Slowly changing dimensions, Current Dimension, Frozen Dimension.
• Document dimensions

Some of the other issues that I will discuss:

• Security in the data warehouse
• Currency Translations
• Multi-language Translations
• Real Time integration with Oracle eBS

Stay tuned.