Sistemas de Información
UNIVERSIDAD CENTRAL DE VENEZUELA
FACULTAD DE CIENCIAS
ESCUELA DE COMPUTACION
´
Tema 6: Inteligenci...
Introducción
Origen y Definición
Soluciones Analíticas
¿Qué es OLAP?
Características de las Soluciones analíticas
Agenda
©...
Objetivos de Aprendizaje
Al finalizar este capitulo, usted estará en capacidad de:
• Los conceptos básicos de OLAP
• Enten...
Introducción
Origen y definición
¿Qué es OLAP?
Características de las Soluciones
Analíticas
© 2010, Universidad Central de...
Modelaje Multi-dimensional
© 2010, Universidad Central de Venezuela. Sistemas de Información.
Modelaje Multi-dimensional
C...
Un modelo dimensional
(lógico)
Cubos y cubos virtuales
Dimensiones privadas y
compartidas
Medidas calculadas en el cubo y ...
Cubos y modelos estrella
• Cubo
– Construcción lógica que contiene medidas (valores) y atributos,
aglomerados en un espaci...
Cubos y Modelo Estrella
• Cubo
Employee
Product
Geography
Sales Facts
Customer Time
Modelo Estrella
© 2010, Universidad Ce...
Esquema de Mondrian
• Un archivo XML que define
– Cubos (Métricas + Dimensiones)
– Seguridad y Tablas Agregadas
• Define l...
Arquitectura OLAP Pentaho
• Motor: crea vista
“multidimensional” en base de
datos relacionales
• Estándares abiertos (Java...
Arquitectura OLAP Pentaho
© 2010, Universidad Central de Venezuela. Sistemas de Información.
11
Cálculos sumarizados por jerarquias
Año
Trim.
La data es
sumarizada por
cada nivel de la
jerarquía
© 2010, Universidad Cen...
Métricas de Ventas por la Dimensión de Tiempo
220
90 130
1st Half 2nd Half
2008
Datos de venta
sumarizados por
nivel
© 201...
El modelo de datos relacional esta impulsado por la necesidad de Unir
(Join) varias tablas. La complejidad y numero de est...
Las métricas son números que “miden” tu negocio
Las métricas son como arreglos y son automáticamente
asociadas a la column...
Esquema Mondrian
© 2010, Universidad Central de Venezuela. Sistemas de Información.
16
Conceptos OLAP: Cubos y Jerarquias
© 2010, Universidad Central de Venezuela. Sistemas de Información.
17
Bases de datos relacionales organizan datos en tablas
planas de dos dimensiones.
Filas y columnas con intersecciones única...
Conceptos OLAP: Dimensiones y Medidas
Los cubos pueden tener más
de dos dimensiones.
El cubo del diagrama tiene
cuatro dim...
Conceptos OLAP: Levels
• Cada dimensión contiene
niveles.
• Por ejemplo, la dimensión
Origen (Source) en el
diagrama tiene...
Conceptos OLAP: Miembros
• Cada nivel organiza los
elementos básicos de
una dimensión en
miembros.
• Cada miembro
represen...
Construcción Básica de un Cubo Mondrian
• Un cubo básico de Mondrian sigue la siguiente estructura en XML
<Cube>
<Dimensio...
Mapeo de Tablas Dimensión en Mondrian
• Para esquemas estrella, una tabla de dimensión
única mapea a una dimensión de Modr...
Una Dimensión Simple (Ejemplo)
• La dimensión Cliente (Customer) tiene una jerarquía con 3 niveles
– Región -> Estado -> C...
Principales Atributos de Dimensiones
Nodo XML Atributo o <Node> Comentario
Dimension foreignKey La columna de la clave for...
Las medidas mapean a columnas en la tabla hecho y generalmente son
definidas como nodos en una definición de cubo.
<Measur...
En dimensiones de tiempo, los usuarios
generalmente quieren visualizar el nombre del
mes, pero lo tienen ordenado por su n...
Las dimensiones de tiempo basadas en
año/mes/semana/día son codificadas de manera distinta en
el esquema Mondrian
Esto per...
Valor LevelType Significado
Definiendo Dimensiones de Tiempo
• El nodo <Dimension> de tiempo debe tener el siguiente valor...
Dimensión de Tiempo (Ejemplo)
<Dimension name=“Time" type="TimeDimension“ foreignKey=“order_date”>
<Hierarchy hasAll="true...
Un ejemplo de dos jerarquías de tiempo, una agregando a semanas y la otra a
meses
<Dimension name="Time" foreignKey=“date_...
Este ejemplo muestra la unión de la dimensión Tipo de Almacenamiento con el cubo de
Ventas usando la clave foránea sales_f...
Este ejemplo muestra el uso de la tabla Estado dos veces en un mismo hecho de
movimiento, uno para una relación de Inicio ...
Una dimensión degenerada es una dimensión que es
representada como una columna en la tabla de hechos :
Dimensiones Degener...
Se declara una dimensión sin una tabla, y Mondrian asume
que las columnas vienen de la tabla de hechos.
<Cube name="Checko...
El mapeo de tablas en el esquema le dice a Mondrian cómo
leer los datos, pero Mondiran es lo suficientemente
inteligente c...
Conclusiones
• Hemos realizado un estudio de …..
• Hemos hecho una discusión sobre….
• Se han desarrollado demostraciones ...
Upcoming SlideShare
Loading in …5
×

Inteligencia de negocio parte v - modelo multidimensional - cubos

4,622 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,622
On SlideShare
0
From Embeds
0
Number of Embeds
1,325
Actions
Shares
0
Downloads
182
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Inteligencia de negocio parte v - modelo multidimensional - cubos

  1. 1. Sistemas de Información UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS ESCUELA DE COMPUTACION ´ Tema 6: Inteligencia de Negocio. Modelado Multidimensional Cubos 1 Prof. Wilfredo Rangel
  2. 2. Introducción Origen y Definición Soluciones Analíticas ¿Qué es OLAP? Características de las Soluciones analíticas Agenda © 2010, Universidad Central de Venezuela. Sistemas de Información. 2 Características de las Soluciones analíticas Modelaje Multidimensional ETL Metodología de desarrollo de soluciones analíticas
  3. 3. Objetivos de Aprendizaje Al finalizar este capitulo, usted estará en capacidad de: • Los conceptos básicos de OLAP • Entender los aspectos relacionados al desarrollo de soluciones analíticas basadas en OLAP (Online © 2010, Universidad Central de Venezuela. Sistemas de Información. soluciones analíticas basadas en OLAP (Online Analitycal Processing) • La arquitectura y módulos de las soluciones analíticas • emplear metodologías de desarrollo de estándares de la industria de BI 3
  4. 4. Introducción Origen y definición ¿Qué es OLAP? Características de las Soluciones Analíticas © 2010, Universidad Central de Venezuela. Sistemas de Información. Analíticas Modelaje Multidimensional – Esquema Estrella Cubos 4
  5. 5. Modelaje Multi-dimensional © 2010, Universidad Central de Venezuela. Sistemas de Información. Modelaje Multi-dimensional Cubos
  6. 6. Un modelo dimensional (lógico) Cubos y cubos virtuales Dimensiones privadas y compartidas Medidas calculadas en el cubo y en lenguaje de consulta OLAP Muestra Datos Relacionales “Dimensionalmente” © 2010, Universidad Central de Venezuela. Sistemas de Información. lenguaje de consulta Jerarquías padre-hijo … mapeadas a esquema estrella/copo de nieve (físico) Tabla de hecho Tablas dimensiones Unidas por claves foráneas 6
  7. 7. Cubos y modelos estrella • Cubo – Construcción lógica que contiene medidas (valores) y atributos, aglomerados en un espacio lógico – Ej: Ventas por producto y fecha • Modelo Estrella © 2010, Universidad Central de Venezuela. Sistemas de Información. • Modelo Estrella – Diseño de base de datos para soportar y producir resultados necesarios para el cubo • Cubo versus Modelo Estrella – Cubo es lógico; Modelo estrella es físico – Están altamente relacionados • Tanto así, que a menudo se consideran intercambiables lo cual no es cierto 7
  8. 8. Cubos y Modelo Estrella • Cubo Employee Product Geography Sales Facts Customer Time Modelo Estrella © 2010, Universidad Central de Venezuela. Sistemas de Información. 8 • Cubo – Resultado de N dimensiones para – Metricas (Total de ventas, Este año vs el año anterior, etc) – Compuesto por • Dimensiones – Jerarquías – Niveles – Atributos • Métricas Modelo Estrella Tablas de dimensiones Miles de registros Columnas de atributos (Nombre del producto) Historia Tablas de Hechos Millones de registros Columnas agregadas (cantidad de ventas) Claves foráneas hacia las dimensiones
  9. 9. Esquema de Mondrian • Un archivo XML que define – Cubos (Métricas + Dimensiones) – Seguridad y Tablas Agregadas • Define la parte “lógica” • Hace el mapeo de lo lógico a lo físico Data Archivo XML del Esquema de Mondrian © 2010, Universidad Central de Venezuela. Sistemas de Información. lo físico MONDRIAN OLAP Query Data Warehouse SQL Queries
  10. 10. Arquitectura OLAP Pentaho • Motor: crea vista “multidimensional” en base de datos relacionales • Estándares abiertos (Java, XML, MDX, JOLAP, XML/A, SQL) • Multi-plataforma (Windows & © 2010, Universidad Central de Venezuela. Sistemas de Información. 10 • Multi-plataforma (Windows & Unix/Linux) • Arquitectura J2EE – Agrupación de Servidores – Tolerancia a fallas • Fuentes de datos – JDBC – JNDI
  11. 11. Arquitectura OLAP Pentaho © 2010, Universidad Central de Venezuela. Sistemas de Información. 11
  12. 12. Cálculos sumarizados por jerarquias Año Trim. La data es sumarizada por cada nivel de la jerarquía © 2010, Universidad Central de Venezuela. Sistemas de Información. 12 Trim. Mes
  13. 13. Métricas de Ventas por la Dimensión de Tiempo 220 90 130 1st Half 2nd Half 2008 Datos de venta sumarizados por nivel © 2010, Universidad Central de Venezuela. Sistemas de Información. 13 40 10 10 20 50 10 10 30 60 10 10 40 70 10 10 50 Jan Feb Mar Apr May Jun Jul Aug Sep Q1 Q2 Q3 Q4 1st Half Oct Nov Dec
  14. 14. El modelo de datos relacional esta impulsado por la necesidad de Unir (Join) varias tablas. La complejidad y numero de estas joins dependen de la complejidad del esquema. El modelo estrella simplifica el modelo de datos a las herramientas de consulta relacional. Sin embargo, el usuario aun debe decidir cuales tablas y columnas son necesarias para incluir en la consulta. En contraste, el cubo multidimensional aísla al usuario del esquema Beneficios de los Cubos Multi-Dimensionales © 2010, Universidad Central de Venezuela. Sistemas de Información. En contraste, el cubo multidimensional aísla al usuario del esquema subyacente porque la herramienta de consulta maneja el proceso de uniones por el usuario. El usuario puede concentrarse en el análisis de la data sin preocuparse de la estructura que lo soporta 14
  15. 15. Las métricas son números que “miden” tu negocio Las métricas son como arreglos y son automáticamente asociadas a la columna de la tabla de hecho física y sus dimensiones relacionadas. La transformación de la columna en la tabla de hecho a métrica aísla al usuario de la complejidad del esquema Métricas © 2010, Universidad Central de Venezuela. Sistemas de Información. métrica aísla al usuario de la complejidad del esquema subyacente y de la necesidad de entender como las diferentes partes del esquema se relacionan. Dentro de un cubo multi-deminsional, es extremadamente sencillo crear nuevas métricas tales como ganancia en ventas y costos de ventas simplemente multiplicando cantidadordenanda * preciounitario. 15
  16. 16. Esquema Mondrian © 2010, Universidad Central de Venezuela. Sistemas de Información. 16
  17. 17. Conceptos OLAP: Cubos y Jerarquias © 2010, Universidad Central de Venezuela. Sistemas de Información. 17
  18. 18. Bases de datos relacionales organizan datos en tablas planas de dos dimensiones. Filas y columnas con intersecciones únicas entre datos Las BD Multidimensionales dependen de estructuras llamadas cubos. Un cubo es una colección de medidas y dimensiones Conceptos OLAP: Cubos y Jerarquías © 2010, Universidad Central de Venezuela. Sistemas de Información. Un cubo es una colección de medidas y dimensiones Pueden haber n dimensiones Las medidas son evaluadas en la intersección de todas las “n” dimensiones Los cubos pueden ser esparcidos (intersecciones mínimas) o densos (muchas intersecciones) Los cubos permiten la agregación a través de jerarquías dimensionales Permite la navegación hacia arriba/abajo rápida Más flexible que una construcción basada en tablas 18
  19. 19. Conceptos OLAP: Dimensiones y Medidas Los cubos pueden tener más de dos dimensiones. El cubo del diagrama tiene cuatro dimensionse: Ruta, Origen, Tiempo, y Medidas. © 2010, Universidad Central de Venezuela. Sistemas de Información. 19 Las medidas representan los datos organizados por otras dimensiones incluidas en el cubo. El cubo del diagrama tiene dos medidas, Paquetes (Packages) y Último (Last). Dimensión Medida
  20. 20. Conceptos OLAP: Levels • Cada dimensión contiene niveles. • Por ejemplo, la dimensión Origen (Source) en el diagrama tiene dos niveles: Hemisphere Country © 2010, Universidad Central de Venezuela. Sistemas de Información. 20 diagrama tiene dos niveles: – Hemisferio que contiene los miembros Este y Oeste. – País que contiene los miembros Africa, Asia, Australia, Europa, América del Norte y Sur. Dimensión Niveles
  21. 21. Conceptos OLAP: Miembros • Cada nivel organiza los elementos básicos de una dimensión en miembros. • Cada miembro representa © 2010, Universidad Central de Venezuela. Sistemas de Información. 21 representa – un elemento de dato único dentro de una dimensión – una rebanada del cubo • En el diagrama, el nivel Hemisferio Este (Eastern Hemisphere) tiene cuatro miembros: Africa, Asia, Australia, y Europa. Nivel Miembros
  22. 22. Construcción Básica de un Cubo Mondrian • Un cubo básico de Mondrian sigue la siguiente estructura en XML <Cube> <Dimension> <Hierarchy> <Level> <Property/> </Level> © 2010, Universidad Central de Venezuela. Sistemas de Información. 22 </Level> </Hierarchy> </Dimension> <Measure/> <CalculatedMember/> </Cube> • Primero se explicarán los conceptos básicos para mapeo a un esquema estrella. • Es posible mapear a copa de nieve y estructuras relacionales similares. • Para una referencia completa de esquema: http://mondrian.sourceforge.net/schema.html
  23. 23. Mapeo de Tablas Dimensión en Mondrian • Para esquemas estrella, una tabla de dimensión única mapea a una dimensión de Modrian • Los elementos críticos a identificar antes de crear un Esquema Mondrian – Columna de Clave Foránea en Tabla de Hecho © 2010, Universidad Central de Venezuela. Sistemas de Información. 23 – Columna de Clave Foránea en Tabla de Hecho – Columna de Clave Primaria en Tabla Dimensión – Niveles de Jerarquía dentro de la Dimensión, y para cada nivel: • Columna de Clave de Nivel: Identifica unívocamente las instancias dentro del nivel • Columna de Visualización: Lo que ve el usuario final • Columna de Ordenamiento: Como las instancias de nivel están ordenadas por defecto • Columnas de propiedades: Atributos adicionales del nivel que dependen de la columna de clave de nivel • Nota: Puede haber más de una jerarquía por dimensión
  24. 24. Una Dimensión Simple (Ejemplo) • La dimensión Cliente (Customer) tiene una jerarquía con 3 niveles – Región -> Estado -> Cliente • El nivel Cliente incluye una propiedad de número de cliente • En la base de datos relacional – La columna de la clave primaria en la tabla customerdim es cust_id – La columna de clave foránea en la tabla de hecho es cust_id también • Los usuarios quieren poder manipular las medidas a través de todos los clientes © 2010, Universidad Central de Venezuela. Sistemas de Información. 24 <Dimension name="Customer" foreignKey="cust_id"> <Hierarchy name="Customer" hasAll="true" allMemberName="All customer" primaryKey="cust_id"> <Table name="customerdim"/> <Level name="Customer Region" column="cust_region" uniqueMembers="true"/> <Level name="Customer State" column="cust_state" uniqueMembers="true"/> <Level name="Customer" column="cust_name" uniqueMembers="true"> <Property name="Customer Number" column="cust_number"/> </Level> </Hierarchy> </Dimension>
  25. 25. Principales Atributos de Dimensiones Nodo XML Atributo o <Node> Comentario Dimension foreignKey La columna de la clave foránea en la tabla type “Standard” es el valor por defecto. “TimeDimension” debería ser usado para dimensiones de tiempo Hierarchy <Table> Usar el atributo Name (Nombre) para definir el nombre de la tabla dimensión primaryKey La columna de la clave primaria en la tabla dimensión hasAll “true” o “false”, si es true las medidas pueden ser sumarizadas para una jerarquía completa allMemberName Solamente válido si hasAll=“true”, e.g. “All Customers” (Todos Clientes) © 2010, Universidad Central de Venezuela. Sistemas de Información. 25 Level table Si la jerarquía define <Table> esto no es necesario, sino es requerido e identifica una tabla dimensión column El nombre de la columna de la clave para el nivel en la tabla dimensión nameColumn El nombre de ala columna visualizada en la tabla diemsnión ordinalColumn El nombre de la columna de ordenamiento en la tabla dimensión uniqueMembers “true” o “false”, si los miembros de este nivel son únicos para todos los miembros padres del nivel. (e.g. Mes no es únicos para todos los Años, pero Estado si lo sería para cada Región) Property Column El nombre de una columna en la tabla dimensión Todos los nodos tienen un atributo “nombre” Level (Nivel) y Property (Propiedad) también tienen tipo para el tipo de dato visualizado <Nodos> de atributos y contenido adicionales existen
  26. 26. Las medidas mapean a columnas en la tabla hecho y generalmente son definidas como nodos en una definición de cubo. <Measure name="Gross Revenue" column="gross_rev" aggregator="sum" datatype="Integer" formatString=“$#,##0"/> <Measure name="Gross Pay" column="gross_pay" aggregator="sum" datatype="Integer" formatString=“$#,##0"/> <Measure name="Gross Profit" aggregator="sum" datatype="Integer" formatString=“$#,##0“ <MeasureExpression> <SQL dialect=“generic”>gross_rev – gross_pay</SQL> </MeasureExpression> </Measure> Definición de Medidas © 2010, Universidad Central de Venezuela. Sistemas de Información. </Measure> Las medidas se mapean a una columna o usan una expresión SQL (debe ser válida para un agregado) Los valores para agregación son suma, contar, mínimo, máximo, promedio, contar distinto (sum, count, min, max, avg, distinct count) Los tipos de datos son entero, numérico y string (integer, numeric, string) Se puede encontrar información adicional acerca de los atributos en el sitio web de referencia de esquemas 26
  27. 27. En dimensiones de tiempo, los usuarios generalmente quieren visualizar el nombre del mes, pero lo tienen ordenado por su número. El siguiente XML permite hacer esto: Orden y Visualización de Miembros de Niveles de Dimensión © 2010, Universidad Central de Venezuela. Sistemas de Información. <Level name="Month" column="month_num" uniqueMembers="false" ordinalColumn="month_num" nameColumn=“date_month_name" levelType=“TimeMonths"/> • Esto también obliga a las consultas MDX a usar el nombre del mes cuando se hace referencia a los miembros. 27
  28. 28. Las dimensiones de tiempo basadas en año/mes/semana/día son codificadas de manera distinta en el esquema Mondrian Esto permite el uso de funciones de tiempo de MDX tales como: Dimensiones de Tiempo © 2010, Universidad Central de Venezuela. Sistemas de Información. WTD (semana a fecha) MTD (mes a fecha) QTD (trimestre a fecha) YTD (año a fecha) PeriodsToDate (períodos a fecha) LastPeriod (último período) ParallelPeriod (período paralelo) 28
  29. 29. Valor LevelType Significado Definiendo Dimensiones de Tiempo • El nodo <Dimension> de tiempo debe tener el siguiente valor de atributo: – type="TimeDimension". • El rol de un nivel en una dimensión de tiempo está indicado por el atributo levelType cuyos valores permisibles son: © 2010, Universidad Central de Venezuela. Sistemas de Información. TimeYears Nivel es un año TimeQuarters Nivel es un trimestre TimeMonths Nivel es un mes TimeDays Nivel representa días 29
  30. 30. Dimensión de Tiempo (Ejemplo) <Dimension name=“Time" type="TimeDimension“ foreignKey=“order_date”> <Hierarchy hasAll="true" allMemberName="All Periods" primaryKey="date_date"> <Table name=“timedim"/> <Level name="Year" column="year" uniqueMembers="true" levelType=“TimeYears" type="Numeric"/> <Level name="Quarter" column="quarter" uniqueMembers="false" levelType=“TimeQuarters" /> <Level name="Month" column="month" uniqueMembers="false" © 2010, Universidad Central de Venezuela. Sistemas de Información. 30 <Level name="Month" column="month" uniqueMembers="false" ordinalColumn="month" nameColumn=“date_month_name" levelType=“TimeMonths" type="Numeric"/> <Level name="Day" column="day_of_year" uniqueMembers="false" ordinalColumn="day_of_year" nameColumn="day_of_year" levelType=“TimeDays" type="Numeric"/> </Hierarchy> </Dimension>
  31. 31. Un ejemplo de dos jerarquías de tiempo, una agregando a semanas y la otra a meses <Dimension name="Time" foreignKey=“date_date"> <Hierarchy name=“Monthly” hasAll="false" primaryKey=" date_date"> <Table name="time_by_day"/> <Level name="Year" column=“date_year" type="Numeric" uniqueMembers="true"/> <Level name="Quarter" column=“date_quarter" uniqueMembers="false"/> <Level name="Month" column=“date_month" type="Numeric" uniqueMembers="false"/> Ejemplo de Jerarquías Múltiples © 2010, Universidad Central de Venezuela. Sistemas de Información. <Level name="Month" column=“date_month" type="Numeric" uniqueMembers="false"/> </Hierarchy> <Hierarchy name="Weekly" hasAll="false" primaryKey=“date_date"> <Table name="time_by_week"/> <Level name="Year" column=“date_year" type="Numeric" uniqueMembers="true"/> <Level name="Week" column=“date_week" uniqueMembers="false"/> <Level name="Day" column="day_of_week" type="String" uniqueMembers="false"/> </Hierarchy> </Dimension> El ejemplo no usa el tipo de dimensión Tiempo El ejemplo muestra como las jerarquías pueden venir de distintas tablas de dimensión 31
  32. 32. Este ejemplo muestra la unión de la dimensión Tipo de Almacenamiento con el cubo de Ventas usando la clave foránea sales_fact_1997.store_id, y al cubo Almacén usando la clave foránea almacén, warehouse.warehouse_store_id: <Dimension name="Store Type"> <Hierarchy hasAll="true" primaryKey="store_id"> <Table name="store"/> <Level name="Store Type" column="store_type" uniqueMembers="true"/> </Hierarchy> </Dimension> Dimensiones Compartidas (Conformadas) © 2010, Universidad Central de Venezuela. Sistemas de Información. </Dimension> <Cube name="Sales"> <Table name="sales_fact_1997"/> ... <DimensionUsage name="Store Type" source="Store Type" foreignKey="store_id"/> </Cube> <Cube name="Warehouse"> <Table name="warehouse"/> ... <DimensionUsage name="Store Type" source="Store Type" foreignKey="warehouse_store_id"/> </Cube> Nota: El nodo DimensionUsage permite las dimensiones conformadas entre cubos 32
  33. 33. Este ejemplo muestra el uso de la tabla Estado dos veces en un mismo hecho de movimiento, uno para una relación de Inicio y una para el Final. <Dimension name=“Start State"> <Hierarchy hasAll="true" primaryKey="state_id"> <Table name=“statedim"/> <Level name=“Start State" column=“state_code" uniqueMembers="true"/> </Hierarchy> </Dimension> Dimensiones Multiuso © 2010, Universidad Central de Venezuela. Sistemas de Información. </Dimension> <Dimension name=“End State"> <Hierarchy hasAll="true" primaryKey="state_id"> <Table name=“statedim"/> <Level name=“End State" column=“state_code" uniqueMembers="true"/> </Hierarchy> </Dimension> <Cube name=“Moves"> <Table name=“move_facts"/> ... <DimensionUsage name=“Start State" source="Start State " foreignKey=“start_state_id"/> <DimensionUsage name=“End State" source=“End State " foreignKey=“end_state_id"/> </Cube> 33
  34. 34. Una dimensión degenerada es una dimensión que es representada como una columna en la tabla de hechos : Dimensiones Degeneradas © 2010, Universidad Central de Venezuela. Sistemas de Información. 34 Supongamos que creamos una tabla dimensión para los valores en le columna payment_method (método pago): Esta tabla de dimensión no tiene mucha finalidad. Solo tiene 3 valores, no aporta información y agrega el costo de un join adicional.
  35. 35. Se declara una dimensión sin una tabla, y Mondrian asume que las columnas vienen de la tabla de hechos. <Cube name="Checkout"> <!-- The fact table is always necessary. --> <Table name="checkout"> <Dimension name="Payment Method"> Dimensiones Degeneradas (cont.) © 2010, Universidad Central de Venezuela. Sistemas de Información. <Dimension name="Payment Method"> <Hierarchy hasAll="true"> <!-- No table element here. Fact table is assumed. --> <Level name="Payment Method" column="payment_method" uniqueMembers="true" /> </Hierarchy> </Dimension> <!-- other dimensions and measures --> </Cube> 35 Note que debido a que no existe un join la clave foránea de la dimensión no es necesaria, y que la jerarquía no tiene nodo <Table> ni clave primaria.
  36. 36. El mapeo de tablas en el esquema le dice a Mondrian cómo leer los datos, pero Mondiran es lo suficientemente inteligente como para no leerlo literalmente. Aplica una cantidad de optimizaciones cuando genera consultas: Optimización de Join © 2010, Universidad Central de Venezuela. Sistemas de Información. Si una dimensión tiene una pequeña cantidad de miembros, Mondrian lo lee a un caché en su primer uso. Si una dimensión está en la tabla de hechos (o, para ser preciso, el nivel de la dimensión siendo accedida está en la tabla de hecho), Mondrian no hace join. Si dos dimensiones acceden la misma tabla a través del mismo join, Mondrian solo hace join una vez. 36
  37. 37. Conclusiones • Hemos realizado un estudio de ….. • Hemos hecho una discusión sobre…. • Se han desarrollado demostraciones de Conclusiones © 2010, Universidad Central de Venezuela. Sistemas de Información. 37

×