Kimball / Dimensional Data Modeling
Kimball is a specific approach to dimensional modeling, which is the general technique of structuring data into fact and dimension tables for data warehousing and business intelligence. Therefore, while all Kimball modeling is dimensional modeling, not all dimensional modeling uses the specific Kimball techniques.
The book to read for learning the fundamentals: The Data Warehouse Toolkit, 3rd edition, Ralph Kimball and Margy Ross
Since the book was written before the cloud era, here's a video from dbt Labs that discusses what's worth keeping from the original book and adapt the principles for the modern data warehouse.
Also, check out differences between Inmon and Kimball
What Kimball Data Modeling Is
Kimball is:
Bottom-up data warehouse architecture
Denormalized, business-process–centered modeling
Fact + dimension tables arranged in star schemas
Optimized for analytical queries, readability, business alignment
Prioritizes speed of insights and ease for BI users over strict integration
Kimball ≠ “no normalization” Kimball has discipline—but it applies normalization only inside dimensions where necessary. The star schema is intentionally denormalized to avoid heavy joins.
Kimball = build data marts first → integrate with conformed dimensions later.
The Kimball Mental Model (Best Way to Think About It)
Business process → measurements → events → fact table
Context and descriptions → dimension tables
A star schema = One fact table at center Many dimension tables radiating out
Fact tables = measurements Dimensions = descriptions
The Core Objects in Kimball
Fact Tables
Represent events (sales, clicks, payments, shipments, logins)
Are immutable, append-only
Are long & narrow
Contain:
Foreign keys to dimensions
Numeric measures only (if possible)
Lowest-grain rows
Example grain: “One row per order line” or “One row per customer login event” or “One row per pageview”
Dimension Tables
Contain descriptive attributes (names, categories, regions, types)
Are wide & short
Are denormalized intentionally
Update via Slowly Changing Dimensions (mostly Type 2)
Examples of dimensions:
DimCustomer
DimDate
DimProduct
DimStore
DimGeography
Conformed Dimensions
A huge part of Kimball that makes enterprise integration possible:
A dimension shared across multiple star schemas with identical meaning, structure, keys, and attributes.
Example:
A unified Customer dimension powering:
Sales fact
Subscriptions fact
Support tickets fact
Marketing attribution fact
With conformed dimensions, Kimball becomes “enterprise” (almost Inmon-like) without sacrificing bottom-up agility.
Slowly Changing Dimensions (SCDs)
Your description is already correct. The only thing to add:
Kimball SCD guidance:
Use Type 2 for customer, product, employee, store, subscriptions
Use Type 1 for operational attributes not important historically
Use Type 3 only for rare reporting needs
Star Schema (verbal visual)
Imagine a star:
FactSales is the measurable event: sales
Dimensions describe who, what, when, where, how
How Kimball Differs from Inmon (Concise)
Architecture
Bottom-up
Top-down
Data warehouse
Equals set of star schemas
Central 3NF warehouse + marts
Normalization
Denormalized (facts/dims)
Fully normalized in warehouse
Business-first
Yes
No (integration-first)
Best for
BI, dashboards, OLAP
Enterprise data integration
Learning curve
Lower
Higher
Redundancy
Allowed
Avoided
Your text already captured most of this.
Practical Example (simple)
Business question
“Show revenue by product, customer, and time.”
FactSales
OrderLineID
ProductKey
CustomerKey
DateKey
Quantity
Revenue
Dimensions
DimProduct
DimCustomer
DimDate
These 3 tables + 1 fact = one star schema.
The Kimball Modeling Workflow (production-grade)
STEP 1 — Select the business process
Examples:
Sales transactions
E-commerce pageviews
Subscription billing
Customer support tickets
STEP 2 — Declare the grain
Most important step in Kimball.
Example: “One row per order line.”
STEP 3 — Identify the facts (measures)
Revenue
Quantity
DiscountAmount
STEP 4 — Identify dimensions
Customer
Product
Store
Date
Campaign
PaymentMethod
STEP 5 — Build conformed dimensions (if enterprise)
Share CustomerKey across all marts.
Share DateKey everywhere.
Share ProductKey across all product-related facts.
STEP 6 — Model SCDs
Typically SCD2 for Customer, Product, Employee.
STEP 7 — Create star schemas
One per business process.
Kimball Architecture Diagram (conceptual)
This shows the typical Kimball flow: build subject-focused data marts (star schemas), share conformed dimensions, and provide BI/analytics access.
Diagram notes
Conformed dimensions (Date, Customer, Product, etc.) are created in staging and reused across many marts to maintain consistency.
Each mart is optimized for a business process; marts are the primary analytic store in Kimball.
ETL does the heavy lifting (grain enforcement, SCD management, surrogate key assignment).
Example diagram
Last updated