Diseño y Construcción de Data Warehouse. Instituto de Computación - Facultad de Ingeniería Mayo Diseño Lógico

Transcripción

1 Diseño y Construcción de Data Warehouse Instituto de Computación - Facultad de Ingeniería Mayo 2017 Diseño Lógico 2

2 Temario: Diseño Lógico Introducción. Formas de almacenamiento Estrategia a partir de un esquema conceptual. Estrategia a partir de datos fuente. 3 Diseño Lógico Introducción 4

3 Motivación Objetivos del Diseño Lógico del DW. Construir el esquema lógico del DW o DM. Sobre un DBMS Relacional o Multidimensional. Problemas a resolver. Transformaciones de modelos y especificaciones: Esquema Conceptual: abstracto. Esquema Lógico: implementado. Obtener estructuras adecuadas a la función. Tener en cuenta la Carga de Trabajo. 5 Arquitectura típica de SDW [Malinowski 2008] 6

4 Objetivo: el DW Propiedades del DW. Volúmenes importantes de datos. Operación crítica: Consultas interactivas complejas, muy frecuentemente con lógica multidimensional. Actualización: Batch (en lotes). Volúmenes de datos importantes. Los datos pasan por varias transformaciones. Solución depende del Modelo Lógico. Relacional o Multidimensional. 7 Proceso de Diseño Lógico Entradas: Información a representar en el DW. Esquema Conceptual o especificación equivalente. Características de las BD Fuente. Estructura. Características de los datos. Información sobre DW workload (carga de trabajo). o especificación equivalente asociada a requerimientos no funcionales. Salida: Esquema Lógico del DW. 8

5 Proceso de Diseño Requerimientos DW diseño de cubos data marts MD carga diseño conceptual esq. conceptual DW diseño lógico refinamiento esq. lógico relacional DW DW rel. carga esq. conceptual fuentes esq. lógico relacional DW bases fuente esquemas de bases fuente 9 Diseño lógico de DW Enfoques de diseño: Pasaje / traducción del esquema conceptual multidimensional al esquema lógico Diseño a partir de las fuentes 10

6 Diseño Lógico desde Esq. Conceptual Conectar (acercar) la especificación Conceptual al Modelo Lógico. Incorporar requerimientos no funcionales: Operaciones críticas. Frecuencias de operaciones. Volúmenes de datos. Agregar al esquema conceptual: Indicaciones orientadas a reqs no funcionales: Lineamientos de Diseño (Design Guidelines). Mappings a BD Fuentes. Construir estructuras del DW con estos 3 elementos: Esquema Conceptual + Guidelines + Mapping Trabajos existentes: [Gol98b][Cab98][Per01] 11 Diseño Lógico desde BDs Fuente Los requerimientos se asocian a las BD fuente: Qué datos interesa acceder? y con qué performance? Pasos: Seleccionar información en BDs fuentes. Transformar para obtener un esquema de DW con acceso eficiente. Teniendo en cuenta requerimientos no funcionales. Trabajos existentes: Consultas OLAP: [Bal98][Kim96][Mar00][Moo00] Consultas SQL: [Lig99][The99][Wid95][Wu97] 12

7 Diseño Lógico desde BDs Fuente Vistas Materializadas Orientado a consultas SQL para mejorar su performance DW es un conjunto de vistas materializadas El problema de diseño del DW: Entrada: consultas sobre relaciones en bases de datos fuentes Salida: un conjunto seleccionado de vistas a materializar de manera de mejorar la evaluación de las consultas Referencias: [Lig99][The99][Wid95][Wu97] 13 Diseño Lógico Modos de Almacenamiento 14

8 ROLAP DW en BD Relacional (ROLAP) Modelo estandarizado. Tanto en estructura como lenguaje de manipulación (SQL). Flexibilidad y potencial para consultas ad-hoc. Especialmente consultas por clave y por condición. Transformación compleja de datos y operaciones MD hacia estructuras y operaciones Relacionales. Mala performance en Joins y Sumarizaciones. Se ha avanzado mucho en optimización de consultas, índices, joins, etc., para aplicaciones DW. Muchos sistemas comerciales utilizan almacenamiento ROLAP o HOLAP para grandes volúmenes de datos. 15 MOLAP DW en BD Multidimensional (MOLAP) Modelo MOLAP: Datos y operaciones multidimensionales se mapean directamente Almacenan datos en estructuras especializadas. Muy alta performance en consultas dimensionales. Poco usables para consultas por clave o por condición. Muy poco flexibles para actualización: Solo append a la BD (carga incremental). Modelo menos estandarizado. No hay estándares de estructura pero si de lenguaje de consulta (MDX). 16

9 ROLAP - MOLAP Multi-dimensional: Acceso a datos relacionales sólo durante la carga. Adecuado cuando se quiere independencia del DBMS relacional. Mejor performance para sistemas accedidos con mucha frecuencia. Relacional: Menor espacio en disco. Adecuado para grandes conjuntos de datos. Híbrido: Balance entre performance y espacio en disco. Adecuado cuando se accede frecuentemente a datos resumidos y los datos detallados son poco accedidos. 17 Diseño de un DW Relacional Características del DW Acceso y mantenimiento de datos Consultas complejas Se considera solo-lectura. El mantenimiento no se hace vía sistema OLTP, sino en forma "batch". Usuario final accede directamente al DW con herramientas de consulta (OLAP) Modelo Relacional poco adecuado para consultas dimensionales. Implican Joins entre varias tablas y Sumarizaciones, que son costosas y poco optimizables. Técnicas de diseño de DW diferentes a las tradicionales para BDs relacionales 18

10 Diseño de un DW Relacional Modelo Dimensional [Kim96] Orientados a consultas OLAP Se representan los conceptos MD sobre el modelo Relacional. Se trata de minimizar joins y totalizaciones: Redundancia en cálculos. Fuerte tendencia a desnormalizar. Estructuras básicas Tablas de hechos (fact tables) Donde se guardan las medidas numéricas del negocio Granularidad: Intersección de las dimensiones Tablas de dimensión (dimension tables) Donde se guardan las descripciones de las dimensiones Jerarquías: desnormalizadas o normalizadas 19 Esquema estrella - Estructura Tabla central: hechos Conjunto de tablas usualmente con menos registros organizadas alrededor: dimensiones Clientes Fechas Geografía Vendedores Hechos de Ventas Productos 20

11 Esquema estrella - Características Tablas de dimensión. Desnormalizadas y con jerarquías embebidas. Tablas de hechos. Unidas a todas las de dimensión por relaciones 1:N Clave primaria = concatenación de las claves primarias de todas las dimensiones. 21 Esquema Estrella (ejemplo) 22

12 Esquema Estrella: Constelación y Galaxia 23 Esquema Snowflake - Estructura Es el resultado de descomponer una o más tablas de dimensiones en varias tablas, que forman jerarquías. Semanas Meses Departamentos Regiones Clientes Días Ciudades Tipos Sucursales Vendedores Hechos de Ventas Modelos Productos 24

13 Esquema Snowflake - Características Es un Esquema Estrella con las dimensiones normalizadas según las jerarquías que contienen. Construcción a partir del Esquema Estrella Normalizar las jerarquías de cada dimensión. Construcción directa: Una tabla de hechos. Una tabla para cada nivel de una dimensión. Las tablas de los niveles de una misma dimensión se relacionan a través de foreign- keys. 25 Esquema Snowflake - Ejemplo 26

14 Esquema Star Cluster Estructura: Es una combinación de Star y Snowflake. Selectivamente separa los fragmentos de jerarquías compartidos entre diferentes dimensiones. El resto de las jerarquías se desnormalizan. Características: Mínimo número de tablas, y a la vez evita solapamiento entre dimensiones. Referencia: [Moo00] 27 Esquema Star Cluster - Ejemplo 28

15 Diseño de un DW Multidimensional Modelos Multi-dimensionales Orientados a consultas OLAP Se implementan los conceptos MD sobre estructuras MD. Estructuras propietarias. Intuición de estructuras Arrays multidimensionales. Granularidad: Intersección de las dimensiones Dimensiones en los ejes, medidas en las celdas. Unidas a jerarquías de dimensiones por referencias. Jerarquías de dimensiones Árboles de jerarquías (índices) Diccionarios con datos descriptivos. 29 Diseño de un DW Multidimensional Id-Familia Nom-familia F1 Sport F2 Gala F1 F2 P1 P2 P3 P4 Id-producto Nom-producto P1 P2 P3 P4 Remera Pantalón Vestido Traje C1 C2 C3 C4 C5 P P2 P3 P

16 Diseño Lógico Traducción del Esquema Conceptual 31 Proceso de Diseño Requerimientos DW diseño de cubos data marts MD carga diseño conceptual esq. conceptual DW diseño lógico refinamiento esq. lógico relacional DW DW rel. carga esq. conceptual fuentes esq. lógico relacional DW bases fuente esquemas de bases fuente 32

17 Traducción a un esq. lógico Consiste en: Diseñar las BDs a partir de esquemas conceptuales. Problemas a resolver: Ofrecer acceso eficiente y simple. Se deben adaptar los esquemas conceptuales al modelo implementado. Tener en cuenta requerimientos no funcionales 33 Metodología Determinar requerimientos no funcionales: Uso del sistema. Performance requerida. Limitaciones de espacio en disco. Elegir modo de almacenamiento: MD, relacional, híbrido. Definir estrategias de almacenamiento: Por ej. lineamientos de diseño. Adaptar las estructuras a restricciones de las herramientas. 34

18 Almacenamiento Se resuelve almacenamiento de: Dimensiones Relaciones dimensionales Agregaciones Resúmenes pre-calculados (aggregates) Un registro representa un resumen de registros de nivel básico de una tabla de hechos o cubo 35 Traducción a un esq. lógico Ejemplo: Cantidad vendida por cliente por producto. clientes departamento id-departamento# nom-departamento productos ciudad id ciudad# nom-ciudad cliente id cliente# nom-cliente familia id-familia# nom-familia producto id producto# nom-producto ventas cantidad cantidad clientes venta productos ventas 36

19 Traducción a relacional Dimensiones Id-producto Nom-producto P1 Remera P2 Pantalón P3 Vestido P4 Traje Id-Familia F1 F1 F2 F2 Id-Familia Nom-familia F1 Sport F2 Gala familia productos familia id-familia# nom-familia producto id producto# nom-producto producto Id-producto Nom-producto Id-Familia Nom-familia P1 Remera F1 Sport P2 Pantalón F1 Sport P3 Vestido F2 Gala P4 Traje F2 Gala 37 Traducción a relacional clientes departamento id-departamento# nom-departamento Dimensiones Id-cliente Nom-cliente Id-ciudad Nom-ciudad Id-depto Nom-depto C1 Juan 1 Mercedes K Soriano C2 Ana 1 Mercedes K Soriano C3 Pablo 2 Colonia L Colonia C4 José 2 Colonia L Colonia C5 María 3 Carmelo L Colonia ciudad id ciudad# nom-ciudad cliente id cliente# nom-cliente 38

20 Traducción a Id-producto relacional Nom-producto Id-Familia Nom-familia P1 Remera F1 Sport P2 Pantalón F1 Sport P3 Vestido F2 Gala P4 Traje F2 Gala Id-cliente Id-producto Cantidad C1 P1 2 C2 P1 5 C2 P2 1 C3 P3 10 C3 P4 3 C4 P1 4 C5 P3 8 productos Relaciones dimensionales venta clientes ventas Id-cliente Nom-cliente Id-ciudad Nom-ciudad Id-depto Nom-depto C1 Juan 1 Mercedes K Soriano C2 Ana 1 Mercedes K Soriano C3 Pablo 2 Colonia L Colonia C4 José 2 Colonia L Colonia C5 María 3 Carmelo L Colonia 39 Traducción a relacional Agregaciones Id-Familia Nom-familia Id-producto Nom-producto Id-Familia Nom-familia F1 Sport P1 Remera F1 Sport F2 Gala P2 Pantalón F1 Sport P3 Vestido F2 Gala P4 Traje F2 Gala Id-cliente Id-producto Cantidad C1 P1 2 C2 P1 5 Id-ciudad Id-familia Cantidad C2 P2 1 1 F1 8 2 F2 13 C3 P F1 4 C3 P4 3 3 F2 8 C4 P1 4 C5 P3 8 Id-cliente Nom-cliente Id-ciudad Nom-ciudad Id-depto Nom-depto C1 Juan Id-ciudad 1 Nom-ciudad Mercedes Id-depto K Nom-depto Soriano C2 Ana 1 1 Mercedes KK Soriano Soriano C3 Pablo 2 2 Colonia LL Colonia C4 José 3 2 Carmelo Colonia LL Colonia C5 María 3 Carmelo L Colonia 40

21 Traducción a MD productos familia id-familia# nom-familia Dimensiones Id-Familia Nom-familia F1 Sport F2 Gala producto id producto# nom-producto F1 F2 P1 P2 P3 P4 Id-producto Nom-producto P1 Remera P2 Pantalón P3 Vestido P4 Traje 41 Traducción a MD Id-depto K L Nom-depto Soriano Colonia Id-ciudad Nom-ciudad 1 Mercedes 2 Colonia 3 Carmelo K L C1 C2 C3 C4 C5 Id-cliente C1 C2 C3 C4 C5 clientes Dimensiones departamento id-departamento# nom-departamento Nom-cliente Juan Ana Pablo José María ciudad id ciudad# nom-ciudad cliente id cliente# 42

22 Traducción a MD Relaciones dimensionales clientes venta ventas F1 F2 productos P1 P2 P3 P4 K L C1 C2 C3 C4 C5 C1 C2 C3 C4 C5 P P2 P3 P Traducción a MD Agregaciones F1 8 4 F F1 F2 P1 P2 P3 P4 K L C1 C2 C3 C4 C5 C1 C2 C3 C4 C5 P P2 P3 P

23 Estrategias de almacenamiento Lineamientos de Diseño [Per01] Objetivo: Complementar especificación conceptual con indicaciones para resolver requerimientos no funcionales. Tipos de Lineamientos: Materialización de Relaciones Dimensionales. Fragmentación (vertical) de Dimensiones. Fragmentación (horizontal) de Cubos. 45 Lineamientos de Diseño En el proceso de Diseño Lógico. conceptual schema design guidelines refined conceptual schema rules REFINEMENT (task 1) MAPPING (task 2) GENERATION (task 3) DW relational schema source relational schema 46

24 Lineamientos de Diseño Materialización relaciones dimensionales. Permite indicar cubos a materializar, para evitar cálculos, aumentando performance en consultas. Fragmentación (vertical) de dimensiones. Especifica grupos de datos dimensionales a ser almacenados conjuntamente. Impacto en grado de partición/unión en estructuras de datos para dimensiones. Fragmentación (horizontal) de cubos. Permite almacenar por separado datos de igual esquema pero diferente uso. 47 Materialización de Relaciones Dimensionales Introducción: En CMDM, las relaciones dimensionales especifican un conjunto de cruzamientos potenciales, dados por los niveles de las dimensiones. A cada cruzamiento concreto se le denomina Cubo. Definición: Un lineamiento de tipo Materialización de Rel Dim, consiste en la especificación de un Cubo indicando que se quiere almacenar materializado. Ejemplo: fechas clientes venta vendedores articulos cantidades clientes rubro id rubro# rubro cliente id cliente# cliente ciudad id ciudad ciudad mes rubro vendedor venta-1 (venta) articulo cantidades 48

25 Criterios de uso Materialización de Relaciones Dimensionales Se almacena al menos un cubo por relación dimensional Se debería materializar los cubos de mayor granularidad para no perder información Cubos adicionales mejoran la performance de ciertas consultas. Debe balancearse con restricciones de almacenamiento y duración de la carga Prever la materialización de datos no obtenibles de los datos detallados por problemas de aditividad Factores a analizar: Performance necesaria para las consultas Restricciones de almacenamiento Tiempo de duración de la carga 49 Fragmentación Vertical de Dimensiones Introducción. Las Dimensiones consisten habitualmente en jerarquías formadas por múltiples niveles. Incluso pueden consistir en varias jerarquías alternativas. Definición: Un lineamiento de tipo Fragmentación Vertical de Dimensión consiste en la especificación de grupos de niveles de una Dimensión a ser almacenados conjuntamente. Ejemplo: 50

26 Criterios de uso Fragmentación Vertical de Dimensiones. Para obtener mejor performance en estas operaciones se tiende a mantener un único fragmento, pero esto genera redundancia Si los datos de la dimensión cambian muy poco, entonces la redundancia no es un gran problema Si la dimensión cambia frecuentemente y se registran versiones, entonces la redundancia genera problemas de mantenimiento. Jerarquías que no se navegan conjuntamente pueden ser almacenadas por separado Factores a analizar: Performance Tratamiento de la redundancia Requerimientos de navegación por las dimensiones 51 Fragmentación Horizontal de Cubos Introducción. Los Cubos tendrán asociados grandes conjuntos de datos, que comparten el mismo esquema pero pueden ser usados en forma diferente. Definición. Un lineamiento de tipo Fragmentación Horizontal de Cubo consiste en la especificación de bandas o franjas correspondientes a particiones horizontales del conjunto de datos. Ejemplo: Se definen franjas según el mes de Venta: Antes de enero Después de enero

27 Criterios de uso Fragmentación Horizontal de Cubos. Cuantas más franjas se definan, serán de menor tamaño y se obtendrá mejor tiempo de respuesta al consultarlas Por otro lado, si algunas consultas involucran varias franjas, estas operaciones tendrán menos performance Requieren drill-across La redundancia (franjas no disjuntas) debe balancearse con restricciones de almacenamiento Factores a analizar: Tamaño del cubo Subconjunto de registros que son usados juntos frecuentemente Restricciones de almacenamiento 53 Lineamientos: criterios de uso Usando los lineamientos el diseñador define: Cubos para cada RelDim. Franjas para cada Cubo. Fragmentos Verticales para cada Dimensión. Para definirlos debe tener en consideración: Requerimientos de performance y almacenamiento. Volúmenes de datos. Funcionamiento del DBMS utilizado. 54

28 Restricciones de herram. OLAP Principio: Refinar las estructuras de datos no soportadas por el OLAP elegido. Ejemplos: No se soportan jerarquías alternativas: Definir varias dimensiones. No se soportan diferentes roll-ups para medidas: Definir varias medidas, una con cada roll-up. No existe drill-across: Tener medidas redundantes, en varios cubos. 55 Restricciones de herram. OLAP Ejemplo: Dimensiones formadas por una única jerarquía de niveles. Fecha Fecha1 Fecha2 Fecha3 Año Año Año Año Semestre Cuatrimestre Semestre Semestre Cuatrimestre Trimestre Bimestre Trimestre Bimestre Bimestre Mes Mes Mes Mes 56

29 Restricciones de herram. OLAP Ejemplo: Medidas sólo soportan un roll-up por defecto. Tener varias medidas una con cada roll-up. Tener calculadas agregaciones para diferentes roll-ups. Ejemplo: Cantidad en stock: Se quiere sumar por producto. Se quiere promedio o último período por fecha. fechas stock productos Suma-stock Promedio-stock Ultimo-stock 57 Restricciones de herram. OLAP Ejemplo: Cubos formados por un conjunto de niveles y un conjunto de medidas. Implementan una relación dimensional. A veces se fusionan varias relaciones dimensionales para evitar drill-across. Ejemplo: Se desea comparar: Cantidad en stock. Cantidad vendida. fechas stock productos stock ventas 58

30 Resumen: Metodología Determinar requerimientos no funcionales: Uso del sistema. Performance requerida. Limitaciones de espacio en disco. Elegir modo de almacenamiento: MD, relacional, híbrido. Definir estrategias de almacenamiento: Por ej. lineamientos de diseño. Adaptar las estructuras a restricciones de las herramientas. 59 Diseño Lógico Diseño Lógico a partir de las Fuentes 60

31 Proceso de Diseño Requerimientos DW diseño de cubos data marts MD carga diseño conceptual esq. conceptual DW diseño lógico refinamiento esq. lógico relacional DW DW rel. carga esq. conceptual fuentes esq. lógico relacional DW bases fuente esquemas de bases fuente 61 De datos fuentes a DW relacional: una propuesta Enfoque clásico: Star Schema derivado de los requerimientos Problemas del enfoque: No todos los datos se adecuan naturalmente a esta estructura Requerimientos de usuario: base inestable para diseño Si el diseñador no entiende las relaciones subyacentes entre los datos, puede llevar a diseños incorrectos Referencia: [Moo00] 62

32 Ventajas del enfoque Enfoque estructurado para desarrollar el modelo dimensional Asegura que el DW refleja las relaciones subyacentes de los datos Simplifica procesos de extracción y de carga El modelo de datos de la empresa provee la base para identificar los requerimientos de forma bottom-up es una base más estable para el diseño que los requerimientos de usuarios 63 Ejemplo Notación de [Hitchman, 1995] para ER. 64

33 Clasificar entidades 3 categorías: Transaction entity Describe un evento que sucede en un punto en el tiempo. Contiene medidas o cantidades. Component entity Directamente relacionado a una transaction entity via una relación 1:N. Contestan quién, qué, cuándo, dónde, cómo y porqué del evento. Classification entity Son entidades que están relacionadas a las component por una cadena de relaciones 1:N. Representan jerarquías embebidas en el modelo de datos, que podrían ser colapsadas en las component entities para formar las dimensiones en un star schema. 65 Ejemplo/ Clasificación de entidades Entidad transacción Entidad componente Entidad clasificación 66

34 Identificar jerarquías Una jerarquía en un MER puede ser identificada como secuencia de entidades unidas a través de relaciones 1:N, alineadas en la misma dirección. Colapsar una jerarquía (desnormalizar) 67 Producir Modelo Dimensional Cuánto colapsar? Hay una gama de opciones para el modelo dimensional: Flat Schema Terraced Schema Star Schema Snowflake Schema Star Cluster Schema 68

35 Flat Schema Método: Se colapsan todas las entidades hasta las entidades minimales (entidades hoja de la jerarquia). Resultado: Una tabla para cada entidad minimal Problemas: Redundancia en dependencias parciales y transitivas. Pueden haber errores al realizar agregaciones cuando existen relaciones entre transaction entities (Ej.: Sale y Sale Ítem) Minimiza nro. de tablas, incrementa la complejidad de cada tabla 69 Terraced Schema Método: Se forma colapsando entidades en las jerarquías maximales, pero deteniéndose cuando se alcanza una transaction entity. Resultado: Una tabla para cada transaction entity. 70

36 Star Schema Método: Para cada transaction entity, una tabla de hechos. Clave: combinación de las claves de las component entities asociadas. Para cada component entity, una tabla de dimensión. Se colapsan en ella las classification entities que están jerárquicamente relacionadas. Cuando hay relaciones jerárquicas entre transaction entities, la entidad hija hereda todas las dimensiones (y los atr. clave) del padre. Resultado: Un star schema separado para cada transaction entity. 71 Star Schema 72

37 Constellation Schema y Galaxy Constellation: Star schemas cuyas tablas de hecho están relacionadas jerárquicamen te (1-N). Galaxy: Star schemas que comparten dimensiones. 73 Snowflake Schema Método: Una tabla de hechos para cada transaction entity. Cada component entity se transforma en una tabla de dimensión. Las classification entity quedan iguales. Cuando hay relaciones jerárquicas entre transaction entities, la entidad hija hereda todas las dimensiones (y los atr. clave) del padre. Las tablas de hechos con la misma clave primaria son candidatas a ser combinadas. 74

38 Snowflake Schema 75 Star Cluster Schema Problema: Al colapsar totalmente las jerarquías: cuando las jerarquías en diferentes dimensiones se solapan. Hay redundancia y puede haber inconsistencias. Se identifican fork entities : classification entities que tienen multiples relaciones 1:N 76

39 Star Cluster Schema Método: Una tabla de hechos para cada transaction entity. Las classification entities se colapsan con sus jerarquias hasta alcanzar una fork entity o una component entity. Si se alcanzo una fork entity, se forma una tabla de sub-dimension. Consistira de la fork entity mas todos sus ancestros. Cuando hay relaciones jerarquicas entre transaction entities, la entidad hija hereda todas las dimensiones (y los atr. clave) del padre. Es un esquemaquedisminuyeel númerode tablasy a la vezevita solapamiento entre dimensiones. 77 Resumen Pasos Desarrollar modelo de datos de la empresa. Modelo integrado ER Clasificar entidades. Diseñar esquemas dimensionales lógicos. Desarrollar star-cluster schemas para cada transaction entity del modelo. Estos se pueden combinar formando constellations o galaxies. 78