El modelo Lógico de nuestro DW. Revisión. Construcción de un prototipo para validación.

Antes de continuar con las siguientes fases del proyecto, se revisa el modelo propuesto y es aprobado. Se va a construir un prototipo para verificar su corrección y funcionalidad antes de pasar al diseño físico definitivo, el analisis del sistema ERP para la identificación de las dimensiones e indicadores  y la construcción de los procesos ETL, que serán los que darán vida a nuestro DW (y que recordemos que sera una de las fases mas complejas y con mas carga de trabajo del proyecto).

Como hemos indicado anteriormente, el módelo lógico definitivo sería el siguiente:

La fase de construcción de un prototipo se podría obviar pero es interesante dedicar unas jornadas a la construcción de un pequeño prototipo con datos reales (o lo mas reales posible ) para que los usuarios puedan validar los resultados del diseño. De esta forma, validamos el modelo antes de empezar la tediosa tarea de construirlo fisicamente y llenarlo de datos desde nuestros sistemas operacionales u otras fuentes. En algunos proyectos, la construcción del prototipo se realiza en el momento de la venta del proyecto como una herramienta de ayuda a la toma de decisión de la compra.

Para la construcción de nuestro prototipo, partiendo del modelo lógico, vamos a utilizar Mysql ( y la herramienta de diseño Mysql Workbench ). Para la construcción del prototipo, utilizaremos la Microstrategy Reporting Suite. Es la suite gratuita que Microstrategy ha lanzado al mercado para hacer frente a la proliferación de los productos OpenSource y para establecer su propia estrategia de captación de clientes (hoy en día ya no valen estrategias de precios de licencia por las nubes). En nuestro caso, hemos registrado una licencia para 25 usuarios. La licencia free incluye lo siguiente:

Características incluidas en Microstrategy Reporting Suite: www.microstrategy.es

Puede ser un buen punto de partida para un pequeño proyecto o para la validación de productos (aunque al final estamos con un fabricante propietario y estamos de alguna manera “cogidos” a un producto cerrado ). Tener en cuenta que tenemos acceso a una gran parte de las herramientas, así como soporte por correo y online, recursos de formación, video tutoriales, etc, que pueden ser una gran ayuda para familiarizarnos con el producto. También se incluye una amplia documentación en pdf de todos los elementos que forman la suite.

En las entradas del blog iremos publicando el modelo de datos físico utilizado para la construcción del prototipo, la copia de seguridad de mysql con los datos “reales” cargados y los metadatos definidos en la herramienta de Microstrategy por si alguien se anima a construir y validar su propio prototipo.

Por tanto, las cuatro fases de construcción del prototipo serán las siguientes:

1) Diseño físico “preliminar”, orientado a la construcción del prototipo.

Construimos el modelo relacional a través de la herramienta MySQL Workbench, y el diseño final sería el siguiente:

Antes de continuar, y al revisar el modelo físico, nos damos cuenta que es conveniente seguir un criterio para el nombrado de los campos que luego facilite el trabajo en la definición del modelo de datos con las herramientas de Microstrategy, asi como en el momento de definir las jerarquias de los atributos de las dimensiones (tema del que todavia no hemos hablado).

Por tanto, antes de continuar, procedemos a un ajuste del módelo fisico y la nomenclatura de los campos (por ejemplo, para los atributos que haya un código y una descripción, siempre llamaremos campox_id al campo del atributo, y campo campox_desc al campo de descripción del atributo). Es una forma de normalizar y utilizar un convenio que nos permite luego trabajar con mas claridad (teniendo en cuenta la cantidad de atributos diferentes de los que disponemos en nuestro proyecto). Para los atributos donde solo haya un identificador (sea numerico o texto, como por ejemplo, para la denominación de origen), llamaremos al campo nombreatributo_id (por ejemplo denomin_id para la denominación de origen de un producto o variet_id para la varietal utilizada en la elaboración del vino).

El esquema fisico revisado quedaría así:

El fichero del modelado con la herramienta lo podeis encontrar en el link: enobi.mwb

El fichero con las sentencias sql para la creación del esquema fisico en el link: enobi.sql

2) Llenado de datos “reales”.

En MySQL, creamos un catalogo que se llama EnoBI. Este catalogo va a almacenar los datos de nuestro DW (luego veremos que tenemos otros catalogos, como el del Metadatos de Microstrategy, el de estadísticas, etc). En este catalogo creamos las tablas físicas tal y como hemos definido y creamos un juego de datos de ejemplo para poder validar el modelo con el prototipo. Algunos ejemplos de los datos simulados serian los siguientes:

Ejemplo de Datos Simulados

El acceso completo a los datos lo teneis en el link siguiente, donde se accede al fichero de backup de la base de datos realizado con MySQL Administrator: backup.sql

3) Implementación del modelo utilizando Microstrategy Reporting Suite. Definición del modelo de metadatos.

Una vez tenemos preparada nuestra base de datos, ya podemos empezar a preparar el entorno de la Microstrategy Reporting Suite para trabajar con dicha base de datos y para hacer el modelado que luego nos va a permitir utilizar las herramientas de Microstrategy. Debemos realizar varias tareas, que en resumen son:

• Instalación de la Microsoft Reporting Suite. Registro de la licencia y activación. En nuestro caso, hemos instalado en un Windows 7 Ultimate (necesitamos tener instalado el Office XP o superior y tener activado el IIS Internet Information Server en el sistema, pues la Suite hace uso de ella para el tema de acceso Web a los informes).
• Configuración de origenes ODBC: en nuestro caso, no tenemos acceso directo a la bd de datos y vamos a definir los siguientes origenes de datos ODBC:
  • Metadatos: es el catalogo donde Microstrategy se va a guardar todas las definiciones del modelo de datos, informes, etc. Le llamamos ENOBI_MD.
  • Historial: donde Microstrategy se guarda un historial de las acciones realizadas sobre los objetos. Le llamamos ENOBI_HS.
  • Origen de datos: será para acceder a datos del DW en si. Le llamamos ENOBI_DW.
• Ejecución del Configuration Wizard: nos va a permitir realizar de forma asistida la configuración de los elementos mas importantes del sistema. Se configuran 3 aspectos:
  • Tablas de repositorio de metadatos e historial: no pide el catalogo donde se van a ubicar y ejecuta las sentencias sql para crear la estructura de tablas necesaria.
  • Configuración del Microstrategy Intelligence Server.
  • Configuración de Origenes del Proyecto: definición de un origen de Proyecto y su vinculación con el Microstrategy Intelligence Server. Luego sobre el podremos construir nuestro proyecto de BI.
• A continuación vamos a crear nuestro proyecto. Podemos utilizar el Project Builder o la herramienta Desktop (con el Architect o el Project Creation Assistant), donde se realiza la creación del proyecto con un asistente y luego se mantienen los diferentes elementos que lo conforman. Vamos a utilizar el Project Builder para este primer paso (es una herramienta orientada a la construcción de prototipos y para la construcción de Sistemas Productivos se recomienda el Architect/Project Creation Assitant ). El resumen de pasos seguido es el siguiente:
  • Selección del origen de datos para guardar los metadatos e identificación del proyecto. Al seleccionar el origen del proyecto estamos indicado en que esquema de bd de metadatos vamos a guardar todo el modelo.

  

  • Selección del origen de datos del DW.

  

  • Selección de la tabla de hechos.

  

  • Selección de indicadores de nuestro modelo: campos de tabla de hechos que queremos utilizar como indicadores de negocio en nuestro modelo.

  

  • Selección de atributos de las dimensiones.

  

  • Definición de las jerarquias entre los atributos: ya veremos en el desarrollo del proyecto como se definen las jerarquias de los diferentes atributos que tenemos en nuestras dimensiones (que al fin y al cabo son los que nos van a permitir la navegación estructurado por los datos). Sin jerarquía el modelo dimensional no tiene sentido.

  

  • Definición de indicadores calculados (a partir de indicadores base).

Realizamos algunos ajustes en las jerarquias, así como en la definición de indicadores y la asociación que realiza Microstrategy entre los campo id y los campos desc. El modelo esta preparado para la definición de los informes de ejemplo para presentar para la aprobación del módelo lógico presentado.

La definición de las jerarquias de los atributos las podeis encontrar en un documento word en el link: jerarquias.doc

4) Construcción de informes ejemplo. Preparación de la plataforma de prototipo para la revisión con usuarios.

En la siguiente entrada del blog analizaremos los informes construidos para el prototipo, con ejemplos de los mas usuales.