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
2 comentarios:
Planteas un problema que todo aquel que haya trabajado algo en DW alguna vez se ha debido plantear y me pasa como a tí, no encuentro una respuesta que me deje convencido.
El cliente en el que trabajo actualmente me preguntó porqué había montado el DW sin IR, no estaban acostumbrados a la tecnología informacional y se llevaban las manos a la cabeza. Se lo justifiqué básicamente por motivos de rendimiento en los ETL, pero no le dejé del todo convencido, seguramente porque ni yo mismo lo estaba.
Creo que lo mejor es tener un buen ETL que valide la integridad y en caso de error notificarlo, cargar el dato con código indeterminado/desconocido, pero no parar la carga y que se carguen todos los datos. Esto tiene el riesgo de que por bueno q sea el ETL y sus validaciones, siempre se pueden colar algunos datos que la IR hubiera detectado al volcarlos a la tabla (fallando el volcado eso sí). Si se hubieran detectado al fallar el volcado tienes le ventaja de que no metes basura, pero al día siguiente es probable que el usuario se cabree ya que no tiene sus datos actualizados porque del pase batch ha fallado en el volcado por temas de integridad. En resumen, porque hay 2 dimensiones pendientes de dar de alta que no tienen mucha repercusión en su análisis de negocio. No lo sé, supongo como siempre depende del caso.
En cuanto al rendimiento, creo que los DW en los que he trabajado no deben ser muy voluminosos, porque en alguna ocasión he tomado tiempos haciendo el volcado con las FK’s activadas y luego desactivadas y la diferencia de tiempos que obtuve a favor del caso de FK’s desactivadas no era muy grande, supongo que se debe notar más cuando vuelcas Teras. Era un modelo en estrella que tenía unas 6 ú 8 dimensiones para cada tabla de hechos.
Estoy de acuerdo contigo en que la solución de volcar datos con FK’s desactivadas y luego activarlas no es bueno. Al activarlas puede ocurrir que salgan muchas desintegridades en un mar de datos y es muy costoso limpiar eso.
Otra solución que hemos adoptado en algún momento es no tener FK’s y validarlo todo en el ETL. Para asegurarnos de que no entra basura en el sistema, planificamos un proceso semanal (en un momento q no interfiera con otros procesos y no cargue la máquina) que se barre la base de datos buscando desintegridades. No es la mejor solución, pero la basura te dura como máximo una semana.
No acabo de entender el porqué ves tan diferente el caso de la IR en un modelo en estrella y en otro en copo de nieve.
En fin, complicado tema el de la IR en DW, pero me ha gustado tu planteamiento ya que se nota que le has dado vueltas al tema y siempre se agradece conocer la opinión de expertos en problemas q se encuentra uno a menudo.
Un saludo,
Juan Vidal
Comentarte amigo JUAN VIDAL, que yo si me encuentro convencido de la solución adecuada (por lo menos en la mayoria de los casos), aunque cada caso es diferente y todo se merecen su estudio especifico y particular.
Tambien es cierto que mi articulo tampoco pretende sentar catedra, simplemente provocar la reflexión del lector.
Sobre la reacción de tu cliente actual, sin entrar en grandes argumentos comentar que basicamente desconoce el motivo u operativa de un sistema decisional y el pq de define la IR en los operacionales, recordemos que es basicamente para garantizar la consistencia de información debido a las constantes operaciones de altas , bajas y modificaciones... tipos de operaciones que no existen en DW (salvo las controladas por el administrador del DW).
Si estamos ante DW de varios Teras, podemos estar seguros que con IR... no tenemos noche suficiente, debemos buscar otro tipo de soluciones más acorde a las necesidades reales. Para otros tipo de necesidades (DW pequeñitos o Data Mart... casi todo vale).
Sobre los IR sobre estrellas o modelos copo de nieve, es muy evidente. Una estrella pura, por ejemplo, la dimensión tiempo esta "condensada" todo en una sola tabla, por ejemplo lk_tiempo. No puedes definir FK entre campos de una misma tabla y por lo tanto el gestor es incapaz de controlar la IR. En modelos copo de nieve, la dimensión tiempo tiene tantas tablas como queramos y podemos desnormalizar a nuestro gusto (por este medio es dificil explicarlo), lo realmente importante es que puedes definir fk a tu gusto, puesto que en definitiva puedes llegar a tener un modelo en tercera forma normal... despues desnormalizas codigos y/o descripciones si quieres y si la herramientas de explotación lo sabe interpretar (que no todas).
Como siempre a tu disposición para aclarar cualquier duda y para aprender los unos de los otros, gracias por estar detras de estas líneas y leerlas.
Un cordial saludo,
José María Arce.
www.josemariaarce.es
Publicar un comentario