Kimball vs Inmon

Updated March 21, 2023

Difference Between Kimball vs Inmon

The following article provides an outline of Kimball vs Inmon. There are different ways in which we can align different components of a data warehouse, and these components are an essential part of a data warehouse. For example, the data source helps us identify where the data is coming from.

With the data staging area, we can decide on certain functionalities that we would like to add to the data before the data is ingested into the data storage. Following this, we can provide the information delivery mechanism. We’ll begin by exploring a very simple, basic data warehouse architecture. With this basic architectural approach, the data warehouse is central. The data source directly interacts with the warehouse without any data staging process in between.

Head to Head Comparison Between Kimball vs Inmon (Infographics)

Below are the top 7 differences between Kimball vs Inmon:

Key Differences Between Kimball vs Inmon

Let us look at the key differences between Kimball vs Inmon:

• While Kimball utilizes dimensional models for the data, Inmon utilizes dimensional models just for the data marts. Now from an architectural perspective, Kimball proposes that it isn’t necessary to separate the data marts from the existing dimensional data warehouse. In the case, Inmon uses the data marts derived from data warehouses to separate them from the data warehouse as separate units physically.
• Now, let’s quickly compare their architectures proposed by the Kimball and Inmon approaches. So we can understand which of these approaches suits our data warehousing requirement better and adopt the appropriate architecture accordingly.
• With the Kimball approach, the focus is on identifying the key business process and the subsequent business solutions that we need to provide with the data warehouse. While the Inmon approach believes in building a data warehouse with the corporate data model.
• The Kimball approach utilizes dimensional models such as star and snowflake schema to organize the data into various business classified data to enable business processes quickly. Inmon, on the other hand, considers the overall corporate data requirement, and as such, it utilizes the ER modelling technique.
• Kimball focuses on providing analytical systems that can be directly accessed from the data warehouse. In other words, Kimball proposes an architecture where an analytical system can directly consume data from the data warehouse. While in the case of Inmon, the architecture is designed so that the analytical system can only access the data from the data warehouse through the data marts.
• Data warehouse architecture of Kimball and Inmon from the perspective of business considerations. The Inmon architecture takes time to construct or implement since we have to plan various data marts. Whereas it takes relatively less time to implement Kimball data warehouse architecture. Since the abstraction is a higher abstraction level, we only consider the data warehouse design using a star or snowflake schema.
• Maintaining Inmon based data warehouse is easy because we can decouple the maintenance tasks into various data maintenance activities. In Kimball-based design, maintenance is difficult because there can be redundant data, and revisions require additional tasks.
• Implementing an Inmon-based data warehouse can incur a high initial cost, but the subsequent project development costs are lower because it requires less maintenance and load change adaptive. On the other hand, Kimball incurs a low initial cost because we only need to plan the data warehouse, and the cost remains the same for the subsequent phases. Inmon based architecture of data warehouse requires longer startup time, whereas Kimball based data warehouses can be set up quickly.
• When we are implementing Inmon based data warehouse, we’ll need a specialist team since we need to design data marts as well. To design data marts, the team has to be familiar with each functional unit. Kimball, on the other hand, requires a general team to implement.
• The resources involved need to know how to work with ER modelling without the need to decouple them into various data marts. We need enterprise-wide data integration with Inmon based data warehouse. Whereas with Kimball based data warehouse, the data integration requirement is focused on the individual business area.
• The final comparison that we’ll explore is around the uses of Inmon and Kimball based data warehouses. Both Inmon and Kimball architecture require data sources, data staging, ETL capabilities, and data marts.
• Business requirements need to be captured, and they both require time attribute for data to facilitate historical data. While Inmon facilitates enterprise data warehouse, Kimball doesn’t. There are no dimensional involved with Inmon since there are multiple data marts to model. And while there are relational tools for Inmon, there are none for Kimball. While Inmon is not process-oriented, Kimball happens to be process-oriented since the focus is on business processes.
• Inmon works with the normalized data model, whereas Kimball prefers the denormalized data model, and as such, we find redundant data models present in the Kimball architecture. The design and architecture of Inmon can be complex, but Kimball based data warehouses are easier to design and implement.
• Continues in the discrete time frame, yes. In the case of Inmon, since we need to monitor the data marks continuously. Slowly changing the time frame, yes. In Kimball’s case, since we have to adapt to the changes and the data warehouse level. With Kimball, we get one data warehouse storage that we need to utilize logically, depending on the business process.

Kimball vs Inmon Comparison Table

Let’s discuss the topmost comparison between Kimball vs Inmon:

Kimball	Inmon
It takes a relatively lesser amount of time to implement.	It is quite a complex method; it takes a quite bit of time to implement.
Kimball-based design maintenance is difficult.	Maintaining an Inmon-based data warehouse is easy.
Kimball, on the other hand, incurs a low initial cost because we only need to plan the data warehouse, and the cost remains the same for the subsequent phases.	Implementing an Inmon-based data warehouse can incur high initial costs, but the subsequent project development costs are lower.
Kimball-based data warehouses can be set up quickly.	The inmon-based architecture of the data warehouse requires a longer startup time.
Kimball, on the other hand, requires a generalist team to implement.	When we’re implementing an Inmon-based data warehouse, we’ll need a specialist team.
Kimball-based data warehouse, the data integration requirement is focused on the individual business area.	We need enterprise-wide data integration with an Inmon-based data warehouse.
It follows Bottom Approach.	It follows the Top-Down Approach.

Conclusion

It takes a relatively lesser amount of time to implement the Kimball data warehouse architecture. Maintaining an Inmon-based data warehouse is easy because we can decouple the maintenance tasks into various data mart maintenance activities. In the case of Kimball-based design, maintenance is difficult because there can be redundant data. Implementing an Inmon-based data warehouse can incur high initial costs. Kimball, on the other hand, incurs a low initial cost, and the cost remains the same for the subsequent phases. Implementing an Inmon-based data warehouse will need a specialist team. Kimball, on the other hand, requires a generalist team to implement.

This has been a guide to Kimball vs Inmon. Here we also discuss the Kimball vs Inmon key differences with infographics and comparison table. You may also have a look at the following articles to learn more –

1. Scala vs Java
2. DDL vs DML
3. Java vs PHP
4. Kimball Methodology