Modelo Dimensional Mg. Samuel Oporto Díaz.

Presentación del tema: "Modelo Dimensional Mg. Samuel Oporto Díaz."— Transcripción de la presentación:

1 Modelo Dimensional Mg. Samuel Oporto Díaz

2 Mapa del Curso Inteligencia de Negocios Metodología Kimball
Planeamiento del Proyecto Modelo del Negocio Modelado Dimensional Modelado Físico ETL Reportes Minería de Datos

3 Tabla de Contenido Información y Conocimiento
Sistemas transaccionales y sistemas analíticos Inteligencia de negocios Almacenes de datos.

4 Objetivos Describir el rol de la Inteligencia de Negocios (BI) y del Datawarehouse en el actual mercado. Describir porque un Sistema de Procesamiento Transaccional en Línea (OLTP) no se ajusta a un reporte analítico. Describir como se procesa las consultas de soporte a las decisiones en un DW . Explicar porque los negocios se orientan a manejar tecnología de Datawarehouse.

5 MODELOS RELACIONALES Y DIMENSIONALES

6 Dos técnicas Modelo E-R Entidades Atributos Relaciones
Modelo dimensional Hechos Dimensiones Medidas

7 E-R - Modelo dimensional
El modelo dimensional puede verse como un caso particular del modelo relacional. Foreing keys Dimensión Hecho Entidad

8 Modelo Estrella Eficiencia Soportado por múltiples RDBMS
Análisis de datos de menor complejidad, debido a la de-normalización

9 Modelo Copo de Nieve Mayor normalización, es decir, los niveles de las jerarquías se normalizan. Mayor flexibilidad Mayor dificultad de mantenimiento Joins más costosos Menos registros en las dimensiones.

10 MODELADO DIMENSIONAL

11 Modelado Dimensional Es una adaptación del modelo relacional.
Consiste de tablas de hechos que se caracterizan usando dimensiones y medidas. La información sobre un hecho (actividad) se representa mediante indicadores (medidas o atributos de hecho). La información de cada dimensión se representa por un conjunto de atributos (atributos de dimensión). Una dimensión es el contexto de un hecho, tienden a ser discretas y jerárquicas. Un indicador es una cantidad que describe el hecho, debe ser agregables.

12 Conceptos básicos Hecho. Evento, actividad, item transacción del negocio. Medida. Atributo o medida de hechos, métricas del negocio Dimensión. Característica de un hecho. Jerarquía. Relaciones padre-hijo dentro de una dimensión Tabla de hechos: Almacena eventos y las métricas. Tabla de dimensión. Almacenan las dimensiones.

13 Hechos 1 Representan un evento o actividad específica, tiene dimensiones y medidas. Representan un item de negocio, una transacción o un evento que tiene significancia para el negocio. Corresponden a una colección de items de datos y datos de contexto. Son aquellos datos que residen en una tabla de hechos y que son utilizados para crear indicadores, a través de sumarizaciones preestablecidas. Un hecho debe estar relacionado al menos con una dimensión: “El tiempo”.

14 Medidas – Métricas - Hechos
2 Es un atributo numérico de un hecho que representa la performance o comportamiento del negocio relativo a la dimensión Ejemplos: Ventas en $$ Cantidad de productos Total de transacciones Cantidad de pacientes admitidos Llamadas efectuadas. ImporteTotal = precioProducto * cantidadVendida Rentabilidad = utilidad / PN CantidadVentas = cantidad PromedioGeneral = AVG(notasFinales)

15 Hechos o medidas Representan los valores que son analizados.
2 Representan los valores que son analizados. Características de las medidas: Deben ser numéricas. Porque estos valores son las bases de las cuales el usuario puede realizar cálculos. Cruzan todas las dimensiones en todos los niveles. Si la medida es no numérica debemos codificarla a un valor numérico y cuando tengamos que exponerla decodificarla para mostrarla con el valor original.

16 Hechos o medidas Las medidas pueden clasificarse en: Naturales.
2 Las medidas pueden clasificarse en: Naturales. Son aquellas que se obtiene por agregación de los datos originales. Suma: suma los valores de las columnas Cuenta: conteo de los valores Mínima: valor mínimo Máxima: valor máximo Cuenta de Distintos: valores diferentes Calculadas Si se derivan de una medida natural. Cálculos Matemáticos Expresiones condicionales Alertas

17 Dimensiones 3 Es una característica de un hecho que permite su análisis posterior, en el proceso de toma de decisiones. Determina el contexto del hecho (quién participó, cuándo y donde pasó y su tipo). Es una entidad de negocios respecto de la cual se deben calcular las métricas (clientes, productos, tiempo) Tienden a ser discretas y jerárquicas <país, región, departamento, provincia, distrito>. Es una colección de miembros o unidades o individuos del mismo tipo que permite categorizar un hecho.

18 Dimensiones Se utilizan como parámetros para los análisis OLAP
3 Se utilizan como parámetros para los análisis OLAP Las dimensiones habituales son: Dimensión Miembro Tiempo Meses, Trimestre, Años Geografía País, Región, Ciudad Cliente Id Cliente Vendedor Id Vendedor

19 Designing Summary Tables
Average Maximum Total Percentage Units Sales(€) Store Product A Total Product B Product C Summary Tables Summary tables contain fact data that is aggregated using functions such as total, average, and margin. The summary table shares the dimensions used by the fact data. Summary data usually exists in summary fact tables, but it may exist in dimension tables if it is discrete (such as year-to-date figures). For example, a customer dimension may contain attributes, such as city, state, and country. The summary table can use these hierarchical attributes to show summary measures for those dimensions of the business. How Many Summaries? The issue with summary tables is not whether you are going to have any, but how many you are going to have. Business users require summary information. For example, a manager needs the bottom line figures that show how well the company is performing. Analysis of the requirement is instrumental in ensuring that the users get the information they need and quickly. A warehouse may contain hundreds of summary tables. Designing Summary Tables Deciding on what summary data to maintain in the warehouse is an early design consideration, and is based upon the users’ query requirements. These requirements are determined early on during analysis, and should be documented, implemented, and monitored. You can identify a summary requirement not specified earlier by monitoring code to identify GROUP BY clauses used commonly in SQL statements. A well designed set of summary tables improves query performance by allowing queries direct access to precomputed summaries and predefined views of data.

20 Summary Tables Example
SALES FACTS Sales Region Month 10,000 North Jan 99 12,000 South Feb 99 11,000 North Jan 99 15,000 West Mar 99 18,000 South Feb 99 20,000 North Jan 99 10,000 East Jan 99 2,000 West Mar 99 SALES BY MONTH/REGION Month Region Tot_Sales$ Jan 99 North 41,000 Jan 99 East 10,000 Feb 99 South 40,000 Mar 99 West 17,000 SALES BY MONTH Month Tot_Sales Jan 99 51,000 Feb 99 40,000 Mar 99 17,000 Summary Tables Example Assume a banking scenario. Simple cumulative data gives the total of deposit transactions, summarized in the warehouse, for that day and every other day thereafter. With this method there is no loss of detail, but a lot of processing is required when querying data. Rolling summarized data brings in daily totals for the first seven days. On day eight, the first seven days are totaled and stored as a weekly record. At the end of the month, weekly records are added together to create a monthly record. You reset weekly and monthly records (slots) to zero at appropriate points. With this method there is less processing required when querying data, but the detail is lost. Note: Summary data is also referred to as aggregated data, aggregated facts, or aggregated detail. Summary Table Management The requirement for summary tables may change over time, as what constitutes a popular query changes. Queries may be seasonal, for example, you may have specific queries for spring, summer, autumn, and winter. The query management process should be able to identify the summaries that are used, the summaries that need to be created, and the summaries that may be removed. Class Management Note Summary data is also covered in lesson 5, Advanced Design Issues and Summary Tables.

21 Summary Management in Oracle8i
Sales summary Sales Region State City Product Time Summary usage Summary advisor Space requirements Summary recommendations The various architectural elements used in summary management are: Fact tables which represent business transactions in an enterprise. In the example, the SALES table containing sales data for several products, sold by a company spread across many regions, is the fact table. Fact tables contain one or more columns such as AMOUNT that may need to be summarized. For example, you may need to obtain yearly sales for each product sold by the company. A fact table is joined to several dimension tables through keys. REGION, STATE, CITY, TIME and PRODUCT are examples of dimension tables. These along with the SALES table, comprise the detail tables in this example. Oracle8i summary management features includes three major components: Query-rewrite capabilities Mechanisms for maintaining summary tables, including incremental updates Advisory capabilities that help the warehouse administrator create and delete summaries, based on usage

22 How and where should it be stored?
The Time Dimension Time is critical to the data warehouse. A consistent representation of time is required for extensibility. Sales fact Time dimension The Time Dimension Because online transaction data, typically the source data for the warehouse, does not have a time element, you apply an element of time in the extraction, transformation and transportation process. For example, you might assign a week identifier to all the airline tickets that sold within that week. The transaction may not have a time of date stamp on it, but you know what date the sale has occurred by the generation of the transaction file. The dimension of time is most critical to the data warehouse. A consistent representation of time is required for extensibility. Storing the Time Dimension Typically there is a time dimension table in the data warehouse although time elements may be stored on the fact table. Before deciding where to store time, you must consider the following: Almost every data warehouse has a time dimension. Organizations use a variety of time periods for data analysis. A row whose key is an SQL date, may be populated. with additional time qualifiers needed to perform business analysis, such as: workday, fiscal period, and special events. Time key on the fact table (usually in SQL DATE format) could be enough if queries limit themselves to day, month, or year-type analyses. How and where should it be stored?

23 Jerarquía de las dimensiones
4 Una jerarquía representa una relación lógica entre los datos de una dimensión. Estos datos poseen una relación “padre-hijo”.

24 Jerarquía de las dimensiones
4 Tienen las siguientes características: Se presentan al interior de una dimensión. Pueden existir varios niveles (dos o más) Relación “1-n” o “padre-hijo” entre atributos consecutivos de un nivel superior y uno inferior. Se pueden identificar cuando existen relaciones “1-n” o “padre-hijo” en la dimensión.

25 Origen de las Jerarquías
4 Entre los atributos de una dimensión se definen jerarquías. Producto nro. producto categoría tipo Almacén ciudad región almacén tipo Tiempo día mes trimestre año semana

26 Granularidad 4 La granularidad es el nivel de detalle en que se almacena la información. Por ejemplo: Datos de ventas o compras de una empresa, pueden registrarse día a día Datos pertinentes a pagos de sueldos o cuotas de socios, podrán almacenarse a nivel de mes. A mayor nivel de detalle, mayor posibilidad analítica, ya que los mismos podrán ser resumidos o sumarizados. Los datos con granularidad fina (nivel de detalle) podrán ser resumidos hasta obtener una granularidad media o gruesa. No sucede lo mismo en sentido contrario.

27 Tablas de Hechos 5 Dimensiones Las tablas de hechos contienen las dimensiones y las medidas de los hechos. Los hechos o medidas son los valores de datos que se analizan (son numéricos). La tabla de hechos tiene una clave primaria compuesta por las claves primarias de las tablas de dimensiones relacionadas a este. Medidas o hechos

28 Tabla de dimensiones Definen la organización lógica de los datos.
6 Definen la organización lógica de los datos. Tiene una PK (única) y columnas de referencia: Clave principal (PK) o identificador único. Clave foráneas. Datos de referencia primarios (identifican la dimensión) Datos de referencia secundarios (complementan la descripción). No siempre la PK del OLTP, corresponde con la PK de la tabla de dimensión relacionada.

29 EJERCICIO

30 Ejercicio Etapas en la construcción de un modelo dimensional: 2 3 4 1
Requerimientos del usuario Construcción de las Dimensiones Armado de la Tabla de Hechos Definición de las Medidas 2 3 4 Decidir la granularidad 1

31 Requerimientos del usuario
Dimensiones Medidas Tiempo Sucursal Vendedor Cliente Producto Ventas_Importe X Ventas_Costo Ventas_Unidades Ventas_ImporteTotal Ventas_Ganancia Ventas_Promedio

32 Decidir la granularidad
1 La granularidad: Es el nivel de detalle al que se desea almacenar información sobre la actividad a modelar. Define el nivel atómico de datos en el almacén de datos. Determina el significado de las tuplas de la tabla de hechos. Determina las dimensiones básicas del esquema. Por ejemplo en la dimensión Sucursal:

33 Decidir la granularidad
1 Ejemplo de la dimensión fecha. Se desea los datos por: Información anual Información semestral Información trimestral Información mensual. .... Información semanal Información diaria Transacción en el OLTP + granularidad + detalle

34 Construcción de las dimensiones
2 Identificar las dimensiones que caracterizan el proceso al nivel de detalle (gránulo) que se ha elegido. De cada dimensión se debe decidir los atributos (propiedades) relevantes para el análisis de la actividad. Entre los atributos de una dimensión existen jerarquías naturales que deben ser identificadas (día-mes-año) Tiempo. Cuándo se produce la actividad Sucursal. Donde está ubicado el almacén Vendedor. Quién ha vendido Cliente. Quién es el destinatario de la actividad Producto. Cuál es el objeto de la actividad

35 2 Dimensiones Medidas Tiempo Sucursal Vendedor Cliente Producto
Ventas_Importe X Ventas_Costo Ventas_Unidades Ventas_ImporteTotal Ventas_Ganancia Ventas_Promedio

36 2 Dimensiones Medidas Tiempo Sucursal Vendedor Cliente Producto
Ventas_Importe X Ventas_Costo Ventas_Unidades Ventas_ImporteTotal Ventas_Ganancia Ventas_Promedio

37 Tabla de Hechos 3 Dimensiones Medidas Tiempo Sucursal Vendedor Cliente
Producto Ventas_Importe X Ventas_Costo Ventas_Unidades Ventas_ImporteTotal Ventas_Ganancia Ventas_Promedio

38 Definición de las medidas
4 Medidas

39

40 ROLAP, MOLAP, HOLAP

41 Tipos de OLAP. OLAP Relacional (ROLAP) OLAP Multidimensional (MOLAP)
OLAP Híbrida (HOLAP)

42 Esquema Físico MOLAP - Multidimensional OLAP. HOLAP - OLAP híbrido
Existe tres formas de almacenar los datos: . MOLAP - Multidimensional OLAP. HOLAP - OLAP híbrido ROLAP - Relacional OLAP.

43 MOLAP En un sistema MOLAP (OLAP multidimensional) los datos se encuentran almacenados en una estructura multidimensional. Para optimizar los tiempos de respuesta, el resumen de la información es usualmente calculado por adelantado. Estos valores pre-calculados o agregaciones son la base de las ganancias de desempeño de este sistema. Algunos sistemas utilizan técnicas de compresión de datos para disminuir el espacio de almacenamiento en disco debido a los valores pre-calculados.

44 ROLAP ROLAP (OLAP Relacional) es un sistema en el cual los datos se encuentran almacenados en una base de datos relacional. Típicamente, los datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas.

45 HOLAP Un sistema HOLAP (OLAP Híbrido) mantiene los registros detallados en la base de datos relacional, mientras que los datos resumidos o agregados se almacenan en una base de datos multidimensional separada. Este método de almacenamiento es una combinación de los dos anteriores e intenta rescatar lo mejor de cada uno.

46 PREGUNTAS