downloading - Proyectos SIU

INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Bibliografía:
 HowTo Pentaho 3.5 & Cubo Mondrian en GNU/Linux – por Alvarez Sebastián Matias – 2009
 Pasos para crear Cubos con Mondrian Schema WorkBench – por Ing. Dennos Alba Infante para la
comunidad Open Business Intelligence
 Mondrian 3.0.4 - Technical Guide - Developing OLAP solutions with Mondrian – 2009
 Mondrian Schema Workbench
 Pentaho Solutions - Business Intelligence and Data -Warehousing with Pentaho and MySQL – de
Roland Bouman Jos van Dongen
WEB:



http://mondrian.pentaho.org/documentation/schema.php
http://assets.en.oreilly.com/1/event/2/Creating%20Interactive%20OLAP%20Applications%20with
%20MySQL%20Enterprise%20and%20Mondrian%20Presentation.ppt#351,1,Diapositiva 1
http://programacionbizarra.blogspot.com/2009/04/olap.html - Herramientas Libres para OLAP:
Mondrian y JPivot Java
Módulo 2:
 Introducción a pentaho Analysis
o Mondrian
o WorkBench
o Jpivot – Análisis Ad-hoc
 Desarrollo de un cubo OLAP
“La comunidad de código abierto se nutre de la participación y la cooperación. Hay
varios canales de comunicación disponibles donde las personas pueden ayudar, pero no
están obligados a hacerlo. Usted es responsable de su propio éxito, lo que requerirá
tiempo, esfuerzo y una pequeña cantidad de capacidad técnica. Si prefiere tener una
relación con un proveedor conocido que responderá a preguntas por teléfono, le ayudará
durante su evaluación y lo apoyará en la producción, por favor visite www.pentaho.com.”
(Pentaho Coporation)
((e
esstta
ad
do
occu
um
me
en
ntta
acciió
ón
nn
no
oe
ess d
de
ep
prro
od
du
ucccciió
ón
np
prro
op
piia
a ssiin
no
o rre
ecco
op
piilla
acciió
ón
nd
de
e lla
a
iin
nffo
orrm
ma
acciió
ón
nd
diissp
po
on
niib
blle
e))
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
HERRAMIENTAS
Bajo la integración de otros proyectos OpenSource que brindan funcionalidad en áreas de BI, la comunidad
PENTAHO trabaja en formalizar varias herramientas y formar el SUITE BI.
PENTAHO ANALYSIS SERVICE
PAS consiste de los siguientes 4 componentes:
 JPIVOT analisys en el front end: interface de usuario basada en Java.
 Mondrian ROLAP engine: motor OLAP, recibe queries MDX desde una herramienta en el front-end
como JPIVOT, y responde enviando un result-set multidimensional.
 Shema Workbench: es una interface visual para diseñar y testear schemas de Mondrian. Mondrian
usa Schemas para interpretar MDX y trasladar a queries SQL que pueda ser interpretado por un
RDBMS.
 Agrégate Designer: una herramienta visual para analizar la performance y generar tablas
agregadas.
Componentes OLAP en PENTAHO
(extraído de Pentaho Solutions - Business Intelligence and Data -Warehousing with Pentaho and MySQL)
Qué es OLAP?
(extraído de HEFESTO del Ing. Bernabeu Ricardo Dario)
OLAP suele ser el primer paso en el campo de la inteligencia de negocios en toda organización.
El procesamiento analítico en línea OLAP (On Line Analytic Processing), es la componente más poderosa del
Data Warehousing, ya que es el motor de consultas especializado del depósito de datos.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Las herramientas OLAP, son una tecnología de software para análisis en línea, administración y ejecución de
consultas, que permiten inferir información del comportamiento del negocio.
Su principal objetivo es el de brindar rápidas respuestas a complejas preguntas, para interpretar la situación
del negocio y tomar decisiones. Cabe destacar que lo que es realmente interesante en OLAP, no es la
ejecución de simples consultas tradicionales, sino la posibilidad de utilizar operadores tales como drill-up,
drill-down, etc, para explotar profundamente la información.
Además, a través de este tipo de herramientas, se puede analizar el negocio desde diferentes escenarios
históricos, y proyectar como se ha venido comportando y evolucionando en un ambiente multidimensional, o
sea, mediante la combinación de diferentes perspectivas, temas de interés o dimensiones. Esto permite
deducir tendencias, por medio del descubrimiento de relaciones entre las perspectivas que a simple vista no
se podrían encontrar sencillamente.
Las herramientas OLAP requieren que los datos estén organizados dentro del depósito en forma
multidimensional, por lo cual es que utilizan los cubos multidimensionales.
Además de las características ya descritas, se pueden enumerar las siguientes:
 Permite recolectar y organizar la información analítica necesaria para los usuarios y disponer de ella
en diversos formatos, tales como tablas, gráficos, reportes, tableros de control, etc.
 Soporta análisis complejos de grandes volúmenes de datos.
 Complementa las actividades de otras herramientas que requieran procesamiento analítico en línea.
 Presenta al usuario una visión multidimensional de los datos (matricial) para cada tema de interés del
negocio.
 Es transparente al tipo de tecnología que soporta el DW, ya sea ROLAP, MOLAP u HOLAP.
 No tiene limitaciones con respecto al número máximo de dimensiones permitidas.
 Permite a los usuarios, analizar la información basándose en más criterios que un análisis de forma
tradicional.
 Al contar con muestras grandes, se pueden explorar mejor los datos en busca de respuestas.
 Permiten realizar agregaciones y combinaciones de los datos de maneras complejas y específicas, con
el fin de realizar análisis más estratégicos.
Reporte de análisis OLAP en JPIVOT:
Bases de Datos OLAP
(extraído de “Herramientas libres para OLAP” de Héctor Francisco Hernández)
Aunque existen muchas herramientas de generación de informes que operan sobre las bases de datos de los
sistemas transaccionales, suelen ser lentas.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Los diseños de estas bases de datos están pensados para realizar altas, bajas y modificaciones de la forma
más óptima, teniendo un mínimo grado de redundancia de información posible. Esto significa que se tiende a
la normalización.
Sin embargo la normalización puede hacer lentas las consultas complejas, ya que al estar la información
distribuida en muchas tablas es necesario calcular productos cartesianos complejos (en sql "inner join", "outer
join", el operador coma) y en gran cantidad. Este tipo de operaciones es de los más costosos para el motor
de base de datos.
Cuando las consultas implican cruzar varias tablas de decenas o cientos de miles de registros, el sistema no
responde satisfactoriamente. Además de tardar varios minutos en presentar la información, se consumen
recursos haciendo más lento y degradando el servicio prestado por el sistema a los otros usuarios en línea.
La solución adoptada consiste en extraer, tranformar y cargar (ETL: Extract, Transform and Load) los datos a
una base exclusiva para OLAP. Si bien las bases de datos relacionales, u orientadas a objetos en los sistemas
más recientes, son las utilizadas comunmente en las aplicaciones OLTP, en el mundo OLAP las bases de datos
impuestas son las multidimensionales.
Conceptualmente, una base de datos multidimensional utiliza la idea de "cubos". Un cubo posee N
dimensiones y en él están registrados "hechos" de un determinado tipo. Los hechos podrían ser, por ejemplo,
desde las ventas realizadas por una empresa (según estudios la utilización de OLAP para el analisis de ventas
es la aplicación más popular) hasta los defectos que reportan los usuarios de un sistema informático, según
cuál fuese la finalidad de la aplicación.
Cada "hecho" tiene asociado un elemento de cada dimensión definida para el cubo. Por ejemplo, si el cubo
registra ventas, cada venta tiene asociado un lugar geográfico (dimensión geográfica), el día en el que ocurrió
(dimensión temporal), el producto que se vendió (dimensión de tipo), etc.
Además el "hecho" tiene valores asociados, por ejemplo el importe por el cual se realizó la venta o la cantidad
de unidades vendidas.
Poseyendo estos tres elementos, a saber, un tipo de hecho, un conjunto de dimensiones y un conjunto de
valores, queda conformado un cubo capaz de responder preguntas como cuántas ventas de determinado
artículo se realizaron en el mes de febrero, o cuál es el producto más vendido del trimestre pasado en la
ciudad de Córdoba.
Para consultar estos datos al cubo se necesita una herramienta fundamental. Así como existen lenguajes de
consultas en los otros paradigmas de bases de datos (SQL), para las bases multidimensionales el lenguaje es
MDX: MultiDimensional eXpressions.
Aunque no es un estándar, sino más bien una especificación propietaria de Microsoft, ha sido adoptada por
una amplia gama de compañías en diversos productos, entre los que se incluyen Applix, Microstrategy, SAS,
SAP, Whitelight, NCR, Panorama Software, Proclarity, AppSource, Cognos, Business Objects, Brio Technology,
Crystal Reports, Microsoft Excel, Microsoft Reporting Services, etc.
Un ejemplo de consulta MDX es la siguiente:
SELECT
{ [Measures].[Importe] } ON COLUMNS,
{ [Tiempo].[2002], [Tiempo].[2003] } ON ROWS
FROM Ventas
WHERE ( [Sucursal].[Zona Oeste].[Tablada] )
Esta consulta obtiene como resultado un reporte OLAP, con los totales de las ventas realizadas por una
sucursal llamada "Tablada" de una cadena de mercados mostrando los años 2002 y 2003 en el eje vertical.
MONDRIAN
La última versión de Mondrian y su documentación se encuentra en http://mondrian.pentaho.org/.
De una manera similar a un ORM (por ejemplo Hibernate en Java), que permite emular una base de datos
orientada a objetos a partir de una relacional, Mondrian nos permite emular una base multidimensional.
Permitiéndonos así realizar consultas en lenguaje MDX, pensando en términos de cubos, hechos, dimensiones
y valores en lugar de tablas, registros y campos.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Mondrian está compuesto por un conjunto de archivos "jar", que proveen una API inspirada en JDBC pero
diseñada para trabajar con una base multidimensional. El sistema necesita que escribamos en un archivo
"xml" cómo se corresponden los elementos de esta base con la base relacional.
La base relacional debe ser diseñada cuidadosamente de modo que sobre ella se pueda hacer el mapeo. Las
estructuras comunmente usadas son tres:

Una única tabla para el cubo donde existe un registro por cada hecho (por ejemplo, un registro por cada
venta). El registro tendrá un código único, un campo o más por cada dimensión y un campo por cada
valor del hecho (un campo con el importe de la venta, otro con la cantidad de artículos vendidos, etc.).

Una estructura de estrella. Con una tabla central de hechos donde está el código único del mismo y los
valores correspondientes, y varias tablas periféricas, una por cada dimensión. Los registros de la tabla
central se relacionan con los registros de las tablas periféricas de un modo "muchos a uno", por lo tanto
la tabla central posee además una clave foránea por dimensión.

Una estructura de copo de nieve. No muy alejada de la estrella, pero busca quitar relaciones de la
tabla central para ahorrar espacio.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
¿Cómo funciona mondrian?
(extraído de “Análisis del estod de Mondrian” de Javier Giménez para Stratebi)
Mondrian es un motor ROLAP con caché. ROLAP significa que en mondrian no residen datos (salvo en la
caché) sino que estos residen en una Sistema de Gestion de Bases de Datos externo.
Es en esta base de datos en la que residen las tablas que conforman la información multidimensional con la
que mondrian trabaja (los modelos en estrella de nuestros data marts por ejemplo). MOLAP es el nombre que
reciben los motores olap en los que los datos residen en una estructura dimensonal.
(extraído de HEFESTO)
Mondrian se encarga de recibir consultas dimensionales (lenguaje MDX) y devolver los datos de un cubo, sólo
que este cubo no es algo físico sino un conjunto de metadatos que definen como se han de “mapear” estas
consultas expresadas utilizando conceptos dimensionales a sentencias SQL ya tratando con conceptos
relacionales que obtengan de la base de datos la información necesaria para satisfacer la consulta
dimensional.
Algunas de las ventajas de este modelo son:
 El no tener que generar cubos estáticos ahorrando lo que cuesta generarlos y la memoria que
ocupan.
 La posibilidad de utilizar siempre los datos residentes en la base de datos, de forma que se
trabaja con datos actualizados. Muy útil en entorno de BI Operacional.
 Pese a que tradicionalmente los sistemas MOLAP tienen una cierta ventaja de rendimiento, la
aproximación híbrida de Mondrian, el uso de caché y de tablas agregadas, hace que se puedan
obtener muy buenos rendimientos con él, sin perder las ventajas del modelo ROLAP clásico.
Flujo de ejecución de mondrian
Veamos para que quede más claro un ejemplo de un flujo de ejecución de una consulta MDX contra
mondrian:
1. Un cliente (por ejemplo la interfaz web JPivot) lanza una consulta MDX contra mondrian, solicitando
una serie de datos y hablando de concepto dimensionales (ej. “Quiero el gasto del ultimo año para
todas las provincias”).
2. Mondrian recibe la sentencia MDX (referida a un cubo en concreto) busca en sus metadatos (esquema
de mondrian, un fichero xml que define cubos) que conceptos relacionales (tablas, columnas) se
asocian con estos conceptos dimensionales. Busca si ya tiene esos datos en la caché (los obtiene muy
rápidamente), si los tiene los devuelve a la interfaz, sino ejecuta el siguiente paso.
3. Genera las sentencias SQL necesarias (mirando en su esquema con la definición del cubo) para
obtener esos datos. (ej. Una consulta SQL que obtiene los nombres de todas las provincias, otra que
obtiene los gastos asociados a cada provincia ya agregados, etc...)
4. La base de datos ejecuta las sentencias SQL (paso que más tiempo consume del proceso) y devuelve
los datos a mondrian.
5. Mondrian almacena los datos recibidos en la cache (para agilizar posteriores consultas).
6. Mondrian devuelve el resultado a la interfaz (al cliente que lo solicitó, por ejemplo JPivot).
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Tablas Agregadas
En el caso de que tengamos tablas agregadas en nuestro modelo en estrella (versión de las tablas de hechos
reducidas con el fin de acelerar las queries), mondrian es capaz de aprovecharlas decidiendo, a la hora de
crear las SQL que van a obtener los datos, a que tabla a de direccionar las queries para obtener la
información, tratando siempre que sea posible de utilizar las tablas agregadas para agilizar el proceso.
Veamos un ejemplo:
Disponemos de dos tablas de hechos, una básica con un millon de registros e información a nivel de día y una
versión agregada con información a nivel de mes y 20.000 registros (HECHOS y HECHOS_AGG).
Si el usuario lanza una consulta MDX que solicita la información de este cubo mondrian hará lo siguiente:
1- Verá si tiene la información en la caché (opción más rápida)
2- Ver si para el nivel jerarquico para el que piden los datos puede obtenerlos con una SQL contra la
tabla HECHOS_AGG, si puede lo hace. (ej. La consulta pedía agregados para los 4 primeros meses).
3- Si la sentencia MDX pedía información a nivel de día, mondrian obtendrá lo que pueda de la caché, lo
que pueda de la tabla agregada y para los niveles de detalle irá a la tabla de HECHOS principal.
Para informar a mondrian de que tablas agregadas hay disponible hay dos opciones:
1- Definirlas explicítamente (todas las que haya) en los metadatos (Esquema de mondrian con las
definiciones de cubos).
2- Utilizar una nomenclatura para los nombres de las tablas de forma que mondrian (con una reglas
gramaticales que tiene definidas y que son customizables) pueda saber automáticamente que tabla
agregada puede utilizar en cada caso.
Además se puede configurar una política de uso de las agregadas para que, en caso de que mondrian
disponga de varias opciones a la hora de satisfacer una demanda de datos, escoja la tabla agregada en
función de unos criterios (menos número de registros, menos tamaño en Bytes, etc...)
Caché
Como hemos visto, mondrian implementa una caché. El objeto de esta memoria intermedia es almacenar
información del cubo de forma que se pueda responder a queries (o partes de las queries) más rápidamente
no siendo necesario lanzar consultas SQL contra la base de datos.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Mondrian, permite desactivar la caché (para entornos en los que el rendimiento no sea crítico pero si lo sea
disponer siempre del dato residente en la base de datos) y además (a partir de la versión 2.3) gestionarla de
un modo sofisticado, veamos.
Mondrian es capaz de limpiar areas determinadas de la caché. La utilidad de esto es aprovechar a la vez las
mejoras de rendimiento de la caché y la posibilidad de obligar a mondrian a volver a cargar una cierta área
de la caché con datos frescos (en caso de que un conjunto determinado de información haya cambiado).
¿Cómo diseñar un cubo en Mondrian ?
(extraído del manual de referencia Técnica de Mondrian)
Qué es un Schema?
Un esquema define una base de datos multi-dimensional. Contiene un modelo lógico, que consiste en cubos,
jerarquías, y los miembros, y una asignación de este modelo a un modelo físico.
El modelo lógico se compone de los constructores utilizados para escribir consultas en lenguaje MDX: cubos,
dimensiones, jerarquías, niveles, y los miembros.
El modelo físico es la fuente de los datos que se presenta a través del modelo lógico. Es normalmente un
esquema en estrella, que es un conjunto de tablas en una base de datos relacional.
Archivos de Schema
Los Schemas de Mondrian están representados en un archivo XML. Un esquema de ejemplo, que contiene
casi todos los las construcciones que aquí analizamos, se suministra como demo / FoodMart.xml en el
Mondrian
de distribución. El conjunto de datos para rellenar este esquema también se encuentra en la distribución.
En la actualidad, podemos crear un esquema es editar un archivo de esquema XML con una aplicación de
escritorio desarrollada en java, Schema WorkBench. La sintaxis XML no es demasiado complicada, así que
esto no es tan difícil usar si se desea un simple editor de texto para obtener un Schema
NOTA: El orden de los elementos XML es importante. Por ejemplo, <UserDefinedFunction> elemento tiene
que ocurrir dentro del elemento <Schema> después de todas las colecciones de <Cube>, <VirtualCube>,
<NamedSet> Y <Role> elementos. Si lo inserta antes de la primera <Cube> elemento, el resto del esquema
será ignorado.
Modelo Lógico
Los componentes más importantes de un esquema son cubos, medidas y dimensiones:
 Un cubo es un conjunto de dimensiones y medidas en un área determinada.
 Una medida es una cantidad que usted está interesado en lasu medición, por ejemplo, las ventas
de unidades de un producto, o precio de coste de los artículos del inventario.
 Una dimensión es un atributo o conjunto de atributos, con la que se puede dividir las medidas en
sub-categorías. Por ejemplo, usted podría desear para romper las ventas de productos por su
color,
el sexo del cliente, y el almacén en el que se vende el producto. Color, sexo, y las tiendas son
todas las dimensiones.
Dimensiones, Jerárquías y Niveles





Un miembro es un punto dentro de una dimensión, determinado por un conjunto específico de
valores de atributos. La jerarquía de género tiene dos miembros ‘M’ y ‘F’. 'San Francisco', 'California'
y 'EE.UU.' son todos los miembros de la jerarquía de la tienda.
Una jerarquía es unconjunto de miembros organizados en una estructura para el análisis práctico.
Por
ejemplo, la jerarquía tienda consiste en el nombre de la tienda, ciudad, estado y nación. La jerarquía
le permite formar subtotales: el sub-total de un estado es la suma de los subtotales de todas las
ciudades de ese estado, cada una de ellas es la suma de los subtotales de las tiendas de esa ciudad.
Un nivel es un conjunto de miembros que tienen la misma distancia a la raíz de la jerarquía.
Una dimensión es unacolección de las jerarquías que se discriminan sobre el mismo atributo en la
misma tabla de hechos (por ejemplo, el día en que se produjo una venta).
Por razones de uniformidad, las medidas son tratados como miembros de una dimensión especial,
llamado ‘Measures’.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Un ejemplo:
1. Para obtener el XML de diseño lógico del cubo (hechos, dimensiones, medidas) usamos:
SCHEMA WORKBENCH
a.
b.
c.
Descomprimir el zip (psw-ce-3.1.6.13364.zip) en el directorio pentaho/design-tools/schemaworkbench
En el directorio pentaho/design-tools/schema-workbench/docs encontraremos documentación de
referencia:
i. mondrian_technical_guide.pdf
ii. schema_workbench.pdf
Configurar la conexión con el datasource:
i. Hay que configurar la conección a la BD, por lo que primero hay que asegurarse de tener
el jdbc correspondiente, en este ejemplo para PostgreSQL.
ii. Copiamos el jdbc de la conosla administrativa, con el que creamos el datasources,
administration-console/jdbc/postgresql-8.4-701.jdbc3.jar al directorio pentaho/designtools/schema-workbench/drivers
iii. Ejecutamos Schema Workbench:
pentaho/design-tools/schema-workbench/workbench.bat
Testeamos la conexión y si está todo ok, Aceptamos.
Las operaciones básicas a realizar son:
 Crear un schema
 Crear cubos dentro del schema
o Elegir una tabla de Hechos
o Crear dimensiones privadas del cubo
o Agregar medidas
 Crear dimensiones compartidas en el schema
o Editar jerarquías por default y elegir una tabla de dimensión
o Definir niveles de la jerarquía
o Opcionalmente, agregar más dimensiones
 Asociar dimensiones con cubos
d.
Crear un Schema:
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
i. Llamaremos al schema “guarani” y lo guardaremos en un archivo xml con ese nombre.
e.
Crear un Cubo dentro del schema:
Un cubo puede tener los siguientes atributos:
 Name: nombre del cubo usado en los queries MDX para reverenciarse al cubo. Debe ser
único en el esquema.
 Caption: especifica un nombre a mostrar, usado por las interfases de usuario.
 Cache: controla si los datos traídos de la tabla de hechos permanecerán en cache.
 Enabled: controla si Mondrian cargará o ignorará el cubo.
i. Eligiendo una tabla de hechos
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Los atributos de la tabla son:
 Schema: el schema de la base de datos que contiene la tabla. Cuando no es especificado,
toma el schema por default.
 Name: nombre de la tabla de hechos.
 Alias: un alias para la tabla cuando se genere la sentencia SQL.
ii. Añadir medidas
El orden en que se creen las medidas es importante, dado que implícitamente la primera
medida es la considerada como medida por default. De todas formas la medida por default
puede ser modificada con una propiedad del cubo:
<Cube defaultMeasure=”ni”……..>
…..
<Cube>
Los atributos de las medidas son:
 Name: es e l identificador que se usará en los queries MDX para refereirse a la
mdedia. Debe ser único en el cubo.
 Aggregator: el nombre de la función de agregación que se aplica sobre la medida.
 Column: el nombre de una columna de la tabla de hechos.
 formatStr ing: formato en el que se muestra la medida.
 Visible: indica si la medida se muestra en la interface de usuario.
 datatype: tipo de dato que queremos que retorne el MDX
 formatter: formato personalizado. Debe implementarse en la interface java
mondrian.olap.CellFormatter.
 caption: nombre a ser mostrado en la interface de usuario
iii. Añadir Dimensiones
o Dimensiones propias del cubo: son dimensiones “privadas”, porque son sólo
conocidad dentro del cubo en que se definen y no pueden ser usadas fuera de él.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Los atributos para las dimensiones son:
 Name: es el nombre con el cual será referenciada la dimensión en el
MDX. Debe ser único dentro del cubo.
 ForeignKey: es el nombre de una columna de la tabla de hechos del
cubo, que es la referencia a la primaryKey de la tabla de dimensión.
 Type: Si la dimensión es el tiempo o una fecha, debe usarse
TimeDimension. Esto permite usar funciones relacionadas con estos
tipos de datos en el MDX. Para cualquier otro caso usar
StandarDimension.
 usagePrefix: se aplica sólo para dimensiones privadas, para evitar
nombres duplicados.
 caption: es el nombre a mostrar en el front-end (la interface de
usuario)
o
Dimensiones del schema: son dimensiones “compartidas” y pueden ser
asociadas con múltiples cubos. Se recomienda el uso de dimensiones compartidas
sobre las privadas.
iv. Añadir Jerarquías
o Cuando se crea una dimensión, también se crea una nueva jerarquía al que debe
asociarse una tabla de dimensión.
o Las cruces rojas en cualquier objeto, significa que hay un error. El detalle del error
aparece en el panel derecho, en la parte inferior al seleccionar el objeto con el
error.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Los atributos de las jerarquías son:
 Name: es el nombre usado en el MDX para referirse a la jerarquía. Debe ser único
dentro de la dimensión. Si no se pone un nombre, asumirá en de la dimensión y
esta será la jerarquía por default.
 Caption: el nombre que será usado en la interface de usuario.
 hasAll: indica si la jerarquía tiene un nivel “All” con un miembro “All”,
generalmente al tope de la jerarquía es agregado este nivel que incluye todos los
miembros.
 allMemberName: si el hasAll esta habilitado, esta propiedad especifica el
identificador que será usado por el miembro “All”.Cuando no se escribe, este será
“All <nombre de la jerarquía>”
 allMemberCaption: Si hasAll esta habilitado, esta propiedad puede ser usada para
especificar cómo se mostrará el miembro “All” en la interface de usuario.
 allLevelName: es el nombre usado para referenciar al nivel “All” en el MDX.

def
aultMember: nombre del miembro por default. Si no es especificado, el miembro
“All”será usado como miembro por default, si la jerarquía tiene un miembro “All”.
Si el miembro “All”no está especificado en la jerarquía y hasAll está deshabilitado,
el primer miembro del primer nivel en la jeraquía se usará como miembro por
default.
 memberReaderClass: nombre de la clase que lee los miembros, si es que está
personalizada. Debe implementar la interface mondrian.rolap.MemberReader.
 primaryKeyTable: puede ser usada para especificar el nombre de la tabla a la cuál
pertenecen los miembros de la jerarquía. Si no es especificada los miembros son
consultados de la tabla de la jerarquía. Esta puede quedar en blanco si se está
implementando un schema estrella. Es requerida cuando es esquema es “copo de
nieve”.
 primaryKey: debe usarse para especificar el nombre de la columna que es primary
key de la tabla de dimensión en la jerarquía. Esta es la columna de la tabla de
dimensión que es referenciada por las filas de la tabla de hechos.
v.
o
Añadir Niveles a la Jerarquía:
Una vez creada la jerarquía, se deben definir niveles.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Las propiedades de un nivel son:
 Name: nombre que es usado para referenciar el nivel en el MDX.
 Table: nombre de la tabla que contiene la columna dónde el dato de la dimensión es
almacenado para el nivel. Esta es la situación normal en un esquema “estrella”. Necesita
especificar una tabla en particular cuando el esquema es “copo de nieve”.
 Column: el nombre de la columna que representa el miembro que identifica el nivel.
Este debe corresponderse con la tabla de nivel.
 Namecolum: nombre de la columna que contiene el nombre del nivel. Cuando no se
especifica, es usado el valor de la propiedad name. Normalmente se deja en blanco.
 Parentcolumn: se aplica sólo a un tipo especial de jerarquía padre-hijo. Normalmente
estará en blanco, pero si se cuenta con este tipo de jerarquía “parent-child”, se usa esta
propiedad para especificar que columna hace referencia al miembro padre.
 Nullparentvalue: cuando nos encontramos con una relación padre-hijo, podemos usar
este atributo cuales valores indican que miembro padre no existe. Quedará en blanco si
no es una jerarquía padre hijo.
 ordinalColumn: esta propiedad sirve para indicar que columnas definen el orden de los
miembros. Debería ser especificada si el orden natural de los miembros no se ajusta con
el orden deseado, sino se deja en blanco. A veces puede especificarse esta propiedad
con una columna cuyo tipo de dato es más adecuado para ordenar que la columna que
provee los valores de los miembros.
 type: el tipo de dato de los valores de los miembros
 uniqueMembers: indica si todos los miembros en el nivel tiene valores únicos. Esta es
siempre “verdadera”para el primer nivel (sin contar el nivel “All”) para cualquier
jerarquía. Si sabe que la propiedad debe ser “verdadera” para cualquiera de los
siguientes niveles, debe especificarlo, de esta forma, Mondrian generará más
eficientemente los quieres SQL. No lo haga si no está 100% seguro de que los valores
son únicos, porque puede causar resultados incorrectos.
 leveltype: si está en blanco se asumirá que es un nivel “regular”, que es correcto para la
mayoría de las dimensiones. En las dimensiones del tipo TimeDimension se debe
especificar un tipo de nivel específico: TimeYears, TimeQuarters, TimeMonths,
TimeWeeks, y TimeDays, es este caso es necesario para poder hacer uso de las
funciones date/time.
 Hidememberif: determina si un miembro estará oculto. Normalmente estará en blanco,
lo que es equivalente a setear el valor “Never”. En este caso el miembro siempre se
muestra.
 approxrowcount: número estimado de miembros en este nivel. Una buena estimación
mejorará la performance.
 caption: nombre del nivel a ser mostrado en la interface con el usuario.
 captioncolumn: especifica que columna de los niveles en la tabla de dimensión se usará
para presentar los miembros al usuario final. Cuando no es especificada, se usa el
identificador del miembro (propiedad column)
 formatter: formato personalizado.
vi. Uso de las Dimensiones Compartidas en el Cubo:
o La asociación entre el Cubo y la dimensión compartida definida en el Schema, se
hace a través de las llamadas dimension usage.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Las propiedades son:
 Name: nombre que es usado para referenciar la dimensión en el MDX. Este nombre tiene
que ser igual al de la dimensión compartida.
 Foreignkey: el nombre de la columna en la tabla de hechos que hace referencia a la
primary key en la tabla de dimensión.
 Source: es el nombre de la dimensión compartida
 Level: se puede especificar un nombre de nivel de la dimensión compartida que se unirá a
la tabla de hechos en el cubo. En un esquema “estrella’, estará en blanco.
 Caption: nombre a mostrar en la interface de usuario.
vii. Uso de las Miembros Calculados:
XML del Schema:
<Schema name="guarani" measuresCaption="totales de guarani para araucano">
<Cube name="guarani-araucano" cache="true" enabled="true">
<Table name="ft_alumnos_arau" schema="guarani">
</Table>
<Dimension type="StandardDimension" foreignKey="idcarrera" name="unidad-carrera">
<Hierarchy name="unidad_carrera" hasAll="true" primaryKey="idcarrera">
<Table name="lt_carreras" schema="guarani">
</Table>
<Level name="unidad_academica" column="unidad_academica" nameColumn="nombre_unidad"
type="String" uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
<Level name="carrera" column="nombre_carrera" nameColumn="nombre_carrera" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="colegio_secundario" name="localidad-colegio">
<Hierarchy name="localidad-colegio" hasAll="true" primaryKey="colegio" primaryKeyTable="lt_colegios">
<Join leftKey="localidad" rightKey="localidad">
<Table name="lt_colegios" schema="guarani">
</Table>
<Table name="lt_localidades_colsec" schema="guarani">
</Table>
</Join>
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
<Level name="localidad" table="lt_localidades_colsec" column="nombre" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
<Level name="colegio" table="lt_colegios" column="nombre" nameColumn="nombre" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="cat_horas_trabajadas" name="trabajahs">
<Hierarchy name="trabajahs" hasAll="true" primaryKey="categoria">
<Table name="lt_horastrabajadas" schema="guarani">
</Table>
<Level name="categoria_hstrabajadas" column="descripcion" nameColumn="descripcion" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Dimension type="StandardDimension" foreignKey="tipo_ingreso" name="tipo_ingreso">
<Hierarchy name="tipo_ingreso" hasAll="true" primaryKey="codigo_tipo">
<Table name="lt_tipoingreso" schema="guarani">
</Table>
<Level name="tipo_ingreso" column="descripcion" nameColumn="descripcion" type="String"
uniqueMembers="false" levelType="Regular" hideMemberIf="Never">
</Level>
</Hierarchy>
</Dimension>
<Measure name="ni" column="cant_nuevos_inscriptos" aggregator="sum" caption="nuevos inscriptos"
visible="true">
</Measure>
<Measure name="ri" column="cant_reinscriptos" aggregator="sum" caption="reinscriptos" visible="true">
</Measure>
<Measure name="egresados" column="cant_egresados" aggregator="sum" visible="true">
</Measure>
<CalculatedMember name="alumnos" formula="[Measures].[ni] + [Measures].[ri]" dimension="Measures">
<CalculatedMemberProperty name="NUMERIC_TYPE" expression="Iif(Value >
0,'style=green','style=red')" value="Numeric">
</CalculatedMemberProperty>
</CalculatedMember>
</Cube>
</Schema>
Tópicos





no cubiertos en los ejemplos que pueden implementarse en MONDRIAN:
Roles y control de acceso
Dimensiones “copo de nieve”
Formateo condicional
Internacionalización
Funciones definidas por el usuario
2. Publicar el cubo obtenido en Pentaho
Tenemos que configurar un password en pentaho para publicar schemas, para ésto, modificamos el
siguiente archivo:
/pentaho/biserver-ce/pentaho-solutions/system/publisher_config.xml
La siguiente entrada:
<publisher-config>
<publisher-password></publisher-password>
</publisher-config>
Y le agregamos la password deseada. Por ejemplo: <publisher-password>ana</publisher-password>
Para que quede efectiva, subimos y bajamos el server.
Después estaremos en condiciones de utilizar la operación del menú de Schema WorkBench “Publish”
3. Visualizar el cubo con Jpivot
Si tenemos todo hecho y publicado, procedamos a navegar el cubo:
 http://localhost:8080/pentaho
 Nos logeamos con el administrador, “Joe”
 En el menú herramientas actualizamos la cache de Mondrian.
 Click en “New Analysis View”
 Seleccionamos el esquema y el cubo que creamos.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
JPIVOT
(extraído de “ ” de Héctor Francisco Hernández)
Existen componentes y programas conocidos como "clientes OLAP", que trabajan con Mondrian, cuyo objetivo
es proporcionar una interfaz ("front" en inglés) "prefabricada" donde, con sólo introducir la consulta MDX, se
puede obtener los datos en una tabla navegable, imprimirlos, graficarlos y hasta exportarlos a una hoja de
cálculo. Entre estos programas se encuentra JRubik, una aplicación de escritorio programada con Swing, y
JPivot, que está implementada como un conjunto de tags JSP (tecnología web), por lo que es altamente
configurable y se integra bien con nuestras aplicaciones web.
JPivot viene integrado a Pentaho, y su licencia open source nos permite modificar según nuestras
necesidades. Es fácil cambiar el aspecto de la interfaz del navegador.
( Extraído de Hefesto )
Cabe aclarar que una consulta a un DW, generalmente consiste en la obtención de indicadores a partir de los
datos (hechos) de una tabla de hechos, restringidas por las propiedades o condiciones de los atributos que
hayan sido creados.
Las operaciones que se pueden realizar sobre modelos multidimensionales y que son las que verdaderamente
les permitirán a los usuarios explorar e investigar los datos en busca de respuestas, son:
Modelo
Multidimensional de
Ejemplo
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
 Drill-down
 Drill-up
 Drill-across
 Roll-across
 Pívot
 Page
Visualizando Cubos de Mondrian con Jpivot
Después de publicar el cubo en el repositorio de soluciones de Pentaho se puede utilizar para construir
aplicaciones de análisis.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
La consola de usuario del servidor de Pentaho BI ofrece la posibilidad de crear una vista de análisis, que es
esencialmente una cross table JPivot del top de un cubo de Mondrian, incluído en una de acción de Pentaho.
Para crear una nueva vista de análisis, haga clic en el icono de vista de análisis en la barra de herramientas o
en la página de área de trabajo inicial. Se le pide que elija un esquema, y dentro del esquema, de un cubo.
Después de elegir el esquema y el cubo y confirmar el cuadro de diálogo, una tabla dinámica aparece.
Inicialmente, los miembros de todas las dimensiones por defecto se muestran en el eje vertical, y la medida
predeterminada se muestra en el eje horizontal. Recuerde que, normalmente, el miembro predeterminado es
el miembro “All”, así que el resultado es una tabla con un solo valor al más alto nivel posible agregación.
Si lo desea, puede guardar la vista de análisis para su uso posterior, haga clic en uno de los iconos de
disquetes en la barra de herramientas de la Consola de Pentaho usuario. Se le pide que proporcione una
ubicación dentro del repositorio, así como un nombre.
INTRODUCCIÓN A PENTAHO BI SUITE 3.5
COMMUNITY EDITION
Al salvar el tabla dinámica, el estado de la tabla también se guardarán, lo que le permite recuperar un
punto de vista específico de los datos que se interese.
Drill y Navegación OLAP de JPivot
Ver la presentación.