Oops! The input is malformed! Data Warehousing: Kimball vs. Inmon (By Inmon) by Bill Inmon - BeyeNETWORK
We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Channel: Non-Invasive Data Governance - Robert S. Seiner RSS Feed for Non-Invasive Data Governance - Robert S. Seiner


Data Warehousing: Kimball vs. Inmon (By Inmon)

Originally published July 22, 2010

In this article, Bill Inmon compares and contrasts the Inmon and Kimball approaches to data warehousing, highlighting the pros and cons of each approach.

You must be a member to view this content. Membership is free and gives you full access to all content across the Network. Login or sign up today.

Sorry there was a problem with your login or password. Please try again.
Member Login

Not a member? Signup now!
Forgot your password? Get it now.



Want to post a comment? Login or become a member today!

Posted August 14, 2010 by Anonymous

I have worked on several data warehouses all being considered Inmon type.  Every single one of them had star schema structures to meet many of the business needs.  So the only potential difference I see is the Inmon integrated data area versus the Kimball staging area.  Are these really different constructs?  Unless all your data sources come from extremely well designed and built systems (of which I have yet to see any) you have to build some area for integrating and cleansing the data?  Don't you.  I'd love for someone to talk about this in detail because I am certainly not an expert on either architecture and am confused by the wars between proponents of the two styles. 

That said,  Bill this article provided nothing of value.  I can't believe you would even spend the time and energy to write this.


Is this comment inappropriate? Click here to flag this comment.

Posted August 4, 2010 by Juan Monterrubio montrubio@gmail.com

I agree with Ferenc Mantfeld.

Is this comment inappropriate? Click here to flag this comment.

Posted July 27, 2010 by ryork@relationalsolutions.com

I want to believe that Bill Inmon is attempting to spark a debate with Kimball by writing this unfortunate piece gibberish. He would have been much better served having a qualified Kimball expert engage in this debate, even if it weren't Ralph Kimball himself.

My company has been building data warehouses for over 15 years. We have built DW's for some of the largest multi-national companies (Xerox, Chrysler, Unilever, Kraftmaid, ...) I can say with certainty that Bill Inmon is way off the mark. 

Many, many times we have made changes to the infrastructure to support new or emerging business needs. Kimball's framework, if implemented with competency, supports changing needs without much "fuss". It is hardly a fragile architecture. To the contrary, some of the very first DW's we built using Kimball's framework are still in production today and have been greatly enhanced to include additional subject areas, corporate acquisitions and new methods for data enhancement.

In addition, an important part of the Kimball framework that Inmon left out is the "staging area". This is where data in cross referenced and validated prior loading into a star schema.

Inmon calls it an "approach" or "architecture".  I call it a framework. A framework is flexible and can be crafted to most environments. Each environment will have its own unique qualities but all can be implemented using Kimball's framework.


Is this comment inappropriate? Click here to flag this comment.

Posted July 25, 2010 by Ferenc Mantfeld



While I have the utmost respect for both you and Ralph, I have to urge you to see things in the real world, the world of the customer and of ever-shrinking budgets and timeframes.

While your approach is generally accepted as the purist approach, it can only ever work when the initiative is sponsored by the upper echelons of the organization who understand the impact, benefits and cost. The customers I come into contact with still see Data Warehousing purely as a data source for their reports and often there is no deeper understanding of the issues, like MDM, DQ, etc.

A purist approach, like the Inmon approach to DW takes a LOT of careful structured planning and resources and in an ideal world, this is probably how it should be done for long-term benefits.

However, most customers want a solution, and by yesterday (of course with all the advantages that a purist approach would deliver). But mingy budgets to not allow for a big-bang approach, thus the incremental DW as a result of a collection of Data Marts using the Kimball methodology is more often than not, the chosen direction.

This is not an endorsement that Kimball is better or anything like that. It is a simple acceptance of the reality that in a time and budget constrained world, the Kimball approach is chosen more often than not and the smaller the organization, the less data, the more likely that the Kimball approach will suffice.

Regards: Ferenc Mantfeld

Is this comment inappropriate? Click here to flag this comment.

Posted July 23, 2010 by Jon Crowell

In my experience, the only times Inmon's approach is favored is when IT is completely in charge of the warehouse. The gap between the work being done and the business value that will result is very hard to determine, as the business questions being answered haven't really been asked yet. If we build it, they will come.

Kimball's goals are speed and ease of understanding. Once a specific business question is formulated, it's fairly easy to build the solution, and helping the business make better decisions in shorter, less expensive cycles is a great way to get executive buy-in.

@adrian -- I hope you can find your article. I would like to read it.

Is this comment inappropriate? Click here to flag this comment.

Posted July 22, 2010 by adrian.miley@gmail.com

I’m not sure whether this “article” is being deliberately disingenuous or whether the author just lacks fundamental understanding of the benefits of the Kimball approach (I suspect though that it’s the latter). Certainly much of it comes over as just a “my way is better because…” rant without any objective appraisal of the counter-argument.

Something I’ve learnt over the years is that strength and weaknesses are completely interchangeable depending on the business context and there is no such thing as a perfect “one size fits all” solution. In fact I can think of many scenarios where the assertions being made can be reversed or are actually false e.g. I can think of situations where Inmon is “fragile” and Kimball actually quite “robust” or, as in an FMCG environment, Kimball can actually be a strategic solution.

Essentially the big advantage with the Kimball approach over the Inmon approach is the ability to quickly prototype a data mart designed to efficiently answer specific well-defined questions and explore new questions that the business might want answers to.

This should not be under-estimated because for many organisation time-to-market is critical so knocking something together in a couple of weeks rather than months can make a significant difference to ROI.

We also need to look at the entire life cost of ownership – Kimball is much cheaper is the short-term but more expensive in the long-term whereas Inmon is more expensive in the short-term (as it requires much more up-front design work) but cheaper in the long-term.

That however is only true if everything runs to a natural conclusion in a mature environment.

In an R&D environment where many prototypes might be built and discarded before a final solution is defined then Kimball is always cheaper because “building on the fly” is a natural part of that approach.

Finally, an interesting thing which is completely overlooked here (and in much of the “compare & contrast” literature) is that both approaches should be utilised in any mature data warehouse / business intelligence environment.

It’s a bit like the difference between general-purpose solutions and single-purpose solutions.

An Inmon “general purpose” data warehouse will be able to answer any question but will not answer any question efficiently (i.e. query performance will be average at best) whereas a Kimball Data Mart will answer the specific questions very efficiently (being what it’s specifically designed for) but cannot answer

Consequently the strategic approach should be mutiple Kimball "single purpose" Data Marts for efficiently answering specific well-defined questions underpinned by an Inmon Data "general purpose" Warehouse for answering ill defined ad-hoc questions.

I wrote an extensive article on this a few years ago – I’ll see if I can dig it up and post it here. 

Is this comment inappropriate? Click here to flag this comment.

Posted July 22, 2010 by daragh fitzpatrick

Hi Bill,

can you try and write this from Ralph's perspective? Do you think that Ralph believes that his approach is (still) the best way, despite it being short-sighted and inflexible? Would you say that he has put away his ego and believes that your approach is better? ...Or is it possible that he believes there is a hybrid approach that takes the best of both approaches and delivers lasting value to the world?

Seriously though, if Rumbaugh and Booch could finally agree on UML, don't you think the two of you could jointly (as the Two Amigos?) take us into DW2.0 before you leave this plane of existence?



Is this comment inappropriate? Click here to flag this comment.