Inteligencia de negocio parte v - modelo multidimensional - cubos

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

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

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ón
Origen y definición
¿Qué es OLAP?
Características de las Soluciones
Analíticas
Analíticas
Modelaje Multidimensional –
Esquema Estrella
Cubos
4

Modelaje Multi-dimensional
Modelaje Multi-dimensional
Cubos

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

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
Employee
Product
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 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

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
lo físico
MONDRIAN
OLAP
Query
Data
Warehouse
SQL
Queries

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

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

Esquema Mondrian
16

Conceptos OLAP: Cubos y Jerarquias
17

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

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

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 los
elementos básicos de
una dimensión en
miembros.
• Cada miembro
representa
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

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 crear
un 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 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

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

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

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

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

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

Una dimensión degenerada es una dimensión que es
representada 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" />
</Hierarchy>
</Dimension>

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Inteligencia de negocio parte v - modelo multidimensional - cubos

Ähnlich wie Inteligencia de negocio parte v - modelo multidimensional - cubos (20)

Inteligencia de negocio parte v - modelo multidimensional - cubos