search

Inmon

Relevant books:

  • Building the Data Warehouse, 4th edition (Wiley) by W.H.Inmon

  • Corporate Information Factory

  • The Unified Star Schema (Technics Publications) by W. H. (Bill) Inmon

hashtag
Inmon Data Modeling (Corporate Information Factory)

Bill Inmon’s “Top-Down” Data Warehouse Architecture

Bill Inmon—often called the father of the data warehouse—defined one of the earliest and most influential approaches to enterprise analytics architecture. His method is typically summarized as top-down, enterprise-wide, and normalized.

At the time (late 1980s), organizations were querying production OLTP systems directly, slowing them down. Inmon’s data warehouse solved this by separating analytical workloads from operational systems.

hashtag
Inmon’s Definition of a Data Warehouse

A data warehouse is:

Subject-oriented, integrated, nonvolatile, and time-variant data that supports management decision-making.

Let’s break down each term and its modeling implications.

hashtag
1. Subject-Oriented

  • The warehouse is built around business subjects (e.g., Sales, Finance, Marketing—not around applications like SAP, Shopify, or HubSpot).

  • Logical models focus on one subject domain at a time.

  • Each domain contains business keys, attributes, and relationships across the enterprise.

Implication: Your data model must capture all enterprise facts about a single business area, not just data from one application.

hashtag
2. Integrated

This is the most important Inmon principle.

  • Data is ingested from multiple disparate source systems.

  • During ETL, it is:

    • standardized

    • conformed

    • cleaned

    • deduplicated

    • sequenced and normalized

When it lands in the warehouse, it has a single unified corporate representation.

Integration creates the “Single Source of Truth.”

Implication: All data must be aligned (domains, data types, business keys). The warehouse becomes the closest thing to a unified enterprise data model.

hashtag
3. Nonvolatile

  • Data, once stored, does not change (except for appending new history).

  • No transactional updates, deletes, or overwrites.

Implication: Design models expecting immutable data:

  • Surrogate keys

  • Audit fields

  • Load dates

  • Business-effective dates

  • Snapshot tables if needed

You build a stable layer where older facts remain intact for long-term analytics.

hashtag
4. Time-Variant

  • Every record includes time context (load time, effective time).

  • Queries can span long historical ranges.

Implication: Modeling must include:

  • slowly changing dimensions (SCDs)

  • historical fact tables

  • lineage tracking

  • temporal data structures

The warehouse becomes a place to ask questions about the past, not just the present.

hashtag
What the Inmon Warehouse Looks Like

Core Characteristics

  • Built using 3rd Normal Form (3NF) entity-relationship modeling.

  • Highly normalized → minimal redundancy → maximum consistency.

  • Mirrors business truth, often resembling normalized OLTP systems in structure (but not purpose).

  • Data arrives via heavy ETL: standardization, validation, integration.

hashtag
Architecture: Top-Down

Below is a conceptual diagram showing how data flows in a classic Inmon (top-down) architecture:

This is the classic Inmon flow: Sources → ETL → 3NF EDW → ETL → Star Schemas → BI.

Key points:

  • EDW is the authoritative source for analytics.

  • Data marts depend on the EDW, not on operational systems.

  • Data marts may be:

    • star schema (common)

    • snowflake schema

    • or any structure optimized for consumption.

hashtag
Example: E-commerce Business

Source systems:

  • Orders

  • Inventory

  • Marketing

These feed into the Enterprise Data Warehouse, where they become:

  • normalized

  • integrated

  • historical

  • immutable

Once in the EDW, downstream ETL builds subject-specific data marts:

  • Sales data mart

  • Marketing data mart

  • Purchasing data mart

Each may use a star schema for performance.

hashtag
Why Inmon?

Pros

  • Strong enterprise consistency (integration).

  • High data quality.

  • Long-term historical accuracy.

  • Excellent for large organizations with complex domains.

Cons

  • Slowest to implement (years in large companies).

  • Heavy ETL maintenance.

  • Requires strict data governance.

  • Analysts often don’t like normalized structures for querying.

hashtag
How It Compares to Kimball

  • Inmon: Top-down → EDW (3NF) → Data marts → Reports Enterprise first.

  • Kimball: Bottom-up → Data marts (star schemas) → Virtual EDW Analytics first.

Modern architectures often blend both.

hashtag
Summary of Inmon Modeling

  • Build a centralized, enterprise-wide data warehouse.

  • Store granular, normalized (3NF) data.

  • Maintain immutable, time-variant history.

  • Use data marts for department-specific access.

  • Prioritize integration consistency above all else.

PreviousData NormalizationNextCore concepts from the book "Building the Data Warehouse"

Last updated