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:
The following table shows how these factors affect the two datawarehouse models:
|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.