Creando el próximo Data Warehouse:  Integración y Calidad de Datos Sesión 1: Fundamentos del DWH Alberto Collado
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
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
Presentación PowerData
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
La solución: los servicios de datos Servicios de datos Servicios de datos Proyectos de integración de datos Iniciativas de TI Necesidades empresariales Almacenamiento  de datos Consolidación  de datos Migración  de datos Sincronización  de datos Gestión de  datos maestros Eliminación  de sistemas  heredados BPO SaaS Hubs de productos,  proveedores  y clientes Consolidación de aplicaciones Inteligencia empresarial Subcontratar funciones secundarias Aumentar la rentabilidad del negocio Fusiones y adquisiciones Modernizar el negocio y reducir los costes de TI Mejorar decisiones y cumplir con la normativa Informatica PowerExchange Informatica Data Explorer Informatica PowerCenter Informatica Data Quality Plataforma de productos de Informatica
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 Acceso A cualquier sistema, por lotes o en tiempo real Limpieza Detección Validar, corregir y estandarizar datos de todo tipo Buscar y perfilar cualquier tipo de datos de cualquier fuente Desarrollo y gestión Desarrollar y colaborar con un repositorio común y metadatos compartidos Data Explorer Data Quality PowerCenter PowerExchange Entrega Integración Entregar los datos adecuados en el momento y formato adecuados Transformar y conciliar datos de todo tipo
Presentación Asistentes:  Conocimientos y Expectativas
Fundamentos del DWH
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
Fundamentos del DWH Introducción al DWH: ¿Qué es?
¿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
Orientado a Tema Los usuarios piensan en términos de ‘ cosas ’ y sus ‘ relaciones ’, no en términos de procesos, funciones o aplicaciones. Proveedor Orden de Compra Pedido Cliente Producto Inventario Proporciona Compuesta por Recuperado  desde Contiene Realiza
Integrado Contiene Convenciones de Nombres Descripciones Atributos físicos de los datos Valores de los datos Consistentes Datos Ventas Marketing Admin. Cuentas Operaciones
Variable en el tiempo Entorno Operacional Datos con valores actuales Horizonte de 30 - 90 días Exactitud en los accesos Id de cliente fecha desde fecha hasta nombre dirección  teléfono ratio de crédito Data Warehouse Datos en ‘fotos’ Horizonte de 5 – 10 años Refleja la perspectiva desde un momento en el tiempo Id de cliente nombre dirección teléfono ratio de crédito
No-Volátil Sistema OLTP  (dinámico) Sistema DSS (más estático) cambio inserción borrado carga lectura
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
¿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 … €€€
Visión del Usuario 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 . Usuarios Finales Base de Datos Representación de Negocio Panel de Consulta
Fundamentos del DWH Arquitectura de un DWH
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
Directo de OLTP a OLAP
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
Data Warehouse Virtual: Directo o Federado EII
Data Warehouse “Total”
Data Marts No Estructurados
Data Marts Estructurados
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.
Ejemplo uso de una herramienta de consulta  El interfaz de usuario simple Trabaja contra representación de negocio de los datos Todos los componentes en una pantalla Información solicitada Condiciones Información disponible
Los informes son la capa visible … Integración Datos no sólo en entornos analíticos Importancia de la Calidad Extracción Limpieza de Datos Servidores Red Herramientas de OLAP / Business Intelligence / Cuadro de Mando Transformación Carga de Datos Bases de Datos Middleware
Data Marts Estructurados: Visión Completa
Fundamentos del DWH Modelado de Datos y Metadatos
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
Consideraciones de Tiempo 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?
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)
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) 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) Ú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
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
Trazado de Auditoría Guarda los cambios de los datos de interés Información: Fecha del cambio Razón del cambio Cómo se ha detectado ... Sólo se extraen/cargan valores modificados
Trazado de Auditoría 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
Técnicas de Optimización Estructural y Física
Técnicas de Optimización Derivación Data Warehouse y Data Marts Usos Facilitar acceso Consistencia resultados
Técnicas de Optimización Agregación No cambio de granularidad Objetivo: Facilitar el acceso a los datos Data Warehouse Data Marts
Técnicas de Optimización Sumarización Histórica Agrupada
Técnicas de Optimización Particionamiento Horizontal Particiones por filas Todos los campos repetidos en las nuevas tablas Uso Aislar datos sensibles Reducción tamaño tablas
Técnicas de Optimización Particionamiento Vertical División por columnas Posibilidad de columnas redundantes Uso Seguridad Distribución Puede ser que tengamos Horizontal y Vertical a la vez
Técnicas de Optimización Particionamiento por Estabilidad Basado en frecuencia de cambio Uso en Staging Area Velocidad de carga Separar datos más volátiles minimiza cambios Claves Primarias en ambas tablas Metadatos a Nivel Registro en ambas tablas
Técnicas de Optimización Claves Alternativas Caso especial de derivación  Creada artificialmente para identificar entidades Habitualmente un entero Staging   DW    DM Hay que mantener un mapeo Generación Claves Alternativas
Técnicas de Optimización Pre-Joins Caso especial de Agregación Data Warehouse y Data Marts Existe redundancia de Información Incrementeo uso espacio Acceso mucho más rápido En el DW Mantendremos también las tablas separadas para cuando no necesitemos la Join
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
Técnicas de Optimización Balancear diferentes Factores
Fundamentos del DWH Esquemas en Estrella
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
Modelización Dimensional -  Regla de Oro Los Esquemas en Estrella  deberían  ser utilizados para cualquier dato accedido directamente por los usuarios finales.
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
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
Esquema en Estrella (conceptual)
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
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?
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?
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
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
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
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
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
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 . . .”
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)
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.
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.
Ejemplo: Preguntas a la División Financiera 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.
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.
Ejemplo: El Esquema Financiero en Estrella
Fundamentos del DWH Procesos y Estrategias de Carga del DWH
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
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
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
Proceso de Diseño Def Origen 2. IMPORTACIÓN DE DEFICIONES DE ORÍGENES Def Destino 3. CREACIÓN DE ESQUEMA DESTINO Mapeo  4.  CREACIÓN DE MAPPINGS 1.  CREACIÓN DE REPOSITORIO
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’
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
Trabajo con Transformaciones DESTINO ESTRATEGIA DE ACTUALIZACIÓN Basado en la coincidencia de Job_IDs,  LOOKUP Busca Job_IDs en el  destino T_JOBS ORIGEN EXTRACCIÓN DEL ORIGEN Ejemplo: Estrategia de Actualización
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
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
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
Timing Ejecución manual Ejecución periódica  cada n minutos/horas/días un máximo de veces/ para siempre Ejecución concreta 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 Planificación de Cargas Planificación Planificación propio  de la herramienta Planificador genérico Control^M, Tareas  Programadas de Windows Scripts de carga (.bat, .sh, JCL)
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 Monitorización de Cargas
La Creación de un Data Warehouse Sostenible y sus Data Marts Incrementales  Requiere la Automatización  de los Procesos de Carga
Fundamentos del DWH Herramientas de Integración de Datos
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
¿Un proceso simple ? ETL
Ensanchando el concepto de Integración de Datos EIM, Content Management Aplicaciones y Midleware (SAP, Siebel, TIBCO, Biztalk, …) BI (BO, SAS, Microstrategy,  Hyperion, Cognos …) Bases de Datos (Oracle, Microsoft, IBM, …) EAI Real Time Scheduling Changed Data  Capture Complex Data Exchange Mainframe ETL Data Grid High Availability Data Profiling DWL Auditing Data Quality Team Base  Develop/ Federation Web Services (SOA) Mucho más que ETL Metadatos
IBM MQSeries TIBCO  webMethods SAP NetWeaver XI SAP NetWeaver SAP IDOC SAP BCI SAP DMI SAP BW Oracle DB2 UDB DB2/400 SQL Server Sybase ADABAS Datacom DB2 IDMS IMS Flat Files, XLS, PPT FTP Encrypted Stream XML, PDF, DOC, … Informix Teradata ODBC Flat Files Web Logs … VSAM C-ISAM Complex Files Tape Formats… Web Services XML JMS ODBC… Peoplesoft Oracle Apps Siebel SAS… Oracle SQL Server Industry Formats Acceso Universal a los Datos Entrega de datos a Sistemas, Procesos y Organizaciones Etc etc …. XML, Messaging,  and Web Services Packaged Applications Relational and Flat Files Mainframe  and Midrange Systems
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
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
Informatica PowerCenter   “Trabajar como pienso” Del papel … MAESTRO DETALLE UNION TABLA REFERENCIA TOTALES DESTINO DATAWAREHOUSE SALIDA _ XML
Informatica PowerCenter   … a la práctica
Informatica PowerCenter Metadata Reporter  Presentación web de los metadatos del repositorio
Fundamentos del DWH Herramientas de Reporting y Análisis
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
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 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
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
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
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
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
Bases de Datos Multidimensionales: el ‘HiperCubo’ MÁS: Región Territorio Vendedor Etc.
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
. . . La ‘Zona de Guerra’ MOLAP Propietario (SQL) Vectores/Cubos Respuesta muy rápida Consultas predefinidas Funciones especiales Nuevos perfiles de desarrollo ROLAP SQL ‘Estándar’ Tablas/Registros Respuesta más lenta Consultas de SQL flexibles Funciones limitadas Uso de perfiles existentes
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
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
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
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
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)
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
Sin  Datos  de  Calidad  todo lo que Tenemos son  Opiniones
 

Fundamentos dw

  • 1.
    Creando el próximoData Warehouse: Integración y Calidad de Datos Sesión 1: Fundamentos del DWH Alberto Collado
  • 2.
    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
  • 3.
    Agenda Sesión 1Presentació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
  • 4.
  • 5.
    Presentación PowerData Empresalider 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
  • 6.
    La solución: losservicios de datos Servicios de datos Servicios de datos Proyectos de integración de datos Iniciativas de TI Necesidades empresariales Almacenamiento de datos Consolidación de datos Migración de datos Sincronización de datos Gestión de datos maestros Eliminación de sistemas heredados BPO SaaS Hubs de productos, proveedores y clientes Consolidación de aplicaciones Inteligencia empresarial Subcontratar funciones secundarias Aumentar la rentabilidad del negocio Fusiones y adquisiciones Modernizar el negocio y reducir los costes de TI Mejorar decisiones y cumplir con la normativa Informatica PowerExchange Informatica Data Explorer Informatica PowerCenter Informatica Data Quality Plataforma de productos de Informatica
  • 7.
    La plataforma deproductos 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 Acceso A cualquier sistema, por lotes o en tiempo real Limpieza Detección Validar, corregir y estandarizar datos de todo tipo Buscar y perfilar cualquier tipo de datos de cualquier fuente Desarrollo y gestión Desarrollar y colaborar con un repositorio común y metadatos compartidos Data Explorer Data Quality PowerCenter PowerExchange Entrega Integración Entregar los datos adecuados en el momento y formato adecuados Transformar y conciliar datos de todo tipo
  • 8.
    Presentación Asistentes: Conocimientos y Expectativas
  • 9.
  • 10.
    Fundamentos del DWHIntroducció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
  • 11.
    Fundamentos del DWHIntroducción al DWH: ¿Qué es?
  • 12.
    ¿Qué es unData 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
  • 13.
    Orientado a TemaLos usuarios piensan en términos de ‘ cosas ’ y sus ‘ relaciones ’, no en términos de procesos, funciones o aplicaciones. Proveedor Orden de Compra Pedido Cliente Producto Inventario Proporciona Compuesta por Recuperado desde Contiene Realiza
  • 14.
    Integrado Contiene Convencionesde Nombres Descripciones Atributos físicos de los datos Valores de los datos Consistentes Datos Ventas Marketing Admin. Cuentas Operaciones
  • 15.
    Variable en eltiempo Entorno Operacional Datos con valores actuales Horizonte de 30 - 90 días Exactitud en los accesos Id de cliente fecha desde fecha hasta nombre dirección teléfono ratio de crédito Data Warehouse Datos en ‘fotos’ Horizonte de 5 – 10 años Refleja la perspectiva desde un momento en el tiempo Id de cliente nombre dirección teléfono ratio de crédito
  • 16.
    No-Volátil Sistema OLTP (dinámico) Sistema DSS (más estático) cambio inserción borrado carga lectura
  • 17.
    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
  • 18.
    ¿Para qué construirun 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 … €€€
  • 19.
    Visión del UsuarioSolució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 . Usuarios Finales Base de Datos Representación de Negocio Panel de Consulta
  • 20.
    Fundamentos del DWHArquitectura de un DWH
  • 21.
    Arquitectura de unDWH 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
  • 22.
  • 23.
    Directo de OLTPa 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
  • 24.
    Data Warehouse Virtual:Directo o Federado EII
  • 25.
  • 26.
    Data Marts NoEstructurados
  • 27.
  • 28.
    OLAP (OnlineAnalytic 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.
  • 29.
    Ejemplo uso deuna herramienta de consulta El interfaz de usuario simple Trabaja contra representación de negocio de los datos Todos los componentes en una pantalla Información solicitada Condiciones Información disponible
  • 30.
    Los informes sonla capa visible … Integración Datos no sólo en entornos analíticos Importancia de la Calidad Extracción Limpieza de Datos Servidores Red Herramientas de OLAP / Business Intelligence / Cuadro de Mando Transformación Carga de Datos Bases de Datos Middleware
  • 31.
    Data Marts Estructurados:Visión Completa
  • 32.
    Fundamentos del DWHModelado de Datos y Metadatos
  • 33.
    Técnicas de ModelizaciónEstructural En esta sección veremos técnicas que afectarán a diversos puntos Consideraciones de Tiempo Técnicas de Optimización
  • 34.
    Consideraciones de TiempoTodo 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?
  • 35.
    Técnicas de ModelizaciónTemporal 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)
  • 36.
    Foto (Snapshot) Dostécnicas diferentes Múltiples Tablas Tabla Única Uso de Fecha Efectiva Inicio en un ejemplo. Metadatos a nivel de registro
  • 37.
    Foto (Snapshot) MúltipleUna 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
  • 38.
    Foto (Snapshot) ÚnicaSe 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
  • 39.
    Foto (Snapshot) ÚnicaFechas (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
  • 40.
    Trazado de AuditoríaGuarda los cambios de los datos de interés Información: Fecha del cambio Razón del cambio Cómo se ha detectado ... Sólo se extraen/cargan valores modificados
  • 41.
    Trazado de AuditoríaSó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
  • 42.
    Técnicas de OptimizaciónEstructural y Física
  • 43.
    Técnicas de OptimizaciónDerivación Data Warehouse y Data Marts Usos Facilitar acceso Consistencia resultados
  • 44.
    Técnicas de OptimizaciónAgregación No cambio de granularidad Objetivo: Facilitar el acceso a los datos Data Warehouse Data Marts
  • 45.
    Técnicas de OptimizaciónSumarización Histórica Agrupada
  • 46.
    Técnicas de OptimizaciónParticionamiento Horizontal Particiones por filas Todos los campos repetidos en las nuevas tablas Uso Aislar datos sensibles Reducción tamaño tablas
  • 47.
    Técnicas de OptimizaciónParticionamiento Vertical División por columnas Posibilidad de columnas redundantes Uso Seguridad Distribución Puede ser que tengamos Horizontal y Vertical a la vez
  • 48.
    Técnicas de OptimizaciónParticionamiento por Estabilidad Basado en frecuencia de cambio Uso en Staging Area Velocidad de carga Separar datos más volátiles minimiza cambios Claves Primarias en ambas tablas Metadatos a Nivel Registro en ambas tablas
  • 49.
    Técnicas de OptimizaciónClaves Alternativas Caso especial de derivación Creada artificialmente para identificar entidades Habitualmente un entero Staging  DW  DM Hay que mantener un mapeo Generación Claves Alternativas
  • 50.
    Técnicas de OptimizaciónPre-Joins Caso especial de Agregación Data Warehouse y Data Marts Existe redundancia de Información Incrementeo uso espacio Acceso mucho más rápido En el DW Mantendremos también las tablas separadas para cuando no necesitemos la Join
  • 51.
    Técnicas de OptimizaciónCadenas de Datos Caso especial de Agregación Eficiente para Reporting NUNCA en operacionales o Staging, pero muy útil en DW y DM
  • 52.
    Técnicas de OptimizaciónBalancear diferentes Factores
  • 53.
    Fundamentos del DWHEsquemas en Estrella
  • 54.
    Puntos Fuertes dela 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
  • 55.
    Modelización Dimensional - Regla de Oro Los Esquemas en Estrella deberían ser utilizados para cualquier dato accedido directamente por los usuarios finales.
  • 56.
    El Esquema enEstrella 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
  • 57.
    Modelización Dimensional Tablasde 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
  • 58.
    Esquema en Estrella(conceptual)
  • 59.
    Diseño de unaTabla 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
  • 60.
    Identifique el ProcesoDepartamental ¿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?
  • 61.
    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?
  • 62.
    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
  • 63.
    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
  • 64.
    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
  • 65.
    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
  • 66.
    La Dimensión deTiempo 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
  • 67.
    Establezca Relaciones Dibujela relación visualmente Identifique la cardinalidad (1-N) Entre la tabla de hechos . . . y cada tabla de dimensión “ Una Imagen vale más . . .”
  • 68.
    Métodos para IdentificarDimensiones 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)
  • 69.
    Ejemplo: Intereses dela 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.
  • 70.
    Ejemplo: Frase deEjemplo 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.
  • 71.
    Ejemplo: Preguntas ala División Financiera 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.
  • 72.
    Ejemplo: Preguntas ala 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.
  • 73.
    Ejemplo: El EsquemaFinanciero en Estrella
  • 74.
    Fundamentos del DWHProcesos y Estrategias de Carga del DWH
  • 75.
    Mapeo de DatosMapeo 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
  • 76.
    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
  • 77.
    Plataformas de Integraciónde 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
  • 78.
    Proceso de DiseñoDef Origen 2. IMPORTACIÓN DE DEFICIONES DE ORÍGENES Def Destino 3. CREACIÓN DE ESQUEMA DESTINO Mapeo 4. CREACIÓN DE MAPPINGS 1. CREACIÓN DE REPOSITORIO
  • 79.
    Transformaciones Más ComunesCreació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’
  • 80.
    Algunas Transformaciones Selecciónde 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
  • 81.
    Trabajo con TransformacionesDESTINO ESTRATEGIA DE ACTUALIZACIÓN Basado en la coincidencia de Job_IDs, LOOKUP Busca Job_IDs en el destino T_JOBS ORIGEN EXTRACCIÓN DEL ORIGEN Ejemplo: Estrategia de Actualización
  • 82.
    Diseño de CargasOrdene 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
  • 83.
    Consejos sobre Planificaciónde 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
  • 84.
    Plan de Cargade 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
  • 85.
    Timing Ejecución manualEjecución periódica cada n minutos/horas/días un máximo de veces/ para siempre Ejecución concreta 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 Planificación de Cargas Planificación Planificación propio de la herramienta Planificador genérico Control^M, Tareas Programadas de Windows Scripts de carga (.bat, .sh, JCL)
  • 86.
    El mantenimiento deun 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 Monitorización de Cargas
  • 87.
    La Creación deun Data Warehouse Sostenible y sus Data Marts Incrementales Requiere la Automatización de los Procesos de Carga
  • 88.
    Fundamentos del DWHHerramientas de Integración de Datos
  • 89.
    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
  • 90.
  • 91.
    Ensanchando el conceptode Integración de Datos EIM, Content Management Aplicaciones y Midleware (SAP, Siebel, TIBCO, Biztalk, …) BI (BO, SAS, Microstrategy, Hyperion, Cognos …) Bases de Datos (Oracle, Microsoft, IBM, …) EAI Real Time Scheduling Changed Data Capture Complex Data Exchange Mainframe ETL Data Grid High Availability Data Profiling DWL Auditing Data Quality Team Base Develop/ Federation Web Services (SOA) Mucho más que ETL Metadatos
  • 92.
    IBM MQSeries TIBCO webMethods SAP NetWeaver XI SAP NetWeaver SAP IDOC SAP BCI SAP DMI SAP BW Oracle DB2 UDB DB2/400 SQL Server Sybase ADABAS Datacom DB2 IDMS IMS Flat Files, XLS, PPT FTP Encrypted Stream XML, PDF, DOC, … Informix Teradata ODBC Flat Files Web Logs … VSAM C-ISAM Complex Files Tape Formats… Web Services XML JMS ODBC… Peoplesoft Oracle Apps Siebel SAS… Oracle SQL Server Industry Formats Acceso Universal a los Datos Entrega de datos a Sistemas, Procesos y Organizaciones Etc etc …. XML, Messaging, and Web Services Packaged Applications Relational and Flat Files Mainframe and Midrange Systems
  • 93.
    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
  • 94.
    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
  • 95.
    Informatica PowerCenter “Trabajar como pienso” Del papel … MAESTRO DETALLE UNION TABLA REFERENCIA TOTALES DESTINO DATAWAREHOUSE SALIDA _ XML
  • 96.
    Informatica PowerCenter … a la práctica
  • 97.
    Informatica PowerCenter MetadataReporter Presentación web de los metadatos del repositorio
  • 98.
    Fundamentos del DWHHerramientas de Reporting y Análisis
  • 99.
    Tipos de HerramientasOLAP Herramientas de Consulta y Generación de Informes Consultas Ad Hoc Herramientas EIS Herramientas de Data Mining Herramientas basadas en Web
  • 100.
    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 FUENTE: Neil Raden, 1995
  • 101.
    Características del ProcesamientoOLAP 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
  • 102.
    Motores Relacionales: Almacenanlos 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
  • 103.
    OLAP Relacional: Permiteel 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
  • 104.
    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
  • 105.
    OLAP Multidimensional Reflejalos 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
  • 106.
    Bases de DatosMultidimensionales: el ‘HiperCubo’ MÁS: Región Territorio Vendedor Etc.
  • 107.
    OLAP Multidimensional Normalmentealmacena 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
  • 108.
    . . .La ‘Zona de Guerra’ MOLAP Propietario (SQL) Vectores/Cubos Respuesta muy rápida Consultas predefinidas Funciones especiales Nuevos perfiles de desarrollo ROLAP SQL ‘Estándar’ Tablas/Registros Respuesta más lenta Consultas de SQL flexibles Funciones limitadas Uso de perfiles existentes
  • 109.
    Argumentos de MOLAPcontra 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
  • 110.
    Argumentos de ROLAPcontra 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
  • 111.
    Data Mining Análisisdel 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
  • 112.
    Herramientas de DataMining: 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
  • 113.
    Selección de HerramientasFinales: 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)
  • 114.
    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
  • 115.
    Sin Datos de Calidad todo lo que Tenemos son Opiniones
  • 116.