17.2. Preparando el reporting. Definición de metadatos con Metadata Editor.

La plataforma Pentaho nos proporciona dos formas integradas de realizar reporting, ademas de permitir la utilización e integración de otras herramientas (como JasperReports o Birt). Las herramientas propias de Pentaho son las siguientes:

• Web Ad Hoc Query and Reporting Client (WAQR): herramienta integrada en el portal que nos permite realizar querys y reporting adhoc de una forma intuitiva y sencilla, aunque con limitaciones.
• Pentaho Report Designer (PRD): a través de una herramienta de diseño desktop, que nos permite definir y construir nuestros informes, y luego publicarlos en el portal de BI para que puedan ser ejecutados por los usuarios.

Para poder trabajar con WAQR, es indispensable tener definido el correspondiente metadatos con PME (Pentaho Metadata Editor), ya que es el único origen de datos permitido en la plataforma para ese componente. En cambio, con PRD podremos utilizar otros muchos origenes de datos, aunque también podremos utilizar el metadata definido con PME como origen de datos (y asi poner una capa lógica encima del modelo físico que va a facilitar con toda probabilidad el diseño de informes).

Veamos antes de entrar en detalle con Pentaho Metadata Editor cual es el planteamiento de Pentaho respecto a los metadatos.

¿Que son los metadatos?

Como hemos visto en varias entradas del blog, los metadatos son información sobre los datos. Se utilizan en las herramientas ETL (como vimos al utilizar Talend), en las herramientas BI (como por ejemplo en Microstrategy) y Pentaho también tiene su propio enfoque.

El metadata de Pentaho esta basado en el estandar Common Warehouse Metamodel (CWM), que es una especificación creada y mantenida por el Object Management Group (OMG). Intenta ser un estandar abierto y neutral para permitir el intercambio y representación de metadatos en plataformas Business Intelligence (http://www.omg.org/technology/cwm).

Ventajas del nivel de metadatos.

El hecho de poner este nivel de metadatos por encima del nivel físico de las tablas nos proporciona algunas ventajas bastante evidentes a la hora de trabajar con nuestro sistema BI.

• Interfaz de usuario mas amigable: cuando trabajamos con bases de datos relacionales, se hace complejo la interrogación de la base de datos, pues hay que conocer en profundidad el lenguaje SQL (para sacarle todo el partido a las consultas) y también se hace necesario conocer la estructura física de las tablas. Al poner la capa de metadatos  por encima, describimos las tablas, los campos y sus relaciones, y los podemos presentar al usuario de una forma  mas comprensible para que construya sus  propios reports sin necesidad de conocer la «compleja» realidad que puede haber detras.

• Flexibilidad e independencia del esquema físico: si tenemos un gran número de informes definidos en nuestro sistema BI, y es necesario cambiar la estructura física de los datos, esto nos obligara a modificar todo los informes para adaptarlos a esta casuística. Al tener la capa de metadatos por enmedio, en un caso como este, modificaremos su esquema con los cambios realizados sin necesidad de modificar los informes. En estos casos, la capa de metadatos nos va a ayudar a absorver el impacto de los cambios en el esquema físico de la base de datos.

• Definición de privilegios de acceso: normalmente, las bases de datos nos permiten establecer privilegios de acceso sobre los objetos o sobre las operaciones que se realizan sobre ellos. Pero no nos  permiten establecer privilegios de acceso sobre la granuralidad de los datos (por ejemplo, limitaciones de lectura según las zonas geográficas, en un tipo ejemplo de informes para delegados regionales). Es decir, no tenemos un control de acceso a nivel de registro. A través de los metadatos, podemos establecer autorizaciones de este tipo bien a nivel de usuario o de rol (grupo de autorizaciones), para establecer politicas de acceso a los datos con alto nivel de detalle.

• Gestión de la localizacion (internacionalizacion): la definición de metadatos también nos  puede permitir gestionar la internacionalización de un sistema BI, definiendo propiedades como etiquetas o descripciones de las tablas y columnas a nivel de idioma. Cuando se utilizen esos elementos en los informes, aparecerán en el idioma del usuario, recuperando las descripciones (apropiadas a cada lenguaje) del metadatos.

• Homogeneización del formateo de datos: en un sistema de reporting de BI,  por ejemplo, puede ser aconsejable unificar la representación de los datos, especialmente en aquellos tipos de campos que necesita un formateo especial (importe monetarios, por ejemplo), con sus correspondientes indicadores de moneda, simbolo de decimales o de miles. Igual para el caso de links a otros informes o páginas (que se han de representar de una forma especial) o similares. El metadatos también nos puede ayudar en estos casos a definir un formato asociado a los campos, que luego se aplicara cuando sean utilizados en los informes.

Caracteristicas del metadatos de Pentaho.

Antes de ver como definir nuestro metadatos utilizando PME, vamos a ver como Pentaho utiliza esta capa en la práctica. Cuando definimos el metadatos, al terminar el proceso este queda archivado en un fichero .xmi (o a nivel de base datos, en el repositorio), y se exporta al servidor BI. En este momento ya puede ser utilizado por la herramienta de reporting Adhoc, o bien desde Pentaho Reporting Designer, para construir nuestro propios informes, utilizandolo como si fuese un origen de datos mas (como cualquier origen de base de datos relacional, por ejemplo).

La construcción de los informes se realiza sin necesidad de ver el esquema físico de los datos, sino que utilizamos la definición que se haya descrito en el metadatos. Al ejecutar uno de estos informes, la definición de las querys se guardan en un formato llamado Metadata Query Language (MQL), que se resuelve contra el metadatos, y se traduce a nivel SQL  para lanzar la consulta contra la base de datos en el lenguaje que esta entiende. Tenemos por tanto un motor MQL que se encarga de realizar este mapeo entre el esquema Lógico y el esquema Físico (tal y como podeis ver en la imagen anterior).

Podemos hablar de 3 niveles en la definición del metadatos: physical layer, logical layer y delivery layer.

En primer lugar, tenemos el physical layer, que conocen los consultores de BI en profundidad (pues lo han diseñado y construido según los requerimientos). Corresponde a los campos y tablas de la base de datos. Estos objetos son los componentes que nos van a permitir construir el logical layer (pues no tiene sentido que los usuarios finales tengan que conocer como esta creada realmente la base datos).

En el logical layer, las tablas del nivel físico son redefinidas, y enriquecidas con columnas adicionales construidas a partir de las campos de las tablas y operaciones o expresiones sobre ellas. Ademas establecemos relaciones entre las tablas, que serán la forma de extraer información de forma conjunta (joins). Ademas, podemos crear varias tablas lógicas sobre la misma tabla física, para el tratamiento,por ejemplo, de las dimensiones role-playing (la misma tabla de dimensión juega diferentes roles).

Layers en Pentaho Metadata Editor

En el delivery layer se realiza una selección de columnas de la capa lógica y se agrupan en unidades que tengan sentido para el usuario de negocio (Business View). Esta es la única parte del metadatos que es visible para los usuarios finales, y partir de ella se realizará la construcción de los informes.

En todos los niveles, podemos definir diferentes elementos, que son principalmente conceptos y propiedades. Ademas, se puede establecer como los conceptos pueden heredar propiedades de otros. Veamos un poco más en detalle en que consiste esto:

Propiedades

Los objetos en el metadata pueden tener un gran número de propiedades. Las propiedades son items con nombres que se usan para asociar diferentes tipos de información a los objetos. Las propiedades se pueden dividir en categorias:

• Propiedades generales: como el nombre y la descripción.
• Propiedades de visualización: como fuente de letra, color, etc.
• Descriptores de modelo: expresiones, tipo de datos, reglas de agregacion, etc.

Dependiendo del tipo de objeto con el que estemos  trabajando, habra propiedades que seran obligatorias y habrá que definir siempre. Otras estarán o no disponibles según el tipo de objeto.

Conceptos.

Ademas de las propiedades, en el metadata de Pentaho podemos trabajar con una colección de propiedades y agruparlas en lo que llaman Concepto. Un concepto se puede aplicar a un objeto del metadatos, y sus propiedades son heredadas por el objeto. Por ejemplo, para todos los importes monetarios (que vamos a mostrar con un formato determinado de numeros decimales) o tipo de letra, podemos crear un concepto y luego aplicarlo a todas las columnas que queremos que compartan propiedades comunes. De esta forma, en lugar de modificar las características  en los todos los objetos del metadata, lo haremos en los conceptos y asi nos aseguramos su consistencia y mantenerlo de una forma más fácil.

Herencia.

Las propiedades se pueden gestionar utilizando la herencia. La herencia ocurre basando un objeto (el objeto hijo) en otro objeto (el objeto padre). De esta forma, las propiedades del hijo y sus valores se construyen a partir de las del padre. Los cambios en las propiedades se transmiten en forma de cascada en la cadena de herencia.

Las propiedades que hereda un objeto se pueden quedar como las del padre, o bien ser modificadas y configuradas como una instanciacion propia de dichas propiedades. En ese momento se rompe la cadena de herencia de esa propiedad con respecto al padre. Cuando se modifique algo del padre, no se modificara la propiedad en el  hijo. En Pentaho tenemos dos niveles de herencia:

• Herencia de objetos derivados: los objetos del metadata heredan las propiedades de sus objetos padre. Por ejemplo, definimos una tabla en el nivel físico y configuramos sus propiedades. Al utilizarla en el logical layer, todas las propiedades de nombres de tabla, campos, formatos, autorizaciones que hubieramos definido antes se heredan en el nuevo objeto. Si la tabla fisica se utiliza en varios tablas lógicas, todas heredaran las  mismas propiedades. Puede ser util, pues seguramente para unas columnas  determinadas pondremos unas descripciones y un formato que nos interesan que se utilicen en todos los sitios de la misma manera. En ese caso, cualquier cambio en el modelo físico se transmitiran a los objetos «descendientes».
• Herencia de conceptos: como hemos visto los conceptos son una forma de asignar propiedades a los objetos de una forma centralizada. Dentro de los conceptos, podemos establecer tambien jerarquía de propiedades, de forma que podemos tener un concepto general, y luego conceptos descendientes de este con propiedades especificas (que luego podremos también asignar a los objetos del metadatos).

Pentaho Metadata Editor.

Como paso final, vamos a ver como definir el metadatos para nuestro modelo (en una entrada anterior del blog vimo como quedaba la estructura física de nuestra base de datos), teniendo en cuenta todas las características de PME vistas hasta ahora.

Al trabajar con PME, podemos utilizar un repositorio local (a nivel de ficheros) o un repositorio de base de datos. El repositorio de PME es independiente del de la plataforma BI o el de Kettle, no tiene nada que ver. Se trabaja con el concepto de Dominio, que es un contenedor que incluye la definición del metadatos.

Los tres niveles que hemos indicado antes (physical layer, logical layer y delivery layer), se implementan de la siguiente manera.

Physical Layer

Contiene los objetos físicos que existen a nivel de base de datos. Es la parte básica de la definición del metadata. Podemos tener varios origenes de datos (varias conexiones), de las que seleccionaremos las tablas que nos interesen para nuestro modelo, y para cada tabla, los campos que la componen. Podemos seleccionar solo aquellos campos que nos interesen, o bien seleccionarlos y luego ocultarlos cuando pasemos al nivel lógico.

• Conexiones: definimos las conexiones de la forma habitual (es necesario tener el jdbc correspondiente y depositarlo en el directorio \libext\jdbc dentro de la carpeta donde tengamos instalado PMD).
• Tablas: desde la conexión, con el menú contextual podremos importar las tablas que queremos añadir a nuestro modelo (con la opción Import Tables o desde Import from explorer). Una vez las tablas estan importadas, podremos modificar sus propiedades, tales como su nombre (incluyendo la internacionalización), descripcion, tipo de tabla (Dimension, Hechos u Otros)

Database Explorer

• Campos: por defecto, se importan todos los campos de las tablas. Posteriormente podemos eliminar aquellos campos que no nos interese tener en el metadata, o bien incluir nuevos campos, como calculos de los existentes o iguales que los existentes pero cambiando determinadas propiedades (por ejemplo, el formato). Al igual que en las tablas, en los campos tenemos un conjunto de propiedades (Nombre, Descripción, Fuente, Color, Alineación del texto, Tipo de datos, forma de agregación). Si el campo es una formula, podremos indicar la composición de esta y también podremos indicar si el campo queremos que este oculto. Además de estas propiedades por defecto, podemos añadir otras, como temas de seguridad, mascaras de edición, ancho de columna, textos explicativos adicionales, etc.

Propiedades de metadata de los campos en una tabla física

A la hora de la construcción de los campos físicos, podemos definir campos que sean operaciones entre varios campos o formulas. Para ampliar la información sobre esta funcionalidad, podeís ver la documentación Online de Pentaho.

Logical Layer.

Una vez tenemos definidos todos los componentes del nivel físico (que van a ser las piezas básicas de nuestro metadatos), continuaremos con el segundo nivel, el nivel lógico.

• Business Models: es un contenedor que nos permite agrupar los objetos lógicos y sus relaciones, para disminuir de la mejor manera posible el impacto de los cambios a nivel físico. Podemos tener varios modelos de negocio dentro de un dominio de metadatos (aunque solo soporta una conexión a base de datos por cada uno de ellos).
• Business Tables y Columns: cuando creamos una nueva Business Table, nos aparece la lista de tablas físicas disponibles en nuestro dominio y seleccionamos las que nos interesan. En ese momento se crean la BT, como una abstracción de la tabla física. Como podeís ver en la imagen, cada tabla lógica (business table) tiene asociada su correspondiente tabla física, y hereda todas las propiedades que tuviera esta. Podemos dejar los atributos como estan o modificarlos en el caso de que nos interese. La tabla también hereda todos los campos que tuviera definidos la tabla física, aunque se pueden eliminar los que queramos. A la hora de añadir, solo se pueden utilizar los definidos en la tabla física, aunque podremos añadir cuantas veces deseemos campos que ya existen y modificar sus propiedades para crear nuevos campos.

Editor de propiedades de las Business Tables

• Relaciones: puede haber casos en que para hacer la lectura de datos, necesitemos juntar varias tablas. En la parte de relaciones, definimos como se va a realizar el join entre las diferentes tablas de nuestro modelo. En la imagen podeis ver el correspondiente editor donde vamos definiendo, en cada tupla de tablas, como va a ser la relación entre ellas.

Editor de relaciones entre Business Tables

Delivery Layer.

La parte final de la definición del metadata es decidir, de todos los elementos de los que disponemos en el modelo de negocio, cuales van a estar a disposición de los usuarios. Esto lo realizamos a traves de las Business Views y las Business Categories. Veamos en que consiste esto:

• Business Views: las vistas de negocio son los contenedores que visualizaran los usuarios, y que contendrán los elementos que van a poder utilizar en el reporting y análisis ad-hoc. Podremos tener varias vistas de negocio a través de lo que llamamos categorias. Las categorias pueden contener una tabla lógica completa o bien una lista de campos seleccionados de varias tablas lógicas. Las diferentes categorias apareceran luego en el reporting, con todos los elementos que hayamos incluido en su definición. Aquí también podremos incluir seguridad para determinar que usuarios pueden trabajar con ellas. Las propiedades de los elementos, igual que con las tablas de negocio, son heredadas de estas, aunque pueden ser modificadas (sobrescribiendo la herencia por defecto).

Gestión de categorias

Hemos realizado la definición del metadata de nuestro proyecto EnoBI para permitir el reporting sobre el.  Como paso final, nos quedaría publicar el metadatos en el portal de BI para poder utilizarlo en el reporting ad-hoc. Para ello, lo publicaremos en el portal (solo puede haber un fichero por solución). También podriamos haber hecho público el fichero ubicandolo en la correspondiente carpeta del servidor (colgando de pentaho-solutions). Igualmente, podemos exportar el fichero xmi para utilizarlo directamente con Pentaho Reporting Designer, como un origen de datos más a la hora de construir los informes.

Publicacion del metadata en el servidor BI

Para trabajar con PRD no hace falta publicar en el servidor BI, sino que accedemos directamente al fichero xmi como origen de datos. Para verificar que el metadata esta correctamente importado en el portal BI, nos conectamos con nuestro usuario de pruebas y realizamos nuestro primer informe Ad-hoc. Todo se ha configurado correctamente.

Informe Adhoc - Ejemplo sencillo de listado de clientes

Podeis ampliar información sobre todo lo visto en esta entrada del blog en la documentación online de Pentaho. A continuación vamos a ver como podemos definir nuestro esquema dimensional utilizando Pentaho Schema Workbench, lo que nos permitira posteriormente trabajar con los análisis sobre los cubos Olap.