Base de Datos Trujillo Index

DISEO Y EXPLOTACIN DE
ALMACENES DE DATOS
Conceptos Bsicos de Modelado Multidimensional
ECU
Juan Carlos Trujillo

Jos Norberto Mazn
Jess Pardillo
Trujillo, Juan Carlos. Diseo y explotacin de almacenes de datos: conceptos bsicos de modelado multidimensional.
: ECU, . p 1
http://site.ebrary.com/id/10751536?ppg=1
Copyright ECU. . All rights reserved.
May not be reproduced in any form without permission from the publisher,
except fair uses permitted under U.S. or applicable copyright law.
Diseo y explotacin de almacenes de datos. Conceptos bsicos de modelado multidimensional

Juan Carlos Trujillo Mondjar
Jos Norberto Mozn Lpez
Jess Pardillo Vela
ISBN: 978-84-9948-546-1
e-book v.1.0
ISBN edicin en Papel: 978-84-8454-902-4
Edita: Editorial Club Universitario. Telf.: 96 567 61 33

Cf. Cottolengo, 25 San Vicente (Alicante)
www.ecu.fm
Maqueta y diseo: Gamma. Telf.: 965 67 19 87
Cf. Cottolengo, 25 San Vicente (Alicante)
www.gamma.frn
gamina@garnma.fm
Reservados todos los derechos. Ni la totalidad ni parte de este libro puede reproducirse o
transmitirse por ningn procedimiento electrnico o mecnico, incluyendo fotocopia, grabacin
magntica o cualquier almacenamiento de informacin o siste ma de reproduccin, sin permiso
previo y por escrito de los titulares del Copyright.
: ECU, . p 2
ndice general
ndice general
iii
1. Introduccin
1.1. La tecnologa de bases de datos

1.2. Las nuevas necesidades de gestin de datos
1.3. Historia de las soluciones informticas a datos histricos
1.4. El almacn de datos: una primera aproximacin
1.5. Historia de las aplicaciones OLAP
1.6. Sistemas analticos contra transaccionales
2. Arquitectura
2.1. Arquitectura general de almacenes de datos

2.2. Las fuentes de datos operacionales
2.3. Los procesos ETL
2.3.1. Extraccin
2.3.2. Transformacin o limpieza
2.3.3. Carga
2.3.4. Herramientas para procesos ETL
2.4. El almacn de datos
2.4.1. Almacenes de datos departamentales o data mar ts
2.5. Los metadatos
2.6. Servidores de bases de datos y consulta
2.7. Las herramientas de consulta
2.8. Aproximaciones metodolgicas para el diseo de almacenes de datos
3. Modelado Multidimensional
3.1. Modelado multidimensional conceptual

3.1.1. Propiedades multidimensionales estructurales
3.1.2. Propiedades multidimensionales dinmicas
3.2. Modelado multidimensional lgico
3.2.1. Esquema estrella
3.2.2. Esquema de constelaciones de hechos
3.2.3. Esquema de copo de nieve
3.2.4. Resumen de los diferentes esquemas
3.2.5. La dimensin tiempo
3.2.6. Otras consideraciones de diseo
1
2
4
6
8
9
13
14
15
16
16
16
17
19
19
19
20
21
22
22
27
28
29
32
33
34
41
42
43
44
45
III
: ECU, . p 3
Iv
4. Procesos ETL
4.1. Introduccin
4.2. Pase de extraccin
4.3. Fase de transformacin
4.4. Fase de carga
4.5. Elementos principales de diseo
5. Herramientas de explotacin OLAP
5.1. Qu es OLAP"
5.2. Arquitectura
5.3. Vendedores OLAP
6. Herramientas de minera de datos
6.1. Motivacin
6.2. Qu es la minera de datos?
6.3. Aplicaciones y tcnicas
6.4. El proceso de descubrimiento de conocimiento
7. Metadatos en almacenes de datos
7.1. Introduccin
7.2. Metadatos de procesos ETL
7.3. Metadatos de usuarios finales
7.4. Metadatos del almacn de datos
Indice general
51
51
53
55
60
65
69
69
72
73
81
81
82
83
85
91
91
93
94
94
A. Aplicaciones de almacenes de datos en el mercado
101
indice alfabtico
103
: ECU, . p 4
Prlogo
Diseo y explotacin de almacenes de datos: conceptos bsicos y modelado multidimensional

se presenta como un libro que introduce aspectos bsicos del modelado multidimensional y del
diseo de los almacenes de datos, y que pretende ser un instrumento til para los estudiantes
de grado y postgrado de las Titulaciones de Informtica y de los profesionales del desarrollo de
almacenes de datos. En este sentido, el libro pretende cubrir un hueco existente hasta ahora en
la literatura y proporcionar un manual en castellano que recoja y ponga en orden los conceptos
bsicos para acometer con garantas el diseo y explotacin de almacenes de datos.
En el ao 2002, propongo a travs del Dpto. de Lenguajes y Sistemas Informticos (DLSI) de
la Universidad de Alicante la asignatura Bases de Datos Multidimensionales como asignatura
optativa de las tres Titulaciones de Informtica. Desde sus orgenes y hasta la actualidad, los
alumnos han demandado ao tras ao, un material (en castellano a ser posible) donde se recogieran los aspectos bsicos del diseo de las bases de datos multidimensionales, almacenes de
datos y las herramientas de consulta ms utilizadas para su correcta explotacin.
Esta demanda tambin se produce en la asignatura Diseo y Explotacin de Almacenes de
Datos del Programa de Tercer Ciclo Aplicaciones de la Informtica del DLSI impartida en la
Universidad de Alicante y del Mster en Informtica que se imparte en la Escuela Politcnica
Superior desde 2009. Adems, dicha asignatura tambin se oferta en el Programa de Tercer Ciclo
que el DLSI imparte en universidades extranjeras como la Universidad de Matanzas "Camilo
Cienfuegos" o la Universidad de la Habana en Cuba, Universidad Latina en Costa Rica y la
Universidad de la Frontera en Temuco (Chile).
Estas experiencias docentes heterogneas tanto en contenido como en alumnado, me han
permitido obtener una retroalimentacin valiosa a la hora de preparar este libro, que pretende
ser claro y conciso adems de verstil. Adems, tengo el placer de compartir la escritura de
este texto con dos ex-alumnos que me "sufrieron" de profesor en los inicios de esta asignatura y
que, con en el paso de los aos, se incorporaron como investigadores al Grupo de Investigacin
Lucentia (http: //www.lucentia. es) desde sus orgenes, siendo en la actualidad dos miembros
fundamentales de dicho grupo. Jos Norberto Mazn defendi su tesis doctoral (A model-driven
approach for the multidimensional designa of data warehouses) el pasado 15 de diciembre de 2008
y, Jess Pardillo se encuentra en la fase final de la suya y, que esperamos defender en el curso
acadmico 2009/10. Cunto camino hemos recorrido ya y cunto ms nos queda por recorrer!
Por otro lado, en los proyectos privados con las empresas con las que hemos colaborado,
hemos detectado en muchas ocasiones una falta de conceptos y criterios bsicos para abordar el
diseo de almacenes de datos. Esto es quizs una consecuencia de que las empresas que ofertan
sistemas de gestin y mantenimiento de almacenes de datos ofrecen productos (comerciales o
de cdigo abierto) para acometer el diseo de almacenes de datos desde su perspectiva lgica,
obviando las importantes fases de anlisis de requisitos y diseo conceptual, con lo que muchos
: ECU, . p 5
VI
Indice general
conceptos necesarios se obvian y, por tanto, se obtienen diseos errneos y poco funcionales con
el consiguiente gasto aadido en recursos de todo tipo (humanos, tcnicos, tecnolgicos, etc.).
Por todo ello, este libro nace con la ilusin de ser el primero de una serie de textos que
pretenden cubrir un hueco en la literatura actual proporcionando aspectos bsicos del diseo
y explotacin de almacenes de datos. Actualmente estamos preparando (I) un texto centrado
en aspectos de implementacin con plataformas concretas y, (II) otro texto que presenta la
metodologa propia desarrollada en el seno del Grupo Lucentia que permite acometer el diseo
de almacenes de datos de forma automtica desde la fase de anlisis de requisitos hasta la
implementacin final utilizando MDA (Model Driven Arehileciure) y UML (Uni ed Modeling
Language). Adems, este mtodo est soportado por una herramienta de diseo basada en
el entorno de desarrollo ECLIPSE que permite acometer el diseo de los almacenes de datos
desde etapas tempranas de desarrollo. Este ltimo texto, sin embargo, estar ms enfocado a
profesionales de la Informtica y alumnos del Tercer Ciclo.
Por ltimo, quisiera agradecer personalmente a los dos co-autores del libro por su apoyo
durante estos ltimos aos y a todos los miembros del Grupo de Investigacin Lucentia (frene
Garrigs, Lilia Muoz, Sergio Lujn, Rafael Romero, Jos Jacobo Zubco Octavio Glorio y
Emilio Soler). No quisiera despedirme sin mostrar mi agradecimiento a todos los miembros del
Dpto. de Lenguajes y Sistemas Informticos de la Universidad de Alicante, por todo el apoyo
que siempre han mostrado hacia nuestro grupo y las actividades que desarrollamos.

Alicante, a 15 de junio de 2009
: ECU, . p 6
Prefacio
Este libro se centra en proporcionar los conceptos y aspectos bsicos necesarios para acometer el diseo y explotacin de almacenes de datos. Tal y como se dejar patente a lo largo
del libro, estos sistemas presentan peculiaridades y aspectos propios que los diferencian de los
sistemas transaccionales y, por tanto, demandan mtodos, modelos y herramientas distintas de
las utilizadas en el diseo y explotacin de los sistemas transaccionales.
Por ello, el libro comienza con el Captulo 1 de Introduccin, cuyo objetivo fundamental es
reflexionar sobre los sistemas transaccionales y su inconveniencia para ser utilizados para la
toma de decisiones estratgicas en el entorno empresarial. Adems, en este captulo se hace una
primera aproximacin a los almacenes de datos y sus objetivos y, lo ms importante, se finaliza
el captulo con una comparativa entre los sistemas transaccionales y los almacenes de datos
para enfatizar las diferencias entre ambos. Por otro lado, se introduce el modelado o paradigma
multidimensional como la aproximacin de modelado ampliamente utilizada para estos sistemas.
Por ltimo, estas diferencias son suficientes para justificar los modelos y mtodos particulares
necesarios para acometer con xito su diseo y, adems, justifican el resto de captulos del libro.
En el Captulo 2, se presenta de manera general todos los componentes fundamentales de una
arquitectura bsica de almacenes de datos y, cmo interactan entre ellos. Al ser ste un texto
de introduccin de conceptos bsicos, hemos evitado hacer alusin a arquitecturas de almacenes
de datos de nueva generacin como son los almacenes de datos espaciales, biomdicos, sociales
o de flujo continuo de datos.
En el Captulo 3, se aborda la parte central del libro: el paradigma o modelado multidimensional. En una primera parte, se presenta el modelado multidimensional a nivel conceptual. Sin
embargo, como en la actualidad no existe ninguna propuesta estndar ampliamente aceptada
para acometer esta fase de diseo, se presentan los conceptos imprescindibles para acometer con
xito el diseo de estos sistemas como son los niveles de jerarquas, la aditividad, la cardinalidad entre relaciones, etc. Si estos conceptos no se recogen de alguna forma desde las etapas
tempranas de desarrollo, lo ms probable es que el diseo final del almacn de datos sea errneo.
En la segunda parte, se hace hincapi en cmo representar los conceptos recogidos en la
fase anterior en un modelo multidimensional lgico. Como nos centramos principalemente en
plataformas relacionales, utilizamos como base el esquema estrella y sus variantes. Una vez
llegado a este punto, el alumno y profesional estar en disposicin de realizar el diseo lgico de
un almacn de datos desde su perspectiva lgica utilizando cualquier plataforma del mercado.
En el Captulo 4, se describen los aspectos fundamentales de los cruciales procesos ETL
(Extraction, Transformation, and Loeding, extraccin, transformacin y carga). Estos procesos
son los encargados de extraer los datos de las diversas y heterogneas fuentes de datos, realizar
las transformaciones necesarias y cargar los datos en las estructuras lgicas del almacn definidas
en el captulo anterior. En la actualidad, un $O por ciento del esfuerzo total dedicado al diseo
de los almacenes de datos se dedica a estos procesos.
VII
: ECU, . p 7
VIII
Indice general
En el Captulo 5, se describen las herramientas de consulta ms habituales en este tipo de

sistemas: las herramientas OLAP (Ora-Line Analytical Processing, procesamiento analtico en
lnea). Estas herramientas presentan un conjunto comn de operaciones que se ejecutan sobre
el modelo multidimensional definido en la fase anterior y que permiten al analista obtener los
datos adecuados para la toma de decisiones.
En el Captulo 6, se introducen las herramientas de minera de datos. Mientras que las herramientas OLAP presentan los datos despus de ejecutar consultas contra el almacn de datos, las herramientas de minera de datos, ejecutan algoritmos sobre los datos existentes con
el fin de encontrar patrones y tendencias ocultas en los datos y de alguna forma, predecir que
puede suceder en un futuro en base a los datos actuales. Este captulo clarifica la diferencia
entre estas herramientas y las herramientas OLAP, ya que a menudo se suelen confundir sus
funcionalidades.
En el Captulo 7, se presentan los metadatos de una arquitectura de almacenes de datos. Los
metadatos son importantes en cualquier aplicacin, sin embargo, cobran especial importancia en
los sistemas de almacenes de datos dada la complejidad de los mismos; ya que se ha de guardar
no solo informacin de los usuarios y los datos en s sino, por ejemplo, de las transformaciones
sufridas por los mismos antes de ser cargados en el almacn.
Para finalizar y, tal y como se ha comentado en el prlogo, este libro pretende ser el primero
de una serie de textos con los que se desea abordar el diseo y explotacin de almacenes de
datos. Adems, deseamos orientar los a los alumnos de las Titulaciones de Grado y Posgrado
de Informtica y a los profesionales de los almacenes de datos. Por ello, se intenta por todos los
medios que sea un libro accesible a todo el pblico.

Jos Norberto Mazn
Jess Pardillo
Alicante, a 15 de Junio de 2009
: ECU, . p 8
Un viaje de miles de kilmetros empieza con

un solo paso.
Lac-Tsu
Introduccin
OMENZAREMOS nuestro estudio de los almacenes de datos repasando brevemente la tecnologa

actual de las bases de datos, haciendo hincapi en los sistemas transaccionales. A continuacin,
se expondrn las nuevas necesidades de gestin de datos dentro del contexto empresarial y de
globalizacin en el que se desenvuelven las empresas. Tras ello, se introducirn los almacenes
de datos realizando una primera aproximacin a este tipo de sistemas. El captulo finalizar
discutiendo las diferencias entre los sistemas transaccionales y los de almacenes de datos para
clarificar an ms la razn de existencia de los almacenes de datos.
Indice

Desde los primeros sistemas de gestin de ficheros all por los aos 70 hasta los SGBD
(Sistema de gestin de bases de datos) actuales, la tecnologa de bases de datos ha evolucionado
hasta disponer en la actualidad de SGBD robustos, eficientes y con un amplio espectro de
herramientas de alto nivel que facilitan su manejo y gestin tanto desde la perspectiva del
servidor como de la de cliente.
: ECU, . p 9
Captulo 1. Introduccin
En la actualidad, podramos decir que aproximadamente el 90 % de los SGBD implantados

son relacionales, obteniendo as las ventajas inherentes del modelo relacional subyacente a tales
sistemas, tales como la integridad de los datos o independencia de los datos y las aplicaciones.
Obviamente, en el mercado tambin se dan otros SGBD como, por ejemplo, los SGBD en red,
jerrquicos, 00 (Orientado u orientacin a objetos) o los objeto-relacionales. Los dos primeros
solemos encontrarlos en entornos bancarios donde todava los mainfmmes y hosts de los aos
ochenta siguen albergando una gran cantidad de datos confidenciales consecuencia de llevar
varias dcadas operativos. Sin embargo, en tales sistemas, las empresas llevan ya algn tiempo
optando por una de estas dos alternativas:
La migracin paulatina de estos sistemas a SGBDR (SGBD relacional) basados en arquitecturas cliente-servidor, o bien,
La construccin de una serie de herramientas de gestin y clientes que se conectan a tales
sistemas y con interfaces que facilitan la interaccin.
En general, los sistemas 00 se encuentran en contextos donde es necesario tratar con tipos
de datos ms complejos, como en bases de datos multimedia, sistemas CAD/CAM (ComputerAided Design/Computer-Aided Manufacturing), etc.
Otra forma de referirse conjuntamente a los SGBD mencionados es la de sistemas tradicionales o transaccionales. La razn de ello es que estos SGBD estn orientados a satisfacer
las necesidades diarias de datos de la empresa, y por ello, estn enfocados a procesar un gran
nmero de transacciones fruto de la actividad diaria de la empresa, como pueda ser: la compra
de productos, la venta de propiedades, el servicio de transporte, etc. A tales sistemas se les suele
denominar OLTP (Ora-Line Transaction Processing, procesamiento transaccional en lnea).
Cuando en tales sistemas se decide que ciertos datos no se utilizan con suficiente frecuencia,
estos se catalogan como histricos y se suelen depositar en almacenamientos externos como
discos duros dedicados o cintas magnticas. Como ejemplo de este tipo de datos tenemos: los
datos econmicos de ejercicios o trimestres anteriores, los clientes dados de baja o los productos
devueltos a los proveedores por defectos detectados.

Dentro de un contexto econmico-empresarial, los analistas econmicos coinciden en que asistimos a un fenmeno definido como globalizacin de la economa. Este fenmeno se ha visto
notablemente influenciado por las TIC (Tecnologas de la Informacin y Comunicacin), que
proporcionan una gran cantidad de informacin y contribuyen a disminuir las barreras fsicas
entre mercados, y consecuentemente, entre empresas. Por lo tanto, las empresas se enfrentan a
entornos ms hostiles con un elevado ndice de competencia. En esta situacin, es imprescindible adoptar decisiones estratgicas que proporcionen a una empresa ventajas competitivas con
respecto a sus rivales.
Independientemente del contexto en el que una empresa opere, en el cuadro 1.1 se exponen una
serie de preguntas que bien podran ser cuestiones formuladas por los responsables de adoptar
decisiones estratgicas en un entorno empresarial. Estas cuestiones pueden servir para introducir
al experto en TIC al punto de vista del analista de informacin o del responsable de la toma
de decisiones en la empresa.
: ECU, . p 10
Cuntos zapatos del 41 de color rojo se vendieron el ltimo mes en la zona norte, este y
sur; comparados con las ventas del mismo mes el ao pasado?
Qu tipo de cliente me ha estado comprando el BMW 3201 durante los ltimos 10 aos?
Directivo, profesor, trabajador escala bsica, etc.?
Ha variado un cliente sus gustos de compra de vehculos? Ha estado comprando el mismo

vehculo de soltero que de casado?
Cules son las 25 primeras marcas, por productos, estilos y regiones de Espaa clasificadas
por el margen de ventas en ?
Cul fue el presupuesto gastado en promociones en clientes que luego hicieron compras
inferiores a 100C?
Qu descuento deberamos ofrecer para incrementar significativamente las ventas?

El producto de tipo A se ha vendido mucho ms que el producto de tipo B. Encontrar
patrones de correlacin entre esos tipos de productos y extraer similitudes y diferencias.
Cules son las tendencias en mis ventas?
Cuadro 1.1.: Tpicas cuestiones estratgicas para tomar decisiones en un negocio
Tal y como se puede concluir de las preguntas formuladas en el Cuadro 1.1, las decisiones
estratgicas requieren una gran cantidad de informacin, normalmente informacin histrica,
procedente de distintas fuentes, que permita al analista descubrir fenmenos y tendencias escondidos en los datos. En este contexto, es fundamental que tal informacin sea proporcionada
al analista de una forma rpida y sencilla, y sobre todo, en una interfaz fcil de utilizar por
el no experto en TIC. Los sistemas de apoyo para la toma de decisiones han experimentado
un gran auge desde los aos ochenta ya que son capaces de proporcionar una gran cantidad de
informacin en un formato fcil de interpretar por el analista. Sin embargo, el problema que
tenan estos sistemas hasta principios de los noventa era poder disponer de informacin histrica
de una forma unificada, compacta y coherente.
En este punto cabra formularse una cuestin: son vlidos los sistemas OLTP para tales
decisiones? La respuesta a esta pregunta debera ser el punto de partida para saber si, o bien
escalando, o bien actualizando los actuales OLTP, se podran satisfacer tales requerimientos;
o si por el contrario, necesitamos otro tipo de sistema. Aportando algunas razones, en primer
lugar, los datos histricos no estn (o no deberan estar) disponibles en los sistemas OLTP.
Si analizamos brevemente las preguntas del cuadro 1.1, se puede ver que la mayora de las
preguntas requieren datos que residen en distintas fuentes de datos de la empresa. Por ejemplo,
los datos de proveedores residirn en la base de datos de proveedores, mientras que los de clientes
y productos residirn en la base de datos de ventas.
As que, tal y como vemos, una caracterstica comn a tales preguntas es que se necesitan
datos de varias fuentes o bases de datos (algunos de ellos no disponibles al ser histricos) y que
integrar tales datos en tiempo real no solo consumira una gran cantidad de recursos, sino que
sera prcticamente inviable. Por otro lado, los analistas del negocio no entienden de tablas,
: ECU, . p 11
columnas, etc. Necesitan entornos de consulta especficos en el que se manejen trminos de

negocio ms prximos a las cuestiones que se formulan. Estas son solo algunas caractersticas
que podramos citar para concluir que los sistemas OLTP no son adecuados para proporcionar
datos en la respuesta a preguntas estratgicas.
1.3. Historia de las soluciones informticas a datos

histricos
Sin embargo, las decisiones estratgicas existen desde que una persona emprendedora decide
realizar una actividad o profesin por cuenta propia. As que vamos a repasar brevemente las
soluciones tecnolgicas que se han ido proporcionando a lo largo de la historia para manejar
tales datos histricos y ponerlos a disposicin del analista de informacin.
Datos procedentes de sistemas heredados

Es durante los aos 70 cuando se extiende el uso de los grandes mainfrarnes o hosts de
IBM. Estos sistemas albergaban los datos en el SGBD DB2 de IBM, disponiendo de rutinas
escritas fundamentalmente en lenguajes como COBOL, CICS o IMS. En los aos ochenta,
se extiende el uso de plataformas AS/400 y del VAX/VMSR. En estos AS/400, el principal
problema radicaba en que los datos estaban embebidos junto con las aplicaciones (no disponan
de la propiedad de independencia de aplicaciones y datos) y, para acceder a ellos, se tena que
disponer del cdigo fuente de tales sistemas. Hoy en da, muchas aplicaciones de negocio se
ejecutan sobre estos sistemas, ya que durante muchos aos han estado recogiendo datos y reglas
de negocio, y resulta ms sencillo disear aplicaciones que se comuniquen con ellos que implantar
otro sistema. Generalmente, los datos se vuelcan en bibliotecas a las que otras aplicaciones de
negocio accedern. Sin embargo, el coste de estas aplicaciones de negocio es elevado, ya que se
trata de desarrollar aplicaciones totalmente personalizadas.
Datos extrados en el escritorio
Los aos noventa se conocen en trminos generales como la gran expansin de las aplicaciones de escritorio. El abaratamiento del hardware permitira que en cada puesto de trabajo
hubiese un PC (Personal Computer) para analizar datos. Con esto, se redujo la distancia entre
usuario final y programador, dado que se extiende el uso de herramientas sencillas de utilizar,
como hojas de clculo o herramientas de anlisis que, adems, el propio usuario final puede
personalizar en funcin del uso. As, aun disponiendo de los sistemas heredados (donde reside
el mayor volumen de datos de la empresa), estas herramientas de escritorio acceden a los datos
producidos por dichos sistemas heredados. El problema comn que suele generar esta forma de
proceder es que los datos tienden a permanecer fragmentados y estn orientados a necesidades
especficas de grupos de usuarios finales, presentando as soluciones parciales para estos, con la
problemtica aadida de que no todos los usuarios disponen de la destreza o tiempo suficientes
para personalizar tales aplicaciones.
: ECU, . p 12
Sistemas de apoyo para la toma de decisiones

Estos sistemas experimentaron un gran auge en los aos ochenta pues estaban orientados
a facilitar el anlisis de datos a los ejecutivos que, por normal general, no estaban dispuestos
a personalizar herramientas de escritorio como las hojas de clculo. En trminos generales,
podemos resumir que:
Los DSS (Decision Support System, sistema de apoyo a la decisin) ofrecen datos ms
detallados y estn ms orientados a los ejecutivos de la escala intermedia de una empresa.
Los BIS (Eze,cutive Information System, sistema de informacin para ejecutivos) ofrecen
datos ms consolidados y, en general, estn ms orientados a los ejecutivos de las altas
escalas de la empresa.
Estos sistemas poseen en comn que presentan los datos en una vista multidimensional; de
forma muy parecida a las rejillas tpicas de las hojas de clculo. A pesar de las diferencias de
partida, cada vez ms autores consideran que son herramientas similares y que incluso solapan
sus funciones, puesto que ambas se pueden orientar a obtener el mismo tipo de informes.
A continuacin, se resumen las caractersticas comunes a los DSS y EIS:
Presentan datos descritos en trminos propios del negocio, en lugar de trminos tcnicos
como tupla, fila o tabla. La principal razn es que tales sistemas estn enfocados a usuarios
no expertos en las TIC.
Los datos se preprocesan siguiendo patrones de reglas de negocio con las que las empresas
han estado trabajando y aplicando; como por ejemplo, los beneficios por la venta de
productos en distintos almacenes.
Ofrecen vistas consolidadas de los datos. Aunque, por supuesto, permiten ver datos en
detalle, rara vez pueden acceder a todos los datos en detalle dado el volumen de los mismos.
Por ello, suele ser mucho ms operativo la consulta de vistas consolidadas o resumidas.
En cierto sentido, DSS y EIS se consideran como los precursores de los almacenes de datos
dado su enfoque multidimensional en la presentacin de los datos para facilitar el anlisis de
la informacin al no experto de las TIC. Sin embargo, el gran inconveniente con el que se
enfrentaba una empresa era la considerable inversin necesaria para implantarlas y, sobre todo,
la descoordinacin existente entre todas las soluciones sobre los datos necesarios para efectuar
informes: cada solucin extraa los datos necesarios del servidor, sin tener en cuenta si la otra
solucin tambin los estaba extrayendo.
Como prembulo del siguiente epgrafe, podemos resumir que los almacenes de datos incorporan la filosofa de las herramientas analticas de datos de los sistemas precedentes: facilidad
de manejo, datos resumidos, capacidad de anlisis, etc. Sin embargo, tal y como veremos en el
siguiente punto, la gran ventaja que aportan los almacenes de datos es proporcionar una solucin
global de repositorio de datos a la empresa, en lugar de proporcionar soluciones parciales con
datos duplicados tal y como ocurra en las soluciones anteriores.
: ECU, . p 13

Antes de proporcionar la definicin tcnica y ms extendida, definiremos a los almacenes de
datos como sistemas que almacenan datos histricos para ser utilizados por los DSS para toma
de decisiones estratgicas. Dichos sistemas son eminentemente de consulta y estn enfocados a
extraer conocimiento de los datos histricos almacenados. Por ello, un almacn de datos no es una
base de datos en el sentido tradicional, donde cualquier aplicacin de usuario final puede realizar
inserciones, actualizaciones y borrados sobre la base de datos. Adelantamos que las herramientas
ms extendidas para realizar el anlisis de estos datos histricos son las herramientas OLAP
(On-Line Analytical Processing, procesamiento analtico en linea), basadas en el denominado
modelado o modelo multidimensional, que a su vez basa el anlisis en cubos, hipercubos y
tablas multidimensionales.
Desde su aparicin a principios de los noventa, an permanece invariable la definicin de
almacn de datos proporcionada por Bill Inmon, considerado uno de los pioneros o padres de
esta tecnologa, en los 90:
" Un (almacn de datos en una coleccin de datos orientados por tema, integrados,
variables en el tiempo y no voltiles que se emplea corno apoyo a la toma de
decisiones estratgicas".
Vamos a desglosar cada una de las partes importantes de esta definicin:
Orientados por tema. El diseo del almacn de datos est enfocado a responder eficientemente
a las consultas estratgicas y no a procesar un gran nmero de transacciones, como sucede

en el diseo de las bases de datos tradicionales o transaccionales. Por ello, el almacn de
datos est organizado de acuerdo con los temas ms importantes para la organizacin y,
por ende, para proporcionar respuestas a estas consultas estratgicas. Desde un punto de
vista intuitivo, se distinguen dos aspectos fundamentales:
Actividades de inters para el anlisis: compras de productos, ventas de vehculos,
alquileres, etc.
Contexto de anlisis para estas actividades de inters: clientes, vendedores, productos,
etc.
Nos permitimos aqu proporcionar la primera aproximacin al modelado o modelo multidimensional que, tal y como veremos a lo largo del libro, es la base para el diseo eficaz
de los almacenes de datos. El modelado multidimensional estructura su diseo en:
Hechos: que son las actividades de inters para la empresa.
Dimensiones: que son el contexto sobre el que se desea analizar estas actividades.
Integrados. Los datos proceden de distintas fuentes de datos, en general heterogneas, dentro de
la organizacin. Esta heterogeneidad de los datos hace que nos enfrentemos, por ejemplo,
a distintos formatos, definiciones o esquemas de bases de datos; con lo que un problema
fundamental al cargar los datos en el almacn de datos ser resolver estas diferencias y
almacenar datos coherentes y homogneos.
Variables en el tiempo. Los datos en el almacn de datos siempre se cargan con una referencia
temporal bajo la que son vlidos. Esta referencia puede ser puntual y concreta, es decir,
: ECU, . p 14

i~"----. .Producto 1.irtipo
.
Ventas
Alinacjn.
canuinidiul
- C-tinnurbi.tlad
11111
Amesmemme,rep~~
Albalera
Micanic
Elche
Sagunto
Valencia Cullera
Comii.1.11
"S pe nuerca do'

Bebida
Con,
1-resco
Refresco Alcohol
100
2011
300
4110
500
600
700
800
900
1000
1100
12{10
1300
1400
15410
1600
Figura 1.L: Tabla multidimensional producida por una posible herramienta OLAP
en un instante determinado, o ser vlidos en un intervalo de tiempo. La variacin con

respecto del tiempo se manifiesta tambin en el gran intervalo de tiempo durante el que
se almacenan los datos, en la asociacin implcita o explcita a la variable temporal, y en
el hecho de que los datos representan una serie de instantneas o intervalos.
No voltiles. Los datos no se insertan, actualizan, borran o refrescan en tiempo real, sino que se
refrescan de forma peridica a partir de las fuentes de datos operaciones. Los nuevos datos
se aaden siempre (o siendo ms realistas, en la mayora de las ocasiones como veremos)
para aumentar el repositorio de datos, en lugar de para sustituir los datos existentes. Tal
y como veremos ms adelante, ciertos procesos sern los encargados de poblar el almacn
de datos desde las fuentes de datos.
As, el objetivo de las tcnicas de almacenamiento de datos es ofrecer informacin histrica
para la toma de decisiones integrando la informacin procedente de distintas fuentes de datos
operacionales. En realidad, los almacenes de datos no son una tecnologa totalmente nueva, sino
que integran eficientemente tecnologa de bases de datos con anlisis de datos: en cuanto a las
bases de datos, utilizan un SGBD que alberga el repositorio del almacn de datos; con respecto
al anlisis de datos, proporcionan herramientas que permitan llevar a cabo de manera sencilla el
anlisis en linea. Las herramientas de anlisis ms conocidas son las herramientas OLAP, que
estn basadas en el anlisis multidimensional de los datos.
Veamos en este punto un ejemplo sencillo de consulta que se podra formular a un almacn
de datos y la tabla o rejilla multidimensional (a modo de hoja de clculo) que devolvera una
herramienta OLAP tpica.
Supongamos que deseamos conocer las ventas de productos con respecto a los productos vendidos, los almacenes donde se vendieron y el tiempo en el que se produjeron estas ventas. En este
ejemplo, la actividad de inters para la empresa sera la venta de productos y las dimensiones
del contexto del anlisis seran la dimensin producto, almacn y tiempo. En la fig. 1.1, vemos
una tabla multidimensional donde en las celdas centrales se muestran los valores de los hechos,
mientras que en los encabezados horizontal y vertical se muestran los valores de las dimensiones.
Para finalizar esta primera aproximacin al almacn de datos, mencionaremos brevemente
algunas de las ventajas e inconvenientes que los almacenes de datos presentan para las empresas:
11
: ECU, . p 15
>4
Ventajas para las empresas:

gneos.
Decisiones soportadas por datos fiables, coherentes y homo-
. Rentabilidad de inversiones (ROI, Return of Investment). Muchos son los informes

que presentan datos en cuanto a la rentabilidad obtenida a un almacn de datos fruto
de las correctas decisiones estratgicas adoptadas.
. Aumenta la competitividad en los entornos hostiles ya que se dispone de datos ms
fiables.
Entornos amigables, ya que los directivos o analistas de informacin acceden a los
datos por ellos mismos con interfaces sencillas de manejar.
Incovenientes para las empresas

Infravalorar los recursos necesarios para construir, poblar y mantener el almacn de
datos a partir de datos operacionales.
No planificar el considerable esfuerzo necesario para lograr un buen diseo.
Considerar que una vez entregado al cliente, el almacn de datos ya est acabado. El
almacn de datos recibe un incremento continuo de requerimientos ad hoc, necesitando
escalar y evolucionar conforme lo hacen las aplicaciones operacionales.
A ms cantidad de datos, ms problemas de seguridad. Dada la confidencialidad y
el matiz de los datos contenidos en los almacenes de datos, hay que extremar las
medidas de seguridad para que personas no autorizadas accedan a datos sensibles.

Quizs, la primera herramienta OLAP considerada como tal del mercado fue el lenguaje de
programacin APL de los aos 70. Sin embargo, este lenguaje fracas ya que el analista deba
tener altos conocimientos de programacin para poder obtener los informes requeridos.
A principios de los ochenta surge el producto de Comshare s System W. Enfocado a soluciones
financieras, proporcionaba datos multidimensionales en forma similar a cubos e hipercubos. Este
producto evolucion al Commander Prism de Essabe. Sin embargo, tuvo que enfrentarse a la
dificultad de que el hardware de aquella poca no soportase los requisitos de estas aplicaciones.
As, surgieron los primeros DSS y los EIS.
Mientras tanto, E. P. Codd, el creador del tan conocido modelo relacional, defini 12 reglas
para disear aplicaciones OLAP. Bsicamente, su propuesta se basa en el tratamiento de datos
multidimensional haciendo uso de la tecnologa relacional.
A finales de los 90 se incrementa tanto la oferta como la demanda de las herramientas OLAP,
surgiendo as dos tipos de arquitectura:
Las herramientas ROLAP (Relational OLAP, OLAP relacional), que utilizan tecnologa
relacional para implementar el almacn de datos.
Las herramientas MOLAP (Multidimensional OLAP, OLAP multidimensional), que
en lugar de utilizar tecnologa relacional, albergan y procesan los datos directamente en
vectores multidimensionales o matrices.
: ECU, . p 16
$5.0
$4.0
Worldwide OLAP
total market size
Subn
2001 saw the

s owest OLAP
growth nate yet
$3.0
$2.0
$1.0
$0.0
Cf. in ID N.
O
r%, ro> TIO
(N Ce CR Q1 g) Cl C1 CD C1 O
Cl Cl 0.1 Ch al 00000 C:o
"T 1-1 l'11
" N rv rv
Figura 1.2.: Evolucin del mercado OLAP desde 1994 hasta 2004
A modo de resumen, en la fig. 1.2 podemos ver un grfico que muestra la evolucin del mercado
americano de herramientas y soluciones OLAP hasta el ao 2004. Mientras que se observa un
crecimiento significativo alrededor del 2001, en 2004, el mercado OLAP ya est maduro y con
dificultad para crecer exponencialmente, presentando incluso cierto grado de saturacin. Sin
embargo, la maduracin del mercado traer consigo la reduccin de costes de forma drstica.

Finalizaremos este captulo de introduccin a la tecnologa de los almacenes de datos con un
resumen (cuadro 1.2) de las principales diferencias entre los sistemas operacionales o transaccionales y los sistemas analticos.
Del cuadro 1.2 se desprende que mientras los almacenes de datos (como sistemas analticos)
estn orientados al tema y el negocio, pues su objetivo es proporcionar respuesta a una gran
cantidad de requisitos ad hoc lanzados por los analistas del negocio, los sistemas operacionales
estn orientados a la aplicacin y a procesar un gran nmero de transacciones. Este aspecto fundamental marcar el diseo del repositorio del almacn de datos (la base de datos que almacena
la informacin para el anlisis), como veremos en los captulos siguientes.
Por ello, mientras que en los sistemas transaccionales se utilizan tcnicas de normalizacin
desde las primeras fases de diseo, tal y como justificaremos a lo largo del texto, mostraremos
que en los almacenes de datos las tcnicas de desnormalizacin sern las ms adecuadas para el
diseo eficaz de los almacenes de datos.
: ECU, . p 17
10
Usuario
Puncin
Diseo de la BD
Datos
Vistas
Destino o utilizacin
Unidades de trabajo
Acceso:
Tipo operacin
Nm. registros
Nm. usuarios
Tamao de la BD
Medida rendimiento
OLTP
Profesional de TIC
Operaciones diarias
Orientada a la aplicacin
(Basado en ER)
Actuales,
aislados
Detalladas
planas, relacionales
Estructuradas, repetitivas
Transacciones simples
OLAP
Analista de informacin
Apoyo a la decisin
Orientado al tema o negocio
(Estrella, Copo de nieve
Histricos,
consolidados
Agregadas,
multidimensionales
Ad hoc
Consultas complejas
Lectura y escritura
Decenas
"Miles"
100 MB GB
Cantidad de transacciones
Lectura mayoritariamente
Millones
"Centenares"
100 GB PB
Cantidad de consultas,
respuesta
Cuadro 1.2.: Diferencias entre sistemas operacionales y sistemas analticos en lnea
: ECU, . p 18
Bibliografa
[1] E. P. Codd. The Relational Model for Database Management. Addison Wesley, 1990.
[2] T. Connolly and C. Begg. Database Systems: A Practical Approach to Designa, Implementation, and Management. Addison Wesley, 2002.
[31 C. J. Date. Introduccin a los sistemas de bases de datos. Prentice Hall, 2001.
[41 R. Elrnasri. Fundamentos de sistemas de bases de datos. Addison Wesley, 2008.
[51 W. H. Turnan. Building the Data Warehouse. Wiley, 1996.
[61 R. Kimhall. The Data Warehouse Toolkit: Practica! Techniques for Building Dimensional
Data Warehouses. John Wiley, 1996.
N. Pendse. The OLAP Report. http://www.olapreport . com.
11
: ECU, . p 19
55b00d6a8d1fbaci45423b1b8d7abd7d1
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
55b00d6a8d1fb8d45423b1b8d7abd7d1
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 20
No permitas que al anlisis te domine.
Luis Barragn
Arquitectura
STE captulo pretende ofrecer una visin general de una arquitectura de almacenes de datos y
servir, a la vez, de ndice para el resto de captulos del libro, ya que a cada parte de la arquitectura
de un almacn de datos se le dedica un captulo del libro. Si el lector desea profundizar en una
parte en concreto, puede acudir directamente al captulo especfico. As, este captulo presenta,
en primer lugar, un esquema general de una arquitectura de almacenes de datos y que servir
para guiar el resto de secciones. A continuacin, se resumen las fuentes de datos y los problemas
derivados de la heterogeneidad de las mismas, para luego centrarse en el almacn de datos y
los metadatos de los mismos. Tras ello, se presentan los distintos servidores de una arquitectura
bsica de almacenes de datos y los tipos de herramientas de consulta comnmente utilizados para
interrogar a un almacn de datos. Finalmente, se proporciona un pequeo listado de las distintas
aplicaciones y ofertas del mercado con respecto a cada una de las partes de la arquitectura.
Indice
14
15
16
2.3.1.
Extraccin
16
16
2.3.3. Carga
17

2.4.1. Almacenes de datos departamentales o data rnaris
19
19
19
2.5. Los metadatos
20
21
13
: ECU, . p 21
14
Captulo 2. Arquitectura

2.8. Aproximaciones metodolgicas para el diseo de almacenes de
datos
22
22

Tanto en este captulo como a lo largo del libro, nos basaremos en una arquitectura clsica de
almacn de datos. Obviamente, esta arquitectura necesita redisearse si nos dirigimos a nuevos
y ms especficos contextos de aplicacin, como son los almacenes de datos basados en servicios
web, de tiempo real o de datos continuos. De este modo, pretendemos en este texto proporcionar
los conceptos bsicos, comunes y estndares a cualquier arquitectura de almacn de datos.
En la fig. 2.1, presentarnos el esquema bsico de arquitectura de almacn de datos trazado
por Chaudhuri & Dayal en el 97. Esta arquitectura se estructura en cinco partes principales:
Fuentes de datos externas (ya sean sistemas transaccionales no) y los procesos responsables de realizar la extraccin de los datos desde las fuentes, transformarlos y cargarlos
en el repositorio.
Repositorio del almacn de datos y data marts o almacenes de datos departamentales.
Metadatos, que contienen datos sobre datos, es decir, informacin sobre todo lo concerniente al almacn de datos.
Herramientas de consulta del usuario final (el tambin denominado front-end).
Servidores OLAP (On-Line Analytical Processing, procesamiento analtico en lnea) que
atienden a consultas de las herramientas de los usuarios finales y las lanzan al servidor del
almacn de datos.
Esta arquitectura clsica de almacn de datos se apoya en ciertas tecnologas, a saber:
El sistema del repositorio o base de datos del almacn de datos ser, en la mayora de las
ocasines, un SGBDR (SGBD relacional).
Los servidores OLAP, pueden ser ROLAP (Relational OLAP, OLAP relacional) o
MOLAP (Multidimensional OLAP, OLAP multidimensional).
Las herramientas de consulta de los clientes para generar fundamentalmente informes y
consultas pueden tratarse de herramientas OLAP y de minera de datos.
Para concluir, cabra preguntarse si es viable conveniente implantar un almacn de datos
sobre un sistema transaccional. Podramos resumir en dos, las principales razones para implantar
un almacn de datos separad del sistema transaccional:
Desempeo :
Al contrario que los almacenes de datos, las base de datos operacionales o transaccionales estn enfocadas y optimizadas para atender a un gran nmero de transacciones; los mtodos y herramientas para el desarrollo de un almacn de datos (diseo,
implementacin, mantenimiento, etc.) son significativamente distintos.
: ECU, . p 22
15
Monitorizacin & Administracin

Aiialisis
C:I=j Repositorio
de metadatos
Servidores
OLAP
\.
Almacn de datos
Fuentes externas
ConsultasInformes
Extraer
Transformar
BD operacionales
Cargar
Mineria de datos
Refrescar
Fuentes de datos
Dota Marts
Herramientas:
de consulta
Figura 2.1.: Arquitectura general de un almacn de datos
Las consultas LAP realizadas a los almacenes de datos son muy complejas, por
lo que procesarlas en un sistema tradicional ralentizara las tareas del servidor de
atender a las transacciones diarias.
Funcionalidad
Los datos histricos no se encuentran generalmente en las bases de datos transaccionales que recogen datos diarios producidos por la empresa y, por tanto, necesitamos
un repositorio especfico para los datos histricos.
Adems, los almacenes de datos presentan generalmente una gran cantidad de datos
consolidados (agregados, sumados, resumidos, etc.) a partir de datos histricos, lo
que dificulta las tareas de mantenimiento de los mismos.
Al proceder de distintas fuentes operacionales, se tiene que prestar especial atencin a
la calidad de los datos, integrndolos bajo un esquema comn y homogneo de bases
de datos. Sera totalmente inviable lanzar una consulta que requiera datos de varias
bases de datos y esperar que en tiempo real se pudiera normalizar para presentar al
usuario final.

Una tipologa de las fuentes de datos utilizadas normalmente para extraer los datos que
albergar el almacn de datos es la siguiente:
Fuentes de datos operacionales que pueden ser: SGBDR o sistemas mainframe utilizados en
las bases de datos jerrquicas y en red de primera generacin. Aunque parezca extrao, se
: ECU, . p 23
16
calcula que en la actualidad, una gran mayora de los datos operacionales de las empresas
se almacenan en este tipo de sistemas.
Sistemas de archivo propietarios como VS AM o RSM.
Bases de datos externas pblicas o privadas, que pueden aportar datos comparativos de la
empresa frente a sus competidores o datos de otros agentes econmicos que participan
en el mismo entorno (como las empresas que recopilan datos y los venden, proveedores,
clientes, etc.).
Internet, que dada la cantidad ingente de datos diversos, puede suponer una fuente importante
a la hora de completar los datos extrados desde las fuentes de datos operacionales.
Datos en formato tradicional, ya que an existen empresas y organismos pblicos que disponen
de datos que estn en formato tradicional como albaranes, facturas, notas de entrega o
datos del registro civil. Incorporar estos datos suele ser un esfuerzo extra porque, en primer
lugar hay que pasarlos a formato electrnico. Sin embargo, en ocasiones es imprescindible
si se quiere disponer de un almacn de datos que registre una larga historia.

Los procesos ETL (Extraction, Transformation, and Loading, extraccin, transformacin y
carga) son de crucial relevancia en la arquitectura del almacn de datos. Estos procesos son los
responsables de extraer los datos de las fuentes de datos transaccionales, realizar las transformaciones necesarias, cargarlos en el almacn de datos una vez hayan sido tratados y realizar
los refrescos o cargas sucesivas de datos durante la vida del almacn de datos. As como a las
herramientas de usuario final se les conoce como el front-end, a los procesos ETL y el tratamiento de los datos operacionales se les suele denominar back-stage, back-room o staging aren.
A continuacin, vamos a concretar un poco ms las tareas que se realizan en cada una de estas
fases.
2.3.1. Extraccin
Son procesos que se encargan de conectar con las fuentes de datos operacionales para extraer
los datos con los que se poblar el almacn de datos. Para programar estos procesos, se tiene que
tener conocimiento de los metadatos de las fuentes de datos y del tipo de conectividad necesaria
para su extraccin.

Es fundamental que los datos del almacn de datos sean correctos, dado que se utilizarn para
adoptar decisiones estratgicas que normalmente llevan asociadas fuertes inversiones, siendo
claves para el posicionamiento de la empresa en el entorno en el que se desenvuelve. Dada la
idiosincrasia de los almacenes de datos, en el sentido que los datos proceden de diversas fuentes
de datos, normalmente heterogneas; existe una alta probabilidad de enfrentarnos a errores en
caso de no limpiar o tratar los datos con anterioridad a su carga en el repositorio.
Por resumir, algunas anomalas tpicas son:
: ECU, . p 24
17
Longitud inconsistente de campos. Es muy comn que los campos de datos (como los de
direccin, nombre o apellidos) tengan longitudes distintas en las diferentes bases de
datos de la organizacin. Estas bases de datos se han podido desarrollar en distintos periodos de tiempo, incluso por distintas empresas o personas, sin tener la precaucin de que
coincidan la longitud de los campos de datos.
Descripcin inconsistente de campos. Podemos encontrar que en una base de datos, por ejemplo, el campo direccin se refiere al nombre de la calle o avenida donde reside una persona, mientras que en otra el campo direccin incluye el referido a nombre, cdigo postal,
ciudad, provincia, etc.
Distintas codi caciones para el mismo trmino. Esta anomala contina siendo una fuente importante de errores aunque sea cada vez menos habitual en las fuentes de datos operacionales (gracias a la generalizacin de formularios que presentan listas desplegables de valores prefijados para la introduccin de datos mediante seleccin). Por ejemplo, podemos
tener en distintas bases de datos (acadmica, econmica, estadstica, etc.) que un estudiante proviene del I. Jorge Juan , Inst . Jorge Juan , I.B. Jorge Juan , I.B. J.
Juan , etc. Si estos datos se cargan sin limpiarlos, a la hora de extraer resmenes, todos
estos nombres sern tratados como institutos de bachillerato distintos, cuando en realidad
son el mismo. Por ello, es fundamental limpiarlos y unificar sus descripciones y nombres
antes de cargarlos en el almacn de datos.
Valores nulos. Es muy comn que una vez diseado el esquema del almacn de datos, cuando
extraigamos datos de las fuentes, nos encontremos con campos de datos nulos, los cuales,
en muchas ocasiones, se tendrn que rellenar de forma manual.
Nuevas reglas de integridad. Si los datos de las fuentes de datos se regan segn unas ciertas
reglas de integridad, ya en el almacn de datos, estas reglas no sern vlidas. ste dispone
de sus propias reglas de integridad y los nuevos datos debern de adecuarse a tales reglas
siguiendo el nuevo esquema de datos, propio del almacn de datos.
2.3.3. Carga
Una vez que los datos se han extrado de las fuentes de datos y se han transformado y limpiado,
hay que cargarlos en el almacn de datos. Pero antes de realizar la "insercin" final de los datos,
normalmente se requiere un preprocesamiento de los datos ya limpiados, que normalmente suele
consistir en:
Comprobar nuevamente las reglas de integridad.
Ordenar los datos.
Calcular datos agregados, resumidos, etc., ya que los almacenes de datos suelen albergar
una gran cantidad de datos de este tipo.
Construir tablas derivadas, virtuales, temporales, etc., necesarias para la carga final de
datos.
: ECU, . p 25
18
Construir ndices especficos para la carga de datos. Una buena poltica de definicin de
ndices suele ser fundamental para el rendimiento del mismo, no slo para las propias
estructuras del almacn de datos, sino tambin para el proceso de carga de datos.
Definir la paginacin de carga de datos.
Especificar el tiempo (la ventana de carga) en el que se desea realizar la carga de datos.
Dicha carga se deber realizar cuando la fuente de datos tenga menos volumen de trabajo.
No resulta extrao entonces que la noche sea el momento adecuado para la carga de
datos en el almacn de datos, pues es cuando probablemente menos consultas tendr
que satisfacer el sistema OLTP. Aun as, siempre podremos dar con casos especiales y
extremos: las empresas multinacionales establecidas en varios continentes es un ejemplo
tpico de cundo deberemos estudiar con detenimiento del perodo ptimo de carga.
Las tcnicas de carga de datos ms comunes son:
Cargas secuenciales. Son las ms caras y las que ms tiempo ocupan, puesto que consisten en
reemplazar la antigua tabla con la nueva despus de una transaccin. Adems, utilizan
comprobaciones peridicas, normalmente, comenzar despus de fallo.
Procesos por lotes (batch). Son aquellas en las que el administrador monitoriza el proceso de
carga. La carga se realiza mediante procesos cortos con uso secuencial de E/S. Tal tcnica
es adecuada para la generacin de ndices y datos derivados.
Procesamiento paralelo y tcnicas incrementales. Slo carga las actualizaciones, no tablas en-
teras. Al realizar la confirmacin de la transaccin, se reemplaza el antiguo estado con los

nuevos datos. Con esta tcnica, el almacn de datos puede ser consultado mientras carga.
Utiliza tambin comprobaciones peridicas de inconsistencia, esto es, mediante procesos
de auditora sobre los datos.
Por otro lado, tras la primera carga del almacn de datos, se procede a un proceso de refresco
en que las actualizaciones realizadas sobre las fuentes de datos se propagan al almacn de datos.
De todas formas, realizar una nueva carga por cada actualizacin de la fuente de datos es un
proceso costoso y slo debera justificarse dada la importancia de analizar datos muy actuales,
como es el caso del anlisis de la bolsa de valores. Normalmente, los refrescos se hacen de manera
peridica, definindose una poltica de actualizacin en funcin de cada caso. Por ello, no se debe
olvidar que los SGBD (Sistema de gestin de bases de datos) ofrecen servidores para replicar
datos con la consiguiente aceleracin de los refrescos.
Existen dos tcnicas fundamentales para el refresco:
Extraccin entera de las bases de datos donde se leen las tablas o bases de datos completa-
mente. Pese a que esta alternativa es costosa, a veces, es la nica eleccin para ficheros o
sistemas heredados.
Tcnicas incrementales donde se detectan y propagan los cambios. Esta tcnica se realiza me-
diante servidores de rplica. Por ejemplo, mediante imgenes (snapshots) y triggers como
con Oracle, mediante transporte de transacciones (transaction shipping) como con Sybase,
u otras como con IBM dato replicator.
: ECU, . p 26
19

Aunque en la prctica los procesos ETL se configuran normalmente haciendo uso de las utilidades para tal fin que proporciona el producto comercial que utilizamos como gestor del almacn
de datos, o programando directamente en cualquier 4GL (Faurth- Generaban programming Language), existen herramientas especificas que estn enfocadas a facilitar estas tareas. Ofrecemos
aqu una clasificacin de las mismas:
Herramientas de migracin de datos (data migration). Permiten definir reglas para transfor-
maciones simples como, por ejemplo, reglas para reemplazar el nombre del campo gnero
en la fuente por sexo en el almacn de datos.
Herramientas de limpieza de datos (data scrubbing). Con ellas se puede registrar conocimien-
to especfico del dominio en forma de reglas y comprobar que los datos las cumplen. Por
ejemplo, permiten la definicin de patrones para direcciones postales y as, cualquier campo
direccin deber cumplir esta regla.
Herramientas de auditora de datos (data auditing tools). Examinan los datos para descu-
brir reglas y relaciones entre ellos y, de esta forma, lanzar seales de violacin si se encuentra que hay reglas predefinidas que no se estn cumpliendo.

Este es el elemento principal de la arquitectura y donde los datos a analizar se integran y
consolidan. Por ello, la definicin de almacn de datos se ha visto ya en el captulo anterior y en
el siguiente se ver su diseo mediante el modelado multidimensional de hechos y dimensiones
bajo anlisis.
2.4.1.
Almacenes de datos departamentales o data marts
Los data marts son repositorios de datos que se asocian a un almacn de datos como vistas
de ste para satisfacer las necesidades de un departamento o seccin dentro de una empresa.
Normalmente, en la prctica suelen contener ms cantidad de informacin agrupada que en
detalle, tal y como ocurre por otro lado en el almacn de datos.
Para su construccin se pueden seguir dos aproximaciones:
1. Definir primero el almacn de datos y, a partir de l, definir los data marts.
2. Definir primero los data marts y posteriormente integrarlos en un almacn de datos global
para la organizacin.
De estas dos aproximaciones, la primera es la ms adecuada desde un punto de vista terico,
pues ayuda a que los procesos de carga integren las fuentes de datos en un nico repositorio
para despus distribuir los datos agregados a los data marts. Por otro lado, en la prctica, si la
envergadura de la empresa es considerable o la experiencia en la construccin de almacenes de
datos es pequea, es aconsejable decantarse por la segunda aproximacin, pues permite definir
un almacn de datos global cuando ya se ha visto la viabilidad y utilidad de proyectos de data
marts ms pequeos y manejables que uno de almacenes de datos. En resumen, podemos decir
que:
: ECU, . p 27
20
Almacn de datos
Data Iklalts
Figura 2.2.: Representacin de los data marts como versiones agregadas del almacn de datos
Almacn de datos corporativo dispone de informacin acerca de toda la empresa, requiere un

modelado del negocio complejo y puede llevar aos en su construccin e implementacin.
Data mart es una versin reducida del almacn de datos orientado a un tema especfico. Por
ejemplo, marketing, clientes, productos ventas. Es ms rpido de disear pero con el
problema de que la integracin con el almacn de datos corporativo puede ser compleja al
haberse diseado antes que l.
Aparte de los data rnarts, existen tambin los almacenes de datos virtuales. Si los primeros
se podan ver como vistas materializadas del almacn de datos, los segundos son vistas (sin
materializar) sobre las fuentes de datos operacionales. Pese a que en general tales vistas son solo
virtuales, tambin se incluyen materializaciones de algunas vistas agregadas para hacer ms
eficientes las consultas ms comunes. Estos repositorios son ms fciles de construir, ya que no
se requieren estructuras fsicas para su almacenamiento, pero necesitan una capacidad operativa
extra en el servidor para ser analizado mediante las herramientas correspondientes. Por ello, no
es extrao que muchas empresas decidan construir almacenes de datos cuando el administrador
ya ha creado uno virtual.
2.5. Los metadatos

Los metadatos "son datos acerca de otros datos". A continuacin, se presentan algunos ejemplos
de tales metadatos:
Qu dato se guarda (por ejemplo, clientes).
Dnde se guarda (tabla clientes).
Campos de la tabla.
Con qu datos de las fuentes se corresponden.
Niveles de agregacin.
: ECU, . p 28
21
Cundo se actualizan los datos.

Cundo fue la ltima actualizacin.
Patrn de dato vlido (por ejemplo, Apellido 1 Apellido2, Nombre).
Los metadatos se clasifican en los siguientes tipos:
Administrativos: estos son toda la informacin necesaria para el almacn de datos. Entre ellos
contamos con: fuentes de datos y contenidos, descripciones del gatetuay, esquema del almacn de datos, vistas y datos agregados, dimensiones de anlisis con sus jerarquas, consultas e informes predefinidos, localizacin y contenido de los data nzarts o las particiones
de datos, entre otros.
De negocio: como es la informacin y trminos de negocio, las polticas de posesin de datos y
las polticas de permiso de datos por los usuarios (seguridad).

Operacionales: recogidos durante el proceso de carga del almacn de datos. Por ejemplo, los
datos migrados y secuencia de transformaciones aplicadas, el estado de los datos (activos, archivados, eliminados, etc.) o la informacin de monitorizacin (estadsticas de uso,
informes de error, auditora, etc.).

El servidor del almacn de datos es un SGBD que se encarga de gestionar el repositorio
del propio almacn de datos, coordinar los procesos ETL que alimentan el almacn de datos
y procesar las consultas lanzadas sobre el almacn devolviendo los datos. Generalmente son
servidores relacionales dada la amplia difusin de tal tecnologa.
Por otro lado, en la mayora de las arquitecturas se utiliza un servidor distinto al del almacn
de datos para las consultas. Esto es debido a motivos de rendimiento y mantenimiento, pues al
separar las consultas del SGBD, se pueden establecer diferentes mecanismos que optimicen las
consultas en funcin de su tipo. Dada su flexibilidad, la mayora de las herramientas funcionan
con esta arquitectura (por ejemplo, MICROSTRATEGY).
Existen dos tipos de arquitecturas fundamentales para implementar tales servidores, en funcin de la tecnologa de bases de datos usada.
Por Un lado, los servidores ROLAP utilizan la tecnologa relacional mediante la extensin de
SQL (Structured Query Language, lenguaje de consulta estructurado) para soportar el acceso
multidimensional a los datos. Presentan mtodos de implementacin adecuados para representar
los datos multidimensionales en la tecnologa relacional. La ventaja del uso de una tecnologa
tan difundida como la relacional es que estn basados en el estndar SQL. Algunos de los ms
extendidos son: ORACLE o IBM (DB2 y BUSINESS SOLUTIONS), por ejemplo.
Por otro lado, los servidores MOLAP utilizan la tecnologa multidimensional. Los datos
estn almacenados directamente en matrices y las operaciones de consulta estn implementadas
directamente sobre tales estructuras de datos. Por ello, no estn basados en el estndar SQL.
La ventaja es que suelen ser ms rpidos que los servidores ROLAP.
: ECU, . p 29
22

Estas herramientas son con las que finalmente se acceder al almacn de datos. A continuacin,
se exponen los tipos fundamentales de herramientas disponibles.
Para la generacin de informes, se disponen de dos entornos: los de consultas ad hac e informes
y los entornos de consulta de directivos. Los primeros permiten el acceso a los datos base y
los informes se construyen con point-and-click. Ejemplos de tales aplicaciones son MICROSOFT
ACCESS y PLATINUM PRO REPORTS. Los segundos, muestran los datos base en trminos de
negocio. Utilizan para ello consultas predefinidas y almacenadas. Sin embargo, tambin dan
un soporte limitado para las consultas ad hac. Ejemplos de tales aplicaciones son BUSINESS
OBJECTS y SAS/EIS.
Por otro lado, las herramientas de explotacin para las cuales est orientado en mayor medida
el diseo del almacn de datos son las herramientas de consulta LAP. Su objetivo es dar
soporte a consultas ad hac para el analista de negocio. Es interesante notar que los analistas del
negocio ya parte de conocer las hojas de clculo, por tanto, el anlisis LAP se presenta como
una extensin de las hojas de clculo para la explotacin del almacn de datos. Esta extensin se
realiza mediante el enriquecimiento semntico con los trminos de negocio y los metadatos para
el anlisis multidimensional de datos datos, esto es, su marcado como hechos y dimensiones.
Ejemplos de herramientas LAP son: ORACLE DISCOVERER e IBM BUSINESS SOLUTIONS,
entre otros muchos.
Como ltimo tipo fundamental de herramientas de consulta tenemos las herramientas de
minera de datos o data mining. Tales herramientas permiten descubrir tendencias y patrones
en los datos (minera interpretativa) y crear modelos que habilitan la prediccin de nuevos datos
(minera predictiva). Esta ltima funcionalidad se realiza mediante la bsqueda de patrones y
modelos en los datos existentes. Por ello, con la inclusin de nuevos datos, los modelos y patrones
encontrados debern ser actualizados para ajustarse a estos datos.
2.8. Aproximaciones metodolgicas para el diseo de

almacenes de datos
Para finalizar, introducimos aqu las mayores aproximaciones metodolgicas para el diseo de
almacenes de datos:
Top-down donde se disea y modela el almacn de datos en funcin de los requisitos de informacin. Se obtienen luego los datos para poblar el almacn de datos a partir de las fuentes
de datos operacionales en funcin de los requisitos encontrados. Esta aproximacin es la
ms utilizada normalmente.
Bottorn-up donde se disea y modela el almacn de datos en funcin de los datos que estn
presentes en las fuentes de datos operacionales. Tras ello, se disean los procesos ETL. En
este caso, los analistas han de adaptarse al diseo en lugar de dirigir el diseo del almacn
de datos.
Hbrida como combinacin de las dos anteriores: se dirige el diseo del almacn de datos mediante los requisitos de informacin y se alinean con las fuentes de datos para resolver qu
requisitos pueden cumplirse.
: ECU, . p 30
2.8. Aproximaciones metodolgicas para el diseo de almacenes de datos
23
BOTTOM UP
HBRIDA
Analistas
-4(
TOP OWN
Figura 2.3.: Mtodos de diseo para almacenes de datos
Con lo expuesto, en el siguiente captulo veremos cmo modelar el repositorio del almacn de
datos mediante el paradigma de modelado multidimensional.
: ECU, . p 31
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 32
Bibliografa
[1] L. Agosta. The Essential Guide to Data Warehousing. Prentice Hall, 1999.
[2] S. Chaudhuri and U. Dayal. An Overview of Data Warehousing and OLAP Technology.
SIGMOD Record, 26(4:65 74, 1997.
[31 P. Furtado. A Survey of Parallel and Distributed Data Warehouses. International Journal
of Data Warehousing and Mining (IJDWM), 5(457 77, 2009.
[4] W. Giovinazzo. Object-oriented data warehouse design: building a star schema. Prentice
Hall, 2000.
[5] MicroStrategy Inc. MicroStrategy. wwra . crostrategy. es.
[6] W. H. Turnan. Building the Data Warehouse. Wiley, 1996.
[7] M. Jarke, M. Lenzerini, Y. Vassiliou, and P. Vassiliadis. Fundamentals of Data Warehouses.
Springer-Verlag, 2003.
[81 R. Kimball. The Data Warehouse Toollcit: Practica! Techniques for Building Dimensional
[91 Oracle. Data Warehousing. www o rac I e com/us /s o lut i ons/dat awarehousing/index
htm.
25
: ECU, . p 33
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 34
El mundo es complejo, dinmico, multidimensional; el papel es esttico y simple. Cmo se puede representar toda la riqueza del
mundo en una hoja de papel?
Edward R. Tufte
Modelado Multidimensional
AS bases de datos tradicionales almacenan transacciones que se refieren al trasiego de informacin operacional de una organizacin, es decir, operaciones que se llevan a cabo diariamente.
Estos sistemas se denominan OLTP (Ora-Line Transaction Processing, procesamiento transaccional en lnea). Por ejemplo, un cajero automtico de un banco es un ejemplo de una aplicacin
OLTP, ya que se deben guardar cada una de las transacciones realizadas.
Sin embargo, los sistemas OLTP no estn preparados para el anlisis de los datos registrados. Un analista que quiera acceder a los datos histricos de una organizacin para poder tomar
decisiones necesita de sistemas con otro tipo de requisitos diferentes a los OLTP. Estos sistemas se denominan OLAP (Ora-Line Analytical Processing, procesamiento analtico en lnea)
y hacen uso de bases de datos multidimensionales para incrementar la capacidad de anlisis
de los usuarios. Por ejemplo, un analista bancario podra necesitar estudiar las transacciones
realizadas en los cajeros automticos para determinar las comisiones a cobrar minimizando el
coste a los usuarios pero sin que el banco tenga prdidas. Este anlisis no se puede llevar a
cabo directamente sobre el sistema OLTP porque resultara costoso, por lo que se debe disear
una base de datos multidimensional que permita el anlisis de los datos mediante herramientas
OLAP.
Los almacenes de datos posibilitan una visin multidimensional de enormes cantidades de
datos histricos provenientes de fuentes operacionales, suministrando la informacin necesaria
para el apoyo a los procesos de toma de decisiones de una organizacin. El paradigma multidimensional estructura la informacin en hechos y dimensiones. Un hecho contiene medidas
interesantes de un proceso de negocio como las ventas o la gestin del inventario (atributos del
hecho), mientras que una dimensin representa el contexto de anlisis de un hecho (producto,
cliente, tiempo, etc.) mediante una serie de atributos organizados jerrquicamente. El modelado
multidimensional requiere de tcnicas de diseo especializadas que se asemejan a los mtodos
tradicionales de diseo de bases de datos. En primer lugar se desarrolla una fase de diseo conceptual con el fin de obtener un modelo multidimensional conceptual para el almacn de datos
27
: ECU, . p 35
28
Captulo 3. Modelado Multidimensional
independiente de la implementacin. Luego, una fase de diseo lgico se encarga de derivar un

modelo dependiente de la tecnologa a partir del modelo conceptual.
En este captulo se introducir al lector en los conceptos bsicos a tener en cuenta en las fases
de diseo conceptual y diseo lgico de un modelo multidimensional.
ndice
3.1.
3.2.
Modelado multidimensional conceptual
28
3.1.1.
Propiedades multidimensionales estructurales
29
3.1.2.
Propiedades multidimensionales dinmicas
32
Modelado multidimensional lgico
33
3.2.1.
Esquema estrella
34
3.2.2.
Esquema de constelaciones de hechos
41
3.2.3.
Esquema de copo de nieve
42
3.2.4.
Resumen de los diferentes esquemas
43
3.2.5.
La dimensin tiempo
44
3.2.5.
Otras consideraciones de diseo
45

El modelado multidimensional se debe acometer a nivel conceptual con el fin de reflejar la
realidad de manera fidedigna y abstraer el diseo de la plataforma donde el almacn de datos ser
implementado. En concreto, el modelo multidimensional conceptual debe representar aquellos
elementos que permitan al usuario obtener la informacin necesaria para el apoyo a la toma
de decisiones. Estos elementos o propiedades multidimensionales pueden ser estructurales o
dinmicos.
Es conveniente realizar aqu un matiz importante que diferencia los almacenes de datos de
las bases de datos transaccionales. Desde hace ya muchos aos, se disponen de modelos conceptuales estndares y ampliamente difundidos para acometer la fase del modelado conceptual de
las bases de datos conceptuales como, por ejemplo, El Modelo Entidad Relacin Extendido, o
UML (Un ed Modelling Language), etc. Sin embargo, tambin es ampliamente aceptado por
la comunidad acadmica y empresarial que estos modelos no son adecuados para el diseo de los
almacenes de datos y aplicaciones OLAP y, en definitiva, para los sistemas basados en el modelado o paradigma multidimensional. La principal razn es que estos modelos estn enfocados
a modelar sistemas transaccionales y no reflejan las propiedades multidimensionales (hechos,
dimensiones, niveles de jerarqua, etc.) tal y como se debe reflejar en estos sistemas.
Sin embargo, hoy en da todava no existen modelos conceptuales acompaados de herramientas de modelado que se hayan aceptado como estndares o, digamos, ampliamente aceptadas.
Las propuestas ms avanzadas y utilizadas emanan de grupos de investigacin en el mbito universitario que llevan ya tiempo proponiendo estndares de modelado para este tipo de
sistemas. Entre ellas podemos destacar la Business Intelligence Suite, herramienta basada en
la Plataforma ECLIPSE y registradas por los autores de este texto y desarrollada en el seno
del grupo Lucential. Dicha herramienta permite el modelado multidimensional basndose en
lhttp://www.lucentia.es
: ECU, . p 36
29
estndares como UML, MDA (Model-Driven. Architecture), etc. Tambin podemos destacar la
herramienta WAND desarrollada en la Universidad de Bolonia.
Sin embargo, con el propsito de que este texto sea un texto de introduccin y que se pueda
aplicar directamente al desarrollo de productos comerciales, hemos evitado en este captulo
introducir estas propuestas de modelado, que si bien han contrastado ya su validez, se encuentran
en el proceso de ser aceptadas como estndares. Por ello, nos ceimos en este punto a los aspectos
abstractos del modelado multidimensional que se deberan especificar en esta fase de modelado.
Adems, permita el lector aqu una crtica a los productos comerciales de almacenes de datos
y, es el hecho de que, si bien con las bases de datos transaccionales estos productos llevan
aos ofreciendo herramientas para acometer el diseo conceptual de los mismos, en cuanto a los
almacenes de datos, parece que an estamos hace una dcada, pues las herramientas comerciales
proporcionadas permiten acometer el diseo desde su perspectiva lgica, con la consiguiente
prdida de expresividad y de abstraccin necesarias en la fase anterior de modelado conceptual.
En este sentido, los autores han estado trabajando en una metodologa basada en MDA y UML
para el diseo de almacenes de datos, que ser descrita en profundidad en un texto en un futuro
no muy lejano.
3.1.1.
Propiedades multidimensionales estructurales
Las propiedades estructurales consisten en la definicin de estructuras de datos que faciliten

el anlisis multidimensional de los mismos. En concreto, la informacin se estructura en hechos
y dimensiones. Un hecho contiene medidas interesantes que son el objeto de anlisis (ventas
de productos, compras, alquileres, transportes, etc.), mientras que las dimensiones representan
diferentes perspectivas para analizar dichas medidas (productos, almacenes, clientes, tiempo,
vehculos, etc.).
Intuitivamente, un modelo multidimensional se representa en forma de cubo o hipercubo (cubo
sobre cubo) o en su versin ms sencilla, como tablas multidimensionales (tipo hoja de clculo).
Un ejemplo de cubo se puede ver en la fig. 3.1; y un ejemplo de tabla multidimensional en la
fig. 3.2, donde tenemos un hecho de ventas de productos a ser analizado por almacn, producto
y fecha en que se realizan las ventas.
Dimensiones
Una dimensin se compone de una serie de atributos organizados jerrquicamente. Estos atributos permiten analizar las medidas de los hechos a diferente nivel de detalle segn se agreguen
o desagreguen los datos. Por ejemplo, las ventas se pueden analizar por ciudad, comunidad,
provincia o pas.
La cardinalidad en la relacin entre estos niveles de detalle da lugar a diferentes tipos de
jerarquas:
Jerarquas estrictas y no-estrictas. Una relacin entre dos niveles de jerarqua es estricta si
para cada elemento de nivel ms detallado (por ejemplo Da en una asociacin entre Da
y Semana) existe como mximo un elemento de nivel ms general (como Semana) el cual
se asocia con dicho elemento; de otra manera, se llama no estricta. En otras palabras, una
asociacin entre dos niveles de jerarqua es estricta si la cardinalidad es uno a muchos,
si no, entonces se llama no-estricta. Por ejemplo, la asociacin entre Semana y Mes es
: ECU, . p 37
30
venta& prOdUCt911
Ltributes da dimensibn
Barcen.nn
Hechos
AI.1~a~~Almacn
Protiucta
Dimenoionen
Tiempo
Figura 3.1.: Ejemplo de cubo de datos
Produclo,Grupo = "Supwnacado"
Ventas
Cmirlit
Cong
Albaicra
Ahn
Alicante
I lehe
cosnunidad
-Cs) rn unidad
B urja sot
Valenciana" V al Lracia
Cunera
Fresco Refresco Alcohol
100
200
300
ol 00
500
600
700
4300
900
1000
1100
1200
1309
1400
1500
1600
Figura 3.2.: Ejemplo de tabla multidimensional
: ECU, . p 38
31
Zona Ventas
Jerarqua
Mltiple
Jerarqua de
camino alternativo
grupo
tipo 1rO
marca()
Producto
nombre
o
Dimansin
comunidad
Almaca
ciuda provincia
poblacin
direccin
telfono
Jerarquas de clasificacin
CD Atributos de dimension
Figura 3.3.: Ejemplo de jerarquas como grafos acclicos dirigidos
no-estricta ya que parte de una misma semana puede estar en un mes dado y parte en el
siguiente mes.
Jerarquas simtricas y asimtricas. Una relacin que involucra a un par de niveles de
dimensin es simtrica si para cada elemento de nivel menos detallado (p. ej. Pas para la
asociacin entre Ciudad y Pas), existe un elemento de nivel ms detallado (p. ej. Ciudad)
el cual se asocia con dicho elemento; de lo contrario la asociacin es asimtrica. En otras
palabras, una relacin entre niveles es asimtrica si la cardinalidad es cero a uno; si no,
se denomina simtrica. Por ejemplo, la asociacin entre Producto y Tipo es asimtrica si
puede haber tipos de productos que no contengan productos especficos. Una jerarqua
asimtrica implica que las instancias de los niveles de la jerarqua no son obligatorios y
pueden no estar instanciados.
Jerarquas completas e incompletas. Una asociacin entre dos niveles de jerarqua es completa si para cada elemento de un nivel ms detallado, (por ejemplo, Vendedor en la asociacin entre Vendedor y Departamento) existe un elemento de nivel ms general (como
Departamento) que se asocia con dicho elemento; si no, se llama incompleta. En otras
palabras, una asociacin entre dos niveles es incompleta si la asociacin entre niveles de
jerarqua es cero a muchos; si no, se denomina completa. Por ejemplo, la asociacin entre Producto y Categora es incompleta si hay productos que no pertenecen a ninguna
categora.
Jerarquas de generalizacin. En las dimensiones puede haber un alto grado de categorizacin, es decir, los atributos de la dimensin pueden tener sentido o no dependiendo de
las instancias. Este tipo de jerarquas pueden representarse mediante relaciones de generalizacin/especializacin. Por ejemplo, el volumen y el porcentaje de alcohol slo tiene
sentido si el producto es una bebida mientras que el tiempo y modo de preparacin solo
es vlido para comidas.
Las jerarquas pueden ser simples si no comparten ningn nivel con ninguna otra jerarqua o
mltiples, si dentro de una dimensin se definen varias jerarquas compartiendo algunos niveles.
Mientras que las jerarquas simples pueden representarse mediante rboles, las mltiples se
suelen representar mediante grafos acclicos dirigidos tal y como se observa en la fig. 3.3, donde se
grafican las dimensiones producto y almacn con sus correspondientes jerarquas de agregacin.
: ECU, . p 39
32
Hechos
Los hechos contienen atributos de hecho o medidas a analizar. estos representan normalmente relaciones muchos a muchos con todas las dimensiones y muchos a uno con cada dimensin
en particular. Por ejemplo, si se estudian las ventas (hecho) por producto (dimensin), tiendas
(dimensin) y tiempo (dimensin), un producto puede venderse en varias ventas, mientras que
una venta se realiza en una sola tienda, de un solo producto, se hace a un solo cliente y en una
fecha concreta. Sin embargo, a veces los hechos se relacionan muchos a muchos con dimensiones en particular. Por ejemplo, si en una nica venta (hecho) participa ms de un vendedor
(dimensin).
Las medidas contenidas en el hecho pueden ser atmicas, por ejemplo, la cantidad vendida
o el precio, o derivados si utilizan una frmula para calculados, por ejemplo, el precio total
(precioTotal = precio * cantidadV enclicia).
A las medidas se les puede aplicar un conjunto de operadores de agregacin (SUM, AVG, etc.)
para agregar los valores de medidas a lo largo de diferentes niveles de detalle (segn las jerarquas
definidas en la dimensin). Al realizar esta agregacin se debe tener en cuenta la aditividad
de las medidas. Una medida es aditiva si la operacin SUM se puede aplicar sobre todas las
dimensiones, es semi-aditiva, si el operador SUM solo se aplica sobre algunas dimensiones, y es
no aditiva si el operador SUM no se puede aplicar sobre ninguna dimensin.
Sin embargo, cabe destacar que si la media es no aditiva, se pueden aplicar otros operadores (AVG, MIN, etc.). Un ejemplo son los atributos que miden niveles (por ejemplo, niveles de
inventarios) ya que no son aditivos sobre la dimensin tiempo, pero s sobre la dimensin producto. Otro ejemplo son las medidas de temperatura, que no son aditivas, puesto que la suma de
temperaturas en el tiempo carece de sentido. Incluso, aplicar funciones de agregacin a algunas
medidas sera semnticamente incorrecto. Por ejemplo, si intentamos agregar la medida nmero
de clientes que cuenta el nmero de tickets emitidos. Es evidente que esta medida no es aditiva
sobre la dimensin producto.
3.1.2. Propiedades multidimensionales dinmicas

Las propiedades dinmicas estn relacionadas con la definicin de los requisitos iniciales de
usuario. Por ejemplo, se necesita saber la cantidad vendida de productos comestibles agrupados
por su familia y tipo, vendidos en la Comunidad Valenciana y agrupados por la provincia y
ciudad donde se vendieron.
Para contestar a estos requisitos se deben utilizar un tipo de operaciones con el fin de interrogar
a la parte estructural del modelo multidimensional (operaciones de consulta OLAP):
RoII-up: esta operacin permite agregar valores de medidas a lo largo de los niveles de jerarquas
de clasificacin de las dimensiones. Por ejemplo, si teniendo las ventas realizadas por
ciudades se necesita saber las ventas por provincias, al aplicar roll-up desde ciudad a
provincia y desde tipo a familia de producto sobre la tabla multidimensional de la fig. 3.2
el resultado se puede observar en la fig. 3.4, donde las celdas del cubo de datos presentan
valores agregados.
DriII-down: esta operacin permite desagregar valores de medidas a lo largo de jerarquas de
clasificacin. Es la operacin contraria al roll-up. Por ejemplo, si teniendo las ventas realizadas por provincias se necesita saber las ventas por ciudades. Al aplicar drill-down desde
: ECU, . p 40
Prncl In.eilipo
Witits
Almacn_
comunidad =
"Curnunidad
VaUMCLEMO
im
!ci
Comida
Bebida
Ahasnt c
14013
2200
Valencia
4600
5400
AlmactnG-
ciudad provincia
zafe
LM111219
t.'"'
Figura 3.4.: Ejemplo de aplicacin de la operacin roll-up
Ventila
Ahruic
Comunidad =
"Comunidad
1111~11
-
=I=
77111
Alba Icra
--- 2(
licuaste
5no
r5D11
Figura 3.5.: Ejemplo de aplicacin de la operacin drill-across.
provincia a ciudad y desde familia a tipo de producto sobre la tabla multidimensional de

la fig. 3.4, obtenemos de nuevo la tabla de la fig. 3.2, donde las celdas del cubo de datos
presentan valores desagregados.
Drill-across: esta operacin permite navegar de un hecho a otro mediante el uso de dimensiones
comunes. Gracias a esta operacin, se pueden consultar medidas de varios hechos en el
mismo cubo.
Slice
Si dice: este par de operaciones permiten definir restricciones sobre niveles de jerarquas.
Por ejemplo, analizar datos del ao 1999 (ver fig. 3.5).
Pivoting: esta operacin permite reorientar la vista multidimensional de los datos, es decir,
cambiar la distribucin de filas o columnas. Algunos autores consideran tambin el intercambio de medidas y hechos como pivoting. Un ejemplo de pivoting se observa en la
fig. 3.6.
3.2.
Modelado multidimensional lgico
Una vez definido un modelo conceptual multidimensional independiente de la plataforma de

implementacin, se debe desarrollar un modelo lgico. El modelado lgico depender del tipo
de tecnologa sobre el que se va a implementar el almacn de datos. Existen dos tendencias
principales:
: ECU, . p 41
34
Producto
Almacn
i.expo
PZoducte,
Almaniln
Dimensiones
TS. =IVO
Figura 3.6.: Ejemplo de aplicacin de la operacin pivoting
Tecnologa multidimensional. Se usan vectores o matrices multidimensionales para representar las diferentes estructuras multidimensionales. Este tipo de tecnologa se denomina
MOLAP (Multidimensional OLAP, OLAP multidimensional).
Tecnologa relacional. Se usan elementos relacionales como tablas, columnas, claves primarias, ajenas, etc., para poder definir las diferentes estructuras multidimensionales. Este
tipo de tecnologa se denomina ROLAP (Relational OLAP, OLAP relacional).
Debido a su alta popularidad y a razones de eficiencia y escalabilidad, la tecnologa relacional
es la ms usada actualmente para la implementacin de almacenes de datos. Por tanto, este
captulo se centrar en la definicin del modelado lgico segn una tecnologa relacional.
El modelado multidimensional relacional tiene el principal referente en el trabajo de Ralph
Kimball, el cual propone un tipo de esquema llamado esquema estrella (y diferentes variantes)
para representar las diferentes estructuras multidimensionales mediante el uso de tecnologa
relacional, haciendo uso del modelo relacional.
3.2.1. Esquema estrella

En un esquema estrella los hechos y las dimensiones se corresponden con tablas de hecho y
dimensin (ver ejemplo de las figs. 3.7 & 3.8). En concreto, un esquema estrella consiste en
una tabla central (tabla de hechos) y un conjunto de tablas de dimensin. Las caractersticas
principales de este tipo de esquema son:
Cada tabla de dimensin contiene una clave primaria no compuesta.
Cada una de las columnas de la tabla de hechos que forma parte de la clave primaria
compuesta es una clave ajena que referencia a la clave primaria de cada dimensin. Es
decir, la clave primaria tabla de hechos est compuesta por claves ajenas a las tablas de
: ECU, . p 42
Producto
producto cod
producto nombre
producto color
atar ca_ead
inarta_dirIchs
falai I ia_cod
faini I ia_den
tipo_ rad
Grupo _ce d
Tab las de
tiimemiOni
V entas_produ d os
andiseto ciad
almacn cod
c
cod
kigsnp9 _451
canlidad vendida
precie
toial_preci o
Cliente
cl1111P
cnd
cliente nombre
iudad
comunidad
"Caba de
iierhos
/I I mactIn
macu
a from:Cu nombre
almacn. _carca
andad
provincia
Zona_ventas
-cflrnunidad
Tiempo
liempo_cod
ella
vacaciones
mes
offlo
Figura 3.7.: Ejemplo de esquema estrella
dimensiones. Por tanto, la tabla de hechos tiene una relacin muchos a muchos con las
tablas de dimensiones.
Cabe destacar que la tabla de hechos almacena datos que se generaron a partir de eventos
ocurridos en el pasado y que no van a cambiar en el futuro. Mientras tanto, las dimensiones
guardan informacin descriptiva que puede aparecer asociada a varios hechos y se utilizan para
restringir las consultas de la informacin de la tabla de hechos. Debido a esto, las tablas de
hecho ocupan ms espacio que las tablas de dimensin.
Una caracterstica importante que se debe tener en cuenta al disear un modelo multidimensional a nivel lgico es la denominada granularidad. La granularidad est relacionada con la lista
de dimensiones que definen el alcance de las medidas almacenadas en la tabla de hechos y con
el nivel de detalle bajo el cual se almacenan los datos (por ejemplo, transacciones individuales,
resmenes diarios, resmenes mensuales, resmenes anuales, cualquier otro perodo de tiempo).
Este nivel se define en funcin de las necesidades del negocio:
Alto nivel de detalle: detalles de las transacciones de los clientes del banco.
Bajo nivel de detalle: resumen de las transacciones de los clientes del banco por mes.
La granularidad afecta al tamao del repositorio y a su grado de anlisis y est relacionada
con la flexibilidad a la hora de analizar los datos, ya que cuanto ms granulares sean los datos,
ms espacio requeriremos (ms datos tendremos), aunque ello nos permitir realizar anlisis con
mayor nivel de detalle (sobre esos mismos datos).
En cuanto a las tablas de dimensin, stas contienen datos "textuales" (alfanumricos) que
se encuentran almacenados de manera desnormalizada, por lo que son tablas que contienen
mucha redundancia de datos. En concreto, en un esquema estrella cada una de las dimensiones
corresponde con una sola tabla (ver ejemplo de la fig. 3.9). La desnormalizacin es una tcnica
: ECU, . p 43
36
CIIKLY
1
1
1
Prud uctoKey
Tiempo Itev
5 al.o Azimut
2
3
1 loc
2 Da
Figura 3.8.: Ejemplo de la tabla de hecho ventas (incluyendo instancias)

ca_c
produclo.. norribro
prolizt calsrr
marra cod
roducto cid
1
2
3
4
5
Producto nombre ....
Family Dese
Pulzwe M ilk L
N'OVE M ilk 1L .
Y oghurt Parco a I
P Roer
Aj ax
Producto3 ilictcom
Productut littec-s
Productor lictcos
PrudthittT.i Implen
Producto3 l m pina_
marca dir
fa -.odia cod
Lica
pa cod
Grupo COd
Figura 3.9.: Ejemplo de la tabla de dimensin producto (incluyendo instancias)

que consiste en unir el contenido de varias tablas en una sola con el fin de aumentar el rendimiento
de las consultas realizadas a costa de incrementar la redundancia de datos. Existen dos razones
principales por las cuales es beneficioso desnormalizar:
Mejorar el rendimiento: al eliminar el nmero de uniones entre tablas se mejora el rendimiento, ya que en un almacn de datos existe un nmero elevado de filas, siendo la unin
la operacin ms costosa de realizar.
Intuitivo: ms fcil para consultar por parte del usuario no experto.
Otros conceptos avanzados sobre el esquema estrella son: dimensiones degeneradas, tablas de
hechos sin hechos, claves autogeneradas, dimensiones que cambian lentamente o tablas y datos
de referencia. Estos conceptos se explican a continuacin.
Dimensin degenerada
Existen tablas de hechos que contienen informacin sobre una dimensin que no existe fsicamente. Esta dimensin se denomina dimensin degenerada y se corresponde con una columna
: ECU, . p 44
37
Ventas_productos
producto cod
almacn ocd
diente cod
tiempo cod
Numera cket
cantidad vendida
precio
Ticket
Numero tid;iet
total precio
Figura 3.10.: Ejemplo de dimensin degenerada nmero de ticket

14~ dirr
ql1W_
Mip"ra_Eosi
Figura 3.11.: Ejemplo de tabla de hechos que no es un hecho
de la tabla de hechos. Esta columna forma parte de la clave primaria de la tabla de hechos. Las
dimensiones degeneradas se usan frecuentemente cuando la granularidad de la tabla de hechos
representa el nivel transaccional haciendo referencia a identificadores presentes en el "mundo
real": nmero de ticket (ver fig. 3.10), cdigo de factura, cdigo de albarn, etc. Mediante una
dimensin degenerada se indica que hay una relacin muchos a muchos en particular entre una
tabla de hechos y una tabla de dimensin.
Tabla de hechos que no son hecho
Las tablas de hechos que no son hechos tienen la particularidad de que no contienen medidas o
atributos de anlisis. Esto es debido a que su finalidad es recoger la ocurrencia de un evento. Por
ejemplo, al analizar las clases que un profesor imparte de ciertas asignaturas, se puede desear
estudiar la ocurrencia o no de una clase en un cierto perodo de tiempo pero sin analizar la
duracin de dicha clase (ver fig. 3.11).
Claves autogeneradas
En cuanto a la clave primaria de las tablas de dimensin, stas pueden ser de dos tipos:
Autogeneradas, las cuales representan un valor entero que se va incrementando de manera
automtica cada vez que se inserta una fila. Este tipo de claves aumenta el rendimiento (al
definir ndices con un ms rpido acceso) y son ms fciles de manejar para los procesos
ETL (Extraction, Transformation, and Loading, extraccin, transformacin y carga).
Con significado semntico, las cuales tienen una correspondencia con alguna clave presente
en el mundo real. Por ejemplo, el DNI sera una clave con significado semntico para una
persona.
: ECU, . p 45
38
Estaco actual
Clave narrarla
; Nmero Telefono
401 I 913555099:11
Despus de cambios
Vino piimans
Narner0 Telfono
cm 1~51111
Figura 3.12.: Ejemplo de la solucin 1 para las dimensiones que cambian lentamente
Dimensiones que cambian lentamente

Las instancias de dimensiones se pueden considerar fijas a lo largo del tiempo. Sin embargo,
a veces se desea registrar cambios que puedan suceder en algunas dimensiones para seguir
analizando datos histricos. Normalmente, estos cambios se producen en la descripcin de ciertas
dimensiones como productos o clientes. Existen tres soluciones bsicas y dos hbridas propuestas
por Kimball. Las soluciones hbridas son ms flexibles aunque presentan una mayor complejidad
de manejo. A continuacin, se resumen estas propuestas:
Solucin 1. Esta solucin es la ms sencilla de todas y consiste simplemente en sobreescribir

el valor antiguo en la fila correspondiente de la tabla de dimensin. Por tanto, la fila registra el
ltimo valor vlido por lo que se pierde la habilidad de analizar "la historia". Se suele utilizar
cuando el valor antiguo deja de tener significado o cuando el cambio en la dimensin se produce
por un error que se debe corregir. Ejemplos: descripcin o nombres nuevos para los productos.
Ver un ejemplo en la fig. 3.12, done el nuevo nmero de telfono substituye al anterior.
Solucin 2. Esta solucin consiste en aadir una fila nueva utilizando un nuevo valor de clave
autogenerada, lo que permite registrar el cambio del valor de un atributo en una dimensin.
Para ello, es imprescindible utilizar claves autogeneradas, aadiendo un campo que identifique
cul es el valor actual. Dentro de esta solucin se pueden utilizar tambin dos atributos para
registrar la fecha de comienzo y fin de validez de cada instancia. Esta solucin presenta dos
problemas: el primero radica en que necesita de almacenamiento extra para los nuevos atributos
creados, y el segundo es la necesidad de chequear cul de las filas contiene la versin vlida de
los datos. Adems, una caracterstica de esta solucin es la segmentacin de los datos histricos,
ya que la tabla de hechos queda particionada. Por ejemplo, dos productos distintos con claves
generadas distintas estarn registrados en las ventas, cuando en realidad se refieren al mismo
producto. Por tanto, para definir las consultas necesarias, se deben definir restricciones sobre el
atributo que ha cambiado el valor. Si estamos interesados por el mismo producto, entonces se
actuar sobre la clave primaria original.
Cabe destacar que esta solucin suele ser la ms utilizada para el tratamiento de las dimensiones que cambian lentamente. Ver un ejemplo en la fig. 3.13, donde una nueva fila es introducida
para reflejar los cambios en el cdigo postal.
Solucin 3. Consiste en aadir atributos para registrar el valor nuevo y el inmediatamente

anterior. Suele utilizarse en cambios mnimos como, por ejemplo, la redefinicin de una descripcin de producto. Es deseable usar esta solucin si se quiere seguir la historia tanto de los
valores antiguos como de los nuevos. Dentro de esta solucin se puede aadir un atributo que
: ECU, . p 46
31)
Estado actual
cieve pherinna
Despus de cambios
r Clave primaria
CF.
002
CP
19104
COS
191 03
CO2
19104
Estado actual
Despus de cambios
Glive pnrnano
Cr4Yo parrializ
CPaclual
CP actual
CP anterior
002
1004 I NIJLL
CP anterior
11 C
1ignota
19104
indique la fecha efectiva. Al utilizar la misma clave autogenerada, esta solucin se utiliza en
pocas ocasiones debido a que solamente permite analizar los datos de la tabla de hechos o bien
por el valor antiguo o bien por el nuevo. Ver un ejemplo en la fig. 3.14, donde se definen dos
campos para almacenar los dos ltimos valores del cdigo postal.
Solucin hbrida 1. Se utiliza cuando los cambios son predecibles con versiones mltiples que
se superponen. Esto es posible ya que existen cambios predecibles y regulares. Por ejemplo, si se
conocen los aos de anlisis de ventas y se pueden consultar el estado del distrito en cada ao.
Solucin hbrida 2. Se utiliza si los cambios no son predecibles con versiones simples que se
superponen. Esta solucin se utiliza si existen cambios irregulares e impredecibles, existiendo
una necesidad de preservar los valores histricos. Ninguna de las soluciones estndares anteriores
contempla estas dos caractersticas, por lo que esta solucin combina aquellas de tipo 1, tipo 2
y tipo 3. En concreto, se realizan las siguientes acciones:
Se aade una nueva fila para capturar los cambios.
Se aade una nueva columna para controlar los valores actuales.
Se utiliza una aproximacin de tipo 1 para cambios de valores muy recientes donde la
historia no interesa.
Otros mtodos. Existen otros mtodos que utilizan marcadores (flags) para el manejo de los
cambios. Estos mtodos se describen a continuacin:
Registrar versiones con flags. Como se puede observar en el ejemplo de la fig. 3.15.
Utilizar la clave primaria de los sistemas OLTP con flags. Como se observa en la fig. 3.16.
: ECU, . p 47
Estado actual
Despus de cambios
Clava primaria
Clava enmara
Miren de versin
NLIrn ere de versin
Raz salsa i
Flag animal
rEatarlo chal
ratedu Mai
000 Trtsi M
002 033 Falaa5 M

032
O01
Toua
DA
Figura 3.15.: Ejemplo de solucin para las dimensiones que cambian lentamente
Estado actual
Despus de carnblos
Carda prinins
Clave primaria
cliente fEl
ZP., 1. la
CP
1 1 1 10104
Echa
Trua Y14123321
CP
AL-bai
202
111
13107
Fecha
Trua 52112001
DCQ
111
19104
esta 551.121:100
Modelar eventos con flags utilizando claves del OLTP (ver fig. 3.17).
Modelar el estado con la clave primaria del OLTP y fiags. Un ejemplo de esta solucin se
puede observar en la fig. 3.18.
Tablas y datos de referencia

Otro tipo de elementos utilizados a nivel lgico son las tablas y datos de referencia (lookup
tables). Estos elementos proporcionan el apoyo necesario para la gestin de las dimensiones ya
que mediante su uso se reduce el volumen del almacn de datos. Ver un ejemplo en la fig. 3.19,
donde se define una lookup table para la tabla de produtos.
Estado actual
Chava primara
Evtada civil
Despus de cambios
Clave primaria
Ar
Momento del verle

ocie
13:00 1,1r2000
Estada civil
I Flag sclual
FA
H 202
Mcirnuntc del evento.

15:005/31/2001 S True
13:00 1#1,20IXI
Falle
: ECU, . p 48
-11
Estado actual
Despus de cambios
Fecha
nom
corrieraD final
ww
NuLLIF-1. ! 202
111
111/2900
1 902
111
11111998
Feche
S
u Fecha corniena
cae azoo iflil
fI
NULL
Trame
himno S nihil
Tablas de hechos ventas

pro _El
al n'imn _id
ventas euros
ventas unidades
/
Tabla nem
Semana
Ahe
Tabla Pro
Pro d
ep d
Pro_Lookap
Pro jd
PrO_Cle6C
Figura 3.19.: Ejemplo de tabla de referencia
3.2.2. Esquema de constelaciones de hechos

Este tipo de esquema es una variante del esquema estrella. En el que la diferencia radica en
que en el esquema de constelaciones de hechos, adems de la tabla de hechos base, se define una
tabla de hechos para cada nivel de agregacin. Por lo tanto, en realidad contiene ms de una
tabla de hechos (de ah su nombre). Este tipo de esquema acelera la consulta de datos agregados,
pues ya se almacenan ciertos hechos preagregados (sin necesidad de computar las agregacin ad
hoc)
Como inconvenientes, este esquema requiere el acceso a diferentes tablas para navegar por
las jerarquas debido a que cada tabla de agregados se usa para calcular un nivel determinado.
Adems, el tamao de los metadatos aumenta, haciendo ms difcil su gestin y mantenimiento,
ya que para cada carga nueva de datos se ha de recalcular todas las tablas de hechos. Un ltimo
inconveniente consiste en que puede haber requisitos que necesiten del concurso de varias tablas.
Una caracterstica de este tipo de esquema es que los requisitos deben tenerse en cuenta de
antemano.
Como ventajas, cabe destacar que este esquema posibilita el acceso rpido a datos precalculados, reduciendo el uso de los recursos computacionales. Adems, mientras que en los sistemas
transaccionales los datos estn poco resumidos, en el esquema de constelaciones de hecho los
datos precalculados estn muy resumidos.
: ECU, . p 49
42
?rodal
2111PLOLePti
macl nombre
al mac,t1 diTCC
pmlccia_aud
pnaluctu_nornbre
producto Dolor
marca c od
giudad
pt Ovincis
mares dircsIsa
forailis
familia des
trd
Zona vallas
Oc ama liad
Elrupg..cod
Woolo_proslx1 os
[i cule/
71Mtlijs,si
rdirsio sombra
ciudad
~lid caer.
Tiorroo
cootwaidad
Figura 3.20.: Ejemplo de esquema de constelacin de hechos

L9ud ad
red Melad
desoir. ciudad
0mbe
eupsli c i w
di re irn
:ul1
ircid IcamunIALAI
c omunidad
deicdpiles
zokpak
.0"11151"
7Atruzip
LIaLaela
Wad
ro& mai unid id
ono
arad
ad
Figura 3.21.: Ejemplo de normalizacin de la dimensin almacn en un esquema de copo de

nieve
3.2.3.
El esquema de copo de nieve se diferencia del esquema estrella en que alguna de las dimensiones
se normaliza segn los niveles de jerarqua. En la tabla dimensin se encuentran los valores del
mnimo nivel de jerarqua.
A primera vista, se podra pensar que este tipo de esquema podra ahorrar espacio en disco, sin
embargo, ya que comparadas con la tabla de hechos las tablas de dimensin son varios rdenes de
magnitud inferior en tamao, en la prctica el ahorro de espacio puede llegar a ser insignificante.
No obstante, una ventaja radica en que la consulta de atributos simples es ms rpida en este
tipo de esquema ya que se recorren tablas con menor nmero de instancias. Adems, se mejora
el rendimiento cuando la mayora de requisitos solicitan niveles de agregacin superiores, ya que
se disminuye el tamao de tablas a escanear.
En cuanto a los inconvenientes a la hora de usar este tipo de esquema, obviamente al aumentar
el nmero de tablas aumenta el nmero de operaciones de unin (join) que se deben realizar,
por lo que algunos requisitos pueden demorarse en exceso. As, la consulta de atributos que
implique ms de una tabla es ms lenta.
En cuanto a su estructura, este esquema puede resultar demasiado complejo para que los
usuarios finales definan sus propias consultas ad hoc a partir de ellos. Adems, se requiere una
clave primaria ms por cada nivel de jerarqua normalizado, por lo que aumenta la complejidad
de diseo y mantenimiento. Un problema prctico estriba en que este tipo de esquemas no est
soportado por todas las herramientas del mercado.
: ECU, . p 50
e lada d
Almario
tad dalia&
Cid r 'Edad
daperip rindok,
hillitau tea ciu
1 o 1 rum Lodazal
EllTinc
:nazi cie
ditaddWal.
/pialas
Comunidad
Pala
C od wonamidad
dorunp
habil mida _Ciudad
cod_paio
&mai p
1_13] drodea
cok sisclad
rVrataa_Prodaciaa
Codprodsclo
ihead
alnada
Cod dio
calad medida
COME
FITZGI
Fred tniul
manero diodo
Widipuldmd
Pod_p :adusto
Cni Andad
Caddk
dwddadyiaidida
Cara
prixiv
Enrayo catre
tilal bonwriGio
ni.un ere e calo
vea majada
VIZ11111 121111111911213
cliaLF redacto
Cid e-momia dad
Cod dio
edad vendida
costa
lamo
o MEI
local bee.estia
oima .i cb calca
Corrtunto
Cu d_pai:
do
wridutveniiida
C1311
artt
Ade
pecio Mal
lalal handl ci
=un. gl aula
Figura 3.22.: Ejemplo de esquema combinando constelacin de hechos y copo de nieve
Este tipo de esquema solo es recomendable para situaciones en las que el espacio en disco es
un problema grave. Sin embargo, se recomienda siempre normalizar una o dos de las dimensiones ms grandes, en lugar de normalizar todo el esquema multidimensional. Una buena recomendacin para este tipo de esquemas consiste en utilizar ndices bitmap para los atributos de
granularidad mnima. De todos modos, este esquema solo puede utilizarse cuando las ventajas
son muy explcitas: cuando el ahorro de espacio de disco es significativo o cuando existen muchos
atributos en los niveles ms altos de jerarquas. Cabe destacar que, estadsticamente, el espacio
en disco ahorrado utilizando esquemas de copo de nieve es del 1 % del espacio total en disco.
Se pueden utilizar esquemas de copos de nieve con constelaciones de hechos conjuntamente_
En la fig. 3.22 se muestra un ejemplo, donde varios copos de nieve aparecen combinados en un
mismo modelo de datos.
3.2.4.
Resumen de los diferentes esquemas
A continuacin, a modo de resumen, se listan las ventajas y desventajas de cada uno de los
esquemas multidimensionales descritos anteriormente:
Esquema estrella
Ventajas
Fcil de entender por los usuarios.
Reduce nmero de uniones fsicas por lo que se producen respuestas rpidas para la
mayora de las consultas.
Metadatos sencillos.
Soportado por la inmensa mayora de aplicaciones.//
Inconvenientes
: ECU, . p 51
44
El aumento del tamao de la tabla de hechos con datos agregados puede empeorar el
rendimiento general. Por ello, se recomienda tablas de hechos agregados al margen.
Las dimensiones tienen un tamao enorme. Un valor normal segn Kimball es de
alrededor de 50 atributos.
Es poco robusto o susceptible a cambios.
Ms lento de construir.
Esquema de constelaciones de hechos
. Ventajas
Los datos agregados no se almacenan con los del nivel de detalle ms bajo en las tablas
de hechos, por lo que aumenta el rendimiento al navegar por los datos almacenados
precalculados.
Inconvenientes
Un gran nmero de tablas de agregados por lo que se complica el mantenimiento de
los metadatos y existe una necesidad del usuario de conocer la existencia de dichas
tablas.
Algunos requisitos pueden necesitar consultar datos de varias tablas y mermar el
rendimiento general del sistema.
Vent ajas
Ms flexible y adecuado para requisitos.
Carga de datos (ETL) ms rpida y sencilla.
Directamente implementados por algunas herramientas.
Mejora considerablemente el rendimiento cuando un gran nmero de requisitos solicita
datos agregados o de niveles superiores de jerarquas ya que los requisitos escanean
un reducido nmero de filas.
. Inconvenientes
Aumenta la complejidad de mantener los metadatos debido al aumento del nmero
de tablas.
Si no se dispone de la suficiente cantidad de tablas de agregados, el rendimiento
general podra disminuir.
3.2.5. La dimensin tiempo
La definicin de una dimensin temporal es obligatoria en un modelo multidimensional, por
lo que necesita ser diseada cuidadosamente.
Una dimensin temporal (ver fig. 3.23) incluye perodos del tiempo de negocio y fechas especiales. Por lo tanto, debe de ser analizada y planificada minuciosamente considerando el rango
: ECU, . p 52
45
Tabla de hechos
Mai d
Tabla de hechos
Dia id
Tabla de hethos
D fa_ id
INm Tlempc.
tiald
Mes id
Cuatrirnestreid
Seirnestre_id
AND id
Di m_Tlerpo
Dla_i d
Mas_ id
Cazad meetrei d
Semestre id
Ao_ id
!desfleca l_id
Cual_
flaca'
_id
Se mester_fiacal_id
Afici_fisee Lid
D im Tiempo
raid
sr.
He* id
Y
Custrissestra
egitr bid
Figura 3.23.: Ejemplo de dimensin tiempo
de fechas relevante e identificando la granularidad correcta. Adems, se debe modelar de forma

que permita un anlisis flexible, por ejemplo, aadiendo atributos como da laborable, perodo
fiscal, principal evento o mes vacaciones.
Los tipos de consultas sobre dimensin tiempo pueden ser absolutas (ventas desde julio 1999
hasta julio 2000) o relativas (obtener ventas para el mes actual del ao pasado).
Por ltimo, resulta conveniente proporcionar cdigos de tiempo secuencial que identifiquen a
los elementos de las jerarquas, por motivos de rendimiento.
3.2.6. Otras consideraciones de diseo

En esta seccin se detallan otras consideraciones a tener en cuenta por el diseador a la hora
de implementar un almacn de datos.
Relaciones muchos a muchos entre hechos y dimensiones
Un ejemplo de esta situacin sera la de un hospital donde mi paciente puede tener varios
diagnsticos (ver fig. 3.24).
El primer problema es que solo se podra visualizar una instancia de la dimensin cada vez de
forma sencilla. Para visualizar todas las instancias relacionadas con el hecho existe una necesidad
de ms uniones entre tablas. Con el fin de saber la contribucin individual de cada instancia de
dimensin en el hecho, se suele utilizar los denominados weighting factors. Kimball propone el
uso de tablas puente (bridge tables) para deshacer la relacin muchos-a-muchos (ver fig. 3.25).
The Data Warehouse Bus Architecture

El trmino Data Wareh.ouse Bus Architecture fue introducido por Kimball para detallar cmo
construir todo el almacn de datos corporativo a partir de cada data mart. En concreto, se basa
: ECU, . p 53
46
Di gnstico
diagnstico cod ....j............\NN.r__
Diagristi co_att
Pwierite
paciente cod ,011
paciente nombre
ciudad
Factura_paciente
ffigt.m._
gtjsg_cod
Mdico cod
paciente_cod
'culpo codi
eantidad_fachira
precio
...
total _precio
...
muni dad
Figura 3.24.: Ejemplo de relacin muchos a muchos entre hecho y dimensin
Dignsiieo
eliajtomicocod
Diagnesticn alt
Tabla puontz de Grupo de

diagnsticos
assusinigu_smpa wad
Diagnostico cal
Weighting factor
Factura,_pacienix
diagritistipp kod
Mdico cod
pacienteM
tiempo ced
cantida reclina
precio
total_precio
Figura 3.25.: Ejemplo de tabla puente
: ECU, . p 54
47
en considerar la mnima granularidad del proceso de negocio que contempla. Con este fin se
utilizan las dimensiones y hechos comunes (conformed) a cada uno de los data marts.
Las dimensiones comunes son aquellas que existen en todos los data marts. Por ejemplo, una
tabla maestro de clientes o productos. Estas tablas se pueden mantener de forma independiente
a los data marts. Es importante que el diseador no obvie ni menosprecie la definicin de estas
dimensiones comunes a la hora de desarrollar el almacn de datos. Una prctica aconsejable es
definir las dimensiones segn el mnimo nivel de granularidad posible y utilizar claves autogeneradas para ello. Cabe destacar que este tipo de dimensiones puede ocupar el 80% del esfuerzo
del desarrollo total.
Como resumen, las ventajas del uso de dimensiones comunes son: una misma dimensin se
puede utilizar contra varios hechos, las interfaces de usuario y datos son consistentes y se permite
navegar entre data marts (drill across).
En cuanto a los hechos comunes (conformed facts), estos se refieren a las medidas utilizadas
en ms de un data mart. Ejemplos: beneficio, coste, precio etc.
: ECU, . p 55
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 56
Bibliografa
[1] A. Abell, J. Samos, and F. Saltar. YAM2: a multidimensional conceptual model extending
UML. Information Systems, 31(6):541 567, 2006.
[2] G. Booch, J. Rumbaugh, and I. Jacobson. The Uni ed Modeling Language User Guide.
Addison Wesley, 2005.
[3] M. Breslin. Data Warehousing Battle of the Giants: Conaparing the Basics of the Kimball
and Inmon Models. Business Inteltigence Journal, 9(1):6 20, 2004.
[4] L. Cabibbo and R. Torlone. A logical approach to multidimensional databases. Leeture
Notes in Computer Science, 1377:183 200, 1998.
[5] P. P. Chen. The Entity-Relationship Model - Toward a Unified View of Data.
Transactions on Database Systems, 1(1):9 36, 1976.
ACM
[6] W. H. Inmon. Building the Data Warehouse. Wiley, 1996.

[7] M. E. Jones and I-Y. Song. Dimensional modeling: Identification, classification, and evaluation of patterns. Decision Support Systems, 45:59 76, 2008.
[81 R. Kimball. The Data Warehouse Toolkit: Practical Techniques for Building Dimensional
[9] Sergio Lujn-Mora, Juan Trujillo, and II-Yeol Song. A UML profile for multidimensional
modeling in data warehouses. DataE.4 Knowledge Engineering, 59(3):725 769, 2006.
[10] Stefano Rizzi Matteo Golfarelli. Data Warehouse Designa: Modero Principies and Methodologies. McGraw-Hill, 2009.
[11] J.N. Mazn, J. Lechtenhkger, and J. Trujillo. A survey on summarizability issues in
multidimensional modeling. Data ' Knowledge Engineering, 68:1452 1469, 2009.
[12] J.N. Mazn and J. Trujillo. An MDA approach for the development of data warehouses.
Decision Support Systems, 45:41 58, 2008.
[13] 0. Romero and A. Abell. A Survey of Multidimensional Modeling Methodologies. International Journal of Data Warehousing and Mining (LIDWM), 5(3):1 23, 2009.
[14] J. Trujillo, M. Palomar, J. Gmez, and I-Y. Song. Designing Data Warehouses with 00
Conceptual Models. IEEE Computer, 34(1466 75, 2001.
49
: ECU, . p 57
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 58
No veo lgico rechazar datos porque parezcan

increbles.
Fred Hoyle
Procesos ETL
. procesos ETL (Extraction, Transformaban, and Loading, extraccin, transformacin y

carga) son los encargados de transportar los datos que contienen las fuentes de datos al almacn
de datos asegurando la calidad de los datos que sern luego analizados mediante las herramientas
de explotacin. En este captulo, tras una introduccin a los procesos ETL, discutiremos las
opciones de diseo de estos procesos en funcin de la fase en la que se requieran: la de extraccin,
transformacin o carga.
ndice
4.1. Introduccin
51
4.2. Fase de extraccin
53
55
4.4. Fase de carga
60
65
4.1. Introduccin
Para introducir los procesos ETL, nada mejor que recordar la definicin de almacenes de
datos que dio Bill Turnan, uno de los pioneros de esta tecnologa:
Un almacn de datos es una coleccin de datos orientados por temas, integrados,
no voltiles y variables en el tiempo en apoyo de la torna de decisiones estratgicas.
de donde podemos destacar la cualidad de integrar mltiples fuentes de datos.
51
: ECU, . p 59
52
Captulo 4. Procesos ETL
Relevantes
tiles
Sistemas
operacionales
Extraer
a
Calidad
Transformar
Precisos
Cargar
Warehouse
Accesibles
Figura 4.1.: Importancia de los procesos ETL
La integracin de estas fuentes de datos se realiza mediante los denominados procesos de

extraccin, transformacin y carga o procesos ETL (del ingls Extraction-TransformationLoading). Estas tres fases en las que se puede dividir un proceso ETL se definen en base a
la extraccin de datos desde fuentes de datos operacionales y heterogneas, transformacin de
esos datos mediante operaciones de limpieza tales como conversin de tipos, normalizacin, eliminacin de valores nulos, etc. y su posterior carga en el almacn de datos dada una cierta
poltica de actualizacin.
Algunas tareas comunes de los procesos ETL son: la unin (7oin) de datos de distintas fuentes,
la agregacin de datos, la conversin a un formato comn, la generacin de claves derivadas, la
verificacin de la calidad de los datos, etc.
Con ello, los procesos ETL son de gran importancia para el xito de una arquitectura de
almacenes de datos. stos contribuyen a que los datos sean relevantes y tiles para la toma de
decisiones. En la fig. 4.1 se muestran algunas de las claves del xito de un almacn de datos en
las que los procesos ETL contribuyen, tales como la relevancia de los datos, su utilidad, calidad,
precisin y accesibilidad. Por la gran dependencia que tiene el almacn de datos de estos procesos
y dada su complejidad, los procesos ETL tienen un elevado coste en tiempo y recursos.
Consideraciones de diseo
Algunas consideraciones generales a tener en cuenta cuando se disean los procesos ETL son
las siguientes:
Definir una estrategia de calidad de datos para la empresa segn poltica de toma de
decisiones.
Definir el nivel de calidad ptimo de los datos.
Considerar la modificacin de las reglas de las fuentes de datos operacionales.
Documentar las fuentes de datos como paso bsico para comprenderlas.
: ECU, . p 60
53
Disear los procesos de limpieza (y sus tareas) de forma muy cuidadosa.

Los procesos de limpieza iniciales pueden variar de los procesos de refresco posteriores.
Datos incorrectos o engaosos producirn decisiones estratgicas errneas.
El coste de los procesos ETL es de aproximadamente el 50 % del presupuesto total de los
proyectos de almacenes de datos.
Actualmente, el diseo y mantenimiento de procesos ETL es todava un asunto ``pendiente"
Aunque existen varias herramientas en el mercado, no disponemos de modelo o metodologa
estndar para su diseo desde primeros pasos de un proyecto de almacenes de datos.
Las soluciones dadas al diseo de procesos ETL abarcan las rutinas convencionales en lenguajes de programacin de cualquier ndole (desde COBOL (COmmon Business-Orented Language) hasta los lenguajes de 4GL (Fourth-Generation programming Language) como C/C-F,
Java o Ruby), herramientas especializadas, procesos de conversin personalizada y expertos de
negocio. Algunos de los factores involucrados en tal diseo son: la investigacin para el desarrollo de nuevas tcnicas que mejoren las actuales, la dependencia con los tipos de fuentes de
datos (relacionales, web, etc.), el grado de estandarizacin de las soluciones comerciales y la
integracin de las fuentes de datos.
Una aproximacin de los pasos en el diseo de un proceso ETL sera el siguiente:
1. Seleccionar las fuentes para extraer datos.
2. Transformar las fuentes.
3. Unir las fuentes.
4. Seleccionar las estructuras destino a cargar datos (hechos, dimensiones, etc.).
5. Traduccin de los atributos de las fuentes en los destinos.
6. Cargar los datos.
El paso de transformacin tambin puede incluir limpieza de datos, por ejemplo, para detectar
y borrar errores e inconsistencias. Con todo ello, la creacin manual y mantenimiento de los
procesos ETL aumenta el coste de los almacenes de datos. Incluso cuando se disponga de una
documentacin adecuada para las fuentes de datos, la documentacin de un proceso ETL puede
alcanzar gran cantidad de pginas de cdigo, por lo que tambin se necesitan herramientas para
su gestin (como se ver en el captulo de metadatos).
As, a continuacin se describirn en profundidad los procesos ETL mediante la exposicin
de cada una de sus fases: (I) la extraccin de las fuentes de datos, (II) la transformacin de los
datos extrados y (III) su carga en el almacn de datos.

Existen diversos tipos de fuentes de datos: de produccin, archivos planos, internas o externas
a la organizacin que da lugar al almacn de datos, etc.
: ECU, . p 61
54
IMS
SAP
1782
Sistemas mdicos
VSAM
Prediccin
financiera
SOL
Oracle Financial
Oracle
Sybase
IRclb
Figura 4.2.: Fuentes de datos de produccin
B.D.
Operacionales
Repositorio
Almacn
Figura 4.3.: Archivos planos de datos
Fuentes de produccin
Las fuentes de datos de produccin (ver fig. 4.2) son las bases de datos de los sistemas de procesamiento de transacciones (OLTP (Ora-Line Transaction Processing, procesamiento transaccional en lnea)). Existen, por tanto, multitud de tecnologas que los implementan en funcin
del vendedor: IMS, DB2, Oracle, SAP, etc.
Factores a tener en cuenta para este tipo de fuente son: el sistema operativo, el motor de bases
de datos en los que operan, la plataforma hardware (por ejemplo, capacidad de clculo, tamao
de la memoria o los protocolos de comunicacin) y el sistema de archivos.
Archivos planos
Los archivos planos (ver fig. 4.3) son todo tipo de archivos de texto o binarios que se encuentran
dispersos en una organizacin y de los que se pueden cargar datos en el almacn de datos. En
este tipo de fuente de datos, se dan las siguientes caractersticas a comentar: existen archivos
en la empresa en los que se encuentran ya los datos histricos almacenados, son tiles para
anlisis de largos perodos de tiempo y para realizar la primera carga del almacn de datos y
generalmente requerirn transformaciones para habilitar su carga en el almacn de datos.
Fuentes internas y externas
Una clasificacin paralela de las fuentes de informacin es la que se da respecto a su pertenencia

a la organizacin que da origen al almacn de datos. As, las internas sern aquellas que estn
controladas por la empresa, mientras que las externas se situarn fuera de sta.
: ECU, . p 62
55
Compaas
especializadas
Informacin
B.Q.
Compradas
z7Competidores
Prediccin
Financiera
Web
I.N.E.
Cinco Das
Expansin
Repositorios
DAN.
Figura 4.4.: Datos internos segn el sistema de origen
Algunos ejemplos de fuentes de datos internas son las de ventas, marketing y finanzas. En
ellas podemos encontrar tanto hojas de trabajo o spreadsheets con datos estructurados como
documentos de cualquier tipo con datos no estructurados. En cualquier caso, dadas las necesidades de informacin de los analistas, puede ser necesario acceder a cualquiera de estos tipos
con independencia de la dificultad para extraer sus datos.
Por otro lado, el acceso a las fuentes de datos externas (ver fig. 4.4) depende del tipo de
tecnologa con la que implementen. Tenemos desde otras bases de datos (a las que se acceder
mediante los protocolos adecuados) de compaas especializadas, informacin de competidores
(en informes pblicos), predicciones financieras en la bolsa de valores y en general cualquier
recurso accesible a travs de Internet.
Respecto a las tcnicas de extraccin, existen las siguientes posibilidades: los programas en
C, COBOL. PL. SQL (Structured Query Language, lenguaje de consulta estructurado) para
las fuentes de origen accesibles mediante gestores de bases de datos, gateways para el acceso
transparente de estas bases de datos y herramientas de diversa ndole. Estas ltimas deben
elegirse cuidadosamente en funcin de criterios como el coste de adquisicin (que puede ser muy
alto) y mantenimiento (inclusive el propio coste de propiedad con el que muchas herramientas
cuentan), el grado de automatizacin que ofrecen y las capacidades para la limpieza de los datos.

La fase de transformacin de un proceso ETL toma sentido dadas las anomalas que existen
en las fuentes operacionales. Por ello, se requiere, entre otras tareas, limpiar los datos. Como
ejemplo, la fig. 4.5 muestra un caso tpico donde un tipo de datos complejos est almacenado
en la fuente de datos con distintas codificaciones. Gracias a los procesos ETL, estos datos se
traducen a mltiples campos donde la codificacin se uniformiza.
Tpicas anomalas son que normalmente no existe clave nica, de codificacin (un mismo tipo
de datos presenta diferentes formatos para su representacin) e inconsistencias en la ortografa.
Tmese como ejemplo el mismo de la fig. 4.5, donde aparece una misma entidad (Telefnica)
con mltiples codificaciones, tanto para su identificador, nombre y direccin.
: ECU, . p 63
56
CLINUM NOMBRE
DIRECC ION
90328575 Telefonica SA
Calle 12, Madrid
90328575 Telefonica
90238475 Telefonica
Calle doce, Madrid

Calle 12, CP 28080, Madrid
90233479 Telefonica Moviles

90233489 Telefonica Espaa
90234E189 Telefonica UK
Cf 12,28080 Madrid
Avenida Blase o I baez, Valencia
Av. Vicente Blanco rbarry ex, Valencia
90345672 Telefonica Internacional
Av. Blasca. lbanyez, Valencia
Figura 4.5.: Anomalas en las fuentes de datos
Nombre.N1
Apellidos
Salario
WRAPPER
Nombre
ApellidoiSala
Figura 4.6.: Wrapper para abstraer archivos planos en tablas de un modelo relacional
A continuacin se explicarn los operadores o transformaciones comunes que se pueden emplear para disear un proceso ETL.
Wrapper
El primero de ellos es el wrapper: un operador para transformar fuentes de datos nativos en
fuentes de datos basadas en registros. Este operador es til para realizar la transformacin de
los datos de las fuentes de datos del almacn.
Generador de claves
Otra operacin es la de generar una clave nica a partir de una clave compuesta en la fuente
de datos. Por ejemplo, la fig. 4.7 presenta una clave compuesta de producto donde se codifica
en un -nico campo desde el cdigo del pas hasta el del vendedor del producto.
Otro ejemplo de codificacin mltiple se muestra en la fig. 4.8 donde el sexo de una persona
se codifica con una letra (in o f), con un bit (1 o O) o con una etiqueta completa (masculino
Cdigo producto= 12 65431345
Cdigo
Nmero cOdoo
pais
Produrto...21.9:,,19!
Figura 4.7.: Claves compuestas
: ECU, . p 64
57
m,f
f
1,0
masculino, femenino
Figura 4.8.: Claves compuestas y generacin de claves simples
mima ilumine.
If ld nal in (rn ',1,rnaszu6inol

Chen .._
1,nuu.
m.f
iffield la 141J LL
timo
Olsef
Figura 4.9.: Generacin de claves a partir de claves compuestas con errores
o femenino). Todos ellos pueden ser unificados en otro formato distinto o convertidos a alguno
de ellos como es el caso de la figura.
Asimismo, cuando alguno de los datos de origen no se corresponde con un valor entre los
esperados (fig. 4.9), entonces se deben disear rutinas de gestin de error segn corresponda.
Conversin
Uno de los operadores ms tiles en los procesos ETL es el de conversin. Por ejemplo, en la
fig. 4.10 se muestra la conversin de unidades de medida, fechas y precios. Para cada tipo, se
necesita, por un lado, identificar el dominio de origen del dato y, por otro, disear la rutina de
conversin propiamente dicha, donde el dominio de origen se traduce al de destino. Para estos
dominios se debe tener en cuenta que existen mltiples formatos vlidos e incluso estndares y
que se pueden necesitar herramientas o filtros para preprocesarlos. En la fig. 4.11 se muestra tal
tipo de conversiones.
CM
cm
milmetros
::1/141161/YY
DD-Mon-YY
PAMDDJYY
1,000 GBP
USD 600
FF 9,990
Figura 4.10.: Operador de conversin
: ECU, . p 65
58
~-11111111
Figura 4.11.: Operador de conversin (2)
SE L ECT
FROM ta
tidire_15
WHE RE tab le_a key eh) a tabhi_h_kay
UN ION
SELECT __
FROM tilo le_a. Eible_b
WHE RE Itab 19_41.1my table_b.koky (+5
1ACME
[AcPiE
ACME
ACME Inc
Figura 4.12.: Operador de unin
Filtrado
Un filtro es toda operacin que devuelve solo los datos que cumplen cierta condicin. Con
los filtros se pueden transformar los valores nulos en el origen, ignorndolos, esperando a que el
usuario decida qu hacer con ellos, marcando las filas o extrayendo bajo condiciones establecidas.
Unin
El operador de unin permite combinar filas provenientes de mltiples fuentes en una nica
fila atendiendo a los valores de algunos de sus campos. Esta operacin se realiza como se muestra
en la fig. 4.12, donde se muestra la unin de dos consultas (select) de SQL.
Combinacin
El operador de combinacin sirve para integrar mltiples campos en una nica fila. Por ejemplo, si tenemos los siguientes datos: nombre, contacto y preferencias podramos formar una
nica fila con el nombre del cliente. Ante esto, es importante destacar que debemos asegurar
que el significado de cada elemento sea el correcto. As se evitan malas interpretaciones. Sin
embargo, establecer claramente el significado de los datos no siempre es fcil. Para paliar esta
situacin se debe documentar siempre que sea posible el significado de los datos en los rnetadatos
correspondientes.
Fusin (merge)
El operador de fusin de datos (ver fig. 4.13) toma varias fuentes de datos compatibles y las
fusiona en la salida.
: ECU, . p 66
59
111
Venta
1,12/98
12:00.61 Pica de jamn
510.011
112
Venta
1/2100
12:00:02 Pizza de queso
hilOD
1/3
Venta
irkau
12:00:02 Pizza de anchos
512.011
14
[levo'.
1/298
12:00:03 Pizza da anchoas
05
Venta
112198
12:00:64 Plana de salchicha
- 512.00
511.00
Valores de datos oi,claves artificiales

*del Venta
1/2/0
*hen Venta
1f2A8 1210:02 Pizza di
12"11/1
Figura 4.13.: Operador de fusin
Marcas temporales
Otra operacin til es la del marcado temporal de los datos. Permite as analizarlos a lo largo
del tiempo aadiendo marcas temporales, tanto a los hechos como a las dimensiones del almacn
de datos.
Clave sustituta
El operador de clave sustituta genera claves para el almacn de datos a partir de las de las
fuentes de origen. Por ejemplo, las ventas identificadas en el origen como SRC1, SRC2, etc., pueden
ser traducidas a DW1, DW2, etc., en el almacn de datos.
Agregacin
El operador de agregacin toma un conjunto de filas de datos y genera una nica fila con un
conjunto de registros cuyos valores son comunes para todas las filas de origen y otro conjunto
de registros como resultado de aplicar una funcin de agregacin sobre ellos. Esta tarea puede
realizarse durante la extraccin de los datos, durante su tratamiento en la staging carea o despus
de cargar los datos en el almacn de datos.
Respecto a los metadatos de los procesos ETL, se deben documentar tanto las reglas de
transformacin como los programas y algoritmos utilizados. Algunos de los datos para elegir la
herramienta adecuada para esta fase son: la carga de trabajo que soporta (nmero de operaciones
por unidad de tiempo), el uso de la CPU y del espacio en disco, el ancho de banda de la red,
el paralelismo, el tiempo de carga, la calidad de los mensajes al usuario, las capacidades de
monitorizacin y documentacin del proceso ETL, la funcionalidad ofrecida, la interfaz grfica,
el acceso a los metadatos de fuentes de datos y repositorio, el procesamiento de la entrada
y salida, las capacidades de limpieza, reformateo y auditoria, sus referencias y la curva de
aprendizaje.
: ECU, . p 67
4.4.
Fase de carga
El planteamiento general para la fase de carga de un proceso ETL es el siguiente. La carga

o loading es el proceso de llevar los datos del staging aren al almacn de datos. Este proceso
puede llevar mucho tiempo dados los grandes volmenes de datos que se manejan. Por ello,
se debe considerar la ventana de carga y planificar concienzudamente la carga para intentar
automatizar todos los procesos involucrados. Es previsible que en la primera carga el volumen
de datos sea mayor que en las posteriores. En cualquier caso, es el propio entorno organizativo el
que dictaminar en buena medida cundo realizar las cargas de datos: tpicamente, se planearn
en aquellos momentos en los que la carga de trabajo sea menor en las fuentes de datos. As, se
aliviar la potencia de trabajo requerida para las fuentes de datos sin que se detecten bajadas
en el rendimiento.
La primera carga del almacn de datos se har con los datos histricos ya almacenados en las
fuentes de datos. Dado que se necesita almacenar la historia de los datos, se deber planear una
primera carga masiva de datos. Para aliviar tal carga, se puede descomponer un proceso ETL en
distintas tareas ETL. Sin embargo, se seguirn requiriendo grandes cantidades de procesamiento
despus de la primera carga.
Las subsiguientes cargas del almacn de datos o refrescos se realizarn conforme el ciclo de
negocio. Se detectarn los perodos de menor actividad en las fuentes de datos para realizar la
carga en esos momentos. Esta es una tarea ms simple que la primera carga, pues idealmente
habr menos datos por cargar. Los ETL son menos complejos dado que hay menos rutinas de
procesamiento despus de la carga.
La estrategia de refresco ser la siguiente: (I) considerar la ventana de carga, (II) identificar
los volmenes de datos, (III) identificar los ciclos, (IV) conocer la infraestructura tcnica, (V)
planificar un rea de "trastienda" (staging) y (VI) determinar cmo detectar cambios. En lo
siguiente se comentarn cada uno de estos pasos.
Requisitos de usuario
En primer lugar, se deben considerar los requisitos multidimensionales de los usuarios. Ellos
definen tambin el ciclo de refresco. Asimismo, se deben documentar todas las tareas y procesos.
Para ello, se pueden consultar a los usuarios expertos.
Proceso de transporte
Para construir el proceso de transporte, se debern especificar: las tcnicas y herramientas

a utilizar, los mtodos de transferencia de ficheros, la ventana de carga, la ventana de tiempo
para otras tareas, los volmenes de primera carga y refresco, la frecuencia del ciclo de refresco
y el ancho de banda de conectividad.
Ventana de carga
Para considerar la ventana de carga se debe evaluar el tiempo disponible para todo el proceso
ETL. Esto se traduce en planificar, comprobar y monitorizar la carga de trabajo de las fuentes
de origen como se muestra en la fig. 4.14 donde los perodos de menor actividad del usuario
son de madrugada. Es precisamente en esos momentos cuando se debera entonces ejecutar los
procesos ETL. Planificar tal carga requerir de una estrategia en funcin del volumen de datos,
: ECU, . p 68
(31
4.4. Fase de carga
Pikldg d e dlo
da if EU aria
Parlodo de carga
1
3
am
12 pm 3
Prifbd d
Ca raa
J
6
12
Figura 4.14.: Ventana de carga de un proceso ETL
Datos
recibidos
File
1
Filo
2
Abrir
Nombre de fichero
leer
Tipos de fichero
ficheros
Nmero de filas
para
FTP Nmero de cargas
verificar
Primera vez de la carga
y
Fecha de fichero
analizar
Fecha de los refrescos
Registros del fichero- coup
Total - arnounts
Proceso
De control
3 arn I
Figura 4.15.: Ejemplo de carga (1)
la infraestructura tcnica, la novedad de los datos y los requisitos de los usuarios, pues ciertos
requisitos pueden significar una ventana de carga pequea.
Granularidad
En cuanto a la granularidad de los datos, se deben planear los requisitos de espacio: el tipo
de almacenamiento, las copias necesarias, los mtodos de recuperacin, el particionarniento y
la carga. Los niveles de granularidad bajos implicarn un elevado coste de carga (nivel de
procesamiento, ms disco, ms detalle), mientras que los niveles ms altos sern ms baratos al
necesitar menor detalle.
Plani cacin de la carga
Las figs. 4.15 & 4.17 muestran mi ejemplo de la planificacin de una carga. En primer lugar,
se obtendrn los requisitos de usuario. En segundo, se disear el ciclo de carga en base a estos.
Tras ello, (3) se actualiza el fichero de control con los datos de la carga a realizar. En (4), el
proceso de control comienza. El siguiente paso (5) es cargar el almacn de datos. Este paso se
realiza a las tres de la maana. Entonces se verifican, analizan y reemplazan los datos cargados
(6). A las seis, la indizacin de los datos comienza (7), se crean resmenes (8) y se actualizan los
metadatos (9). Tras ello, se realizan las copias de seguridad del almacn de datos (10) y se crean
las vistas para las herramientas especializadas (11). Con todo ello, los usuarios pueden acceder
: ECU, . p 69
62
Captulo
4. Procesos
o
Cargar en
Almacn
Verificar.
Crear
Ana izar.
resmenes
9:
Reemplazar kL)
Indexar
Actualizar
datos
metadatos
File
1
File
2
Caiga
aralela
3 am
6 am
Figura
9 am
4.16.: Ejemplo de carga (2)
71,
Crear
Vistas para
Herramientas
O Especializadas
Back up
Del
Almacen
13
_
(I)
Usuarios
Acceden
Datos
resumidas
Publicar
Acceso usuario
6 am
9 am
Figura 4.17.: Ejemplo de carga (3)
: ECU, . p 70
ETL
4.4. Fase de carga
63
a los datos resumidos (12), publicarlos (13) y a partir de las nueve de la maana empezar el
acceso tpico al sistema de almacenes de datos.
Refresco
Continuando con la captura de datos para refrescar el almacn de datos, sta se realiza de la
siguiente forma. Se capturan los nuevos datos de los hechos en primer lugar. Luego se capturan
los datos de las dimensiones que han cambiado. Para ello, se debe determinar el mtodo de
captura. Existen varios: reemplazar datos a gran escala, comparar instancias de bases de datos,
comprobar/escanear las marcas temporales (timestamping), lanzar los triggers en las bases de
datos de origen, escanear los archivos de log de stas. Por supuesto, para cualquier refresco, se
pueden utilizar tcnicas hbridas como combinacin de cualquiera de las anteriores.
Al refrescar existen dos estrategias. La primera es reemplazar a gran escala los datos ya guardados. Sin embargo, esta estrategia es cara, los datos histricos son limitados, se reemplazan los
perodos de tiempo y est orientada solo a la carga de data marts. La segunda, es la comparacin
de instancias de la base de datos actual con las pasadas. Esta estrategia es simple, pero todava
cara y necesita ficheros de cambios con los cambios de los datos operaciones desde el ltimo
refresco.
Los cambios para refrescar pueden identificarse, como se ha comentado, mediante el marcado
temporal de los datos de origen. Este mtodo permite una rpida comprobacin para Ios registros
cambiados desde la ltima extraccin, aunque se debe actualizar la fuente de datos con las fechas
de cada dato cuando se cambian a la par de que no es capaz de detectar los datos borrados.
Otro mtodo es el uso de disparadores en las fuentes de datos. Estos disparadores, a diferencia
del mtodo anterior, permiten identificar el cambio tan pronto ocurre. Los datos cambiados son
interceptados a nivel del servidor, aunque hace un uso extra de los dispositivos de entrada/salida
y necesita un mantenimiento extra.
Como ltimo mtodo, tenemos el uso de archivos de log. Mediante su anlisis podemos extraer
el conocimiento acerca de qu campos son los que se han actualizado. Se registran imgenes de
la base de datos antes y despus del cambio. Sin embargo, necesita el uso de check-points del
sistema. Pese a todo, es un mtodo muy comn para identificar los cambios a refrescar.
Con lo expuesto, podramos preguntarnos acerca de cul es el mtodo a elegir. Para responderla deberemos: analizar cada mtodo de forma individual, considerar una solucin hbrida si
un solo mtodo no es adecuado y considerar elementos como aplicaciones actuales, bases de
datos operacionales disponibles y tecnologa actual disponible. Por otro lado, la aplicacin de
los cambios se puede consultar las polticas de modelado esbozadas por Kimball en lo referente
a dimensiones y hechos que cambian lenta o rpidamente.
Tcnicas de transporte
En cuanto a las tcnicas de transporte, estas dependen de: herramientas, utilidades y lenguajes
de cuarta generacin (4GL), gateways, programas de copias personalizados. Pueden utilizarse
tambin rplicas, servidores FTP (Pile Transfer Protocol) o realizarse de forma totalmente
manual. Para aplicar realizar el refresco se debe tener en cuenta que: las herramientas adecuadas
tienden a ser muy caras, las utilidades son rpidas y potentes y los gateways no son siempre los
ms rpidos. Estos ltimos se emplean para acceder a otras bases de datos, proporcionar data
marts, soportar entornos distribuidos y proporcionar acceso en tiempo real si fuera necesario.
: ECU, . p 71
64
Deshabilitar Cargar Habilitar
restricciones datos restricciones
Crear Detectar Volver a

indices errores procesar
Figura 4.18.: Mtodo para la gestin de restricciones en la generacin de ndices
Pese a todo, independientemente de la alternativa elegida, suele necesitarse un tratamiento

posterior a la carga (una fase de posprocesado).
ndices
En cuanto a la definicin de ndices en el almacn de datos durante el proceso de carga, si
se calculan antes de la carga, es ms rpido que si se hace durante o despus de sta, pues se
debe aadir un tiempo adicional a la ventana de carga. Para generar ndices nicos se deben
gestionar las restricciones de integridad del almacn de datos como muestra la fig. 4.18, esto es,
deshabilitarlas antes de la carga del almacn de datos y volverlas a activar antes de la creacin
de indices.
Datos derivados y agregados

Durante la carga, es momento de generar las claves derivadas para el almacn de datos. Usar
tal tipo de claves (que se derivan de las de la fuente de datos), se mantiene la unicidad de
la fila, aunque se necesita una poltica y proceso administrativo para asignar las claves. Para
ello, se puede concatenar las claves operacionales con un cierto nmero. Este mtodo es fcil
de mantener y las claves generadas mantienen un tamao manejable. Sin embargo, el mtodo
ms adecuado es el de las claves sustitutas, donde la clave de origen simplemente se traduce a
la correspondiente clave de destino en el almacn de datos tomada de un cierto dominio (por
ejemplo, el de los nmeros naturales). Debe atenderse en este caso a que no tengan un significado
concreto salvo el de identificar unvocamente cada fila de datos. Por otro lado, las operaciones
de extraccin debern referirse a las tablas operacionales para asignar las claves sustitutas.
Respecto a la carga de datos agregados, solo hacer notar que durante la carga tambin debern
tenerse en cuenta tales elementos. Por ello, se puede necesitar tanto crear las tablas agregadas
correspondientes como cargar los data mares desde el almacn de datos.
Integridad y disponibilidad
Con todo ello, solo resta verificar la integridad de los datos ya cargados. Para esta tarea se
pueden cargar los datos en mi fichero o tabla intermedia y comprobar los totales en el almacn de
datos con totales antes de la carga. Algunas otras tareas de verificacin son: evaluar el estado de
la carga consultando el fichero de lag, evaluar si el proceso ha finalizado correctamente, todos los
datos han sido cargados o lanzar el proceso ETL de nuevo en caso de que hubiese habido algn
: ECU, . p 72
65
problema. Otras tareas asociadas son la actualizacin de los metadatos tanto de los procesos
ETL como de las herramientas de consulta, la publicacin de los nuevos datos (en funcin de
su disponibilidad, de las vistas del negocio y de los propios cambios) y considerar aspectos de
seguridad para los accesos no deseados.
Para que los datos estn disponibles, a veces se requiere de hasta 24 horas para realizar todo
el proceso de carga. Por ello, se debe llegar a un compromiso entre el tiempo de carga y el
acceso por usuarios finales. Las soluciones a este compromiso pasan por considerar copias de las
actualizaciones, tablas temporales o utilizar tablas separadas para reconciliar ambos tiempos.
Dado que los procesos ETL pueden ser realmente complejos como se ha tratado de exponer con
toda la problemtica tratada en este captulo, cualquier tipo de automatizacin al respecto ser
bienvenida. Las tareas a automatizar sern: las propias actividades de extraccin, transformacin
y carga, el procesamiento posterior a la carga, la actualizacin de los metadatos y la publicacin
de los cambios despus del proceso. Sin embargo, siempre puede ser necesaria la intervencin
humana para tratar las cuestiones imprevistas.

A modo de resumen, comentaremos los elementos principales en el diseo de cada una de las
fases estudiadas.
Para el diseo de los procesos de extraccin se deben analizar las fuentes y tecnologas de
origen y los tipos de datos, su calidad y propietarios. Como opciones de diseo tenemos la
gestin manual, personalizada, gat eways y de terceros o la rplica ya sea total o parcial. Como
elementos de diseo tendremos los volmenes de datos, actualizados y copias y la automatizacin
en funcin de la tecnologa disponible.
Para el diseo de los procesos de transformacin deberemos analizar las traducciones involucradas entre fuentes de datos y destino (el almacn de datos), las reglas de negocio, la granularidad de los datos, las claves o los metadatos, entre otros. Con ello, las opciones de diseo
se centran en seleccionar el lenguaje de codificacin (por ejemplo, PL/SQL), el replicado de
los datos, los clientes y terceros. Los elementos a disear sern el rendimiento, el tamao del
preprocesado y el manejo de restricciones de integridad y excepciones.
Para el diseo de los procesos de carga, el anlisis se centrar en los volmenes de datos a
cargar y sus actualizaciones y la distribucin en data rnarts de la arquitectura de almacenes de
datos. Para las las opciones de diseo tendremos la especificacin de rplicas, la personalizacin,
el lenguaje de programacin y las herramientas externas. En cuanto a los elementos a disear,
estarn los perodos permitidos de carga (las ventanas de carga), el particionamiento de los
datos y su distribucin.
Como ejemplo de una solucin comercial a lo expuesto en este captulo, tenemos la plataforma
Oracle. En ella, el proceso de extraccin se realiza mediante SQL*Loader desde ficheros planos
y bases de datos a tablas intermedias (la denominada staging aren). Mediante el entorno de
diseo visual proporcionado por Oracle (OWB, Oracle Warehouse Builder), este cdigo se genera
de forma automtica mediante modelos visuales sin necesidad de codificar explcitamente las
instrucciones de carga. La fase de transformacin se realiza mediante el modelado de los flujos
de datos y los operadores de transformacin involucrados que son luego traducidos por OWB a
cdigo PL/SQL de Oracle, mientras que la fase de carga final se realiza de igual forma atendiendo
al tipo de politica de actualizacin seguida (por ejemplo, insertando siempre los nuevos datos,
no cargando los datos en caso de que ya existiera un registro en el destino, etc.).
: ECU, . p 73
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 74
Bibliografa
[1] W. H. Turnan. Building the Data Warehouse. Wiley, 1996.

[2] R. Kimball. The Data Warehouse Toolkit: Practical Technigues for Building Dimensional
[31 R. Kimball and J. Caserta. The Data Warehouse ETL Toolkit: Practical Techniques for
Extracting, Cleaning, Conforming, and Delivering Data. Wiley, 2004.
[41 Oracle. Oracle Warehouse Builder (OWB). szww. oracle com./technology/1)r oduct s/
warehouse/index . html.
[5] P. Vassiliadis. A Survey of Extract-Transform-Load Technology. International Journal of

Data Warehousing and Mining (IJDWM), 5(3):1 27, 2009.
[61 P. Vassiliadis, A. Simitsis, and E. Baikousi. A taxonomy of ETL activities. In DOLAP,
pages 25 32, 2009.
67
: ECU, . p 75
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 76
El que no pueda guardar sus pensamientos,
jams sabr analizar grandes cosas.

Thomas Carlyle
Herramientas de explotacin OLAP
STE captulo presenta las principales herramientas de anlisis para las que se disea el almacn de datos. Estas herramientas no son otras que las denominadas herramientas OLAP (OnLine Analytical Processing, procesamiento analtico en linea). Para tal exposicin se ver en
primer lugar en qu consiste tal tecnologa. Luego se ver su arquitectura y los vendedores que
ofrecen herramientas comerciales. Estudiaremos algunos aspectos prcticos para su eleccin y
profundizaremos en dos de tales soluciones comerciales.
ndice
5.1. Qu es OLAP?
69
5.2. Arquitectura
72
73
5.1. Qu es OLAP?
La tecnologa OLAP se concibe en el contexto de la toma de decisiones empresariales. En
tal entorno, existen las siguientes variables que fundamentan tal tecnologa. Primero, existen
demasiados datos para procesar. Se habla de una sobreabundancia de informacin en la que es
muy difcil saber qu es lo valioso y qu lo superfluo. De ah, que directamente no se sepa qu
fuentes de datos contienen informacin relevante para el anlisis. En segundo lugar, el contexto
para los datos es el equivocado. No se presentan de una forma adecuada: cada dato est enlazado
al resto de formas no intuitivas para el analista y por ello, de difcil explotacin. Con un contexto
adecuado, cada dato se transformar en informacin valiosa acerca de la empresa. Por ltimo,
el analista recibe los datos tarde, en lugar de cuando se necesitan realmente. Las soluciones
69
: ECU, . p 77
70
Captulo 5. Herramientas de explotacin OLAP

Volumen de ventas
ft"!
Eo
L
o
616. ab.. C.1
46 rl
...
REO ION
DISTR GTO
VE h DE DOR
Roll-up -
Drill-down
El.
Figura 5.1.: Navegacin por un cubo de datos mediante roll-up y drill-down

Volumen de ventas
O
E;
L
Mini Va
0[171
t1".
Goupe
Elbe
Glyde
WhIla
"Diced" Data
Garr
/
G leas
Glyde
Sedan
VENDEDOR 11
Blue Red INNIe
COLO
Figura 5.2.: Manipulacin de un cubo de datos mediante slice-dice
previas a. OLAP no ofrecen la interactividad con los datos que sta ofrece y las sesiones de
anlisis deben planearse a priori pues si no, los datos no podrn consultarse a tiempo dadas
las elevadas necesidades de procesamiento. Con todo ello, en el contexto empresarial previo a
OLAP, se toman malas decisiones.
OLAP ofrece para solucionar tal situacin mi conjunto de funcionalidades que facilitan el
anlisis de datos multidimensionales para una toma de decisiones ms rpida e informada. Entre
otras propiedades, se tiene entonces: la naturalidad con que los analistas pueden consultar la
informacin, que se presenta en base a la metfora de cubos de datos, vistas mltiples de los datos
y operaciones intuitivas sobre esos cubos. Asimismo, OLAP permite el anlisis y la comparacin
de medidas en base a diversos factores, el procesamiento de los datos y relaciones entre ellos.
Como ejemplo, en la fig. 5.1, se muestra la navegacin entre cubos de datos a diferentes
granularidades o niveles de detalle. Esta navegacin se hace mediante los operadores OLAP de
roll-up (agregacin) y drill-down (desagregacin). En un cubo de ventas como el de la figura,
cuyas dimensiones son el color, localizacin del vendedor y modelo del producto vendido, se
puede alterar su nivel de detalle a lo largo de la dimensin de localizacin para analizar los
datos desde el vendedor, pasando por los distritos, hasta la regin de ventas.
: ECU, . p 78
5.1. Qu es OLAP?
71
Por otro lado, la fig. 5.2 muestra otra de las operaciones tpicas de OLAP, el slice-dice.
Esta operacin toma un cubo de datos y genera un subcubo con los datos que cumplen cierta
condicin. Por ejemplo, en la figura, se muestra el mismo cubo de datos en el que se ha hecho
una seleccin de los datos en base al nombre del vendedor.
Desde el punto de vista del analista, las herramientas OLAP permiten generar las siguientes
propiedades sobre unos datos que: se almacenan en grandes cantidades, son multidimensionales,
con mltiples tipos de relaciones, en situaciones complejas y con un cierto contexto o inters. Las
propiedades que se obtienen son: un procesamiento ms rpido dado que la tecnologa OLAP
emplea estructuras de datos orientadas al rendimiento, mejor comprensin pues los datos se
organizan de manera intuitiva para los analistas, un mejor comunicacin pues la interactividad
de la herramienta permite que el dilogo entre analistas y datos sea ms fluido y finalmente, con
todo ello, una mejor toma de decisiones en la empresa.
Con la visin intuitiva de la tecnologa de explotacin OLAP, vamos a describir, a continuacin, dos de las definiciones ms importantes que se dan en la actualidad.
e nicin 1: Las 12 reglas de Codd

La primera de las definiciones de OLAP la dio Codd, el creador del modelo relacional. Esta definicin consiste en un total de 12 propiedades que toda herramienta debe cumplir para
considerarse OLAP. Estas propiedades o reglas son:
Vista conceptual multidimensional mediante la metfora de cubo de datos o tabla multidimensional.
Transparencia en el acceso a fuentes de datos heterogneas y en el proceso de transformacin

de datos realizado por los procesos ETL (Extraction, Transformation, and Loading, extraccin, transformacin y carga).
Accesibilidad en los datos presentados a los usuarios con un esquema lgico sencillo de interpretar (esto es, el esquema estrella).
Rendimiento de informes consistente con lo que no se debera demorar en exceso conforme el

nmero de dimensiones crece.
Arquitectura cliente/servidor para sistemas abiertos y modulares.

Dimensionalidad general no limitada a tres dimensiones (3D) y no particularizado a ninguna
dimensin en concreto.
Gestionar matrices sparse (vacas) dinmicas que se debera adaptar a la variacin de almacenamiento y opciones de consulta de datos.
Soportar multiusuario es decir, mltiples usuarios actuando de manera concurrente.

Operaciones a travs de dimensiones no restringidas y por ello no limitar las relaciones entre
las celdas de datos.
Manipulacin de datos intuitiva para los usuarios.

Informes exibles para que los usuarios sean capaces de imprimir solo aquello que necesitan.
: ECU, . p 79
72
Dimensiones y niveles de agregacin no limitados donde se debera soportar al menos 15 dimensiones y, preferiblemente 20.
De nicin 2: FASMI
Sin embargo, la definicin de Codd, a menudo resulta compleja pues involucra muchas propiedades y muchas de estas ya constituyen un factor comn para no solo herramientas OLAP
sino de todo tipo. Por ello, Nigel Pendse define OLAP mediante las siglas FASMI, esto es:
Fast el tiempo de respuesta de la mayora de las consultas debera ser menor de cinco segundos.
Analysis lgica del negocio relevante y anlisis estadstico que sea suficientemente simple para
los analistas no expertos
Shared gestionar mltiples actualizaciones de forma segura y rpida

Multidimensional proporciona una vista conceptual de los datos a lo largo de varias dimensiones.
Information capacidad para gestionar todos los datos relevantes y la informacin derivada requerida.
Con esta definicin, se proporcionan argumentos ms acordes con la situacin actual de
OLAP, donde la tecnologa de explotacin se caracteriza por el acceso intuitivo y rpido a

datos multidimensionales en base a la metfora de cubo de datos.
5.2. Arquitectura
La tecnologa OLAP tiene por arquitectura tpica aquella donde el almacn de datos constituye el repositorio de datos al que acceder a travs de las herramientas OLAP. Esto hace que
el acceso sea fcil y eficiente, mediante una vista multidimensional de los datos de las fuentes,
una configuracin cliente/servidor como recomendaba Codd, y que se puedan dar operaciones
de navegacin complejas sobre los datos.
Sin embargo, tambin cabe la posibilidad de que las herramientas de explotacin OLAP
accedan directamente a las fuentes de datos para recoger la informacin necesaria para el anlisis.
Sin embargo, en estos casos, el rendimiento en el acceso puede verse mermado dado que las
fuentes de datos no fueron diseadas para la explotacin OLAP.
En cuanto al servidor OLAP en esta arquitectura, existen dos alternativas clsicas en funcin
de la tecnologa con la que se implemente. En primer lugar, los servidores MOLAP (Multidimensional OLAP, OLAP multidimensional), o de OLAP multidimensional, manipulan los
datos sobre bases de datos en las que estos se representan directamente como dimensiones y
hechos mediante estructuras matriciales que potencian el rpido acceso. Por otro lado, tenemos
la tecnologa ROLAP (Relotional OLAP, OLAP relacional), de OLAP relacional, donde los
datos se almacenan en estructuras de datos relacionales (tablas). Como ventaja de esta aproximacin est que es ms usada dado que la tecnologa relacional est muy difundida. Sin embargo,
el rendimiento que se puede obtener con ella y la funcionalidad ofrecida puede ser menor de no
gestionarse correctamente el rendimiento ofrecido.
: ECU, . p 80
000
o o Hyperionr
73
~soft
APPribr
COGM
I OS'
LlgN [ SI;OBIEtrs.
CARTESIS .
a DVTUM
crystai dedsions
Figura 5.3.: Principales vendedores OLAP del mercado

Dada la importancia de la tecnologa OLAP para la correcta toma de decisiones en la empresa,
existen una gran cantidad de empresas que ofrecen servicios de tal tipo. En la, fig. 5.3 se muestran
algunos de los ms importantes. Entre ellos, cabe mencionar marcas ampliamente conocidas
como Oracle, Microsoft, Cognos, BusinessObjects, Hyperion, IBM o SAS.
Tomando los datos del informe (ver fig. 5.4) acerca de las tecnologas OLAP que Pendse ofrece
cada ao a travs de la pgina web The OLAP Report, se muestra el ratio de mercado que tiene
cada vendedor. Se observa que los principales vendedores son Hyperion y Microsoft, seguido de
Cognos y MicroStrategy. Por otro lado, la fig. 5.5 muestra la tendencia en los ltimos aos que
han seguido las ventas de estas herramientas para los seis ms vendedores ms importantes.
Puede observarse aqu que las soluciones de Microsoft, Hyperion y Cognos han estado ganando
cuota de mercado en contra del resto. Cabe destacar el caso de Microsoft donde el crecimiento
ha sido sensiblemente superior al del resto de sus competidores.
Como aspectos prcticos a considerar en la eleccin de una herramienta o plataforma OLAP,
tenemos los siguientes:
Evaluacin precisa de datos acerca de lo que los usuarios necesitan realmente y no lo que dicen
necesitar, pues a menudo hasta que no se tiene la plataforma desplegada, el usuario no

sabe con certeza qu es lo que realmente necesitaba.
Usuario nal participa en cada fase del proyecto.
Requisitos sern confusos, por ello, deberemos tener estrategias para formalizarlos y documen-
tarlos.
Almacenamiento, arquitectura y procesamiento ser lo ltimo, pues solo tras comprender el
negocio se puede seleccionar con precisin la tecnologa adecuada.

Cuidado con consejos parciales de vendedores OLAP concretos pues nos darn una visin
sesgada de todas las posibilidades y opciones que ofrece la competencia.
: ECU, . p 81
21%
2.4%,_
2. 511- -12.5%
21.3'
Hyperion Soluticns Microsoft

a Coplas
Oracle
tylicro Strategy
Appld
e Cornshare
i. Other
131J 51 ri ess Object 5

CarlesisiRte
ISM
Figura 5.4.: Ratios de vendedores del mercado OLAP
OLA.? maritei 5 haga trend

ISK-Tsmace
25%
10%
euree:
The OLA P Frepart
Y",0,49,.C...1 con.
0%
1!}09 .1540 2941 2407 2 003 211.1
Figura 5.5.: Tendencia de mercado en herramientas OLAP
: ECU, . p 82
75
Estandarizacin y dogmas no son buenos pues un nmero limitado de herramientas OLAP

podran cubrir varias aplicaciones.
Asimismo, otros elementos adicionales son: la fiabilidad y rendimiento de las consultas, la
flexibilidad e integracin, la capacidad y escalabilidad de la solucin, el crecimiento de la base
de datos exponencial, el coste total y los cambios tecnolgicos que puedan llegar a producirse.
Caso de estudio
Como caso de ejemplo, vamos a describir la plataforma de Oracle y Cognos. Como panorama
general, Oracle proporciona herramientas de acceso a datos de los siguientes tipos: MOLAP,
ROLAP, DSS (Decsion Support System, sistema de apoyo a la decisin), reportiag (generacin de informes) y minera de datos (que veremos en el siguiente tema) mediante la integracin
con otros vendedores (partners). Adems, proporciona servicios de consultora y docencia para
sus soluciones. Concretamente, en almacenes de datos, Oracle cuenta con la herramienta para
disearlos, de nombre OWB (Oracle Warehouse Builder). Por otro lado, el acceso a los datos
se realiza mendiante Oracle Discoverer orientado a los gestores del negocio y el Oracle Express orientado a los analistas. Tambin cabe destacar que la plataforma de explotacin soporta
tecnologa web.
La tecnologa Express de Oracle (el servidor MOLAP de Oracle) permite el anlisis y modelado multidimensional, en contraposicin con la solucin clsica con bases de datos relacionales.
Express da soporte para Express Objects, Express Andyzer, Express Financial y Express Sales
Analyzer. Por ltimo, decir que tal solucin est basada en la tecnologa internet/intranet.
En cuanto al Oracle Discoverer, ste se divide en varias herramientas: Discoverer Desktop para la explotacin de datos multidimensionales por los analistas finales, una capa final de usuario
(End User Layer, EUL (End-User Layer)) que abstrae la capa de datos subyacente y el Discoverer Administrator que se emplea por los diseadores OLAP para especificar metadatos OLAP
sobre fuentes de datos relacionales. Las ventajas de esta solucin es su facilidad de uso dado
que est basada en el empleo de wizards que guan al analista en el proceso de consulta que se
efecta mediante una interfaz sencilla. Otras ventajas son el rendimiento ptimo que se consigue
mediante tcnicas de caching (almacenamiento temporal) de cubos de datos y procesamiento de
consultas en el servidor, junto con la explotacin y exploracin de datos flexible. Como ejemplo
del tipo de informes generados, en la fig. 5.6 se muestra una tabla resumen fruto de un anlisis
OLAP de las notas obtenidas por los alumnos registrados en una plataforma educativa internacional. La tabla muestra tales datos desglosados por fecha (meses) y lugar (pases, provincias
y ciudades). As, con este tipo de herramienta, los analistas pueden navegar por los datos de
manera intuitiva.
En cuanto a la EUL de Oracle, cabe comentar que est diseada para esconder la complejidad de las bases de datos subyacentes. En ella se permite as definir caminos de agregacin,
crear y mantener datos resumidos y redireccionar las consultas de forma automtica hacia esos
resmenes con objeto de acelerar el rendimiento.
La fig. 5.7 muestra el concepto que hay detrs de la EUL. Mientras que la base de datos
contiene campos en un formato determinado para la mquina (a la derecha de la figura), gracias
a la EUL, el usuario slo percibe los datos de forma intuitiva, es decir, en base a los conceptos
que modelan (direccin del cliente y total de ventas en la figura).
Por ltimo, respecto a la plataforma web de Oracle, esta permite un acceso rpido y fcil a
travs de cualquier navegador web. As se amplia la portabilidad de la solucin OLAP y facilita
: ECU, . p 83
76
Capitulo 5. Herramientas de explotacin OLAP
02 U1 aL 109i I7iv.t.,7e540 [DUO j
hin de Eso 71107
.f] 0044.7 Eike,
6107
hrUlia.
Fe
Grif Venier
rases _
lr
o Lugar de Nacimiento de los lti07
n1
5 Anos
gZ=EZIM
awn.
2 1215
10..
A. i
A.
A.
1019
3,67
1,00
Cantabla
1,03
5090
7,03
P.M750
.1,16
AM..
11,0014
4117-41
7216
a
UnUa
Mana
101.50
507030
7137090
0.17,1 039
salamanca
X.1r,
77777
M'yo
Nzolerrtre
0.77.7
512errue
0J771
1,19
Affl
Affl
9,774
3,76
2,50
2,50
104
1,0
1,91
1,91
419
1,23
2,57
2,27
ME
1,20
7,7.1
7,7..1
1,59
1,24
4,71.
4,71.
3,44
AM
993
993
AH
7791.
sm
sm
5,25
3,90
9,75
1,65
5,40
4,01
3,02
0,25
5,04
5,10
4,05
4,70
5,00
4,03
9,53
3,43
3,94
4,65
4,11
4,62
5,25
4,50
3,00
4,07
3,75
0,22
4,65
4,57
21.
1'2'
0,00
91.
...49
5A5
0,50
1,9.
4,40
2
1.
2'2'
2500
4,60
4..
mas
1.
sffl
519
4,57
cl,a3
c...
2,49
9.42
4,
19
9.42
4,794,00
4,24
9,47
2,
42
2,07
407
4.6
4,.
4.83
4.16
5,91
%.
4..
.1,52
4.53
...
...
4,95
3,104,06
4.51
.7,57
2,22
2,02
4,69
4,02
4,52
4,52
4,90
4,32
71,20
71,20
2,55
0,55
457
$0
10]
5055
5.97
5.97
4,29
5,52
210
415
410
410
9,2]
2,14
/42
111
2,14
2,14
425
4,44
497
4,511
4,54
4,54
30]
150
1,69
1,69
3,99
2,50
197
1,00
515
5,25
3,69
058
4,72
3,18
4,03
Son
263
1,75
1,75
8,35
2,05
2,92
1,E10
7,00
7,00
1,92
5,36
2,7]
5,72
7,19
7,19
5,41
8,3E1
8,00
8,75
2,50
2,50
5,92
.1,512
4,99
2,99
4,19
..47
2,42
1,79
...
,609
5,744
.9.
6,25
5,00
1,52
6,25
5,00
1,52
6,1211212111
Fchntru
5,11
5,113
5,113
512
Lena
Mr.0.1T.rm492
Grona
li
Enero
5,76
50
519
4555
115
113
4,62
417
4,95
5555
5,99
3,00
400
105
125
130
20
20
5,57
7,67
7..00
6,50
6,55
4,60
6,47
5,55
7,11
4,00
4,00
5,00
6,10
4,75
0,40
3,25
3,25
2,44
66
5,25
4,75
4,75
4,15
4,15
0,377
100
426
4,71
4,15
517
50
50
4,45
3,51
519
3/5
3,55
3,50
7,85
5,75
7,75
2,70
2,70
5,00
rn
6,05
4,75
6,17
0,00
0,00
1,75
175
5,27
9,25
4,W
2,95
197
7.75
5,20
5,2,9
7,03
7,03
192
41.1
9,55
175
175
9,33
4,15
5,65
7,23
5.673^3,51.
7,12
344
5,63
7,30
3,44
50
2,22
5,39
5,54
4211
2,80
5,22
4RS
117
0624.11177N4nl.
Figura 5.6.: Consulta OLAP realizada en Oracle Discoverer Desktop
Direccin de diente
End
User
Layer
cl_diri
cl_dir2
Gi_Giuclad
I fatal de verlas
Figura 5.7.: Capa final de usuario (EUL) en Oracle Discoverer
: ECU, . p 84
77
Id21 sil
I ilelT)I
AL._
Mcds.111:
Yta
Lrza
10o
Liget C3
Cande:
Qui...1142
hir tie sawl
p:d.d..
IN La.. e -.ml
N sr.t. e d./ Frod.n.u.
CNdazil
1'40 da:
I Nirs-Pa F
Cele
witre 1-arvel
E ncergedo. dr venta;
Figura 5.8.: Diseo de modelos multidimensionales con Cognos
su uso. Para ello, se dispone de las herramientas adecuadas para administrar la configuracin
web. Entre ellas, destaca la gestin de resmenes, donde se actualizan los metadatos con la
informacin sobre los datos resumidos a la par que se generan y mantienen los resmenes.
Adems, se gestionan matrices sparse de forma automtica, con lo que su gestin se facilita
enormemente.
Aparte de la solucin de Oracle, nos gustara comentar brevemente tambin la solucin de
Cognos como ejemplo de plataforma MOLAP. Esta compaa dispone de varias herramientas
para la explotacin OLAP, donde destacan: Impromptu en la creacin de modelos multidimensionales bajo la arquitectura cliente/servidor, el Cognos Transformer para la creacin de cubos
multidimensionales a partir de los modelos multidimensionales generados por Impromptu, pero
tambin a partir de las propias fuentes de datos (no multidimensionales), y el Cognos Power
Play para visualizar los cubos de datos de forma sencilla.
Como ejemplo de la apariencia que ofrecen estas herramientas de Cognos, las figs. 5.8 & 5.10
muestran un proceso tpico de diseo donde se parte de un modelo multidimensional de los datos
que se necesitan analizar (figs. 5.8 & 5.9) para ofrecer al analista una interfaz usable para la
explotacin multidimensional mediante tecnologas OLAP (fig. 5.10).
Habiendo visto las diferentes alternativas y factores de diseo para las herramientas OLAP,
en el siguiente tema trataremos el uso de algunas tcnicas para la extraccin de conocimiento
de los almacenes de datos, como las tendencias en los datos o las reglas que siguen estos. stas
sern las denominadas tcnicas de minera de datos.
: ECU, . p 85
ks,
I lkolLhoz rryr Kop
Lreade Rodeo
Held*:
Pb de cene!
,m+,..gr..:1
IP bei
wrion 1211:11:11:3V 4 o n 19rib1121111

qeow.
C 1.,exle4
leer./ yn
0. 1.4.
Lemirde.
enhurn.
Hawih
C.
Cdow.lcel er.
(MIL
Creo
Cala 'Loro
Pa.
- Su
RawVraa
- UNID
-la 11 2.
prona
naa
- *ware
Ckded
Ah:te
- CaM9m..
-Cala
Be.oen
A LA..
11..4.:1
C Wle
Ikedalax
Selmenee
-AHala
-Lomat
Mes.
- Zamora
- LeMOD
Pardea
- Mude,
DIzerw9c de r.
Ouodchio
Ca
iwan ~rae
1.1.1
klmul Rapa
loa. L'eyrax
-1111.
k.
Red Pub.
Beehunee
IonFin., di
ktmaJeteSLMed
3.haa
Ng.1
IP.CL
Arder Honewe
lam
:del Vaama
/urjo Harma:.
EncYpego ventee
ano I.and
HMnrp ung
Inacno:
cee.
Figura 5.9.: Exploracin de jerarquas de agregacin con Cognos
FAe
Ed7 i4ew itoser1 Epiar e. Pan)*
Dicivil@iffila' ,.
leOlva. E
P
uslmaw 11-
nr.
7c4d4
..9.~ Hlb
at[Elial[rzlt]
'0 7+ .1.1:. -01.1s.
1.r
1
CIP111111110511PROI
FOCNZ
i Pral. ttrs
Lp+U hI
t
Lugar.
C.J CtAele%
NOr01111B
Modelas
Centro
1,1~
Madidp I 1 Noma: I
Deperte
Wrarlanyo
PlOta
1500
d05
250E1
SOD
8100
1+00
700
d00
WO.
Sur
300
4-100
440D
Noris
900
3920
152D
4020
$507D
350
04 ite
Loores
4003
2256
35D
Figura 5.10.: Explotacin OLAP de cubos creados con Cognos
: ECU, . p 86
Bibliografa
[1] E. P. Codd. The Relational Model for Database Management. Addison Wesley, 1990.
[2] IBM. Cognos Business Intelligence and Performance Management Software. www. ibm. com/
software/data/cognos.
[31 R. Kimhall. The Data Warehouse Toolkit: Practical Technigues for Building Dimensional
vil
Oracle. Oracle Business Intelligence Discoverer. http : //www oracle cm/technology/

pro duc t
scovererfindex.html.
[5] N. Pendse. The OLAP Report. http://www.olapreport.com.

[6] Erik Thornsen. OLAP Solutions: Building Multidimensional Information Systems. Wiley,
1997.
79
: ECU, . p 87
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 88
autntico conocimiento es conocer la extensin de la propia ignorancia.

Confucio
El
Herramientas de minera de datos
RAS haber presentado en el captulo anterior en qu consista la tecnologa OLAP (OnLine Analytical Processing, procesamiento analtico en lnea), en este captulo se expone lo
que son las tcnicas y herramientas para la minera de datos. En primer lugar, se motivar el
problema subyacente de la minera de datos, para a continuacin, dar la definicin de este tipo de
tecnologa. Tras ello, se detallarn los diferentes tipos de tcnicas de minera y sus aplicaciones.
Finalmente, se expondr el marco de trabajo sobre el que se concibe la minera de datos.
Indice
6.1. Motivacin
81
6.2. Qu es la minera de datos?
82
83
85
6.1. Motivacin
Las tcnicas de minera de datos surgen como solucin al problema de la explosin de datos.
Dada la cantidad de informacin que manejan las aplicaciones hoy en da, tales como los sistemas
de almacenes de datos, se hace cada vez ms necesario el uso de mtodos automticos para
descubrir y analizar la informacin ms valiosa que se encuentra escondida en los datos.
La situacin que da lugar a tales volmenes de datos no es otra que el hecho de que los
propios mtodos de recoleccin de datos estn automatizados junto con los potentes sistemas de
almacenamiento. Esto conduce a una cantidad ingente de datos almacenados en bases de datos,
ya sean almacenes de datos u otros repositorios.
81
: ECU, . p 89
Captulo 6. Herramientas de minera de datos
82
Tecnologia
de BD
Estadsticas
Machine
Learning
Ciencia de la
Informacin
Otras
Figura 6.1.: Factores que definen la minera de datos
Con ello, podemos hacernos la pregunta de si los datos que mantenemos almacenados son
realmente informacin valiosa para la empresa. Recordemos que para que un dato se considere
informacin debe describirse sobre un contexto que le asigne significado y, adems, que ese
significado sea relevante para el analista. As, la integracin de almacenes de datos con tcnicas
de minera soluciona el problema de identificar esa informacin en los datos de una organizacin.
Con las tcnicas de minera de datos se podr extraer esa informacin, pero no solo eso, sino
conocimiento: mediante tcnicas automticas se extraern los patrones, reglas y restricciones
que siguen los grandes volmenes de datos almacenados.
6.2.
Qu es la minera de datos?
La minera de datos se define dentro del proceso de descubrimiento de conocimiento en bases

de datos:
La minera de datos es la extraccin de informacin interesante (no-trivial, implcita,
previamente desconocida y potencialmente
), relaciones y/o patrones a partir de
los datos en grandes bases de datos.
Esta definicin pone de relieve el tratamiento de grandes volmenes de datos para la generacin de conocimiento, siempre que nos encontremos en un escenario donde la extraccin de
informacin o conocimiento deba realizarse de forma automtica pues su tratamiento manual
seria impracticable, entonces podemos hablar de minera de datos.
Cabe destacar que a la minera de datos tambin se la conoce por otros nombres como: el
ya comentado de extraccin de conocimiento en bases de datos, anlisis de patrones y datos,
machine learning, etc.
Con todo, la minera de datos ser un paso en el proceso de descubrimiento de conocimiento, consistiendo en la aplicacin de algoritmos particulares (mtodos) que bajo algn objetivo
aceptable, para producir una enumeracin de patrones (modelos) sobre los datos. Se aplican
para ello tcnicas estadsticas y de inteligencia artificial (algoritmos) para descubrir patrones
e irregularidades en los grandes volmenes de datos. Es, por tanto, una tecnologa que utiliza
tcnicas conocidas.
: ECU, . p 90
83
A modo de resumen, en la fig. 6.1 se presentan algunos de los factores en la definicin de la

tecnologa de minera de datos que hemos visto. Tenemos que la minera de datos se forma por
unin de disciplinas como la de bases de datos, la estadstica, la de visualizacin de informacin
o niachine learning, entre otras.
Por otro lado, podemos definir la minera de datos en base a lo que no es. No es una extensin
del lenguaje SQL (Structured Query Language, lenguaje de consulta estructurado). Pese a que
hay extensiones de SQL orientadas a la minera de datos, stas son solo medios de especificar
la ejecucin de las tcnicas de minera. Igualmente, el empleo de SQL para generar resmenes
tampoco se considera minera de datos. Tampoco es OLAP. La tecnologa OLAP permite
navegar datos resumidos y agregados en una vista multidimensional, pero no genera datos que no
existiesen antes de aplicar tal tcnica. Por ltimo, la minera de datos est basada en algoritmos
que pueden descubrir patrones escondidos, suelen ser interactivos y no totalmente automticos.
Podemos tambin comparar el tipo de consultas que involucra la minera de datos en relacin
con las consultas OLAP. Mientras que las consultas OLAP estn basadas en conocimiento
previos y conjeturas y son ejecutadas por los usuarios, las de minera de datos no necesitan
conocimiento previo y, por el contrario, estn guiadas por el analista.
Para terminar con la definicin de la minera de datos, podemos enumerar tambin algunos
de sus usos:
Descubre hechos y relaciones de datos.
Se necesita poca intervencin humana.
Encuentra patrones.
Determina y establece reglas.
Almacena y reutiliza reglas.
Presenta informacin a los usuarios.
Puede llevar muchas horas.
El usuario final debe ser capaz de analizar resultados.

Como principales aplicaciones de la minera de datos tenemos el anlisis de bases de datos
y apoyo a la decisin. Como ejemplo, podemos mencionar la aplicacin de la minera de datos
al anlisis del mercado: marketing, CRM (Customer Relationship Management, gestin de la
relacin con los clientes), anlisis de la cesta de la compra, segmentacin de mercados, etc. Otro
ejemplo es el anlisis de riesgos mediante la prediccin de estos, la fidelidad del cliente, el control
de calidad y el anlisis competitivo, o la deteccin y gestin de fraudes.
Otras aplicaciones de la minera de datos en funcin de la tecnologa sobre la que acta son:
la minera de textos en grupos de noticias, correo electrnico y documentos, la minera web
(analizando, por ejemplo, los patrones de navegacin de los visitantes) y la minera de imgenes
(analizando formas, colores, etc.).
Respecto a las tcnicas de minera, a continuacin citaremos algunas de las ms relevantes.
Sin embargo, dado el amplio espectro de tcnicas (que depende del tipo de patrn y dato que se
: ECU, . p 91
84
Salario anual
24,000C
Deudor
<10,000
Buen cliente
Crdito
anual
50,000
Mal cliente
Figura 6.2.: Ejemplo de rbol de decisin
Salario anual
Mal cliente
Deudas
Crdito
Edad actual
uen cliente
Figura 6.3.: Ejemplo de red neuronal
pretende analizar), existen multitud de tcnicas y algoritmos que las implementan, por lo que
el conjunto de estas permanece abierto por definicin.
La primera de las tcnicas es la de los rboles de decisin (ver fig. 6.2). Estos rboles representan decisiones anidadas que sirven para clasificar los datos. As, aplicando un rbol de
decisin sobre los datos se obtendrn las reglas que permiten clasificarlos. Como ejemplo, la
fig. 6.2 muestra el rbol de decisin para un buen o mal cliente: ste es clasificado, en primer
lugar, por su salario anual. Tras ello, en funcin del valor de su salario, puede clasificrsele como
deudor o de crdito anual. As, se clasifica dentro de dos regiones de salario (menor que 10000
o mayor que 50000) y, con ello, en buenos o malos clientes.
Otra tcnica interesante es la de redes neuronales (ver fig. 6.3). Estas definen un modelo
predictivo que se configura de forma iterativa mediante ejemplos que se emplean a modo de
aprendizaje para la red neuronal. Por ello, estn desarrolladas a partir de cmo el cerebro
humano entiende y aprende. Tcnicamente, emplean modelos estadsticos como la regresin
mltiple para funcionar. Como ejemplo, la fig. 6.3 muestra una red neuronal donde los salarios,
deudas, crdito y edad de un cliente sirve de entrada para que la red (la capa interna de neuronas
en la figura) decida si ste es un buen o mal cliente.
Tambin puede emplearse las reglas de asociacin en minera de datos. Esta tcnica permite
el descubrimiento de correlaciones entre un conjunto de elementos de datos. Responde a preguntas como de qu manera se relacionan los datos? y cmo se venden los productos en el
supermercado?
: ECU, . p 92
"vit^ilute
~S1 k
ANG
le 44444 I
-LP
85
Wien".1111~
11~
d'e
.1 .1fTly
ORACLE'
Mi neSet
e0IPTWAFIC rvwena THE inrcara-r-
Unica 111,
Figura 6.4.: Proveedores de soluciones de minera de datos
En la misma lnea, la tcnica de patrones secuenciales permite descubrir las asociaciones de

los datos a lo largo de un perodo de tiempo. Responde, por tanto, a preguntas como qu me
comprar un cliente el mes que viene si hoy ha comprado un artculo 'relacionado"?
Como ltima tcnica a presentar tenemos las clasificacin de datos propiamente dicha. La
tcnica de clasificacin analiza un conjunto de datos entrenados y construye un modelo para
cada clase de elementos en funcin de sus datos. Como ejemplo, en la cesta de la compra,
mediante esta tcnica se podra determinar los patrones de compra y, despus encontrar los
clientes con atributos similares que pudieran ser incluidos en la misma campaa de marketing.
Existen, por otro lado, otras muchas tcnicas de minera de datos:
Algoritmos genticos basados en la teora de la evolucin.
Funciones estadsticas tales como medias y totales.
Tcnicas del vecino ms prximo para encontrar asociaciones.
Induccin de reglas aplicando lgica: por ejemplo, mediante clusulas Talen.
Experimentos con diferentes tcnicas (como mtodo hbrido).
Algunos de los vendedores ms reconocidos de soluciones de almacenes de datos tambin
proporcionan soluciones para la minera de datos, pero dado que la minera de datos no se
limita a estos repositorios, tambin se dan otros muchos vendedores dedicados a proporcionar
soluciones estadsticas. Ejemplos de ellos pueden verse en la fig. 6.4. Entre estos, cabe destacar
por ejemplo, SPSS que es una de las suites estadsticas ms conocidas que, por supuesto, puede
aplicarse para realizar minera de datos mediante las tcnicas que implementa.

Para terminar este captulo, vamos a comentar el marco de trabajo sobre el que se define el
proceso de minera de datos. Este proceso no es otro que el de descubrimiento de conocimiento
en bases de datos.
: ECU, . p 93
86
Ev aluacin
de patrones
Data Min7illik
Datos para aplicar DM 111
Data Warehouse "
/`Selccciu
...".."7
pimpi;.
., - Integracin
Bases de datos
Figura 6.5.: Proceso de descubrimiento de conocimiento en bases de datos
Como se muestra en la fig. 6.5, la minera de datos se concibe como una tcnica de explotacin
sobre los almacenes de datos para la extraccin de conocimiento. Por un lado, el almacn de
datos es la plataforma idnea sobre la que realizar la minera de datos ya que extrae los datos de
las fuentes de datos para su integracin y limpieza. De esta manera, llegados al almacn de datos,
se encuentran en un formato adecuado para la aplicacin de las tcnicas de minera de datos.
As, tras el diseo del almacn de datos y la posterior seleccin de los data marts en funcin
de las necesidades de informacin de sectores concretos de la organizacin, se pasa al anlisis
de los datos. Concretamente, la minera de datos se muestra en la fig. 6.5 como el proceso que
extrae de los cubos de datos del almacn de datos los patrones y tendencias que sern evaluados
posteriormente por los analistas para finalmente extraer el conocimiento inicialmente oculto en
esos datos.
Finalizamos enumerando los pasos de este proceso:
1. Aprender el dominio de la aplicacin: es importante tener conocimiento previo y seleccionar
las metas a cumplir por la aplicacin.
2. Crear un conjunto de datos objeto seleccionando los datos requeridos.
3. Limpiar los datos y preprocesarlos (esta tarea puede llevar el 60 % del esfuerzo total de la
minera de datos).
4. Reduccin de datos y transformacin, encontrando caractersticas tiles, reduciendo variables y dimensionalidad de los datos, etc.
5. Escoger funciones y tareas de minera de datos como puedan ser la de clasificacin, regresin, reglas de asociacin, clustering, etc.
6. Escoger los algoritmos de minera de datos para las tcnicas seleccionadas.
: ECU, . p 94
87
7. Realizar, finalmente, la minera de datos (lanzando los algoritmos seleccionados) para la

bsqueda de patrones de inters.
8. Evaluar los patrones y presentar el conocimiento obtenido mediante tcnicas de visualizacin, la eliminacin de patrones redundantes, etc.
9. Utilizar el conocimiento descubierto para tomar mejores decisiones en la organizacin.
As, la minera de datos nos proporciona tcnicas muy potentes para el tratamiento automtico de grandes volmenes de datos que, sobre almacenes de datos, permite la extraccin de
conocimiento.
: ECU, . p 95
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 96
Bibliografa
[1] M. J. A. Berry. Data Mining Technigues: For Marketing, Sales, and Customer Relationship
Management. Wiley, 2004.
[21 IBM. SPSS Modeler (Clementine). www.spss com/software/modeling/modeler.
[31 G. Piatetsky-Shapiro and W. Frawley. Knowledge diseouery in databases. Aaai Pr, 1991.
[41 The University of Waikato. Weka 3 Data. Mining with Open Source Machine Learning
Software in Java. mal; . cs . vaikat o . ac .nzrmliveka.
89
: ECU, . p 97
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 98
Piensa como piensan los sabios, mas habla

como habla la gente sencilla.
Aristteles
7
Metadatos en almacenes de datos
ASTA ahora hemos visto las alternativas de diseo que existen en cada una de las partes de
una arquitectura de almacenes de datos. En este captulo, se vern de qu manera se almacena
la informacin de diseo. Los metadatos nos permitirn describir cada una de esas fases. A
continuacin, se introducir la motivacin para estos metadatos, seguido de su descripcin para
las partes fundamentales del almacn de datos: los procesos ETL (Extraction, Transformaban,
and Loading, extraccin, transformacin y carga), las herramientas de explotacin OLAP (OnLine Analytical Processing, procesamiento analtico en linea) y el propio almacn.
ndice
7.1. Introduccin
91
93
7.3. Metadatos de usuarios finales
94
94
7.1. Introduccin
Los metadatos existentes en un proyecto de almacenes de datos son cruciales para su xito.
Cuando hablamos de metadatos, no solo nos referimos a un esquema multidimensional (por
ejemplo, el esquema estrella) o a unas reglas de negocio. Los metadatos son toda aquella informacin acerca de los objetos que estamos diseando: desde las fuentes de datos y procesos
ETL, pasando por el almacn de datos y data marts, hasta las herramientas de explotacin.
Los metadatos han de ser escalables y siempre estn expuestos a cambios. Por ello, deben
permitir la integracin, registrar la historia y contenido del almacn de datos y deben reflejar
91
: ECU, . p 99
92
Captulo 7. Metadatos en almacenes de datos
los cambios que se realicen. Dada su complejidad, la definicin de una buena estrategia de
metadatos es fundamental para el proyecto. Esta estrategia involucra la implantacin, el control
y la gestin de los metadatos en todas las fases del proyecto del almacn de datos.
La estrategia de metadatos debe asegurar su calidad. Para ello, se suministrarn a los distintos
tipos de usuarios informacin de calidad del almacn de datos. Pero tambin se requiere dar
soporte a la integracin de los metadatos atendiendo a:
Objetivos, fuentes y tipos de metadatos.
Fuentes de datos y su localizacin.
Mantenimiento y gestin.
Utilizar estndares siempre que se pueda.
Herramientas de definicin, gestin y acceso.
Integracin y evolucin.
A continuacin se detallan cada uno de estos puntos.
Objetivos, fuentes y tipos. Son importantes las siguientes caractersticas: los requisitos de
los metadatos, el acceso (quin y cmo se accede a ellos), la identificacin de las fuentes de
informacin sobre la que disear los metadatos, la estrategia de integracin, la gestin del cambio
y evolucin, especificar los usuarios de los metadatos y sus necesidades, el qu debera contener
los metadatos y qu herramienta se debera utilizar para crear y mantener los metadatos.
Tcnicas y herramientas. Las herramientas de modelado de datos se dividen en dos tipos:

operacionales y de almacenes de datos. En cuanto a las segundas, tenemos las que se utilizan
para definir esquemas de bases de datos, las herramientas ETL y las herramientas de anlisis
de datos de usuario final. Asimismo, existen otras herramientas de soporte como las que sirven
para copiar los sistemas heredados (por ejemplo, los COBOL (COmman Business-Oriented
Language) copyboaks) o las herramientas rriiddleware.
Localizacin de los metadatos. Normalmente est en el servidor del almacn de datos y

cuando no, en otras plataformas operacionales. Existen tambin las herramientas de escritorio
con filosofa metalayer (por ejemplo, el Oracle Disco verer) que almacenan los metadatos. Quien
maneja y administra estos metadatos es normalmente el administrador del servidor del almacn
de datos. Es interesante notar que siempre que se pueda se debern utilizar estndares, ya que
facilitan la interoperabilidad entre herramientas.
Acceso y herramientas. Hay que responder a las siguientes preguntas: quin? cundo? y
qu informacin? Para ello, se dispone de herramientas para la gestin, consulta y desarrollo
de metadatos.
: ECU, . p 100
93
Integracin y evolucin Se trata de disear la integracin y el intercambio de los distintos

tipos de metadatos. Con ello, el cambio de los metadatos debe tenerse en cuenta en el diseo de
los programas para su gestin. La gestin del cambio debe considerar la programacin de ciclos
de refresco para actualizar los metadatos.
Como comentbamos, existen diferentes tipos de metadatos. Podemos diferenciar principalmente los metadatos operacionales, de procesos ETL, el esquema del almacn de datos y los de
las herramientas de explotacin y usuarios finales.
Los metadatos operacionales residen en las fuentes de datos. Dado que podemos no tener
control directo sobre tales fuentes, existen consideraciones de acceso y polticas de extraccin
de datos (estas polticas se vieron en el tema de los procesos ETL). Se debe atender, por tanto,
tambin al propio rendimiento de los procesos de extraccin de datos.

En un proyecto de almacenes de datos existe tambin la necesidad de disponer de informacin
acerca de los procesos ETL, ya sea de su diseo o de su ejecucin. Para simplificar el estudio de
tales metadatos, estos pueden clasificarse segn la fase del proceso ETL que describen, esto es:
la fase de extraccin, de transformacin o de carga. A continuacin, se exponen varias listas de
metadatos. Lejos de ser listas cerradas, dependiendo del diseador y necesidades de informacin
particulares de cada proyecto de almacenes de datos, los metadatos necesarios variarn.
Fase de extraccin.
La informacin necesaria para describir la fase de extraccin es acerca de:

las reglas de negocio, las estructuras de datos de las fuentes de datos (tablas, campos, valores
clave, etc.), los propietarios de los datos de origen, las conversiones de campos, las tablas de
referencia y maestros, los cambios de nombres, los cambios en los valores clave, los valores por
defecto, la gestin de mltiples fuentes de datos, los algoritmos empleados en la extraccin, las
referencias temporales, los requisitos de almacenamiento y espacio, la localizacin de las fuentes
de datos, los registros de acceso, las polticas de seguridad, los contactos, los nombres de los
programas, los detalles de frecuencia de acceso, los procedimientos de fallos y la calidad de los
datos.
Fase de transformacin. La informacin necesaria para describir esta fase es la que describe lo
siguiente: rutinas de duplicados y copias de datos, el gestor de excepciones, la nueva definicin
de claves, las conversiones debido a la granularidad, la traduccin de nombres entre fuentes y
destino, la frecuencia, los agregados, las transformaciones manuales y las reglas de conversin
segn la unidad del proceso ETL.
Fase de carga. La informacin de esta tercera y ltima fase es acerca de: el mtodo de transferencia, la frecuencia de la carga, los procedimientos de validacin, los procedimientos de fallos
y las reglas de utilizacin de los procesos de carga. Tambin, muy importante, se debe tener
informacin acerca de los fallos que se producen en la carga para actuar como corresponda.
: ECU, . p 101
94
Nombre Nombre
Tabla
Columna
Datos
Significado
Producto P-rodid
73916 Unique i clentifie r for the product
Producto fecha_v Ida
01197
Producto focalizacin
1.81C
Warehouse location nurrider
Producto color
15
Colar del producto; por favor,
Last refresh date
ver tabla COL_REF para detalles

Productcumaso
17 62
Peso del cal:mete en Iso
Figura 7.1.: Ejemplo de metadatos de usuarios finales
7.3. Metadatos de usuarios nales

Los metadatos de los usuarios finales consisten en el contexto de las tablas a consultar, la
localizacin de hechos y dimensiones, la disponibilidad de los datos, la descripcin del contenido
de cada tabla, los algoritmos empleados para los datos derivados y agregados, etc.
En la fig. 7.1, se muestra un ejemplo de relacin de metadatos de los usuarios finales. Se presentan metadatos de los atributos de la tabla producto (por ejemplo, de las fechas, localizacin,
color, etc.), con sus valores y significados.
Interesantes tambin, son los metadatos acerca del contexto de la informacin. Dado que se
deben soportar los cambios de los metadatos (recurdese las dimensiones que cambian lentamente, por ejemplo), es importante mantener el contexto de cada metadato. Estos metadatos
pueden ser: simples (estructuras de datos, reglas para nombramiento o mtricas de calidad),
complejos (definiciones de productos, mercados o precios) o externos (econmicos o polticos).
Algunas de las herramientas dedicadas a la gestin de metadatos de usuarios finales son
las siguientes: Carleton, Evolutionary Technologies, Hewlett Packard, Inforrnatica, Information
Advantage, Platinum Technolow, Prism Solutions y Sagent, entre otras.

Para exponer tal tipo de metadatos necesitamos definir el concepto de metamodelo de un
almacn de datos: los metadatos sobre el modelo multidimensional utilizado. Por ejemplo, la
informacin que dice que una dimensin se relaciona con un hecho o que el nivel inferior de una
jerarqua de agregacin se relaciona con uno superior. Con esta definicin, se puede advertir que
todo modelo tendr en verdad su propio metamodelo.
Concretamente, dada la problemtica de gestin de datos en un entorno tan complejo como
el de almacenes de datos, existen propuestas para la estandarizacin de metadatos del almacn
de datos. En particular, estudiaremos aqu CWM (Comnon Warehouse Metomodel). CWM
pertenece a la familia de lenguajes a la que pertenece tambin UML (Uni ed Modelling Language) y constituye un intento de estandarizar todos los tipos de metadatos que existen en la
arquitectura de un almacn de datos.
: ECU, . p 102
95
BTL
Dala
Y/merla:11m-
Fuera BS fletas
OparacianRINg
IFuenlles
Fuenlm
lewlinte
CWM Tne4
Fuellas
Panvise
lo Ganan ores)
D estino
UtisLmo
Down
Figura 7.2.: Solucin al intercambio de metadatos empleada por CWM
Para comprender cmo una propuesta como CWM contribuye al modelado de metadatos, se
detallarn los elementos de modelado de CWM (paquetes, dependencias, asociaciones, etc.), se
discutirn los fundamentos de CWM como lenguaje de modelado y su relacin con UML.
Podemos definir CWM segn sus diseadores como:
Interfaces estndar que se pueden utilizar para un intercambio fcil de la informacin de los metadatos del almacn de datos entre plataformas de almacn de datos,
herramientas de almacenes de datos y repositorios de metadatos de almacn de datos
en entornos distribuidos heterogneos.
Donde queda claro el objetivo principal que sigue CWM, que no es otro que el intercambio
fcil de metadatos en un entorno de almacenes de datos. Dado su objetivo, CWM cuenta
con el apoyo de mltiples compaas, entre las que destacan como co-creadores IBM, Unisys,
NCR, Hyperion, Oracle, UBS, Genesis y Dimension EDI. Por otro lado, hoy en da lo soportan
herramientas de los siguientes proveedores: Deere, Sun, HP, Data Access Technologies, In-line
Software, Aonix, Hitachi, SAS Institute, Meta Integration Technology, entre otros.
La fig. 7.2 muestra la problemtica en el intercambio de metadatos que CWM resuelve. Mientras que un formato no estndar fuerza a que cada herramienta deba implementar importadores
y exportadores de formatos por cada uno de los existentes, las herramientas que empleen CWM
como estndar de metadatos podrn utilizar este formato como puente comn hacia el resto de
herramientas que tambin lo implementen, solucionando la complejidad anterior.
La arquitectura de CWM es la que se presenta en la fig. 7.3. Para la definicin de CWM
(en la capa M2) se necesita de otro lenguaje de modelado que lo defina (o meta-metamodelo, en
la capa M3). Por otro lado, CWM define modelos de metadatos (en la capa 111) que a su vez,
sirven de lenguaje para los propios datos (en la capa 1110). La fig. 7.3 muestra tambin ejemplos
de cada capa. Por ejemplo, el nivel superior (MO) est dominado por el lenguaje MOF (MetaObject Facility) que define clases, atributos, operaciones y asociaciones, mientras que el nivel M2
con UML tiene clases, atributos, etc., y con CWM tiene tablas, columnas, tipos de elementos,
etc.
: ECU, . p 103
96
Meta-metamodel
Layer (11/13)
_IMF' Clase, Atributo,

Operncii5r4
Asociacin
Metamodel
Layer(M.2)
LML: Ciase, Atributo

CWM: rabLa, Columna
E letnentType. Attribute
Metadataillcle1
.Layer(M1)
User DatalUbject
Layer (M0)
Prod: nombre, preci
.1..Prod norubte="1BNI."
preciel.E2".,>
Figura 7.3.: Capas en la arquitectura de CWM
Example s
M3
meta-nieta-nade'
The "MOF Model"
M2
rnetamadat meta-metadata
UML Metarnalei,
CWM Metarnode I
M1
mode I , rr: atad ata
UML models,
CWM rnetadata
MCI
object, data
Mode I leal systems,

Warehousa data
Figura 7.4.: Nomenclatura de metadatos en la arquitectura de CWM
: ECU, . p 104
Management
97
W2 rhe LIS 9
Wa re h ouse
Pr 0,Ge53
Op erat I on
Anaiysie
Tren sforreat on OLA P
Resource
Oject
b
ec..,Lkh.,..r+- Rolad:mai
Data
Informatio n
Business
Minino. Visuelltation Nornenciature
Record
WrIatlEn sh IPSi
Foundation
Object Model
"luidDi mer.sonal
XMS
Business Data
Ke y s
Type
Software
Expre s Mons
!niel-mal I an Types
IndeK Mapping ID e pi 1;n/rent
Core
Behayl ural
Relationsh i os
I nstanee
Figura 7.5.: Divisin lgica de CWM
Para aclarar la nomenclatura involucrada en tales arquitecturas de modelado, la fig. 7.4 resume
los nombres de los modelos en relacin a su nivel de abstraccin.
Por otro lado, la fig. 7.5 muestra los paquetes o divisiones lgicas de modelado en los que se
divide CWM. Cada uno representa una parte de la arquitectura de un almacn de datos cuyos
metadatos son susceptibles de modelarse. En esta misma figura, se muestra que los paquetes
tambin estn organizados en capas, sirviendo las inferiores como base para definir las superiores.
Por ejemplo, para definir un warehouse process en la capa de gestin de CWM se necesita del
paquete transformation de la capa de anlisis.
Como ejemplo de modelado con CWM, la fig. 7.6 muestra los elementos de modelado relacional de CWM (en la parte inferior derecha de la figura) que son aplicados a la tabla de
ejemplo (en la parte superior) para modelar sus metadatos en CWM (en la parte izquierda).
Como puede observarse, los elementos de modelado de CWM en este caso son tablas y columnas que se identifican ambos por un nombre y, por ejemplo, un tipo en el caso de las columnas.
As, una relacin de cursos con su instructor y despacho (ver figura) puede modelarse con estos
constructores de CWM quedando formalizados los metadatos con un formato estndar.
Habiendo visto en qu consiste CWM, cabe preguntarse por su relacin con UML. CWM
representa un lenguaje orientado a la implementacin o intercambio de metadatos en almacenes
de datos, mientras que UML est orientado al diseo general de sistemas de software. Por tanto,
difieren en mbito y nivel de abstraccin. En UML la claridad de la notacin es primordial,
mientras que CWM simplemente no atiende a esta cuestin pues el intercambio de metadatos
no es una tarea que requiera de tal caracterstica.
Como apunte final, en relacin a la complejidad de los metadatos a disear, es preferible que
se diseen mltiples paquetes de pequeo tamao que estn muy cohesionados. As, se facilita
su reutilizacin en el futuro dado que se disminuyen las dependencias entre unidades lgicas (se
disminuye el acoplamiento entre paquetes).
: ECU, . p 105
98
GII.C59ID
TAGT
AESI
GCLITSC
Instructor
D es p a che
Romero
21
Peraf
20.
19411v4FTrue
Tabla Curso y sus valores

_1 corsou
IrvtIrltelOF
RocruNg
r"
011aTYPv arre ho I
HCala Tvpe.51ring
Data-rypstrinsi
Tibie
r
ph orla 2trIng
tlible
OpuIrtlia i Halen 1
COi
VAIn9 : Milrig
In todalaTypo: Zrno
Modelo de tabla relacional.
Instancias de tabla curso

Figura 7.6.: Paquete de CWM para modelado relacional
: ECU, . p 106
Bibliografa
[11 G. Booch, J. Rumbaugh, and I. Jacobson.

Addison Wesley, 2005.
The Un ed Modeling Language User Guide.
[21 J-N. Mazn and J. Trujillo. Data Warehousing Meets MDA: A Case Study for Multidimensional l'vlodeling. In New &ends in Data Warehousing and Data Analysis, pages 51 70.
2009.
OMG. Common warehouse metamodel (cwm), version 1.1. http: //www.omg.org/
technology/clocuments/formal/cwm .htm, March 2003.
OMG.
Unified Modeling Language (UML), version 2.1.1.
technology/documents/formal/uml.htm.February 2007.
http: //www.omg.org/
J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehonse Metamodel Developer s

Guide. Wiley, 2003.
99
: ECU, . p 107
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 108
Aplicaciones de almacenes de datos en el

mercado
Este apndice tiene como objetivo el listado a modo de referencia de algunas de las principales
herramientas del mercado. Estas herramientas se han clasificado segn la parte de la arquitectura
de un almacn de datos que resuelven. Entre ellos, se resaltan en negrita las ms importantes.
Conectividad con los sistemas OLTP (On-Line Transaction Processing, procesamiento

transaccional en linea)
Apertus, CA-Ingres Gateway, Information Builders EDA/SQL, IBM Data Joiner, Informix
Enterprise Gateway , Microsoft ODBC, Oracle Open Connect, Platinum InfoHub, SAS
Connect, Software AG Entire, Sybase Enterprise Connect, Trinzic InfoHub.
Procesos ET L
CA-Ingres Replicator, Carleton Passport, Evolutionary Tech Inc. ETI-Extract, Harte-Hanks

Trilium, IBM Data Joiner, Data Propagator, Oracle (Oracle Warehouse Builder y
SQL Loader y/o PL/SQL), Platinum InfoRefiner, InfoPumop, Praxis OmniReplicator, Prism
Warehouse Manager, IBM Redbrick TMU, SAS Access, Software AG Sourcepoint, Sybase
Replication Server, Trinzic InfoPump.
Servidores MOLAP (Multidimensional OLAP, OLAP multidimensional)
Arbor Essabase, Comshaer Commander OLAP. Oracle IRI Express, SAS System.
101
: ECU, . p 109
102
Apndice A. Aplicaciones de almacenes de datos en el mercado
SGBD (Sistema de gestin de bases de datos)
CA-Ingres, IBM DB2: Informix y Redbrick, Information Builder ocus, Oracle DB,
Praxis Model 204, Software AG ADABAS, Sybase MPP, Tandem, Teradata, SQL Server.
Servidores ROLAP (Relational OLAP, OLAP relacional)
HP Intelligent Warehouse, Information Advantage Asxys, Microstrategy DSS Server, La gran

mayora de los anteriores (Oracle, IBM, SQL Server).
Entornos de consulta e informes
Brio/Query, Business Objects, Cognos Impromptu, CA Visual Express, IBM DataGuide, Information Builders Focus Six, Microstrategy, Platinum Forest & Trees, SAS Access,
Software AG Esperant.
Anlisis multidimensional
Andyne Pablo, Albor Essbase Analisys Server, Business Objects, Cognos PowerPlay,
Dimensional Insight CrossTarget, Holistic Systems HOLOS, Information Advantage Decision
Suite, IQ Software IQ/Vision, Kenan Systems Acumate, Lotus 123, MS Excel, Microstrategy
DSS, Pilot Lightship, Platinum Forest & Trees, Prodea Beacon, SAS OLAP++.
Minera de datos
Clementine, DataMind, Information Discoverer, Magnify, Thinking Machines, IBM Intelligent Miner, SGI Mineset, Oracle Datamining.
Metadata
HP Intelligence Warehouse, IBM DataGuide, Platinum Repository, Prism Director Manager.

Controladores del sistema
CA Unicenter, HP Open View, IBM Datallub, Information Builder Site Analyzer, Prism
Warehouse Manager, SAS CPE, Software AG Source Point, Tivoli.
Controladores de procesos
AT&T TOPEND, HP Intelligente Warehouse, IBM FlowMArk, Platinum Repository, Prism

Warehouse Manager, Software AG Source Point.
: ECU, . p 110
ndice de acrnimos
4GL Fourth-Generation programming Language

bit Binary diglT
B D Base de Datos
CAD/CAM Computer-Aided Design/Computer-Aided Manufacturing
C0130L COmmon Business-Oriented Language
CRM Customer Relationship Management, gestin de la relacin con los clientes
CWM Common Warehouse Metamodel
EIS Executive Information System, sistema de informacin para ejecutivos

ER modelo entidad relacin
ETL Extraction, Transformation, and Loading, extraccin, transformacin y carga
EU L End-User Layer
D55 Decision Support System, sistema de apoyo a la decisin
FTP File Transfer Protocol
GB GigaByte, 1024 MB
M DA Model-Driven Architecture
MB MegaByte, 1024 bytes (1 byte = 8 bits)
MOF Meta-Object Facility
MOLAP Multidimensional OLAP, OLAP multidimensional
OLAP On-Line Analytieal Processing, procesamiento analtico en lnea
OLTP On-Line Transaction Processing, procesamiento transaccional en lnea
00 Orientado u orientacin a objetos
OWB Oracle Warehouse Builder
PB PetaByte, 1024 GB
103
: ECU, . p 111
104
ndice de acrnimos
PC Personal Computer
ROLAP Relational OLAF, OLAP relacional
SGBD Sistema de gestin de bases de datos
SGBDR SGBD relacional
SQL Structured Query Language, lenguaje de consulta estructurado
TIC Tecnologas de la Informacin y Comunicacin
UML Un ed Modelling Language
: ECU, . p 112
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
ebrary
551300d6a8d1fb8d45423b1b8d7abd7d1
ebrary
: ECU, . p 113
Desde su aparicin en la dcada de los noventa, ros almacenes

de datos se han erigido como la tecnologa clave en los Sistemas
de Apoyo a la Decisin_
El libro Diseo y explotacin de almacenes de datas: conceptos
bsicos y modelado multidimensional se presenta como un libro
que introduce aspectos bsicos del modelado multidimensional
y del diseo de los almacenes de datos, y que pretende ser un
instrumento til para los estudiantes de grado y posgrado de las
titulaciones de informtica, as como para los profesionales del
desarrollo de almacenes de datos. En este sentido, el libro recoge
cuestiones y conceptos bsicos sobre la arquitectura y diseo de
los almacenes de datos, adems de aspectos bsicos del
paradigma o modelado multidimensional que rige el diseo de
estos sistemas en todas sus fases. As, el presente libro pretende
ser un manual en castellano que recoja y ponga en orden los
conceptos bsicos para acometer con garantas el diseo y
explotacin de almacenes de datos.
www.ecu.fm
ECU
EDIKIRIAIGE UNIVIESIRE IQ
: ECU, . p 114

Base de Datos Trujillo Index

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Base de Datos Trujillo Index

Încărcat de

Drepturi de autor:

Formate disponibile

DISEO Y EXPLOTACIN DE

Juan Carlos Trujillo

Diseo y explotacin de almacenes de datos. Conceptos bsicos de modelado multidimensional

ISBN edicin en Papel: 978-84-8454-902-4

Edita: Editorial Club Universitario. Telf.: 96 567 61 33

1.1. La tecnologa de bases de datos

2.1. Arquitectura general de almacenes de datos

3.1. Modelado multidimensional conceptual

A. Aplicaciones de almacenes de datos en el mercado

Diseo y explotacin de almacenes de datos: conceptos bsicos y modelado multidimensional

Juan Carlos Trujillo

En el Captulo 5, se describen las herramientas de consulta ms habituales en este tipo de

Juan Carlos Trujillo

Un viaje de miles de kilmetros empieza con

OMENZAREMOS nuestro estudio de los almacenes de datos repasando brevemente la tecnologa

1.2. Las nuevas necesidades de gestin de datos

1.3. Historia de las soluciones informticas a datos histricos

1.4. El almacn de datos: una primera aproximacin

1.5. Historia de las aplicaciones OLAP

1.6. Sistemas analticos contra transaccionales

1.1. La tecnologa de bases de datos

En la actualidad, podramos decir que aproximadamente el 90 % de los SGBD implantados

1.2. Las nuevas necesidades de gestin de datos

1.2. Las nuevas necesidades de gestin de datos

Ha variado un cliente sus gustos de compra de vehculos? Ha estado comprando el mismo

Qu descuento deberamos ofrecer para incrementar significativamente las ventas?

Cules son las tendencias en mis ventas?

Cuadro 1.1.: Tpicas cuestiones estratgicas para tomar decisiones en un negocio

columnas, etc. Necesitan entornos de consulta especficos en el que se manejen trminos de

1.3. Historia de las soluciones informticas a datos

Datos procedentes de sistemas heredados

Datos extrados en el escritorio

1.3. Historia de las soluciones informticas a datos histricos

Sistemas de apoyo para la toma de decisiones

1.4. El almacn de datos: una primera aproximacin

a las consultas estratgicas y no a procesar un gran nmero de transacciones, como sucede

1.4. El almacn de datos: una primera aproximacin

"S pe nuerca do'

en un instante determinado, o ser vlidos en un intervalo de tiempo. La variacin con

Ventajas para las empresas:

Decisiones soportadas por datos fiables, coherentes y homo-

. Rentabilidad de inversiones (ROI, Return of Investment). Muchos son los informes

Incovenientes para las empresas

1.5. Historia de las aplicaciones OLAP

1.6. Sistemas analticos contra transaccionales

2001 saw the

1.6. Sistemas analticos contra transaccionales

Cuadro 1.2.: Diferencias entre sistemas operacionales y sistemas analticos en lnea

No permitas que al anlisis te domine.

2.2. Las fuentes de datos operacionales

2.3. Los procesos ETL

2.3.2. Transformacin o limpieza

2.3.4. Herramientas para procesos ETL

2.5. Los metadatos

2.6. Servidores de bases de datos y consulta

2.7. Las herramientas de consulta

2.1. Arquitectura general de almacenes de datos

2.2. Las fuentes de datos operacionales

Monitorizacin & Administracin

Figura 2.1.: Arquitectura general de un almacn de datos

2.2. Las fuentes de datos operacionales

2.3. Los procesos ETL

2.3.2. Transformacin o limpieza

2.3. Los procesos ETL