Las 10 cosas ms importantes

para crear un Data Warehouse

Si tuviera que dar una nica recomendacin para la

construccin de un data warehouse, o para la
implantacin de un proyecto Business Intelligence,
sera sin duda el principio DRY de no repetirse.

Dont repeat yourself, o simplemente DRY, es un

principio que defi ende la necesidad de reducir o
eliminar todo tipo de duplicidades. Este principio,
aplicado a la ingeniera 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 extraccin de la informacin, en el
tratamiento de estos datos, en el modelo de datos, en
la arquitectura de la solucin, en los patrones que
seguimos, en las herramientas de explotacin, en los
informes que realizamos y en la estructura de cada
uno de ellos, en la documentacin En todo. Cada vez
que nos ponemos la gorra de programadores y
hemos de disear algo o tomar una decisin tcnica (o
no), debemos preguntarnos, Y qu opinara DRY de
esto?

Por supuesto, y muy lamentablemente, a veces son

inevitables las duplicidades. De hecho,
paradjicamente, un data warehouse es la duplicacin
de datos que ya tenamos en otro lugar. Tambin las
herramientas o los lenguajes de programacin (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 justifi cada esta
duplicidad que estoy a punto de introducir? Las
ventajas que nos aporta la duplicidad cubre los
importantes costes de mantenimiento que tiene toda
reiteracin? No es posible automatizarlo? Es posible
realizarlo de otro modo? No hagas nada sin pasarlo por
el fi ltro DRY.

Lo contrario de DRY es WET (Write Everything

Twice), y tiene unas implicaciones nefastas: La ms
leve de ellas es que se tarda el doble de tiempo en
escribirlo, y la ms grave es que tendrs la lgica de
tu aplicacin y procesos, y los datos de tu DW
diseminados en distintos lugares de tu arquitectura.
Una implantacin WET tiene unos costes de
mantenimiento y una deuda tcnica muy elevados.
Cuando se recurre al cmodo Copiar y pegar,
aunque pueda parecer que es fcil y rpido, se est
asumiendo una deuda (deuda tcnica) que repercutir
en intereses (sobrecoste) a lo largo de tooooda la vida
del proyecto.
Como caso particular, analizar la arquitectura que
propona en el artculo 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
tenamos en los sistemas de origen los duplicamos
temporalmente en la staging, los volvemos a duplicar
en un modelo normalizado y fi nalmente los duplicamos
en el modelo dimensional que ser accedido por la
capa de presentacin. S, es una duplicacin dolorosa,
y costosa como todas las duplicaciones (alguien
 pensaba que construir un DWH es gratis?). Como toda
duplicacin, debe justifi carse, 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 contraposicin al
sistema operacional de origen, tiene un enfoque
analtico y cubre unos requerimientos que el
operacional no alcanza (facilidad de uso, tiempo de
respuesta, visin histrica). 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 justifi carlo: Es temporal, es fcil
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 discpulos 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 tcnica, y con el volumen
de informacin que gestionan las empresas, el
modelo normalizado no cubre los requerimientos
que justifi can la existencia del DWH (facilidad de
uso y tiempos de respuesta, fundamentalmente). En
el mejor de los mundos posibles, las rbitas de los
planetas seran circunferencias perfectas, no habra
terremotos en Lisboa, y todas las consultas seran
instantneas. En el nuestro, no, y por eso es
necesario hacer caso a Kimball y mantener un
modelo dimensional. Otras consideraciones ayudan
a justifi car esta best practice: El modelo
dimensional ser el nico que ser accedido por las
 herramientas de explotacin. En este sentido, es
muy distinto al modelo normalizado. Adems, crear
un modelo dimensional a partir de un modelo
normalizado es una tarea casi trivial que se justifi ca
fcilmente.
En la arquitectura propuesta, los cubos son
opcionales. De entrada, por DRY, evitaremos esta
duplicidad. Pero no somos dogmticos en este
aspecto, los cubos estn muy bien y muchas veces
cumplen una funcin. Lo nico que digo es que debe
justifi carse convenientemente su necesidad.
En los procesos de aprovisionamiento (ETL) ,
tambin es necesario refl exionar si seguimos o no el
principio DRY. En este caso, es fcil 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:
Extraccin: Al extraer los datos desde la
fuente hasta la staging, estamos movindolos a una
base de datos distinta, tal vez en otra tecnologa o
en otra ubicacin fsica. El nico punto que se
accede a las fuentes es aqu. Si se requiere cambiar
el proceso o la estrategia de extraccin, solo se
debe modifi car este cdigo. Es DRY.
Transformacin: El proceso desde la staging al
modelo normalizado es probablemente el ms
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
fi nal, cargamos las tablas que sern accedidas por
la capa de presentacin. Para minimizar el trabajo,
y para optimizar el rendimiento, cargamos solo la
informacin que razonablemente necesitar el
usuario. Las estrategias de carga que seguiremos
 sern 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 artculo he analizado la arquitectura tpica 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
consideracin ms importante a tener en cuenta
durante la construccin de un data warehouse.

Ah, me olvidaba, el declogo de las cosas ms

importantes para crear un Data Warehouse:

Usars DRY en el anlisis

Usars DRY en el diseo
Usars DRY en la ETL
Usars DRY en la implantacin
Usars DRY en data quality
Usars DRY en la explotacin
Usars DRY en el mantenimiento
Usars DRY en la documentacin
Usars DRY en la auditora
Usars DRY en la atencin a usuarios
que se resume en dos uno: Seguirs el principio
DRY, no seguirs el principio WET .