Hola, a la hora de diseñar un data warehouse, me considero dentro del grupo de los "kimbalistas".
Suelo estructurar los repositorios de datos tal y como recomienda Kimball en su "biblia". Me choca bastante cuando en reuniones de trabajo con otros colegas de éste negocio, normalmente consultores externos que vienen a trabajar con nosotros, me preguntan que porqué están los datamarts o la staging area dentro de la misma base de datos que el data warehouse.
Dejando de lado restricciones técnicas (volumen de infromación, restricciones en cuanto a tiempos de respuesta, etc), desde el punto de vista "teórico" del diseño, cuando les digo que los datamarts son la capa de explotación o presentación del DW y por tanto forman parte del propio DW me miran como si les hablara en chino y me argumentan que no, que los datamarts no forman parte del DW.
Al preguntarles por qué metodología siguen para aplicar ese criterio de diseño, no saben qué responderme. Sin embargo, a mi sí que me gustaría conocer vuestra opinión y si existe algún otro autor o gurú que soporte esta otra "filosofía" de construcción, más que otra cosa por mirarla y ver qué puedo aprender.
- Inicie sesión para enviar comentarios
La clásica alternativa a la
Subido por Carlos el 19 Octubre, 2011 - 13:22
La clásica alternativa a la metodología 'Kimball' es la de Bill Inmon, el otro gurú del Data Warehouse. De hecho yo diría que las dos discusiones más repetidas en BI y DWH son 'Kimball vs Inmon' y 'Estrella vs Copo de Nieve'.
Inmon propone un modelo en el que primero se crea el Data Warehouse corporativo, teniendo en cuenta todos los requerimientos disponibles de diversos departamentos, y después se crean los Datamarts simplemente como extracciones o subconjuntos de ese Data Warehouse corporativo.
La propuesta de Kimball es una aproximación por partes, se va construyendo el Data Warehouse corporativo a medida que se van desarrollando Datamarts, y esos Data Marts comparten dimensiones conformadas, que pueden permitir realizar consultas o análisis sobre más de un Data Mart a la vez. Así, el DWH corporativo es más bien virtual, ya que en realidad es la integración de todos los Data Marts que se hayan ido construyendo.
Volviendo a tu pregunta, estoy de acuerdo contigo en que siguiendo la filosofía Kimball no tiene mucho sentido decir que los Data Marts se separen del Data Warehouse, como mucho podrías tener Data Marts en BBDD diferentes. La propuesta de Inmon, sin embargo, separa lógica y físicamente el Data Warehouse corporativo y los Data Marts, por lo que, aunque pueden estar en la misma base de datos, si por ejemplo el volumen de datos es grande una manera de mejorar el rendimiento puede ser alojar el DWH en una BD y los DM en otra, ya que además las características de cada entorno son diferentes, sobretodo en cuanto a volumetría de las tablas de hechos; de esta manera los parámetros de cada base de datos se podrán afinar por separado para dar mejores tiempos de respuesta.
Interesante pregunta, e
Subido por Crono el 23 Octubre, 2011 - 01:57
Interesante pregunta, e interesante respuesta de Carlos.
Mi opinión es que independientemente de la "filosofía" que sigamos, debemos saber y preguntarnos a menudo porque hacemos las cosas cómo las hacemos.
Aunque sea verdad que según Kimball un DWH está formado por múltiples DM, ¿Por qué Kimball propone eso? O, mejor, ¿Por qué tú lo haces de esa manera?
Si los DM son capas de explotación que se atacan por herramientas/soluciones/usuarios independientes, ¿Qué necesidad hay de que estén en el mismo servidor o en la misma base de datos? ¿O lo hacemos así sólo por “filosofía”?
Haciéndolo así, evidentemente tenemos una serie de ventajas: Un único servidor y una única base de datos suponen -quizá- un ahorro económico y mayor facilidad de manteniemiento. Pero también hay inconvenientes: El uso de unos usuarios puede afectar a los demás, si se “rompe” la máquina todos quedan afectados, la estimación de recursos HW es más compleja, etc.
Y cuando hay pros y contras, como siempre, hemos de ponderar y decidir. Ni siempre es mejor ponerlo todo junto, ni siempre es mejor ponerlo todo separado, y existen muchos grados intermedios…
Esas cosas son las que, a mi parecer, hemos de discutir y valorar, antes de si Kimball o Inmon decían tal o cual…
Además, si un DWH está formado por distintos DM, ¿Quién dice que un DWH deba estar en un único servidor? ¿o en una única base de datos? ¿Quién dice que yo no puedo tener mi DWH repartido geográficamente? Es decir, que dividiendo el problema en distintas BD, tampoco creo que estés contradiciendo la visión de Kimball…
Simplemente, he adoptado la
Subido por cmateos el 25 Octubre, 2011 - 14:56
En respuesta a Interesante pregunta, e por Crono
Simplemente, he adoptado la "visión Kimball" porque me pareció acertada, consistente y estructurada y no vi necesidad de ver otras. Me miraré la visión Inmon, a ver qué puedo sacar. Si bien si es cierto que la primera regla de Kimball para montar un DW es que el negocio manda.