DATAWAREHOUSE 1

DATAWAREHOUSE
1
Introducción
“Un datawarehouse es un conjunto de datos
integrados , orientados a una materia que
varian con el tiempo y que no son
transitorios, los cuales soportan el proceso
de toma de decision”
2
No son transitorios
No son volatiles
 No se llevan a cabo modificaciones o
eliminaciones, solo inserciones
 Guarda datos sumarizados

3
Orientados a una materia
Organiza y orienta los datos en función del
usuario final y sus temas de interés
Ejemplo
Ventas, Competencias, Internaciones
4
Datos integrados
Los datos provienen de diferentes fuentes
La integración de datos se logra mediante la
consistencia en la Convenciones de
nombres, Unidades de medida y
Codificación
5
Unidades de medida
Las distintas fuentes de datos pueden tener
un mismo elemento medido en:
– Centímetros|
– Metros
– pulgadas
6
Codificación
Las distintas fuentes de datos pueden
tener distintas codificaciones,
ejemplo: genero
M, F
0, 1
x, y
7
Convenciones de nombres
El mismo elemento puede estar referido con
nombres diferentes en distintas aplicaciones
8
Varían con el tiempo
Mantiene tanto datos históricos como datos
actuales
 La información histórica es de gran
importancia, permite analizar tendencias

9
Toma de decisión
Sistemas orientados para dar soporte a la
toma de decisión dirigido a los trabajadores
del conocimiento:
Ejecutivos
Administradores
Analistas
10
Diferencias entre OLTP y OLAP
OLTP: On Line Transaction Processing
OLAP: On-Line Analytical Processing
11
Diferencias entre OLTP y OLAP
OLTP
 Datos organizados por
aplicación
 Focalizado en
aplicaciones
específicas
 No integradas
 Distintos tipos de
datos
OLAP
 Datos organizados por
tema
 Focalizado en
requerimientos
empresariales
 Integradas
 Mismo tipo de datos
12
Diferencias entre OLTP y OLAP
OLTP
 Diferente formatos de
archivos
 Diferentes plataformas
hardware
 Realizan
periodicamente altas,
bajas y modificaciones
OLAP
 Formatos de archivos
standard
 Un sólo servidor
(lógico)
 Solamente altas de
datos
13
Diferencias entre OLTP y OLAP
OLTP
 Se realizan acciones
repetidas
 Manipulación de datos
registro a registro
 Transacciones y/o
validación a nivel de
registro
OLAP
 Continuamente cambia
el tipo de pregunta
 Carga y acceso de
datos en forma masiva
 Validación antes o
después de la carga
(nunca a nivel de
registro o transacción)
14
Diferencias entre OLTP y OLAP
OLTP
 Manejan cientos de
transacciones diarias


Falta de soporte
explícito para datos
historicos
Datos operacionales
volátiles
OLAP
 Manejan pocas
transacciones con
muchos registros
 Soporte para datos
históricos

Datos altamente
estables
15
Diferencias entre OLTP y OLAP
Normalmente se encuentra separado el
DataWarehouse del OLTP, debido a:
– El DataWarehouse tiene alta demanda de
recursos, puede entorpecer el desempeño del
OLTP
– Los datos del DataWarehouse normalemente
son integrados de múltiples sistemas OLTP
remotos
16
Arquitectura General de un
DataWarehouse
17
Arquitectura General de un
DataWarehouse
Extracción de datos de múltiples fuentes
 Transformación de datos
 Carga de datos
 Acceso de datos

18
Transformación de datos
Proceso de sumarización y cambios en los
datos operacionales para reunir los objetivos
de orientación a temas
19
Extracción de datos
Se extraen datos de las distintas fuentes
operativas a un espacio temporal para
posterior limpieza y transformación
20
Carga de datos
Inserción sistemática de datos en el
componente de almacenamiento fisico del
DataWarehouse
21
Acceso de datos
Los usuarios acceden al DataWarehouse
mediante herramientas basados en GUI:
– Software de consultas
– Generadores de reportes
– Data mining
22
Metadatos
Representan toda la información de
administración y seguimiento
necesarios para:
– Acceso a datos
– Compresión y utilización
» Semántica
» Origen
» Formato
» Reglas de agregación
23
Datamarts
Subconjuntos departamentales que focalizan
objetos seleccionados
 Se caracteriza por una definición de
requerimientos más rápida y fácil
 Pueden integrarse en un futuro en un
DataWarehouse

24
Data mining
“Extracción de información oculta y
predecible de grandes bases de datos”
Predicción automatizada de tendencias y
comportamientos
 Descubrimiento automatizado de modelos
previamamente desconocidos

25
Modelo Conceptual
de un
DataWarehouse
26
Esquema de Hechos
27
Esquema de Hechos
El esquema de DataWarehouse consiste en un
conjunto de esquemas de hechos.
Componentes:
– Hechos
– Dimensiones
– jerarquías
28
Hecho
Es un enfoque de interés para la empresa
Ejemplo
VENTAS
COMPETENCIAS
INTERNACIONES
29
Dimensiones
Determina la granularidad para la
determinación de los hechos
Ejemplo
Producto
Fecha
almacen
30
Jerarquías
La dimensiones se asocian con sus jerarquías
y especifican distintos niveles de
agrupamiento
Ejemplo
Día Mes  trimestre año
Producto  Tipo  Categoría
31
Hipercubo
32
Vista Multidimensional - Ventas
Producto
camisa
saco
pantalon
Ciudad
NYork
Paris
Roma
Mar 99
Feb 99
Ene 99
Los datos se encuentran en la interseccion de las dimensiones
33
Vista de un archivo plano tradicional
Campo (columna)
Registro
(fila)
P ro duct o
Saco
Ca m is a
Saco
Pan talo n
Pan talo n
Ca m is a
Ca m is a
Saco
Pan talo n
Saco
Pan talo n
Fech a
En e 99
En e 99
En e 99
En e 99
Feb 9 9
Feb 9 9
Feb 9 9
Feb 9 9
M ar 9 9
M ar 9 9
M ar 9 9
Ciu da d
Lo n d res
Ro ma
Paris
Lo n d res
New Yo r k
Ro ma
Lo n d res
Ro ma
New Yo r k
New Yo r k
Lo n d res
Uni da des
20 0 00
10 2 00
15 0 00
52 0 0
32 0 0
78 0 0
95 2 0
45 2 0
25 8 0
58 9 0
65 2 0
El dato se encuentra en la interseccion de una fila y columna
34
Operaciones
Pivoting
 Slicing dicing
 Roll up
 Drill down

35
Pivoting
Rotar el cubo para ver una cara en particular
Ejemplo
Analizar informacion referida a proveedores
36
Slicing dicing
Seleccionar algún subconjunto de ese cubo
Ejemplo
Analizar el cubo de datos restringiendolo
para algunos proveedores, productos y
fechas
37
Roll up
Agrupamiento por alguna dimensión
determinada
Ejemplo
Analizar las ventas de producto a las ventas
por tipo de producto
38
Drill down
Operación inversa: muestra información
detallada de cada agrupamiento
Ejemplo
Analizar las ventas de tipo de producto a las
ventas por producto
39
Implementaciones relacionales
Esquema estrella
 Copo de nieve ó Pochoclo
 Constelación

40
Esquema estrella
Compuesto por una tabla central –tabla
de hechos- y un conjunto de tablas
mostradas en una forma
radial alrededor de ésta –tablas
dimensión-
41
Esquema estrella
42
Modelos - Estrella
Ventajas
Facil de entender
Rapida respuesta a consultas
Datos simples
Desventajas
Mas susceptible a los cambios
Lenta de construir por la denormalizacion
43
Copo de nieve ó Pochoclo
Extensión del esquema estrella, donde cada
una de las tablas del esquema
se divide en más tablas
-tablas más normalizadas-
44
Modelos - Pochoclo
Ventajas
 Mas flexible a requerimientos
 Carga mas rapida
Desventajas
 Puede agrandarse y ser inmanejable
 Puede degradar la performance
45
Copo de nieve
46
Modelos - Constelación
Tabla clientes
cod-cliente
nombre-cliente
Tabla deposito
cod-depo
cod-localidad
Tabla hechos
precio-unidad
ventas-unidad
ventas-pesos
costo-pesos
Tabla tiempo
cod-semana
cod-periodo
cod-año
Resumen por producto,
deposito, y tiempo para
todos los clientes
Tabla resumen
cod-cliente
ventas-total
valor top-ventas
promedio-ventas
Tabla producto
cod-prod
desc-prod
47
Modelos - Constelación
Tabla Regiones
cod-region
desc-region
Tabla producto
cod-prod
desc-prod
Tabla Hechos-inventario
cod-prod
cod-estante
costo-pesos
cantidad
Tabla tiempo
cod-semana
cod-periodo
cod-año
Tabla deposito
cod-depo
cod-localidad
Tabla hechos
cod-depo
cod-item
ventas-pesos
ventas-unidades
Tabla Item
cod-item
desc-item
48
Diseño conceptual de un
DataWarehouse a partir
del Modelo Entidad
Interrelación
49
Diseño conceptual de un
DataWarehouse
Metodología semi automática para
construir un modelo lógico
de un DataWarehouse a partir de un
Modelo Entidad Interrelación
50
Ejemplo de MER
51
Transformación de una relación
en entidad
52
Metodología
Definir los hechos
 Por cada hecho

–
–
–
–
–
Construir el árbol de atributos
Recortar e injertar el árbol
Definir dimensiones
Definir atributos de hecho
Definir jerarquias
53
Definir los hechos
Los hechos son conceptos de interés
primario para realizar procesos de toma de
decisiones
Un hecho puede ser representado en un MER
mediante un entidad o una relación que
representan archivos actualizables
54
Construir el árbol de atributos
Dada una porción de interés del MER y una
entidad F que pertenece a él, denominamos
árbol de atributos al árbol que:
Cada vértice corresponde a un atributo del
esquema
 La raíz corresponde al identificador de F

55
Algoritmo
translate(F, identifier(F))
donde
translate(E, v): // E es la entidad actual, v es el vértice actual
{ for each attribute a e E  a  identifier(F) do
addChild (v, a); // agrego un hijo a al vértice v
for each entity G connected to E
by a x-to-one relationship R do
{ for each attribute b e R do
addChild (v, b);
addChild (v, identifier(G));
translate(G, identifier(G));
}
}
56
Árbol de atributos
57
Recortar e injertar el árbol
No todos los atributos representados en el
árbol pueden ser de interés.
El árbol puede ser podado e injertado para
eliminar detalles innecesarios
58
Recortar e injertar el árbol
graft(v):
{ for each v”  v” is child of v do
addChild(v’,v”);
drop v;
}
59
Árbol podado e injertado
60
Definir dimensiones
Las dimensiones determinan cómo las
instancias de hechos pueden ser agregadas
para el proceso de la toma de decisiones
Deben ser elegidas entre los vértices del árbol
Ejemplo
Fecha
Producto
Almacen
61
Definir atributos de hecho
Son cantidades del número de instancias de
hecho o suma/promedio/máximo/mínimo
de expresiones que involucran atributos
numéricos del árbol de atributos
62
Definir jerarquías
La jerarquías especifican distintos niveles de
agrupamiento
El árbol ya muestra una organización
jerárquica
63