Integración y análisis de datos para el control y toma de decisiones de los portadores energéticos

Texto completo

(1)Matemática, Física y Computación. Título: Integración y análisis de datos para el control y toma de decisiones de los portadores energéticos. Autor: Yadiel Díaz Zamora Tutor(es): MSc. Iván M. Cárdenas Tandrón Lic. Frank Reyes García Santa Clara, 2014.

(2) Hago constar que el presente trabajo fue realizado en la Universidad Central ―Marta Abreu‖ de Las Villas como parte de la culminación de los estudios de la especialidad de Ingeniería Informática, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del tutor. Firma del jefe del Seminario.

(3) Dedicatoria. Dedico este trabajo y a mi familia que es el eje central de mi inspiración y dedicación al estudio..

(4) Agradecimientos. . A mi familia que sin ellos nada de esto me. estuviera sucediendo. . A mi novia Yamisleydy por ser mi compañera. incansable en los momentos más difíciles. . A mis amigos y compañeros de aula por ser. excelentes y haber aprendido junto a ellos la importancia del compañerismo y ayuda mutua. . A mis tutores por el apoyo brindado y excelencia. profesional. . A todo el claustro de profesores que fue capaz de. guiarme por el sendero correcto..

(5) Resumen RESUMEN Una de las actividades que contribuye a la ayuda económica en el país es la medida activa que se lleva a cabo para el ahorro y adecuada utilización de los portadores energéticos para su desarrollo, ejemplo de ello es la encaminada revolución energética. El presente trabajo va dirigido al análisis de inteligencia de negocios, en este caso del control de consumo de portadores energéticos en ayuda a la toma de decisiones, en períodos de planificación en su distribución y utilización. Para ello el mismo se estructura de cuatro capítulos que abarcan un proceso continuo de estudio especializado bibliográfico en el tema y enfoques que permiten el análisis de datos para el correcto diseño de un almacén de datos capaz de abarcar todos los objetivos trazados, dirigido hacia la toma de decisiones de los portadores energéticos, permitiendo así que se pueda determinar cantidades reguladas e indicadas en el consumo de combustible y otros portadores consultando información para controlar gastos innecesarios, a través de visualización de reportes OLAP (On-Line Analytical Processing)..

(6) Abstract ABSTRACT One of the activities that contribute to the economic aid in the country is the active measurement that is carried out for the saving and suitable use of the power carriers for the development of the country, example of it is the directed power revolution. The present work goes directed to the analysis of intelligence of businesses, in this case of the control of consumption of power carriers in aid to the decision making, in periods of planning in its distribution and use. For it the same structure of 4 chapters that include a continuous process of study specialized bibliographical in the subject and approaches which they allow the analysis of data for the correct design of a data store able to include all the objectives drawn up, directed towards the decision making of the power carriers, allowing as that can be determined amounts regulated and indicated in the fuel consumption and other carriers consulting information to control unnecessary expenses, through visualization of reports OLAP (On-Line Analytical Processing)..

(7) Contenido;Figuras;Tablas. CONTENIDO. Introducción .............................................................................................................................................................................. 1 Objetivo general .............................................................................................................................................................. 1 Objetivos específicos ................................................................................................................................................... 2 Capítulo 1. Análisis y especificación de requisitos en la toma de decisiones. ................................................ 5 Introducción ...................................................................................................................................................................... 5 1.1. Especificación y análisis de requisitos .............................................................................................. 5. 1.2. Factor toma de decisiones ......................................................................................................................... 6. 1.2.1. Desarrollo de la toma de decisión .............................................................................................. 7. 1.2.2. Tipos de decisiones............................................................................................................................... 7. 1.3. Sistemas de apoyo a la toma de decisiones .................................................................................... 8. 1.4. Almacén de datos ........................................................................................................................................... 10. 1.4.1. Proceso de diseño de un almacén de datos ......................................................................... 12. 1.4.2. Etapas del proceso de diseño de un almacén de datos ................................................ 14. 1.4.3. Tablas de hechos .................................................................................................................................. 16. 1.4.4. Tablas de dimensiones ..................................................................................................................... 17. 1.5. Esquemas para el modelado en el almacén de datos ............................................................. 18. 1.6. Integración de datos .................................................................................................................................... 20. 1.7. Herramientas para el desarrollo de sistemas de apoyo a la toma de decisiones 22. 1.8. Conclusiones parciales ............................................................................................................................... 25. Capítulo 2. Modelo de procesos y actividades del DW.......................................................................................... 33 Introducción .................................................................................................................................................................... 33 2.1. Modelo de casos de uso del sistema .................................................................................................. 33. 2.1.1. Nombre y descripción de los actores del sistema ........................................................... 34. 2.1.2. Nombre y descripción de los casos de uso del sistema ............................................... 35. 2.2. Métodos de diseño de un almacén de datos ................................................................................. 35. 2.3. Aplicación del método ................................................................................................................................ 38. 2.4. Conclusiones parciales ............................................................................................................................... 41. Capítulo 3. Arquitectura y diseño del sistema. ......................................................................................................... 44 Introducción .................................................................................................................................................................... 44 3.1. Arquitectura general del sistema ....................................................................................................... 44. 3.2. Vista de despliegue de la arquitectura ............................................................................................ 45.

(8) Contenido;Figuras;Tablas 3.3. Diseño del almacén de datos .................................................................................................................. 45. 3.3.1. Matriz de BUS (Instrumento) ....................................................................................................... 46. 3.3.2. Esquemas del mercado de datos ................................................................................................ 47. 3.4. Diseño y publicación de los cubos OLAP ........................................................................................ 50. 3.5. Proceso de extracción transformación y carga (ETL) ........................................................... 52. 3.5.1. Proceso de ETL para hechos y dimensiones ....................................................................... 52. 3.5.2. Proceso ETL para jobs ....................................................................................................................... 56. 3.6. Conclusiones parciales ............................................................................................................................... 57. Capítulo 4. Despliegue del sistema................................................................................................................................. 56 Introducción .................................................................................................................................................................... 56 4.1. Requerimientos de hardware y software ...................................................................................... 56. 4.1.1. Requerimientos mínimos y recomendados de hardware ......................................... 56. 4.1.2. Requerimientos de software .............................................................................................................. 57. 4.2. Resultados obtenidos con el despliegue del sistema ............................................................. 57. 4.3. Conclusiones Parciales............................................................................................................................... 61. Conclusiones ............................................................................................................................................................................ 62 Recomendaciones .................................................................................................................................................................. 63 Bibliografía .............................................................................................................................................................................. 64 Glosario de Términos .......................................................................................................................................................... 66 Anexos ....................................................................................................................................................................................... 71 Anexo Nro 1: Especificación de paquetes de EnerguX ......................................................................... 71 Anexo 1.1 Diagrama entidad relación paquete nomencladores .............................................. 71 Anexo 1.2 Paquete Tarjeta ................................................................................................................................ 72 Anexo 1.3 Paquete Portadores ....................................................................................................................... 73 Anexo 1.4 Paquete Histórico ............................................................................................................................ 73 Anexo 1.5 Paquete Transporte ....................................................................................................................... 74 Anexo Nro 2: Consultas SQL para el llenado de tablas hechos ....................................................... 75 Anexo 2.1 Consulta SQL para Consumo de Combustible. .............................................................. 75 Anexo 2.2 Consulta SQL para Portador Consumo. .............................................................................. 77 Anexo 2.3 Consulta SQL para Consumo Eléctrico. ............................................................................... 79.

(9) Contenido;Figuras;Tablas. LISTA DE FIGURAS CAPITULO 1 Figura 1.1 Etapas del proceso de diseño de un almacén de datos. ........................................................................... 15 Figura 1.2 Diagrama jerárquico de una dimensión. ...................................................................................................... 18 Figura 1.3 Principales pasos en el proceso de ETL. ..................................................................................................... 20 Figura 1.4 Ejemplo de cuadro de mando con Pentaho................................................................................................ 25. CAPITULO 2 Figura 2.1 Casos de uso del sistema. ................................................................................................................................. 34 Figura 2.2 Fases y actividades DWEP.............................................................................................................................. 38 Figura 2.3 Diagrama de actividad de los principales pasos del método. ............................................................... 40. CAPITULO 3 Figura 3.1 Arquitectura del sistema de apoyo a la toma de decisiones. ................................................................. 44 Figura 3.2 Despliegue del sistema de apoyo a la toma de decisiones..................................................................... 45 Figura 3.3 Mercado de datos Consumo_Combustible................................................................................................. 48 Figura 3.4 Mercado de datos Portador_Consumo. ........................................................................................................ 49 Figura 3.5 Mercado de datos Portador_Consumo. ........................................................................................................ 50 Figura 3.6 Cubos definidos mediante la herramienta Schema Workbench. .......................................................... 51 Figura 3.7 Secuencia de ejecución. Consumo de Combustible. ............................................................................... 52 Figura 3.8 Secuencia de ejecución. Portador Consumo. ............................................................................................. 53 Figura 3.9 Secuencia de ejecución. Consumo Eléctrico. ............................................................................................ 53 Figura 3.10 Paso Table Input en la Secuencia de ejecución Consumo Combustible. ....................................... 54 Figura 3.11 Paso String Operations en la Secuencia de ejecución Consumo Combustible. ........................... 54 Figura 3.12 Paso Modified Java Script Value en la Secuencia de ejecución Consumo Combustible. ......... 55 Figura 3.13 Paso Microsoft Excel Output en la Secuencia de ejecución Consumo Combustible. ................ 55 Figura 3.14 Job Consumo energuX. .................................................................................................................................. 56.

(10) Contenido;Figuras;Tablas CAPITULO 4 Figura 4.1 Reporte de consumo eléctrico semestral. .................................................................................................... 58 Figura 4.2 Parámetros de entrada para reporte consumo de combustible. ............................................................ 59 Figura 4.3 Reporte consumo de combustible por portador. ....................................................................................... 59 Figura 4.4 Comparación OLAP de consumo de combustible por portadores y año. ................................. 60 Figura 4.5 Comparación OLAP de consumo eléctrico por empresas y año. ........................................................ 60 Figura 4.6 Comparación OLAP de consumo de otros portadores por año............................................................ 61 Figura 4.7 Vista de fuente de datos para consumo de otros portadores. ................................................................ 61. LISTA DE TABLAS CAPITULO 2 Tabla 2.1 Descripción de los actores del sistema. ......................................................................................................... 34 Tabla 2.2 Casos de uso del sistema. .................................................................................................................................. 35. CAPITULO 3 Tabla 3.1 Matriz de Bus para DW. .................................................................................................................................... 47. CAPITULO 4 Tabla 4.1 Requerimientos de hardware recomendado para Pentaho. ..................................................................... 56 Tabla 4.2 Requerimientos de software para el sistema de apoyo a la toma de decisiones en el proceso de control de portadores energéticos....................................................................................................................................... 57.

(11) Introducción. INTRODUCCIÓN. Los recursos energéticos se están agotando a nivel mundial y se encarecen cada día. Todo país que intente mantener su desarrollo y/o desarrollarse debe mantener una política estable y sostenida de ahorro energético. Esto se traduce en llevar este ahorro a cada empresa, a cada área de la empresa, a cada equipo, etc. En las entidades cubanas se debe realizar diariamente un control del consumo de los portadores energéticos y valorar su comportamiento en el consejo de dirección mensual de la entidad, relacionándolo con los resultados productivos y de la prestación de los servicios, con el fin de tomar medidas dirigidas a la disminución de los índices de consumo por portador y la intensidad energética con respecto a lo alcanzado en cada periodo precedente, además, se realiza un diagnostico energético con el objetivo del análisis de los equipos mayores consumidores y la puesta en práctica de las soluciones técnicas organizativas que permitan obtener una mayor eficiencia energética, conformando un plan de medidas de ahorro de energía y portadores energéticos. Lo anterior expuesto conllevó a la definición del problema de esta investigación el cual radica en la Integración y el Análisis de los Datos para el Control de Portadores Energético, Solución de Inteligencia de Negocios (BI) en ayuda a la toma de decisiones en períodos de planificación en su distribución y utilización, que permita a los directivos de la actividad a nivel provincial, el análisis de esta con el fin de tomar decisiones inteligentes, para la mejora continua del proceso en dicho nivel. La investigación se centra en el objeto de estudio: Sistemas de apoyo a la toma de decisiones.. Objetivo general Para ello se plantea el siguiente objetivo general: Diseñar e implementar una solución de apoyo a la toma de decisiones en el proceso de control de portadores energéticos, que permita la integración de los datos del EnerguX, a partir de la recuperación de datos en su. 1.

(12) Introducción. almacenamiento. Además de la creación de vistas de análisis para los directivos de la actividad, con el fin de tomar decisiones inteligentes, para la mejora continua de sus procesos.. Objetivos específicos 1. Identificar los requisitos, enfoques y tendencias actuales en materia de diseño de herramientas de apoyo a la toma de decisiones en la literatura especializada y las experiencias prácticas nacionales e internacionales en este. (Técnicas y herramientas de BI). 2. Realizar el modelo de negocio y diseño de todas las fases y aspectos relevantes de los almacenes de datos, a través de un método global que abarque todas sus fases e integre los distintos modelos utilizados en cada una de ellas de una forma coherente. 3. Diseñar y desarrollar una solución al problema planteado. 4. Definir vistas de Reportes OLAP. Para dar cumplimiento al objetivo general y a los objetivos específicos trazados, el proceso de investigación se desarrolló en las fases siguientes:  Caracterización de la situación problemática. Fundamentación del problema de investigación a resolver. Diseño general de la investigación.  Revisión y análisis de la literatura especializada y otras fuentes relacionadas con el diseño de herramientas de apoyo a la toma de decisiones, las tendencias actuales tanto a nivel internacional como en Cuba. Elaboración del marco teórico-referencial.  Definir la herramienta de software a utilizar para el desarrollo del sistema de apoyo a la toma de decisiones en el proceso de control de portadores energéticos.  Diseñar el almacén de datos del cual se nutrirá el sistema de apoyo a la toma de decisiones.  Implementar el sistema de apoyo a la toma de decisiones en el proceso de control de portadores energéticos.  Comprobar el sistema desarrollado mediante su implantación en la empresa DESOFT de Villa Clara.. 2.

(13) Introducción. Se define como campo de acción: Sistemas de apoyo a la toma de decisiones para el proceso de control de portadores energéticos. Para dar cumplimiento a los objetivos trazados se emplearon los siguientes métodos:  Histórico – Lógico: Para determinar las tendencias actuales de desarrollo de los elementos relacionados en el desarrollo del presente trabajo.  Analítico – Sintético: Para llegar a conclusiones en la investigación a partir de la información que se procese y precisar características necesarias para la realización del trabajo propuesto.  Método Sistémico: Para definir los elementos del sistema de control de, así como sus relaciones. Estructura del trabajo: El presente trabajo se estructura de cuatro capítulos. En el primer capítulo, ―Análisis y especificación de requisitos en la toma de decisiones‖, se estructuran los requisitos y consta de una síntesis teórica acerca del diseño de almacenes de datos, así como la aplicación de los sistemas de apoyo a la toma de decisiones y las herramientas a utilizar. En el capítulo dos, ―Modelo de procesos y actividades del DW‖, se establecen pautas para el diseño de todas las fases y aspectos relevantes de los almacenes de datos teniendo en cuenta actores y casos de uso fundamentales del sistema. Un capítulo tres ―Arquitectura y diseño del sistema‖ que muestra el diseño del sistema de apoyo a la toma de decisiones en el proceso de control de portadores energéticos, la arquitectura de este, el diseño del almacén de datos y el proceso de extracción transformación y carga (ETL) y un capítulo cuatro ―Despliegue del sistema‖ que refleja despliegue y vistas de reportes OLAP. Finalmente se expone un cuerpo de conclusiones y recomendaciones generales derivadas del proceso de investigación realizado, el listado de la bibliografía referida en el trabajo y otras fuentes, así como un grupo de glosario de términos y anexos necesarios para la mejor comprensión y fundamentación de su contenido.. 3.

(14) Capítulo 1. Análisis y especificación de requisitos en la toma de decisiones..

(15) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. CAPÍTULO 1. ANÁLISIS Y ESPECIFIC ACIÓN DE REQUISITOS EN LA TOMA DE DECISIONES.. Introducción En el presente capítulo se realiza una evaluación del estado del arte referente al estudio de los sistemas basados en la toma de decisiones, se muestra un análisis de la literatura especializada y otras fuentes, con vistas a precisar los principales aspectos conceptuales involucrados en la investigación realizada, permitiendo sentar las bases teórico-prácticas del proceso de investigación para dar solución a la especificación de requisitos tratada en el problema planteado.. 1.1 Especificación y análisis de requisitos EnerguX es un software destinado al control estricto de los portadores energéticos y está diseñado para obtener una serie de datos estadísticos que pueden ser de gran utilidad para el control de estos. La arquitectura de la aplicación consta de varios paquetes, que de alguna manera estructuran el almacenado de datos: . Paquete de Nomencladores (Ver Anexo 1.1). . Paquete Tarjeta (Ver Anexo 1.2). . Paquete Portadores (Ver Anexo 1.3). . Paquete Transporte (Ver Anexo 1.4). . Paquete Histórico (Ver Anexo 1.5). A partir de lo que está reflejado y brinda EnerguX, en una empresa se necesita llevar el consumo de los portadores energéticos. Cada consumo debe relacionarse con el centro de costo o área que consume y la actividad en concreto. El consumo se mide en diferentes unidades de medida en dependencia del portador (litros, etc.) y tiene un importe en una moneda. En ocasiones es necesario llevar el control del consumo que se realiza, pagando el servicio por tarjeta a un proveedor.. 5.

(16) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Teniendo en cuenta estos factores, para la obtención de reportes avanzados y herramientas para el apoyo a la toma de decisiones, los directivos precisaron en gran medida: -. Obtener informe que muestre períodos del año con igual nivel de producción y diferentes consumos por tipo de portador, que ayude a identificar los factores que han provocado este comportamiento.. -. Analizar el comportamiento del índice de consumo durante un período de tiempo dado que le sirva de apoyo a los directivos de la empresa para determinar los factores que influyen en las variaciones de dicho índice a nivel de empresa.. -. Determinar los índices de consumo por portador energético a planificar para un nivel de producción previsto.. -. Analizar el comportamiento del consumo de cada portador durante un período de tiempo para la toma de decisiones a la hora de confeccionar el plan de consumo.. -. Determinar los meses del año donde el consumo de electricidad es mayor que le permita a los directivos tomar acciones para el ahorro de este portador.. -. Obtener informe que permita detectar vehículos que para igual cantidad de kms recorridos tengan diferentes consumos, que ayude a identificar las causas de este comportamiento.. 1.2 Factor toma de decisiones Continuamente, las personas deben elegir entre varias opciones, aquellas que consideren más favorables, tomando gran cantidad de decisiones en su vida cotidiana, con mayor o menor grado de importancia, fáciles o difíciles de tomar y en función de las consecuencias o resultados derivados de cada una de ellas. El proceso de toma de decisiones puede ser realizado desde varios enfoques, la ―teoría de la decisión‖ y ―decisión y elección‖. La teoría de la decisión es un enfoque enmarcado en un ámbito predominante matemático, basado en modelos, que permiten utilizar ecuaciones y generar, con éstas, resultados para la toma de una decisión; mientras el enfoque ―decisión y elección‖ utiliza la asociación de nociones con. 6.

(17) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. implícitas opciones de libertad, siendo un campo de discusión para filósofos, sociólogos y psicólogos.. 1.2.1 Desarrollo de la toma de decisión Muchos han sido los criterios que definen en que consiste el proceso de la toma de decisiones, tal es así que decidir significa adoptar una posición implicando dos o más alternativas bajo consideraciones y las personas que decidan tendrán que elegir entre ellas. Para Ponniah (2001) es la forma como el hombre se comporta y actúa conforme a maximizar u optimizar ciertos resultados. Tomando las decisiones como reacción a un problema. Según John People (2003) la toma de decisiones ―Es un proceso mental, mediante el cual un directivo recopila información y la utiliza. Los directivos de manera individual o por equipos, gestionan y controlan la información y por lo tanto, el entorno de su empresa, preguntando a los demás, aclarando sus respuestas para encontrar la información relevante y analizar los datos recopilados‖. Para Performance (2006) el proceso de toma de decisiones es ―encontrar una conducta adecuada para una situación en la que hay una serie de sucesos inciertos. Una vez determinada cuál es la situación, para tomar decisiones es necesario elaborar acciones alternativas, extrapolarlas para imaginar la situación final y evaluar los resultados teniendo en cuenta la incertidumbre de cada resultado y su valor‖. Analizadas y expuestas algunas de las definiciones que existen de toma de decisiones, la gran mayoría coincide en que es un proceso mental mediante el cual se recopila información y en base a dicha recopilación se encuentra la solución o decisión adecuada.. 1.2.2 Tipos de decisiones Existen dos tipos de toma de decisiones:  Programadas  No programadas 7.

(18) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Las programadas son aquellas tomadas de acuerdo con alguna política, reglas o procedimientos. Siendo las políticas las que simplifican la toma de decisiones en situaciones recurrentes al limitar o excluir opciones, por ejemplo la decisión del salario a pagar a un trabajador contratado esta decisión está condicionada por una escala de sueldos para todos los puestos de trabajo. Las decisiones programas se aplican cuando se tratan de decisiones complejas y no complejas pero generalmente se usan para solucionar problemas de rutinas determinadas por reglas, procedimientos o hábitos. Son apropiadas para problemas estructurados y decisiones de rutina. (Inmon, 2002). Las decisiones no programadas son aquellos problemas que no se comprenden bien, no están bien estructurados, tienden a ser únicos y no llevan a procedimientos rutinarios o sistemáticos. La clave para entenderlas es recordar que suceden infrecuentemente y debido a que ocurren raramente, existen pocos precedentes para la toma de decisión. Estas dependen excesivamente de las capacidades de la toma de decisiones de los ejecutivos porque no hay soluciones rutinarias disponibles. Los ejecutivos emplearán los datos de problemas y desempeños pasados, analizando analogías históricas. (Kimball, 1998).. 1.3 Sistemas de apoyo a la toma de decisiones Dy (2002) define a los Sistemas para el Soporte de Decisiones (DSS), como un conjunto de programas y herramientas que permiten obtener oportunamente la información requerida durante el proceso de la toma de decisiones, en un ambiente de incertidumbre. A lo anterior se agrega que, en la mayoría de los casos, lo que constituye el detonante de una decisión es el tiempo límite o máximo en el que se debe tomar. Así, en cada decisión que se toma, siempre se podrá pensar en que no se tiene toda la información requerida; sin embargo, al llegar al límite de tiempo, se deberá llegar a una decisión, trayendo consigo que el verdadero objetivo de un sistema de apoyo a la toma de decisiones sea proporcionar la mayor cantidad de información relevante en el menor tiempo posible, con el fin de decidir lo más adecuado. Cuando los datos han dejado de ser simples letras y cantidades, se analizan de manera que se pueda obtener una ventaja competitiva; se podrán ver ventajas de ahorros y sobre todo se tomarán decisiones basadas en datos reales y actuales de tal forma que el tiempo para la toma de 8.

(19) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. decisiones se disminuya y esto a su vez permita generar acciones para generar ventajas. (Kimball, 1996). Los sistemas de apoyo a la toma de decisiones generalmente se componen de reglas y mecanismos y una base de conocimiento organizacional donde se encuentran diferentes alternativas a la solución de un problema específico. Esto permite en el caso de los administradores de dichos sistemas, que éstos puedan visualizar qué pasará si decide tomar una decisión o si decide cambiarla y combinarla con otros escenarios. Objetivos de los sistemas de apoyo a la toma de decisiones: (Kimball, 2008).  Disminución de tiempo en la toma de decisiones.  Generar información confiable para poder tomar decisiones correctas.  Disminución de costos para la toma de decisiones.  Aumento de productividad.  Conduce a un análisis de, ¿qué pasa si?  Explora impactos de futuras oportunidades. Características de los sistemas de apoyo a la toma de decisiones (Kimball & Ross, 2010):  Brindan informes dinámicos, flexibles e interactivos, de manera que el usuario no tenga que ceñirse a los listados predefinidos que se configuraron en el momento de la implantación y que no siempre responden a sus dudas reales.  No requiere conocimiento técnico de los usuarios para crear nuevos gráficos e informes y navegar entre ellos, haciendo drag&drop o dril through. Por tanto, para examinar la información disponible o crear nuevas métricas no es imprescindible buscar ayuda en el departamento de informática.  Rapidez en el tiempo de respuesta ya que la base de datos subyacente suele ser un datawarehouse corporativo o un datamart, con modelos de datos en estrella o copo de nieve permitiendo analizar grandes volúmenes de información.  Permite la integración entre todos los sistemas o departamentos de la compañía ya que el proceso de Extract, Transform and Load (ETL) previo a la implantación de un Sistema de Soporte a la Decisión garantiza la calidad y la integración de los datos entre las diferentes unidades de la empresa. Proporciona la integridad referencial absoluta. 9.

(20) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”.  La disponibilidad de información histórica en estos sistemas está a la orden del día, pues se puede comparar los datos actuales con información de otros períodos históricos de la entidad, con el fin de analizar tendencias y fijar la evolución de los parámetros de negocios.. 1.4 Almacén de datos Un Almacén de Datos (DW) por sus siglas en inglés (Data Warehouse) es una base de datos corporativa de apoyo a la toma de decisiones que se caracteriza por integrar datos crudos de una o más fuentes distintas, depurando y almacenando la información necesaria de forma organizada para luego procesarla, permitiendo su análisis desde múltiples perspectivas y con grandes velocidades de respuesta (Galemmo, 2003). Permiten, tener una visión más completa e integral de los procesos, dado que el resultado de su implementación es conocimiento acerca del funcionamiento de la organización. Según John People (2003) el negocio moderno descansa sobre datos, la cantidad total de datos en las computadoras se duplica cada cinco años y debe duplicarse cada año en el futuro; la información se está convirtiendo en un componente clave de todo producto o servicio, siendo importante el almacenamiento de datos actual como historico, para un correcto análisis en la toma de desiciones. Thornthwaite (2006) manifiesta que los sistemas de bases de datos tradicionales satisfacen los requerimientos de la actualizacion de la información; por eso se usan ampliamente en los Sistemas de Procesamiento Electrónicos de Datos (SPED) y los Management Informations Systems (MIS). Sin embargo, la histórica alcanza su mayor valor cuando se quiere desarrollar un sistema de apoyo a la toma de decisiones; en la actualidad la tecnología de bases de datos orientado a este propósito se conoce como almacén de datos. Inmon (2002) define un almacén de datos como una base de datos orientada a ayudar a la toma de decisiones, la cual contiene una enorme cantidad de información en la que la dimensión de tiempo forma parte de las llaves para poder soportar su evolución histórica. Varios (R. Kimball, 1998) definen un almacén de datos, desde la perspectiva de un sistema de apoyo a la toma de decisiones, como un almacén inteligente y activo de datos que puede manipular y agregar información a partir de muchas fuentes, distribuir ésta donde se necesite y activar políticas de negocios. 10.

(21) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Según la definición más tradicional del término DW, especificada por Bill Inmon (2002), los DW se caracterizan por ser: . Orientados al Sujeto: Los datos almacenados brindan información sobre un sujeto o asunto en particular en lugar de concentrarse en la dinámica de las transacciones de la organización.. . Integrado: Los datos cargados en el DW pueden provenir de diferentes fuentes y son integrados para dar una visión global coherente.. . Variables en el Tiempo: El DW se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones, lo que implica que todos los datos deben estar asociados con un período de tiempo específico.. . No volátiles: Los datos son estables en el DW, se agregan y modifican datos, pero los datos existentes no son removidos.. La creación de un DW representa en la mayoría de las ocasiones uno de los primeros pasos, desde el punto de vista técnico, para implantar una solución completa y fiable de BI. Al no generar datos por sí mismos se dice que este tipo de sistemas son fuentes secundarias de información, alimentados desde fuentes de datos externas.. Las áreas o componentes básicos que conforman un sistema de DW definidas por Kimball (1996) son : . Sistemas de Datos Fuentes: Donde se encuentra la información relevante que va a ser utilizada y cargada en el DW.. . Área de almacenamiento temporal: Aquí se guardan los datos limpios, combinados y estandarizados dentro de un sistema temporal de almacenamiento y sobre el cual se realizan procesamientos secuenciales de trabajos.. . ETL: Procesos que permiten obtener datos de distintas fuentes y depurarlos por medio de transformaciones para finalmente cargarlos en el DW.. . Área de presentación de datos: Es donde la información es organizada, almacenada y habilitada para la consulta directa de los usuarios finales. 11.

(22) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. . Área de Herramientas de acceso a datos: Corresponde a las herramientas de acceso a los datos del área de presentación y que permiten realizar análisis sobre los mismos.. Inmom (2005) afirma que un almacén de datos constituye los fundamentos arquitectónicos de los sistemas de apoyo a la toma de decisiones, por cuanto crean las condiciones para el éxito y la eficiente explotación de los datos como un recurso. Un enfoque popular para un almacén de datos son los llamados (OLAP); las herramientas OLAP ofrecen análisis multidimensionales de datos, superando al lenguaje de manipulación de datos más usado Structured Query Language (SQL). Claudia Imhoff (2003) ha reconocido que el principal problema en el procesamiento de la información es cómo procesar bases de datos cada vez más grandes y conteniendo datos cada vez más complejos, sin sacrificar los tiempos de respuesta. Las técnicas OLAP constituyen una categoría de aplicaciones para abordar dichas problemáticas; los servidores de bases de datos OLAP usan estructuras multidimensionales para almacenar datos y sus interrelaciones. Un ejemplo de una base de datos OLAP es que pueden ser usadas en el tratamiento de las ventas. Una consulta OLAP se puede caracterizar como una transacción on-line en la que: (V. Harinarayan, 2000).  Se accede a grandes volúmenes de datos.  Se requiere la interrelación entre diferentes elementos de la actividad.  Involucra datos agregados.  Compara datos agregados sobre períodos de tiempos jerárquicos. Estas características, unidas a otras, hacen que los servidores OLAP traten el almacenamiento de datos de forma no tradicional para responder de forma dinámica y con la eficiencia requerida a nuevos requerimientos y perspectivas de los sistemas de gestión de bases de datos.. 1.4.1 Proceso de diseño de un almacén de datos En la construcción de un almacén de datos se necesitan herramientas para ayudar a la migración y a la transformación de los datos hacia el almacén. Una vez construido, se requieren medios para manejar grandes volúmenes de información. Se diseña su arquitectura dependiendo de la 12.

(23) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. estructura interna de los datos del almacén y especialmente del tipo de consultas a realizar. Con este criterio los datos deben ser repartidos entre numerosos mercados de datos. (Ralph Kimball, 2004) . Los mercados de datos son subconjunto definido de un almacén de datos representando una unidad de negocios de un almacén de datos enteros, por ejemplo el marketing dentro de una compañía. (Greenfield, 2014). Para abordar un proyecto de almacén de datos es necesario hacer un estudio de algunos temas generales de la organización o empresa. Permitiendo que sean analizados algunos términos como:  Situación actual de partida: pues cualquier solución propuesta de almacén de datos debe estar orientada por las necesidades del negocio y debe ser compatible con la arquitectura técnica existente y planeada de la compañía.  Decidir qué proceso(s) de negocio se van a modelar, es decir qué ―hechos‖ interesa analizar, combinando un entendimiento del negocio con un entendimiento de cuáles son los datos disponibles.  Tipo y características del negocio: es indispensable tener el conocimiento exacto sobre el tipo de negocio de la organización y el soporte que representa la información dentro de todo su proceso de toma de decisiones.  Decidir sobre la granularidad del almacén datos, es decir el nivel de detalle de datos que se tendrá en el almacén de datos que puede ir desde transacción por transacción hasta agregados por día, semana, mes o como se decida.  Definir por cuáles dimensiones se quieren analizar los hechos.  Una vez identificado el proceso de negocio de interés se pueden identificar las medidas a analizar.  Se debe decidir cómo almacenar ―las dimensiones que cambian lentamente en el tiempo‖. En (Ross, 2002) se hace alusión de tres alternativas: a) Sobrescribir los valores viejos en el registro de la dimensión y por lo tanto perder la posibilidad de rastreo histórico.. 13.

(24) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. b) Crear un registro adicional en la dimensión al momento del cambio con los valores nuevos de los atributos. c) Crear nuevos campos en el registro llamado actuales. d) Entorno técnico: Se debe incluir tanto el aspecto del hardware (mainframes, servidores, redes) así como aplicaciones y herramientas.  Expectativas de los usuarios: un proyecto de almacén de datos no es únicamente un proyecto tecnológico, es una forma de vida de las organizaciones y como tal, tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad.  El ―envejecimiento‖ de los datos define cuánta información del almacén de datos va estar disponible en línea y cómo y dónde se va almacenar aquella que ya es más vieja, en dependencia de lo que defina la empresa en cuestión.  Etapas de desarrollo: con el conocimiento previo ya se entra en el desarrollo de un modelo conceptual para la construcción del almacén de datos.  Prototipo: un prototipo es un esfuerzo designado a simular tanto como sea posible el producto final que se entrega a los usuarios.  Piloto: el piloto de un almacén de datos es el primero, o cada uno de los primeros resultados generados de forma iterativa que se hacen para llegar a la construcción del producto final.  Prueba del concepto tecnológico: es un paso opcional que se puede necesitar para determinar si la arquitectura especificada del almacén de datos funcionará finalmente como se espera.. 1.4.2 Etapas del proceso de diseño de un almacén de datos El proceso de diseño del almacén de datos puede dividirse en tres etapas secuenciales: diseño conceptual, diseño lógico y diseño físico. En la Figura 1.1 se muestran las etapas con sus respectivas entradas y salidas de información.. 14.

(25) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Figura 1.1 Etapas del proceso de diseño de un almacén de datos.. Diseño conceptual: En esta etapa se construye un esquema conceptual de la realidad a partir de los requerimientos y/o bases fuentes. Dicho esquema conceptual es enriquecido con requerimientos de desempeño y almacenamiento durante la etapa de diseño lógico y a partir de él se genera un esquema lógico, que es dependiente del tipo de modelo y tecnología de DBMS (Database Management System). Este diseño tiene por objetivo la construcción de una descripción abstracta y completa del problema. Comienza con el análisis de requerimientos de los usuarios y de reglas de negocio y finaliza con la construcción de un esquema conceptual expresado en términos de un modelo conceptual.. Diseño lógico: La etapa de diseño lógico toma como entrada un esquema conceptual y genera un esquema lógico relacional o multidimensional. La dificultad principal es encontrar un esquema lógico que satisfaga, no sólo los requerimientos funcionales de información, sino también requerimientos de desempeño en la realización de consultas complejas de análisis de datos. Tiene particular 15.

(26) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. impacto en el uso de bases relacionales ya que las consultas de análisis de datos incluyen operaciones muy costosas para DBMS relacionales. Algunas metodologías parten de un esquema conceptual y proveen mecanismos para generar un esquema lógico a partir de él; otras metodologías pasan por alto el modelado conceptual y construyen el esquema lógico a partir de los requerimientos y/o las bases fuentes. El resultado de esta etapa es la especificación formal de un esquema lógico para el almacén de datos. En el enfoque basado en vistas, el almacén de datos se ve como un conjunto de vistas materializadas de las bases fuentes. Estos trabajos no se centran en la representación de conceptos multidimensionales, como dimensiones y medidas, sino en materializar algunas vistas para un desempeño en un conjunto dado de consultas. Diseño físico o Modelo multidimensional: El diseño físico es conocido como modelo multidimensional. Este tipo de diseño tiene como ventajas que es muy flexible, está desnormalizado y orientado a los intereses de un usuario final. Mediante la utilización de un Multichannel Multipoint Distribution Service (MMDS) se disminuye la cantidad de tablas y relaciones entre ellas, agilizando el acceso a los datos y define además los aspectos físicos del almacén de datos como el almacenamiento de las estructuras lógicas en diferentes discos o la configuación de los servidores de bases de datos que mantienen el almacén de datos.. 1.4.3 Tablas de hechos Las tablas de hechos son las medidas del negocio, representan la ocurrencia de un determinado proceso dentro de la organización y no tienen relación entre sí. Generalmente, almacenan medidas numéricas, las que representan valores de las dimensiones, aunque en ocasiones éstas no están presentes y se les denominan ―tablas de hechos sin hechos‖. La llave de la tabla de hecho es una llave compuesta pues se forma de la composición de las llaves primarias de las tablas dimensionales con las que tiene relación. (Ross, 2002).. 16.

(27) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Las tablas de hechos pueden contener un gran número de filas, a veces cientos de millones de registros cuando contienen uno o más años de la historia de una gran organización, la cardinalidad es acotada superiormente por la cardinalidad de las tablas dimensionales. Se requiere que los nombres de los hechos conformados sean únicos y con una interpretación clara e inequívoca, además deben utilizarse las mismas unidades de medida. Una característica importante de las tablas de hecho es el ―nivel de detalle‖ de la información que se almacena. Es muy importante no cometer el error de añadir dimensiones en una tabla de hechos antes de definir su granularidad. De hecho, la creación de una tabla de hechos es una tarea con poco margen a la imaginación. Debe localizarse el origen de la información que se quiere cargar, entenderse perfectamente el significado de estos indicadores y determinar el nivel de detalle de estos datos. Una vez hecho esto, la creación de la estructura de la tabla es inmediata.. 1.4.4 Tablas de dimensiones Según Merz (2000) se denominan dimensiones a los datos que permiten filtrar, agrupar o seccionar la información. Las tablas de dimensiones contienen, generalmente, una llave simple y atributos que la describen. En dependencia del esquema de diseño que se asuma pueden contener llaves foráneas de otras tablas de dimensión. Existe una dimensión fundamental en todo almacén de datos, la dimensión tiempo que ocurre porque todo registro que se incluya constituye la ocurrencia de un fenómeno en un instante de tiempo definido. Dicha dimensión es la que establece uno de los objetivos fundamentales de la construcción de un almacén de datos, la conservación de un ―histórico‖. La calidad del modelo multidimensional, dependerá en gran parte de cuán descriptivos y manejables sean los atributos dimensionales para ello se establecen niveles jerárquicos Figura 1.2, por lo que es un error abreviar las descripciones en las dimensiones con la intención de reducir el espacio requerido.. 17.

(28) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Figura 1.2 Diagrama jerárquico de una dimensión.. 1.5 Esquemas para el modelado en el almacén de datos Para el diseño del almacén de datos es necesario definir los posibles esquemas que conforman el modelo del almacén. Existen tres esquemas con características particulares, que permiten elegir, entre ellos, el más factible para diseñar el sistema de apoyo a la toma de decisiones en el proceso de control de portadores energéticos. 1. Estrella (Star) El esquema de estrella es la arquitectura de almacén de datos más simple. En este esquema la tabla de hechos está rodeada por dimensiones, permitiendo que se forme una estructura que permite implementar mecanismos básicos para poder utilizarla con una herramienta de consultas OLAP. (Zhou, 2014) El esquema estrella del almacén de datos implementa un diseño lógico relacional de base de datos, por lo que las tablas de hechos alcanzan la Tercera Forma Normal (3FN) y las dimensiones tienen Segunda Forma Normal (2FN). En este modelo, para obtener información solicitada no hay que construir una sentencia SQL muy compleja que lea muchas tablas de una vez. Una herramienta de consultas sólo tiene que acceder una tabla.. 18.

(29) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. La clave primaria de una tabla de hechos está formada por todas las columnas que corresponden a las dimensiones. Las columnas que contienen los datos numéricos no forman parte de la clave primaria, porque están agregadas en los informes. Se puede encontrar la mayoría de la información de una tabla de hechos en una tabla de dimensiones. Lo característico de la arquitectura de estrella es que sólo existe una tabla de dimensiones para cada dimensión y esta tabla representa la segunda forma normal. Este esquema es ideal por su simplicidad y velocidad para ser usado en análisis multidimensionales (OLAP, mercado de datos). Permite acceder tanto a datos agregados como de detalle. El diseño de esquemas en estrella permite implementar la funcionalidad de una base de datos multidimensional utilizando una clásica base de datos relacional (más extendidas que las multidimensionales). (Greenfield, 2014). 2. Copo de Nieve (Snowflake) El esquema en copo de nieve (bola de nieve) es una variedad más compleja del esquema estrella. El afinamiento está orientado a facilitar el mantenimiento de dimensiones. Su arquitectura se distingue, porque las tablas de dimensiones en este modelo representan relaciones normalizadas (3NF) y forman parte de un modelo relacional de base de datos. 3. Constelación de hechos (Fact Constellation Schema) Para cada esquema estrella o esquema del copo de nieve en el diseño de un almacén de datos es posible construir un esquema de constelación de hechos. Este esquema es más complejo que las otras arquitecturas debido a que contiene múltiples tablas de hechos, pero permite que las tablas de dimensiones puedan estar compartidas entre más de una tabla de los hechos. Este esquema tiene mucha flexibilidad siendo su mayor ventaja. Sin embargo su mayor problema es cuando el número de las tablas vinculadas aumenta la arquitectura puede llegar a ser muy compleja y difícil de mantener.. 19.

(30) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Por las razones expuestas anteriormente y además utilizar los esquemas en estrella aprovechando su simplicidad desde el punto de vista del usuario final, las consultas no son complicadas ya que las condiciones y las uniones (joins) necesarias sólo involucran a la tabla de hechos y a las de dimensiones, no haciendo falta que se encadenen uniones y condiciones a dos o más niveles como ocurriría en un esquema en copo de nieve. En el trabajo se hace uso de este diseño por su simplicidad, rendimiento y velocidad pues permite indexar las dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de datos en su conjunto, en comparación con respecto a otros diseños, como los de copo de nieve que es utilizado cuando las tablas de dimensiones están muy grandes o complejas y es muy difícil representar los datos en esquema estrella, más simple también respecto al diseño de constelación de hechos debido a que este contiene múltiples tablas de hechos.. 1.6 Integración de datos La integración de datos es un proceso que consta de tres actividades principales que se realizan sobre los datos, extracción, transformación y carga (ETL). Los pasos a seguir para realizar estas actividades se muestran en la Figura 1.3. (Zhou, 2014).. Figura 1.3 Principales pasos en el proceso de ETL.. 20.

(31) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. El encargado de la actualización y el mantenimiento del almacén de datos es el proceso de extracción, transformación y carga. Dicho proceso tiene dos funciones principales: (Ralph Kimball, 2004). 1. La carga inicial: permite poblar inicialmente el almacén con los datos extraídos desde los diferentes sistemas operacionales. Generalmente se utiliza para rellenar las tablas de dimensiones. 2. Mantenimiento o actualización periódica: es el encargado de mantener actualizados los datos del almacén y cuyo período de actualización puede ser inmediato, diario, semanal, mensual, etcétera, de acuerdo a las necesidades de la empresa. Algunas definiciones: . Transformación: la transformación es el elemento básico de diseño de los procesos ETL. Una transformación se compone de pasos o steps, que están enlazados entre sí a través de los saltos o hops. Los pasos son el elemento más pequeño dentro de las transformaciones. Una transformación no es ningún programa ni un ejecutable, simplemente es un conjunto de metadatos en XML (eXtensible Markup Language) que le indican al motor de Pentaho Data Integration (PDI) las acciones a realizar.. . Saltos: los saltos constituyen el elemento a través del cual fluye la información entre los diferentes pasos (siempre es la salida de un paso y la entrada de otro).. . Trabajo: es un conjunto sencillo o complejo de tareas con el objetivo de realizar una acción determinada. En los trabajos se pueden utilizar pasos específicos (que son diferentes a los disponibles en las transformaciones) como para recibir un fichero vía ftp, mandar un email o ejecutar un comando. Además, se puede ejecutar una o varias transformaciones de las que se hayan diseñado y orquestar una secuencia de ejecución de ellas. Los trabajos estarían en un nivel superior a las transformaciones.. Los especialistas de ETL tienen una misión de alto grado de complejidad que consiste de manera general en construir la trastienda del almacén de datos. Específicamente: . Proporcionar los datos de manera más eficiente para las herramientas de usuarios finales.. . Adicionar valor a los datos en los pasos de limpieza y consolidación. 21.

(32) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. . Proteger y documentar el linaje de los datos.. . Asegurar la calidad y limpieza de los datos.. 1.7 Herramientas para el desarrollo de sistemas de apoyo a la toma de decisiones En la implementación de un sistema de apoyo a la toma de decisiones existen varias tecnologías o herramientas que permiten el desarrollo del mismo. Se deben utilizar un conjunto de herramientas que permitan establecer una cooperación entre ellas para transitar por las diferentes etapas del proceso de extracción, transformación, carga en el almacén de datos y análisis de los datos hasta la visualización de los resultados. De las herramientas definidas, PDI es una de las más utilizadas en el mundo para implementar una solución que realmente responda a las necesidades en este caso de la información de los directivos en el proceso de control de portadores energéticos, aunque existen otras.. Entre las más destacadas se encuentran: . Oracle Database 10g R2 Enterprise Edition. . Oracle Warehouse Builder 10g. . PL / SQL Developer. . Oracle Discoverer. . SQL Serverx. . Cognos. Pentaho es un proyecto iniciado por la comunidad Open Source, provee una Suite completa para desarrollar soluciones de BI a la altura de las soluciones comerciales existentes en el mercado. La solución al igual que su ambiente de implantación están basados en el lenguaje de programación JAVA, haciéndolo flexible para cubrir amplias necesidades empresariales. Esta herramienta será la que se utilizará en el desarrollo de la solución de inteligencia de negocio dado sus características que serán ampliadas en el desarrollo del trabajo, su condición de 22.

(33) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. software libre, utilización en empresas cubanas y dominio de la misma para un mejor desenvolvimiento de desarrollo. La Suite de inteligencia de negocio Open Source Pentaho integra funcionalmente diversos proyectos de Open Source, permitiendo ofrecer soluciones en áreas como: OLAP, reportes, tableros de mando, flujos de trabajo (del inglés workflow) y minería de datos. La Suite inteligencia de negocio Open Source Pentaho pretende ser una alternativa a las soluciones propietarias tradicionales más completas: Systeme, Anwendungen und Produkte (SAP), Cognos, Microstrategy, Microsoft, etcétera, por lo que incluye todos aquellos componentes que se encuentran en las soluciones BI propietarias más avanzadas. Algunas de sus características son: . Plataforma 100% J2EE, asegurando la escalabilidad, integración y portabilidad.. . Servidor: servidores compatibles con J2EE como JBOSS AS, WebSphere, Tomcat, WebLogic y Oracle AS.. . Bases de datos: vía JDBC (Java Database Connectivity), IBM (International Business Machinies) DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, NCR Teradata, Firebird.. . Sistema operativo: no hay dependencia. Lenguaje interpretado.. . Lenguaje de programación: Java, Java Script, JSP (Java Server Pages), XSL (XSLT/XPath/XSL-FO).. . Interfaz de desarrollo: Java SWT, Eclipse, Web-based.. . Repositorio de datos basado en XML.. . Todos los componentes están expuestos vía Web Services para facilitar la integración con Arquitecturas Orientadas a Servicios (SOA).. La Suite inteligencia de negocio Open Source Pentaho está construida en torno al servidor de aplicaciones J2EE JBoss y Jboss Portal, habilitando que toda la información sea accesible mediante un browser. Presenta informes en los formatos habituales (html, excel, pdf) mediante JfreeReport. Para la generación de PDFs utiliza Apache FOP.. 23.

(34) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. Incorpora la biblioteca JPivot, gracias a la cual se pueden ver tablas OLAP a través de un browser y realizar las aplicaciones típicas de análisis OLAP. Todas las plataformas y herramientas anteriormente mencionadas se basan en la extensión de las necesidades de la empresa y de la diversidad de datos que ésta deberá manejar. Por esta razón, la filosofía de cada una se basa en la construcción de productos cada vez más veloces y potentes, que crezcan con la empresa y manejen absolutamente todos los tipos requeridos, esto implica que se necesiten tecnologías de última generación para poder desarrollarlos. Características de la herramienta Pentaho: Pentaho se define a sí mismo como una plataforma de inteligencia del negocio ―orientada a la solución‖ y ―centrada en procesos‖ que incluye los principales componentes requeridos para implementar soluciones basados en procesos: A continuación se muestra una breve descripción de algunas de las herramientas que componen la Suite. a) Kettle Está formada por un conjunto de herramientas, cada una con un propósito específico: . Spoon: es la herramienta gráfica que permite el diseño de las transformaciones y trabajos. Incluye opciones para pre visualizar y probar los elementos desarrollados. Es la principal herramienta de trabajo de PDI y con la que se van a construir y validar los procesos ETL.. . Pan: es la herramienta que permite la ejecución de las transformaciones diseñadas en spoon (desde un fichero o desde el repositorio). Permite desde la línea de comandos preparar la ejecución mediante scripts.. . Kitchen: presenta características similares a Pan, pero permite ejecutar los trabajos o jobs.. . Carte: es un pequeño servidor web que permite la ejecución remota de transformaciones y jobs.. 24.

(35) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. b) Schema Workbench Esta herramienta genera archivos XML que se publican en el servidor de Pentaho para la construcción de los cubos. Es una interfaz de diseño que permite crear y probar esquemas de cubos OLAP Mondrian visualmente. c) Pentaho CDF La Comunity Dashboard Framework (CDF) es un conjunto de tecnologías que permiten a los desarrolladores de BI crear cuadros de mando dinámico. Los CDF son páginas web que utilizan la tecnología ajax para combinar de forma dinámica los componentes de BI, tales como gráficos, tablas OLAP y mapas. En la Figura 1.4 se puede observar un ejemplo de tablero de instrumentos de apoyo al cliente creado con Pentaho. En este tablero se incluye visualizaciones avanzadas como gráficas de barras y de pastel además de una tabla desplegable.. Figura 1.4 Ejemplo de cuadro de mando con Pentaho.. 1.8 Conclusiones parciales En la literatura consultada existe una gran variedad de información acerca de los sistemas de apoyo a la toma de decisiones y almacenes de datos, lo que permitió realizar una valoración de. 25.

(36) Capítulo 1: “Análisis y especificación de requisitos en la toma de decisiones.”. las posibles herramientas a utilizar para el sistema de apoyo a la toma de decisiones en el proceso de control de portadores energéticos. Luego de un profundo análisis se decidió: 1- Utilizar el esquema de la estrella para el diseño del almacén de datos del sistema. 2- Utilizar la Suite Open Source Pentaho Business Intelligence, por ser la herramienta más completa entre las valoradas y la más adecuada a usar por las empresas cubanas por su condición de Open Source.. 26.

(37) Capítulo 2. Modelo de procesos y actividades del DW..

(38) Capítulo 2: “Modelo de procesos y actividades del DW”.. CAPÍTULO 2. MODELO DE PROCESOS Y ACTIVIDADES DEL DW.. Introducción Dada la gran variedad de modelos utilizados en las distintas fases de diseño de los almacenes de datos, se hace absolutamente necesario abarcar un método lo más estándar posible que proporcione guías de diseño para crear y transformar estos modelos durante la fase de desarrollo de un almacén de datos. En la actualidad, existen métodos para el desarrollo de almacenes de datos. Sin embargo, muchos de ellos no cubren todas las fases y transformaciones necesarias para disponer de un estándar para el diseño de almacenes de datos. Teniendo en cuenta esto junto con el modelo y especificación de los casos de uso que a continuación se describe, en el capítulo se establecerán pautas importantes para el desarrollo del trabajo.. 2.1. Modelo de casos de uso del sistema. El modelado de casos de uso es un método para identificar las necesidades funcionales del problema, que en este caso particular dichas necesidades constan de los procesos fundamentales que se deben tener en cuenta para desarrollar nuestra solución de inteligencia de negocio. La Figura 2.1 muestra el modelo de casos de uso del sistema correspondiente a dicha solución.. 33.

(39) Capítulo 2: “Modelo de procesos y actividades del DW”.. Figura 2.1 Casos de uso del sistema.. 2.1.1 Nombre y descripción de los actores del sistema En la Tabla 2.1 se define por cada actor del sistema el nombre y una breve descripción. Tabla 2.1 Descripción de los actores del sistema.. Actor del sistema. Descripción. Administrador. Se denomina Administrador al encargado en este caso de definir y gestionar nuevas Bases de Conocimientos (BC) así como interactuar y manipular los datos para futuros reportes.. Directivo. Encargado de realizar y visualizar las consultas al sistema.. 34.

(40) Capítulo 2: “Modelo de procesos y actividades del DW”.. 2.1.2 Nombre y descripción de los casos de uso del sistema En la Tabla 2.2 se define por cada caso de uso nombre y una breve descripción. Tabla 2.2 Casos de uso del sistema.. Caso de uso del sistema. Descripción. Editar (BC). Escenario que permite al administrador introducir las reglas de conocimiento, modificarlas, así como crearlas y borrarlas.. Desarrollar procesos de ETL. Escenario donde el administrador extrae, modifica y carga los datos estableciendo un mapeo que permite establecer posteriormente la visualización de los mismos.. Gestionar Reportes (BC). Escenario donde el administrador diseña y publica los reportes a disposición de usuarios finales, teniendo en cuenta los requisitos plasmados en las bases de conocimiento.. Consultar Reportes. Escenario donde los directivos visualizan el resultado en el sistema de información basado en la (BC).. 2.2 Métodos de diseño de un almacén de datos En (Kimball, 1996), se representan varios casos de estudio significativos de data marts (almacenes de datos departamentales) a los que se le aplica el esquema estrella y sus variantes de copo de nieve y constelación de hechos para realizar el modelado multidimensional. Además, propone lo que denomina una matriz de BUS para integrar el diseño de varios data marts y conseguir así un almacén de datos corporativo y global. 35.

(41) Capítulo 2: “Modelo de procesos y actividades del DW”.. En (R. Kimball, 1998), se presenta el ciclo de vida de un proyecto de almacén de datos, para el cual los autores proponen distintas herramientas y técnicas a seguir, sin que se proponga un método o modelo global y formal a lo largo de todo el proceso. En (Rizzi, 1998), los autores proponen el Dimensional-Fact Model (DFM) como una notación propia para realizar el modelado conceptual de los almacenes de datos. Además proponen un marco metodológico para definir un esquema conceptual a partir de los esquemas EntidadRelación (ER) que representan las fuentes de datos operacionales. En (Torlone, 1998), los autores presentan el Multidimensional Model (MD), un modelo lógico para realizar el diseño de un almacén de datos y un método para construirlo a partir de los esquemas ER de las fuentes de datos operacionales. En (Kortink, 2000) se propone de nuevo cómo construir el esquema estrella (y sus diferentes variantes) a partir de los esquemas conceptuales de las fuentes de datos operacionales de que disponga la empresa. Una vez más, presupone que las fuentes de datos están definidas mediante esquemas ER. Se diferencia de otras propuestas en que no propone su propia notación gráfica para el diseño conceptual del almacén de datos, sino que emplea ER. Cabe destacar el trabajo (J.M. Cavero, 2001), donde se propone otro método para el diseño de almacenes de datos. Este método está basado en el modelo MD y propone una serie de procesos que cubren el diseño conceptual, lógico y físico de un almacén de datos. Una de las principales ventajas con respecto a las propuestas anteriores es el hecho de que para extraer el esquema conceptual se tenga en cuenta, además de las fuentes de datos operacionales, los requisitos de usuario. En esta tesis, se trabaja con un método de diseño global (Sergio Lujan-Mora, 2000) orientado a objetos que integra todas las fases de diseño de los almacenes de datos desde las fuentes de datos operacionales hasta la implementación, incluyendo la definición de los procesos de ETL y los requisitos de usuario. El objetivo es combinar, en un conjunto de modelos relacionados, todo el análisis y diseño de los almacenes de datos y se compone de cinco fases y tres niveles. Al contrario que otros métodos y propuestas para el modelado multidimensional y el diseño de 36.