Si tuviera que dar una única recomendación para la construcción de un data warehouse, o para la implantación de un proyecto Business Intelligence, sería sin duda el principio DRY de no repetirse.

“Don’t repeat yourself” , o simplemente DRY, es un principio que defiende la necesidad de reducir o eliminar todo tipo de duplicidades. Este principio, aplicado a la ingeniería del software, fue formulado por Andrew Hunt y David Thomas en “The Pragmatic Programmer” (libro imprescindible si te dedicas al mundo del desarrollo en cualquiera de sus formas…).

El principio DRY debe ser valorado en todas y cada una de las decisiones que tomamos durante el ciclo de vida de un proyecto de software (y de datawarehousing en particular). Hemos de evitar las duplicidades en la extracción de la información, en el tratamiento de estos datos, en el modelo de datos, en la arquitectura de la solución, en los patrones que seguimos, en las herramientas de explotación, en los informes que realizamos y en la estructura de cada uno de ellos, en la documentación… En todo. Cada vez que nos ponemos la “gorra” de programadores y hemos de diseñar algo o tomar una decisión técnica (o no), debemos preguntarnos, ¿Y qué opinaría DRY de esto?

Por supuesto, y muy lamentablemente, a veces son inevitables las duplicidades. De hecho, paradójicamente, un data warehouse es la duplicación de datos que ya teníamos en otro lugar. También las herramientas o los lenguajes de programación (el SQL, por ejemplo) a veces nos obligan a repetir cosas. Es muy triste y muchos gatitos muren por ello, y a veces lo hacemos, pero no sin antes preguntarnos: ¿De verdad es imprescindible? ¿Está justificada esta duplicidad que estoy a punto de introducir? ¿Las ventajas que nos aporta la duplicidad cubre los importantes costes de mantenimiento que tiene toda reiteración? ¿No es posible automatizarlo? ¿Es posible realizarlo de otro modo? No hagas nada sin pasarlo por el filtro DRY.

Lo contrario de DRY es WET ( “Write Everything Twice” ), y tiene unas implicaciones nefastas: La más leve de ellas es que se tarda el doble de tiempo en escribirlo, y la más grave es que tendrás la lógica de tu aplicación y procesos, y los datos de tu DW diseminados en distintos lugares de tu arquitectura. Una implantación WET tiene unos costes de mantenimiento y una deuda técnica muy elevados. Cuando se recurre al cómodo “Copiar y pegar”, aunque pueda parecer que es fácil y rápido, se está asumiendo una deuda (deuda técnica) que repercutirá en intereses (sobrecoste) a lo largo de tooooda la vida del proyecto.

Como caso particular, analizaré la arquitectura que proponía en el artículo anterior y veremos hasta qué punto los datos y procesos de la arquitectura siguen el principio DRY:

Los datos , indudablemente, parece que los estamos repitiendo en distintos sitios. Los datos que ya teníamos en los sistemas de origen los duplicamos temporalmente en la staging, los volvemos a duplicar en un modelo normalizado y finalmente los duplicamos en el modelo dimensional que será accedido por la capa de presentación. Sí, es una duplicación dolorosa, y costosa como todas las duplicaciones (¿alguien pensaba que construir un DWH es gratis?). Como toda duplicación, debe justificarse, y en este caso se valora que los usos que se hacen en cada una de las áreas son distintos y claramente diferenciados:

• El data warehouse , en contraposición al sistema operacional de origen, tiene un enfoque analítico y cubre unos requerimientos que el operacional no alcanza (facilidad de uso, tiempo de respuesta, visión histórica…). Es decir, aunque los datos sean los mismos, el DW y el operacional son cosas distintas.
• El área de staging es una duplicidad evidente. Son los mismos datos que el sistema de origen. Es necesario justificarlo: Es temporal, es “fácil” duplicarlo, y evita que los procesos de carga del DWH (que pueden llegar a ser largos) afecten negativamente al operacional.
• El modelo normalizado es el modelo de datos DRY por excelencia. En un modelo 3NF, cada dato está una y solo una vez. Si hemos aceptado que necesitamos un DWH, y queremos una única “fuente de la verdad”, y somos buenos discípulos de DRY, hemos de defender a capa y espada el modelo normalizado, con la ayuda de Codd.
• El modelo dimensional es un mal necesario. En el estado actual de la técnica, y con el volumen de información que gestionan las empresas, el modelo normalizado no cubre los requerimientos que justifican la existencia del DWH (facilidad de uso y tiempos de respuesta, fundamentalmente). En el mejor de los mundos posibles, las órbitas de los planetas serían circunferencias perfectas, no habría terremotos en Lisboa, y todas las consultas serían instantáneas. En el nuestro, no, y por eso es necesario hacer caso a Kimball y mantener un modelo dimensional. Otras consideraciones ayudan a justificar esta best practice : El modelo dimensional será el único que será accedido por las herramientas de explotación. En este sentido, es muy distinto al modelo normalizado. Además, crear un modelo dimensional a partir de un modelo normalizado es una tarea casi trivial que se justifica fácilmente.
• En la arquitectura propuesta, los cubos son opcionales. De entrada, por DRY, evitaremos esta duplicidad. Pero no somos dogmáticos en este aspecto, los cubos están muy bien y muchas veces cumplen una función. Lo único que digo es que debe justificarse convenientemente su necesidad.

En los procesos de aprovisionamiento (ETL) , también es necesario reflexionar si seguimos o no el principio DRY. En este caso, es fácil ver que los tres procesos de carga propuestos son ortogonales y distintos. Cumplen funciones distintas y siguen estrategias distintas. En esta ETL no estamos duplicando nada:

• Extracción : Al extraer los datos desde la fuente hasta la staging, estamos moviéndolos a una base de datos distinta, tal vez en otra tecnología o en otra ubicación física. El único punto que se accede a las fuentes es aquí. Si se requiere cambiar el proceso o la estrategia de extracción, solo se debe modificar este código. Es DRY.
• Transformación : El proceso desde la staging al modelo normalizado es probablemente el más complejo. En este punto, y solo en este punto , conformamos las dimensiones, integramos las distintas fuentes, limpiamos o seleccionamos los datos, guardamos la historia de las SCD, etc. Es muy DRY.
• Carga del modelo dimensional: En el proceso final, cargamos las tablas que serán accedidas por la capa de presentación. Para minimizar el trabajo, y para optimizar el rendimiento, cargamos solo la información que razonablemente necesitará el usuario. Las estrategias de carga que seguiremos serán muy distintas a las anteriores (no nos hemos de preocupar de crear la historia de las SCD, podemos usar estrategias de recarga completas, no hemos de controlar la calidad del dato de origen, etc.).

En este artículo he analizado la arquitectura típica de un DWH desde la óptica DRY. Pero es solo un ejemplo. El principio DRY debes considerarlo en todo lo que hagas, y por eso me atrevo a decir que es la consideración más importante a tener en cuenta durante la construcción de un data warehouse.

Ah, me olvidaba, el decálogo de las cosas más importantes para crear un Data Warehouse:

• Usarás DRY en el análisis
• Usarás DRY en el diseño
• Usarás DRY en la ETL
• Usarás DRY en la implantación
• Usarás DRY en data quality
• Usarás DRY en la explotación
• Usarás DRY en el mantenimiento
• Usarás DRY en la documentación
• Usarás DRY en la auditoría
• Usarás DRY en la atención a usuarios

…que se resume en dos uno: Seguirás el principio DRY, no seguirás el principio WET .