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.

Inmon Versus Kimball: A Common Meeting Ground

Originally published March 3, 2011

There have traditionally been two data warehousing camps: those who favor the Inmon architecture and those who favor the Kimball star-schema architecture. Can these two architectures co-exist? This article provides Bill Inmon's perspective on this frequently asked question.

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 March 10, 2011 by Neil Raden

I guess the question I have, and I don't favor either approach categorically, is that Bill clearly describes a use for the star schemas, but what is the use for the DW 2.0? If you buy into the single version of the truth (which I don't) why can't it be implemented as part of the Kimball extended architecture blueprint? Especially these days when it's becoming more feasible to federate and virtualize data sources? It just seems like a lot of structure that adds latency across the board.

It would be best, IMO, if it didn't' matter how the data was modeled so that all loading and querying could process through a semantic layer.

So, I think this discussion is superfluous.

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

Posted March 3, 2011 by

Bill, this is an excellent example of architectural thinking that gives up "religious fidelity" for "best of breed" creativity.

Too often, we hear "data warehouse" being used as if it were a monolithic entity -- every level of every function must conform to a single orthodoxy. In fact, the larger business goals that a "data warehouse" supports depend on a degree of flexibility, agility and freedom of movement that permits of a blend of small architectures within a large, over-arching architectural vision.

I have been an adherent of this "stacking" of quick-fire data marts onto a solid foundational data warehouse for many a year. It is always surprising to see how much resistance I've run into from both the "all data mart" and the "all data warehouse" sides.

In the end, the business is best served by whichever toolset and solution addresses their immediate need. Our purpose, as architects, is to ensure that there is a stable base from which they can launch those solutions.


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