Kimball vs. Inmon: two different ways to think about a data warehouse
Kimball vs. Inmon: two different ways to think about a data warehouse
When people start learning data warehousing, one of the first big questions is:
Should you design top-down or bottom-up?
That is where Inmon and Kimball usually come into the conversation.
A simple way to think about it:
A data warehouse is like the company’s central library.
A data mart is like one section of that library.
Inmon
Top-down approach
With Inmon, you first build the centralized enterprise data warehouse, usually in a normalized way, and then derive downstream data marts from it.
It is often:
Strengths
Challenges
Kimball
Bottom-up approach
Kimball sees the data warehouse as the union of all business data marts.
Instead of starting with the whole house, you build one useful room at a time.
It is often:
Kimball usually uses a star schema, where business processes are modeled around:
Strengths
Risks
What makes Kimball practical?
One of the things I like most about Kimball is that it is very grounded in business processes.
The dimensional design flow is usually:
That order matters.
Because if the grain is not clear, everything after that becomes confusing.
And what about SCDs?
When working with dimensions, handling change is essential.
Some common Slowly Changing Dimension (SCD) types are:
Type 2 is usually the most common when historical tracking matters.
My takeaway
I do not think Kimball and Inmon should always be treated as enemies.
They are different design philosophies for different contexts.
If the priority is enterprise-wide integration and consistency, Inmon can make sense.
If the priority is business value, speed, and usability, Kimball is often the more practical choice.
In real projects, many teams end up using a mix of both ideas.
Which approach have you seen more in practice: Kimball, Inmon, or a hybrid model?
#DataEngineering #DataWarehouse #Kimball #Inmon #DimensionalModeling #StarSchema #BusinessIntelligence #AnalyticsEngineering