UNIVERSIDAD DEL AZUAY FACTULAD DE CIENCIAS DE LA ADMINISTRACION ESCUELA DE INGENIERIA DE SISTEMAS

Transcripción

1 UNIVERSIDAD DEL AZUAY FACTULAD DE CIENCIAS DE LA ADMINISTRACION ESCUELA DE INGENIERIA DE SISTEMAS CREACION DE UN DATA WAREHOUSE PARA LA EMPRESA FIBRO ACERO S.A. TESIS PREVIA A LA OBTENCION DEL TITULO DE INGENIEROS DE SISTEMAS AUTORES: VALERY MAGALY RODAS ORELLANA CARLOS SEBASTIAN CALLE CEVALLOS DIRECTOR: ING. OSWALDO MERCHAN CUENCA ECUADOR 2008

2 AUTORIA Los autores son los únicos responsables de los conceptos, conclusiones y observaciones emitidas en la presente Tesis. Válery M. Rodas O. Carlos S. Calle C.

3 AGRADECIMIENTO Esta tesis es una muestra de la culminación de un gran paso en mi carrera, es por esto que quiero agradecer a muchas personas que por su amistad y apoyo me han ayudado de una u otra manera a terminarla. A mis padres, Rodrigo y Elva, por todo el esfuerzo y confianza depositados en mí, que además de haberme dado la mejor educación profesional, me han dado el mejor crecimiento como ser humano. A mis hermanas Jéssica y Leydy, y a mis amigos por toda la amistad y ánimos brindados. Al Ing. Oswaldo Merchán quien fue una guía y apoyo fundamental para la realización de este proyecto. Al Ing. Geovany Vintimilla y al Ing. Demetrio Toledo, que a más de ser grandes amigos nos dieron su mano incondicionalmente en todo momento. A la empresa Fibro Acero S.A. por confiar en nuestro proyecto y facilitarnos todo lo necesario para culminar esta tesis. A mi compañero de tesis Carlos Calle, quien puso todo su esfuerzo y conocimientos y fue una gran compañía tanto profesional como personal para realizar este importante proyecto. Y por sobre todo a Dios, quien me ha dado el impulso necesario día a día para salir adelante en todo lo que me proponga. Válery M. Rodas O.

4 AGRADECIMIENTO Para la elaboración de esta tesis se necesitó de la ayuda de muchas personas a las cuales quisiera agradecer: A Dios por darme salud y vida durante el desarrollo de este proyecto de tesis. A mis padres: Iván y Marina, mis hermanos: Fernando Y Gina, a mi cuñada: Fabiola y a mi sobrino Nicolás, les agradezco por estar siempre a mi lado, brindarme su apoyo incondicional, alegrar mi vida y confiar siempre en mí. A mi director de tesis: Ing. Oswlado Merchán, gracias por aportar sus conocimientos y guiarme de manera correcta durante el desarrollo de esta tesis. A mi compañera de tesis: Ing. Válery Rodas, persona muy importante en mi vida. Gracias por ser quien me daba ánimos de seguir adelante en mis momentos de cansancio y debilidad, de aportar con grandes ideas y soluciones durante el desarrollo de esta tesis y por siempre confiar en mí. Gracias por todo, ya que sin ti esta tesis no hubiera podido ser realizada. A los Ing.: Demetrio Toledo y Geovanny Vintimilla, participes del desarrollo de esta tesis, les agradezco por compartir sus conocimientos no solo sobre este tema, sino en diferentes ámbitos los cuales nos permitieron realizar de una mejor manera este proyecto. Y por último pero no el menos importante, un agradecimiento especial a la empresa Fibro Acero S.A., dirigida por el Eco. Marcelo Cordero. Gracias por abrirme las puertas de su empresa y facilitarme la documentación y recursos necesarios para la finalización de esta tesis. Carlos S. Calle C.

5 Dedicatoria Esta tesis la dedico a mis padres que gracias a su ejemplo y dedicación e logrado ir cumpliendo mis metas, siempre tomando en cuenta los valores que me han enseñado como la sencillez y humildad, a Dios por ser el pilar fundamental en mi vida, a mis hermanas y a mi compañero de tesis por todo el apoyo y confianza brindados. Válery M. Rodas O.

6 Dedicatoria Esta tesis la dedico a Dios por darme la vida durante del desarrollo de este proyecto, a mi familia por darme el soporte económico y moral durante el transcurso de mis estudios y siempre confiar en mi; y a mi compañera de tesis por ser parte fundamental no solamente en el desarrollo de esta tesis, si no a lo largo de mi formación profesional. Gracias a todos. Carlos S. Calle C.

7 RESUMEN Un Data Warehouse es un almacén de datos que permite obtener información confiable y valiosa para la toma de decisiones, es por esto que cada día más empresas tienen la necesidad de implementarlo debido a la globalización y competencia existente en el mercado. Siendo Fibro Acero S.A. una empresa que se encuentra en el mercado por mas de quince años como fabricante y comercializador de cocinas, cocinetas y cilindros de gas, es de gran utilidad implementar esta herramienta para facilitar la toma de decisiones y así permitir a los gerentes mejorar sus estrategias. Para desarrollar el Data Warehouse utilizaremos la herramienta case Genexus en la creación y administración, Gxplorer el cual es un complemento OLAP de Microsoft Excel permitirá a los usuarios explotar la información, y SQL Server 2000 como base de datos.

8

9 INDICE DE CONTENIDOS Resumen.i Abstract..ii 1. INTRODUCCION ASPECTOS TEORICOS Introducción Sistemas de información Tipos de sistemas Data Warehouse Características Estructura de un data warehouse Arquitectura de un data warehouse Usos, ventajas y desventajas de un data warehouse Ejemplos de un data warehouse Modelo de datos Modelo relacional Modelo Multidimensional Conclusiones HERRAMIENTAS PARA LA CONSTRUCCIÓN, ADMINISTRACIÓN Y MANIPULACIÓN DE UN DATA WAREHOUSE Introducción Herramientas para la transformación del Data Warehouse GeneXus y el Data Warehouse Herramientas para la administración del data warehouse Clasificación y características Microsoft SQL Server 2000 y el Data Warehouse Herramientas para manipular la información del data warehouse Clasificación y características Conclusiones: METODOLOGIA DE DESARROLLO PARA LA CONSTRUCCION E IMPLEMENTACION DEL DATA WAREHOUSE Introducción Fases para la construcción del Data Warehouse Recogida y Análisis de Requisitos...46

10 Diseño Conceptual Diseño Lógico Específico Diseño Lógico General Implementación Conclusiones PRUEBAS SOBRE UN DATA WAREHOUSE Introducción Tipos de pruebas y características Prueba de Integración Prueba de Caja Negra Prueba de Caja Blanca Prueba de Aceptación Prueba de Rendimiento Prueba de Robustez Prueba de Resistencia Prueba de Transformación Ventajas y desventajas Conclusión CONCLUSIONES BIBLIOGRAFIA ANEXOS..115

11 INDICE DE FIGURAS Figura No. 2.1: Procesos de un Sistema de Información...8 Figura No. 2.2: Niveles de la Organización...8 Figura No. 2.3: Data Warehouse Integrado Figura No. 2.4: Data Warehouse Orientado a Temas Figura No. 2.5: Data Warehouse no Volátil Figura No. 2.6: Estructura de un Data Warehouse Figura No. 2.7: Arquitectura real del Data Warehouse Figura No. 2.8: Concurrencia en el Data Warehouse Figura No. 2.9: Enfoque anticuado de procesamiento de la Información Figura No. 2.10: Esquema Estrella Figura No. 2.11: Esquema Copo de Nieve Figura No. 2.12: Constelación de hechos Figura No. 2.13: Ejemplo de un Cubo de tres dimensiones Figura No. 2.14: Slice & Dice Figura No. 2.15: Rotación Figura No. 2.16: Drill Up y Drill - Down Figura No. 2.17: Roll - Up Figura No. 2.18: Drill - Across Figura No. 2.19: Drill - Through Figura No. 3.1: Etapas del Data Warehouse - Transformación Figura No. 4.1: Fases para la construcción de un DWH Figura No. 4.2: Diagrama Entidad Relación del Sistema EcoSAC Figura No. 4.3: Diagr. Entidad Relación de la base de datos Ventas Figura No. 4.4: Notación Gráfica en CMDM del nivel Empleado Figura No. 4.5: Notación Gráfica en CMDM de la Dimensión Empleado Figura No. 4.6: Notación Gráfica en CMDM de la Relación Dimensional Faltas y Permisos Figura No. 4.7: Representación Gráfica Dimensión Fecha Figura No. 4.8: Representación Gráfica Dimensión Sucursal Figura No. 4.9: Representación Gráfica Dimensión Cliente Figura No. 4.10: Representación Gráfica Dimensión Producto Figura No. 4.11: Representación Gráfica Dimensión Documentos Figura No. 4.12: Representación Gráfica Dimensión Total Ventas Figura No. 4.13: Representación Gráfica Relación Dimensional Ventas Figura No. 4.14: Representación Gráfica Dimensión Tiempo Figura No. 4.15: Representación Gráfica Dimensión Clasificación... 57

12 Figura No. 4.16: Representación Gráfica Dimensión Proveedor Figura No. 4.17: Representación Gráfica Dimensión Tipo Calificación Figura No. 4.18: Representación Gráfica Dimensión Tipo Calificación Figura No. 4.19: Representación Gráfica de la Relación Dimensional Calificación Proveedor Figura No. 4.20: Representación Gráfica Dimensión Fecha Figura No. 4.21: Representación Gráfica Dimensión Motivo Figura No. 4.22: Representación Gráfica Dimensión Empleado Figura No. 4.23: Representación Gráfica Dimensión Estado Figura No. 4.24: Representación Gráfica Dimensión Permisos Figura No. 4.25: Representación Gráfica Relación Dimensional Faltas y Permisos. 60 Figura No. 4.26: Representación Gráfica Dimensión Fecha Figura No. 4.27: Representación Gráfica Dimensión Empleado Figura No. 4.28: Representación Gráfica Dimensión Remuneración Figura No. 4.29: Representación Gráfica Relación Dimensional Remuneraciones 62 Figura No. 4.30: Materialización de la Relación Ventas, Cubo Figura No. 4.31: Materialización de la Relación Calificación Proveedor, Cubo Figura No. 4.32: Materialización de la Relación Faltas y Permisos, Cubo Figura No. 4.33: Materialización de la Relación Remuneraciones, Cubo Figura No. 4.34: Fragmentación Vertical de Dimensiones Req. Dep. Ventas Figura No. 4.35: Fragmentación Vertical de Dimensiones Req. Dep. Logística Figura No. 4.36: Fragmentación Vertical de Dimensiones Req. Faltas y Permisos 69 Figura No. 4.37: Fragmentación Vertical de Dimensiones Req. Remuneraciones 70 Figura No. 4.38: Mapeo de la Dimensión Empleado. Dep. Talento Humano Figura No. 4.39: Mapeo de la Dimensión Producto. Dep. Ventas Figura No. 4.40: Mapeo de Cubos Faltas y Permisos. Dep. Talento Humano Figura No. 4.41: Mapeo de Cubos Remuneraciones. Dep. Talento Humano Figura No. 4.42: Mapeo de Cubos Ventas. Dep. Ventas Figura No. 4.43: Mapeo de Cubos Logística. Dep. Logística Figura No. 4.44: Esquema Lógico del DWH de Talento Humano Figura No. 4.45: Modelo Multidimensional en Estrella, Tabla de hecho Permisos Figura No. 4.46: Modelo Multidimensional en Estrella, Tabla de hecho Remuneraciones Figura No. 4.47: Esquema Lógico del DWH del departamento de Ventas Figura No. 4.48: Esquema Lógico del DWH del departamento de Logística Figura No. 4.49: Elección del objeto Dimensión o Medida Figura No. 4.50: Estructura de la Dimensión Departamentos Figura No. 4.51: Estructura de la Medida Permisos... 81

13 Figura No. 4.52: Objeto transacción para el Data View y tabla externa Figura No. 4.53: Creación y estructura de un Data View Figura No. 4.54: Creación y especificación de un Data Store Figura No. 4.55: Algoritmo para la importación de información desde un archivo de Excel Figura No. 4.56: Menú principal de la aplicación del DWH Figura No. 4.57: Pantalla para el ingreso de las fechas de carga al DWH Figura No. 4.58: Información del DWH Figura No. 4.59: Creación del Metadata Figura No. 4.60: Asignación de Nombre y Ubicación del Metadata Figura No. 4.61: Menú de carga del Metadata Figura No. 4.62: Elección del paradigma Figura No. 4.63: Elección de la ubicación de la base de conocimiento Figura No. 4.64: Elección de modelo de la base de conocimiento Genexus Figura No. 4.65: Creación y asignación del ODBC para el Metadata Figura No. 4.66: Visualización de la Metadata con sus dimensiones y medidas cargadas Figura No. 4.67: Ingreso al modulo Gxplorer Settings Figura No. 4.68: Creación de un nuevo usuario Figura No. 4.69: Ubicación de la barra de Gxplorer Olap para MSExcel Figura No. 4.70: Nueva Consulta Gxplorer Figura No. 4.71: Selección de las dimensiones y medidas a consultar Figura No. 4.72: Resultado consulta con Gxplorer Olap para MSExcel Figura No. 4.73: Grafico explicativo de los resultados de la consulta DWH Figura No. 4.74: Materialización de la Relación Ventas, Cubo Figura No. 4.75: Materialización de la Relación Ventas, Cubo Figura No. 4.76: Materialización de la Relación Calificación Proveedor, Cubo Figura No. 4.77: Materialización de la Relación Faltas y Permisos,Cubo Figura No. 4.78: Materialización de la Relación Faltas y Permisos,Cubo Figura No. 4.79: Mapeo de la Dimensión Motivo. Dep. Talento Humano Figura No. 4.80: Mapeo de la Dimensión Estado. Dep. Talento Humano Figura No. 4.81: Mapeo de la Dimensión Fecha. Dep. Talento Humano Figura No. 4.82: Mapeo de la Dimensión Fecha. Dep. Ventas Figura No. 4.83: Mapeo de la Dimensión Cliente. Dep. Ventas Figura No. 4.84: Mapeo de la Dimensión Sucursal. Dep. Ventas Figura No. 4.85: Mapeo de la Dimensión Documentos. Dep. Ventas Figura No. 4.86: Drill-up del Cubo Faltas1. Dep. Talento Humano Figura No. 4.87: Drill-up del Cubo Faltas2. Dep. Talento Humano

14 Figura No. 4.88: Drill-up del Cubo Faltas2. Dep. Talento Humano Figura No. 4.89: Drill-up del Cubo Ventas1. Dep. Ventas Figura No. 4.90: Drill-up del Cubo Ventas2. Dep. Ventas Figura No. 4.91: Drill-up del Cubo Ventas3. Dep. Ventas Figura No. 4.92: Drill-up del Cubo Calificación Proveedor Figura No. 4.93: Drill-up del Cubo Calificación Proveedor

15 CAPITULO 1 INTRODUCCION

16 1. INTRODUCCION En un mundo cada vez más competitivo en donde las empresas sienten la necesidad de crear estrategias que les permita mantenerse y sobresalir en el mercado, es de vital importancia contar con información precisa para tal fin. Hoy en día las empresas cuentan con sistemas transaccionales que almacenan las actividades diarias del negocio, pero no permiten obtener de manera rápida, resumida y objetiva la información que se necesita. Es por esto que surge un nuevo concepto para almacenar y analizar la información llamado Data Warehouse, que de ahora en adelante nos referiremos como DWH, el mismo que consolida los datos provenientes de diferentes bases de datos operacionales y los hace disponibles para la realización de análisis de tipo gerencial. La información que almacenan los sistemas operacionales podría darnos los informes requeridos, pero para hacerlo se necesitaría que los usuarios sean expertos en lenguajes de consulta como SQL, además, al consultar grandes cantidades de datos el rendimiento del sistema puede verse perjudicado; es por esto que al momento de crear nuestro data warehouse se debe integrar toda la información relevante para apoyar en la toma de decisiones de una manera eficiente. Para lograrlo es preciso realizar un análisis de lo que se desea construir, en este proyecto nos enfocamos en un análisis multidimensional, que en base a los requerimientos de los usuarios se identifican las dimensiones, medidas y hechos para representar la realidad, además de esto se requiere un modelo a seguir, pero al no existir todavía una metodología para la construcción de un DWH, en este trabajo se expondrá una metodología transaccional pero con variantes únicas asociada al data warehouse. A lo largo de esta tesis podremos observar como se crea un data warehouse que cumpla con las necesidades de tres departamentos de Fibro Acero S.A.: ventas, logística y talento humano. 3

17 Para la construcción hemos utilizando la herramienta Genexus, con la cual, extraeremos la información por medio de objetos Data Views, construiremos el DWH ya que esta herramienta permite generar la estructura dimensional creando las medidas y dimensiones, y cargaremos la información al DWH con aplicaciones desarrolladas para tal fin. Como almacén de datos utilizaremos SQL Server 2000 y para explorar la información resultante de nuestro DWH utilizaremos Gxplorer Olap que lo encontraremos como complemento de Microsoft Excel lo cual es muy familiar para los usuarios. En el capitulo 2 revisaremos de forma global lo que es un data warehouse, analizaremos su arquitectura y características, además nos adentraremos en los fundamentos del modelo multidimensional. En el capitulo 3 analizaremos Genexus, Gxplorer, SQL Server 2000 además de otras herramientas existentes para desarrollar y explotar un DWH. En el capitulo 4 desarrollaremos el DWH para la empresa Fibro Acero S. A., expandiendo la metodología que utilizamos y exponiendo como se utilizaron las herramientas en cada etapa del proceso. En el capitulo 5 exponemos ciertas pruebas que pueden realizarse durante la implementación del DWH. 4

18 CAPITULO 2 ASPECTOS TEORICOS 5

19 2. ASPECTOS TEORICOS 2.1. Introducción La competencia a nivel empresarial es cada vez mayor, y la necesidad de contar con información valiosa para ayudar a los directivos de la empresa a tomar decisiones de nivel estratégico crece aun más, es por esto que las empresas cuentan con sistemas transaccionales que les permiten procesar y almacenar los datos resultantes de la operación diaria del negocio, pero no les permite obtener información resumida para toma de decisiones, es por esto la importancia de crear un DWH. En este capitulo nos introduciremos en los conceptos y estructura de un DWH, veremos desde información básica sobre los diferentes sistemas hasta adentrarnos mas y poder explicar mejor las características, arquitectura, herramientas front end, y los tipos de modelos de datos. Como la mayor parte de información que conforma un data warehouse, proviene de los sistemas transaccionales, es necesario hacer referencia a la estructura de la organización con respecto a los sistemas de información. 6

20 2.2. Sistemas de información Es un conjunto de elementos que interactúan entre sí, con la finalidad de apoyar a las actividades de una empresa. La tarea principal de los sistemas de información es cumplir 3 objetivos básicos: - Automatización de procesos operativos. - Proporcionar información para ayudar en la toma de decisiones. - Lograr ventajas competitivas gracias a su implementación y uso. Estos sistemas realizan cuatro procedimientos, como se muestra en la figura 2.1, conocidos como: Entrada, Almacenamiento, Procesamiento y Salida de información. - Entrada de información: es el proceso por el cual el sistema obtiene la información necesaria para su funcionamiento. Estas entradas pueden ser manuales, como teclados, scanners, etc., o automáticas, provenientes de sistemas externos o módulos. - Almacenamiento de información: esta actividad es la más importante, ya que permite guardar los datos e información en discos duros, CD, etc., para luego ser reutilizada según las necesidades de la empresa. - Procesamiento de información: es la capacidad de transformar los datos en información, basándose en cálculos o tareas preestablecidas, y así lograr conocer el estado de la empresa y en ciertos casos sirve de apoyo en la toma de decisiones. - Salida de información: permite extraer la información procesada al exterior. La manera más común es a través de impresoras, discos extraíbles, etc. En algunos casos pueden ser entradas de información para otros sistemas. 7

21 Figura No. 2.1: Procesos de un Sistema de Información Tipos de sistemas Existen cuatro tipos de sistemas, y se dividen de acuerdo al siguiente esquema: 1 Figura No. 2.2: Niveles de la Organización Sistemas estratégicos: Su objetivo es brindar el apoyo necesario para la toma de decisiones dentro de las empresas, mediante información filtrada y relevante. Su característica principal es la carga periódica de trabajo, es decir que su utilización no es predecible. Dentro de esta categoría tenemos los Sistemas de Información Gerencial (MIS), Sistemas de Información Ejecutivos (EIS), Sistemas de Información Georeferencial (GIS), Sistemas de Simulación de Negocios (BIS y que en la práctica son sistemas expertos o de Inteligencia Artificial - AI). 1 Instituto Nacional de Estadística e Informática, Manual para la construcción de un Data Warehouse. [consulta 20 de noviembre de 2006] 8

22 Sistemas tácticos: Estos sistemas están diseñados para coordinar y manejar la documentación de una empresa. Su objetivo es facilitar consultas de la información almacenada en el sistema y la generación de informes. Entre los sistemas mas conocidos se encuentran los Sistemas de Transmisión de Mensajería (correo electrónico y servidor de fax), Control y coordinación de tareas (Work Flow), Sistemas Ofimáticos (OA), y tratamiento de documentos (Imagen, Trámite y Bases de Datos Documentarios). Sistemas técnico-operativos: Son los sistemas tradicionales, utilizados para el ingreso masivo de información al sistema (contabilidad, facturación, control de personal, etc.). En la actualidad este tipo de sistemas tratan de mejorar su funcionalidad mediante censores, bases de datos relacionales, data warehousing, etc. Sistemas interinstitucionales: Es un nuevo tipo de sistema que está en constante crecimiento, y tiene como objetivo, crear una conexión entre organizaciones y el mercado mundial, por medio de redes informáticas de alcance nacional y global (Internet), sin importar donde se encuentren las organizaciones (intranet) ni en que mercado se encuentren (extranet) Data Warehouse El Data Warehouse surge por dos razones: primero, la necesidad de proporcionar una fuente única de datos limpia y consistente para propósitos de apoyo para la toma de decisiones, y segundo, la necesidad de hacerlo sin afectar a los sistemas operacionales. Es por esto que se ha desarrollado una arquitectura sólida que permite procesar la información y poner su uso estratégico como generador de ventajas competitivas. Esta arquitectura es el Data Warehouse (en lo adelante nos referiremos como DWH) que nace a inicio de los 90. Para entender mejor su concepto, daremos la definición clásica de Bill Inmon, reconocido como el padre del DWH. 9

23 Un Data Warehouse es una colección de datos orientados a un tema, integrados, no volátiles, e historiados, organizados para dar soporte al proceso de ayuda a la toma de decisiones 2 Con esta definición simple y concreta se clarifica el concepto de un DWH, y si la profundizamos, podríamos decir que algunos de sus objetivos son: - Comprender las necesidades de los usuarios por áreas dentro del negocio. - Determinar qué decisiones se pueden tomar con la ayuda del DWH - Seleccionar un subconjunto del sistema de fuentes de datos que sea el más efectivo y procesable para presentar el DWH. - Asegurar que los datos sean precisos, correctos y confiables, y que mantengan la consistencia. - Monitorear continuamente la precisión y exactitud de los datos y el contenido de los reportes generados. - Publicar los datos Características Siguiendo con la definición de Inmon, un DWH se caracteriza por ser: Integrado Un DWH recoge los datos de diferentes sistemas operacionales de la organización y/o fuentes externas, como se muestra en la Figura No. 2.3, por lo tanto el aspecto más importante del ambiente data warehousing es que la información encontrada en su interior este siempre integrada, para que al utilizarla, los usuarios se enfoquen en usar los datos y no preguntarse sobre la confiabilidad o consistencia de los mismos. 2 Inmon, W.H. Building the Data Warehouse. Tercera Edición, Jhon Wiley & Sons, [consulta 26 de octubre de 2006] 10

24 Figura No. 2.3: Data Warehouse Integrado Cuando los datos se mueven de los sistemas operacionales al DWH, experimentan una transformación fundamental antes de entrar al depósito, y ésta integración se muestra de muchas maneras como: nomenclatura, medidas para las variables, formas de codificar, entre otros Orientado a temas El DWH excluye la información que no será utilizada por el proceso de sistemas de soporte de decisiones, y la clasifica en base a los aspectos que son de interés para la empresa. Por ejemplo, consolidar toda la información de los vendedores en una sola tabla para que los usuarios puedan acceder más fácilmente. Figura No. 2.4: Data Warehouse Orientado a Temas De tiempo variante La información del DWH es requerida en cualquier momento, a diferencia de los sistemas operacionales, que se la necesita al momento de acceder a ellos. Por esta característica, los datos encontrados en el depósito se llaman 11

25 de tiempo variante. Este tiempo variante se muestra de algunas maneras como: - El horizonte largo de tiempo, de 5 a 10 años. - Cada estructura clave del DWH contiene un elemento de tiempo como día, semana, mes, etc. - Una vez almacenada la información en el DWH no puede ser actualizada No volátil Para realizar la toma y análisis de decisiones, es necesaria una base de datos estable, y eso es lo que nos brinda un DWH, en este solo se realizan dos operaciones fundamentales, la carga inicial de los datos y el acceso a los mismos, a diferencia del ambiente operacional donde existe el ingreso, modificación y eliminación como se muestra en la figura No Figura No. 2.5: Data Warehouse no Volátil Estructura de un data warehouse La estructura que conforma un DWH es diferente a la de una base de datos normal, como observamos en la figura 2.6, en el DWH encontramos niveles y cada una de ellos tiene un diferente grado de detalle, esto nos permite conocer los límites que posee el almacén de datos. Los niveles anteriormente mencionados son los siguientes: 3 3 Instituto Nacional de Estadística e Informática, Manual para la construcción de un Data Warehouse. [consulta 10 de diciembre de 2007] 12

26 Detalle de datos actuales. Detalle de datos antiguos. Datos ligeramente resumidos. Datos completamente resumidos. Meta data Figura No. 2.6: Estructura de un Data Warehouse 3 Detalle de datos actuales: En este nivel se encuentra almacenada la información más detallada de un DWH, que es obtenida desde las bases de datos operacionales y es considerada las más importante debido a que: Contiene la información más reciente y ésta es de gran interés. Mantiene su información con un gran detalle. Es de fácil acceso y su almacenamiento se lo hace en disco. Detalle de datos antiguo: Como su nombre lo dice, en este nivel se almacena la información histórica del DWH y se lo hace de manera detallada, consistente con el detalle de los datos actuales. Su acceso no es frecuente y el método de almacenamiento depende de la cantidad de información que se tenga, esta puede ser almacenada en discos locales, discos alternos, etc. 13

27 Datos ligeramente resumidos: Comúnmente este nivel es almacenado en disco y su información proviene de los datos actuales. El grado de resumen que este presenta, depende del diseño establecido y se basa en dos factores: la unidad de tiempo con la cual está estructurado y el contenido o atributos que se tiene. Datos completamente resumidos: Este nivel contiene información que es compacta y de fácil acceso, la cual es adquirida del nivel de datos ligeramente resumidos. Estos dos últimos niveles son los más accedidos por los usuarios, ya que contienen la información relevante de la empresa y la más adecuada para el soporte en la toma de decisiones. Meta data: Es el componente final de un DWH, el cual se encuentra en una dimensión diferente, por que su información es diferente a la almacenada en otros niveles y no son tomados de los sistemas operacionales. Aquí se encuentra: Un directorio para ayudar al analista a ubicar los contenidos del DWH. Una guía que indica la manera en la que los datos se transforman desde los sistemas operacionales al DWH. Indica las operaciones que se realizan para transformar, la información del detalle actual de datos, a los datos ligeramente resumidos y estos a su vez, a los datos completamente resumidos Arquitectura de un data warehouse La tecnología Data Warehouse representa de mejor manera la amplia estructura de una empresa, por lo tanto, para saber cómo se relacionan todos los componentes involucrados en el DWH, es necesario analizar su arquitectura, la misma que establece el marco de trabajo, estándares y procedimientos a un nivel empresarial. Los objetivos de las actividades de la arquitectura son simples, integrar al DW las necesidades de información empresarial. 14

28 Elementos que constituyen la arquitectura de un data warehouse Figura No. 2.7: Arquitectura real del Data Warehouse Fuentes de extracción de datos Estas fuentes, tales como los sistemas OLTP, fuentes externas de datos, etc., son las que proveen toda la información que será almacenada en el DWH, sin antes haberla transformado e integrado. OLTP (On-Line Transaction Processing) son aplicaciones que definen el comportamiento habitual de un entorno operacional de gestión, y ejecutan las operaciones del día a día Sistemas dorsales (back-end) Son herramientas que se encargan de la extracción, limpieza, transformación, integración, carga y refresco de los datos de las fuentes externas. Dentro de la clasificación de sistemas dorsales, podemos mencionar los sistemas ETL y el mismo DWH, que se describen a continuación. Sistemas ETL (Extraction, Transformation, Load): Realizan funciones como: - Extracción de los datos desde las distintas fuentes de datos. - Transformación o filtrado de los datos: limpieza, consolidación, etc. 4 Sepúlveda Castro, Jorge. Urrutia Suárez, Luis. Diseño e Implementación de un Data Warehouse para la gestión de ventas de la empresa vitivinícola Miguel Torres Chile. Diciembre, [consulta 12 de marzo de 2007] 15

29 - Carga inicial del Data Warehouse: ordenación, agregaciones, etc. - Refresco del Data Warehouse: es una operación periódica que propaga los cambios de las fuentes externas al Data Warehouse. Data Warehouse: Posee información relevante de los datos o metadatos, estos metadatos, contienen información relativa a los datos y comúnmente, permiten mantener información sobre: - La procedencia y frecuencia de refresco de los datos - La fiabilidad y forma de cálculo de los datos - Semántica de los datos y su localización en el DW, etc Sistemas frontales (front-end) Los sistemas frontales o herramientas front-end, ofrecen al usuario final mecanismos de acceso a la información simples y potentes, permitiendo obtener una correcta y eficaz conexión con el DWH. Con estos sistemas se pueden realizar consultas, informes, análisis y extracción del conocimiento (data mining). Dentro de esta clasificación podemos mencionar las Interfaces y Gestores de Consultas, y los Sistemas de Integridad y Seguridad. Las Interfaces y Gestores de Consulta permiten acceder a los datos y sobre ellos conectar herramientas más sofisticadas como OLAP (Online Analytical Processing, que lo revisaremos mas adelante), EIS, minería de datos (data mining) Data Marts A partir del depósito de datos integrado del DWH, se pueden crear los data marts. En síntesis, los data marts son repositorios de datos o pequeños DWH centrados en un tema o un área de negocio específico. En muchos casos, los Data Warehouse comienzan siendo Data Marts con el objetivo de minimizar los riesgos para luego ir ampliando su espectro gradualmente Tipos de Arquitectura - Arquitectura real: (Figura No. 2.7) Es la más usada en los sistemas de soporte de decisión. La información es obtenida de extracciones 16

30 periódicas al sistema de producción y fuentes externas, se la integra, limpia y transforma para realizar la carga o almacenamiento en el DWH, que se lo hace en un SGBD (Sistema Gestor de Base de Datos) separado del sistema de producción de la empresa. Mediante esta arquitectura, obtenemos datos que se ajustan a las necesidades del proceso de toma de decisiones. - Arquitectura virtual: En esta arquitectura, la información del DWH es almacenada en el sistema tradicional, por lo que no existe un coste de almacenamiento suplementario, y el acceso a los datos se lo hace en tiempo real por medio de middlewares o pasarelas. Pero las desventajas que esta arquitectura presenta lo hacen poco utilizable, por ejemplo, los datos no son preparados y los accesos de decisión pueden entorpecer el funcionamiento y rendimiento del sistema de la empresa. - Arquitectura remota: Es una combinación de las dos arquitecturas antes descritas. Trata de implementar físicamente los niveles agregados (los niveles de datos más utilizados) para conservar el nivel de detalle en los sistemas de producción, y facilitar el acceso que se lo hace a través de middleware o gateways Usos, ventajas y desventajas de un data warehouse El acceso a un DWH o a una base de datos tradicional, depende del usuario y la información que necesite obtener. Un DWH esta orientado hacia las personas que necesitan hacer consultas complejas, de múltiples fuentes, que su respuesta no sea inmediata y en algunos casos que contenga información histórica. En una empresa, los usuarios que utilizan las bases de datos operacionales necesitan que la información consultada tenga una respuesta inmediata y normalmente son consultas predefinidas, las cuales en muchos de los casos acceden a una sola base de datos para satisfacer la petición. Por el contrario, un DWH permite realizar cualquier tipo de consulta, según la 17

31 información que se necesite (detallada, ligeramente resumida o completamente resumida). Un DWH tiene una característica notable, que es la concurrencia. Los recursos que se necesitan para poder realizar las consultas son altos, y mientras más usuarios accedan al DWH más recursos serán necesarios. Como muestra la figura 2.8, se debe distribuir de manera adecuada el acceso a los diferentes niveles del DWH, puesto que mientras más alto sea el nivel de acceso menos recursos se deberán utilizar, y la concurrencia podrá ser mayor. Figura No. 2.8: Concurrencia en el Data Warehouse A continuación se describen algunas ventajas y desventajas que tiene un DWH. 5 Ventajas: Gran poder de procesamiento de la información. Permite mayor flexibilidad y rapidez en el acceso de la información. 5 Asesoría, Diseño y Desarrollo de Aplicaciones [consulta 23 de noviembre de 2006] 18

32 Facilita la toma de decisiones en los negocios. Las empresas obtienen un aumento en la productividad. Proporciona una comunicación fiable entre los departamentos de la empresa. Permite conocer lo que sucede en la empresa. Transforma los datos en información y la información en conocimiento. Reduce los tiempos de respuesta y los costes de operación. Desventajas: Requiere una revisión del modelo de datos, objetos, transacciones y además del almacenamiento. Tiene un diseño complejo y multidisciplinar. Requiere una reestructuración de los sistemas operacionales. Tiene un alto coste Ejemplos de un data warehouse Ejemplo 1: Preparación de un reporte complejo. El informe incluye las finanzas actuales, el inventario y la condición de personal, acompañado de comparaciones del mes actual con el anterior y el mismo mes del año anterior, con una comparación adicional de los 3 años precedentes. Se debe explicar cada desviación de la tendencia que cae fuera de un rango predefinido. Sin un data warehouse, el informe es preparado de la siguiente manera: La información financiera actual se obtiene desde una base de datos mediante un programa de extracción de datos, el inventario actual de otro programa de extracción de otra base de datos, la condición actual de personal de un tercer programa de extracción y la información histórica desde un backup de cinta magnética o CD-ROM. Lo más interesante es que se ha pedido otro informe que continúe al primer informe (debido a que las preguntas se originaron a partir del anterior). El hecho es, que ninguno de los trabajos realizados hasta aquí (por ejemplo, 19

33 diversos programas de extracción) se pueden usar para los próximos o para cualquier reporte subsiguiente. Imagine el tiempo y el esfuerzo que se ha desperdiciado por un enfoque anticuado. (Ver Figura 2.9). Las inconsistencias deben identificarse en cada conjunto de datos extraídos y resolverse, por lo general, manualmente. Cuando se completa todo este procesamiento, el reporte puede ser formateado, impreso, revisado y transmitido. Nuevamente, el punto importante aquí es que todo el trabajo desempeñado para hacer este informe no afecta a otros reportes que pueden solicitarse es decir, todos ellos son independientes y caros, desde el punto de vista de recursos y productividad. Ventas Proveedor Producto Histórico Extraer Datos Extraer Datos Extraer Datos Extraer Datos Combinar datos e identificar inconsistencias Desviación Resolver inconsistencias y explicar las desviaciones Procesamiento Manual Formatear, imprimir y transmitir reportes Figura No. 2.9: Enfoque anticuado de procesamiento de la Información 20

34 Al crear una data warehouse y combinar todos los datos requeridos, se obtienen los siguientes beneficios: Las inconsistencias de los datos se resuelven automáticamente cuando los elementos de datos se cargan en el data warehouse, no manualmente, cada vez que se prepara un reporte. Los errores que ocurrieron durante el proceso complejo de la preparación del informe, se minimizan porque el proceso es ahora mucho más simple. Los elementos de datos son fácilmente accesibles para otros usos, no sólo para un reporte particular. Se crea una sola fuente. Ejemplo 2: Transporte de Cargas y Pasajeros Se utilizan DWH para almacenar y acceder a meses o años de datos de clientes y sistemas de reservas para realizar actividades de marketing, planeamiento de capacidad, monitoreo de ganancias, proyecciones y análisis de ventas y costos, programas de calidad y servicio a clientes. Las empresas de transporte de cargas llevan datos históricos de años, de millones de cargamentos, capacidades, tiempos de entrega, costos, ventas, márgenes, equipamiento, etc. Las aerolíneas utilizan sus DWH para sus programas de viajeros frecuentes, para compartir información con los fabricantes de naves, para la administración del transporte de cargas, para compras y administración de inventarios, etc. Hacen un seguimiento de partes de repuesto, cumplimiento con las regulaciones aeronáuticas, desempeño de los proveedores, seguimiento de equipaje, historia de reservas, ventas y devoluciones de tickets, reservas telefónicas, desempeño de las agencias de viajes, estadísticas de vuelo, contratos de mantenimiento, etc. 21

35 Algunas empresas que cuentan con DWH de magnitud: Cornrail, Union Pacific, Norfolk Southern, American President Lines, Delta, Lufthansa, QANTAS, British Airways, American Airlines, Canadian Airlines, SNFC Modelo de datos Modelo relacional Es un modelo de datos basado en la lógica de predicado y en la teoría de conjuntos. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos 6. La estructura fundamental del modelo es precisamente la relación, una tabla bidimensional la cual está constituida por tuplas (registro) y columnas (atributos). Usa el álgebra relacional, y para manipular la información utiliza ocho operaciones: restrict, project, times, union, minus, join, intersect y divide. Restrict: restituye una relación que contiene un subconjunto de las tuplas de la relación a la que se aplica. Los atributos se quedan como estaban. Project: restituye una relación con un subconjunto de los atributos de la relación a la que viene aplicado. Las tuplas de la relación resultado se componen de las tuplas de la relación original, de manera que siguen siendo un conjunto en sentido matemático. Time: se aplica a dos relaciones y efectúa el producto cartesiano de las tuplas. Cada tupla de la primera relación está concatenada con cada tupla de la segunda. Union: aplicando este operador a dos relaciones compatibles, se obtiene una que contiene las tuplas de ambas relaciones. Dos relaciones son compatibles si tienen el mismo número de atributos y los atributos correspondientes en las dos relaciones tienen el mismo dominio. 6 Wikipedia. Modelo Relacional. [consulta 3 de enero de 2007 ] 22

36 Minus: aplicado a dos relaciones compatibles restituye una tercera que contiene las tuplas que se encuentran sólo en la primera relación. Join: se concatenan las tuplas de dos relaciones de acuerdo con el valor de un conjunto de sus atributos. Intersect: aplicado a dos relaciones compatibles restituye una relación que contiene las tuplas que existen en ambas. Divide: aplicado a dos relaciones que tengan atributos comunes, restituye una tercera que contiene todas las tuplas de la primera relación que se puede hacer que correspondan con todos los valores de la segunda relación. Este es el modelo más difundido y es considerado el pilar fundamental de las bases de datos que existen hoy en día en grandes y medianas empresas, el único problema es: Legibilidad limitada: Los usuarios finales no pueden interpretar el modelo entidad relación, por lo que no pueden navegar por este modelo en busca de información. Dificultad de las herramientas para encontrar información: Cuando se maneja una cantidad muy grande de información, las herramientas no siempre pueden realizar una selección correcta de los datos y en algunos casos pueden devolver información errónea Modelo Multidimensional El modelo multidimencional es una técnica que les permite visualizar a los usuarios finales las relaciones que existen en el modelo de una manera mas simple y entendible. Este modelo permite el empleo de cualquier base de datos como MOLAP (matrices multidimensionales), base de datos relacionales, ROLAP (transforma datos multidimensionales en operaciones relacionales en SQL), etc. Los objetivos del modelo son: 7 7 Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 10 de enero de 2007] 23

37 Representación de los datos en forma cercana a la intuición del usuario. Resolver problemas planteados en sistemas relacionales. Un esquema multidimensional esta formado por dos elementos: tablas y esquemas. Las tablas dentro de un modelo multidimensional se dividen en dos tipos: Tabla de hechos: Contienen información obtenida generalmente por una aplicación de una manera estadística, es decir, un conjunto de valores agrupados en un solo valor. Estos son conocidos como atributos de hechos o síntesis. Tabla de dimensiones: Poseen atributos conocidos como atributos de dimensión o clasificación y contienen el detalle de los valores obtenidos en los atributos de hecho o síntesis. Las dimensiones poseen jerarquías, que son varios atributos unidos mediante algún tipo de jerarquía, de aquí nace el concepto de que el modelo multidimensional se puede representar mediante un esquema tipo estrella o copo de nieve. 8 o Esquema estrella: Su nombre se da por la distribución que tiene este tipo de esquema. Tiene una tabla de hecho en el centro y en las puntas están las tablas de dimensiones. Tablas de dimensiones Dim1 Id_Dim Dim3 Id_Dim Hecho Id_Dim1 Id_Dim2 Id_Dim3 Id_Dim4 valor1 valor2 Tabla de Hechos Dim2 Id_Dim Dim4 Id_Dim Figura No. 2.10: Esquema Estrella 8 Sepúlveda Castro, Jorge. Urrutia Suárez, Luis. Diseño e Implementación de un Data Warehouse para la gestión de ventas de la empresa vitivinícola Miguel Torres Chile. Diciembre, [consulta 24 de abril de 2007] 24

38 o Esquema copo de nieve: La diferencia con el esquema estrella radica en que las tablas de dimensiones están normalizadas y cada una de estas tiene un solo nivel. T1 Id_T T2 Id_T Dim1 Id_Dim1 Id_T1 Id_T Dim3 Id_Dim Hecho Id_Dim1 Id_Dim2 Id_Dim3 Id_Dim4 valor1 valor2 Tabla de Hechos Dim2 Id_Dim2 Id_T Dim4 Id_Dim4 Id_T T3 Id_T T4 Id_T Figura No. 2.11: Esquema Copo de Nieve o Constelación de hechos: Son tablas de hecho que comparten varias tablas de dimensiones. Figura No. 2.12: Constelación de hechos Bases de datos multidimensionales: Dentro de las bases de datos multidimensionales la información se representa como una matriz multidimensional conocida como cubo o hipercubo, en cuyos ejes se encuentran las dimensiones o criterios de análisis, y en los cruces las medidas, que representan los indicadores o valores a analizar, tal como lo 25

39 muestra la siguiente figura, en donde las dimensiones año, mes y motivo se cruzan entre si para indicarnos el numero de faltas, que seria nuestra medida a analizar. Enfermedad Cal. Dom. Personal Viaje Figura No. 2.13: Ejemplo de un Cubo de tres dimensiones Operaciones en Modelos Multidimensionales: Slice & Dice: Permite seleccionar los valores de las dimensiones que se requieren. Como se muestra en la figura 2.14, en donde seleccionamos ciertos motivos en años y meses específicos. MOTIVO Enfermedad Cal. Dom. Personal Viaje MAY ABR MAR FEB ENE M E S Slice & Dice MOTIVO AÑO Enfermedad Viaje MAY ENE M E S AÑO Figura No. 2.14: Slice & Dice Rotación: Este operador selecciona el orden de visualización de las dimensiones, como lo muestra la siguiente figura. 26

40 MOTIVO Enfermedad Cal. Dom. Personal Viaje MES MAY Viaje ABR MAR FEB ENE M E S Rotación Personal Cal. Dom. Enfermedad MOTIVO AÑO AÑO Figura No. 2.15: Rotación Drill Down Drill Up: permite bajar o subir a los niveles más atómicos de nuestro esquema multidimensional según la jerarquía establecida en las dimensiones. En la figura 2.16 se pueden apreciar las dos operaciones según la jerarquía de las dimensiones empresa, sección y subsección. Enfermedad Cal. Dom. Personal Viaje Horno Serigrafia Linea 1 Linea 2 Pintura Ensamblaje Fibro Acero S.A Figura No. 2.16: Drill Up y Drill - Down Roll Up: Permite hacer cálculos a las medidas en función de agrupamientos. Estas operaciones pueden ser: count, sum, min, max, avg, etc, en el siguiente ejemplo se realiza un roll up suma sobre las faltas de los empleados. 27

41 Roll Up (suma) MOTIVO Enfermedad Cal. Dom. Personal Viaje MAY ABR MAR FEB M E S ENE SUBSECCION SECCION EMPRESA Figura No. 2.17: Roll - Up Drill-Across: Permite combinar datos de varios cubos, como lo muestra la figura MOTIVO Enfermedad Cal. Dom. Personal Viaje MAY AÑO ABR MAR FEB ENE M E S MOTIVO Enfermedad Cal. Dom. Personal Viaje PINTURA ENSAMBLE CORTE S E C C I O N PINTURA ENSAMBLE CORTE S E C C I O N AÑO AÑO Figura No. 2.18: Drill - Across Drill-Through: Operador que permite acceder a datos descriptivos, un ejemplo de esto en la figura 2.19 Enfermedad Cal. Dom. Personal Viaje Figura No. 2.19: Drill - Through 28

42 2.5. Conclusiones La necesidad en las empresas de información más detallada y de fácil acceso para tomar decisiones acertadas y bien fundamentadas, hace necesaria la creación de aplicaciones para soporte de decisiones basadas en un data warehouse. El DWH es un repositorio, donde se almacenan datos estratégicos, tácticos y operativos. Toda la información esta previamente depurada para garantizar la calidad, y su orientación hacia el negocio, su información se explota mediante herramientas flexibles que independizan en lo posible al usuario del desarrollo informático, llamadas front-end. La información que contendrá este Data Warehouse será elaborada a partir de las diferentes fuentes de datos que existen en la empresa, y el modelo a utilizar para esquematizarlo será el multidimensional, ya que su representación de los datos es cercana a la intuición del usuario. 29

43 CAPITULO 3 HERRAMIENTAS PARA LA CONSTRUCCIÓN, ADMINISTRACIÓN Y MANIPULACIÓN DE UN DATA WAREHOUSE 30

44 3. HERRAMIENTAS PARA LA CONSTRUCCIÓN, ADMINISTRACIÓN Y MANIPULACIÓN DE UN DATA WAREHOUSE 3.1. Introducción Para la utilización de un DWH es de gran importancia conocer las tres fases que nos garantizarán una correcta administración del mismo, las cuales son: Transformación, Administración de la base de datos y por último la Manipulación de los datos. Cada una de estas fases tienen diferentes herramientas para poder ser creadas, y deben ser elegidas cuidadosamente según su funcionalidad, robustez, escenarios en los que van a trabajar, etc. En este capítulo se indicarán las herramientas que pueden ser útiles en cada una de las fases, indicando su definición y características principales. 31

45 3.2. Herramientas para la transformación del Data Warehouse En esta fase se realiza la transformación de inconsistencias y formatos de los datos de las diferentes bases de datos operacionales según las reglas de transformación establecidas (Figura No. 3.1). B.D. A género = F, M B.D. B género = 1, 0 TRANSFORMACION DATA WAREHOUSE B.D. C género = femenino, masculino género = F, M Figura No : Etapas del Data Warehouse - Transformación La transformación de los datos es muy importante dentro de la construcción del DWH ya que de ello depende el correcto funcionamiento y la consistencia de la información. Las herramientas que se pueden utilizar para realizar el objetivo de este nivel son innumerables, basta con utilizar una herramienta de programación que permita interactuar con las bases de datos operacionales; entre las más conocidas tenemos: GeneXus, Oracle, Microsoft Visual Basic, Microsoft Visual FoxPro, etc GeneXus y el Data Warehouse Para la fase de transformación de la información del DWH en la empresa Fibro Acero S.A. se utilizará la herramienta de programación GeneXus. La principal razón para utilizar esta herramienta es que la utilizan en la empresa y es el lenguaje mas conocido por los desarrolladores de este proyecto. A continuación algunas características de dicha herramienta. GeneXus: Es una herramienta inteligente generadora de código y base de conocimiento para el diseño y desarrollo de complejas aplicaciones multiplataforma, que permite el desarrollo de aplicaciones partiendo del diseño de una base de conocimiento, lo cual ofrece un ahorro de hasta un 30% en tiempo y recursos, y de un 70% aproximadamente en la fase de 32

46 mantenimiento 9, realizando los cambios desde la base de conocimiento y transmitiéndolos hacia las aplicaciones generadas de ésa fuente. Miles de medianas y grandes empresas y casas de software en todo el mundo utilizan GeneXus para desarrollar complejos sistemas de misión crítica con grandes bases de datos que comprenden desde sistemas centralizados, distribuidos hasta aplicaciones Web. Estos sistemas integran módulos de data warehouse, Web services, portales corporativos y mucho más. GeneXus es una poderosa herramienta para el diseño y desarrollo de software multiplataforma. Permite el desarrollo incremental de aplicaciones críticas de negocio de forma independiente de la plataforma. GeneXus genera el 100% de la aplicación. Basado en los requerimientos de los usuarios realiza el mantenimiento automático de la base de datos y del código de la aplicación, sin necesidad de programar. GeneXus soporta las plataformas y lenguajes líderes y los DBMS más populares. GeneXus y GXplorer apoyan el ciclo vital entero de un almacén de los datos, desde el desarrollo hasta el análisis de datos Herramientas para la administración del data warehouse La segunda fase que tiene un DWH es el almacenamiento y administración de la información, esto se lo puede lograr por medio de una buena base de datos, la cual nos brinde un tiempo de respuesta menor, datos consistentes y aminore el costo de mantenimiento y administración de información. 9 Genexus. [consulta 29 de noviembre de 2006] 33

47 Clasificación y características A continuación se detallan algunas herramientas para la administración y almacenamiento de información en un DWH Oracle La construcción de su almacén de datos es la mejor manera de consolidar y organizar todos sus datos para que puedan ser manejados, alcanzados y analizados fácilmente. Con una única interfaz de administración y capacidades de self-tuning y autodiagnóstico, Oracle simplifica el mantenimiento de su almacén de los datos en continuo crecimiento, con el funcionamiento más rápido y la mejor relación precio/rendimiento del mercado. El Oracle Warehouse Builder 10g es la herramienta para el diseño de la integración del BI corporativo que gestiona el ciclo vital completo de datos y metadatos para la base de datos Oracle 10g. Algunas de sus características son las siguientes: Posee igual interacción en todas las plataformas (Windows, Unix, Macintosh, Mainframe). Soporta bases de datos de todos los tamaños, desde severas cantidades de bytes y gigabytes en tamaño. Provee salvar con seguridad de error lo visto en el monitor y la información de acceso y uso. Soporta un verdadero ambiente cliente servidor. Este establece un proceso entre bases de datos del servidor y cliente para la aplicación de programas PostgreSQL Es un manejador de bases de datos relacional y de objetos de alta escalabilidad y compatible con SQL. Cuenta con más de 15 años de experiencia en desarrollo y corre en la mayoría de los sistemas operacionales: Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, 34

48 SunOS, Tru64), BeOS, y Windows 10. Esta base de datos cuenta con todas las características de los motores de base de datos privativos como: full ACID compliant, tiene soporte a foreign keys, joins, views, triggers y stored procedures (en diferentes lenguajes), incluye soporte a SQL92 y SQL99 data types, incluyendo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, y TIMESTAMP. También soporta almacenamiento de BLOBs. Cuenta con interfaces de programación para C/C++, Java, Perl, Python, Ruby, Tcl, ODBC y una excelente documentación. Entre algunas de sus características tenemos: Agregación en memoria usando tablas de hashing para hacer que las consultas sean más rápidas. Mejoras en el manejo de subconsultas por el optimizador, que resultan en hasta un 400% de incremento en la velocidad de respuesta de consultas complejas. Nuevo protocolo de conexión que incrementa la velocidad de las transferencias de datos. Implementación mejorada de índices funcionales que permite una mejor indexación en tipos de datos personalizados y compuestos Db2 Es una plataforma de depósito de datos totalmente integrada de IBM, ofrece una integración más completa de los metadatos y la infraestructura de ejecución. DWE (Data Warehouse Edition) le ayuda a conseguir información en demanda al integrar los componentes principales de la administración del depósito, la minería de datos, el proceso analítico online (OLAP) y la creación de informes/análisis en línea, junto con el rendimiento y la utilización mejorada de funciones de business intelligence (BI), cuyo fin es obtener un conocimiento en tiempo real y facilitar la toma de decisiones. Amplía el valor del depósito de datos empresarial con: 10 Asociación Colombiana de Ingenieros de Sistemas. Noviembre [consulta 30 de noviembre de 2005] 35

49 Proceso analítico online (OLAP) y análisis más rápidos, mediante DWE Cube Views y Tablas de consultas materializadas. Gestión de tablas derivada y resumen mediante DWE SQL Warehousing Tools. Minería que se conecta fácil y directamente con el depósito de datos empresariales (EDW) mediante DWE Intelligent Miner Modeling. Técnicas de minería de datos que aprovechan la potencia del EDW distribuido en varios sistemas mediante DWE Intelligent Miner Scoring. Comprensión y análisis de datos muy eficaz mediante DWE Intelligent Miner Visualization. Análisis integrado de DB2 Alphablox, que aprovecha la comprensión EDW en sus procesos empresariales. Entorno de herramientas común para el modelado de datos, el modelado de cubos y el flujo/control de datos SQL mediante DWE Design Studio Microsoft SQL Server 2000 y el Data Warehouse La herramienta de administración del DWH que va a ser utilizada en el desarrollo de este proyecto es Microsoft SQL Server 2000, debido que la empresa cuenta con los permisos y licencias necesarias para su utilización y es el administrador de base de datos más conocido por los desarrolladores de este proyecto. A continuación se define y se detallan algunas características de Microsoft SQL Server Microsoft SQL Server 2000 es uno de los motores de base de datos más conocido en grandes y pequeñas empresas, debido a la fiabilidad, calidad y facilidad de uso, y es considerado una excelente plataforma para procesos transaccionales en línea (OLTP), almacenamiento de datos y aplicaciones de comercio electrónico. Esta herramienta tiene cierta evolución en comparación a su versión anterior, entre las principales tenemos: 36

50 Analysis Services de SQL Server. Conocido anteriormente como servicios OLAP, el cual incluye componentes para la minería de datos. Meta Data Services de Microsoft SQL Server que es su nuevo repositorio de datos. Entre sus características principales encontramos: Integración con Internet. SQL Server 2000 incluye compatibilidad integrada con XML y con diferentes componentes de almacenamiento de datos para sitios Web de mayor tamaño. Escalabilidad y disponibilidad. Puede soportar diferentes plataformas, como equipos con Microsoft Windows 98, por medio de servidores que tengan Microsoft Windows También admite características de servidores federados, vistas indizadas y soporte para memorias grandes, aspectos importantes para diferentes sitios Web. Características de base de datos corporativas. Protege la integridad de los datos a la vez que minimiza la carga de trabajo de la administración de miles de usuarios modificando la base de datos simultáneamente. De igual manera, permite hacer referencia a datos de varios orígenes como si fueran parte de la base de datos de SQL Server Facilidad de instalación, distribución y utilización. Incluye un conjunto de herramientas administrativas y de desarrollo para mejorar el proceso de instalación, distribución, administración y uso del SQL Server Almacenamiento de datos. Incluye herramientas para extraer y analizar datos de resumen para el procesamiento analítico en línea. 37

51 3.4. Herramientas para manipular la información del data warehouse Esta es la tercera y ultima fase en la elaboración de un DWH, la cual nos permite visualizar, utilizar y manipular la información almacenada en nuestro almacén de datos. Existen diversas herramientas las cuales nos permiten manipular un DWH, unas más conocidas y potentes que otras Clasificación y características A continuación se describirán las herramientas más conocidas para la manipulación de información en un DWH. SBI Discoverer Application: Esta es una herramienta de tipo OLAP (tratamiento analítico en línea) que tiene como objetivo integrar una plataforma para el análisis multidimensional de información destinada a optimizar el proceso de toma de decisiones. SBI Discoverer está diseñada para ser utilizada por empresas de diversos sectores y usuarios de diferentes niveles en las organizaciones. Para la utilización de esta herramienta se utilizan 2 componentes conocidos como SBI Discoverer y SBI Generator. El primero es un potente navegador multimensional, generador de reportes y buscador de información oculta, el cual tiene la posibilidad de realizar graficas y dar formato de presentación a los informes. A demás es de fácil utilización, ya que posee la flexibilidad para que los usuarios puedan ir descubriendo las respuestas a sus preguntas, detectando indicadores y desvíos ocultos en la información. Por otra parte, SBI Generator permite generar cubos multidimensionales para ser analizados por SBI Discoverer. Entre algunas de las características de BSI Discoverer Application tenemos: Análisis multidimensional por planilla. Construcción de gráficos totalmente configurables. Drill Down / Drill Up. Creación de medidas calculadas. Generación de reportes con actualización automática. Aplicable a cualquier modelo de datos. 38

52 Conexión a múltiples bases de datos vía ODBC. Creación de dimensiones, niveles y medidas de una manera sencilla. Permite particionar los cubos de información para una mayor velocidad. GXplorer: Es una herramienta nos permite realizar la construcción y administración de un DWH. Esta compuesta de 2 elementos: GXplorer OLAP para las consultas de un DWH y GeneXus Query para las consultas dinámicas sobre la base de datos. Este es un producto que permite obtener la información estratégica necesaria para realizar una correcta toma de dediciones en una organización, y a la vez le da a conocer el estado verdadero en el que se encuentra su empresa de manera sencilla y con la interfaz que prefiera: Windows o Web. GXplorer se encarga de minimizar la complejidad en la construcción y utilización del DWH, permitiendo al ejecutivo una utilización muy simple e inmediata dentro de un ambiente que le es muy natural: EXCEL. Permite administrar todo el ciclo de vida de un DWH, desde la construcción y carga de los datos operacionales hasta la utilización de la información. A continuación se detallan algunas de las características de GXplorer. Permite implementar business intelligence de una manera mas ágil y con un costo total menor (desarrollo, implementación y mantenimiento). Se puede acceder a la información de manera local y remota a través de la Web. Seguridad en el acceso de la información según el perfil del usuario. Con GXplorer se pueden realizar consultas de una manera sencilla y utilizarlas en EXCEL. 39

53 Se puede administrar todo el ciclo de vida de un DWH, automatizando los procesos de creación, carga de datos y mantenimiento. Nos permite utilizar un método incremental en el desarrollo del DWH. 40

54 3.5. Conclusiones: Las herramientas dentro del desarrollo de un proyecto son lo más importante a tomar en cuenta, ya que de estas depende la rapidez, robustez y en si la calidad y funcionalidad del proyecto final. De acuerdo a cada etapa se han escogido las siguientes herramientas para la implementación del DWH en Fibro Acero S.A. Genexus: Se lo utilizará para la construcción y transformación de la información por las siguientes razones. Es el lenguaje utilizado en la empresa por lo que se cuenta con licencia, además es el mas conocido por los desarrolladores de este proyecto. Al ser una herramienta generadora de código, permite ahorrar hasta un 30% en tiempo y recursos, y un 70% en la fase de mantenimiento Es una herramienta para el diseño y desarrollo de software multiplataforma. Soporta las plataformas y lenguajes líderes y los DBMS más populares. Microsoft SQL Server 2000: es la herramienta de administración del DWH que va a ser utilizada en el desarrollo de este proyecto. Permite la integración con Internet. Escalabidad y disponibilidad. Protege la integridad de los datos. Facilidad de instalación, distribución y utilización. Incluye herramientas para extraer y analizar datos de resumen para el procesamiento analítico en línea. Gxplorer y Gxquery: Serán las herramientas front-end a utilizar en nuestro proyecto. Los usuarios utilizan y manipulan la información por medio de EXCEL. 41

55 Permite el manejo de perfiles, lo cual provee seguridad en el acceso a la información. Se puede administrar todo el ciclo de vida del DWH Permite implementar BI de una manera más ágil y a un menor costo. Se puede acceder a la información a través de la Web. Nos permite utilizar un método incremental en el desarrollo del DWH. 42

56 CAPITULO 4 METODOLOGIA DE DESARROLLO PARA LA CONSTRUCCION E IMPLEMENTACION DEL DATA WAREHOUSE 43

57 4. METODOLOGIA DE DESARROLLO PARA LA CONSTRUCCION E IMPLEMENTACION DEL DATA WAREHOUSE 4.1. Introducción Durante los últimos años, se han propuesto diferentes metodologías de análisis y diseño de sistemas de información. Sin embargo, aún no hay una metodología específica para el análisis y diseño de sistemas Data Warehousing que sea ampliamente aceptada. Por lo tanto, para desarrollar nuestro proyecto nos basaremos en las fases de desarrollo de sistemas transaccionales, pero con variantes únicas asociadas al DWH. Durante el desarrollo de este capítulo explicaremos cada una de las fases mientras se va desarrollando el DWH para la empresa Fibro Acero S.A. utilizando la herramienta case Genexus y base de datos SQL Server 2000 para tal fin. 44

58 4.2. Fases para la construcción del Data Warehouse En total son cinco fases las que implementaremos para construir nuestro DWH, se muestran a continuación en la Figura 4.1. Recogida y Análisis de Requisitos Diseño Conceptual Diseño Lógico Específico Diseño Lógico General Implementación Figura No. 4.1: Fases para la construcción de un DWH Recogida y Análisis de Requisitos: aquí se especifican las funciones, servicios y demás resultados que se esperan obtener del DWH a través de la determinación de fuentes de extracción de información, tanto para el sistema OLTP de la empresa, como para las fuentes externas, y también los datos obtenidos de entrevistas y consultas a los usuarios. 45

59 Diseño Conceptual: en esta etapa se especifica el problema a resolver, a través de la construcción del diseño o esquema conceptual del Data Warehouse en base a los requerimientos y la información obtenida en la etapa anterior. Diseño Lógico Específico: el objetivo de esta etapa es construir el esquema lógico partiendo del modelo conceptual generado en la etapa anterior y del análisis sobre el perfomance y almacenamiento de la información. Diseño Lógico General: definición del esquema ROLAP o MOLAP y diseño de las ETL (Extraction, Transformation, Load). Implementación: construcción del Data Warehouse, y preparación de la interfaz con el usuario a través de las herramientas front-end Recogida y Análisis de Requisitos Esta fase es una de las más importantes para el desarrollo del DWH, pues aquí delimitaremos los objetivos y resultados que se esperan obtener en base a las necesidades de los usuarios y a las fuentes de información disponibles en la empresa. Además, con el progreso del análisis que realicemos, se detectaran ciertos inconvenientes, como la transformación de la información si existiera incompatibilidad en el formato de los datos, o la falta de la misma. Para el desarrollo de esta fase, utilizaremos ciertos métodos que nos permitan obtener y depurar los requerimientos de los usuarios, como las reuniones de definición de requerimientos con los implicados en el desarrollo del proyecto, reuniones con el personal de sistemas para determinar como se llevaran acabo dichos requerimientos y analizar la información existente en la empresa Fibro Acero S.A. 46

60 Reuniones de definición de requerimientos Como primer paso realizamos entrevistas a los jefes de los diferentes departamentos en donde se implementara el DWH. A continuación se muestran los requerimientos obtenidos. Departamento de Ventas: Se necesita mostrar la cantidad y el valor de las ventas, tanto locales, nacionales y de exportación, las cuales se puedan dimensionar por el año y mes de venta, tipo de venta, sucursal, ciudad, tipo de cliente, grupos, líneas, productos, estado del cliente y tipo de documentos. El objetivo de este requerimiento es el poder visualizar o explorar las ventas de una manera detallada y acumulada, por medio de los parámetros antes mencionados. Departamento de Logística: Se necesita generar un informe comparativo entre los proveedores que tiene la empresa, para conocer la eficiencia de cada uno de ellos tomando en cuenta la calidad del producto, tiempo de entrega y cantidad entregada. Cada proveedor esta clasificado según la ingerencia del material en la línea de producción, pudiendo llegar a pertenecer al Tipo A, B o C. También es de importancia para el departamento el poder dimensionar las calificaciones según el proveedor, ciudad y país del proveedor, año y periodo de entrega, calificación, clasificación, calidad del producto, entrega a tiempo y cantidad entregada. Departamento de Talento Humano: En este departamento encontramos 2 tipos de necesidades: Faltas y Permisos: Conocer la cantidad en horas y el numero de faltas y permisos que solicitan los empelados de la empresa en un rango de tiempo especifico y así poder llevar un mejor control sobre las justificaciones y motivos por los cuales se han realizado dichos permisos. Es de vital importancia para el departamento, que estos datos puedan ser analizados por: la empresa en la que trabajan, 47

61 sección, subsección, departamento, turno, motivo, año y mes, si esta justificado, si es descontable o si el permiso está anulado. Remuneraciones: Conocer la variación del valor de las remuneraciones según la Empresa, Sección, Subsección, Departamento, Empleado, Año y Mes Reuniones con el personal de Sistemas Una vez establecidas las necesidades de los usuarios, nuestro siguiente paso es entrevistarnos con los encargados del área de sistemas, el Ing. Geovanny Vintimilla, jefe del área y el Ing. Demetrio Toledo, desarrollador de la empresa, para analizar y determinar las fuentes de información que utilizaremos y verificar si es posible satisfacer todas las necesidades por medio de la información que la empresa tiene almacenada en sus bases de datos Análisis de las fuentes de información La empresa Fibro Acero S.A. cuenta con dos sistemas desarrollados por el departamento de sistemas, EcoSAC y Producción, creados con la herramienta case Genexus y utilizan una base de datos en SQL Server 2000 que se encuentra almacenada en un servidor con Windows Server Junto al personal de sistemas se procedió a revisar los sistemas antes mencionados para analizar los requerimientos establecidos y descartar las necesidades que actualmente se encuentran solucionadas por los sistemas oltp, también se verificó que exista la información necesaria en las bases de datos para poder implementar el DWH. Como se van a crear 3 DWH (uno por cada departamento) veremos por separado a cada uno de ellos. Departamento de Talento Humano: El departamento tiene dos requerimientos por cumplir, el primero es de Permisos y Faltas y el segundo de Remuneraciones. Permisos y Faltas: Por medio del análisis antes mencionado, la información se obtendrá del programa EcoSAC, el cual guarda la información en SQL Server 2000 en la base de datos fa002. Aquí se 48

62 necesitará acceder a 10 tablas para poder obtener la información necesaria. En la Figura 4.2 se muestra el modelo entidad relación para esta base de datos. Remuneraciones: La información que requiere el DWH se encuentra en archivos externos de tipo Excel, por lo que es necesario realizar un proceso de carga directa. Estos archivos son generados por el propio departamento y han sido modificados para que su nueva estructura sea aprovechada en el DWH. Departamento de Ventas: La información de las ventas que realiza la empresa y sus sucursales la maneja el sistema Adviser, que esta desarrollado en cobol y la información la almacena en archivos en un Servidor con Red Hat version 8.0, para este caso el departamento de sistemas tiene ya creado un proceso, el cual, permite importar la información del sistema Adviser en Linux a Windows y almacenarlo en una base de datos en SQL Server 2000 llamada Ventas, de donde nuestro DWH obtendrá la información. El modelo entidad relación de esta base de datos será indicada en la Figura 4.3. Departamento de Logística: Para desarrollar este DWH se encontró un problema, el cual no permitirá cumplir con todas las necesidades del departamento, puesto que actualmente el programa que este departamento utiliza Producción se encuentra en etapa de pruebas. En nuestro caso, se procederá a realizar una simulación de cual seria el almacén de datos resultante, mediante la importación de archivos de Excel los cuales contienen ya la información requerida por el departamento. Diagramas Entidad Relación: A continuación se muestran los diagramas entidad relación de las tablas que utilizamos en el desarrollo del DWH. En el caso de los archivos de Excel se muestra un extracto en el Anexo

63 Diagrama Entidad Relación de la base de datos fa002 del sistema EcoSAC para el DWH de Talento Humano. Figura No. 4.2: Diagrama Entidad Relación del Sistema EcoSAC Vintimilla, Geovanny. Modelo Entidad Relación Sistema EcoSAC. [consulta 23 de noviembre de 2007] 50

64 Diagrama Entidad Relación de la base de datos Ventas. Figura No. 4.3: Diagrama Entidad Relación de la base de datos Ventas Diseño Conceptual Para desarrollar el esquema conceptual, utilizaremos los modelos multidimensionales, q están formados básicamente por dimensiones, medidas y hechos, para representar la realidad. Para seleccionar los objetos relevantes y determinar cuales serán dimensiones o medidas, existen tres enfoques, el primero se basa en el análisis de requerimientos, el segundo en un análisis de las bases de datos fuente y el tercero un intermedio entre ambos Vintimilla, Geovanny. Modelo Entidad Relación de la migración de la base de datos Ventas [consulta 28 de noviembre de 2007] 13 Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 15 de enero de 2007] 51

65 En el enfoque basado en requerimientos se analizan los requerimientos de los usuarios obtenidos en la fase anterior y se identifican en ellos los hechos, dimensiones y medidas relevantes. En el enfoque basado en las bases fuentes se construyen cubos multidimensionales transformando un esquema conceptual de las bases fuentes, en general se utiliza el modelo E/R, por lo general se comienzan por identificar en el esquema fuente los posibles hechos relevantes para la toma de decisiones, y a partir de los hechos identificados se navega por las entidades y relaciones construyendo las jerarquías de las dimensiones. Para nuestro trabajo escogimos el modelo CMDM (Conceptual Multidimensional Data Model) desarrollado por Carpani, cuyo enfoque esta dirigido a analizar los requerimientos e identificar en ellos los hechos, dimensiones y medidas relevantes. Aparte incluye nuevas estructuras llamadas relaciones dimensionales, que representan las relaciones entre los objetos Estructuras básicas en el modelo CMDM Nivel: conjunto de objetos que son de un mismo tipo. Gráficamente los atributos de los niveles o ítems aparecen debajo del nombre del nivel. Los ítems que identifican un nivel llevan un numeral (#) a la derecha (clave absoluta), y los que lo identifican sólo con respecto a su padre (clave débil o relativa) aparecen subrayados. En la figura 4.4 se puede observar el nivel Empleado con sus respectivos atributos. EMPLEADO tra_codigo # tra_nombre tra_cedula Figura No. 4.4: Notación Gráfica en CMDM del nivel Empleado 14 Carpani, Fernando. CMDM: Un modelo Conceptual para la Especificación de Bases Multidimensionales. Agosto, [consulta 20 de abril del 2007] 52

66 Dimensión: Es un conjunto de niveles relacionados jerárquicamente, del nivel con más detalle (hijo) al nivel con menos detalle (padre). En cada jerarquía se tiene una relación uno a muchos entre objetos del nivel superior e inferior. Figura No. 4.5: Notación Gráfica en CMDM de la Dimensión Empleado Relaciones Dimensionales: representa el conjunto de todos los cubos que se pueden construir a partir del cruzamiento de los niveles de un conjunto dado de dimensiones 15, en cada uno de los cubos debe aparecer al menos un nivel de cada una de las dimensiones que participan en la relación y uno de ellos puede representar la medida. En CMDM, un cubo representa un cruzamiento concreto entre niveles determinados de las Jerarquías de la relación dimensional, es decir, un conjunto de datos relacionados con un tema en particular como Ventas, Logística, Talento Humano, etc. Por lo tanto, el esquema de una relación dimensional está dado por un nodo central que tiene el nombre de la relación dimensional y los nodos de cada una de las dimensiones que participan de la relación. 15 Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 15 de enero de 2007] 53

67 Figura No. 4.6: Notación Gráfica en CMDM de la Relación Dimensional Faltas y Permisos Implementación del Diseño Conceptual Con los requerimientos obtenidos en el capitulo anterior y el análisis realizado, procederemos a implementar el diseño conceptual CMDM definiendo las estructuras necesarias para el proyecto de acuerdo a cada departamento. Departamento de Ventas: En este departamento se obtuvieron seis dimensiones que permitirán implementar el requerimiento de ventas. A continuación se muestran las dimensiones con sus respectivos atributos y la relación dimensional resultante del cruzamiento entre las dimensiones. Figura No. 4.7: Representación Gráfica Dimensión Fecha Figura No. 4.8: Representación Gráfica Dimensión Sucursal 54

68 CLIENTE CIUDAD ciu_codigo # ciu_nombre TIPO CLIENTE tipcli_codigo # tipcli_descripcion ACTIVO act_codigo # act_descripcion CLIENTE cli_codigo # cli_nombre Figura No. 4.9: Representación Gráfica Dimensión Cliente PRODUCTO GRUPO gru_codigo # gru_descripcion LINEA lin_codigo # lin_nombre PRODUCTO pro_codigo # pro_nombre Figura No. 4.10: Representación Gráfica Dimensión Producto DOCUMENTOS DOCUMENTO doc_codigo # doc_descripcion FACTURA fac_numero # fac_detalle SECUENCIA DETALLE sec_detalle # sec_nombre Figura No. 4.11: Representación Gráfica Dimensión Documentos 55

69 Dimensión Total Ventas: Al manejarse en CMDM la dimensionalidad genérica, las medidas también se las representa como dimensiones. La dimensión Total Ventas posee un solo nivel compuesto por los atributos ven_total que representa el total de ventas en dinero y ven_cantidad que es la cantidad en unidades vendidas. Figura No. 4.12: Representación Gráfica Dimensión Total Ventas Relación Dimensional Ventas: Como resultado del cruzamiento entre las diferentes dimensiones obtenidas para este departamento se obtuvo la relación dimensional que se muestra en la figura Figura No. 4.13: Representación Gráfica Relación Dimensional Ventas Departamento de Logística: como resultado del análisis del requerimiento solicitado por este departamento se han creado cinco dimensiones con sus respectivos atributos, y se muestran a continuación representados gráficamente. TIEMPO AÑO anio_anio # anio_descripcion PERIODO per_codigo # per_descripcion Figura No. 4.14: Representación Gráfica Dimensión Tiempo 56

70 Figura No. 4.15: Representación Gráfica Dimensión Clasificación PROVEEDOR PAIS pai_codigo # pai_descripcion CIUDAD ciu_codigo # ciu_descripcion PROVEEDOR prov_codigo # prov_nombre Figura No. 4.16: Representación Gráfica Dimensión Proveedor TIPO CALIFICACION CALIFICACION cal_codigo # cal_descripcion CALIDAD_PRODUCTO cal_pro_codigo # cal_pro_descripcion CANTIDAD_ENTREGA ent_can_codigo # ent_can_descripcion TIEMPO_ENTREGA ent_tie_codigo # ent_tie_descripcion Figura No. 4.17: Representación Gráfica Dimensión Tipo Calificación Dimensión Calificación: La dimensión calificación representa la medida y posee un solo nivel compuesto por los atributos cal_calidad, cal_cantidad_entrega, cal_tiempo_entrega, cal_proveedor que muestran la calificación de los proveedores. CALIFICACION CALIFICACION cal_calidad cal_cantidad_entrega cal_tiempo_entrega cal_proveedor Figura No. 4.18: Representación Gráfica Dimensión Tipo Calificación 57

71 Relación Dimensional Calificación Proveedor: en la figura 4.19 se muestra el cruce de las dimensiones obtenidas en una única relación dimensional. Figura No. 4.19: Representación Gráfica de la Relación Dimensional Calificación Proveedor Departamento de Talento Humano: en este departamento existen dos requerimientos, obtener información de acuerdo a las faltas y permisos, y de acuerdo a las remuneraciones. En las siguientes figuras se muestran las dimensiones obtenidas para cumplir con estos requerimientos y las relaciones dimensionales resultantes. Faltas y Permisos: como resultado del análisis para este requerimiento se obtuvieron cinco dimensiones. Figura No. 4.20: Representación Gráfica Dimensión Fecha Figura No. 4.21: Representación Gráfica Dimensión Motivo 58

72 Figura No. 4.22: Representación Gráfica Dimensión Empleado ESTADO DOCUMENTOS doc_codigo # doc_descripcion DOCUMENTO NUMERO docu_codigo # docu_descrpcion DETALLE NUMERO det_codigo # det_descrpcion ANULADO anu_codigo # anu_descrpcion DESCONTABLE des_codigo # des_descrpcion FALTA fal_codigo # fal_descrpcion JUSTIFICADO jus_codigo # jus_descrpcion Figura No. 4.23: Representación Gráfica Dimensión Estado Dimensión Permisos: Esta dimensión representa la medida y posee un nivel compuesto por el atributo num_horas que representa el total en horas que se han dado en permisos y faltas, y el atributo cant_permisos que nos muestra la cantidad de permisos y faltas que se han concedido a los empleados. 59

73 Figura No. 4.24: Representación Gráfica Dimensión Permisos Relación Dimensional Faltas y Permisos: El resultado del cruzamiento de las dimensiones antes definidas nos da la siguiente relación dimensional mostrada en la figura Figura No. 4.25: Representación Gráfica Relación Dimensional Faltas y Permisos Remuneraciones: al analizar la información necesaria para obtener este requerimiento se obtuvieron tres dimensiones. Figura No. 4.26: Representación Gráfica Dimensión Fecha 60

74 EMPLEADO EMPRESA emp_codigo # emp_nombre DEPARTAMENTO depa_codigo # depa_nombre SECCION sec_codigo # sec_nombre EMPLEADO tra_codigo # tra_nombre tra_cedula Figura No. 4.27: Representación Gráfica Dimensión Empleado Dimensión Remuneración: en nuestro análisis consideramos esta dimensión como la medida para nuestro requerimiento, y tiene un nivel con el atributo valor_remun que representa el valor en dólares de las remuneración. Figura No. 4.28: Representación Gráfica Dimensión Remuneración Relación Dimensional Remuneraciones: La relación dimensional en donde intervienen las tres dimensiones antes definidas se muestra en la figura

75 Figura No. 4.29: Representación Gráfica Relación Dimensional Remuneraciones Diseño Lógico Específico El objetivo de esta etapa es construir el esquema lógico tomando en cuenta el esquema conceptual construido en la fase anterior, y las estrategias para resolver los requerimientos de almacenamiento y perfomance. El procedimiento a realizar será dividido en dos fases. Definición de lineamientos y mapeos a la base fuente: en esta fase el diseñador indica algunos lineamientos que complementan al esquema conceptual, por ejemplo: criterios para fragmentar datos históricos o qué datos almacenar juntos; estos lineamientos más el esquema conceptual conforman el esquema intermedio. Luego de esto, el diseñador establece mapeos o correspondencias entre el esquema intermedio y la base de datos fuente, es decir, indicar de que datos fuentes se tomara la información para cargar al DWH. Generación del esquema lógico: se especifica como se almacenará el DWH, ya sea utilizando el esquema copo de nieve o estrella Definición de lineamientos y mapeos Lineamientos Son pautas que especifica el diseñador, como el estilo que tendrá el DWH (estrella, copo de nieve, etc) y la forma de almacenar la información. Existen 62

76 varios tipos de lineamientos, pero describiremos los que utilizaremos en el proyecto Materialización de Relaciones En el modelo conceptual, una relación representa el conjunto de cubos que se pueden obtener del cruce de dimensiones. Por lo tanto, con este lineamiento el diseñador indica que cubos se van a materializar, es decir, cuales se van a implementar y almacenar físicamente en el DWH. Un cubo esta formado por un nombre, una relación a la cual materializa, un conjunto de niveles que forman su nivel de detalle, u opcionalmente un nivel que es elegido como medida. 16 Para nuestro proyecto materializaremos los siguientes cubos de acuerdo a cada departamento donde se implementa el DWH. Ventas: Para la relación dimensional Ventas, se decide materializar los siguientes cubos. o Con detalle de Año, Mes, Documento, Sucursal, Grupo, Línea, Producto o Con detalle de Año, Mes, Tipo de Cliente, Ciudad, Activo o Con detalle de Año, Mes, Documento, Sucursal, Grupo, Línea, Producto, Tipo de Cliente La figura 4.30 muestra gráficamente el primer cubo de la relación dimensional Ventas, los demás cubos se muestran en el anexo No Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 4 de diciembre de 2007] 63

77 Figura No. 4.30: Materialización de la Relación Ventas, Cubo 1 Logística: En la relación dimensional Calificación Proveedor se materializaran los siguientes cubos. o Con detalle de Clasificación, Año, Periodo, País, Ciudad, Proveedor o Con detalle de Clasificación, Año, Periodo, Calidad Producto, Entrega a Tiempo, Entrega Cantidad, Proveedor En la figura 4.31 se muestra la representación gráfica de la materialización del primer cubo, el resto de cubos se pueden observar en el anexo No Figura No. 4.31: Materialización de la Relación Calificación Proveedor, Cubo 1 64

78 Talento Humano: en este caso tenemos dos relaciones dimensionales, para la primera relación Faltas y Permisos, se materializan los siguientes cubos: o Con detalle de Año, Mes, Empresa, Sección, Subsección o Con detalle de Año, Mes, Motivo, Justificado, Falta o Con detalle de Año, Mes, Empresa, Sección, Subsección, Motivo, Justificado A continuación se encuentra el grafico del primer cubo, los cubos restantes pueden observarse en el anexo No Figura No. 4.32: Materialización de la Relación Faltas y Permisos, Cubo 1 Y para la relación dimensional Remuneraciones se implementa el siguiente cubo, cuya representación gráfica se muestra en la figura o Con detalle de Año, Mes, Empresa, Departamento, Sección. Figura No. 4.33: Materialización de la Relación Remuneraciones, Cubo 1 65

79 Fragmentación vertical de Dimensiones En este lineamiento el diseñador decide como se van a almacenar los niveles de las dimensiones especificadas en el esquema conceptual. Se los puede desnormalizar (esquema estrella), normalizar (copo de nieve) o aplicar una estrategia diferente para cada dimensión, ya sea normalizar, desnormalizar o indicar que niveles se guardaran juntos en la tabla. Un fragmento es un subconjunto de los niveles de la dimensión, por lo tanto, para que la fragmentación se realice correctamente, debemos tomar en cuenta que esta debe ser completa, es decir que todos los niveles deben estar en al menos un fragmento para no perder información. Gráficamente representamos una fragmentación como una coloración de niveles, los niveles de un mismo fragmento se recuadran con el mismo color. La fragmentación es completa si todos los niveles tienen color 17. Para las dimensiones creadas en nuestro proyecto decidimos aplicar las siguientes estrategias: Departamento de Ventas: en la figura 4.34 se puede observar gráficamente la fragmentación realizada en las dimensiones de acuerdo a lo siguiente: o Fecha: Desnormalizado. o Producto: Tres fragmentos, grupo, línea y producto como tal. o Cliente: Cuatro fragmentos, ciudad, tipo cliente, activo y cliente como tal. o Sucursal: Un fragmento, sucursal. o Documentos: Tres fragmentos, documento, factura, secuencia detalle. o Total Ventas: Al ser la medida no se la fragmenta. 17 Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 13 de diciembre de 2007] 66

80 FECHA AÑO anio_anio # anio_descripcion MES mes_mes # mes_descripcion SUCURSAL SUCURSAL suc_codigo# suc_nombre PRODUCTO DOCUMENTOS GRUPO gru_codigo # gru_descripcion DOCUMENTO doc_codigo # doc_descripcion LINEA lin_codigo # lin_nombre FACTURA fac_numero # fac_detalle PRODUCTO pro_codigo # pro_nombre SECUENCIA DETALLE sec_detalle # sec_nombre CLIENTE CIUDAD ciu_codigo # ciu_nombre TIPO CLIENTE tipcli_codigo # tipcli_descripcion ACTIVO act_codigo # act_descripcion CLIENTE cli_codigo # cli_nombre Figura No. 4.34: Fragmentación Vertical de Dimensiones Requerimiento Dep. Ventas Departamento de Logística: la representación gráfica de la fragmentación de las dimensiones que participan en este requerimiento se la puede observar en la figura o Tiempo: Desnormalizado. o Clasificación: Un fragmento, clasificación. 67

81 o Tipo Calificación: Desnormalizado. o Proveedor: Tres fragmento, país, ciudad y proveedor como tal. o Calificación: No se aplica la fragmentación por ser la medida. Figura No. 4.35: Fragmentación Vertical de Dimensiones Requerimiento Dep. Logística Departamento de Talento Humano: en este departamento tenemos dos requerimientos. Faltas y Permisos: en la figura 4.36 tenemos la fragmentación vertical realizada en las dimensiones para este requerimiento de acuerdo a las siguientes estrategias. o Fecha: Desnormalizado. o Empleado: Cinco fragmentos, empresa, sección, turno, subsección y empleado. o Estado: Ocho fragmentos, documentos, documento numero, anulado, detalle numero, descontable, falta y justificado. o Motivo: Un fragmento, motivo. o Permisos: Será utilizada como la medida, por lo tanto no se la fragmenta. 68

82 EMPLEADO MOTIVO MOTIVO mot_codigo # mot_descripcion EMPRESA emp_codigo # emp_nombre SECCION sec_codigo # sec_nombre TURNO tur_codigo # tur_descripcion FECHA AÑO anio_anio # anio_descripcion SUBSECCION sub_codigo # sub_nombre MES mes_mes # mes_descripcion EMPLEADO tra_codigo # tra_nombre tra_cedula ESTADO DOCUMENTOS doc_codigo # doc_descripcion DOCUMENTO NUMERO docu_codigo # docu_descrpcion DETALLE NUMERO det_codigo # det_descrpcion ANULADO anu_codigo # anu_descrpcion DESCONTABLE des_codigo # des_descrpcion FALTA fal_codigo # fal_descrpcion JUSTIFICADO jus_codigo # jus_descrpcion Figura No. 4.36: Fragmentación Vertical de Dimensiones Requerimiento Faltas y Permisos Dep. Talento Humano Remuneraciones: en este requerimiento las dimensiones fueron fragmentadas de acuerdo a lo siguiente, y su representación gráfica se la puede observar en la figura o Fecha: Desnormalizado. o Empleado: Cuatro fragmentos, empresa, departamento, sección y empleado como tal. o Remuneración: No se implementa porque es la medida. 69

83 Figura No. 4.37: Fragmentación Vertical de Dimensiones Requerimiento Remuneraciones Dep. Talento Humano Fragmentación horizontal de Cubos Para mejorar la perfomance al momento de realizar consultas en tablas de hechos con gran cantidad de información, se las puede fragmentar horizontalmente, con lo cual se obtienen tablas con la misma estructura y más pequeñas, llamadas franjas o bandas. Para definir una fragmentación, las condiciones que distinguen una banda de otra, deben ser expresadas en términos de los ítems de los niveles del cubo 18. Para nuestro proyecto no realizaremos la fragmentación horizontal. Como resultado de la definición de lineamientos sobre el esquema conceptual, tenemos como resultado el esquema intermedio, que consiste de los ítems, niveles, dimensiones y restricciones del esquema conceptual, e incorpora los cubos, fragmentación de dimensiones y fragmentación de cubos definidos en los lineamientos. 18 Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 15 de abril de 2007] 70

84 Mapeos Son funciones que asocian los elementos del esquema intermedio con una expresión construida en base a las tablas y atributos de la base de datos fuente. Una expresión de mapeo puede ser un atributo de una tabla fuente (directo), un cálculo de varios atributos de una tupla (calculo simple), una totalización de atributos de varias tuplas (calculo agregado), o un valor externo, como constantes (externo). Existen dos tipos de funciones de mapeo; los mapeos de dimensiones y los mapeos de cubos. Gráficamente se puede representar la función de mapeo, mediante links o líneas entre los elementos del modelo conceptual y los atributos de las tablas fuente, cuando el mapeo es directo se representa con una línea corrida, cuando es un cálculo se representa con una línea cortada a cada atributo que interviene en el cálculo y se adjunta la definición del cálculo, y cuando es externo no se utilizan líneas pero se adjunta la expresión a la que mapea. 19 Cabe recordar que al inicio del capitulo se indico que El DWH de logística no tiene completamente definidas sus tablas origen, ya que se encuentra en fases de pruebas, por lo que es difícil el poder interpretar el mapeo de dimensiones. De igual manera sucede con el DWH de Remuneraciones en el departamento de Talento Humano, puesto que la información la llevan en hojas de Excel y no existen sus tablas origen Mapeo de dimensiones En este caso, se define una función de mapeo para todos los ítems que conforman la dimensión. Estas funciones deben pensarse como consultas SQL para elegir correctamente a que atributo mapear los ítems. 19 Peralta, Verónica. Diseño Lógico de Data Warehouse a partir de esquemas conceptuales multidimensionales. Noviembre, [consulta 21 de julio de 2007] 71

85 Para indicar las tablas fuentes se tomo la información que provee el SQL 2000, en la cual se muestran solo atributos que son de nuestro interés para la realización del mapeo. Departamento de Talento Humano. o Faltas y Permisos: A continuación se muestra uno de los mapeos que componen el DWH de Talento Humano, en el Anexo 4.5 se pueden observar el resto de mapeos de este departamento. EMPLEADO EMPRESA emp_codigo # emp_nombre SECCION sec_codigo # sec_nombre TURNO tur_codigo # tur_descripcion SUBSECCION sub_codigo # sub_nombre EMPLEADO tra_codigo # tra_nombre tra_cedula Figura No. 4.38: Mapeo de la Dimensión Empleado. Dep. Talento Humano Departamento de Ventas. De igual manera que el caso anterior, a continuación se muestra el mapeo de una de las dimensiones que componen este DWH, el resto de dimensiones se las podrá observar en el anexo

86 Figura No. 4.39: Mapeo de la Dimensión Producto. Dep. Ventas Mapeo de cubos Se lo puede realizar de dos formas, mapeo base, que consiste en especificar una función de mapeo y una condición, o con un mapeo recursivo, en donde se definen una secuencia de drill-ups y una función de mapeo base, sin dejar de lado las operaciones roll-up asociadas a las medidas en cualquiera de los dos casos. Departamento de Talento Humano. A continuación se muestra el mapeo de cubos del DWH de Faltas y Permisos (Fig. 3.40) y de Remuneraciones (Fig. 3.41). En el anexo 4.6 se muestra el drill-up de Faltas y Permisos. Figura No. 4.40: Mapeo de Cubos Faltas y Permisos. Dep. Talento Humano 73

87 EMPLEADO AÑO MES EMPRESA REMUNERACION 1 (REMUNERACIONES) REMUNERACION Sum (remuneracion) DEPARTAMENTO SECCION Figura No. 4.41: Mapeo de Cubos Remuneraciones. Dep. Talento Humano Departamento de Ventas. A continuación se muestra el mapeo de cubos de este departamento. En el anexo 4.8 se puede observar el drillup de Ventas. Figura No. 4.42: Mapeo de Cubos Ventas. Dep. Ventas Departamento de Logística. A continuación se muestra el mapeo de cubos de este departamento. En el anexo 4.9 se puede observar el drillup de Logística. 74

88 Figura No. 4.43: Mapeo de Cubos Logística. Dep. Logística Esquema Lógico Una vez que se han diseñado los cubos, dimensiones y medidas, se procede a realizar el esquema lógico que muestra como esta formado nuestro DWH Esquema lógico del departamento de Talento Humano: Aquí se puede observar la estructura del DWH de Talento Humano, con todas sus medidas y dimensiones. D I M E N S I O N E S D I M E N S I O N E S MEDIDAS Figura No. 4.44: Esquema Lógico del DWH del departamento de Talento Humano 75

89 Tabla de hecho Permisos: en la figura 4.45 podemos observar como esta tabla se relaciona con las dimensiones por medio de una estructura en estrella. Este esquema nos permite realizar todo tipo de reportes especificados en la sección Definición de lineamientos y mapeos de este capitulo. Figura No. 4.45: Modelo Multidimensional en Estrella, Tabla de hecho Permisos Tabla de hecho de Remuneraciones: con el esquema en estrella que se muestra en la figura 4.46 podemos realizar los reportes solicitados en el punto Definición de lineamientos y mapeos de este capitulo para el departamento de Talento Humano con respecto a las remuneraciones. 76

90 Figura No. 4.46: Modelo Multidimensional en Estrella, Tabla de hecho Remuneraciones Esquema lógico del departamento de Ventas: Este esquema nos muestra el DWH de Ventas con su medida y sus dimensiones. Se puede observar que el modelo que se utiliza es un multidimensional tipo estrella. Figura No. 4.47: Esquema Lógico del DWH del departamento de Ventas Esquema lógico del departamento de Logística: Muy similar al esquema del departamento de ventas, utiliza un modelo 77

91 multidimensional de tipo estrella. A continuación se puede observar su medida y sus dimensiones. Figura No. 4.48: Esquema Lógico del DWH del departamento de Logística Diseño Lógico General También llamado diseño físico. En esta etapa del proceso se especifica como se implementara el esquema lógico en el manejador de base de datos, SQL Server 2000, y se preparan las vistas del usuario. Para nuestro proyecto hemos definido dos etapas que engloban este procedimiento Diseño de las ETL Como se explico en el capitulo uno las ETL nos permiten determinar el proceso de extracción, transformación y carga de los datos. o Extracción: una vez realizado el análisis de las fuentes de información existente y de especificar que datos serán necesarios cargar en nuestro DWH, realizamos la extracción de la información de las fuentes internas utilizando objetos propios de la herramienta Genexus (Data Views), y para el caso de la información externa se desarrollo una aplicación dentro del DHW que permite extraer la información de hojas de Excel a nuestro almacén de datos. 78

92 o Transformación: no existió la necesidad de transformar los datos provenientes tanto de las fuentes internas como externas ya que esta información mantiene una estandarización, y nuestro DWH se rigió a las mismas normas que maneja la empresa. o Carga de Información: para un mejor manejo de la carga de la información, en cada DWH se creo una aplicación que permite especificar un rango de fechas de carga con el propósito de cumplir a cabalidad los requerimientos de la empresa según cada departamento Herramientas Front End Para que los usuarios puedan explotar la información almacenada en el DWH se utilizara la herramienta GXplorer, la cual funciona como un complemento de Microsoft Excel y permite de una manera sencilla y dinámica realizar todo tipo de reportes Implementación En esta etapa del desarrollo de nuestro DWH realizaremos la implementación del diseño lógico general especificado anteriormente, cabe recalcar que la implementación será indicada solamente del departamento de Talento Humano, ya que este departamento contiene la mayor cantidad de casos que se pueden encontrar para la recolección de datos Extracción, transformación y carga: Como se había explicado en la etapa anterior, para realizar este proceso utilizaremos la herramienta Genexus, la cual nos permitirá generar la aplicación para realizar la carga de información al DWH, a continuación explicamos paso a paso lo que se realizo en este punto. 79

93 Primero debemos crear las dimensiones y medidas para nuestro DWH por medio de la creación de un objeto tipo transacción y especificando el tipo de elemento de la estructura del DWH, como se muestra en las figuras 4.49, 4.50 y Figura No. 4.49: Elección del objeto Dimensión o Medida Figura No. 4.50: Estructura de la Dimensión Departamentos 80

94 Figura No. 4.51: Estructura de la Medida Permisos Como los datos que necesitamos para nuestro DWH se encuentran en diferentes bases de datos, Genexus nos permite utilizar estas tablas como si fueran parte de nuestra base de conocimiento, para lograr esto se utilizan los objetos conocidos como Data View (Vista de una tabla específica en una base de datos especifica, la cual permite consultar información externa en nuestra aplicación). Para la creación de un Data View se tienen que realizar 3 acciones: o Crear un objeto transacción. Normalmente se usa la misma estructura de la tabla de la base de datos externa (figura 4.52). o Crear y especificar la estructura del Data View. Creamos el objeto y luego se indican los índices externos para realizar una mejor conexión con la base de datos externa, de igual manera se indica la plataforma y su estructura como se indica en la Figura

95 o Especificar la conexión del Data Store. Se indica en donde se encuentra la base de datos externa y a que tabla queremos acceder (Figura 4.54). Figura No. 4.52: Objeto transacción para el Data View y tabla externa Figura No. 4.53: Creación y estructura de un Data View 82

96 Figura No. 4.54: Creación y especificación de un Data Store Para el caso de la medida de remuneraciones es necesario a más de la creación de los Data View el crear un algoritmo el cual nos permita importar información desde un archivo, en nuestro caso es un archivo de Excel que contiene los datos ya filtrados para ser cargados al DWH. En la figura 4.55 se muestra la parte del algoritmo para la carga de los datos. Figura No. 4.55: Algoritmo para la importación de información desde un archivo de Excel Una vez creada la base de datos y los objetos necesarios para el DWH, está lista nuestra aplicación para realizar la carga de los datos, en la 83