42-47_almacendedatos.
qxd:Maquetación 1 28/4/09
Jorge Moral Rubia
Ingeniero del ICAI de la promoción
1997, en la rama de Gestión y Orga-
nización Industrial. Su experiencia la-
boral ha estado íntegramente dedica-
da a los campos de Business
Intelligence y Datawarehouse. Es cer-
tificado en Business Objects y Mi-
crostrategy y ha trabajado con las
tecnologías de SAS, Oracle e IBM.
Actualmente trabaja como Consul-
tor Experto en Business Intelligence
para Fujitsu Services.
Comentarios a:
comentarios@icai.es
42 anales de mecánica y electricidad / marzo-abril 2009
13:23 Página 42
Introducción a los
almacenes de datos
Introduction to Data Warehousing
Palabras clave: almacén de datos,
inteligencia de negocio, esquema en estrella
y esquema en copo de nieve
Resumen
Este artículo presenta una introducción al
concepto de almacén de datos (Data Ware-
house), explicando cuál ha sido su razón de
ser, y cómo se construye. A continuación se
describe más detalladamente el concepto de
diseño que implica y sus usos habituales. Le si-
gue una breve descripción de las características
de las aplicaciones que lo explotan. Por último,
vaticina cuál puede ser su desarrollo futuro.
Introducción
La aparición de los ordenadores persona-
les (PC) en la década de los 80 supuso un
cambio muy drástico en la gestión de la in-
formación corporativa. Por un lado, facilitó a
los trabajadores un sopor te con el cual, y
ayudados de hojas de cálculo y procesado-
Key words: Datawarehouse, Business
Intelligence, Star schema, Snowflake schema
Abstract
This article stands for an introduction to
the Data Warehouse concept, by explaining
what its origins were, and how it is built
and fed. Later, it explains the design
principles it involves and how it is used
frequently. It continues with a little outlook
of the applications that exploit it. And
finally, it forecasts what its future
development may be.
res de texto, se afrontaban los quehaceres
laborales de una forma muy distinta; por
otro lado, las grandes infraestructuras de al-
macenamiento y procesamiento de datos
corporativos, que hasta entonces habían re-
sidido en mainframes, comenzaron a descen-
tralizarse para dar paso al procesamiento
distribuido.
42-47_almacendedatos.qxd:Maquetación 1 28/4/09
La evolución tecnológica continua ha su-
puesto desde entonces incrementos sustan-
ciales en la velocidad de proceso de la infor-
mación, así como reducciones significativas
de los costes unitarios de almacenamiento.
Ambos avances han sostenido la diversifica-
ción de los sistemas de gestión, que han ex-
pandido su acción a áreas empresariales co-
mo la contabilidad o la facturación. Al mismo
tiempo, estos sistemas se han dotado pro-
gresivamente de mayor complejidad, puesto
que a menudo son diseñados para procesar
información de compañías con un gran nú-
mero de clientes que realizan transacciones
en tiempo real: los operadores de telecomu-
nicaciones o las entidades financieras son un
claro exponente del grado de complejidad
alcanzado.
Muchos de estos sistemas de gestión de-
partamental son el resultado de la adaptación
de aplicaciones estándar a la situación especí-
fica de la compañía usuaria (el ejemplo más
conocido son las aplicaciones de planificación
de recursos corporativos, ERP, de las que la
alemana SAP es el máximo exponente). En
otros casos, sin embargo, la aplicación es dise-
ñada a medida para un uso concreto, pero no
se considera la integración de la información
en ella almacenada con la de otros sistemas
de gestión. El resultado, en cualquier caso, son
diferentes sistemas de gestión, operando con
los mismos “elementos” (clientes, proveedo-
res, empleados, etc.), pero adoptando codifi-
caciones y nomenclaturas específicas, que ha-
cen imposible la comunicación entre ellos.
Los ejecutivos de las empresas necesitan
para la gestión de las mismas el cálculo de
indicadores de negocio que implican, desde
esta perspectiva, el empleo de información
procedente de dos o más sistemas de ges-
tión. Dicho de otro modo, estos ejecutivos
precisan de una visión consolidada o unifica-
da de la empresa.Y es aquí donde aparece la
tecnología objeto de este artículo.
Almacén de datos
Un almacén de datos (Data Warehouse) es
una base de datos que integra datos proce-
dentes de uno o varios sistemas de informa-
ción de una compañía, y que está orientado
a la toma de decisión.
La integración permite dotar de nomen-
clatura única a los diferentes elementos que
en él se utilizan, y garantizar un acceso cen-
tralizado a información procedente de distin-
tos departamentos: contabilidad, calidad, pro-
ducción, marketing, ventas, etc.
13:23 Página 43
Para llevar a cabo esta integración, es
fundamental en primer lugar tener diseña-
da la base de datos (de ello se hablará más
adelante), pues es dicho diseño el que mar-
cará las necesidades de extracción de in-
formación de cada uno de los sistemas
fuente.
Los procesos que se conectan a los datos
de los sistemas fuente, los recodifican, los in-
tegran y los cargan dentro del almacén de
datos. Reciben el nombre de procesos ETL
(del inglés Extract, Transform, Load).
Estos procesos se ejecutarán con distinta
periodicidad dependiendo de las necesida-
des de los usuarios y de la naturaleza de la
información que se esté almacenando. Por
ejemplo, cuando los almacenes se constru-
yen para datos financieros, la periodicidad de
ejecución de dichos procesos suele ser men-
sual. Sin embargo, cuando se almacena infor-
mación de llamadas telefónicas y su tarifica-
ción, la periodicidad de los procesos de carga
siempre es diaria.
Es en este punto donde reside una de las
grandes diferencias entre un almacén de da-
tos y una base de datos de transacciones. Las
bases de datos de transacciones se diseñan
óptimamente para accesos concurrentes por
muchos usuarios, cuyas operaciones básicas
son altas, bajas y modificaciones en la infor-
mación. Un almacén de datos, por el contra-
rio, es accedido concurrentemente por un
número menor de usuarios, y el acceso siem-
pre se produce para consultar la informa-
ción. Dado que estas consultas entorpecen y
ralentizan sobremanera la carga de los datos
en el almacén, casi siempre los procesos ETL
que cargan los datos son programados du-
rante la noche, momento en el cual no hay
demanda de información para análisis.
El carácter de base de datos de consulta
indica su finalidad básica: la toma de decisio-
nes. Como se verá en los siguientes capítu-
los, las consultas al almacén, realizadas desde
un conocimiento del área que se analiza,
permiten a los usuarios acceder a informa-
ción transaccional consolidada y desagregada
al nivel requerido.
Hechos y dimensiones
Todos los almacenes de datos acostumbran
a construirse mediante una base de datos di-
señada con un concepto dimensional. Se en-
tiende por dimensión el eje de análisis (tiem-
po, producto, cliente, proveedor, etc.) por el
que se desea categorizar la información. Si se
utilizase una denominación estadística, estos
Introducción a los almacenes de datos 43
42-47_almacendedatos.qxd:Maquetación 1 28/4/09 13:23 Página 44

Figura 1. Representación cartesiana de un pleo de diagramas en los que se visualiza de

hecho y sus dimensiones
forma clara la estructura física con la que se
va a diseñar el almacén.
DIMENSIÓN En la Figura 2 se observa un ejemplo sim-
ZONA ple de estos diagramas. Habitualmente, las
cajas incluidas en ellos se corresponden con
Nº Incidencias
las tablas del almacén, y cada línea en ella es-
crita se corresponde con una columna de di-
DIMENSIÓN
cha tabla. De este modo, la tabla naranja (lla-
TIEMPO
mada, en el argot, "tabla de hechos")
DIMENSIÓN almacena los hechos mensurables (num_inc:
SERVICIOS
número de incidencias recibidas; num_avisos:
número de avisos; inc_res: incidencias resuel-
tas; inc_pdt: incidencias pendientes) por cada
ejes recibirían el nombre de variables cuali- día (cod_dia), zona (cod_zona) y ser vicio
tativas. (cod_servicio).
Los hechos son las variables de negocio Las líneas existentes entre cajas se deno-
(ventas, costes, consumos, tiempos, etc.) so- minan uniones (joins) entre tablas, e indican
bre los que se va a totalizar, promediar, y en que la tabla de hechos contiene información
general, realizar operaciones de agregación analizable por la dimensión a la que se une.
que conduzcan a conclusiones sobre la evo- Estas variables especificadas con el prefijo
lución del área o departamento que se estu- “cod_” constituyen códigos únicos en sus res-
die. La denominación estadística de dichas pectivas dimensiones. Es decir, son codificadas
variables de negocio sería la de variables de tal forma que un código de zona, por ejem-
cuantitativas. plo, no sea compartido por dos zonas.
La Figura 1 representa gráficamente el
hecho, el número de incidencias, como un Indicadores y jerarquías
punto de mayor o menor grosor en fun- Jerarquías
ción de cuántas se hayan producido. Su si- Si se observa las dimensiones de la Figura
tuación respecto a los tres ejes representa 2, se aprecia con claridad la existencia de je-
gráficamente los valores codificados de zo- rarquías dentro de las mismas. Una jerarquía
na, ser vicio y tiempo para los que se han es un orden determinado dentro de las va-
producido dichas incidencias. riables o atributos de una dimensión.
Esta forma de representación gráfica no se Estas jerarquías son utilizadas a la hora de
usa habitualmente, puesto que limita las di- agregar (navegación ascendente, drill up) o
mensiones a tres. Sí que es frecuente el em- desagregar (navegación descendente, drill
down) la información.
Figura 2. Representación del modelo lógico de datos Para el modelo que nos ocupa, las jerarquías
naturales serían las siguientes:
•Tiempo: año (desc_año) → trimestre
ZONA
(desc_trimestre) → mes (desc_mes) → día
cod_zona
(desc_dia).
desc_zona
•Zona: comunidad autónoma (desc_ccaa) →
desc_provincia
provincia (desc_provincia)→ zona
desc_ccaa
(desc_zona).
•Ser vicio: responsable → ser vicio
(desc_servicio).
cod_dia Es destacable el hecho de que cada una de
TIEMPO
SERVICIO cod_servicio estas jerarquías contiene sus atributos en
cod_dia
cod_servicio cod_zona una única tabla. Este tipo de modelización,
desc_dia
desc_servicio num_inc denominada “en estrella” (star schema de-
desc_mes
responsable num_avisos sign), toma las dimensiones como puntas de
desc_trimestre
inc_res la estrella, y la tabla de hechos como centro
desc_año
inc_pdt de dicha estrella. El diseño en estrella es óp-
timo para agilizar las consultas, pues se mini-
miza el número de tablas sobre las que con-
sultar la información.

44 anales de mecánica y electricidad / marzo-abril 2009

42-47_almacendedatos.qxd:Maquetación 1 28/4/09 13:23 Página 45

Figura 3. Representación de un modelo en copo de nieve

ZONA
cod_zona
desc_zona
MES
desc_provincia
cod_mes
desc_ccaa
desc_mes
desc_trimestre
desc_año

cod_dia
cod_servicio T
SERVICIO DIA
cod_zona I
cod_servicio cod_dia
num_inc E
desc_servicio desc_día
num_avisos M
responsable desc_mes
inc_res P
inc_pdt O

cod_mes
cod_servicio
cod_zona
presupuesto

Existe otra forma de modelizar, denomina- Indicadores

da “en copo de nieve” (snowflake schema de-
sign), que se emplea menos frecuentemente.
Este modelo se caracteriza por que alguna
de sus dimensiones tiene atributos distribui-
dos en más de una tabla.
Siguiendo con el ejemplo que nos ocupa,
imaginemos que se desease analizar las inci-
dencias y avisos en relación al presupuesto
de cada servicio. Si el dato presupuestario
sólo puede ser obtenido mensualmente, el
modelo de datos expuesto anteriormente
debería ser rediseñado como aparece en la
Figura 3.
Esta modelización tiene los atributos de la
dimensión tiempo distribuidos entre las ta-
blas MES y DIA. Aunque es más sencilla des-
de el punto de vista de aprovisionamiento,
representa un serio obstáculo a las posibili-
dades de consulta de datos, pues introduce
dos contextos de cálculo separados. Por ello,
es conveniente buscar una forma de llevar
todos los hechos que se consideran en el
modelo a un nivel de desagregación común
(es lo que se denomina “granularidad de la
tabla de hechos”), de tal forma que, como en
la Figura 2, los hechos sean almacenables en
una única tabla. En este caso, lo mejor sería
encontrar un criterio razonable de reparto
del presupuesto para cada día del mes.
Los indicadores se construyen a partir de
las variables cuantitativas que se almacenan
en las tablas de hechos. Es frecuente que és-
tas sean analizadas mediante el uso de esta-
dísticos descriptivos tales como la suma, la
media, la desviación típica, la mediana, etc. A
la expresión que resulta de emplear un ope-
rador estadístico o de sumarización en estas
variables se le denomina métrica o indicador.
El modelo de la Figura 2 permite construir
diferentes indicadores del área de Resolu-
ción de Incidencias, tales como:
1.1 .Nº incidencias recibidas diarias.
1.2. Nº incidencias resueltas diarias.
1.3. Nº incidencias pendientes diarias.
1.4. % de actividad diario, definido como: nº
incidencias resueltas diarias * 100 / nº inci-
dencias recibidas diarias.
Los tres primeros indicadores son el resul-
tado de utilizar un operador de suma sobre
las variables respectivas de la tabla de he-
chos. El cuarto indicador también compon-
dría su fórmula con dicho operador de su-
ma, pero se deberían definir reglas de
agregación específicas cuando la información
no se desagregara por servicio, día y zona.
Precisamente, cuando no existe un único
operador de agregación válido para cualquier
combinación de atributos de las dimensiones,

Introducción a los almacenes de datos 45

42-47_almacendedatos.qxd:Maquetación 1 28/4/09 13:23 Página 46

Tabla 1. Enero 2009: cuadro resumen de zonas principales varias dimensiones y agilizan, por tanto, las
consultas al almacén. En nuestro ejemplo, el
Zona Nº incidencias recibidas Nº incidencias resueltas % actividad
indicador % de actividad podría almacenarse
Madrid-Retiro 325 100 30,77 agregado por mes si la Tabla 2 fuese un infor-
Madrid-Atocha 250 150 60,00 me muy demandado por los usuarios y/o el
Bcn-Ciutat Vella 200 125 62,5 volumen mensual de nuestra tabla de he-
Bcn-Poble Nou 300 100 33,33 chos inicial (por día, zona y servicio) fuera
del orden de millones de registros, se conse-
se habla de indicador no agregable. En este guiría una “compresión” aproximada de 1/30,
caso, sería mejor catalogarlo como semia- por lo que la creación de una tabla agregada
gregable, pues si bien el operador suma da- valdría mucho la pena.
ría un resultado correcto agregando por zo-
na o por ser vicio, por tiempo sería lógico Herramientas de análisis y consulta
utilizar un operador promedio. Para obtener resultados tabulares como
De este modo, la Tabla 1 utilizaría, para la los representados en las Tablas 1 y 2, u obte-
fórmula: suma (nº incidencias resueltas dia- ner resultados gráficos, existen actualmente
rias) * 100 / suma (nº incidencias recibidas en el mercado numerosas herramientas que
diarias), mientras que la tabla 2 emplearía la simplifican la labor al usuario en dos direc-
fórmula: promedio (nº incidencias resueltas ciones:
diarias) * 100 / promedio (nº incidencias reci- •Construyen objetos de consulta manipula-
bidas diarias). bles en un panel de consulta (atributos de
Obsérvese que el indicador 1.3 también dimensión, indicadores, filtros), de tal modo
es semiagregable en la dimensión tiempo, que cualquier usuario puede, en modo con-
porque no sirve con aplicarle simplemente currente, emplearlos mediante acciones de
un operador suma. Cuando se quiere saber arrastrar y soltar (drag and drop) para cons-
el número de incidencias pendientes para truir sus propios informes.
toda España en enero de 2009, es preciso •Dichos objetos son reutilizables y su com-
calcular el valor de las incidencias pendientes binación genera, de forma automática y
para toda zona y servicio el último día de transparente para el usuario, el código SQL
ese mes (es decir, el 31), y será este valor el (lenguaje de consulta de base de datos) que
que se sumarice. Es un problema análogo al se ha de ejecutar para extraer la información
que se puede tener para calcular los kg de del almacén.
producto semiterminado en una fábrica, o Estas herramientas están pensadas para
las existencias del almacén. satisfacer las necesidades de la gran mayoría
Hay situaciones, como la que plantea el in- de usuarios. Permiten navegar dentro del in-
dicador 1.4, en que a la dificultad de estable- forme, desagregando una o varias de las di-
cer un operador de sumarización único se mensiones, construir totales, implementar
une un volumen de registros considerable fórmulas que combinen indicadores, etc.
(es el caso de entidades financieras u opera- Por otro lado, suelen estar construidas de tal
dores de teléfono, que pueden registrar mu- modo que permiten su empleo por dos vías:
chos millones de transacciones en sus siste- •Cliente pesado (heavy client) o arquitectu-
mas operacionales). Para este tipo de ra 2 capas: denominada de este modo por-
situaciones suele plantearse la construcción que la aplicación está instalada en el PC del
de las llamadas tablas agregadas, que almace- usuario, y es éste quien ejecuta directamen-
nan la información sumarizada para una o te, desde su aplicación, las consultas al al-
macén.
•Cliente ligero (thin client) o arquitectura 3
Tabla 2. Semestre 2008: cuadro resumen de provincias principales
capas: el usuario emplea la aplicación me-
PROV ENE FEB MAR ABR MAY JUN diante un navegador web que abre sesión en
% act. % act. % act. % act. % act. % act. el servidor donde se encuentra instalada la
herramienta. Es por tanto el servidor quien
Madrid 63,50 62,25 67,13 64,28 61,12 60,57 soporta el proceso de creación de la consul-
ta y quien la envía y descarga los resultados
Barcelona 59,24 64,91 68,11 60,19 50,56 42,88
desde el almacén.
Sevilla 60,01 62,37 58,64 59,23 65,48 58,21
Un diagrama representativo de estos dos
Valencia 58,32 57,49 61,15 63,61 60,98 58,01 modos de funcionamiento se encuentra en
la figura 4.

46 anales de mecánica y electricidad / marzo-abril 2009

42-47_almacendedatos.qxd:Maquetación 1 28/4/09
Figura 4. Cliente pesado y cliente ligero
USUARIO
SERVIDOR WEB
Cliente pesado
Existe otro tipo de usuarios, menos fre-
cuentes y de perfil más analítico, que utilizan
técnicas de investigación operativa y estadísti-
ca avanzada con los datos del almacén (como
la segmentación, la regresión logística o los ár-
boles de decisión, por citar algunos). Este tipo
de análisis se denomina minería de datos (da-
ta mining), puesto que, por lo general, preten-
de extraer de los datos patrones ocultos que
permitan una mejora sustancial de la eficiencia
en el área analizada. Para estos usuarios tam-
bién existen paquetes de software específicos
(siempre con arquitectura cliente-servidor),
cuyo uso a pleno rendimiento requiere de
una buena base matemática y estadística.
Perspectivas de futuro
Los almacenes de datos están bastante
desarrollados en sectores como el financie-
ro, el de telecomunicaciones, el de retail y
el energético. Son sectores en los que el
volumen de transacciones, y la informatiza-
ción de las mismas, favorece en gran medi-
da su construcción; además, su uso para in-
formes corporativos y, en menor medida,
en minería de datos, ha agilizado el repor-
ting corporativo en el primer caso y una
mejora de la eficiencia en el segundo.
Los almacenes de datos son –o han sido,
cabría mejor decir- el primer estadio de un
concepto más amplio denominado Inteligen-
cia de Negocio (Business Intelligence). La idea
que subyace detrás de este término es la de
aprovechar el flujo de datos que existe en
cualquier empresa para, mediante su captura
y análisis, tomar medidas y acciones que me-
joren la eficiencia y la rentabilidad de la mis-
ma. A par tir de la Inteligencia de Negocio
13:23 Página 47
SERVIDOR HERRAMIENTA
ALMACÉN DE DATOS
Cliente ligero
surgen otros conceptos como BPM (Business
Performance Management) o CPM (Corporate
Performance Management), que introducen
ciertas diferencias con el original, pero que
concuerdan, en cuanto al fin último, con el
anteriormente descrito.
La Inteligencia de Negocio es un concepto
relativamente nuevo (menos de 10 años de
vida), y por tanto aún tiene un recorrido
muy interesante. Lo usual es que su implan-
tación en cualquier compañía se sustente so-
bre un almacén de datos, aunque hay quien
sostiene que la tecnología posibilita ya acce-
der a la información de los diferentes siste-
mas sin necesidad de almacén intermedio.
Sea como fuere, en mi opinión hay dos prin-
cipios inherentes a la Inteligencia de Negocio
que son imprescindibles para su éxito en
cualquier empresa:
•Tiene que implicar un cambio cultural en la
organización.
•Todos los trabajadores pueden beneficiarse
de su implantación.
Las reglas y técnicas de construcción de
un almacén están en la actualidad muy con-
solidadas, y existe bibliografía en el mercado
para ponerlas en práctica correctamente. Sin
embargo, la Inteligencia de Negocio, repre-
sentada por los dos puntos que acabo de
enunciar, permanece sin desarrollarse en ple-
nitud.
Creo que será su puesta en práctica en los
próximos años, urgidos por la crisis econó-
mica presente y la necesidad de aumentar la
productividad en todas las organizaciones, lo
que favorecerá una mayor implantación de
los almacenes de datos, y un uso más intensi-
vo de los mismos.
Introducción a los almacenes de datos 47