Modelos de Datos Multidimensionales. Qué se representa?

Modelos de Datos Multidimensionales Qué se representa?

Objetivos de los MMD: Representar los datos en forma cercana a la intuición del usuario. Resolver problemas planteados en sistemas relacionales.

Características Se representan los datos como una matriz. En los ejes están los criterios de análisis. En los cruces están los valores a analizar. A esta estructura se le llama Cubo o Hipercubo.

Características Agregando una 3a. dimensión:

Características Agregando una 4a. dimensión:

Estructuras básicas Los Cubos o Hipercubos constan de: Dimensiones: Criterios de análisis de los datos. Macro-objetos del problema. Variables independientes. Ejes en el hipercubo. Medidas Valores o indicadores a analizar. Datos asociados a relaciones entre los objetos del problema. Variables dependientes. Variables en la intersección de las dimensiones.

Medidas Aditivas, pueden ser sumarizadas a lo largo de cualquier dimensión. Ej: temperatura, que puede estar dada por las dimensiones estación, región y fecha. Semi aditivas, pueden no ser sumarizadas a lo largo de una o más dimensiones. Ej: nómina que puede estar dada por las dimensiones empleados y tiempo, pero no producto. No aditivas, no pueden sumarizarse a lo largo de ninguna dimensión. Ej: cantidad de producto, que únicamente puede estar dada por la dimensión producto.

Estructuras básicas En el ejemplo anterior: Dimensiones: Modelo Color Vendedor Fecha Medida: Cantidad Vendida

Dimensiones Jerarquías: Los valores se organizan en jerarquías (categorías). Por ejemplo: Dimensión: Vendedores

Dimensiones Jerarquías alternativas: Pueden haber varias jerarquías para una misma dimensión. Por ejemplo: Dimensión Vendedores: Región / Ciudad / Vendedor. Sexo / Rango_Edad / Vendedor.

Dimensiones Jerarquías Arbitrariamente Complejas Vendedor Año Fecha Región Semestre Trimestre Ciudad Mes Semana Vendedor Día

Medidas Propiedades: Se ubican en la intersección de algunos valores de las dimensiones. Dado un valor para cada dimensión se puede determinar un valor para la medida.

Medidas

Cubos La realidad se modela como un conjunto de cubos. Cada cubo, esta formado por: Un conjunto de Dimensiones organizadas en jerarquías. Un conjunto de Medidas asociadas a cada Coordenada. Es posible moverse en las jerarquías de las dimensiones y observar de esa forma, diferentes visiones de las medidas.

Ejemplo

Operaciones Principales operaciones en modelos MD: Slice. Dice. Rotación. Drill-down. Drill-up. Roll-up. Drill-across. Drill-through. Se implementan vía MDX, pero las mayoría de las herramientas de manejo de BI tienen facilidades tipo drag&drop para evitar la codificación

Operaciones: Slice Seleccionar Dimensiones (Slice) Se define un subconjunto del hipercubo especificando sobre qué dimensiones interesa analizar qué medida. Dimensión Medidas Colores Ventas Color Cantidad Modelos Modelo

Operaciones: Slice

Operaciones: Dice Filtrado (DICE) Se fijan valores para algunas dimensiones.

Operaciones: Rotación Rotación. Selecciona el orden de visualización de las dimensiones.

Operaciones: Drill-up, drill-down Movimientos en la Jerarquía de una Dimensión (Drillup,Drill-down)

Operaciones: Drill-up, drill-down Drill-Up o Drill-Down pueden verse como ajuste en las escalas de los ejes. Son agrupamientos y des-agrupamientos.

Operaciones: Roll-up Consolidación (Roll-Up). Calcula las medidas en función de agrupamientos. Realiza el re-cálculo de la medida de acuerdo a los ajustes de escala.

Operaciones: Roll-up Propiedades: Se debe especificar cuál es la operación que calcula el nuevo valor de la medida. Esta operación puede ser: suma, promedio, etc. Pueden haber medidas con comportamientos diferentes. Por ejemplo: Cantidades de productos vendidos se acumulan. Notas en exámenes se promedian.

Operaciones: Roll-up En general cualquier operación de navegación en un cubo implica un nuevo cálculo de la medida. Hay dos momentos posibles: Se asocia a la medida una operación por defecto. En el momento de hacer un movimiento en la dimensión se especifica cómo se hacen los cálculos.

Operaciones: Drill-Across Drill-Across Relaciona dos cubos.

Operaciones: Drill-Through Drill-Through. Accede a datos descriptivos

Agenda Inteligencia de Negocios: Pequeña Introducción Almacenes de Datos: Qué son? Modelos de Datos Multidimensionales: Qué se representa? Desarrollo de un DW: Cómo se hace? Diseño Lógico: Cómo nos acercamos a la implementación? Enfoques Diseño Conceptual: Cómo podemos diseñar conceptualmente un DW? Conclusiones

Desarrollo de un DW Cómo se hace?

Proceso de Desarrollo de un DW Componentes a desarrollar: Mecanismo de Adquisición de Datos Almacenamiento del DW Mecanismos de acceso para usuarios finales Para el DW Elegir Estrategia de Desarrollo Identificar Datos Fuentes a considerar Diseñar el DW a nivel Conceptual Diseñar el DW a nivel Lógico Implementar Planificar la Carga de Datos Operar

Desarrollo de un DW Integración Necesidades de Usuarios Bases de Datos Fuentes Esquema Integrado BD Fuentes E T L DW Esquema Lógico DW Esquema Conceptual del DW

El DW Tipo/s de DBMS. Relacional, Multidimensional, o ambos. Concepción del DW. Diseño e implementación de la carga. Administración del DW: Cómo describir y documentar los datos? Qué información hay que monitorear? Cómo organizar y realizar la administración del DW? Mediante qué tipo de herramientas?

DBMS para el Data Warehouse DBMSs Relacionales: Solución "universal". Soportan el grueso de las aplicaciones DW. Dificultades para resolver eficientemente consultas dimensionales. DBMSs Multi-Dimensionales: Representan los datos del problema en términos de dimensiones. Estructuras de almacenamiento están diseñadas para optimizar consultas dimensionales.

Diseño del Data Warehouse Elementos base: Las operaciones principales son consultas. La carga/actualización no es transaccional. Importancia de la calidad y facilidad de acceso. Por lo tanto El DW se construye en capas asignando propiedades a las tablas de cada una. Se suele des normalizar y materializar cálculos. En cuanto a complejidad El diseño del DW y programación de la carga constituyen las tareas más costosos y complejas.

El proceso de ETL BD Fuente ODS Data Warehouse Corporativo Data Marts Indicadores Agregados Históricos Datos Detallados Transformaci ones Datos preparados Datos homogeneizados Datos sin preparar Describen los otros datos Datos homogeneizados, integrados, preparar METADATA Datos más preparados y especializados

Diseño Lógico Cómo nos acercamos a la implementación?

Tablas de Hecho La tabla de hechos es la tabla primaria dentro de un modelo multidimensional, contiene los valores de las medidas de negocios, por ejemplo: ventas promedio, número de unidades vendidas, etc.

Tablas de Dimensiones Las tablas de dimensiones contienen el detalle de los valores que se encuentran asociados a la tabla de hechos. Generalmente tienen muchas columnas o atributos.

Esquemas de Representación Esquema Estrella Esquema Copo de Nieve

Esquema Estrella Compuesto de una tabla central con una clave primaria compuesta, denominada tabla de hechos, y un conjunto de dimensiones. Cada una de las tablas de dimensiones tiene una clave primaria que corresponde exactamente con uno de los componentes de la clave compuesta de la tabla de hechos. Las tablas de hechos, además de sus campos clave, contienen una o más medidas, indicadores o hechos. Las medidas más útiles en una tabla de hechos son numéricas y aditivas. En el modelo estrella las dimensiones no se normalizan. Con ello se logra minimizar el número de uniones y, por consiguiente, incrementar el rendimiento de las consultas.

Esquema Estrella

Esquema Copo de Nieve Derivado del esquema en estrella, en el que las tablas de dimensión se normalizan en múltiples tablas. La tabla de hechos deja de ser la única tabla del esquema que se relaciona con otras tablas, y aparecen nuevos joins gracias a que las dimensiones de análisis se representan ahora en tablas de dimensión normalizadas. En la estructura dimensional normalizada, la tabla que representa el nivel base de la dimensión es la que hace join directamente con la tabla de hechos. La diferencia entre ambos esquemas (estrella y copo de nieve) reside entonces en la estructura de las tablas de dimensión.

Esquema Copo de Nieve

Enfoques Diseño Conceptual Cómo podemos diseñar conceptualmente un DW?

Enfoques de Diseño Conceptual Análisis desde requerimientos: Los requerimientos son el universo de información. Las bases fuente se relacionarán luego. Aplicable cuando se tienen Bases Fuentes complejas. (Se analizan con los requerimientos en mente). Análisis desde datos: Datos fuentes son el universo de información. El DW se obtiene transformando las fuentes. Aplicable cuando los requerimientos están poco claros. Enfoque MDA Ortogonal a los enfoques previos Se basa en la transformación de modelos, ya sea desde los requerimientos o los datos fuentes Aún en desarrollo Alineamiento Estratégico

Estrategia Basada en Datos Método propuesto por Matteo Golfarelli Parte desde el MER y entrega un modelo de los cubos a implementar. Tiene un fuerte uso de los grafos y sus propiedades.

MER CAUSAL BECA (1,1) CRÉDITO (1,1) (1,1) tiene tiene tiene RAMO (1,n) Ramo_toma (0,n) (1,n) (0,n) ALUMNO (0,n) (1,1) tiene (1,1) INGRESO (1,n) (1,1) (0,1) pertenece Viene de tiene (1,n) (1,n) (1,1) MALLA COLEGIO TITULACIÓN

Cubo para una medida Medida o hecho de interés: Cantidad de años promedios que los alumnos demoran en salir de la Universidad. Dimensiones: Sexo, Colegio de procedencia, Zona de procedencia.

Construcción del árbol de atributos % BECA Año Créd. Especiales Créd. Electivos Id_Sem Sección Profesor Fecha vencimiento Cuidad Origen Genéro CRÉDITO Carrera Ptje. RAMO INGRESO Id. Sem MALLA ALUMNO RAMO Alumno Créd. Obligatorio Créditos Nota Individuo TITULACIÓN Id_sem CAUSAL COLEGIO Año Nota Estado Nombre Articulo Detalle Financiamiento Tipo Educ.

Poda y repoblación del árbol Promedio de años necesarios para Titularse Id_sem Puntaje Nota TITULACION Carrera INGRESO ALUMNO Id_sem Ciudad Género Género Titulación Nota de Titulación - Cantidad promedio de Años Puntaje de Entrada

Visión General MER Promedio de años necesarios para Titularse CAUSAL Puntaje Id_sem Carrera RAMO pertenece (1,1) (1,n) INGRESO (1,n) tiene Ramo_toma ALUMNO (0,n) (1,n) Género BECA tiene (0,n) ALUMNO (1,1) Viene de (1,1) Nota TITULACION (0,n) (1,1) (0,1) Id_sem Nota de Titulación tiene tiene tiene (1,1) Ciudad (1,1) CRÉDITO Género Titulación INGRESO - Cantidad promedio de Años MALLA (1,n) (1,n) COLEGIO Puntaje de Entrada (1,1) TITULACIÓN

Implementación Se eligió SQLServer + Analysis Services SQLServer tiene las tablas fuentes. Analysis Services tiene los cubos. Los cubos pueden ser exportados a aplicaciones de ofimática tales como Word o Excel.

El cubo en Analysis Services Promedio de años necesarios para Titularse Id_sem Puntaje Nota TITULACION Carrera INGRESO ALUMNO Id_sem Ciudad Género Género Titulación Nota de Titulación - Cantidad promedio de Años Puntaje de Entrada

Una visión de los datos

Centrada en los Requerimientos Metodología basada en el ciclo de desarrollo de software y BD tipico Lenguaje de Modelación CMDM (Carpani) Se centra en identificar qué se requiere, luego identifica dónde se encuentra la información necesaria. Si no está disponible, se deben desarrollar los sistemas OLTP que la gestionen.

Indicadores Para una Universidad

Diseño Lógico

Cruce de Dimensión

Observaciones En este caso se implementaron un conjunto de dashboards y otros reportes de gestión con indicadores relevantes para la gestión universitaria (se utilizó el software CorVu)

Conclusiones

Conclusiones DW es un elemento clave de cualquier sistema de análisis (BI) Es necesario comprender bien el negocio para desarrollar aplicaciones que sean útiles Perfil altamente demandado en Chile La implementación aún es inmadura Complejidades asociadas a la falta de metoldologías ampliamente aceptadas de diseño (ni lenguajes) Grandes volúmenes de información Costo alto Relevancia de procesos ETL

Desafíos Mejorar el proceso de desarrollo (MDA con UML?) Manejar información cualitativa en las medidas (FuzzyDW) Operar en un FuzzyDW Manejar información hetereogénea Proveer sistemas realmente usables, confiables y flexibles Mejorar los lenguajes de consulta (MDX)

Referencias

Referencias Kimball, R. (1997). The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses. New York: John Wiley and Sons. Livingston, G. R. (1997). Database Design for Data Warehouses: The Basic Requirements. En H. E. R. Barquin, Planning and Designing the Data Warehouse. New Jersey: Prentice Hall. F. Carpani. CMDM: Un Modelo Conceptual para la Especificación de Bases de Datos Multidimensionales, Tesis para optar al grado de Maestría. Universidad de la República Uruguay. 2000.URL:http://www.fing.edu.uy/inco/pedeciba/bibliote/te sis/tesis-carpani.pdf.

S. Chaudhuri, U. Dayal. An Overview of Data Warehousing and OLAP Technology SIGMOD Record, Vol. 26, pp. 65-74, 1997. Pearson. 2004. ISBN 8420540250. M. Golfarelli, D. Maio, S. Rizzi, The dimensional fact model: A conceptual model for data warehouses. International Journal of Cooperative Information Systems, Vol.7, Issue 3, pp. 215-247, 1998. W. Inmon, Building the Data Warehouse. John Wiley & Sons, 2002. J-N. Mazón, J. Trujillo, An MDA approach for the development of data warehouses. Decision Support Systems Vol. 45, pp. 41-58, 2008.

J-N. Mazón, J. Lechtenbörger, J. Trujillo: A survey on summarizability issues in multidimensional modeling. Data Knowl. Eng. Vol. 68. Issue 12, pp. 1452-1469. 2009. J. Trujillo, M. Palomar, J. Gómez., Il-Yeol Song, Designing Data Warehouses with OO Conceptual Models. IEEE Computer. Vol. 34, pp. 66-75, 2001.