Introducción al Data Warehousing

Transcripción

1 Introducción al Data Warehousing Universidad Tecnológica Metropolitana Facultad de Ingeniería Dpto. de Informática y Computación SZC

2 Indice de contenidos INTRODUCCION CONCEPTOS BÁSICOS CONSTRUCCIÓN DE UN DW ESTRUCTURACIÓN DE DATOS MODELO DE CICLO DE VIDA CALIDAD FUTURO 2

3 INTRODUCCION Objetivo Problema Qué es Data Warehousing La solución actual Procesamiento clásico: OLTP Procesamiento orientado a la decisión: OLAP DW entre OLTP y OLAP Una solución software 3

4 Objetivo Ofrecer información útil a los empleados de la empresa que están encargados de analizar el funcionamiento de la misma y tomar decisiones al respecto. DATOS DEL FUNCIONAMIENTO DE LA EMPRESA DECISIONES 4

5 Problema Las organizaciones manejan enormes cantidades de datos. Esos datos suelen: Estar en distintos formatos. Residir en distintas plataformas. Estar almacenados usando distintos tipos de ficheros. Estar organizados utilizando distintos gestores de BD. Consecuencia: Dificultad de acceso y de uso. La organización tiene que escribir y mantener gran cantidad de código para extraer, preparar e integrar los datos que tiene para poder usarlos en aplicaciones de análisis e informe. 5

6 Qué es Data Warehousing? Data warehousing es el diseño e implementación de procesos, herramientas y facilidades para manejar y proporcionar información completa, oportuna, correcta y entendible para la toma de decisiones. 6

7 La solución actual Utilizar técnicas de Data Warehousing: Acceso a fuentes de datos heterogéneas: Limpiado de datos Filtrado de datos Transformación de datos Almacenamiento de información relevante en una estructura de datos: Fácil de acceder. Fácil de entender. Fácil de usar. 7

8 Procesamiento clásico: OLTP OLTP: On-line Transaction Processing Las aplicaciones de tipo OLTP son estructuradas y repetitivas y consisten fundamentalmente en transacciones cortas, atómicas y aisladas. Requieren datos detallados y al día y afectan fundamentalmente a pocos registros a los cuales se accede principalmente a través de la llave primaria. Las bases de datos sobre las que se opera son de gran tamaño (cientos de megabytes o algunos gigabytes). La consistencia y recuperabilidad de las mismas son de vital importancia El criterio esencial de rendimiento es optimizar la gestión de transacciones. 8

9 Procesamiento orientado a la decisión: OLAP OLAP: On-line analytical processing Las aplicaciones de tipo OLAP están orientadas al soporte de decisiones. Los datos importantes son entonces aquellos que están consolidados, resumidos y de tipo histórico. El trabajo habitual de estos sistemas necesita la resolución de consultas complejas, fundamentalmente ad hoc, que pueden involucrar a millones de registros e implicar una serie de reuniones, búsquedas y agregaciones. Necesita estructuras de datos diferentes. El procesamiento de consultas y el tiempo de respuesta son más importantes que el tráfico de transacciones. 9

10 DW Buffer entre OLTP y OLAP SISTEMAS OLTP DATA WAREHOUSE SISTEMAS OLAP ESQUEMA OPERACIONAL DATOS OPERACIONALES ESQUEMA del DW DATOS RECONCILIADOS ESQUEMA de USUARIO DATOS DERIVADOS 10

11 Una solución software De dónde vienen los datos que hay en el Data Warehouse? Cómo se introducen los datos en el Data Warehouse? Cómo se mantienen? Cómo se estructuran los datos? Qué hay realmente en el Data Warehouse? 11

12 CONCEPTOS BÁSICOS 12 Qué es el Data Warehouse Bases de datos clásicas y DW Técnicas de análisis de datos Consultas e informes Análisis multidimensional Data mining Estructura básica de un DW Arquitectura del DW Data Marts Tipos de arquitectura: Global Distribuida Global Centralizada DMs Independientes DMs Interconectados Implementación de un DW Enfoques: Top-Down Bottom-up Combinado

13 Qué es el Data Warehouse? Data Warehouse (DW) Es un almacén de información integrada, incluyendo tanto datos operacionales como históricos, que proporciona datos para el procesamiento analítico y la toma de decisiones. Los datos en un DW son limpios (sin errores,ni imprecisión) resumidos y no-volátiles. 13

14 BD clásicas y DW Aspectos Bases de datos clásicas Data Warehouses Usuarios Función Diseñadores, DBAs, Operadores de entrada de datos Operaciones diarias (on-line) Procesamiento de transacciones Decisores, Ejecutivos, Expertos... Soporte de decisiones (online) Procesamiento analítico Diseño Orientado a aplicaciones Orientado al individuo Datos Actuales, atómicos, relacionales, aislados Uso Repetitivo, rutinario Ad hoc Acceso Lectura/escritura, transacciones simples (usualmente 2 ó 3 tablas) Necesidades Gestión de transacciones Datos consistentes Históricos, resumidos, multidimensionales, integrados Lectura (fundamentalmente) Consultas complejas Gestión de consultas Datos ajustados (organizados) 14

15 Técnicas de análisis de datos Consultas e informes Análisis Multidimensional Data Mining 15 Data Warehouse Data Mart

16 Consultas e informes El análisis para resolver consultas e informes conlleva: Recuperar información relevante del DW. Tranformar esa información al contexto adecuado. Mostrarla en un formato legible. Está conducido por analistas que plantean las preguntas para obtener una respuesta. 16

17 Proceso para resolver consultas y elaborar informes Definición de la Consulta Acceso y recuperación de datos Manipulación y cálculo Preparación del informe 17 Envío del informe

18 Análisis Multidimensional En lugar de elaborar consultas sobre los datos, se preparan los datos estructurándolos de forma que se pueda acceder a ellos de forma fácil y rápida para responder las preguntas más frecuentes. Qué cantidad de productos se han vendido en un determinado día, por un determinado vendedor, en una tienda determinada? Se usan dimensiones para estructurar los datos, teniendo en cuenta las dimensiones que intervienen en las preguntas que se quieren resolver. 18

19 Organización de datos en dimensiones Ventas Continente Continente Continente Roll Up Región Región Drill Down País País País Cliente Cliente 19

20 Data mining Dirigido por el analista Asistido por el analista Dirigido por los datos Consultas e Informes Análisis Multidimensional Data Mining 20

21 Importancia de la técnica El tipo de análisis que se vaya a hacer con el DW determina la forma de modelar sus contenidos: Para consultas, informes y análisis multidimensional hace falta agregar la información y tener en cuenta metadatos. Para el análisis multidimensional hay que tener en cuenta las distintas operaciones que pueden interesar sobre las dimensiones que tienen los datos. Para el data mining, sin embargo, cuanto mayor sea el detalle de los datos, mejor. 21

22 Estructura básica de un DW ESQUEMA DEL USUARIO ESQUEMA DEL USUARIO ESQUEMA DEL USUARIO usuarios finales DATOS DERIVADOS DATOS DERIVADOS DATOS DERIVADOS ESQUEMA DEL DW AGREGACIÓN & ADAPTACIÓN diseñador del DW Repositorio DATOS RECONCIALIADOS EXTRACCIÓN & INTEGRACIÓN ODS Administrador BD 22 ESQUEMA DE LA FUENTE DATOS OPERACIONALES ESQUEMA DE LA FUENTE DATOS OPERACIONALES ESQUEMA DE LA FUENTE DATOS OPERACIONALES

23 Arquitectura del DW La arquitectura que se siga para hacer Data Warehousing determina: Dónde reside el Data Warehouse. Quién controla el Data Warehouse. Hay distintos tipos de arquitectura: Global. Independiente. Interconectada. 23

24 Data Marts Data Mart (DM) DWs de pequeño tamaño que pueden funcionar de forma independiente o interconectada para formar un DW integrado global. Están asociados a un departamento de la empresa y están orientados a un análisis de problemas concretos de ese departamento. 24

25 Arquitectura global Data Warehouse Data Mart Data Warehouse Data Mart Data Warehouse Data Mart Datos Externos y Operacionales Global Distribuida Global Centralizada 25 Datos Data Warehouse Data Mart

26 DW Global DW Fuente... Fuente 26

27 Arquitectura de DMs Datos Externos y Operacionales Datos Data Warehouse Data Mart Data Warehouse Data Mart Data Warehouse Data Mart Independiente Interconectada Data Warehouse Data Mart 27 Data Warehouse Data Mart Data Warehouse Data Mart

28 DW con DMs DMs Locales Finanzas Marketing Distribución DW 28 Fuente... Fuente

29 Implementación de los DW Los DW se implementan aparte de las bases de datos operacionales. Los DW se pueden implementar sobre bases de datos relacionales: Servidores OLAP relacionales (ROLAP). Estos servidores suponen que los datos están almacenados en una base de datos relacional y proporcionan extensiones de SQL para trabajar eficientemente con datos multidimensionales. Se pueden usar directamente estructuras multidimensionales: Los servidores de OLAP basados en una estructura multidimensional (MOLAP). 29

30 Sistemas ROLAP y MOLAP Ejemplos de sistemas ROLAP: MetaCube Suite (Informix) Microstrategy Red Brick Systems Sybase Ejemplos de sistemas MOLAP: Arbor Software Esquemas híbridos: Oracle Express Server 30

31 Enfoques de Implementación A la hora de elegir un enfoque para la implementación hay que tener en cuenta los siguientes factores: Infraestructura disponible. Recursos disponibles. Arquitectura elegida. Ámbito de la implementación. Rapidez deseada para la implementación. Se puede elegir entre distintos tipos de enfoque: Enfoque Top-Down Enfoque Bottom-Up Enfoque combinado. 31

32 Implementación Top-Down Datos Externos y Operacionales DW Global DW de la Organización Data Marts Datos 32 Definiciones más consistentes. Se plasman mejor las reglas del negocio. Es apropiado si hay un CPD centralizado en la empresa responsable de todos los recursos.

33 Implementación Botton-up DW de la Organización Datos Externos y Operacionales DW Global Data Marts Datos Data Marts Se obtienen resultados muy pronto. La implementación inicial es más barata. 33 Problemas de redundancia e inconsistencia.

34 CONSTRUCCIÓN DE UN DW Estructura detallada de un DW Integración de fuentes 34 Labores Formas de integrar: Integración de esquemas Integración virtual de datos Integración materializada Integración de esquemas Limpieza de datos Carga de datos Refresco de datos Dificultades Tipos de fuentes Elementos software Encapsuladores Monitores Integradores

35 Estructura detallada un DW Monitorización y administración Fuentes de datos Repositorio de datos DW Servidor OLAP Análisis Bases de datos Extrae Transforma Sirve Datos Consulta Data Mining DMs Servidor OLAP 35

36 Labores de la integración Reconciliación de datos: integración de formatos distintos gestión de códigos diferentes... Validación de datos: Identificación de datos potencialmente inconsistentes que pueden eliminarse o corregirse. Filtrado de datos: Elección de los datos, en función de los requerimientos del DW. 36

37 Formas de integración Integración de esquemas Entrada: conjunto de esquemas de las fuentes Salida: un único esquema general Integración virtual de datos Entrada: varios conjuntos de datos fuente. Salida: una especificación de cómo acceder de una forma global y unificada a los mismos. Integración de datos materializada Entrada: varios conjuntos de datos fuente. Salida: un conjunto de datos obtenido por reconciliación de todas las fuentes. 37

38 Integración de esquemas Actividad de integrar los esquemas de distintas fuentes de datos, con la intención de producir una descripción homogénea de las mismas. Fases: Preintegración Comparación de esquemas Adecuación de esquemas Mezcla y reestructuración de esquemas 38

39 Preintegración Análisis de los esquemas para decidir la política general que se va a seguir para integrarlos. Qué esquemas se van a integrar Orden en el que se van a integrar Asignar preferencias... Se suelen completar los esquemas originales con toda la información relevante que haga falta para la integración. 39

40 Comparación de esquemas Consiste en un análisis de los esquemas que se realiza para determinar las correlaciones que existen entre los conceptos de distintos esquemas y encontrar los posibles conflictos. Tipos de conflictos: Heterogeneidad de modelo de datos Asignación de nombres distintos Semánticos o de abstracción Estructurales 40

41 Adecuación de esquemas Preparar los esquemas fuentes para hacerlos compatibles y poderlos integrar. En este paso se resuelven los conflictos detectados en la anterior fase. Hay mucha investigación asociada a este nivel: Objetivo: automatizar este proceso (es muy complejo). Normalmente: se presentan los conflictos al diseñador y este suele elegir entre una serie de alternativas para resolver el conflicto. 41

42 Mezcla de los esquemas Los esquemas adaptados se juntan y se obtiene un esquema global para el conjunto de las fuentes. Se aplican métricas de calidad para determinar la bondad del esquema obtenido: Completitud Corrección Minimalidad Legibilidad 42

43 Limpieza de los datos Es un paso fundamental en todos los procesos de migración. Objetivo principal: garantizar datos de calidad. Corrección. Relevancia. Consistencia. Sin lagunas. Se convierte en algo primordial cuando los datos vienen de fuentes herogéneas (como es nuestro caso). 43

44 Suciedad en los datos Ejemplos: Formatos diferentes para el mismo campo. Cadenas de texto que contienen información relevante sin formato. Valores inconsistentes para la misma entidad por errores de escritura. Valores nulos que son necesarios en el DW. Información duplicada en la misma fuente o en fuentes distintas. 44

45 Funciones de los módulos de limpieza Funciones de conversión y normalización: 45 Cambio de formatos Uso de formatos normalizados para cada tipo de dato Limpieza de propósito específico En función del dominio de la aplicación se pueden utilizar diccionarios para encontrar fallos en la información (sinónimos, abreviaturas, nombres incorrectos,...). Limpieza independiente del dominio Mezcla de registros que se refieren a la misma entidad Limpieza basada en reglas Uso de reglas para la mezcla de los datos Especificadas por el usuario. Derivadas automáticamente.

46 El ciclo de vida de los datos Las fases que siguen los datos en el DW son: Fase de diseño: Definición de vistas de usuario, vistas auxiliares, extractores para las fuentes, limpiadores de datos,... Fase de carga: Instanciación original del DW: Cálculo inicial del contenido Fase de refresco o actualización: El flujo de los datos es similar al de la anterior fase, pero ahora se tienen en cuenta sólo los datos que han cambiado en las fuentes. 46

47 Carga de los datos Fases del proceso de carga: Preparación Para cada fuente: Extracción de los datos Limpieza de datos Archivo opcional de datos Integración Reconciliación de los datos obtenidos en cada fuente por el anterior proceso. Agregación Cálculo de vistas agregadas (resumidas) a partir de los datos obtenidos en la integración. Adaptación al cliente Cálculo y derivación de los datos para las aplicaciones de ususario. 47

48 Carga y refresco de datos Adaptación Adaptación al cliente DMs Agregación Agregación (HL) DW corporativo Integración Archivo de datos Integración de datos ODS 48 Preparación Limpieza de datos Archivo de datos Extracción de datos Logs, históricos, deltas Fuentes de datos

49 Refresco de los datos Qué es? Actualizar la información que hay en el DW con los últimos cambios que se van produciendo en las fuentes de datos. 49 Factores: Requisitos de la aplicación: Antiguedad de los datos Tiempo de cálculo Corrección de los datos Restricciones de las fuentes Disponibilidad Frecuencia de cambio Limitaciones del DW Espacio disponible Límites de funcionalidad

50 Directiva básica Se deben utilizar técnicas de carga paralelas (mientras se carga de nuevo y se refresca, se sigue usando la versión anterior) y mecanismos de carga incrementales (sólo modificaciones). 50

51 Dificultad del refresco El refresco de datos es difícil y constituye una tarea crítica especialmente por: El volumen de datos almacenado en el DW grande y tiende a crecer en el futuro. El refresco del DW exige ejecutar trabajos transaccionales de distinta complejidad: El ODS necesita muchas transacciones que trabajan sobre pocos registros para actualizarse. El DW corporativo necesita ejecutar transacciones que involucran gran cantidad de datos. Igual ocurre para agregar los datos en los DMs. El refresco debe convivir con el procesamiento de consultas: Tanto en las fuentes. Como en el DW. 51

52 Tipos de fuentes Fuentes de datos No cooperativas Cooperativas Fuentes con snapshots Fuentes consultables Fuentes con réplica Fuentes activas Fuentes con log Fuentes con aviso Fuentes sin aviso 52

53 Problemas en la detección Problemas planteados. Las fuentes consultables deben equilibrar la frecuencia de consulta con el rendimiento de la propia fuente de manera que este no se altere con el esfuerzo de mantener al día el DW. El tipo de fuente condiciona el módulo software que interacciona con ella: este componente es altamente dependiente de la fuente concreta. 53

54 Elementos de interés en la integración/carga/refresco Data Warehouse Data Mart Integrador Encapsulador Encapsulador Encapsulador BD BD BD 54

55 Encapsuladores/monitores Misiones: Traslación: convertir las estructuras de datos de la fuente al modelo que se haya adoptado para el DW. Detección de cambios: vigilar los cambios en la fuente que son relevantes para el DW y propagar dichos cambios hacia el integrador: Detección on-line: los cambios de propagan cuando se detectan o en un periodo de tiempo realmente corto. Detección off-line: Ignorar la detección de cambios y propagar periódicamente copias de seguridad reconstruyendo todo el DW cada cierto tiempo. 55

56 Integradores Mision básica Propagar la información que le aportan los encapsuladores hacia el DW. Diferencias con el mantenimiento clásico: 56 En muchos casos, las vistas almacenadas no pueden extraerse directamente de forma automática ( se manejan datos históricos). Los DW mantienen información altamente agregada y resumida: puede ocurrir que las funciones de agregación pedidas sean complejas. Distintos tipos de fuentes de información, tendrán distintas formas de actualización. Ciertos sistemas de DW no exigen que el mantenimiento de vistas deba ser instantáneo.

57 Herramientas de encapsulado e integración Actualmente se realizan mediante una gran variedad de herramientas de extracción y limpieza de datos y utilidades de carga y refresco (actualización a partir de las fuentes de datos). La extracción de datos de fuentes externas se implementa via portales e interfaces standard ( tales como ODBC, Oracle Open connect etc..) Estas herramientas se denominan herramientas posteriores (back-end tools) y corresponden a las conexiones del DW con las fuentes de datos. 57

58 Estructuración de datos Tipos de datos Grano Modelo dimensional: Medidas Dimensiones Operaciones Visualización Representación ROLAP MOLAP Nivel físico: Indices Algunas notas de diseño Agregaciones precalculadas 58

59 Los datos del DW limpiar Datos filtrar transformar resumir Datos preparados estructurar agregar Datos estructurados Por lo tanto, hay que elegir bien la forma de estructurar dichos datos, antes de empezar el proceso. 59

60 Tipos de datos Datos de tiempo real: Representan el estado actual del negocio. Se usan normalmente por aplicaciones operacionales. Cambian continuamente con las transacciones. Para usarlos en el DW: Hay que limpiarlos Se les suele dar un formato común fácil de manipular y entender. Datos reconciliados: Son datos detallados procedentes de disintas fuentes que han sido integrados para realizar análisis sobre ellos. Datos derivados: Se obtienen al resumir, agregar, o hacer cálculos sobre los datos de tiempo real. Son los datos que normalmente se utilizan para el análisis y la toma de decisiones. 60

61 Granularidad de los datos Granularidad Nivel de resumen con el que se almacenan o visualizan los datos, es decir, es el nivel de detalle que tienen los datos del DW. Granularidad alta: mayor detalle. Granularidad baja: menor detalle. La granularidad es importante porque: Influye de forma determinante en el rendimiento. Determina la cantidad de recursos de almacenamiento necesarios. Fija el tipo de preguntas que se pueden hacer sobre los datos. 61

62 Importancia de la granularidad Mayor detalle Menor detalle Fecha Hora NºCuenta Tipo de Trans. Cantidad 50 reg/mes 7.5 Kb/mes Mes Nº Cuenta Número de D. Cantidad de D. Número de H. Cantidad de H. 1 reg/mes 0.2 Kb/mes 62

63 Modelado Dimensional Técnica para conceptualizar y visualizar modelos de datos como un conjunto de medidas que están descritas por aspectos comunes del negocio. Es muy adecuada para resumir y reordenar datos que van a ser utilizados para el análisis. Está enfocado para trabajar sobre datos numéricos: valores, conteos, pesos, ratios y ocurrencias. Puede decirse que el modelado dimensional es más simple, más expresivo y más fácil de entender que el modelado E/R. El problema es su reciente aparición y la falta de madurez de las metodologías de modelado. 63

64 Hechos y dimensiones Conceptos básicos: Hecho: Un hecho es una colección de porciones de datos relacionados, compuesto por medidas y un contexto. Ejemplo: Cantidad vendida de un producto en una tienda un día determinado, Dimension: Una dimensión es una colección de miembros o unidades del mismo tipo. Las dimesiones determinan el contexto de los hechos. Cada hecho está asociado con un miembro de cada dimensión. Son los parámetros sobre los que queremos hacer OLAP. Ejemplos: Tiempo Localización Clientes Vendedores Escenarios

65 Dimensiones Las dimensiones tienen: Miembros: Son los distintos nombres o identificadores que marcan una posición dentro de la dimensión. Ejemplo: Todos los meses, los cuatrimestres, los años, son miembros de la dimensión Tiempo. Todas las ciudades, regiones y países son miembros de la dimensión Localización. Jerarquías: Los miembros de las dimensiones suelen estar organizados en forma de jerarquías. Año Cuatrimestre Cuatrimestre Cuatrimestre Cuatrimestre Mes Mes Mes Mes Mes Mes Mes Mes Mes Mes Mes Mes 65

66 Medidas Medidas: Son atributos numéricos de los hechos, que representan el comportamiento del negocio relativo al contexto que tiene asociado el hecho. Los valores reales se denominan variables. Ejemplos: La cantidad de dinero de las ventas. El volumen de ventas. El coste de los proveedores. La cantidad de transacciones.... Están determinadas por una combinación de miembros de las dimensiones que caracterizan al hecho. 66

67 Formalización Se considera un objeto de análisis que depende de una serie variables y se modela como una función w=f(x,y,..) x,y... se denominan dimensiones y se pueden definir jerarquías sobre ellas: Si D es el dominio de x, definimos la jerarquía H={H 1,...,H l } de forma que j {1..,l} ; H j D A partir de esta estructura multidimensional se definen una serie operaciones que facilitan el análisis de la medida en cuestión a través de las dimensiones ( análisis multidimensional ). 67

68 68 Visualización de un modelo dimensional

69 Operaciones OLAP 69 Agregación (Roll-up) a lo largo de una dimensión subiendo el nivel de una o varias jerarquías: Menos detalle. Descomposición (Drill-down o Roll-down), es la operación inversa de la anterior: Más detalle Selección o filtro, supone la particularización de algunos valores de las dimensiones y/o alguna condición adicional sobre la medida: Ventas de más de 100 unidades en la zona este del país y en invierno. Corte (slicing): fijar un valor de una dimensión y trabajar con el resto de la estructura Pivotaje (pivoting, rotating, dicing): consiste fundamentalmente en cambiar el orden de las dimensiones o en sustituir una por otra.

70 Operaciones básicas en OLAP VOLUMEN DE PRODUCCIÓN 1996 CTR1 CTR2 CTR3 CTR4 OESTE SAN JOSE BOULDER ROLL UP (TIEMPO) DRILL DOWN (TIEMPO/C1) VOLUMEN DE PRODUCCION CTR1 ENERO FEBRERO MARZO OESTE SAN JOSE BOULDER

71 Operaciones básicas en OLAP VOLUMEN DE PRODUCCIÓN MÓVIL BUSCADOR (Octubre de 1996) OESTE SAN JOSE BOULDER Dice VOLUMEN DE PRODUCCIÓN 1996 MOVIL-BUSCADOR C1 C2 C3 C4 OESTE SAN JOSE BOULDER Slice VOLUMEN DE PRODUCCIÓN 1996 MOVIL C1 C2 C3 C4 OESTE SAN JOSE BOULDER

72 Operaciones básicas en OLAP L SLICE T P L P T DICE L L T P T P 72

73 Ejemplo Proceso normal: Se elige un proceso del negocio que se pretende modelar: Qué necesita el negocio. Qué datos tengo. Se elige el grano con el que se va a representar la información: El más bajo que permitan los recursos. El grano suele indicar las dimensiones. Se eligen las dimensiones que determinan el contexto del proceso. Se eligen las medidas que determinan el proceso. 73

74 Proceso y grano Ventas que se producen en una empresa de distribución de productos con una serie de tiendas en todo el país. Grano: Productos por tienda por promoción por día. Medidas: Unidades vendidas. Ingreso. Coste. Clientes que han comprado el producto. 74

75 Esquema para el ejemplo Tiempo clave_tiempo atributos de tiempo Promoción Ventas clave_tiempo clave_producto clave_tienda clave_promoción cantidad_vendida dinero_ingresado coste nº_de_clientes Producto clave_producto atributos de producto Tienda clave_promoción atributos de promoción clave_tienda atributos tienda 75

76 Dimensión tiempo Tiempo clave_tiempo dia_semana dia_mes dia_desde_ref semana_año semana_desde_ref mes mes_desd_ref cuatrimestre periodo_fiscal flag_vacaciones flag_díasemana flag_ultimodelmes estación evento... 76

77 Dimensión producto Producto clave_producto descripción número_producto tamaño_paquete tipo_producto subcategoría categoría departamento tipo_paquete peso... 77

78 Dimensión Tienda Tienda clave_tienda nombre número calle ciudad región estado zip distrito manager telefono fax tipo_planta fecha_apertura fecha_remodelación extensión... 78

79 Dimensión promoción Promoción clave_promoción nombre redución anuncio poster cupón medio coste fecha_inicio fecha_fin... 79

80 Los hechos Ojo con la aditividad de las medidas y de los cálculos: Medidas: Aditivas: se pueden agregar por todas las dimensiones: ingresos coste Semiadivitas: se pueden agregar por algunas dimensiones cuenta de clientes No aditivas: no se pueden agregar ratios (margen de ventas...) hay que agregar y luego hacer cálculos. 80

81 Espacio necesario Estimación: Dimensión tiempo: 2 años x 365 días = 730 días Dimensión tienda: 300 tiendas Dimensión producto: productos, 10% se venden de media en cada tienda cada día. Dimensión promoción: un producto aparece en una sóla promoción cada día. Hechos: 730 x 300 x 3000 x 1 = 657 millones de registros. 657 millones de registros x 32 bytes = 21 GB 81

82 Representación del modelo dimensional Se puede representar sobre bases de datos relacionales, que se denominarán servidores OLAP relacionales (ROLAP): Estos servidores suponen que los datos están almacenados en una base de datos relacional y proporcionan extensiones de SQL para trabajar eficientemente con datos multidimensionales. Los servidores de OLAP basados en una estructura multidimensional (MOLAP) almacenan directamente los datos sobre estructuras multidimensionales: Normalmente utilizan matrices e implementan las operaciones OLAP sobre estas estructuras 82

83 Esquemas de almacenamiento ROLAP Modelo de Estrella Star model Trata de superponer un estructura multidimensional sobre el modelo bidimensional de tabla. La base de datos que se implementa consiste en una tabla simple de hechos y una tabla para cada dimensión. Cada tupla de la tabla de hechos consta de: un puntero, normalmente la llave exterior, a cada dimensión, lo que proporciona las coordenadas multidimensionales los datos de las medidas que el modelo considere (cantidad, costos etc..). Los datos se organizan así para el procesamiento analítico 83

84 84 Esquema en estrella

85 Esquemas de almacenamiento ROLAP Esquema en bola de nieve Snowflake model En la representación en estrella las tablas asociadas a las dimensiones tienen una estructura no-normalizada con respecto a las jerarquías de las mismas. La estructura en bola de nieve se obtiene cuando se normalizan las tablas de las dimensiones. Suponen una ventaja porque manejan tablas normalizadas, pero tienen que manejar más tablas. Los esquemas en estrella y bola de nieve pueden generalizarse con la inclusión de distintas tablas de hechos que comparten todas o parte de las dimensiones, es lo que se denomina constelaciones de hechos 85

86 86 Esquema en bola de nieve

87 Representación con BDR (ROLAP) Idea básica: Utilizar un modelo relacional extendido de forma que las operaciones sobre datos multidimensionales se transforman en operaciones relacionales standard. Se construye entonces una visión multidimensional sobre una BDR. Capacidades de los servidores ROLAP: Generador de SQL: Crea consultas complejas contra el modelo multidimensional. Genera consultas SQL optimizadas contra la base relacional subyacente. Permite la construcción y mantenimiento de tablas resumen para mejorar el rendimiento. 87

88 Representación con BDR (ROLAP) 88 Capacidades de los servidores ROLAP: Optimizacion de las funciones de : Normalización: trata de suprimir la condición de normalización para minimizar el tiempo consumido por la ejecución de reuniones. Resumen y agregación: permite mantener vistas de tablas resumen que pueden contribuir al rendimiento de la visión multidimensional. Particionamiento: permite dividir una gran tabla en tablas más pequeñas con filas que correspondan a datos más usados y mejorar tanto el tiempo de respuesta como el de actualización del DW. Inconveniente: Los servidores son poco eficaces debido a la necesidad de realizar reuniones que involucren a toda una tabla de hechos. En un procesamiento OLTP se necesitan las tablas normalizadas para actualizar y la consulta se hace mediante la reunión de pocas tuplas previa selección. En un procesamiento OLAP no necesitamos las tablas normalizadas y la consulta se hace mediante una reunión donde se involucran todas las tuplas.

89 Representación multidimensional (MOLAP) Definición: 89 El OLAP multidimensional (MOLAP) es un modelo de datos de propósito especial y las operaciones se hacen directamente. Las bases de datos multidimensionales almacenan los datos como matrices, identificando las dimensiones del modelo multidimensional con las dimensiones de las matrices. Las bases de datos multidimensionales (MDDBs) son capaces de proporcionar un rendimiento de consulta muy alto: La información en una MDDB es de una granularidad más gruesaquela quese consideraen unabase de datos relacional standard, y por tanto los índices asociados son menores y pueden residir en memoria.

90 Representación multidimensional (MOLAP) Ventajas: En las bases de datos multidimensionales la información está físicamente almacenada en arrays lo que significa que no se produce prácticamente ninguna redundancia. La operaciones OLAP son nativas. Con un servidor de bases de datos multidimensional es fácil pivotar la información, realizar drill-down y en general realizar cálculos complejos que involucren a distintas celdillas. No hay necesidad de recurrir a reuniones complejas, subconsultas y uniones. Inconveniente: El menor cambio en las dimensiones obliga a estructurar toda la base de datos. 90

91 Representación multidimensional (MOLAP) Almacenamiento 91 Los modelos MOLAP pueden almacenar eficientemente dimensiones múltiples utilizando una tecnología de almacenamiento de matrices poco densas (sparse-matrix technology). La idea básica es eliminar en lo posible celdillas vacías ya que probablemente no todas las celdas de un hipercubo contendrán datos. Se obtienen entonces submatrices que se almacenan de forma comprimida. Sistemas MOLAP No existe un acuerdo sobre lo que debe ser un modelo de datos MOLAP y tampoco hay un método standard de acceso tales como el SQL o APIs. Cada producto es diferente uno de otro y alcanza distintos niveles a la hora de proporcionar ayuda a la decisión.

92 El nivel físico de un DW: indexación La estructura de índices asociada a un modelo relacional clásico es la de B-árbol. Se basa en la idea de que la tabla índice es muy grande porque el atributo por el cual se indexa tiene muchos valores. Las hojas del árbol son entonces un único valor del atributo y un conjunto de RIDs que corresponden a dicho valor. Este enfoque se llama también de indexación por lista de valores Cuando el número de valores del atributo no es muy grande este enfoque puede no ser efectivo. Ya que este conjunto puede obligar a recorrer toda la tabla, si los datos no están agrupados 92 Una posibilidad de reducir esfuerzos en el caso de consultas con AND (OR) es realizar la intersección (unión) de los conjuntos de RIDs asociados a los valores que se buscan.

93 El nivel físico de un DW: indexación Para atributos con pocos valores una mejor alternativa es la indexación por medio de mapas de bits Los mapas de bit se diferencian de las listas de valores en la forma en que se representan los RIDs: Dado un atributo v, de dominio Dv,se le asigna un mapa de Dv bits de forma que si el registro r i posee el valor d i en el atributo v entonces el i-ésimo bit del mapa se pone a 1. Con esta estructura la unión e intersección de índices es muy directa. Los mapas de bits son muy adecuados para los DWs: Las dimensiones tiene pocos valores Pueden generarse en el tiempo de carga Cuando se trata de atributos cuyo dominio es un gran rango de números, se usan técnicas especiales. 93

94 El nivel físico:indexación (índices de reunión) La naturaleza de los esquemas en estrella hace que los índices de reunión ( join índices) sean especialmente atractivos. La diferencia entre un índice normal y uno de reunión es que Cuando se indexa por un valor un atributo de una tabla T1, obtengo, a través de un join implícito los RIDs de las tuplas de una tabla T2 cuyo valor de llave exterior coincide con la llave primaria de T1, Es decir que manejamos un direccionamiento indirecto a través de las llaves exteriores. Teniendo en cuenta que una tabla de hechos maneja las dimensiones a través de las llaves exteriores, los índices de reunión son particularmente útiles en este caso. Este tipo de índices se puede configurar también usando mapas de bits. 94

95 Algunas notas En una dimensión puede haber más de una jerarquía. Drill down persigue ganar detalle en el informe, independientemente de si se hace en relación con una jerarquía. La distribución de copo de nieve debe evitarse: normalizar sólo porque el problema lo exija. Las dimensiones que cambian hay que modelarlas con cuidado: Realizando el cambio. Llevando todo el histórico de valores. En algunos casos pueden aparecer tablas de hechos sin medidas. 95

96 Agregaciones 96 El uso de tablas de agregación precalculadas es el método más simple y efectivo para controlar el rendimiento del DW. Cada grano de agregación debe ocupar su propia tabla de hechos, con sus propias tablas de dimensiones, ajustadas al grano con el que se está trabajando. Hay que elegir bien sobre qué se preagrega: Evitar explosión en el tamaño del DW. Si hay tablas de agregación precalculadas, conviene incluir en el sistema un navegador de agregación: Permite determinar si existen tablas precalculadas al hacer las consultas. Permite aislar las consultas de la existencia de tablas agregadas.

97 MODELO DE CICLO DE VIDA Ciclo de vida Definición del proyecto Especificación de requerimientos Modelado Diseño Enfoque dirigido por usuario Enfoque dirigido por datos 97

98 Ciclo de Vida Definición del Proyecto Modelado del DW Especificación de Requerimientos Validación del modelo Diseño del DW Implementación del DW Validación del diseño 98

99 Definición del proyecto Definición de objetivos de alto nivel: Qué quiero analizar. Porqué quiero analizarlo. No hay que precisar tanto como en otro tipo de sistemas. Se establecen los límites del proyecto. No podemos olvidar que en un DW dos características fundamentales son: Su flexibilidad Su capacidad de gestionar una pregunta no planteada previamente. Por lo tanto hay que encontrar un equilibrio. 99

100 Especificación de requerimientos Que gente, grupos u organizaciones son de interés para el usuario? Qué funciones trata de analizar el usuario? Por qué necesita el usuario los datos? Cuándo hay que almacenar los datos? Dónde ocurren los procesos relevantes? Cómo se puede medir el rendimiento y el estado de las funciones que están siendo analizadas? 100

101 Dos enfoques para los requerimientos Requerimientos de usuario LO QUE QUEREMOS Conducido por el usuario LOS QUE SE PUEDE HACER Y ES DE UTILIDAD Conducido por la fuente LO QUE TENEMOS 101 Datos Operacionales

102 Teniendo en cuenta la fuente Los requerimientos se definen utilizando los datos de los sistemas operacionales. Se analiza el modelo ER de los datos si está disponible o la implementación física de los mismos. Ventaja: Sabemos desde el principio que tenemos los datos necesarios para elaborar el análisis. Desventaja: 102 Dado que el usuario no interviene, hay más riesgo de no encontrar un conjunto adecuado de requerimientos. Dependiendo del volumen de datos y de la complejidad, puede requerir mucho tiempo. Puede haber requerimientos basados en datos aún no disponibles.

103 Teniendo en cuenta al usuario Se definen los requerimientos teniendo en cuenta las funciones que el usuario desarrolla. Se basa en técnicas de reunión o entrevista. Ventaja: Se descubre lo que se necesita, no lo que está disponible. Suele producir un DW en menor tiempo. Desventaja: Comunicación con el usuario. 103

104 Modelado del DW Paso 1 Producto Componente Región de Manufactura Modelo de Producto Región de Ventas Planta de Manufactura Punto de Venta Localización de Cliente 104 Cliente Vendedor

105 Modelado del DW Paso 2 COMPONENTE MANUFACTURA PRODUCTO CLAVE DEL PRODUCTO DESCRIPCIÓN PRECIO POR MAYOR PRECIO POR MENOR DESCUENTO POR VOLUMEN CLAVE DE LA COMPONENTE DESCRIPCION COSTE CLAVE DE MANUFACTURA NOMBRE DE LA REGIÓN NOMBRE DE LA PLANTA 105 CLIENTE CLAVE DEL CLIENTE NOMBRE DIRECCIÓN VENTAS CLAVE DE VENTA NOMBRE DE LA REGION NOMBRE DEL PDV TIPO DEL PDV VENDEDOR

106 Modelado del DW Paso Cuál es la cantidad media de existencias este mes para cada modelo en cada planta de manufactura? 2. Cuál es el coste total y los ingresos totales para cada modelo que se ha vendido hoy, resumido por punto de venta, tipo de punto de venta y región? 3. Cuál es el coste total e ingresos totales para cada modelo que se ha vendido hoy, resumidos por planta de manufactura y región? 4. Qué modelos y productos no se han vendido la semana pasada? Y el mes pasado? 5. Cuáles son los cinco mejores modelos por ingresos durante el pasado mes? Por cantidad vendida? Por coste total? 6. Qué puntos de venta no tienen ventas de los anteriores modelos durante el último mes? 7. Qué vendedores no han vendido durante el último mes esos productos?

107 Modelado del DW Paso 4 Dimensiones y medidas C1 C2 C3 C4 C5 C6 C7 Dimensiones Venta x x x Manufactura x x Producto x x x x x x x Medidas Cantidad media de existencias x Coste total x x x Ingresos totales x x x Cantidad vendida x 107

108 Modelado del DW Paso 5 TIEMPO CLAVE DE TIEMPO FECHA SEMANA DEL AÑO MES DEL AÑO PRODUCTO CLAVE DEL PRODUCTO DESDEFECHA HASTAFECHA DESCRIPCIÓN CODIGO DEL MODELO COSTE UNITARIO PRECIO POR MAYOR PRECIO POR MENOR DESCUENTO POR VOLUMEN VENTAS CLAVE DE VENTA NOMBRE DE LA REGION NOMBRE DEL PDV TIPO DEL PDV VENDEDOR MANUFACTURA CLAVE DE MANUFACTURA NOMBRE DE LA REGIÓN NOMBRE DE LA PLANTA 108

109 Modelado del DW Paso 6 HECHOS DE INVENTARIO CLAVE DE TIEMPO CLAVE DE MANUFACTURA CLAVE DE PRODUCTO CANTIDAD DE EXISTENCIAS COSTE TOTAL INGRESO TOTAL 109

110 Modelado del DW - fin TIEMPO CLAVE DE TIEMPO FECHA SEMANA DEL AÑO MES DEL AÑO PRODUCTO CLAVE DEL PRODUCTO DESDEFECHA HASTAFECHA DESCRIPCIÓN CODIGO DEL MODELO COSTE UNITARIO PRECIO POR MAYOR PRECIO POR MENOR DESCUENTO POR VOLUMEN HECHOS DE INVENTARIO CLAVE DE TIEMPO CLAVE DE MANUFACTURA CLAVE DE PRODUCTO CANTIDAD DE EXISTENCIAS COSTE TOTAL INGRESO TOTAL MANUFACTURA 110 CLAVE DE MANUFACTURA NOMBRE DE LA REGIÓN NOMBRE DE LA PLANTA

111 El diseño de un DW Etapas en el diseño Definir la arquitectura, planificar la capacidad, seleccionar los servidores de almacenamiento, los servidores OLAP y de bases de datos y las herramientas. Integrar toda las estructuras software seleccionadas. Diseñar el esquema del DW así como las vistas asociadas. Definir la organización física del DW, situación de los datos, distribución y métodos de acceso. Conectar las fuentes utilizando: portales, dispositivos ODBC. Diseñar e implementar las herramientas de extracción de datos, limpieza, transformación, carga y actualización. Rellenar el repositorio con el esquema, vistas y otros meta datos. Diseñar e implementar los interfaces de usuario. Poner en marcha el DW y sus aplicaciones. 111

112 CALIDAD Calidad 12 reglas de Codd 112

113 Calidad del DW CALIDAD DISPONIBILIDAD VALIDACIÓN INTERPRETABILIDAD FIABILIDAD UTILIDAD 113

114 12 reglas para evaluar productos OLAP 114 1) Visión conceptual multidimensional: 2) Transparencia 3) Accesibilidad Contemplar la información de forma multidimensional Facilitar todas las operaciones asociadas al modelo OLAP debe ser transparente a las fuentes de datos (homogéneas o heterogéneas, locales o remotas) Transparente a la arquitectura y origen: OLAP debe proporcionarse en el contexto de un sistema abierto permitiendo que la herramienta de análisis se incruste en donde se desee, sin impacto negativo en la herramienta anfitrión Se debe acceder a todos los datos de la empresa (todas las bases de datos) pero presentando al usuario una visión común y adecuada El sistema debe ser capaz de acceder sólo a los datos realmente requeridos para realizar el análisis que se pide sin entrar en accesos innecesarios

115 12 reglas para evaluar productos OLAP 4) Rendimiento en la generación de informes 115 El rendimiento no puede depender del número de dimensiones ni del tamaño de las bases de datos subyacentes. Esta variación del rendimiento puede obligar al analista a tomar caminos engañosos (excesivo resumen etc..) para conseguir información. 5) Arquitectura cliente/servidor La mayoría de las fuentes de datos están almacenadas en main-frames y el acceso para OLAP se hace desde PCs El servidor debe ser capaz realizar las transformaciones de esquemas lógicos y físicos de distintas bases de datos en un único esquema físico y lógico Es imperativo que el servidor OLAP sea lo suficientemente inteligente para que pueda servir a los requerimientos de distintos usuarios compartiendo recursos con un mínimo esfuerzo

116 12 reglas para evaluar productos OLAP 6) Dimensionalidad Genérica 116 Cualquier dimensión debe ser equivalente tanto en su estructura como en su capacidad operacional. 7) Manipulación Dinámica de matrices dispersas Es necesario seleccionar una estructura multidimensional que optimice tanto memoria como operaciones, teniendo en cuenta el problema de la dispersión. La organización física deberá adaptarse a dicho esquema Es importante tener en cuenta el grado de dispersión de una estructura multidimensional ya que éste influirá en todas las estructuras derivadas 8) Soporte multiusuario Para ser considerado verdaderamente útil, OLAP debe proporcionar acceso concurrente (recuperación y actualización) así como mecanismos de seguridad y mantenimiento de integridad

117 12 reglas para evaluar productos OLAP 117 8) Permitir operaciones a través de las dimensiones de forma no restringida Cualquier conjunto de celdillas, independientemente de la dimensión en que aparezcan y del nivel de agregación, debe poder usarse para definir una operación. Las fórmulas no deben estar restringidas a una dimensión y cualquier condición impuesta podrá incluir atributos de varias dimensiones. En definitiva, cualquier celdilla de datos o dimensión en el modelo de datos debe poder ser usada en un cálculo en cualquier momento. 9) Manipulación de datos intuitiva La presentación del modelo para el analista debe ser flexible y fácil de visualizar. La gestión de operaciones (drill -down, agregación, o pivotaje) se debe realizar por acción directa sobre las visualizaciónes

118 12 reglas para evaluar productos OLAP 11) Capacidad de presentación de la información flexible Los datos deben poder presentarse de distintas formas Se deben poder comparar distintos datos Debe darse la posibilidad de cambiar la presentación de forma interactiva 12) Capacidad para un número ilimitado de dimensiones y niveles de agregación Cualquier herramienta OLAP debería soportar al menos hasta 20 dimensiones de datos Cada dimensión debe soportar un número prácticamente ilimitado de niveles de agregación a definir por los analistas que trabajen con el modelo 118

119 FUTURO Software Optimización de consultas Técnicas avanzadas de indexación Compresión de datos Procesamiento paralelo y técnicas de caché Herramientas de diseño: automatización Herramientas de administración 119