UTILIZACIÓN DE INFORMACIÓN HISTÓRICA PARA DECISIONES EMPRESARIALES

Transcripción

1 UTILIZACIÓN DE INFORMACIÓN HISTÓRICA PARA DECISIONES EMPRESARIALES Autores: Juan David Peña Rivera Jesús Armando Suárez Daza Proyecto de grado presentado para optar el título de Ingeniero de Sistemas Director: Luis Roberto Ojeda PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS SANTAFÉ DE BOGOTA D.C. Junio de 2005

2 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS Rector Magnífico: Padre Gerardo Remolina Vargas S.J. Decano Académico Facultad de Ingeniería: Ingeniero Francisco Rebolledo Decano del Medio Universitario Facultad de Ingeniería: Padre José Sarmiento Nova S.J. Director Carrera de Ingeniería de Sistemas: Ingeniera Hilda Cristina Chaparro López Director Departamento de Ingeniería de Sistemas: Ingeniero Germán Alberto Chavarro

3 Nota de Aceptación Director del Proyecto Jurado Jurado Junio, 2005

4 Artículo 23 de la Resolución No. 1 de Junio de 1946 La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia

5 TABLA DE CONTENIDO INTRODUCCIÓN...1 I MARCO TEÓRICO DATA WAREHOUSE COMPONENTES DE UN DATA WAREHOUSE BODEGA DE DATOS Y DATAMARTS Características de la bodega de datos PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA DE LOS DATOS EXPLOTACIÓN Análisis OLAP...7 II. HERRAMIENTAS DE DATA WAREHOUSE HERRAMIENTAS DE BASES DE DATOS Y OLAP MOTOR DE BASES DE DATOS MYSQL MOTOR DE BASES DE DATOS POSTGRESQL Arquitectura de la herramienta HERRAMIENTA DE OLAP JPIVOT MONDRIAN Arquitectura de la herramienta Estrategias de almacenamiento y agregación API MDX Esquema Mondrian Modelo lógico...16 III. METODOLOGIA PARA EL DESARROLLO DE UN DATA WAREHOUSE METODOLOGIA DE RALPH KIMBALL PARA UN PROYECTO DE DATA WAREHOUSE Planeación y administración del proyecto Análisis de requerimientos Modelamiento dimensional Diseño técnico de la arquitectura Procesos de extracción, transformación y carga Selección e instalación de productos CARACTERÍSTICAS DE aplicaciones para usuarios finales Mantenimiento y crecimiento de un data warehouse...39 IV. DESARROLLO DEL PROCESO DE CONSTRUCCIÓN DEL DATAMART PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO OBJETIVO DEL PROYECTO DEFINICIÓN DEL PROYECTO ALCANCE DEL PROYECTO JUSTIFICACIÓN DEL PROYECTO EN EL NEGOCIO ANÁLISIS DE REQUERIMIENTOS Levantamiento de requerimientos...44 v

6 5.2 Documentación de requerimientos Ver ventas por productos Ver ventas por cliente Ver ventas por tiempos Ver ventas de productos por cliente Ver ventas por productos en el tiempo Ver ventas por cliente en el tiempo Ver ventas por cliente y producto en el tiempo Ver ventas por ciudad Ver ventas por productos en ciudades Ver ventas por ciudad en el tiempo MODELAMIENTO DIMENSIONAL EL DATAMART DEFINICIÓN DE LA GRANULARIDAD DIMENSIONES Dimensión línea Dimensión producto Dimensión cliente Dimensión sector Dimensión geografía Dimensión tiempo TABLA DE HECHOS DISEÑO DEL MODELO DIMENSIONAL DISEÑO TECNICO DE LA ARQUITECTURA DATOS Mapeo de los datos en el modelo dimensional BACK ROOM FRONT ROOM INFRAESTRUCTURA DE DATA WAREHOUSE PROCESO DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA HERRAMIENTA DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA ETL de dimensión sector ETL de dimensión línea ETL de dimensión geografía ETL de dimensión producto ETL de dimensión cliente ETL tabla de hechos CONSTRUCCIÓN DEL CUBO ARCHVIVOS JSP ESTRUCTURAS XML Estructura del cubo Estructura de la dimensión Segmento Estructura de la dimensión Ciudad Estructura de la dimensión Producto Estructura de la dimensión tiempo REPORTES IMPLEMENTADOS...67 vi

7 10.1 VENTAS POR PRODUCTOS VENTAS POR CLIENTE VENTAS POR TIEMPOS VENTAS DE PRODUCTOS POR CLIENTE VENTAS POR PRODUCTOS EN EL TIEMPO VENTAS POR CLIENTE EN EL TIEMPO VENTAS POR CLIENTE Y PRODUCTO EN EL TIEMPO VENTAS POR CIUDAD VENTAS POR PRODUCTOS EN CIUDADES VENTAS POR CIUDAD EN EL TIEMPO MANTENIMIENTO Y CRECIMIENTO DEL DATAMART...78 CONCLUSIONES...79 RECOMENDACIONES...81 GLOSARIO...82 BIBLIOGRAFÍA...83 vii

8 INTRODUCCIÓN Empresas de diferentes sectores buscan incrementar su productividad y ventajas competitivas proporcionándole a la gerencia información analítica y estratégica para el negocio. Esto se logra al aprovechar la información que a diario es almacenada en sus bases de datos operativas. Al intentar utilizar esta información de las bases de datos operativas para tomar decisiones, se presentan varios problemas: existe demasiada información, muy genérica de la cual no se pueden sacar conclusiones. La información muchas veces es irrelevante para el área interesada en mejorar sus decisiones, y la organización termina por desaprovechar todos estos datos, perdiendo un proceso de aprendizaje de sus propios logros e información. Por lo tanto, se plantea realizar una unión entre el mundo de los datos y el de los negocios, por medio de la inteligencia de negocios con una solución basada en data warehousing (bodega de datos). Esta solución permite utilizar los datos operativos de una empresa para producir información relevante y que soporte la toma de decisiones empresariales. Para el proyecto de data warehousing se toman como fuente los sistemas de información que tenga la empresa, pueden ser varios y en diferentes formatos, como bases de datos o archivos de texto. Luego de extraer los datos relevantes, son transformados de ser necesario y son cargados a una nueva base de datos, diseñada para soportar la inteligencia de negocios, que luego será analizada tridimensionalmente con análisis OLAP. Mediante este proceso se producirá información relevante para los ejecutivos de una empresa. Preguntas como: Se va a lograr una cuota de ventas en un trimestre determinado?, En cuál ciudad tiene mayor potencial determinado producto?, Qué tal se está vendiendo un producto con respecto a períodos de tiempo anteriores?, Cual es el producto más rentable en determinada ciudad? Cuáles son mis mejores clientes? y por lo tanto, sus decisiones correspondientes se toman a diario en una empresa, basándose en muchas ocasiones en intuiciones o suposiciones. Mediante el tipo de análisis proporcionado en este proyecto, estas preguntas serán resueltas con base en hechos y cifras rescatadas de las fuentes de datos operativas de la organización. Grandes empresas como EPM, Telmex e IBM han utilizado la inteligencia de negocios para estos propósitos, permitiéndoles conocer mejor a sus clientes, sus productos, ventas, costos y otros factores determinantes en sus negocios. Las pymes han estado ajenas a estas tecnologías por el alto costo que una solución de inteligencia de negocios como lo es el Data warehouse implica. Es por esto que el proyecto plantea el desarrollo 1

9 de una solución de data warehouse para una pyme, utilizando herramientas de código abierto para cada etapa de un desarrollo de este tipo. Al poner a disposición de las pymes la inteligencia de negocios, se incrementará la competitividad de estas frente al mercado y les dará la misma capacidad de inteligencia y análisis que disponen sus grandes competidoras. Al abordar este documento, se expone un conocimiento teórico del proceso de data warehousing, describiendo su definición y procesos necesarios para realizarlo. Luego se da a conocer la metodología utilizada para el desarrollo del proyecto, establecida por Ralph Kimball, quien es considerado el padre y autoridad en el mundo del data warehouse. Más adelante se exponen los elementos más importantes de las herramientas libres utilizadas para la solución, para después entrar a detallar los procesos realizados en el proyecto, desde la planeación del proyecto hasta su implantación. Finalmente se exponen las conclusiones y recomendaciones que ha dejado el proyecto para dar claridad a los conceptos desarrollados y servir de base a futuros desarrollos de la misma área. 2

10 I MARCO TEÓRICO 1. DATA WAREHOUSE El Data Warehouse es un conjunto de procesos y acciones que involucra un almacenamiento de datos no volátil, orientado a un tema, integrado e histórico para el soporte al proceso de toma de decisiones de la gerencia. Es una técnica para consolidar y administrar datos de diversas fuentes con el propósito de responder preguntas de negocios y tomar decisiones (Ver figura 1). Está constituido por la correcta organización e interrelación de los desarrollos tecnológicos consistentes en: consolidar datos desde una variedad de fuentes; manejar grandes volúmenes de datos de una forma que no era posible, acceder a los datos de una forma más directa, en "el lenguaje del negocio", y analizarlos para obtener relaciones complejas entre los mismos. Figura 1. Necesidad de información que soporte decisiones del negocio. 1 1 [4] Fundamentals of Data Warehouse and Business Intelligence for Knowledge Management. 3

11 Un sistema Data warehouse define un nuevo concepto para el almacenamiento de datos, integra la información generada en todos los ámbitos de una actividad de negocio (ventas, producción, finanzas, Marketing, etc.) que proviene de diferentes fuentes, formatos y tipos en un único depósito y permite un acceso y explotación de la información contenida en las bases de datos, facilitando un amplio abanico de posibilidades de análisis multivariables que permitirán la toma de decisiones estratégicas. 1.1 COMPONENTES DE UN DATA WAREHOUSE El Data Warehouse tiene varios componentes dentro de su arquitectura. Está conformado por: 1. El repositorio de datos o bodega de datos 2. Los procesos de: Extracción Transformación Carga Explotación 1.2 BODEGA DE DATOS Y DATAMARTS En 1992, Inmon define la bodega de datos como: " una colección de datos orientados a temas, integrados, no-volátiles y variante en el tiempo, organizados para soportar decisiones empresariales" 2. En 1993, Susan Osterfeldt publica una definición que sin duda es la clave de bodega de datos: "Yo considero la bodega de datos como algo que provee dos beneficios empresariales reales: Integración y Acceso de datos. La bodega de datos elimina una gran cantidad de datos inútiles y no deseados, como acierta también el procesamiento desde el ambiente operacional clásico". El datamart se ajusta a la definición de una bodega de datos, con la diferencia que su enfoque es servir a un área específica del negocio. Los procesos y fuentes de datos necesarios para construir un datamart son iguales que en el caso de la bodega, pero la información almacenada en el datamart proporcionará información específica, como información de ventas, o de producción. De todas formas no se puede considerar a un datamart como una pequeña bodega, pues un datamart puede ser más complejo y contener mayor volumen de datos que toda una bodega, dependiendo del negocio y los requerimientos de cada caso. 2 [11] Building the Data Warehouse. 4

12 Figura 2. Datamart, proporciona información a un área específica de la organización Es así que la bodega de datos y el datamart son un repositorio centralizado que contiene datos de una o diversas fuentes y que está específicamente diseñado para permitir consultas y análisis detallado de los datos. En el caso del datamart, este análisis tiene un enfoque determinado a áreas específicas del negocio Características de la bodega de datos La bodega de datos se caracteriza por ser: Temático: La bodega de datos está orientada a los principales temas o entidades de la organización lo cual está en contraste con la mayoría de los sistemas de hoy en día cuya orientación se basa en los procesos o funciones. De acuerdo con esta característica, la bodega de datos para una empresa de ventas se enfocaría en proveedores, clientes, productos, mientras que un subsistema típico lo haría en proceso de compras, de ventas, de inventario. Integrada: Los datos almacenados deben integrarse en una estructura consistente. Esto se refleja en consistencia de nomenclaturas, de variables y medidas, de estructuras y códigos, de atributos de datos afines, etc. Histórico: El tiempo es parte implícita de la información contenida en una bodega de datos. A diferencia de los sistemas transaccionales, que mantienen los datos actualizados a un instante determinado en el tiempo, una bodega de datos puede mantener información de más de un instante. La bodega se carga con los distintos valores que toma una variable en el tiempo y de esta manera los datos pueden ser analizados y comparados, facilitando las labores gerenciales. No volátil: La información de la bodega de datos existe para ser leída y no modificada, por lo tanto, se carga una sola vez y permanece igual en adelante. De esta manera la actualización de la bodega de datos es la incorporación de los últimos valores que tomaron las distintas variables, sin ningún tipo de acción sobre lo que ya existía. Esto 5

13 está en contraste con la información de un sistema transaccional que está sujeta a permanentes inserciones, actualizaciones, reemplazos o borrados. 1.3 PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA DE LOS DATOS Para obtener la bodega de datos se desarrollan en forma secuencial la extracción de los datos, su transformación y finalmente su carga en la bodega. El proceso de extracción consiste en la obtención de la información desde las distintas fuentes (bases de datos y archivos operacionales) tanto internas como externas mediante herramientas de gestión de datos. Figura 3. Procesos de extracción, transformación o elaboración y carga. 3 A continuación es necesario transformar los datos en los requeridos para el depósito. El proceso consiste en filtrado, limpieza, depuración, homogeneización e integración de la información. Esto debe hacerse, ya que las bases de datos operacionales, diseñadas para el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato, entonces, pueden tenerse los mismos elementos de datos, pero nombres y formatos y codificaciones incoherentes. Todas estas inconsistencias deben resolverse antes de realizar el último paso de este proceso que corresponde a la carga de los datos en la bodega. 1.4 EXPLOTACIÓN Es importante recordar que la Bodega de Datos no es un fin en sí misma, sino que es un medio para solucionar una necesidad: el análisis de información y la toma de decisiones a través de los datos de la empresa, objetivo que se logra con el proceso de explotación de la bodega de datos. En esta etapa es donde se desarrolla la inteligencia del Negocio y por lo tanto es un componente esencial del data warehouse, ya que es el punto de contacto directo con el usuario final, quien es el encargado de tomar decisiones o acciones que redundan en beneficio de la compañía y en el ROI (Retorno de la Inversión) del Data Warehouse. 3 [12] Diseño de un prototipo de bodega de datos para un modelo de empresa de ventas y aplicación de herramientas OLAP. 6

14 Las herramientas utilizadas para el desarrollo de inteligencia del negocio pueden incluir software de consultas, generadores de reportes, procesamiento analítico en línea, herramientas de minería de datos, etc., dependiendo de los tipos de usuarios y sus requerimientos particulares. Sin embargo, se hace necesaria la integración de varias herramientas puesto que una sola no satisface todos los requerimientos. Los niveles de aplicaciones típicas en esta etapa son: Consultas e Informes, Olap, minería de datos, Sistemas de Información Ejecutiva, y Visualización geográfica Análisis OLAP OLAP, (On-Line Analytical Processing). El Procesamiento Analítico en Línea es la técnica que permite ver y manipular los datos por dimensiones, proveyendo a los gerentes y analistas fácil acceso a la información con el fin de soportar el proceso de toma de decisión. En esta técnica de análisis, en lugar de ejecutar múltiples consultas, los datos son estructurados para permitir un acceso rápido y fácil a las respuestas de las preguntas que son típicamente formuladas. De esta manera, Olap, brinda flexibilidad en la visualización de la información. Las herramientas OLAP pueden soportar requerimientos complejos de análisis, analizar datos desde diferentes perspectivas y soportar análisis complejos contra un volumen determinado de datos. Su objetivo fundamental es proveer al usuario final el fácil análisis de los datos, con la potencia y confiabilidad de una base de datos corporativa, y con la posibilidad de ver los datos desde diversos puntos de vista o dimensiones. Permite vistas reformateadas y calculadas sin el riesgo de perder o corromper los datos originales y hace que la información pueda ser compartida por varios usuarios sin tener que duplicar archivos. En muchos casos los usuarios pueden adicionar o cambiar datos sin el riesgo de sobrescribir la información original. El uso más común de estas herramientas en una empresa se da en el análisis de ventas y compras de materia prima. Gracias a este análisis se evalúa la rentabilidad de productos, capacidad de producción o la demanda. Estos aspectos dependen directamente de los requerimientos del negocio específicos para cada empresa. Las herramientas OLAP están dirigidas principalmente a los usuarios finales por lo que requieren de una interfaz simple y deben tener una buena integración con los sistemas que las alimentan Conceptos y componentes 1. Cubo 7

15 OLAP efectúa el almacenamiento lógico de los datos en arreglos ó matrices multidimensionales denominadas cubos. El cubo contiene los datos que son de interés para los usuarios; organiza la información dentro de dimensiones y medidas en una estructura multidimensional para soportar las preguntas que tienen los usuarios acerca de los datos de su compañía. Además proporcionan un mecanismo para la consulta de datos con rapidez y con una respuesta uniforme ante diferentes cantidades de datos que contenga el cubo o por la complejidad de una consulta. Figura 4. Cubo tridimensional: Geografía, producto, tiempo. 4 Un cubo se compone de dimensiones, jerarquías (niveles) y medidas. En el ejemplo de la figura 4 se tiene un cubo con tres dimensiones: Geografía, Producto y Ciudad. Además se tienen tres medidas: Unidades, Valor venta y Costo. En la celda de la parte inferior derecha de la imagen se muestran los datos para una posible pregunta gerencial: Cuántas unidades, a qué valor y con qué costo se vendieron pantalones en la ciudad de Cali en el tiempo T4? Con su respectiva información. 2. Medida La medida es el valor que toma determinada variable que se está analizando. Las medidas son resultados cuantificables, o indicadores clave de desempeño usados para determinar el éxito de una operación de negocios. Orientan las respuestas a preguntas relacionadas con cuestiones numéricas como la cantidad, valor o costo. 4 [13] Business Intelligence 8

16 En el caso de la figura 4 se tienen tres medidas, indicando que se vendieron 1930 unidades, a un valor de venta de 6745 y con costo de Un cubo puede contener una o varias medidas, dependiendo del diseño y los requerimientos. Existen dos tipos de medidas: Medida regular: toma su dato directamente de una fuente disponible. Es un compendio de información que ya se tiene, tal como el número de unidades vendidas, ingresos, gastos, niveles de inventario. Medida calculada: obtiene como resultado un nuevo dato numérico para medidas que no están en una fuente directa disponible. Es derivada de otras medidas. Ejemplos de este tipo de medidas son: ganancia (ingresos costos), margen de ganancia (ingreso costo /ingreso), tiempo promedio de espera ( fecha de entrega fecha de la orden), etc. 3. Dimensión Los atributos de tipo texto que describen cosas son organizados en dimensiones. Es necesario establecer un criterio puramente de diseño y basado en los requerimientos del negocio para establecer los atributos que se incluyen como dimensiones y los que se pueden descartar al realizar la bodega de datos. 4. Nivel Las dimensiones están construidas por niveles. Estos niveles representan la jerarquía establecida por las estructuras organizacionales y modelos de datos que la organización usa. Cada nivel inferior provee cada vez datos más detallados que relaciona a la dimensión. Las herramientas especializadas para análisis OLAP permiten fijar este nivel de granularidad en forma dinámica mientras el usuario final navega por su reporte. La dimensión tiempo provee un claro ejemplo del uso de niveles. Se tiene el año en un nivel superior, luego le siguen el semestre, trimestre, mes y por último en el nivel más inferior se encuentra el día Operaciones con OLAP La información que se analiza con OLAP debe estar estructurada de tal forma que se puedan realizar las siguientes operaciones: Drill Down y Roll Up (profundizar y escalar): Estas dos operaciones permiten visualizar la información a un nivel detalle distinto del actual. Drill Down permite ver un nivel mayor de detalle, es decir de lo general se va a lo particular. Roll Up permite al usuario desplazarse entre los niveles superiores para obtener información agregada, ver acumulados y sumarizaciones. Alterar las filas por columnas (permutar dos dimensiones de análisis). Rotar (Swap). Obtener interactivamente respuestas desde diferentes perspectivas. Realizar consultas que requieren combinación de diferentes fuentes contenidas en el data warehouse. 9

17 Efectuar cálculos relativamente complejos (ranking, porcentajes, sumas, etc.) Slice and Dice (Cortar y Rotar): Estas dos operaciones permiten navegar a través de un cubo visualizado. La operación Slice corta el cubo para que el usuario pueda enfocarse solamente en algunas perspectivas. La operación Dice hace que el cubo rote para poder apreciar la información desde otra perspectiva. Por ejemplo si se tiene un reporte que muestra el número de productos vendidos por cada sucursal al final del último trimestre, se puede cortar y rotar la información para mostrar los ingresos sobre los últimos dos meses por cada línea de producto. 10

18 II. HERRAMIENTAS DE DATA WAREHOUSE En el proyecto desarrollado están involucradas varias herramientas desarrolladas por terceros, todas ellas de libre distribución. Se cuenta con herramientas de base de datos y un servidor OLAP utilizados en el proyecto. 2. HERRAMIENTAS DE BASES DE DATOS Y OLAP 2.1 MOTOR DE BASES DE DATOS MYSQL MySQL es el servidor de bases de datos relacionales libre más popular, desarrollado y proporcionado por la compañía Sueca MySQL AB, que mantiene el copyright del código fuente del servidor SQL, así como también de la marca. MySQL AB es una empresa cuyo negocio consiste en proporcionar servicios en torno al servidor de bases de datos MySQL. Una de las razones para el rápido crecimiento de popularidad de MySQL, es que se trata de un producto Open Source, y por lo tanto, va de la mano con este movimiento. MySQL es un sistema de gestión de bases de datos relacional, licenciado bajo la GPL de la GNU. Su diseño multihilo le permite soportar una gran carga de forma muy eficiente. MySQL AB distribuye una versión comercial de MySQL, que no se diferencia de la versión libre más que en el soporte técnico que se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de no ser así, se vulneraría la licencia GPL. Este gestor de bases de datos es, probablemente, el gestor más usado en el mundo del software libre, debido a su gran rapidez y facilidad de uso. Esta gran aceptación es debida, en parte, a que existen infinidad de librerías y otras herramientas que permiten su uso a través de gran cantidad de lenguajes de programación, además de su fácil instalación y configuración. MySQL es una herramienta Open Source. Es posible descargar el software de MySQL de Internet y usarlo sin pagar por ello. Inclusive, es posible estudiar el código fuente y cambiarlo de acuerdo a cualquier necesidad. MySQL usa la licencia GPL (Licencia Pública General GNU), para definir qué es lo que se puede y no se puede hacer con el software para diferentes situaciones. Sin embargo, 11

19 si se quiere tener otra licencia para incorporar código de MySQL en una aplicación comercial, es posible comprar una versión de MySQL con una licencia comercial. 2.2 MOTOR DE BASES DE DATOS POSTGRESQL PostgreSQL es un sistema de gestión de bases de datos objeto-relacional (ORDBMS) basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este proyecto es el profesor Michael Stonebraker, y fue patrocinado por Defense Advanced Research Projects Agency (DARPA), el Army Research Office (ARO), el National Science Foundation (NSF), y ESL, Inc. PostgreSQL se coloca en la categoría de las bases de datos conocidas como objetorelacionales. Ha generado algunas características que son propias del mundo de las bases de datos orientadas a objetos. Esto ha llevado a que algunas bases de datos comerciales hayan incorporado recientemente estas ventajas en las que PostgreSQL fue pionera. Tomando en cuenta esas características y sumando la estabilidad, rendimiento, disponibilidad y la eficiencia de un sistema operativo como Linux sobre el cual comúnmente es instalada, muchas empresas e instituciones la están adoptando como servidor de bases de datos. PostGreSQL es un sistema objeto-relacional, ya que incluye características de la orientación a objetos, como puede ser la herencia, tipos de datos, funciones, restricciones, disparadores, reglas e integridad transaccional. A pesar de esto, PostGreSQL no es un sistema de gestión de bases de datos puramente orientado a objetos Arquitectura de la herramienta PostgreSQL utiliza un modelo cliente/servidor. Una sesión de PostgreSQL consiste de los siguientes procesos: Proceso Servidor. Administra los archivos de las base de datos, acepta conexiones a las bases de datos de aplicaciones clientes y realiza acciones sobre las bases de datos por solicitud de los clientes. Aplicaciones cliente. Permiten realizar operaciones sobre las bases de datos. Existen diversos tipos de aplicaciones cliente: un cliente puede ser una herramienta basada en texto, una herramienta gráfica, un servidor web que accede a la base de datos para sus páginas web, o herramientas de administración de las bases de datos. El servidor y clientes pueden estar ejecutándose en diferentes equipos, por lo tanto PostgreSQL permite la comunicación entre estos procesos a través de conexiones TCP/IP. 12

20 El servidor soporte múltiples conexiones concurrentes de clientes. Para este propósito ejecuta nuevos procesos (forks) para cada conexión. Este proceso es transparente para los usuarios. 2.3 HERRAMIENTA DE OLAP JPIVOT MONDRIAN Mondrian es el primer servidor OLAP de código abierto con la calidad necesaria para entrar en producción. Su primera versión suficientemente madura fue Mondrian 1.0, que fue distribuida en agosto de 2003 luego dos años de desarrollo. Esta versión contiene mejoras en las conexiones JDBC con bases de datos, incorporación de nuevas características y arreglo de buggs que se presentaban en las versiones Beta anteriores. Mondrian es un servidor OLAP escrito en Java. Permite analizar grandes cantidades de registros almacenados en bases de datos SQL. JPivot es una librería JSP que permite realizar navegación OLAP utilizando como servidor a Mondrian Arquitectura de la herramienta El sistema de Mondrian esta compuesto por cuatro capas muy bien definidas: la capa de presentación, la capa de cálculo, la capa de agregación, y la capa de almacenaje. Capa de presentación Determina lo que ve el usuario final en su pantalla, y cómo él puede interactuar con la herramienta para hacerle consultas. Hay varias formas de presentar los resultados multidimensionales. Es posible mostrarlos con tablas, graficas de líneas, barras o pies; además de con herramientas avanzadas de visualización como mapas y graficas dinámicas. Estas pueden estar escritas en Swing o en graficas en formato JPEG o GIF o trasmitidas o un aplicación remota vía XML. Capa de cálculo La capa de cálculo analiza, valida y ejecuta consultas en el lenguaje MDX (Ver sección 2.3.4). Una consulta es evaluada en múltiples fases. Los ejes se evalúan primero, luego los valores de las celdas relacionados con los ejes. Por eficiencia, la capa de cálculo va enviando las repuestas ya procesadas a la capa de agregación en paquetes para que esta comience a realizar su trabajo. La transformación de consultas permite a la aplicación manipular los queries existentes en vez de construir una declaración de MDX desde el principio por cada solicitud. La metadata describe el modelo dimensional y su mapeo con el modelo relacional. Capa de agregación Una agregación es un conjunto de valores en memoria (celdas) agrupadas por columnas dependiendo de valores de las dimensiones. La capa de cálculo envía 13

21 solicitudes a conjuntos de celdas. Si las celdas solicitadas no están en cache, el administrador de agregación envía la solicitud a la capa de almacenamiento. Capa del almacenamiento Es una capa RDBMS, es responsable de proveer agregaciones de datos y atributos de tablas de dimensión. Estas capas pueden estar en la misma máquina o distribuidas en diferentes máquinas. Sin embargo, las capas de cálculo y agregación deben estar en la misma máquina, porque comprometen al servidor. La capa de almacenamiento puede estar en otra máquina siendo accedida por una conexión JDBC Estrategias de almacenamiento y agregación Los servidores OLAP son categorizados de acuerdo al almacenamiento de los datos: - El servidor MOLAP (MOLAP multidimensional) almacena todos los datos en el disco utilizando estructuras óptimas para acceso multidimensional. Normalmente los datos son almacenados en arreglos densos requiriendo de 4 a 8 bytes por celda. - El servidor ROLAP (OLAP relacional) almacena los datos en DB relacionales. Cada fila de la tabla de hechos tiene una columna para cada dimensión y medida. Se requiere almacenar 3 tipos de datos: datos de la tabla de hechos (registros transaccionales), agregaciones y dimensiones. Las bases de datos MOLAP almacenan hechos en la tabla de hechos en formato multidimensional pero si hay varias dimensiones los datos serán dispersos y el formato multidimensional no tendrá un buen rendimiento. Un sistema HOLAP (OLAP hibrido) resuelve este problema almacenando los datos de mayor granularidad en bases de datos relacionales, y almacena las agregaciones en formato multidimensional. Es necesario realizar agregaciones precalculadas cuando hay muchos registros para no tener que leer todo el contenido de una tabla de hechos en ciertos queries. Comúnmente las agregaciones MOLAP son una imagen de las estructuras de datos de memoria divididas por páginas y almacenadas en el disco. Las agregaciones ROLAP son almacenadas en tablas. 14

22 El último componente de las estrategias de agregaciones es el cache. Este almacena en memoria agregaciones precalculadas para que futuros queries puedan acceder a valores de celdas sin tener que leerlos del disco. El cache es la parte más importante de la estrategia de agregación gracias a su adaptabilidad. Es difícil escoger el conjunto de agregaciones para precalcular, las cuales aumentan la velocidad del sistema a costo de alto espacio en disco, y en sistemas donde los datos cambian continuamente en el tiempo no es práctico mantener agregaciones precalculadas. Un tamaño de cache razonable permite al sistema desempeñarse adecuadamente en caso de queries no predecibles con pocas agregaciones precalculadas. La estrategia de agregación de Mondrian es la siguiente: - Los datos de la tabla de hechos son almacenados en RDBMS. Porqué desarrollar una estrategia de almacenamiento si RDBMS ya tiene una? - Lectura de datos de agregación en cache al utilizar queries en grupo. - Si el RDBMS soporta vistas materializadas y el administrador de la base de datos elige crear vistas materializadas para agregaciones en particular, Mondrian las utilizará implícitamente. El administrador de agregaciones de mondrian tendrá en cuenta que estas vistas materializadas existen y por lo tanto que estas agregaciones son fáciles de calcular API Mondrian provee un API para que las aplicaciones cliente ejecuten queries. El lenguaje que usa Mondrian para los queries es MDX (Multidimensional Expression) donde JDBC utiliza SQL. El API también presenta el esquema de base de datos como un conjunto de objetos: Esquema, cubo, dimensión, jerarquía, nivel, miembro. Para cumplir con nuevos estándares se están agregando dos APIs a Mondrian: JOLAP es un estándar del proceso JSR y será parte de J2EE. XML for analysis, es un estándar para acceder a servidores OLAP vía SOAP( Simple Object Access Protocol ). Esto permite que componentes que no están basados en java como Microsoft Excel ejecuten quieries con Mondrian MDX 15

23 MDX es un lenguaje para realizar queries en bases de datos multidimensionales, de la misma forma análoga al SQL en bases de datos relacionales. Inicialmente fue definido como parte de la especificación de OLAP OLE DB, y un lenguaje similar, mdxml, es parte de la especificación XML for Analysis. Para conocer más detalles del lenguaje MDX ver anexo Manual de Administrador Esquema Mondrian Un esquema define una base de datos multidimensional. Contiene un modelo lógico, que consiste de cubos, jerarquías, atributos y un mapeo de este modelo a un modelo físico. El modelo lógico se compone de los constructores usados para escribir queries en lenguaje MDX: cubos, dimensiones, jerarquías, niveles y atributos. El modelo físico es la fuente de los datos que es representado por el modelo lógico. Típicamente es un modelo en estrella, que es un conjunto de tablas en una base de datos relacional. Los esquemas de Mondrian son representados en un archivo XML. Actualmente la única forma de crear este esquema es haciéndolo en un editor de texto, la sintaxis de XML no es muy complicada y se está desarrollando un editor gráfico para crear y modificar los esquemas Modelo lógico Los componentes más importantes de un esquema son los cubos, medidas y dimensiones: Un cubo es una colección de dimensiones y medidas de un área en particular. Una medida es una cantidad que se quiere medir, por ejemplo unidades vendidas de un producto, o costos de inventario. Una dimensión es un atributo, o conjunto de atributos en los cuales se pueden dividir medidas en subcategorías. Por ejemplo, es posible dividir las ventas de productos por sus colores, el género del cliente y la sucursal en donde es hecha la venta. Color, género 16

24 y tienda son dimensiones. 17

25 III. METODOLOGIA PARA EL DESARROLLO DE UN DATA WAREHOUSE 3. METODOLOGIA DE RALPH KIMBALL PARA UN PROYECTO DE DATA WAREHOUSE La metodología para el desarrollo del proyecto será la establecida por Ralph Kimball, quien es autoridad en el campo de las bodegas de datos y considerado como uno de los padres de este concepto. Kimball se ha dedicado al desarrollo de su metodología para que este concepto sea correctamente aplicado en las organizaciones, y se asegure la calidad de este tipo de proyectos. Durante su carrera ha innovado, escrito libros, educado y ha sido consultor en el campo de las bodegas de datos 5. Kimball ha establecido ciertos procesos para llevar al éxito un proyecto de data warehouse. Para su desarrollo se incluyen varias tareas que pueden ser realizadas en paralelo o en forma secuencial. El correcto desarrollo de cada una de las fases planteadas en esta metodología garantiza la calidad y el correcto proceso de desarrollo. 3.1 PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO Definición del proyecto Existen varios escenarios posibles en los que surge un proyecto de bodega de datos para une empresa. Es importante identificar el escenario para determinar el alcance y definición del proyecto. Los escenarios, originados por una demanda del proyecto en una empresa son los siguientes: Demanda de un sector del negocio: En este escenario, un ejecutivo del negocio tiene el propósito de obtener mejor información con un mejor acceso para tomar mejores decisiones. Demasiada demanda de información: En este escenario, existen múltiples ejecutivos del negocio buscando mejor información. En busca de demanda. En este escenario usualmente está involucrado el presidente de una empresa, quien no identifica necesidades de una bodega de 5 [14] About Kimball Group 18

26 datos para su negocio pero desea incorporar este sistema por razones diferentes a requerimientos o necesidades del negocio. Al identificar el escenario, es posible determinar si existe demanda para el proyecto y de donde proviene esta demanda. El primer caso es el ideal, pues se tienen objetivos claros y con un alcance determinado de lo que se quiere del proyecto. El segundo escenario es riesgoso, pues para implementar una bodega de datos que soporte varios requerimientos de diferentes áreas de la empresa, se necesita mucho tiempo, dinero y soporte interno de la organización que perdure a largo plazo. En el tercer escenario se deben buscar los requerimientos que puede implementar la solución y basar en ellos el proyecto. En todos los escenarios es determinante contar con sponsors o patrocinadores internos del proyecto para lograr el éxito. Sino se cuenta con un patrocinador interno de la empresa involucrado en la demanda es preferible posponer el proyecto. Luego de identificar el escenario es importante conocer si la empresa está lista para realizar este proyecto. Determinar la preparación de la empresa para un proyecto de bodega de datos De acuerdo a Ralph Kimball existen cinco factores que deben existir en una organización para iniciar un proyecto de bodega de datos. Patrocinio de la gerencia del negocio: Al contar con este patrocinio se tiene una visión del impacto que tendrá la bodega de datos en la empresa. Los gerentes son líderes influyentes dentro de la organización y determinarán el apoyo y soporte al proyecto de los de más miembros de la organización. Es preferible tener varios patrocinadores que uno solo, en caso de cambios en la organización o necesidad un apoyo más fuerte. Motivación del negocio: Al implementar una bodega de datos se busca encontrar un sentido de emergencia por parte de la organización, causado por una motivación del negocio. Un ejemplo de motivadores son la competencia y la visión competitiva. Otras organizaciones han encontrado el motivador en una crisis. Un motivador importante también es un mercado potencial. Lo importante para un proyecto de bodega de datos es alinearse con uno de estos motivadores estratégicos del negocio. Acompañamiento del departamento de tecnología y de negocio: El éxito de un proyecto de bodega de datos se produce gracias a un esfuerzo de las áreas de tecnología y de negocio, compartiendo responsabilidades. Presencia de cultura analítica: Es importante que las decisiones de la organización se basen en hechos, más que en simples intuiciones. Y que estas decisiones sean determinantes y recompensadas. Factibilidad: Es preferible que la infraestructura que soporte la bodega de datos esté presente y sea robusta. La primera factibilidad debe ser la de los datos. Si estos se encuentran sucios o no cumplen con estándares, el proyecto tendrá retrasos respecto al cronograma planeado. Desarrollo del enfoque preliminar 19

27 Luego de haber determinado la preparación de la organización para el proyecto, se debe centrar el proyecto en su enfoque, y justificarlo para recibir el apoyo y presupuesto de desarrollo. Para determinar el enfoque, se deben responder preguntas como: Se busca el enfoque y presupuesto para cubrir el levantamiento de requerimientos y diseño? O para una primera versión de la bodega? O para el proyecto completo? Para definir este enfoque la base debe ser los requerimientos del negocio, no un cronograma. Para la definición del enfoque es importante seguir los siguientes parámetros: La definición del enfoque es responsabilidad del departamento de tecnología y de negocio: El enfoque usualmente se establece para desarrollar requerimientos específicos del negocio, en un tiempo determinado. El enfoque inicial del proyecto debe ser factible y manejable: Es preferible empezar pequeño. Luego continuar el proceso de forma iterativa. Lanzando pequeños y rápidos desarrollos del proyecto. Enfoque inicial en un solo requerimiento del negocio soportado por una sola fuente de datos. Limitar el número de usuarios que tendrán acceso a la bodega de datos inicialmente. Establecer criterios de éxito del proyecto mientras se define el enfoque: Se refiere a entender lo que la gerencia espera del proyecto. Una vez el área de tecnología y negocios han acordado un enfoque, este se debe documentar. Desarrollar la justificación del negocio Luego de haber definido el enfoque, la justificación debe ser establecida. Esto significa que se identifican anticipadamente los costos y beneficios asociados al proyecto. Una forma de hacer esto es con el factor retorno de la inversión (ROI), que consiste en comparar el retorno financiero esperado (beneficios del negocio) contra la inversión esperada (costos). Se deben considerar las siguientes inversiones y costos: Compras de licencias de software y hardware. Costos de mantenimiento: muchos productos de hardware y software requieren mantenimiento. Recursos internos de desarrollo. Recursos externos requeridos. Capacitación para desarrolladores y usuarios. Soporte a usuarios. Costos de crecimiento: Por cambios en requerimientos y actualizaciones. Se deben considerar los siguientes retornos y beneficios: 20

28 Los proyectos de bodegas de datos típicamente tienen un impacto en el incremento de ingresos y ganancias, más que en reducción de costos. Incremento de ingresos por nuevas ventas a nuevos y antiguos clientes. Incremento de ganancias por aumento de respuestas a la publicidad. Incremento de niveles de servicio al cliente. Descubrimiento de nuevas oportunidades. Planeación del proyecto El proyecto de bodega de datos debe tener un nombre. Luego, se identifican roles que pueden ser cubiertos por uno o varios integrantes del equipo y cada miembro del equipo también puede desempeñar varios roles, dependiendo de los requerimientos y del tamaño del proyecto. Los siguientes roles se identifican para el proyecto: Patrocinadores de negocio. Gerente del proyecto: Responsable de la gerencia de tareas y actividades cotidianas. Líder de negocios del proyecto: Con el gerente del proyecto monitorea el proyecto y lo comunica a la organización. Tiene un alto entendimiento de los requerimientos del negocio. Analista del sistema de negocios: Lidera las actividades de definición de requerimientos. Modelador de datos: responsable del análisis de datos y el modelo dimensional. Administrador de bases de datos de la bodega (DBA): Responsable de determinar agregaciones, particiones y soporte a la base de datos. Diseñador de proceso ETL: Responsable del diseño de la extracción, transformación y carga de la bodega. Desarrolladores de aplicación al usuario. Educador de la bodega de datos. Desarrollo del plan del proyecto El objetivo de la planeación es proveer el detalle suficiente para hacer seguimiento al progreso del proyecto. Se identifican actividades, recursos y tiempos para el desarrollo. También permite monitorear los procesos y tener un plan de riesgos. Administración del proyecto Se consideran las reuniones de equipo, monitoreo del estatus, el enfoque y estrategias de comunicación. Para las reuniones se debe seguir una agenda y mantener un ambiente de comunicación entre el equipo. El monitoreo se debe realizar periódicamente, analizando el estado del proyecto en diferentes estados del tiempo. 21

29 3.2 ANÁLISIS DE REQUERIMIENTOS Acercamiento a la definición de requerimientos Para entender mejor los requerimientos se debe empezar por hablar con los usuarios del negocio. No se debe preguntar a estos usuarios, qué datos quieren que aparezcan en el datamart, sino hablar con ellos sobre sus trabajos, objetivos y retos e intentar conocer cómo toman decisiones, actualmente y en el futuro. Se debe considerar lo que requiere el negocio comparando estos requerimientos con los datos disponibles en las bases de datos que servirán como fuente, para lograr el soporte de estos requerimientos. Preparación de la entrevista Se deben determinar roles y responsabilidades en el equipo entrevistador. Es preferible que el mismo equipo conduzca las entrevistas a usuarios del negocio y al equipo de tecnología de la empresa. Los roles que se deben manejar, comprenden a un líder, encargado de dirigir el cuestionario, debe tener habilidades en el conocimiento del negocio y comunicaciones. También debe existir un escribano encargado de tomar notas durante las entrevistas. Se debe tomar el mayor detalle posible del contenido. Al finalizar las entrevistas, esta persona debe hacer preguntas para aclarar dudas y obtener una retroalimentación de los entrevistados. Investigación previa a entrevistas. Antes de iniciar el proceso de levantamiento de requerimientos, se deben analizar los reportes anuales de la compañía, para determinar las decisiones y hechos estratégicos. También es útil obtener planes de negocios de la compañía. También se debe analizar la competencia de la compañía y sus principales fortalezas y debilidades. Si ha existido un intento anterior de desarrollar una bodega de datos de la compañía, este también se debe analizar. Selección de los entrevistados Se deben seleccionar personas representativas de cada área de la organización. Es importante observar el organigrama de la compañía para determinar los candidatos a entrevista. Los principales entrevistados deben ser los administradores ejecutivos del negocio, para comprender la estrategia en un alto nivel de la empresa. Luego es importante entrevistarse con los analistas del negocio de cada área quienes conocen el manejo de información que se lleva a cabo. Desarrollo del cuestionario El líder de la entrevista debe desarrollar el cuestionario antes de iniciar la entrevista. Se deben desarrollar varios cuestionarios que serán aplicados dependiendo del rol de los entrevistados dentro de la empresa. El cuestionario debe ser de una sola página, para evitar exceso de tiempo de entrevistas. 22

30 Es preferible iniciar las entrevistas en un nivel medio de jerarquía de la organización, en vez de iniciar desde la parte superior con las altas gerencias, pues en los mandos medios se maneja un mayor nivel de detalle respecto a los datos que sirven para luego definir la granularidad de la bodega. Es importante que durante la entrevista se especifique terminología, la definición exacta de esta tendrá un gran impacto en la granularidad y dimensionalidad del modelo. Es posible que una palabra signifique muchas cosas, por eso lo importante es identificarlas y documentar estas inconsistencias en el vocabulario para luego confrontarlas con los entrevistados. Inicio y desarrollo de la entrevista La entrevista debe iniciarse con una introducción, para recordar al usuario sobre el proyecto y el equipo desarrollador. Los objetivos del proyecto y de la entrevista deben ser nombrados y los miembros del equipo presentados. Para documentar información útil se debe preguntar a los usuarios sobre sus trabajos, por qué los hacen y cómo los hacen. Se deben realizar preguntas en un alto nivel y luego irse al detalle para obtener respuestas cada vez más específicas. Al entrevistar ejecutivos, el principal objetivo es obtener una visión y entender globalmente el negocio. Al entrevistar administradores y analistas de la empresa, se buscan los objetivos y visión de cada departamento. En el área de auditoria y administración de datos se busca saber si existen los datos para poder dar soporte a los requerimientos encontrados en las entrevistas previas. Se debe entender las definiciones de los campos de las bases de datos, granularidad, volúmenes de datos, y otros detalles de estas fuentes de información. Al cierre de las entrevistas se debe preguntar por los criterios de éxito del proyecto, de esta forma se entienden las actitudes y expectativas frente al proyecto. Estos criterios deben ser medibles y cuantificables. Análisis de las entrevistas Si algún miembro del equipo conoce los sistemas operativos fuente de la empresa, debe explicarlos al resto del equipo para determinar la factibilidad de implementar los requerimientos encontrados. Se deben resaltar los descubrimientos y requerimientos clave para el proyecto. Se deben analizar y repasar los reportes y análisis reunidos en las entrevistas, lo cual comúnmente conlleva a una aproximación del descubrimiento de dimensiones para el modelo. Para finalizar, es importante documentar los requerimientos obtenidos y comunicarlos a los usuarios para adquirir su aprobación y compromiso. 23

31 3.3 MODELAMIENTO DIMENSIONAL Modelo entidad relación El modelo entidad relación (ER) es una técnica poderosa para diseñar lógicamente sistemas para el procesamiento de transacciones OLTP (procesamiento transaccional en línea). Siempre va encaminado a la eliminación de la redundancia, lo que permite que la manipulación sobre la base de datos tenga que hacerse en un solo lugar y sea mucho más rápido ya que en el momento en que la transacción requiera insertar, adicionar, borrar o modificar un dato es necesario que lo haga en un solo lugar y no en múltiples. Esto contribuye también al almacenamiento de grandes cantidades de datos dentro de las bases de datos relacionales, a través del proceso de normalización. Por eso es perfecto para la inserción y actualización de la información. Este es un modelo excelente para registrar transacciones y administración de tareas operativas. Sin embargo, para el modelamiento de una bodega de datos presenta varios problemas. Los usuarios finales no entienden ni recuerdan un diagrama entidad relación. Nos es posible que los usuarios finales naveguen sobre el modelo. El uso del modelo entidad relación va en contra del objetivo principal de una bodega de datos, de proporcionar datos de forma intuitiva y con un buen desempeño y tiempos de respuesta. Modelo Dimensional El modelo dimensional es una técnica de diseño lógico que busca presentar los datos de una forma intuitiva y que proporcione acceso de alto desempeño. Cada modelo dimensional se compone de una tabla con múltiples llaves foráneas, llamada tabla de hechos (fact table), y un conjunto de tablas más pequeñas, llamadas tablas de dimensión. Los atributos de las tablas de dimensión son las fuentes de las restricciones de búsqueda necesarias para consultar una bodega de datos. Son utilizadas como título de atributo de las filas resultantes de queries de SQL. Existen dos modelos dimensionales que predominan en las soluciones de bodegas de datos: el modelo estrella y el modelo copo de nieve. En el modelo estrella, como se ve en la figura 5 se tiene una tabla de hechos y en ella llaves foráneas a cada una de las tablas de dimensión que tiene el modelo. Es decir, cada tabla dimensional está directamente relacionada a la tabla de hechos. 24

32 Figura 5. Modelo estrella Una dimensión es modelada de forma copo de nieve cuando los campos de baja cardinalidad de la dimensión han sido removidos a tablas separadas y unidas a la tabla original con llaves foráneas 6 (ver figura 6). En este modelo la tabla de hechos no tendrá llaves foráneas a todas las demás tablas como en el caso de la estrella. Las nuevas tablas no estarán conectadas con la tabla de hechos sino con las dimensionales establecidas. Figura 6. Modelo copo de nieve Generalmente el copo de nieve no es recomendado en ambientes de bodegas de datos. Este modelo será más complejo para los usuarios y la navegación por el modelo será más lenta. Diseño de dimensiones y hechos En el desarrollo de una bodega o un datamart comúnmente es necesario unir datamarts. Esto se logra creando una arquitectura de bus de datamarts. Como se utilizarán las mismas tablas de dimensiones, es importante que las tablas de dimensiones y hechos cumplan con las mismas especificaciones, como su granularidad. Estas dimensiones son llamadas dimensiones conformes (conformed dimensions). Se caracterizan por cumplir estas condiciones: 1. Una tabla de dimensión puede ser usada con cualquier tabla de hechos de la misma base de datos. 6 [1] The Data Warehouse Toolkit 25

33 2. Las interfaces de usuario y contenido de datos son consistentes para cualquier uso de la dimensión. 3. Hay una interpretación consistente de atributos, por lo tanto se obtiene la misma interpretación de la tabla en cualquier datamart. La granularidad es un factor que se debe tener en cuenta para el diseño de las tablas. Una bodega de datos debe mantener sus dimensiones basadas en datos con la mayor granularidad posible. De esta forma se facilita la expansibilidad de los datamarts para contener nuevos atributos, ya sea en las tablas de dimensiones o en la de hechos. Además, se permite de esta manera realizar técnicas de minería sobre la bodega, las cuales comúnmente requieren una alta granularidad. Figura 7. Modelo de cubo multidimensional Al diseñar las tablas de hechos y dimensiones, la idea principal es permitir que cada dato del negocio sea representado como un cubo. Donde las celdas del cubo contienen valores medidos y los bordes del cubo definen las dimensiones de los datos. Comúnmente al modelar datos de negocios se obtienen entre 4 y 15 dimensiones. En el ejemplo de la figura 7 se modela un cubo con las dimensiones Producto, Tiempo y Ciudad. A la derecha de la figura aparece el modelo dimensional que representa al cubo, con las tres dimensiones unidas a la tabla de hechos. Hechos Los hechos son medidas de las variables que se consideran. Un hecho puede ser el valor de una factura con sus respectivas relaciones: la factura es generada a un cliente, correspondiente a un producto, creada en una sucursal. Al seleccionar los hechos para el diagrama dimensional, se debe sospechar que cualquier valor numérico, especialmente si es de tipo flotante, es probablemente un hecho. Es de especial utilidad que cada hecho sea aditivo, para los análisis propios de la bodega. 26

34 Dimensiones Los atributos de tipo texto que describen cosas son organizados en dimensiones. Es necesario establecer un criterio puramente de diseño y basado en los requerimientos del negocio para establecer los atributos que se incluyen como dimensiones y los que se pueden descartar al realizar la bodega de datos. Los atributos dimensionales, servirán como fuente para las restricciones y encabezados de filas en los reportes. Todos los atributos dimensionales son igualmente candidatos a ser encabezados de filas en los reportes. Al agregar restricciones a una búsqueda o reporte, se está haciendo un drilling down, es decir se está estableciendo una nueva restricción en una búsqueda para obtener un mayor nivel de detalle. Un drill down eficiente mezcla atributos de las diferentes dimensiones, para realizar reportes realmente robustos. Llaves subrogadas Todas las llaves de las tablas de la bodega de datos deben ser llaves subrogadas, es decir no deben significar nada respecto a las características de su contenido ni a su fuente en los sistemas fuente. No se deben utilizar las llaves originales de un sistema fuente del cual fueron extraídas. Estas llaves subrogadas se manejan como enteros. Método de diseño de una tabla de hechos Para el diseño de la tabla de hechos, de acuerdo a la metodología de Ralph Kimball se deben seguir los siguientes pasos, de cada paso depende el siguiente. Se deben tomar decisiones respecto a: 1. El datamart. 2. La granularidad de la tabla de hechos. 3. Las dimensiones. 4. Los hechos. 1. Selección del datamart. Para un correcto desarrollo de una bodega, es preferible seleccionar e implementar primero los datamarts que dependan de una sola fuente y luego continuar con los que deben extraer datos de múltiples fuentes. En el caso más simple, seleccionar el datamart es lo mismo que seleccionar la fuente legacy de datos. En casos más complejos, se puede definir un datamart que deba incluir múltiples fuentes legacy. 2. Declaración de granularidad de la tabla de hechos. Es necesario definir claramente lo que es un registro de la tabla de hechos en el diseño dimensional propuesto. La granularidad es la respuesta a la pregunta Qué es un registro de la tabla de hechos? 27

35 La granularidad se refiere al nivel de detalle existente en las unidades de los datos de la bodega. Entre más detalle halla, menor será el nivel de la granularidad. Entre menos detalle halla, mayor será la granularidad. Es un factor determinante en el desarrollo de la bodega, debido a que de ella depende el volumen de datos que será almacenado en la bodega y el tipo de queries que pueden ser realizados 7. Figura 8. Ejemplo de granularidad en una empresa de telefonía. Generalmente la granularidad de la tabla de hechos es seleccionada como la más baja o granular posible. Existen varias ventajas para seleccionar este tipo de granularidad como una transacción individual o una línea de documento. De esta forma será mas fácil responder a nuevas consultas y agregar nuevos datos. 3. Selección de dimensiones. Generalmente la granularidad determina unas dimensiones mínimas e iniciales. Al agregar nuevas dimensiones los atributos de estas deben cumplir con la misma granularidad que se ha definido. La granularidad de un dimensión no puede ser menor que la granularidad de la tabla de hechos. 4. Selección de los hechos. La selección de granularidad de la tabla de hechos también permite seleccionar los hechos. En el caso de tabla de hechos de transacciones habrá un solo hecho, el monto de la transacción. Si el caso es una tabla de hechos de snapshot puede contener diversos resúmenes de las actividades realizadas en la toma del snapshot. Como cantidad vendida, valor, costo. Los hechos siempre deben ser específicos a la granularidad de la tabla de hechos. 3.4 DISEÑO TÉCNICO DE LA ARQUITECTURA 7 [11] Building the Data Warehouse 28

36 En los sistemas de información la definición de una arquitectura permite hacer un desarrollo más confiable y eficiente. Con la definición de la arquitectura se mejora la comunicación entre las diferentes áreas del proyecto, el planeamiento del proyecto, la flexibilidad y el mantenimiento del mismo. Aspectos de arquitectura Para hacer el diseño de la arquitectura se debe comenzar analizando los sistemas legacy actuales, estos deben ser consistentes y manejar de forma correcta sus transacciones, pues en la metodología del desarrollo del DWH (Data warehouse) se toma como hecho que estos sistemas son confiables. Para hacer el diseño de la arquitectura se debe comenzar analizando los sistemas legacy actuales, estos deben ser consistentes y manejar de forma correcta sus transacciones, pues en la metodología del desarrollo del DWH se toma como hecho que estos sistemas son confiables. NIVEL DE DETALLE Auditoria para los requerimientos del negocio Modelos y documentos de Arquitectura Especificaciones y modelos Implementación Datos (el qué) Que información se necesita para tomar mejores decisiones del negocio?, Cómo se conectarán los componentes de datos en la arquitectura de bus? Modelo dimensional: Cuales son las principales entidades que componen esta información y como se relacionan?, Cómo se deben estructurar estas entidades? Modelos lógicos y físicos: Cuales son los elementos individuales, sus derivaciones y reglas para la derivación?, Cuáles son los recursos y como se mapear a los destinos? Crear bases de datos, índices, Back up, documentación?. Back Room(el como) Como se hará el proceso ETL y como se tendrán los datos disponibles para los usuarios? Cómo se hace actualmente? Que características especificas se necesitaran para tener los datos en una forma útil en los lugares apropiados? Cuáles son los principales almacenes de datos y donde deben estar localizados? Que estándares y productos proveen las características requeridas?, Cómo se relacionaran?, Cuáles son los estándares para desarrollo, administración de código y nombres? Escritura de extracciones y cargas, automatización de procesos, documentación. Front Room (el como) Cuales son los principales retos que enfrenta el negocio? Como se quieren analizar los datos? Que requerirán los usuarios para cargar la información de una forma útil?, Qué clases de análisis y reportes se deben proveer y cuales son las prioridades? Cuales son las especificaciones de reportes incluyendo filas, columnas, secciones, encabezados, etc..?, Quién las necesita, que tan a menudo?, Cómo se distribuirán? Implementación del ambiente de reporte y análisis, Construcción del conjunto de reportes inicial, entrenamiento a usuario, Documentación. Tabla 1. Bases de la estructura de la arquitectura de Data warehouse Infraestructura (el donde) Que niveles de DWH y sistemas se requieren para tener éxito? Cuales existen actualmente? Cual es el origen y destino de los datos, Se tiene suficiente capacidades de procesamiento y almacenamiento? Como se interactúa con estas características?, Qué utilidades existen en el sistema, API,s etc? Instalación y pruebas de nuevos componentes de la infraestructura. Conexión de las fuentes a los destinos y los clientes. Documentación 29

37 En la tabla 1 se muestran las bases para la estructura de la arquitectura de un DWH. Entre las áreas principales se pueden destacar los datos, el área técnica y la infraestructura. Estas áreas de la arquitectura son interceptadas por filas que nos indican el detalle del incremento. Definición de Columnas Datos: El contenido del DWH son datos. Estos se refieren a todo el contenido físico del este(dwh) que mas adelante se la hará un tratamiento para permitir ver análisis multidimensionales y reportes útiles que apoyen la toma de decisiones. Los Datos guardan toda la información del ambiente del DWH y de las fuentes que surten a este. Técnica: Esta área corresponde a los procesos y a las herramientas que se aplicaran sobre los datos. Esta área se encarga a de responder a la preguntas Como. Por ejemplo Cómo vamos a extraer los datos de la fuentes?, Cómo los podemos organizar de forma que podamos hacer análisis conforme a los requerimientos del negocio?, entre otras. Esto se enfoca principalmente a las herramientas, al desarrollo del DWH y al mantenimiento del mismo. Para garantizar un mejor funcionamiento del área técnica estas se divide en: El Back Room : Es el área del DWH responsable de extraer y preparar los datos. El Front Room: Es el área del DWH responsable de mostrarle a los usuarios los resultados con los datos analizados y examinados, listo para que se puedan ser utilizados. Infraestructura: Corresponden la las plataformas sobre las que se ejecutan los servidores de base de datos, los servidores de aplicaciones y donde se ejecutan los procesos. La infraestructura es la planta física del DWH, se refiere principalmente al hardware utilizado para el desarrollo del proyecto. Definición de los niveles de detalle (las filas). Se comenzará desde los niveles mas altos de detalle. Parte de esa arquitectura trata de hacer modelos y documentos de diferentes niveles de detalle, algunos cercanos y otro no tan cercanos a la realidad. Los mayores niveles de detalle de la arquitectura se usan para diseñar una estructura y obtener un mejor entendimiento de los niveles de detalle mas bajos. Los modelos detallados ayudan a tomar rápidamente las especificaciones que se deben tener en cuenta durante el diseño y que por ningún motivo se pueden pasar por alto, pues de esta forma no se tendría un entendimiento total del negocio. Nivel de requerimientos del negocio: Este nivel no trata de ninguna implementación técnica del DWH, el interés del arquitecto del proyecto se centra en entender el comportamiento de los negocios, los procesos de la empresa y las limitaciones que podrían ir en contra del desarrollo del DWH. Nivel de modelos de arquitectura: Este es el primer donde se piensa en la forma de responder a los requerimientos. 30

38 Un modelo de arquitectura, propone los principales componentes de una arquitectura que se deben implantar para consecución de los requerimientos. Todas las tecnologías de arquitectura, deben ser justificadas y deben garantizar que funcionan juntas en un sistema. Se debe definir si los componentes técnicos se comunican unos con otros, si las suposiciones administrativas para usar la tecnología son razonables y si la organización tiene recursos para soportar esta tecnología. Nivel de detalle del modelo: Hace referencia a las especificaciones funcionales de cada componente de la arquitectura, esto debe incluir suficiente información que sirva como guía al equipo de desarrolladores para tener una implementación mas confiable y con menos errores. Esto también sirve en el caso que se quiera establecer un contrato legal, pues lo establecido en el la especificación es lo mismo que se va implementar y se puede evitar que el cliente exija mas funcionalidades cuando nunca fueron determinadas formalmente. El modelo dimensional y modelo físico de una fact- table corresponden la los modelo de detalle para el área de datos. Nivel de implementación: La implementación es realizada a partir de los detalles del modelo, pues ahí se tiene considerado la arquitectura y detalles para llevar acabo el desarrollo. El desarrollo del proyecto debe estar documentado. 3.5 PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA Este proceso comprende varios aspectos determinantes para la bodega de datos. Por lo tanto se debe seguir un plan para su correcto desarrollo. Se establecen varios pasos que conducen al desarrollo del proceso y se describen a continuación. Paso 1. Plan de alto nivel El proceso de diseño se inicia con un esquema simple de los componentes del plan que son conocidos: Las fuentes y los destinos de los datos. Se identifica de donde provienen los datos y las características y problemas con dichas fuentes. Con este esquema es posible comunicar la complejidad del proyecto a la gerencia y miembros del equipo de desarrollo del proyecto. Las aplicaciones de ETL realizan tres pasos: extracción, transformación y carga a la bodega de datos. Estos pasos se deben ver en un esquema de alto nivel: Tomar los datos de las fuentes, transformarlos y cargarlos en los destinos. Paso 2. Herramientas ETL Las extracciones típicamente se escriben en el lenguaje de la fuente de los datos. Existen herramientas que realizan todo el proceso de extracción, transformación y carga que buscan minimizar el tiempo requerido para estas tareas. Estas herramientas implican 31

39 un costo por licencias y posibles incompatibilidades o dificultades con transformaciones complejas que fuesen requeridas para el proceso. Ya se haga el proceso con código desarrollado, o herramientas existentes, es determinante realizar prácticas que mejoren el rendimiento del proceso, como ordenar los datos o cargarlos de forma rápida para cargas masivas en las bases de datos. Paso 3. Plan detallado El plan se inicia seleccionando la tablas en las que se va a trabajar, en cual orden y secuenciar las transformaciones para cada conjunto de datos. Se debe graficar un diagrama con estas estructuras. Todas las tablas de dimensión deben ser cargadas antes que las tablas de hechos. Se debe iniciar el desarrollo de la aplicación ETL con la dimensión más simple y continuar con las demás hasta llegar la tabla de hechos. Paso 4. Poblar una tabla de dimensión simple La principal razón para iniciar el proceso con una dimensión estática y simple es la facilidad para poblar esta tabla. A continuación se presenta información para realizar el proceso completo de ETL relevante a cualquier tabla destino (dimensiones y hechos). Extracción de una dimensión Se deben entender las características de la fuente de datos. Si la fuente es relevante para la dimensión destino, como se actualiza esta fuente, si hay alguna hora en el día en la cual no se deba acceder a esta fuente, son preguntas que se deben resolver en esta etapa. También se deben generar reportes de extracción, que permitan extraer únicamente los campos o datos requeridos de cada fuente. Existen dos fuentes principales de datos: archivos y bases de datos. Si la fuente se encuentra en una base de datos, se crea un solo proceso que haga fluir los datos desde la fuente a la sección de transformación y carga. Si la fuente es un archivo, se requieren varios pasos en el proceso: extracción al archivo, ubicación del archivo en el servidor del proceso, transformar los datos del archivo y cargar el archivo en la base de datos utilizada para transformar y cargar datos. Transformación de una dimensión Existen transformaciones comunes y sencillas, como el cambio de un tipo de dato a otro, o cambiar letras minúsculas por mayúsculas, otras más complejas se indican a continuación. - Asignación de llaves substitutas (surrogate en inglés) Las llaves substitutas son las llaves primarias de las tablas del modelo dimensional, que son diferentes y no deben tener ninguna relación con las llaves primarias de las tablas fuentes ni de los datos mismos. Típicamente se utilizan enteros para estas llaves. - Combinación de diferentes fuentes 32

40 Si un dato depende de diferentes fuentes se debe mapear el dato destino y los datos orígenes para controlar esta transformación. Carga Para mejorar el rendimiento, la primera carga a la bodega se debe hacer con las características de población masiva de datos del motor de base de datos del modelo dimensional. Los principales motores de bases de datos tienen esta característica y su uso depende del producto utilizado. Otra forma de mejorar el rendimiento de carga es suprimir los índices en la base de datos, que son costosos para el rendimiento de la carga, y este costo no se recupera en mejora de rendimiento del análisis multidimensional de la bodega. Paso 5. Implementación de la lógica del cambio de una dimensión Al cambiar los datos de una dimensión, ya sean nuevos o actualizaciones a los datos previos, es preferible construir la extracción de tal forma, que se extraigan únicamente los datos que han cambiado. Al determinar los cambios, se debe contar con reglas del negocio que determinen como manejar estos cambios en los atributos. Si se determina que la modificación es legítima y es posible actualizar el dato, se utiliza la técnica de una dimensión cambiante. El primer paso para preparar la dimensión consiste en determinar si ya existe un registro antiguo del dato. Al encontrar una modificación se aplica alguno de los siguientes tipos de respuesta al cambio. Tipo 1: Sobrescribir. Se toma el nuevo dato de la fuente y se sobrescribe la tabla de la dimensión con el nuevo contenido. Tipo 2: Crear un nuevo registro de la dimensión. Se crea un nuevo registro de la dimensión con una nueva llave subrogada. Tipo 3: Bajar el antiguo valor. Se crea un nuevo campo en la dimensión que contenga el antiguo valor del dato modificado y se actualiza la dimensión con el nuevo contenido. Cada tabla de dimensión usará una, dos o las tres técnicas para administrar los cambios de datos. Paso 6. Poblar las dimensiones restantes Para poblar el resto de dimensiones se sigue el proceso del paso 4, y se cargan ya sea con el uso de una herramienta de carga existente o con el desarrollo de una que soporte conexiones ODBC o JDBC. Paso 7. Carga histórica de hechos 33

41 En el proceso de ETL debe existir un paso para reemplazar las llaves primarias de las fuentes por las llaves subrogadas que se han asignado a cada dimensión, y que deben ir como llaves foráneas en la tabla de hechos. Para mantener una integridad referencial en la bodega, - que significa que por cada llave foránea en la tabla de hechos exista un registro en la dimensión correspondiente se realizan dos búsquedas de llaves subrogadas en el proceso de extracción. Una ocurre cuando se utiliza la técnica 2 del paso 5, y se ha creado un nuevo registro de una dimensión que contiene una nueva llave subrogada y un campo modificado con el resto del contenido original. La segunda búsqueda ocurre cuando se están procesando los registros de la tabla de hechos. En este momento se debe buscar en todas las dimensiones los registros que coincidan con el dato que se está buscando relacionar con la tabla de hechos, y una vez encontrado el registro de la dimensión, agregar su llave subrogada a la llave foránea de la tabla de hechos. Este proceso funciona bien para bodegas de datos que no manejan grandes cantidades de registros, pues al ser grande el tamaño de datos es preferible mantener una tabla de búsqueda que registre la llave primaria en la fuente y la llave subrogada en la dimensión. D esta manera se mejora el rendimiento al poblar la tabla de hechos. Una vez se cuenta con todas las llaves foráneas de la tabla de hechos, esta tabla se empieza a cargar. Paso 8. ETL de una tabla de hechos incremental Al realizar cargas semanales o periódicas a la bodega desde las fuentes, es decir al actualizar la bodega, se deben extraer y procesar únicamente las transacciones que han ocurrido luego de la última carga. Para seleccionar únicamente estas nuevas transacciones se pueden usar los logs de las bases de datos, y de esta forma identificar los datos que han cambiado en el período analizado. El log captura cada cambio que haya sido realizado a un registro. También es posible crear losgs en las bases de datos fuentes que registren únicamente los cambios que son importantes para la bodega, utilizando triggers. Paso 9. Operación y automatización de la bodega de datos Idealmente el proceso ETL de una bodega de datos se ejecuta de manera automática y no atendida. Las operaciones típicas en la bodega son que se deben tener en cuenta en este paso son las siguientes: Definición de tarea Flujos y dependencias Horarios de tareas basadas en tiempos y hechos Monitoreo Logging Manejo de excepciones Manejo de errores Notificaciones 34

42 Estas características deben ser proporcionadas para que la bodega de datos pueda ser un sistema de producción. Procesos automáticos: Extracción. Para que todo el proceso ETL sea automático, el paso de extracción debe notificar al siguiente cuando empezar. Este proceso también debe registrar su trabajo en una metadata, que contenga el nombre de la tarea realizada, el usuario, la fecha, tiempo tomado para la tarea y cualquier otro hecho que quiera ser monitoreado. Calidad y limpieza de datos. En todos los sistemas se encontrarán problemas de calidad y limpieza de datos, por lo tanto se deben establecer políticas que determinen estándares de calidad aceptables y procedimientos a realizar cuando estos problemas se identifiquen. Mejoramiento de datos. Para garantizar el uso de los mejores datos posibles para la bodega, se deben tener en cuenta los siguientes pasos: - Identificar la fuente de datos con la mejor calidad: Es posible que se encuentren varias fuentes con los mismos datos, pero en algunas se tenga mejor calidad de los mismos. - Identificar variaciones en palabras: Como errores de ortografía y mayúsculas y minúsculas. - Discutir problemas de datos con el equipo. - Arreglar los problemas de datos en las fuentes cuando sea posible, en vez de hacerlo en el proceso ETL o directamente a la bodega. - No arreglar todos los problemas. Si existen muchos problemas en las fuentes, arreglarlos en el proceso ETL irá en contra del rendimiento, estos problemas deben ser responsabilidad de los sistemas fuentes. - Realizar tareas de limpieza sobre los datos. Aseguramiento de la calidad Un vez se tienen los datos, es importante determinar si este contenido es realmente correcto. Se pueden hacer varios procesos para determinar esto: - Cruce de datos. Se ejecutan varios queries contra las fuentes de datos y se verifica que el resultado de estos queries sea el mismo que el dado con los datos seleccionados del proceso ETL - Examen manual. Si existen varias fuentes para un mismo dato, o eventos de ese tipo, es preferible examinar los datos manualmente y compararlos con el resultado esperado. - Validación del proceso. Al utilizar la bodega de datos es posible encontrar diferentes resultados de los que se harían con simples queries sobre las fuentes. Esto se da debido a la limpieza y transformaciones hechas a los datos en el proceso ETL. Por lo tanto 35

43 es importante identificar las causas de las diferencias y determinar cual resultado es realmente el correcto. 3.6 SELECCIÓN E INSTALACIÓN DE PRODUCTOS Selección de Productos. Una vez se tiene completa la arquitectura, se deben tener en cuenta dos componentes fundamentales para la selección de productos: Requerimientos técnicos. Requerimientos de negocio. Mantener el negocio enfocado Para la selección de la herramienta se debe hacer un riguroso estudio de cada una de ellas, mirar sus ventajas y desventajas y saber el alcance que se quiere con cada una para saber las cosas que se pueden y nos se pueden hacer. Otro punto importante en la escogencia de la herramienta son los requerimientos de los usuarios: los requerimientos del negocio, mirar el análisis y el grado de procesamiento que se puede obtener con cada una ya sea un motor de base de datos, una herramienta de ETL o una herramienta OLAP o de reportes. También de deben mirar las limitaciones de los usuarios en lo referente al HW, pues no tiene sentido contratar una herramienta que consume muchos recursos cuando no se tiene la plataforma para soportarla.. Para la escogencia de las herramientas también se debe tener presente el plan del proyecto, la arquitectura para mirar los alcances técnicos y la documentación de los requerimientos que seguramente ayudan a la mejor opción. El momento de la escogencia de las herramientas tiene su momento indicado durante el desarrollo del proceso de DWH. Si se hace muy temprano no se tendrá un real entendimiento de los requerimientos del negocio y seguramente no se hará la mejor opción. Si espera y se hace un tiempo después tendremos mas información acerca los requerimientos, las plataformas y se puede escoger de esta forma una mejor opción. Áreas a evaluar para la escogencia de las herramientas Se tienen cuatro área fundamentales para la evaluación y escogencia de las herramientas. Plataforma de hardware: Se deben avaluar las diferentes plataformas para mirar su capacidad y escoger las herramientas teniendo esto en cuenta la limitaciones que se podrían presentar. La plataformas de servidores donde se ejecutarán las herramientas de análisis dimensional, la plataforma donde tenemos los Datamart y los demás servidores de aplicaciones deben ser analizadas cuidadosamente. 36

44 Plataformas de Base de Datos: Para proyectos pequeños se puede utilizar un motor de BD sencillo como mysql que no se muy pesado y que podrán soportar las plataformas. Para proyectos grandes se debe considerar un motor de BD con mas características, que me seguridad y que me permita realizar mas y mejores aplicaciones, por ejemplo PostgreSQL, Oracle, SQL Server, interbase, entre otras. Herramientas de Data Staging: Esta es el área de trabajo del DWH donde la información se extrae de las fuentes, se le hace limpieza a los datos, se hacen las transformaciones y se envían a los datamarts. Estas son las herramientas mas costosas y complejas del proyecto. Herramienta de acceso a los datos: Esta elección es difícil porque en el marcado no existe un líder, y además se terminan usando varias de estas herramientas por los gran variedad de requerimientos que de desea cumplir. Cuando se usa software propietario es fácil la utilización por que se solicita soporte técnico para que ayude en la capacitación y manejo de la herramienta y aprovechar algunos beneficios adicionales que pueda ofrecer. Para la escogencia de la herramienta se debe tomar un tiempo prudente, debemos recordar que las herramientas tecnológicas cambian continuamente por eso hay que hacer lo posible para mantenerse siempre actualizado. Una posibilidad con el software propietario es que se puede tener acceso a versiones trial por 90 días para tener la oportunidad de conocer el producto y decidir si definitivamente se ajusta o no a las necesidades del proyecto. Cuando las herramientas son SW libre se deben manejar recursos como foros on-line y hacer contacto con otros usuarios del producto para de esta manera tener algo de soporte técnico. 3.7 CARACTERÍSTICAS DE APLICACIONES PARA USUARIOS FINALES En los pasos explicados anteriormente, se ha analizado el diseño e implementación; ahora se profundizará más en el front room. El objetivo del front room es proporcionar la interfaz que mostrará al usuario reportes y análisis multidimensionales que tomará como base en la toma de decisiones. Una aplicación de usuario final, provee un diseño y estructura a los reportes tomando como base los datos del DWH. Especificación de aplicaciones para usuario finales Hay algunos pasos importantes en el proceso de especificación de las aplicaciones de usuario final: Determinar el conjunto inicial de plantillas de reportes Determinar la navegación en los reportes. Determinar el estándar de plantillas de reportes. Determinar la especificación de estas plantillas. 37

45 Determinar el conjunto inicial de plantillas de reportes: El primer paso es tener la lista de reportes que se va a desarrollar en la aplicación. Para esto se deben hacer 3 tareas fundamentales: Identificar los posibles reportes: mirando la documentación que se tiene del proyecto, mirando los requerimientos del negocio se encuentra un gran potencial para determinar los posibles reportes. Con esta información se hace una lista de reportes a planificar, especificando el nombre, las filas y columnas con los elementos de datos y las medidas. Por ejemplo, tener la lista de la información de los departamentos que van a estar involucrados en los reportes y análisis. Consolidar la lista de candidatos: Una vez se tiene la lista de reportes, de debe categorizar dicha lista. Las categorías se reconocen rápidamente debido a la forma como están estructuradas las compañías. Para analizar como categorizar los reportes, se pueden tener en cuenta las siguientes preguntas: Como es el negocio?, Cuál es la tendencia?, entre otras. Priorizar la lista de reportes: Una vez la lista de reportes se tiene establecida, se debe definir con el usuario final para establecer prioridad en los reportes que ellos van a utilizar. Definir la navegación para los reportes: Se debe desarrollar un modelo que permita al usuario encontrar la información de una manera más rápida y eficiente. Se debe crear un modelo inicial para la navegación y poder analizar de una manera más fácil los reportes y análisis multidimensionales. Definir los estándares de las plantillas de reportes: En esta parte se establecen estándares en cuanto a los elementos de la BD. Esta estandarización es muy importante por ayuda para entender la naturaleza de los reportes. La estandarización se enfoca principalmente a los elementos de datos del DWH que son utilizados para alimentar los reportes. Detalles de especificación de la plantillas de reportes: Cada organización tiene un diferente grado de detalle en la documentación del proyecto. También se debe determinar si el equipo que trabaja en el proyecto hace formalmente la documentación de las aplicaciones. Si la respuesta es negativa se debe presionar para que la tenga al día y a disposición para cualquier usuario que la quiera mirar. Formato de especificación: La especificación del aplicación para el usuario final tiene 2 partes fundamentales: - La definición, que provee información básica acerca de la plantillas de reportes. - El diseño, provee una representación visual de lo que debería mostrar el reporte. La definición de las plantillas de reportes incluye el nombre, la descripción o propósito, frecuencia con que debe ser actualizado, parámetros, entrada, entre otros. 38

46 Tipos de aplicaciones para usuarios finales: Existen varios tipos de aplicaciones: 1. Basadas en Web: Estas aplicaciones son accedidas a través de un browserde Internet. Los usuarios podrían conectarse y ver los reportes vía intranet o Internet entrando a la pagina del DWH. 2. Herramienta independiente: Con la herramienta se diseñan algunas plantillas de reportes que el usuario va a poder acceder a través de una interfaz. Esta implementación no es muy flexible, pues en el caso que se quiera añadir reportes sale costoso, pero de igual forma es muy rápida. Estos reportes son muchas veces almacenados en archivos compartidos para que todas las personas la puedan acceder. 3. Herramienta de interfaz ejecutiva: Proporciona una estructura de acceso a las plantillas de reportes a través de una serie de screens. Estas implementaciones permiten fácilmente la navegación en la plantilla escogida. 4. Interfaz por código: Estas herramientas proporcionan un API que permite diseñar una interfaz. Esta es una buena posibilidad, pues se utiliza una herramienta de desarrollo grafico y la navegación se puede ajustar mejor a las necesidades del usuario. 3.8 MANTENIMIENTO Y CRECIMIENTO DE UN DATA WAREHOUSE Administración del entorno de data warehouse Cuando una empresa adquiere sus sistemas de información el cambio que tendrán estos sistemas es muy poco, sin embargo cuando se desarrolla un proyecto de DWH se debe pensar en el mantenimiento posterior a la implementación, pues estas aplicaciones tienen gran tendencia a crecer a medida que crece la información de la organización. La inversión en el mantenimiento del DWH es bastante importante, sin embargo estas aplicaciones retornan la inversión que se les hace. Diagnóstico de resultados incorrectos Cuando se tienen problemas en el DWH y no se tienen los resultados esperados, se debe revisar alguno de los pasos anteriores en el ciclo de vida. También se tiene una serie de preguntas que en el caso de no ser positivas, hay mas razones para revisar los pasos anteriores. El proyecto tiene el apoyo de los altos ejecutivos de la organización? El equipo de desarrollo del proyecto entendió correctamente los requerimientos del usuario? Los usuarios finales entienden el modelo dimensional o tienen que recurrir a las complicada tablas del datamart directamente? Para la escogencia de las herramientas análisis de datos, los usuarios finales fueron considerados en el proceso? Los datos utilizados para alimentar el datamart son correctos? 39

47 Son coherentes los reportes que se están obteniendo del DWH?, de no ser así, el equipo de desarrollo entiende la inconsistencias y tiene informado a los usuarios finales? Los datos en el DWH se renuevan de manera oportuna? La BD esta bien diseñada o las consultas tardan mucho tiempo para darnos el resultado? Tiene el DWH un equipo constante para la construcción de plantillas de reportes que ayuden al usuario a hacer mejores análisis? Los usuarios finales han recibido suficiente entrenamiento en las herramientas generadoras de análisis multidimensionales o de reportes? Conocen los usuarios del negocio a quien recurrir del equipo del DWH en el caso que tengan problemas con este? Alguien responde cuando ellos necesitan consultoría para resolver problemas? Enfoque en usuarios del negocio Durante las semanas posteriores a la terminación del proyecto, se debe tener en cuenta que la cercanía del usuario debe ser esencial, pues se le debe prestar la mayor ayuda posible para que el proyecto comience a mostrar sus resultados rápidamente. No se debe esperar que los usuarios llamen a los miembros del equipo, los más correcto es estar con ellos porque si los problemas duran mucho tiempo el usuario se podría sentir decepcionado con el producto. Administración de operaciones Cuando el DWH hace grandes cargas, se debe tener la implementación bien robusta para que el proceso sea completamente exitoso; se le debe hacer mantenimiento a la infraestructura técnica, al manejo y mantenimiento de la BD y al manejo de los datos y mata data. Manejo de la infraestructura técnica: esta es una de las pocas ares donde el DWH se parece a los sistemas operacionales de la empresa. Se debe monitorear frecuentemente la infraestructura técnica para más adelante no tener problemas con el DWH. Las áreas críticas donde pueden haber problemas son los servidores de aplicaciones, los servidores de BD, entre otros. Desempeño de la base de datos: Se pueden sacar indicadores cada vez que se cargan datos o cuando se ejecuten rutinas que involucren esta plataforma. Con estos indicadores se puede medir el desempeño de esta plataforma. Mantenimiento de los datos y meta datos: Los datos en el DWH cambian mucho, es decir por la gran cantidad de procesos y por la transacionabilidad de las operaciones diarias, continuamente se están anexando datos al DWH y los usuarios finales cada vez están necesitando más y más análisis de datos para mejorar la calidad en la toma de decisiones. El impacto de estos cambios debe analizarse de forma detenida, y determinar si tienen algún efecto en contra de la funcionalidad de la plataforma del DWH. 40

48 Todos estos cambios en la plataforma se deben documentar para tener detallado el seguimiento que se le hace y además para que todos los miembros del equipo de desarrollo estén actualizados acerca del estado del proyecto. 41

49 IV. DESARROLLO DEL PROCESO DE CONSTRUCCIÓN DEL DATAMART Para el desarrollo de la construcción del datamart se sigue la metodología estudiada de Ralph Kimball, dado que establece claros procesos para todo el ciclo del desarrollo del proyecto y garantiza la calidad y eficiencia de la solución de inteligencia de negocios. Esta metodología fue desarrollada desde el inicio del proceso de construcción, hasta llegar a las etapas de interacción con el usuario y documentación del proyecto. En las siguientes secciones se describen los procesos realizados para cada fase del proyecto que garantizan su calidad y cumplimiento. 4. PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO 4.1 OBJETIVO DEL PROYECTO Construir un datamart que soporte el análisis multidimensional de ventas de la empresa Ubiquando, utilizando herramientas de libre distribución para mantener una solución basada en software libre. 4.2 DEFINICIÓN DEL PROYECTO Para el proyecto desarrollado se identificó un alto interés de la gerencia de la empresa para el éxito de su implementación. La demanda del proyecto se encuentra en el gerente de Ubiquando, quien identifica necesidades de obtener mejor información sobre su negocio para tomar mejores decisiones para la empresa y así mejorar su competitividad. Esta demanda se satisface al implantar la solución de inteligencia de negocios del proyecto, con un datamart encargado de transformar los simples datos operativos de la empresa en información útil de sus ventas, utilizando análisis OLAP. Toda la solución es basada en software libre y no utiliza ningún componente comercial, tanto en las etapas de desarrollo como en las de producción. Esto permite reducir costos y poner a disposición la inteligencia de negocios a PYMES como Ubiquando y empresas que no cuentan con el soporte financiero de las grandes empresas, históricamente beneficiadas con las costosas soluciones comerciales de inteligencia de negocios. 42

50 4.3 ALCANCE DEL PROYECTO El proyecto contiene todos los componentes de una bodega de datos o datamart. Como fuentes se tienen una base de datos de contabilidad de la empresa, hecha en Mysql de forma relacional y varios archivos de texto. Para el proceso de extracción, transformación y carga, se desarrolló un software en java que permite realizar esta tarea utilizando las diferentes fuentes de información. La bodega de datos, o datamart es construida en una base de datos en PostgreSQL. Finalmente, el análisis OLAP es realizado utilizando el servidor OLAP Mondrian. Todas estas herramientas son soportadas por varios sistemas operativos, incluyendo Microsoft Windows y Linux. Esto permite una gran portabilidad y la posibilidad de realizar el análisis OLAP vía web, gracias a que el análisis OLAP se realiza utilizando un navegador de Internet. El datamart proporciona información sobre las ventas de Ubiquando, al utilizar las fuentes mencionadas para producir la información. Se desarrollan e implementan los requerimientos de ventas determinados luego del levantamiento y análisis de requerimientos que son acordados con la empresa. 4.4 JUSTIFICACIÓN DEL PROYECTO EN EL NEGOCIO Además de ser un proyecto académico, el proyecto busca mejorar la productividad y beneficios económicos de Ubiquando. Como justificación para el negocio se prevén los siguientes beneficios: Incrementar el número de negocios Se establece que al realizar un análisis por segmentos de clientes, la empresa realizará esfuerzos de marketing más eficientes, al enfocar determinados productos a los candidatos de compra apropiados. Mejorar servicios y productos en temporadas Se determina que se pueden mejorar las ventas de productos en temporadas de alta demanda de los mismos, gracias al acceso a mejor información. Se pueden realizar tácticas de promoción y realizar mejoras al proceso de fijación de precios para aprovechar la alta demanda de las temporadas encontradas. Selección de los mejores clientes Se establece que al realizar un análisis sobre las ventas de clientes y productos se determinan preferencias y necesidades de clientes sobre determinados productos. Se pueden ofrecer productos, que se pronostica que el cliente necesitará, dadas sus últimas compras, u ofrecer productos que se diagnostiquen como de su preferencia. 43

51 5. ANÁLISIS DE REQUERIMIENTOS Para el levantamiento de requerimientos se realizaron entrevistas a personas del área técnica y de negocio de la empresa. Los requerimientos identificados en esta etapa (capítulo 5.1), se implementan con la herramienta OLAP Mondrian. 5.1 LEVANTAMIENTO DE REQUERIMIENTOS Para realizar la recolección de requerimientos se realizaron entrevistas con los futuros usuarios de la solución y también con personas del área de tecnología de la empresa. Los requerimientos del negocio se describen a continuación. Ver ventas por productos. Ver ventas por cliente. Ver ventas por tiempos. Ver ventas de productos por cliente. Ver ventas por productos en el tiempo. Ver ventas por cliente en el tiempo. Ver ventas por cliente y producto en el tiempo. Ver ventas por ciudad en el tiempo. Ver ventas por productos en ciudades. Ver ventas por ciudad. Estos requerimientos fueron los acordados a implementar con la empresa, todos ellos soportados con datos encontrados en la base de datos con ayuda de archivos que también funcionan como fuentes. 5.2 DOCUMENTACIÓN DE REQUERIMIENTOS La documentación de estos requerimientos pretende presentar una descripción de cada uno y las fuentes de donde se extraerán los datos para producir la información de la cual cada caso es responsable. El detalle de cada fuente de datos se encuentra en el capítulo 7. Para conocer la forma como se accede a cada reporte que implementa a cada requerimiento desde la herramienta, ver el anexo Manual de administrador. 44

52 5.2.1 Ver ventas por productos Descripción: Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas ventas por sus líneas de productos. Al hacer drill down se exploran las ventas por productos individuales. Fuentes de datos: Base de datos netcontable y archivos planos facturas.txt y productos.txt Ver ventas por cliente Descripción: Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas ventas por sus sectores de clientes. Al hacer drill down se exploran las ventas por clientes individuales. Fuentes de datos: Base de datos netcontable, archivo plano clientes.txt Ver ventas por tiempos Descripción: Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas ventas por las fechas de venta. Al hacer drill down se limita más el criterio del reporte, permitiendo analizar las ventas por año, semestre, trimestre y día. Fuentes de datos: Base de datos netcontable Ver ventas de productos por cliente Descripción: Se muestran las ventas que se han hecho a los clientes con sus respectivos productos. Fuentes de datos: Base de datos netcontable, archivos planos facturas.txt, clientes.txt y productos.txt Ver ventas por productos en el tiempo Descripción: Se muestra el reporte que indica las ventas que se han realizado de los productos de Ubiquando en el tiempo. Fuentes de datos: Base de datos netcontable y archivo plano facturas.txt, productos.txt Ver ventas por cliente en el tiempo Descripción: Permite visualizar las ventas hechas a clientes en períodos de tiempos. Fuentes de datos: Base de datos netcontable y archivo plano clientes.txt. 45

53 5.2.7 Ver ventas por cliente y producto en el tiempo Descripción: Esta consulta es la más elaborada y compleja del cubo de ventas. Comprende una unión entre todas las dimensiones del cubo para dar respuesta a una consulta de tipo ventas por cliente y producto vendido en esa venta en cierto segmento del tiempo. Es posible analizar las ventas de cierta línea de productos o de un producto a un segmento de clientes o a un cliente específico en un año, semestre, trimestre o día determinado. Fuentes de datos: Base de datos netcontable, archivos planos clientes.txt, productos.txt, facturas.txt Ver ventas por ciudad Descripción: Esta consulta permite ver el valor de las ventas por ciudades en las que Ubiquando tiene sus clientes. Fuentes de datos: Base de datos netcontable Ver ventas por productos en ciudades Descripción: Esta consulta permite ver el valor de las ventas por cada línea de producto o productos individuales en las ciudades de venta. Fuentes de datos: Base de datos netcontable y archivo plano clientes.txt Ver ventas por ciudad en el tiempo Descripción: Esta consulta permite ver el valor de ventas de cada ciudad en diferentes períodos de tiempo (año, semestre, trimestre, mes o día) dependiendo del criterio del analista. Fuentes de datos: Base de datos netcontable. 46

54 6. MODELAMIENTO DIMENSIONAL Para iniciar el modalamiento dimensional se debe tener en cuenta el principal objetivo de cualquier bodega de datos o datamart: el análisis de la información. Este análisis es realizado por medio de reportes, por lo tanto al modelar el datamart se debe tener como objetivo la información deseada en los reportes. Dada la definición de los requerimientos se identifican reportes de ventas que contengan información sobre: ciudades, segmentos de clientes, clientes individuales, líneas de productos, productos individuales y períodos del tiempo en que se realizan las ventas. Estas categorías son dimensiones en el modelo dimensional, y la tabla en donde aparece la medida, que es el valor de las ventas es llamada tabla de hechos. La relación de la tabla de hechos a las tablas de dimensiones es de uno a muchos. Esto se comprende lógicamente por el modelo del negocio, que tiene ventas en muchas ciudades, a varios segmentos de clientes, de varias líneas de productos en diferentes períodos del tiempo. En las siguientes secciones se detalla cada componente del modelo dimensional. 6.1 EL DATAMART El modelo diseñado e implementado es un datamart. Este concepto se diferencia al de bodega de datos en que el datamart busca centrarse en un objetivo único, o en el análisis de un área específica de la empresa. En el caso de este proyecto el objetivo es analizar las ventas únicamente. Una bodega de datos sirve a varias áreas de una empresa, y en muchos diseños es compuesta de varios datamarts. Sin embargo, no es posible clasificar a un datamart como una pequeña bodega de datos, pues el concepto de datamart o bodega es solo de diseño. Un datamart de un área de una gran empresa puede ser más complejo y contener un mayor número de datos que toda una bodega de datos de una empresa de menor tamaño, o con diferentes bases de datos. El datamart implementado en este proyecto tiene varias fuentes de datos que poblan el datamart: una base de datos implementada en MySQL de la contabilidad de la empresa y varios archivos de texto que complementan la información de la base de datos. Los detalles de estas fuentes de datos se encuentran en el capitulo DEFINICIÓN DE LA GRANULARIDAD 47

55 Se definió la granularidad de la tabla de hechos como la más baja o granular posible. Esta granularidad corresponde a una venta de un producto a un cliente en una fecha determinada, es decir una transacción individual. De esta forma será posible llegar al grado de detalle de consultar una venta específica, aunque este no sea el objetivo de un datamart. La medida, que es el campo de valor de la tabla de hechos es el valor de una venta con la granularidad establecida. 6.3 DIMENSIONES Se definen las dimensiones que soportan los requerimientos definidos, cumpliendo con la granularidad de la tabla de hechos. Las siguientes secciones relacionan las tablas diseñadas para la base de datos con su dimensión correspondiente Dimensión línea Tabla: dim_linea. Contiene la información acerca de las líneas de productos para poder hacer una clasificación por cada uno de estos. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria lin_idlinea INT8 Llave primaria de dim_linea Si lin_descripcion Varchar(40) Nombre de la línea (Instalación, Desarrollo, Capacitación, Soporte, Asesoría) Tabla 2. Tabla dim_linea No Dimensión producto Tabla: dim_producto Contiene la información de los productos que ofrece la empresa. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria pro_idproducto Varchar(20) Llave primaria de dim_producto Si pro_descripcion Varchar(100) Nombre del Producto No proidlinea INT8 Llave foránea a la tabla dim_linea, indica a cual línea pertenece este producto. Tabla 3. dim_producto No 48

56 6.3.3 Dimensión cliente Tabla: dim_cliente Contiene la información de los clientes que maneja la empresa. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria cli_idcliente INT8 Llave primaria de dim_cliente Si cli_nombre Varchar(100) Nombre del Cliente No cliidsector IINT8 Llave foránea a la tabla dim_sector, indica a cual sector pertenece este cliente cliidgeografia Varchar(30) Llave foránea a la tabla dim_geografia, indica a cual ciudad pertenece este cliente Tabla 4. dim_cliente No No Dimensión sector Tabla: dim_sector Contiene información de los sectores a los que pertenecen los clientes. Cada cliente pertenece a un sector y a un subsector. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria sec_idsector INT8 Llave primaria de dim_sector Si sec_descripcion Varchar(40) Nombre del sector No sec_subcategoria Varchar(40) Nombre de la subcategoría No Tabla 5. dim_sector Dimensión geografía Tabla: dim_geografia Contiene información sobre la ciudad a la que pertenece un cliente. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria geo_idgeografia INT8 Llave primaria de dim_geografia Si geo_ciudad Varchar(40) Ciudad a la que pertenece el cliente No Tabla 6. dim_geografia 49

57 6.3.6 Dimensión tiempo Tabla: dim_tiempo Contiene información de las fechas en que se realizan las ventas. Esta tabla contiene información sobre el año, semestre, trimestre, mes y día. Se tienen estos diferentes campos para una misma fecha para permitir al usuario navegar por la dimensión dependiendo del grado de profundidad de fecha que prefiera. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria tie_idtiempo INT8 Llave primaria de dim_tiempo Si tie_dia Varchar(30) Descripción del día en que se realizó la venta tie_mes Varchar(30) Contiene información del mes No tie_trimestre Varchar(30) Contiene información del trimestre No tie_semestre Varchar(30) Contiene información del semestre No tie_ano INT4 Contiene información del año No Tabla 7. dim_tiempo No 6.4 TABLA DE HECHOS En este datamart hay un solo hecho: el hecho de la transacción. Este hecho es el valor de una venta; también es llamado una medida. Esta medida cumple con la granularidad definida, es decir es el valor de una transacción individual de una venta. Los demás campos son llaves foráneas, para relacionar esta tabla con sus dimensiones. Tabla: fact_venta Registra información de las ventas que hace la empresa. Campo-Nombre Tipo/Tamaño Descripción Llave Primaria venidcliente INT8 Id de la dim_cliente No venidproducto Varchar(20) Id de la dim_producto venidtiempo INT8 Id de la dim_tiempo No ven_valor Float(30) Medida que muestra el valor de la venta que hizo a un cliente de un producto determinado en una fecha especifica. Tabla 8. Fac._venta No No 50

58 6.5 DISEÑO DEL MODELO DIMENSIONAL Luego de haber determinado las dimensiones y la tabla de hechos se diseña el diagrama multidimensional implementado en la base de datos PostgreSQL. Este diagrama es un modelo de copo de nieve, pues algunas dimensiones (producto y cliente) se tienen asociadas otras dimensiones. Se prefirió diseñar el modelo en copo de nieve por ofrecer una mayor claridad de diseño y mejor organización de los datos. El concepto negativo que se tiene de este modelo por ofrecer un menor rendimiento que el de estrella, no aplica en este caso. El número de datos manejados por el datamart no compromete su rendimiento; además, gracias a los bajos costos que el hardware ofrece, cada vez la desventaja del rendimiento se vuelve más insignificante. Figura 9. Diagrama multidimensional del datamart Como aparece en el diagrama de la figura 9 y en el análisis de dimensiones se tienen seis dimensiones. Para la dimensión cliente se tienen dos asociadas a ella: las dimensiones sector y geografía. Cada una de ellas clasifica a los clientes de una manera diferente, agrupándolos por sectores del mercado o por ciudades respectivamente. La dimensión producto también tiene una dimensión asociada, permitiendo agrupar productos en líneas de productos. 51

59 7. DISEÑO TECNICO DE LA ARQUITECTURA 7.1 DATOS Los datos constituyen la información del DWH, se refieren al componente principal de los procesos que llevan a la construcción de la aplicación. Para el análisis de los datos, se comienza por analizar los datos fuentes que manejan los procesos de la empresa, el tipo de la base de datos y la estructura de las tablas. La empresa Ubiquando tiene actualmente un modelo E R en sus sistemas OLTP descrito en la figura 10. Esta base de datos se encuentra implementada en MySQL y es llamada netcontable. En el diagrama (figura 10) únicamente se muestran las relaciones entre las tablas de interés para el datamart (las tablas que se encuentran en negrilla) para dar claridad al diagrama. Figura 10. Diagrama entidad relación de la base de datos netcontable 52

60 Para el datamart desarrollado, se requiere la información relacionada con las ventas. Para este caso en especial las tablas utilizadas de netcontable fueron: TERCERO: Tiene la información referente a los clientes. CIUDAD: Tiene la información referente a las ciudades de los clientes. COMPROBANTE: Tiene información referente a las ventas. Relaciona el cliente y la fecha en que es realizada una venta. Detalle: Tiene la información de los productos relacionados con las ventas y además el valor de la venta. Adicionalmente tiene los siguientes archivos planos: sectores.txt: maneja la información de los sectores a los que pertenecen los clientes. Este archivo tiene la siguiente estructura y datos: ID_Sector Nombre clientes.txt: La información del cliente es manejada en la tabla tercero del modelo E-R. Este archivo tiene la información de los sectores a los que están asociados los clientes. La estructura del archivo es la siguiente. ID_Cliente ID_Sector lineas.txt: tiene la información referente a las líneas a las que pertenecen los productos. El archivo tiene la siguiente estructura: ID_Linea Nombre productos.txt: Este archivo tiene la información de los productos que ofrece la empresa. La información de estos productos se almacenaba inicialmente en la BD fuente de la empresa y se manejaba a través de los sistemas OLTP, pero esta (Ubiquando) hizo una labor de limpieza de datos para organizar mejor los productos que esta ofreciendo actualmente. Estos productos se registran actualmente en un el archivo productos.txt. El archivo tiene la siguiente estructura: ID_Producto Nombre Mapeo de los datos en el modelo dimensional 53

61 Para cargar de los datos en el modelo dimensional se requiere la información de las tablas del modelo E-R mencionadas anteriormente, y además, para tener la información completa se requiere de los archivos planos. En la siguiente tabla se pueden ver las tablas del modelo dimensional y su respectiva fuente de datos. Tablas del la Estrella dim_geografia dim_sector dim_cliente dim_linea dim_producto dim_tiempo fact_venta Fuente de datos CIUDAD sectores.txt TERCERO, clientes.txt linea.txt producto.txt tiempo.txt COMPROBANTE, DETALLE, ventas.txt Tabla 9. Tabla con destinos y fuentes de datos Los campos de las tablas del modelo dimensional se deben mapear de la siguiente forma: En dim_geografia: geo_idgeografia con el campo codigo de la tabla ciudad. geo_ciudad con el campo nombre de la tabla ciudad. En dim_sector: sec_idsector con el primer campo de los datos almacenados en el archivo sector.txt. sec_descripcion con el segundo campo de los datos almacenados en el archivo sector.txt. sec_subcategoria con el tercer campo de los datos almacenados en el archivo sector.txt. En dim_cliente : cli_idcliente con el campo ID de la tabla tercero. cli_nombre con el campo nombre de la tabla tercero. cliidgeografia con el campo ciudad de la tabla tercero. cliidsector con el segundo campo de los datos almacenados en el archivo clientes.txt dim_linea lin_idlinea con el primer campo de los datos almacenados en el archivo lineas.txt lin_descripcion con el segundo campo de los datos almacenados en el archivo lineas.txt dim_producto pro_idproducto con el primer campo de los datos almacenados en el archivo productos.txt 54

62 pro_descripcion con el segundo campo de los datos almacenados en el archivo productos.txt. proidlinea con el primer campo de los datos almacenados en el archivo productos.txt. dim_tiempo La información se carga de un archivo que contiene registrados los días, meses, trimestres, semestres y años correspondientes a los desde el 2004 al Este archivo es estático pues es cargado una sola vez en la bodega y no actualiza temporalmente como los otras tablas de la bodega. fact_venta venidcliente con el campo tercero de la tabla comprobante venidproducto con el campo ref de la tabla detalle venidtiempo con el campo creacion de la tabla comprobante ven_valor con el campo valor de la tabla detalle. En la figura 11 se resumen las fuentes y destinos de los datos que componen el datamart de ventas de Ubiquando. Siguiendo la figura mencionada se puede tener con mayor claridad en la forma que se realizó el proceso de extracción y carga de la bodega. Figura 11. Diagrama de mapeo de los datos. Las tablas en negrilla indican archivos o bases de datos fuentes, las demás son las tablas destino del modelo dimensional 55

63 7.2 BACK ROOM Es el área del DWH responsable de extraer y preparar los datos. Aquí se explicará como se realizo el proceso ETL en la bodega. Se parte de los datos fuentes en los sistemas de información de la empresa. Una de las políticas del datawarehousing es no modificar los sistemas de la empresa pues se estarían alterando sus procesos de negocios y de esta forma los procesos OLTP. Extracción: La empresa Ubiquando maneja la base de datos Mysql en sus sistemas de información. En el proyecto se hizo una extracción de las tablas que interesan para el desarrollo de la estrella, estas tablas fueron : tercero, comprobante, ciudad y detalle. Además de las tablas, también se hace extracción de los archivos fuentes pues la información que estos tienen es fundamental para la información que contendrá la estrella. La herramienta de ETL fue desarrollada por el grupo del proyecto. Se probaron algunas herramientas libres de ETL y las pruebas en pilotos fueron exitosas pero al momento de colocarlas en un ambiente de producción no se adaptaron a las necesidades del sistema que se necesitaba implementar. Para esta herramienta se utilizaron conexiones JDBC que me permiten seleccionar los registros y guardarlos en unas tablas temporales, esta práctica con JDBC permite tener un mejor control de las tablas y así poder obtener solo los campos que interesan. En los clientes, por ejemplo, solo se requiere guardar en la temporal cliente el ID y el nombre, datos como el telefono y el no son necesarios en la tabla temporal. Transformación: Para la transformación de los datos se hizo el mapeo descrito en la sección Para entender mejor la transformación se puede ver que las tablas temporales (Figura XXXX) no tienen una estructura exactamente igual a las tablas fuente pues solo se hizo la extracción de los datos que interesaban, de esta forma se hicieron las transformaciones. Carga: Luego de tener los datos transformados en las tablas temporales y los archivos de texto listos, se hace el proceso de carga en la estrella o modelo dimensional que consiste en tomar estos datos fuentes y guardarlos en la estrella de tal forma que queden listos para que se puedan utilizar herramientas OLAP o de Análisis Multidimensional. Finalmente, los datos extraídos y transformados son cargados en la base de datos del modelo dimensional de la figura XXXXX. 7.3 FRONT ROOM El datamart de ventas de Ubiquando está estructurado de forma que se puede ver la información multidimensional de las ventas con respecto a los clientes, sectores de clientes, productos, líneas de producto y en medidas de tiempo (por día, mes, trimestre, semestre y año). Para mayor información de los reportes ver sección

64 Respecto a los reportes también se puede decir que serán actualizados semanalmente, cuando el usuario ejecute la aplicación de carga para actualizar la información contenida en la bodega. 7.4 INFRAESTRUCTURA DE DATA WAREHOUSE Las bases de datos y los servidores OLAP se ejecutan sobre maquinas de configuración muy similar, por esta razón se puede ver que tanto los servidores de BD como los servidores OLAP tiene la siguiente configuración: Sistema Operativo: Fedora Core1. Memoria RAM: 512 megas con capacidad para correr en maquinas de 256 megas. Disco Duro: 60 Gb. Procesador: Pentium 4 de 2.4Ghz. Una plataforma con esta capacidad tiene la facultad de soportar las BD Postgresql y MySQL, la herramienta de ETL desarrollada en JAVA y el servidor OLAP Jpivot- Mondrian. La BD de los sistemas de información de la empresa esta montada sobre MySQL y la bodega en PostgreSQL. 57

65 8. PROCESO DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA El proceso de extracción, transformación y carga (ETL) es el responsable de llevar a cabo el plan de mapeo descrito en la sección Para este proceso se extraen los datos fuente que se encuentran en la base de datos netcontable descrita en la sección 7.1 y de los archivos de texto descritos en la misma sección. Se realizan las transformaciones requeridas en cada caso y finalmente se cargan los datos en la base de datos donde se encuentra el modelo dimensional. 8.1 HERRAMIENTA DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA Para el proyecto se determinó la necesidad de desarrollar una herramienta de ETL debido a la falta de soporte para las necesidades de extracción y transformación del proyecto por parte de las herramientas disponibles en la comunidad de software libre. La herramienta es desarrollada en java y cumple con la única función de extraer los datos de las fuentes determinadas (sección 7.1), realizar las transformaciones requeridas a los datos y cargar los datos al modelo dimensional implementado en PostgreSQL. Para mantener una consistencia en las referencias, primero se procesan las dimensiones independientes (sector, línea, geografía) que son las que poblan sus respectivas tablas de la base de datos dimensional (dim_sector, dim_linea, dim_geografia) directamente, sin realizar ninguna asociación a ninguna otra tabla ni transformaciones necesarias. Luego se poblan las dimensiones producto y cliente y por último la dimensión tiempo y la tabla de hechos. En las siguientes secciones se describe el proceso realizado para poblar cada una de estas tablas. Para más detalles de la herramienta y su proceso realizado ver anexo Manual Administrador sección ETL de dimensión sector Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en el archivo sectores.txt a la dimensión dim_sector. En este método, lo primero que se hace es borrar de la tabla dim_sector de la bodega todo lo que halla, para luego cargar en esa misma tabla los datos que se encuentren en el archivo sectores.txt. Por lo tanto, si se hiciese algún cambio en el archivo de sectores, al realizar la siguiente carga, la información del archivo sectores.txt actualizada reemplaza a la que se había cargado previamente ETL de dimensión línea 58

66 Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en el archivo lineas.txt a la dimensión dim_linea. En este método, lo primero que se hace es borrar de la tabla dim_linea de la bodega todo lo que halla, para luego cargar en esa misma tabla los datos que se encuentren en el archivo lineas.txt. Por lo tanto, si se hiciese algún cambio en el archivo de líneas, al realizar la siguiente carga, la información del archivo lineas.txt actualizada reemplaza a la que se había cargado previamente ETL de dimensión geografía Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en la base de datos netcontable en la tabla ciudad. Los campos extraídos de esta tabla son codigo y nombre. Estos campos son extraídos y cargados a una tabla temporal llamada ciudad, encontrada en la base de datos martventas (nombre de la base de datos del diagrama multidimensional figura 5) de PostgreSql. ciudad es independiente y se encuentra aislada del diagrama estrella de la bodega. En esta tabla se realizan las transformaciones que sean necesarias, para luego cargar los datos de esta tabla temporal a la tabla dim_geografia. Todos los datos de la tabla dim_geografia son borrados antes de cargar los nuevos datos de la tabla temporal. Y los datos de esta tabla temporal son borrados luego de realizar el proceso ETL de dimensión producto Este proceso tiene como objetivo extraer, transformar y cargar los datos fuentes, encontrados en el archivo productos.txt a la dimensión dim_producto. En este método, lo primero que se hace es borrar de la tabla dim_producto de la bodega todo lo que halla. Luego se leen los datos del archivo de texto y se hace la transformación para asignarle una llave foránea a cada producto, que indique su pertenencia a una línea ETL de dimensión cliente Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en la base de datos netcontable en la tabla tercero y el archivo clientes.txt. Los campos extraídos de la tabla tercero son id, nombre y ciudad. Primero se borran todos los datos existentes en la tabla dim_cliente y luego se insertan los datos encontrados en las fuentes. Los campos cli_idcliente, cli_nombre y cli_ciudad de la tabla destino dim_cliente son tomados de netcontable; y el campo cli_idsector que relaciona a un cliente con un sector, tiene como fuente el archivo clientes.txt. Son necesarias estas dos fuentes, pues en la base de datos netcontable no se establece correctamente le pertenencia del cliente a un sector, por lo tanto se requiere este archivo adicional ETL tabla de hechos 59

67 Este proceso tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes a la tabla de hechos fact_venta. Dado que durante el proceso de desarrollo del proyecto, la empresa Ubiquando realizó un cambio en su base de datos netcontable para registrar correctamente los productos asociados a una factura (es decir a una venta), fue necesario realizar dos procesos distintos para la carga de esta tabla, uno antes de realizar este cambio y otro para después de haber realizado el cambio. Para el primer escenario, en el que los productos no están bien relacionados a cada venta registrada en la base de datos netcontable en la tabla comprobante, se tiene el archivo ventas.txt. Los campos extraídos de la tabla comprobante son numero, creacion, tercero y total. Los elementos del archivo de texto son: el número de factura y el código del producto vendido en esa factura. Para realizar el proceso ETL de esta tabla, se crea una tabla temporal llamada comprobante en la base de datos martventas. Esta tabla es independiente del diagrama estrella de la bodega, solo se utiliza para hacer las transformaciones requeridas antes de insertar los datos en la tabla fact_venta de la bodega. En esta tabla temporal se insertan los datos extraídos de todos los registros de la tabla comprobante de la base de datos netcontable. Luego de haber extraído los datos, se borran todos los datos de la tabla fact_venta y se poblan con los nuevos. Para el segundo escenario, en el que los productos sí se relacionan correctamente en la base de datos con cada venta registrada, no se utiliza el archivo ventas.txt. En su lugar, se utiliza la tabla detalle de la base de datos netcontable. Esta tabla contiene datos sobre cada producto incluido en una factura y se extraen los campos: n_comp, secuencial, ref y valor. Los campos extraídos de la tabla comprobante son numero, creación y tercero. En este caso el campo total no es extraído de comprobante dado que el dato sobre el valor del producto vendido se extrae del campo valor de la tabla tercero. Para realizar el proceso ETL de esta tabla, se crea una tabla temporal llamada comprobante y una tercero en la base de datos martventas. Estas tablas son independientes del diagrama estrella de la bodega; solo se utilizan para hacer las transformaciones requeridas antes de insertar los datos en la tabla fact_venta de la bodega. En estas tablas temporales se insertan los datos extraídos de todos los registros de la tabla comprobante y sus tablas asociadas detalle, que hallan sido ingresados después de la fecha en que se realizó el cambio en el registro de las ventas con productos de la base de datos fuente netcontable. Luego de haber extraído los datos, se borran todos los datos de la tabla fact_venta y se poblan con los nuevos. Los datos de las tablas temporales son borrados al final del proceso de carga. 60

68 9. CONSTRUCCIÓN DEL CUBO El análisis OLAP de la solución es realizado con la herramienta Mondrian (ver sección 2.3). Por lo tanto, el cubo que refleja el diseño del modelo dimensional del datamart será construido de acuerdo a los requerimientos de Mondrian para tal fin. Se deben crear dos archivos para utilizar un cubo en Mondrian, en las siguientes secciones se describen las estructuras de estos archivos. Para conocer más detalles de la creación de estos archivos, ver anexo Manual de Administrador. Luego de haber establecido las estructuras de estos archivos, un usuario puede navegar por estas estructuras (dimensiones, atributos y medidas) de forma intuitiva e interactiva, utilizando únicamente el Mouse desde la interfaz gráfica ofrecida por Mondrian Jpivot. Mondrian maneja dimensiones, niveles, categorías y medidas. Las Dimensiones (tiempo, producto, etc.) están compuestas por niveles, que representan la jerarquía establecida por las estructuras organizacionales y los modelos de datos de la organización. Estas determinan la ruta posible de drill down y drill up en la herramienta Olap, Mondrian. Los valores que toma cada nivel son conocidos como las categorías. Las Medidas representan los indicadores de gestión del negocio para analizar (datos numéricos). 9.1 ARCHVIVOS JSP El archivo JSP es utilizado para definir la ruta y una consulta inicial de un cubo Mondrian. Las siguientes líneas de código son las líneas esenciales para establecer esta ruta. <%-- Archivo martventas.jsp --%> <jp:mondrianquery id="query01" jdbcdriver="org.postgresql.driver" jdbcurl="jdbc:postgresql://localhost/martventas" cataloguri="/web-inf/queries/martventas.xml" jdbcuser="postgre" jdbcpassword=""> select {[Measures].[Valor]} on columns, {[Producto]} ON rows from cuboventas Figura 12. Líneas del archivo jsp 61

69 La primera línea indica la ruta en donde se encuentra la base de datos dimensional que soporta el datamart. Esta base de datos, implementada en PostgreSQL se llama martventas e implementa el modelo de copo de nieve definido en la sección 6.5. La segunda línea indica la ruta donde se encuentra el archivo XML que define las estructuras (ver sección 9.2) del cubo. En el caso de este proyecto, este archivo XML es llamado martventas.xml. La tercera línea indica el nombre de usuario y contraseña del usuario que tiene acceso a la base de datos del modelo dimensional. Las últimas líneas definen una consulta MDX (Ver sección 2.3.4) que será la consulta predeterminada del datamart. Esta consulta muestra el valor de ventas para el total de productos. 9.2 ESTRUCTURAS XML Mondrian, para entenderse con la base de datos diseñada con el modelo dimensional, usa un archivo xml en el cual se describen las dimensiones, medidas y cubos que se usan en el proceso de análisis multidimensional del datamart de ventas de Ubiquando. En estas descripciones se asocian los nombres de los campos de la base de datos. El archivo XML que define las dimensiones y la medida usados en el cubo que soporta el datamart de Ubiquando es como sigue: <%-- Archivo martventas.xml --%> <?xml version="1.0"?> <Schema name="martventas"> <Cube name="cuboventas"> <Table name="fact_venta"/> <Dimension name="segmento" foreignkey="venidcliente"> <Hierarchy hasall="true" primarykeytable="dim_cliente" primarykey="cli_idcliente"> <Join leftkey="cliidsector" rightkey="sec_idsector"> <Table name="dim_cliente"/> <Table name="dim_sector"/> </Join> <Level name="sector" table="dim_sector" column="sec_descripcion" uniquemembers="true"/> <Level name="subcategoria" table="dim_sector" column="sec_subcategoria" uniquemembers="true"/> <Level name="cliente" table="dim_cliente" column="cli_nombre" uniquemembers="true"/> </Hierarchy> </Dimension> <Dimension name="ciudad" foreignkey="venidcliente"> <Hierarchy hasall="true" primarykeytable="dim_cliente" primarykey="cli_idcliente"> <Join leftkey="cliidgeografia" rightkey="geo_idgeografia"> <Table name="dim_cliente"/> <Table name="dim_geografia"/> </Join> <Level name="ciudad" table="dim_geografia" column="geo_ciudad" uniquemembers="true"/> 62

70 uniquemembers="true"/> <Level name="cliente" table="dim_cliente" column="cli_nombre" </Hierarchy> </Dimension> <Dimension name="producto" foreignkey="venidproducto"> <Hierarchy hasall="true" primarykeytable="dim_producto" primarykey="pro_idproducto"> <Join leftkey="proidlinea" rightkey="lin_idlinea"> <Table name="dim_producto"/> <Table name="dim_linea"/> </Join> <Level name="linea" table="dim_linea" column="lin_descripcion" uniquemembers="true"/> <Level name="producto" table="dim_producto" column="pro_descripcion" uniquemembers="true"/> </Hierarchy> </Dimension> <Dimension name="tiempo" foreignkey="venidtiempo"> <Hierarchy hasall="true" primarykey="tie_idtiempo"> <Table name="dim_tiempo"/> <Level name="ano" column="tie_ano" uniquemembers="true"/> <Level name="semestre" column="tie_semestre" uniquemembers="true"/> <Level name="trimestre" column="tie_trimestre" uniquemembers="true"/> <Level name="mes" column="tie_mes" uniquemembers="true"/> <Level name="dia" column="tie_dia" uniquemembers="true"/> </Hierarchy> </Dimension> <Measure name="valor" column="ven_valor" aggregator="sum" formatstring="#,###"/> </Cube> </Schema> Figura 13. Código de la estructura del cubo Este archivo debe estar referenciado en todos los archivos jsp que contengan una consulta MDX, que estará basada en la información de este archivo. Todas las consultas MDX que se hacen en el datamart, se hacen sobre los datos almacenados en el cubo descrito en el documento. El archivo martventas.xml une las dos partes básicas de la construcción del cubo: la definición de dimensiones y la del cubo. Se establecen estas dos partes en la misma estructura pues en este caso no se comparten las dimensiones con varios cubos, pues se desarrolla únicamente el de ventas. Se emplea el esquema de Dimensiones propias de cubos. El esquema de Dimensiones propias de cubos, se especifica al interior de los tags <Cube>, para hacer que solo ese cubo use cada dimensión. El cubo es definido para soportar el diagrama dimensional. Un cubo es un conjunto de dimensiones y medidas. Las dimensiones son la forma por la cual se quiere ver la medida, y la medida es un valor numérico que mide un hecho objeto del análisis. En las próximas secciones se explicará detalladamente el cubo, dimensiones y medidas usadas en este archivo xml Estructura del cubo 63

71 En el proyecto y específicamente en los esquemas de Mondrian el cubo diseñado se define como martventas. Este cubo se compone de varias dimensiones y de una medida: Nombre del cubo: martventas Nombres dimensiones: segmento, ciudad, linea, producto y tiempo. Nombre tabla de hechos (fact table): fact_venta El cubo se basa en la tabla de hechos fact_venta. En este cubo se almacena información sobre una venta, relacionándola con el producto, cliente y tiempo en el cual ocurre esta venta. Además existen las dimensiones dim_sector y dim_linea que categorizan a los clientes y los productos respectivamente. Este cubo está diseñado para suplir una necesidad de un reporte Diario. Tiene una granuralidad baja debido a que el registro con menor granuralidad es una sola venta a un cliente de un solo producto. La estrategia para poblar este cubo consiste en extraer los datos necesarios de diferentes fuentes y cargarlos a cada dimensión como se describe en la sección Estructura de la dimensión Segmento La dimensión Segmento es usada para analizar las ventas según los segmentos de clientes de Ubiquando. Esta dimensión está asociada directamente a la dimensión cliente, por lo tanto es un tipo de clasificación de clientes, la otra forma de clasificarlos es por la ciudad. Esta forma se describe en la siguiente sección. En esta dimensión se manejan tres niveles: sector, subcategoría y cliente. Por lo tanto, se puede hacer drill down y drill up para navegar a través de los niveles y de esta forma modificar una consulta, para restringir una búsqueda a una categoría general, una subcategoría de esta o clientes específicos de las subcategorías. Esta dimensión se define en el código de la siguiente forma: <Dimension name="segmento" foreignkey="venidcliente"> <Hierarchy hasall="true" primarykeytable="dim_cliente" primarykey="cli_idcliente"> <Join leftkey="cliidsector" rightkey="sec_idsector"> <Table name="dim_cliente"/> <Table name="dim_sector"/> </Join> <Level name="sector" table="dim_sector" column="sec_descripcion" uniquemembers="true"/> <Level name="subcategoria" table="dim_sector" column="sec_subcategoria" uniquemembers="true"/> <Level name="cliente" table="dim_cliente" column="cli_nombre" uniquemembers="true"/> </Hierarchy> </Dimension> Figura 14. Estructura dimensión segmento 64

72 9.2.2 Estructura de la dimensión Ciudad La dimensión ciudad es usada para analizar las ventas según las ciudades donde se ubican los clientes de Ubiquando. Esta dimensión está asociada directamente a la dimensión cliente, por lo tanto es un tipo de clasificación de clientes, la otra forma de clasificarlos es por el segmento. Esta otra forma se describe en la siguiente anterior. En esta dimensión se manejan dos niveles: ciudad y cliente. Por lo tanto, se puede hacer drill down y drill up para navegar a través de los niveles y de esta forma modificar una consulta, para restringir una búsqueda a una ciudad general o clientes específicos de las ciudades. Está definida de la siguiente forma: <Dimension name="ciudad" foreignkey="venidcliente"> <Hierarchy hasall="true" primarykeytable="dim_cliente" primarykey="cli_idcliente"> <Join leftkey="cliidgeografia" rightkey="geo_idgeografia"> <Table name="dim_cliente"/> <Table name="dim_geografia"/> </Join> <Level name="ciudad" table="dim_geografia" column="geo_ciudad" uniquemembers="true"/> <Level name="cliente" table="dim_cliente" column="cli_nombre" uniquemembers="true"/> </Hierarchy> </Dimension> Figura 15. Estructura dimensión ciudad Estructura de la dimensión Producto La dimensión producto permite analizar las ventas por producto. Debido a que Ubiquando tiene muchos productos, se tiene otro nivel llamado dim_linea que clasifica los productos en líneas de productos. En esta dimensión se manejan dos niveles: línea, y producto. Por lo tanto, se puede hacer drill down y drill up para navegar a través de los niveles y de esta forma modificar una consulta, para restringir una búsqueda a una línea general, o productos específicos de cada línea. Está definida de la siguiente forma: <Dimension name="dim_producto" foreignkey="venidproducto"> <Hierarchy hasall="true" primarykeytable="dim_producto" primarykey="pro_idproducto"> <Join leftkey="proidlinea" rightkey="lin_idlinea"> <Table name="dim_producto"/> <Table name="dim_linea"/> </Join> <Level name="linea" table="dim_linea" column="lin_descripcion" uniquemembers="true"/> <Level name="producto" table="dim_producto" column="pro_descripcion" uniquemembers="true"/> </Hierarchy> </Dimension> Figura 16. Estructura dimensión producto 65

73 9.2.4 Estructura de la dimensión tiempo La dimensión tiempo es la dimensión más importante de todas las dimensiones en cualquier proceso de análisis multidimensional. Es decir, todos los analistas por lo general desean ver su información discriminada por meses, semanas días, o años. Es por esto que esta dimensión contiene toda la información referente al tiempo. Es decir, un día determinado a que mes, trimestre, semestre y año pertenece, para poder ser agrupado por estos niveles. Tiene cuarto niveles por los que se puede hacer drill down y drill up que son año, semestre, trimestre, mes y día. Esta definida de la siguiente forma: <Dimension name="dim_tiempo" foreignkey="venidtiempo"> <Hierarchy hasall="true" primarykey="tie_idtiempo"> <Table name="dim_tiempo"/> <Level name="ano" column="tie_ano" uniquemembers="true"/> <Level name="semestre" column="tie_semestre" uniquemembers="true"/> <Level name="trimestre" column="tie_trimestre" uniquemembers="true"/> <Level name="mes" column="tie_mes" uniquemembers="true"/> <Level name="dia" column="tie_dia" uniquemembers="true"/> </Hierarchy> </Dimension> Figura 17. Estructura dimensión tiempo 66

74 10. REPORTES IMPLEMENTADOS Los reportes implementados cumplen con los requerimientos planteados en el capítulo 5 acordados con Ubiquando. Su implementación está hecha sobre Mondrian, y con el uso de su interfaz gráfica es posible ver estos reportes y analizar la información con tablas de datos o gráficas de diversos tipos (barras, pies, líneas, etc). Para este análisis de información se dan diferentes posibilidades de navegación, como el drill up y drill down. Además es posible analizar solo algunas dimensiones, o incluir a varias para un reporte. También es posible restringir en un análisis a determinados miembros de una dimensión que sean del interés del análisis, en vez de incluir a todos. Para conocer más detalles de la forma de utilizar el análisis OLAP Mondrian ver anexo Manual de administrador. En las siguientes secciones se documentan estos reportes en forma gráfica, aunque en la herramienta también se muestra la tabla de resultados de los datos. Se incluye también el query MDX necesario para realizar los reportes. Es importante notar que no es necesario escribir un query MDX para navegar por el cubo OLAP. Esta navegación puede ser hecha de forma sencilla e interactiva con el usuario usando solo el mouse, seleccionando las opciones que se quieren (ver anexo Manual de administrador). Además de los reportes acordados con Ubiquando es posible realizar muchos más, haciendo uso de las características de Mondrian y de las dimensiones implementadas. Se mostrará un solo reporte por página para dar claridad al documento. 67

75 10.1 VENTAS POR PRODUCTOS La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {[Measures].[Valor]} ON columns, NON EMPTY Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)) ON rows from [cuboventas] Figura 18. Consulta MDX Ventas por productos Figura 19. Resultados gráficos del reporte Ventas por productos Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas ventas por sus líneas de productos. Al hacer drill down se exploran las ventas por productos individuales. En esta consulta la medida es el valor de la venta en la columna y los productos en las filas. 68

76 10.2 VENTAS POR CLIENTE La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {[Measures].[Valor]} ON columns, NON EMPTY Hierarchize(Union({[Segmento].[All Segmentos]}, [Segmento].[All Segmentos].Children)) ON rows from [cuboventas] Figura 20. Consulta MDX Ventas por cliente Figura 21. Resultados gráficos del reporte Ventas por cliente Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas ventas por sus sectores de clientes. Al hacer drill down se exploran las ventas por clientes individuales. En esta consulta la medida es el valor de la venta en la columna y los clientes en las filas. 69

77 10.3 VENTAS POR TIEMPOS La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {[Measures].[Valor]} ON columns, NON EMPTY {[Tiempo].[All Tiempos]} ON rows from [cuboventas] Figura 22. Consulta MDX Ventas por tiempos Figura 23. Resultados gráficos del reporte Ventas por tiempos Esta consulta permite explorar el valor de las ventas de Ubiquando, discriminando estas ventas por las fechas de venta. Al hacer drill down se limita más el criterio del reporte, permitiendo analizar las ventas por año, semestre, trimestre y día. En esta consulta la medida es el valor de la venta en la columna y los tiempos en las filas. 70

78 10.4 VENTAS DE PRODUCTOS POR CLIENTE La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY Crossjoin(Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)), {[Measures].[Valor]}) ON columns, NON EMPTY Hierarchize(Union({[Segmento].[All Segmentos]}, [Segmento].[All Segmentos].Children)) ON rows from [cuboventas] Figura 24. Consulta MDX Ventas de productos por cliente Figura 25. Resultados gráficos del reporte Ventas de productos por cliente Se Compara el cruce de la dimensión Producto y la dimensión Cliente (con medida valor, las medidas en mondrian son vistas como una dimensión aparte, que se llama [Measures]). 71

79 10.5 VENTAS POR PRODUCTOS EN EL TIEMPO La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {([Tiempo].[All Tiempos], [Measures].[Valor])} ON columns, NON EMPTY Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)) ON rows from [cuboventas] Figura 26. Consulta MDX Ventas por productos en el tiempo Figura 27. Resultados gráficos del reporte Ventas por productos en el tiempo Con esta consulta que utiliza las propiedades children y Crossjoin descritas en el numeral 1.4, se permite analizar las ventas de las líneas de producto y los productos específicamente en los tiempos requeridos por el usuario. Es posible analizar a todos los productos en el tiempo que varía en año, semestre, trimestre y día. También se explora el interior de cada línea de producto o por producto individual en estas secciones de tiempo. Esta consulta se compone del valor en la columna y de las dimensiones producto y tiempo en las filas. 72

80 10.6 VENTAS POR CLIENTE EN EL TIEMPO La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {([Tiempo].[All Tiempos], [Measures].[Valor])} ON columns, NON EMPTY Hierarchize(Union({[Segmento].[All Segmentos]}, [Segmento].[All Segmentos].Children)) ON rows from [cuboventas] Figura 28. Consulta MDX Ventas por cliente en el tiempo Figura 29. Resultados gráficos del reporte Ventas por cliente en el tiempo Con esta consulta que utiliza las propiedades se permite analizar las ventas a los segmentos de cliente y los clientes específicamente en los tiempos requeridos por el usuario. Es posible analizar las ventas a todos los clientes en el tiempo que varía en año, semestre, trimestre y día. También se explora el interior de cada segmento de cliente o por cliente individual en estas secciones de tiempo. Esta consulta contiene el valor en la columna y la dimensión cliente y tiempo en las filas. 73

81 10.7 VENTAS POR CLIENTE Y PRODUCTO EN EL TIEMPO La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {([Tiempo].[All Tiempos], [Measures].[Valor])} ON columns, NON EMPTY Hierarchize(Crossjoin({[Producto].[All Productos]}, Union({[Segmento].[All Segmentos]}, [Segmento].[All Segmentos].Children))) ON rows from [cuboventas] Figura 30. Consulta MDX Ventas por cliente y producto en el tiempo Figura 31. Resultados gráficos del reporte Ventas por cliente y producto en el tiempo La consulta comprende una unión entre las dimensiones sector, producto y tiempo del cubo para dar respuesta a una consulta de tipo ventas por cliente y producto vendido en esa venta en cierto segmento del tiempo. Es posible analizar las ventas de cierta línea de productos o de un producto a un segmento de clientes o a un cliente específico en un año, semestre, trimestre o día determinado. Esta consulta se compone de las dimensiones producto y cliente en las filas y tiempo y valor en las columnas. 74

82 10.8 VENTAS POR CIUDAD La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY {[Measures].[Valor]} ON columns, NON EMPTY {[Ciudad].[All Ciudads]} ON rows from [cuboventas] Figura 32. Consulta MDX Ventas por ciudad Figura 33. Resultados gráficos del reporte Ventas por ciudad Esta consulta permite ver el valor de las ventas en las diferentes ciudades donde Ubiquando tiene clientes. Esta consulta se compone de las dimensiones geografía en las filas y valor en las columnas. 75

83 10.9 VENTAS POR PRODUCTOS EN CIUDADES La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY Crossjoin(Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)), {[Measures].[Valor]}) ON columns, NON EMPTY Hierarchize(Union({[Ciudad].[All Ciudads]}, [Ciudad].[All Ciudads].Children)) ON rows from [cuboventas] Figura 34. Consulta MDX Ventas por productos en ciudades Figura 35. Resultados gráficos del reporte Ventas por productos en ciudades Esta consulta permite ver el valor de las ventas correspondiente a cada línea de producto o a cada producto individual (al hacer drill down) por cada ciudad. Esta consulta se compone de las dimensiones geografía en las filas y producto y valor en las columnas. 76

84 10.10 VENTAS POR CIUDAD EN EL TIEMPO La consulta MDX que soporta este reporte es la siguiente: select NON EMPTY Crossjoin(Hierarchize(Union({[Tiempo].[All Tiempos]}, [Tiempo].[All Tiempos].Children)), {[Measures].[Valor]}) ON columns, NON EMPTY Hierarchize(Union({[Ciudad].[All Ciudads]}, [Ciudad].[All Ciudads].Children)) ON rows from [cuboventas] Figura 36. Consulta MDX Ventas por ciudad en el tiempo Figura 37. Resultados gráficos del reporte Ventas por ciudad en el tiempo Esta consulta permite ver el valor de las ventas en las ciudades en los diferentes instantes de tiempo. Esta consulta se compone de las dimensiones geografía en las filas y tiempo y valor en las columnas. 77

85 9. MANTENIMIENTO Y CRECIMIENTO DEL DATAMART Luego de pasar exitosamente la etapa de pruebas de todo proyecto de software y ser aceptado por el cliente final, el DWH está actualmente en producción. Los directivos de la empresa lo recibieron con mucho entusiasmo y satisfacción. Tanto ellos como el grupo del desarrollo del proyecto están convencidos de haber hecho un producto de excelente calidad, pues se rigió por una metodología especializada para la materia, que siguiéndose con prudencia iba a garantizar el éxito del proyecto. También se realizó una capacitación en el uso del producto, confirmando la aceptación y acogida que tuvo el proyecto. Esta capacitación fue rápida, pues Jpivot-Mondrian es muy fácil y orientada al usuario, característica fundamental que permitió facilitar el trabajo. En cuanto al mantenimiento y crecimiento de la bodega, se puede decir que se harán actualizaciones semanales, condición impuesta por los ejecutivos de la empresa, para mantener datos al día y disponibles para cualquier momento que se necesiten. En cuanto al crecimiento, la tabla que crecería con mayor incremento es la tabla de fact_venta de la bodega de datos. No existe ningún riesgo que estos datos se pierdan o entren en conflicto en la aplicación, la base de datos PostgreSQL garantiza que soporta la cantidad de información que puede ser generada por la empresa en los negocios que se enfrentaran mas adelante. 78

86 CONCLUSIONES El data warehouse es mucho más que un producto. Es una serie de productos relacionados entre sí que por medio de procesos bien definidos producen información útil para los usuarios. Para que una solución de este tipo realmente tenga éxito, los usuarios deben aprovechar esta información y ejecutar decisiones y acciones basadas en el conocimiento adquirido. Para que un proyecto de data warehousing tenga éxito es necesario que exista una cultura de información en la organización. Si las decisiones son tomadas basadas en intuiciones y suposiciones y no hay disposición al cambio, un proyecto de data warehouse está destinado a fracasar en la organización. El desarrollo óptimo del proceso de implementación del data warehouse se encuentra estrechamente relacionado con la existencia de patrocinadores dentro de la organización. Si no se cuenta con patrocinadores en el área del negocio y en el área técnica es preferible posponer un proyecto. Es esencial el manejo de roles en el equipo de desarrollo de un proyecto de data warehouse, de esta manera hay fluidez y especialización en los miembros del equipo que implica una mayor eficiencia y calidad del trabajo. El proceso con más dificultades en un proyecto de data warehouse es el de recolección de requerimientos y análisis de los sistemas fuente. En las empresas existe un alto volumen de inconsistencias en los datos y falta de documentación de sus sistemas de información. Un datamart permite servir a un área del negocio como lo haría una bodega a varias áreas. La especialización del datamart tiene un enfoque hacia la necesidad de un área específica, que facilita la definición de la granularidad de los datos utilizados y sus dimensiones. El uso de software libre en inteligencia de negocios tiene la ventaja de ser desarrollado a la medida de las necesidades de una organización. Por lo tanto ofrece un análisis más personalizado y con menores restricciones que el llevado a cabo con herramientas comerciales, a las cuales se debe ajustar el negocio. Con el software libre, la solución es la que se ajusta al negocio. Dada la madurez y fortaleza de las herramientas libres utilizadas en este proyecto, se llega a competir en iguales condiciones en términos de funcionalidad, rendimiento y fortaleza con las herramientas comerciales tradicionales del data warehousing. 79

87 Aunque existe una documentación limitada de las herramientas de software libre, existen foros mundiales sobre estas herramientas compuestos por personas de la comunidad libre, que dan soporte efectivo a desarrolladores y usuarios de estas herramientas. La estructura de una base de datos de inteligencia de negocios es esencial para el éxito de un proyecto de este tipo. Aunque la estructura de entidad relación funciona correctamente para almacenar datos operativos, es totalmente impropia para estas soluciones. Se debe seleccionar ya sea un modelo en estrella o copo de nieve para un data warehouse dependiendo de las necesidades del negocio. Este modelo es utilizado dado que refleja las necesidades de un negocio en términos de soporte a toma de decisiones. El análisis OLAP es adecuado para el análisis de una bodega de datos, dado que permite relacionar a una o varias medidas con atributos vistos como dimensiones, analizando los aspectos importantes y determinantes para el éxito de un negocio. El análisis OLAP realizado con Mondrian es similar al realizado con herramientas comerciales del mismo tipo, ofreciendo la misma funcionalidad y rendimiento. Aunque la construcción y definición de dimensiones y cubos requiere conocimientos técnicos más avanzados que con las otras herramientas, una vez implementados, la facilidad de uso para el usuario es evidente. Más que una solución para reducir costos, el data warehouse debe ser visto como una solución para incrementar ingresos y ventas. Sus resultados se perciben como beneficios económicos para una empresa en términos de mediano y largo plazo. Dada la proximidad del tratado de libre comercio, negociado actualmente por Colombia, es necesario el uso de la inteligencia de negocios para aprovechar nuevos mercados y fortalecer la posición ocupada en el mercado actual por las empresas colombianas. El uso de estas herramientas mejorará la competitividad de las empresas y las hará más eficientes. Las pymes, tradicionalmente alejadas de soluciones tecnológicas por sus altos costos, se acercan cada vez más a una competencia de igual a igual con grandes empresas inteligentes, dada la disminución de costos en hardware y a la implantación de soluciones de software libre como la de este proyecto. El presupuesto de las empresas para su área tecnológica se encuentra en crecimiento cada año, por lo que existe un mercado potencial para soluciones de inteligencia de negocios. 80

88 RECOMENDACIONES En un proyecto de data warehouse se deben confrontar los requerimientos del negocio con el área técnica, para determinar si existen las fuentes de datos para dar soporte a los requerimientos planteados. De esta forma no ofrecer reportes imposibles de cumplir en el proyecto. Un data warehouse es tan confiable como sus datos fuentes. Por lo tanto, se debe determinar la confiabilidad y disponibilidad de estos datos, y si existe un mismo dato en diversas fuentes, extraerlo de la fuente que sea más confiable. Al iniciar un proyecto de data warehouse se deben identificar y mantener sponsors del proyecto al interior de la organización. Si no se identifican, es mejor posponerlo o buscar el apoyo. Se deben identificar justificadores del negocio al iniciar un proyecto de data warehouse, esto es justificar el proyecto desde un punto de vista financiero con un retorno sobre la inversión. De esta manera aumentará el entusiasmo hacia el proyecto de la organización. En Colombia hay miles de pymes, todas ellas son un cliente potencial para esta solución. Por lo tanto se deben aprovechar sus necesidades de información y el bajo costo de esta solución para cubrir este mercado. 81

89 GLOSARIO DWH: Por el inglés Data warehouse. Es una bodega de datos. Datamart: subconjunto especializado de una bodega de datos. Los diferentes datamarts contienen diferentes combinaciones y selección de los mismos datos detallados identificados en la bodega de datos, por esto puede decirse que los datamarts vienen a ser como una extensión natural de la bodega de datos. JDBC: Java Database Connectivity, API de Java que permite hacer conexiones a bases de datos para manipular la información que están contienen. Metadata: Información sobre los datos almacenados en la bodega de datos, permite conocer las fuentes de donde es extraído y reglas de negocio. OLAP: ON LINE ANALYTICAL PROCESSING, tecnología que permite a los usuarios tener una visión de los datos de una forma rápida, interactiva y fácil de usar. OLTP: ON LINE TRANSACTIONAL PROCESSING, las aplicaciones de OLTP están organizadas para ejecutar las transacciones para los cuales fueron hechos, como por ejemplo: mover dinero entre cuentas, un cargo o abono, una devolución de inventario, etc. Por otro lado, una bodega de datos está organizada en base a conceptos, como por ejemplo: clientes, facturas, productos, etc. Query: Consultas sobre una base de datos o sobre una bodega de datos. Permiten manipular la información de las bases de datos y las bodegas. RDBMS: Manejador de bases de datos relacional. Constituyen la base para los sistemas OLTP. Sistemas Legacy: Sistemas fuente de la empresa con los que manejan la operación de las transacciones diarias. Su característica principal es el enfoque en los procesos de operación diaria de la empresa. 82

90 BIBLIOGRAFÍA [1] Ralph Kimball, The Data Warehouse Toolkit. Wiley. [2] Ralph Kimball, The Data Warehous Lifecycle Toolkit. Wiley. [3] Barry Devlin, Data Warehouse from architecture to implementation. Addison Wesley. [4] IBM Learning Services, Fundamentals of Data Warehouse and Business Intelligence for Knowledge Management. IBM Global Services Group. [5] Richard Connelly, Robin McNeill, Roland Mosimann, The Multidimensional Manager. Cognos Incorporated. [6] Corinne Baragoin, Jorge Bercianos, Janez Komel, Gary Robinson, Richard Sawa, Erik Schuinder, OLAP Server Theory and Practices. IBM Red Books. [7] IBM Learning Services. Business Intelligence Tutorial. IBM Corporation. [8] Jiawei Han, Micheline Kamber, Data Mining: Concepts and Techniques. Morgan Kaufmann Publishers. [9] Julian Hyde, Paul Dymecki, Sean McCullough, Andreas Voss, What is Mondrian? (online). Mondrian Project. [10] PostgreSQL Global Development Group, PostreSQL Documentation. PostgreSQL Global Development Group. [11] William H. Inmon, Building the Data Warehouse.Wiley. [12] Liza Andrea Rojas Rojas, Diseño de un prototipo de bodega de datos para un modelo de empresa de ventas y aplicación de herramientas OLAP. Trabajo de grado (Ingeniero de Sistemas). Universidad Nacional de Colombia. Facultad de Ingeniería. Departamento de Ingeniería de Sistemas. [13] Alexandra Pomares, Business Intelligence. Universidad Javeriana. [14] Kimball Group. About Kimball Group (online). 83

91 ANEXOS ANEXO 1. MANUAL DE ADMINISTRADOR

92 Datamart Ventas Datamart Ventas Ubiquando Manual Administrador Tabla de Contenido 1 Propósito y Alcance 1 2 Conceptos Basicos Sobre Consultas OLAP EL MODELO DIMENSIONAL EN ESTRELLA DEFINICIÓN DE UN CUBO EN XML ANÁLISIS MULTIDIMENSIONAL MDX 12 3 Herramientas para el datamart JAKARTA-TOMCAT POSTGRESQL 20 4 Scripts de carga a la base de datos 22 5 Quienes Pueden Usar La Herramienta? 28 6 Navegando En El Datamart 29 Manual Administrador Versión 1.0

93 1. PROPÓSITO Y ALCANCE El propósito de este documento es describir los conceptos básicos y avanzados del datamart ventas así como sus funcionalidades. Esta dirigido al usuario administrador describiendo características de los lenguajes MDX y de las herramientas de software pre-instaladas para el funcionamiento del datamart. El documento esta limitado a todo lo descrito en la fase de requerimientos del proyecto. 1

94 2. CONCEPTOS BÁSICOS SOBRE CONSULTAS OLAP En este capítulo se verá la teoría detrás del datamart. Este datamart no es una herramienta de reporteo común, se basa en tecnología OLAP para realizar consultas multidimensionales, así que es una herramienta orientada al análisis de datos. Comenzaremos por la capa más baja, que es la de base de datos. Una bodega de datos debe estar orientada al análisis, no al almacenamiento transaccional de los datos. Existen básicamente dos tipos de almacenamientos multidimensionales, y son el M-OLAP y el R-OLAP. El primero se basa en motores de bases de datos especializados para almacenar sus datos en estructuras dimensionales, el segundo se basa en los motores de bases de datos Relacionales comunes. Este segundo modelo es en el que se basa Mondrian, la herramienta implementada en el datamart. 2.1 EL MODELO DIMENSIONAL EN ESTRELLA. Este modelo, es conocido como R-OLAP star schema. R-OLAP por ser utilizado por el análisis OLAP soportado sobre bases de datos Relacionales, de ahí la "R". El modelo propiamente se conoce como estrella, araña o copo de nieve. Este modelo está específicamente diseñado para basarse en el la construcción de hipercubos o cubos de decisión, donde se tiene una serie de dimensiones, temas que interesan a la organización, y todas estas dimensiones rodeando tablas de hechos que son las que registran todos los movimientos o transacciones sobre las cuales se quiere hacer el análisis. Figura 1. Generalidades del modelo estrella 2

95 Las generalidades del modelo son como se muestra en la figura 1, donde se observa que debe existir una tabla de hechos rodeada por las dimensiones asociadas. En las bases de datos que adoptan este modelo, se puede tener una o más estrellas, dependiendo de los hechos que se quieran registrar en las tablas de hechos. La tabla de hechos o "fact table" como se conoce comúnmente, debe tener una estructura que se divide en dos partes: La primera de ellas debe contener las llaves foráneas que van a relacionar a las dimensiones. Es decir, que por cada dimensión que exista asociada a una tabla de hechos, debe aparecer una llave foránea a dicha dimensión. Esto permite que al momento de utilizar los hipercubos se involucre información contenida en los atributos de las dimensiones que no estén almacenados en la tabla de hechos. Después de los campos que tienen las llaves foráneas a las dimensiones, deben aparecer los campos que almacenan la información concreta del registro y particular al problema, y que permiten hacer las sumarizaciones que se requieran en la aplicación. Esto es lo que en el lenguaje de hipercubos se conoce como las Medidas o los Indicadores. Las medidas como su nombre lo indica son las que miden una determinada variable de estudio, y por lo general son cantidades de cosas (cantidades de ventas, de dinero, etc.). La medida utilizada en este proyecto que permite analizar las ventas de Ubiquando, es el valor de venta en pesos. También pueden ser fechas, o en fin, cualquier atributo que sea comparable y medible, y que proporcione información valiosa al realizar los análisis requeridos del negocio. Sin unos buenos indicadores, los resultados de las herramientas de acceso a datos no van a ser muy eficientes. Una vez analizada la tabla de hechos, se continúa con las dimensiones. Cada una de las dimensiones es un tema, que debe tener una llave asociada en la tabla de hechos. Estas dimensiones guardan información en sus atributos que solo le atañe a ella, que no es necesario que deba ir incluida en la tabla de hechos. 2.2 DEFINICIÓN DE UN CUBO EN XML Mondrian utiliza un esquema propio para la generación de los hipercubos, y es en un archivo de extensión.xml. En este archivo se establece el modelo lógico, es decir, las dimensiones, jerarquías, medidas y niveles del cubo, así como el modelo físico, o la relación con la base de datos que soporta dicho modelo. Típicamente es el modelo de estrella, descrito en este documento. 3

96 La sintaxis para crear un cubo en xml es bastante intuitiva y organizada. A continuación se muestra un esquema xml sencillo para el ejemplo incluido en Mondrian, de una tienda de alimentos: < Schema> < Cube name="sales"> < Table name="sales_fact_1997"/> < Dimension name="gender" foreignkey="customer_id"> < Hierarchy hasall="true" allmembername="all Genders" primarykey="customer_id"> < Table name="customer"/> < Level name="gender" column="gender" uniquemembers="true"/> < /Hierarchy> < /Dimension> < Dimension name="time" foreignkey="time_id"> < Hierarchy hasall="false" primarykey="time_id"> < Table name="time_by_day"/> < Level name="year" column="the_year" type="numeric" uniquemembers="true"/> < Level name="quarter" column="quarter" uniquemembers="false"/> < Level name="month" column="month_of_year" uniquemembers="false"/> < /Hierarchy> < /Dimension> < Measure name="unit Sales" column="unit_sales" aggregator="sum" formatstring="#,###"/> < Measure name="store Sales" column="store_sales"aggregator="sum" formatstring="#,#"/> < /Cube> </ Schema> Figura 2. Esquema de cubo XML Este esquema contiene un cubo sencillo, llamado "Sales", o ventas. El cubo tiene 2 dimensiones, que son tiempo y género, y 2 medidas, que son unidades vendidas y valor de dichas unidades vendidas. Con este esquema ya se puede construir una consulta MDX como: select {[Measures].[Unit Sales], [Measures].[Store Sales]} on columns, {[Time].[1997].[Q1].descendants} on rows from [Sales] where [Gender].[F] 2.3 ANÁLISIS MULTIDIMENSIONAL El análisis multidimensional utilizado en este proyecto se basa en los siguientes conceptos básicos. Cubo Multidimensional. Es una estructura de almacenamiento que permite realizar las diferentes y posibles combinaciones para visualizar los resultados de una organización hasta un determinado grado de detalle. Esta estructura es independiente del sistema transaccional de la organización y facilita consultar información histórica de manera rápida y eficiente; ofreciendo la posibilidad de navegar y analizar los datos requeridos. Cabe 4

97 recordar que el modelo de estrella es el que sopota este modelo de cubos multidimensionales. Medidas. Son características cualitativas o cuantitativas de los objetos que se desean analizar en el negocio, es decir los temas. Las medidas cuantitativas están dadas por valores o cifras porcentuales. Lo que se puede medir se puede controlar y mejorar. Por ejemplo, se tienen las ventas en dólares, el número de unidades de inventario, las horas trabajadas, el promedio de piezas producidas, el porcentaje de aceptación de un producto, el consumo de combustible de un vehículo, etc. Hay muchos ejemplos de medidas, pero la definición de las mismas corresponde a cada hipercubo en particular, es decir, del problema que se desee resolver. Dimensión. Son los objetos del negocio, con los cuales se puede analizar la tendencia y el comportamiento del mismo. La definición de estas dimensiones, se basa en políticas de la compañía o del mercado. Depende del modo como se interpreta o clasifica su información, para segmentar el análisis en sectores que por sus características comunes facilitan la observación y el análisis. Para poder definir las dimensiones requeridas dentro de los cubos multidimensionales, se deben responder a las siguientes preguntas: Cuando? : Permite hacer un análisis a través del tiempo y visualizar de manera comparativa el desempeño del negocio por unidades de tiempo que van desde días hasta años. Donde? : Se centra en un área física o imaginaria donde se están llevando a cabo los movimientos que se desean analizar, estos lugares pueden ser zonas geográficas, bodegas de almacenamiento de mercancía, divisiones hacia el interior de la organización, centros de costo, clasificación de las cuentas contables y etc. Que?: Es el objeto del negocio, o es el objeto de interés para determinada área de la compañía. Quien?: En esta dimensión se plantea una estructura de los elementos que inciden directamente sobre el objeto de interés, en estos casos se hace referencia a el área comercial o de ventas, a los empleados de la organización cuando se esta realizando un análisis a nivel del talento Humano y etc. Cual? : Es hacia donde esta enfocado el esfuerzo de la organización o una determinada área del negocio, para hacer llegar los productos o servicios. En esta dimensión se trabaja con los clientes que pueden ser internos o externos a la organización Los Cubos De Decisión Al contar con estos componentes del análisis multidimensional, se inicia el proceso de determinar los cubos que reflejen las necesidades del negocio. 5

98 CUANDO DONDE QUE QUIEN CUAL MEDIDAS año zona tipo de producto fuerza de ventas división de clientes ventas semestre región grupo de producto categoría tipo de cliente unidades trimestre ciudad producto vendedor cliente horas Tabla 1. Ejemplos de dimensiones. Un cubo de decisión es el resultado lógico del proceso de modelamiento en estrella. En el caso del manejo relacional de bases de datos, los cubos pueden estar organizados físicamente en motores de bases de datos que soporten esta multidimensionalidad. De esta manera un cubo se convierte en una abstracción multidimensional de los datos contenidos en un esquema relacional. En un cubo están relacionados varios conceptos vistos en la sección anterior, pero los conceptos que básicamente componen un cubo son las dimensiones, las medidas, las jerarquías y los miembros. Otros conceptos determinantes en el análisis multidimensional son las celdas, los niveles, las tuplas y los grupos o sets, que son elementos que agregan complejidad y funcionalidad a uno de estos cubos. Intentar separar estos conceptos e intentar explicarlos por separado es una tarea muy difícil pues se encuentran estrechamente relacionados entre sí. Para enunciar y explicar de manera adecuada estos elementos se da un ejemplo. Los elementos fundamentales de un cubo son las dimensiones y las medidas. En la Tabla 2 aparecen dos dimensiones. La dimensión tiempo y la dimensión producto. Para este cubo que consta de dos dimensiones existe una medida, que es el número de unidades vendidas. Es decir que cada una de las celdas contiene el valor de una medida que es la intersección de dos miembros de la dimensión. La dimensión producto tiene cuatro miembros, que son: carnes, vegetales, cereales y leche. La dimensión tiempo tiene cuatro miembros también, que son los meses de abril a julio. Es decir que la información contenida en este cubo habla de las unidades vendidas de cada producto en cada mes. Los valores de la medida unidades vendidas aparecen en una celda, que representa la intersección entre dos dimensiones. Unidades Vendidas Producto tiempo carnes vegetales cereales leche abril mayo junio

99 Unidades Vendidas julio Tabla 2. Cubo de dos dimensiones y una medida Por supuesto, podemos dar vuelta a las filas para que queden en las columnas y viceversa, y el sentido de los datos es el mismo, como lo muestra la tabla 3. Unidades Vendidas Tiempo Producto abril mayo junio julio carnes vegetales cereales leche Tabla 3. Cubo de dos dimensiones y una medida con dimensiones cambiadas. Claramente, cada celda puede ser descrita en términos de un miembro de cada dimensión. En ambas visualizaciones del cubo se pueden ver el número de unidades de cereales vendidas en el mes de mayo. Es muy fácil visualizar y analizar un cubo como estos, que consiste en dos dimensiones y una medida. Sin embargo, no hay razón para que un cubo como estos deba estar limitado a una sola medida. También se podría tener una nueva medida, la medida "pesos vendidos". Hay muchas formas de visualizar ésta medida y la medida de unidades vendidas. Podría representarse bien como en la tabla 4. Unidades Vendidas/pesos vendidos Producto tiempo carnes vegetales cereales leche abril 23 $ $ $ $6000 mayo 34 $ $ $ $2000 junio 43 $ $ $ $5300 julio 23 $ $ $ $2345 Tabla 4. Cubo de dos dimensiones y dos medidas En este caso las unidades vendidas ocupan la parte izquierda de la celda y los pesos vendidos la parte derecha. Así como los cubos pueden tener múltiples medidas, también pueden tener más de dos dimensiones. Si al negocio de este ejemplo, se le agrega que la compañía que vende estos productos tiene sedes en distintos lugares, aparecería una nueva dimensión. Es posible ver la información anterior, ahora discriminada por dichos lugares. Se le agrega la dimensión ciudad y se obtiene el cubo de la figura 3. 7

100 Figura 3. Cubo dimensional de tiempo, producto y ciudad. La celda que está en verde en el cubo muestra una intersección entre tres aristas del cubo.cada arista representa una dimensión. La celda seleccionada es pues una intersección de el mes de mayo, de el producto vegetales y de la ciudad Bogotá. El valor que se encuentra dentro de la celda es el número de unidades de vegetales vendidos en mayo en bogota. De esta manera los datos ahora se analizan en tres dimensiones. Sin embargo, gracias a OLAP no hay límite de dimensiones para el análisis de datos. Por lo tanto, un cubo multidimensional podría tener muchas más dimensiones que las expuestas en el anterior ejemplo. Para complementar ese cubo tridimensional se podría agregar la dimensión empleado, para saber que empleado vendió el producto, y también agregar la dimensión cliente, para saber a que persona se le han vendido cuantos productos. De esta manera el cubo ahora tendría cinco dimensiones. De este cubo, se puede obtener una aseveración como esta: "pedro vendió 10 cajas de cereal en mayo en la ciudad de bogota a la cliente María, que le costaron $35000 pesos". Para conocer esto se han usado las 5 dimensiones definidas, así como las dos medidas. Hasta este punto se ha expuesto la relación de los conceptos básicos de análisis multidimensional, como dimensiones, medidas, miembros y celdas. Pero la complejidad de los conceptos va en aumento, y se agregan los siguientes elementos: 8

101 Jerarquías Y Agregaciones. Las dimensiones vistas proveen una análisis significativo para los datos. Sin embargo han sido dimensiones estáticas, que no permiten variar su forma. Si se pretendiera analizar los datos por día, por mes, por trimestre, o por año no se justificaría hacer un cubo diferente para cada restricción. Para hacerlo eficiente, se usan dimensiones con jerarquías. Una dimensión puede estar organizada jerárquicamente. Por ejemplo, muchos cubos tienen una dimensión tiempo que normalmente es jerárquica, y que incluye un año, semestre, trimestre, mes y día. Un ejemplo de esta dimensión ocurre cuando se quieren ver las unidades vendidas de un producto en determinada ciudad discriminadas por año, mes, trimestre y día. Estas vistas son las tablas 5, 6 y 7. Unidades Vendidas producto tiempo carnes vegetales cereales leche año Tabla 5. Resultados por año Unidades Vendidas producto tiempo carnes vegetales cereales leche trimestre trim trim trim trim Tabla 6. Resultados por trimestre Unidades Vendidas producto tiempo carnes vegetales cereales leche mes abril mayo junio julio Tabla 7. Resultados por mes. Todas estas tablas se refieren a la dimensión tiempo, y se relacionan entre sí, dado que un mes está contenido en un trimestre, y este a su vez está contenido en un año. Están organizados lógicamente de manera jerárquica. 9

102 Los resultados de los datos con estas restricciones se pueden representar como aparecen en la tabla 8. Este tipo de representaciones que se encuentran al interior de un cubo, son el resultado de sumar o hacer agregaciones de los datos originalmente guardados en la base de datos. Es decir, el resultado por trimestre surge de sumar los resultados de los tres meses que conforman el trimestre. Esto es lo que se conoce como una agregación. El termino agregación no es propiamente un concepto del análisis multidimensional. Surge de la necesidad de optimizar los tiempos de respuesta a los clientes o usuarios, y en él vienen involucrados conceptos de almacenar y cargar datos temporalmente en la memoria. carnes leche 2000 trim 3 julio agosto septiembre trim 3 total trim 4 octubre noviembre diciembre trim 4 total total Tabla 8. Resultados anteriores vistos de una forma más compleja Las jerarquías están compuestas por niveles, que se exponen a continuación. Niveles. Siguiendo con el ejemplo de la dimensión tiempo, la jerarquía de esta dimensión podría ser como se ve en la figura 4. Figura 4. Niveles de la jerarquía tiempo. 10

103 En la figura 4, se incluye por cuestiones de visibilidad solo parte de la jerarquía. En este ejemplo de observa claramente que la jerarquía de la dimensión tiempo tiene 4 niveles, que son: el nivel "all", el año, el trimestre y el mes. Además de los niveles propios de una fecha, que son: el año, el trimestre y el mes, se incluye el nivel all, que es la raíz de este árbol jerárquico. El nivel all está creado específicamente para poder manejar y tener acceso a toda la información de tiempo contenida dentro del cubo, para producir respuestas a preguntas como : cual es el número de unidades vendidas de algún producto para todo el periodo de tiempo cubierto por el cubo?. Muchas de las dimensiones existentes poseen un nivel superior "all". Los niveles tienen miembros, y un miembro es un ítem simple en una dimensión. Se podría formar un cubo con cada uno de estos niveles y la dimensión tiempo, y todos serían miembros. El nivel año tiene 2 miembros, el nivel trimestre tiene 8 miembros, y así sucesivamente. Tuplas Y Sets. Un set es un conjunto o un grupo. Pero para efectos del análisis multidimensional se considera tal cual como se maneja en el ambiente multidimensional. Tuplas. Dada la figura 3 descrita anteriormente, se analiza la celda seleccionada, identificada con color verde. Esta selección se representa con la siguiente notación: " [productos].[vegetales], [tiempo].[mayo], [ciudad].[bogota] " En esta notación, se tiene la intersección especificada en función de las tres dimensiones y sus miembros respectivos. Primero está la dimensión producto, donde el miembro al que se hace referencia es vegetales, y de esta forma se representan las demás dimensiones, separadas por comas. En este orden se hace referencia a la celda seleccionada en el caso del ejemplo. Es independiente el orden en el que se coloquen las dimensiones. La celda descrita también se podría representar de esta manera: " [productos].[vegetales], [ciudad].[bogota], [tiempo].[mayo] ". Lo importante es utilizar las coordenadas dentro del cubo para hacer la selección requerida. Las coordenadas son miembros, un miembro tomado de cada dimensión. Por lo tanto, se llega a la definición que este conjunto de coordenadas es lo que se conoce como una tupla que es única en la matriz multidimensional. 11

104 Figura 5. Expresión multidimensional vista gráficamente. Sets. Un set es una colección simple de tuplas, o un conjunto de tuplas, las cuales son definidas usando las mismas dimensiones. El uso de las mismas dimensiones se ve en esta expresión: ( [productos].[vegetales], [ciudad].[bogota], [tiempo].[mayo] ) ( [productos].[carnes], [ciudad].[bogota], [tiempo].[mayo] ) Estas dos tuplas toman cada una exactamente un miembro de cada una de las dimensiones, y ambas son definidas usando las mismas dimensiones. Es decir que si se unen en una expresión, se convertirían en un set. Podemos decir que estas tuplas tienen la misma "dimensionalidad". Por lo tanto se complementa la definición de set, estableciendo que es una colección de tuplas con la misma dimensionalidad. Puede tener varias tuplas, una tupla, o ninguna tupla, en cuyo caso sería un set vacío. 2.4 MDX Definición Básica Del Lenguaje Mdx. Hasta ahora se ha usado una notación para referirse a un miembro en una dimensión. Se había dicho que primero se colocaba la dimensión, entre [ ], se separaban por un punto y se escribía el miembro entre otros [ ]. Todo esto pertenece a un lenguaje llamado MDX. Las siglas MDX significan Multi Dimensional expressions. Es un lenguaje que sirve para hacer consultas en una base de datos multidimensional, análogamente a como lo haría el lenguaje SQL en las bases de datos comunes. Es la forma de expresar el análisis de un cubo OLAP. 12

105 Desde que la empresa Microsoft entro al mundo de la Inteligencia de negocios, en el año de 1998, con una versión de servicios OLAP en la aplicación SQL Server 7.0, el lenguaje MDX se ha venido convirtiendo en una lengua estándar para este tipo de consultas. Es verdad que aunque fue creado por compañías propietarias, el lenguaje MDX ha sido adoptado también por el mundo del Software libre, para las aplicaciones OLAP existentes. Este lenguaje es útil para muchas cosas, desde aspectos de seguridad en el cubo, hasta el diseño de la navegación hacia adentro y fuera del cubo. En definitiva este lenguaje fue creado específicamente para el manejo de cubos OLAP. Una de las grandes características de este lenguaje es el de permitir el manejo de las agregaciones y los resultados precalculados, sin necesidad de que aparezcan físicamente establecidos en las bases de datos. Siguiendo con la notación del lenguaje, la forma natural de llamar a un miembro con una jerarquía suficiente podría ser como este: [lugar].[colombia].[cundinamarca].[bogota].[chapinero]. Esta sería la forma completa para referirse al barrio chapinero de la ciudad de Bogotá. Aunque muchas veces es posible usar expresiones más cortas, como [ciudad].[chapinero], esto se puede hacer, pero solo bajo ciertas condiciones de nombrado y ciertos datos. Por ejemplo, para el caso de la dimensión tiempo, es posible tener una expresión como "[tiempo].[octubre]". Pero como se podría saber si el octubre al que se hace referencia es al del año 2001 o 2002 o 2003?. Una forma de solucionar este inconveniente es el de hacer unas convenciones de nombramiento. Por ejemplo, si el miembro no se llamara octubre sino "octubre- 2001", ya se podría identificar con una corta expresión, es decir que se puede definir como: [tiempo].[octubre-2001] en vez de: [tiempo].[all].[2001].[octubre]. La sintaxis MDX no es solo para obtener datos de las bases multidimensionales, también provee una funcionalidad extra para el manejo de sets, manejo de miembros calculados y la escritura de información acerca de dimensiones y celdas. Para finalizar esta definición de MDX, se examina la siguiente consulta MDX, definida de la siguiente forma: SELECT {[Measures].[Cantidad_visitas], [tiempo].[all Members].[1998].[sem2]} ON columns, {[geografía].[all Members]} ON rows FROM [visitas] WHERE [vendedor].[juan] Esta sencilla consulta mdx presenta la misma estructura que una consulta SQL, es decir, tiene un select, un from y un where. Es importante notar que en el lenguaje mdx las medidas también son interpretadas como dimensiones. En este ejemplo se está consultando el número de visitas hechas en el segundo semestre de 1998 en todas las zonas, veredas y municipios, por el vendedor juan. Como se identifica en la sintaxis se da la opción de escoger como comparar las dimensiones, en filas o en columnas. [visitas] es el nombre del cubo. 13

106 2.4.1 Conceptos Avanzados con mdx. En la explicación anterior se revisaron los conceptos básicos de como construir una consulta MDX, en esta parte se explicarán conceptos mas avanzados de MDX. La estructura detallada de una consulta MDX se expone en el siguiente diagrama. Dimensiones Eje X, Columnas. SELECT {[Measures].[Cantidad_visitas], [tiempo].[all Members].[1998].[sem2]} ON columns, {[geografía].[all Members]} ON rows Eje Y, Filas. FROM [visitas] Alcance de la consulta, (cubo) WHERE [vendedor].[juan] Cláusula de selección Figura 6. Estructura de una consulta MDX Existe una similitud entre las consultas MDX y SQL, debido a que comparten sintaxis como lo son las cláusulas SELECT, FROM y WHERE. Sin embargo existen ciertos elementos que se distancian de SQL para dar soporte a las necesidades multidimensionales. En MDX se identifican varios miembros, que cumplen un rol determinado por su posición en la jerarquía. Children. La primera función es Children la cual, identifica el miembro o los miembros de un nivel por debajo del nivel inicial. Para usar la función Children se debe especificar el miembro, para que la función retorne todos los niveles por debajo de ella. Ejemplo: Se tiene la siguiente consulta MDX: select {[Measures].[Valor]} ON columns, Hierarchize({[Producto].[All Productos]}) ON rows from [cuboventas] De esta consulta se obtiene el siguiente resultado Measures Producto Valor All Productos 1,480,238,151 14

107 Que es el valor de las ventas de todos los productos. Ahora se utilizará la función children aplicada a la dimensión producto para comparar su resultado. Ejemplo de consulta select {[Measures].[Valor]} ON columns, Hierarchize(Union({[Producto].[All Productos]}, [Producto].[All Productos].Children)) ON rows from [cuboventas] Al ejecutar la anterior consulta se da el siguiente resultado Measures Producto Valor All Productos 1,480,238,151 Asesora 5,510,000 Capacitación 110,569,754 Desarrollo 1,068,367,852 Instalación 147,968,876 Soporte 88,168,533 Esta nueva consulta muestra el valor vendido de todos los productos como un total y también de cada uno, pues cada producto es hijo de la categoría Producto. Count. La función Count retorna el numero de items de de un cubo, por ejemplo las dimensiones, las tuplas, las celdas, niveles en una dimensión o una jerarquía. Se tiene el siguiente ejemplo: with member [Measures].[total] as 'count([producto].[all Productos].Children)' select {[Measures].[total]} ON columns from [cuboventas] El resultado es el siguiente: 5 Measures total La función realiza un conteo de los componentes de Producto, que son cinco pues hay cinco categorías de productos. Avg. La función Avg retorna el promedio de un número total de miembros. En la siguiente consulta de ejemplo se utiliza esta función. 15

108 with member [Measures].[total] as 'Avg([Producto].[All Productos].Children)' select {[Measures].[total]} ON columns from [cuboventas] El resultado es el promedio del valor de las ventas de las categorías de productos. Measures total 284,117,003 Max. La Función max retorna el máximo valor de un numero total de miembros. Max(«Set»[, «Numeric Expression»]) En el siguiente ejemplo se ve: with member [Measures].[total] as 'Max([Producto].[All Productos].Children)' select {[Measures].[total]} ON columns from [cuboventas] Tiene el siguiente resultado: Measures total 1,068,367,852 En el cual se ve el valor de ventas de la categoría de producto con mayor valor en ventas. Min La Función min retorna un mínimo valor de un numero total de miembros. Min({Set}[, {Numeric Expression}]) Para la cual se da el siguiente ejemplo. with member [Measures].[total] as 'Min([Producto].[All Productos].Children)' select {[Measures].[total]} ON columns from [cuboventas] Measures total 5,510,000 El resultado muestra el valor de la categoría de productos con menores ventas. Crossjoin 16

109 Frecuentemente en MDX, los resultados de una consulta deberán necesitar más miembros de más de una dimensión. Crossjoin({Set1}, {Set2}) Esta función retorna el producto cartesiano de distintos miembros de dos sets, que retorna todas las posibles combinaciones de esos miembros. El siguiente ejemplo muestra el uso de esta característica. select Crossjoin(Hierarchize(Union({[Ciudad].[All Ciudads]}, [Ciudad].[All Ciudads].Children)), {[Measures].[Valor]}) ON columns, {[Producto].[All Productos]} ON rows from [cuboventas] Se genera el siguiente resultado: Ciudad All Ciudads - BOGOTA CALI MONTERIA Measures Measures Measures Measures Measures Producto Valor Valor Valor Valor Valor All 1,480,238,15 43,584, ,610, ,833,235 57,565,495 Productos Se hace un producto cartesiano entre el miembro Producto y Ciudad, para conocer el valor de las ventas de los productos en cada ciudad. 17

110 3. HERRAMIENTAS PARA EL DATAMART Para el desarrollo del datamart se usaron varias herramientas, y varias de ellas soportan el funcionamiento del datamart. A continuación se explica el concepto y funcionalidad de cada una de ellas, así como el proceso de instalación, administración y uso de estas aplicaciones, todas ellas de libre distribución. 3.1 JAKARTA-TOMCAT Tomcat es un sub proyecto de Jakarta que provee un poderoso servidor web (web-container) con soporte a Java Servlets y JSP. El servidor de Tomcat ha llegado a ser la referencia para el funcionamiento tanto de servlet como de JSP. Es muy estable y tiene todas las características de un servidor web comercial. Tomcat también proporciona funcionalidades adicionales que lo hacen una excelente opción para desarrollar una solución web El Manager de Tomcat El manager es una aplicación para administración del motor Tomcat que usa una interfaz vía web. En principio y por razones de seguridad no se puede ingresar al módulo manager hasta que sea creado un usuario de Tomcat con privilegio de administrador. Para crearlo se debe modificar el archivo de configuración de usuarios de Tomcat, que se encuentra en $Tomcathome/CATALINA_HOME/conf/tomcat-users.xml. A dicho archivo se deben agregar las siguientes líneas: <role rolename="manager"/> <user username="root" password="xxxxxxx" roles="manager"/> Debido a que es un documento xml, se debe respetar el orden de las etiquetas. Dicho de otro modo, la línea <role> debe insertarse debajo de las que ya están y lo mismo para la línea <user>. Con respecto a la línea <user> agregada, se puede poner el nombre de usuario que se prefiera, no hace falta que sea root (la condición de administrador se define en el atributo role, no en el nombre). Al momento de asignar el password puede ser cualquiera. Una vez se ha agregado el usuario, se debe reiniciar Tomcat y acceder, desde un navegador a la dirección se introduce la información del usuario administrador (username/password), recién creado y aparecerá la interfaz del manager. Dicha interfaz consta de 5 partes: o Message: Aquí se muestra el resultado de las órdenes que se le hayan dado al manager. Pueden ser OK o FAILED. 18

111 o o o o Manager: Aquí se encuentran tres opciones. La primera recarga la lista de aplicaciones instaladas. Las dos siguientes son un enlace a la documentación de Tomcat. Applications: Aquí aparece la lista de aplicaciones web que está ejecutando Tomcat. Para cada aplicación se tiene la columna Commands que es la más importante para administrar los servicios ofrecidos por Tomcat. Las opciones de Commands son: parar (stop), iniciar (start), recargar (reload) o borrar (undeploy) la aplicación. Install: Desde aquí se suben aplicaciones directamente al Tomcat. Para agregar una aplicación, se da el url del archivo.war de la aplicación que se quiere instalar. Luego se oprime el botón install, y la aplicación es agregada a las aplicaciones soportadas por Tomcat. Server information: Información respecto al servidor. Arranque del servidor Tomcat. Hay dos técnicas de arranque del servidor Tomcat La primera es mediante la variable de ambiente: - Estableciendo la variable de ambiente TOMCAT_HOME en la ruta del directorio el cual se ha instalado el Tomcat %TOMCAT_HOME%\bin\startup para Unix, (para Windows %TOMCAT_HOME%/bin/startup.sh La segunda puede hacerse modificando el directorio actual de trabajo: - Ejecute los siguientes comandos en el shell: cd$tomcat_home/bin (Linux)./startup.sh (Unix) Hay dos técnicas para parar el Tomcat: Vía variable de ambiente: - Establecerla variable de ambiente TOMCAT_HOME en la ruta del directorio en la cual se instalo el Tomcat. - Ejecutar el comando prompt o shell: $TOMCAT_HOME/bin/shutdown.sh (para Unix) Modificando su actual directorio de trabajo: - Ejecutar los comandos siguientes en el prompt oshell: 19

112 cd $TOMCAT_HOME/bin./shutdown.sh (para Linux) (para Linux) 3.2 POSTGRESQL PostgreSQL es un administrador de bases de datos relacionales, que soporta las instrucciones de SQL, y se encuentra entre los más populares y funcionales dentro del mundo del software libre. Además, ofrece una potencia adicional sustancial al incorporar los siguientes cuatro conceptos adicionales básicos en una vía en la que los usuarios pueden extender fácilmente el sistema clases herenci a tipos funcione s Otras características aportan potencia y flexibilidad adicional: Restricciones (Constraints) Disparadores (triggers) Reglas (rules) Integridad transaccional Estas características colocan a Postgresql en la categoría de las Bases de Datos identificadas como objeto-relacionales. Nótese que éstas son diferentes de las referidas como orientadas a objetos, que en general no son bien aprovechables para soportar lenguajes de bases de datos relacionales tradicionales. Postgresql tiene algunas características que son propias del mundo de las bases de datos orientadas a objetos. De hecho, algunas Bases de Datos comerciales han incorporado recientemente características en las que Postgresql fue pionera. Instalación de PostgreSQL En el directorio de instalación se digita la siguiente línea: [root#localhost]# su postgres [bash]$ 20

113 El siguiente paso es crear un nuevo usuario para la base de datos en postgresql, se digita lo siguiente: [bash]$:createuser Enter name of user to add: Ubiquando Shall the new user be allowed to create databases? (y/n) y Shall the new user be allowed to create more new users? (y/n) y CREATE USER [bash]$createdb martventas CREATE DATABASE Para permitir conexiones tcp/ip, se necesita editar el fichero postgresql.conf y habilitar la opción tcpip_socket. En redhat 9, este fichero está localizado en /var/lib/pgsql/data. Como súper usuario (root) configure lo siguiente y se modifica la siguiente línea: #tcpip_socket = false y la cambiamos por los siguiente: tcpip_socket = true Queda un último paso que es editar el fichero pg_hba.conf. Este fichero especifica los ordenadores que pueden conectarse a la base de datos postgres. Se guarda el archivo y por ultimo se debe reiniciar el servicio. service postgresql restart 21

114 4. SCRIPTS DE CARGA A LA BASE DE DATOS Descripción: La Funcionalidad de los scripts de carga es realizar la carga de los datos a la base de datos que manipula el datamart, a partir de los archivos planos y de la base de datos netcontable que son utilizados como fuente del datamart. Este documento va a describir cual es la función de cada uno de cada archivos planos y de la base de datos netcontable que son las fuentes de datos, y de los scripts de carga, para los que se define cada cuanto se realiza su ejecución. Definición de los archivos planos: 1. Sectores.txt Este archivo contiene los sectores de clientes que se han identificado para Ubiquando, cada cliente de Ubiquando será relacionado con uno de estos sectores. Se tienen tres campos para identificar a cada sector, estos campos deben estar en la misma línea. El primer campo es el código del sector. Este código no se puede asignar al azar, pues tiene un significado. Los códigos que inician con 00 son categorías de Gobierno, si se quieren agregar subcategorías a Gobierno los códigos de estos subsectores deben iniciar con 00 y empezar a numerar cada subsector en el quinto carácter de este campo, incrementando de uno en uno. Por ejemplo, sería la primera subcategoría de gobierno, la siguiente, y continúa con y así sucesivamente. Los campos que inician con 01 hacen referencia a clientes del sector Corporativo y se incrementa la numeración del código para cada subsector de igual manera que en el caso de Gobierno. El último sector es el de Pymes, el cual inicia con 02 y cumple con los mismos requisitos en los códigos que los anteriores sectores. El segundo campo de cada línea, identifica el nombre de la categoría del sector. Este puede ser: Gobierno, Corporativo o Pymes. Y por último, el tercer campo de cada línea dice el nombre de la subcategoría de la categoría. Se pueden agregar subcategorías a cada categoría en este archivo, lo importante es mantener el estándar de codificación descrito en el párrafo anterior. El siguiente es un ejemplo de la estructura del archivo Sectores.txt ;Gobierno;Gobierno 01000;Corporativo;Agremiaciones 01001;Corporativo;Salud 02000;PYMES;PYMES 2. Clientes.txt Este archivo es utilizado para relacionar a cada cliente de Ubiquando con el segmento al que pertenece, de acuerdo a la clasificación acordada de 22

115 clientes. Debe contener una lista de la identificación de todos los clientes, la cual es extraída de la tabla tercero y su campo id de la base de datos netcontable. Al lado de cada identificación, y separada por punto y coma (;) se debe incluir el código del sector al que pertenece el cliente. Los códigos de sector que se pueden incluir se encuentran en el archivo sectores.txt descrito previamente. Las siguientes dos líneas son un ejemplo de la estructura que debe contener el archivo ; ; lineas.txt Este archivo es utilizado para especificar las líneas de productos que tiene Ubiquando. Cada renglón de este archivo establece una línea de producto, especificando su código y luego de un punto y coma (;) se da el nombre de la línea. Cada producto pertenece a una línea y esta relación entre producto y línea se realiza en el archivo productos.txt que será descrito en la siguiente sección. Es importante el código de cada línea, pues a partir de este código se codifican los productos. A continuación se da todo el contenido del archivo lineas.txt por ser de gran utilidad para describir la siguiente sección. 0;Asesora 1;Instalación 2;Desarrollo 3;Capacitacion 4;Soporte 4. productos.txt En este archivo aparecen todos los productos que comercializa Ubiquando. Cada renglón del archivo especifica un producto, incluyendo un código del producto, seguido por punto y coma(;) y luego por el nombre del producto. Es importante la codificación de cada producto, pues de su código depende su clasificación en las líneas de producto. Todos los códigos tienen una longitud de cinco caracteres. Los códigos de producto que empiecen con 00 se refieren a productos de asesoría, los que empiezan con 01 a instalación, los de 02 a desarrollo, los de 03 a capacitación y los de 04 a soporte. Luego de identificar a la línea de el producto codificado utilizando los dos primeros caracteres del código, se asigna un número a cada producto individual, estableciendo el quinto dígito del campo e incrementando este número para cada producto individual de la misma línea. A continuación se dan ejemplos de renglones incluidos en el archivo productos.txt ;Mensajeria y ;Proteccion de Borde 01002;VPN 01003;PDC 23

116 En estos renglones todos los productos pertenecen a la línea Instalación, por iniciar con 01 y luego se incrementa el número del quinto dígito para establecer el código individual de cada producto. 5. Ventas.txt Dado que la mayoría de los registros de ventas existentes en las base de datos netcontable, la cual es utilizada para registrar ventas - entre otras cosas -, contienen información errónea respecto al producto vendido por cada factura, se dio la necesidad de crear este archivo. El archivo contiene todos los códigos de facturas encontrados en netcontable desde el 01/01/2004 hasta el 20/04/2005. Por cada código de factura se agrega el código del producto vendido en esa factura, separados ambos códigos por un punto y coma(;). Cada renglón del archivo corresponde a una factura. Este archivo fue creado hasta el 20/04/2005 para establecer el correcto código de producto vendido en estas facturas, pues el registrado en netcontable es erróneo. A partir de esta fecha se ingresan correctamente los códigos de productos vendidos a la base de datos netcontable, por lo tanto la carga de las facturas generadas luego de esta fecha se hace directamente a la base de datos netcontable y no a través de este archivo. Por lo que el archivo no se actualizará. A continuación se da un ejemplo de las líneas de este archivo, reafirmando que el primer campo corresponde al número de factura y el segundo al código del producto vendido en esa factura. 875; ; ;4002 Definición de Scripts: 6. Fechas200X.csv Este script se debe correr directamente en un cliente de PostgreSQL. El script inserta los datos directamente a la dimensión dim_tiempo de la base de datos martventas del datamart. Lo que hace cada renglón de este archivo es crear el registro de un día de calendario a esta dimensión. Cada renglón tiene la forma insert into dim_tiempo values(número de llave primaria,número de año,'nombre del número de semestre','nombre del número de trimestre','nombre del mes',número de día);. En la base de datos ya se encuentran, por defecto ingresadas las fechas hasta el Para agregar nuevas fechas es importante seguir con el mismo estándar y tener precaución de no repetir llaves primarias, por lo que es necesario, incrementar el valor de cada llave primaria en uno para cada nuevo registro. Por lo tanto, es importante verificar el último valor de llave primaria encontrado en la tabla dim_tiempo de la base de datos martventas e insertar el nuevo registro con llave primaria de ese valor más uno. A continuación se da un ejemplo de un renglón de este archivo. insert into dim_tiempo values(161,2004,'sem1','trim2','junio',11); 24

117 7. Propiedades.java Esta clase define los parámetros externos que requiere la clase CargaBodegaUbiquando.java descrita a continuación para ejecutarse. El único objetivo de Propiedades.java es especificar los datos del usuario de la base de datos martventas, la ubicación de esta base de datos, la ubicación de los drivers de las bases de datos, y el directorio y nombres de los archivos de texto fuentes de datos para la bodega. 8. CargaBodegaUbiquando.java Esta clase es la única invocada por el usuario o el sistema para realizar el proceso de extracción, transformación y carga a la bodega. Antes de ejecutar esta clase es importante que se encuentren disponibles todos los archivos de texto fuentes en el directorio especificado por el archivo Propiedades.java y las bases de datos fuentes y destino. En esta clase se obtiene una instancia de seis clases, cada una encargada del proceso ETL de una dimensión y de la tabla de hechos. Luego de obtener la instancia de cada clase, se ejecuta el método correspondiente a cada clase para extraer, transformar y cargar su respectiva dimensión o tabla de hechos. A continuación se relaciona a cada clase instanciada dentro de CargaBodegaUbiquando.java con su dimensión o tabla de hechos objetivo. Clase Tabla del datamart CargaSectores CargaLinea CargaGeografia CargaProductos CargaCliente CargaFactVenta dim_sector dim_linea dim_geografia dim_producto dim_cliente fact_venta Luego de ejecutar la clase CargaBodegaUbiquando.java, la bodega estará cargada para hacerle los análisis necesarios con OLAP. A continuación se describe cada clase que aparece en la tabla superior en el orden de invocación de la clase principal CargaBodegaUbiquando.java. 9. CargaSectores.java Tiene como datos fuentes: Archivo sectores.txt. Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en el archivo sectores.txt a la dimensión dim_sector. El método invocado desde la clase principal CargaBodegaUbiquando.java es cargarsectores(). En este método, lo 25

118 primero que se hace es borrar de la tabla dim_sector de la bodega todo lo que halla, para luego cargar en esa misma tabla los datos que se encuentren en el archivo sectores.txt. Por lo tanto, si se hiciese algún cambio en el archivo de sectores, al realizar la siguiente carga, la información del archivo sectores.txt actualizada reemplaza a la que se había cargado previamente. 10. CargaLinea.java Tiene como datos fuentes: Archivo lineas.txt. Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en el archivo lineas.txt a la dimensión dim_linea. El método invocado desde la clase principal CargaBodegaUbiquando.java es cargarlinea(). En este método, lo primero que se hace es borrar de la tabla dim_linea de la bodega todo lo que halla, para luego cargar en esa misma tabla los datos que se encuentren en el archivo lienas.txt. Por lo tanto, si se hiciese algún cambio en el archivo de líneas, al realizar la siguiente carga, la información del archivo lineas.txt actualizada reemplaza a la que se había cargado previamente. 11. CargaGeografia.java Tiene como datos fuentes: Tabla ciudad de la base de datos netcontable. Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en la base de datos netcontable en la tabla ciudad. Los campos extraídos de esta tabla son codigo y nombre. Estos campos son extraídos y cargados a una tabla temporal llamada ciudad, encontrada en la base de datos martventas de PostgreSql. ciudad es independiente y se encuentra aislada del diagrama estrella de la bodega. En esta tabla se realizan las transformaciones que sean necesarias, para luego cargar los datos de esta tabla temporal a la tabla dim_geografia. Todos los datos de la tabla dim_geografia son borrados antes de cargar los nuevos datos de la tabla temporal. Y los datos de esta tabla temporal son borrados luego de realizar el proceso. 12. CargaProductos.java Tiene como datos fuentes: Archivo productos.txt. Esta clase tiene como objetivo extraer, transformar y cargar los datos fuentes, encontrados en el archivo productos.txt a la dimensión dim_producto. En este método, lo primero que se hace es borrar de la tabla dim_producto de la bodega todo lo que halla. Luego se leen los datos del archivo de texto y se hace la transformación para asignarle una llave foránea a cada producto, que indique su pertenencia a una línea. 13. CargaCliente.java Tiene como datos fuentes: Archivo clientes.txt y tabla tercero de base de datos netcontable. Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en la base de datos netcontable en la tabla tercero y el archivo clientes.txt. Los campos extraídos de la tabla 26

119 tercero son id, nombre y ciudad. Primero se borran todos los datos existentes en la tabla dim_cliente y luego se insertan los datos encontrados en las fuentes. Los campos cli_idcliente, cli_nombre y cli_ciudad de la tabla destino dim_cliente son tomados de netcontable; y el campo cli_idsector que relaciona a un cliente con un sector, tiene como fuente el archivo clientes.txt. Son necesarias estas dos fuentes, pues en la base de datos netcontable no se establece correctamente le pertenencia del cliente a un sector, por lo tanto se requiere este archivo adicional. 14. CargaFactVenta.java Tiene como datos fuentes: Archivo ventas.txt y tabla comprobante de base de datos netcontable. Esta clase tiene como objetivo extraer, transformar (si fuese necesario) y cargar los datos fuentes, encontrados en la base de datos netcontable en la tabla comprobante y el archivo ventas.txt. Los campos extraídos de la tabla comprobante son numero, creacion, tercero y total. Los elementos del archivo de texto son: el número de factura y el código del producto vendido en esa factura. Para realizar el proceso ETL de esta tabla, se crea una tabla temporal llamada comprobante en la base de datos martventas. Esta tabla es independiente del diagrama estrella de la bodega, solo se utiliza para hacer las transformaciones requeridas antes de insertar los datos en la tabla fact_venta de la bodega. En esta tabla temporal se insertan los datos extraídos de todos los registros de la tabla comprobante de la base de datos netcontable. Luego de haber extraído los datos, se borran todos los datos de la tabla fact_venta y se poblan con los nuevos. Preservación de errores Cuando se ejecuta el script de carga puede presentarse algún problema, si esto llega a ocurrir el script genera algunos mensajes que se pueden llegar a presentar en el cargue como pueden ser: Mal formato de la fecha y hora. No se tiene conexión con base de datos netcontable No tiene conexión con base de datos martventas No se encuentra el archivo fuente xxx.txt. Entre otros más que se pueden presentar en el momento de la ejecución, actualmente la ejecución de los scripts envía los mensajes por pantalla. 27

120 5. QUIENES PUEDEN USAR LA HERRAMIENTA? Figura 6. Registro del usuario Como recomendación para usar la herramienta debe haberse seguido la capacitación planeada para Ubiquando para tal fin, y haber entendido los conceptos básicos de análisis multidimensional que expone este documento. Roles de usuarios. La aplicación del datamart define dos roles usuarios: Analista y administrador. Funciones de cada rol. Administrador. Tendrá acceso a todas las funciones básicas de la aplicación, es decir, ingreso y exploración. Adicionalmente podrá modificar el archivo Propiedades.txt para modificar las propiedades y usuarios de la base de datos. Analista: Tendrá acceso a las funciones de análisis de la aplicación: ingreso, visualización de consultas. 28

121 6. NAVEGANDO EN EL DATAMART Mondrian es una herramienta supremamente robusta en cuanto al manejo de hipercubos y tratamiento de bases de datos se refiere. El usuario de mondrian debe tener conocimientos básicos de OLAP, generación y uso de hipercubos e inteligencia de negocios y administración. Por lo general, las Herramientas OLAP son dirigidas a usuarios que toman decisiones, como ejecutivos, gerentes o buzos de información. Por lo tanto son herramientas que permiten una interacción relativamente sencilla con el usuario, permitiéndole generar un cubo gráficamente o hacer gráficas con los resultados sin mayores conocimientos técnicos. El menú principal del datamart es el que se presenta a continuación: Figura 7. Menú principal del datamart Dicho menú muestra en su lado izquierdo la opción del datamart de Ubiquando. Al apuntar con el puntero del Mouse sobre esta opción, se despliega la opción Análisis de ventas. Para ingresa al reporte se da clic en el nombre de esta opción. Para explicar los modos y opciones de navegación en la herramienta se seguirá el proceso de realizar un reporte típico. Luego de entrar a la opción Análisis de ventas se muestra el primer resultado, que ha sido predeterminado para mostrar las ventas por productos. Esta vista se encuentra en la siguiente figura. 29

122 Figura 8. Reporte predeterminado del datamart En esta vista se determina que está involucrada la dimensión Producto y la medida Valor. En este ejemplo se ve el valor total vendido por todos los productos. Figura 9. Barra de herramientas OLAP de Mondrian Para poder interactuar con los reportes se utiliza la barra de herramientas de mondrian: Los nombres de los botones son los siguientes: Navegador OLAP Editor de MDX Mostrar Miembros Padre Detallar miembros padre Ocultar celdas vacías Intercambiar filas por columnas 30

123 Taladrar miembro Taladrar posición Taladrar reemplazando Taladrar a través Mostrar Gráfica y Configurar Gráfica Imprimir en PDF y configurar Impresión Exportar a Excel Salir al menú Principal Se continúa el ejemplo haciendo clic sobre el botón Navegador Olap, que muestra un menú con las dimensiones del cubo que pueden ser utilizadas para generar el reporte. 31

124 Figura 10. Dimensiones disponibles para el análisis OLAP En este caso, en las columnas del reporte se tiene la medida (valor) y en las filas la dimensión Producto. En la parte que dice Filter se encuentran todas las dimensiones del cubo que no intervienen directamente en la consulta específica. De allí, con ayuda de los iconos auxiliares se pueden ubicar las dimensiones en las columnas o las filas dependiendo del criterio del analista. En este mismo menú se puede ver como está compuesta una dimensión, haciendo clic sobre su nombre. La figura 11 muestra cómo se describe la dimensión Producto al hacer clic sobre su nombre. Figura 11. Composición de la dimensión Producto Se puede ver que esta dimensión tiene dos niveles, con cinco miembros, que son: Asesora, Capacitación, Desarrollo, Instalación y Soporte. Si se quiere hacer una consulta que involucre a solo uno o varios miembros, se seleccionan las casillas de verificación correspondiente a los miembros requeridos en la consulta. Usando el botón de intercambio filas por columnas se intercambian las dimensiones de lugar. A continuación se va a navegar un nivel más abajo en la 32

125 dimensión Producto. Para esto se da clic en el signo + que acompaña el nivel ALL de la dimensión: Figura 12. Drill down aplicado a la dimensión producto. De lo general (Producto) se va a analizar lo particular (Asesoria, Capacitacion, Desarrollo, Instalacion, Soporte) En el análisis aparecen ahora todas las categorías de productos. Si existiesen celdas sin valor, se puede oprimir el botón Ocultar celdas vacías, y de este modo se ocultarán los renglones en el reporte para los que no halla una medida. En este caso, los renglones donde el valor de venta es 0. En este navegador Olap se puede escribir una consulta MDX (explicado anteriormente) por líneas de código para realizar un reporte específico. Normalmente no se escribe código para realizar las consultas, pues este código es generado automáticamente por la herramienta cuando se navega y se escogen opciones utilizando el Mouse. Sin embargo, si el usuario es avanzado puede especificar directamente los criterios del reporte. Figura 13. Inserción de código MDX para generar consultas Hay otra serie de botones que prestan servicios de visualización de los padres de un miembro. El primero de ellos es el botón de Detallar miembros padre. Cambia la tabla de tal forma que al lado derecho en un solo bloque se muestren los padres del miembro. Al utilizar esta opción en el ejemplo seguido se muestra la siguiente tabla. 33

126 Figura 14. Opción Detallar miembros padre activada El botón Detallar miembros padre especifica el padre de cada miembro en su lado izquierdo, como se ve en la siguiente figura 14, donde el padre de las cinco categorías de productos es Producto. La siguiente es una de las funcionalidades más útiles de la herramienta, pero igual que todo en OLAP depende del modelamiento de la base de datos. Se llama Drill through o taladrar a través, y consiste en poder observar el detalle de determinada celda del cubo. Este detalle será tan específico como específicos sean los datos en la base de datos. Cabe aclarara que esta función no aplica en el caso de las sumarizaciones, por la razón anterior, ni cuando se trabaja con miembros o medidas calculadas como porcentajes o promedios. Se puede solamente obtener el detalle de los hechos. Luego de seleccionar la opción de taladrar, se da clic en la flecha verde que aparece al lado del valor de cada miembro. Al hacer clic en la flecha correspondiente al miembro Desarrollo de obtiene el siguiente resultado. Si se da clic sobre el botón E sobre la tabla de drill through, se puede configurar esta tabla de una mejor manera. Permitiendo establecer los campos que aparecerán en el reporte. Figura 15. Opción drill through activada para la dimensión Desarrollo. 34

127 Por último se encuentran los botones de despliegue gráfico y exportación. Si se utiliza la opción mostrar gráfica, se despliega un gráfico que muestra los datos que están en ese momento expresados en la tabla Figura 16. Reporte gráfico de la consulta Este gráfico se puede configurar con el siguiente botón, de configurar la gráfica: Figura 17. Configuración de la gráfica, con múltiples opciones de gráficos. En la opción Chart Type se encuentran los tipos de gráficas más comunes y útiles en reportes, como líneas verticales, horizontales, bloques, pies, entre otros. También es posible configurar las leyendas y el tamaño y tipo de letras de ellos, como también el tamaño de la gráfica. 35

128 El botón de imprimir en PDF es el que continúa. Al oprimir este botón se crea un archivo PDF que se puede guardar en el disco duro o se puede abrir. Dicho pdf se puede configurar con el siguiente botón. Figura 18. Configuración del archivo PDF de exportación. Las opciones para configurar el pdf incluyen darle un titulo al reporte, escoger el tamaño de la página, la orientación de la hoja y elegir la forma de incluir la gráfica en el pdf. Por último se encuentra la funcionalidad de exportar a Excel, con lo que se crea un archivo que se puede almacenar en el disco duro o ser abierto directamente. Este archivo Excel exporta los valores de la tabla que se este visualizando en el momento de la exportación. El último botón da la opción de regresar al menú principal. 36