Voy a intentar exponer de la forma más sencilla posible el eterno dímela sobre el uso de la Integridad Referencial sobre un Data Warehouse.
He optado hoy por escribir algo sobre ello por varias causas: nunca encontré nada al respecto en ningún lugar o por lo menos de forma clara, e incluso grandes “Gurus”, el mismo Kimball como consultor CONSULTOR, tampoco me contesto claramente a dichas preguntas. Se limito a decir un “depende”, desde luego así no se equivocó.
Para empezar debemos partir del concepto claro de que al DW solamente se accede, por los usuarios, para la consulta de información. Por lo tanto, inicialmente no se justifica controles para garantizar la consistencia e integridad de la información.
Los problemas de consistencia e integración nos pueden aparecer en los procesos de altas, bajas y modificaciones. Estos dos últimos casos más que discutibles conceptualmente en un DW, pero siempre existen excepciones y causas de fuerza mayor.
El tener “levantada” la integridad referencial tiene lógicamente las ventajas de todos conocidas, pero para procesos de carga masivos nos ocasiona o nos puede ocasionar graves problemas. Las cargas son radicalmente más lentas, debido a las gestiones que debe realizar la propia BBDD, el orden de las cargas tiene que estar adecuado a las mismas, etc, etc.
También en función del volumen de información a cargar y de la ventana temporal que nos hubieran dejado para ello, nos aporta suficientes “input” como para decidir definir IR o no.
Una consideración muy especial la podríamos obtener por asegurar la calidad de los procesos ETL desarrollados. Si dichos procesos están REALMENTE bien desarrollados, en todos los aspectos (calidad, depuración de errores, parámetros de control de ejecución, etc.), entonces y solo entonces nos podríamos plantear no tener declarada una IR, de escasa necesidad real en el día a día del DW. ¿Estamos seguros de que mis ETL son muy buenos?.
Lo que no tiene especial sentido, o por lo menos nos puede ocasionar más dolores de cabeza que beneficios, es disponer de IR y cuando vamos a lanzar los procesos de carga (inicial, histórica, periódica o lo que queráis) es desactivar dicho control, proceder con la carga masiva y luego intentar levantar la IR. Esta solución la plantea algún fabricante de BBDD, se nota que no han tenido cargas masivas de Teras. La IR no podrá activarse… ¿Y ahora qué? ¿Qué limpia el desastre?, Al final existen soluciones para todo, pero bajo mi opinión estamos perdiendo un tiempo escaso y caro. ¡¡¡Ojo a esta solución!!!.
También el uso de la IR, tiene mucho que ver con el tipo de modelo de datos y de base de datos. Entendiendo que dicha cuestión se centra exclusivamente en las BBDD relacionales, pues las multidimensionales propietarias… no tiene sentido.
Volviendo al tema de los modelos. Si estamos, y lo siento, bajo “estrellas” solamente podremos activar IR entre la tabla de hechos y sus dimensiones asociadas. Pero no podremos definir ni gestionar relaciones de padres e hijos, y además con IR, entre los campos de una misma tabla. Ojo, que esta cuestión suele ser olvidada, ya estamos obligados a hacer bien la carga de una dimensión sobre una única tabla (estrella) vía ETL o manual, pues aquí nadie nos va a ayudar.
Si por el contrario usamos modelos copo de nieve, afortunadamente podremos usar todas las ventajas de la IR y podremos descargar, si fuera nuestra solución definida, de controles y procesos complejos a los procesos ETL.
“Ante la duda …” (y no empecemos) monten, si pueden, integridad referencial, no olviden que si cargan basura sacarán basura.
José María Arce
He optado hoy por escribir algo sobre ello por varias causas: nunca encontré nada al respecto en ningún lugar o por lo menos de forma clara, e incluso grandes “Gurus”, el mismo Kimball como consultor CONSULTOR, tampoco me contesto claramente a dichas preguntas. Se limito a decir un “depende”, desde luego así no se equivocó.
Para empezar debemos partir del concepto claro de que al DW solamente se accede, por los usuarios, para la consulta de información. Por lo tanto, inicialmente no se justifica controles para garantizar la consistencia e integridad de la información.
Los problemas de consistencia e integración nos pueden aparecer en los procesos de altas, bajas y modificaciones. Estos dos últimos casos más que discutibles conceptualmente en un DW, pero siempre existen excepciones y causas de fuerza mayor.
El tener “levantada” la integridad referencial tiene lógicamente las ventajas de todos conocidas, pero para procesos de carga masivos nos ocasiona o nos puede ocasionar graves problemas. Las cargas son radicalmente más lentas, debido a las gestiones que debe realizar la propia BBDD, el orden de las cargas tiene que estar adecuado a las mismas, etc, etc.
También en función del volumen de información a cargar y de la ventana temporal que nos hubieran dejado para ello, nos aporta suficientes “input” como para decidir definir IR o no.
Una consideración muy especial la podríamos obtener por asegurar la calidad de los procesos ETL desarrollados. Si dichos procesos están REALMENTE bien desarrollados, en todos los aspectos (calidad, depuración de errores, parámetros de control de ejecución, etc.), entonces y solo entonces nos podríamos plantear no tener declarada una IR, de escasa necesidad real en el día a día del DW. ¿Estamos seguros de que mis ETL son muy buenos?.
Lo que no tiene especial sentido, o por lo menos nos puede ocasionar más dolores de cabeza que beneficios, es disponer de IR y cuando vamos a lanzar los procesos de carga (inicial, histórica, periódica o lo que queráis) es desactivar dicho control, proceder con la carga masiva y luego intentar levantar la IR. Esta solución la plantea algún fabricante de BBDD, se nota que no han tenido cargas masivas de Teras. La IR no podrá activarse… ¿Y ahora qué? ¿Qué limpia el desastre?, Al final existen soluciones para todo, pero bajo mi opinión estamos perdiendo un tiempo escaso y caro. ¡¡¡Ojo a esta solución!!!.
También el uso de la IR, tiene mucho que ver con el tipo de modelo de datos y de base de datos. Entendiendo que dicha cuestión se centra exclusivamente en las BBDD relacionales, pues las multidimensionales propietarias… no tiene sentido.
Volviendo al tema de los modelos. Si estamos, y lo siento, bajo “estrellas” solamente podremos activar IR entre la tabla de hechos y sus dimensiones asociadas. Pero no podremos definir ni gestionar relaciones de padres e hijos, y además con IR, entre los campos de una misma tabla. Ojo, que esta cuestión suele ser olvidada, ya estamos obligados a hacer bien la carga de una dimensión sobre una única tabla (estrella) vía ETL o manual, pues aquí nadie nos va a ayudar.
Si por el contrario usamos modelos copo de nieve, afortunadamente podremos usar todas las ventajas de la IR y podremos descargar, si fuera nuestra solución definida, de controles y procesos complejos a los procesos ETL.
“Ante la duda …” (y no empecemos) monten, si pueden, integridad referencial, no olviden que si cargan basura sacarán basura.
José María Arce
