25/3/11
1
Data WareHouse
Data WareHouse
1. Introducción a los almacenes de datos: motivación definición y características.
2. Arquitectura de un sistema de almacén de datos.
3. Explotación de un almacén de datos: herramientas OLAP.
4. Diseño de un almacén de datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un almacén de datos.
Data WareHouse
Algunos dibujos de las diapositivas han sido tomados del curso Data Warehousing Fundamentals. Oracle Education.
25/3/11
2
Data WareHouse
• Building the Data Warehouse (4ª ed.). Inmon, W.H. Wiley, 2005
• Data Warehouse Performance. Inmon, W.H. et al. Wiley, 1999
• Building the Operational Data Store (2ª ed.). Immon, W. H. Willey, 2000
• Exploration Datawarehouse. Immon, W.H. Willey, 2000.
• The Corporate Information Factory, (2ª ed.). John Wiley, 2001
• The Data Warehouse Toolkit : the complete guide to dimensional modeling. Kimball, R., et al. Wiley, 2002
• The Data Warehouse ETL Toolkit : practical techniques for extracting, cleaning, conforming, and delivering data. Kimball, R., et al. Wiley, 2004
• The Data Webhouse Toolkit : building the Web-enabled data warehouse. Kimball, et al. Wiley, 2000
Bibliografía
Data WareHouse
Direcciones de interés:
The OLAP Report : http://www.olapreport.com/
Data Warehousing and OLAP Bibliography (D. Lemire - Quebec University): http://www.ondelette.com/OLAP/dwbib.html
DBLP Computer Science Bibliography: http://dblp.uni-trier.de/
Bibliografía
25/3/11
3
Data WareHouse
Conferencias especializadas en DW: International Workshop on Data Warehousing and OLAP. DOLAP (ACM)
International Conference on Data Warehousing and Knowledege Discovery. DaWaK (DEXA).
Conferencias especializadas en BD: International Conference of Very Large Databases (VLDB)
International Conference on Data Engineering (ICDE)
Interantional Conference on Conceptual Modeling (ER)
International Conference on Extending Database Technology (EDBT).
International Conference on Database Theory (ICDT).
International Conference on Database and Expert Systems Applications (DEXA)
Bibliografía
Data WareHouse
1. Introducción a los Almacenes de Datos: motivación definición y características.
2. Arquitectura de un Sistema de Almacén de Datos (SAD).
3. Explotación de un Almacén de Datos: herramientas OLAP
4. Diseño de un Almacén de Datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un Almacén de Datos.
Data WareHouse
25/3/11
4
Data WareHouse
I+D
Tecnología de gestión de datos
Evolución de la tecnología de los
computadores
Requisitos de los usuarios
Evolución del software
Aplicación
Data WareHouse
Data WareHouse
Situación actual: uso extendido de los SGBD
BD son el soporte del Sistema de Información de las organizaciones
BD son diseñadas para dar soporte (eficiente) a las funciones básicas de la organización (ventas, producción, personal...)
SISTEMAS OPERACIONALES (OLTP On Line Transaction Processing)
las organizaciones almacenan grandes volúmenes de datos con información histórica
1970 2000 evolución de la tecnología de gestión de datos
- SGBD eficientes - SGBD robustos - lenguajes y herramientas de uso de alto nivel
Situación actual de la tecnología de gestión de datos.
Data WareHouse
25/3/11
5
Data WareHouse
Una vez satisfecha la necesidad de tener un soporte informático para los procesos básicos de la organización (sistemas de información para la gestión).
La organizaciones exigen nuevas prestaciones de los sistemas de información (sistemas de información para la toma de decisiones).
Data WareHouse
Data WareHouse
Almacenes de datos (AD) (Data WareHouse DW)
disponer de Sistemas de Información de apoyo a la
toma de decisiones*
disponer de bases de datos que permitan extraer conocimiento de la información histórica almacenada en la organización
motivación
análisis de la organización
previsiones de evolución
diseño de estrategias
objetivos
* DSS: Decision Support Systems
Data WareHouse
25/3/11
6
Data WareHouse
Tecnología de almacenes de datos
Evolución de la tecnología de los
computadores
Requisitos de los usuarios
Evolución del software
Aplicación
Data WareHouse
Data WareHouse
Avances tecnológicos que han favorecido el desarrollo de la tecnología de almacenes de datos
– Paralelismo • Hardware • Sistemas Operativos • Bases de Datos • Consultas • Índices ─ VLD (bases de datos muy grandes)
─ Arquitecturas de 64 bit ─ Técnicas de indexación
─ Sistemas abiertos
─ Herramientas y sistemas para DW ─ Herramientas de análisis de usuario final
VLDB
Data WareHouse
25/3/11
7
Data WareHouse
“Colección de datos diseñada para dar apoyo a los procesos de toma de decisiones.”
Data WareHouse
Data WareHouse
Almacén de datos
Base de Datos diseñada con un objetivo de explotación distinto que el de las bases de datos de los sistemas operacionales.
Sistema Operacional
(OLTP)
Sistema de Almacén de Datos
(DW)
BD orientada al proceso
BD orientada al análisis
Data WareHouse
25/3/11
8
Data WareHouse
Almacén de datos
colección de datos diseñada para dar apoyo a los procesos
de toma de decisiones
orientada hacia la información* relevante de la organización
integrada variable en el tiempo
no volátil
características
* subject oriented, not process oriented
Data WareHouse
Data WareHouse
Orientada hacia la información relevante de la organización
se diseña para consultar eficientemente información relativa a las actividades (ventas, compras, producción, ...) básicas de la organización, no para soportar los procesos que se realizan en ella (gestión de pedidos, facturación, etc).
Data WareHouse Data WareHouse
25/3/11
9
Data WareHouse
Entorno Operacional
Aplicación Cuentas de
Ahorro
Aplicación Cuentas
Corrientes
Aplicación Préstamos
Integrada integra datos recogidos de diferentes sistemas operacionales de la organización (y/o fuentes externas).
Data WareHouse
Data WareHouse
Los datos son almacenados como fotos (snapshots) correspondientes a periodos de tiempo.
Datos Tiempo
01/97
02/97
03/97
Datos de Enero
Datos de Febrero
Datos de Marzo
Data Warehouse
Variable en el tiempo
los datos son relativos a un periodo de tiempo y deben ser incrementados periódicamente.
Nota: El periodo de tiempo cubierto por un DW varia entre 2 y 10 años.
Data WareHouse
25/3/11
10
Data WareHouse
SELECT
Carga
INSERT SELECT
UPDATE
DELETE
Bases de datos operacionales Warehouse
No volátil los datos almacenados no son actualizados, sólo son incrementados.
Data WareHouse
Data WareHouse
El objetivo último de un almacén de datos es integrar datos corporativos, residentes en bases de datos operacionales de la organización, en un único repositorio sobre el cual los usuarios puedan realizar consultas o informes y hacer análisis de datos.
La tecnología de almacenes de datos integra las técnicas de bases de datos y las técnicas de análisis de datos.
Data WareHouse
25/3/11
11
Data WareHouse
Almacenes de datos ventajas para las organizaciones
rentabilidad de las inversiones realizadas para
su creación
aumento de la competitividad en el mercado
aumento de la productividad de los técnicos de
dirección
Data WareHouse
Data WareHouse
Almacenes de datos problemas
infravaloración de los recursos necesarios
para la captura, carga y almacenamiento de
los datos
incremento continuo de los requisitos de los
usuarios
privacidad de los datos
infravaloración del esfuerzo necesario para su diseño y
creación
Data WareHouse
25/3/11
12
Data WareHouse
Sistema Operacional (OLTP) Almacén de datos (DW)
- almacena datos actuales - almacena datos históricos
- almacena datos de detalle - almacena datos de detalle y datos agregados a distintos niveles
- bases de datos medianas - bases de datos grandes - los datos son dinámicos (actualizables) - los datos son estáticos
- los procesos (transacciones) son repetitivos - los procesos no son previsibles
- el número de transacciones es elevado - el número de transacciones es bajo o medio
- tiempo de respuesta pequeño (segundos) - tiempo de respuesta variable (segundos-horas)
- dedicado al procesamiento de transacciones - dedicado al análisis de datos
- orientado a los procesos de la organización - orientado a la información relevante
- soporta decisiones diarias - soporta decisiones estratégicas
- sirve a muchos usuarios (administrativos) - sirve a técnicos de dirección
Data WareHouse
Data WareHouse
1. Introducción a los Almacenes de Datos: motivación definición y características.
2. Arquitectura de un Sistema de Almacén de Datos (SAD).
3. Explotación de un Almacén de Datos: herramientas OLAP.
4. Diseño de un Almacén de Datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un Almacén de Datos.
Data WareHouse
25/3/11
13
Data WareHouse
2. Arquitectura de un SAD
Datos Op. 1
Datos Op. 2
Datos Op. 3
metadatos
datos de detalle
datos agregados
datos agregados
AD
gestor de carga
gestor del AD
gestor del AD
gestor de consultas
copias
herramientas de consultas e informes
herramientas de OLAP
herramientas de Data Mining
SAD
área de almacenamiento
intermedio
herramientas de EIS
Data WareHouse
Componentes: • datos operacionales: el origen de los datos puede ser: bases de datos operacionales de la organización, bases de datos privadas, bases de datos públicas, etc.
• gestor de carga: permite realizar las funciones de extracción de datos de las fuentes externas, transformación (limpieza, consolidación, ...) y la carga del AD, utiliza un almacenamiento intermedio y realiza las siguientes operaciones:
extracción de los datos.
transformación de los datos: limpieza, estandarización, etc.
carga inicial del almacén: ordenación, agregaciones, etc.
refresco del almacén: operación periódica que propaga los cambios de las fuentes operacionales al almacén de datos
(herramientas* del fabricante o programas de la organización).
• ETT (extracción, transformación y transporte)
• ETL (extracción, transformación y carga (load))
2. Arquitectura de un SAD
25/3/11
14
Data WareHouse
Componentes...
• metadatos: documentación sobre los datos (origen, descripción, nivel de agregación, almacenamiento, etc).
• herramientas de consulta: herramientas para diseñar consultas e informes, herramientas de desarrollo de aplicaciones de usuario final, herramientas de análisis de datos (OLAP), herramientas de minería de datos (DATA MINING), herramientas dirigidas a ejecutivos (EIS). (herramientas de diferentes fabricantes).
• gestor (servidor) del AD: permite realizar todas las funciones de definición y mantenimiento del almacén de datos: definición, agregación de datos, vistas, creación de índices, copias, etc. (herramienta del fabricante).
• gestor de consultas: ejecución de consultas. (herramienta del fabricante).
2. Arquitectura de un SAD
Data WareHouse
tecnología multidimensional (sistemas MOLAP): sistemas de gestión de bases de datos construidos específicamente para el análisis de datos (estructuras de almacenamiento, optimizadores de consultas, etc.). (Express de ORACLE)
tecnología relacional (sistemas ROLAP): SGBD relacionales con ciertas extensiones. Sobre estos sistemas relacionales se acoplan herramientas de OLAP.
MicroStrategy: herramienta OLAP que trabaja sobre ACCESS, ORACLE, SQL Server, ...
Discoverer: herramienta OLAP de ORACLE.
El servidor (gestor del almacén de datos) puede estar construido usando:
2. Arquitectura de un SAD
25/3/11
15
Data WareHouse
Data Mart
se definen para satisfacer las necesidades de un departamento o sección de la organización.
contiene menos información de detalle y mas información agregada.
En la construcción de un Data Mart se siguen dos aproximaciones:
definir previamente el almacén de datos de la organización y posteriormente definir sobre él los data marts.
definir previamente los data marts de departamentos y posteriormente integrarlos en un almacén de datos para la organización
subconjunto de un almacén de datos
2. Arquitectura de un SAD
Data WareHouse
1. Introducción a los Almacenes de Datos: motivación definición y características.
2. Arquitectura de un Sistema de Almacén de Datos (SAD).
3. Explotación de un Almacén de Datos: herramientas OLAP.
4. Diseño de un Almacén de Datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un Almacén de Datos.
Almacenes de Datos
(Data Warehouse)
25/3/11
16
Data WareHouse
Las herramientas (OLAP) de explotación de los almacenes de datos han adoptado un modelo multidimensional de datos.
Se ofrece al usuario una visión multidimensional de los datos que son objeto de análisis.
Herramientas de OLAP: Discoverer, Micro Strategy, ...
3. Explotación de un Almacén de Datos: Herramientas OLAP
Data WareHouse
EJEMPLO Organización: Cadena de supermercados.
Actividad objeto de análisis: ventas de productos.
Información registrada sobre las ventas: "ventas diarias de productos en los supermercados de la cadena“.
Ejemplo: "del producto “Coca-Cola 33cl” se han vendido en el almacén “Almacén nro.1” el día 12/01/1999, 50 unidades por un importe de 70€.”
Para hacer el análisis de ventas no interesa la venta individual (ticket) realizada a un cliente sino las ventas diarias de productos en los distintos almacenes de la cadena.
3. Explotación de un Almacén de Datos: Herramientas OLAP
25/3/11
17
Data WareHouse
importe
unidades
Dimensiones que caracterizan la actividad.
Producto Tiempo (día)
Almacén
Actividad que es objeto de análisis con los indicadores que interesa analizar
3. Explotación de un Almacén de Datos: Herramientas OLAP
Data WareHouse
importe
unidades
La actividad de ventas se registra a nivel diario para cada producto y cada almacén
Producto Tiempo (día)
Almacén
3. Explotación de un almacén de datos: herramientas OLAP
Actividad que es objeto de análisis con los indicadores que interesa analizar
25/3/11
18
Data WareHouse
importe
unidades
Tiempo (día)
Almacén
Producto
“Importe total de ventas por almacén y producto”
OLAP
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
Agua Jabón Vino Leche
Almacén2
Almacén1
Almacén
Producto
2000000 1000000 3000000 2000000
1000000 1500000 8000000 2400000
Tabla multidimensional
OLAP
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
19
Data WareHouse
Presentaciones del esquema multidimensional en una herramienta OLAP:
- representación en estrella
- representación en cubo de datos
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
importe
unidades
Dimensiones que caracterizan la actividad.
Producto Tiempo (día)
Almacén
3. Explotación de un almacén de datos: herramientas OLAP
Modelo en estrella:
- actividad (centro)
- dimensiones (puntas) Actividad que es objeto de análisis con los indicadores que interesa analizar
25/3/11
20
Data WareHouse
Almacén
Producto
Tiempo
Ventas
Almacén
Producto
Tiempo
Cliente
4 dimensiones
3 dimensiones
Modelo en cubo de datos:
- actividad (celda)
- dimensiones (ejes)
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
importe
unidades
Para enriquecer el análisis las dimensiones se completan con atributos descriptores.
Producto Tiempo (día)
Almacén
OLAP
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
21
Data WareHouse
importe
unidades
Departamento Nro_producto
Categoría
Marca
Tipo Día
Mes
Día de la semana
Nombre
Ciudad
Región
Tipo
Año
Descripción
Actividad que es objeto de análisis con los indicadores que interesa analizar
Dimensiones con atributos descriptores.
Pro
duct
o
Tiem
po
Alm
acén
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nro_almacén
Data WareHouse
Modelo multidimensional: en un esquema multidimensional se representa una actividad que es objeto de análisis (hecho) y las dimensiones que caracterizan la actividad (dimensiones).
la información relevante sobre el hecho se representa por un conjunto de indicadores (medidas o atributos de hecho).
la información descriptiva de cada dimensión se representa por un conjunto de atributos (atributos de dimensión).
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
22
Data WareHouse
importe
unidades
Alm
acén
Nombre
Ciudad
Región
Tipo
Pro
duct
o
Departamento Nro_producto
Categoría
Marca
Tipo
Descripción
hecho
medidas
Tiem
po
Día Mes
Día de la semana
Año Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nro_almacén dimensión
atributos
Data WareHouse
importe
unidades
Alm
acén
Nro_almacén
Ciudad
Región
Tipo
Pro
duct
o
Departamento Nro_producto
Categoría
Marca
Tipo
Descripción
Entre los atributos de una dimensión existe uno que hace la función de identificador
Tiem
po
Día Mes
Día de la semana
Año Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
25/3/11
23
Data WareHouse
importe
unidades
Alm
acén
Nro_almacén
Ciudad
Región
Tipo
Pro
duct
o
Departamento Nro_producto
Categoría
Marca
Tipo
Descripción
Entre los atributos de una dimensión existe uno que hace la función de identificador
Tiem
po
Día Mes
Día de la semana
Año Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Los valores (instancias) de la dimensión Producto son productos ofertados por la cadena
Los valores (instancias) de la dimensión Tiempo son días del calendario
Los valores (instancias) de la dimensión Almacén son almacenes de la cadena
Nombre
Data WareHouse
Entre los atributos de una dimensión existen jerarquías*
departamento
nro_almacén ciudad región
nro_almacén tipo
día mes año
Producto
Almacén
Tiempo
nro. producto categoría
trimestre
3. Explotación de un almacén de datos: herramientas OLAP
departamento
nro. producto tipo
* Jerarquías basadas generalmente en dependencias funcionales entre los atributos de la dimensión.
25/3/11
24
Data WareHouse
importe
unidades
Alm
acén
Nro_almacén
Ciudad
Región Tipo
Pro
duct
o
Departamento
Nro_producto
Categoría
Marca
Tipo
Descripción
Tiem
po
Día Mes
Día de la semana
Año
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
Data WareHouse
Los atributos de las dimensiones van a servir para:
expresar condiciones que restringen el subconjunto de datos del AD que se desea consultar
definir los parámetros de la consulta: nivel de detalle (o agregación) al que se desean presentar los datos seleccionados
añadir información descriptiva a los elementos de la dimensión
las jerarquías definidas entre los atributos de las dimensiones son una guía para "navegar" por los datos seleccionados, cambiando el nivel de agregación con el que son presentados
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
25
Data WareHouse
importe
unidades
Alm
acén
Nro_almacén
Ciudad
Región Tipo
Pro
duct
o
Departamento
Nro_producto
Categoría
Marca
Tipo
Descripción
Tiem
po
Día Mes
Día de la semana
Año
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
Importe total de ventas por almacén, para almacenes de tipo "gran superficie", indicando el nombre completo del almacén.
atributo de selección
atributo descriptivo
atributo de agrupación
Data WareHouse
Consulta de un AD con una herramienta OLAP
Las herramientas de OLAP presentan al usuario un visión multidimensional de los datos (esquema multidimensional) para cada actividad que es objeto de análisis.
El usuario formula consultas a la herramienta OLAP seleccionando atributos de este esquema multidimensional sin conocer la estructura interna (esquema de base de datos) del almacén de datos.
La herramienta OLAP genera la correspondiente consulta y la envía al gestor de consultas del sistema (sentencia SELECT en un sistema ROLAP).
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
26
Data WareHouse
Pro
duct
o
Tiem
po
Alm
acén
importe
unidades
Departamento Nro_producto
Categoría
Marca
Tipo Día
Mes
Día de la semana
Nro_almacén
Ciudad
Región
Tipo
Año
“Importe total de ventas por año, región y departamento”
OLAP
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
Data WareHouse
info
rme
Importe de ventas
SELECT ...........
departamento región año importe
OLAP
año
región departamento
3. Explotación de un almacén de datos: herramientas OLAP
ROLAP
25/3/11
27
Data WareHouse
fecha
nro_producto
nro_almacén
importe
unidades
Ventas
nro_almacén
nombre
dirección
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
nro_producto
descripción
marca
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén
Producto
fecha
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
“Una consulta a un almacén de datos consiste generalmente en la obtención de medidas sobre los hechos parametrizados
por atributos de las dimensiones y restringidos por condiciones impuestas sobre las dimensiones”
¿Importe total de las ventas durante este año de los productos del departamento Bebidas, por trimestre y por categoría?.
Restricciones: productos del departamento Bebidas, ventas durante este año
medida hecho
Parámetros de la consulta: por categoría de producto y por trimestre
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
28
Data WareHouse
“2002”
“Bebidas” P
rodu
cto
Tiem
po
Alm
acén
importe
unidades
Departamento Nro_producto
Categoría
Marca
Tipo Día
Mes
Día de la semana
Nro_almacén
Ciudad
Región
Tipo
Año
“Importe total de ventas en este año, del departamento
de “Bebidas”, por categoría y trimestre”
OLAP
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
Data WareHouse
SELECT ...........
trimestre categoría importe
OLAP
3. Explotación de un almacén de datos: herramientas OLAP
ROLAP
25/3/11
29
Data WareHouse
fecha
nro_producto
nro_almacén
importe
unidades
Ventas
nro_almacén
nombre
dirección
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
nro_producto
descripción
marca
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén
Producto
fecha
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo 3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
SELECT P.categoría, T.trimestre, SUM (V.importe)
FROM Ventas V, Tiempo T, Producto P
WHERE V.nro_producto = P.nro_producto AND
V.fecha = T.fecha AND
P.departamento= ‘ Bebidas’ AND
T.año= year (TODAY)
GROUP BY T.trimestre, P.categoría
medida
selección de datos de la tabla de hechos restringidos por condiciones sobre las tablas de dimensión
agregación sobre Almacén
agrupación por Tiempo y Producto
tabla de hechos
3. Explotación de un almacén de datos: herramientas OLAP
parámetros
25/3/11
30
Data WareHouse
SELECT D1.C1, ..., Dn.Cn, Agg1(F.A1),..., Aggn(F.An)
FROM Hechos F, Dimensión1 D1,...Dimensión Dn
WHERE
JOIN_cond (F,D1) AND
...
JOIN_cond (F,Dn) AND
condición_selección
GROUP BY D1.C1,..., Dn.Cn
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
Presentación tabular (relacional) de los datos seleccionados
Categoría Trimestre Ventas
T4
T2
T3
T1
T3
2000000
3000000
1500000
2400000
8000000
T1 1000000
T4
T2 1000000
Refrescos
Refrescos
Refrescos
Refrescos
Zumos
Zumos
Zumos
Zumos
2000000
Se asumen dos categorías en el departamento de Bebidas: Refrescos y Zumos.
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
31
Data WareHouse
T4 T3 T2 T1
Zumos
Refrescos
Categoría
Trimestre Presentación matricial (multidimensional) de los datos seleccionados
Los parámetros de la consulta (“por trimestre” y “por categoría”) determinan los criterios de agrupación de los datos seleccionados ("ventas de productos del año actual", "del departamento de Bebidas"). La agrupación se realiza sobre dos atributos de dos dimensiones: Producto (categoría), Tiempo (trimestre).
2000000 1000000 3000000 2000000
1000000 1500000 8000000 2400000
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
El carácter agregado de las consultas en el análisis de datos, aconseja la definición de nuevos operadores que faciliten la agregación (consolidación) y la disgregación (división) de los datos:
Agregación (roll): permite sustituir (eliminándolo o utilizando uno de mayor granularidad) un criterio de agrupación utilizado en el análisis. Se agregan los grupos de la consulta actual.
Disgregación (drill): permite sustituir (añadiendo uno nuevo o utilizando uno de menor granularidad) un criterio de agrupación utilizado en el análisis. Se disgregan los grupos de la consulta actual.
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
32
Data WareHouse
Las operaciones de agregación (ROLL) y disgregación (DRILL) se pueden hacer sobre:
atributos de una dimensión sobre los que se ha definido una jerarquía: DRILL-DOWN, ROLL-UP
departamento – categoría - producto (Producto)
año - trimestre – mes - día (Tiempo)
sobre dimensiones independientes: DRILL-ACROSS, ROLL-ACROSS
Producto – Almacén -Tiempo
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
“2002”
“Bebidas”
Pro
duct
o
Tiem
po
Alm
acén
importe
unidades
Departamento Nro_producto
Categoría
Marca
Tipo Día
Mes
Día de la semana
Nro_almacén
Ciudad
Región
Tipo
Año
“Importe total de ventas en este año, del departamento de
“Bebidas”, por categoría y mes”
OLAP
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
25/3/11
33
Data WareHouse
trimestre categoría importe
OLAP
¡ la operación de DRILL se realiza sobre el informe original !
3. Explotación de un almacén de datos: herramientas OLAP
día
mes
año
trimestre
RO
LL-U
P
DR
ILL-
DO
WN
Data WareHouse
Categoría Ventas Mes
500000
Refrescos
Enero
drill
-dow
n
Categoría Trimestre Ventas
T4
T2
T3
T1
T3
2000000
3000000
1500000
2400000
8000000
T1 1000000
T4
T2 1000000
Refrescos
Refrescos
Refrescos
Refrescos
Zumos
Zumos
Zumos
Zumos
2000000
Febrero
Refrescos
Refrescos Marzo
1000000
500000
Cada fila (categoría-trimestre) de la consulta original se disgrega en tres nuevas filas (categoría-mes).
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
34
Data WareHouse
drill-down
SELECT P.categoría, T.mes, SUM (V.importe)
FROM Ventas V, Tiempo T, Producto P
WHERE V.nro_producto = P.nro_producto AND
V.fecha = T.fecha AND
P.departamento= ‘ Bebidas’ AND
T.año= year (TODAY)
GROUP BY T.mes, P.categoría
medida
selección de datos de la tabla de hechos restringidos por condiciones sobre las tablas de dimensión
agrupación por Tiempo y Producto
tabla de hechos
3. Explotación de un almacén de datos: herramientas OLAP
Sustitución de nivel en la jerarquía de la dimensión Tiempo por un nivel de granularidad más fina
Data WareHouse
Si se desea introducir la dimensión Almacén en el análisis anterior e incluir un nuevo criterio de agrupación sobre la ciudad del almacén:
¿Importe total de las ventas durante este año de los productos del departamento Bebidas, por trimestre, por categorías y por ciudad del almacén?.
Restricciones: productos del departamento Bebidas, ventas durante este año Parámetros de la consulta: por categoría de producto, por trimestre y por ciudad del almacén.
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
35
Data WareHouse
“2002”
“Bebidas” P
rodu
cto
Tiem
po
Alm
acén
importe
unidades
Departamento Nro_producto
Categoría
Marca
Tipo Día
Mes
Día de la semana
Nro_almacén
Ciudad
Región
Tipo
Año
“Importe total de ventas en este año, del departamento de “Bebidas”, por categoría,
trimestre y ciudad”
OLAP
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
Data WareHouse
trimestre categoría importe
OLAP
¡ la operación de DRILL se realiza sobre el informe original !
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
36
Data WareHouse
Categoría Trimestre Ventas Ciudad
T2
T1
300000
T2 700000
Refrescos T1
Valencia
drill
-acr
oss
Categoría Trimestre Ventas
T4
T2
T3
T1
T3
2000000
3000000
1500000
2400000
8000000
T1 1000000
T4
T2 1000000
Refrescos
Refrescos
Refrescos
Refrescos
Zumos
Zumos
Zumos
Zumos
2000000
León
Refrescos
Refrescos
Refrescos
Valencia
León
1000000
1000000
* Se asumen dos ciudades: Valencia y León.
Cada fila (categoría-trimestre) de la consulta original se disgrega en dos nuevas filas (categoría-trimestre-ciudad) para las ciudades de León y Valencia.
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
drill-across
SELECT P.categoría, T.trimestre, A.ciudad, SUM (V.importe)
FROM Ventas V, Tiempo T, Producto P, Almacén A
WHERE V.nro_producto = P.nro_producto AND
V.fecha = T.fecha AND
V.nro_almacén=A.nro_almacén AND
P.departamento= ‘ Bebidas’ AND
T.año= year (TODAY)
GROUP BY T.trimestre, P.categoría, A.ciudad
medida
selección de datos de la tabla de hechos restringidos por condiciones sobre las tablas de dimensión
agrupación por Tiempo, Producto y Almacén
tabla de hechos
3. Explotación de un almacén de datos: herramientas OLAP
Inclusión de una nueva dimensión en los criterios de agrupación
25/3/11
37
Data WareHouse
T1 T2 T3 T4
Zum
os
Ref
resc
os
1000000
300000
300000
500000
100000
200000
500000
2000000
Presentación matricial de los datos seleccionados.
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
Si se desea eliminar el criterio de agrupación sobre la dimensión Tiempo en la consulta original:
¿Importe total de las ventas durante este año de los productos del departamento Bebidas, por categorías?.
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
38
Data WareHouse
“2002”
“Bebidas” P
rodu
cto
Tiem
po
Alm
acén
importe
unidades
Departamento Nro_producto
Categoría
Marca
Tipo Día
Mes
Día de la semana
Nro_almacén
Ciudad
Región
Tipo
Año
“Importe total de ventas en este año, del departamento
de “Bebidas”, por categorías”
OLAP
Trimestre
3. Explotación de un almacén de datos: herramientas OLAP
Nombre
Data WareHouse
OLAP
trimestre categoría importe
¡ la operación de ROLL se realiza sobre el informe original !
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
39
Data WareHouse
Categoría Ventas
Refrescos 8000000
Zumos 12900000
roll-
acro
ss
Categoría Trimestre Ventas
T4
T2
T3
T1
T3
2000000
3000000
1500000
2400000
8000000
T1 1000000
T4
T2 1000000
Refrescos
Refrescos
Refrescos
Refrescos
Zumos
Zumos
Zumos
Zumos
2000000
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
SELECT P.categoría, T.trimestre, SUM (V.importe)
FROM Ventas V, Tiempo T, Producto P
WHERE V.nro_producto = P.nro_producto AND
V.fecha = T.fecha AND
P.departamento= ‘ Bebidas’ AND
T.año= year (TODAY)
GROUP BY T.trimestre, P.categoría
medida
selección de datos de la tabla de hechos restringidos por condiciones sobre las tablas de dimensión
agregación sobre Almacén y Tiempo
agrupación por Producto
tabla de hechos
roll-across
3. Explotación de un almacén de datos: herramientas OLAP
Eliminación de una dimensión en los criterios de agrupación
25/3/11
40
Data WareHouse
Otras operaciones de OLAP: SLICE: elimina una dimensión de la consulta actual, fijando un valor para ella.
DICE: selecciona un subconjunto de datos de la consulta actual.
PIVOT: reorientación de las dimensiones en la consulta actual.
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
Ventas
Electrónica Juguetes Ropa Cosméticos
Q1
5,2 1,9 2,3 1,1
Electónica Juguetes Ropa Cosméticos
Q2
8,9 0,75 4,6 1,5
Productos Tienda1 Tienda2
5,6 1,4 2,6 1,1 7,2 0,4 4,6 0,5
Ventas
Electrónica Juguetes Ropa Cosméticos Ti
enda
1 5,2 1,9 2,3 1,1
Electrónica Juguetes Ropa Cosméticos Ti
enda
2 5,6 1,4 2,6 1,1
Productos Q1 Q2
8,9 0,75 4,6 1,5 7,2 0,4 4,6 0,5
PIVOT
3. Explotación de un almacén de datos: herramientas OLAP
25/3/11
41
Data WareHouse
Ventas
Electrónica Juguetes Ropa Cosméticos
Q1
5,2 1,9 2,3 1,1
Electrónica Juguetes Ropa Cosméticos
Q2
8,9 0,75 4,6 1,5
Productos Tienda1 Tienda2
5,6 1,4 2,6 1,1 7,2 0,4 4,6 0,5
Ventas
Electrónica Juguetes Q
1 5,2 1,9
Productos Tienda1
Electrónica Juguetes Q
2 8,9 0,75
DICE
3. Explotación de un almacén de datos: herramientas OLAP
Tienda3
6,1 4,2 2,6 1,8 6,2 0,5 3,6 0,7
Tienda2
5,6 1,4
7,2 0,4
Data WareHouse
Ventas
Electrónica Juguetes Ropa Cosméticos
Q1
5,2 1,9 2,3 1,1
Electrónica Juguetes Ropa Cosméticos
Q2
8,9 0,75 4,6 1,5
Productos Tienda1 Tienda2
5,6 1,4 2,6 1,1 7,2 0,4 4,6 0,5
Ventas
5,2 Q1 5,6
Tienda1 Tienda2
8,9 Q2 7,2
SLICE
3. Explotación de un almacén de datos: herramientas OLAP
Productos = 'Electrónica'
25/3/11
42
Data WareHouse
Las herramientas de OLAP se caracterizan* por:
ofrecer una visión multidimensional de los datos.
no imponer restricciones sobre el número de dimensiones.
ofrecer simetría para las dimensiones.
permitir definir jerarquías sobre las dimensiones
ofrecer operadores de manipulación: drill-down, roll-up.
permitir expresar condiciones sobre las dimensiones y criterios de agrupación de los datos.
ser transparentes al tipo de tecnología que soporta el almacén de datos (ROLAP o MOLAP).
*Subconjunto de las 12 reglas propuestas por E.F. Codd.
3. Explotación de un almacén de datos: herramientas OLAP
Data WareHouse
1. Introducción a los almacenes de datos: motivación definición y características.
2. Arquitectura de un sistema de almacén de datos.
3. Explotación de un almacén de datos: herramientas OLAP.
4. Diseño de un almacén de datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un almacén de datos.
Almacenes de datos (Data Warehouse)
25/3/11
43
Data WareHouse
4. Diseño de un almacén de datos
La visión multidimensional seguida por las herramientas de explotación de almacenes de datos (OLAP) ha inspirado los modelos y metodologías de diseño de este tipo de sistemas.
En la literatura se habla de “Bases de Datos Multidimensionales” y de “Diseño
Multidimensional”
Data WareHouse
Modelado multidimensional: en un esquema multidimensional se representa una actividad que es objeto de análisis (hecho) y las dimensiones que caracterizan la actividad (dimensiones).
la información relevante sobre el hecho se representa por un conjunto de indicadores (medidas o atributos de hecho).
la información descriptiva de cada dimensión se representa por un conjunto de atributos (atributos de dimensión).
4. Diseño de un almacén de datos
25/3/11
44
Data WareHouse
Modelado multidimensional: el modelado multidimensional se puede aplicar utilizando distintos modelos de datos (conceptuales o lógicos).
la representación gráfica del esquema multidimensional dependerá del modelo de datos utilizado (relacional, ER, UML, OO, ...)
4. Diseño de un almacén de datos
Data WareHouse
Metodología de diseño de almacenes de datos: Cualquier metodología de diseño de almacenes de datos debe seguir las fases clásicas del diseño de bases de datos:
Análisis
Diseño
Implementación
4. Diseño de un almacén de datos
25/3/11
45
Data WareHouse
Diseño conceptual
Especificación de transacciones
Esquema conceptual
Universo de discurso
Recogida y análisis de requisitos
Requisitos de proceso Requisitos de información
Estática Dinámica
Metodología de diseño de bases de datos:
4. Diseño de un almacén de datos
Data WareHouse
Diseño físico
Esquema interno
Diseño lógico
Esquema lógico
Esp
ecífi
co p
ara
ca
da S
GB
D
SGBD disponible
Especificación de transacciones
Implementación de transacciones
Implementación
Creación BD
Especificación de transacciones
Esquema conceptual
Inde
pend
ient
e
del S
GB
D
Dinámica Estática Diseño conceptual
4. Diseño de un almacén de datos
25/3/11
46
Data WareHouse
Diseño físico Esquema interno
Diseño lógico
Esquema lógico (ROLAP, MOLAP)
Implementación Creación del AD
Esquema conceptual multidimensional
Diseño conceptual
Recogida y análisis de requisitos
Requisitos de consulta
Metodología de diseño de almacenes de datos:
Mod
elad
o m
ultid
imen
sion
al
ER, UML, ...
4. Diseño de un almacén de datos
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos Análisis
Descripción del sistema de información de la organización (OLTP)
Requisitos de usuarios del AD
Esquema conceptual
Entidad-Relación
UML
…
4. Diseño de un almacén de datos
25/3/11
47
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos
Diseño conceptual
Modelado multidimensional
Esquemas multidimensionales
(ER, UML, ..)
4. Diseño de un almacén de datos
Data WareHouse
Modelado multidimensional: Estilo de modelado que se centra en la representación de la actividad objeto de interés (hecho) y en las dimensiones que la caracterizan (dimensiones).
Los modelos conceptuales clásicos (ER, UML,...) pueden usarse* con este enfoque o estilo multidimensional. * Existen muchas propuestas de extensión de estos modelos para adaptarse mejor a la filosofía multidimensional.
4. Diseño de un almacén de datos
25/3/11
48
Data WareHouse
Modelado multidimensional con ER.
4. Diseño de un almacén de datos
Producto
N
Ventas
1
N
Tiempo
1
unidades
Almacén
N
1
importe
Data WareHouse
Modelado multidimensional con ER.
4. Diseño de un almacén de datos
N
Ventas N
unidades
N importe
día 1
mes
trimestre
año
Tiempo
producto
categoría
departamento
1
Producto
ciudad
almacén 1
región Almacén
25/3/11
49
Data WareHouse
Modelado multidimensional con UML. 4. Diseño de un almacén de datos
Producto
Ventas
importe unidades
Tiempo
1
Almacén
*
1
1
*
*
1 ≡ 1..1
* ≡ 0..*
Data WareHouse
Modelado multidimensional con UML.
4. Diseño de un almacén de datos
Ventas
importe unidades
*
*
*
día
1
mes
trimestre
año
Tiempo
1 producto
categoría
departamento
1 Producto
1
ciudad
almacén 1
región Almacén
25/3/11
50
Data WareHouse
Esquema multidimensional en UML.
4. Diseño de un almacén de datos
Hecho
medida1 medida2
...
* *
*
1 1
1
D1 D2
D3 Dn
* 1
Data WareHouse
Esquema multidimensional en UML.
4. Diseño de un almacén de datos
Hecho
medida1 medida2
...
* *
*
1 1
1..*
D1 D2
D3 Dn
* 1
Algunos modelos multidimensionales aceptan
relaciones M:M entre el Hecho y algunas dimensiones.
25/3/11
51
Data WareHouse Estructura de las dimensiones.
Ventas
importe unidades
*
*
* 1
Almacén
1
D
1
D
almacén
nro_almacén
nombre
M2
tipo
ciudad
nombre
habitantes
región
nombre
habitantes
país
nombre
zona_ventas
nro_zona
nombre
1..1
1..1
1..1
1..1
1..*
1..*
1..*
1..*
4. Diseño de un almacén de datos
Data WareHouse
jerarquía 1 Estructura de las dimensiones.
Nivel0
id_nivel
Atr1
Atr2
...
Nivel11
id_nivel
...
....
id_nivel
...
Nivel1n
id_nivel
...
Nivel21
id_nivel
... ....
id_nivel
...
atributos de nivel
Una dimensión es un grafo dirigido, acíclico con un nivel raíz (Nivel0).
Una jerarquía es un camino en el grafo que parte del nivel raíz.
jerarquía 2
Nivel raíz (atributo identificador
de la dimensión)
25/3/11
52
Data WareHouse
Niveli id_nivel
Atr1
Atr2
...
Nivel de dimensión
atributos de nivel
En un nivel de dimensión:
atributos analíticos: sirven para establecer condiciones y criterios de agregación
• atributo identificador: jerarquías de agregación
• atributos de selección: definición de condiciones
atributos descriptivos: completar los informes
Almacén
nro_almacén
tipo
nombre
M2
...
Nivel de dimensión
atributo de agregación
atributo de selección
atributo descriptivo
4. Diseño de un almacén de datos
Data WareHouse
tipo=‘gran superficie’ Importe total de ventas por almacén, para almacenes de tipo "gran superficie", indicando el nombre completo del almacén.
Almacén
nro_almacén
tipo
nombre
...
Nivel de dimensión
atributo de agregación
atributo de selección
atributo descriptivo
4. Diseño de un almacén de datos
Ventas
importe unidades
1..1
0..*
SELECT nro_almacén, nombre, SUM (importe)
FROM Ventas V, Almacén A
WHERE V.nro_almacén=A.nro_almacén AND tipo=‘gran superficie’
GROUP BY nro_almacén
nro_almacén
tipo
nombre
... nro_almacén .....
importe unidades
Almacén
Ventas
Esquema Relacional
Esquema UML
25/3/11
53
Data WareHouse
Atributos analíticos: - evitar codificaciones
- dominios discretos
- utilizar rangos de valores en lugar de valores absolutos
Atributos descriptivos: sirven para completar los informes con información textual:
- de cualquier tipo
(descripción completa de un producto, nombre de un almacén, dirección de un almacén...)
4. Diseño de un almacén de datos
Data WareHouse
Estructura de las dimensiones.
Nivel0
id_nivel
Atr1
Atr2
...
Niveli id_nivel
...
Niveli+1
id_nivel
...
Nivel1n
id_nivel
...
Nivel21
id_nivel
... ....
id_nivel
...
Nivel raíz
atributos de nivel
Los arcos de una jerarquía representan asociaciones
binarias de cualquier multiplicidad
Nota: Las jerarquías en una dimensión (grafo dirigido) se representan por la numeración de los niveles
25/3/11
54
Data WareHouse
Estructura de las dimensiones.
Nivel0
id_nivel
Atr1
Atr2
...
Niveli id_nivel
...
Niveli+1
id_nivel
...
Nivel1n
id_nivel
...
Nivel22
id_nivel
... ....
id_nivel
...
Nivel raíz
atributos de nivel
1..1
1..* multiplicidad mas frecuente: relación jerárquica
Data WareHouse
Estructura de las dimensiones.
Niveli id_nivel
...
Niveli+1
id_nivel
... 1..
completa
Niveli id_nivel
...
Niveli+1
id_nivel
... ..1
estricta
Niveli id_nivel
...
Niveli+1
id_nivel
... 1..
balanceada
25/3/11
55
Data WareHouse
Estructura de las dimensiones.
Niveli id_nivel
...
Niveli+1
id_nivel
... 0..
no-completa
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bisutería
Bebidas
Papel
Data WareHouse
Estructura de las dimensiones.
Niveli id_nivel
...
Niveli+1
id_nivel
... ..*
no-estricta
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bebidas
Papel
Droguería
25/3/11
56
Data WareHouse
Estructura de las dimensiones.
Niveli id_nivel
...
Niveli+1
id_nivel
... 0 ..
no-balanceada
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bebidas
Papel
Varios
Data WareHouse
Esquemas multidimensionales que comparten una dimensión a distinto nivel.
4. Diseño de un almacén de datos
Hecho1
medida1 medida2
...
*
*
1
1
D1
D2
Hecho2
medida1 medida2
...
D1
D2
D3
Nivel0
id_nivel
...
Nivelj id_nivel
...
Nivel1n
id_nivel
...
1
1
1
* *
*
* *
1
1
25/3/11
57
Data WareHouse
4. Diseño de un almacén de datos
Ventas
unidades importe
...
* *
1
1
Suministros
unidades importe
...
día
...
mes
...
año
1
* * *
1
1
1..1
1..1
*
1
1..*
1..*
Data WareHouse
El desarrollo de la tecnología de almacenes de datos se ha caracterizado por:
- un temprano desarrollo industrial provocado por las demandas de los usuarios.
- el uso de metodologías de diseño centradas principalmente en los niveles lógico e interno. (la atención se ha centrado en mejorar la eficiencia en la ejecución de consultas)
Metodología de diseño basada en el modelo relacional: Modelo multidimensional de Kimball
4. Diseño de un almacén de datos
25/3/11
58
Data WareHouse
Diseño físico Esquema interno
Diseño lógico específico
Esquema lógico (ROLAP, MOLAP)
Implementación Creación del AD
Esquema relacional multidimensional
Diseño conceptual
Recogida y análisis de requisitos
Requisitos de consulta
Metodología de diseño de almacenes de datos basada en el MR (modelo relacional):
Mod
elad
o m
ultid
imen
sion
al
MR
4. Diseño de un almacén de datos
Data WareHouse
Método de diseño de almacenes de datos basado en el modelo relacional: modelo multidimensional de Kimball. (nivel lógico)
esquema relacional compuesto de:
- 1 tabla de hechos
- n tablas de dimensiones
diseño multidimensional de Kimball
Esquema multidimensional (esquema en estrella)
tabla de hechos: actividad que es objeto del análisis
tablas de dimensiones: dimensiones del análisis
4. Diseño de un almacén de datos
25/3/11
59
Data WareHouse
esquema estrella (star schema)
tabla de hechos
tabla de dimensión
tabla de dimensión
tabla de dimensión
tabla de dimensión
tabla de dimensión
tabla de dimensión
CAj
CAj
CAj
CAj
CAj
CAj
medidas
visión multidimensional de los datos
¡ la
tabl
a de
hec
hos
se re
laci
ona
con
la ta
blas
de
dim
ensi
ones
a tr
avés
de
rela
cion
es 1
:M !
4. Diseño de un almacén de datos
Data WareHouse
esquema copo de nieve (snowflake schema)
tabla de hechos
tabla de dimensión
tabla de dimensión
jerarquía de dimensión
tabla de dimensión
CAj
CAj
CAj
CAj
CAj
CAj
medidas
Extensión del esquema en estrella cuando las dimensiones se organizan en jerarquías de niveles de dimensión (normalizar las tablas de dimensiones)
CAj
jerarquía de dimensión
CAj CAj
jerarquía de dimensión
4. Diseño de un almacén de datos
25/3/11
60
Data WareHouse
Pasos en el diseño conceptual del almacén de datos:
Paso 1. Elegir un “proceso” de la organización para modelar.
Paso 2. Decidir el gránulo (nivel de detalle) de representación del proceso.
Paso 3. Definir las dimensiones que caracterizan el proceso.
Paso 4. Decidir la información a almacenar sobre el proceso.
Modelado multidimensional: 4. Diseño de un almacén de datos
Para ilustrar los pasos de la metodología de diseño conceptual, se va a utilizar el modelo de Kimball.
Data WareHouse
Paso 1. Elegir un “proceso” de la organización para modelar.
Proceso: actividad de la organización soportada por un OLTP del cual se puede extraer información con el propósito de construir el almacén de datos.
Pedidos (de clientes)
Compras (a suministradores)
Facturación
Envíos
Ventas
Inventario
4. Diseño de un almacén de datos
25/3/11
61
Data WareHouse
Ejemplo: Cadena de supermercados. Cadena de supermercados con 300 almacenes en la que se expenden unos 30.000 productos distintos.
Actividad: Ventas.
La actividad a modelar son las ventas de productos en los almacenes de la cadena.
4. Diseño de un almacén de datos
Data WareHouse
Paso 2. Decidir el gránulo (nivel de detalle) de representación.
Gránulo: es el nivel de detalle al que se desea almacenar información sobre la actividad a modelar.
El gránulo define el nivel atómico de datos en el almacén de datos.
El gránulo determina el significado de las filas de la tabla de hechos.
El gránulo determina las dimensiones básicas del esquema
• transacción en el OLTP
• información diaria
• información semanal
• información mensual. ....
4. Diseño de un almacén de datos
25/3/11
62
Data WareHouse
id_dim1
id_dim2
id_dim3
...
id_dim n
....
(hechos)
tabla de hechos tabla
Dimensión 3 tabla Dimensión 1
tabla Dimensión 2
tabla Dimensión n
4. Diseño de un almacén de datos
Data WareHouse
Ejemplo: Cadena de supermercados. Gránulo: “se desea almacenar información sobre las ventas diarias de cada producto en cada almacén de la cadena”.
Gránulo:
define el significado de las filas de la tabla de hechos.
determina las dimensiones básicas del esquema.
producto
día
almacén
ventas
4. Diseño de un almacén de datos
25/3/11
63
Data WareHouse
Gránulo inferior: no se almacena información a nivel de línea de ticket porque no se puede identificar siempre al cliente de la venta lo que permitiría hacer análisis del comportamiento (hábitos de compra) de los clientes individuales.
Gránulo superior: no se almacena información a nivel semanal o mensual porque se perderían opciones de análisis interesantes: ventas en días previos a vacaciones, ventas en fin de semana, ventas en fin de mes, ....
4. Diseño de un almacén de datos
Data WareHouse
En un almacén de datos se almacena información a un nivel de detalle (gránulo) fino no porque se vaya a interrogar el almacén a ese nivel sino porque ello permite clasificar y estudiar (analizar) la información desde muchos puntos de vista.
4. Diseño de un almacén de datos
25/3/11
64
Data WareHouse
producto
día
almacén
ventas
id_producto
id_fecha
id_almacén
.....
.....
......
tabla de hechos
la clave primaria* está formada por los identificadores de las dimensiones.
datos (medidas) sobre las ventas diarias de un producto en un almacén.
* pueden existir excepciones a esta regla general
4. Diseño de un almacén de datos
Data WareHouse
Paso 3. Identificar las dimensiones que caracterizan el proceso. Dimensiones: dimensiones que caracterizan la actividad al nivel de detalle (gránulo) que se ha elegido.
Tiempo (dimensión temporal: ¿cuándo se produce la actividad?)
Producto (dimensión ¿cuál es el objeto de la actividad?)
Almacén (dimensión geográfica: ¿dónde se produce la actividad?)
Cliente (dimensión ¿quién es el destinatario de la actividad?)
De cada dimensión se debe decidir los atributos (propiedades) relevantes para el análisis de la actividad.
Entre los atributos de una dimensión existen jerarquías naturales que deben ser identificadas (Ej. día-mes-trimestre-año en la dimensiónTiempo)
4. Diseño de un almacén de datos
25/3/11
65
Data WareHouse
id_dim1
....
tabla Dimensión 1
4. Diseño de un almacén de datos
Por simplicidad se diseñarán esquemas en estrella, es decir las tablas de dimensiones contendrán todos los atributos de la dimensión.
Data WareHouse
Ejemplo: Cadena de supermercados.
definición de gránulo
dimensiones básicas
tiempo
producto
almacén
Nota: En las aplicaciones reales el número de dimensiones suele variar entre 4 y 15 dimensiones.
4. Diseño de un almacén de datos
25/3/11
66
Data WareHouse
Dimensión Tiempo:
dimensión presente en todo esquema multidimensional porque el AD contiene información histórica sobre la organización.
aunque el lenguaje SQL ofrece funciones de tipo DATE, una dimensión Tiempo permite representar otros atributos temporales no calculables en SQL.
se puede calcular de antemano
atributos frecuentes: – nro. de día, nro. de semana, nro. de año: valores absolutos del calendario juliano que permiten hacer ciertos cálculos aritméticos.
– día de la semana (lunes, martes, miércoles,...): permite hacer análisis sobre días de la semana concretos (ej. ventas en sábado, ventas en lunes,..).
4. Diseño de un almacén de datos
Data WareHouse
atributos frecuentes:
- día del mes (1..31): permite hacer comparaciones sobre el mismo día en meses distintos (ventas el 1º de mes).
- marca de fin de mes, marca de fin de semana : permite hacer comparaciones sobre el último día del mes o días de fin de semana en distintos meses.
- trimestre del año (1..4): permite hacer análisis sobre un trimestre concreto en distintos años.
- marca de día festivo: permite hacer análisis sobre los días contiguos a un día festivo.
- estación (primavera, verano..)
- evento especial: permite marcar días de eventos especiales (final de futbol, elecciones...)
jerarquía natural:
día - mes - trimestre -año
4. Diseño de un almacén de datos
25/3/11
67
Data WareHouse
Dimensión Producto:
la dimensión Producto se define a partir del fichero maestro de productos del sistema OLTP.
las actualizaciones del fichero maestro de productos deben reflejarse en la dimensión Producto (¿cómo?).
la dimensión Producto debe contener el mayor número posible de atributos descriptivos que permitan un análisis flexible. Un número frecuente es de 50 atributos.
atributos frecuentes: identificador (código en la organización), descripción, tamaño del envase, marca, categoría, departamento, tipo de envase, producto dietético, peso, unidades de peso, unidades por envase, fórmula, ...
jerarquías: producto-subcategoría-categoría-departamento
4. Diseño de un almacén de datos
Data WareHouse
Dimensión Almacén: la dimensión Almacén representa la información geográfica básica.
en un proceso de integración como es la creación de un A.D, esta dimensión suele ser creada explícitamente recopilando información que sólo tiene sentido en el A.D y que no la tiene en un OLTP (número de habitantes de la ciudad del almacén, caracterización del tipo de población del distrito donde se encuentra el almacén, ...)
atributos frecuentes: identificador (código en la organización), nombre, dirección, distrito, región, ciudad, país, teléfono, fax, tipo de almacén, superficie, fecha de apertura, fecha de la última remodelación, superficie para congelados, superficie para productos frescos, datos de la población del distrito, zona de ventas, ...
jerarquías:
– almacén - distrito - ciudad - región - país (jerarquía geográfica)
– almacén - zona_ventas - región_ventas (jerarquía de ventas)
4. Diseño de un almacén de datos
25/3/11
68
Data WareHouse
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
Almacén día
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto
4. Diseño de un almacén de datos
Data WareHouse
día
nro_producto
nro_almacén
...
...
...
Ventas
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén
Producto
día
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo 4. Diseño de un almacén de datos
25/3/11
69
Data WareHouse
4. Diseño de un almacén de datos
definición de gránulo
dimensiones básicas
D1
D2
Dn
id_dim1
id_dim2
id_dim3
...
id_dimn
(medidas)
tabla de hechos tabla
Dimensión 3 tabla Dimensión 1
tabla Dimensión 2
tabla Dimensión n
...
Los identificadores de las dimensiones (básicas) identifican la tabla de hechos
Data WareHouse
4. Diseño de un almacén de datos
id_dim1
id_dim2
id_dim3
...
id_dimn
(medidas)
tabla de hechos tabla
Dimensión 3 tabla Dimensión 1
tabla Dimensión 2
tabla Dimensión n
Se pueden añadir nuevas dimensiones al conjunto de dimensiones inicial, para incluir nuevos puntos de vista en el análisis.
tabla Dimensión k
25/3/11
70
Data WareHouse
4. Diseño de un almacén de datos
nro_producto
día
nro_almacén
id_promoción
ventas
Se desea incluir en el análisis el punto de vista de la promoción bajo la cual se ha realizado una venta.
Ventas
Si un producto, un día, en un almacén sólo puede ser ofertado con un tipo de promoción: la dimensión promoción está determinada por las dimensiones originales. El gránulo del esquema no ha variado.
Los identificadores de las dimensiones de manera independiente no constituyen el identificador de la tabla de hechos
Data WareHouse
4. Diseño de un almacén de datos
nro_producto
día
nro_almacén
nro_promoción
ventas
Se desea incluir en el análisis el punto de vista de la promoción bajo la cual se ha realizado una venta.
Ventas
Si un producto, un día, en un almacén puede ser ofertado con varios tipos de promociones: las cuatro dimensiones son independientes entre sí. El gránulo del esquema ha variado.
Los identificadores de las dimensiones en su conjunto constituyen el identificador de la tabla de hechos
25/3/11
71
Data WareHouse
Paso 4. Decidir la información a almacenar sobre el proceso. Hechos: información (sobre la actividad) que se desea almacenar en cada fila de la tabla de hechos y que será el objeto del análisis.
Precio
Unidades
Importe
....
Nota: algunos datos que en el OLTP coincidirían con valores de atributos de dimensiones, en el almacén de datos pueden representar atributos de hechos. (Ejemplo: el precio de venta de un producto).
4. Diseño de un almacén de datos
Data WareHouse
Ejemplo: Cadena de supermercados.
Gránulo: “se desea almacenar información sobre las ventas diarias de cada producto en cada almacén de la cadena”.
– importe total de las ventas del producto en el día
– número total de unidades vendidas del producto en el día
– número total de clientes distintos que han comprado el producto en el día.
4. Diseño de un almacén de datos
25/3/11
72
Data WareHouse
día
nro_producto
nro_almacén
importe
unidades
nro_clientes
Ventas
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén
Producto
día
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo
4. Diseño de un almacén de datos
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos
Diseño lógico
traducción del esquema conceptual multidimensional
(ER, UML, MR, ..)
Esquema relacional (ROLAP)
Esquema multidimensional (MOLAP)
4. Diseño de un almacén de datos
25/3/11
73
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos
Met
odol
ogía
de
Kim
ball
traducción directa
esquema relacional (ROLAP)
4. Diseño de un almacén de datos
(MR) esquema relacional
multidimensional
Se asumirá que el SAD es un sistema ROLAP, ya que es el caso mas frecuente.
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos
Mod
elad
o m
ultid
imen
sion
al
traducción
esquema relacional (ROLAP)
4. Diseño de un almacén de datos
(ER, UML, OO, ...) esquema conceptual multidimensional (ER, UML, OO, ..)
25/3/11
74
Data WareHouse
4. Diseño de un almacén de datos
Esquema multidimensional en UML.
Hecho
medida1 medida2
...
* *
*
1 1
1
D2
D3 Dn
* 1
Nivel0
id_nivel
...
....
id_nivel
...
Nivel1n
id_nivel
...
clase de hecho
tabla de hechos
clase de nivel de dimensión
tabla de nivel
asociación
(1:M)
clave ajena
traducción
Data WareHouse
4. Diseño de un almacén de datos
CAj CAj
CAj
D2
D3
Dn
id_nivel
...
id_nivel
...
id_nivel
...
CAj
CAj
CAj
id_dim1
id_dim2
..
id_dimn
medidas
Nivel0
Nivel..
Nivel1n
Hechos
25/3/11
75
Data WareHouse
Orientaciones de diseño lógico (ROLAP): uso de claves sin significado.
– en un almacén de datos debe evitarse el uso de las claves del sistema operacional.
– las claves de las dimensiones deben ser generadas artificialmente: claves de tipo entero (4 bytes) son suficiente para dimensiones de cualquier tamaño (232 valores distintos).
– la dimensión TIEMPO debe tener también una clave artificial.
Inconvenientes del uso de las claves del sistema operacional:
en el OLTP se puede decidir reutilizar valores de la clave no utilizados actualmente en la organización.
en el OLTP se puede decidir cambiar la codificación de las claves.
reduce el tamaño de la tabla de hechos
4. Diseño de un almacén de datos
Data WareHouse
id_almacén
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
Almacén id_fecha
día
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo id_producto
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto
4. Diseño de un almacén de datos
25/3/11
76
Data WareHouse
id_fecha
id_producto
id_almacén
importe
unidades
nro_clientes
Ventas
id_almacén
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
id_producto
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén
Producto
id_fecha
día
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo
4. Diseño de un almacén de datos
Data WareHouse
Orientaciones de diseño lógico (ROLAP): evitar normalizar.
Si se ha definido una única tabla de dimensión para cada dimensión identificada en el análisis (esquema en estrella), es frecuente que entre el conjunto de atributos de la tabla aparezcan dependencias funcionales que hacen que la tabla no esté en 3ª F.N.
Evitar normalizar:
el ahorro de espacio no es significativo
se multiplican los JOIN durante las consultas.
4. Diseño de un almacén de datos
25/3/11
77
Data WareHouse
id_almacén
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
id_producto
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén Producto
id_fecha
día
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo
3ª F.N
¿normalizar?
4. Diseño de un almacén de datos
Data WareHouse
id_producto
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto • 30.000 productos • 30 departamentos • ∼ 300 categorías (30 x10)
• ∼ 3000 subcategorías (300 x10)
Coca-Cola 33cl.→ Refresco-cola → Refrescos → Bebidas
• “el nombre de un departamento (20 bytes) se repite aproximadamente 1000 veces en la tabla Producto”.
• “el nombre de una categoría (20 bytes) se repite aproximadamente 100 veces en la tabla Producto”.
• “el nombre de una subcategoría (20 bytes) se repite aproximadamente 10 veces en la tabla Producto”.
4. Diseño de un almacén de datos
25/3/11
78
Data WareHouse
id_producto
nro_producto
descripción
marca
id_subcat
peso
unidades_peso
tipo_envase
dietético
...
Producto id_subcat
subcategoría
id_cat
id_cat
categoría
id_dpto
id_dpto
departamento
Departamento
Categoría
Subcategoría
3ª F.N
4. Diseño de un almacén de datos
esquema en copo de nieve
Data WareHouse
• “el nombre de un departamento (20 bytes) se repite aproximadamente 1000 veces en la tabla Producto”.
• “el nombre de una categoría (20 bytes) se repite aproximadamente 100 veces en la tabla Producto”.
• “el nombre de una subcategoría (20 bytes) se repite aproximadamente 10 veces en la tabla Producto”.
ahorro de espacio: ∼ 20.000 bytes
Tamaño frecuente de una tabla Producto: ∼ 3 GB
4. Diseño de un almacén de datos
25/3/11
79
Data WareHouse
4. Diseño de un almacén de datos
CAj CAj
CAj
D2
D3
Dn
id_nivel
...
id_nivel
...
id_nivel
...
CAj
CAj
CAj
id_dim1
id_dim2
..
id_dimn
medidas
Nivel0
Nivelj
Nivel1n
Hechos
desnormalizar
D1
CAj
Data WareHouse
Ventajas de la desnormalización:
evitar la concatenación (join) de tablas durante las consultas
sencillez de uso
Inconvenientes de la desnormalización:
redundancia (ocupación de espacio)
4. Diseño de un almacén de datos
25/3/11
80
Data WareHouse
Alternativas: dimensión desnormalizada: todos los atributos de la dimensión están incluidos en una única tabla.
dimensión normalizada: cada tabla de nivel en la dimensión incluye el identificador interno (clave ajena) del nivel "padre" en cada jerarquía a la que pertenece (puede incluir también el identificador en la organización).
dimensión moderadamente normalizada: cada tabla de nivel incluye los identificadores internos de todos los "antecesores" en cada jerarquía a la que pertenece (puede incluir también los identificadores en la organización).
4. Diseño de un almacén de datos
Data WareHouse
4. Diseño de un almacén de datos
Esquema en estrella
Dimensión Producto desnormalizada
id_producto
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto
25/3/11
81
Data WareHouse
id_producto
nro_producto
descripción
marca
id_subcat
peso
unidades_peso
tipo_envase
dietético
...
Producto id_subcat
subcategoría
id_cat
id_cat
categoría
id_dpto
id_dpto
departamento
Departamento
Categoría
Subcategoría
3ª F.N
4. Diseño de un almacén de datos
Esquema en copo de nieve
Dimensión Producto normalizada
Data WareHouse
id_producto
nro_producto
descripción
marca
id_subcat
subcategoría
peso
unidades_peso
tipo_envase
dietético
...
Producto id_subcat
subcategoría
id_cat
categoría
...
id_cat
categoría
id_dpto
departamento
...
id_dpto
departamento
...
Departamento
Categoría
Subcategoría
3ª F.N
4. Diseño de un almacén de datos
Esquema en copo de nieve
Dimensión Producto normalizada
25/3/11
82
Data WareHouse
id_producto
nro_producto
descripción
marca
id_subcat
id_cat
id_dpto
peso
unidades_peso
tipo_envase
dietético
...
Producto id_subcat
subcategoría
id_cat
id_dpto
...
id_cat
categoría
id_dpto
...
id_dpto
departamento
...
Departamento
Categoría
Subcategoría
4. Diseño de un almacén de datos
Esquema en copo de nieve
Dimensión Producto moderadamente normalizada
Data WareHouse
id_producto
nro_producto
descripción
marca
id_subcat
subcategoría
id_cat
categoría
id_dpto
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto id_subcat
subcategoría
id_cat
categoría
id_dpto
departamento
…
id_cat
categoría
id_dpto
departamento
…
id_dpto
departamento
…
Departamento
Categoría Subcategoría
4. Diseño de un almacén de datos
Esquema en copo de nieve
Dimensión Producto moderadamente normalizada
25/3/11
83
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos
Diseño físico
consideraciones de almacenamiento físico
Esquema físico en el SGBD disponible
4. Diseño de un almacén de datos
Data WareHouse
Diseño físico: depende del tipo de SAD (MOLAP o ROLAP).
Sistemas MOLAP disponen de estructuras de almacenamiento específicas (matrices multidimensionales) y técnicas de compactación de datos que favorecen el rendimiento del almacén.
Sistemas ROLAP se implementan sobre tecnología relacional, pero disponen de algunas facilidades para mejorar el rendimiento (índices de mapas de bits, índices de JOIN, técnicas de particionamiento, ...).
4. Diseño de un almacén de datos
Objetivo: obtener un buen tiempo de respuesta en la evaluación de las consultas.
25/3/11
84
Data WareHouse
Diseño físico: depende del tipo de SAD (MOLAP o ROLAP).
Las decisiones de diseño físico deben tener en cuenta la estrategia de optimización de consultas seguida en el SGBD disponible.
4. Diseño de un almacén de datos
Objetivo: obtener un buen tiempo de respuesta en la evaluación de las consultas.
Data WareHouse
Diseño físico en un sistema ROLAP: Plan de evaluación de una consulta*:
1. Evaluar las condiciones de la consulta sobre cada dimensión para obtener un conjunto de identificadores.
2. Combinar (producto cartesiano) los identificadores de todas las dimensiones obtenidos en el paso anterior.
3. Buscar las filas de la tabla de hechos correspondientes a estos identificadores.
4. Agrupar las filas y agregar las medidas.
* Este plan de evaluación de consultas presupone que el sistema ROLAP aplica una estrategia de optimización específica para esquemas multidimensionales (esquemas en estrella): star schema optimization.
4. Diseño de un almacén de datos
25/3/11
85
Data WareHouse
34 12-12-98 12-98 lunes 4-98 1998 no
56 10-6-97 6-97 miércoles 2-97 1997 si
12 10-1-99 1-99 sábado 1-99 1999 no
34 12-8-98 8-98 lunes 3-98 1998 si
41 1-6-97 6-97 sábado 2-97 1997 no
Tiempo ..... sábado domingo 0 0
0 1 1 0 0 0
1 0 …
Índice-día de la semana
12
41 Identificadores
(Tiempo)
4. Diseño de un almacén de datos
1. Evaluar las condiciones de la consulta sobre cada dimensión para obtener un conjunto de identificadores.
día='sábado'
Data WareHouse
3 almacén1 Valencia Comunidad Valenciana España
34 almacén5 León Castilla-León España
21 almacén7 Valencia Comunidad Valenciana España
....
Almacén Valencia [•, • ] León [• ]
…
Índice-ciudad
3
21
Identificadores
(Almacén)
4. Diseño de un almacén de datos 1. Evaluar las condiciones de la consulta sobre cada dimensión para obtener un conjunto de identificadores.
ciudad='Valencia'
25/3/11
86
Data WareHouse
4. Diseño de un almacén de datos
3
21
Identificadores
(Almacén)
12
41
Identificadores
(Tiempo)
X
12 3
12 21
41 3
41 21
2. Combinar (producto cartesiano) los identificadores de todas las dimensiones obtenidos en el paso anterior.
Data WareHouse
id_fecha id_alm id_prod importe ....
12 3 14 100000
.....
12 21 34 50000
.....
12 3 99 65000
Índice Tiempo-Almacén
12 3 [•, • ]
......
12 21 [• ]
.....
Ventas
RIDs
12 3
12 21
41 3
41 21
4. Diseño de un almacén de datos
3. Buscar las filas de la tabla de hechos correspondientes a estos identificadores.
25/3/11
87
Data WareHouse
.......
12 3 14 100000
.....
12 21 34 50000
.....
12 3 99 65000
Ventas
4. Diseño de un almacén de datos
.......
12 3 165000
.....
12 21 50000
.....
Informe
4. Agrupar las filas y agregar las medidas.
Data WareHouse
4. Diseño de un almacén de datos
Recursos para el diseño físico en sistemas ROLAP: Diseño de índices
índices en árbol B
índices de mapa de bits
índices de JOIN
Particionamiento de la tabla de hechos
particionamiento vertical (por columnas)
particionamiento horizontal (por filas)
25/3/11
88
Data WareHouse
Diseño de índices: Tabla de hechos:
1 índice sobre la clave primaria (compuesta)
índices sobre subconjuntos de componentes de la clave primaria.(utilizados frecuentemente en las búsquedas)
Tablas de dimensión:
índices sobre los atributos usados frecuentemente para establecer restricciones sobre las dimensiones.
4. Diseño de un almacén de datos
Data WareHouse
Diseño de índices:
Los índices compuestos deben diseñarse ordenando los campos en el índice de forma que favorezcan la evaluación de las consultas más frecuentes.
4. Diseño de un almacén de datos
25/3/11
89
Data WareHouse
Estimación del tamaño del AD: Hipótesis de trabajo:
- los atributos identificadores (clave) son de 4 bytes.
- los atributos (numéricos) de la tabla de hechos (medidas) son de 4 bytes
- en tablas de hechos con 4 o menos medidas el tamaño del índice maestro (sobre la clave primaria) suele tener un tamaño entre el 60% y el 80% del tamaño de la tabla de hechos.
- en tablas de hechos que tienen de 15 a 20 medidas el tamaño del índice maestro suele tener un tamaño entre el 30% y el 50% del tamaño de la tabla de hechos.
- el tamaño de las tablas de dimensiones y sus índices asociados es mucho menor que el tamaño de la tabla de hechos.
4. Diseño de un almacén de datos
Data WareHouse
Estimación del tamaño del AD:
Ejemplo: Cadena de supermercados.
Tabla de hechos (sin índices ni datos agregados)
Tiempo: información almacenada durante 2 años (2x365 días=730 días)
Almacén: 300 almacenes.
Producto: 30000 productos (10% se venden diariamente en un almacén).
3000 x 730 x 300= 657 millones de tuplas
657millones de tuplas x 6 atributos x 4 bytes ∼ 16 GB
4. Diseño de un almacén de datos
25/3/11
90
Data WareHouse
Tecnología actual de Almacenes de Datos: La tecnología actual está preparada para gestionar almacenes de datos con:
nro. tuplas de tabla de hechos < 1billón de tuplas
tamaño de la tabla de hechos < 100GB.
4. Diseño de un almacén de datos
Data WareHouse
Sectores con almacenes de datos muy grandes: Compañías telefónicas: análisis de llamadas.
Proveedores mayoristas: ventas a nivel de línea de ticket.
Compañías de tarjetas de crédito: compras con tarjeta.
4. Diseño de un almacén de datos
25/3/11
91
Data WareHouse
Ejemplo: Proveedores mayoristas. Tiempo: 3 años
Ingresos anuales: $80 billones
Importe medio de una línea de factura: $5
Nro. de líneas de factura: $80 / $5=16 billones
Nro. de tuplas de la tabla de hechos: 16b. x 3=48b.
Nro. de campos de la clave: 4; Nro. de campos de datos: 4
Tamaño de la tabla de hechos:
48b. x 8 campos x 4bytes = 1.540GB.
4. Diseño de un almacén de datos
Data WareHouse
Ejemplo: Compañía telefónica. Tiempo: 3 años = 1095 días
Nro. llamadas por día: 100 millones
Nro. de tuplas de la tabla de hechos: 1095 x 1000000=109b.
Nro. de campos de la clave: 5; Nro. de campos de datos: 3
Tamaño de la tabla de hechos:
109b. x 8 campos x 4bytes = 3.490GB.
4. Diseño de un almacén de datos
25/3/11
92
Data WareHouse
Ejemplo: Tarjetas de crédito. Tiempo: 3 años = 36 meses
Nro. de tarjetas de crédito: 50 millones
Nro. medio de compras mensuales con tarjeta: 30.
Nro. de tuplas de la tabla de hechos: 36 x 50000000 x 30 = 54b.
Nro. de campos de la clave: 5; Nro. de campos de datos: 3
Tamaño de la tabla de hechos:
54b. x 8 campos x 4bytes = 1.730GB.
4. Diseño de un almacén de datos
Data WareHouse
Consideraciones en el diseño de almacenes de datos. Diseño de dimensiones:
dimensión Tiempo
dimensiones “muy grandes”
dimensiones en la sombra
dimensiones degeneradas
dimensiones no-completas
dimensiones no-estrictas
4. Diseño de un almacén de datos
25/3/11
93
Data WareHouse
Consideraciones en el diseño de almacenes de datos. Diseño de hechos:
diseño de la tabla de hechos
relaciones M:M entre la tabla de hechos y las tablas de dimensiones
tablas de hechos degeneradas
4. Diseño de un almacén de datos
Data WareHouse
Consideraciones en el diseño de almacenes de datos. Otras consideraciones:
dimensiones “que cambian”
definición de agregados
4. Diseño de un almacén de datos
25/3/11
94
Data WareHouse
Consideraciones en el diseño de almacenes de datos. Diseño de dimensiones:
dimensión Tiempo
dimensiones “muy grandes”
dimensiones en la sombra
dimensiones degeneradas
dimensiones no-completas
dimensiones no-estrictas
4. Diseño de un almacén de datos
Data WareHouse
En un almacén de datos muchas consultas son restringidas y parametrizadas por criterios relativos a periodos de tiempo (último mes, este año, ...).
Diseño de dimensiones: introducir la dimensión Tiempo.
4. Diseño de un almacén de datos
25/3/11
95
Data WareHouse
id_fecha
id_producto
id_almacén
importe
unidades
nro_clientes
Ventas
id_almacén
nro_almacén
nombre
dirección
distrito
región
ciudad
país
tlfno
fax
superficie
tipo_almacén
...
id_producto
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Almacén
Producto
id_fecha
fecha
semana
mes
año
día_semana
día_mes
trimestre
festivo
....
Tiempo 4. Diseño de un almacén de datos
Data WareHouse
id_fecha fecha mes día-semana trimestre año festivo
12-12-98 12-98 lunes 4-98 1998 no
10-6-97 6-97 miércoles 2-97 1997 si
10-1-99 1-99 jueves 1-99 1999 no
12-8-98 8-98 lunes 3-98 1998 si
1-6-97 6-97 sábado 2-97 1997 no
Ejemplo de dimensión Tiempo desnormalizada
4. Diseño de un almacén de datos
25/3/11
96
Data WareHouse
Atributos de la dimensión tiempo: fecha completa (en el formato del AD)
mes, trimestre y año
día de la semana (lunes.. domingo)
día del mes (1..31)
semana del mes (1..5)
día del año (1..365)
semana del año (1..48)
trimestre del año (1..4)
mes del año (enero..diciembre)
víspera de día festivo
día festivo
4. Diseño de un almacén de datos
Data WareHouse
Diseño de dimensiones : dimensiones “muy grandes”.
Existen dimensiones especialmente grandes, de millones de registros, que pueden plantear problemas de eficiencia durante la explotación del A.D. (tabla de clientes de una compañía de servicios, tabla de clientes de una aseguradora, etc)
crear minidimensiones
4. Diseño de un almacén de datos
25/3/11
97
Data WareHouse
Diseño de dimensiones: dimensiones “muy grandes”.
Ejemplo: El tamaño usual de una tabla de dimensión es de un número de registros inferior a 50.000 filas y aproximadamente 50 atributos. (dimensión PRODUCTO en una cadena de supermercados).
Una tabla de dimensión muy grande puede tener millones o incluso decenas de millones de filas. (dimensión CLIENTE en una compañía telefónica).
El tamaño de la dimensión penaliza la evaluación de restricciones sobre los atributos de la dimensión.
Nota: Incluso una tabla de dimensión muy grande con 10 millones de tuplas puede ocupar de 5 a 6 GB.
4. Diseño de un almacén de datos
Data WareHouse
Diseño de dimensiones: dimensiones “muy grandes”.
id_cliente
nro_cliente
dni
nombre
dirección
....
edad
nivel_ingresos
estado_civil
sexo
nivel_estudios
...
CLIENTE
atrib
utos
dem
ográ
ficos
son utilizados frecuentemente para establecer condiciones en las consultas.
tienen un rango de valores reducido.
4. Diseño de un almacén de datos
25/3/11
98
Data WareHouse
Diseño de dimensiones: dimensiones “muy grandes”.
id_cliente
nro_cliente
dni
nombre
dirección
....
id_demo
CLIENTE
id_demo
código
franja_edad
nivel_ingresos
estado_civil
sexo
nivel_estudios
minidimensión demográfica
......
id_cliente
id_demo
......
......
Tabla de Hechos
separar un grupo de atributos afines de la dimensión original en una dimensión auxiliar.
4. Diseño de un almacén de datos
Data WareHouse
Minidimensión: – se crea un registro en la minidimensión para cada combinación distinta de valores de los atributos seleccionados.
– el tamaño de la minidimensión debe estar por debajo de 100.000 filas.
– la clave de la minidimensión se incluye en la dimensión original (“dimensión muy grande”) y en la tabla de hechos*.
* En este caso la inclusión de una nueva dimensión no cambia la granularidad del esquema ni la clave primaria de la tabla de hechos.
4. Diseño de un almacén de datos
25/3/11
99
Data WareHouse
Ventajas del uso de las minidimensiones: ahorro de espacio
mejora la evaluación de restricciones sobre los atributos de la minidimensión.
restricciones sobre atributos de la minidimensión pueden ser aplicadas sin acceder a la dimensión original, concatenando directamente con la tabla de hechos.
restricciones sobre atributos de la minidimensión y otros atributos de la dimensión original pueden ser evaluados (la clave de la minidimensión aparece en la dimensión original).
facilita el tratamiento de cambios sobre atributos de la minidimensión: no es necesario crear un nuevo registro en la dimensión original.
4. Diseño de un almacén de datos
Data WareHouse
id_demo ...........
1 ............
2 ............
3 ............
id_cliente ......... id_demo
11 ........... 2
26 ............ 1
33 ............ 1
.... id_cliente id_demo .............
.... 11 1 ............
.... 11 2 ............
.... 33 1 ............
Tabla de hechos
Demo
Cliente
El cliente de id_cliente 11 ha cambiado su dimensión demográfica de un valor 1 a un valor 2 (valor actual) teniendo hechos almacenados de cada etapa. Un nuevo cambio al valor 3 significaría modificar el valor de id_demo en Cliente y almacenar a partir de ese momento los hechos relativos al cliente 11 con el valor de id_demo igual a 3.
4. Diseño de un almacén de datos
25/3/11
100
Data WareHouse
Diseño de dimensiones: dimensiones en la sombra.
id_almacén
id_fecha
id_producto
unidades
nro_clientes
importe
Ventas Almacén
1 1
1
N
N
N
Tiempo
Producto
Las tablas de dimensiones representan “los puntos de vistas del análisis”.
4. Diseño de un almacén de datos
Data WareHouse
Las tablas de dimensiones deben contener atributos analíticos:
- los atributos analíticos no son propios de un valor (instancia) de la dimensión sino de conjuntos de valores. (Ejemplo: categoría, región, …)
- los atributos analíticos suelen tener un rango de valores limitado.
- los atributos analíticos son utilizados en el análisis de datos: aplicar condiciones sobre las dimensiones.
Diseño de dimensiones: dimensiones en la sombra.
4. Diseño de un almacén de datos
25/3/11
101
Data WareHouse
Cuando en el análisis de datos, una dimensión participa al nivel básico (producto, almacén, día), suele ser frecuente que en el informe del usuario se deseen incluir atributos descriptivos del valor (instancia) de la dimensión.
Ejemplo: En un informe de ventas por productos, regiones y años, puede ser interesante que aparezca la descripción completa del producto (nombre).
Este hecho justifica la inclusión de atributos que no son analíticos en las dimensiones: descripción del producto, nombre del cliente, ..
Para no penalizar el tamaño de las tablas de dimensiones con atributos que no son analíticos se suelen definir dimensiones en la sombra (shadow dimension).
Diseño de dimensiones: dimensiones en la sombra.
4. Diseño de un almacén de datos
Data WareHouse
id_almacén
id_fecha
id_producto
id_info_producto
unidades
nro_clientes
importe
Ventas Almacén
1 1
1
N
N
N
Tiempo
Producto 1 N
Info_producto
dimensión en la sombra
Diseño de dimensiones: dimensiones en la sombra.
4. Diseño de un almacén de datos
* En este caso la inclusión de una nueva dimensión no cambia la granularidad del esquema ni la clave primaria de la tabla de hechos.
25/3/11
102
Data WareHouse
id_cliente
id_fecha
id_clinica
importe
Facturación Cliente
1 1
1
N
N
N
Tiempo
Clínica
Tabla de hechos: facturación a clientes en las distintas clínicas de un sistema sanitario.
Diseño de dimensiones: dimensiones degeneradas.
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_factura
importe
Facturación Cliente
1 1
1
N
N
N
Tiempo
Clínica
Tabla de hechos: facturación a clientes en las distintas clínicas de un sistema sanitario.
1
N Factura
dimensión degenerada
Diseño de dimensiones: dimensiones degeneradas.
4. Diseño de un almacén de datos
25/3/11
103
Data WareHouse
id_cliente
id_fecha
id_clinica
Id_factura
importe
Facturación Cliente
1 1
1
N
N
N
Tiempo
Clínica
Tabla de hechos: facturación a clientes en las distintas clínicas de un sistema sanitario.
1 N Factura
dimensión degenerada
Diseño de dimensiones: dimensiones degeneradas.
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_factura
importe
Facturación Cliente
1 1
1
N
N
N
Tiempo
Clínica
Tabla de hechos: facturación a clientes en las distintas clínicas de un sistema sanitario.
1 N Factura dimensión
degenerada
Diseño de dimensiones: dimensiones degeneradas.
4. Diseño de un almacén de datos
25/3/11
104
Data WareHouse
Diseño de dimensiones: dimensiones no-completas.
4. Diseño de un almacén de datos
Dimensión no-completa: dimensión que tiene una jerarquía no completa
Categoría
nombre
...
Departamento
nombre
... 0..
no-completa
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bisutería
Bebidas
Papel
Data WareHouse
Diseño de dimensiones: dimensiones no-completas.
4. Diseño de un almacén de datos
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bisutería
Bebidas
Papel
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto
Solución: convertir la jerarquía no-completa en una jerarquía completa introduciendo valores artificiales para el nivel que causa el problema.
25/3/11
105
Data WareHouse
Diseño de dimensiones: dimensiones no-completas.
4. Diseño de un almacén de datos
id_producto id_fecha id_almacén importe ...
3 12 13 100
7 15 12 50
4 78 11 400
6 7 12 67
......
Ventas 1 p23 Magno Coñac Bebidas
2 p34 Cune Vino Bebidas
3 p11 Dodot Servilleta Papel
4 p4 Klenex Pañuelo Papel
6 p14 Loewe Bisutería NULL
Producto
Departamento Ingresos
Bebidas 150
Papel 400
Total ingresos: 550
El total (550) es incorrecto
Informe de ingresos por departamento.
id_prod nro_prod marca categoría departamento
Data WareHouse
Diseño de dimensiones: dimensiones no-completas.
4. Diseño de un almacén de datos
id_producto id_fecha id_almacén importe ....
3 12 13 100
7 15 12 50
4 78 11 400
6 7 12 67
......
Ventas
Producto
Departamento Ingresos
Bebidas 150
Papel 400
Varios 67
Total ingresos: 1220
El total (1220) es correcto
Informe de ingresos por departamento.
Definir un departamento Varios para convertir la jerarquía no-completa en completa.
1 p23 Magno Coñac Bebidas
2 p34 Cune Vino Bebidas
3 p11 Dodot Servilleta Papel
4 p4 Klenex Pañuelo Papel
6 p14 Loewe Bisutería Varios
id_prod nro_prod marca categoría departamento
25/3/11
106
Data WareHouse
Diseño de dimensiones: dimensiones no-estrictas.
4. Diseño de un almacén de datos
Categoría
nombre
...
Departamento
nombre
... ..*
no-estricta
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bebidas
Papel
Droguería
Dimensión no-estricta: dimensión que tiene una jerarquía no-estricta
Data WareHouse
Diseño de dimensiones: dimensiones no-estrictas.
4. Diseño de un almacén de datos
Categoría Departamento
Coñac
Vino
Servilletas
Pañuelos
Bebidas
Papel
Droguería
nro_producto
descripción
marca
subcategoría
categoría
departamento
peso
unidades_peso
tipo_envase
dietético
...
Producto
Solución: documentar el esquema y advertir al usuario de los problemas.
25/3/11
107
Data WareHouse
Diseño de dimensiones: dimensiones no-estrictas.
4. Diseño de un almacén de datos
id_prod id_fecha id_alm importe
3 12 13 100
7 15 12 50
4 78 11 400
5 7 12 67
......
Ventas
Producto id_prod nro_prod marca categoría
3 p23 Magno Coñac
7 p34 Cune Vino
4 p11 Dodot Servilleta
5 p4 Klenex Pañuelo
id_dpto departamento
1 Bebidas
2 Papel
3 Droguería
Departamento
id_prod id_dpto
3 1
7 1
4 2
5 2
5 3
Prod_Dpto
Data WareHouse
Diseño de dimensiones: dimensiones no-estrictas.
4. Diseño de un almacén de datos
id_producto id_fecha id_almacén importe
3 12 13 100
7 15 12 50
4 78 11 400
5 7 12 67
......
Ventas
Producto
Departamento Ingresos
Bebidas 150
Papel 467
Droguería 67
Total ingresos: 684
El total (684) es incorrecto
Informe de ingresos por departamento.
1 p23 Magno Coñac Bebidas
2 p34 Cune Vino Bebidas
3 p11 Dodot Servilleta Papel
4 p4 Klenex Pañuelo Papel, Droguería
id_prod nro_prod marca categoría departamento
25/3/11
108
Data WareHouse
Diseño de dimensiones: dimensiones no-estrictas.
4. Diseño de un almacén de datos
id_producto id_fecha id_almacén importe
3 12 13 100
7 15 12 50
4 78 11 400
5 7 12 67
......
Ventas
Informe de ingresos por departamento.
No se puede agrupar por departamento, ya que la jerarquía no es estricta por debajo de departamento.
1 p23 Magno Coñac Bebidas
2 p34 Cune Vino Bebidas
3 p11 Dodot Servilleta Papel
4 p4 Klenex Pañuelo Papel, Droguería
id_prod nro_prod marca categoría departamento
Data WareHouse
Consideraciones en el diseño de almacenes de datos. Diseño de hechos
diseño de la tabla de hechos.
relaciones M:M entre la tabla de hechos y las tablas de dimensiones.
tablas de hechos degeneradas
4. Diseño de un almacén de datos
25/3/11
109
Data WareHouse
Diseño de hechos: atributos aditivos, semiaditivos y no-aditivos
– los atributos de la tabla de hechos (medidas) son generalmente de dominios continuos, numéricos y de carácter aditivo.
– existen medidas que pueden ser aditivos para algunas dimensiones y no serlo para otras. ¡Atención!
– los cálculos realizados sobre las medidas pueden ser aditivos o no aditivos. ¡Atención!
4. Diseño de un almacén de datos
Data WareHouse
Diseño de hechos: atributos aditivos, semiaditivos, no-aditivos
id_fecha
id_producto
id_almacén
importe
unidades
nro_clientes
Ventas
id_fecha id_producto id_almacén importe unidades nro_clientes
....
13 1 23 5000 10 10
13 23 23 2000 4 2
13 12 23 1000 2 1
....
agrupación por Fecha y Almacén
agregación sobre Producto Ventas
8000 16 ≤ 13
aditivo aditivo no aditivo
El atributo nro_clientes es semiaditivo porque no es aditivo sobre la dimensión Producto.
Nota: en el ejemplo cliente es sinónimo de compra (no se pueden identificar los clientes).
4. Diseño de un almacén de datos
25/3/11
110
Data WareHouse
Diseño de hechos: atributos aditivos, semiaditivos y no-aditivos
Importe es aditivo sobre Tiempo, Producto, Almacén
Unidades es aditivo sobre Tiempo, Producto, Almacén
Nro-clientes es aditivo sobre Tiempo, Almacén y no es aditivo sobre Producto.
id_fecha id_producto id_almacén importe unidades nro_clientes
....
12 1 23 5000 10 10
12 1 25 2000 4 2
12 1 3 1000 2 1
....
agru
paci
ón p
or F
echa
y P
rodu
cto
agre
gaci
ón s
obre
Alm
acén
Ventas
8000 16 13
aditivo aditivo aditivo
4. Diseño de un almacén de datos
Data WareHouse
Diseño de hechos: atributos aditivos, semiaditivos y no-aditivos
Cálculos aditivos y no aditivos ¡Atención!
(beneficio es aditivo) beneficio = importe - costo
Z = X - Y (beneficio de cada venta individual)
∑X - ∑Y = ∑ (X -Y) = ∑Z
(el beneficio total es igual a la suma de beneficios individuales)
margen = beneficio/importe (margen no es aditivo)
Z= X/ Y (margen de beneficio en cada venta individual)
∑X/ ∑Y ≠ ∑(X/Y) = ∑Z
(el margen de beneficios total no es igual a la suma de márgenes de beneficio individuales)
4. Diseño de un almacén de datos
25/3/11
111
Data WareHouse
id_producto
id_fecha
id_almacén
id_promoción
ventas
Diseño de hechos: tablas de hechos “sin medidas”
Ejemplo: el almacén de datos para la “cadena de supermercados” introduciendo la dimensión promoción.
¡En el esquema anterior no es posible saber qué productos han estado en promoción en un almacén en una fecha determinada si no han tenido ventas!
4. Diseño de un almacén de datos
Data WareHouse
Diseño de hechos: tablas de hechos “sin medidas”
id_producto
id_fecha
id_almacén
id_promoción
Solución: tabla de hechos “sin medidas” para registrar las promociones diarias de productos en los almacenes de la cadena.
La tabla de hechos Ventas y la tabla de hechos Promociones permiten responder a las consultas:
productos que han estado en promoción y han sido vendidos
productos que han estado en promoción y no han sido vendidos
Promociones
4. Diseño de un almacén de datos
25/3/11
112
Data WareHouse
Diseño de hechos: tablas de hechos “sin medidas”
Las tablas de hechos “sin medidas” son tablas de hechos compuestas por los identificadores de las dimensiones pero sin medidas (datos).
Las tablas de hechos “sin medidas” se usan para registrar la ocurrencia de eventos que no llevan información asociada
4. Diseño de un almacén de datos
Data WareHouse
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
En un esquema multidimensional (en estrella) la tabla de hechos se relaciona con las tablas de dimensiones a través de relaciones 1:M.
id_dim1
id_dim2
id_dim3
...
id_dim n
....
(medidas)
tabla de hechos tabla
Dimensión 3 tabla Dimensión 1
tabla Dimensión 2
tabla Dimensión n
1 1
1
1
N
N
N
N
4. Diseño de un almacén de datos
25/3/11
113
Data WareHouse
En un esquema multidimensional (en estrella) la tabla de hechos se relaciona con las tablas de dimensiones a través de relaciones 1:M.
id_dim1
id_dim2
id_dim3
...
id_dim n
....
(medidas)
tabla de hechos tabla
Dimensión 3 tabla Dimensión 1
tabla Dimensión 2
tabla Dimensión n
1 1
1
1
N
N
N
N
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 N
N
N
N
N
Tiempo
Clínica Diagnóstico
En un sistema sanitario, en la factura a un cliente la clínica puede facturar pruebas realizadas para distintos tipos de diagnóstico (hepatitis, sida, …)
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
114
Data WareHouse
El identificador de las tuplas de la tabla de hechos esta formado por los identificadores: id_cliente, id_fecha, id_clínica.
El atributo id_diag, en la tabla de hechos es multivaluado.
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 N
N
N
N
N
Tiempo
Clínica Diagnóstico
Data WareHouse
id_cliente id_fecha id_clinica importe id_diag.....
2 4 12 145 3
7
4 6 15 300 3
25 78 12 400 7
......
Informe de facturación. 1 Diabetes
2 Hepatitis
4 Sida
Diagnósticos
Diagnóstico Ingresos
2 445
3 545
Total ingresos: 990
El total (990) es incorrecto
Informe de ingresos por tipo de diagnóstico.
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
115
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 N
N
N
N
N
Tiempo
Clínica Diagnóstico
En un sistema sanitario, en la factura a un cliente la clínica puede facturar pruebas realizadas para distintos tipos de diagnóstico (hepatitis, sida, …)
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_grupo
importe
Facturas Cliente
id_grupo
id_diag
factor
1 1
1 N
N
N
N
1
Tiempo
Clínica Grupo_diag
Solución 1: Crear una tabla puente (Grupo_diag) que permite fijar un factor (porcentaje) para cada diagnóstico dentro de una factura (o el importe exacto del diagnóstico en la factura). Una factura estará asociada a tantas filas de la tabla puente como diagnósticos incluya la factura.
id_diag
desc
…
Diagnóstico 1
N
Solución 1
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
116
Data WareHouse
id_cliente
id_fecha
id_clinica
id_grupo
importe
Facturas Cliente
id_grupo
id_diag
factor
1 1
1 N
N
N
N
1
Tiempo
Clínica Grupo_diag
Solución 1: el id_grupo representa una clave alternativa en la tabla de hechos.
id_diag
desc
…
Diagnóstico 1
N
Solución 1 Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
Data WareHouse
id_cliente id_fecha id_clinica id_grupo importe
.....
3 4 12 1 145
4 6 15 6 300
25 78 12 53 400
......
Informe de facturación 1 Diabetes
2 Hepatitis
4 Sida
Diagnóstico
Diagnóstico Ingresos (factor × importe)
2 336.25
3 508.75
Total ingresos: 845 El total (845) es correcto
Informe de ingresos por tipo de diagnóstico.
1 3 25
1 7 75
6 3 100
53 7 100
Se agrupa por tipo de diagnóstico
Grupo_diag
porcentaje que el diagnóstico
representa en el importe de la
factura
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
117
Data WareHouse
id_cliente id_fecha id_clinica id_grupo importe
.....
3 4 12 1 145
4 6 15 6 300
25 78 12 53 400
......
Facturas 1 Diabetes
2 Hepatitis
4 Sida
Diagnóstico
Diagnóstico Ingresos
2 336.25
3 508.75
Total ingresos: 845 El total (845) es correcto
Informe de ingresos por tipo de diagnóstico.
1 3 25
1 7 75
6 3 100
53 7 100
Se agrupa por tipo de diagnóstico
Grupo_diag
porcentaje que el diagnóstico
representa en el importe de la
factura
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 N
N
N
N
N
Tiempo
Clínica Diagnóstico
En un sistema sanitario, en la factura a un cliente la clínica puede facturar pruebas realizadas para distintos tipos de diagnóstico (hepatitis, sida, …)
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
118
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
Solución 2: Crear varias filas en la tabla de hechos que representen el mismo hecho (factura), una por cada diagnóstico incluido en la factura.
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
Data WareHouse
El identificador de la tabla de hechos está compuesto por los identificadores: id_cliente, id_fecha, id_clinica, id_diag.
Ha cambiado la granularidad del esquema en estrella: gránulo mas fino.
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
25/3/11
119
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
En las filas de la tabla de hechos se está almacenando información agregada (importe total de la factura). La medida importe no corresponde a la granularidad del esquema en estrella.
Con la granularidad del esquema en estrella, sólo se pueden usar la función COUNT sobre la tabla de hechos. No se puede utilizar la medida importe.
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
Data WareHouse
2004
“Resonancia”
“Valencia”
Clie
nte
Tiem
po
Dia
gnós
tico
importe
Ciudad Región
Nombre
DNI
Tipo_cliente Día
Mes
Día de la semana
Diagnóstico
Descripción
Departamento
Tipo_diag
Año
OLAP
Trimestre
Clín
ica
Ciudad Región
Nombre
Clínica
Tipo_clinica
Número de diagnósticos del departamento de Resonancia realizados este año en
clínicas de Valencia, por diagnóstico y por clínica.
4. Diseño de un almacén de datos
25/3/11
120
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
importe
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
SELECT D.diagnóstico, C.clínica, COUNT (*)
FROM Facturas F, Tiempo T, Diagnóstico D, Clínica C
WHERE F.id_diag = D.id_diag AND F.id_fecha = T.id_fecha AND
F.id_clínica = C.id_clínica AND D.departamento= ‘ Resonancia’ AND
C.ciudad = 'Valencia' AND T.año= year (TODAY)
GROUP BY D.diagnóstico, C.clínica
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
factura
importe
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
Para poder controlar la información redundante sobre una misma factura en la tabla de hechos, es necesario incluir en la tabla de hechos un atributo que identifique a la factura: nivel de agregación en el que tiene significado la medida importe.
Sólo cuando se agrupa por factura, se puede incluir la medida importe como atributo del grupo.
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
121
Data WareHouse
2004
“Análisis Valencia”
Clie
nte
Tiem
po
Dia
gnós
tico
factura
importe
Ciudad Región
Nombre
DNI
Tipo_cliente Día
Mes
Día de la semana
Diagnóstico
Descripción
Departamento
Tipo_diag
Año
OLAP
Trimestre
Clín
ica
Ciudad Región
Nombre
Clínica
Tipo_clinica
Facturación realizada en la clínica 'Análisis Valencia', para el año en curso.
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
factura
id_diag
importe
Facturas Cliente
1 1
1
1
N
N
N
N
Tiempo
Clínica
Diagnóstico
SELECT T.dia, CL.dni, CL.nombre, F.factura, sum(F.importe )
FROM Facturas F, Tiempo T, Clínica C, Cliente CL
WHERE
F.id_clinica = C.id_clínica AND F.id_fecha = T.id_fecha AND CL.id_cliente=F.id_cliente
AND C.clínica = 'Análisis Valencia' AND T.año = year (TODAY)
GROUP BY T.dia, CL.dni, CL.nombre, F.factura;
4. Diseño de un almacén de datos
25/3/11
122
Data WareHouse
Observar que el atributo factura de la tabla de hechos determina funcionalmente a id_cliente, id_fecha e id_clínica, es decir una factura corresponde a un cliente y ha sido realizada en una fecha y en una clínica determinada.
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
id_cliente
id_fecha
id_clinica
factura
id_diag
importe
Facturas Cliente
1 1
1
1
N
N
N
N
Tiempo
Clínica
Diagnóstico
Data WareHouse
id_cliente
id_fecha
id_clinica
id_diag
factura
importe
factor
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
Se puede incluir también un atributo que represente el porcentaje del diagnóstico en la factura o el importe del diagnóstico: medidas al nivel de la granularidad del esquema en estrella.
Solución 2
Diseño de hechos: relaciones M:M entre la tabla de hechos y una dimensión
4. Diseño de un almacén de datos
25/3/11
123
Data WareHouse
2005
“Resonancia”
Clie
nte
Tiem
po
Dia
gnós
tico
factura
importe
factor
Ciudad Región
Nombre
DNI
Tipo_cliente Día
Mes
Día de la semana
Diagnóstico
Descripción
Departamento
Tipo_diag
Año
OLAP
Trimestre
Clín
ica
Ciudad Región
Nombre
Clínica
Tipo_clinica
Importe total obtenido por pruebas del departamento de "Resonancia" , este año
por diagnóstico.
importe × factor
4. Diseño de un almacén de datos
Data WareHouse
SELECT D.diagnóstico, SUM (importe × factor)
FROM Facturas F, Tiempo T, Diagnóstico D
WHERE F.id_diag = D.id_diag AND F.id_fecha = T.id_fecha
AND D.departamento = 'Resonancia' AND T.año = year (TODAY)
GROUP BY D.diagnóstico
4. Diseño de un almacén de datos
id_cliente
id_fecha
id_clinica
id_diag
factura
importe
factor
Facturas Cliente
1 1
1 1
N
N
N
N
Tiempo
Clínica Diagnóstico
25/3/11
124
Data WareHouse
id_cliente
id_fecha
id_clinica
id_grupo
importe
Facturas Cliente
id_grupo
id_diag
importe
1 1
1 N
N
N
N
1
Tiempo
Clínica Grupo_diag
id_diag
desc
…
Diagnóstico 1
N
La tabla Grupo_diag es realmente una tabla de hechos degenerada: contiene información sobre la facturación a los clientes a nivel de diagnóstico.
Diseño de hechos: tablas de hechos degeneradas.
4. Diseño de un almacén de datos
Data WareHouse
id_cliente
id_fecha
id_clinica
id_grupo
importe
Facturas Cliente
id_grupo
id_diag
importe
1 1
1 N 1
Tiempo
Clínica Grupo_diag
id_diag
desc
…
Diagnóstico 1
N
La tabla Grupo_diag es realmente una tabla de hechos de un esquema en estrella cuyas dimensiones son Diagnóstico y Facturas.
Diseño de hechos: tablas de hechos degeneradas.
4. Diseño de un almacén de datos
25/3/11
125
Data WareHouse
id_cliente
id_fecha
id_clinica
id_grupo
importe
Facturas Cliente
id_grupo
id_diag
importe
1 1
1 N
N
N
N
1
Tiempo
Clínica Grupo_diag
id_diag
desc
…
Diagnóstico 1
N
La tabla Grupo_diag es realmente una tabla de hechos de un esquema en estrella cuyas dimensiones son Diagnóstico e indirectamente (a través de Facturas) Tiempo, Cliente y Clínica.
Diseño de hechos: tablas de hechos degeneradas.
4. Diseño de un almacén de datos
Data WareHouse
Consideraciones en el diseño de almacenes de datos. Otras consideraciones:
dimensiones “que cambian”
definición de agregados.
4. Diseño de un almacén de datos
25/3/11
126
Data WareHouse
Orientaciones de diseño: dimensiones “que cambian”.
Ejemplo: En un A.D existe la dimensión CLIENTE. En la tabla correspondiente un registro representa la información sobre el cliente “María García” cuyo estado civil cambia el 15-01-1994 de soltera a casada. El estado civil del cliente es utilizado con frecuencia en el análisis de la información.
Se considera relevante el caso en que, en el mundo real, para un valor de una dimensión, cambia el valor de un atributo que es significativo para el análisis sin cambiar el valor de su clave.
4. Diseño de un almacén de datos
Data WareHouse
Existen tres estrategias para el tratamiento de los cambios en las dimensiones:
Tipo 1: Realizar la modificación.
Tipo 2: Crear un nuevo registro.
Tipo 3: Crear un nuevo atributo.
4. Diseño de un almacén de datos
25/3/11
127
Data WareHouse
Orientaciones de diseño: dimensiones “que cambian”.
Tipo 1: Realizar la modificación.
° estrategia mas fácil de implementar.
° la información histórica ya no es segura.
° es aconsejable para:
– corregir errores.
– tratar cambios que no son relevantes para el análisis (ej. dirección del cliente, nombre del cliente, ...).
4. Diseño de un almacén de datos
Data WareHouse
Orientaciones de diseño: dimensiones “que cambian”.
Tipo 2: Crear un nuevo registro con los nuevos valores.
° a partir de ese momento existen en el A.D varias versiones de un mismo objeto del mundo real (cliente).
° es necesario crear un nuevo valor para la clave (generalización de la clave original o generación de un nuevo valor).
° implica una partición de la tabla de hechos en subconjuntos de tuplas asociados a cada versión del objeto.
° el usuario no puede relacionar la información sobre las distintas versiones del objeto (en la práctica son dos objetos distintos).
° el usuario puede reconstruir la historia del objeto a partir de otros atributos que no cambien de valor, como la clave del operacional (dni, nss, ..).
° es responsabilidad del S.G.A.D saber cuál es la última versión del objeto para asociarle los nuevos hechos que llegan al A.D.
4. Diseño de un almacén de datos
25/3/11
128
Data WareHouse
Generalización de la clave original: cuando la clave de la dimensión coincide con una clave del sistema operacional (clave con significado). La solución mas usual es añadir a la clave original uno o dos dígitos de versión para contemplar los sucesivos cambios.
Generación de un nuevo valor para la clave: cuando los valores de la clave son generados artificialmente (clave sin significado).
4. Diseño de un almacén de datos
Data WareHouse
nro_cliente dni nombre civil ....... 123 1876543 María García Soltera ......
....
1231 1876543 María García Casada ......
.....
1232 1876543 María García Divorciada ....
CLIENTE
nro_cliente id_poliza id_fecha
123 1 12/12/01
....
1231 35 13/01/02
...
1232 359 11/04/02
....
• el cliente de nro_cliente 123 realiza una póliza (1) en la fecha 12/12/01
• el cliente de nro_cliente 1231 realiza una póliza (35) en la fecha 13/01/02
• el cliente de nro_cliente 1232 realiza una póliza (359) en la fecha 11/04/02
dígito de versión
Cliente Póliza
Tiempo
4. Diseño de un almacén de datos
25/3/11
129
Data WareHouse
Orientaciones de diseño: dimensiones “que cambian”.
Tipo 3: Crear un nuevo atributo.
º se mantiene el atributo original con su valor y se crea un nuevo atributo con el valor actual y un atributo para indicar la fecha del cambio
º la partición en las tuplas asociadas de la tabla de hechos se realiza utilizando la fecha del cambio
º sólo se conservan dos valores: el valor original y el valor actual (se pierden los valores intermedios).
º permite considerar la historia completa del objeto (independientemente del valor del atributo) o considerar la historia dividida en dos periodos (anterior y posterior a la fecha de cambio).
...
atributo_original
atributo_actual
fecha_cambio
...
Dimensión
4. Diseño de un almacén de datos
Data WareHouse
Definición de agregados.
¡En un almacén de datos es usual consultar información agregada!
Ejemplos:
ventas por almacén, día y categoría de producto
ventas por ciudad, día y producto
ventas por ciudad, mes y producto
ventas por ciudad, día y categoría de producto
El almacenamiento de datos agregados por distintos criterios de agregación mejora la eficiencia del AD.
4. Diseño de un almacén de datos
25/3/11
130
Data WareHouse
Definición de agregados.
Estrategias de almacenamiento de datos agregados: Estrategia 1: definir nuevas tablas de hechos y de dimensiones para almacenar la información agregada y la descripción de los niveles de agregación. (definir un nuevo esquema en estrella).
Estrategia 2: insertar en las tabla de hechos y en las tablas de dimensiones del esquema, tuplas que representan respectivamente la información agregada y los niveles de agregación.
4. Diseño de un almacén de datos
Data WareHouse
Definición de agregados.
Estrategia 1: definir nuevas tablas de hechos y de dimensiones (nuevos esquemas en estrella).
Si se desea poder almacenar información agregada por categorías, ciudades y meses, se necesitarán tres "nuevas tablas de dimensiones" (CATEGORÍA, CIUDAD y MES) y tantas nuevas tablas de hechos como tipos distintos de agregación se desee realizar combinando estos tres criterios de agregación y las tres dimensiones básicas. Por ejemplo:
– ventas por categoría, día y almacén
– ventas por producto, mes y almacén
– ventas por producto, día y ciudad
– ventas por categoría, mes y almacén
– ventas por categoría, día y ciudad
– ventas por producto, mes y ciudad
– ventas por categoría, mes y ciudad.
4. Diseño de un almacén de datos
25/3/11
131
Data WareHouse
Definición de agregados.
Estrategia 1: definir nuevas tablas de hechos y de dimensiones.
id_categoría
categoría
departamento id_mes
mes
año id_ciudad
región
país
Categoría
Ciudad
Mes
Nuevas tablas de dimensiones
4. Diseño de un almacén de datos
Data WareHouse
Definición de agregados.
Estrategia 1: definir nuevas tablas de hechos y de dimensiones.
id_fecha
id_categoría
id_almacén
importe
unidades
nro_clientes
Ventas-categoría
id_almacén
nro_almacén
nombre
dirección
distrito
ciudad
país
...
Almacén
id_fecha
día
semana
mes
año
....
Tiempo
id_categoría
categoría
departamento
Categoría
Nueva tabla de hechos
Nuevo esquema en estrella
4. Diseño de un almacén de datos
25/3/11
132
Data WareHouse
Definición de agregados.
Estrategia 1: definir nuevas tablas de hechos y de dimensiones.
La creación de "tablas de dimensiones de agregación" exige la definición de claves artificiales para identificar todos los valores posibles para cada criterio de agregación considerado (id_categoría, id_ciudad, id_mes)
4. Diseño de un almacén de datos
Data WareHouse
Definición de agregados.
Estrategia 1: definir nuevas tablas de hechos y de dimensiones.
La definición de tablas de agregación por cualquier criterio no siempre tiene sentido.
La definición de la tabla agregada Ventas-categoría aconseja no definir también la tabla agregada de Ventas-departamento, ya que ésta última es fácilmente calculable a partir de la primera.
4. Diseño de un almacén de datos
25/3/11
133
Data WareHouse
Definición de agregados. Estrategia 2: insertar nuevas tuplas en la tabla de hechos y en las tablas de dimensiones.
id_echa
id_producto
id_almacén
importe
unidades
nro_clientes
Ventas
id_almacén
nro_almacén
nombre
dirección
distrito
id_fecha
día
semana
mes
año
Tiempo
Nuevo atributo para indicar el nivel de agregación representado por la tupla
id_producto
nro_producto
nivel_agregación
descripción
marca
subcategoría
categoría
departamento
...
Producto
Almacén
4. Diseño de un almacén de datos
Data WareHouse
Definición de agregados.
Estrategia 2: insertar nuevas tuplas en la tabla de hechos y en las tablas de dimensiones.
id_producto
nro_producto
nivel_agregación
descripción
marca
subcategoría
categoría
departamento
...
Producto Valores del atributo nivel_agregación: base, categoría, departamento, todos, ...
(contemplando la definición de agregados a distintos niveles de agregación en la dimensión producto)
4. Diseño de un almacén de datos
25/3/11
134
Data WareHouse
Estrategia 2: insertar nuevas tuplas en la tabla de hechos y en las tablas de dimensiones.
id_fecha id_producto id_almacén importe unidades nro_clientes
....
12 145 28 50000 100 18
12 23 23 2000 4 2
1 13 23 600000 340 90
....
Ventas
id_prod nivel_agreg ... categoría ... depto ... tipo_envase
.....
23 base refresco bebidas cristal
145 categoría servilleta droguería NULL
13 departamento NULL bebidas NULL
......
Producto
tuplas de agregación
4. Diseño de un almacén de datos
Data WareHouse
Estrategia 2: insertar nuevas tuplas en la tabla de hechos y en las tablas de dimensiones.
La estrategia 2, exige que en las consultas se controle el valor del atributo nivel_agregación: todas las tuplas seleccionadas al evaluar una restricción sobre la dimensión deben tener el mismo valor en el atributo nivel_agregación.
En la estrategia 2, las claves nuevas definidas para representar los niveles de agregación deben ser compatibles con las claves de las dimensiones originales.
4. Diseño de un almacén de datos Definición de agregados.
25/3/11
135
Data WareHouse
la estrategia 2 puede plantear el problema del “doble conteo” en la evaluación de restricciones sobre una dimensión: considerar en una agregación tuplas de niveles distintos (ej. del nivel básico y de otro nivel de agregación).
id_producto
nro_producto
nivel_agregación
descripción
marca
subcategoría
categoría
departamento
...
Producto
Una restricción sobre la dimensión Producto que incluya la condición Categoría=‘Papel’ y que no controle el valor del atributo nivel_agregación, recuperaría tuplas correspondientes a productos básicos de la categoría ‘Papel’ y la tupla de nivel de agregación “categoría” correspondiente a la categoría ‘Papel’.
4. Diseño de un almacén de datos
Estrategia 2: insertar nuevas tuplas en la tabla de hechos y en las tablas de dimensiones.
Definición de agregados.
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos
Implementación
Definición del esquema ROLAP o MOLAP
Carga del AD
Preparación de las vistas de usuario
(herramienta OLAP)
4. Diseño de un almacén de datos
25/3/11
136
Data WareHouse
Implementación
Definición del esquema ROLAP o MOLAP
Carga del AD
Preparación de las vistas de usuario
(herramienta OLAP)
Proceso de transformación:
filtrado de datos
consolidación de datos
agregación de datos
4. Diseño de un almacén de datos
Data WareHouse
1. Introducción a los almacenes de datos: motivación definición y características.
2. Arquitectura de un sistema de almacén de datos.
3. Explotación de un almacén de datos: herramientas OLAP.
4. Diseño de un almacén de datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un almacén de datos.
Almacenes de datos (Data Warehouse)
25/3/11
137
Data WareHouse
5. Sistemas ROLAP y MOLAP.
Sistemas ROLAP: El almacén de datos se construye sobre un SGBD Relacional.
Los fabricantes de SGBD relaciones ofrecen extensiones y herramientas para poder utilizar el SGBDR como un Sistema Gestor de Almacenes de Datos.
Data WareHouse
Sistemas ROLAP. Extensiones de los SGBD relacionales:
índices de mapa de bits
índices de JOIN
técnicas de particionamiento de los datos
optimizadores de consultas
extensiones del SQL
5. Sistemas ROLAP y MOLAP.
25/3/11
138
Data WareHouse
Índice: estructura de datos que permite el acceso a los registros (tuplas) de un fichero (relación) por el valor de un campo (atributo) (campo de indización)
Elementos de un índice (entradas del índice) en BD:
valor del campo de indización de una tupla
“dirección” de la tupla (RID) +
Los índices permiten el acceso directo y el acceso ordenado a los registros (tuplas) del fichero (relación) por el campo (atributo) de indización.
5. Sistemas ROLAP y MOLAP.
Data WareHouse
índice ≡ estructura en árbol de búsqueda
árboles B
árboles B+
árboles de búsqueda
equilibrados
de orden p
ocupación eficiente del espacio en los nodos
5. Sistemas ROLAP y MOLAP.
25/3/11
139
Data WareHouse
8 • 3 • 1 • 5 •
• • • 3
5 • • •
12 • 9 • 6 • 7 •
• • • 7 8
Árbol B+ para la secuencia de claves de entrada: 8, 5, 1, 7, 3, 12, 9, 6
Cada entrada en un nodo-hoja de un árbol B+ consiste de un valor del atributo de indización (clave) y un identificador de tupla (Row IDentifier) o una lista de RIDs de las tuplas que tienen dicho valor.
Los nodos internos sirven para distribuir las claves que sólo aparecen en los nodos-hoja.
5. Sistemas ROLAP y MOLAP.
Data WareHouse
Para campos de indización con una cardinalidad baja los índices de mapa de bits ofrecen un ahorro de espacio de almacenamiento.
cada valor del atributo de indización lleva asociado un vector de bits, el iésimo elemento de ese vector tiene el valor 1 si la iésima tupla de la relación tiene dicho valor en el atributo de indización, sino tiene el valor 0.
los índices de mapa de bits son más eficientes para la evaluación de condiciones lógicas (NOT, AND, OR).
5. Sistemas ROLAP y MOLAP.
25/3/11
140
Data WareHouse
Profesor (cod_prof, nombre, sexo, categoría)
varón dama
0 1
0 1
1 0
0 1
… …
TEU TU CEU CU
0 1 0 0
1 0 0 0
0 0 1 0
0 1 0 0
… …
Índice-sexo Índice-categoría
vector de bits para el valor ‘varón’
vector de bits para el valor ‘dama’
5. Sistemas ROLAP y MOLAP.
Data WareHouse
“Profesores varones que sean catedráticos de universidad”:
0
0
1
0
…
0
0
0
0
…
AND
0
0
0
0
…
5. Sistemas ROLAP y MOLAP.
25/3/11
141
Data WareHouse
Índices de JOIN: Una consulta OLAP selecciona tuplas de la tabla de hechos restringidas por condiciones impuestas sobre los atributos de las dimensiones.
El interés de la consulta no está en las tuplas de la tabla de dimensión que cumplen la condición de la restricción sino en las tuplas de la tabla de hechos que se relacionan con ellas.
Ejemplo: En el contexto de una agencia inmobiliaria: “número de alquileres realizados en sábado” El interés no está en las tuplas (fechas) de la tabla TIEMPO con el valor Sábado en el atributo “día de la semana” sino en las tuplas de CONTRATOS con una de dichas fechas.
5. Sistemas ROLAP y MOLAP.
Data WareHouse
12-12-98 12-98 lunes 4-98 1998 no
10-6-97 6-97 miércoles 2-97 1997 si
10-1-99 1-99 sábado 1-99 1999 no
12-8-98 8-98 lunes 3-98 1998 si
1-6-97 6-97 sábado 2-97 1997 no
Tiempo
..... sábado domingo 0 0
0 1 1 0 0 0
1 0 …
Índice-día de la semana
10-1-99
1-6-99 Claves K
5. Sistemas ROLAP y MOLAP.
25/3/11
142
Data WareHouse
10-1-99
1-6-99
.......
10-1-99 cl23 p45 100000
.....
1-6-99 cl45 p89 50000
.....
10-1-99 cl78 p77 65000
Índice-Tiempo 10-1-99 [•, • ]
1-6-99 [• ]
Contratos
Claves K
RIDs
5. Sistemas ROLAP y MOLAP.
fecha cliente inmueble
Data WareHouse
sábado [•, •, • ]
Índice JOIN-día de la semana
.......
10-1-99 cl23 p45 100000
.....
1-6-99 cl45 p89 50000
.....
10-1-99 cl78 p77 65000
Contratos
Los índices de JOIN permiten evaluar consultas sobre esquemas en estrella sin realizar joins entre la tabla de dimensiones y la tabla de hechos.
5. Sistemas ROLAP y MOLAP.
25/3/11
143
Data WareHouse
Sistemas ROLAP.
Extensiones del SQL: operador CUBE.
SALES (Id_sale, maker, date, colour , ......, discount, employee, store, units, import)
SELECT maker, year(date), colour, SUM (units)
FROM Sales
GROUP BY CUBE (Maker, Year(date), Colour)
Calcula, sobre el resultado de la consulta, todas las agregaciones que pueden definirse sobre las tres dimensiones (parámetros) de la consulta (color, año, fabricante).
5. Sistemas ROLAP y MOLAP.
Data WareHouse
Extensiones del SQL: operador CUBE.
RED WHITE BLUE
By Color
By Make & Color
By Make & Year
By Color & Year
By Make By Year
Sum
The Data Cube and The Sub-Space Aggregates
RED WHITE BLUE
Chevy Ford
By Make
By Color
Sum
Cross Tab RED
WHITE BLUE
By Color
Sum
Group By (with total) Sum
Aggregate
Jim Gray Adam Bosworth Andrew Layman Microsoft
Hamid Pirahesh IBM
5. Sistemas ROLAP y MOLAP.
25/3/11
144
Data WareHouse
Extensiones del SQL: operador CUBE.
RED WHITE BLUE
By Color
By Make & Color
By Make & Year
By Color & Year
By Make By Year
Sum
The Data Cube and The Sub-Space Aggregates
RED WHITE BLUE
Chevy Ford
By Make
By Color
Sum
Cross Tab RED
WHITE BLUE
By Color
Sum
Group By (with total) Sum
Aggregate
Cada plano cartesiano representa la agregación sobre una dimensión
5. Sistemas ROLAP y MOLAP.
Data WareHouse
Extensiones del SQL: operador CUBE.
RED WHITE BLUE
By Color
By Make & Color
By Make & Year
By Color & Year
By Make By Year
Sum
The Data Cube and The Sub-Space Aggregates
RED WHITE BLUE
Chevy Ford
By Make
By Color
Sum
Cross Tab RED
WHITE BLUE
By Color
Sum
Group By (with total) Sum
Aggregate
Cada eje cartesiano representa la agregación sobre dos dimensiones
5. Sistemas ROLAP y MOLAP.
25/3/11
145
Data WareHouse
Extensiones del SQL: operador CUBE.
RED WHITE BLUE
By Color
By Make & Color
By Make & Year
By Color & Year
By Make By Year
Sum
The Data Cube and The Sub-Space Aggregates
RED WHITE BLUE
Chevy Ford
By Make
By Color
Sum
Cross Tab RED
WHITE BLUE
By Color
Sum
Group By (with total) Sum
Aggregate
El origen de los ejes representa la agregación sobre las tres dimensiones
5. Sistemas ROLAP y MOLAP.
Data WareHouse
Sistemas ROLAP. Extensiones del SQL: operador ROLLUP.
SALES (Id_sale, maker, date, colour , ......, discount, employee, store, units, import)
SELECT maker, year(date), colour, SUM (units)
FROM Sales
GROUP BY ROLLUP (Maker, Year(date), Colour)
Calcula sobre el resultado, agregaciones progresivas (de derecha a izquierda) sobre los atributos de agrupación de la consulta.
5. Sistemas ROLAP y MOLAP.
25/3/11
146
Data WareHouse
Extensiones del SQL: operador ROLLUP.
Maker Year Colour SUM (units)
Ford 1999 Red 30
Ford 1999 Blue 20
Ford 2000 Blue 15
Seat 1999 Blue 25
Seat 1999 Yellow 12
Sales (maker-year-colour) Maker Year Colour SUM (units)
Ford 1999 Red 30
Ford 1999 Blue 20
Ford 1999 ALL 50
Ford 2000 Blue 15
Ford 2000 ALL 15
Ford ALL ALL 65
Seat 1999 Blue 25
Seat 1999 Yellow 12
Seat 1999 ALL 37
Seat ALL ALL 37
ALL ALL ALL 102
5. Sistemas ROLAP y MOLAP.
Data WareHouse
Sistemas MOLAP. Sistema de propósito específico:
estructuras de datos (matrices multidimensionales)
técnicas de compactación.
El objetivo de los sistemas MOLAP es almacenar físicamente los datos en estructuras multidimensionales que favorezcan los tiempos de respuesta del sistema.
5. Sistemas ROLAP y MOLAP.
25/3/11
147
Data WareHouse
Herramienta OLAP
Herramienta OLAP
Servidor Relacional
Warehouse
MOLAP ROLAP
Clie
nte
Ser
vido
r Servidor Multidimensional
5. Sistemas ROLAP y MOLAP.
Data WareHouse
– Estructuras de datos matrices multidimensionales (arrays)
– Almacenamiento se pierde eficiencia con matrices muy
dispersas. (con celdas vacías) - Consultas
la memoria del computador no es multidimensional (es lineal): en el almacenamiento de matrices, siempre se favorecen unas dimensiones respecto a otras.
los tiempos de respuesta son buenos para las consultas previstas (favorecidas por el almacenamiento)
los tiempos de respuesta son malos para consultas no previstas.
5. Sistemas ROLAP y MOLAP.
Herramienta OLAP
Warehouse
MOLAP
Servidor Multidimensional
25/3/11
148
Data WareHouse
Herramienta OLAP
Herramienta OLAP
Servidor Relacional
Warehouse
HOLAP (MOLAP híbrido) ROLAP
Clie
nte
Ser
vido
r
Servidor Multidimensional
Servidor Relacional
5. Sistemas ROLAP y MOLAP.
Data WareHouse
Servidor Multidimensional
– El servidor multidimensional construye y almacena datos en estructuras multidimensionales.
– La herramienta de OLAP presenta estas estructuras multidimensionales al usuario.
Herramienta
OLAP
Estructuras multidimensionales
Warehouse SGBDR
5. Sistemas ROLAP y MOLAP. HOLAP (MOLAP híbrido)
25/3/11
149
Data WareHouse
– Datos • matrices multidimensionales
(arrays) • extraídos del almacén de datos
– Almacenamiento* y procesos eficientes**
– el análisis se suele hacer sobre datos agregados y métricas o indicadores precalculados.
* se pierde eficiencia con cubos de datos muy dispersos.
** la memoria no es multidimensional (es lineal): siempre se favorece una dimensión dependiendo del almacenamiento físico del cubo.
Servidor Multidimensional
Herramienta
OLAP
Estructuras multidimensionales
SGBDR
Warehouse
5. Sistemas ROLAP y MOLAP. HOLAP (MOLAP híbrido)
Data WareHouse
Inconvenientes de los sistemas HOLAP (multidimensional híbrido):
la construcción de las estructuras multidimensionales.
el coste de los cambios en la visión de los datos.
5. Sistemas ROLAP y MOLAP.
25/3/11
150
Data WareHouse
1. Introducción a los almacenes de datos: motivación definición y características.
2. Arquitectura de un sistema de almacén de datos.
3. Explotación de un almacén de datos: herramientas OLAP.
4. Diseño de un almacén de datos.
5. Sistemas ROLAP y MOLAP.
6. Mantenimiento de un almacén de datos.
Almacenes de datos (Data Warehouse)
Data WareHouse
6. Mantenimiento de un almacén de datos.
El sistema encargado del mantenimiento del almacén de datos es el Sistema E.T.L* (Extracción - Transformación - Load (carga))
– La construcción del Sistema E.T.L es responsabilidad del equipo de desarrollo del almacén de datos.
– El Sistema E.T.L es construido específicamente para cada almacén de datos.
– En la construcción del E.T.L se pueden utilizar herramientas del mercado o programas diseñados específicamente.
Funciones del Sistema E.T.L: – carga inicial. (initial load)
– mantenimiento periódico: inmediato, diario, semanal, mensual, ... (refreshment)
* E.T.T: Extracción – Transformación – Transporte (carga)
25/3/11
151
Data WareHouse
Fases del proceso de E.T.L: – Extracción
– Transformación y
– Transporte (Load)
E.T.L
6. Mantenimiento de un almacén de datos.
Data WareHouse
E.T.L.
Correspondencia
Bases de datos operacionales Almacenamiento
intermedio
Almacén de datos
Transformación
Extracción Transporte
6. Mantenimiento de un almacén de datos.
25/3/11
152
Data WareHouse
Tareas del proceso E.T.L – Lectura de datos operacionales – Identificación de los cambios – Limpieza y transformación de
datos – Integración de datos
Almacén de Datos
Programas
Herramientas
Sistemas Operacionales
– Creación de claves – Cálculo de agregaciones.
– Mantenimiento de metadata – Carga e indización.
– Pruebas de calidad.
E.T.L
6. Mantenimiento de un almacén de datos.
Data WareHouse
E.T.L. Correspondencia
Transformación
Extracción Transporte
Identificación de los datos que han cambiado
Extracción (lectura) de datos.
Obtención de agregados
Mantenimiento de metadata
Limpieza y transformación de datos
Integración de datos (cálculo de datos derivados)
Creación de claves
Obtención de agregados
Mantenimiento de metadata
Carga
Indización
Obtención de datos agregados.
Realización de pruebas de calidad de la carga.
Gestión de errores.
Mantenimiento de metadata
6. Mantenimiento de un almacén de datos.
25/3/11
153
Data WareHouse
¿Herramientas E.T.L.?
6. Mantenimiento de un almacén de datos.
Data WareHouse
Definir una estrategia de calidad: – actuación sobre los sistemas operacionales: modificar
las reglas de integridad, los disparadores y las aplicaciones de los sistemas operacionales.
– documentación de las fuentes de datos. – definición de un proceso de transformación. – nombramiento de un responsable de calidad del sistema
(Data Quality Manager)
La “calidad de los datos” es la clave del éxito de un almacén de datos.
6. Mantenimiento de un almacén de datos.
25/3/11
154
Data WareHouse
Correspondencia.
Correspondencia
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos
6. Mantenimiento de un almacén de datos.
Data WareHouse
Correspondencia – definir la ley de derivación de los datos del almacén a partir de
los datos de las fuentes operacionales. • decidir las transformaciones que se van a aplicar a los
datos (extraídos) de los sistemas operacionales. • decidir las operaciones o cálculos que se deben aplicar a
los datos operacionales (regla de derivación).
File A F1 123 F2 Bloggs F3 10/12/56
Clientes Número USA123 Nombre Mr. Bloggs Fecha 10-Dec-56
Metadata File A Clientes F1 Número F2 Nombre F3 Fecha
6. Mantenimiento de un almacén de datos.
25/3/11
155
Data WareHouse
Fase de Extracción.
– Programas diseñados para extraer los datos de las fuentes. – Herramientas: data migration tools, wrappers, ...
Correspondencia
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos
Extracción
6. Mantenimiento de un almacén de datos.
Data WareHouse
Ejecución de la extracción: a) si los datos operacionales están mantenidos en un SGBDR, la extracción de datos se puede reducir a consultas en SQL o rutinas programadas.
b) si los datos operacionales están en un sistema propietario (no se conoce el formato de los datos), la extracción puede ser muy difícil y puede tener que realizarse a partir de informes o volcados de datos proporcionados por los propietarios que deberán ser procesados posteriormente.
Extracción: lectura de datos del sistema operacional.
a) durante la carga inicial .
b) mantenimiento del AD
6. Mantenimiento de un almacén de datos.
25/3/11
156
Data WareHouse
Identificación de Cambios. – Identificar los datos operacionales (relevantes) que han sufrido
una modificación desde la fecha del último mantenimiento. – Métodos
• Carga total. • Comparación de instancias de la base de datos operacional. • Uso de marcas de tiempo (time stamping) en los registros del
sistema operacional. • Uso de disparadores en el sistema operacional. • Uso del fichero de log (gestión de transacciones) del sistema
operacional. • Uso de técnicas mixtas.
Extracción: en el mantenimiento del AD, antes de realizar la extracción es preciso identificar los cambios.
6. Mantenimiento de un almacén de datos.
Data WareHouse
– Similar a hacer en cada mantenimiento (frecuencia establecida), una carga inicial.
– Estrategia cara y costosa. – El análisis de datos históricos está limitado a los datos cargados en
cada ciclo (disponibles en el sistema operacional). – Adecuado para data marts. – Es recomendable usar una estrategia de copias (mirrors) del AD para
evitar que el AD este desactivado durante el mantenimiento.
Identificación de cambios: carga total.
Base de datos operacional
Carga actual
Carga siguiente
Extracción
Extracción
6. Mantenimiento de un almacén de datos.
25/3/11
157
Data WareHouse
Comparación
Base de datos (t1)
Ficheros (Delta) con los registros modificados
– Método simple, pero caro. – Ficheros (Delta)
• Cambios que han tenido lugar en la base de datos operacional desde la fecha del último mantenimiento.
• Para poder hacer la comparación debe conservarse en el sistema operacional una copia de los datos en la fecha del último mantenimiento.
Identificación de cambios: comparación de instancias.
Base de datos (t2)
6. Mantenimiento de un almacén de datos.
Data WareHouse
– Búsqueda rápida de los registros modificados desde el último mantenimiento.
– Deben existir marcas de tiempo en la base de datos operacional: cambiar aplicaciones o utilizar disparadores.
– ¡Atención con los borrados!
Identificación de cambios: uso de marcas de tiempo.
Base de datos operacional
Ficheros (Delta) con los registros modificados
6. Mantenimiento de un almacén de datos.
25/3/11
158
Data WareHouse
– Los cambios son capturados durante el funcionamiento del sistema operacional
– Sobrecarga del sistema operacional. – La acción de los disparadores actualiza el fichero (Delta) con los
registros modificados.
SGBDR
Disparadores en BD operacional
Trigger
Trigger
Trigger
Identificación de cambios: uso de disparadores.
Base de datos operacional
Ficheros (Delta) con los registros modificados
6. Mantenimiento de un almacén de datos.
Data WareHouse
Identificación de cambios: uso de ficheros de log.
Fichero de log
Análisis del fichero de log y extracción
SGBDR (módulo de
recuperación) Base de datos
operacional Ficheros (Delta) con los registros modificados
— Si el sistema operacional dispone de un sistema de gestión de transacciones con fichero de log (diario): un programa (bastante complejo) debe procesar el contenido de los ficheros de log para determinar los cambios producidos en la BD desde el último mantenimiento (simulando al propio módulo de recuperación del sistema transaccional).
(Esta estrategia tiene sentido si en el AD se almacena información a nivel transaccional).
6. Mantenimiento de un almacén de datos.
25/3/11
159
Data WareHouse
Fase de transformación.
Limpieza Transformación de datos Integración
Correspondencia
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos
Transformación
6. Mantenimiento de un almacén de datos.
Data WareHouse
En los datos operacionales existen errores debidos a: – desarrollos independientes a lo largo del tiempo, – fuentes heterogéneas de datos, – problemas en la fase de extracción, ...
12M65431
12-m-65421
“12m65421”
“12m65421”
“ ”
12M65431
12M65431
12-m-65421
“12m65421”
“12m65421”
“ ”
12M65431
12
12
12
M
m
m
65431
65421
65421
12
12
M
M
65431
65421
6. Mantenimiento de un almacén de datos.
Registros de las fuentes
Eliminación de duplicados y de
registros con datos faltantes
Unificación de codificación
12M65431
12-m-65421
“12m65421”
Transformación de formato
12
12
12
M
M
M
65431
65421
65421
Eliminación de duplicados
Fase de transformación.
25/3/11
160
Data WareHouse
Limpieza: - eliminar datos irrelevantes, - eliminar datos duplicados, - detectar y corregir o eliminar datos erróneos, - detectar y tratar valores anómalos (outliers values), - detectar y tratar valores faltantes (missing values), ...
Correspondencia
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos
Transformación
6. Mantenimiento de un almacén de datos. Fase de transformación.
Data WareHouse
Valores duplicados: deben ser eliminados. • SQL • restricciones de integridad
ACME Inc
ACME Inc
ACME Inc ACME Inc
6. Mantenimiento de un almacén de datos.
Limpieza
Fase de transformación.
25/3/11
161
Data WareHouse
– Detección de valores nulos (missing values): se deben detectar los valores nulos y analizar su causa (error en la extracción, desconocimiento de la información, ...)
– Tratamiento de valores nulos: los valores nulos son válidos si están permitidos en el AD (son significativos), sino son equivalentes a valores desconocidos.
– Tratamiento de valores desconocidos: • ignorar los registros. • congelar la extracción de los registros hasta que se puedan obtener los
datos desconocidos.
6. Mantenimiento de un almacén de datos.
Limpieza Fase de transformación.
Data WareHouse
– Detección de datos anómalos (outliers values): valores que no se ajustan al comportamiento general de los datos.
– Tratamiento de valores anómalos: analizar si son errores o excepciones los valores erróneos deben ser eliminados las excepciones pueden interesar para algunos estudios: uso
fraudulento de tarjetas, predicción de innundaciones, ...
6. Mantenimiento de un almacén de datos.
Limpieza Fase de transformación.
25/3/11
162
Data WareHouse
Fase de transformación.
– Detección y tratamiento de datos erróneos: la integridad referencial debe reconstruirse.
Departamento 10 20 30 40
6. Mantenimiento de un almacén de datos.
Limpieza.
Data WareHouse
Transformación de datos: - discretización, - numerización, - codificación, - unificación, - estandarización, ...
Correspondencia
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos
Transformación
6. Mantenimiento de un almacén de datos. Fase de transformación.
25/3/11
163
Data WareHouse
– Claves con estructura: descomponer en valores atómicos
código del país
zona de ventas
número de producto
código de vendedor
Código de producto = 12M65431345
6. Mantenimiento de un almacén de datos.
Transformación de datos
Fase de transformación.
Data WareHouse
– Discretizar datos: transformar valores continuos en valores discretos o nominales.
(Deben detectarse los valores erróneos).
pequeño
0-3
0
6. Mantenimiento de un almacén de datos. Fase de transformación.
mediano grande
4-7 8-10
3 4 7 8 10 ... ... ...
Transformación de datos
25/3/11
164
Data WareHouse
– Numerizar datos: transformar valores nominales en valores numéricos (enteros).
6. Mantenimiento de un almacén de datos. Fase de transformación.
administrativo
revisor
1
conductor
mecánico
controlador
...
2
3
4
5
...
Transformación de datos
Data WareHouse
– Unificación: unificar codificaciones
(Deben detectarse los valores erróneos).
v , h
1 , 0
varón, hembra
v, h
6. Mantenimiento de un almacén de datos. Fase de transformación. Transformación de datos
25/3/11
165
Data WareHouse
Fase de transformación.
– Unificación: unidades de medida, unidades de tiempo, unidades de moneda,...
cm
inches cm
DD/MM/YY
MM/DD/YY DD-Mon-YY
1,000 GBP
FF 9,990 USD 600
6. Mantenimiento de un almacén de datos.
Transformación de datos
Data WareHouse
– Unificación: formato de los datos.
ASCII EBCDIC
12373 “123-73”
ACME Co.
áøåëéí äáàéí Beer (Pack of 8)
6. Mantenimiento de un almacén de datos.
Fase de transformación. Transformación de datos
25/3/11
166
Data WareHouse
Fase de transformación.
- Integración: aplicar las leyes de derivación para calcular los datos derivados.
Correspondencia
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos
Transformación
6. Mantenimiento de un almacén de datos.
Data WareHouse
Transformación. Creación de claves.
#1 Venta 1/2/98 12:00:01 Ham Pizza $10.00
#2 Venta 1/2/98 12:00:02 Cheese Pizza $15.00
#3 Venta 1/2/98 12:00:02 Anchovy Pizza $12.00
#5 Venta 1/2/98 12:00:04 Sausage Pizza $11.00
#4 Devolución 1/2/98 12:00:03 Anchovy Pizza - $12.00
#dw1 Venta 1/2/98 12:00:01 Ham Pizza $10.00
#dw2 Venta 1/2/98 12:00:02 Cheese Pizza $15.00
#dw3 Venta 1/2/98 12:00:04 Sausage Pizza $11.00
Claves sin significado
6. Mantenimiento de un almacén de datos.
25/3/11
167
Data WareHouse
Fase de transformación.
– Integración de datos de distintas fuentes:
Bases de datos operacionales
SELECT PROJECT JOIN GROUP, ....
Almacenamiento intermedio
6. Mantenimiento de un almacén de datos.
Data WareHouse
Fase de transformación.
– Integración de datos de distintas fuentes. – Cálculo de nuevos datos
Bases de datos operacionales
Cálculo de nuevos datos: • Datos agregados • Datos calculados
Almacenamiento intermedio
6. Mantenimiento de un almacén de datos.
Integración de datos: SELECT PROJECT JOIN GROUP, ....
25/3/11
168
Data WareHouse
Fase de transporte. Correspondencia
Transporte
Bases de datos operacionales
Almacenamiento intermedio
Almacén de datos Transporte
Cuando la Transformación se realiza en el sistema operacional o en el AD.
6. Mantenimiento de un almacén de datos.
Data WareHouse
Fase de transporte. (carga) – La fase de transporte consiste en mover los datos desde las
fuentes operacionales o el almacenamiento intermedio hasta el almacén de datos y cargar los datos en las correspondientes estructuras de datos.
– La carga puede consumir mucho tiempo – En la carga inicial del AD se mueven grandes volúmenes de
datos. – En los mantenimientos periódicos del AD se mueven pequeños
volúmenes de datos. – La frecuencia del mantenimiento periódico está determinada
por el gránulo del AD y los requisitos de los usuarios.
6. Mantenimiento de un almacén de datos.
25/3/11
169
Data WareHouse
Fase de transporte. Creación y mantenimiento de un AD.
– Crear el AD (base de datos) – En intervalos de tiempo fijos añadir cambios al AD – Ocasionalmente archivar o eliminar datos obsoletos que ya
no interesan para el análisis.
T1 T2 T3
Base de datos operacional
6. Mantenimiento de un almacén de datos.
Data WareHouse
Fase de transporte. Carga inicial. – Carga del AD con información histórica. – Afecta a grandes volúmenes de datos.(3 años, 5 años, ...) – Significa la realización de distintas tareas del E.T.L – Significa la realización de numerosas operaciones después
de la carga. (indización, cálculo de agregados, ...)
T1 T2 T3
Base de datos operacional
6. Mantenimiento de un almacén de datos.
25/3/11
170
Data WareHouse
Fase de transporte. Mantenimiento periódico. – Se realiza de acuerdo a un ciclo previamente definido.
(semanal, mensual,..) – Implica tareas de E.T.L más sencillas. – Afecta a un volumen de datos menor.(tabla de hechos y
excepcionalmente tablas de dimensiones). – Implica un menor número de operaciones posteriores a la
carga.
T1 T2 T3
Base de datos operacional
6. Mantenimiento de un almacén de datos.
Data WareHouse
Fase de transporte. Mantenimiento periódico. (factores relevantes)
– Horario en el que el AD está disponible para el mantenimiento (load window).
– Volumen de datos. – Frecuencia (ciclo). – Infraestructura técnica.
T1 T2 T3
Base de datos operacional
6. Mantenimiento de un almacén de datos.
25/3/11
171
Data WareHouse
Load Window: tiempo disponible para el transporte y los procesos posteriores.
determinar primero los requisitos de acceso de los usuarios.
Acceso de usuarios Load Window Load Window
6. Mantenimiento de un almacén de datos.
Data WareHouse
Procesos posteriores a la carga. Browser: http://
Browser: http:// Browser: http://
Exracción
Transformación
Transporte
Procesos posteriores a la carga
Agregados
Indización
6. Mantenimiento de un almacén de datos.
25/3/11
172
Data WareHouse
Procesos posteriores a la carga: indización. – Durante la carga:
carga con el índice habilitado proceso tupla a tupla. (lento)
– Después de la carga: carga con el índice deshabilitado creación del índice (total o parcial). (rápido)
Index
Almacén de datos
Base de datos operacional
6. Mantenimiento de un almacén de datos.
Data WareHouse
Procesos posteriores a la carga: obtención de agregados.
– Durante la extracción. – Después de la carga (transporte).
Base de datos operacional
Almacenamiento intermedio Almacén de
datos
Transporte Extracción
6. Mantenimiento de un almacén de datos.
25/3/11
173
Data WareHouse
Ejemplo: diseño de un almacén de datos para una empresa que se dedica al alquiler de inmuebles y locales.
Data WareHouse
Descripción de la organización: la empresa trabaja a través de oficinas repartidas por la geografía nacional.
cada oficina dispone de una base de datos para su gestión.
las bases de datos almacenan información actual e histórica.
existen tres actividades básicas que realiza cada oficina: inspección de inmuebles, visitas a los inmuebles con los clientes y realización de contratos de alquiler.
Ejemplo
25/3/11
174
Data WareHouse
Notas: Un inmueble o local puede ser inspeccionado varias veces al día por el mismo o distintos empleados.
Un inmueble o local puede ser mostrado a un cliente varias veces al día, por el mismo o distintos empleados.
Un inmueble o local no se puede alquilar mas de una vez al día al mismo cliente.
Un cliente puede estar dado de alta en varias oficinas.
Un inmueble o local puede estar dado de alta en varias oficinas.
Ejemplo
Data WareHouse
Diseño físico
Diseño lógico específico
Implementación
Diseño conceptual
Recogida y análisis de requisitos Análisis
Descripción del sistema de información de la organización
Requisitos de usuario
Esquema
Entidad-Relación
Ejemplo
25/3/11
175
Data WareHouse
Revisa N Inspección 1
Es revisado
N
1
nro
fecha valor
Inmueble
Propietario
Es dueño
1
N
dni nombre
tipo ciudad direc
nro_prop
tipo direc ciudad
precio fecha_alta
fecha_baja
Es visitado
Cita
nro_cita Visita N
N
1
fecha Enseña
1
N
valor
1
Empleado
nro_emp nombre dni
1 Es alquilado Alquila N N
Contrato
nro_contrato fecha_inicio
precio fecha_fin 1
Cliente
ciudad
dni nombre
fecha_alta
tipo
direc
fecha_baja
nro_cliente
fecha
Data WareHouse
nro_contrato ° nro_cliente ° nro_prop ° fecha ° fecha_inicio ° fecha_fin ° mensualidad
nro_prop ° fecha_alta ° fecha_baja ° direc ° ciudad ° precio ° tipo ° propietario
nro_cliente ° dni ° nombre ° fecha_alta ° fecha_baja ° tipo ° direc ° ciudad_cliente
dni ° direc ° ciudad_prop ° nombre ° tipo
nro_cita ° nro_emp ° nro_prop ° nro_cliente ° fecha ° valor
nro_emp ° nombre ° dni
Contratos
Clientes
Inmuebles
Visitas
Propietario nro ° nro_emp ° nro_prop ° fecha ° valor
Inspecciones
Empleados
Base de Datos (relacional) de cada oficina
Ejemplo
25/3/11
176
Data WareHouse
Si se quiere integrar toda la información de la organización (oficinas), hace falta incluir la entidad OFICINA, con sus propiedades y relaciones con otras entidades.
Ejemplo
Data WareHouse
Revisa N Inspección 1
Es revisado
N
1
nro
fecha valor
Oficina
nro_oficina
direc
ciudad Oferta N
N Inmueble
Propietario
Es dueño
1
N
dni nombre
tipo ciudad direc
nro_prop
tipo direc ciudad
precio fecha_alta
fecha_baja
Es visitado
Cita
nro_cita Visita N
N
1
fecha Enseña
1
N
valor
1
1
Asignado N Empleado
nro_emp nombre dni
1 Es alquilado Alquila N N
Contrato
nro_contrato fecha_inicio
precio fecha_fin 1
Cliente
N
Pertenece
N
ciudad
dni nombre
fecha_alta
tipo
direc
fecha_baja
nro_cliente Hace
N
1
fecha_
25/3/11
177
Data WareHouse
Revisa N Inspección 1
Es revisado
N
1
nro
fecha valor
Oficina
nro_oficina
direc
ciudad Oferta N N Inmueble
Propietario
Es dueño
1
N
dni nombre
tipo ciudad direc
nro_prop
tipo direc ciudad
precio fecha_alta
fecha_baja
Es visitado
Cita
nro_cita Visita N
N
1
fecha Enseña
1
N
valor
1
1
Asignado N Empleado
nro_emp nombre dni
1 Es alquilado Alquila N N
Contrato
nro_contrato fecha_inicio
precio fecha_fin 1
Cliente
N
Pertenece
N
ciudad
dni nombre
fecha_alta
tipo
direc
fecha_baja
nro_cliente Hace
N
1
fecha_
Data WareHouse
Requisitos de los usuarios: Inspecciones: No interesa analizar la actividad de inspecciones.
Contratos: Interesa analizar los contratos realizados por fecha, inmueble (ciudad y tipo del inmueble), oficina (ciudad de la oficina) que hace el contrato y cliente (tipo de cliente).
Visitas: Interesa analizar las visitas realizadas por fecha, inmueble (ciudad del inmueble), cliente (tipo de cliente), y oficina (ciudad de la oficina) que realiza la visita.
Ejemplo
25/3/11
178
Data WareHouse
Ejemplos de consultas para el AD:
a) sobre los clientes
- el número de clientes que se han registrado el último mes en cada oficina comparados con los del mismo mes de los dos últimos años.
- el número previsible de clientes que se registrará en cada ciudad durante el próximo año basándose en el índice de crecimiento de los últimos cinco años.
b) sobre los contratos
- para cada oficina, la media en los últimos seis meses del número de inmuebles alquilados mensualmente con un precio mensual mayor que 100.000 ptas.
- el número total de inmuebles visitados clasificados por tipos, para cada mes de 1997.
Ejemplo
Data WareHouse
Diseño físico
Diseño lógico refinado
Implementación
Diseño conceptual
Recogida y análisis de requisitos Diseño
Modelado multidimensional (MR)
Esquemas
estrella
Ejemplo
25/3/11
179
Data WareHouse
El almacén de datos debe ser diseñado para responder a preguntas (no previstas) relativas a las actividades básicas de la organización analizadas desde distintos puntos de vista:
visitas de clientes a los inmuebles ofertados
realización de contratos de alquiler sobre los inmuebles
Para cada actividad básica (visitas, contratos) existe en la base de datos operacional una información básica objeto de análisis (fecha y valoración de la cita, fecha y precio del contrato) y unas dimensiones respecto a las cuales interesa realizar el análisis (características de los inmuebles, de los clientes y de las oficinas).
Ejemplo
Data WareHouse
a) para cada actividad de la organización que es objeto de análisis (visitas, contratos) se diseñará un esquema en estrella o en copo de nieve :
definir la tabla de hechos con la información relevante (medidas) sobre la actividad a analizar.
definir las tablas de dimensiones con las propiedades relevantes de cada una de las dimensiones (atributos) que caracterizan la actividad
establecer las correspondientes claves ajenas
b) integrar las vistas parciales en un único esquema: esquema del almacén de datos
c) traducir a un esquema ROLAP o MOLAP según la tecnología disponible.
d) realizar el diseño físico
Diseño: Ejemplo
25/3/11
180
Data WareHouse
Cliente Alquila N Contrato 1 N
nro_contrato
Es alquilado Inmueble 1
fecha_inicio
id_cliente id_prop Id_fecha id_oficina fecha_inicio fecha_fin mensualidad
id_prop nro_prop ciudad_inmueble tipo_inmueble
id_cliente nro_cliente dni tipo_cliente ciudad_cliente
precio
esquema estrella para el análisis de contratos
fecha_fin Oficina Hace 1 N
id_oficina nro_oficina ciudad_oficina
Ejemplo
id_fecha
….
fecha_
Data WareHouse
Cliente Visita N
Cita
1
N
nro_cita
Es visitado Inmueble 1
fecha
id_cliente id_prop id_oficina Id_fecha nro _ visitas
id_prop nro_prop ciudad_inmueble tipo_inmueble
id_cliente nro_cliente dni tipo_cliente ciudad_cliente
Empleado Enseña N 1
id_oficina nro_oficina ciudad_oficina
valor
esquema estrella para el análisis de visitas
1
Asignado
N
Oficina
Ejemplo
id_fecha
….
25/3/11
181
Data WareHouse
Si se desea incluir información sobre el propietario del inmueble :esquema copo de nieve para el análisis de contratos
id_propietario dni ciudad_propietario tipo_propietario
id_cliente id_prop Id_fecha id_oficina fecha_inicio fecha_fin mensualidad
id_prop nro_prop ciudad_inmueble tipo_inmueble id_propietario
id_cliente nro_cliente dni tipo_cliente ciudad_cliente
id_oficina nro_oficina ciudad_oficina
Ejemplo
id_fecha
….
Data WareHouse
Decisiones de diseño del almacén de datos:
se han ignorado la información sobre algunas actividades (inspecciones).
se ha eliminado alguna información (empleado, nombre de cliente, fecha de alta de un inmueble, etc) que no es relevante para el análisis.
se han creado nuevas entidades de información (oficina).
se ha decidido mantener el mismo nivel de detalle (granularidad) que en la base de datos operacional para la actividad de contratos.
se ha decidido registrar la información relativa a visitas con una granularidad mayor que en el operacional (no se considera relevante la información sobre el empleado que hace la visita sino sobre las visitas realizadas por la oficina).
Ejemplo
25/3/11
182
Data WareHouse
cita
propiedad
cliente
oficina
esquema del almacén de datos
contratos
integración de las vistas Ejemplo
tiempo
Data WareHouse
id_cliente id_prop id_fecha ° id_oficina ° fecha_inicio ° fecha_fin ° mensualidad
id_prop ° nro_prop ° ciudad_inmueble ° tipo_inmueble
id_cliente ° nro_cliente ° dni ° tipo_cliente ° ciudad_cliente
id_oficina id_prop id_cliente Id_fecha ° nro_visitas
Contratos
Clientes
Inmuebles
Visitas
id_oficina
° nro_oficina
° ciudad_oficina
Oficinas
Base de Datos (relacional) del Almacén de Datos
(ROLAP)
Ejemplo
id_fecha
….
Tiempo
25/3/11
183
Data WareHouse
Orientaciones de diseño: desnormalizar ¡ si las consultas sobre contratos están restringidas por atributos relativos a su propietario!
id_propietario dni ciudad_propietario tipo_propietario
id_cliente id_prop Id_fecha id_oficina fecha_inicio fecha_fin mensualidad
id_prop nro_prop ciudad_inmueble tipo_inmueble id_propietario
id_cliente nro_cliente dni tipo_cliente ciudad_cliente
id_oficina nro_ofocina ciudad_oficina
Si se desea incluir información sobre el propietario del inmueble :esquema copo de nieve para el análisis de contratos
Ejemplo
id_fecha
….
Data WareHouse
Orientaciones de diseño: desnormalizar
¡ las jerarquías entre dimensiones se desnormalizan !
3FN
esquema en estrella esquema en copo de nieve
id_cliente id_prop fecha_inicio id_oficina id_fecha fecha_inicio fecha_fin mensualidad
id_prop nro_prop ciudad_inmueble tipo_inmueble dni ciudad_propietario tipo_propietario
id_cliente nro_cliente dni tipo_cliente ciudad_cliente
id_oficina nro_oficina ciudad_oficina
Ejemplo
id_fecha
….