Sistemas de Informaci

on

Felix Gomez Marmol

5o Ingeniera Informatica
Curso 2005-2006
Profesor: Jose Samos Jimenez (jsamos@ugr.es)
http://lsi.ugr.es/bdf/jsamos/ii/si/
Departamento de Lenguajes y Sistemas Informaticos

Indice general

Indice general

Indice de figuras

2. El Modelo de Datos Multidimensional

2.1. Fundamentos del modelo de datos multidimensional: Un modelo para consulta
2.1.1. Principios de los sistemas operacionales o transaccionales . . . . . . .
2.1.2. Principios de los sistemas multidimensionales . . . . . . . . . . . . . .
2.1.3. Funcionamiento de los sistemas multidimensionales . . . . . . . . . . .
2.1.4. El modelo de datos multidimensional a Nivel Conceptual . . . . . . .
2.1.5. Implementacion de los sistemas multidimensionales: Nivel Logico . . .
2.2. Dise
no multidimensional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Pasos para realizar un dise
no multidimensional a nivel conceptual . .
2.2.2. Pasos para realizar un dise
no multidimensional a nivel logico . . . . .
2.2.3. Caso de dise
no seg
un fotografa periodica . . . . . . . . . . . . . . . .
2.2.4. Otros casos de dise
no . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5. Dise
no de sistemas OLTP vs OLAP . . . . . . . . . . . . . . . . . . .
2.3. Procesamiento de consultas y optimizacion . . . . . . . . . . . . . . . . . . .
2.3.1. Patron de consulta y tecnicas de indexacion . . . . . . . . . . . . . . .
2.3.2. Particion de la tabla de hechos . . . . . . . . . . . . . . . . . . . . . .
2.3.3. Definicion de agregados . . . . . . . . . . . . . . . . . . . . . . . . . .

7
7
9
9
10
12
13
17
17
19
21
23
24
25
25
27
28

3. La F
abrica de Informaci
on Corporativa
3.1. Arquitectura del sistema de informacion: la FIC . . . . . .
3.1.1. Arquitectura seg
un Kimball . . . . . . . . . . . . .
3.1.2. Arquitectura seg
un Inmon . . . . . . . . . . . . . .
3.2. Construccion de la FIC . . . . . . . . . . . . . . . . . . .
3.2.1. ETL. Extraccion, Transformacion y Carga . . . . .
3.2.2. Desarrollo de ETL . . . . . . . . . . . . . . . . . .
3.2.3. Estructura de los proyectos de desarrollo de la FIC
3.2.4. Nuevos perfiles para el desarrollo de proyectos FIC

31
31
31
32
34
34
35
35
35

Bibliografa

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

37

INDICE GENERAL

Indice de figuras
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

7
8
8
9
9
9
10
10
10
11
12
12
12
13
13
14
14
15
17
18
18
19
21
22
22
22
23
23
24
25
25
27
28
28
29

3.1. Fabrica de Informacion Corporativa seg

un Kimball . . . . . . . . . . . . . . .
3.2. Fabrica de Informacion Corporativa seg
un Inmon . . . . . . . . . . . . . . . .
3.3. Data Warehouse Corporativo . . . . . . . . . . . . . . . . . . . . . . . . . . .

31
32
33

2.1. Descripcion de una organizacion . . . . . . . . . . . . . . . . . . . .

2.2. Diagrama Entidad/Relacion . . . . . . . . . . . . . . . . . . . . . . .
2.3. Diagrama relacional resultado de normalizar el diagrama de la figura
2.4. Informe de ventas entre septiembre de 2004 y septiembre de 2005 . .
2.5. Hechos con mediciones y dimensiones . . . . . . . . . . . . . . . . . .
2.6. Ejemplo del diagrama multidimensional de una venta . . . . . . . . .
2.7. Ejemplo simplificado del diagrama multidimensional de una venta .
2.8. Representacion de un dato en el espacio . . . . . . . . . . . . . . . .
2.9. Representacion en el espacio de todos los datos . . . . . . . . . . . .
2.10. Roll-up en la dimension producto . . . . . . . . . . . . . . . . . . . .
2.11. Operacion slice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.12. Sistemas OLTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.13. Ejemplo de hecho con mediciones y dimensiones con descriptores . .
2.14. Estructura de la descomposicion de una dimension por niveles . . . .
2.15. Ejemplos de descomposicion de una dimension por niveles . . . . . .
2.16. Dise
no a nivel conceptual del modelo de datos multidimensional . . .
2.17. Implementacion en Estrella . . . . . . . . . . . . . . . . . . . . . . .
2.18. Implementacion en Copo de Nieve . . . . . . . . . . . . . . . . . . .
2.19. Dimensiones sin desdoblar . . . . . . . . . . . . . . . . . . . . . . . .
2.20. Dimensiones de la figura 2.19 desdobladas . . . . . . . . . . . . . . .
2.21. Saldo de una cuenta de ahorros . . . . . . . . . . . . . . . . . . . . .
2.22. Dise
no a nivel logico . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.23. Enfoque 1: Transacciones de almacen . . . . . . . . . . . . . . . . . .
2.24. Enfoque 2: Fotografa periodica de almacen . . . . . . . . . . . . . .
2.25. Constelacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.26. Data Warehouse Bus Architecture . . . . . . . . . . . . . . . . . . .
2.27. Foco de atencion: Venta . . . . . . . . . . . . . . . . . . . . . . . . .
2.28. Foco de atencion: Promocion . . . . . . . . . . . . . . . . . . . . . .
2.29. Dimension de mediciones . . . . . . . . . . . . . . . . . . . . . . . .
2.30. Join entre cada dimension y los hechos . . . . . . . . . . . . . . . . .
2.31. Join del producto cartesiano de las dimensiones y los hechos . . . . .
2.32. Procesamiento de consultas con ndices de mapa de bits . . . . . . .
2.33. Cubos agregados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.34. Navegador de agregados . . . . . . . . . . . . . . . . . . . . . . . . .
2.35. Fallo en la dispersion de los agregados . . . . . . . . . . . . . . . . .

. .
. .
2.2
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

INDICE DE FIGURAS

Captulo 2

El Modelo de Datos
Multidimensional

Figura 2.1: Descripcion de una organizacion

2.1.

Fundamentos del modelo de datos multidimensional: Un

modelo para consulta

A lo largo de todo el captulo desarrollaremos el siguiente ejemplo:

Tenemos una cadena de supermercados en la que hay, entre otros empleados:
Un director general (en lo mas alto de la piramide)
Un director del departamento de ventas (en alg
un nivel intermedio de la piramide)
Cajeros/as (en la base de la piramide)
Nosotros nos vamos a centrar en los intereses del director del departamento de ventas, el
cual toma decisiones (entre otras muchas) sobre, por ejemplo:
Que productos vender
A que precio vender cada producto
Bajo que ofertas vender cada producto, etc.
7

Captulo 2. El Modelo de Datos Multidimensional

Que aplicacion seramos capaces nosotros de hacer ahora mismo para gestionar las ventas
en una cadena de supermercados? La figura 2.2 nos muestra un ejemplo de lo que sabramos
hacer.

Figura 2.2: Diagrama Entidad/Relacion

En la figura 2.3 vemos el diagrama relacional correspondiente al E/R mostrado en la
figura 2.2. Lo que se ha hecho para pasar de uno al otro no ha sido mas que Normalizar, esto
es, dejar solamente relaciones del tipo 1..N.
A nivel intuitivo podramos decir que al normalizar lo que se pretende es que cada dato
solo aparezca en un sitio (en una u
nica tabla) con el objetivo de facilitar las modificaciones
(evitar inconsistencias, etc.).

Figura 2.3: Diagrama relacional resultado de normalizar el diagrama de la figura 2.2

En definitiva, tanto el modelo relacional como el E/R estan orientados a optimizar las
modificaciones de los datos almacenados.
Pero este tipo de aplicacion no le es u
til al director del departamento de ventas. Supongamos que este quiere saber las ventas realizadas entre septiembre de 2004 y septiembre de
2005. Para ello deberamos crear una aplicacion que le mostrara una tabla similar a la que
aparece en la figura 2.4.
Otro informe que le podra interesar podra ser el que mostrara las ventas por cada tienda,
o por cada departamento, o por cada cajero, durante el u
ltimo a
no, o el u
ltimo trimestre, o
el u
ltimo mes, etc.
En resumen, el director del departamento de ventas necesita informes distintos a los que
produce la aplicacion de las figuras 2.2 y 2.3.

2.1 Fundamentos del modelo de datos multidimensional: Un modelo para

consulta

Producto

Sept 2004

Sept 2005

Figura 2.4: Informe de ventas entre septiembre de 2004 y septiembre de 2005

2.1.1.

Principios de los sistemas operacionales o transaccionales

El objetivo principal no es mas que registrar transacciones, esto es, entrada y modificacion
de los datos; y estan destinados a usuarios operacionales (en nuestro ejemplo, los cajeros).
Pero como ya hemos visto, necesitamos informes. Cuales? Muchos y de muy diversa
ndole: los que el usuario determine cuando analiza la informacion (en vez de a priori, durante
el dise
no de la base de datos).
Obtener el informe de la figura 2.4 es sencillo pero no trivial. Muy probablemente el
decisor no sabra hacerlo. El trabajo del informatico en ese caso es crear informes a medida.

2.1.2.

Principios de los sistemas multidimensionales

Los modelos relacionales y E/R se dicen que son homogeneos porque todas las relaciones
tienen la misma importancia (recordemos que estan orientados a transacciones y no tanto a
consultas).
El modelo multidimensional es no homogeneo (con unas relaciones mas importantes que
otras) y no orientado a transacciones, sino orientado a consultas.
Los informes requeridos por el director del departamento de ventas seran del tipo cu
anto
de que, quien, cu
ando, c
omo, .... En este caso, cu
anto sera lo importante (tambien llamado
foco de atencion) y el resto sera lo adicional.

Figura 2.5: Hechos con mediciones y dimensiones

En nuestro ejemplo, como se observa en la figura 2.6, el foco de atencion es una venta.

Figura 2.6: Ejemplo del diagrama multidimensional de una venta

10

Captulo 2. El Modelo de Datos Multidimensional

Como se representa esto? (Lo subrayado es lo importante y el resto es lo adicional).

Boli Azul, Promo: Ninguna, 10/10/2005 17:22:18, Caja-3, La Chana, Ma Carmen,
Pepe, no 318, 1, 060 Euros, 060 Euros, 020 Euros
Simplificando el ejemplo de la figura 2.6 tendramos algo como:

Figura 2.7: Ejemplo simplificado del diagrama multidimensional de una venta

Boli Azul, 10/10/2005, La Chana, 1, 060 Euros, 020 Euros

2.1.3.

Funcionamiento de los sistemas multidimensionales

En el modelo multidimensional la representacion de un dato es un punto en el espacio.

La representacion espacial de la entrada anterior se puede ver en la figura 2.8.

Figura 2.8: Representacion de un dato en el espacio

Si por ejemplo los domingos la tienda de La Chana no abre, no existira una lnea de puntos
en el espacio correspondiente a cada domingo en la tienda de La Chana (equivalentemente,
si el 09/10/05 no se vendio ning
un boli azul en la tienda de La Chana, no existira ese punto).
Por lo tanto, la representacion en el espacio de todos los datos resulta ser un cubo no
macizo como el que se ve en la figura 2.9. Con mas de tres dimensiones lo correcto es hablar
de hipercubo, aunque nosotros siempre utilizaremos el termino cubo.

Figura 2.9: Representacion en el espacio de todos los datos

2.1 Fundamentos del modelo de datos multidimensional: Un modelo para

consulta

11

En nuestro ejemplo de la cadena de supermercados, los productos tienen varios atributos, como descripcion, tipo, marca, provincia de fabricacion, etc. Tambien puede resultar
interesante agrupar el eje de los productos seg
un alguno o algunos de estos atributos.
Esta operacion de agrupar los datos de una determinada dimension seg
un alguno o algunos
de sus atributos recibe el nombre de roll-up (vease la figura 2.10), mientras que la operacion
inversa se conoce como drill-down.
El extremo de roll-up consistira en agrupar todos los puntos de una dimension en un
solo punto. Por otra parte, una vez que se ha hecho roll-up, para poder hacer drill-down
se plantea un problema irresoluble si no se almacenaran los datos de mas bajo nivel (en
nuestro ejemplo, las ventas de productos individuales).
Por lo tanto, para hacer drill-down lo que en realidad se hace es un roll-up a partir del
cubo base (cubo con todos los datos al menor nivel de detalle posible) para conseguir el
cubo que se desea obtener.

Figura 2.10: Roll-up en la dimension producto

Tomar una capa del cubo se le dice slice. Por ejemplo, ver solamente los datos referidos
a bolgrafos (o ver solamente los productos fabricados en Murcia).
Por contra, dice consiste en hacer cubiletes mas peque
nos a partir del cubo total. Por
ejemplo, ver todas las ventas de bolgrafos en el mes de enero.
Con slice se dice que se pierde una dimension (vease la figura 2.11), mientras que con
dice esto no ocurre.
Vistas estas operaciones podemos afirmar que: un modelo de datos multidimensional es
mas potente cuantos mas atributos tenga cada dimension, puesto que esto nos permitira hacer
roll-up (equivalentemente, drill-down) de muchas mas formas distintas. Dicho de otro modo,
a mayor n
umero de atributos en cada dimension, mayor n
umero de posibles informes.

12

Captulo 2. El Modelo de Datos Multidimensional

Figura 2.11: Operacion slice

2.1.4.

El modelo de datos multidimensional a Nivel Conceptual

Los sistemas OLTP (On Line Transactional Processing, vease la figura 2.12) son los que
hemos aprendido en cursos anteriores. Ahora estudiaremos los sistemas OLAP (On Line
Analytical Processing).

Figura 2.12: Sistemas OLTP

En el modelo de datos multidimensional, a diferencia del E/R o el ODL, existe el problema
de que no hay un u
nico modelo de datos multidimensional aceptado por todo el mundo. Lo
que s hay, sin embargo, es un consenso acerca de los elementos generales.
Los elementos generales en los que existe consenso son los siguientes:
Hechos
Nombre
Mediciones, que pueden ser derivadas o no derivadas
Dimensiones
Nombre
Niveles
Nombre
Descriptores

Figura 2.13: Ejemplo de hecho con mediciones y dimensiones con descriptores

2.1 Fundamentos del modelo de datos multidimensional: Un modelo para

consulta

13

En el ejemplo mostrado en la figura 2.13 la medicion Beneficio es derivada, ya que

puede ser calculada a partir de las mediciones PVP y Coste siguiendo la siguiente formula:
Beneficio = PVP - Coste.
No todos los atributos de una entidad en el modelo E/R seran niveles en el modelo de
datos multidimensional; unos s seran niveles, pero otros seran descriptores de niveles.
Toda descomposicion correcta de una dimension en sus correspondientes niveles debe
tener una estructura similar a la mostrada en la figura 2.14.

Figura 2.14: Estructura de la descomposicion de una dimension por niveles

La figura 2.15 muestra dos ejemplos de descomposicion de dimensiones en niveles.

Figura 2.15: Ejemplos de descomposicion de una dimension por niveles

2.1.5.

Implementaci
on de los sistemas multidimensionales: Nivel L
ogico

Existen varias posibilidades:

1. SGDBMD. Consiste en usar estructuras de datos a medida tales como arboles, ndices,
matrices, etc. Se les conoce como MOLAP (Multidimensional OLAP ).
2. ROLAP (Relational OLAP ). Se crea un modelo de datos multidimensional a partir de
una BBDD relacional que puede estar normalizada o no.
3. O3LAP (Object Oriented OLAP )
4. HOLAP (Hybrid OLAP ). Estructuras de datos a medida junto con BBDD.

14

Captulo 2. El Modelo de Datos Multidimensional

Nosotros trabajaremos con ROLAP, no obstante a continuacion se presentan las ventajas

e inconvenientes entre ROLAP y MOLAP:
MOLAP
Mas rapido
SGBD nuevo
- No hay especialistas
- Gestion adicional
Lmite (muy alto en el no de dimensiones)

ROLAP
Rapido (y aumentando)
SGBD Relacional
- Hay especialistas
- Deben aprender lo nuevo
Sin lmite en el no de dimensiones

Tras esta comparativa y sabiendo que hoy por hoy en el mercado imperan los sistemas
ROLAP vamos a ver como se implementan estos. Recordamos que el dise
no a nivel conceptual
del modelo de datos multidimensional de nuestro ejemplo de la cadena de supermercados tena
un aspecto similar al mostrado en la figura 2.16.

Figura 2.16: Dise

no a nivel conceptual del modelo de datos multidimensional
Para implementar este dise
no sobre una base de datos relacional comenzaremos creando

las tablas que consideremos necesarias. Estas

son las mostradas en la figura 2.17.

Figura 2.17: Implementacion en Estrella

Como vemos hemos creado una tabla para cada dimension y otra para los hechos. A este
tipo de implementacion se le conoce como implementacion en estrella.

2.1 Fundamentos del modelo de datos multidimensional: Un modelo para

consulta

15

As los atributos que podra tener, por ejemplo,

la tabla Producto son:

Marca
Producto-nombre

Fabricante

Codigo barras
Provincia fabricacion
Color


Tipo emvase

Familia
Peso
Nombre

Departamento
Seccion
Nombre
Nombre

Responsable
Responsable
Algunas entradas (o registros) de la tabla Producto podran ser, por ejemplo:
Agua Lanjar
on 05L, XXX, NA, PVC, 05K, Lanjar
on, Aguas Lanjar
on, Granada,
Aguas, Bebidas no Alcoh
olicas, ...
Agua Lanjar
on 15L, XXX, NA, PVC, 15K, Lanjar
on, Aguas Lanjar
on, Granada,
Aguas, Bebidas no Alcoh
olicas, ...
Agua Lanjar
on 5L, XXX, NA, PVC, 5K, Lanjar
on, Aguas Lanjar
on, Granada, Aguas,
Bebidas no Alcoh
olicas, ...
Otros ejemplos de registros para la tabla Tiempo podran ser:
24/10/2005, lunes, no fin de semana, laborable, oto~
no, 43, octubre, 10, 2005
no, 43, octubre, 10, 2005
25/10/2005, martes, no fin de semana, laborable, oto~
Como vemos, con esta implementacion aparece claramente el problema de la informacion
replicada. Por lo tanto, la solucion pasa por normalizar nuestro dise
no. Y as obtenemos el
conjunto de tablas que aparecen en la figura 2.18.

Figura 2.18: Implementacion en Copo de Nieve

A este tipo de implementacion se le conoce como implementacion en copo de nieve y
en ella se tiene una tabla por cada nivel de cada dimension. La principal diferencia con una
implementacion en estrella es que esta u
ltima no esta normalizada, mientras que con copo de
nieve s que lo esta.
Por otra parte, las consultas en una implementacion en estrella son mucho mas faciles y
rapidas ya que implican muchas menos tablas con muchas menos referencias a otras tablas.
En copo de nieve, sin embargo, se esta mas cercano al nivel conceptual, aunque tambien
sera posible presentar una implementacion en estrella seg
un un dise
no de nivel conceptual
(bastara con indicar que atributos de las dimensiones son niveles y cuales son descriptores).

16

Captulo 2. El Modelo de Datos Multidimensional

Otra diferencia que podramos pensar que existe entre ambas implementaciones es la del
espacio ocupado por cada una de ellas. Para analizar esto recordemos lo que decamos sobre
la normalizacion: cuando esta se aplica conseguimos evitar anomalas en las modificaciones,
ya que se coloca cada dato en un solo sitio, con el consecuente ahorro de espacio.
Vamos a estimar el tama
no ocupado por una implementacion en estrella suponiendo que
tenemos los siguientes valores: 60.000 productos, 1825 das, 20 tiendas y 500 promociones.
Parece evidente que las tablas de cada una de las dimensiones seran mas grandes que con
una implementacion de copo de nieve. Ahora bien, en cuanto a la tabla de los hechos (la
ventas), que significan cada uno de sus registros?
Venta en un da, de un producto, en una tienda, bajo una promoci
on
24/10/2005, Botella Agua 05L, Mercadona Parque Almunia, sin promoci
on,
25 u, 05 Euros, 03 Euros
Por otra parte debemos plantearnos cuantos registros puede tener la tabla de los hechos.
Pues como maximo tendra el producto 60000 1825 20 500 = 10 095 1012 , lo cual dara
lugar a un cubo totalmente macizo que, como ya vimos, no es nada probable. Pensemos que
lo que estaramos diciendo con ello es que cada da se han vendido cada uno de los productos,
en cada una de las tiendas, bajo cada una de las promociones.
Un estimacion aproximada del n
umero real de registros podra ser:
1825 das 20 tiendas 10 % de 60000 productos 10 5 promociones = 3280 5 106 registros
As, la tabla realmente grande es la de los hechos y es ah donde debemos esforzarnos por
ahorrar espacio. Un calculo del espacio ocupado por cada registro de dicha tabla podra ser:
Mediciones
Cantidad 2 bytes
PVP
4 bytes
Coste
4 bytes
10 bytes

Llaves externas
Fecha: dd/mm/aaaa
8 bytes
Producto: codigo barras 10 bytes
Tienda: nombre
15 bytes
Promocion: nombre
25 bytes
58 bytes

Si convenimos que cada entrada ocupa 68 bytes, el tama

no total de la tabla sera de
3280 5 106 68 ' 220 338 GB.
Moviendonos en estos ordenes de espacio podemos afirmar que el espacio ocupado por las
tablas de las dimensiones es despreciable con respecto al ocupado por la tabla de los hechos.
Y puesto que dicha tabla tiene el mismo tama
no en una implementacion en estrella que en
una en copo de nieve, concluimos que el espacio ocupado no es un factor determinante o
decisivo para decantarse por una implementacion u otra.
No obstante siempre interesa ahorrar todo el espacio posible. Para conseguir este objetivo
podramos pensar en reducir el n
umero de dimensiones o eliminar mediciones de la tabla de
hechos, pero esto sera, en la mayora de los casos, una solucion incorrecta.
Lo que s que se puede hacer es convertir las llaves externas antes vistas en llaves generadas, que consisten basicamente en asignar un n
umero a cada registro distinto en las tablas
de las dimensiones (numerarlos, en definitiva). Con esta transformacion tendramos que:
Mediciones
Cantidad 2 bytes
PVP
4 bytes
Coste
4 bytes
10 bytes

Llaves generadas
Fecha
2 bytes
Producto
4 bytes
Tienda
2 bytes
Promocion 2 bytes
10 bytes

Es decir (10 + 10) 20 bytes por cada registro, ocupando as la tabla completa un total de
3280 5 106 20 = 60 57 GB. No olvidemos que ahorrando espacio tambien estamos mejorando
el rendimiento global del sistema, reduciendo, por ejemplo, el tiempo de respuesta ante una
consulta.

2.2 Dise
no multidimensional

2.2.

17

Dise
no multidimensional

En esta seccion vamos a estudiar como realizar un dise

no tanto a nivel conceptual como a
nivel logico de un sistema OLAP. Sera el equivalente a aprender el modelo E/R y el modelo
relacional en sistemas OLTP.

2.2.1.

Pasos para realizar un dise

no multidimensional a nivel conceptual

1. Seleccionar el
area de negocio
En este primer paso debemos determinar quien sera el usuario dentro de la piramide de
la organizacion (figura 2.1) que usara la aplicacion.
Es mas, debemos determinar el area, el usuario y los objetivos del mismo (es decir, las
decisiones a las que se va a dar soporte).
En nuestro ejemplo el area es el departamento de ventas, el usuario es el director del
departamento de ventas y los objetivos son permitirle tomar decisiones sobre precios de productos, promociones, etc.
2. Definir los hechos
a) Ventas de un producto en una tienda, en una fecha, bajo una promocion.
b) Ventas de un producto en una lnea de ticket, una tienda, en una fecha, bajo una
promocion.
3. Definir las dimensiones. Bases
Identificamos todas las dimensiones que se nos ocurran con todos los atributos que pensemos (siempre que podamos obtener los datos de alguna fuente), ya que cuanto mayor sea
el n
umero de dimensiones con sus respectivos descriptores, mayor es el n
umero de combinaciones posibles para hacer roll-up, es decir, mayor es el n
umero de posibles informes que se
pueden crear.
En ese momento definimos las bases, que no son mas que el conjunto de dimensiones que
identifican unvocamente a cada registro de los hechos.
En nuestro ejemplo la base la forman las dimensiones Producto, Tienda, Fecha y Promoci
on,
aunque podran haber sido otras, como por ejemplo LineaTicket de un Ticket, o bien Fecha,
Hora, Caja y Tienda.
En ocasiones puede ocurrir que nos encontremos con una dimension con muchsimos
registros y con mucha informacion repetida, como ocurre en la figura 2.19.

Figura 2.19: Dimensiones sin desdoblar

18

Captulo 2. El Modelo de Datos Multidimensional

La solucion pasa entonces por desdoblar la dimensi

on, que no es otra cosa que tomar
una dimension y dividirla en dos, consiguiendo as tener mucha menos informacion replicada, con el consecuente ahorro de espacio. La figura 2.20 muestra el desdoblamiento de las
dimensiones que veamos en la figura 2.19.

Figura 2.20: Dimensiones de la figura 2.19 desdobladas

4. Identificar las mediciones. Aditividad
Ya conocemos lo que son las mediciones; por otra parte, la aditividad es una caracterstica
de estas que nos indica como agregarlas (es decir, como hacer roll-up con ellas).
Existen tres tipos de mediciones atendiendo a su aditividad:
Aditivas. Se puede aplicar la SUMA por todas las dimensiones. Es el caso de las
mediciones No art
culos, No clientes o Beneficio.
No aditivas. No se puede aplicar la SUMA por ninguna dimension. Por ejemplo el PVP
o el Coste.
Semi-aditivas. Se puede aplicar la SUMA por algunas dimensiones. Como ocurre, por
ejemplo, con el Saldo de la figura 2.21, que se puede sumar por las dimensiones Cliente
y Cuenta, pero no por la dimension Fecha.1

Figura 2.21: Saldo de una cuenta de ahorros

Las mediciones derivadas habitualmente seran aditivas, mientras que las no derivadas
pueden ser de cualquier tipo. Generalmente son preferibles las mediciones aditivas frente a
las no aditivas y las semi-aditivas.Entre la opcion (a) y la (b), es preferible la opcion (b).
U. Vendidas
PVP
CosteUnitario
BeneficioUnitario
(a)

U. Vendidas
ImporteVenta
CosteVenta
BeneficioVenta
(b)

5.Validaci
on
1. Comprobar que hay fuentes de datos (generalmente aplicaciones OLTP).
2. Estimar el n
umero de registros de los hechos y de alguna dimension, si esta es especialmente grande.
1

Aunque esto estara bastante bien ;-)

2.2 Dise
no multidimensional

2.2.2.

19

Pasos para realizar un dise

no multidimensional a nivel l
ogico

Como ya vimos anteriormente, con un dise

no multidimensional en estrella, los hechos se
corresponden con una tabla, as como cada una de las dimensiones.
En la figura 2.22 se muestra una estimacion del n
umero de registros para cada dimension.

Figura 2.22: Dise

no a nivel logico

Dimensiones degeneradas
Un registro de LineaTicket tendra el siguiente aspecto:
Lnea
1
2
3

Ticket
328-25
328-25
328-25

Por lo tanto, consideramos que el atributo Lnea de la tabla LineaTicket no es relevante

para el decisor y lo eliminamos. Pero si vamos un poco mas lejos y nos damos cuenta de que el
atributo Ticket tampoco tiene importancia, entonces eliminamos la dimension LineaTicket
entera.
A este tipo de dimension se le llama dimensi
on degenerada, la cual tiene una llave
externa en la tabla de hechos pero no tiene una tabla de dimension asociada porque no
aporta informacion adicional.
Otro ejemplo viene con los registros de la tabla Hora, los cuales tendran un aspecto
similar al siguiente:
ID hora
00:00:00
..
.

Subparte da
Noche
..
.

Parte da
Noche
..
.

10:00:00
..
.

Media ma~
nana
..
.

Ma~
nana
..
.

16:00:00
..
.

1a hora de la tarde
..
.

Tarde
..
.

23:59:59

Noche

Noche

Para empezar podramos quedarnos solo con aquellos registros de las horas en las que
permanecieran abiertas las tiendas. Pero si fueramos mas alla y decidieramos prescindir de los
atributos subparte del da y parte del da, nos encontraramos nuevamente con una dimension
degenerada.

20

Captulo 2. El Modelo de Datos Multidimensional

Dimensiones cambiantes
Hasta ahora hemos considerado que las dimensiones eran fijas, estaticas, mientras que a
los hechos se le estan a
nadiendo nuevos registros continuamente.
Pero la realidad no es del todo as, puesto que existen las llamadas dimensiones cambiantes. Y estos cambios en los datos de las dimensiones deben quedar reflejados de alguna
manera. Existen cuatro posibilidades:
Tipo 1 Sobreescribir los valores antiguos con los nuevos.
Antes de los cambios, tendramos, por ejemplo:
Nombre
F
elix G
omez

Telefono
968269977

Telefono
958206925

Y despues de los cambios, tendramos:

Nombre
F
elix G
omez

Esta solucion no siempre sera aceptable, puesto que no podemos perder de vista que estamos cambiando la historia.
Tipo 2 Crear un nuevo registro con el nuevo valor del registro correspondiente.
Antes de los cambios, tendramos, por ejemplo:
ID
34

CodBarras
1X73F624J

Descripcion
Agua Lanjar
on 5L

Seccion
Alimentaci
on

Y despues de los cambios, tendramos:

ID
34
90

CodBarras
1X73F624J
1X73F624J

Descripcion
Agua Lanjar
on 5L
Agua Lanjar
on 5L

Seccion
Alimentaci
on
Aguas

Esta solucion, adecuada en algunos casos, tiene el inconveniente del incremento en el

n
umero de registros de la dimension cambiante.
nadir nuevos campos a los registros ya existentes.
Tipo 3 A
Antes de los cambios, tendramos, por ejemplo:
ID
34

CodBarras
1X73F624J

Descripcion
Agua Lanjar
on 5L

Seccion
A

Y despues de los cambios, tendramos:

ID
34
34

CodBarras
1X73F624J
1X73F624J

Descripcion
Agua Lanjar
on 5L
Agua Lanjar
on 5L

Seccion
A
B

NuevaSeccion
B
C

Aunque otra opcion podra ser:

ID
34

CodBarras
1X73F624J

Descripcion
Agua Lanjar
on 5L

Seccion
A

NuevaSeccion
B

UltimaSecci
on
C

A este tipo tambien se le conoce como realidad alternativa, puesto que permite ver la
informacion almacenada, desde distintas perspectivas.

2.2 Dise
no multidimensional

21

Tipo 6 (3+2+1)
Antes de los cambios, tendramos, por ejemplo:
ID
34

CodBarras
1X73F624J

Descripcion
Agua Lanjar
on 5L

Seccion
A

NuevaSeccion
A

Ultimo
S

Seccion
A
B

NuevaSeccion
B
B

Ultimo
No
S

NuevaSeccion
C
C
C

Ultimo
No
No
S

Y despues de los cambios, tendramos:

ID
34
96

CodBarras
1X73F624J
1X73F624J

Descripcion
Agua Lanjar
on 5L
Agua Lanjar
on 5L

Si hubiera un cambio mas, entonces tendramos:

ID
34
96
132

CodBarras
1X73F624J
1X73F624J
1X73F624J

Descripcion
Agua Lanjar
on 5L
Agua Lanjar
on 5L
Agua Lanjar
on 5L

Seccion
A
B
C

A este problema se le conoce como el problema de las dimensiones lentamente cambiantes

o SCD (Slowly Changing Dimension). Sin embargo, tambien existen otro tipo de dimensiones
con campos rapidamente cambiantes. Es el caso del campo PVP en la dimension Producto.
Si el PVP de un producto lo ponemos en la dimension Producto, podramos adoptar una
solucion de tipo 1. Otra opcion sera poner el PVP en la tabla de los hechos. Y una tercera
alternativa pasara por desdoblar la dimension Producto en funcion de la estabilidad de sus
campos, dejando de un lado los atributos lentamente cambiantes y del otro lado los atributos
rapidamente cambiantes.

2.2.3.

Caso de dise
no seg
un fotografa peri
odica

Hasta ahora hemos visto que en los hechos se registraban transacciones (de ventas, por
ejemplo). Ahora vamos a tomar como ejemplo uno en el que el foco de atencion es el inventario
de un almacen.
El enfoque 1 que se muestra en la figura 2.23 es equivalente al ya hecho para las ventas.

Figura 2.23: Enfoque 1: Transacciones de almacen

En el enfoque 2 mostrado en la figura 2.24 los hechos registran el inventario de cada
producto en cada fecha y en cada almacen, con lo que se tiene un cubo solido, sin huecos.
A1, P1, F1. 30u, 50 Euros, 70 Euros
A1, P2, F1. 10u, 20 Euros, 30 Euros
A1, P2, F2. 20u, 15 Euros, 20 Euros
Lo importante de esto es ver que para un usuario podra valer cualquiera de los dos
enfoques dependiendo de sus necesidades a la hora de generar informes. De hecho, es posible
que necesite ambos enfoques.

22

Captulo 2. El Modelo de Datos Multidimensional

Figura 2.24: Enfoque 2: Fotografa periodica de almacen

Para ello es necesario poder crear informes combinados a partir de distintos esquemas.
A esta operacion multidimensional de crear informes combinados se le conoce como drillacross, y consiste en llevar las condiciones definidas en un informe sobre un esquema (slice
& dice) a otro esquema.
Nivel de ventas
 Drill-across
Nivel de almacenamiento

(en un lugar y periodo)

(en un lugar y periodo)

La condicion necesaria que se debe cumplir para poder aplicar drill-across es que ambos
esquemas compartan, al menos, las dimensiones sobre las que se definen las condiciones.
A esta combinacion de dimensiones procedentes de distintos esquemas se le llama constelacion (ver figura 2.25), aunque cada base de datos multidimensional individual no tiene por
que ser necesariamente en estrella.

Figura 2.25: Constelacion

Otra representacion de las constelaciones es la Data Warehouse Bus Architecture, como
se puede observar en la figura 2.26.

Figura 2.26: Data Warehouse Bus Architecture

Seg
un la herramienta que se use puede ser suficiente incluso con que se compartan solamente aquellas partes de las dimensiones sobre las que se definen las restricciones.

2.2 Dise
no multidimensional

2.2.4.

23

Otros casos de dise

no

Hechos sin mediciones

Figura 2.27: Foco de atencion: Venta

Dado el esquema de la figura 2.27, deseamos crear un informe que nos muestre aquellas
promociones que no han tenido exito.
Para ello es necesario centrar nuestro foco de atencion en las promociones, como se muestra
en la figura 2.28.

Figura 2.28: Foco de atencion: Promocion

ID prod
35

ID fecha
6

ID tienda
69

Promocion
43

Existe
1

Los registros de la tabla de hechos de este u

ltimo esquema tendran siempre un 1 en el
atributo Existe, de tal forma que la operacion SUM sera equivalente a la operacion COUNT.
A este tipo de hechos sin mediciones tambien se les conoce como factless facts.
Para resolver nuestro informe que muestre las promociones que no han tenido exito, necesitaremos hacer drill-across entre ambos esquemas.
Otro ejemplo es el caso de las carreras de taxi planteado en la practica 2. Que ocurre si
se pueden aplicar varios suplementos a la vez a una misma carrera?
Solucion 1. Medicion especfica de cada suplemento. Solucion mala si hay muchos suplementos.
Solucion 2. Una medicion y en la dimension combinaciones de los suplementos. Solucion
mala si hay muchos suplementos.
Solucion 3. Centrar el foco de atencion en los suplementos y hacer drill-across.

24

Captulo 2. El Modelo de Datos Multidimensional

Dimensiones de mediciones
Otro esquema alternativo al presentado en la figura 2.27 es el que se puede observar en
la figura 2.29.

Figura 2.29: Dimension de mediciones

ID prod
35

ID fecha
6

ID tienda
69

ID Promo
43

ID Medicion
2

Medida
25

Como se observa, cada registro de la tabla de hechos tendra un u

nico identificador de
medicion, con su correspondiente valor en el atributo Medida. De esta forma la tabla de
hechos tendra tantos mas registros como mediciones haya; es decir que si, por ejemplo, hay
cinco mediciones, la tabla de hechos tendra cinco veces mas registros.
Este tipo de esquema tiene sentido si existen muchas mediciones para los hechos, pero
solo unas pocas en cada hecho tienen valor y el resto estan indefinidas.
Dimensiones caj
on de trastos
Si se da la situacion de tener un dise
no en el que hay muchas dimensiones con poco valores
cada una, podemos agruparlas en una u
nica dimension, generando todas las combinaciones
posibles de valores.

2.2.5.

Dise
no de sistemas OLTP vs OLAP

Algunas diferencias en el dise

no de ambos sistemas son las que a continuacion se citan:
Conocimiento de los sistemas por parte de los usuarios.
Los sistemas OLTP son hoy por hoy mas conocidos que los OLAP, sus caractersticas,
sus posibilidades, etc. Es tarea nuestra, por tanto, formar e informar al usuario final.
Granuralidad de los hechos (equivalentemente, nivel de detalle).
Conviene considerar siempre el nivel de detalle mas bajo posible, siempre que se pueda
implementar.
Sacar los datos para guardar en el sistema OLAP de alg
un sistema OLTP (en la mayora
de los casos).

2.3 Procesamiento de consultas y optimizaci

on

2.3.

25

Procesamiento de consultas y optimizaci

on

2.3.1.

Patr
on de consulta y t
ecnicas de indexaci
on

Todo informe creado sobre una base de datos multidimensional consta de una cabecera
o seleccion, unas columnas que son atributos de las dimensiones y otras columnas que son
mediciones de los hechos.
1. Seleccion sobre las dimensiones correspondientes. Por ejemplo: Bebidas, Enero2005.
Reduce las dimensiones solo a aquellos registros que cumplen las condiciones.
2. Obtener los atributos de las dimensiones para el informe.
3. Obtener los hechos asociados a los atributos seleccionados. Para ello existen dos posibilidades:
a) Hacer un join entre cada dimension y los hechos. Pero el resultado de cada uno de
esos joins es una tabla de tama
no similar a la de los hechos. Problema: resultados
intermedios demasiado grandes.

Figura 2.30: Join entre cada dimension y los hechos

b) Obtener todas las combinaciones (producto cartesiano) de los registros de las dimensiones y despues hacer join con los hechos.

Figura 2.31: Join del producto cartesiano de las dimensiones y los hechos

Indice de mapa de bits

Inventado en los 70 y redescubierto en los 90, ha resultado ser una solucion muy buena a
la hora de indexar los registros en las bases de datos multidimensionales.
Sea, por ejemplo, la siguiente tabla:
Key
1
2
3
4
5
6

Nombre
Pepe
Alberto
Alberto
Felix
Concha
Pepe

Sexo
Hombre
Hombre
Hombre
Hombre
Mujer
Hombre

26

Captulo 2. El Modelo de Datos Multidimensional

Dada dicha tabla podramos crear un ndice de mapa de bits por cada atributo (nombre,
sexo, ...) mediante una nueva tabla que tuviera una columna por cada valor distinto del
atributo elegido. Y para cada uno de esos valores, se tendra una columna de ceros y unos
(tantos como registros tiene la tabla original) donde un 0 en la columna i-esima y en la posicion
j-esima indica que el valor i-esimo del atributo elegido NO se encuentra en el registro j-esimo
de la tabla original. Un 1 en esa misma posicion indica lo contrario. Por ejemplo:
Key
1
2
3
4
5
6

Nombre
Pepe
Alberto
Alberto
Felix
Concha
Pepe

Sexo
Hombre
Hombre
Hombre
Hombre
Mujer
Hombre

Felix
0
0
0
1
0
0

Nombre
Alberto Concha
0
0
1
0
1
0
0
0
0
1
0
0

Pepe
1
0
0
0
0
1

Sexo
Hombre Mujer
1
0
1
0
1
0
1
0
0
1
1
0

Del mismo modo, si quisieramos obtener los registros de todas aquellas personas cuyo
nombre fuera Alberto y cuyo sexo fuera mujer, sera tan sencillo como hacer:
Alberto
0
1
1
0
0
0

AND

Mujer
0
0
0
0
1
0

0
0
0
0
0
0

As, el DNI, por ejemplo, no sera un buen atributo para hacer ndices de mapas de bits
(ya que por cada columna de ceros y unos solo habra un 1 y el resto seran 0). La edad, sin
embargo, s podra ser un buen atributo para tal efecto.
Join index (ndice de join)
Se trata de un ndice creado sobre una tabla que considera valores de atributos de otra
tabla con la que se puede hacer join (podramos decir que es un join materializado).
Key
1
2
3
4
5
6

Nombre
Pepe
Alberto
Alberto
Felix
Concha
Pepe

Sexo
Hombre
Hombre
Hombre
Hombre
Mujer
Hombre

Venta
Cliente
4

Felix
1
0
0
0
0
0
0
1

Nombre
Alberto Concha
0
0
0
0
1
0
1
0
0
0
0
0
0
1
0
0

Pepe
0
1
0
0
1
1
1
1

Procesamiento de consultas con ndices de mapa de bits

Crear ndices de mapa de bits sobre los campos de las dimensiones con muchos valores
repetidos, para realizar la seleccion de datos de las dimensiones. Por ejemplo, el campo
mes de la dimension Fecha.
Crear mapas de bits en los hechos sobre las llaves externas, o bien join index sobre
valores de atributos de las dimensiones usados muy frecuentemente.

2.3 Procesamiento de consultas y optimizaci

on

27

Figura 2.32: Procesamiento de consultas con ndices de mapa de bits

As, los pasos anteriormente dichos para la realizacion de una consulta ahora se llevaran
a cabo de la siguiente manera:
1. Seleccion de los registros de las dimensiones. Ahora consiste en seleccionar las columnas
de mapas de bits que correspondan y hacer un OR entre todas ellas.
Por ejemplo, supongamos que queremos obtener todos los registros de los hechos de las
ventas realizadas en el mes de febrero sobre el producto aceite.
Supongamos que el mapa de bits sobre el campo mes de la dimension Fecha nos dice que
los registros 230 al 290 (de dicha dimension) corresponden al mes de febrero. Entonces
tomamos las columnas 230 a 290 del mapa de bits de las llaves generadas de la dimension
Fecha en los hechos y hacemos un OR de todas ellas. Lo mismo se hace para el producto
aceite.
2. Combinacion de todas las dimensiones. Que ahora no es otra cosa que hacer un AND
de todas las columnas de ceros y unos anteriormente seleccionadas.
Para nuestro ejemplo, tendramos que hacer un AND entre la columna que nos indexa
aquellas ventas del mes de febrero y la que os indexa las ventas del producto aceite.
3. Obtener los registros de la tabla de hechos indexados por la columna de bits resultado.

2.3.2.

Partici
on de la tabla de hechos

El SGBD permite particionar (dividir) tablas en funcion de valores de uno o mas campos
(llaves o partes de ellas), de tal forma que se tiene una u
nica tabla logica con varias tablas
fsicas asociadas.
Con esto se facilita la gestion, mejorando las copias y restauraciones e incluso puede que
consultas. Por ello la tabla de hechos es una buena candidata para perticionarla, pero en
funcion de que llaves?
En el caso de las ventas la mejor particion sera en funcion del Tempo (la Fecha), ya que
proporcionara una distribucion bastante uniforme de los datos en las distintas tablas fsicas,
aunque tambien podra valer la tienda o una combinacion de ambas.
Las particiones son transparentes al usuario y se pueden crear y destruir dinamicamente.

28

2.3.3.

Captulo 2. El Modelo de Datos Multidimensional

Definici
on de agregados

Como ya dijimos hace tiempo, en un dise

no multidimensional lo que se almacena es el
cubo base, a partir del cual se pueden obtener todos los informes posibles.

Figura 2.33: Cubos agregados

Sin embargo, para consultas muy frecuentes se pueden tener cubos al nivel de detalle
requerido, con lo que se ahorra tiempo, en detrimento del espacio y con el consecuente mantenimiento (que no siempre es sencillo). Estos cubos reciben el nombre de agregados.
Que agregados definir? Los de uso mas frecuente.
Como usarlos? De forma transparente al usuario (este no sabe que hay agregados).
El navegador de agregados

Figura 2.34: Navegador de agregados

El navegador de agregados examina la consulta del usuario y comprueba si alg
un agregado
la satisface, es decir, comprueba que tiene todos los atributos que aparecen en la consulta. Si
no hay ning
un agregado que satisfaga la consulta, esta se realiza sobre el cubo base.
Lo ideal es ordenar los agregados por tama
no y buscar primero en los mas peque
nos.
El n
umero total de agregados posibles se calcula como
!
numDim
Y
ni 1
i=1

donde ni es el n
umero de niveles de la dimension i-esima (y el -1 es para no contar el cubo
base).

2.3 Procesamiento de consultas y optimizaci

on

29

Fallo en la dispersi
on de los agregados

Figura 2.35: Fallo en la dispersion de los agregados

Dado el cubo base de la figura 2.35, supongamos que este tiene 150 106 de registros.
150 106
Entonces podramos pensar que el agregado a nivel de mes tendra
registros y, del
30
6
150 10
mismo modo, el agregado a nivel de a
no,
registros.
365
Sin embargo esta suposicion es erronea, ya que en los agregados existe menos dispersion
(los huecos son mas peque
nos) que en el cubo base.
De este modo, si el n
umero de registros del cubo base se calcula como
20 tiendas (60,000 productos 7 %) 1825 das 150 106
entonces el n
umero de registros del agregado a nivel de mes sera
20 tiendas (60,000 productos 80 %) 60 meses = 57,6 106


6=

150 106
= 5 106
30

y el n
umero de registros del agregado a nivel de a
no, como
20 tiendas (60,000 productos 100 %) 5 a
nos = 6 10

150 106
6=
411 103
365

El n
umero de registros en los agregados no se reduce en la misma proporcion que lo hacen
los ejes de coordenadas.

30

Captulo 2. El Modelo de Datos Multidimensional

Captulo 3

La F
abrica de Informaci
on
Corporativa
3.1.

Arquitectura del sistema de informaci

on: la FIC

La FIC (Fabrica de Informacion Corporativa) recibe este nombre porque lo que se hace
en ella es tomar los datos a partir de las fuentes y con ellos fabricar informes que serviran
de soporte a los decisores.

3.1.1.

Arquitectura seg
un Kimball

Figura 3.1: Fabrica de Informacion Corporativa seg

un Kimball
Kimball asemeja la fabrica de informacion corporativa a un restaurante, con sus distintas
dependencias: mercado, cocina y comedor.
31

32

Captulo 3. La F
abrica de Informaci
on Corporativa

Mercado.
El mercado representa las fuentes de datos, esto es, las aplicaciones previamente existentes en la organizacion (tambien conocidas como Legacy System).
Cocina.
Aqu es donde se cocinan los datos. Se extraen los datos necesarios de las fuentes,
se transforman (se depuran, se modifican y se integran) y se cargan en los diferentes
cubos.
Este proceso se conoce con el nombre de ETL (Extraction, Transformation, Load ), de
Extraccion, Transformacion y Carga.
Tambien existe una carga inicial de todos los datos historicos disponibles que el usuario necesite (por ejemplo, los datos de los u
ltimos 4 a
nos). Posteriormente se realizan
refrescos periodicos de los nuevos datos que se van produciendo.
Comedor.
El usuario solo ve el comedor. Tanto la cocina, como el mercado son propiedad exclusiva del informatico. Aqu puede tener lugar el Data Warehouse Bus Architecture que
vimos en el captulo 2, para integrar unos cubos con otros.

3.1.2.

Arquitectura seg
un Inmon

La principal diferencia con la vision de Kimball radica en que ahora el usuario ve el

comedor y algunos elementos de la cocina. La carga inicial y el refresco periodico, sin embargo,
tambien tienen lugar en esta arquitectura.

Figura 3.2: Fabrica de Informacion Corporativa seg

un Inmon
Los datos de los cubos deben estar integrados para poder hacer drill-across. Pero para
conseguir este objetivo, no se pueden realizar desarrollos independientes. Por lo tanto necesitamos desarrollar de forma integrada la cocina para todos los cubos.

3.1 Arquitectura del sistema de informaci

on: la FIC

33

Figura 3.3: Data Warehouse Corporativo

En esta nueva arquitectura, mostrada en la figura 3.3, ahora los cubos reciben tambien el
nombre de Data Warehouse Departamental Data Marts. Por otra parte, el comedor y la mitad
de la cocina se consideran areas informacionales o decisionales, mientras que el mercado y la
otra mitad de la cocina son areas transaccionales u operacionales.
Un data warehouse (almacen de datos) es una base de datos con las siguientes caractersticas:
Es historiada

Es no volatil

Esta orientada a temas

Sirve de soporte a la toma de decisiones

Esta integrada
Data
Warehouse
Historiada (Pelcula)
Orientado a temas
Integrada
No volatil
Da soporte a las decisiones

VS

Sistema transaccional
u operacional
No historiada (Fotografa)
Orientado a aplicaciones
No integrada
Volatil
Registra transacciones

El Operational Data Store (ODS) es una base de datos con las siguientes caractersticas:
Es no historiada
Esta orientada a temas
Esta integrada
Es volatil
Sirve de soporte a la toma de decisiones y para registrar transacciones operacionales.

34

Captulo 3. La F
abrica de Informaci
on Corporativa

3.2.

Construcci
on de la FIC

3.2.1.

ETL. Extracci
on, Transformaci
on y Carga

Extracci
on
Se obtienen los datos de las fuentes de datos con dos propositos principales:
1. La carga inicial, que se realiza solo una vez y en la que se toman todos los datos
existentes necesarios.
2. Las actualizaciones, que se realizan periodicamente y en las que se extraen todos aquellos
datos que hubieran sido modificados.
El problema se presenta a la hora de determinar que datos han sido modificados para las actualizaciones periodicas. Existen dos metodos para detectar estas modificaciones:
Retardados e Inmediatos1 .
Retardados. Con este tipo de metodos se pueden perder cambios si se realiza mas de
una modificacion sobre un mismo dato entre dos actualizaciones consecutivas.
Comparacion de imagenes. Se saca una copia, se modifica el original y luego se
comparan ambos para detectar los cambios. Siempre se puede realizar, pero tardara tanto mas tiempo cuanto mayor sea la base de datos.
Huella de tiempo. Se emplea un campo que indica la fecha de la u
ltima modificacion. Si ese campo ya existe, esta es una solucion factible. En otro caso, puede
resultar bastante costoso.
Inmediatos. Con este tipo de metodos no se pierden cambios.

Las aplicaciones guardan los movimientos. Esta

resulta ser una buena solucion si
las aplicaciones de la organizacion ya guardan los movimientos. En caso contrario
puede resultar una tarea bastante tediosa e incluso inviable.
Los SGBD pueden usar triggers (disparadores).
Mediante la bitacora o Log, de forma que no se pierda ning
un cambio. Pero aunque
casi todos los SGBD crean un Log, este no esta pensado para lo que aqu se
proponen y a menudo suele ser difcil de interpretar.
Si es factible usar las soluciones de huella de tiempo, aplicaciones que guardan modificaciones o triggers, es preferible. Si no se puede, se intenta la opcion del log. Y si esta tambien
falla, entonces se usa comparacion de imagenes.
Transformaci
on (Integraci
on)
Si existen datos sobre una misma entidad (empleado, alumno, profesor, etc.) en varias
aplicaciones distintas, hay que decidir cual de ellas coger.
Siempre se debe realizar una integracion tanto a nivel sintactico como semantico y almacenar dicha integracion en el Data Warehouse Corporativo. En el modelo de datos se realizan
una serie de transformaciones para poder integrar, a saber:
1. Unir todos los datos de una misma entidad
2. A
nadir llaves de tiempo (puesto que nos interesa la historia)
3. Dividir en funcion de la estabilidad de los datos (algo parecido a lo que suceda con las
dimensiones cambiantes)
1

Examen ;-)

3.2 Construcci
on de la FIC

35

Carga (Loading )
Existen dos variantes para la carga de datos:
Incremental. A
nadir solamente lo nuevo.
Cargar todo de nuevo (solo aplicable a los cubos). Se suele aplicar a los agregados.

3.2.2.

Desarrollo de ETL

Todo el proceso que acabamos de describir de ETL lo realizara un programa informatico que, o bien podremos programar nosotros mismos, o bien podemos adquirirlo como un
producto comercial existente.
Dicho programa suele estar escrito en alg
un lenguaje como por ejemplo SQL hospedado.

3.2.3.

Estructura de los proyectos de desarrollo de la FIC

El enfoque mas frecuente es pensar que construir un proyecto de la FIC consiste u

nicamente en crear los cubos; pero este enfoque es erroneo.
Otro enfoque ve toda la FIC en un solo proyecto. Este enfoque tambien es equivocado,
ya que el proyecto de construir toda la FIC puede ser extremadamente grande (faraonico).
En un enfoque razonable lo primero es tener claramente definida la arquitectura de la
FIC, para a continuacion implementar cubo por cubo seg
un sus fases de mercado, cocina y
comedor.
Sea cual sea el enfoque que se adopte, cada proyecto debe tener un beneficio justificado
(tarea no siempre facil).

3.2.4.

Nuevos perfiles para el desarrollo de proyectos FIC

Dise
nador de sistemas multidimensionales: OLAP, Data Mass o Business Intelligence.
Tecnico de sistemas del SGBD OLAP (para saber optimizar consultas, por ejemplo).
Especialista en extraccion y elicitacion de los datos, as como en el manejo de herramientas ETL.
Dise
nador de la arquitectura de la FIC.
Dise
nador del Data Warehouse Corporativo.

36

Captulo 3. La F
abrica de Informaci
on Corporativa

Bibliografa
[1] R. Andreu, J. Ricart, J. Valor, Estrategia y Sistemas de Informaci
on, McGraw-Hill,
1996
[2] W. Inmon, C. Imhoff, R. Sousa, Corporate Information Factory, John Wiley & Sons,
Inc., 1998
[3] M. Jarke, M. Lenzerini, Y. Vassiliou, P. Vassiliadis, Fundamentals of Data Warehouses,
2nd Edition, Springer-Verlag, 2003
[4] R. Kimball, The Data Warehouse Toolkit, 2nd Edition, John Wiley & Sons, Inc., 2002

37