Inmon vs. Kimball

Imagine you're organizing a family photo album. There are two ways to do it. Ralph Kimball and Bill Inmon are like two friends giving you different advice on how to structure it.

• Kimball says: "Group the photos by important events, such as birthdays, vacations, or Christmas. That way, when you want to remember something specific, you just open the album for that event and find the photos easily."
• Inmon says: "First, categorize all the photos into sections like 'Family,' 'Vacations,' and 'Birthdays.' Once they're organized, you can create themed albums with the photos you need."

Both approaches have their pros and cons, but each answers different questions. Now, let's apply this analogy to the world of Data Warehouses.

Key Differences Between Kimball and Inmon Approaches

The Kimball approach (Bottom-up) focuses on building dimensional Data Marts optimized for fast analysis. Its data structure is based on star or snowflake schemas, making access easier for business users. This model prioritizes query speed and simplicity for operational decision-making.

On the other hand, the Inmon approach (Top-down) first creates a highly normalized corporate Data Warehouse in 3rd Normal Form (3NF). This DWH serves as the single source of truth for the entire organization.

Unlike Kimball's model, Inmon does not use star or snowflake schemas, meaning it is not designed to be consumed directly by analytical tools. To facilitate data consumption, dimensional Data Marts must be created on top of it.

The Relationship Between OLTP, Inmon, and Kimball

Both Online Transactional Processing (OLTP) systems and Inmon's Data Warehouse follow 3rd Normal Form (3NF), but with different goals. OLTP systems are designed for day-to-day transactions with speed and accuracy; their normalized structure minimizes redundancy and facilitates updates (e.g. sales OLTP: customer, product, billing in separate related tables). That same normalization can be a drawback for analysis, because obtaining consolidated information requires joining many tables—queries become complex and slow.

The Inmon approach builds a corporate Data Warehouse in 3NF to integrate data from multiple sources while ensuring data quality and consistency at the enterprise level. Even so, Inmon's Data Warehouse is not designed for direct querying—excessive normalization makes analytical queries inefficient. To solve this, dimensional Data Marts are built following Kimball's model, which denormalizes the data into fact and dimension tables so BI tools can query information quickly and easily.

In summary:

1. OLTP: Operational systems in 3NF for daily transactions.
2. Inmon: Corporate Data Warehouse in 3NF for enterprise integration.
3. Kimball: Dimensional Data Marts for fast and efficient analysis.

Why Can't Inmon Be Consumed Directly?

Inmon's model is highly normalized: data is spread across multiple related tables to reduce redundancy and ensure consistency. That design enhances data integrity but also increases query complexity—you need many table joins in SQL. For example, to generate a sales report in an Inmon-based Data Warehouse you might join Customer, Product, Sales, and SalesDetails. That makes direct analysis difficult, which is why dimensional Data Marts are created to simplify queries by restructuring the data into star or snowflake schemas.

Pros and Cons of Each Approach

Kimball (Dimensional Approach)

Pros:

• Easy for business users to query and understand.
• Faster implementation compared to Inmon.
• Optimized for reporting and dashboarding tools.
• Quick insights for decision-making.
• Lower initial cost and complexity.

Cons:

• May lead to data redundancy across different Data Marts.
• Less focus on enterprise-wide data consistency and governance.
• Difficult to adapt to changing business requirements.
• Requires careful planning to avoid siloed Data Marts.

Inmon (Normalized 3NF Approach)

Pros:

• Ensures high data quality and consistency across the organization.
• Single source of truth by integrating data from multiple sources.
• Easier to scale and accommodate future data sources.
• Strong governance and compliance capabilities.
• Reduces data duplication and storage costs over time.

Cons:

• Requires significant time and resources to implement.
• Complex query structures; challenging for business users to access data directly.
• Higher initial costs due to extensive ETL and data modeling.
• Typically needs additional Data Marts for easy data consumption.

Adding an ODS Before the Data Warehouse

Some companies add an Operational Data Store (ODS) as an intermediate layer before the Data Warehouse. An ODS collects real-time data from transactional systems and makes it available for operational reporting without overloading source systems.

Benefits of an ODS:

• Quick access to recent data.
• Reduces load on operational systems.
• Serves as a staging area before loading into the DWH.
• Enables near real-time operational decision-making.

Typical data flow with an ODS:

1. Operational systems (CRM, ERP, sales)
2. ODS (quick operational data access)
3. Inmon Data Warehouse (corporate view)
4. Kimball Data Marts (optimized reports)

The Hybrid Approach: Combining Inmon and Kimball

Many organizations combine both approaches to leverage their strengths:

1. First, build a corporate Data Warehouse following Inmon's approach, integrating data from multiple systems in a normalized format.
2. Then, create Data Marts using Kimball's approach, providing fast and accessible reports for business users.

This hybrid model offers a solid and reliable foundation (Inmon) while ensuring the flexibility and speed needed for data analysis (Kimball).

Conclusion

Both Inmon and Kimball approaches have their place, depending on the organization's needs and goals. If the priority is to deliver fast reports to specific business areas, Kimball is the ideal choice. If the goal is long-term data quality and governance, Inmon is the better option.

In many cases, combining both models allows organizations to leverage their strengths, achieving a balance between governance and speed.

Need help designing your data warehouse strategy? Contact us at team@simov.io.