Oracle Data Warehouse – Integridad Referencial

Existen numerosas opciones de motores relacionales en el mercado que nos permiten implementar data warehouse y datamarts, una de las más utilizadas (sobre todo por grandes empresas) es Oracle.

Resulta por tanto de interés conocer las posibilidades que este proveedor ofrece a la hora de construir aplicaciones BI. En esta entrada, dedicada a la integridad referencial, damos inicio a una serie de publicaciones en las que repasaremos algunos tips y buenas prácticas en el modelado de bases de datos Oracle.

Seguramente en algún momento nos habremos planteado si habilitar o no las foreign key en nuestro modelo, y que ventajas o inconvenientes tendremos en función de la decisión tomada. En principio podría parecer que no tiene mucho sentido habilitar las claves ajenas, sobre todo si ya estamos garantizando la consistencia de los datos en procesos ETL implementados con herramientas como Informatica PowerCenter, kettle o AB Initio.
Muchos de los argumentos en contra de establecer foreign key afirman que hacerlo afecta negativamente en la carga del data warehouse:

  • Se pierde flexibilidad y paralelismo en el proceso de carga. Para evitar rechazo de registros por incumplimiento de restricciones, sería necesario seguir un orden secuencial en la actualización de las tablas del modelo. Esto hace muy difícil el refresco simultáneo de las tablas hub y satellite tal y como propone Dan Linsted en el esquema Data Vault 2.0.
  • Cada vez que se actualizan los datos de las tablas de hechos se requiere de un tiempo extra para que el SGBD compruebe la existencia de los correspondientes valores en las tablas referenciadas.

Sin embargo, habilitar las foreign key, tiene unos beneficios que deben ser tenidos en cuenta, y tienen peso suficiente como para decidir activarlas en nuestra solución BI:

  • Son muy útiles a la hora de entender el modelo de datos. Mediante un proceso de ingeniería inversa, se pueden obtener las relaciones entre tablas, lo que supone un beneficio muy importante para los administradores y equipos de mantenimiento de las aplicaciones, pues no siempre se cuenta con documentación completa que describa todos los elementos del modelo y sus relaciones. Sin las claves ajenas, lo que obtendríamos sería una colección de tablas desconectadas sin que a primera vista pudiéramos identificar las conexiones existentes entre ellas.
  • Son fundamentales para que el optimizador de consultas encuentre el plan de ejecución idóneo. Además, como veremos en siguientes entradas, algunos métodos de optimización de datamarts requieren de la existencia de foreign keys.

De modo que las claves ajenas proporcionan ventajas que ayudan a nuestra solución, haciéndola más legible y eficiente. Pero ¿cómo evitar los inconvenientes y aprovechar estos beneficios? La respuesta es crear foreign keys con una serie de características especiales. Para ello usaremos las cláusulas rely, disable y novalidate.

Disable Si aplicamos esta cláusula, a la hora de insertar nuevos registros, no se realiza ninguna comprobación de existencia de valores en la tabla referenciada, lo cual no es necesario si por ejemplo ya tenemos un proceso ETL que garantiza la integridad referencial.
Novalidate Cuando una constraint presenta esta característica, el cumplimiento de la misma no se garantiza para los datos ya existentes en la tabla, de tal manera que podríamos deshabilitar la clave ajena, hacer una carga bulk, y volver a habilitarla sin incidir en ninguna pérdida de rendimiento en la actualización del data warehouse, pues el sistema gestor no está obligado a validarlo.
Rely Con esta opción le indicamos al optimizador de consultas que puede utilizar esta constraint aunque este en modo novalidate. Es muy importante recordar que si una foreign key quiere usarse como rely, previamente la primary key a la que hace referencia debe haberse declarado como rely.

 

A modo de ejemplo si tenemos una tabla de divisas y otra de contratos que contiene un campo id_divisa apuntando a la primera, podemos crear la clave ajena de la siguiente forma:

ALTER TABLE divisa
ADD CONSTRAINT pk_divisa
PRIMARY KEY (id_divisa) RELY;
ALTER TABLE contratos
ADD CONSTRAINT fk_contratos_divisa
FOREIGN KEY (id_divisa)
REFERENCES divisa (id_divisa)
RELY DISABLE NOVALIDATE;

De esta manera, utilizando correctamente ciertas cláusulas que modifican el normal funcionamiento de una clave ajena, podemos hacer uso de ellas en nuestro data warehouse aprovechando sus beneficios y evitando a la vez posibles problemas en la eficiencia de las cargas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.