POST 5: Desarrollo del Modelo Dimensional del Kardex

Una base de datos con “modelo dimensional” es una base de datos que tiene una estructura adecuada para resolver consultas analíticas. Se trata de modelos sencillos que aseguran unos buenos tiempos de respuesta, y que se corresponden bastante con el lenguaje de negocio de los usuarios. Las herramientas de BI se conectan al “modelo dimensional” del DWH. Típicamente, se implementa con alguna de estas dos opciones: 

        Opción A: En una base de datos relacional. 

        Opción B: En una base de datos multidimensional. 

En el caso de que utilices una base de datos relacional (esto es: una base de datos normal y corriente de las de toda la vida), construirás el “modelo dimensional” utilizando una estructura en estrella, o una estructura en copo de nieve.

Y si utilizas una base de datos multidimensional, construirás “cubos”, y utilizarás una tecnología específica para estos menesteres (con sus ventajas e inconvenientes).

Se llama “modelo dimensional”, creo, porque para su creación/definición se hace un estudio sobre los datos de la empresa, identificando las “dimensiones”, y analizando como las dimensiones se relacionan entre sí (creando jerarquías), y como se relacionan con las tablas de hecho (creando “estrellas” o “cubos”).

En resumen, el “modelo dimensional” es el modo óptimo de organizar los datos en los sistemas de Business Intelligence, y puede hacerse mediante bases de datos relacionales (ROLAP), o utilizando bases de datos multidimensionales (MOLAP).

Y, sin duda, este artículo quedaría cojo si no mencionase que Kimball y Inmon tuvieron mucho que ver en la popularización de estas metodologías. Recomiendo esta magnífica entrada de Roberto Espinosa para ampliar los conceptos de modelado multidimensional. O en esta presentación que también hablan del modelado dimensional.

¿Que se puede utilizar si no es la normalización? pues tenemos otras técnicas, entre ellas lo que se conoce como modelo dimensional. En este modelo ya hay que cambiar de perspectiva y también hay que tener en claro en que contexto se utiliza. Si tengo mucha información y quiero generar reportes desde ella para realizar análisis, utilizaremos un modelo dimensional; si por otra parte lo que se quiere es guardar información y que la misma esté lo más completa posible (íntegra), hay que utilizar un modelo normalizado en el nivel adecuado (1FN, 2FN, 3FN, 4FN, etc.).

Retomando los modelos dimensionales y sabiendo donde se han de utilizar, ahora se presenta un informe técnico en base a un estudio realizado donde se generó un modelo dimensional a partir de una estructura normalizada, en dicho informe se aprecia, entre otras cosas; la diferencia en el tiempo de respuesta de las consultas, lo cual asoma que el modelo dimensional resulta conveniente para situaciones de búsqueda de información.

Informe técnico modelo dimensional: Enlace

POST 4: Fase de Diseño.

Ha llegado el momento de comenzar con el proceso de desarrollo y diseño de un sistema que sirva de apoyo para la toma de decisiones en el ámbito académico bien sea cualquier nivel de educación, lo hemos llamado "Krystal" y su lema es "Para medir el desempeño con claridad y coordinación" creado por el Grupo 3.

Una problemática actual tiene que ver con la forma como se lleva el control de la evolución académica de los estudiantes durante cada período educativo que cursan indiferentemente como sea el proceso en el institución donde se harán tal control (semestre, trimestre, anual, etc), esto en los casos donde existe tal control.

Se ha detectado un punto crítico, y es el hecho concreto que la medición del desempeño de los estudiantes muchas veces se hace al final del período académico o simplemente no se hace porque no existen las herramientas necesarias para tal fin, donde ya no hay acción posible que tomar sino que queda la esperanza de un proceso de reparación o la resignación de volver a ver la materia por parte el estudiante y si es el caso del evaluador simplemente aceptar la situación y seguir implantando su materia sin ningún estudio o modificación para la mejora del rendimiento del alumnado.

Por lo expuesto anteriormente, se tiene como objetivo fundamental el proveer un sistema que le permita a los estudiantes realizar fácilmente un seguimiento de su desempeño académico, pudiendo así detectar de forma temprana cualquier desviación que le afecte el resultado final en una materia. Además de ello, también podrían tener su historial de desempeño, donde se mostraría su evolución a lo largo del ciclo de estudio, ayudando esto a visualizar bajo que condiciones son más efectivos académicamente.

De la misma forma, partiendo de la información de los alumnos, los profesores pueden detectar variaciones en el rendimiento de sus estudiantes, agruparlos de acuerdo a su desempeño para dirigir una mayor atención en aquellos que la necesiten, y en fin; disponer de un conjunto de información que le permita tomar decisiones para mejorar los resultados de las materias que imparte.

Y no solo termina en los profesores, el sistema provee la agregación de datos (consolidación), lo cual le permite a las instancias organizacionales por encima del nivel del profesor tener resúmenes que también le ayuden a tomar decisiones oportunas y efectivas, además de mostrarles el estado de salud de los segmentos académicos que están bajo su responsabilidad.

El proyecto ciertamente resulta interesante y a primera vista asoma que puede ser de gran utilidad, sin embargo se requiere un trabajo para lograrlo y he aquí que viene la parte importante de su ciclo de vida. Para ello es importante que cada integrante tenga tareas definidas y que éstas puedan ser ejecutadas sin ningún tipo de dependencia de los demás, y si hay dependencia, que sea mínima; ya que si las tareas de una persona dependen totalmente de otra, es igual a que lo hiciera una sola.

Es importante aclarar que en la primera ejecución de una tarea no se logrará el resultado esperado, sino que a partir de un proceso de realimentación en base a la experiencia adquirida es que se van mejorando las cosas. Entonces podemos evidenciar que todo proceso tiene una historia. Afortunadamente existen herramientas que nos permiten llevar tal control y poder "retroceder el tiempo" hacia el punto que necesitemos durante el desarrollo de un proyecto de software para mejorar lo que se había hecho. Hay muchas, sin embargo nos orientaremos al uso del protocolo "Git" a través del servicio de versionamiento gratuito que ofrece Google (code.google.com).

Explicar "Git" no es el objetivo de este post, la intención es dar una introducción al proyecto que se va a realizar e indicar la herramienta de control utilizada; esto con el fin de que cualquiera que desee indagar un poco más en lo que se está realizando, pueda saber que herramientas necesita para hacerlo.

No hay más introdución que dar por ahora, dejamos a la mano los recursos de este proyecto para que sea el contenido de éstos los que reflejen el proceso de aprendizaje de los participantes.

A continuación tenemos partes del diseño de este proyecto:

• Visión del Sistema
• Planificación del Proyecto
• Monitoreo Académico Krystal - Para Medir El Desempeño

POST 3: Metodología de Kimball

Metodología de Kimball

La Metodología Kimball, es una metodología empleada para la construcción de un almacén de datos (data warehouse, DW) que no es mas que, una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza.

La metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Este ciclo de vida del proyecto de DW, está basado en cuatro principios básicos:

• Centrarse en el negocio
• Construir una infraestructura de información adecuada
• Realizar entregas en incrementos significativos (este principio consiste en crear el almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses, en este punto, la metodología se parece a las metodologías ágiles de construcción de software)
• Ofrecer la solución completa (En este se punto proporcionan todos los elementos necesarios para entregar valor a los usuarios de negocios, para esto ya se debe tener un almacén de datos bien diseñado, se deberán entregar herramientas de consulta ad hoc, aplicaciones para informes y análisis avanzado, capacitación, soporte, sitio web y documentación).

La construcción de una solución de DW/BI (Datawarehouse/Business Intelligence) es sumamente compleja, y Kimball nos propone una metodología que nos ayuda a simplificar esa complejidad. Las tareas de esta metodología (ciclo de vida) se describen a continuación:

Planificación del Proyecto

En este proceso se determina el propósito del proyecto de DW/BI, sus objetivos específicos y el alcance del mismo, los principales riesgos y una aproximación inicial a las necesidades de información.

Esta tarea incluye las siguientes acciones típicas de un plan de proyecto:

• Definir el alcance (entender los requerimientos del negocio).
• Identificar las tareas
• Programar las tareas
• Planificar el uso de los recursos.
• Asignar la carga de trabajo a los recursos
• Elaboración de un documento final que representa un plan del proyecto.

Además en esta parte definimos cómo realizar la administración o gestión de esta sub-fase que es todo un proyecto en si mismo, con las siguientes actividades:

• Monitoreo del estado de los procesos y actividades.
• Rastreo de problemas
• Desarrollo de un plan de comunicación comprensiva que direccione la empresa y las áreas de TI

Definición de Requerimientos del Negocio

La definición de requerimientos, es un proceso de entrevistar al personal de negocio y técnico, aunque siempre conviene, tener un poco de preparación previa. En esta tarea, se debe aprender sobre el negocio, los competidores, la industria y los clientes del mismo. Se debe dar una revision a todos los informes posibles de la organización; rastrear los documentos de estrategia interna; entrevistar a los empleados, analizar lo que se dice en la prensa acerca de la organización, la competencia y la industria y se deben conocer los términos y la terminología del negocio.

Se sugiere entrevistar al personal que se encuentra en los cuatro grupos que se mencionan a continuación:

• El directivo responsable de tomar las decisiones estratégicas.
• Los administradores intermedios y de negocio responsables de explorar alternativas estratégicas y aplicar decisiones
• El personal de sistemas, si existe (estas son las personas que realmente saben qué tipos de problemas informáticos y de datos existen en la organización)
• El personal que se entrevista por razones políticas.

Entre las tareas antes descritas, existe una flecha bidireccional, esto indica que los requerimientos del negocio son el soporte inicial de las tareas subsiguientes, también tiene influencia en el plan de proyecto.

Si avanzamos por el camino central del diagraman, encontramos las tareas asociadas al área de Datos, en esta, diseñaremos e implementaremos el modelo dimensional, y desarrollaremos el subsistema de Extracción, Transformación y Carga (Extract, Transformation, and Load - ETL) para cargar el DW. Las tareas pertenecientes al área, se describen a continuación:

Modelado Dimensional

Es un proceso dinámico y altamente iterativo. Comienza con un modelo dimensional de alto nivel obtenido a partir de los procesos priorizados y descritos en la tarea anterior, y El proceso iterativo consiste en cuatro pasos:

1. Elegir el proceso de negocio: que consiste en, elegir el área a modelizar. Esta es una decisión de la dirección, y depende fundamentalmente del análisis de requerimientos y de los temas analíticos anotados en la etapa anterior.
2. Establecer el nivel de granularidad: La granularidad significa especificar el nivel de detalle. La elección de la granularidad depende de los requerimientos del negocio y lo que es posible a partir de los datos actuales. La sugerencia general es comenzar a diseñar el DW al mayor nivel de detalle posible, ya que se podrían realizar agrupamientos posteriores, al nivel deseado.
3. Elegir las dimensiones: Las dimensiones surgen naturalmente de las discusiones del equipo, y facilitadas por la elección del nivel de granularidad y de la matriz de procesos/dimensiones (que se realiza en la tarea 4.2) Las tablas de dimensiones tienen un conjunto de atributos (generalmente textuales) que brindan una perspectiva o forma de análisis sobre una medida en una tabla hechos. Una forma de identificar las tablas de dimensiones es que sus atributos son posibles candidatos para ser encabezado en los informes, tablas pivot, cubos, o cualquier forma de visualización, unidimensional o multidimensional.
4. Identificar medidas y las tablas de hechos: Este paso, consiste en identificar las medidas que surgen de los procesos de negocios. Una medida es un atributo (campo) de una tabla que se desea analizar, sumando o agrupando sus datos y usando los criterios de corte conocidos como dimensiones. Las medidas habitualmente se vinculan con el nivel de granularidad del punto 2, y se encuentran en tablas que denominamos tablas de hechos (fact en inglés). Cada tabla de hechos tiene como atributos una o más medidas de un proceso organizacional, de acuerdo a los requerimientos. Un registro contiene una medida expresada en números, como ser cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una operación de agregación (promedio, conteo, suma, etc.) en función de una o más dimensiones. La granularidad, en este punto, es el nivel de detalle que posee cada registro de una tabla de hechos.

Diseño Físico

En esta tarea, se contestan las siguientes preguntas:

¿Cómo puede determinar cuán grande será el sistema de DW/BI?

¿Cuáles son los factores de uso que llevarán a una configuración más grande y más compleja?

¿Cómo se debe configurar el sistema?

¿Cuánta memoria y servidores se necesitan? ¿Qué tipo de almacenamiento y procesadores?

¿Cómo instalar el software en los servidores de desarrollo, prueba y producción?

¿Qué necesitan instalar los diferentes miembros del equipo de DW/BI en sus estaciones de trabajo?

¿Cómo convertir el modelo de datos lógico en un modelo de datos físicos en la base de datos relacional?

¿Cómo conseguir un plan de indexación inicial?

¿Debe usarse la partición en las tablas relacionales?

Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL)

El subsistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta el Data warehouse. Si se diseña adecuadamente, puede extraer los datos de los sistemas de origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los mismos, consolidar la información proveniente de distintos sistemas, y finalmente cargar (grabar) la información en el DW en un formato acorde para la utilización por parte de las herramientas de análisis.

Implementación

La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del negocio. Existen varios factores extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la comunicación y las estrategias de feedback.

Mantenimiento y Crecimiento del Data Warehouse

Para administrar el entorno del Data Warehouse existente es importante enfocarse en los usuarios de negocio, los cuales son el motivo de su existencia, además de gestionar adecuadamente las operaciones del Data Warehouse, medir y proyectar su éxito y comunicarse constantemente con los usuarios para establecer un flujo de retroalimentación, En esto consiste el Mantenimiento. Finalmente, es importante sentar las bases para el crecimiento y evolución del Data Warehouse en donde el aspecto clave es manejar el crecimiento y evolución de forma iterativa utilizando el Ciclo de Vida propuesto, y establecer las oportunidades de crecimiento y evolución en orden por nivel prioridad.

Si avanzamos por el camino inferior del diagraman, encontramos las tareas asociadas al área Aplicaciones de Inteligencia de Negocios, en esta ruta se encuentran tareas en las que diseñamos y desarrollamos las aplicaciones de negocios para los usuarios finales. Las tareas pertenecientes al área, se describen a continuación:

Especificación de aplicaciones de BI

En está tarea se proporciona, a una gran comunidad de usuarios una forma más estructurada y por lo tanto, más fácil, de acceder al almacén de datos. Se proporciona este acceso estructurado a través de lo que llamamos, aplicaciones de inteligencia de negocios (Business Intelligence Aplications). Las aplicaciones de BI son la cara visible de la inteligencia de negocios: los informes y aplicaciones de análisis proporcionan información útil a los usuarios. Las aplicaciones de BI incluyen un amplio espectro de tipos de informes y herramientas de análisis, que van desde informes simples de formato fijo, a sofisticadas aplicaciones analíticas que usan complejos algoritmos e información del dominio. Kimball divide a estas aplicaciones en dos categorías basadas en el nivel de sofisticación, y les llama:

1. Informes estándar: son informes relativamente simples, de formato predefinido, y parámetros de consulta fijos, proporcionan a los usuarios un conjunto básico de información acerca de lo que está sucediendo en un área determinada de la empresa y se utilizan día a día.
2. Aplicaciones analíticas: Son más complejas que los informes estándar. Estas aplicaciones pueden incluir algoritmos y modelos de minería de datos, que ayudan a identificar oportunidades o cuestiones subyacentes en los datos, y el usuario puede pedir cambios en los sistemas transaccionales basándose en los conocimientos obtenidos del uso de la aplicación de BI. Algunas aplicaciones analíticas comunes incluyen:

• Análisis de la eficacia de la promociones
• Análisis de rutas de acceso en un sitio Web
• Análisis de afinidad de programas
• Planificación del espacio en espacios comerciales
• Detección de fraudes
• Administración y manejo de categorías de productos

Por ultimo, en el camino superior, encontramos las tareas asociadas al área Tecnología en esta ruta, se encuentran las tareas relacionadas con software específico, por ejemplo, Microsoft SQL Analysis Services, etc. Las tareas pertenecientes al área, se describen a continuación:

Diseño de la Arquitectura Técnica

El área de arquitectura técnica cubre los procesos y herramientas que se aplican a los datos. En el área técnica existen dos conjuntos que tienen distintos requerimientos, brindan sus propios servicios y componentes de almacenaje de datos, por lo que se consideran cada uno aparte: El back room (habitación trasera) y el front room (habitación frontal). El back room es el responsable de la obtención y preparación de los datos, por lo que también se conoce como adquisición de datos y el front room es responsable de entregar los datos a la comunidad de usuario y también se le conoce como acceso de datos.

Informe Técnico: enlace