Kimball vs Inmon
Two schools, one practical answer
Kimball models bottom-up and dimensionally for business consumption; Inmon models top-down and normalized as an enterprise repository. Most modern BI lands somewhere between — read-oriented stars over a governed, unified core.
What you will learn
- Contrast Kimball's bottom-up stars with Inmon's top-down 3NF
- Explain where data vault fits
- Choose a modeling approach for modern, lake-forward BI
What is this?
Kimball's approach builds business-process-centered dimensional marts bottom-up (each mart a star), emphasizing understandability and quick delivery. Inmon's approach builds a normalized enterprise data warehouse (EDW) top-down first, then derives departmental marts, emphasizing integration and flexibility. The modern stack usually runs a governed, integrated core (often in a medallion/data-vault shape) feeding read-oriented star marts.
Why do you need it?
- The choice is really about speed-to-value vs integration-first governance.
- Kimball stars are what BI tools actually consume; Inmon-style cores reduce source-change pain.
- Modern warehouses are cheap enough to keep both: raw cores plus certified marts.
- Understanding the debate explains why your data platform looks the way it does.
Mental model
A co-op kitchen garden vs one giant farm
Kimball vs Inmon
Kimball: many small, ready-to-eat beds per dish (business process marts), fast to plant. Inmon: one integrated, well-planned farm that supplies everything, slower to build but feeds every dish. Modern shops keep a mixed approach and eat well either way.
How it works
- Kimball: identify business processes, build a dimensional star per process, using conformed dims for integration.
- Inmon: build a normalized 3NF EDW that models the enterprise entities and relationships, then derive marts from it.
- Data vault: staged, auditable integration (hubs/links/satellites) that supports agile EDW evolution.
- Conformed dims are how Kimball connects marts without a 3NF core.
- Modern practice: embedded business keys, open formats, and a shared governed core with stars on top.
Bottom-up marts vs top-down integration.
In production
- A retail chain runs Inmon-style integrated customer/product core, feeding per-process star marts for sales, inventory and labor.
- A fintech uses data vault staging for auditable source integration, then Kimball marts for BI.
- A mid-market SaaS skips the 3NF core: bronze → silver → star golds (a practical Kimball-with-gate), trading some integration rigor for speed.
Best practices
- Design marts for a named business process and its questions.
- Conform dimensions across marts even in an agile gold layer.
- For regulated/integration-heavy orgs, stage with a vault/integrated core before marts.
- Document the approach, because tomorrow's analyst will ask why the schema looks like it does.
Common mistakes
- Building an Inmon-style EDW nobody finishes (integration paralysis).
- Primitive star marts with zero integration, giving the company 6 versions of 'customer'.
- Copying marts per region and losing conformity later.
- Choosing the methodology by fashion instead of by integration needs and delivery tempo.
Common issues
Source schema change breaks every downstream martNo integrated core to absorb it (pure process marts)
Insert a governed staging/core layer or data-vault style hubs to localize change.
Never-ending EDW projectTop-down modeling without business-first marts
Ship a first process mart early, then grow the integrated core behind it.
Debugging tips
- Cross-mart inconsistency usually means unmet conformity, not data bugs.
- Many source-driven schema changes → your integration layer is weak; consider vault-style staging.
- Slow delivery → your integration-first approach may outweigh your report demand.
Interview checkpoint
Quick quiz
Kimball's integration mechanism across process marts is:
Modern warehouses always require a full Inmon-style 3NF enterprise core.