Arquitectura BI (Parte IV): Comparativa entre Inmon y Kimball

BI Geek / Arquitecturas  / Arquitectura BI (Parte IV): Comparativa entre Inmon y Kimball
Arquitectura: comparación entre los modelos de Inmon y Kimball

Arquitectura BI (Parte IV): Comparativa entre Inmon y Kimball

Existen marcadas divergencias entre ambos modelos a la hora de establecer los pasos a seguir para desarrollar un Data WarehouseComo habréis podido observar tras exponer en entradas anteriores los enfoques de Inmon y Kimball, sus principios son tan dispares que no solo la estructura interna y alcance de éstos presentan variaciones, sino que también su intención y finalidad se ven afectados.

Sin embargo, a pesar de esta confrontación de enfoques e ideas y de las grandes diferencias que presentan ambos modelos, resulta muy atrevido decir que uno u otro es correcto o incorrecto ya que, según sea el caso en el que nos encontremos, nos puede encajar en mayor o menor medida implantar una de las dos perspectivas.

 

Aspectos a analizar

Por esta razón, hay una serie de aspectos que habrá que analizar antes de decantarnos por una de las opciones:

  • Presupuesto para acometer el proyecto
  • Plazos disponibles para la construcción del datawarehouse
  • Expertise requerido para el equipo de desarrolladores
  • Alcance del datawarehouse, ya sea para albergar los datos de toda la compañía o de determinadas áreas de negocio o departamentos
  • Complejidad de las labores de mantenimiento

 

La siguiente tabla muestra cómo afectan estos factores a los dos modelos de datawarehouse:

                                  Inmon Kimball
Presupuesto Coste inicial alto Coste inicial bajo
Plazos Requiere más tiempo de desarrollo Tiempo de desarrollo inferior
Expertise Equipo con especialización alta Equipo con especialización media
Alcance Toda la compañía Departamentos individuales
Mantenimiento Fácil mantenimiento Mantenimiento más complejo

 

Aparte de estas variables, que van a ser determinantes a la hora de decidirnos por un modelo u otro, tenemos que tener muy clara cuál será la finalidad de nuestro datawarehouse.

Inmon y Kimball

Si recordamos lo expuesto en entradas anteriores, el datawarehouse de Kimball está orientado a la consulta de la información, por lo que su estructura interna está especialmente diseñada para garantizar una explotación de los datos rápida y sencilla, no requiriendo usuarios especializados para ello. Por el contrario, el datawarehouse de Inmon persigue la integración de todos los datos de la compañía, estando orientado hacia el almacenaje de grandes volúmenes de datos, por lo que su estructura interna normalizada se diseña para evitar la redundancia de datos, simplificar las labores de mantenimiento, etc. cuestiones que complican las consultas de la información, requiriendo que los usuarios finales estén mucho más especializados.

Así, podríamos decir que el enfoque de Kimball se ajusta más a proyectos pequeños en los que se persiga un sistema fácilmente explotable y entendible por el usuario y de rápido desarrollo, siendo el modelo de Inmon más apropiado para sistemas complejos de mayor envergadura.

Todo proyecto tiene sus propias peculiaridades, siendo cada caso único e independiente, por lo que resulta necesario llevar a cabo un estudio de todas ellas antes de decantarnos por una solución u otra, de forma que podamos hacernos una idea sobre qué modelo se ajusta mejor a las condiciones de nuestro proyecto.

 

Aun así, tampoco debemos cerrarnos a estas dos opciones, ya que existen casos en los que se han implantado soluciones intermedias entre ambas visiones, logrando así sistemas híbridos que permiten conjugar con éxito las ventajas de ambas perspectivas.