BI Architecture (Part IV): Comparison between Inmon and Kimball

There are marked differences between both models when establishing the steps to follow to develop a Data Warehouse.

As you may have observed after exposing in previous posts the approaches of Inmon and Kimball, their principles are so different that not only their internal structure and scope vary, but also their intention and purpose are affected.

However, despite this confrontation of approaches and ideas and the great differences presented by both models, it is very bold to say that one or the other is correct or incorrect since, depending on the case we handle, it can fit us to a greater or lesser extent, implanting one of the two perspectives.

Aspects to analyze

For this reason, there are a number of aspects that must be analyzed before opting for one of the options:

  • Budget to undertake the project
  • Deadlines available for the construction of the datawarehouse
  • Expertise required for the developer team
  • Scope of the datawarehouse, either to host the data of the entire company or certain business areas or departments
  • Complexity of maintenance work

The following table shows how these factors affect the two datawarehouse models:

Inmon Kimball
Budget High initial cost Low initial cost
Deadlines It requires more development time Lower development time
Expertise Highly specialized team Team with medium specialization
Scope Whole company Individual departments
Maintenance Easy maintenance More complex maintenance

Apart from these variables, which are going to be decisive when deciding on one model or another, we have to be very clear about the purpose of our datawarehouse.

Inmon and Kimball

If we remember what was stated in previous entries, the Kimball datawarehouse is oriented to the consultation of the information, so its internal structure is specially designed to guarantee a fast and simple exploitation of the data, not requiring specialized users for it. On the contrary, the Inmon datawarehouse seeks the integration of all the company’s data, being oriented towards the storage of large volumes of data, so that its internal standardized structure is designed to avoid data redundancy, simplify the work of maintenance, etc. issues that complicate information queries, requiring end users to be much more specialized.

Thus, we could say that Kimball’s approach is more suited to small projects which pursue an easily exploitable and understandable system by the user and that is rapidly developed, being the most appropriate Inmon model for larger complex systems.

Every project has its own peculiarities, each case being unique and independent, so it is necessary to carry out a study of all of them before opting for one solution or another, so that we can get an idea about which model best fits the conditions of our project.

Even so, we must remain open to these two options, since there are cases in which intermediate solutions have been implemented between both visions, achieving hybrid systems that successfully combine advantages from both perspectives.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.