Cmo no construir un datawarehouse

A travs de TodoBI he encontrado un artculo muy interesante de Ralph Kimball (Algn

despistado que no lo conoce?) donde detalla los 12 errores ms comunes en la
construccin de un datawarehouse.
Se trata de un artculo excelente. Cada vez que he cometido alguno de estos errores, he
tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien
desde el principio.
Los doce errores ms comunes en la construccin de un datawarehouse son:

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la
intencin de filtrar o agrupar.
Error 11: Abreviar las descripciones en las tablas de dimensin con la intencin de
reducir el espacio requerido.
Error 10: Dividir las jerarquas y los niveles de las jerarquas en mltiples
dimensiones.
Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
Error 8: Crear smart keys para relacionar una tabla de dimensin con una tabla
de hechos.
Error 7: Aadir dimensiones en una tabla de hechos antes de definir su
granularidad.
Error 6: Crear un modelo dimensional para resolver un informe en particular.
Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
Error 4: Olvidarse del mximo nivel de detalle en el modelo entidad-relacin.
Error 3: Omitir las tablas agregadas y comprimir las tablas de dimensin para
afrontar los problemas de rendimiento.
Error 2: No unificar los hechos entre distintas tablas de hechos
Error 1: No compartir dimensiones entre diferentes tablas de hechos.

En mi vida laboral he participado en la construccin de varios datawarehouses, y he visto

muchos de estos errores. Durante los prximos das, analizar una a una estas
recomendaciones de Kimball, e intentar justificar por que son errores graves y cmo
debemos evitarlos.
A mis lectores menos "tekies", os pido perdn porque los prximos mensajes no los
escribo pensando en vosotros. Van dirigidos al lado oscuro... :-)

Datawarehouse

El datawarehouse (DWH) es una pieza bsica, fundamental e indispensable de todo

sistema Business Intelligence. Tal vez alguien no comparta la anterior afirmacin, y crea
que se puede construir un cuadro de mando, o un sistema de reporting, a partir de un
datamart o unos cubitos. Perdnales, porque no saben lo que dicen... :-)
La pieza fundamental de un sistema Business Intelligence es el DWH porque todos los
listados y anlisis que se hagan se harn a partir de esta nica base de datos. En el DWH la
informacin est limpia, unificada y verificada, y gracias a esto todo lo que hagamos
despus cuadrar.
Tal como deca en mi anterior mensaje, voy a analizar los 12 errores ms comunes que
enumera el gur Ralph Kimball. Tal como hace l, har la cuenta regresiva del 12 al 1,
aunque intentar hacerlo en positivo, aadiendo ejemplos y experiencias personales, y
explicando las bases sobre cmo construir un datawarehouse:
Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intencin de
filtrar o agrupar.
En un modelo dimensional se deben diferenciar claramente las tablas de hecho de las
tablas de dimensiones.

Las tablas de hecho contienen los indicadores numricos provenientes de los

orgenes transaccionales.
Las tablas de dimensin contienen los atributos (normalmente textuales) que nos
permiten filtrar y agrupar los indicadores.

En ocasiones no es evidente si un dato es dimensional o si se trata de un indicador. Por

ejemplo, la hora de la venta (hh:mm:ss) puede considerarse un dato mas del hecho de

venta (como el precio, o las unidades vendidas), o una dimensin temporal muy detallada.
O la matrcula del camin que subcontratamos para realizar los transportes. Si no tenemos
un maestro de los miles de camiones que utilizan nuestros transpostistas, ni queremos
analizarlo por las caractersticas del camin, podramos considerar la matrcula como una
especie de indicador e incluirlo en la tabla de hechos.
En caso de duda:

Evita colocar texto largos (como comentarios, o nombres de ciudades o personas)

en las tablas de hecho. Estos campos ocuparan un espacio precioso de nuestras
tablas de hechos, que pueden tener cientos de millones de registros, y que por lo
tanto ocuparan mucho espacio en disco y las consultas seran lentas por el IO
generado. Hoy en da, los gigas son baratos, pero el tiempo para leerlos, no.
Si el dato es compartido entre varias tablas de hecho, ponlo siempre como una
dimensin. Por ejemplo, un mismo cliente puede tener pedidos, ventas,
devoluciones, quejas,

Dimensiones

Denominamos dimensiones a aquellos datos que nos permiten filtrar, agrupar o seccionar
la informacin. El trmino "dimensin" sigue teniendo un cierta connotacin tcnica, por
lo que muchas personas lo siguen denominando "atributo", "caracterstica", "propiedad",
"campo", o incluso "cuadradito azul" (en el caso de una instalacin de BO).
Algunas aplicaciones Business Intelligence utilizan el trmino "dimensin" como
equivalente a "jerarqua" (especialmente en bases de datos multidimensionales). De esta
manera, se habla de la dimensin geogrfica que agrupa los diferentes niveles de
continentes, pases, regiones, provincias y localidades.

Personalmente, prefiero reservar el trmino "dimension" para referirme a cada uno de los
niveles de la jerarqua.
En el modelo relacional del datawarehouse las dimensiones se almacenan en las "tablas
de dimensin", lo que nos lleva al error nmero 11 de nuestra serie:
Error 11: Abreviar las descripciones en las tablas de dimensin con la intencin de
reducir el espacio requerido.
El espacio requerido por las tablas de dimensin es despreciable frente a lo que ocupan
los hechos. Por ejemplo, una cadena como Zara puede tener unas 5000 tiendas, y debe
generar unos 3 o 4 millones de registros de venta diarios. En este y otros ejemplos que
podramos citar, tambin las dimensiones de cliente o producto son despreciable frente a
las ventas, los envos o la produccin diaria.
Por lo tanto, no debemos considerar el espacio como un aspecto determinante para
modelizar las dimensiones. En particular, cada cdigo debe tener su descripcin. Las
dimensiones son la interfaz que tendrn los usuarios para navegar por la informacin, por
lo que conviene que sean lo ms explcitas y claras posible.
Incluso debemos plantearnos la necesidad real de introducir los cdigos en la capa de
presentacin a los usuarios. Aunque algunos trabajadores pueden estar acostumbrados a
trabajar con los cdigos de familia, las referencias o los cdigos de proveedor, nadie los
conoce todos, y especialmente los nuevos empleados pueden tener dificultades para
reconocerlos. Siempre son preferibles las descripciones.
Personalmente, omito por defecto todos los cdigos de la capa de presentacin, y slo
cuando algn usuario lo solicita explcitamente lo aado en el sistema. Esta manera de
actuar nunca me ha generado un problema. De hecho, es sorprendente lo rpido que se
acostumbran los usuarios a trabajar con las descripciones y lo rpido que se olvidan de los
cdigos con los que han trabajado toda la vida... (una causa de esto es que con una
herramienta Business Intelligence raramente se ha de teclear un cdigo, ya que se trabaja
con clics de ratn y con listas de valores).

Jerarquas
Las dimensiones se agrupan en jerarquas mediante relaciones uno-a-muchos. Una
poblacin agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una
regin est formada por varias provincias. Etctera. Las jerarquas tpicas, que aparecen
en cualquier sistema Business Intelligence, son:

Jerarqua geogrfica o de clientes (pas del cliente/regin/ciudad/cliente)

Jerarqua de producto (marca/familia/producto/presentacin)
Jerarqua comercial (pas/zona/punto de venta)
Jerarqua temporal (ao/trimestre/mes/da)

Evidentemente, pueden existir jerarquas adicionales, o incluso puede haber diferentes

maneras de jerarquizar una misma informacin. En particular, es habitual la existencia de
diferentes jerarquas de producto (lo que es una "pesadez" muchas veces necesaria, otro
da lo comentar).
Esta manera de visualizar jerrquicamente la informacin resulta muy natural y cmoda
para los usuarios de negocio.
Y, como siempre, podemos cometer errores modelizando las jerarquas. ste es el error
nmero 10 de esta serie sobre cmo construir un datawarehouse:
Error 10: Dividir las jerarquas y los niveles de las jerarquas en mltiples dimensiones
Existen dos maneras principales de modelizar las jerarquas:

Modelo en estrella: Donde una nica tabla contiene toda la informacin de la

jerarqua.
Modelo copo de nieve: Donde se crea una tabla para cada nivel de la jerarqua

En la base de datos de presentacin (tambin llamado modelo dimensional) del DWH

debe preferirse siempre el modelo en estrella. Es decir, debe crearse una nica tabla para

cada jerarqua. La misma tabla de PRODUCTOS debe tener toda la informacin relativa a
los productos (presentacin, producto, familia, marca).
El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence, por
lo que interesa que las consultas generadas sean sencillas (con pocas tablas y pocas
relaciones). El modelo en estrella es perfecto para conseguir este objetivo. Adems,
desaparece el problema que generan las diferentes jerarquas en que se pueden agrupar
los productos.
Sin embargo, por desgracia, no siempre es posible tener un modelo en estrella perfecto.
La herramienta de explotacin puede requerir normalizar parte de una jerarqua en una
tabla independiente. Esta limitacin aparece cuando diferentes "hechos" estn definidos
con diferente granularidad. Por ejemplo, las ventas estn a nivel de "producto", pero los
objetivos de venta se marcan a nivel de "familia". En este caso, muchas herramientas BI
exigirn la existencia de una tabla de FAMILIAS.
Finalmente, es importante destacar que adems del "modelo dimensional" el DWH debe
mantener un modelo normalizado de la informacin (llamado "modelo relacional"). En
este otro modelo, la informacin s que debe estar normalizada, unificada y limpia.

Dimensiones lentamente cambiantes

En los anteriores comentarios de esta serie sobre cmo construir un datawarehouse,
explicaba las caractersticas de las dimensiones y las jerarquas. Sin embargo, estaba
omitiendo un aspecto principal de estas tablas.
La informacin de las dimensiones no es esttica, ya que puede modificarse en el
operacional por diferentes motivos. Por ejemplo, puede corregirse la fecha de nacimiento
de un cliente, o ste puede cambiar de ciudad, o una delegacin puede asignarse a un
delegado diferente, etc. Cmo debe gestionarse esta informacin?
En primer lugar, debe tenerse en cuenta que el tratamiento que se realizar depender de
cada dimensin y de las necesidades del negocio. Por ejemplo, si se actualiza la fecha de
nacimiento de un cliente se puede asumir que ese cambio aplica a toda la historia de ese
cliente. Sin embargo, existen casos donde la informacin dimensional histrica es
importante. Considera estas dos situaciones:
Previsin de ventas: Para realizar una previsin de ventas para el prximo ao, deberemos
considerar las ventas histricas de las tiendas que actualmente tiene asignado cada
delegado.
Anlisis de mrgenes: Si queremos analizar los descuentos que aplica cada delegado,
deberemos considerar las ventas de aquellas tiendas que han tenido asignadas a lo largo
del tiempo.
Por lo tanto, en este ejemplo, deberemos modelizar la informacin de tal modo que
seamos capaces de conocer el "delegado actual" y el "delegado/s histrico/s".
Para conseguir este objetivo se introducen las "claves subrogadas", que son
identificadores sin ningn significado especfico para el negocio. Aunque existen
diferentes maneras de modelizar estos datos, lo habitual es trabajar con las "fechas de
vigencia". Por ejemplo, esta sera la estructura de la tabla de DELEGACIONES en el modelo
relacional:

Ampliar imagen
Analizando cuidadosamente los valores de esta tabla, puede observarse que Pedro era el
responsable de las delegaciones de Madrid y Barcelona, y que sus funciones fueron

asumidas posteriormente por Juan y Mara. En el modelo dimensional, la tabla podra

modelizarse de este modo:

El sistema funcionara de manera similar con cualquier otra dimensin que pudiese tener
la jerarqua de delegaciones, o cualquier otra jerarqua. Evidentemente, se trata de un
tema complejo y que debe considerarse, o caeramos de lleno en el error nmero 9:
Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes
En cualquier definicin del trmino datawarehouse se menciona que es un repositorio de
informacin histrica, y con ello se pretende enfatizar que contiene:

Historia de los hechos: En el operacional existe registro de los "hechos" del

negocio de los ltimos meses o de unos pocos aos. Sin embargo, en el DWH se
intenta que exista un histrico mucho mayor.
Historia de las dimensiones: El operacional slo suele guardar la situacin actual
de las dimensiones. En el DWH, sin embargo, debe mantenerse toda la evolucin
de los cambios dimensionales.

Pues bien, este segundo punto se suele olvidar (o ignorar) en algunas implantaciones de
DWH por las siguientes razones:

La "visin actual" parece suficiente. Al fin y al cabo, es lo que siempre se ha hecho

en el sistema operacional.
El usuario no siempre entiende la diferencia entre la "visin actual" y la "visin
histrica". Y por lo tanto no sabe concretar sus necesidades reales.
La gestin de cambios en las dimensiones nunca aparece en los requerimientos
que motivaron el proyecto. De entrada, no parece importante (pero lo es).

No nos dejemos engaar. A pesar de todo esto, la gestin de dimensiones lentamente

cambiantes es imprescindible. Personalmente, acostumbro a guardar toda la historia de
las dimensiones en el modelo relacional (incluso algunos datos que inicialmente no
parecen necesarios como la "fecha de nacimiento"). En el modelo dimensional, de
entrada, slo publico la visin actual, y slo cuando lo solicita explcitamente el usuario de
negocio, aado la visin histrica de esa dimensin.

Claves subrogadas

En la anterior entrega de esta serie sobre cmo construir un datawarehouse ya introduca

el concepto de las claves subrogadas.
Una clave subrogada es un identificador nico que se asigna a cada registro de una tabla
de dimensin. Esta clave, generalmente, no tiene ningn sentido especfico de negocio.
Son siempre de tipo numrico. Preferiblemente, un entero autoincremental.
Habitualmente, el sistema operacional ya utiliza sus propias claves, aunque suelen ser de
tipo carcter y tienen un sentido especfico para los empleados de la compaa. Por
ejemplo, el cdigo BCN puede utilizarse para referirse a Barcelona, o el DNI de cada
empleado puede ser la clave nica de la tabla de empleados. O el cdigo de barras para
referirse a un producto. Por qu necesitamos, entonces, crear unos nuevos
identificadores en el sistema Business Intelligence? Por varios motivos:

Fuentes heterogneas. El DWH suele alimentarse de diferentes fuentes, cada una

de ellas con sus propias claves, por lo que es arriesgado asumir un cdigo de
alguna aplicacin en particular. Qu ocurrira si en el futuro se aade informacin
de una aplicacin que tiene su propio maestro de ciudades? Seguro que nos
generar un problema, aparecern ciudades que no existan en nuestro
maestroCmo lo gestionaramos? No s. Lo mejor es crear nuestras propias
claves subrogadas desde el inicio del proyecto.
Cambios en las aplicaciones origen. Puede ocurrir que cambie la lgica
operacional de alguna clave que hubisemos supuesto nica, o que siempre
debera estar informada. Qu pasar cuando llegue un empleado sin DNI? Qu
pasar cuando se de de alta una ciudad extranjera con el cdigo BCN? Prefiero no
saberlo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del
proyecto.
Rendimiento. En la base de datos, ocupa menos espacio un entero que una
cadena. Identificar una ciudad con 5 bytes, o una persona con 9 bytes es un
desperdicio considerable de espacio. De hecho, no debe preocuparnos el espacio
que ocupa, sino el tiempo que se pierde en leerlo Recordad que las claves
subrogadas las llevaremos a las tablas de hechos, por lo que cada cdigo es

susceptible de repetirse cientos de millones de veces. Conviene optimizarlo al

mximo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del
proyecto.
Por supuesto, tambin se pueden cometer errores al generar una clave subrogada
Error 8: Crear smart keys para relacionar una tabla de dimension con una tabla de
hechos.
En ocasiones, nos puede parecer til aprovechar la lgica que subyace a los elementos
para generar nuestras propias claves. Por ejemplo, si queremos crear una jerarqua de
ciudades, nunca debemos caer en la tentacin de crear una simple concatenacin (y
generar el cdigo ESP-CAT-BCN para referirnos a Barcelona) Tambin es un error crear
una clave compuesta de varios campos. Aunque en el operacional la terna pas-CCAAciudad sea nica, en el DWH debemos crear una clave subrogada formada por un solo
campo entero autoincremental.
Recuerda: Sustituye cualquier clave fsica por una clave entera numerada secuencialmente
desde 1 hasta N.

Tablas de hecho
Denominamos hechos a los indicadores de negocio. Por ejemplo, son hechos las
ventas, los pedidos, los envos, las reclamaciones, las compras, etc. Es decir, son todas
aquellas medidas numricas que incluiremos en nuestro sistema Business Intelligence.
Tcnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el
siguiente diagrama, la tabla de ventas es la tabla de hechos:

Una caracterstica importante de las tablas de hecho es el nivel de detalle de la

informacin que se almacena. En el anterior ejemplo, las ventas estn guardadas a nivel
de cliente, producto, almacn, promocin y fecha.
La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su
nivel de detalle, y los indicadores. Nada ms.
Por lo tanto, antes de crear la tabla de hechos debe entenderse perfectamente la
informacin que se guardar, o se estar cometiendo el error nmero 7 de esta serie
sobre cmo construir un datawarehouse
Error 7: Aadir dimensiones en una tabla de hechos antes de definir su granularidad.
De hecho, la creacin de una tabla de hechos es una tarea con poco margen a la
imaginacin. Antes que nada, debe localizarse el origen de la informacin que se quiere
cargar, debe entenderse perfectamente el significado de estos indicadores, y debe
determinarse el nivel de detalle de estos datos. Una vez hecho esto, la creacin de la

estructura de la tabla es inmediata. Tal y como comentaba anteriormente:La tabla de

hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de
detalle, y los indicadores. Nada ms. Y nada menos.
En particular, es un error desnormalizar cualquier dimensin en la tabla de hechos. Por
ejemplo, si la informacin est a nivel de cliente, no necesitamos poner la poblacin o el
pas en la tabla de hechos. Resultara redundante e impactara directamente en el tamao
de la tabla (y en los tiempos de respuesta).

DWH organizado por temas

Otra de las caractersticas importantes que debe tener un DWH es estar "organizado por
temas" (subject-oriented). Bill Inmon es considerado uno de los padres del concepto
DWH, y fue el quien introdujo esta caracterstica en su definicin:
"A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of
data in support of managements decision making process" (Bill Inmon, 1990)

La organizacin temtica de la informacin se refiere a que los datos que estn cargados
incluyen los indicadores relevantes de diferentes reas de informacin de la compaa.
Adems, deben poder cruzarse los indicadores relativos al mismo objeto o evento del
mundo real.
Esta organizacin temtica de la informacin facilita posteriormente la construccin de
informes ad-hoc, ya que permite obtener y cruzar informacin que se gener en procesos
de negocio muy diferentes (aunque de una misma temtica). Observad que esta manera
de organizar la informacin es muy distinta de la existente en un sistema OLTP tradicional,
donde la informacin est organizada por transacciones y procesos.
Modelizar adecuadamente la estructura del sistema Business Intelligence es fundamental
para que posteriormente el usuario puede generarse cualquier informe que necesite. En
particular, es un error grave y frecuente el error nmero 6 de esta serie sobre cmo
construir un datawarehouse
Error 6: Crear un modelo dimensional para resolver un informe en particular.

Efectivamente, el modelo dimensional debe ser independiente de cualquier informe en

particular. Una de las razones que habitualmente justifica la creacin de un sistema
Business Intelligece es la necesidad de otorgar a los usuarios la capacidad de realizar
informes ad-hoc. No tendra sentido, por lo tanto, que el equipo de IT tuviese que adaptar
el datawarehouse para cada informe necesario.
Al iniciar un proyecto de datawarehouse, muchas veces he visto cmo se gastan
demasiados esfuerzos en definir los informes que se necesitan, y se hacen interminables
reuniones con los usuarios de negocio con este objetivo. Es un error que puede costar
muy caro. Me explico: Esas reuniones son necesarias, pero el objetivo debera ser
entender los indicadores y los conceptos con los que trabajan los usuarios de negocio, y
no conocer particularidades intrascendentes de informes determinados.
En particular, si se trabaja con consultores externos, conviene evitar que la aceptacin del
proyecto est vinculada a la realizacin de unos informes en particular. Si esos son los
trminos de tu contrato, existe el riesgo de que los esfuerzos se focalicen en la
construccin de esos informes, cuando lo correcto sera modelizar el DWH de tal forma
que fuese viable consturir cualquier informe.
No digas que no te lo advert :-)

Tablas agregadas

El datawarehouse tiene, y debe tener, todo el detalle de informacin en su nivel atmico.

As, las ventas estarn detalladas por fecha, cliente, producto y punto de venta.
Rpidamente nos daremos cuenta que estaremos trabajando con un volumen muy
importante de informacin. Por poner algn ejemplo, en los sectores de distribucin
retail, telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles
de millones de registros.
Sin embargo, la mayora de consultas no necesitan acceder a tanto detalle. Un "product
manager" puede estar interesado en los totales de venta de sus productos mes a mes,

mientras que el "area manager" consulta habitualmente la evolucin de ventas de sus

zonas.
Incluso con el uso de ndices, la compresin de las tablas, o con una inversin millonaria
en hardware, estas consultas habituales deberan leer, agrupar y sumar decenas de
millones de registros, lo que repercutira directamente en el tiempo de respuesta y en el
descontento de los usuarios.
La solucin ante estas situaciones pasa siempre para la preparacin de tablas agregadas.
Las tablas agregadas sumarizan los indicadores de las tablas de detalle a un nivel superior.
Por ejemplo, las ventas podran precalcularse a nivel mensual, o por cliente, o por
producto. De esta manera, las consultas tpicas del "product manager" o del "area
manager" podran ejecutarse en pocos segundos, sin necesidad de acceder a la tabla de
ventas detalladas.
La existencia de estas tablas agregadas debe ser completamente transparente para el
usuario de negocio. Es decir, tanto el "area manager" como el "producto manager"
trabajarn con el indicador "Ventas", y la herramienta Business Intelligence har el resto.
En mi opinin, lo ms complicado es definir las tablas agregadas necesarias. De nada sirve
crear muchos agregados si estos no se utilizan. Es necesario conocer las consultas
habituales de los usuarios. Y, desde luego, lo que no debe hacerse es lo que indica el error
5 de esta serie sobre cmo construir un datawarehouse:
Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
Calcular los agregados en la misma tabla de ventas es un error muy grave e injustificable.
Aunque puede parece adecuado en algunas situaciones, ser sin duda una fuente de
problemas e incoherencias futuras. Este tipo de construcciones errneas suelen aparecer
ante la falta de funcionalidad de las herramientas BI, lo que obliga al tcnico a crear
modelos extraos.
Personalmente, he visto este tipo de tablas (que mezclan informacin a diferente nivel de
detalle) en sistemas operacionales, donde resulta prohibitivo calcular los totales en el
momento de generacin del informe. De esta manera, el operacional apunta el detalle y
los totales en el mismo momento, y de esta manera los listados predefinidos del host se
ejecutan de manera rpida y sencilla. En un entorno datawarehouse, evidentemente, todo
esto es innecesario y contraproducente.
Recuerda: Cada "granularidad" requiere su propia tabla de hechos.

Mximo nivel de detalle

Aunque existen varias opiniones al respecto, yo soy de los que cree firmemente que en el
DWH debe estar disponible el mximo nivel de detalle de la informacin. Se debe guardar
cada ticket, cada venta, cada transaccin.
Si se dispone la informacin detallada, cualquier consulta posterior podr resolverse en
cualquier de las agrupaciones disponibles. Tal vez, de entrada, puede parecer suficiente
ver las ventas diarias de cada familia, s, Pero y si luego quiero verlo por grupo social? O
por hora de venta? O si lo quiero segmentar por precio de venta? O por tipo de
subfamilia? Slo si inicialmente se dise y carg el datawarehouse con la informacin
detallada podrn contestarse estas preguntas.
En general, dentro del DWH se distinguen tres reas principales:

rea de staging: Que contiene las informacin bruta extrada de los sistemas
operacionales. Es un rea temporal donde los datos se preparan y normalizan
antes de cargarse definitivamente en el DWH.
Modelo relacional: Es una base de datos donde la informacin se encuentra
normalizada. Contiene todo el detalle de informacin. Y toda la historia posible. No
hay tablas agregadas. En este punto la informacin ya est limpia e integrada, y ya
se han creado las claves subrogadas. Es preferible un modelo en "copo de nieve" o
incluso normalizado totalmente.
Modelo dimensional: Es la base de datos que utilizan las herramientas de Business
Intelligence para obtener la informacin y hacer los informes o anlisis. El modelo
dimensional est optimizado para conseguir un buen rendimiento. Existen tablas
agregadas. Se prefiere el modelo en estrella. Y, en mi opinin, tambin debe tener
todo o casi todo el detalle de informacin.

Soy consciente que el mximo nivel de detalle implica cargar muchos datos, y hacerlo por
triplicado, lo que requiere tiempo de carga y espacio en disco. Ya. Conozco las
desventajas. Y debemos asumirlas si queremos un datawarehouse que se til para las
necesidades actuales y para las necesidades futuras.
El error 4 de esta serie sobre cmo construir un datawarehouse trata este asunto:
Error 4: Olvidarse del mximo nivel de detalle en el modelo entidad-relacin.

Efectivamente, el mximo detalle no lo debemos dejar ni en el operacional, ni en la

staging, ni en el modelo relacional. Todo el detalle debe propagarse hasta el modelo
dimensional. Slo de esta manera el sistema Business Intelligence superar el ataque de
las consultas ad-hoc.
Habitualmente, esta manera de trabajar slo la cuestionan los consultores que han
intervenido en excesivos proyectos de cuadro de mando. Es habitual que las empresas
soliciten un cuadro de mando sin tener antes un datawarehouse ni un sistema de
reporting aceptable. En estos casos, cargar todo el detalle puede parecer difcil de
justificar. Cmo voy a proponer un DWH de 500Gb si el gerente slo quiere 4 pantallitas
para hacer el seguimiento mensual de un puado de indicadores? En mi opinin, hay que
proponerlo. Slo disponiendo de un buen DWH podr asegurarse la continuidad del
proyecto BI.
Recuerda: Por lo menos carga el mximo nivel de detalle en el modelo relacional, y podrs
mostrarlo cuando te des cuenta de que tambin lo necesitas en el modelo dimensional.

Rendimiento

En primer lugar, reconozcamos que tenemos un problema de rendimiento. Todos los

datawarehouse tienen un problema de rendimiento. Ninguno va excesivamente rpido.
Siempre se puede mejorar. Es ms, la falta de problemas de rendimiento suele esconder
un problema mucho mayor y de ms difcil solucin la falta de uso del sistema.
Si has llegado hasta esta pgina intentando resolver los problemas de rendimiento de tu
sistema Business Intelligence, lamento decirte que no encontrars la respuesta en este
post. La respuesta est en todos los dems: Modeliza correctamente, y el sistema
funcionar como debe.
Personalmente, creo que la mejor estrategia para afrontar los problemas de lentitud pasa
por monitorizar continuamente el sistema. Debemos conocer cuantas consultas se estn
ejecutando diariamente, y cuanto tiempo requiere cada consulta. Si hacemos esto,

sabremos como de mal va el sistema, y podremos fijarnos objetivos. En el ltimo proyecto

datawarehouse que he participado, hubo un momento en el que 85 % de las consultas
tardaban menos de 1 minuto, y sin embargo muchos usuarios se quejaban de la lentitud
del sistema. El 5% de las consultas tardaban ms de 30 minutos. Para mejorar la situacin,
analizamos diariamente estas consultas en ocasiones eran problemas en la manera de
hacer las consultas por parte de los usuarios, y otras veces era un problemas de
modelizacin. Educando a los usuarios, y con pequeos cambios en el modelo dimensional
pudimos ofrecer una mejora significativa a los usuarios. Menos del 1 % de las consultas
seguan tardando ms de 30 minutos. Afortunadamente, seguamos teniendo problemas
de rendimiento, porque lo contrario sera seal de que dejaron de utilizar el sistema :-)
Los problemas siempre son del software, del hardware, o del informtico. El usuario
nunca se equivoca. Distingo, pues, estas 3 causas de problemas de rendimiento:

Dificultad de uso de la herramienta Business Intelligence, lo que provoca consultas

incorrectas o sin sentido por parte de los usuarios
Modelizacin deficiente (falta de agregados, falta de ndices, etc.)
Hardware insuficiente (el sistema debe dimensionarse en funcin del volumen a
informacin a gestionar y el nmero de usuarios activos)

En particular, ante un problema de rendimiento, debe evitarse cometer el error nmero 3

de esta serie sobre cmo construir un datawarehouse:
Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar
los problemas de rendimiento.
Efectivamente, las tablas agregadas proporcionan una mejora inmediata (y en muchas
ocasiones espectacular) en el rendimiento (siempre y cuando la herramienta de BI sea
capaz de aprovecharse de estos agregados, que debe serlo). En primer lugar, deben
considerarse mejoras en la modelizacin y descartar nuevas y caras inversiones en
hardware.
Si el sistema no est bien modelizado, seguir funcionando mal despus de una
ampliacin de discos, de RAM o de CPU. La ampliacin de hardware slo puede justificarse
ante un aumento del volumen de informacin a gestionar y/o en el nmero de usuarios
del sistema.
Tambin debo decir que el uso de tablas agregadas tiene un coste. Las tablas agregadas
aaden complejidad al sistema, ya que son nuevos elementos que debern mantenerse y
actualizarse indefinidamente. Las tablas agregadas slo son tiles si efectivamente se
usan, y reducen considerablemente el nmero de registros de la tabla detallada.

Unificar los hechos

En la definicin de datawarehouse de Bill Inmon (y en todas las definiciones posteriores de

cualquier menda aficionado al BI, como el autor de este blog de Business Intelligence en
espaol) se seala que un DWH es un repositorio donde la informacin corporativa se
encuentra "integrada".
A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of
data in support of managements decision making process (Bill Inmon, 1990)

Efectivamente, cualquier empresa tiene mltiples sistemas operacionales, cada uno de

ellos con sus propios maestros y su propia informacin. Uno de los objetivos del DWH es
unificar toda esa informacin dispersa en un nico repositorio. Sin embargo, no se trata
slo de juntar todos estos datos, el objetivo es unificarlos, integrarlos y conformarlos, es
decir, dar la misma forma y el mismo significado a dimensiones y hechos aparentemente
distintos (en ingls dicen "conform information").
Por ejemplo, una empresa de distribucin puede tener dos canales de ventas a travs de
los cuales vende los mismos productos (venta al mayor y venta retail). Habitualmente, la
gestin de estos dos negocios la realizarn personas diferentes de diferentes
departamentos, y cada uno de ellos tendr sus sistemas informticos con diferencias
significativas entre ellos. Es muy diferente el negocio minorista del negocio mayorista.
Pues bien, en este ejemplo, uno de los retos de la creacin del DWH sera la unificacin de
estos dos negocios, porque sin duda existirn usuarios que querrn conocer la
"facturacin", y la facturacin evidentemente incluye las ventas al mayor y al ventas retail.
Para realizar esta unificacin, las dos tablas de hechos debern compartir las mismas
dimensiones, y debern definirse con precisin los trminos de cada negocio para que
resulten agregables entre s Incluso, podra ser recomendable unificar los dos hechos en
una misma tabla de hechos, donde la dimensin "tipo de venta" permitiese diferenciar las
ventas al mayor de las ventas retail.
A esta unificacin se refiere el penltimo error de esta serie sobre cmo construir un
datawarehouse:

Error 2: No unificar los hechos entre distintas tablas de hechos

Tal como comentaba, independientemente de que los hechos se modelicen en una o
varias tablas de hechos, estos deben tener la misma forma. Deben tener dimensiones
compartidas que permitan la comparacin y/o agregacin entre s. Si se quiere sumar o
dividir la informacin de distintos hechos, estos deben tener la misma forma y deben
haberse cargado aplicando los mismos criterios.
Otro ejemplo de "conformar" adecuadamente los hechos sera aplicar los mismos criterios
al cargar las compras y las ventas. Si se quiere calcular el cociente de ventas sobre
compras, deberemos asegurarnos que en los dos indicadores se estn considerando los
mismos productos. No debemos, por ejemplo, olvidarnos de aquellos productos que slo
se venden por Internet o que forman parte de un negocio secundario de la compaa. Si
estos productos se incluyen en las ventas, deben incluirse tambin en las compras
(aunque provengan de fuentes distintas).

Unificar las dimensiones

En la anterior entrada de esta serie sobre cmo construir un datawarehouse se describa

la importancia de unificar los hechos. Ahora hablaremos de unificar las dimensiones. No
es ms importante una cosa que la otra. Las dos son imprescindibles.
Sabemos que es normal que dentro de una compaa convivan muchas aplicaciones
informticas, cada una de ellas con sus propios maestros. Una funcin importante del
DWH es la unificacin de estas aplicaciones en unos maestros nicos.
Por ejemplo, la aplicacin de recursos humanos puede utilizar los cdigos "M" y "F" para
indicar el sexo de los empleados, mientras que la aplicacin de CRM puede estar
utilizando los cdigos "H" y "M". Es slo un ejemplo tonto, pero es la realidad de todas las
empresas. Incluso puede haber diferencias entre los cdigos de las tiendas y productos
que utilizan las distintas aplicaciones o mdulos del ERP.

En el DWH, evidentemente, debe existir un solo maestro de gnero. Y un solo maestro de

tiendas. Y un solo maestro de productos. Y un solo maestro de cualquier cosa. En el
proceso de carga del datawarehouse, deben identificarse los cdigos equivalentes, y
asignarles una nica clave subrogada.
Un caso especial, y muy problemtico, es el maestro de clientes. Se puede captar
informacin de los clientes a partir de un formulario en la pgina web, o un carnet de
afiliacin que solicita el cliente en la tienda, o una llamada al departamento de
reclamaciones Es importante identificar las personas entre distintos aplicativos. Ni el
nombre y los apellidos del cliente, ni el email, ni la direccin, ni siquiera el DNI son
mtodos fiables para detectar una misma persona en diferentes aplicaciones. Para
identificar adecuadamente un cliente debe utilizarse una combinacin de todos los
anteriores e incluso puede ser necesaria la intervencin manual. Existen herramientas y
compaas especializadas en esta tarea, y no suele considerarse una responsabilidad del
modelizador del DWH. Normalmente, para realizar una identificacin fiable resulta
necesario modificar las aplicaciones orgen, para realizar el "matching" cuanto antes.
En todos los dems casos, el equipo del DWH debe estar obsesionado por entender y
unificar todos los maestros de la compaa.
El primer error, el ms grave segn Raplh Kimbal, se refiere precisamente a este aspecto
de la modelizacin:
Error 1: No compartir dimensiones entre diferentes tablas de hechos.
Efectivamente, por falta de tiempo y recursos, se pueden cargar los diferentes maestros
tal cual llegan de los distintos operacionales. Es un error muy grave. Las dimensiones
compartidas entre diferentes hechos permiten navegar por la informacin, o cruzar
informacin de distintos orgenes.
Si se realiza correctamente, daremos mucha potencia y funcionalidad a los usuarios de
negocio, el mantenimiento del sistema ser ms sencillo, y podr aadirse nueva
informacin al sistema Business Intelligence de manera paulatina y harmoniosa.
Si no se realiza correctamente, el datawarehouse perder mucha de su utilidad y sentido.