Automatización de los procesos de carga en el mercado de datos Recursos Humanos de la UCLV

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática-Física-Computación. Automatización de los procesos de carga en el mercado de datos Recursos Humanos de la UCLV Trabajo de Diploma para optar por el Título de Licenciado en Ciencia de la Computación. Autor: Juan Luis García Mendoza Tutora: MSc. Lisandra Díaz De la Paz. Santa Clara, 2014.

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

(3) Dedicatoria A mi mamá: Por ser la mejor madre del mundo, esa que lo dio todo por mí y que no pensó en bienestar propio más que el mío. Por haber existido y darme tanto amor y cariño de manera incondicional. Por tus consejos y valores que me ayudan a ser un mejor hombre. Por haber sido mi confidente, amiga y hermana. Por brindarme tu sabiduría, tu alegría y los momentos más felices de mi vida. Por tu comprensión cuando más la necesitaba. Por ser mi motivo de inspiración y guía en la vida.. A mi abuela: Por ser más que mi abuela mi segunda madre, la que me ha criado y cuidado toda mi vida. Por motivarme constantemente a ser alguien a través del estudio. Por tus enseñanzas que sin duda han contribuido a mi formación como persona. Por tu atención constante y estar pendiente de mí en todo momento. Por ser la mejor abuela del mundo. Por haber tenido una hija tan maravillosa, mi mamá. Por tu sacrificio al cuidarme, a ti te debo el hombre que soy. Por ser mi motivo de inspiración y guía en la vida.. A mi abuelo: Por tu sacrificio al cuidarme como un hijo. Por tu apoyo y preocupación constante..

(4) Dedicatoria A mi papá: Por tus consejos y enseñanzas tan valiosos que me guían en la vida. Por todo tu apoyo como padre. Por brindarme tu sabiduría y conocimiento.. A mi familia: Por todo su apoyo, han sido muy importantes para mí, porque sin ustedes no fuera lo que soy hoy.. A mi novia: Por estar a mi lado en los buenos y malos momentos, brindarme todo tu apoyo, cariño y amor..

(5) Agradecimientos Agradecimientos  A mi mamá y abuela por ser mis motivos de inspiración y por todo el sacrificio que han realizado en pos de que me convierta en un buen hombre.  A mi tutora MSc. Lisandra Díaz De la Paz, por toda su ayuda y sobre todo su comprensión, además de sus revisiones y sugerencias.  A mi familia materna por su ayuda y apoyo constante en especial a mi abuelo Luis, a mis tías Isa, Tania, Barbarita y Milady, a mis tíos y a mis primos.  A mi papá y familia paterna por su ayuda incondicional y por todo su cariño.  A mi novia y su familia por brindarme su cariño y apoyo incondicional.  A mis amigos por ayudarme y brindarme su apoyo cuando más lo necesité.  A mis hermanos que aunque no vivan conmigo sé que están ahí.  A todos mis profesores, por contribuir en mi formación profesional.  A todos aquellos que no he mencionado y de una forma u otra me dieron su ayuda..

(6) Resumen Resumen. En la actualidad los procesos de Extracción, Transformación y Carga (ETL) han tomado auge en el desarrollo de los almacenes de datos. Estos constituyen un punto esencial en la extracción de datos desde fuentes heterogéneas, la limpieza, integración y carga de los mismos hacia el almacén o mercado de datos correspondiente, mediante la implementación de transformaciones. El departamento de Recursos Humanos (RRHH) de la Universidad Central “Marta Abreu” de Las Villas (UCLV) cuenta con un mercado de datos poblado a partir de procesos ETL que garantizan la carga inicial. Hasta el momento, las transformaciones y trabajos implementados no permiten su actualización a partir de los cambios en los datos. Por tanto, el presente trabajo de diploma tiene como objetivo implementar procesos ETL que garanticen la carga incremental hacia dicho mercado de datos. Además, se confeccionan cubos OLAP, reportes estáticos y dinámicos que permiten el análisis de la información actual e histórica. Para lograr estos objetivos se utiliza el software DB Visual ARCHITECT 4.0 para la modelación dimensional, el Sistema Gestor de Base de Datos (SGBD) PostgreSQL para almacenar los datos del mercado de datos y varias herramientas de la suite de Pentaho, haciendo énfasis en el entorno de desarrollo Spoon perteneciente al Pentaho Data Integration (PDI)..

(7) Abstract Abstract. At the present time Extraction, Transformation and Load processes has taken boom in the development of Data Warehouses. These constitute an essential point for data extraction from heterogeneous sources, cleaning, integration and load of them towards the corresponding Data Warehouse or Data Mart, through the implementation of transformations. Human Resources department from Universidad Central “Marta Abreu” de Las Villas have a data mart populated from ETL processes that they assurance the initial load. Until this moment the jobs and transformations implemented does not allow their update beginning with change in the data. For this reason, the present work has as the main objective to implement ETL processes that guarantee the incremental load towards such data mart. Besides, OLAP cubes, static and dynamic reports are designed which allow the analysis of historical and present information. To reach these objectives DB Visual ARCHITECT 4.0 software for dimensional modelation, the SGBD PostgreSQL to data store and several tools from Pentaho suite are used, making emphasis in the development environment Spoon which belong to Pentaho Data Integration..

(8) Tabla de Contenidos Tabla de Contenidos. Introducción ............................................................................................................................ 1 Capítulo 1 Consideraciones generales sobre los procesos ETL. ............................................ 5 1.1 Metodologías de desarrollo de DWH. .............................................................................. 5 1.1.1 Metodología top-down. ................................................................................................. 5 1.1.2 Metodología bottom-up. ................................................................................................ 6 1.2 Procesos ETL.................................................................................................................... 8 1.2.1 Funcionalidades de los procesos ETL. .......................................................................... 9 1.2.2 Subsistemas de Kimball. ............................................................................................. 10 1.2.3 Proceso de extracción de datos. ................................................................................... 10 1.2.3.1 Extracción inicial. ..................................................................................................... 11 1.2.3.2 Extracción incremental. ............................................................................................ 11 1.2.3.2.1 Técnicas intrusivas. ............................................................................................... 13 1.2.3.2.1.1 Técnica de CDC basada en fuentes de datos. ..................................................... 13 1.2.3.2.1.2 Técnica de CDC basada en disparadores............................................................ 14 1.2.3.2.1.3 Técnica de CDC basada en snapshot. ................................................................. 16 1.2.3.2.2 Técnicas poco intrusivas........................................................................................ 17 1.2.3.2.2.1 Técnica de CDC basada en archivos log. ........................................................... 18 1.2.3.2.3 Comparación entre las técnicas de CDC. .............................................................. 19 1.2.4 Proceso de transformación........................................................................................... 19 1.2.4.1 Limpieza. .................................................................................................................. 19 1.2.4.2 Calidad de los datos. ................................................................................................. 20 1.2.4.3 Conformación. .......................................................................................................... 20 1.2.5 Proceso de carga. ......................................................................................................... 20 1.2.5.1 Carga inicial. ............................................................................................................. 21 1.2.5.2 Carga incremental. .................................................................................................... 21 1.2.5.2.1 SCD Tipo 0. ........................................................................................................... 21 1.2.5.2.2 SCD Tipo 1. ........................................................................................................... 22 1.2.5.2.3 SCD Tipo 2. ........................................................................................................... 22 1.2.5.2.4 SCD Tipo 3. ........................................................................................................... 23 1.2.5.2.5 SCD Tipo 4. ........................................................................................................... 23.

(9) Tabla de Contenidos 1.2.5.2.6 SCD Tipo 5. ........................................................................................................... 24 1.2.5.2.7 SCD Tipo 6. ........................................................................................................... 25 1.2.5.2.8 SCD Tipo 7. ........................................................................................................... 25 1.3 Herramientas utilizadas. ................................................................................................. 26 1.3.1 DB Visual ARCHITECT 4.0 ....................................................................................... 26 1.3.2 Sistema Gestor de Base de Datos PostgreSQL. ........................................................... 27 1.3.3 Suite Pentaho. .............................................................................................................. 27 1.3.3.1 Consola de usuario de Pentaho 5.0.1. ....................................................................... 27 1.3.3.2 Pentaho Data Integration 5.0.1. ................................................................................ 28 1.3.3.2.1 Spoon. .................................................................................................................... 29 1.3.3.2.2 Pan y Kitchen. ....................................................................................................... 29 1.3.3.2.3 Carte. ..................................................................................................................... 29 1.3.3.3 Pentaho Schema Workbench 3.6.1. .......................................................................... 30 1.3.3.4 Pentaho Report Designer 5.0.1. ................................................................................ 30 1.3.3.5 Pentaho Metadata Editor 5.0.1. ................................................................................ 31 1.4 Conclusiones parciales. .................................................................................................. 31 Capítulo 2 Metodología de desarrollo del mercado de datos RRHH de la UCLV. .............. 32 2.1 Comparación de las metodologías de Inmon y Kimball................................................. 32 2.2 Tareas de la metodología de Kimball. ............................................................................ 33 2.2.1 Planificación y análisis de requerimientos. ................................................................. 33 2.2.2 Modelado dimensional. ............................................................................................... 33 2.2.3 Diseño lógico. .............................................................................................................. 38 2.2.3.1 Diseño lógico del DSA. ............................................................................................ 38 2.2.3.2 Diseño lógico del mercado de datos RRHH de la UCLV. ....................................... 39 2.2.4 Diseño físico. ............................................................................................................... 40 2.2.5 Diseño e implementación de los procesos ETL........................................................... 41 2.2.5.1 Fuentes de datos. ...................................................................................................... 41 2.2.5.2 Proceso de extracción de los datos. .......................................................................... 43 2.2.5.2.1 Extracción inicial. .................................................................................................. 43 2.2.5.2.1 Extracción incremental. ......................................................................................... 43 2.2.5.2.1.1 Lectura directa basada en timestamps. ............................................................... 44.

(10) Tabla de Contenidos 2.2.5.2.1.2 Técnica de CDC usando secuencias de la base de datos. ................................... 44 2.2.5.2.1.3 Técnica de CDC basada en disparadores............................................................ 44 2.2.5.2.1.4 Técnica de CDC basada en snapshot. ................................................................. 44 2.2.5.2.1.5 Técnica de CDC basada en archivos log. ........................................................... 46 2.2.5.2.1.6 Comparación de las técnicas de CDC. ............................................................... 46 2.2.5.3 Transformación ......................................................................................................... 47 2.2.5.4 Proceso de carga. ...................................................................................................... 48 2.2.5.4.1 Carga inicial ........................................................................................................... 48 2.2.5.4.2 Carga incremental .................................................................................................. 48 2.2.5.5 Implementación de los procesos ETL para poblar el mercado de datos RRHH. ..... 49 2.2.5.6 Implementación de los procesos ETL para realizar las cargas incrementales. ......... 51 2.2.5.7 Comparación entre las técnicas full reloading y basada en snapshot. ...................... 53 2.3 Conclusiones parciales ................................................................................................... 53 Capítulo 3 Validación de los procesos ETL y explotación de la información del mercado de datos RRHH de la UCLV. .................................................................................................... 54 3.1 Configuración de pasos del PDI. .................................................................................... 54 3.1.1 Configuración del paso Merge Rows (diff). ................................................................ 54 3.1.2 Configuración del paso Dimension Lookup/Update. .................................................. 55 3.1.2.1 Tratamiento de los tipos de SCD (modo de actualización). ..................................... 59 3.1.2.2 Carga de la tabla de hechos (modo de búsqueda). .................................................... 63 3.2 Validación de los procesos ETL. .................................................................................... 65 3.2.1 Inserción después de la carga inicial. .......................................................................... 66 3.2.2 Actualización en una SCD Tipo 2 después de la carga inicial. ................................... 67 3.3 Diseño de los cubos OLAP............................................................................................. 69 3.4 Reportes estáticos y dinámicos. ...................................................................................... 72 3.4.1 Reportes estáticos. ....................................................................................................... 72 3.4.2 Reportes dinámicos. .................................................................................................... 74 3.5 Roles y usuarios. ............................................................................................................. 75 3.6 Automatización de los procesos ETL. ............................................................................ 76 3.7 Conclusiones parciales. .................................................................................................. 77 Conclusiones......................................................................................................................... 78.

(11) Tabla de Contenidos Recomendaciones. ................................................................................................................ 79 Referencias bibliográficas. ................................................................................................... 80.

(12) Lista de Figuras Lista de Figuras. Figura 1: Representación esquemática del desarrollo del DWH según la metodología topdown descrita por Inmon (1992). ........................................................................................... 6 Figura 2: Tareas de la metodología denominada Ciclo de Vida Dimensional del Negocio (Kimball et al., 1998, Mundy et al., 2006, Kimball et al., 2008). .......................................... 7 Figura 3:Arquitectura general de las herramientas de integración de datos (Tellez et al., 2012). ...................................................................................................................................... 9 Figura 4: Ejemplo de SCD Tipo 1 (Bouman y Van Dongen, 2009). ................................... 22 Figura 5: Ejemplo de SCD Tipo 2 (Bouman y Van Dongen, 2009). ................................... 23 Figura 6: Hecho con SCD Tipo 2 (Bouman y Van Dongen, 2009). .................................... 23 Figura 7: Ejemplo de SCD Tipo 3 (Bouman y Van Dongen, 2009). ................................... 23 Figura 8: Diseño lógico usando SCD Tipo 4 (Ross, 2013) .................................................. 24 Figura 9: Diseño lógico usando SCD Tipo 5 (Ross, 2013). ................................................. 24 Figura 10: Solución Híbrida SCD Tipo 6 (Ross, 2013). ...................................................... 25 Figura 11: Diseño lógico usando SCD Tipo 7 (Ross, 2013). ............................................... 26 Figura 12: Arquitectura del PDI (Bouman y Van Dongen, 2009)........................................ 29 Figura 13: Funcionamiento básico de Pentaho Schema Workbench (Cognus, 2012, Masó y Castellón, 2013) .................................................................................................................... 30 Figura 14: Modelo lógico del DSA ...................................................................................... 39 Figura 15: Modelo lógico del mercado de datos RRHH de la UCLV realizado por Masó y Castellón (2013). .................................................................................................................. 39 Figura 16: Modelo lógico del mercado de datos RRHH de la UCLV (Modificado) ........... 40 Figura 17: Diseño físico del mercado de datos RRHH de la UCLV .................................... 40 Figura 18: Diseño para la implementación de la extracción inicial. .................................... 43 Figura 19: Algoritmo MergeSort (Labio y García-Molina, 1996). ...................................... 45 Figura 20: Diseño para la implementación de la extracción incremental. ............................ 47 Figura 21: Diseño de las cargas incrementales. .................................................................... 49 Figura 22: Diseño de los procesos ETL para poblar el mercado de datos RRHH. .............. 49 Figura 23: Transformación dsa_causa_baja. ....................................................................... 50 Figura 24: Trabajo carga_dsa. ............................................................................................. 50 Figura 25: Transformación inicial_dim_tiempo. .................................................................. 51.

(13) Lista de Figuras Figura 26: Trabajo carga_inicial.......................................................................................... 51 Figura 27: Diseño de los procesos ETL para realizar las cargas incrementales hacia el mercado de datos RRHH de la UCLV. ................................................................................ 51 Figura 28: Transformación incremental_dim_persona. ....................................................... 52 Figura 29: Subtransformación subtransformación_dim_persona. ....................................... 52 Figura 30: Comparación de la duración entre las técnicas full reloading y basada en snapshot. ............................................................................................................................... 53 Figura 31: Configuración del paso Merge Rows (diff) del software PDI. ............................ 55 Figura 32: Configuración del paso Dimension lookup/update del software PDI. ................ 56 Figura 33: Configuración del panel Fields en modo de actualización. ................................ 59 Figura 34: Modificación a la transformación inicial_dim_persona. .................................... 61 Figura 35: Duración del paso RH variando los valores de los campos Commit size y Cache size in rows para el caso de inserción. .................................................................................. 61 Figura 36: Duración del paso RH variando los valores del campo Cache size in rows para el caso de inserción. .................................................................................................................. 62 Figura 37: Duración del paso RH variando los valores del campo Cache size in rows para el caso de actualización. ........................................................................................................... 63 Figura 38: Configuración del panel Fields en modo de búsqueda. ...................................... 63 Figura 39: Modificación a la transformación inicial_tabla_hechos..................................... 64 Figura 40: Duración del paso Persona variando los valores del campo Cache size in rows para el caso de búsqueda. ..................................................................................................... 65 Figura 41: Fragmento de la tabla dim_persona donde existe la empleada “Airenys”. ........ 67 Figura 42: Fragmento de la tabla hecho_bajas_altas donde existe un hecho relacionado con la empleada “Airenys”. ......................................................................................................... 67 Figura 43: Valores de los atributos de “Sinesio” en la tabla fuente Empleados_Gral antes de la carga inicial. ...................................................................................................................... 68 Figura 44: Valores de los atributos de “Sinesio” en la tabla dim_persona después de la carga inicial........................................................................................................................... 68 Figura 45: Valores de los atributos de “Sinesio” en la tabla fuente Empleados_Gral modificados después de la carga inicial. .............................................................................. 68.

(14) Lista de Figuras Figura 46: Valores de los atributos de “Sinesio” en la tabla dim_persona después de la carga incremental. ................................................................................................................. 69 Figura 47: Registros del empleado “Sinesio” en la tabla de hechos hecho_baja_alta después de la carga incremental. ........................................................................................................ 69 Figura 48: Cubos del mercado de datos RRHH. .................................................................. 70 Figura 49: Cubo Altas General publicado en la consola de Pentaho. .................................. 71 Figura 50: Cubo Bajas General publicado en la consola de Pentaho. .................................. 71 Figura 51: Fragmento del reporte relación entre altas y bajas en los últimos 10 años de la UCLV. .................................................................................................................................. 73 Figura 52: Fragmento del reporte relación entre altas y bajas en los últimos 10 años de un área pasada por parámetro. ................................................................................................... 73 Figura 53: Modelo de metadatos del mercado de datos RRHH de la UCLV. ...................... 74 Figura 54: Fragmento del reporte dinámico donde se muestran las bajas del 2014 por área75 Figura 55: Fragmento del reporte dinámico donde se muestran las altas del 2013 por área. .............................................................................................................................................. 75 Figura 56: Usuarios creados en la vista de administración de Pentaho. ............................... 76 Figura 57: Archivo carga_incremental.bat. ......................................................................... 76.

(15) Lista de Tablas Lista de Tablas. Tabla 1: Comparación entre las técnicas de CDC (Casters et al., 2010). ............................. 19 Tabla 2: Puntuaciones por cada uno de los parámetros (Villarreal, 2013). .......................... 32 Tabla 3: Comparación entre las metodologías de Inmon y Kimball (Villarreal, 2013). ...... 32 Tabla 4: Atributos de la tabla de dimensiones dim_persona. ............................................... 36 Tabla 5: Atributos de la tabla de mini dimensiones mini_dim_causa_baja. ........................ 36 Tabla 6: Atributos de la tabla de dimensiones dim_tiempo. ................................................. 37 Tabla 7: Atributos de la tabla de dimensiones dim_area. .................................................... 37 Tabla 8: Atributos de la tabla de hechos hecho_bajas_altas. ............................................... 38 Tabla 9: Detalles de las fuentes de información. .................................................................. 42 Tabla 10: Comparación entre las técnicas de CDC adaptadas de Casters et al. (2010). ...... 46 Tabla 11: Solución a las inconsistencias encontradas en las fuentes de datos. .................... 47.

(16) Introducción Introducción. Hoy en día, las bases de datos (BD) existentes en las empresas mantienen la información necesaria para la actividad diaria de las mismas, ya que dichas BD suministran datos a los sistemas de información corporativos (Rodríguez, 2010).. Los almacenes de datos [acrónimo del inglés Data Warehouse (DWH)] surgen por la necesidad de resolver problemas de análisis de grandes volúmenes de información (Rosales, 2009, Valdés et al., 2013).. Los datos de interés, esparcidos a través de múltiples fuentes heterogéneas son integrados en un sistema de bases de datos central, llamado DWH (Jörg y Dessloch, 2010). La integración de datos consta de tres pasos fundamentales; primero se extraen los datos de sus fuentes, que generalmente son heterogéneas, luego se transforman y depuran, con el uso de técnicas de limpieza de datos y finalmente se cargan en el DWH.. Las herramientas de ETL que han sido construidas soportan estos pasos de integración de datos. Es por ello que los procesos ETL son el centro del almacén de datos (Kimball y Ross, 2002, Kimball y Caserta, 2004, Jörg y Dessloch, 2008, Jörg y Dessloch, 2009) y su calidad es de importancia significativa para la exactitud, operatividad y usabilidad (Karagiannis et al., 2013).. El proceso de construcción de un proceso ETL puede ser extraordinariamente exigente y complejo, estando además limitado por muchos aspectos, tales como: los requerimientos, formatos y deficiencias de los datos de origen, las habilidades del personal disponible, las necesidades de los usuarios finales, el presupuesto del proyecto y los períodos de tiempo para los procesos de actualización. Teniendo en cuenta esto, no se debe despreciar el tiempo y los recursos que se han de utilizar para su construcción (Bouman y Van Dongen, 2009, Casters et al., 2010).. 1.

(17) Introducción Por razones de eficiencia los DWH son típicamente actualizados de forma incremental, es decir, los cambios son capturados en las fuentes y propagados para el DWH regularmente. (Jörg y Dessloch, 2008). El departamento de Recursos Humanos de la Universidad Central “Marta Abreu” de Las Villas cuenta con un mercado de datos [acrónimo del inglés Data Mart (DM)] poblado a partir de procesos ETL que garantizan la carga inicial.. Hasta el momento las transformaciones y trabajos implementados no permiten la actualización del mercado de datos a partir de los cambios en los datos, surgiendo así la necesidad de implementar procesos ETL que permitan las cargas incrementales para incorporar de manera automática los datos al DM Recursos Humanos de la UCLV.. Objetivo General Implementar procesos ETL que garanticen la carga incremental hacia el mercado de datos RRHH de la UCLV utilizando la herramienta Pentaho Data Integration para mantenerlo actualizado de manera automática.. Objetivos Específicos 1.. Analizar los tipos de carga, estrategias y métodos que existen actualmente dentro de los procesos de ETL.. 2.. Incorporar al mercado de datos RRHH de la UCLV los cambios en los datos de forma incremental.. 3.. Automatizar los procesos de carga del mercado de datos de la UCLV de manera que permita su actualización.. Preguntas de Investigación 1.. ¿Qué estrategia de carga es la más adecuada para el mercado de datos RRHH de la UCLV?. 2.. ¿Cómo incorporar los cambios en los datos del sistema fuente en el mercado de datos RRHH de forma incremental? 2.

(18) Introducción 3.. ¿Qué transformaciones y trabajos implementar para lograr la actualización de los procesos de carga de manera automática?. Justificación de la Investigación La investigación posee utilidad práctica porque frecuentemente la dirección de la UCLV solicita informes resumidos sobre los ingresos y bajas de los profesores e investigadores de las diferentes áreas de la UCLV. Hasta el momento estos reportes se hacen utilizando como fuente primaria una BD en Access, lo cual dificulta el trabajo y provoca información redundante y pérdida de la misma. En el trabajo de Masó y Castellón (2013) se implementa un DM para darle solución a esta problemática, pero este no permite la actualización de los datos a partir de sus fuentes, por lo que es necesario la implementación de las cargas incrementales para mantenerlo actualizado de manera automática.. Viabilidad Para llevar a cabo la presente investigación se utiliza la suite de Inteligencia de Negocios Pentaho en su versión libre, en especial se emplea la herramienta gráfica Spoon del PDI para implementar las transformaciones y trabajos en la solución de las anomalías detectadas en las fuentes de datos. Sobre esta herramienta existen estudios previos los cuales aseveran su fiabilidad.. En el grupo de Base de Datos del Centro de Estudios Informáticos (CEI) se cuenta con los medios técnicos, software y personal necesario para desarrollar este trabajo.. El presente trabajo se estructura en tres capítulos: En el capítulo 1 se exponen dos de las metodologías de desarrollo de DWH más reconocidas por la comunidad de la modelación dimensional de las mismas. Se describen las etapas de los procesos ETL así como los diferentes tipos, métodos y estrategias de carga incremental y se muestran las principales características de las herramientas utilizadas, haciendo énfasis en la herramienta PDI.. 3.

(19) Introducción En el capítulo 2 se comparan las metodologías de desarrollo de Inmon y Kimball, se selecciona una y se describe paso a paso cómo llevar a cabo el desarrollo del mercado de datos en el área RRHH de la UCLV. Además se analiza el diseño de los procesos ETL encargados de las cargas inicial e incremental así como las fuentes de datos utilizadas y se implementan dichos procesos.. En el capítulo 3 se analizan las configuraciones de los pasos Merge Rows (diff) y Dimension Lookup/Update. Se diseñan y publican cubos OLAP mediante la herramienta Pentaho Schema Workbench (PSW) y los metadatos utilizando Pentaho Metadata Editor (PME), estos últimos, para obtener reportes dinámicos que aportan flexibilidad en los parámetros de la consulta. Se confeccionan y visualizan reportes estáticos mediante la herramienta Pentaho Report Designer (PRD) que permiten analizar los datos del mercado de datos RRHH de la UCLV. Por último se definen los usuarios que tienen acceso a la información publicada en la consola de Pentaho y los roles de cada uno como medida de seguridad.. 4.

(20) Capítulo 1 Capítulo 1 Consideraciones generales sobre los procesos ETL. En este capítulo se exponen dos de las metodologías de desarrollo de DWH más reconocidas por la comunidad de la modelación dimensional de las mismas. Se presentan las etapas de los procesos ETL, los principales conceptos, tipos de carga, estrategias y métodos de carga incremental existentes actualmente en estos procesos. Además, se muestran aspectos fundamentales de las herramientas utilizadas, haciendo énfasis en la herramienta PDI.. 1.1 Metodologías de desarrollo de DWH. Las metodologías de desarrollo de DWH se pueden englobar dentro de dos grandes bloques: top-down y bottom-up, que se corresponden con las metodologías propuestas por Inmon (1992, 2002) y Kimball y Ross (2002), respectivamente. Estos autores, en muchos aspectos, se consideran los precursores del DWH (Rodríguez, 2010).. 1.1.1 Metodología top-down. Esta metodología se define en el año 1992 (Inmon, 1992), se actualiza en el 2002 (Inmon, 2002) y se basa en conceptos bien conocidos del diseño de bases de datos relacionales (Inmon, 2002, Imhoff et al., 2003).. Inmon (1992, 2002) involucra, desde el inicio, todo el ámbito corporativo sin centrarse en un incremento específico hasta después de haber terminado completamente el diseño del DWH. En la filosofía de este autor, un DM es sólo una de las capas del DWH y son dependientes del mismo por lo que se construyen después de él. La idea es identificar las áreas principales desde el inicio del proyecto para evitar la aparición de situaciones inesperadas que lo puedan poner en peligro.. La metodología top-down tiene un enfoque a modo de explosión porque en cierta forma no viene acompañada del ciclo de vida normal de las aplicaciones, sino que los requisitos van acompañando al proyecto según vaya comprobándose su necesidad. Esto ocasiona riesgos a la compañía, que invierte grandes esfuerzos en el desarrollo del DWH y no explota la inversión y obtiene los beneficios hasta la aparición de los DM.. 5.

(21) Capítulo 1 Consecuentemente, es probable que después de invertir tiempo y recursos en el desarrollo del DWH, sean necesarios cambios fundamentales que incrementen los costos de desarrollo para la organización y evidencien el peligro del éxito de todo el proyecto, los cuales podían ser evitados con una pronta puesta en explotación (Rodríguez, 2010).. Figura 1: Representación esquemática del desarrollo del DWH según la metodología top-down descrita por Inmon (1992).. 1.1.2 Metodología bottom-up. La metodología bottom-up se convierte en el estándar para el apoyo a las decisiones empresariales (Rodríguez, 2010). La misma se basa en lo que Kimball y Ross (2002) denominan Ciclo de Vida Dimensional del Negocio (del inglés Business Dimensional Life Cycle) que utiliza el modelo dimensional (Kimball et al., 1998, Mundy et al., 2006, Kimball et al., 2008, Rivadera, 2010).. Este ciclo de vida del proyecto de DWH, está basado en cuatro principios básicos: . Centrarse en el negocio: Identificación de los requerimientos del negocio y su valor asociado.. . Construir una infraestructura de información adecuada: Diseñar una base de información única, integrada, fácil de usar, de alto rendimiento, donde se reflejará la amplia gama de requerimientos de negocio identificados en la empresa.. . Realizar entregas en incrementos significativos: Crear el DWH en incrementos entregables en plazos de seis a doce meses. 6.

(22) Capítulo 1 . Ofrecer la solución completa: Proporcionar todos los elementos necesarios para entregar valor a los usuarios de negocios, lo que significa tener un DWH sólido, bien diseñado, con calidad probada y accesible. También se deben entregar herramientas de consulta ad hoc, aplicaciones para informes y análisis avanzados, capacitación, soporte, sitio web y documentación.. La figura 2 muestra las tareas de esta metodología.. Figura 2: Tareas de la metodología denominada Ciclo de Vida Dimensional del Negocio (Kimball et al., 1998, Mundy et al., 2006, Kimball et al., 2008).. En la figura 2 se observa la importancia de la planificación del proyecto y el rol central de la definición de requerimientos del negocio que es soporte inicial de las tareas subsiguientes, además existe una relación entre estas dos tareas, evidenciada por la doble flecha. Otra observación es la existencia de tres caminos, que se combinan cuando se instala finalmente el sistema: . Tecnología (Camino Superior): Implica tareas relacionadas con software específico, por ejemplo, la suite de Pentaho.. . Datos (Camino del medio): En el mismo se diseña e implementa el modelo dimensional y se desarrollan los procesos ETL para cargar el DWH.. 7.

(23) Capítulo 1 . Aplicaciones de Inteligencia de Negocios (Camino Inferior): En esta ruta se encuentran tareas en las que se diseñan y desarrollan las aplicaciones de negocios para los usuarios finales.. 1.2 Procesos ETL Los procesos ETL son el centro de cualquier almacén de datos (Kimball y Ross, 2002, Kimball y Caserta, 2004, Jörg y Dessloch, 2008, Jörg y Dessloch, 2009) y reciben una atención considerable en el mercado de integración de datos (Jörg y Dessloch, 2009). El 70% de los recursos necesitados para la implementación y mantenimiento de un DWH son típicamente consumidos por estos procesos (Kimball y Caserta, 2004).. Durante los procesos ETL, los datos son extraídos de múltiples y heterogéneas fuentes como bases de datos de Procesamiento de Transacciones en Línea [acrónimo del inglés OnLine Transaction Processing (OLTP)], archivos de texto, sistemas legados, hojas de cálculo, entre otras. Luego son transformados y limpiados con el objetivo de ajustarlos al diseño del DWH y cargados en el mismo donde son accesibles para las aplicaciones de Inteligencia de Negocios [acrónimo del inglés Business Intelligence (BI)] (Berson y Smith, 1997, El-Sappagh et al., 2011).. Los procesos ETL requieren las habilidades de analistas de empresas, diseñadores de bases de datos, desarrolladores de aplicaciones y no son eventos únicos. Como los datos de las fuentes se modifican, el DWH debe actualizarse periódicamente. Además, como el negocio cambia, las necesidades del DWH también deben cambiar.. Los procesos ETL deben ser diseñados para que sean fáciles de modificar; además, un proceso ETL sólido, bien diseñado y documentado es necesario para el éxito de un proyecto de DWH (El-Sappagh et al., 2011). La figura 3 muestra la arquitectura general de las herramientas de integración de datos.. 8.

(24) Capítulo 1. Figura 3:Arquitectura general de las herramientas de integración de datos (Tellez et al., 2012).. 1.2.1 Funcionalidades de los procesos ETL. Las funcionalidades de los procesos ETL pueden ser resumidas en las siguientes tareas prominentes (Simitsis et al., 2005a, Simitsis et al., 2005b): 1.. Identificación de información relevante en las fuentes de datos.. 2.. Extracción de esta información.. 3.. Adecuación e integración de la información que proviene de las múltiples fuentes de datos en un formato común.. 4.. Limpieza del conjunto de datos resultante.. 5.. Propagación de los datos para el almacén de datos y/o mercados de datos.. También, Vassiliadis (2009) define funcionalidades de los procesos ETL similares a las anteriores: 1.. Extracción de los datos apropiados de las fuentes de datos.. 2.. Transporte para un área de preparación de los datos [acrónimo del inglés Data Staging Area (DSA)] donde serán procesados.. 3.. Transformación de los datos fuentes y el cálculo de los valores nuevos (y, posiblemente los registros) con el propósito de obedecer la estructura de la relación del DWH para el cual son dirigidos.. 4.. Aislamiento y limpieza de registros problemáticos, para garantizar que las reglas de negocio y las restricciones de la BD sean respetadas.. 5.. Carga de los datos limpios y transformados para la relación apropiada en el DWH.. 9.

(25) Capítulo 1 1.2.2 Subsistemas de Kimball. Kimball y Caserta (2004) crearon 38 subsistemas para añadir estructura a las diversas tareas que son parte de un proceso ETL y son requisitos magníficos para validar cualquier solución ETL disponible, no sólo para el PDI sino también para cualquier software de integración de datos. Luego, Kimball et al. (2008) reestructuraron los subsistemas y los redujeron finalmente a 34.. Según Casters et al. (2010) y Díaz et al. (2013), las cuatro áreas principales que conforman los 34 subsistemas son: . Extracción: Obtención de los datos de sus fuentes de origen. Contiene 3 subsistemas.. . Limpieza y conformación: Consiste en acciones que permiten validar y aumentar la calidad de la información. Contiene 5 subsistemas.. . Entrega: Carga y actualización de los datos del almacén de datos. Contiene 13 subsistemas.. . Gestión: Controla y supervisa la correcta tramitación de todos los componentes de la solución ETL. Contiene 13 subsistemas.. 1.2.3 Proceso de extracción de datos. El primer paso en cualquier proceso ETL es la extracción de los datos (El-Sappagh et al., 2011), el cual es responsable de extraer los datos de sus fuentes, con distintas características que necesitan ser manejadas por el proceso ETL para la lograr una extracción eficaz. Durante la extracción de los datos de sus fuentes, el equipo de desarrollo de los procesos ETL debe estar al tanto de:. 1.. Los drivers ODBC\JDBC utilizados para conectarse a las bases de datos fuentes.. 2.. La estructura de los datos en las fuentes de datos.. 3.. Conocer cómo manejar las fuentes de datos con naturaleza diferente como unidades principales.. La extracción es la parte más dura de la actualización del DWH, esto es debido a dos hechos: primero, el software de extracción debe incurrir en gastos generales mínimos con las fuentes 10.

(26) Capítulo 1 de datos durante la corrida y en segundo lugar, el software de extracción debe ser instalado en el lado fuente con efecto mínimo para la configuración del software de la fuente de datos (Vassiliadis, 2009).. La extracción está dividida en dos fases: la inicial y la incremental (Kimball et al., 1998, ElSappagh et al., 2011, Yuan et al., 2011) y durante la misma, los datos son extraídos de sus fuentes y propagados para el DSA (Kimball et al., 1998, Castellanos et al., 2009).. 1.2.3.1 Extracción inicial. En la extracción inicial, se obtienen por primera vez los datos de diferentes fuentes para ser cargados dentro del DWH. Este proceso se hace solo una vez después de construir el DWH para poblarlo con un volumen grande de datos (Kimball et al., 1998, El-Sappagh et al., 2011).. Durante esta extracción, la captura de cambios en los datos [acrónimo del inglés Change Data Capture (CDC)] no tiene importancia porque en la mayoría de los casos se extrae la fuente de datos entera (Kimball y Caserta, 2004). Una vez concluido este proceso, la prioridad número uno es la CDC, la cual está distante de ser una tarea trivial y desde el comienzo del proyecto se debe planificar una estrategia que permita capturarlos y mantener actualizado el DWH.. 1.2.3.2 Extracción incremental. La aproximación más sencilla para la actualización del DWH es llamada full reloading cuya idea es simplemente volver a correr el proceso ETL de carga inicial (Jörg y Dessloch, 2009, Jörg y Dessloch, 2010). De este modo, los cambios requeridos para la actualización del DWH pueden ser recuperados. Esta aproximación es ineficiente porque frecuentemente solo una fracción pequeña de los datos fuentes cambia durante los ciclos de carga, y solo se necesita capturar estos cambios y propagarlos para el DWH. Además, no es práctico eliminar y volver a cargar los datos del DWH puesto que los datos históricos tienen que ser preservados.. Otra aproximación es la incremental cuya idea es capturar solo los datos que cambian en las fuentes desde la última extracción, lo que la hace más eficaz que full reloading (Jörg y Dessloch, 2008, Jörg y Dessloch, 2009, Jörg y Dessloch, 2010). 11.

(27) Capítulo 1 Con el propósito de capturar estos cambios en las fuentes de datos, las técnicas de CDC deben ser explotadas (Jörg y Dessloch, 2010).. Las técnicas de CDC monitorean las fuentes de datos operacionales con el objetivo de detectar y capturar cambios en los datos (Kimball y Caserta, 2004, Jörg y Dessloch, 2008) y constituye el subsistema dos de los 34 propuestos por Kimball et al. (2008). Estas técnicas solo capturan cambios que no han sido previamente extraídos (Eccles, 2013) y son de particular importancia para el mantenimiento del DWH porque permite la propagación de los cambios capturados en las fuentes de datos hacia el mismo.. Los procesos ETL utilizan diversas técnicas de CDC para capturar los datos modificados, añadidos y eliminados en las fuentes de datos desde la última extracción, con el propósito de actualizar el DWH (Casters et al., 2010, El-Sappagh et al., 2011). Estos procesos son periódicos coincidiendo con el ciclo de actualización del DWH y las necesidades del negocio (El-Sappagh et al., 2011).. Existen varias técnicas que se pueden utilizar para capturar los cambios en los datos (Eccles, 2013). Cada una de ellas sigue uno de los siguientes estilos arquitectónicos en el subsistema CDC: . Pull CDC, donde una técnica de CDC captura los cambios en los datos en las fuentes de datos.. . Push CDC, donde una técnica de CDC detecta los cambios en los datos en su ruta para las fuentes de datos.. Las técnicas de CDC con arquitectura Pull existen en abundancia, debido a la relativa facilidad con la cual pueden ser implementadas. Las técnicas Push son rara vez implementadas, pero tienen la ventaja de estar en mejor posición para permitir la captura de los cambios en los datos en tiempo real. En este trabajo solo se analiza la arquitectura Pull CDC.. 12.

(28) Capítulo 1 Muchos autores han reconocido varias técnicas de CDC (Ram y Do, 2000, Kimball y Caserta, 2004, Bouman y Van Dongen, 2009, Casters et al., 2010, Jörg y Dessloch, 2010, Eccles, 2013) y aunque difieren en algunas, coinciden en la mayoría. En el presente trabajo se utiliza la clasificación de autores como Bouman y Van Dongen (2009) y Casters et al. (2010), porque además de conceptualizar estas técnicas ofrecen soluciones en la herramienta PDI.. Según la clasificación dada por estos autores existen dos categorías principales de técnicas de CDC: intrusivas y poco intrusivas (Bouman y Van Dongen, 2009, Casters et al., 2010).. 1.2.3.2.1 Técnicas intrusivas. Las técnicas intrusivas son aquellas que tienen un posible impacto en el desempeño de la fuente donde los datos son recuperados, y por tanto, cualquier operación que requiera ejecutar declaraciones SQL, es una técnica intrusiva. Tres de las cuatro técnicas descritas por Bouman y Van Dongen (2009) y Casters et al. (2010), para capturar cambios en los datos son intrusivas, dejando sólo una opción poco intrusiva.. 1.2.3.2.1.1 Técnica de CDC basada en fuentes de datos. La técnica de CDC basada en fuentes de datos se trata como columnas de auditoría (Kimball y Caserta, 2004) y depende de que existan atributos (columnas de auditoría) disponibles en las fuentes de datos que permitan a los procesos ETL hacer una selección de los registros que cambiaron (Bouman y Van Dongen, 2009, Casters et al., 2010). Estos atributos son usualmente poblados por los disparadores de la base de datos y sirven de criterio de selección para capturar los cambios en los datos que ocurrieron desde la última extracción (Jörg y Dessloch, 2008, Jörg y Dessloch, 2009, Jörg y Dessloch, 2010).. Existen dos alternativas dentro de esta técnica: . Lectura directa basada en timestamps (valores de fecha y tiempo): Al menos un atributo de tipo timestamp se necesita para esta alternativa pero preferentemente son necesarios dos: uno con la fecha y tiempo cuando se creó el registro y otro cuando fue modificado por última vez.. 13.

(29) Capítulo 1 . Secuencias de la base de datos: La mayoría de las bases de datos tienen algún tipo de opción de autoincremento para valores numéricos en una tabla. Cuando tal secuencia es usada, es fácil de identificar cuáles registros se han insertado desde la última vez que se analizó la tabla.. Las alternativas anteriores requieren tablas auxiliares en el DWH para almacenar la información referente a la última fecha en la cual los datos fueron cargados o el último número recuperado de la secuencia (Bouman y Van Dongen, 2009, Casters et al., 2010). Una práctica común es crear estas tablas ya sea en un diseño separado o en el DSA, pero nunca en el almacén de datos, ni en uno de los DM.. Un timestamp o solución basada en secuencias es considerada una de las más simples para implementar una técnica de CDC (Bouman y Van Dongen, 2009, Casters et al., 2010) y por esta razón también es uno de los métodos más comunes para capturar los cambios en los datos, sin embargo, esta simplicidad es discutida, debido a la ausencia de algunas capacidades esenciales que pueden encontrarse en opciones más adelantadas: . Distinción entre inserciones y actualizaciones: Solamente cuando la fuente de datos contiene dos timestamps, uno para inserciones y otro para las actualizaciones, esta diferencia puede ser detectada.. . Detección de registros eliminados: Esto no es posible, a menos que el sistema fuente sólo borre un registro de forma lógica. La columna tiene una fecha de eliminación pero no está físicamente borrado de la tabla.. . Detección de múltiples actualizaciones: Cuando un registro es actualizado múltiples veces durante el período comprendido entre las cargas inicial y actual, estas actualizaciones intermedias se pierden durante el proceso.. . Capacidades de tiempo real: Timestamp o extracción basada en secuencias de datos es siempre una operación batch y por consiguiente inadecuado para ser usado en tiempo real.. 1.2.3.2.1.2 Técnica de CDC basada en disparadores. Los disparadores de una base de datos pueden usarse para disparar acciones cuando se utiliza cualquier declaración de manipulación de datos como insert, update o delete (Bouman y Van 14.

(30) Capítulo 1 Dongen, 2009, Casters et al., 2010). Por tanto, los disparadores también pueden emplearse para la captura de cambios en los datos y colocar estos registros cambiados en tablas intermedias en las fuentes de datos para extraerlos más tarde o ponerlos directamente en el DSA del DWH.. Esta técnica no es implementada a menudo porque agregar disparadores a una base de datos no está permitido en la mayoría de los casos debido a que requiere modificaciones en la misma, y estas muchas veces no están cubiertas por acuerdos de servicio o no se tiene autorización asignada por parte de los administradores de la base de datos [acrónimo del inglés Database Administrator (DBA)]. Además, puede reducir severamente la velocidad de un sistema transaccional.. La técnica de CDC basada en disparadores es la alternativa más intrusiva pero tiene la ventaja de detectar todos los cambios en los datos, permitiendo cargas en tiempo real (Bouman y Van Dongen, 2009, Casters et al., 2010), y se puede usar la interfaz ODBC para capturar estos cambios sin necesidad de crear o comprar herramientas especializadas (Eccles, 2013).. Las desventajas de la técnica de CDC basada en disparadores son la necesidad de permisos por parte del DBA para poder modificar la base de datos fuente, la sintaxis específica de la base de datos para las declaraciones de los disparadores, el gran costo de procesamiento que implica y el requerimiento de espacio de almacenamiento adicional (Bouman y Van Dongen, 2009, Casters et al., 2010).. Una alternativa para utilizar los disparadores directamente en las fuentes de datos es establecer una solución de replicación, donde los cambios detectados en las tablas seleccionadas sean replicados para las tablas receptoras en el DSA. Estas tablas replicadas entonces pueden ser extendidas con los disparadores requeridos para soportar esta técnica de CDC.. Aunque esta solución implica un gran costo de procesamiento y requiere espacio de almacenamiento adicional, es realmente eficiente y poco intrusiva ya que la réplica se basa en leer los cambios de los archivos log de la base de datos, técnica que se describe en el acápite 15.

(31) Capítulo 1 1.2.3.2.2.1. La réplica es también una funcionalidad estándar de la mayoría de los SGBD, incluyendo MySQL, PostgreSQL e Ingres.. 1.2.3.2.1.3 Técnica de CDC basada en snapshot. Cuando ningún timestamps está disponible y los disparadores o la réplica no son una opción, otro recurso que se puede usar es snapshots de las tablas, que pueden ser comparadas en búsqueda de cambios (Bouman y Van Dongen, 2009, Casters et al., 2010). Esta técnica, conocida también como snapshot differential, es además, apropiada para los datos que residen en fuentes poco sofisticadas como archivos planos (Jörg y Dessloch, 2008, Jörg y Dessloch, 2009).. La técnica snapshot guarda una copia exacta de cada extracción previa en el DSA para uso futuro y durante la siguiente corrida, el proceso lleva la tabla fuente entera al DSA donde se compara con los datos cargados durante el último proceso (Kimball y Caserta, 2004). Si bien no es la técnica más eficiente, es la más confiable de todas las técnicas incrementales de extracción para capturar cambios en los datos, porque hace una comparación fila por fila en busca de cambios y es casi imposible la pérdida de datos. Adicionalmente, tiene la ventaja que las filas borradas en la fuente de datos pueden ser detectadas.. Un inconveniente principal de esta técnica es la necesidad de extracciones de grandes volúmenes de datos, sin embargo, es aplicable para todos los tipos de fuentes de datos (Jörg y Dessloch, 2008, Jörg y Dessloch, 2009).. En principio, la identificación de los registros que están presentes en una snapshot y no en la otra da las inserciones y las supresiones realizadas. Las actualizaciones se refieren a dos registros que están presentes en las dos snapshots y comparten la misma llave primaria, pero los valores que no son claves difieren. A pesar de esta simplicidad teórica, las consideraciones de rendimiento tienen mucha importancia y plantean un problema de investigación (Vassiliadis, 2009).. 16.

(32) Capítulo 1 Una idea general del funcionamiento de esta técnica es planteada por Castellanos et al. (2009). Según estos autores, los datos extraídos, después de guardados en Lnew son comparados contra una snapshot previa (Lold), para discriminar inserciones, eliminaciones y actualizaciones recientes en los registros. Esta comparación es realizada a través de un operador de diferencia, [Diff (Δ)], que revisa en busca de igualdad sólo en un cierto subconjunto de atributos de los registros (generalmente la llave primaria).. Considerando A, como un conjunto de atributos y B un subconjunto de estos se pueden encontrar los registros recién insertados, mediante la expresión: ΔB (Lnew, Lold) = {x ∈ 𝐿𝑛𝑒𝑤 | ¬ y ∈ 𝐿𝑜𝑙𝑑: x[b1] = y[b1] ∧. . .∧ x[bn] = y[bn]} donde b1,…,bn ∈ B.. Para encontrar un registro actualizado, se considera que para cada registro de Lnew existe uno en Lold con los mismos valores para B y al menos un atributo perteneciente a A con un valor diferente. (Si A=B se puede utilizar el operador de diferencia de relaciones clásico). Invirtiendo el uso del operador de diferencia, se obtienen los registros borrados. El último paso de esta fase es reemplazar la snapshot Lold con Lnew.. Varios métodos pueden servir para eso. Uno de ellos borra la snapshot más antigua y simplemente renombra Lnew como Lold (primero una supresión lógica es realizada para no afectar la carga de trabajo del sistema, y entonces en un punto posterior inactivo, la supresión física se hace). Otro método es actualizar Lold con los registros que cambiaron.. El uso de snapshot tiene doble propósito: puede ser considerada como una solución de respaldo cuando se cometen errores o servir de DSA.. 1.2.3.2.2 Técnicas poco intrusivas. Las técnicas poco intrusivas son aquellas que tienen un bajo impacto en el desempeño de la fuente donde los datos son recuperados.. 17.

(33) Capítulo 1 1.2.3.2.2.1 Técnica de CDC basada en archivos log. La forma más avanzada y menos intrusiva entre las técnicas de CDC es usar una solución basada en archivos log, en los cuales puede ponerse cada operación de inserción, actualización y eliminación manejada en una base de datos (Bouman y Van Dongen, 2009, Casters et al., 2010). Esta técnica es utilizada en conjunto con SGBD (Jörg y Dessloch, 2008, Jörg y Dessloch, 2009).. Para los casos en que es necesaria una solución basada en archivos log en un ambiente heterogéneo están disponibles varias ofertas comerciales como son: el Oracle Golden Gate y Attunity Stream. Una desventaja de estas ofertas es el precio para la cual se propone como alternativa la herramienta de código abierto Tungsten Replicator (Casters et al., 2010).. La herramienta Tungsten Replicator es una opción interesante y ofrece opciones avanzadas de replicación maestro-esclavo. Además, soporta opciones basadas en declaración y replicación fundamentadas en filas, por lo que constituye una solución adelantada (Bouman y Van Dongen, 2009, Casters et al., 2010).. Cuando un archivo log es vaciado, todas las transacciones dentro de él son irrescatables. Para evitar esto se aconseja que el DBA cree un archivo log especial específicamente para esta técnica de CDC porque solo se necesita transacciones para algunas tablas específicas de la base de datos fuente (Kimball y Caserta, 2004).. Existen algunas variantes para la implementación de estas técnicas de CDC: log scraping o log sniffing (Kimball y Caserta, 2004). Log scraping analiza gramaticalmente los archivos log y recupera los cambios de interés (Labio y García-Molina, 1995, Labio y García-Molina, 1996, Jörg y Dessloch, 2008, Jörg y Dessloch, 2009, Jörg y Dessloch, 2010).. Log sniffing, en contraste, recorta el archivo log y captura los cambios muy de prisa. Mientras estas técnicas tienen poco impacto en la base de datos fuente, implican alguna latencia entre la transacción original y los cambios capturados. Obviamente, esta latencia es más alta para el acercamiento log scraping (Jörg y Dessloch, 2010). 18.

(34) Capítulo 1 1.2.3.2.3 Comparación entre las técnicas de CDC. La tabla 1 muestra una comparación entre las técnicas CDC analizadas. En esta se puede apreciar la eficiencia de las técnicas basadas en archivos log y en disparadores, aunque para el mercado de datos RRHH de la UCLV se vislumbran como las más factibles de implementar las basadas en archivos log y en snapshot.. Tabla 1: Comparación entre las técnicas de CDC (Casters et al., 2010). Aspectos. Timestamps. Snapshot. Triggers. Log. NO NO NO NO NO NO SI. SI NO SI NO NO NO SI. SI SI SI NO SI SI NO. SI SI SI SI SI SI NO. Distinción entre inserción/actualización Detección de múltiples actualizaciones Identificación de eliminaciones Poco intrusivo Soporta tiempo real Requiere DBA Independiente del SGBD 1.2.4 Proceso de transformación.. El segundo paso en cualquier proceso ETL es la transformación de los datos (Vassiliadis, 2009). Este paso realiza la limpieza y conformación de los datos entrantes para obtener datos precisos, correctos, completos, coherentes y no ambiguos. También incluye depuración, transformación e integración de datos.. 1.2.4.1 Limpieza. La limpieza es la corrección en los datos de posibles errores, por ejemplo: datos incompletos, duplicados, formatos inconsistentes en cuanto a descripción, abreviaturas y unidades de medidas, falta de datos de entrada o que violen las restricciones de integridad del sistema. La etapa de limpieza es una de las más importantes, ya que garantiza la calidad de los datos en el DWH y en ella se deben corregir las anomalías que se detecten en el proceso de la unificación de datos (Díaz et al., 2013).. 19.

(35) Capítulo 1 1.2.4.2 Calidad de los datos. La calidad de los datos es un término que abarca el estado de los datos, así como el conjunto de procesos para lograrla (Díaz et al., 2013). Los datos deben ser correctos, inequívocos, coherentes y completos (Kimball y Caserta, 2004, Díaz et al., 2013) : . Datos correctos: Los valores y las descripciones de los datos deben describir su verdadera definición.. . Datos inequívocos: Los valores y las descripciones de los datos sólo pueden tener un único significado.. . Datos coherentes: Los valores y las descripciones de datos deben usar una notación constante para transmitir su verdadero significado. Ejemplo: para mantener la coherencia de los datos se debe utilizar solo una nomenclatura.. . Datos completos: Se debe garantizar que los valores individuales y las descripciones de los datos, se definan para cada caso, permitiendo identificar que valores posibles puede tomar cada dato y se debe asegurar que el número total de registros completados después que se realice el proceso de integración debe ser del 100% completo asegurando que no se pierde información en alguna parte del flujo de datos.. 1.2.4.3 Conformación. Cuando la información se encuentra limpia y con una calidad adecuada, ésta es unificada, conformada y normalizada. Los indicadores son calculados de una forma racional, lo mismo que los atributos de las dimensiones, para que estén unificados y en todos los sitios donde aparezcan tengan la misma estructura y el mismo significado (Díaz et al., 2013).. 1.2.5 Proceso de carga. La carga de los datos para la estructura dimensional seleccionada es el paso final de un proceso ETL (Vassiliadis, 2009). En este paso, los datos extraídos y transformados son escritos en las estructuras dimensionales a las que acceden los usuarios finales y sistemas aplicativos. El paso de carga incluye ambas tablas, las de dimensiones y las de hechos.. 20.

(36) Capítulo 1 1.2.5.1 Carga inicial. En la carga inicial, todos los datos extraídos y transformados de las fuentes son cargados en el DWH (Jörg y Dessloch, 2009).. 1.2.5.2 Carga incremental. En la carga incremental los cambios en los datos que ocurrieron en las fuentes son propagados hacia el DWH (Jörg y Dessloch, 2009). La idea básica de esta carga es actualizar el DWH con los cambios capturados en las fuentes. Sus beneficios comparada con full reloading son dobles: primero, el volumen de datos cambiados en las fuentes es muy pequeño comparado con el volumen global y en segundo lugar, la mayoría de los datos dentro del DWH permanece ilesa durante la carga incremental, ya que los cambios son sólo aplicados donde son necesarios.. Los procesos ETL diseñados para implementar la carga incremental utilizan las técnicas de CDC para capturar los cambios en las fuentes de datos (Jörg y Dessloch, 2008). Durante la misma es necesario tener en cuenta el manejo de las dimensiones lentamente cambiantes [acrónimo del inglés Slowly Changing Dimension (SCD)], el cual se corresponde con el subsistema nueve de los propuestos por Kimball et al. (2008).. Las dimensiones que se consideran SCD son aquellas que pueden cambiar de manera ocasional o constante, siendo de gran importancia el registro de los cambios históricos realizados para mantener la veracidad de la información cargada en el DWH (Tellez et al., 2012).. 1.2.5.2.1 SCD Tipo 0. En el tipo 0 el valor del atributo dimensión nunca cambia, por lo que los hechos son siempre agrupados por este valor original. Este tipo es apropiado para cualquier atributo etiquetado “original” y se aplica a la mayoría de los atributos de la tabla de dimensiones tiempo (Ross, 2013).. 21.

(37) Capítulo 1 1.2.5.2.2 SCD Tipo 1. Se sobrescriben los valores de la dimensión con los nuevos valores que vienen de la fuente de datos. Este tipo es el más básico y no permite mantener una traza de los cambios ocurridos en los datos ya que siempre se actualizan los valores anteriores con los nuevos. Se considera básico y sencillo de implementar. Usualmente esta estrategia es implementada en casos donde no es importante mantener la información histórica, como por ejemplo: cuando se trata de modificar el valor de un campo de un registro porque contiene errores ortográficos (Kimball y Caserta, 2004, Tellez et al., 2012). La figura 4 muestra un registro existente en el DWH al cual se le realiza un cambio en el atributo Customer_City variando los valores de Toronto a Vancouver.. Figura 4: Ejemplo de SCD Tipo 1 (Bouman y Van Dongen, 2009).. 1.2.5.2.3 SCD Tipo 2. Se añaden nuevos registros a la dimensión con los nuevos valores que provienen de la fuente de datos. Se agrega un campo de versión y generalmente dos columnas, una para almacenar la fecha de inicio y en otra la fecha final de ese valor. Con este método se puede conocer el período de tiempo para el cual es válido cierto dato en la dimensión y se genera ilimitada información de cambios (Kimball y Caserta, 2004, Tellez et al., 2012). En resumen se añade una nueva fila con una nueva llave subrogada y el nuevo valor que cambió quedando el resto de los atributos iguales, en especial su llave natural (Figuras 5 y 6).. 22.

(38) Capítulo 1. Figura 5: Ejemplo de SCD Tipo 2 (Bouman y Van Dongen, 2009).. Figura 6: Hecho con SCD Tipo 2 (Bouman y Van Dongen, 2009).. 1.2.5.2.4 SCD Tipo 3. Este tipo requiere de una columna para el valor actual y otra para el valor anterior (Figura 7). En caso que sea necesario mantener una cantidad específica de valores anteriores se debe crear esa cantidad de columnas para almacenarlos. A diferencia del tipo 2, este tipo mantiene cambios limitados en la historia (Kimball y Caserta, 2004, Tellez et al., 2012).. Figura 7: Ejemplo de SCD Tipo 3 (Bouman y Van Dongen, 2009).. 1.2.5.2.5 SCD Tipo 4. Este tipo es usado cuando un grupo de atributos en una tabla de dimensiones cambian rápidamente por lo que son colocados en una mini dimensión que requiere su llave primaria. 23.

(39) Capítulo 1 única. Las llaves primarias de la tabla de dimensiones base y de la mini dimensión son propagadas hacia la tabla de hechos asociada a ambas (Ross, 2013). La figura 8 muestra cómo queda el diseño lógico de un caso de estudio usando SCD Tipo 4.. Figura 8: Diseño lógico usando SCD Tipo 4 (Ross, 2013). 1.2.5.2.6 SCD Tipo 5. Es llamado tipo 5 por la suma de los tipos 4 y 1 (4+1= 5) y es usado para conservar los valores con precisión y reportar los hechos históricos según los datos actuales de los atributos. El tipo 5 incorpora un atributo tipo 1 que referencia a la mini dimensión en la dimensión base. Esto permite que los atributos de la mini dimensión sean accedidos junto con los de la dimensión base sin acoplarse a través de una tabla de hechos. Estas dos tablas deben presentarse como una sola (Ross, 2013). La figura 9 muestra cómo queda el diseño lógico de un caso de estudio usando SCD Tipo 5.. Figura 9: Diseño lógico usando SCD Tipo 5 (Ross, 2013).. 24.

(40) Capítulo 1 1.2.5.2.7 SCD Tipo 6. Este tipo es conocido como SCD Tipo 6 o híbrido y se describe como la suma de los tipos 1, 2 y 3 (1+2+3= 6), es decir, es una mezcla de diferentes estrategias aplicadas en una sola tabla de dimensiones (Bouman y Van Dongen, 2009, Díaz y López, 2013).. La decisión de responder a los cambios en los atributos de la dimensión con los tres tipos de SCD es hecha columna por columna (Figura 10). En este caso se tiene un tipo 3 con una columna tipo 2 y en otra un tipo 1 (Ross, 2013).. Figura 10: Solución Híbrida SCD Tipo 6 (Ross, 2013).. 1.2.5.2.8 SCD Tipo 7. En el tipo 7 existen dos tablas de dimensiones con el mismo diseño, donde una de ellas almacena solo los valores actuales (Current Product Dimension), permitiendo realizar consultas sin filtrar por el atributo current de la tabla de dimensiones Product Dimension. La tabla de hechos tiene dos llaves foráneas, una para cada dimensión, y la tabla de dimensiones Product Dimension tiene una llave foránea referenciando a Current Product Dimension. Si se necesita comparar atributos de la tabla Current Product Dimension con otros atributos de la 25.

(41) Capítulo 1 tabla Product Dimension, no es necesario hacer el acople con la tabla de hechos, simplemente se hace por la referencia directa que se tiene en esta última tabla (Ross, 2013). La figura 11 muestra el diseño lógico de un caso de estudio utilizando el tipo 7.. Figura 11: Diseño lógico usando SCD Tipo 7 (Ross, 2013).. 1.3 Herramientas utilizadas. Para la creación del mercado de datos RRHH de la UCLV se utilizan un conjunto de herramientas como DB Visual ARCHITECT para el diseño de la BD, el SGBD PostgreSQL para almacenar los datos del mercado y la suite de Pentaho como herramienta de BI.. 1.3.1 DB Visual ARCHITECT 4.0 DB Visual ARCHITECT 4.0 (DB-VA) es un sofisticado diseñador de mapeo objeto-relacional [acrónimo del inglés Object-Relational Mapping (ORM)] para el desarrollo rápido de aplicaciones de base de datos y generador de código. DB-VA ofrece capacidad visual de modelado para realizar los diseños lógico y físico de los datos. Además, soporta sincronización entre el modelo de objetos y el modelo de datos y genera una capa ORM confiable, escalable y de alto rendimiento. La misma soporta transacción, caché y otras características optimizadas para manipular registros de la base de datos relacional de forma completamente orientada a objetos (Paradigm, 2007).. 26.