stmdm una herramienta de soporte para la implementación de
TRANSCRIPT
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
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
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
IV
LISTA DE TABLAS
Tabla 1: Actividades técnicas de una solución de datos maestros y herramientas de apoyo 4
Tabla 2: Técnicas de integración 7
Tabla 3: Algoritmos de alineamiento de ontologías 11
Tabla 4: Características generales de AdventureWorks 13
Tabla 5: Características generales de AdventureWorksDW 14
Tabla 6: Características generales de HR 14
Tabla 7: Características generales de CLIENTS 14
Tabla 8: Entidades de negocio – Datos Maestros 18
Tabla 9: Pasos de la solución 23
Tabla 10: Resultados de la ejecución utilizando un umbral de 0.7 54
Tabla 11: Resultados de la ejecución utilizando un umbral de 0.85 54
Tabla 12: Dimensiones del modelo de datos maestros 56
Tabla 13: Comparación de algoritmos al incluir información de negocio 58
Tabla 14: Comparación de las relaciones detectadas para las entidades Customer y Address 58
Tabla 15: Comparación de tecnologías 61
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
VI
LISTA DE ALGORITMOS
Algoritmo 1. Carga del objeto DataTypes 30
Algoritmo 2. Carga del objeto Resources 30
Algoritmo 3. Carga de columnas 31
Algoritmo 4. Carga de llaves primarias 31
Algoritmo 5. Carga de llaves foráneas 32
Algoritmo 6. Carga de relaciones entre llaves 32
Algoritmo 7. Creación de archivos de ontología parcial 37
Algoritmo 8. Creación de archivos de ontología completo 38
Algoritmo 9. Método de alineamiento de ontologías 40
Algoritmo 10. Estrategia de alineamiento 41
Algoritmo 11. Carga de alineaciones al modelo (TableToTable) 43
Algoritmo 12. Eliminación de alineaciones no simétricas (TableToTable) 43
Algoritmo 13. Identificación de entidades candidatas 45
Algoritmo 14. Generación de dimensiones – transformaciones 46
Algoritmo 15. Generación de atributos de las dimensiones 47
Algoritmo 16. Generación de transformaciones adicionales 50
Algoritmo 17. Generación de transformaciones – Método de soporte 51
VII
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
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.
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.
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 Herramientas de Apoyo
Inventario de los objetos de datos Manual, InfoSphere (IBM)
Identificación de los datos maestros Manual
Resolución de conflictos semánticos Manual, Schema Matching, Ontologías
Definición del modelo de datos maestros Herramienta de MDM
Generación de componentes de integración Scripts SQL, Código Ejecutable, Herramientas de ETL
Tabla 1: Actividades técnicas de una solución de datos maestros y herramientas de apoyo
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.
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.
7
• 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.
2.3 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 Descripción Ejemplo
Consolidación Extraer los datos de múltiples
fuentes e integrarlos en un
repositorio persistente
Bodegas de datos,
procesos de ETL, ODS
Federación Realizar la creación de una vista
virtual (no persistente) de los datos
EII
Propagación Realizar la sincronización de los
cambios entre las distintas fuentes
de información en tiempo real
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
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:
• 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.
2.5 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”.
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.
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.
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 Número mínimo de manipulaciones (insertar, eliminar, remplazar - un carácter) necesarias para transformar una cadena en otra
NGRAM Comparación de los n-gramas similares entre dos cadenas
SMOA Distancia especializada para alineamiento de ontologías
WORDNET Distancia basada en Wordnet (diccionario de sinónimos en inglés) Tabla 3: Algoritmos de alineamiento de ontologías
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.
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 # Tablas # Columnas
HumanResources 7 44
Person 6 41
Production 25 166
Purchasing 8 75
Sales 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
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 # Tablas # Columnas
dbo 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 # Tablas # Columnas
HR 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 # Tablas # Columnas
CLIENTS 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:
15
Figura 4. Recursos humanos - AdventureWorks
16
Figura 5. Recursos humanos – Alpes
Figura 6. Clientes - AdventureWorks
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:
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.
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.
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
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.
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
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 Eclipse Modeling Tools - Helios
Service Release 1
P1. Carga de información de las bases de datos
relacionales al modelo STMDM
Automática JDBC, Eclipse Modeling Framework
(Manipulación de objetos Java)
P2. Carga de información de negocio al modelo
STMDM
Manual Eclipse Modeling Tools - Helios
Service Release 1
P3. Conversión del modelo STMDM a ontologías Automática Acceleo Model To Text
Transformation Language (MTL) - 3.0
P4. Alineamiento de ontologías Automática AlignApi -4.3
P5. Carga de los resultados del alineamiento al
modelo STMDM
Automática Eclipse Modeling Framework
(Manipulación de objetos Java)
P6. Identificación y generación del modelo de datos
maestros
Automática Eclipse Modeling Framework
(Manipulación de objetos Java)
P7. Generación de las transformaciones Automática Eclipse Modeling Framework
(Manipulación de objetos Java)
Tabla 9: Pasos de la solución
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 EXTENSIONES AL METAMODELO 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:
25
5.2.1.1.1 EXTENSIÓN AL PAQUETE RELATIONAL
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 DEFINICIÓN DE CONTENEDOR 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)
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 EXTENSIÓN PARA SOPORTAR EL ALMACENAMIENTO DE LAS ALINEACIONES
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
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
28
5.2.1.2 MANIPULACIÓN DEL MODELO
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 DIAGRAMA
Figura 16. Diagrama - P1. Carga de información de las bases de datos relacionales al modelo STMDM
29
5.2.2.2 DESCRIPCIÓ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
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
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
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.
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
34
5.2.3 P2. CARGA DE INFORMACIÓN DE NEGOCIO AL MODELO STMDM
5.2.3.1 DIAGRAMA
Figura 19. Diagrama – P2. Carga de información del negocio al modelo STMDM
5.2.3.2 DESCRIPCIÓ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
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 DIAGRAMA
Figura 21. Diagrama – P3. Conversión del modelo STMDM a ontologías
36
5.2.4.2 DESCRIPCIÓN
Para realizar la actividad de búsqueda de equivalencias semánticas es necesario realizar la
conversión del modelo STMDM a ontologías. La herramienta que se utiliza para realizar esta
conversión de modelo a texto es Acceleo, en donde mediante una transformación de modelo a
texto se generan las ontologías correspondientes (Una por cada modelo relational extendido con
las relaciones a BN en caso que existan).
Dadas las características de la solución, la búsqueda de equivalencias semánticas a nivel de
ontologías no requiere que estas se definan completamente (En [20], [21], [22] se presentan
algunas estrategias para realizar el mapeo de un motor de base de datos relacional a ontologías).
Por esta razón únicamente se mapean los conceptos de tabla y columna, utilizando los nombres
modificados. El mapeo se realiza utilizando el algoritmo que se presenta a continuación, en donde
cada esquema se convierte en una ontología, cada tabla se convierte en una clase y cada atributo
se convierte en una propiedad de tipo de dato. Adicionalmente, si la tabla esta relacionada con
algún término del modelo de nomenclatura de negocio, o el nombre de la tabla tiene términos
asociados, estos se incluyen como subclases de la tabla asociada.
37
Algoritmo 7. Creación de archivos de ontología parcial
38
Algoritmo 8. Creación de archivos de ontología completo
En el algoritmo 7 se presenta la creación de archivos de ontología parciales, los cuales incluyen
únicamente la información de las tablas (Class) y la información del modelo de nomenclatura de
negocio. Estos archivos son generados con el prefijo Partial para su identificación posterior. En el
algoritmo 8 se presenta la creación de archivos de ontología completos, los cuales incluyen las
tablas y las columnas (DataTypeProperty) del modelo STMDM. Estos archivos se generan con el
prefijo Full para su identificación posterior. Los algoritmos 7 y 8 recorren los catálogos del modelo
STMDM a partir de la relación resources, y posteriormente se recorren los esquemas, las tablas y
las columnas (únicamente algoritmo 8) para generar las ontologías. La división de los archivos de
ontología resultantes en parciales y completos se realiza para facilitar el alineamiento en el
siguiente paso de la solución.
39
5.2.5 P4. ALINEAMIENTO DE ONTOLOGÍAS
5.2.5.1 DIAGRAMA
Figura 22. Diagrama – P4. Alineamiento de ontologías
5.2.5.2 DESCRIPCIÓN
Al tener las ontologías definidas se aplican técnicas de alineamiento utilizando la herramienta
AlignApi – 4.3, la cual se puede descargar en la siguiente ruta (http://alignapi.gforge.inria.fr/). Esta
herramienta que se detalla en [23], permite la comparación de dos ontologías utilizando distintos
algoritmos. Para el uso de la herramienta, se genera un ejecutable que llama al API de
alineamiento con las distintas ontologías.
En el algoritmo 9 se visualiza el llamado al API de alineamiento desde la herramienta STMDM. En
la implementación se pueden visualizar los siete tipos de algoritmos de comparación (EQUAL,
HAMMING, LEVENSHTEIN, NGRAM, SMOA, SUBSTRING, WORDNET) disponibles en la herramienta
AlignApi y que fueron implementados en STMDM. La búsqueda de equivalencias semánticas se
realiza utilizando el tipo de búsqueda (“?*”), que genera las relación entre un objeto de la
ontología de origen y un objeto de la ontología destino, pero permite que un mismo objeto del
destino este asociado a múltiples objetos del origen. Este tipo de búsqueda le otorga al usuario la
posibilidad de visualizar las relaciones no simétricas generadas por la herramienta. Un ejemplo de
estas relaciones se presenta en la figura 23, en donde la tabla DimProduct tiene equivalencias
semánticas con múltiples tablas del origen (Product, ProductPhoto, ProductReview,
ProductModel), pero solo existe una relación simétrica entre DimProduct y Product.
40
Algoritmo 9. Método de alineamiento de ontologías
Figura 23. Ejemplo de alineamientos no simétricos
La ejecución las alineaciones utilizando los archivos OWL de ontologías se realiza en dos etapas. En
la primera fase se utilizan las ontologías parciales (únicamente tablas + nomenclatura de negocio),
con lo que se busca otorgar una mayor prioridad al tipo de equivalencias Tabla - Tabla. Esta
prioridad se genera al comparar semánticamente los objetos de tipo tabla, sin tener en cuenta las
columnas para la búsqueda de equivalencias. En la segunda etapa se incluyen las ontologías
completas (tablas y columnas) para evaluar los demás tipos de equivalencia (Columna – Columna,
Tabla – Columna, Columna - Tabla).
41
Algoritmo 10. Estrategia de alineamiento
En el algoritmo 10 se visualiza la implementación de la solución, en donde se recorren los archivos
de ontología parciales, y para cada par de archivos diferentes se invoca el método de alineamiento
de ontologías. Posteriormente se recorren los archivos de ontologías completas y se realiza una
invocación similar. La complejidad de los algoritmos de comparación es O( 2 * f1 * (f1-1)) ≈ O( 2 *
f12 ) en donde f1 es el número de archivos de ontologías de entrada o el número total de
esquemas de las bases de datos a analizar (9 en el caso de estudio).
5.2.6 P5. CARGA DE LOS RESULTADOS DEL ALINEAMIENTO AL MODELO STMDM
5.2.6.1 DIAGRAMA
Figura 24. Diagrama – P5. Carga de los resultados del alineamiento al modelo STMDM
42
5.2.6.2 DESCRIPCIÓN
El quinto paso de la herramienta STMDM carga los resultados del alineamiento al modelo STMDM
utilizando la extensión definida en P0. Para realizar la carga se recorren los resultados del
alineamiento de P4 y se crean los objetos Alignment dentro del modelo con sus relaciones
respectivas. El proceso incremental de implementación del modelo STMDM en P5 genera las
clases presentadas en la figura 15. El concepto Alignment incluye el tipo de relación, la confianza,
el objeto de origen y el objeto de destino. En la figura 25 se pueden visualizar estos conceptos
para un ejemplo del caso de estudio, en donde se carga una relación de tipo Table-Table entre las
tablas ProductDescription y Product, con una confianza de 0.868.
Figura 25. Visualización de la clase Alignment en el modelo STMDM
Los resultados de las equivalencias de P4 (objetos JAVA) se recorren, y mediante manipulaciones
del objeto XMI se cargan al modelo utilizando el algoritmo 11, en donde primero se realiza un
recorrido sobre los objetos de tipo Cell (Align-Api), los cuales almacenan las alineaciones
existentes y dependiendo del tipo de objeto alineado (c.getObject1().getClass()) se identifica el
tipo de relación y se crean los objetos Alignment y sus relaciones a partir de la fabrica
CwmFactory.
43
Algoritmo 11. Carga de alineaciones al modelo (TableToTable)
El algoritmo 11 presenta la carga para las alineaciones de tipo TableTable. Los algoritmos para
cargar las alineaciones TableColumn, ColumnColumn y ColumnTable utilizan una lógica similar, en
donde se modifican los objetos de comparación resultantes de la ontología (OWLClass por
OWLDataProperty). En este punto el modelo STMDM incluye las alineaciones detectadas, sin
importar si estas son o no simétricas. Para identificar las alineaciones simétricas existentes en el
modelo (alineaciones relevantes para la identificación de datos maestros) se implementa el
algoritmo 12, en el cual se recorren las alineaciones existentes y se modifica el atributo symmetric
de cada una de las alineaciones en caso que estas sean simétricas.
Algoritmo 12. Eliminación de alineaciones no simétricas (TableToTable)
44
La complejidad de los algoritmos de carga de los resultados de alineamiento al modelo STMDM es
O(2a + a2 ), en donde a es el número de alineaciones no simétricas detectadas por la herramienta.
El valor de a depende del algoritmo de alineamiento utilizado, y en el caso de estudio para
umbrales de 0.7 y 0.85 este valor se varía entre 480 y 1244.
5.2.7 P6. IDENTIFICACIÓN Y GENERACIÓN DEL MODELO DE DATOS MAESTROS
5.2.7.1 DIAGRAMA
Figura 26. Diagrama – P6. Identificación y generación del modelo de datos maestros
5.2.7.2 DESCRIPCIÓN
A partir de los resultados de las alineaciones y de las relaciones entre los esquemas relacionales es
posible realizar la identificación de los datos maestros. En el contexto se presentan las
características comunes de los datos maestros, y para la identificación se tienen en cuenta las
siguientes reglas:
Un dato maestro se utiliza en múltiples procesos y aplicaciones de negocio, por lo cual un
objeto del modelo candidato a dato maestro debe tener por lo menos un alineamiento
con otro objeto del modelo.
Un dato maestro es referenciado por otros objetos de datos, por lo cual un objeto del
modelo candidato a dato maestro debe ser referenciado directa o indirectamente por otra
tabla del modelo.
Estas reglas se implementan en la herramienta utilizando el algoritmo 13, en el cual se recorren los
catálogos, los esquemas y las tablas del modelo relacional. En caso de que la tabla tenga una o
más alineaciones simétricas relacionadas, esta se tiene en cuenta para validar la segunda regla.
Sobre las tablas con una o más alineaciones, se buscan las llaves primarias que sean referenciadas
directamente por otras llaves foráneas. En caso que la tabla sea referencia por una o más llaves
foráneas, esta pasa a ser candidata a dato maestro. Adicionalmente el algoritmo realiza la
búsqueda de las tablas que son referenciadas por otras tablas sin la existencia de llaves foráneas
45
entre las mismas. Estas tablas también se consideran candidatas a ser datos maestros. La
complejidad del algoritmo de identificación de datos maestros es O(c * s * t * col * pKey ), 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 y pKey es el número de llaves primarias.
Algoritmo 13. Identificación de entidades candidatas
La implementación incremental del modelo STMDM en P6 añade al modelo los conceptos
Dimension y Attribute del paquete CWM olap. Cada dato maestro identificado se define como una
dimensión y sus atributos son la unión de los atributos definidos en los modelos relational
asociados. Para la definición del repositorio centralizado se escogió el paquete CWM olap dado
que los conceptos de este paquete presentan equivalencias con los conceptos de una solución de
datos maestros. Más específicamente, las dimensiones de un modelo OLAP son equivalentes a las
entidades de negocio de una solución de datos maestros. En la figura 27 se visualizan las clases
adicionadas el modelo STMDM y sus relaciones como resultado de P6. (La relación entre los
atributos y las dimensiones es heredada del metamodelo core).
46
Figura 27. Entidades cargadas a STMDM como resultado de P6
Para generar las dimensiones del modelo de datos maestros se utiliza el algoritmo 14, en donde a
partir de la fábrica OlapFactory se crean los las dimensiones utilizando la siguiente lógica: Las
entidades relacionadas se cargan una sola vez en el modelo, para lo cual cada una de las tablas
candidatas se recorre junto con sus tablas relacionadas, y en caso que no haya sido creada como
dimensión previamente, se crea. Por ejemplo si la dimensión Department se carga a partir de la
tabla AdventureWorks.HumanResources.Department, y esta se encuentra alineada con la tabla
HR.dbo.DEPARTMENTS, la búsqueda de alineaciones definida en el algoritmo permite identificar
que estas dos tablas son equivalentes y realiza la carga una única vez.
Algoritmo 14. Generación de dimensiones – transformaciones
La generación de los atributos de las dimensiones se presenta en el algoritmo 15, en donde
primero se cargan todos los atributos de la entidad directamente relacionada (en el ejemplo
anterior los atributos de la tabla HumanResources.Department) y posteriormente se navegan las
tablas asociadas, y para cada una se cargan sus atributos, teniendo en cuenta que estos no estén
47
relacionados con los atributos ya cargados en el modelo. La complejidad del algoritmo de
generación de dimensiones es O (tC * tR), en donde tC es el número de entidades candidatas, y tR
es el total de tablas alineadas con las entidades candidatas. La complejidad del algoritmo de
generación de atributos es O (d * col + d * tR * colR1 * colR2) en donde d es el número de
dimensiones, col es el número de columnas de la tabla directamente relacionada, tR es el total de
tablas alineadas con las dimensiones, colR1 es el total de columnas de las tablas tR y colR2 es el
total de columnas alineadas con las columnas colR1.
Algoritmo 15. Generación de atributos de las dimensiones
El resultado final de la carga de los atributos para el ejemplo del caso de estudio se presenta en la
figura 28, en donde se puede observar que la dimensión Department, únicamente incluye las
columnas no alineadas de las tablas asociadas. En este caso, la columna DEPARTMENTID de la
tabla HR.dbo.DEPARTMENTS no se incluye en el modelo resultante dado que esta se encuentra
alineada con un atributo existente en el modelo (DepartmentID) cargado a partir de la tabla
AdventureWorks.HumanResources.Department. Una situación similar se presenta para la
dimensión Employee, en donde de la tabla HR.dbo.EMPLOYEES únicamente se cargan las columnas
JOBID y COMMISSIONPCT, las cuales no se encuentran definidas en las demás tablas asociadas.
48
Figura 28. Resultado de P6
5.2.8 P7. GENERACIÓN DE LAS TRANSFORMACIONES
5.2.8.1 DIAGRAMA
Figura 29. Diagrama – P7. Generación de las transformaciones
5.2.8.2 DESCRIPCIÓN
En el último paso de la generación incremental del modelo STMDM se añaden los conceptos
Transformation, TransformationMap, ClassifierMap, FeatureMap y ClassifierFeatureMap del
paquete CWM transformation al modelo STMDM. Estos conceptos permiten generar las
transformaciones entre las entidades del metamodelo relational y las entidades del metamodelo
olap. Se seleccionaron las transformaciones del estilo ETL como mecanismo para generar la
49
sincronización de las fuentes relaciones con el modelo de datos maestros debido a la facilidad que
estas ofrecen a los usuarios para la administración y mantenibilidad de las mismas. Estos paquetes
de transformación, posteriormente pueden ser implementados en herramientas visuales que
permiten observar el flujo de información y no se convierten en archivos SQL o archivos de código
que no son fácilmente administrables por los usuarios. En la figura 30 se presentan las clases
generadas por la herramienta STMDM como resultado de P7.
Figura 30. Entidades cargadas a STMDM como resultado de P7
La herramienta STMDM genera automáticamente las transformaciones en ambos sentidos entre
los modelos relacionales y el modelo OLAP. Las transformaciones en el sentido relacional a OLAP
pueden presentar conflictos de prioridad en la información. Esto es un mismo concepto puede
estar definido en el esquema 1 y en el esquema 2, y en el modelo de datos maestros solo aparece
una vez, por lo cual es necesario identificar la versión de la verdad. Esta tarea se debe realizar de
manera manual por parte del usuario, y para esto se extiende el metamodelo Transformation en
las clases ClassifierMap, FeatureMap y ClassifierFeatureMap añadiendo el atributo primarySource
de tipo boolean. De esta manera el usuario puede definir la relación válida entre múltiples
orígenes y un destino. Adicionalmente en caso que el mapeo sea entre tablas y columnas, es
necesario definir por parte del usuario la expresión asociada. A la transformación en el sentido
OLAP a relacional, no se le deben definir ninguna prioridad dado que el mapeo es 1 a 1. En la
siguiente figura se presenta un ejemplo conceptual de las transformaciones generadas por la
herramienta.
50
Figura 31. Transformaciones generadas por la herramienta
La generación de las transformaciones se realiza en dos etapas. En la primera etapa se definen las
transformaciones entre tablas y dimensiones, y en la segunda etapa se definen las
transformaciones entre columnas y atributos. Una parte de la primera etapa se incluye en el
algoritmo de generación del modelo de datos maestros (14), en donde para cada dimensión
generada se crean las relaciones con la tabla directamente relacionada. En el ejemplo para la
dimensión Department, esta primera parte de la etapa crea la relación entre la tabla
AdventureWorks.HumanResources.Department y la dimensión Department utilizando la clase
ClassifierMap. Las transformaciones entre las tablas alineadas (HR.dbo.DEPARTMENTS) y la
dimensión se crean utilizando el siguiente algoritmo:
Algoritmo 16. Generación de transformaciones adicionales
51
La creación de los objetos del metamodelo transformation se realiza utilizando el algoritmo 17, el
cual a partir de la fabrica TransformationFactory, crea los clases requeridas para la transformación
con sus respectivas asociaciones.
Algoritmo 17. Generación de transformaciones – Método de soporte
Un ejemplo de las transformaciones detectadas por la herramienta para el caso de estudio se
presenta a continuación, en donde se pueden visualizar la relación entre la dimensión Customer y
las tablas asociadas en la parte izquierda de la imagen. En la parte derecha se presentan las
transformaciones generadas por la herramienta entre las columnas de cada una de las fuentes
relacionales y los atributos de la dimensión Customer.
Figura 32. Transformaciones generadas para la dimensión Customer
52
5.2.9 REPORTES
Al tener el modelo STMDM completo con todos los conceptos definidos en este capítulo, es
posible generar reportes utilizando transformaciones de modelo a texto (Acceleo). En la figura 32
se presentan dos reportes generados por la herramienta utilizando una transformación desde el
modelo STMDM hacia archivos html. Estos reportes permiten al usuario analizar los resultados
que entrega la herramienta para su posible implementación posterior en herramientas
tecnológicas. Adicional al reporte de relaciones entre dimensiones y tablas, y atributos y
columnas, con la información almacenada en el modelo se pueden generar reportes de conflictos
(tipos de dato, valores nulos) entre las distintas transformaciones.
53
Capítulo VI
VALIDACIÓN
6.1 INTRODUCCIÓN
Esta sección pretende ilustrar las estrategias de validación de la propuesta planteada en el
documento. Dado que no es posible comparar la ejecución de la herramienta contra herramientas
similares, se plantean dos estrategias de validación. El primer modo de validación consiste en
analizar los resultados de la herramienta STMDM utilizando distintos algoritmos de alineamiento
de ontologías, y detallar dos casos particulares del caso de estudio para observar los resultados de
la misma. El segundo modo de validación consiste en realizar una comparación de características
funcionales de la herramienta STMDM contra las características funcionales de las herramientas
comerciales, basado en los documentos públicos que estas ofrecen.
6.2 COMPARACIÓN DE ALGORITMOS DE EQUIVALENCIA SEMÁNTICA
El objetivo de la validación presentada en esta sección es comparar los resultados de la ejecución
de los pasos P4, P5, P6 y P7 de la herramienta STMDM, utilizando diferentes algoritmos de
alineamiento de ontologías. La comparación de los resultados busca identificar la sensibilidad de la
solución con respecto a los distintos algoritmos de alineamiento, y para cada uno de estos,
comparar la calidad del modelo de datos maestros resultante y la complejidad de las
transformaciones resultantes (número de transformaciones y número de mapeos).
Los resultados que se presentan en esta sección fueron generados utilizando una máquina con las
siguientes características:
Procesador Intel Core i7. Q 740 @ 1.73 GHz
Máquina virtual en Hyper-V con dos procesadores lógicos asociados
Memoria RAM: 2.14 GB
Eclipse Modeling Tools – Version Helios Service Release 1
WordNet 2.0
La primera estrategia de validación de la herramienta STMDM consiste en generar los resultados
de los pasos P4, P5, P6 y P7 utilizando distintas variables para el alineamiento de ontologías. Para
esto, se hace uso de la implementación del paso P4 (algoritmo 9), la cual soporta siete tipos de
algoritmos de comparación y permite modificar el umbral del algoritmo. A continuación se
presentan los resultados comparativos para los umbrales 0.7 y 0.85:
54
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
El tiempo (segundos) que se presenta como resultado de la ejecución en las tablas anteriores,
incluye los pasos P4 – P7 de la herramienta, los cuales aportan la mayor parte al tiempo total de
ejecución. Para el caso del algoritmo WORDNET*, la comparación parcial (únicamente tablas) se
realizó utilizando este algoritmo y la comparación completa (tablas y columnas) se realizó
utilizando el algoritmo SMOA, debido el alto tiempo de ejecución (mayor a 30 min) del algoritmo
WORDNET al incluir las columnas en la comparación.
En los resultados presentados se puede observar la complejidad del análisis para un caso de
estudio ficticio como el planteado en este documento. El total de alineamientos resultantes entre
tablas y columnas varía de 430 a 1244, dependiendo de los parámetros utilizados. Esta cantidad de
alineamientos detectados, utilizando umbrales significativamente altos (0.7, 0.85) permite
visualizar el total de equivalencias semánticas en el caso de estudio analizado. La columna
relaciones de las tablas presentadas anteriormente permite identificar el número de equivalencias
reales (simétricas) existentes entre los modelos (215 - 399).
Las columnas entidades candidatas y dimensiones permiten ver el efecto de los parámetros
utilizados en el modelo resultante. Entre las entidades candidatas a ser datos maestros se puede
observar que el caso de estudio otorga entre 16 y 30 entidades a partir del análisis de la
herramienta, que pueden llegar a ser datos maestros. De estas entidades se seleccionan entre 9 y
16 dimensiones que conforman el modelo resultante. Una característica interesante de los
resultados, es la proporción entre Dimensiones y Entidades Candidatas, la cual oscila entre 0.52 y
0.56, lo que indica que por cada 10 entidades candidatas, se generan 5 o 6 dimensiones para el
caso de estudio.
AlgoritmoAlineamientos
NO simétricos
Alineamientos
SimétricosRelaciones
Entidades
CandidatasDimensiones Atributos Transformaciones Mapeos
Tiempo
(seg)
EQUAL 430 430 215 16 9 173 36 398 24,1
HAMMING 516 502 251 21 11 193 46 474 23,4
LEVENSHTEIN 566 530 265 21 11 192 46 486 23,6
NGRAM 577 514 257 25 13 230 56 572 23,2
SMOA 1244 798 399 30 16 279 80 744 27,2
SUBSTRING 642 556 278 25 14 237 64 588 21,4
WORDNET* 1204 782 391 25 14 234 66 612 162,6
AlgoritmoAlineamientos
NO simétricos
Alineamientos
SimétricosRelaciones
Entidades
CandidatasDimensiones Atributos Transformaciones Mapeos
Tiempo
(seg)
EQUAL 430 430 215 16 9 173 36 398 22,3
HAMMING 449 448 224 21 11 198 46 472 22,0
LEVENSHTEIN 449 448 224 21 11 198 46 472 24,3
NGRAM 457 450 225 21 11 197 46 472 23,4
SMOA 705 584 292 25 14 234 64 592 24,8
SUBSTRING 472 466 233 21 11 197 46 472 22,4
WORDNET* 675 570 285 21 11 193 48 492 157,1
55
Una de las principales características de la herramienta STMDM es la generación de componentes
de transformación (ETL) de manera automática a nivel del metamodelo. De acuerdo a los
resultados en total son necesarias mínimo 36 transformaciones y 398 mapeos, lo que muestra la
utilidad de la generación automática de estos componentes, principalmente si se tiene en cuenta
que la mayoría de estas transformaciones se realizan comúnmente utilizando herramientas de
modelamiento visual como SQL Server Integration Services u Oracle Data Integrator.
El efecto de aumentar el umbral de los algoritmos de alineamiento, reduce parcialmente la
complejidad del modelo resultante. Al incrementar el umbral de 0.7 a 0.85, los tres primeros
algoritmos (EQUAL, HAMMING, LEVENSHTEIN) no se ven afectados por el cambio, pero los
algoritmos restantes tienen una reducción de la complejidad (dimensiones, transformaciones y
mapeos) del 20% aproximadamente.
Entre los distintos algoritmos de alineamiento la tendencia en la complejidad de la solución se
mantiene estable para ambos umbrales, en donde el algoritmo SMOA es el que genera una mayor
complejidad (744 y 592 mapeos), seguido del algoritmo WORDNET*, el cual como se mencionó
anteriormente utiliza el algoritmo SMOA para el alineamiento de columnas. La diferencia entre la
búsqueda exacta (algoritmo EQUAL) y las búsquedas de comparación de cadenas, dependiendo
del algoritmo generan diferencias significativas. Utilizando como umbral 0.7, la diferencia máxima
es cercana al 50% (SMOA 80 transformaciones, EQUAL 36 transformaciones) y utilizando como
umbral 0.8, la diferencia máxima es del 56% (SMOA 64 transformaciones, EQUAL 36
transformaciones).
6.3 ANÁLISIS DEL MODELO DE DATOS MAESTROS GENERADO
El objetivo de la validación presentada en esta sección es comparar el modelo de datos maestros
resultante de la ejecución de los pasos P4, P5, P6 y P7 de la herramienta STMDM, utilizando
diferentes algoritmos de alineamiento de ontologías. Para identificar la calidad del modelo
generado se tienen en cuenta los resultados de los algoritmos SMOA, WORDNET* y HAMMING, y
se profundizará en las entidades de negocio cliente (Customer) y empleado (Employee). En la
siguiente tabla se presentan las entidades maestras identificadas por cada uno de los algoritmos,
en donde se puede observar que once de las entidades se repiten en todos los algoritmos.
56
Tabla 12: Dimensiones del modelo de datos maestros
6.3.1 CLIENTE
La dimensión cliente generada por los distintos algoritmos tiene asociada las siguientes tablas:
AdventureWorks_Sales_Customer
AdventureWorksDW_dbo_DimCustomer
El algoritmo WORDNET* adicionalmente genera correctamente el mapeo entre la dimensión
cliente y la tabla CLIENTS_dbo_Client. Esto se debe a que el algoritmo además de utilizar técnicas
de comparación de cadenas, cuenta con un diccionario semántico (WORDNET) que almacena la
relación Customer – Client.
Los atributos de la dimensión Cliente resultan ser el consolidado de los tres fuentes para el caso
del algoritmo WORDNET*. En los resultados aparece repetida únicamente la columna ClientID
(CustomerID) lo cual se debe a que la comparación de columnas no se realizó utilizando el
algoritmo WORDNET sino el algoritmo SMOA. En la figura 32 se presentan el reporte de mapeos
para la dimensión cliente.
6.3.2 EMPLEADO
La dimensión empleado generada por los distintos algoritmos tiene asociada las siguientes tablas:
AdventureWorks_HumanResources_Employee
AdventureWorsDW_dbo_DimEmployee
HR_dbo_EMPLOYEEES
WORDNET* - 0,85 WORDNET* - 0,7 SMOA - 0,85 SMOA - 0,7 HAMMING - 0,85 HAMMING - 0,7
Department Department Department Department Department Department
Employee Employee Employee Employee Employee Employee
Location Location Location Location Location Location
Product Product Product Product Product Product
ProductCategory ProductCategory ProductCategory ProductCategory ProductCategory ProductCategory
ProductSubcategory ProductSubcategory ProductSubcategory ProductSubcategory ProductSubcategory ProductSubcategory
Currency Currency Currency Currency Currency Currency
CurrencyRate CurrencyRate CurrencyRate CurrencyRate CurrencyRate CurrencyRate
Customer Customer Customer Customer Customer Customer
SalesReason SalesReason SalesReason SalesReason SalesReason SalesReason
SalesTerritory SalesTerritory SalesTerritory SalesTerritory SalesTerritory SalesTerritory
Contact Contact Contact
CountryRegion CountryRegion CountryRegion
Address Address Address
PurchaseOrderHeader
Account
57
En el caso de esta dimensión, el algoritmo tiene en cuenta correctamente las tres posibles fuentes,
y los atributos son el consolidado de las tres fuentes. En el resultado únicamente aparecen
repetidos los atributos EmployeeKey – EmployeeID, y los atributos ManagerID –
ParentEmployeeKey. Esta última relación existente entre Manager y ParentEmployeeKey no la
logra detectar adecuadamente el algoritmo.
Figura 33. Transformaciones generadas para la dimensión Employee
6.4 COMPORTAMIENTO DE STMDM AL ADICIONAR INFORMACIÓN DE NEGOCIO
Una de las capacidades relevantes de la herramienta STMDM es la posibilidad de incluir
información de negocio a través del modelo de nomenclatura de negocio. El objetivo de esta
sección es presentar los resultados de la herramienta al definir algunos conceptos de negocio en el
modelo. Para esto se definen la relación entre la tabla S2502 y el término Address y la relación
entre los términos Customer y Client como se visualiza en la figura 20. Adicionalmente, dadas las
características de la información de los clientes en la base de datos AdventureWorks (existen los
conceptos customer y contact, en los cuales se almacena la información de los clientes) se genera
la relación entre los términos Customer y Contact.
En la tabla 13 se presenta la comparación de los resultados de la herramienta utilizando un umbral
de 0.85 para los algoritmos SMOA, WORDNET* y HAMMING al definir los términos y las relaciones
58
mencionados anteriormente en el modelo de negocio. En estos resultados se puede ver el efecto
de incluir conceptos de negocio en el modelo. Para los algoritmos HAMMING y WORDNET*, el
número de entidades candidatas, dimensiones y atributos aumento, mientras que para el
algoritmo SMOA disminuyo en todas las medidas. El número de transformaciones se incrementó
para todos los algoritmos, mientras el número de mapeos se redujo.
Algoritmo Definición
de BN Entidades
Candidatas Dimensiones Atributos Transformaciones Mapeos
HAMMING NO 21 11 198 46 472
SI 23 12 215 54 266
SMOA NO 25 14 234 64 592
SI 25 13 227 68 307
WORDNET* NO 21 11 193 48 492
SI 23 12 207 54 275 Tabla 13: Comparación de algoritmos al incluir información de negocio
La explicación de los resultados anteriores se pude visualizar en la tabla 14, en donde se presentan
los mapeos existentes entre las tablas relacionadas y las entidades de negocio Customer y Address.
Para el caso del cliente, los algoritmos HAMMING y SMOA sin definir los términos de negocio
únicamente existe relación con las tablas Customer y DimCustomer. El algoritmo WORDNET*, al
utilizar una búsqueda de sinónimos es capaz de identificar adicionalmente la relación con la tabla
Client. Al incluir los términos de negocio, el algoritmo de HAMMING adiciona a sus mapeos las
relaciones con la tabla Client y la tabla Contact. Por su parte algoritmo WORDNET* adiciona la
relación con la tabla Contact. El algoritmo SMOA al incluir la información de negocio genera
además de las cuatro relaciones válidas (Customer, DimCustomer, Client y Contact) las relaciones
con las tablas VendorContact y ContactCreditCard, las cuales son relaciones inválidas.
Tabla 14: Comparación de las relaciones detectadas para las entidades Customer y Address
Entidad AlgoritmoDefinición de
BNRelaciones
NO AdventureWorks_Sales_Customer, AdventureWorksDW_dbo_DimCustomer
SI
AdventureWorks_Person_Contact, AdventureWorksDW_Dbo_DimCustomer,
AdventureWorks_Sales_Customer, CLIENTS_dbo_Client
NO AdventureWorks_Sales_Customer, AdventureWorksDW_dbo_DimCustomer
SI
AdventureWorks_Person_Contact, AdventureWorksDW_Dbo_DimCustomer,
AdventureWorks_Sales_Customer, CLIENTS_dbo_Client,
AdventureWorks_Purchasing_VendorContact, AdventureWorks_Sales_ContactCreditCard
NO AdventureWorks_Sales_Customer, AdventureWorksDW_dbo_DimCustomer, CLIENTS_dbo_Client
SI
AdventureWorks_Person_Contact, AdventureWorksDW_Dbo_DimCustomer,
AdventureWorks_Sales_Customer, CLIENTS_dbo_Client
NO
SI AdventureWorks_Person_Address, CLIENTS_dbo_S2502
NO AdventureWorks_Person_Address, AdventureWorks_Purchasing_VendorAddress
SI
AdventureWorks_Person_Address, AdventureWorks_Purchasing_VendorAddress,
CLIENTS_dbo_S2502
NO
SI AdventureWorks_Person_Address, CLIENTS_dbo_S2502
HAMMING
SMOA
WORDNET*
Customer
Address
HAMMING
SMOA
WORDNET*
59
Para la entidad Address, ningún algoritmo logra realizar los mapeos adecuados sin realizar la
definición de los términos en la nomenclatura de negocio. Los algoritmos HAMMING y WORDNET*
no detectan ninguna relación mientras que el algoritmo SMOA detecta una relación inválida con la
tabla VendorAddress. Al adicionar los términos y las relaciones en el modelo, los algoritmos
HAMMING y WORDNET* logran detectar correctamente la relación entre las tablas Address y
S2502.
Los resultados presentados en esta sección, permiten visualizar el impacto en el modelo resultante
de adicionar términos y relaciones al modelo de nomenclatura de negocio. Para las dos entidades
analizadas, los algoritmos HAMMING y WORDNET* generan los resultados esperados al adicionar
la información al modelo, mientras el algoritmo SMOA detecta además de las relaciones válidas,
algunas relaciones inválidas. Estos resultados nos permiten concluir que la estrategia de adicionar
información al modelo de negocio mejora las características del modelo de datos resultante y nos
permite identificar alineaciones entre conceptos que sin esta capacidad serían imposibles de
detectar (relación tabla S2502 con tabla Address).
6.5 COMPARACIÓN CON HERRAMIENTAS COMERCIALES
Múltiples herramientas comerciales cómo Oracle [24], Microsoft [25] y Orchestra Networks [26]
ofrecen soluciones de administración de datos maestros. Estas soluciones están principalmente
enfocadas a la parte de gobierno de la información, pero no incluyen capacidades de generación
automática de modelos ni componentes de sincronización.
6.5.1 MICROSOFT
La solución de datos maestros de Microsoft (servicio Master Data Services) esta disponible desde
SQL Server 2008 R2. Esta solución incluye un repositorio centralizado almacenado en SQL Server
(Bases de datos del sistema), y una interfaz web para la administración de los datos maestros. En
SQL Server 2012 adicionalmente se incluyo un cliente para Microsoft Excel que permite al usuario
final administrar los datos maestros de su organización desde Excel.
Para realizar una implementación de esta solución, es necesario crear el modelo de datos
maestros manualmente mediante la interfaz web, y posteriormente generar los componentes de
sincronización utilizando servicios web (real time) ó tablas de stage (batch). A nivel batch, el
sistema ofrece múltiples tablas de entrada y un conjunto de vistas de salida para realizar la
sincronización. Los componentes de integración se deben realizar manualmente, y en el caso de
Microsoft la herramienta para el modelamiento de procesos de extracción, transformación y
cargue es Integration Services.
Aunque la parte técnica de la solución es necesario implementarla manualmente, a nivel de
gobierno de datos se ofrecen capacidades cómo definición de reglas de negocio, administración de
versiones , seguridad, auditoría y definición de responsables de los datos, entre otros.
60
6.5.2 ORACLE
La solución de Oracle para la administración de datos maestros esta basada en la suite MDM, la
cual incluye las aplicaciones para consolidar, limpiar gobernar y compartir los datos maestros
operacionales [32]. Estas aplicaciones se dividen en hubs para los siguientes tipos de datos: cliente
(CustomerHub), producto (ProductHub), proveedor (SupplierHub) y sitio (SiteHub). Cada uno de
estos hubs incluye un componente de gobierno de datos que permite la administración de los
datos maestro por parte de los usuarios finales. Adicionalmente la suite de MDM incluye
características de calidad de datos para distintas entidades de negocio.
En el caso de ORACLE, los modelos para cada uno de los hubs ya están construidos, y pueden ser
extensibles. Para garantizar la correcta funcionalidad de los servicios de datos maestros, se
necesitan algunas aplicaciones cómo Oracle Service Bus, BPEL PM, Oracle Business Rules, Oracle
Identity Management, entre otras. Para las tareas de migración e integración de información la
plataforma sugerida es Oracle Data Integrator, mediante la cual es posible realizar la carga de
información a los hubs. Una de las características que hace interesante la solución de Oracle, es la
integración con servidores de calidad de datos para mejorar la calidad de los datos maestros.
6.5.3 EBX5 – ORCHESTRA NETWORKS
La solución de Orchestra Networks, de acuerdo con su guía de producto [29] elimina las
restricciones de los modelos predefinidos o rígidos y provee características de modelamiento
semántico. Entre las características del producto se incluye la capacidad de definir los objetos de
datos, las reglas de calidad y los diccionarios de negocio. Al permitirle al usuario definir su modelo
de datos maestros, la solución es multidominio y puede aplicarse a cualquier conjunto de datos
maestros.
Entre las características relevantes de EBX5, se encuentra la capacidad de tener todas las
capacidades de administración de datos maestros en un solo producto, que adicionalmente
provee una interfaz web de administración. El sistema incluye capacidades de modelamiento,
calidad de datos, y gobierno de la información. Para realizar las tareas de integración de datos el
sistema incluye su motor de integración, y adicionalmente puede conectarse con distintos
proveedores cómo Oracle Data Integrator.
6.5.4 COMPARACIÓN
A continuación se presenta una comparación de las capacidades de STMDMD con las herramientas
comerciales a partir de la documentación de las mismas:
61
Capacidad Oracle EBX5 Microsoft STMDM
Repositorio centralizado SI SI SI SI
Generación automática del modelo NO NO NO SI
Identificación de conflictos NO NO NO SI
Extensibilidad del modelo Limitada SI SI SI
Generación automática de transformaciones NO NO NO SI
Versionamiento SI SI SI NO
Seguridad SI SI SI NO
Reglas de Negocio SI SI SI NO
Calidad de datos SI SI NO NO
Interoperabilidad NO - NO SI
Implementación funcional SI SI SI Metamodelo
Interfaz de usuario amigable SI SI SI NO
Multidominio - SI SI SI
Soporte CWM SI NO NO SI
Auditoria SI SI SI NO
Tabla 15: Comparación de tecnologías
En la comparación, se puede visualizar que la herramienta STMDM soporta las características
técnicas de la implementación de una solución de datos maestros, pero se encuentra limitada en
las características de gobierno, mientras que las tecnologías comerciales están más enfocadas en
el gobierno de la información e interfaz de usuario final que en las etapas técnicas. Una de las
características de la herramienta STMDM es que permite integrarse con las tecnologías de
bodegas de datos ofrecidas por los proveedores, pero no es posible integrarse con las tecnologías
de administración de datos maestros, dado que no existe un metamodelo estándar para la
administración de datos maestros.
62
Capítulo VII
TRABAJO RELACIONADO
7.1 INTRODUCCIÓN
La investigación alrededor de la administración de datos maestros no ha sido ampliamente
desarrollada a pesar de la relevancia del tema en las organizaciones actuales. En esta sección del
documento se presentan algunos trabajos relacionados con la administración de datos maestros y
metamodelos. Adicionalmente se presentan algunos trabajos relevantes en el área de
alineamiento de esquemas.
7.2 ADMINISTRACIÓN DE DATOS MAESTROS
En [7] se presenta una solución de integración basada en esquemas XML. En este solución, los
modelos de datos maestros se definen utilizando esquemas XML que describen estructuras de
datos complejas. El aporte de [7] a la solución (EBX.Platform – Orchestra Networks), es la
capacidad de enriquecer la estructura y la semántica de los modelos utilizando un metamodelo, en
el cual se definen las relaciones semánticas entre los objetos como links entre los conceptos. El
metamodelo resultante se utiliza para definir un perfil UML y optimizar las operaciones como la
validación de los modelos, la factorización de los datos y la representación en árboles. El perfil
UML se aprovecha para facilitar la creación de los modelos.
En [8] se presenta un metamodelo que define el concepto de dato maestro, los tipos de datos
maestros y los criterios de identificación de los mismos. El modelo planteado para los datos
maestros se basa en un conjunto de esquemas ORM. Según el documento, el proceso de
administración de datos maestros se divide en los siguientes pasos: Definición de datos maestros,
administración de datos maestros, cambio de los datos maestros, servicios de datos maestros,
privilegios de datos maestros y migración de datos maestros. El metamodelo planteado en este
documento incluye características de administración de nombres (incluyendo acrónimos y
conceptos asociados), versionamiento, ciclo de vida de los datos, responsables, fuentes de datos,
representación de la información (tipo de dato, precisión) y reglas de negocio. En cada uno de los
metamodelos se plantean las entidades y la definición de los conceptos.
En [9] se plantean un conjunto de modelos para colaborar con la identificación de equivalencias de
los datos maestros buscando la adecuada resolución de entidades. Estos modelos, definidos en un
esquema ORM incluyen modelos de mapeo, de transformación, de selección y de alineamiento,
entre otros. En el documento se plantea como primer paso la necesidad de identificar los mapeos
de orígenes y destinos, para lo cual se utiliza un metamodelo de mapeo a nivel de tipo que incluye
los conceptos de base de datos (tabla, columna) y los conceptos de mapeo (mapeos, filtros y
63
transformaciones) en el mismo metamodelo. Entre los conceptos relevantes que se plantean en el
documento, es la necesidad de incluir información de tipo (metadata) e información de valor
(datos) para garantizar la calidad del metamodelo resultante. La figura 35 permite visualizar las
características del metamodelo planteado en [9], en donde están incluidos la gran mayoría de
conceptos que define la herramienta STMDM para realizar el mapeo y las transformaciones.
Figura 34. Metamodelo de mapeo – Tomado de [9]
En [14] se presenta un framework para realizar una aproximación a la implementación de una
solución de administración de datos maestros, y se diferencian cuatro estrategias principales de
aproximación. Las estrategias dependen del punto de inicio de la aproximación y del camino
durante el proyecto. Los puntos de inicio mencionados en el artículo son los datos o el proceso, y
los caminos son orientados al problema u orientado a la solución. En el documento se describen
cada una de las aproximaciones y se presentan sus ventajas y las desventajas correspondientes.
Con respecto a la estrategia utilizada en STDMD (data driven) se menciona que este tipo de
soluciones no tienen en cuenta el impacto de la calidad de datos en los procesos de negocio.
7.3 ALINEAMIENTO DE ESQUEMAS
Múltiples autores han planteado la necesidad de integrar esquemas de bases de datos para
garantizar la interoperabilidad entre múltiples fuentes de datos. La alineación e integración de
esquemas ha sido trabajada ampliamente, y un ejemplo de este trabajo se puede observar en [27],
en donde se plantea el uso de una herramienta semiautomática para la alineación y la integración
de esquemas (SASMINT por sus siglas en inglés). En este trabajo se plantean estrategias de
identificación y resolución de conflictos sintácticos, semánticos y estructurales entre esquemas de
bases de datos. SASMINT es una herramienta semiautomática, dado que solicita la validación de
los alineamientos por parte del usuario. Esta herramienta adicionalmente permite la generación
de un esquema integrado como resultado final de su proceso. Para la parte del alineamiento, se
64
utilizan técnicas de procesamiento de lenguaje y teoría de grafos. En el desarrollo de SASMINT se
plantean las reglas de integración para los posibles resultados del alineamiento de esquemas.
En [28] se presenta otra herramienta semiautomática de integración de esquemas, la cual ofrece
la posibilidad de entregar múltiples esquemas resultantes a partir de los esquemas originales. El
objetivo de esta solución, es ofrecer a los usuarios diferentes esquemas integrados que pueden
ser útiles en distintos escenarios. La solución planteada en este documento se apoya en la
herramienta Clio (Proyecto de investigación de IBM) que permite generar el mapeo de esquemas y
describir las relaciones entre los esquemas originales y el esquema integrado. Adicionalmente Clio
permite la generación de ejecutables (código o queries) para transformar una instancia de un
esquema origen a un esquema destino.
En [29] se presenta la herramienta ISI (Intelligent Schema Integrator), la cual permite integrar
esquemas XML y busca solucionar el problema de los homónimos y sinónimos entre los esquemas
y busca generar un esquema integrado. Para la comparación utiliza un diccionario de sinónimos
que permite detectar los posibles homónimos y sinónimos entre los esquemas. En [30] se presenta
una estrategia de alineamiento de esquemas basada en metamodelos. La herramienta planteada
(SAMT4MDE por sus siglas en inglés) define un metamodelo propio de mapeo y un metamodelo
de administración de versiones. A partir de este metamodelo se plantea un algoritmo de
alineamiento. Esta herramienta incluye un plug-in para eclipse basado en EMF en donde se
incluyen los conceptos de mapeo definidos en el algoritmo. Mediante esta herramienta es posible
comparar dos metamodelos y generar las transformaciones en ATL que permiten convertir un
metamodelo de origen en un metamodelo de destino.
En [31] se presenta una estrategia de integración de información a partir de ontologías, la cual
genera como resultado transformaciones del metamodelo CWM. Esta propuesta facilita la
generación de los mapeos entre la bodega de datos de una organización y las fuentes originales
utilizando la siguiente estrategia: para cada fuente de datos se define un metamodelo junto con
una ontología asociada que incluye la información semántica de la fuente de datos. Se asume que
la bodega de datos tiene su propio metamodelo definido y una ontología asociada que describe las
características de la bodega. A partir de las ontologías de las fuentes de datos y de la bodega se
realiza el alineamiento de las mismas, y se generan los mapeos utilizando los conceptos
ClassifierMap y FeatureMap del metamodelo CWM.
65
Capítulo VIII
CONCLUSIONES
8.1 CONCLUSIONES
Aunque las soluciones de datos maestros han tenido una gran acogida en las organizaciones en los
últimos años debido a la heterogeneidad de las fuentes de datos que conlleva a problemas de
calidad, la mayoría de software disponible es comercial y la investigación respecto a este tema no
ha sido lo suficientemente amplia. Adicionalmente, el software comercial esta enfocado
principalmente en brindar capacidades de gobierno de la información, pero no se realiza mucho
énfasis en la automatización de las tareas técnicas necesarias para la implementación de la
solución.
La herramienta de soporte para la creación de una solución de datos maestros (STMDM)
planteada en este documento ofrece un apoyo a las organizaciones para la implementación
técnica de una solución de este estilo. STMDM esta basado en un modelo estándar (CWM) que es
independiente de la plataforma (PIM) y adicionalmente esta soportado por los principales
proveedores de bases de datos del mercado (Oracle, IBM, Hyperion, Cognos) lo que permitiría
utilizar esta herramienta como un apoyo para las etapas técnicas trabajando sobre un
metamodelo PIM y fácilmente convertirlo en una implementación tecnológica. Aunque en algunas
partes de la estrategia se plantean extensiones a CWM, estas únicamente hacen parte del proceso
pero se podrían eliminar del modelo final para garantizar la compatibilidad con los metamodelos
dependientes de la plataforma (PSM).
La solución planteada en STMDM, al apoyarse en un metamodelo permite la navegación entre los
distintos modelos que hacen parte de la solución (relacional, olap) lo que facilita la trazabilidad de
la información. Adicionalmente al ser un metamodelo de bodegas de datos, este incluye
conceptos de ETL, que generalmente al momento de implementarse tecnológicamente ofrecen
una interfaz de diseño amigable para la administración y evolución de los componentes de
sincronización. Adicionalmente, dadas las características que brinda la implementación de STMDM
sobre un metamodelo, se podrían generar transformaciones de modelo a texto para generar
código en lenguajes de programación que permitan realizar la sincronización utilizando estrategias
diferentes a la integración mediante ETL.
Aunque el caso de estudio del documento es un caso simple (4 bases de datos) y ficticio (bases de
prueba de proveedores tecnológicos), se logró presentar la complejidad del problema planteado
en la introducción. En un caso real, en donde el número de fuentes y la cantidad de tablas
disponibles sea mucho mayor, es claro que es necesario utilizar alguna estrategia de
automatización dado que la realización de los pasos manuales es altamente costosa en tiempo y
puede permitir errores.
66
Debido a las características propias del modelamiento de las bases de datos relacionales, la
complejidad para el desarrollo de la parte técnica de una solución de administración de datos
maestros (búsqueda de equivalencias semánticas, identificación de los datos maestros, generación
del modelo centralizado, generación de mapeos) impide que la generación sea totalmente
automática y hace necesaria en algún punto la interacción humana. Aún con la complejidad propia
del problema, la herramienta STMDM logra identificar la gran mayoría de las relaciones
semánticas y genera los mapeos correspondientes adecuadamente. Como se planteó desde un
inicio, la herramienta STMDM brinda soporte a la implementación de una solución de datos
maestros en una organización, pero no logra obtener todas las características óptimas para una
implementación. Esta optimización debe ser realizada por los responsables de los datos, los cuales
pueden aprovechar los distintos resultados de la herramienta para definir el algoritmo más
adecuado, definir los umbrales e identificar las características adicionales requeridas.
Adicionalmente, los responsables de los datos pueden aprovechar la capacidad de STMDM de
incluir información en el proceso técnico de implementación mediante la nomenclatura de
negocio sin la necesidad de definir todos los conceptos asociados, sino únicamente aquellos que la
herramienta no logra detectar automáticamente. Esta capacidad de adicionar información de
negocio al modelo brinda resultados exitosos, como se presento en la sección de validación.
8.2 TRABAJO FUTURO
Para garantizar la calidad del modelo de datos maestros resultante y el correcto alineamiento de
este con los procesos de negocio de la organización, se podrían incluir diagramas de proceso para
complementar la identificación de los datos maestros. El presente trabajo únicamente plantea una
estrategia basada en los datos (bottom - up), pero en la literatura [3] [14], se menciona la
posibilidad de realizar análisis a partir de los procesos de negocio (top - down).
Otra característica que se podría incluir en la solución para mejorar el modelo resultante y la
identificación de los datos maestros sería la información de número de registros y cambios en el
volumen de la información. Esta característica podría facilitar la identificación de los datos
maestros teniendo en cuenta las características relativamente estáticas de los mismos.
Una de las limitaciones de la solución planteada en STMDM es la necesidad de cargar únicamente
fuentes relacionales. Se pueden dar casos en las organizaciones, en donde el acceso a los sistemas
de relacionales sea restringido, o la complejidad del modelo sea muy alta, pero existan esquemas
XML que permitan acceder a la información de una manera más sencilla. Para esto, la solución
planteada en se puede extender aprovechando las bondades de CWM, en donde se encuentran
definidos los orígenes de datos de archivos planos y archivos XML. Para extender esta solución a
otros orígenes de datos, sería necesario generar los loaders hacia el modelo respectivo y generar
la transformación de modelo a texto para realizar el alineamiento de ontologías.
Las transformaciones generadas mediante STMDM generan los mapeos entre los orígenes de
datos y el modelo de datos maestros, pero no aprovechan todas las características del
67
metamodelo Transformation. Las únicas características que se tuvieron en cuenta en la solución
fueron las relacionadas al área de transformación y trazabilidad. En el modelo existen otro
conjunto de transformaciones que permiten agrupar las tareas y las ejecuciones como
TransformationStep, TransformationTask y TransformationActivity. La implementación de estos
modelos, facilitaría la posterior implementación de los modelos CWM en las plataformas
tecnológicas.
La tendencia actual del mercado [2] respecto a la administración de los datos maestros incluye
adicionalmente a la generación de los componentes de sincronización en batch mediante técnicas
de ETL, la necesidad de realizar sincronización de la información en tiempo real. Usualmente esta
sincronización se realiza utilizando servicios web, para lo cual se podría aprovechar el modelo
STMDM y generar una transformación de modelo a texto, en donde el resultado serían los
servicios web requeridos para la sincronización de la información.
Otra característica de la solución planteada en STMDM es que únicamente soporta las tareas
técnicas de la implementación de una solución de datos maestros. Como se presentó en el
contexto, una solución de este tipo debe contemplar la parte técnica, y la parte de gobierno. Para
incluir el gobierno (versionamiento, seguridad, stewardships, reglas de negocio) se podría llegar a
extender el metamodelo CWM para que soportara este tipo de características. En el desarrollo de
STMDM no se consideró la parte de gobierno, porque múltiples proveedores tecnología ya la
tienen definida en sus soluciones, aunque para garantizar la interoperabilidad entre tecnologías
podría llegar a extenderse.
68
REFERENCIAS
[1] The Open Group Architecture Framework. (2009). TOGAF. (Version 9).
[2] P.Russom. (2012). Next Generation Master Data Management. TDWI Best Practices
Report. TDWI Research.
[3] D. Loshin, Master Data Management. Estados Unidos: Morgan Kaufmann Publishers,
2009.
[4] A. Haug, F. Zachariassen, D. Liempd. “The costs of poor data quality”, Journal of Industrial
Engineering and Management. V4(2), pp. 168 – 193. 2011.
[5] L. English. “Process and Business Failure: The High Costs of Low Quality Information” en
Information Quality Applied: Best Practices for Improving Business Information, Processes
and Systems. Estados Unidos: John Wiley & Sons, 2009.
[6] A. Berson, L. Dubov. Master Data Management and Customer Data Integration for a
Global Enterprise. Estados Unidos: The McGraw-Hill Companies, Inc, 2007.
[7] L. Menet, M. Lamolle, A. Zerdazi. “Managing Master Data with XML Schema and UML”.
International Workshop on Advanced Information Systems for Enterprises. IEEE. 2008.
[8] B.Piprani, S.Dham. “A Metamodel for Master Data”. OTM 2010 Workshops. Springer-
Verlag Berlin Heidelberg. pp. 447-456. 2010.
[9] B. Piprani. “A model for Semantic Equivalence Discovery for Harmonizing Metadata”. OTM
2009 Workshops. Springer-Verlag Berlin Heidelberg. pp. 649-658. 2010.
[10] R. Silvola, O. Jaaskelainen, H. Krospu-Vehkapera, H. Haapasalo. “Managing one master
data – Challenges a Preconditions”. Industrial Management & Data Systems. Emerald
Group Publishing Limited. Vol. 111 No 1, pp. 146-162. 2011.
[11] A.D. Giordano. Data Integration Blueprint and Modeling. Techniques for a Scalable and
Sustainable Architecture. IBM Press - Pearson plc, 2010.
[12] M. Godinez, E. Hechler, K. Koenig, S. Lockwood, M. Oberhofer, M. Schroeck. The Art of
Enterprise Information Architecture. A Systems-Based Approach for Unlocking Business
Insight. IBM Press - Pearson plc, 2010.
[13] C. White (2005). Data Integration: Using ETL, EAI and EII Tools to Create an Integrated
Enterprise. BI Research. TDWI Report Series.
69
[14] A. Cleven, F. Worthmann. “Uncovering four strategies to approach master data
management”. Precedings of the 43rd Hawaii International Conference on System Sciences.
IEEE. 2010.
[15] J. Bezivin. “In Search of a Basic Principle for Model Driven Engineering”. UML and Model
Engineering. Vol. V, No. 2, pp. 21-24. Abril. 2004.
[16] M. Guttman, J.Parodi. Real-life MDA: solving business problems with model driven
architecture. Estados Unidos: Morgan Kaufmann Publishers. 2006.
[17] The Object Management Group. (2003). Common Warehouse Metamodel (CWM)
specification. (Version 1.1) [En línea]. Disponible: http://www.omg.org/spec/CWM/1.1/
[18] World Wide Web Consortium (W3C). (2004). OWL Web Ontology Language Guide. [En
línea]. Disponible: http://www.w3.org/TR/owl-guide/
[19] J. Poole, D. Chang, D. Tolbert, D.Mellor. Common Warehouse Metamodel Developer’s
Guide. Estados Unidos: Wiley Publishing, InC. 2003.
[20] Z. Xu, S. Zhang, Y. Dong. “Mapping between Relational Database Schema and OWL
Ontology for Deep Annotation”. Proceedings of the 2006 IEEE/WIC/ACM International
Conference on Web Intelligence. IEEE. pp. 548-552. 2006.
[21] K. Albarrak, E. Sibley. “Translating Relational & Object-Relational Database Models into
OWL Models”. Information Reuse & Integration. IEEE. pp. 336- 341. 2009.
[22] I. Astrova. “Rules for Mapping SQL Relational Databases to OWL Ontologies”. Metadata
and Semantics. Springer. Part 5, pp. 415-424. 2009.
[23] D. Jerome, J. Euzenat, F. Scharffe, C. Trojanh. “The alignment API 4.0”. Semantic web
journal. 2(1). pp. 3 – 10. 2011.
[24] Oracle. (2011). Master Data Management. An Oracle White Paper. [En línea]. Disponible:
http://www.oracle.com/us/products/applications/master-data-management/018876.pdf
[25] Microsoft Developer Network. Master Data Services. [En línea]. Disponible:
http://msdn.microsoft.com/en-us/library/ee633763
[26] Orchestra Networks. (2011). EBX5: The next Generation of MDM. Product Overview by
Orchestra Networks. [En línea]. Disponible: http://www.orchestranetworks.com/product/
[27] O. Unal, H. Afsarmanesh. “Semi-automated schema integration with SASMINT”.
Knowledge and Information Systems. Springer-Verlag. Vol 23 Issue 1, pp. 99-128. Abril,
2010.
70
[28] L. Chiticariu, M.A. Hernández, P.G.Kolaitis, L.Popa. “Semi-Automatic Schema Integration in
Clio”. VLDB '07 Proceedings of the 33rd international conference on Very large data bases.
pp. 1326-1329. 2007.
[29] K. Ahmad, H. Khim Chiew, R. Samad. “Intelligent Schema Integrator (ISI): A Tool to Solve
the Problem of Naming Conflict for Schema Integration”. 2011 International Conference on
Electrical Engineering and Informatics. pp. 1-5. 2011.
[30] D. Lopes, S. Hammoudi, Z. Abdelouahab. “Schema Matching in the Context of Model
Driven Engineering: From Theory to Practice”. Advances in Systems, Computing Sciences
and Software Engineering. Springer. pp. 219-227. 2006.
[31] A. Hoang, B. Nguyen. “An integrated use of CWM and Ontological modeling approaches
towards ETL Process”. ICEBE '08 Proceedings of the 2008 IEEE International Conference on
e-Business Engineering. IEEE. pp. 715-720. 2008.
