Creando el próximo Data Warehouse:

Integración y Calidad de Datos

Sesión 1: Fundamentos del DWH
Alberto Collado
1
 Agenda

 Sesión 1:
 Fundamentos del DWH

 Sesión 2:
 Fundamentos de la Calidad de Datos

 Sesión 3:
 Caso práctico: Un DWH con Calidad

2
 Agenda Sesión 1

 Presentación PowerData
 Presentación asistentes: Conocimientos y Expectativas
 Fundamentos DWH
 Introducción al DWH
 Arquitectura de un DWH
 Modelado de Datos y Metadatos
 Esquemas en Estrella
 Procesos y Estrategias de carga del DWH
 Herramientas de Integración de Datos
 Herramientas de Reporting y Análisis

3
 Presentación PowerData

4
4
 Presentación PowerData

 Empresa lider especializada en Data Management

 Colaboradores de Informatica Corporation en España (Elite
Partner), Chile, Argentina, Perú y Uruguay (Distributor)
 www.powerdata.es
 www.informatica.com
 Informatica
 Nacida en 1993, en California
 +1.400 colaboradores
 Powerdata
 Nacida en 1999, en Barcelona
 90 empleados

5
 La solución: los servicios de datos

Mejorar Modernizar el
Necesidades decisiones y negocio y Aumentar la Subcontratar
Fusiones y rentabilidad
cumplir con la reducir los adquisiciones funciones
empresariales normativa costes de TI del negocio secundarias

Inteligencia Eliminación Consolidación Hubs de productos, BPO

Iniciativas de empresarial de sistemas de aplicaciones proveedores SaaS
TI heredados y clientes

Proyectos de
integración
de datos
Almacenamiento Migración Consolidación Gestión de Sincronización
de datos de datos de datos datos maestros de datos

Servicios Servicios de datos

de datos

Plataforma de productos de Informatica

Informatica Informatica Informatica Informatica

PowerExchange Data Explorer Data Quality PowerCenter

6
 La plataforma de productos de Informatica
Automatización de todo el ciclo de vida de la integración de datos

Auditoría, control y creación de informes

Garantizar la coherencia de los datos, realizar análisis de impacto y supervisar
constantemente la calidad de la información

Data Explorer Data Quality

Acceso Detección Limpieza Integración Entrega

A cualquier Buscar y perfilar Validar, corregir y Transformar y Entregar los datos
sistema, por cualquier tipo de estandarizar datos conciliar datos de adecuados en el
lotes o en datos de de todo tipo todo tipo momento y formato
tiempo real cualquier fuente adecuados

PowerExchange PowerCenter

Desarrollo y gestión
Desarrollar y colaborar con un repositorio común y metadatos compartidos

7
 Presentación Asistentes:
Conocimientos y Expectativas

8
8
 Fundamentos del DWH

9
 Fundamentos del DWH

 Introducción al DWH: ¿Qué es?

 Arquitectura de un DWH
 Modelado de Datos y Metadatos
 Esquemas en Estrella
 Procesos y Estrategias de carga del DWH
 Herramientas de Integración de Datos
 Herramientas de Reporting y Análisis

10
 Fundamentos del DWH
Introducción al DWH: ¿Qué es?

11
 ¿Qué es un Data Warehouse?

 Orientado a un Tema
 Colección de información relacionada organizada
alrededor de un tema central

 Integrado
 Datos de múltiples orígenes; consistencia de datos

 Variable en el tiempo
 ‘Fotos’ en el tiempo
 Basado en fechas/periodos

 No-volátil
 Sólo lectura para usuarios finales

 Menos frecuencia de cambios/actualizaciones

 Usado para el Soporte a Decisiones y Análisis de Negocio

12
 Orientado a Tema

Los usuarios piensan en términos de ‘cosas’ y sus ‘relaciones’,

no en términos de procesos, funciones o aplicaciones.

Proveedor Pedido Realiza Cliente

Proporciona Contiene

Orden de
Compra Producto Inventario
Compuesta por Recuperado
desde

13
 Integrado

 Contiene
 Convenciones de Nombres
 Descripciones
 Atributos físicos de los datos
 Valores de los datos
Consistentes
Admin. Marketing
Datos
Operaciones

Ventas Cuentas

14
 Variable en el tiempo

 Entorno Operacional  Data Warehouse

 Datos con valores actuales
 Horizonte de 30 - 90 días
 Exactitud en los accesos
 Datos en ‘fotos’
 Horizonte de 5 – 10 años
 Refleja la perspectiva desde un
momento en el tiempo

Id de cliente
Id de cliente fecha desde
nombre fecha hasta
dirección nombre
teléfono dirección
ratio de crédito teléfono
ratio de crédito

15
 No-Volátil

inserción cambio
lectura
carga

borrado

Sistema OLTP Sistema DSS

(dinámico)
(más estático)

16
 Un Data Warehouse es ...

 … un modelo de datos de soporte a decisiones que

representa la información que una compañía necesita
para tomar BUENAS decisiones estratégicas.

 … basado en la estructura de un sistema de gestión de

base de datos relacional el cual puede ser usado para
INTER-RELACIONAR los datos contenidos en él.

 … con el propósito de proporcionar a los usuarios finales

un acceso SENCILLO a la información.

… un CONCEPTO, no una COSA

17
 ¿Para qué construir un Warehouse?

 Para tener un mayor conocimiento del negocio

 Para tomar mejores decisiones y en un tiempo
menor
 Para mejorar y ser más efectivos
 Para no perder distancia con la competencia
 … en definitiva … €€€

18
 Visión del Usuario

Panel de Representación de
Usuarios Consulta Negocio
Finales

Base de Datos

 Solución integrada de: Consultas, informes y análisis.

 Capa semántica que da una representación de los datos desde el
punto de vista de negocio.

 Los usuarios utilizan términos de negocio, no términos

informáticos.
19
 Fundamentos del DWH
Arquitectura de un DWH

20
 Arquitectura de un DWH

 Nomenclatura
 DWH: Data Warehouse
 DataMart
 OLTP: On-Line Transaction Processing
 OLAP: On-Line Analytic Processing
 ROLAP: Relational On-Line Analytic Processing
 MOLAP: Multidimensional On-Line Analytic Processing
 ODS: Object Data Store
 DSS: Decision Support System
 ETL: Extract, Transform and Load
 ETQL: Extract, Transform, Quality and Load
 EII: Enterprise Information Integration
 EAI: Enterprise Application Integration
 ERP: Enterprise Resource Planning

21
 Directo de OLTP a OLAP

Life
Life Life
Information System OLAP

Health
Health
Information System Health
Query

Auto Auto
Information System Auto
Analysis
22
 Directo de OLTP a OLAP

 Es bueno, si los datos lo son.

 Horizonte de tiempo limitado
 Compite con OLTP por los recursos
 Uso frecuente para hojas de cálculo
 No tiene metadatos (o sólo implícitos)
 Principalmente, para jefes de departamentos,
no se considera información “para las masas”
 No hay información cruzada entre los
diferentes sistemas

23
 Data Warehouse Virtual: Directo o Federado

Life
Life
Information System

Health
EII
Health
Information System "Customer"
OLAP

Auto Auto
Information System

24
 Data Warehouse “Total”

Extract:
COBOL,
Life SQL,
Life Etc.
Information System Life
OLAP
MDD Tools

Extract: Enterprise
COBOL, Data
Health SQL,
Warehouse
Health Etc.
Information System Health
R/OLAP
Star Schema

Extract:
COBOL,
SQL,
Auto
Auto Etc. Auto
Information System SQL Query

25
 Data Marts No Estructurados

Extract:
COBOL, Life
Life SQL, Data
Mart Life
Life Etc. OLAP
Information System MDD Tools

Extract:
COBOL, Health
Health SQL, Data
Health
Health Etc. Mart R/OLAP
Information System Star Schema

Extract:
COBOL,
Auto
SQL,
Auto Data
Auto Etc. Auto
Information System
Mart SQL Query

26
 Data Marts Estructurados

Life Life
OLTP Data
Mart
EXTRACT Life
SELECT OLAP
MDD Tools
TRANSFORM
INTEGRATE
LOAD
Enterprise
Health
Data Health
Cleanse Data
OLTP for: Warehouse Data
Names Mart Health
Formats "Customer" R/OLAP
Star Schema
Values
Domains
Metadata

Auto Auto
OLTP Data
Mart Auto
SQL Query

27
 OLAP (Online Analytic Processing)

 Herramientas orientadas a consulta/análisis

 Puede ser ROLAP o MOLAP
 'Multi-dimensional', es decir, puede ser visualizada como
’cuadrículas' o 'cubos'
 Consulta interactiva de datos, siguiendo un “hilo” a través
de múltiples pasos -- 'drill-down'
 Visualización como tablas cruzadas, y tablas pivotantes
 Actualización de la base de datos
 Capacidad de modelización (motor de cálculo)
 Pronósticos, tendencias y análisis estadístico.
28
 Ejemplo uso de una herramienta de consulta
Información solicitada

Información
disponible

Condiciones

 El interfaz de usuario simple

 Trabaja contra representación de negocio de los datos
 Todos los componentes en una pantalla
29
 Los informes son la capa visible …

• Integración Datos no sólo en entornos analíticos

• Importancia de la Calidad

Herramientas de OLAP / Business Intelligence / Cuadro de Mando

Servidores
Extracción
Red
Limpieza de Datos
Bases de Datos
Transformación
Middleware
Carga de Datos
30
 Data Marts Estructurados: Visión Completa

Ficheros: FF,
XML
DM
Compras
Aplicaciones:
ERP,...

BBDD DM
DWH Financiero
Integración +
Calidad de
Datos
Tiempo Real,
WS, Http
DM
Ventas
Legacy

Diseño Mapeos ETL, Almacenamiento: Análisis

Replicación
Perfilado de Estandarización, Agregación, Reporting
Distribución
Datos Desduplicación Indexación,... Cuadros Mando

Metadatos: Análisis Impacto, Linaje de datos, Auditoría, Monitorización, etc

31
 Fundamentos del DWH
Modelado de Datos y Metadatos

32
 Técnicas de Modelización Estructural

 En esta sección veremos técnicas que afectarán a

diversos puntos

 Consideraciones de Tiempo
 Técnicas de Optimización

33
 Consideraciones de Tiempo
Staging Data Data Marts
Area Warehouse Relacional Dimensional
Actualidad de Datos
ESTRUCTURAL

¿Cuál es el impacto
Agrupaciones basadas del Tiempo en cada
en tiempo
Almacén de Datos?
Tiempo

Retención de
Histórico

 Todo el DW se ve afectado por cambios temporales porque

por definición es “Tiempo-dependiente”
 Preguntas importantes:
 ¿Cuan actual deben ser los datos para satisfacer las
necesidades de negocio?
 ¿Cuánta historia necesitamos en nuestro negocio?
 ¿Qué niveles de agregación son necesarios para qué ciclos de
negocio?
34
 Técnicas de Modelización Temporal

 Unidades de tiempo
 Calendarios de negocio

 Técnicas
 Foto (Snapshot)
 Trazado de Auditoría

 Metadatos temporales
 Fechas Efectivas de Inicio y Fin
 Fecha de cambio en Fuentes (evento)
 Fecha de cambio en Destinos (carga)

35
 Foto (Snapshot)

 Dos técnicas diferentes

 Múltiples Tablas
 Tabla Única
 Uso de Fecha Efectiva Inicio en un
ejemplo. Metadatos a nivel de registro

Foto (SNAPSHOT)

Nov 2001 CLIENTE

CLIENTE
Num Cliente
Oct 2001 CLIENTE
Nombre Num Cliente
Apellido1 O bien Fecha Efectiva Inicio
Num Cliente
Apellido2 Nombre
Género Nombre Apellido1
Apellido1
Fecha Carga Apellido2
Apellido2 Género
Género Fecha Carga
Fecha Carga

36
 Foto (Snapshot) Múltiple
 Una tabla para cada período
 Se guardan TODOS los datos (cambien o no)
 Nombre de la tabla refleja el período
 Buen enfoque de (extracción/carga/modelado) para
Data Marts. Cada mes, en el ejemplo, representa los
datos tal y como estaban
 Mal enfoque para Staging, ya que hay mucha
replicación de datos Foto (SNAPSHOT)

Nov 2001 CLIENTE

CLIENTE
Num Cliente
Nombre
Oct 2001 CLIENTE Num Cliente
Apellido1 O bien Fecha Efectiva Inicio
Apellido2
Num Cliente Nombre
GéneroNombre Apellido1
Fecha Carga
Apellido1 Apellido2
Apellido2 Género
Género Fecha Carga
Fecha Carga

37
 Foto (Snapshot) Única
 Se guardan TODOS los datos (cambien o no)
 Buen enfoque para Data Marts y puede ser útil en el
Warehouse.
 Mal enfoque para Staging, ya que hay mucha
replicación de datos
 Time Stamps imprescindibles
Fecha Efectiva
Foto (SNAPSHOT) de Negocio

Nov 2001 CLIENTE

CLIENTE
Num Cliente
Oct 2001 CLIENTE
Nombre Num Cliente
Apellido1 Fecha Efectiva Inicio
Num Cliente O bien Nombre
Apellido2
GéneroNombre Apellido1
Apellido1
Fecha Carga Apellido2
Apellido2 Género
Género Fecha Carga
Fecha Carga

38
 Foto (Snapshot) Única

 Fechas (Time Stamps) necesarias para

identificar la validez de los datos:
 Fecha efectiva de Inicio
 Fecha efectiva de Fin (no está en el ejemplo)
 Fecha de Carga
Num Cliente Fecha Efectiva Inicio Nombre Género Fecha Carga
2304 31/10/2001 Juan Reyes Hombre 01/11/2001
5590 31/10/2001 Julia Astur Mujer 01/11/2001
6720 31/10/2001 Carlos Márquez Hombre 01/11/2001
7841 31/10/2001 Luis Tesquilo 01/11/2001
2304 30/11/2001 Juan Reyes Hombre 01/12/2001
5590 30/11/2001 Julia Picado Mujer 01/12/2001
6720 30/11/2001 Carlos Márquez Hombre 01/12/2001
7841 30/11/2001 Luis Tesquilo 01/12/2001
Vemos la duplicidad de los datos
39
 Trazado de Auditoría
CLIENTE

ID_cliente
nombre
apellido1

 Guarda los cambios de

apellido2
género
fecha_aniversario
los datos de interés
 Información:
 Fecha del cambio
 Razón del cambio Metadato a nivel
AUDITORIA CLIENTE
 Cómo se ha detectado ID_cliente
registro

fecha_inicio_efectiva
 ... nombre
apellido1
apellido2
Fecha de Negocio
 Sólo se extraen/cargan género
fecha_aniversario
(no Metadato)
fecha_carga
valores modificados

40
 Trazado de Auditoría
Num Fecha Efectiva Nombre Género Fecha Fecha
Cliente Inicio aniversario Carga
2304 31/10/2001 Juan Reyes Hombre 01/01/1964 01/11/2001
5590 31/10/2001 Julia Astur Mujer 06/03/1948 01/11/2001
6720 31/10/2001 Carlos Hombre 19/09/1960 01/11/2001
Márquez
7841 31/10/2001 Luis Tesquilo 25/07/1952 01/11/2001
5590 30/11/2001 Julia Picado Mujer 06/03/1948 01/12/2001

 Sólo cambios en la tabla

 Usado en Staging Area y Data Warehouse
 Posible en Data Marts, pero no es habitual ya
que no es claro para un usuario final

41
 Técnicas de Optimización Estructural y Física
Staging Data Data Marts
Area Warehouse Relacional Dimensional
Actualidad de Datos
Tiempo

Agrupaciones basadas
ESTRUCTURAL

en tiempo
Retención de Histórico
Seguridad
Posición

Distribución

Acceso
Navegación
Uso

Herramientas
Rendimiento
Implementación

Tamaño ¿Cómo debe optimizarse cada

almacén de datos en la
Disponibilidad Implementación?
FÍSICO

Recuperación
DBMS

42
 Técnicas de Optimización

 Derivación
 Data Warehouse y Data Marts
 Usos
 Facilitar acceso PÓLIZA RESIDENCIAL
num_póliza
 Consistencia resultados total_cobertura
supl_terremotos
supl_inundaciones
supl_viento
supl_robos
va c ió n
PÓLIZA
supl_arte Deri
total_suplementos
total_suplementos=
num_póliza supl_terremotos +
código_tipo_póliza supl_inundaciones +
fecha_inicio_póliza una supl_viento +
fecha_inicio_cobertura de supl_robo +
fecha_fin_cobertura supl_arte
términos
cantidad_prima
cantidad_servicio PÓLIZA_AUTOMOVIL

num_póliza
total_colisión
...

43
 Técnicas de Optimización
Data Warehouse PÓLIZA RESIDENCIAL

 Agregación num_póliza
total_cobertura
supl_terremotos
supl_inundaciones

 No cambio de supl_viento
supl_robos
supl_arte
granularidad PÓLIZA total_suplementos
fecha_carga
num_póliza

 Objetivo: Facilitar el código_tipo_póliza

fecha_inicio_póliza
fecha_inicio_cobertura una

acceso a los datos fecha_fin_cobertura

términos
de

cantidad_prima
cantidad_servicio PÓLIZA_AUTOM OVIL
fecha_carga
num_póliza
total_colisión
AGREGACIÓN descuento_cliente
indic_precio_especial
fecha_carga

PÓLIZA RESIDENCIAL
AGREGACIÓN
num_póliza
código_tipo_póliza PÓLIZA_AUTOM OVIL
fecha_inicio_póliza
fecha_inicio_cobertura num_póliza
fecha_fin_cobertura total_colisión
términos descuento_cliente
cantidad_prima indic_precio_especial
cantidad_servicio código_tipo_póliza
total_cobertura fecha_inicio_póliza
supl_terremotos fecha_inicio_cobertura
supl_inundaciones fecha_fin_cobertura
supl_viento términos
supl_robos cantidad_prima
supl_arte cantidad_servicio
total_suplementos fecha_carga
fecha_carga

44 Data Marts
 Técnicas de Optimización
CLIENTE
RESUM EN ANUAL
id_cliente
CLIENTES
fecha_alta_cliente
fecha_baja_cliente
 Sumarización nombre
apellido1
id_cliente
año_resumen
valor_inicio_año
apellido2
 Histórica grupo_edad
género
valor_final_año
total_cuenta_inicio_año
total_cuenta_final_año

 Agrupada
estado_civil
total_años_como_cliente
indic_cliente_perdido
fecha_carga

AÑO
BASE CLIENTELA
ANUAL
num_año
id_zona
id_producto
código_tipo
num_año
cuenta_cliente
TRIM ESTRE

num_trimestre

BASE CLIENTELA

id_zona
id_producto
M ES código_tipo
num_mes
num_mes cuenta_cliente

45
 Técnicas de Optimización

 Particionamiento Horizontal
 Particiones por filas RESUM EN ANUAL
CLIENTES

 Todos los campos repetidos id_cliente

año_resumen
en las nuevas tablas código_región
valor_inicio_año

 Uso valor_final_año
total_cuenta_inicio_año
total_cuenta_final_año
 Aislar datos sensibles total_años_como_cliente

 Reducción tamaño tablas

RESUM EN ANUAL RESUM EN ANUAL

CLIENTES - SUR CLIENTES - NORTE

id_cliente id_cliente
año_resumen año_resumen
valor_inicio_año valor_inicio_año
valor_final_año valor_final_año
total_cuenta_inicio_año total_cuenta_inicio_año
total_cuenta_final_año total_cuenta_final_año
total_años_como_cliente total_años_como_cliente

46
 Técnicas de Optimización
CLIENTE

id_cliente
fecha_alta_cliente
fecha_baja_cliente
 Particionamiento Vertical nombre
apellido1
apellido2
 División por columnas grupo_edad
género
estado_civil
 Posibilidad de columnas indic_cliente_perdido
num_cuenta_debito
redundantes nombre_banco_debito
num_autorización_débito
rango_crédito
 Uso fecha_ultimo_check_credito
fecha_carga

 Seguridad Campos con Campos con

Datos no Sensibles Datos Sensibles
 Distribución
CLIENTE CLIENTE_SEGURO

 Puede ser que tengamos id_cliente

fecha_alta_cliente
id_cliente
fecha_alta_cliente
Horizontal y Vertical a la fecha_baja_cliente
nombre
fecha_baja_cliente
nombre
apellido1 apellido1
vez apellido2
grupo_edad
apellido2
num_cuenta_debito
género nombre_banco_debito
estado_civil num_autorización_débito
indic_cliente_perdido rango_crédito
fecha_carga fecha_ultimo_check_credito
47
 Técnicas de Optimización
 Particionamiento por Estabilidad PÓLIZA RESIDENCIAL

 Basado en frecuencia de cambio num_póliza

fecha_inicio_póliza
fecha_inicio_cobertura
 Uso en Staging Area fecha_fin_cobertura
términos
cantidad_prima
 Velocidad de carga cantidad_servicio
total_cobertura
 Separar datos más volátiles minimiza supl_terremotos
supl_viento
cambios supl_inundación
supl_pieles
supl_arte
supl_joyas
supl_otros
fecha_carga

PÓLIZA RESIDENCIAL

num_póliza PÓLIZA RESIDENCIAL

Claves Primarias fecha_inicio_póliza
en ambas tablas num_póliza
fecha_inicio_cobertura
fecha_inicio_póliza
fecha_fin_cobertura
supl_pieles
términos
supl_arte
cantidad_prima
supl_joyas
cantidad_servicio
supl_otros
total_cobertura
fecha_carga
supl_terremotos
supl_viento
supl_inundación
fecha_carga
Metadatos a
Nivel Registro en
ambas tablas
48
 Técnicas de Optimización
Fichero M aster Ventas
Número_factura Identificador Factura
 Claves Alternativas Número_cliente Identificador Cliente

 Caso especial de derivación

...

Fichero M aster M arketing

 Creada artificialmente para ID_campaña Identificador campaña

identificar entidades ID_cliente Identificador Cliente

...

 Habitualmente un entero PÓLIZAS

 Staging DW  DM ID_Póliza Identificador Póliza

ID_Tomador Identificador Asegurado

 Hay que mantener un mapeo ...

Generación Claves Alternativas

M APEO_ID_CLIENTE CLIENTE

código_sist_origen num_id_cliente
id_cliente_origen fecha_alta
fecha_inicio fecha_baja
fecha_fin grupo_edad
num_id_cliente ...
49 fecha_carga fecha_carga
 Técnicas de Optimización PÓLIZA_AUTOMOVIL VEHÍCULO
num_póliza num_bastidor
fecha_inicio_póliza fecha_inicio_vehículo
fecha_inicio_cobertura num_póliza
fecha_fin_cobertura marca
términostotal_colisión modelo
descuento_cliente ...
indic_precio_especial ind_ABS
código_tipo_póliza ind_airbag
ind_ESP
 Pre-Joins
...
fecha_carga fecha_carga

 Caso especial de Agregación

 Data Warehouse y Data Marts
 Existe redundancia de Información PÓLIZA_Y_VEHÍCULO

 Incrementeo uso espacio num_bastidor

fecha_inicio_vehículo
num_póliza
 Acceso mucho más rápido fecha_inicio_cobertura
fecha_fin_cobertura

 En el DW
términostotal_colisión
descuento_cliente
indic_precio_especial
 Mantendremos también las tablas código_tipo_póliza
marca
separadas para cuando no necesitemos la modelo
...
Join ind_ABS
ind_airbag
ind_ESP
fecha_carga
50
 Técnicas de Optimización

 Cadenas de Datos
 Caso especial de Agregación
 Eficiente para Reporting
 NUNCA en operacionales o
Staging, pero muy útil en DW
y DM

51
 Técnicas de Optimización

 Balancear diferentes Factores

Rendimiento

Seguridad

Distribución

Recuperación
errores

Tamaño &
Bases de Datos del
Crecimiento
Data Warehose
Estabilidad

Histórico
Plataforma
Acceso &
Navegación

52
 Fundamentos del DWH
Esquemas en Estrella

53
 Puntos Fuertes de la Modelización Dimensional

 Coincide con las percepciones de los usuarios

 Estructura predecible, estándar
 Facilita el desarrollo de consultas y análisis
 Las herramientas OLAP pueden hacer suposiciones
 Cada dimensión es equivalente para todos los datos
 Puede ser modificada fácilmente
 Usa perspectivas de modelización comunes
 Simplifica la agregación

54
 Modelización Dimensional -
Regla de Oro

Los Esquemas en Estrella deberían

ser utilizados para cualquier dato
accedido directamente por los
usuarios finales.

55
 El Esquema en Estrella

 Hechos
 Dimensiones
 De-normalizado (generalmente)
 Tiene caminos de unión bien diseñados
 Paraleliza la visión de los datos por el usuario
 Son fácilmente modificables
 Simplifica la comprensión y navegación por los
metadatos
 Amplia la elección de herramientas de usuario final

56
 Modelización Dimensional

 Tablas de Hechos: contienen datos cuantitativos sobre el

negocio
 La clave primaria es una concatenación de claves de
dimensión, incluyendo el tiempo
 Cada elemento de la clave primaria compuesta es una clave
de integridad referencial hacia una tabla de dimensión.
 Contienen menos atributos, pero muchos más registros

 Tablas de Dimensión: gestionan datos descriptivos que

reflejan las diversas dimensiones del negocio
 Contienen muchos atributos pero menos (pocos) registros
 La clave primaria ‘ayuda’ a componer las claves primarias de
las tablas de hechos

57
 Esquema en Estrella (conceptual)

58
 Diseño de una Tabla de Hechos

 Elija el PROCESO del Data Mart

 Comience el contenido del data mart a partir de datos de un
solo origen

 Defina la GRANULARIDAD de la tabla de hechos

 Elija el nivel granular más bajo posible
 Transacciones individuales o fotos

 Elija las DIMENSIONES

 Reflejan el contenido de la tabla de hechos y la granularidad

 Elija los HECHOS

 Los hechos individuales y el ámbito de estos hechos deben
ser específicos a la granularidad de la tabla de hechos

59
 Identifique el Proceso Departamental

 ¿Cuál es el proceso o función

subyacente para el DM?
 ¿Cuál es el ámbito aproximado del
DM?
 ¿Quién usará el DM?
 ¿A qué preguntas les gustaría a los
usuarios que contestaran los datos del
DM?

60
 Determine los Hechos
 ¿Qué hechos están disponibles?
 ¿Cuáles son los datos cuantitativos fundamentales que hay
por debajo?
 Los hechos más útiles son los numéricos y aditivos

 ¿Qué nivel de detalle (granularidad) necesita mantener?

 Serán datos ‘atómicos’ (todo el detalle) o datos agregados
(sumarizados)?
 Si son agregados, cómo (usando qué algoritmo)?
 ¿Para qué propósito de negocio?

 ¿Cuál es la frecuencia de carga de datos requerida?

 ¿Cada transacción?
 ¿Cada hora? ¿Día? ¿Semana? ¿Mes?
61
 Tablas de Hechos ‘Sin Hechos’ - EVENTOS

 Eventos: Algo que ‘ha ocurrido’

 Ejemplo: Asistencia de estudiantes a una clase, asientos
de pasajeros de línea aérea o habitaciones de hotel
ocupadas

 Enlace el evento a:
 Tiempo / estudiante / profesor / curso / facilidades

 Típico para crear un ‘hecho vacío’

 Asistencia = 1

 La granularidad es el evento individual de ‘asistencia a

clase’
FUENTE: Kimball, 1998

62
 Las Agregaciones Pueden:

 Asegurar la consistencia entre data marts

 Ser hechas reutilizables para mantenerlas de
manera centralizada
 Mejorar el rendimiento del usuario
 Reducir los recursos necesarios para
preparar las consultas (CPU, disco,
memoria)
 Ser utilizadas en base a:
 Frecuencia de acceso
 Efecto del número de registros
63
 Determine las Dimensiones

 ¿Qué dimensiones pueden necesitar los usuarios?

 ¿Cuáles son los conceptos fundamentales (entidades o
temas) con los que los usuarios trabajarán?

 Siempre existirán al menos dos dimensiones; quizá

hasta una decena.
 El tiempo será una dimensión prácticamente siempre
 ¿Cuál es el identificador (clave primaria) de cada una de
las dimensiones?
 No_Cliente, ID_Cuenta, NoFactura

 Los atributos de la dimensión se convierten en las

cabeceras de los registros SQL

64
 Para Cada Tabla de Dimensión

 Establezca la clave primaria para cada registro

dimensional
 Use la clave primaria como una parte de la clave
compuesta de la tabla de hechos
 Identifique los atributos de interés para los usuarios
 ¿Qué atributos deben ser de-normalizados?
 ¿Qué otros atributos podrían tener valores significativos?
 ¿Hay alguna oportunidad de incluir datos ‘de fuera’?
¿Cuáles?
 Ayúdese de los valores reales contenidos en los atributos

65
 La Dimensión de Tiempo

 Debe ser día a día durante 5-10 años

 Separe los campos de semana, mes, día, año,
día de la semana, vacaciones, estaciones, etc.
 Trimestres naturales y fiscales
 Créela como una sola tabla en el DWH
 Cargue el contenido en los DM a medida que se
necesiten

66
 Establezca Relaciones

 Dibuje la relación visualmente

 Identifique la cardinalidad (1-N)
 Entre la tabla de hechos . . . y cada tabla de
dimensión
 “Una Imagen vale más . . .”

67
 Métodos para Identificar Dimensiones y Hechos

 Informes de Concepto
 Reuniones y Entrevistas
 Requerimientos Especiales del Proyecto
 Documentos sobre Ámbito del Proyecto
 Peticiones de Información
 ‘Cartas a los Reyes Magos’
 Modelos y Bases de Datos Existentes
 Informes Actuales (y Deseados)

68
 Ejemplo:
Intereses de la División Financiera
 La división financiera ha preparado la siguiente lista de
funcionalidades deseables en el data mart.
 Muchos de estos datos son información de cliente /
demográfica.
 Nos permitirá evaluar el impacto de costes en nuestros
clientes, ubicación y uso por nuestros clientes, costes
incurridos por ubicación para servir a nuestros clientes y
otros tipos de evaluaciones financieras relativas a costes,
uso, etc.
 Este tipo de información será muy valiosa para dirigir los
aspectos financieros y políticos de las planificaciones y
soluciones futuras a los problemas actuales.
 Esta información nos permitirá contestar mejor a las
importantes preguntas que aparecerán durante ese
proceso.
69
 Ejemplo:
Frase de Ejemplo de Misión

Capture datos de nuestro sistema para realizar

evaluaciones por zonas de nuestros clientes,
intereses y beneficios y para asesorar el
impacto de costes sobre nuestra base de
clientes.

70
 Ejemplo:
Preguntas a la División Financiera
1. Datos demográficos de nuestros clientes - el tipo
de datos que aparece en un censo (tipo de
vivienda, valor de la vivienda, ocupación, sexo,
educación, ingresos, etc.) Puede ser usado para
enviar mensajes oficiales, evaluación de intereses
de penalización, y mercado objetivo.

2. Clientes por clase de interés – definición por

clientes residenciales, comerciales, industriales,
gobierno y multifamiliares.

3. Beneficio demográfico por cliente y consumo –

como valor de la vivienda, ingresos o educación.
71
 Ejemplo:
Preguntas a la División Financiera (2)
4. Información sobre el servicio al cliente – incluyendo beneficio
por los diferentes tipos de intereses y cobros por zona
geográfica, beneficio y consumo.
5. Beneficio total por clase de cliente y categoría de intereses – a
lo largo de los últimos cinco años. ¿Qué clases de clientes dan
más beneficio?
6. Presupuesto del año en curso por zona – debe mostrar el
presupuesto actual y en qué áreas se han ido incurriendo esos
costes.
7. Valor de activos por zona – un informe que muestre el valor
depreciativo de los activos propios por zona.

72
 Ejemplo:
El Esquema Financiero en Estrella

73
 Fundamentos del DWH
Procesos y Estrategias de Carga del DWH

74
 Mapeo de Datos
 Mapeo LÓGICO -
 describe cómo ir desde donde se encuentra
hasta donde quiere ir

 Mapeo FÍSICO -
 Indica las rutas, baches, desvíos atajos de la
carretera

 TRANSPORTE -
 Decida si está conduciendo un coche deportivo o
un camión de recogida de chatarra

 PLANIFICACIÓN -
 Indica cuándo saldrá y cuánto espera que le lleve
llegar al destino

75
 Soluciones de Extracción, Transformación y Carga de
Datos (ETL)

 Aproximación de primera generación (o crecimiento

‘casero’)
 Mapean origen a destino con capacidades variables
de transformación y limpieza
 Generan código o directamente deben programarse
 Suelen controlar metadatos limitados

FUENTE: Doug Hackney, 1998

76
 Plataformas de Integración de Datos

 Soluciones integradas
 Capacidad de implantación a nivel corporativo
 Metadatos completos, abiertos y extensibles
 Abanico de transformaciones y reglas de negocio
 Análisis, entrega y planificación integradas
 Gestión Ad-hoc de agregaciones
 Monitorización y Auditoría integradas
 Funciones avanzadas de Calidad de Datos
 Versionados, despliegues inteligentes
77
 Proceso de Diseño

2. IMPORTACIÓN DE
DEFICIONES DE ORÍGENES
1. CREACIÓN DE
REPOSITORIO

4. CREACIÓN DE
MAPPINGS Def Origen

Mapeo
3. CREACIÓN DE ESQUEMA
Def Destino DESTINO

78
 Transformaciones Más Comunes
 Creación de valores por defecto para los nulos
 Gestión de fechas
 Selección o filtrado de datos origen
 Unión de orígenes heterogéneos
(SAP+Ficheros+Tablas+…)
 Normalización de los ficheros de datos
 Generación de esquemas en estrella
 Creación de estrategias de actualización
 Creación y actualización de agregaciones
 Creación de dimensiones ‘slowly-changing’

79
 Algunas Transformaciones
Selección de datos del Origen representa la consulta o primer filtrado/ordenación de los
datos origen

Normalización convierte registros de orígenes relacionales o VSAM a registros

normalizados (cláusulas OCCURS, REDEFINES)

Cálculo de Expresiones/Nuevos Campos realiza cálculos a nivel de campo

Filtro funciona como un filtro condicional de los registros procesados
Agregación realiza cálculos agregados (totales o incrementales)
Rango limita los registros a los primeros o últimos de un rango
Estrategia de Actualización para marcar cada registro como inserción, actualización,
borrado, o registro rechazado
Lookup busca valores complementarios y los pasa a otros objetos
Procedimientos Externos/Almacenados llama a programas desarrollados en otros
lenguajes o en la base de datos
Generador de Secuencia genera nuevos identificadores únicos

80
 Trabajo con Transformaciones
Ejemplo: Estrategia de Actualización

EXTRACCIÓN ESTRATEGIA DE
ORIGEN DEL ORIGEN LOOKUP ACTUALIZACIÓN DESTINO
Busca Basado en la
Job_IDs coincidencia de
en el Job_IDs,
destino
T_JOBS

81
 Diseño de Cargas

 Ordene los datos por secuencias específicas de

carga
 Fuerce a reglas limitadas de integridad de datos
 Busque la carga correcta de cada paso
 Construya estadísticas de carga y mensajes de
error
 Cree el plan para cargas fallidas – qué debe ocurrir
 Produzca la notificación inmediata y automática en
caso de fallos (y/o éxitos) en las cargas

FUENTE: O’Neil, 1997

82
 Consejos sobre Planificación de Cargas
 Orden de carga – cargue primero las tablas independientes
 Determine la ventana necesaria de carga – use las horas de
inicio y final para determinar el tiempo necesario para las cargas

 Ejecute cargas en paralelo

 Ejecución concurrente
 Uso de threads, desarrollos multiproceso, paralelización de
base de datos
 No sobrecargue los sistemas origen o destino

 Carque en paralelo un mismo destino

 Datos de sistemas independientes que van al mismo destino

 Cargue múltiples destinos en paralelo

 Datos del mismo origen que vayan a diferentes destinos –
ahorre accesos de lectura

83
 Plan de Carga de Destinos

 Primero, tablas independientes

 Después, tablas que no contienen claves foráneas
a otras tablas
 Por último, las tablas que contienen claves
foráneas a otras tablas
 Tenga cuidado con transacciones de base de
datos e intervalos de commit: los datos pueden
estar cargados pero no validados

84
 Planificación de Cargas

Timing Planificación
 Planificación propio
 Ejecución manual
de la herramienta
 Ejecución periódica
 cada n minutos/horas/días  Planificador genérico
 un máximo de veces/  Control^M, Tareas
para siempre Programadas de Windows
 Ejecución concreta
 Scripts de carga (.bat, .sh, JCL)
 En un momento determinado
 Cada primer martes de mes a las 21:43
 Ejecución basada en eventos
 Disponibilidad del fichero origen
 Sólo si la carga anterior acabó bien/mal

85
 Monitorización de Cargas

El mantenimiento de un data mart es una

revisión constante de los procesos para
optimizar valores de datos, pasos, tiempos,
recursos utilizados, accesos a sistemas
origen o destino … debido a los constantes
requerimientos nuevos de los usuarios finales
y el crecimiento en funcionalidad y volumen
de datos que eso conlleva

86
 La Creación de un Data Warehouse
Sostenible y sus Data Marts
Incrementales
Requiere la Automatización
de los Procesos de Carga

87
 Fundamentos del DWH
Herramientas de Integración de Datos

88
 Integración de Datos, más allá del BI

 El ETL se ha quedado relegado a entornos

analíticos
 Aparecen necesidades de Integración de datos
para otro tipo de proyectos
 Externalización
 Migraciones
 Integración de Aplicaciones, BBDD
 Sincronización
 etc

89
 ¿Un proceso simple?

ETL

90
 Ensanchando el concepto de Integración de Datos
EIM, Content
Management Metadatos

Complex Data Grid Data Web

Data
Data Services
Profiling
Exchange (SOA)
High
Availability Quality

Real ETL Federation

Time
EAI DWL
Aplicaciones
y BI
Midleware Changed
Data Mainframe
Auditing
Team Base
(BO, SAS, Microstrategy,
Hyperion, Cognos …)
(SAP, Siebel, TIBCO, Biztalk, …) Scheduling
Capture Develop/

Bases de Datos
91 (Oracle, Microsoft, IBM, …)
 Acceso Universal a los Datos
Entrega de datos a Sistemas, Procesos y Organizaciones

Systems IBM MQSeries Web Services

XML
TIBCO
webMethods JMS
SAP NetWeaver XI ODBC…
XML, Messaging,
and Web Services
SAP NetWeaver Peoplesoft
SAP IDOC Oracle Apps
SAP BCI Siebel
SAP DMI SAS…
SAP BW
Packaged
Applications
Oracle Informix
DB2 UDB Teradata
DB2/400 ODBC
SQL Server Flat Files
Sybase Web Logs …
Relational and
Flat Files ADABAS VSAM
Datacom C-ISAM
DB2 Complex Files
IDMS Tape Formats…
IMS

Mainframe
and Midrange Flat Files, XLS, PPT Oracle
FTP SQL Server
Encrypted Stream Industry Formats
XML, PDF, DOC, …
Etc etc ….

92
 Informatica PowerCenter
Puntos de interés como plataforma de integración de datos (1/2)

 Permite integrar múltiples fuentes de datos heterogéneas

 Desarrollo de alta productividad
 Herramientas de trabajo visuales. Interfaz gráfico totalmente intuitivo
 Asistentes de transformación
 NO hay generación de código
 Detección de errores (debugger integrado)
 Reutilización de componentes
 Fácil de mantener: Metadatos corporativos
 Análisis de Impacto
 Análisis del Linaje de datos
 Presentación Web Metadatos y Autodocumentación
 Metadatos extensibles
 Despliegues guiados. Rollback
 Versionado
93
 Informatica PowerCenter
Puntos de interés como plataforma de integración de datos (2/2)

 Plataforma de Alto rendimiento

 Grid computing
 Alta Disponibilidad
 Tolerancia a fallos y recuperación automática
 Soporte a cargas BULK
 Capacidades de Tiempo real
 Conectores WebServices, ESB, EAI
 Adaptabilidad y escalabilidad
 Plataforma, recursos, volumen y usuarios
 Capacidad de expandir las Transformaciones con módulos
externos (PL/Sql, C++, …)
 Autodocumentación
 Planificador integrado

94
 Informatica PowerCenter
“Trabajar como pienso” Del papel …

TABLA REFERENCIA DESTINO

MAESTRO DATAWAREHOUSE

DETALLE UNION TOTALES SALIDA_XML

95
 Informatica PowerCenter
… a la práctica

96
 Informatica PowerCenter Metadata Reporter
Presentación web de los metadatos del repositorio

97
 Fundamentos del DWH
Herramientas de Reporting y Análisis

98
 Tipos de Herramientas OLAP

 Herramientas de Consulta y Generación de

Informes
 Consultas Ad Hoc
 Herramientas EIS
 Herramientas de Data Mining
 Herramientas basadas en Web

99
 On-Line Analytic Processing - (OLAP)

 Perspectiva ‘multidimensional’ de los datos

 pueden ser vistos como ‘cuadrículas’ de datos

 Consulta interactiva de datos

 seguimiento de un flujo de información mediante múltiples
pasos de “drill-down”

 Los resultados son mostrados como tablas

cruzadas, o tablas pivotantes
 Capacidades de modelización
(incluyendo un motor de cálculos)

 Usado para análisis de previsiones,

tendencias y estadísticas
100 FUENTE: Neil Raden, 1995
 Características del Procesamiento OLAP

 Acceden a volúmenes de datos ENORMES

 Analizan las relaciones entre muchas
dimensiones
 Involucran a datos agregados (ventas,
presupuestos, beneficios, etc.)
 Comparan datos agregados a lo largo del
tiempo
 Presentan los datos en diferentes jerarquías
 Realizan cálculos complejos
 Pueden responder rápidamente a los usuarios

101
 Motores Relacionales:

 Almacenan los datos como líneas (registros)

en tablas
 Todos siguen el mismo modelo relacional
 Se accede a ellos a través de un lenguaje
común - SQL
 Tienen aproximadamente el mismo conjunto
de funcionalidades

102
 OLAP Relacional:

 Permite el acercamiento mayor a las percepciones de

los usuarios
 NO requiere la regeneración de la base de datos si
cambian las dimensiones
 No requiere más trabajo de front-end
 Posiblemente requiere menos re-trabajo a lo largo del
tiempo
 ESTÁ limitado por un conjunto de funciones
disponibles
 Permite una granularidad más flexible en los datos

103
 OLAP Relacional (total):

 Posee un potente generador SQL, capaz de crear

consultas multi-pasada
 Puede crear rangos no triviales, comparaciones y
cálculos de porcentajes respecto al total
 Genera SQL optimizado, con extensiones
 Usa metadatos para modelos / consultas
 Está siendo promocionado por los fabricantes de
BBDD

104
 OLAP Multidimensional

 Refleja los pensamientos de los usuarios sobre la

actividad del negocio
 Hace referencia a cubos de datos
 Los cubos de más de tres dimensiones se conocen
como hipercubos
 El modelo de datos representado por el hipercubo
es un modelo multidimensional
 Cualquier base de datos que pueda almacenar y
representar ese modelo es una BD multidimensional
FUENTE: O’Neil, 1997

105
 Bases de Datos Multidimensionales:
el ‘HiperCubo’

Ti
m
e
Customer

Product
MÁS:
Región
Territorio
Vendedor
Etc.
106
 OLAP Multidimensional

 Normalmente almacena los datos como vectores

internos
 Proporciona un gran rendimiento ante las consultas
 Porque los datos han sido preparados previamente
dentro de la estructura
 A veces limitado a un número concreto de celdas del
cubo

 Dispone de librerías especiales de funciones

 Cambios en la estructura dimensional pueden requerir
la regeneración del cubo
 Requiere recursos que administren la generación de
las estructuras
107
 . . . La ‘Zona de Guerra’

 ROLAP  MOLAP
 SQL ‘Estándar’  Propietario (SQL)
 Tablas/Registros  Vectores/Cubos
 Respuesta más lenta  Respuesta muy rápida
 Consultas de SQL flexibles Consultas predefinidas
 Funciones limitadas  Funciones especiales
 Uso de perfiles existentes  Nuevos perfiles de
desarrollo

108
 Argumentos de MOLAP contra ROLAP

 Los gestores de bases de datos relacionales no

gestionan las relaciones multidimensionales con
eficiencia
 Inherentemente de dos dimensiones
 El SQL no es obvio para los usuarios finales
 Las uniones múltiples y el pobre rendimiento son un
serio problema
 Las tablas denormalizadas absorben el rendimiento y
los recursos

109
 Argumentos de ROLAP contra MOLAP

 Los cubos ofrecen niveles limitados de detalle

 No están de acuerdo con el modelo dimensional
 Las MDDs no disponen de un un método de acceso
estándar (como SQL)
 No se pueden cambiar las dimensiones sin regenerar
completamente el cubo
 El ámbito de cada producto y su funcionalidad para el
soporte a decisiones pueden variar ampliamente
 Cada herramienta es prácticamente de una categoría
diferente

110
 Data Mining

 Análisis del Warehouse

 Comienza con una hipótesis
 Busca aquellos datos que soportan esa hipótesis.
 Muestra los clientes mayores que (asumimos que) compran
los artículos más caros

 Data mining
 El proceso crea la teoría en base a la navegación
automática por los datos
 ¿Quién compra realmente los artículos más caros?
 ¿Cuáles son sus nombres para el mercado indicado?

FUENTE: Computerworld, March 29, 1999

111
 Herramientas de Data Mining:

 Requieren datos detallados históricos

 Requieren una calidad de datos muy alta

 Buscan patrones de comportamiento

 Necesitan una selección equilibrada de

variables

FUENTE: ComputerWorld, Mar 29, 1999

112
 Selección de Herramientas Finales:

 Debería ocurrir MÁS TARDE en el proceso

 La CLAVE de la selección de la herramienta son los usuarios

finales: es la única parte que verán de todo el proyecto de DW

 Enfóquese hacia los requerimientos que solucionan problemas

técnicos y de negocio importantes para diferenciarlas

 Involucre a los usuarios finales que usarán las herramientas

 Compruebe sus funciones, facilidad de uso, integración,

metadatos, cuota de mercado y estabilidad

FUENTE: O’Neil, 1997 (y others)

113
 Múltiples Necesidades = Múltiples
Herramientas

 La realidad del data mart es que

necesitará múltiples herramientas para
dar soporte a los diferentes usuarios
 Use un número manejable de estas
herramientas
 Estas herramientas deberían ser
consideradas en los cambios de
tecnología y necesidades de usuarios

114
 Sin Datos de Calidad
todo lo que Tenemos
son Opiniones

115
116