Introducción a Data Warehousing

Presentación del tema: "Introducción a Data Warehousing"— Transcripción de la presentación:

1 Introducción a Data Warehousing

2 Objetivo Proporcionar una descripción de los elementos fundamentales de un Data warehouse, las técnicas necesarias para su construcción, una arquitectura típica , y tópicos de interés abiertos a la investigación.

3 Motivación Mercados altamente dinámicos y competitivos.
Necesidad de tomar decisiones rápidamente. Aumento de la capacidad de almacenamiento Crecientes volúmenes de información disponible. Baja de costos del Hardware.

4 Definición Data Warehousing: Almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones.

5 Qué es un Data Warehouse?
“Un Data Warehouse es una colección de datos orientada al negocio, integrada, variante en el tiempo y no volátil para el soporte del proceso de toma de decisiones de la gerencia.” W.H. Inmon

6 Características Orientado al Negocio: organiza y presenta los datos desde la perspectiva del usuario. Maneja gran volumen de datos: contiene datos históricos. Almacena información sobre diversos medios: a causa del gran volumen que debe manejar.

7 Características (cont.)
Abarca múltiples versiones de un esquema de base de datos: debido a la información histórica que contiene. Sumariza y agrega información: para presentarla de una manera comprensible para los usuarios. Integra y asocia información proveniente de diversas fuentes: datos recolectados durante años por diversas aplicaciones.

8 Qué es un Sistema de Soporte de Decisiones?
Es un sistema que provee información a sus usuarios, de forma tal que puedan analizar una situación y tomar decisiones, y de esa manera realizar su trabajo en forma más efectiva.

9 Integración de la Información
RDBMS Oracle SQL Server Sybase Active Directory Repositorio Central (Data Warehouse) 1        Data Warehousing y Olap 1.1    Introducción El término Data Warehousing se refiere a las arquitecturas, algoritmos, herramientas y técnicas que combinadas brindan la posibilidad de unificar información o datos provenientes de múltiples orígenes (bases de datos u otros medios de almacenamiento), en un único repositorio especialmente diseñado para la consulta y análisis de dicha información. Estos repositorios se denominan Data Warehouses. De esta forma el procesamiento analítico de la información (OLAP) puede realizarse sin interferir con el procesamiento transaccional de la información (OLTP). Esto permite desarrollar las tareas de análisis sin interferir con el “día a día”, ya que ambas operaciones requieren diferentes tecnologías de bases de datos, como se explica mas adelante. Se podría decir que las principales características de los sistemas OLAP son: 1.      Ofrecer una vista multidimensional de la información sin importar como esta se encuentre realmente almacenada. 2.      Ofrecer siempre una forma gráfica e interactiva de realizar consultas 3.      Permitir navegar por una consulta aumentando o disminuyendo el nivel de detalle o agregación de la misma. Esto se realiza mediante las operaciones de “drill-down”, “roll-up” y “slice and dice” que serán explicadas mas adelante en este Capítulo. 4.      Rapidez de respuesta (no mas de dos minutos en general) Rigurosamente hablando, un Data Warehouse es una base de datos que almacena datos provenientes de distintos orígenes de una organización, mientras que Data Warehousing es el conjunto de procesos que permite transformar los datos almacenados de manera tal que estos sean fáciles de consultar para la toma de decisiones. Los Data Warehouses se diferencian de los sistemas transaccionales u operacionales en varios puntos: 1.      Los Sistemas Operacionales son diseñados y optimizados para responder eficientemente a consultas del tipo: “Calcular el saldo de las cuentas que pertenecen a Juan Pérez”. El modelo Entidad-Relación usado en el diseño de Bases de Datos Operacionales genera una base de datos altamente normalizada. Sin embargo, este modelado no es útil para el diseño de un Data Warehouse. Por este motivo, nuevos modelos han sido creados de los cuales el Esquema Estrella [KIM/96] es el mas popular. Así, para poder realizar consultas OLAP, la estructura del Data Warehouse debe ser lo mas simple posible. 2.      Los sistemas Operacionales suelen trabajar al límite de sus capacidades, lo cual hace inaceptable sobrecargarlo con consultas OLAP que suelen ser muy pesadas dado que requieren múltiples operaciones de agregación. 3.      Las técnicas de indexado y procesamiento de consultas son diferente en ambos modelos. 4.      Los Sistemas Operacionales habitualmente están sometidos a múltiples operaciones “on line” mientras que los Data Warehouses son bases de datos “read only”, excepto durante el proceso de actualización y carga de la información, el cual se realiza fuera de línea. 1.1.1 On Line Analitical Processing (OLAP) y On Line Transactional Processing (OLTP) El término OLTP (On Line Transaction Procesing) [ULL/88] [NAV/94] se refiere al procesamiento transaccional de la información. En cambio, el término OLAP (On Line Analytical Processing) [COD/93] [KIM/96] es usado para caracterizar el análisis de datos sobre colecciones históricas de éstos, a efectos de contribuir al proceso de toma de decisiones. On Line Transaction Procesing (OLTP) es distinto conceptualmente a On Line Analytical Processing (OLAP) ya que [COD/93]: ·        Son distintos los usuarios. En el modelo transaccional, típicamente se encargan de ingresar los datos al sistema. Los usuarios de los sistemas OLAP son analistas de información o decidores, que no cargan datos sino que solo consultan información resumida y abarcativa, no puntual. ·        Es distinto el Uso que se le da al sistema, pues los sistemas OLTP se utilizan para ingresar las transacciones una tras otra y día tras día. En cambio el modelo OLAP se usa para la consulta de información orientada a la toma de decisiones. ·        Son distintas las características de los datos, pues en el transaccional los datos son puntuales mientras que en el modelo analítico los datos son sumarizados o totalizados con varios niveles de agrupación. ·        Son distintas las cargas de trabajo, pues en el modelo tradicional los datos se leen y actualizan permanentemente, en cambio, en los sistemas OLAP los datos son solo para consulta, salvo durante el proceso de carga. ·        Son distintas las unidades de trabajo. En los sistemas transaccionales la unidad de información es la transacción, mientras que en los sistemas OLAP es la consulta. ·        Son distintas las estructuras de las bases de datos, pues para los sistemas transaccionales estos esquemas se componen de múltiples tablas y múltiples relaciones muy complejas y difíciles de entender. Las consultas en este tipo de modelo, debido a su complejidad, no son fáciles de resolver para los usuarios finales. También es importante notar que en las bases transaccionales el objetivo es reducir la redundancia de información. En la Bases de Datos OLAP los esquemas son simples, expresados en los términos y formas en las cuales los usuarios finales entienden el negocio. Además no se intenta normalizar estas tablas pues lo que se busca es eficiencia en las consultas y no en la actualización de la información. ·        Las transacciones son distintas. En general, en OLTP, una transacción retorna o se aplica a pocas tuplas (por ejemplo, el saldo de una cuenta), mientras que en OLAP, habitualmente, todas las tuplas son procesadas. ·        Es distinta la actualización de la información, pues en los sistemas OLTP se actualiza de a un registro por vez, mientras que en los sistemas OLAP se hace la actualización en un solo paso y fuera de línea. 1.1.1 Reglas de Codd OLAP permite a los analistas, managers y ejecutivos entender los datos a través de rápidos, consistentes e interactivos accesos a una amplia variedad de vistas de la información. OLAP transforma los datos almacenados en un Data Warehouse en información valiosa. De esta forma, OLAP y Data Warehousing son procesos que se complementan. El manejo de datos de un Data Warehouse y el análisis de estos datos es llamado OLAP. Codd [COD/93] propone un conjunto de doce reglas que caracterizan un sistema OLAP en términos de acceso a datos, definición de datos, requerimientos de los usuarios, “front-end”, accesibilidad, etc. Estas reglas son: 1.      Vista conceptual multidimensional. OLAP debe permitir a los usuarios ver los datos como ven su negocio. 2.      Transparencia. El lugar donde reside el sistema OLAP debe ser transparente para el usuario. 3.      Accesibilidad. El o los sistemas desde los cuales los datos son obtenidos debe ser transparente para el usuario. Las herramientas OLAP deberán manejar datos posiblemente heterogéneos. 4.      Performance de reportes consistente. Al aumentar el numero de niveles la performance no debe decaer. 5.      Arquitectura Cliente Servidor 6.      Dimensionalidad Genérica. Cada dimensión debe ser equivalente en su estructura y capacidades operacionales. 7.      Manejo Dinámico de Matrices Esparzas. El sistema debe adaptarse a cualquier configuración de datos, cambios dinámicos, y de ser necesario, también debe adaptar sus métodos de acceso a los datos. 8.      Soporte multiusuario 9.      Operaciones sobre las dimensiones no restrictivas. Cualquier celda puede usarse en cualquier formula. 10.  Manipulación intuitiva de datos. Las operaciones de consulta deben ejecutarse de forma intuitiva. 11.  Flexibilidad para reportes. 12.  Que soporte una cantidad ilimitada de dimensiones y niveles de agregación. 1.1    Data Warehousing 1.1.1 Fases del proceso de Data Warehousing Los principales procesos dentro de un ambiente de Data Warehousing son: 1.      Extracción y Carga Este es el proceso mediante el cual se obtienen los datos de los distintos orígenes y se los carga en el Data Warehouse haciéndolos visibles para los analistas. Se debe tener en cuenta que los datos pueden provenir de distintos sistemas como Bases de Datos Relaciónales, archivos ASCII, planillas, documentos, etc., lo cual obliga al sistema de carga a trabajar sobre cada uno de estos orígenes tomar la información, transformarla a un formato común y recién después incorporarla al Data Warehouse. También es importante aclarar que la información a ser incorporada debe pasar una serie de filtros y validaciones que aseguren su consistencia e integridad. 2.      Limpieza y Transformación de datos Este es el proceso mediante el cual se incorporan los datos previamente cargados de distintos orígenes en las estructuras apropiadas para su posterior consulta (como podrían ser las del Esquema Estrella). Se particionan los datos para aumentar la performance de las consultas y se realizan las agregaciones necesarias. Este proceso transforma los datos en datos consistentes, íntegros y sin errores. 3.      Backup 4.      Consultas Esta es la etapa de consulta. Donde los analistas pueden consultar el cubo previamente cargado y validado. 1.1.2 Módulos del Data Warehouse Los distintos procesos que sufren los datos y la información dentro de un Data Warehouse son realizados por los distintos módulos que lo componen 1.      Load Manager Este es el modulo encargado de la extracción de datos de los distintos orígenes y la posterior carga de estos datos en tablas temporales y homogéneas que el Warehouse Manager pueda entender. Este modulo esta compuesto por distintos procedimientos, muchas veces en distintos lenguajes y preparados para trabajar en los distintos sistemas y ambientes donde se encuentra la información original. 2.      Warehouse Manager Este modulo se encarga de : ·        Analizar datos, chequear consistencia e integridad. ·        Transformar y mezclar los datos que el módulo de carga deposito previamente en tablas y otras estructuras temporales. ·        Depositar los datos previamente transformados y mezclados dentro de las estructuras del Data Warehouse. ·        Generar las tablas del “Esquema Estrella” o el “Esquema Snowflake”. ·        Crear Vistas, índices, etc.. ·        Crear y Actualizar agregaciones. ·        Realizar un backup de la información. ·        Analizar el rendimiento de las consultas. 3.      Query Manager Este es el módulo encargado de interpretar y evaluar las consultas. Para esto utiliza las vistas, índices y agregaciones así como también los datos y meta datos del Data Warehouse. 1.1.3 Consultas El cliente de esta arquitectura es generalmente una herramienta OLAP, que debe permitir una fácil navegación sobre el cubo de datos a efectos de obtener información útil para la toma de decisiones. Las operaciones principales que estas herramientas [ARB/97] [PIL/96] [INF/96] [PLA/98] deberían proveer son: ·        Drill-Down Posibilita aumentar el nivel de detalle de una consulta. Al navegar por un cubo y analizar por ejemplo las Ventas de una Corporación se puede aumentar el nivel de detalle de la consulta bajando en la jerarquía Producto por algunas de sus ramas hacia el nivel inmediato inferior. De esta manera se pueden ver los datos totalizados por todas las Compañía de la Corporación o bien por todas sus Categorías [KIM/96] como se puede ver en la Figura 2.1. Roll-Up Permite aumentar el nivel de agregación de una consulta sobre los datos que se están analizando. De esta manera si se están analizando por ejemplo las Unidades vendidas en todas las Ciudades de una determinada Provincia se puede, haciendo Roll-Up, subir por la jerarquía Geografía y ver los datos totalizados por Provincia en vez de por Ciudad. Por lo tanto este operador produce el efecto contrario a Drill-Down [KIM/96]. Drill-Across Este operador permite en una misma consulta involucrar más de un cubo de datos [KIM/96]. Podría suceder que dos cubos de datos compartan la dimensión Tiempo y se desee ver la unión de las ventas registradas en ambos cubos en un periodo de tiempo determinado, en este caso se utiliza el operador Drill-Across. Introduccion, Historia Data Warehouse, Data Warehousing OLAP vs OLTP Fuentes Heterogeneas. Archivo de Texto Mail Server

10 OLTP - On Line Transaction Processing
Procesamiento de los datos operacionales. Gran nivel de detalle. Ineficiente para toma de decisiones : No permite tener una visión integradora del negocio Se requiere información analítica

11 OLAP-On Line Analytical Processing
Permite recolectar y organizar la información analítica realmente necesaria y disponer inmediatamente de ella en diversos formatos (tablas, gráficos, reportes, etc.). Analiza los datos desde diferentes perspectivas (dimensiones) del negocio. Soporta análisis complejos de grandes volúmenes de datos.

12 Un Sistema OLTP no soporta las necesidades de los Sistema de Decisión porque ...
Los datos provienen de diversas fuentes y formatos. Los datos cambian a lo largo del tiempo y no fueron diseñados para ser fácilmente sumarizados. Requieren una programación menos amigable para consultarlos. Los Sistemas transaccionales a menudo están sobreutilizados.

13 OLTP vs OLAP OLTP OLAP Usuario Tipico empleado profesional
Uso del sistema operacional analizar negoc. Interaccion usuarios predeterm Ad-hoc Unidad de trabajo transaccion consulta Caracteristicas lectura/grab. Lectura Registros accedidos decenas millones Cant. De usuarios miles cientos Focalizacion ingresar datos extraer info.

14 Objetivos de un Data Warehouse
Permitir el acceso a los datos de la organización, en forma inmediata, sobre demanda y con alta performance. Manejar datos consistentes. Permitir que los datos puedan ser separados y combinados.

15 Objetivos (cont). DW no es sólo datos sino un conjunto de herramientas para consultar, analizar y presentar información (OLAP). Ser el lugar donde se publican los datos usados en la organización. La calidad de los datos en el DW es un indicador de la necesidad de efectuar una reingeniería del negocio (manifestado por la cantidad de datos irrelevantes que le llegan).

16 Tecnologías Arquitecturas abiertas cliente/servidor.
Técnicas avanzadas para replicar, refrescar y actualizar datos. Software “front-end” para acceso y análisis de datos.

17 Tecnologías(cont.) Herramientas de software para extraer, transformar y cargar datos desde múltiples fuentes heterogéneas. Bases de datos diseñadas para manejar altos volúmenes de datos.

18 Modelo de Datos Componentes :
Fuentes de datos. Sistemas operacionales, información externa, etc.. Meta Datos. Estructura, definición ,origen y Dependencias de Datos. Data Warehouse. Datos organizados y herramientas para su análisis. Usuarios . Responsables de tomar decisiones.

19 Arquitectura Los datos son extraídos desde las aplicaciones, bases de datos y archivos. Los datos de las diversas fuentes son integrados y transformados antes de ser cargados en el DW. El DW es una BD read-only creada para soporte de decisiones específicamente. Los usuarios acceden el DW usando una herramienta “front-end” o una aplicación.

20 ARQUITECTURA DE UN DW (que abarca los procesos)

21 Estructura del Data Warehouse
Proceso de sumarización muy sumarizado poco sumarizado Datos operacionales Datos históricos detallados

22 Fases del Ciclo de Vida de un DW
Planeamiento (plan del proyecto). Análisis de requerimientos de usuarios. Diseño y desarrollo de la Base de Datos. Extracción , transformación y carga de datos.

23 Fases del Ciclo de Vida de un DW
Selección del software apropiado. Desarrollo de las aplicaciones. Creación del conjunto inicial de informes. Validación y prueba de los datos. Capacitación de usuarios. Rollout.

24 Metadatos tablas, nombres y sumarizaciones.
Ubicación y descripción de servers, bd, tablas, nombres y sumarizaciones. Reglas para “drill-down y roll-up” de jerarquías de dimensiones de negocio. Descripción de fuentes y transformaciones de datos.

25 Metadatos (cont.) Definiciones lógicas de tablas y atributos.
Definiciones físicas de tablas y columnas. Historia de extracciones. Algoritmos de sumarización. Indicadores de calidad de datos.

26 Metadatos (cont.) Permiten la localización de información en el DW.
Describen cómo cierta información es derivada desde otra. Almacenan las reglas de negocio que se definen en el DW.

27 Diseño de la Base de Datos
Las metas de un Sistema de Soporte de Decisión se logran por medio del Modelado Multidimensional. Su principal herramienta es el denominado Esquema Estrella.

28 Esquema Estrella Diseño de BD con los mejores tiempos de respuesta.
Diseño fácilmente modificable. Paralelismo entre el diseño de la BD y cómo los usuarios visualizan y usan los datos.

29 Por qué no el Modelo E/R? Pensado para obtener una BD altamente normalizada, adecuada para Sistemas con muchas transacciones que acceden a un número pequeño de registros. Adecuado para OLTP, donde los datos son fuertemente estructurados. En DSS la normalización afecta la eficiencia de las consultas( dificulta el drill-down y el roll-up).

30 Dos tipos de tablas: Tablas de Hechos Tablas de Dimensiones
Esquema Estrella Dos tipos de tablas: Tablas de Hechos Tablas de Dimensiones

31 Dimensiones Son los parámetros naturales del negocio. Ej.: Productos, Cuentas, Tiempo. Se organizan en jerarquías, que permiten el roll-up y drill-down, mediante los elementos dimensionales . Ej.: Días, Meses, Años. Cada elemento dimensional se describe con un atributo en la tabla de Dimensiones. La tabla de Dimensiones generalmente se diseña desnormalizada.

32 Esquema Estrella Simple: Ventas
Dimensión Dimensión Esquema Estrella Simple: Ventas Períodos Productos Ventas Período DescrP Trimestre Año Producto DescrPr Marca Tamaño Período Producto Mercado Importe Precio Descuento Mercados Mercado DescrM Distrito Región

33 Ventas Ubicación Producto Local_ID Nombre_Loc Dirección Región
Distrito Gte _Distrito C_postal País Superf_Cub Producto_ID Categoría_Pro Nombre_Prod Gte_Producto Proveedor Unidad_Medid Costo_Unitario Ventas Local_ID Producto_ID DDMMAAAA Agente_ID Vtas_unidades Vtas_importe Forma_Pago Vendedor Tiempo Agente_ID Nombre_Agente Categoría_Agente Antiguedad DDMMAAAA Día_Semana Día_Año Semana_mes Semana_trim

34 Normalización de Dimensiones
Esquema “snowflake”. Mayor complejidad en la estructura. Mejor performance? Mejor uso del espacio. Util en tablas de Dimensiones de muchas tuplas.

35 Ventas Local Proveedor Ubicación Producto Agente Vendedor Estación
Local_ID Dirección Superfic Tipo Local_ID Cod_Dist Cod_Reg Prov_ID Nombre Domicilio Producto_ID Prov_ID Categoría_Pro Nombre_Prod Gte_Producto Unidad_Medid Costo_Unitario Ventas Distrito Local_ID Producto_ID DDMMAAAA Agente_ID Vtas_unidades Vtas_importe Forma_Pago Cod_Dist Nombre Región Agente Cod_Reg Nombre Agente_ID Nombre_Agen Categoría Antiguedad Vendedor Estación Agente_ID Depto-V-ID DDMMAAAA Día_Semana Cod_Estac Cod_Estac Nombre Clima Depto_V_ID Nombre Dep-Vtas Tiempo

36 Arquitecturas Multidimensionales
ROLAP MOLAP Arquitectura física (ROLAP/MOLAP/HOLAP) Los sistemas OLAP proveen una vista multidimensional de los datos. Esto no significa que invariablemente los datos se almacenen en una forma multidimensional. Los datos son percibidos por el usuario como un cubo multidimensional donde cada celda contiene un valor o medida con cierto nivel de agregación. La arquitectura física de la información, es decir la forma en la que esta se almacena, puede variar sin que esto afecte la forma en la que el usuario percibe el cubo de datos. Si los datos se almacenan en forma multidimensional, es decir, mediante vectores o matrices esparzas, se dice que la arquitectura física de la información es MOLAP (Multidimensional OLAP). Si, en cambio, los datos se almacenan en bases de datos relacionales se dice que la arquitectura es ROLAP (Relational OLAP). Existen también formas híbridas de almacenamiento de la información llamadas HOLAP (Hybrid OLAP) [LAZ/97] Entre las arquitecturas ROLAP y MOLAP hay varias diferencias relacionadas con: 1.      Forma de almacenamiento de la información: En ROLAP la información se almacena en bases de datos relacionales, mientras que en MOLAP la información se almacena en arreglos propietarios especialmente diseñados para el análisis dimensional. 2.      Acceso a la información: En ROLAP la información es accedida mediante SQL. En MOLAP la información es accedida mediante algoritmos propietarios que trabajan sobre vectores o matrices esparzas. 3.      Aplicabilidad: Un ROLAP Server es usado generalmente en Data Warehouses que almacenan gran variada y cantidad de información sobre varias áreas de una organización. Mientras que MOLAP esta destinado a Data Marts (pequeños Data Warehouses dedicados exclusivamente a solo un sector de la organización). 4.      Tamaño de la base de datos sobre la cual trabaja: Debido a que un ROLAP Server trabaja sobre una base de datos relacional, este puede almacenar grandes cantidades de información destinando gran cantidad de recursos al indexado y permitiendo así un rápido acceso a los datos. Por este motivo la capacidad de almacenamiento de un ROLAP Server es del orden de los tetra bytes. Mientras que las capacidad de un MOLAP Server es del orden de los giga bytes. 5.      Capacidad y facilidad de actualización del cubo de datos: Debido a la forma de almacenamiento de la información es más sencilla la actualización en un ROLAP que en un MOLAP Server. 6.      Performance: La performance de un MOLAP Server es en general buena debido a que sus métodos de acceso trabajan sobre estructuras propietarias, especialmente diseñadas para estos fines, y a que su capacidad de almacenamiento de información es reducida. En un ROLAP Server, estas características dependen de cada producto. 7.      Manejo Multidimensional de los datos físicamente almacenados: El manejo de los datos en un ROLAP Server esta limitado por la capacidad del lenguaje de consulta (SQL). Por este motivo muchos de los cálculos requeridos para el manejo multidimensional de la información como ser Rankings, Movings Averanges y otros, son realizados fuera del servidor relacional, en el cliente o en el Servidor OLAP. 8.      Desarrollo de cada tecnología: Los ROLAP Servers están más desarrollados y hay más productos en el mercado que los MOLAP Servers debido a que la tecnología relacional tiene un mayor grado de madurez. HOLAP

37 MOLAP Tecnología optimizada para consultas y análisis , basada en el modelo multidimensional. Motor especializado. Herramientas limitadas y propietarias. Alta eficiencia de procesamiento. No adecuada para muchas dimensiones . Cota superior : 10 Gb de datos. Util para Data Marts.

38 ROLAP Almacena los datos en una BD Relacional.
3 capas lógicas: De almacenamiento (BDR), de análisis (visión conceptual de los datos) , y de presentación. Todos los beneficios de la tecnología relacional.

39 OLAP (Cont.) Multidimensional vs.Relacional

40 On-Line Analytical Processing OLAP
Multidimensionales ---> MOLAP Ej. Hyperion Essbase D&B/Pilot LightShip Cognos PowerPlay

41 On-Line Analytical Processing OLAP
super-relacionales ----> ROLAP Ej. Informix Meta Cube MicroStrategy DSS Server Red Brick

42 On-Line Analytical Processing OLAP
Híbridos -----> HOLAP Ej. Oracle Express MS SQL Server 7

43 El Cubo de Datos Sucursal Dimensiones del Cubo de Datos
Producto Sucursal Fecha ALL ALL ALL Corporación Pais Año Marca Ciudad Cuatr. Semana itemId Barrio Mes sucId Día y Hora Producto p5 p1 p2 p3 p4 p6 El Cubo de Datos En un Data Warehouse los datos son presentados en forma multidimensional. Esto, como se dijo previamente, no implica que la información se almacene de esta forma. Sin embargo un usuario final percibe los datos como organizados según un cubo (Data Cube) donde sus ejes son denominados Dimensiones y sus celdas Medidas. Los cubos o hipercubos están compuestos por un conjunto de dimensiones las cuales se mapean en forma de coordenadas dentro del cubo. Cada coordenada tiene asociada una serie de valores denominados “medidas”. Por ejemplo un cubo llamado Ventas podría estar compuesto por las dimensiones Tiempo, Geografía y Producto y sus coordenadas corresponderían a la cantidad de productos vendidos en una Geografía y Tiempo dado para un Producto determinado. Cada dimensión esta organizada en forma jerárquica. Los miembros de una dimensión son cada una de las posibles instancias de los niveles de su jerarquía. Por ejemplo la jerarquía asociada a la dimensión Geografía puede estar compuesta de los niveles País, Provincia y Ciudad, y los miembros asociados al nivel País podrían ser Argentina, Uruguay, etc. Los atributos están asociados a los niveles de las jerarquías y estos son propiedades descriptivas de los miembros del nivel. Por ejemplo el nivel País podría tener los atributos Cantidad de Habitantes y Presidente. Los cubos y la definición de las dimensiones son agrupados dentro de un esquema [KIM/96]. Un usuario puede analizar información del cubo realizando cortes y divisiones (slice & dice) del cubo en cada una de sus dimensiones lo cual le permite navegar, comprender y visualizar los datos [KIM/96]. Dimensiones, Jerarquias, Niveles, Miembros o Instancias Medidas, Agregaciones. Consultas del Cubo, Cortes, Divisiones, Roll-up y Drill-down. Percepcion vs Implementacion. Fecha 1 2 3 4 7 6 5

44 Aplicaciones usuales Finanzas Marketing Control de Gestión
Contabilidad Ingeniería Actuarial

45 Ejemplos de Consultas Grafique la contribución a las ventas semanales y beneficios ,de los ítems vendidos en las sucursales de la zona sur durante el mes de enero. Grafique las ventas reales contra las previstas ,para cada trimestre del ejercicio, y compárelas contra los mismos trimestres del año anterior

46 Uso de un Data Warehouse Herramientas para el Soporte de Decisiones: se usan para recuperar, manipular y analizar los datos, y luego presentar los resultados.

47 Uso de un Data Warehouse Las herramientas se usan en dos modos:
Uso de un Data Warehouse Las herramientas se usan en dos modos: - Verificación Descubrimiento.

48 Uso de un Data Warehouse Herramientas que implementan el modo de verificación: - herramientas de consulta. - sistemas de reporting. - herramientas de análisis multidimensional.

49 Uso de un Data Warehouse Modo de descubrimiento: las herramientas tratan de descubrir características en los datos, tales como patrones de comportamiento y asociaciones, que no son previamente conocidas por el usuario. Ej.: herramientas de Data Mining.

50 Temas de Investigación
Manejo del DW Diseño Carga (DW 7 x 24 x 365) Metadatos Evolución de las fuentes y del DW. Información duplicada y/o inconsistente. debido a la diversidad de orígenes de los datos. Información desactualizada. Cómputo del data cube

51 Arquitectura Integrador DW Wrapper/Monitor Wrapper/Monitor
Fuente Fuente Fuente

52 Fuentes de Datos Cooperativas ( proveen triggers)
Logged ( mantienen un log , del que se extrae la información) Consultables ( Permiten al Monitor consultarlas a efectos de detectar cambios) Snapshot. (solo proveen dumps periódicos).

53 Wrapper/Monitor Traduce la información desde el modelo de la fuente al modelo del DW. Detecta los cambios en la fuente, que son de interés para el DW, y le informa al integrador. Cada tipo de fuente requiere de un WM distinto. Problema abierto : automatizar la implementación del WM para todo tipo de fuente

54 Integrador(cont.) El problema de Materialización de vistas es más complejo en DW porque : El integrador está débilmente acoplado a la fuente de Datos. Las fuentes sólo reportan cambios, sin participar en el mantenimiento de las vistas. Normalmente es necesario transformar los datos base (data scrubbing), antes de integrarlos al DW.

55 Optimizaciones Filtrado de Updates Automantenimiento de vistas
Determinar qué modificaciones a los datos base son relevantes al DW ( producen cambios en las vistas). Automantenimiento de vistas determinar cuando es posible modificar los agregados sin recurrir a los datos base

56 Optimizaciones(cont.)
Optimización de vistas múltiples Los DW en general almacenan múltiples vistas. Podría ser más eficiente materializar solamente algunas de ellas. Este es otro tema abierto de investigación.

57 Otros temas .. Manejo del DW Evolución de las fuentes y del DW.
Diseño Carga Metadatos Evolución de las fuentes y del DW. Información duplicada y/o inconsistente. debido a la diversidad de orígenes de los datos. Información desactualizada.

58 Bibliografía Barquin: Planning & Designing the Data Warehouse. Wiley Devlin: Data Warehouse: from Architecture to Implementation. Addison Wesley Gill: The Official Guide to Mining. The Data Warehousing. QUE

59 Bibliografía (Cont.) Inmon: Building the Data Warehouse. Wiley. 2º Edición Inmon: Managing the Data Warehouse. Wiley Kimball: The Data Warehouse Toolkit. Wiley Mattison: Data Warehousing. Wiley Poe: Building a Data Warehouse for Decision Support. Prentice-Hall