STMDM - una herramienta de soporte para la implementación de una solución de datos maestros

Texto completo

(1)STMDM – Una herramienta de soporte para la implementación de una solución de datos maestros. Trabajo de Tesis presentado al Departamento de Ingeniería de Sistemas por Andrei Garzón Bernal. Asesor: Darío Ernesto Correal Torres. Para optar al título de Magister en Ingeniería. Ingeniería de Sistemas y Computación Universidad de los Andes Julio, 2012.

(2) II. Índice general. Lista de Tablas ................................................................................................................................................... IV Lista de Figuras ................................................................................................................................................... V Lista de Algoritmos ............................................................................................................................................ VI Resumen ............................................................................................................................................................. 1 INTRODUCCIÓN .................................................................................................................................................. 2 1.1. Problema ........................................................................................................................................... 4. 1.2. Propuesta .......................................................................................................................................... 5. 1.3. Estructura del documento ................................................................................................................ 5. CONTEXTO .......................................................................................................................................................... 6 2.1. Introducción ...................................................................................................................................... 6. 2.2. Integración de Datos ......................................................................................................................... 6. 2.3. Técnicas de Integración .................................................................................................................... 7. 2.4. Datos maestros ................................................................................................................................. 7. 2.5. Administración de datos maestros ................................................................................................... 8. 2.6. Arquitectura Dirigida por Modelos ................................................................................................. 10. 2.7. Common WareHouse Metamodel .................................................................................................. 10. 2.8. Ontologías ....................................................................................................................................... 11. CASO DE ESTUDIO ............................................................................................................................................ 12 3.1. Introducción .................................................................................................................................... 12. 3.2. Escenario ......................................................................................................................................... 12. 3.3. Bases de Datos ................................................................................................................................ 13. 3.3.1. AdventureWorks......................................................................................................................... 13. 3.3.2. AdventureWorksDW ................................................................................................................... 13. 3.3.3. HR ............................................................................................................................................... 14. 3.3.4. Clients ......................................................................................................................................... 14. 3.4. Entidades de Negocio Duplicadas ................................................................................................... 14. 3.5. Datos Maestros ............................................................................................................................... 17. 3.6. Complejidad Estimada (Mapeos - Componentes de Integración) .................................................. 18. Estrategia .......................................................................................................................................................... 19 4.1. Introducción .................................................................................................................................... 19. 4.2. Estrategia ........................................................................................................................................ 19.

(3) III. 4.2.1. Arquitectura de Datos Maestros ................................................................................................ 19. 4.2.2. CWM ........................................................................................................................................... 20. Propuesta ......................................................................................................................................................... 23 5.1. Introducción .................................................................................................................................... 23. 5.2. Proceso ........................................................................................................................................... 24. 5.2.1. P0 Definición del Metamodelo STMDM ..................................................................................... 24. 5.2.2. P1. Carga de información de las bases de datos relacionales al modelo STMDM ..................... 28. 5.2.3. P2. Carga de información de negocio al modelo STMDM .......................................................... 34. 5.2.4. P3. Conversión del modelo STMDM a ontologías ...................................................................... 35. 5.2.5. P4. Alineamiento de ontologías .................................................................................................. 39. 5.2.6. P5. Carga de los resultados del alineamiento al modelo STMDM .............................................. 41. 5.2.7. P6. Identificación y generación del modelo de datos maestros ................................................. 44. 5.2.8. P7. Generación de las transformaciones .................................................................................... 48. 5.2.9. Reportes ..................................................................................................................................... 52. Validación ......................................................................................................................................................... 53 6.1. Introducción .................................................................................................................................... 53. 6.2. Comparación de algoritmos de equivalencia semántica ................................................................ 53. 6.3. Análisis del modelo de datos maestros generado .......................................................................... 55. 6.3.1. Cliente ......................................................................................................................................... 56. 6.3.2. Empleado .................................................................................................................................... 56. 6.4. Comportamiento de STMDM al adicionar información de negocio ............................................... 57. 6.5. Comparación con herramientas comerciales ................................................................................. 59. 6.5.1. Microsoft .................................................................................................................................... 59. 6.5.2. Oracle ......................................................................................................................................... 60. 6.5.3. EBX5 – Orchestra Networks ........................................................................................................ 60. 6.5.4. Comparación............................................................................................................................... 60. Trabajo Relacionado ......................................................................................................................................... 62 7.1. Introducción .................................................................................................................................... 62. 7.2. Administración de Datos Maestros ................................................................................................. 62. 7.3. Alineamiento de Esquemas............................................................................................................. 63. Conclusiones ..................................................................................................................................................... 65 8.1. Conclusiones ................................................................................................................................... 65. 8.2. Trabajo Futuro ................................................................................................................................ 66. Referencias ....................................................................................................................................................... 68.

(4) IV. LISTA DE TABLAS Tabla 1: Actividades técnicas de una solución de datos maestros y herramientas de apoyo Tabla 2: Técnicas de integración Tabla 3: Algoritmos de alineamiento de ontologías Tabla 4: Características generales de AdventureWorks Tabla 5: Características generales de AdventureWorksDW Tabla 6: Características generales de HR Tabla 7: Características generales de CLIENTS Tabla 8: Entidades de negocio – Datos Maestros Tabla 9: Pasos de la solución Tabla 10: Resultados de la ejecución utilizando un umbral de 0.7 Tabla 11: Resultados de la ejecución utilizando un umbral de 0.85 Tabla 12: Dimensiones del modelo de datos maestros Tabla 13: Comparación de algoritmos al incluir información de negocio Tabla 14: Comparación de las relaciones detectadas para las entidades Customer y Address Tabla 15: Comparación de tecnologías. 4 7 11 13 14 14 14 18 23 54 54 56 58 58 61.

(5) V. LISTA DE FIGURAS Figura 1. Duplicación de información en las organizaciones 3 Figura 2. Metamodelo CWM. Tomado de [17] 11 Figura 3. Caso de Estudio – Escenario 13 Figura 4. Recursos humanos – AdventureWorks 15 Figura 5. Recursos humanos – Alpes 16 Figura 6. Clientes – AdventureWorks 16 Figura 7. Clientes – Alpes 17 Figura 8. Arquitectura de Datos Maestros 19 Figura 9. Modelo inicial 21 Figura 10. Modelo final 22 Figura 11. Estrategia de solución 22 Figura 12. Paquetes seleccionados del metamodelo CWM 24 Figura 13. Extensión del metamodelo Relational – Objeto Table 25 Figura 14. Diagrama de clases para el objeto STMDM 26 Figura 15. Extensión para soportar el almacenamiento de las alineaciones 27 Figura 16. Diagrama - P1. Carga de información de las bases de datos relacionales al modelo STMDM 28 Figura 17. Principales entidades cargadas a STMDM como resultado de P1 29 Figura 18. Modelo CWM al cargar la información de las bases de datos Oracle y SQL Server 33 Figura 19. Diagrama – P2. Carga de información del negocio al modelo STMDM 34 Figura 20. Asociación de concepto de negocio a modelo relacional 35 Figura 21. Diagrama – P3. Conversión del modelo STMDM a ontologías 35 Figura 22. Diagrama – P4. Alineamiento de ontologías 39 Figura 23. Ejemplo de alineamientos no simétricos 40 Figura 24. Diagrama – P5. Carga de los resultados del alineamiento al modelo STMDM 41 Figura 25. Visualización de la clase Alignment en el modelo STMDM 42 Figura 26. Diagrama – P6. Identificación y generación del modelo de datos maestros 44 Figura 27. Entidades cargadas a STMDM como resultado de P6 46 Figura 28. Resultado de P6 48 Figura 29. Diagrama – P7. Generación de las transformaciones 48 Figura 30. Entidades cargadas a STMDM como resultado de P7 49 Figura 31. Transformaciones generadas por la herramienta 50 Figura 32. Transformaciones generadas para la dimensión Customer 51 Figura 33. Transformaciones generadas para la dimensión Employee 57 Figura 34. Metamodelo de mapeo – Tomado de [9] 63.

(6) VI. LISTA DE ALGORITMOS Algoritmo 1. Carga del objeto DataTypes Algoritmo 2. Carga del objeto Resources Algoritmo 3. Carga de columnas Algoritmo 4. Carga de llaves primarias Algoritmo 5. Carga de llaves foráneas Algoritmo 6. Carga de relaciones entre llaves Algoritmo 7. Creación de archivos de ontología parcial Algoritmo 8. Creación de archivos de ontología completo Algoritmo 9. Método de alineamiento de ontologías Algoritmo 10. Estrategia de alineamiento Algoritmo 11. Carga de alineaciones al modelo (TableToTable) Algoritmo 12. Eliminación de alineaciones no simétricas (TableToTable) Algoritmo 13. Identificación de entidades candidatas Algoritmo 14. Generación de dimensiones – transformaciones Algoritmo 15. Generación de atributos de las dimensiones Algoritmo 16. Generación de transformaciones adicionales Algoritmo 17. Generación de transformaciones – Método de soporte. 30 30 31 31 32 32 37 38 40 41 43 43 45 46 47 50 51.

(7) VII.

(8) 1. RESUMEN La integración de múltiples fuentes de datos es uno de los mayores retos que afrontan las organizaciones actualmente. Una de las estrategias que más auge ha tenido en los últimos años para realizar esta integración es la administración de datos maestros. La parte tecnológica relacionada a la implementación de una solución de datos maestros requiere el conocimiento de las fuentes de datos, la búsqueda de equivalencias, la identificación de los datos maestros, la generación del repositorio centralizado y la implementación de los componentes de sincronización. En este artículo se presenta la herramienta STMDM, mediante la cual se soportan las tareas mencionadas anteriormente utilizando ingeniería basada en modelos. El proceso desarrollado en STMDM incluye el cargue de información hacia el modelo CWM extendido, la búsqueda de equivalencias utilizando ontologías y la definición de reglas para la identificación de los datos maestros. El resultado de la herramienta es un repositorio de datos maestros centralizado y los componentes de transformación modelados en CWM. Adicionalmente, la herramienta genera múltiples reportes que permiten la identificación de problemas/conflictos en la generación del repositorio o de los componentes de sincronización. Términos clave —CWM, Datos Maestros, Integración de datos, Metadatos, Metamodelos, Ontologías.

(9) 2. Capítulo I INTRODUCCIÓN Las organizaciones actuales poseen en su información uno de sus principales activos. Este hecho se presenta en los principios de datos de TOGAF [1] de la siguiente manera: “Los datos son un recurso organizacional importante; estos tienen un valor real y medible. … Los datos son la base de nuestras decisiones, por lo tanto debemos manejarlos cuidadosamente para garantizar que sabemos en donde están, si podemos confiar en ellos y los podemos obtener cuando y donde los necesitemos”. El hecho que los datos sean un activo organizacional, implica la necesidad de administrarlos correctamente y de garantizar que podemos confiar en los mismos. Para satisfacer estos requerimientos, en TOGAF se plantean otros principios que deben tener los datos organizacionales: los datos son compartidos, los datos son accesibles, los datos son confiables y existe un vocabulario/definiciones comunes. Debido a los cambios tecnológicos, y la continua evolución de los negocios, las organizaciones cada día van almacenando más información en sistemas heterogéneos, lo que genera problemas para realizar una correcta administración de la información y cumplir a cabalidad los principios de datos mencionados anteriormente. La heterogeneidad de las fuentes comúnmente conlleva a la duplicación de datos en los distintos sistemas de la organización. Un ejemplo de esta situación podría ser el cambio de enfoque de las organizaciones al pasar de un enfoque orientado al producto a un enfoque orientado al cliente. En esta situación los sistemas legados (enfoque producto) incluirían un sistema de información para cada uno de los productos y la información de los clientes podría estar distribuida en uno o más sistemas, dependiendo de los productos adquiridos. En el enfoque orientado al cliente, la organización requeriría una visión completa de cada uno de sus clientes, lo cual es complejo si se tienen en cuenta los distintos sistemas de información empresarial. En la figura 1 se presenta un ejemplo de la situación mencionada, en donde un cliente esta almacenado en dos sistemas de información legados y adicionalmente se encuentra en un sistema de administración de relación con el cliente (CRM, por sus siglas en ingles). En esta situación, la duplicidad de la información puede generar problemas de calidad, lo cual dificulta la visión 360° del cliente por parte de la organización..

(10) 3. Figura 1. Duplicación de información en las organizaciones. En un estudio reciente de TDWI [2] sobre datos maestros se muestra que la situación hipotética planteada en el ejemplo anterior es una realidad actual de las organizaciones. En el estudio mencionado, a la pregunta ¿Aproximadamente cuantas definiciones de cliente tiene su organización?, el 67% de los encuestados respondieron 5 o más (aproximadamente) y a la pregunta ¿Aproximadamente cuantas definiciones de producto tiene su organización?, el 66% de los encuestados respondieron 5 o más (aproximadamente). Las múltiples fuentes de información, y en muchos casos la heterogeneidad de las mismas, además de dificultar su administración generalmente conllevan a problemas de calidad de datos en las organizaciones. En [3] se plantea esta relación entre múltiples fuentes de información y problemas de calidad de datos de la siguiente manera: “aunque relativamente, sólo un pequeño grupo de objetos maestros son utilizados, existen múltiples maneras en las cuales estos objetos pueden ser nombrados, modelados, representados y almacenados”. Está demostrado que los problemas de calidad de datos impactan negativamente en la eficiencia de las organizaciones. En [4] se presentan algunas de las consecuencias de tener baja calidad de datos en las organizaciones, entre las cuales se incluyen impactos económicos y sociales cómo menor satisfacción del cliente, incremento en costos operacionales, toma de decisiones ineficiente, entre otros. Estos costos han sido cuantificados a partir de diversos estudios que se pueden visualizar en [4], [5]. Una de las cuantificaciones más relevantes se presenta en [4]: “Los problemas de calidad de datos le cuestan a las organizaciones entre el 20 -35% del ingreso operacional”. Para solucionar el problema de heterogeneidad de fuentes y calidad de datos, la integración de la información es uno de los principales retos que afrontan las organizaciones hoy en día. Los requerimientos de acceso a información consolidada y de calidad con propósitos operacionales o analíticos, generan la necesidad en las organizaciones de integrar las múltiples fuentes de datos disponibles, lo cual es una tarea compleja si se tienen en cuenta heterogeneidad de las mismas, y en muchos casos la falta de documentación..

(11) 4. Una de las disciplinas que ha tenido mayor adopción en los últimos años por parte de las organizaciones para solucionar el problema de integración de información es la administración de datos maestros (MDM, por sus siglas en inglés) [2], [3], [6]. Esta adopción se debe principalmente a la necesidad de las organizaciones de tener una única versión de la verdad de los datos maestros para evitar problemas de calidad de datos y de esta manera mejorar la eficiencia organizacional.. 1.1. PROBLEMA. En [3] se presentan las actividades de alto nivel necesarias para el desarrollo de una solución de datos maestros, las cuales son el inventario de los objetos de datos, la identificación de los datos maestros, la resolución de los conflictos semánticos, la estandarización de la información, la definición de reglas de integración y la definición de un framework de gobierno. Diversos proveedores tecnológicos como Microsoft, Oracle y Orchestra Networks; y algunos artículos investigativos como [7], [8], [9], plantean soluciones de administración de datos maestros enfocadas principalmente al proceso de administración/gobierno (administración de versiones, seguridad, acceso a la información, reglas de negocio) de los datos maestros, pero no plantean soluciones concretas en la parte de identificación de datos maestros, generación del modelo centralizado, ni mapeo entre los sistemas origen y el repositorio centralizado. En [10] se presentan algunos de los principales retos a nivel de datos para la implementación de una solución de datos maestros, entre los cuales están: “Los datos están en distintos formatos y no son confiables. Por esta razón la consolidación es lenta y costosa” “Definir los datos maestros es retante. Las definiciones de los datos difieren entre organizaciones“ Estos retos técnicos (a nivel de datos) que se presentan al implementar una solución de datos maestros se generan dado que comúnmente las actividades relacionadas se realizan de forma manual, o en el mejor de los casos de forma semiautomática y mediante herramientas diferentes, lo cual es costoso en tiempo y esfuerzo para las organizaciones. Un ejemplo de esta situación se presenta en la siguiente tabla: Actividad Inventario de los objetos de datos Identificación de los datos maestros Resolución de conflictos semánticos Definición del modelo de datos maestros Generación de componentes de integración. Herramientas de Apoyo Manual, InfoSphere (IBM) Manual Manual, Schema Matching, Ontologías Herramienta de MDM Scripts SQL, Código Ejecutable, Herramientas de ETL. Tabla 1: Actividades técnicas de una solución de datos maestros y herramientas de apoyo.

(12) 5. Adicionalmente el problema de realizar las actividades de manera manual/semiautomática y en herramientas diferentes se vuelve más difícil de resolver a medida que aumentan el número de sistemas de información y entidades de negocio. En la sección III del presente documento se realiza una ejemplificación del problema utilizando un caso de estudio.. 1.2. PROPUESTA. Para dar solución al problema establecido en el numeral anterior, se propone una solución basada en Ingeniería Dirigida por Modelos (MDE) que permite a través de diversas estrategias realizar las actividades técnicas relacionadas con una solución de datos maestros. La solución se basa en el metamodelo CWM (Common Warehouse Metamodel) definido por la OMG, el cual contiene los conceptos necesarios para modelar los sistemas fuentes, las transformaciones y el modelo de datos maestros. Una de las ventajas del metamodelo CWM, es que varios proveedores tecnológicos son compatibles con este metamodelo, lo que permite que aunque la solución planteada en este documento es independiente de la plataforma (PIM), esta pueda implementarse en múltiples herramientas tecnológicas. Para realizar la carga de la información de los sistemas fuentes al metamodelo CWM se utiliza un componente desarrollado en Java que se conecta a las fuentes de datos relacionales y carga la información al metamodelo. Para realizar la tarea de resolución de conflictos semánticos se utilizan técnicas de alineamiento de ontologías y para la identificación de los datos maestros se define un conjunto de reglas sobre los datos que permiten la definición automática del modelo de datos maestros. La solución planteada únicamente considera como fuentes de información aquellas bases de datos relacionales que se pueden acceder utilizando interfaces relaciones como ODBC ó JDBC, aunque puede ser extendida para soportar otro tipo de fuentes de información cómo archivos XML ó archivos planos, como se plantea en VIII.. 1.3. ESTRUCTURA DEL DOCUMENTO. En la sección II del documento se presenta un contexto general de los conceptos utilizados en el documento. En la sección III se presenta el caso de estudio. En la sección IV se presenta la estrategia de solución. En la sección V se desarrolla la propuesta del trabajo utilizando el caso de estudio. En la sección VI se presenta la validación de la propuesta. En la sección VII se presentan los trabajos relacionados y en la sección VIII se presentan las conclusiones y el trabajo futuro..

(13) 6. Capítulo II CONTEXTO 2.1. INTRODUCCIÓN. Esta sección presenta al lector el contexto requerido para comprender el presente documento. Los conceptos que se definen en esta sección incluyen la integración de datos, los datos maestros, la administración de datos maestros, la ingeniería dirigida por modelos, el metamodelo CWM y el alineamiento de ontologías.. 2.2. INTEGRACIÓN DE DATOS. La integración de datos se puede definir de múltiples formas de acuerdo a diferentes autores. Para algunos como Giordano [11], la integración de datos es “el conjunto de procedimientos, técnicas y tecnología utilizados para diseñar y construir procesos que extraen, transforman, mueven y cargan datos entre fuentes de datos operacionales y analíticas, en lotes (batch) o en tiempo real”. Otra posible definición de integración de datos, de acuerdo a Loshin [3] es: “la integración de datos comprende los procesos de recolección de datos de distintos orígenes, y la manera de hacerlos accesibles a diferentes aplicaciones”. Actualmente en la industria es común identificar la necesidad de integrar datos de diferentes fuentes con propósitos operacionales o analíticos. Uno de los principales problemas al momento de realizar la integración es la diversidad de las fuentes de datos. Esta diversidad conlleva a la falta de claridad respecto a los activos de información dentro de la organización, y esto genera incertidumbre al momento de obtener datos de calidad para la organización. Tendencias del mercado como Inteligencia de Negocios o Administración de datos Maestros, nos muestran la necesidad de las organizaciones de tener datos de calidad para utilizarlos en procesos operacionales o en procesos de toma de decisiones. La información almacenada en las organizaciones se puede clasificar en distintos dominios de acuerdo a las características y el uso de la misma. En [12] se presenta la siguiente calificación: • • •. Metadata: Información que describe las características los activos de información corporativos y otras entidades. Datos Maestros: Instancias de los datos que describen las entidades principales de negocio. Datos Operacionales: Datos estructurados creados o utilizados por las transacciones de negocio. Datos transaccionales que describen los hechos del negocio..

(14) 7. • •. 2.3. Datos no Estructurados: Datos con propósito operacional que son utilizados durante el funcionamiento del negocio (Contenido, correos, archivos) Datos Analíticos: Resultado de colocar los datos operacionales junto a los datos maestros en un contexto analítico.. TÉCNICAS DE INTEGRACIÓN. Tecnológicamente, los problemas de integración de datos se resuelven utilizando patrones arquitecturales o técnicas como EII (Enterprise Information Integration) ó ETL (Extract, Transform and Load). Cada uno de los patrones de integración se enmarca en una de las siguientes técnicas: consolidación, federación o propagación [13]. Las principales características de cada una de las técnicas se resumen en la siguiente tabla: Técnica Consolidación. Federación Propagación. Descripción Extraer los datos de múltiples fuentes e integrarlos en un repositorio persistente Realizar la creación de una vista virtual (no persistente) de los datos Realizar la sincronización de los cambios entre las distintas fuentes de información en tiempo real. Ejemplo Bodegas de datos, procesos de ETL, ODS EII ESB, EAI. Tabla 2: Técnicas de integración. Estas técnicas de integración en algunos casos requieren la modificación de los sistemas originales para su correcto funcionamiento. Una técnica de integración se considera intrusiva si es necesario modificar los sistemas originales para realizar la integración. Un ejemplo de técnicas intrusivas es la federación, en donde al crear la vista virtual los aplicativos deben cambiar su conexión de la fuente de datos original a la vista virtual. En una técnica no intrusiva no es necesario modificar los sistemas originales de la organización, con lo cual se garantiza la continuidad de la operación sobre los productos actuales y se puede generar valor adicional mediante un sistema externo. Entre los ejemplos de soluciones no intrusivas encontramos los ODS (Operational Data Store), las bodegas de datos y los repositorios de datos maestros.. 2.4. DATOS MAESTROS. Los datos maestros de acuerdo con [3], son “los objetos principales de negocio utilizados en distintas aplicaciones a través de la organización, junto con su metadata asociada, atributos, definiciones, roles, conexiones y taxonomía”. En [6] se definen como “los datos que han sido.

(15) 8. limpiados, racionalizados e integrados en un sistema de registro para las principales actividades organizacionales”. En general, los datos maestros se pueden definir como las entidades de negocio que se utilizan en múltiples procesos de una organización. Los datos maestros más trabajados en las organizaciones al momento de implementar soluciones de MDM son los clientes (Customer Data Integration) y los productos. En [14] se definen tres dominios de maestros que son comunes en las organizaciones: individuos/organizaciones, cosas y ubicaciones. En el dominio de individuos/organizaciones algunos ejemplos son los clientes, los proveedores, los empleados, los pacientes y los ciudadanos. En el dominio de cosas algunos ejemplos son los productos, los servicios, los procesos. Y en el dominio de ubicaciones algunos ejemplos son regiones, departamentos y ciudades. Algunas características de los datos maestros de acuerdo con [3], [10], [14], son: •. •. •. •. •. 2.5. Existen independientemente: Los datos maestros existen de manera independiente a otros objetos de datos. Por ejemplo un cliente existe en los repositorios de información sin necesidad de tener otro objeto de datos asociado, mientras un registro transaccional como una venta, no puede existir si no esta definido el cliente. Son referenciados por otros objetos de datos: Los datos maestros en general se utilizan como referencia en sistemas transaccionales y analíticos. Como se planteó en el ejemplo anterior, un registro transaccional como una venta referencia múltiples datos maestros como el cliente y el producto. Presentan baja frecuencia de cambios: Los datos maestros no cambian tan frecuentemente como los datos transaccionales y la cantidad de registros permanece relativamente constante. Por ejemplo, la información de un producto no cambia frecuentemente y el número de productos crece relativamente poco comparado con la información de un dato transaccional (ventas). Representan un objeto del mundo real: Los datos maestros describen las características básicas de un objeto del mundo real, por ejemplo para un cliente algunos de los atributos básicos son el nombre y la identificación Son referenciados en múltiples procesos de negocio: Un dato maestro en general es referenciado por múltiples procesos de negocio. Por ejemplo la entidad cliente puede ser referenciada en los procesos de mercadeo y en ventas.. ADMINISTRACIÓN DE DATOS MAESTROS. La administración de datos maestros (MDM, por sus siglas en inglés) se define como “el conjunto de procesos y herramientas que permite definir y administrar consistentemente las entidades de negocio (datos maestros) de una organización” [3]. En [6] se define como un “framework de procesos y tecnologías dirigido a crear y mantener un ambiente de datos autoritativo, confiable, sostenible, preciso y seguro que represente una única versión de la verdad, y es aceptado como un sistema de registro utilizado por un conjunto diverso de sistemas y líneas de negocio”..

(16) 9. En las organizaciones los datos maestros generalmente existen en más de un sistema de información de la organización, por ejemplo un cliente puede existir en el sistema de ventas y en el sistema de facturación. Adicionalmente, estos datos maestros en cada sistema pueden estar modelados de manera diferente, lo que genera un reto al momento de realizar la integración de la información. La implementación de una solución de datos maestros administración de datos maestros en una organización se puede dividir en dos partes: tecnológica y gobierno. En la parte tecnológica se define la infraestructura que va a soportar la administración y se realizan las tareas técnicas de integración y sincronización de la información. En la parte de gobierno de datos, se realiza la definición de reglas, políticas y responsables para la administración de los datos maestros. De acuerdo con Loshin [3], las tareas de alto nivel necesarias para una solución de datos maestros son: • • • • • •. Inventario de los objetos de datos Identificación de los datos maestros Resolución de conflictos semánticos Estandarización de la información Definición de reglas de integración Framework de gobierno de información. La identificación de los datos maestros de acuerdo con [3] se puede realizar utilizando dos estrategias diferentes. La primer estrategia es una búsqueda top-down a partir de los procesos de negocio de la organización, en donde se realiza la identificación de los objetos de datos críticos para la correcta ejecución de los procesos. La segunda estrategia es una búsqueda bottom-up a partir de las fuentes de datos organizacionales para la identificación de objetos de datos que se puedan considerar datos maestros. En [3] se plantean las siguientes estrategias arquitecturales para una solución de datos maestros: •. •. •. Índice virtual de datos maestros: Estrategia en la cual se genera un registro mínimo de datos maestros y a partir de este, se generan consultas sobre los sistemas de origen. El registro incluye los mínimos atributos necesarios para identificar la entidad de negocio, y las llaves de cada sistema para poder acceder los atributos adicionales a partir de consultas. Repositorio centralizado: Estrategia en la cual se centralizan los datos maestros en un repositorio centralizado. El repositorio para cada entidad de negocio, debe incluir todos los atributos existentes en las fuentes originales. Hibrida: Estrategia que mezcla un índice virtual para algunos atributos de las entidades de negocio dentro de un repositorio centralizado..

(17) 10. 2.6. ARQUITECTURA DIRIGIDA POR MODELOS. La arquitectura dirigida por modelos (MDA) es la realización de la ingeniería basada en modelos alrededor de un conjunto de estándares definidos por la OMG (Object Management Group) como MOF (Meta Object Facility), XMI (XML Metadata Interchage) [15]. En la ingeniería basada en modelos las entidades de primer nivel son los modelos, lo que permite mejorar el ciclo de vida de la especificación, arquitectura, diseño, desarrollo, despliegue, mantenimiento e integración de las tecnologías de información por medio de un modelado formal [16]. Una de las principales características de la arquitectura dirigida por modelos es la capacidad de modelar los conceptos fundamentales de un problema en términos independientes de la plataforma, lo que facilita el entendimiento de los conceptos a modelar. Adicionalmente, utilizando técnicas de transformación de modelos y transformaciones de modelo a texto, es posible convertir los modelos independientes de las plataformas (PIM) en modelos dependientes de la plataforma (PSM) y en código ejecutable.. 2.7. COMMON WAREHOUSE METAMODEL. Uno de los metamodelos definidos por OMG (Object Management Group) para el manejo de metadata es CWM (Common Warehouse Metamodel). El principal objetivo de este metamodelo es permitir el intercambio de metadata entre herramientas, plataformas y repositorios de bodegas de datos en ambientes heterogéneos [17]. Aunque CWM esta diseñado para el intercambio de metadata para soluciones de bodegas de datos, los conceptos principales pueden ser utilizados para soluciones similares como la administración de datos maestros. Una de las características relevantes del metamodelo CWM es que este es soportado y aceptado por múltiples proveedores tecnológicos de soluciones de bodegas de datos, lo que permite su implementación en múltiples plataformas tecnológicas. El metamodelo CWM esta basado en un conjunto de paquetes (Figura 2) que permiten modelar las distintas características de una solución de bodega de datos. Utilizando los paquetes disponibles es posible modelar las fuentes de datos relacionales, las fuentes XML, los cubos OLAP y la nomenclatura de negocio. En el capítulo IV se presenta mayor detalle sobre los paquetes con los cuales se trabajará en la solución..

(18) 11. Figura 2. Metamodelo CWM. Tomado de [17]. 2.8. ONTOLOGÍAS. Una ontología es un término adquirido de la filosofía que hace referencia a la ciencia de describir las clases de entidades en el mundo y sus relaciones [18]. Las ontologías son comúnmente utilizadas para facilitar la capacidad de comunicación al establecer un vocabulario común. Uno de los lenguajes que permite definir e instanciar ontologías es el OWL Ontology Language, definido por el grupo W3C. Este lenguaje de definición e instanciación de ontologías permite realizar consultas y generar conocimiento adicional, aprovechando la comprensión semántica de las entidades y sus relaciones. Dada las características semánticas de las ontologías, estas se pueden utilizar para facilitar la integración de distintos sistemas heterogéneos. El alineamiento de ontologías es la actividad que permite encontrar las correspondencias y equivalencias entre distintas entidades de dos ontologías diferentes. La descripción de los algoritmos de alineamiento más comunes se presenta en la siguiente tabla: Algoritmo. Descripción. EQUAL. Identificación de cadenas idénticas. HAMMING. Número mínimo de sustituciones requeridas para transformar una cadena en otra. LEVENSHTEIN NGRAM SMOA WORDNET. Número mínimo de manipulaciones (insertar, eliminar, remplazar - un carácter) necesarias para transformar una cadena en otra Comparación de los n-gramas similares entre dos cadenas Distancia especializada para alineamiento de ontologías Distancia basada en Wordnet (diccionario de sinónimos en inglés) Tabla 3: Algoritmos de alineamiento de ontologías.

(19) 12. Capítulo III CASO DE ESTUDIO 3.1. INTRODUCCIÓN. Esta sección muestra al lector el caso de estudio con el cual se realizó la implementación y validación del presente trabajo de investigación. El escenario con el cual se trabajó es un escenario ficticio, que se construye a partir de las bases de datos de ejemplo que vienen con los motores de bases de datos Microsoft SQL Server y Oracle. Adicional a estas bases de datos de ejemplo, se define una base de datos que permite mostrar algunas capacidades relevantes de la solución. Dadas las características de la solución planteada en el presente documento, en el caso de estudio se omite la información de procesos de negocio relacionados a la organización. Utilizando este caso de estudio en el capítulo V se detalla la propuesta de la solución. 3.2. ESCENARIO. Una de las situaciones que generalmente resultan en problemas de calidad de datos es la fusión de compañías. Para simular esta fusión se construye un escenario en el cual es necesario integrar dos compañías las cuales utilizan dos motores relacionales diferentes, en este caso SQL Server y Oracle. La compañía 1 (AdventureWorks) posee una base de datos OLTP llamada AdventureWorks, la cual incluye información de 5 procesos de negocio: recursos humanos, clientes, producción, compras y ventas. Adicionalmente esta compañía tiene una bodega de datos llamada AdventureWorksDW. La compañía 2 (Alpes) posee dos esquemas OLTP en los cuales se almacena la información de recursos humanos (HR) y la información de clientes (CLIENTS). Al momento de fusionar las compañías, se presentan algunos problemas de duplicación de información que se detallan más adelante, lo que genera la necesidad de implementar una solución de administración de datos maestros. En la figura 3 se presenta una visualización de los motores relaciones, sus bases de datos y sus esquemas..

(20) 13. Figura 3. Caso de Estudio - Escenario. 3.3. BASES DE DATOS. 3.3.1 ADVENTUREWORKS AdventureWorks (Base de datos de ejemplo de Microsoft SQL Server) es una base de datos. transaccional que contiene los esquemas HumanResources, Person, Production, Purchasing y Sales. Cada uno de estos esquemas almacena información relacionada a distintas áreas de negocio de la compañía. A continuación se presentan las características relevantes de cada esquema: Esquema HumanResources Person Production Purchasing Sales. # Tablas # Columnas 7 44 6 41 25 166 8 75 22 151. Tabla 4: Características generales de AdventureWorks. 3.3.2 ADVENTUREWORKSDW AdventureWorksDW (Base de datos de ejemplo de Microsoft SQL Server) es una bodega de datos que contiene el esquema dbo. Dentro de este esquema se almacenan las dimensiones y los hechos de la bodega de datos. En total existen 7 tablas de hechos y 16 tablas de dimensiones. Las tablas.

(21) 14. de hechos se pueden identificar por el prefijo Fact, y las tablas de dimensiones por el prefijo Dim. A continuación se presentan las características del esquema: Esquema dbo. # Tablas # Columnas 23. 298. Tabla 5: Características generales de AdventureWorksDW. 3.3.3 HR HR (Esquema de ejemplo de Oracle) es un esquema transaccional que soporta el área de recursos humanos de una organización. Dentro de este esquema existen 7 tablas que incluyen información de empleados, departamentos, países, regiones y trabajos. A continuación se presentan las características del esquema: Esquema HR. # Tablas # Columnas 7. 35. Tabla 6: Características generales de HR. 3.3.4 CLIENTS Clients es un esquema definido en Oracle para soportar el manejo de clientes. Dentro de este esquema, algunas de las tablas presentan nombres no naturales (por ejemplo S2502) para nombrar algunos conceptos. A continuación se presentan las características del esquema: Esquema CLIENTS. # Tablas # Columnas 3. 9. Tabla 7: Características generales de CLIENTS. 3.4. ENTIDADES DE NEGOCIO DUPLICADAS. Al realizarse la fusión de las compañías AdventureWorks y Alpes, aparecen dos áreas de negocio duplicadas (recursos humanos y clientes), y es necesario tener una única visión de estas áreas. Cada uno de los esquemas de las áreas maneja conceptos diferentes y el objetivo es unificar estos conceptos en un repositorio centralizado a través de la herramienta STMDM. A continuación se presentan los esquemas de cada una de las áreas mencionadas:.

(22) 15. Figura 4. Recursos humanos - AdventureWorks.

(23) 16. Figura 5. Recursos humanos – Alpes. Figura 6. Clientes - AdventureWorks.

(24) 17. Figura 7. Clientes – Alpes. En los diagramas de cada una de las tablas se pueden observar distintas estrategias de modelamiento para cada una de las áreas de negocio. Por ejemplo en AdventureWorks la relación entre el empleado y el departamento es indirecta, mientras en Alpes se presenta una relación directa. En el caso del área de clientes la base de datos de AdventureWorks incluye llaves foráneas para garantizar la integridad referencial, mientras en Alpes no se tiene ninguna llave foránea definida. Otra característica que se puede visualizar en los diagramas es la definición del teléfono para los clientes: en AdventureWorks es una columna de la tabla Contact, mientras en Alpes los teléfonos se almacenan en la tabla Phones, que relaciona a cada cliente con su teléfono. Para el caso de las direcciones de los clientes, en Alpes estas se encuentran almacenadas en la tabla S2502, lo que genera una dificultad al momento de encontrar las equivalencias semánticas. Entre los distintos esquemas existen múltiples diferencias, que no se nombran en detalle debido a su extensión. Adicionalmente a la necesidad de integrar las áreas de recursos humanos y clientes de la compañía, la implementación de datos maestros debe tener en cuenta la bodega de datos AdventureWorksDW, la cual tiene por su característica de bodega de datos, tiene un modelamiento diferente a los sistemas OLTP, lo que implica otro reto al momento de implementar el sistema de datos maestros.. 3.5. DATOS MAESTROS. Teniendo en cuenta las entidades de negocio existentes en los distintos modelos, en total se tendrían 8 objetos mínimos a considerar como datos maestros. Estos objetos se presentan en la siguiente tabla:.

(25) 18. Entidad Account Currency Customer Department Employee Product SalesTerritory Location Tabla 8: Entidades de negocio – Datos Maestros. 3.6. COMPLEJIDAD ESTIMADA (MAPEOS - COMPONENTES DE INTEGRACIÓN). Las características del escenario nos presentan la necesidad de mapear 4 bases de datos diferentes con el repositorio centralizado de datos maestros. Para ejemplificar la complejidad de la solución, a continuación se van a presentar los mapeos y componentes de integración necesarios para las entidades Cliente y Producto. Cliente: Para los clientes es necesario realizar el mapeo de 3 fuentes de datos: AdventureWorks (15 columnas), AdventureWorksDW (29 columnas) y CLIENTS (5 columnas) con el repositorio de datos maestros para la entidad cliente (38 columnas). En total serían necesarios realizar 98 mapeos ((15 + 29 + 5)*2) en el peor de los casos. Adicionalmente serían necesarios generar 3 componentes de integración desde los orígenes hacia los repositorios y 3 componentes de integración desde el repositorio hacia los orígenes. Producto: Para los productos es necesario realizar el mapeo de 2 fuentes de datos: AdventureWorks (6 tablas, 52 columnas) y AdventureWorksDW (3 tablas, 46 columnas) con el repositorio de datos maestros para la entidad producto (1 tabla, 46 columnas). En total serían necesarios realizar 196 mapeos ((52 + 46)*2) en el peor de los casos. Adicionalmente serían necesarios generar 2 componentes de integración desde los orígenes hacia los repositorios y 2 componentes de integración desde el repositorio hacia los orígenes. Si utilizamos una estrategia manual para realizar el mapeo únicamente para las entidades cliente y producto, tendríamos que realizar 294 mapeos y generar 10 componentes de integración de manera manual. Dependiendo de la estrategia utilizada para generar los componentes de integración (Scripts SQL, ETL) el costo de generar estos componentes podría llegar a ser bastante alto. Utilizando este caso de estudio simple y ficticio, se puede observar la complejidad del problema para 4 fuentes de datos..

(26) 19. Capítulo IV ESTRATEGIA 4.1. INTRODUCCIÓN. Esta sección pretende ilustrar la estrategia de solución utilizada por la herramienta STMDM para la implementación de una solución de datos maestros. La estrategia de solución se plantea utilizando una arquitectura de datos maestros tipo repositorio centralizado. Adicionalmente esta se basa en la instanciación incremental de 4 paquetes del metamodelo CWM teniendo en cuenta únicamente las características de las fuentes relacionales (bottom – up). 4.2. ESTRATEGIA. 4.2.1 ARQUITECTURA DE DATOS MAESTROS Entre las dos arquitecturas posibles para la implementación de una solución de datos maestros definidas en el contexto, la solución planteada utiliza la arquitectura de repositorio centralizado dado que esta permite tener un repositorio centralizado con una visión completa de los datos maestros. Adicionalmente esta estrategia permite solucionar problemas de calidad de datos y definir reglas de negocio sobre el repositorio centralizado.. Figura 8. Arquitectura de Datos Maestros. En la solución planteada únicamente se consideran las fuentes de datos relacionales como orígenes de información, aunque aprovechando las características del metamodelo CWM es posible extender la solución para incluir otro tipo de fuentes cómo archivos XML. La estrategia de solución adicionalmente únicamente utiliza las fuentes de datos relacionales para realizar la identificación de los datos maestros (bottom - up) y no tiene en cuenta los procesos de negocio..

(27) 20. 4.2.2 CWM La herramienta STMDM esta basada en la instanciación incremental del metamodelo CWM. Este fue seleccionado debido a que es un estándar de la industria definido desde hace más de 8 años, y aunque esta diseñado para el trabajo de bodegas de datos, muchos de los conceptos aplican para múltiples técnicas de integración de la información. Adicionalmente, este metamodelo es independiente de la plataforma tecnológica pero esta soportado por múltiples proveedores. Otra característica del metamodelo es que es fácilmente extensible, lo que permite incluir conceptos adicionales, que son útiles para las tareas de búsqueda de equivalencias, identificación de los datos maestros y generación del repositorio centralizado, pero no afectarían la conversión a un metamodelo dependiente de la plataforma (PSM). Los paquetes de CWM que se utilizan en la herramienta STMDM son: •. •. •. •. Paquete relacional: Describe los datos que son accesibles a través de interfaces relacionales como RDBMS, ODBC ó JDBC. Este paquete incluye los principales conceptos de las bases de datos como las tablas, columnas, llaves primarias y llaves foráneas entre otros, lo que permite definir en el modelo las principales características de las bases de datos. Paquete de nomenclatura de negocio: Describe las relaciones entre los conceptos de negocio a través de glosarios y taxonomías. Este paquete se utiliza en STMDM para agregar conocimiento en la búsqueda de equivalencias a través de conceptos de negocio, y sus posibles relaciones con objetos del paquete relacional. Paquete OLAP: Describe las estructuras multidimensionales utilizadas para los análisis OLAP. Se selecciono este paquete para modelar el repositorio centralizado, dado que incluye el concepto de dimensión (OLAP), que en la práctica es equivalente al concepto de dato maestro. La principal diferencia entre las dimensiones, y una tabla de un esquema relacional, es que las primeras permiten la definición de jerarquías, lo cual es relevante en una implementación de datos maestros. Paquete de transformaciones: El paquete de transformaciones permite modelar un proceso de ETL. Debido a la complejidad de las transformaciones, se selecciono esta estrategia dado que en general, las herramientas tecnológicas que la implementan presentan interfaces visuales que facilitan la evolución y la mantenibilidad de los ejecutables.. Las actividades de apoyo para la implementación de una solución de datos maestros realizadas por la herramienta STMDM son: • • • • •. Inventario de las fuentes de datos Búsqueda de equivalencias Identificación de los datos maestros Generación del repositorio centralizado Implementación de los componentes de integración.

(28) 21. STMDM genera una implementación incremental del modelo conforme a CWM, siguiendo los pasos mencionados anteriormente. El modelo inicia con la definición de un objeto STMDM (extensión a CWM) que permite relacionar múltiples paquetes dentro del modelo (Figura 9).. Figura 9. Modelo inicial. En el primer paso del proceso, se realiza la carga automática de información de las bases de datos en la relación Resources del metamodelo. Esta relación permite tener múltiples esquemas almacenados para el objeto STMDM. El segundo paso del proceso, es opcional y consiste en la carga manual de información del negocio (Objeto BusinessNomenclature del metamodelo) y sus relaciones con los objetos relacionales. Una de las características relevantes de la herramienta STMDM es la posibilidad de realizar esta carga manual de información, lo que facilita la identificación de relaciones semánticas que no son deducibles a partir de las fuentes de datos. El tercer paso del proceso consiste en realizar la conversión automática del metamodelo relacional y el metamodelo de nomenclatura de negocio a ontologías. El cuarto paso de la propuesta es realizar las tareas de alineamiento y búsqueda de equivalencias. STMDM utiliza el alineamiento de ontologías como estrategia de búsqueda de equivalencias dada la capacidad de esta técnica de alineamiento para identificar relaciones entre conceptos. El quinto paso es cargar los resultados del alineamiento en el modelo STMDM. A partir de los resultados del paso anterior, en el sexto paso se realiza la identificación de los datos maestros utilizando un conjunto de reglas predefinidas y se crean el modelo de los datos maestros en el objeto MasterDataModel. Como último paso se generan las transformaciones entre los modelos definidos en el objeto Resources y el repositorio centralizado definido en el objeto MasterDataModel. Las transformaciones se generan utilizando como base la trazabilidad generada durante el proceso. El resultado final de la ejecución de la herramienta (Figura 10), es el modelo STMDM completamente definido con la descripción de las fuentes relacionales, la nomenclatura de negocio, las alineaciones detectadas, el repositorio centralizado y las transformaciones..

(29) 22. Figura 10. Modelo final. En la figura 11 se plantea un esquema de la estrategia de solución, en donde se visualizan los pasos presentados anteriormente y la relación con el modelo STMDM. En el siguiente capítulo, se presenta con mayor detalle la implementación de cada uno de los pasos del proceso.. Figura 11. Estrategia de solución.

(30) 23. Capítulo V PROPUESTA 5.1. INTRODUCCIÓN. Como se planteó en el capítulo anterior, la estrategia de solución planteada en STMDM consta de siete pasos (sin contar la definición del metamodelo) que permiten apoyar a una organización en la implementación de una solución de datos maestros (Figura 11). Un resumen de cada uno de los pasos se presenta en la tabla 9. En esta sección se presenta el detalle de la implementación de cada uno estos pasos, utilizando como base el caso de estudio. Tipo Actividad. Herramientas tecnológicas. P0. Definición del metamodelo STMDM. Manual. P1. Carga de información de las bases de datos relacionales al modelo STMDM. Automática. P2. Carga de información de negocio al modelo STMDM P3. Conversión del modelo STMDM a ontologías. Manual. P4. Alineamiento de ontologías. Automática. AlignApi -4.3. P5. Carga de los resultados del alineamiento al modelo STMDM P6. Identificación y generación del modelo de datos maestros P7. Generación de las transformaciones. Automática. Eclipse Modeling Framework (Manipulación de objetos Java) Eclipse Modeling Framework (Manipulación de objetos Java) Eclipse Modeling Framework (Manipulación de objetos Java). Automática. Automática Automática. Tabla 9: Pasos de la solución. Eclipse Modeling Tools - Helios Service Release 1 JDBC, Eclipse Modeling Framework (Manipulación de objetos Java) Eclipse Modeling Tools - Helios Service Release 1 Acceleo Model To Text Transformation Language (MTL) - 3.0.

(31) 24. 5.2. PROCESO. 5.2.1 P0 DEFINICIÓN DEL METAMODELO STMDM La herramienta de soporte para la creación de una solución de datos maestros (STMDM) se basa en la implementación incremental de un modelo conforme a CWM, por lo cual el paso cero de la solución consiste en definir el metamodelo a trabajar. La definición del metamodelo CWM otorgada por OMG esta basada en UML. Para poder trabajar con Eclipse Modeling Tools como plataforma base de la herramienta STMDM, se obtuvo una implementación del metamodelo en EMF del repositorio de inria forge (https://gforge.inria.fr/scm/viewvc.php/integration/examples/BasicDemo_projects/?root=opene mbedd). A partir del metamodelo original de CWM, se genera un metamodelo reducido que únicamente incluye los paquetes necesarios de CWM para la solución de datos maestros. Estos paquetes son ObjectModel, Foundation, Relational del paquete Resource y Transformation, Olap y BusinessNomenclature del paquete Analysis. En la siguiente imagen se presentan los paquetes utilizados del metamodelo CWM en la herramienta STMDM:. Figura 12. Paquetes seleccionados del metamodelo CWM. 5.2.1.1. E XTENSIONES AL M ETAMODELO CWM. Para soportar la funcionalidad de la herramienta STMDM, es necesario extender el metamodelo en algunos de sus paquetes para incluir información adicional que es necesaria en los siguientes pasos de la solución. Las extensiones al metamodelo se presentan a continuación:.

(32) 25. 5.2.1.1.1. E XTENSIÓN AL P AQUETE R ELATIONAL. Con el fin de mejorar el proceso de búsqueda de equivalencias semántica y facilitar las etapas posteriores de la estrategia, se extiende el paquete CWM Relational para soportar dos atributos adicionales: FullName y OriginalName en los objetos Catalog, Schema, Table y Column. La propiedad OriginalName permite almacenar el nombre original de los objetos y la propiedad FullName permite tener la jerarquía de nombres para todos los objetos (ej. Para una tabla la jerarquía es <NombreCatalogo>.<NombreEsquema>.<NombreTabla>). La extensión del metamodelo CWM Relational se visualiza de la siguiente manera para el objeto Table. Figura 13. Extensión del metamodelo Relational – Objeto Table. 5.2.1.1.2. D EFINICIÓN DE C ONTENEDOR STMDM. Para relacionar los distintos paquetes del metamodelo CWM se define la clase STMDM como contenedora de los objetos relevantes del paquete CWM. Estos objetos se almacenan utilizando referencias (EReference) desde la clase STMDM a los siguientes objetos del metamodelo CWM: • • •. Resources: Define la relación con los distintos catálogos (paquete Relational) que representan las fuentes relacionales BusinessNomenclature: Define la relación con los conceptos de nomenclatura de negocio (paquete Business Nomenclature) MasterDataModel: Define la relación con el modelo de datos maestros (concepto Schema del paquete OLAP). Adicionalmente se definen las clases Transformations y DataTypes, las cuales se utilizan como contenedor de las relaciones hacia los objetos de transformación y de tipo de datos. Estas referencias son: DataType: Define la relación con los tipos de datos para las fuentes relacionales (concepto SQLDataType del paquete Relational) Transformation: Define la relación con las transformaciones existentes en el modelo (concepto Transformation del paquete Transformation).

(33) 26. En la siguiente imagen se presenta el diagrama de clases con las principales relaciones de la clase STMDM hacia los objetos del paquete CWM y hacia las clases DataTypes y Transformations definidas anteriormente.. Figura 14. Diagrama de clases para el objeto STMDM. 5.2.1.1.3. E XTENSIÓN PARA SOPORTAR EL ALMACENAMIENTO DE LAS A LINEACIONES. Para incluir los conceptos de alineamiento en el modelo, se define la clase Alignment, la cual permite almacenar los resultados del alineamiento de ontologías en el modelo. Esta clase incluye las referencias a los objetos relacionados (ModelElement) del cual heredan los conceptos que se buscan alinear (Table, Column) e incluye las características de la relación (confianza y tipo). Los posibles tipos de relación entre objetos se definen en la enumeración AlignmentType, en donde se encuentran las siguientes relaciones: Table_Table: Permite representar la relación de equivalencia entre dos tablas a partir de los nombres Table_Column: Permite representar la relación de equivalencia entre una tabla y una columna a partir de los nombres.

(34) 27. Column_Column: Permite representar la relación de equivalencia entre dos columnas a partir de los nombres Column_Table: Permite representar la relación de equivalencia entre una columna y una tabla a partir de los nombres El objeto Alignment definido en el modelo (Figura 15) referencia dos objetos relacionados entre sí. Esta relación tiene un origen (object1) y un destino (object2), por lo cual para que una relación entre dos objetos sea válida, es necesario definir las relaciones en ambos sentidos, lo que se llamará de ahora en adelante una relación simétrica (atributo symmetric). Para garantizar la navegabilidad del modelo se extienden las clases Table y Column del paquete CWM Relational para referenciar las relaciones a las que pertenecen cada uno de los objetos (referencia Alignment de la figura 15) Adicionalmente, para relacionar la clase STMDM definida en el numeral anterior con las alineaciones existentes en el modelo, desde la clase STMDM se crea la clase Alignments la cual funciona como contenedor de las relaciones (concepto Alignment), como se puede observar en la figura 14.. Figura 15. Extensión para soportar el almacenamiento de las alineaciones.

(35) 28. 5.2.1.2. M ANIPULACIÓN DEL M ODELO. La implementación de los pasos P1, P5, P6 y P7 de la solución, está basada en la creación y manipulación de objetos Java generados mediante el API de Eclipse Modeling Framework (EMF). A través de este API se manipula el modelo conforme al metamodelo STMDM planteado en el numeral anterior, de tal forma que sea posible implementar incrementalmente el modelo. Para realizar esta manipulación, se utilizan las siguientes clases generadas a partir del metamodelo: CwmFactory: Clase que permite crear los objetos pertenecientes al metamodelo Cwm (extensión STMDM) RelationalFactory: Clase que permite crear los objetos pertenecientes al metamodelo Relational OlapFactory: Clase que permite crear los objetos pertenecientes al metamodelo Olap TransformationFactory: Clase que permite crear los objetos pertenecientes al metamodelo Transformation. 5.2.2 P1. CARGA DE INFORMACIÓN DE LAS BASES DE DATOS RELACIONALES AL MODELO STMDM 5.2.2.1. D IAGRAMA. Figura 16. Diagrama - P1. Carga de información de las bases de datos relacionales al modelo STMDM.

(36) 29. 5.2.2.2. D ESCRIPCIÓN. La primera actividad que realiza la herramienta STMDM es la carga de la información de manera automática de las bases de datos al modelo STMDM. Para realizar esta actividad se define un ejecutable en Java el cual lee la información de las bases de datos y la carga en un modelo conforme al metamodelo STMDM. El paquete relational dentro de STMDM es el destino de la carga de información. Dentro de este, se realiza la carga de los conceptos Catalog, Schema, Table, Column, CheckConstraint, SQLSimpleType, PrimaryKey, ForeignKey, UniqueConstraint y Unique Key. En la figura 17 se pueden observar las principales entidades cargadas al modelo como resultado de P1 (Las relaciones entre los objetos del metamodelo relational son heredadas del metamodelo core).. Figura 17. Principales entidades cargadas a STMDM como resultado de P1. El algoritmo utilizado para cargar la información de las bases de datos relacionales al modelo STMDM esta basado en el algoritmo propuesto en el capítulo cinco de [19]. Este algoritmo se modifica teniendo en cuenta la herramienta de desarrollo de STMDM (Eclipse Modeling Framework) y algunos conceptos faltantes en la implementación. Como se mencionó en al final de la sección anterior (5.2.1.2), la manipulación del modelo se realiza utilizando el API de Eclipse Modeling Framework (EMF) y modificando el modelo XML Metadata Interchange (XMI) a través del lenguaje de programación Java. Para el acceso a las bases de datos se utiliza la interfaz JDBC y se aprovechan las características de la interfaz java.sql.DatabaseMetaData para extraer la información de los sistemas relacionales. Para los motores de bases de datos SQL Server y Oracle.

(37) 30. se generó una implementación de la herramienta, que tiene como diferencia los conceptos de catalogo y esquema entre las bases de datos. Adicionalmente, para cada motor se identifican las tablas del sistema para excluirlas del proceso de carga de información. Los pasos generales del algoritmo se presentan a continuación:. Algoritmo 1. Carga del objeto DataTypes. En el algoritmo 1 se puede visualizar la carga del objeto de datos DataTypes, en el cual se almacenan los tipos de datos existentes en los objetos relacionales (SQLSimpleType) mediante la relación DataType. Para la creación de los objetos del modelo STMDM se utilizan las fábricas CwmFactory y RelationalFactory. La complejidad del algoritmo es O(k) ≈ O(1), en donde k es el número de tipos de datos definidos en el motor relacional.. Algoritmo 2. Carga del objeto Resources.

(38) 31. En el algoritmo 2 se puede visualizar la carga del objeto resources del modelo STMDM. Para realizar la carga se recorren los catálogos de las fuentes de datos, para cada catálogo se recorren los esquemas, para cada esquema se recorren las tablas y para cada tabla se recorren las columnas, las llaves primarias y las llaves foráneas. En el algoritmo se puede visualizar la creación de los distintos objetos utilizando la fábrica rFactory y la definición de relaciones entre los objetos.. Algoritmo 3. Carga de columnas. En el algoritmo 3 se puede visualizar la carga de las columnas y su asociación con los tipos de datos cargados previamente en el modelo. Para cada columna se carga su nombre modificado, su nombre original, el tipo de dato y el soporte a valore nulos de la columna.. Algoritmo 4. Carga de llaves primarias.

(39) 32. Algoritmo 5. Carga de llaves foráneas. En los algoritmos 4 y 5 se puede visualizar la carga de llaves primarias y de llaves foráneas para cada una de las tablas. Cada una de las llaves, incluye entre sus características una relación a las columnas asociadas mediante el atributo feature. En el algoritmo 6 se puede visualizar la relación entre las llaves foráneas y las llaves primarias. Esta relación permite asignar a cada llave foránea su llave primaria correspondiente, y a cada llave primaria las llaves foráneas que la referencian. La carga de las relaciones entre llaves foráneas y llaves primarias (algoritmo 6) se realiza posteriormente a la carga de todas las llaves primarias y foráneas para garantizar que los objetos a relacionar existan en el modelo.. Algoritmo 6. Carga de relaciones entre llaves. La complejidad del algoritmo de carga de los objetos resources del modelo STMDM con todos sus atributos (algoritmos 2, 3, 4, 5, 6) es O(c * s * t * col * pKey2 * fKey2 ), en donde c es el número de catálogos a cargar, s es el número de esquemas a cargar, col es el número de columnas a cargar, pKey es el número de llaves primarias y fKey es el número de llaves foráneas..

(40) 33. El algoritmo utilizado al momento de cargar los nombres de los objetos Catalog, Schema, Table y Column al modelo STMDM aplica las siguientes reglas con el objetivo de mejorar la búsqueda de equivalencias semánticas: •. •. Supresión de palabras: El algoritmo busca en el nombre de los objetos alguna palabra comodín que se encuentra definida en un archivo xml. Esta supresión permite eliminar palabras como Fact o Dim que son comunes en implementaciones de bodegas de datos para que no interfieran en la búsqueda de equivalencias. Separación de palabras: El algoritmo considera como dos palabras diferentes los nombres que estén separados mediante un guion ( _ - ). Por ejemplo, el algoritmo convierte la palabra Customer_name en la palabra CustomerName. El resultado de este paso para el caso de estudio se puede ver en la figura 18, en donde se pueden observar los catálogos cargados en el sistema, y en el caso del catálogo HR se observan las tablas cargadas, y para la tabla COUNTRIES, se observan las columnas, las llaves primarias y las llaves foráneas.. Figura 18. Modelo CWM al cargar la información de las bases de datos Oracle y SQL Server.

(41) 34. 5.2.3 P2. CARGA DE INFORMACIÓN DE NEGOCIO AL MODELO STMDM 5.2.3.1. D IAGRAMA. Figura 19. Diagrama – P2. Carga de información del negocio al modelo STMDM. 5.2.3.2. D ESCRIPCIÓN. Una de las características relevantes que incluye la herramienta STMDM es la posibilidad de incluir información adicional en el análisis de equivalencias. En algunas situaciones es posible que los algoritmos de alineamiento no logren identificar las relaciones existentes entre objetos de múltiples fuentes. Un posible ejemplo de esta situación se presenta si existen tablas almacenadas en la base de datos cuyos nombres son genéricos cómo en el caso de estudio la tabla S2502 (Direcciones de los clientes) del esquema CLIENTS. En este caso, ningún algoritmo de equivalencia semántica va a lograr identificar a partir del nombre de la tabla la relación con otras fuentes de información. Otro caso similar en el caso de estudio se presenta con las tablas Customer y Client, en donde la relación entre los dos conceptos es difícil de detectar con un nivel de confianza adecuado utilizando algoritmos de alineamiento. La posibilidad de incluir información adicional en el análisis se basa en el metamodelo CWM business nomenclature (BN) para incluir conceptos de negocio a través de glosarios y taxonomías. El metamodelo BN permite definir conceptos y relacionarlos con objetos del metamodelo relational, aunque esta relación no es obligatoria. Para el caso de la tabla nombrada S2502, es posible definir el termino Address en el modelo BN y relacionarlo con el objeto tabla del modelo relational. De esta manera, la búsqueda de equivalencias en pasos posteriores va a analizar el objeto S2502 utilizando su nombre, y adicionalmente utilizando el concepto definido en el modelo de nomenclatura de negocio. Para el caso de la relación entre las tablas Customer y Client es.

(42) 35. posible definir estos términos en el modelo BN y relacionarlos entre sí utilizando la relación Related Term definida en CWM. La definición de la información de negocio en el modelo STMDM se realiza utilizando el modelo resultante de P1. En la siguiente figura se puede visualizar la asociación del concepto Address a la tabla S2502 del modelo (atributo Model Element) y la relación entre los términos Customer y Client.. Figura 20. Asociación de concepto de negocio a modelo relacional. Es importante resaltar que la carga de información de negocio al modelo STMDM es una actividad opcional que busca complementar la información disponible en las bases de datos relacionales. Pero entre más completo este el modelo de nomenclatura de negocio se espera que los resultados de la búsqueda de equivalencias sean más acordes con la realidad.. 5.2.4 P3. CONVERSIÓN DEL MODELO STMDM A ONTOLOGÍAS 5.2.4.1. D IAGRAMA. Figura 21. Diagrama – P3. Conversión del modelo STMDM a ontologías.