inteligencia de negocio parte v - modelo multidimensional - cubos

Sistemas de Información

UNIVERSIDAD CENTRAL DE VENEZUELAFACULTAD DE CIENCIAS

ESCUELA DE COMPUTACION

´

Tema 6: Inteligencia de Negocio. Modelado Multidimensional

Cubos

1Prof. Wilfredo Rangel

IntroducciónOrigen y DefiniciónSoluciones 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íticasModelaje MultidimensionalETLMetodología de desarrollo de soluciones analíticas

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


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

IntroducciónOrigen y definición¿Qué es OLAP?Características de las Soluciones

Analíticas


AnalíticasModelaje Multidimensional –

Esquema EstrellaCubos

4

Modelaje Multi -dimensional


Modelaje Multi -dimensionalCubos

Un modelo dimensional(lógico)

Cubos y cubos virtualesDimensiones privadas ycompartidasMedidas calculadas en el cubo y enlenguaje de consulta

OLAP Muestra Datos Relacionales “Dimensionalmente”


lenguaje de consultaJerarquías padre-hijo

… mapeadas a esquemaestrella/copo de nieve(físico)

Tabla de hechoTablas dimensionesUnidas por claves foráneas

6

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


• 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

Cubos y Modelo Estrella

• Cubo

EmployeeProduct

Geography

Sales Facts

Customer Time

Modelo Estrella


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 EstrellaTablas 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

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ísicoData

Archivo XML del Esquemade Mondrian


lo físico

MONDRIAN

OLAPQuery

Data Warehouse

SQLQueries

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 &


10

• Multi-plataforma (Windows & Unix/Linux)

• Arquitectura J2EE– Agrupación de Servidores– Tolerancia a fallas

• Fuentes de datos– JDBC– JNDI

Arquitectura OLAP Pentaho


11

Cálculos sumarizados por jerarquias

Año

Trim.

La data es sumarizada por cada nivel de la jerarquía


12

Trim.

Mes

Métricas de Ventas por la Dimensión de Tiempo

220

90 130

1st Half 2nd Half

2008

Datos de venta sumarizados por

nivel


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

El modelo de datos relacional esta impulsado por la necesidad de Unir(Join) varias tablas. La complejidad y numero de estas joins dependende la complejidad del esquema.El modelo estrella simplifica el modelo de datos a las herramientas deconsulta relacional. Sin embargo, el usuario aun debe decidir cualestablas 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


En contraste, el cubo multidimensional aísla al usuario del esquemasubyacente porque la herramienta de consulta maneja el proceso deuniones por el usuario.El usuario puede concentrarse en el análisis de la data sin preocuparsede la estructura que lo soporta

14

Las métricas son números que “miden” tu negocioLas métricas son como arreglos y son automáticamenteasociadas a la columna de la tabla de hecho física y susdimensiones relacionadas.La transformación de la columna en la tabla de hecho amétrica aísla al usuario de la complejidad del esquema

Métricas


métrica aísla al usuario de la complejidad del esquemasubyacente y de la necesidad de entender como lasdiferentes partes del esquema se relacionan.Dentro de un cubo multi-deminsional , esextremadamente sencillo crear nuevas métricas tales comoganancia en ventas y costos de ventas simplementemultiplicando cantidadordenanda * preciounitario.

15

Esquema Mondrian


16

Conceptos OLAP: Cubos y Jerarquias


17

Bases de datos relacionales organizan datos en tablasplanas de dos dimensiones.

Filas y columnas con intersecciones únicas entre datos

Las BD Multidimensionales dependen de estructurasllamadas cubos .Un cubo es una colección de medidas y dimensiones

Conceptos OLAP: Cubos y Jerarquías


Un cubo es una colección de medidas y dimensionesPueden haber n dimensionesLas medidas son evaluadas en la intersección de todas las “n” dimensionesLos cubos pueden ser esparcidos (intersecciones mínimas) o densos (muchasintersecciones)

Los cubos permiten la agregación a través de jerarquíasdimensionales

Permite la navegación hacia arriba/abajo rápidaMás flexible que una construcción basada en tablas

18

Conceptos OLAP: Dimensiones y Medidas

Los cubos pueden tener másde dos dimensiones .

El cubo del diagrama tienecuatro dimensionse: Ruta, Origen, Tiempo, y Medidas.


19

Las medidas representanlos datos organizados porotras dimensiones incluidasen el cubo.

El cubo del diagrama tienedos medidas, Paquetes(Packages) y Último(Last).

Dimensión

Medida

Conceptos OLAP: Levels

• Cada dimensión contiene

niveles .

• Por ejemplo, la dimensión

Origen (Source) en el

diagrama tiene dos niveles:

Hemisphere

Country


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

Conceptos OLAP: Miembros

• Cada nivel organiza loselementos básicos deuna dimensión enmiembros .

• Cada miembrorepresenta


21

representa– un elemento de dato único

dentro de una dimensión– una rebanada del cubo

• En el diagrama, el nivelHemisferio Este(Eastern Hemisphere)tiene cuatro miembros:Africa, Asia, Australia, yEuropa.

Nivel

Miembros

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>


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

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 crearun Esquema Mondrian– Columna de Clave Foránea en Tabla de Hecho


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 instanciasdentro 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

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


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>

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)


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

Las medidas mapean a columnas en la tabla hecho y generalmente sondefinidas 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


</Measure>

Las medidas se mapean a una columna o usan una expresión SQL (debe servá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 webde referencia de esquemas

26

En dimensiones de tiempo, los usuariosgeneralmente quieren visualizar el nombre delmes, 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


<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 elnombre del mes cuando se hace referencia a losmiembros.

27

Las dimensiones de tiempo basadas enaño/mes/semana/día son codificadas de manera distinta enel esquema MondrianEsto permite el uso de funciones de tiempo de MDX talescomo:

Dimensiones de Tiempo


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

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 atributolevelType cuyos valores permisibles son:


TimeYears Nivel es un año

TimeQuarters Nivel es un trimestre

TimeMonths Nivel es un mes

TimeDays Nivel representa días

29

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"


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>

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


<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"/>


El ejemplo no usa el tipo de dimensión Tiempo

El ejemplo muestra como las jerarquías pueden venir de distintas tablas de

dimensión31

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"/>


Dimensiones Compartidas (Conformadas)


</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 cubos32

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"/>


Dimensiones Multiuso


</Dimension>

<Dimension name=“End State"><Hierarchy hasAll="true" primaryKey="state_id"><Table name=“statedim"/><Level name=“End State" column=“state_code" uniqueMembers="true"/>


<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

Una dimensión degenerada es una dimensión que esrepresentada como una columna en la tabla de hechos :

Dimensiones Degeneradas


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.

Se declara una dimensión sin una tabla, y Mondrian asume que las columnas vienen de la tabla de hechos.

<Cube name="Checkout"><Table name="checkout"><Dimension name="Payment Method">

Dimensiones Degeneradas (cont.)


<Dimension name="Payment Method"><Hierarchy hasAll="true"><Level name="Payment Method" column="payment_method" uniqueMembers="true" />


</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.

El mapeo de tablas en el esquema le dice a Mondrian cómoleer los datos, pero Mondiran es lo suficientementeinteligente como para no leerlo literalmente.Aplica una cantidad de optimizaciones cuando generaconsultas:

Optimización de Join


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 j oin ,

Mondrian solo hace join una vez.

36

Conclusiones

• Hemos realizado un estudio de …..

• Hemos hecho una discusión sobre….

• Se han desarrollado demostraciones de

Conclusiones


37

inteligencia de negocio parte v - modelo multidimensional - cubos

Documents