# Kimball / Dimensional Data Modeling
***
{% embed url="" %}
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](https://www.youtube.com/watch?v=3OcS2TMXELU) 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](https://www.geeksforgeeks.org/dbms/difference-between-kimball-and-inmon/)
***
### **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:
```
DimDate
|
DimProduct — FactSales — DimCustomer
|
DimStore
```
* FactSales is the measurable event: sales
* Dimensions describe who, what, when, where, how
***
### **How Kimball Differs from Inmon (Concise)**
| Feature | Kimball | Inmon |
| -------------- | -------------------------- | ----------------------------- |
| 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.
```
┌────────────────────────┐
│ Source Systems │
│ (ERP, Web, POS, Ads) │
└────────────────────────┘
│
▼
┌────────────────────────┐
│ Staging / ETL Layer │
│ - Extract │
│ - Cleanse │
│ - Conform Dimensions │
│ - Apply SCD logic │
└────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────────────┐
│ Data Marts (Star Schemas) │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Sales Mart │ │ Marketing │ │ Fulfillment │ │
│ │ (Star) │ │ Mart (Star) │ │ Mart (Star) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ ▲ ▲ ▲ │
│ │ │ │ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │DimDate │◀────────│DimCustomer│────────│DimProduct│───────┤
│ └──────────┘ └──────────┘ └──────────┘ │
│ (Conformed dims shared across marts) │
└───────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────┐
│ BI / Reporting / │
│ Dashboards / ML │
└────────────────────────┘
```
#### 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
***
