data warehouse

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.


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



3. Explotación de un Almacén de Datos: herramientas OLAP.




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))‏


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).


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:


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


Data WareHouse



3. Explotación de un Almacén de Datos: herramientas OLAP.




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.


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


Data WareHouse

importe

unidades

La actividad de ventas se registra a nivel diario para cada producto y cada almacén


Almacén

3. Explotación de un almacén de datos: herramientas OLAP


25/3/11

18

Data WareHouse

importe

unidades

Tiempo (día)‏

Almacén

Producto

“Importe total de ventas por almacén y producto”

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


25/3/11

19

Data WareHouse

Presentaciones del esquema multidimensional en una herramienta OLAP:

- representación en estrella

- representación en cubo de datos


Data WareHouse

importe

unidades

Dimensiones que caracterizan la actividad.


Almacén


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)‏


Data WareHouse

importe

unidades

Para enriquecer el análisis las dimensiones se completan con atributos descriptores.


Almacén

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


Dimensiones con atributos descriptores.

Pro

duct

o

Tiem

po

Alm

acén

Trimestre


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).


25/3/11

22

Data WareHouse

importe

unidades

Alm

acén

Nombre

Ciudad

Región

Tipo

Pro

duct

o


Categoría

Marca

Tipo

Descripción

hecho

medidas

Tiem

po

Día Mes

Día de la semana

Año Trimestre


Nro_almacén dimensión

atributos

Data WareHouse

importe

unidades

Alm

acén

Nro_almacén

Ciudad

Región

Tipo

Pro

duct

o


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


Nombre

25/3/11

23

Data WareHouse

importe

unidades

Alm

acén

Nro_almacén

Ciudad

Región

Tipo

Pro

duct

o


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


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


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


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


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


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).


25/3/11

26

Data WareHouse

Pro

duct

o

Tiem

po

Alm

acén

importe

unidades


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


Nombre

Data WareHouse

info

rme

Importe de ventas

SELECT ...........

departamento región año importe

OLAP

año

región departamento


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


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


25/3/11

28

Data WareHouse

“2002”

“Bebidas” P

rodu

cto

Tiem

po

Alm

acén

importe

unidades


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


Nombre

Data WareHouse

SELECT ...........

trimestre categoría importe

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


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


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.


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


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.


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


Data WareHouse

“2002”

“Bebidas”

Pro

duct

o

Tiem

po

Alm

acén

importe

unidades


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


Nombre

25/3/11

33

Data WareHouse


OLAP

¡ la operación de DRILL se realiza sobre el informe original !


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


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).


25/3/11

34

Data WareHouse

drill-down

SELECT P.categoría, T.mes, SUM (V.importe)






GROUP BY T.mes, P.categoría

medida


agrupación por Tiempo y Producto

tabla de hechos


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.


25/3/11

35

Data WareHouse

“2002”

“Bebidas” P

rodu

cto

Tiem

po

Alm

acén

importe

unidades


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


Nombre

Data WareHouse


OLAP

¡ la operación de DRILL se realiza sobre el informe original !


25/3/11

36

Data WareHouse

Categoría Trimestre Ventas Ciudad

T2

T1

300000

T2 700000

Refrescos T1

Valencia

drill

-acr

oss


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.


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



V.nro_almacén=A.nro_almacén AND



GROUP BY T.trimestre, P.categoría, A.ciudad

medida


agrupación por Tiempo, Producto y Almacén

tabla de hechos


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.


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?.


25/3/11

38

Data WareHouse

“2002”

“Bebidas” P

rodu

cto

Tiem

po

Alm

acén

importe

unidades


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


Nombre

Data WareHouse

OLAP


¡ la operación de ROLL se realiza sobre el informe original !


25/3/11

39

Data WareHouse

Categoría Ventas

Refrescos 8000000

Zumos 12900000

roll-

acro

ss


T4

T2

T3

T1

T3

2000000

3000000

1500000

2400000

8000000

T1 1000000

T4

T2 1000000

Refrescos

Refrescos

Refrescos

Refrescos

Zumos

Zumos

Zumos

Zumos

2000000


Data WareHouse

SELECT P.categoría, T.trimestre, SUM (V.importe)






GROUP BY T.trimestre, P.categoría

medida


agregación sobre Almacén y Tiempo

agrupación por Producto

tabla de hechos

roll-across


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.


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


25/3/11

41

Data WareHouse

Ventas


Q1

5,2 1,9 2,3 1,1


Q2

8,9 0,75 4,6 1,5


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


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


Q1

5,2 1,9 2,3 1,1


Q2

8,9 0,75 4,6 1,5


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


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.


Data WareHouse







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).


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, ...)‏


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


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:


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


Implementación de transacciones

Implementación

Creación BD


Esquema conceptual

Inde

pend

ient

e

del S

GB

D

Dinámica Estática Diseño conceptual


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


Requisitos de consulta

Metodología de diseño de almacenes de datos:

Mod

elad

o m

ultid

imen

sion

al

ER, UML, ...


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

…


25/3/11

47

Data WareHouse

Diseño físico


Implementación

Diseño conceptual


Diseño conceptual

Modelado multidimensional

Esquemas multidimensionales

(ER, UML, ..)‏


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.


25/3/11

48

Data WareHouse

Modelado multidimensional con ER.


Producto

N

Ventas

1

N

Tiempo

1

unidades

Almacén

N

1

importe

Data WareHouse

Modelado multidimensional con ER.


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.


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.


Hecho

medida1 medida2

...

* *

*

1 1

1

D1 D2

D3 Dn

* 1

Data WareHouse



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..*


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




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




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...)‏


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


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


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


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


Niveli id_nivel

...

Niveli+1

id_nivel

... ..*

no-estricta


Coñac

Vino

Servilletas

Pañuelos

Bebidas

Papel

Droguería

25/3/11

56

Data WareHouse


Niveli id_nivel

...

Niveli+1

id_nivel

... 0 ..

no-balanceada


Coñac

Vino

Servilletas

Pañuelos

Bebidas

Papel

Varios

Data WareHouse

Esquemas multidimensionales que comparten una dimensión a distinto nivel.


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


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


25/3/11

58

Data WareHouse

Diseño físico Esquema interno


Esquema lógico (ROLAP, MOLAP)‏

Implementación Creación del AD

Esquema relacional multidimensional

Diseño conceptual


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


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


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 !


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


CAj CAj



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


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.


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. ....


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


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


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, ....


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.


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


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)‏


25/3/11

65

Data WareHouse

id_dim1

....

tabla Dimensión 1


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.


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,..).


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


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


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)‏


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


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


definición de gránulo

dimensiones básicas

D1

D2

Dn

id_dim1

id_dim2

id_dim3

...

id_dimn

(medidas)‏



tabla Dimensión 2

tabla Dimensión n

...

Los identificadores de las dimensiones (básicas) identifican la tabla de hechos

Data WareHouse


id_dim1

id_dim2

id_dim3

...

id_dimn

(medidas)‏



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


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


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).


Data WareHouse


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.


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


Data WareHouse

Diseño físico


Implementación

Diseño conceptual


Diseño lógico

traducción del esquema conceptual multidimensional

(ER, UML, MR, ..)‏

Esquema relacional (ROLAP)‏

Esquema multidimensional (MOLAP)‏


25/3/11

73

Data WareHouse

Diseño físico


Implementación

Diseño conceptual


Met

odol

ogía

de

Kim

ball

traducción directa

esquema relacional (ROLAP)‏


(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


Implementación

Diseño conceptual


Mod

elad

o m

ultid

imen

sion

al

traducción

esquema relacional (ROLAP)‏


(ER, UML, OO, ...)‏ esquema conceptual multidimensional (ER, UML, OO, ..)‏

25/3/11

74

Data WareHouse



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


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


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


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


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.


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?


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”.


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


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


25/3/11

79

Data WareHouse


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)‏


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).


Data WareHouse


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


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



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



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



Dimensión Producto moderadamente normalizada

25/3/11

83

Data WareHouse

Diseño físico


Implementación

Diseño conceptual


Diseño físico

consideraciones de almacenamiento físico

Esquema físico en el SGBD disponible


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, ...).


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.


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.


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)


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


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


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


.......

12 3 165000

.....

12 21 50000

.....

Informe

4. Agrupar las filas y agregar las medidas.

Data WareHouse


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.


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.


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.


Data WareHouse

Estimación del tamaño del AD:


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


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.


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.


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.


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.





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.





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


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


Data WareHouse

Consideraciones en el diseño de almacenes de datos. Otras consideraciones:

dimensiones “que cambian”

definición de agregados


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


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.


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


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


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


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.


Data WareHouse


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.


25/3/11

98

Data WareHouse


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.


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.


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.


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.


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”.


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.



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).



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



* 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.


Data WareHouse

id_cliente

id_fecha

id_clinica

id_factura

importe


1 1

1

N

N

N

Tiempo

Clínica


1

N Factura

dimensión degenerada



25/3/11

103

Data WareHouse

id_cliente

id_fecha

id_clinica

Id_factura

importe


1 1

1

N

N

N

Tiempo

Clínica


1 N Factura

dimensión degenerada



Data WareHouse

id_cliente

id_fecha

id_clinica

id_factura

importe


1 1

1

N

N

N

Tiempo

Clínica


1 N Factura dimensión

degenerada



25/3/11

104

Data WareHouse

Diseño de dimensiones: dimensiones no-completas.


Dimensión no-completa: dimensión que tiene una jerarquía no completa

Categoría

nombre

...

Departamento

nombre

... 0..

no-completa


Coñac

Vino

Servilletas

Pañuelos

Bisutería

Bebidas

Papel

Data WareHouse




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



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



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


Bebidas 150

Papel 400

Varios 67

Total ingresos: 1220

El total (1220) es correcto


Definir un departamento Varios para convertir la jerarquía no-completa en completa.

1 p23 Magno Coñac Bebidas



4 p4 Klenex Pañuelo Papel

6 p14 Loewe Bisutería Varios


25/3/11

106

Data WareHouse

Diseño de dimensiones: dimensiones no-estrictas.


Categoría

nombre

...

Departamento

nombre

... ..*

no-estricta


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




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



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



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


Bebidas 150

Papel 467

Droguería 67

Total ingresos: 684






4 p4 Klenex Pañuelo Papel, Droguería


25/3/11

108

Data WareHouse



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


No se puede agrupar por departamento, ya que la jerarquía no es estricta por debajo de departamento.




4 p4 Klenex Pañuelo Papel, Droguería


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


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!


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).


25/3/11

110

Data WareHouse


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.


....

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


Data WareHouse


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)‏


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!


Data WareHouse


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


25/3/11

112

Data WareHouse


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


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 Dimensión 2

tabla Dimensión n

1 1

1

1

N

N

N

N


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 Dimensión 2

tabla Dimensión n

1 1

1

1

N

N

N

N



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, …)‏



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.



id_cliente

id_fecha

id_clinica

id_diag

importe

Facturas Cliente

1 1

1 N

N

N

N

N

Tiempo


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


Informe de ingresos por tipo de diagnóstico.



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





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



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


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


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



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


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



Data WareHouse

id_cliente

id_fecha

id_clinica

id_diag

importe

Facturas Cliente

1 1

1 N

N

N

N

N

Tiempo



Solución 2



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


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



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



id_cliente

id_fecha

id_clinica

id_diag

importe

Facturas Cliente

1 1

1 1

N

N

N

N

Tiempo


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


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



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.


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


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


Data WareHouse

id_cliente

id_fecha

id_clinica

id_diag

factura

importe

Facturas Cliente

1 1

1 1

N

N

N

N

Tiempo


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



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.


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;


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



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


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



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


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


id_cliente

id_fecha

id_clinica

id_diag

factura

importe

factor

Facturas Cliente

1 1

1 1

N

N

N

N

Tiempo


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.


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.



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.



Data WareHouse

Consideraciones en el diseño de almacenes de datos. Otras consideraciones:

dimensiones “que cambian”

definición de agregados.


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.


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.


25/3/11

127

Data WareHouse


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, ...).


Data WareHouse


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.


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).


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



dígito de versión

Cliente Póliza

Tiempo


25/3/11

129

Data WareHouse


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


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.


25/3/11

130

Data WareHouse


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.


Data WareHouse


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.


25/3/11

131

Data WareHouse


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


Data WareHouse



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


25/3/11

132

Data WareHouse



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)‏


Data WareHouse



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.


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


Data WareHouse


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)‏


25/3/11

134

Data WareHouse



....

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


Data WareHouse


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’.




Data WareHouse

Diseño físico


Implementación

Diseño conceptual


Implementación

Definición del esquema ROLAP o MOLAP

Carga del AD

Preparación de las vistas de usuario

(herramienta OLAP)‏


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


Data WareHouse








25/3/11

137

Data WareHouse


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


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.


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


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.


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).


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’


Data WareHouse

“Profesores varones que sean catedráticos de universidad”:

0

0

1

0

…

0

0

0

0

…

AND

0

0

0

0

…


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.


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


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


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.


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).


Data WareHouse


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


25/3/11

144

Data WareHouse


RED WHITE BLUE

By Color

By Make & Color

By Make & Year

By Color & Year

By Make By Year

Sum


RED WHITE BLUE

Chevy Ford

By Make

By Color

Sum

Cross Tab RED

WHITE BLUE

By Color

Sum


Aggregate

Cada plano cartesiano representa la agregación sobre una dimensión


Data WareHouse


RED WHITE BLUE

By Color

By Make & Color

By Make & Year

By Color & Year

By Make By Year

Sum


RED WHITE BLUE

Chevy Ford

By Make

By Color

Sum

Cross Tab RED

WHITE BLUE

By Color

Sum


Aggregate

Cada eje cartesiano representa la agregación sobre dos dimensiones


25/3/11

145

Data WareHouse


RED WHITE BLUE

By Color

By Make & Color

By Make & Year

By Color & Year

By Make By Year

Sum


RED WHITE BLUE

Chevy Ford

By Make

By Color

Sum

Cross Tab RED

WHITE BLUE

By Color

Sum


Aggregate

El origen de los ejes representa la agregación sobre las tres dimensiones


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.


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


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.


25/3/11

147

Data WareHouse

Herramienta OLAP

Herramienta OLAP

Servidor Relacional

Warehouse

MOLAP ROLAP

Clie

nte

Ser

vido

r Servidor Multidimensional


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.


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 Relacional


Data WareHouse


– 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.


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.


25/3/11

150

Data WareHouse








Data WareHouse


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


Data WareHouse

E.T.L.

Correspondencia

Bases de datos operacionales Almacenamiento

intermedio

Almacén de datos

Transformación

Extracción Transporte


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


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


Carga

Indización

Obtención de datos agregados.

Realización de pruebas de calidad de la carga.

Gestión de errores.



25/3/11

153

Data WareHouse

¿Herramientas E.T.L.?


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.


25/3/11

154

Data WareHouse

Correspondencia.

Correspondencia

Bases de datos operacionales

Almacenamiento intermedio

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


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



Almacén de datos

Extracción


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


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.


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


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)‏


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.




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.




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).


25/3/11

159

Data WareHouse

Fase de transformación.

Limpieza Transformación de datos Integración

Correspondencia



Almacén de datos

Transformación


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


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


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



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


Limpieza


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.


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, ...


Limpieza Fase de transformación.

25/3/11

162

Data WareHouse


– Detección y tratamiento de datos erróneos: la integridad referencial debe reconstruirse.

Departamento 10 20 30 40


Limpieza.

Data WareHouse

Transformación de datos: - discretización, - numerización, - codificación, - unificación, - estandarización, ...

Correspondencia



Almacén de datos

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


Transformación de datos


Data WareHouse

– Discretizar datos: transformar valores continuos en valores discretos o nominales.

(Deben detectarse los valores erróneos).

pequeño

0-3

0


mediano grande

4-7 8-10

3 4 7 8 10 ... ... ...


25/3/11

164

Data WareHouse

– Numerizar datos: transformar valores nominales en valores numéricos (enteros).


administrativo

revisor

1

conductor

mecánico

controlador

...

2

3

4

5

...


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


– 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



Data WareHouse

– Unificación: formato de los datos.

ASCII EBCDIC

12373 “123-73”

ACME Co.

áøåëéí äáàéí Beer (Pack of 8)‏


Fase de transformación. Transformación de datos

25/3/11

166

Data WareHouse


- Integración: aplicar las leyes de derivación para calcular los datos derivados.

Correspondencia



Almacén de datos

Transformación


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


25/3/11

167

Data WareHouse


– Integración de datos de distintas fuentes:


SELECT PROJECT JOIN GROUP, ....



Data WareHouse


– Integración de datos de distintas fuentes. – Cálculo de nuevos datos


Cálculo de nuevos datos: • Datos agregados • Datos calculados



Integración de datos: SELECT PROJECT JOIN GROUP, ....

25/3/11

168

Data WareHouse

Fase de transporte. Correspondencia

Transporte



Almacén de datos Transporte

Cuando la Transformación se realiza en el sistema operacional o en el AD.


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.


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



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



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



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



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


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


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



Data WareHouse

Procesos posteriores a la carga: obtención de agregados.

– Durante la extracción. – Después de la carga (transporte).


Almacenamiento intermedio Almacén de

datos

Transporte Extracción


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


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


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


Contrato


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


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


Contrato


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


Empleado Enseña N 1


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_prop nro_prop ciudad_inmueble tipo_inmueble id_propietario



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_prop nro_prop ciudad_inmueble tipo_inmueble id_propietario


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



Ejemplo

id_fecha

….

data warehouse

Documents

data warehouse toolkit

estrategias data warehouse

data warehouse performance

data warehousecoleccin

data warehouseevolucin

data warehousei

data warehouse etl toolkit

usuario final data warehouse