Módulo de evaluación de calidad de datos utilizando reglas de negocio en un contexto determinado (DQ-Rules)

Texto completo

(1)1. MÓDULO DE EVALUACIÓN DE CALIDAD DE DATOS UTILIZANDO REGLAS DE NEGOCIO EN UN CONTEXTO DETERMINADO (DQ- Rules). ASESORA María del Pilar Villamil [email protected]. AUTOR Jaime Alberto Muñoz Córdoba [email protected]. DOCUMENTO DE TESIS MAESTRÍA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. 2012.

(2) 2. TABLA DE CONTENIDO 1.. 2.. 3.. 4.. INTRODUCCIÓN ............................................................................................................................................................ 5 1.1. ANTECENDENTES ................................................................................................................................................ 5. 1.2. PROBLEMÁTICA Y OBJETIVOS ......................................................................................................................... 5. 1.3. ORGANIZACIÓN DEL DOCUMENTO ................................................................................................................ 6. ESTADO DEL ARTE EN CALIDAD DE DATOS ......................................................................................................... 6 2.1. CONTEXTO ............................................................................................................................................................ 6. 2.2. GENERALIDADES................................................................................................................................................. 7. 2.3. TIPOS DE PROBLEMAS DE CALIDAD DE DATOS .......................................................................................... 7. 2.4. MEDICIÓN DE LA CALIDAD DE DATOS .......................................................................................................... 9. 2.5. METODOLOGÍA PARA CALIDAD DE DATOS ............................................................................................... 17. 2.6. HERRAMIENTAS PARA CALIDAD DE DATOS .............................................................................................. 19. 2.7. SÍNTESIS DEL ESTADO DEL ARTE ................................................................................................................. 22. DQ-RULES - PROPUESTA ........................................................................................................................................... 23 3.1. PRINCIPIOS DE LA INVESTIGACIÓN.............................................................................................................. 23. 3.2. MECANISMO DE CALIDAD DE DATOS UTILIZANDO REGLAS DE NEGOCIO ....................................... 27. 3.3. METODOLOGÍA APLICADA AL PROCESO DE CALIDAD DE DATOS ...................................................... 42. VALIDACIÓN ............................................................................................................................................................... 43 4.1. METODOLOGÍA DE CALIDAD DE DATOS Y CONCEPTOS APLICADOS ................................................. 43. 4.2. VALIDACIÓN DE LOS OPERADORES - FLUJO DE DATOS ......................................................................... 50. 4.3. MEJORAR RENDIMIENTO EN LA EJECUCIÓN DEL FLUJO DE VALIDACIÓN........................................ 57. 5.. CONCLUSIONES Y TRABAJO FUTURO................................................................................................................... 59. 6.. REFERENCIAS .............................................................................................................................................................. 60.

(3) 3. INDICE DE IMÁGENES Figura 1: Puntos de interacción de usuarios y otras aplicaciones. ............................................................................................. 7 Figura 2: Problemas de calidad de datos de una sola fuente y múltiples fuentes. ...................................................................... 7 Figura 3: Entradas y salidas de la metodología de calidad de datos. ....................................................................................... 18 Figura 4: Fases y actividades de la metodología de calidad de datos. ..................................................................................... 18 Figura 5: Cuadrante mágico de Gartner 2011 para herramientas de calidad de datos. ............................................................ 20 Figura 6: Funcionalidades de calidad de datos direccionadas por las herramientas de calidad de datos. ................................ 20 Figura 7: Flujos de procesamiento de datos. ............................................................................................................................ 21 Figura 8: Objetivo final del flujo. ............................................................................................................................................ 22 Figura 9: Modelo conceptual para representar las afirmaciones estructurales. ........................................................................ 25 Figura 10: Modelo conceptual para representar las afirmaciones de acción. ........................................................................... 26 Figura 11: Representación de las clases de afirmaciones de acción. ....................................................................................... 26 Figura 12: Modelo conceptual para representar las derivaciones. ........................................................................................... 26 Figura 13: Modelo conceptual para representar sentencias y políticas con reglas de negocio. ............................................... 27 Figura 14. Componentes utilizados y desarrollados en la solución propuesta. ........................................................................ 28 Figura 15. Estructura jerárquica de las reglas de negocio. ....................................................................................................... 28 Figura 16. Modelo relacional para representar los componentes de las reglas de negocio. ..................................................... 29 Figura 17. Componentes principales de un Sistema Gestor de Reglas de Negocio. ................................................................ 30 Figura 18. Paquetes del mecanismo de validación. ................................................................................................................. 38 Figura 19. Clases del paquete BusinessRulesModel. ............................................................................................................... 38 Figura 20. Clases del paquete DataModel. .............................................................................................................................. 39 Figura 21. Clases del paquete Manager. .................................................................................................................................. 39 Figura 22. Operadores de validación en RapidMiner. ............................................................................................................. 40 Figura 23. Ejemplo de flujo de validación de datos. ................................................................................................................ 41 Figura 24. Pantalla de ingreso a Guvnor. ................................................................................................................................. 41 Figura 25. Reglas y complementos para la solución. ............................................................................................................... 42 Figura 26. Lista de reglas de negocio que se administran a través de la plataforma. ............................................................... 42 Figura 27. Responsabilidades del SIVIGILA. ......................................................................................................................... 45 Figura 28. Secuencia de grupos de validación. ........................................................................................................................ 51 Figura 29. Subproceso para validar términos........................................................................................................................... 51 Figura 30. Subproceso para validar el hecho asociado a Diagnóstico Principal y Causa Externa. .......................................... 52 Figura 31. Generación de registros entre Consultas Medicas y Usuarios. ............................................................................... 52 Figura 32. Validación de diagnóstico principal y género. ....................................................................................................... 52 Figura 33. Validación de diagnóstico principal y edad. ........................................................................................................... 53 Figura 34. Resultado que se obtiene de la ejecución de las cuatro muestras. .......................................................................... 57.

(4) 4. INDICE DE TABLAS Tabla 1: Representación del cliente en una fuente de datos....................................................................................................... 8 Tabla 2: Representación del cliente en una segunda fuente. ...................................................................................................... 8 Tabla 3: Relación Movies donde se presentan varios problemas de precisión sintáctica y semántica. ...................................... 9 Tabla 4: Relación Movies donde se presentan problemas de calidad de datos. ....................................................................... 13 Tabla 5: Resumen dimensiones para evaluar la calidad de los datos. ...................................................................................... 16 Tabla 6: Listado de metodologías desarrolladas para la calidad de datos. ............................................................................... 17 Tabla 7. Artefacto para la definición de reglas de validación. ................................................................................................. 43 Tabla 8: Caracterización de la regla No. 001. .......................................................................................................................... 46 Tabla 9: Caracterización de la regla No. 002. .......................................................................................................................... 46 Tabla 10: Caracterización de la regla No. 003. ........................................................................................................................ 47 Tabla 11: Caracterización de la regla No. 004. ........................................................................................................................ 47 Tabla 12: Caracterización de la regla No. 005. ........................................................................................................................ 48 Tabla 13: Caracterización de la regla No. 006. ........................................................................................................................ 48 Tabla 14: Caracterización de la regla No. 007. ........................................................................................................................ 48 Tabla 15. Lista de variables evaluadas sobre el conjunto de datos. ......................................................................................... 50 Tabla 16. Resultados del primer escenario de validación aplicado.......................................................................................... 51 Tabla 17. Resultados del segundo escenario de validación (primera muestra). ....................................................................... 53 Tabla 18. Resultados del segundo escenario de validación (segunda muestra). ...................................................................... 54 Tabla 19. Resultados del segundo escenario de validación (tercera muestra). ........................................................................ 55 Tabla 20. Resultados del tercer escenario de validación aplicado. .......................................................................................... 57.

(5) 5. 1.. INTRODUCCIÓN. 1.1 ANTECENDENTES La información ha sido considerada como un factor clave en las empresas durante su operación diaria y en el proceso de planificación, gestión, control y toma de decisiones. Se considera que la información se encuentra al mismo nivel que cualquier otro recurso en la compañía, por lo cual, esta debe ser tratada con la misma importancia (actualmente se la considera como uno de los activos más importantes). La información, que por lo general se distribuye a los usuarios en los niveles operativos, tácticos y estratégicos [1], se genera en los diferentes módulos computacionales de un sistema de información y se almacena en las fuentes de datos distribuidas y de análisis. La información al ser tratada por los distintos componentes de los sistemas de información o procesos dentro de la compañía, puede sufrir transformaciones o cambios que afectan su calidad y significado para la organización. Los errores generados en los datos, pueden ser la consecuencia de aplicaciones que contienen defectos en su codificación, problemas de seguridad informáticos, acceso inesperado a las fuentes de información, manipulación indebida a las bases de datos en procesos de migración, sincronización e integración; y actualizaciones masivas (enmarcadas en procesos ETL) [2]. Baja Calidad de los Datos o Low Data Quality, es un término que se ha utilizado para calificar los diferentes problemas encontrados en la información, los cuales pueden impactar de diferente manera según el tipo de empresa y fuente de datos donde se presente. Se ha observado a través del tiempo que el problema de calidad de datos ha generado grandes pérdidas en industrias financieras, comerciales, manufactureras y salud; por otro lado, el problema ha tenido menos importancia en las fuentes de datos de las redes sociales y sistemas virtuales [3]. Considerando la importancia de la calidad de los datos, algunos autores y casas de software han hecho un gran esfuerzo buscando estrategias que permitan medir, evaluar y corregir los datos considerados como erróneos, de acuerdo a un conjunto de criterios definidos por la organización.. 1.2 PROBLEMÁTICA Y OBJETIVOS La calidad de datos se ha convertido en uno de los grandes retos para las empresas, por esta razón, muchas de ellas utilizan estrategias y herramientas para tratar de resolver el problema. Estas iniciativas abordan la problemática utilizando una serie de componentes que procesan los datos de acuerdo a condiciones específicas que corrigen los errores sin atacar las causas propias dadas por las reglas del negocio (prevención), convirtiéndose en iniciativas aisladas de los procesos de la organización. Por tal motivo, es necesario incluir sobre estos proyectos la calidad de datos según el contexto del negocio y la arquitectura de la información, con el fin de que haya conciencia y responsabilidad sobre el manejo de los datos.. 1.2.1. Objetivo General. Diseñar e implementar un módulo de calidad de datos que permita identificar, evaluar y corregir problemas en los datos contenidos en una fuente de información, teniendo en cuenta el contexto del negocio (reglas de negocio). 1.2.2. Objetivos Específicos. Realizar un estudio de las estrategias de calidad de datos actuales para comprender su funcionamiento en los sistemas e identificar oportunidades de mejora. Diseñar e implementar un módulo para identificar, medir, evaluar y corregir problemas de calidad de datos en una fuente de información, tomando como base un conjunto de reglas de negocio definidas en un repositorio central (contexto de negocio, dominio). Validar las diferentes fases del proceso propuesto en un caso de estudio del dominio de la Salud, comparando y analizando los resultados obtenidos..

(6) 6. 1.3 ORGANIZACIÓN DEL DOCUMENTO El contenido del documento está organizado de la siguiente manera. En el capítulo 2 se describe el estado del arte correspondiente a las generalidades, tipos de problemas y estrategias actuales para tratar la calidad de datos. El capítulo 3 presenta los principios de la investigación, la propuesta del módulo de evaluación y los aportes de la metodología al proceso. En el capítulo 4 se indican los criterios de evaluación y resultados obtenidos. Finalmente, en el capítulo 5 se presentan las conclusiones de la investigación y se indican puntos que se derivan para trabajo futuro.. 2.. ESTADO DEL ARTE EN CALIDAD DE DATOS. 2.1 CONTEXTO Actualmente las organizaciones ejecutan las operaciones diarias de su negocio mediante la construcción de diferentes tipos de procesos (estratégicos, misionales y de apoyo), es por esto que las empresas califican los procesos como un concepto importante y dominante dentro de su arquitectura empresarial y sus sistemas de información. La arquitectura empresarial es una visión holística de la empresa, permite definir, entender y organizar los diferentes elementos de una organización (estrategia, proceso de negocio, aplicaciones tecnológicas e información). La arquitectura empresarial se fundamente principalmente en cuatro (4) dominios: Arquitectura de Negocio, que corresponde al modelado de los procesos, organización, gente y activos. Arquitectura de Información, que consiste en identificar los datos de negocio (entidades / objetos) y la definición del flujo, uso, integridad, seguridad y calidad de la información. Arquitectura de Aplicaciones, cuyo objetivo es el diseño del modelo de automatización de software requerido para soportar los procesos de negocio definidos en la Arquitectura de Negocio. Finalmente, la Arquitectura Tecnológica, la cual se centra en el diseño detallado de la infraestructura y los elementos tecnológicos requeridos para cumplir con los requerimientos no funcionales definidos por la organización según sus prioridades. El enfoque de arquitectura orientado a procesos de negocio, permite a las empresas lograr agilidad organizacional y ventajas competitivas, debido a la capacidad de adaptación a los cambios continuos que genera el mercado donde operan; cambios que se reflejan en modificaciones en sus procesos de negocio. Cada uno de los procesos de negocio, se apoyan en un conjunto de sistemas de información internos o externos que pueden abarcar varios departamentos o filiales geográficamente distribuidos, es con esto que surge el paradigma de BPM y EIM que permiten la integración de ambientes heterogéneos (sistemas de información existentes y nuevos); y la gestión de los procesos de negocio mediante aplicaciones conocidas como BPMS (descubrimiento, diseño, simulación, despliegue, ejecución, interacción, monitorización, control, análisis y optimización). Los sistemas de información están formados por el conjunto de elementos utilizados para el procesamiento y administración de datos e información de una empresa. Como se presenta en la Figura 1, sobre los sistemas de información existen diferentes puntos en donde se presenta interacción tanto de usuarios como de aplicaciones, los cuales generan y modifican datos. La interacción de los usuarios y aplicaciones en estos puntos pueden generar problemas de calidad en los datos, debido a errores presentes en la codificación de las aplicaciones, inconvenientes de seguridad, acceso inesperado a las bases de datos, y actualizaciones masivas que se pueden presentar sobre ellos (procesos de migración e integración utilizados). Debido a los problemas de calidad de datos generados y a la consideración de la información como uno de los activos más importantes de la organización, diversos autores y casas de software invierten un gran esfuerzo en la definición de estrategias que permitan medir, evaluar, corregir y controlar los diferentes tipos de problemas generados [3]..

(7) 7. Figura 1: Puntos de interacción de usuarios y otras aplicaciones.. 2.2 GENERALIDADES La calidad de los datos es un concepto que se enmarca en la utilidad de los mismos para la organización y la representación que hacen del mundo real. Por esto, los datos son considerados de alta calidad… “si ellos son aptos para el uso en operaciones, toma de decisiones y planificación dentro de la organización” [4]. Este aspecto es de gran importancia para las empresas, pero no siempre puede ser concebida debido a las situaciones y estados sobre las cuales se encuentran los datos y las fuentes que los hospedan. Actualmente, el problema de calidad de datos está siendo tratado por las organizaciones utilizando guías y herramientas que permiten identificar, medir, y corregir los problemas de acuerdo a conjunto de criterios específicos definidos por ellas. 2.3 TIPOS DE PROBLEMAS DE CALIDAD DE DATOS Una clasificación dada a los problemas de calidad de datos es la que se presenta sobre la Figura 2, donde se muestra una fuerte distinción entre los problemas presentes en una sola fuente o múltiples fuentes; y problemas a nivel de esquema e instancia [5].. Figura 2: Problemas de calidad de datos de una sola fuente y múltiples fuentes..

(8) 8. Los problemas de calidad de datos que se pueden encontrar en una sola fuente, dependen del grado de gobernabilidad dado por las restricciones de esquema e integridad que controlan los valores permitidos. Para fuentes sin esquema, tales como archivos planos, hay pocas restricciones que puedan controlar el ingreso y contenido de los datos, dando lugar a una alta probabilidad de errores e inconsistencias. Los gestores de bases de datos, por el contrario, hacen cumplir restricciones de un modelo de datos especifico (por ejemplo, modelo relacional requiere de valores de atributos simples, integridad referencial, relaciones, etc.). En la tipología de una sola fuente - nivel de esquema, los errores ocurren por la pérdida o falta de restricciones de integridad en los modelos o aplicaciones específicas. Por ejemplo:  Se pueden presentar valores incorrectos como fechas (30.13.1970/dd.mm.yyyy), al definir un tipo de dato no adecuado para el campo.  Violación de integridad referencial, cuando a un empleado se le asigna el código de un departamento que no existe.  Problema de unicidad, cuando a dos empleados se les asigna el mismo número de identificación.  Violación de la dependencia entre atributos, cuando la edad de un empleado no se encuentra sincronizada con el cálculo de la fecha actual y la fecha de nacimiento.  Entre otros. Por otro lado, el nivel de instancia corresponde a errores propios del dato que no pueden ser controlados a nivel de esquema. Por ejemplo:  Valores faltantes ((57)-48544XY para números telefónicos).  Violación de la dependencia entre atributos (código postal errado 77777 para la ciudad de Bogotá).  Valores embebidos, cuando en una dirección de residencia se encuentra información que debe ser considerada como un concepto independiente (Cra 34 No. 143-43 Edificio Centenario, Bogotá - Colombia).  Entre otros. Los problemas presentes en una sola fuente se vuelven más complejos cuando se requiere la integración de otras fuentes. Cada fuente puede contener distintos errores y los datos pueden ser representados de manera heterogénea. Esto es porque las fuentes se suelen desarrollar, desplegar, y mantener de forma independiente para satisfacer necesidades específicas. A nivel de esquema, los principales problemas son el conflicto de nombres (objetos similares nombrados de manera diferente) y conflictos de estructura, donde existen diferentes representaciones para el mismo objeto (diferentes relaciones, tipos de datos y restricciones). En este nivel los problemas deben ser abordados a través de traducción e integración de esquemas. Además de los problemas a nivel de esquema, se presentan muchos conflictos a nivel de instancia (conflictos en datos). Con nombres y tipos de datos heterogéneos, los valores pueden representarse e interpretarse de manera diferente a través de las fuentes. Adicionalmente, la información puede ser suministrada a diferentes niveles o hacer referencia a diferentes puntos en el tiempo. En el siguiente ejemplo (Tabla 1, Tabla 2), se muestra el conflicto entre nombres y valores que se puede presentar en diferentes fuentes (representación diferente en dato y estructura). Tabla Cliente (Fuente No 01) CID Nombre 11 Kristen Smith 24 Christian Smith … …. Genero 0 1 …. Tabla 1: Representación del cliente en una fuente de datos.. Tabla Clientes (Fuente No 02) CNo Apellido 493 Smith 125 Smith … …. Nombre Kris L. Christoph. Genero M F …. Tabla 2: Representación del cliente en una segunda fuente.. Adicionalmente a los problemas que puedan existir a nivel de esquema e instancia, existen otro tipo de problemas que se pueden identificar en los datos y que no se tiene en cuenta en muchas de las estrategias de solución actuales. Este problema.

(9) 9. se encuentra asociado a los datos, registros y relaciones que no cumplen con una serie de supuestos que son propios del contexto del negocio y que no se pueden expresar fácilmente a través de condiciones simples sobre las herramientas. Como un ejemplo de este tipo de problemas, se puede mencionar la condición que debe cumplir un niño menor de 30 días (MS = Menor Sin Identificar) cuando se inscribe en el sistema de información en un contexto de Salud. El niño debe ser identificado utilizando el número de documento de la madre si existe o el número de documento del cabeza de familia y un consecutivo que inicia en uno (1) [20].. 2.4 MEDICIÓN DE LA CALIDAD DE DATOS La medición y evaluación de los problemas de calidad de datos se realiza a través de una serie de métricas que se encuentran enmarcadas en las dimensiones de calidad. Una dimensión de calidad es la definición operacional de las métricas, es decir, definen los aspectos claves a tener en cuenta durante el proceso de medición y evaluación. El proceso de medición y evaluación de los problemas de calidad de datos generalmente se realiza en la fase de Assessment / Measurement en las metodologías correspondientes [6]. Las dimensiones más usadas se resumen a continuación [7]:. 2.4.1. PRECISIÓN. Describe la cercanía que existen entre un valor V’ y el valor V considerado como la representación correcta del fenómeno del mundo real [7]. Existen dos tipos de precisión que se pueden medir, la sintáctica, asociada a la formación del dato en si (por ejemplo, “John” es sintácticamente correcto) y la semántica, que corresponde a la validez que tiene una tupla o registro a través de todos sus atributos (por ejemplo, la tupla que contiene el registro de “John” puede ser semánticamente incorrecta debido a que contiene un valor en un atributo que no le corresponde a John). 2.4.1.1 Precisión Sintáctica En la precisión sintáctica existe un interés de chequear si el valor V se encuentra sobre el conjunto de términos en un dominio D. Esta métrica se obtiene usando las funciones de comparación, que evalúan la distancia entre V y los valores del dominio D. En el siguiente ejemplo se ilustra el uso de la función “Edit Distance”, función utilizada para calcular la precisión sintáctica que existe entre cadenas: ID 1 2 3 4. TITLE Casa Blanca Deas Poets Society Rman Holiday Sabrina. DIRECTOR Weir Curtiz. YEAR 1942 1989. 3 0. NoREMAKES. LAST_REMAKE_YEAR 1940 NULL. Wylder NULL. 1953 1964. 0 0. NULL 1985. Tabla 3: Relación Movies donde se presentan varios problemas de precisión sintáctica y semántica.. El valor Rman Holiday contenido en el atributo TITLE de la fila 3 es sintácticamente incorrecto, ya que no corresponde a ningún título de película valido. La métrica Edit Distance calculada entre los dos valores es uno (1), que corresponde a la inserción de un carácter sobre la cadena errada (Roman Holiday). Otro tipo de funciones de comparación entre cadenas han sido planteadas por otros autores, las cuales se mencionan a continuación: 1. 2. 3.. Edit Distance: Mínimo costo de convertir una cadena a otra utilizando una secuencia de inserciones, supresiones, y sustitución de caracteres. N-gramas, bi-gramas, q-gramas: Función de comparación que forma el conjunto de todas las sub cadenas de longitud n por cada cadena. SoundexCode: Agrupar nombres que tengan sonidos similares. El soundexcode de Hilbert y Heilbpr es H416..

(10) 10. 4. 5.. 6.. Jaro Algorithm: Algoritmo de Jaro encuentra en el número de caracteres comunes y el número de caracteres transpuestos en las dos cadenas. Hamming Distance: Cuenta el número de discrepancias entre las dos cadenas. Se utiliza sobre todo para los campos numéricos de tamaño fijo, como códigos postales o números de seguridad social. Por ejemplo, la distancia de Hamming entre 00185 y 00155 es 1 porque hay una diferencia. Smith-Waterman: Dadas dos secuencias, este algoritmo utiliza la programación dinámica para encontrar el menor costo de los cambios que convierten una cadena en otra. El algoritmo funciona bien para abreviaturas, teniendo en cuenta las carencias de los caracteres, y también cuando los registros pierden información o contienen errores tipográficos.. 2.4.1.2 Precisión Semántica Cercanía de un valor V a un valor V’ verdadero. En el ejemplo presentado en la sección anterior Tabla 3, si cambiamos los nombres de los directores de las filas 1 y 2, sintácticamente para la película 1 el nombre Curtiz sería aceptado. Sin embargo, Curtiz no es el director de Casa Blanca; entonces un error de precisión semántica se produce. La precisión semántica se identifica con los valores discretos <si, no> o <correcto, incorrecto>. La técnica para identificar precisión semántica consiste en buscar los mismos datos en diferentes fuentes y encontrar la información correcta por comparación (también requiere de la estrategia de identificación de objetos para conocer si dos tuplas representan a la misma entidad del mundo real o no) [7]. Los principales retos que se deben abordar para resolver el problema de la identificación de objetos son: Identificación: Tuplas en diferentes fuentes pueden no tener identificadores únicos, por lo tanto es necesario que haya una correspondencia a través de claves adecuadas. Estrategia de decisión: Una vez se vinculan a través de una clave coincidente, se debe decidir si las tuplas corresponden a la misma entidad o no. La precisión discutida previamente se refiere a un solo valor de una relación (atributo). Al considerar la precisión de un conjunto de valores en lugar de valores individuales, un concepto más de precisión se puede tratar denominado Duplicación. La duplicación ocurre cuando una entidad del mundo real es almacenada dos veces o más en la base de datos. El problema de duplicación ocurre con mayor frecuencia en archivos o fuentes de datos no estructuradas que no permiten la definición de restricciones de integridad. Lee, Pipino, Funk y Wang [2006], sugieren que las diferentes métricas, incluyendo la precisión sintáctica y semántica, sean medidas utilizando ratios simples entre los valores que cumplen el criterio específico de medición y el número total de valores [8]. Las métricas de calidad de datos pueden ser definidas a nivel de dato, atributo (columna), registro (fila) o relación (tabla o conjunto resultado de una consulta). Específicamente, para la precisión se pueden tener encuentra la siguiente medida:  Precisión de una relación % PRi = (1 - (NTI / NTR)) * 100 NTI = Número de tuplas en la relación que tienen uno o más valores incorrectos. NTR = Total de tuplas sobre la relación. Ri = Relación sobre la cual se aplica la medición. Esta relación puede ser una tabla o el conjunto de resultados que se obtiene de una consulta.  Precisión de un atributo (columna) % PAi = (1 - (NCI / NTC)) * 100 NCI = Número de campos incorrectos sobre el atributo..

(11) 11. NTC = Total de campos sobre el atributo. Ai = Atributo sobre el cual se aplica la medición.  Precisión de un registro (fila) % PFi = (1 - (NCI / NTC)) * 100 NCI = Número de campos incorrectos sobre la fila. NTC = Total de campos sobre la fila. Fi = Fila sobre la cual se aplica la medición.. 2.4.2. COMPLETITUD. Es la medida en que los datos son de suficiente amplitud, profundidad y alcance para realizar una tarea específica [7].. 2.4.2.1 Completitud de datos relacionales La completitud en el modelo relacional puede ser caracterizado con respecto a: (i) la presencia/ausencia y significado de valores nulos, y (ii) la validez de una de las dos hipótesis denominadas Open World Assumption y Closed World Assumption. La presencia de un valor nulo tiene el significado general de un valor que falta, es decir, un valor que se encuentra en el mundo real pero por alguna razón no está disponible. Es importante entender por qué un valor no está presente. Un valor puede no estar presente porque existe pero se desconoce, o porque no existe en absoluto, o porque puede existir pero en realidad no se sabe si existe o no. -. Closed World Assumption (CWA): establece que solo los valores presentes en una tabla relacional r, y no otros, representan los hechos del mundo real.. -. Open World Assumptions (OWA): no se puede establecer ni la verdad ni la falsedad de los hechos que no están representados en las tuplas de r.. De las cuatro posibles combinaciones que surgen de considerar las dos opciones (i) si o no tener en cuenta valores nulos y (ii) OWA y CWA, se tratan a continuación los dos casos más interesantes de medir. -. Modelo sin nulos con OWA: Se introduce el concepto denominado relación referencia. Dada la relación r, la ref(r) (relación referencia) es la relación que contiene todas las tuplas que satisfacen el esquema relacional de r.. Como un ejemplo, si Dept es una relación que representa los empleados de un departamento, y un empleado especifico del departamento no se encuentra representado en la relación, entonces la tupla que corresponde al empleado faltante esta en ref(Dept), y ref(Dept) difiere de departamento en exactamente una tupla. Con base en la relación referencia, la completitud de la relación r es medida en el modelo sin nulos como la fracción de tuplas actualmente representadas en la relación r, con respecto al total de tuplas en ref(r).. Ejemplo, número de ciudadanos registrados en el municipio de Roma es de 6 millones. Suponemos que la compañía almacena datos de los ciudadanos para propósitos de negocio; si la cardinalidad de la relación almacenando los datos es de 5,4 millones entonces la completitud de la relación C(r) es de 0,9. -. Modelo con nulos y CWA: La completitud se puede calcular considerando la granularidad de los elementos del modelo, a nivel de valor (dato), tupla (fila), atributo (columna) o relación (tabla). Por ejemplo, si la fila de una.

(12) 12. tabla contiene un valor NULO en cualquiera de los cinco atributos que posee, podemos decir que la completitud de la tupla es de 0.8. De la misma forma, las métricas de la dimensión completitud se pueden expresar como ratios simples de la siguiente manera [8]:  Completitud de valor (dato): Esta medida se define por la existencia o no del dato según un criterio definido (NULL, vacio, errado, etc.).  Completitud de registro (fila) % CFi = (1 – (NAI / NTA)) * 100 NAI = Número de atributos incompletos. NTA = Número total de atributos de la fila. Fi = Fila evaluada.  Completitud de atributo (columna) % CAi = (1 - (NVI / NTV)) * 100 NVI = Número de valores incompletos. NTV = Número total de valores en el atributo. Ai = Atributo evaluado.  Completitud de relación (tabla o conjunto resultado de una consulta): % CRi = (1 - (NRI / TRR)) * 100 NRI = Número de registros incompletos. TRR = Total de registros de la relación. Ri = Relación evaluada.. 2.4.3. CONSISTENCIA. Permite medir los errores generados por la violación de reglas semánticas definidas sobre un conjunto de ítems, donde los ítems pueden ser registros de tablas relacionales o filas en un archivo. Con referencia a la teoría relacional, las restricciones de integridad son una instanciación de tales reglas. En estadísticas, los datos de edición son otro ejemplo de reglas semánticas que permiten chequear la consistencia.. 2.4.3.1 Restricciones de Integridad Las restricciones de integridad son propiedades que deben cumplir todas las instancias de un esquema de base de datos. Aunque las restricciones de integridad son típicamente definidas a nivel de esquemas, ellas pueden al mismo tiempo ser chequeadas sobre una instancia específica del esquema que actualmente representa la extensión de la base de datos. Categorías de restricciones de integridad: -. Restricciones de intrarrelación: Pueden considerar atributos simples (también llamadas restricciones de dominio) o múltiples atributos de una relación.. Vamos a considerar la relación Empleado con los siguientes campos Nombre, Apellido, Edad, Años Trabajo, y Salario. Un ejemplo de restricción de dominio definida sobre el esquema es “Edad está incluida entre 0 y 120”. Un ejemplo de restricción de integridad de múltiples atributos es “Si los años de trabajo son menores a 3, el salario no puede ser mas de 25.000 Euros por año”..

(13) 13. -. Restricciones de interrelación: Involucra atributos de más de una relación.. Considerando la siguiente tablas de películas y una tabla adicional denominada “OscarAwards” especificando los premios Oscar ganados por cada película, la cual incluye un atributo Año correspondiente al año en el que el premio fue asignado. ID 1 2 3 4. TITLE Casa Blanca Deas Poets Society Rman Holiday Sabrina. DIRECTOR Weir Curtiz. YEAR 1942 1989. 3 0. NoREMAKES. LAST_REMAKE_YEAR 1940 NULL. Wylder NULL. 1953 1964. 0 0. NULL 1985. Tabla 4: Relación Movies donde se presentan problemas de calidad de datos.. Un ejemplo de restricción de interrelación dice “El año de la relación Movies debe ser igual al atributo año en la tabla OscarAwards”. Muchas de las restricciones de integridad consideradas son dependencias. Las siguientes tres tipos de dependencias son consideradas: -. Dependencia de clave: Dada una relación r, que se define por un conjunto de atributos, se dice que un subconjunto K de los atributos mantienen una dependencia de clave en r, sino hay dos filas de r que tengan el mismo valor de la clave. Por ejemplo, un atributo similar al SocialSecurityNumber puede servir como clave en cualquier instancia de la relación Person. Cuando las restricciones de claves de dependencia se aplican, no se producen duplicados dentro de la relación.. -. Dependencia de inclusión: Es un tipo común de restricción, también conocida como restricción referencial. Una dependencia de inclusión sobre la instancia de una relación r dice que algunas columnas de r son contenidas en otras columnas de r o en las instancias de otra instancia s relacional. Una restricción de llave foránea es un ejemplo de una dependencia de inclusión, afirmando que las columnas que hacen referencia en una relación deben estar contenidas en la columna llave de la relación de referencia.. -. Dependencia funcional: Dada una instancia relacional r, sean X y Y dos conjuntos de atributos no vacios en r. r satisface la dependencia funcional X  Y ( determina), si se cumple lo siguiente para cada par de tuplas t1 y t2 en r:. If t1.X = t2.X, then t1.Y = t2.Y, donde la notación t1.X significa la proyección de la tupla t1 en los atributos de X. Por ejemplo, si se conoce el valor de FechaNacimiento podemos conocer el valor de Edad. Propiedades de la dependencia funcional: -. Dependencia funcional reflexiva (dependencia trivial): A  B, si B está contenida en A. Ejemplo, si la dirección o el nombre están contenidos en el DNI (Documento Nacional de Identidad), entonces con el DNI podemos determinar la dirección o el nombre.. -. Dependencia funcional aumentativa: A  B, entonces entonces AC  BC.. -. Dependencia funcional transitiva: Sean X, Y, Z tres atributos, si X  Y  Z entonces X  Z. Ejemplo, FechaNacimiento Edad  Conducir.. -. Propiedades deducidas: o Unión: Si X  Y, y X  Z entonces X  YZ. o Pseudo-transitiva: Si X  Y, y WY  Z entonces WX  Z. o Descomposición: Si X  Y, y Z está incluida en Y entonces X  Z.. . O más cómodamente A  B.

(14) 14. 2.4.3.2 Data Edits Las restricciones de integridad fueron discutidas en el modelo relacional como una categoría especifica de consistencia de reglas semánticas. Sin embargo, cuando los datos no son relacionales las reglas de consistencia no se pueden definir. Como un ejemplo, en el campo estadístico, los datos procedentes de cuestionarios aplicados en censos tienen una estructura correspondiente al esquema de cuestionario. Las reglas semánticas están definidas sobre esta estructura de manera similar que las restricciones de integridad. Tales reglas, llamadas Edits, son menos poderosas que las reglas de integridad referencial porque ellas no se basan en un modelo de datos como el relacional. Data editing es definida como la tarea de detectar inconsistencias formulando reglas que deben ser respetadas por todo los conjuntos de respuestas correctas. Tales reglas son expresadas como edits, las cuales denotan las condiciones de error. Como un ejemplo, una respuesta inconsistente a un cuestionario puede ser declarada como: marital_status = “married”, age = “5 years old”. La regla para definir este tipo de inconsistencias puede ser la siguiente: If marital_status is married, age must not be less than 14. La regla en forma de un edit. marital_status = married ^ age< 14 De la misma forma, las métricas de la dimensión consistencia se pueden expresar como ratios simples de la siguiente manera [8]: Criterios de evaluación: - C1 = Criterio 1 de consistencia para el registro. - C2 = Criterio 2 de consistencia para el registro. - Cn = Criterio n de consistencia para el registro. CoCiRj = (NRC / NTR) * 100 NRC = Número de registros que cumplen Ci. NTR = Número total de registros Rj. Ci = Criterio de consistencia evaluado. Rj = Relación sobre la cual se aplica la validación. Esta relación puede ser una tabla o el conjunto de resultados que se obtiene de una consulta.. 2.4.4. RELACIONADAS CON EL TIEMPO. Un aspecto importante de los datos es el cambio y la actualización en el tiempo. Las principales dimensiones propuestas para la caracterización son:. 2.4.4.1 Rapidez (Currency) Que tan pronto los datos son actualizados en el tiempo. Por ejemplo, si la dirección de una persona es actualizada, y esta corresponde a la dirección donde vive la persona entonces la rapidez es alta. La rapidez puede ser típicamente medida con respecto a la última actualización de los metadatos, que corresponde a la última vez que los datos específicos fueron actualizados. Para tipos de datos que cambian con frecuencia fija, los metadatos de la última actualización permiten calcular la rapidez directamente. Por otro lado, para los tipos de datos cuya frecuencia de cambio varía, una forma de calcular la rapidez es el promedio de la frecuencia de cambio. Como un ejemplo, si las fuentes de datos almacenan direcciones de residencia las cuales se estima que cambian cada 5 años, y una de ellas con el reporte de actualización de un mes antes de la fecha de observación puede ser considerada como actual; en contraste, si el reporte de la fecha es de 10 años antes de la fecha observación, se considera que no es actual..

(15) 15. Una métrica más compleja puede ser definida para medir esta dimensión: Currency = Age + (DeliveryTime – InputTime) Age mide la antigüedad de la unidad de datos cuando se recibe. DeliveryTime es el momento cuando el dato se entrega al cliente, e InputTime es el momento en el cual la unidad de datos se obtiene.. 2.4.4.2 Volatilidad (Volatility) Frecuencia con la cual los datos varían en el tiempo. Por ejemplo, las fechas de nacimiento tienen cero (0) como grado de volatilidad mientras el nivel de inventario de una compañía posee un alto grado. La volatilidad se define como la longitud en tiempo para el cual el dato sigue siendo válido.. 2.4.4.3 Oportunidad (Timeliness) Datos disponibles en un momento determinado para cumplir con una tarea específica. Una posible medida consiste de (i) la medida de rapidez y (ii) un chequeo que los datos se encuentren disponibles antes del tiempo de uso previsto. max{0, 1 − (currency / volatility)} Los rangos de oportunidad son 0 y 1, donde 0 significa mala oportunidad y 1 significa buena oportunidad. Las métricas de la dimensión tiempo, también pueden ser expresadas como ratios simples [8]. A continuación, se presenta un ejemplo de una de las métricas: Criterios de evaluación: - C1: 0 - 1 día (Bueno). - C2: 1 - 3 días (Aceptable). - C3: 3 - 5 días (Regular). - C4: Más de 5 días (Malo). ActRi = (Fecha de Entrega al Usuario – Fecha de Ingreso al Sistema) Ri = Registro entregado al usuario. % Act (Ci) = (NRC / NTR) * 100 NRC = Número de registros cumplen Ci. NTR = Número total de registros. Ci = Criterio de evaluación. La Tabla 5 resume el conjunto de dimensiones que se pueden utilizar para validar la calidad de datos. DIMENSIÓN. DESCRIPCIÓN. TIPO. Sintáctica. Precisión. Describe la cercanía que existen entre un valor V’ y el valor V considerado como la representación correcta del fenómeno de la vida real.. Semántica. DESCRIPCIÓN En la precisión sintáctica existe un interés de chequear si el valor v se encuentra sobre el conjunto de términos en un dominio D. Corresponde a la validez que tiene una tupla o registro a través de todos sus atributos.. MEDICIÓN - Edit Distance. - N-gramas, Bi-gramas, Q-gramas. - Hamming Distance, etc. La técnica para identificar precisión semántica consiste en buscar los mismos datos en diferentes fuentes y encontrar la información correcta por comparación..

(16) 16. Completitud. Es la medida en que los datos son de suficiente amplitud, profundidad y alcance para realizar una tarea específica.. Closed World Assumption (CWA): establece que solo los Sin nulos con valores presentes en una tabla OWA relacional r, y no otros, representan los hechos del mundo real.. Con nulos y CWA. Closed World Assumption (CWA): establece que solo los valores presentes en una tabla relacional r, y no otros, representan los hechos del mundo real. - Restricciones de intrarelación: Pueden considerar atributos simples (también llamadas restricciones de dominio) o múltiples atributos de una relación.. Consistencia. Permite medir los errores generados por la violación de reglas semánticas definidas sobre un conjunto de ítems, donde los ítems pueden ser registros de tablas relacionales o filas en un archivo.. Restricciones - Restricciones de interrelación: de Integridad Involucra atributos de más de una relación. Muchas de las restricciones de integridad consideradas son dependencias (Llave, Inclusión, Funcionales).. Data Edits. Rapidez (Currency). Relacionadas con el tiempo. Un aspecto importante de los datos es el cambio y la actualización en el tiempo.. Volatilidad. Oportunidad. Se aplican cuando el modelo no es relacional. Por ejemplo, los datos procedentes de cuestionarios aplicados en censos tienen una estructura correspondiente al esquema de cuestionario.. Que tan pronto los datos son actualizados en el tiempo. Por ejemplo, si la dirección de una persona es actualizada, y esta corresponde a la dirección donde vive la persona entonces la rapidez es alta.. Frecuencia con la cual los datos varían en el tiempo. Por ejemplo, las fechas de nacimiento tienen cero (0) grado de volatilidad mientras el nivel de inventario de una compañía posee un alto grado.. Datos disponibles en un momento determinado para cumplir con una tarea específica.. C(r) = |r| / ref (r)|, - r, tuplas actualmente representadas en la relación. - ref(r) (relación referencia), relación que contiene todas las tuplas que satisfacen el esquema relacional de r. Se puede calcular considerando la granularidad de los elementos del modelo, a nivel de valor (dato), tupla (fila), atributo (columna) o relación (tabla). Una restricción de dominio definida sobre un esquema es “Edad está entre 0 y 120”. Se puede calcular identificando los atributos que cumplan la restricción o no. Una restricción de interrelación dice “El año de la relación Movies debe ser igual al atributo año en la tabla OscarAwards”. Se mide identificando que relaciones cumplen con la condición o no. La regla para definir este tipo de inconsistencias puede ser la siguiente: If marital_status is married, age must not be less than 14. Se mide identificando los conceptos que no cumplen con la condición o no. La rapidez puede ser típicamente medida con respecto a la última actualización de los metadatos, que corresponde a la última vez que los datos específicos fueron actualizados. Una métrica más compleja puede ser: Currency = Age + (DeliveryTime – InputTime). La volatilidad se define como la longitud en tiempo para el cual el dato sigue siendo válido.. Una posible medida consiste de (i) la medida de rapidez y (ii) un chequeo que los datos se encuentren disponibles antes del tiempo de uso previsto. max{0, 1 − (currency / volatility)}, 0 buena, 1 mala oportunidad.. Tabla 5: Resumen dimensiones para evaluar la calidad de los datos..

(17) 17. 2.5 METODOLOGÍA PARA CALIDAD DE DATOS Una metodología de calidad de datos se define como un conjunto de líneas guía y técnicas que, a partir de la información de entrada que describe un contexto de aplicación determinado, define un proceso racional para evaluar y mejorar la calidad de los datos [7]. Aunque existen diversas metodologías para la calidad de los datos, existen tres etapas generales sobre las cuales se fundamentan: La primera de ellas es la fase de Construcción de Estado, la cual busca obtener información de los procesos y servicios organizacionales del dominio específico de análisis. Adicionalmente, permite obtener información de las fuentes de datos, procesos relacionados con la gestión, necesidades de calidad y costos. La segunda fase corresponde a la Medición/Evaluación de la calidad de los datos. Como su nombre lo indica esta fase está determinada por la medición de la calidad a través de las diferentes dimensiones; y por el término evaluación, que indica que los resultados de la medición deben ser comparados con valores referencia para determinar el diagnóstico final. Por último, se presenta la fase de Mejoramiento en la cual se eligen los pasos, estrategias y técnicas para alcanzar nuevos objetivos de calidad de datos (identificar causas de error, definir soluciones de mejora, definición de procesos de control, monitoreo, etc.). A lo largo de varios años se han definido metodologías enmarcadas en actividades propias de las fases y orientadas a dominios específicos. En la Tabla 6 se presenta la lista de algunas metodologías que han sido planteadas: ACRÓN.. NOMBRE. TDQM DWQ TIQM AIMQ CIHI DQA IQM. Total Data Quality Management The Datawarehouse Quality Methodology Total Information Quality Management A methodology for information quality assessment Canadian Institute for Health Information methodology Data Quality Assessment Information Quality Measurement. ISTAT AMEQ. ISTAT methodology Activity-based Measuring and Evaluating of product information Quality methodology Cost-effect Of Low Data Quality Data Quality in Cooperative Information Systems Methodology for the Quality Assessment of Financial Data Comprehensive methodology for Data Quality management. COLDQ DaQuinCIS QAFD CDQ. REFERENCIA Wang, 1998 Jeusfeld, 1998 English, 1999 Lee, 2002 Long y Seko, 2005 Pipino, 2002 Eppler y Münzenmaier, 2002 Falorsi, 2003 Su y Jin, 2004 Loshin, 2004 Scannapieca, 2004 De Amicis y Batini, 2004 Batini y Scannapieca, 2006. Tabla 6: Listado de metodologías desarrolladas para la calidad de datos.. Carlo Batini y Monica Scannapieca [7] reúnen las ventajas de metodologías de años anteriores y plantean la guía denominada “Comprehensive methodology for Data Quality management (CDQ)”, la cual cuenta con una serie de fases y actividades que pueden ser ajustadas de acuerdo al escenario donde se aplique el proceso de calidad de datos. Las entradas y salidas que están asociadas a la metodología se presentan en la Figura 3..

(18) 18. Figura 3: Entradas y salidas de la metodología de calidad de datos.. Bases de datos, proceso, flujos y dimensiones hacen parte de los conceptos de entrada para que la metodología apoye de la mejor manera el proceso de calidad y genere los mejores resultados a la luz de las estrategias y técnicas de mejora que garanticen el proceso. Las fases y actividades que se enmarcan en la metodología son las siguientes:. Figura 4: Fases y actividades de la metodología de calidad de datos.. FASE I – State Reconstruction: En esta fase se pretende identificar y entender las bases de datos, procesos y reglas de negocio que harán parte del proceso de calidad de datos aplicado en la organización. Las actividades que hacen parte de la fase son: Identificar las bases de datos: Identificar las bases de datos y objetos sobre los cuales se aplica el proceso de calidad. Identificar los procesos de negocio: Identificar los procesos de negocio que generan datos para los sistemas de información. Sobre los procesos de negocio se deben identificar puntos críticos que puedan generar errores o inconsistencias sobre la información. Identificar normas y reglas de la organización que controlan los procesos de negocio: En esta actividad se identifican las normas y reglas de negocio por las cuales se rige la organización y sus procesos. Las reglas de negocio son sentencias que definen o restringen algún aspecto del negocio. FASE II – Assessment / Measurement: Como su nombre lo indica esta fase está determinada por la medición de la calidad de los datos a través de las diferentes dimensiones y por la evaluación, la cual indica que los resultados de la medición deben ser comparados con valores referencia para determinar el diagnóstico final. Las actividades que hacen parte de la fase son:.

(19) 19. Elección de variables: Identificar, describir y clasificar las variables primarias que serán valoradas (atributos de datos principales). Las variables son identificadas y clasificadas de acuerdo a su significado y rol. Las posibles caracterizaciones son cualitativa/categórica, cuantitativo/numérico y fecha/hora. Análisis: En esta actividad se identifican las dimensiones y restricciones de integridad que serán medidas sobre los datos. El objetivo final es descubrir las causas principales de los datos erróneos, como la carga de datos no estructurados, carga de datos no controlada y procesos de actualización. El resultado del análisis sobre las dimensiones seleccionadas conduce a un informe con la identificación de los errores. Valoración objetiva: Niveles o valores apropiados son definidos para la evaluación y cuantificación del nivel de calidad de datos global. El número de errores para las diferentes dimensiones y los atributos de datos se evalúan con métodos estadísticos y/o empíricos; y posteriormente, se normalizan y se resumen. Valoración subjetiva: Esta evaluación se obtiene mediante la valoración de: (i) un experto del negocio, que analiza los datos desde un punto de vista de procesos de negocio, (ii) un operador, que utiliza datos diarios dentro de la organización, y (iii) un experto en calidad de datos, que tiene la función de analizar los datos y examinar su caracterización. Comparación: Finalmente, se ejecuta una comparación entre la valoración objetiva y subjetiva. Por cada variable y dimensión de calidad de datos, el experto analiza las discrepancias para detectar causas de errores y encontrar alternativas de solución para corregirlos. FASE III – Improvement: Corresponde a la elección de pasos, estrategias y técnicas para alcanzar los objetivos de calidad trazados (identificar causas de error, definir soluciones de mejora, estrategias de corrección, procesos de control, monitoreo, etc.). Las actividades que hacen parte de la fase son: Asignar responsables para flujos y datos: Es necesario definir las personas responsables a cargo de los flujos de información y datos, quienes deben gestionar, monitorear y controlar las estrategias de calidad aplicadas. Identificar causas de error: Identificar la causa de los errores presentados sobre las variables elegidas, medidas y valoradas, permite buscar la mejor estrategia para corregir las inconsistencias identificadas sobre las variables. Elegir estrategias y técnicas de mejora: De acuerdo a los tipos de errores y causas identificadas, se elige la estrategia y técnica adecuada para corregir y controlar los errores. Diseñar e implementar solución de mejora: Existen diferentes tipos de solución que pueden ser aplicadas sobre los datos y procesos para corregir las inconsistencias, en esta etapa se diseñan e implementan en los sistemas de información y bases de datos de la organización. Gestionar y monitorear estrategias de mejora: Después de diseñar e implementar la solución de mejora, es necesario monitorear y controlar los resultados obtenidos para seguir mejorando las estrategias aplicadas e incluir nuevas variables.. 2.6 HERRAMIENTAS PARA CALIDAD DE DATOS En la actualidad, las herramientas de calidad de datos continúan experimentando un crecimiento considerable debido a la demanda del mercado en casos de Business Intelligence (BI) y Master Data Management (MDM). Grandes vendedores continúan entrando en este espacio mediante la adquisición de proveedores más pequeños o especialistas (por ejemplo, la adquisición de Datanomic por parte de Oracle), nuevos vendedores continúan emergiendo como es el caso de Talend y Ataccama. Cuando se evalúan las ofertas dadas por el mercado, las organizaciones deben valorar no solo la amplitud de las capacidades funcionales que posee (profiling, parsing, standarization, marching, monitoring and enrichment), sino también el grado en el cual estas funcionalidades pueden ser fácilmente entendidas, administradas y aprovechas por los recursos del negocio en.

(20) 20. lugar del personal de TI. Otro importante aspecto que debe ser valorado es la facilidad con la cual estas herramientas puedan ser embebidas en flujos de trabajo de procesos de negocio o iniciativas de BI y MDM. Los ingresos asociados a las herramientas de calidad de datos para el año 2010 fue de aproximadamente $800 millones, mostrando un fuerte crecimiento del 12.6% sobre el 2009. Se espera que para los próximos cinco años se logre un crecimiento del 16%, apoyado por el interés en calidad de datos de las verticales: financiera, gobierno, comunicaciones y salud [9]. Gartner - Technology Research en el 2011, calificó las iniciativas presentadas por las casas de software para tratar los problemas y necesidades de calidad de datos. Gartner, a través de su cuadrante mágico, muestra a las compañías que lideran el desarrollo de estas iniciativas [9].. Figura 5: Cuadrante mágico de Gartner 2011 para herramientas de calidad de datos.. DataFlux, Informatica, IBM, SAP y Trillium, son las empresas que lideran y se posicionan entre las mejores en el cuadrante (lado superior derecho). La estrategia de calidad de datos de la mayoría de estas herramientas consiste en ofrecer un conjunto de transformaciones (componentes pre-construidos), los cuales ejecutan validaciones definidas a un conjunto de datos de entrada. En la Figura 6 se presentan las transformaciones de calidad de datos más comunes que poseen las herramientas.. Figura 6: Funcionalidades de calidad de datos direccionadas por las herramientas de calidad de datos..

(21) 21. •. Gender Analysis (DataFlux): determina el género de una persona tomando como base el campo nombre.. •. Parsing (DataFlux): busca valores embebidos en un atributo y produce los componentes o tokens conceptuales dentro del elemento (por lo general se aplica para nombres, para identificar primer nombre, segundo nombre, apellidos etc.).. •. Standarization (DataFlux, IBM Data Stage): el proceso de estandarización intenta asignar significado semántico a tokens validos e inválidos, para revisar la relación entre los valores contenidos en la representación original y sugerir opciones para llevar el dato hacia una forma estándar.. •. Global Address Cleanse (SAP Data Services, DataFlux): identifica, analiza, valida y corrige los datos globales de direcciones tales como número primario, nombre principal, tipo primario, direccional, etc. Este tipo de transformaciones necesitan uno o más motores (diccionarios) para procesar los datos.. •. Data Cleanse (SAP Data Services, algunas funcionalidades en DataFlux): la transformación se utiliza para identificar y analizar el nombre, cargo, y datos de la empresa, número de teléfono, número de seguro social y direcciones de correo electrónico. También puede asignar el género, prefijos para nombres, saludos, y convierte las fuentes de entrada a un formato estándar.. •. Match (SAP Data Services, DataFlux, IBM Data Stage): responsable de la ejecución de correspondencia con las reglas de negocio que se defina. La transformación envía los registros coincidentes y únicos a la siguiente transformación en el flujo de datos. Para obtener mejores resultados, los datos sobre los cuales se está tratando de encontrar coincidencias deben estar limpios. Por lo tanto, se debe colocar después de las transformaciones Address Cleanse y Data Cleanse.. Otras funcionalidades que son de interés para las empresas son: •. Profiling: Análisis de los datos para capturar estadísticas (metadatos) que permiten conocer la calidad y ayudan a identificar problemas.. •. Enrichment: Enriquecer el valor de los datos internos agregando atributos relacionados de otras fuentes.. Para que la transformación ejecute la tarea de validación, esta debe estar ubicada como un paso dentro del flujo de datos que procesa la entrada. En general, el flujo de datos está compuesto por tres secciones o pasos: Entrada, Proceso y Salida. -. La entrada es un elemento que se utiliza para consumir el conjunto de datos que va a ser procesado dentro del flujo. El proceso es el conjunto de transformaciones que son utilizadas para tratar los datos según los criterios definidos por el desarrollador. La salida es un elemento que lleva los datos procesados a un medio de almacenamiento, ya sea un archivo plano, tabla de datos, Excel, etc.. En la Figura 7, se puede observar un ejemplo de un flujo de datos donde se posiciona la entrada, diferentes transformaciones de proceso y una salida. El objetivo fin del flujo es la estandarización de un conjunto de registros de clientes.. Figura 7: Flujos de procesamiento de datos..

(22) 22. Figura 8: Objetivo final del flujo.. 2.7 SÍNTESIS DEL ESTADO DEL ARTE Actualmente, las organizaciones se enfrentan a problemas de calidad en los datos e información que se almacena en sus fuentes transaccionales y de análisis. Problemas que surgen debido a la interacción de usuarios y comunicación de aplicaciones con los sistemas de información y módulos computacionales que apoyan las operaciones diarias de la compañía (procesos de negocio). Estrategias, metodologías y herramientas han sido planteadas y desarrolladas con el objetivo de tratar los diferentes tipos de problemas presentes en las fuentes, desde inconsistencias en la representación de los datos (esquema) hasta el contenido en sí mismo (instancia). Dada la diferencia entre las organizaciones y el uso que se le da a la información, surgen otro tipo de condiciones asociadas al contexto que deben cumplir los datos y que actualmente no han sido consideradas por las diferentes estrategias que tratan la dificultad. En la mayoría de las estrategias para tratar el problema de calidad de datos, se aplican medidas para dimensionar cada una de las inconsistencias presentes, las cuales se convierten en el objetivo principal de mejora para la organización. Las diferentes medidas que se pueden aplicar se encuentran enmarcadas por las dimensiones de calidad, precisión, completitud, consistencia y aspectos relacionados con el tiempo. Algunos autores sugieren plasmar el resultado de las medidas usando métricas simples que se calculan tomando el número de valores que cumplen un criterio especifico sobre el número total de valores evaluados. Las actividades que buscan identificar las mejores estrategias de calidad para aplicar sobre la información, incluyendo la aplicación de métricas, están determinadas por guías metodológicas definidas a lo largo de los años de investigación que se ha dado al tema. Aunque existen diferentes metodologías, cada una de ellas con un objetivo específico trazado, la gran mayoría se fundamentan en tres fases Construcción de Estado, Medición / Valoración y Mejora. La primera fase presenta actividades que apoyan el entendimiento del escenario donde se aplica el proceso, mostrándose así la especificación de las fuentes y datos que participan en la validación. La segunda fase, como su nombre lo indica, busca medir y comparar con valores de referencia las inconsistencias encontradas en los datos para que sea evaluada por los expertos del negocio y definir si hacen parte del proceso de validación. Finalmente, se identifican estrategias de mejora para alcanzar los objetivos de calidad trazados por la organización. Pese a que la metodología ofrece actividades que guían el proceso, algunas de ellas no se encuentran orientadas hacia la concepción de otro tipo de validaciones con base en el contexto, lo que corresponde a un nuevo problema que enfrentan las organizaciones actuales. La mayoría de las estrategias de mejora elegidas por la organización poseen un cimiento tecnológico, aplicaciones y herramientas que ofrecen un conjunto de transformaciones u operadores (compontes pre-construidos) para ejecutar las validaciones definidas a un conjunto de datos. Entre los operadores más conocidos se encuentran Parsing, Standarization, Matching, cuyo objetivo es tratar de encontrar información faltante sobre los datos. La orientación que han dado las diferentes casas de software al desarrollo de dichos operadores, ha sido hacia la solución de problemas de carácter intrínseco.

(23) 23. y no contextual, es decir, la construcción de transformaciones como medio para expresar condiciones específicas traducidas técnicamente por los desarrolladores, mientras tanto, las organizaciones se enfrentan a una necesidad de llevar las validaciones a un nivel más alto en donde se incluyen temas propios del contexto. Tratar de resolver esta nueva necesidad con herramientas convencionales, da como resultado la construcción de flujos de validación complejos con el uso de varias transformaciones, incluso la adición de código en casos especiales. Para aplicar una modificación o ajuste a una condición especifica dentro del flujo, se hace necesario acudir al área de TI experta en la herramienta para que apoye dicha actividad. El enfoque de un sistema de producción de reglas, solución propuesta en el presente documento, es la representación de conocimiento para expresar lógica proposicional y de primer orden en una manera concisa, no ambigua y declarativa, permitiendo a los analistas del negocio participar activamente en la concepción del proceso de validación expresando fácilmente situaciones propias al contexto. El núcleo principal de una estrategia de validación que utiliza reglas de negocio, es el conjunto en sí de reglas definidas, por esta razón el uso de trasformaciones se reduce a las necesarias para definir que campos validar, que reglas aplicar en el proceso y el registro de la auditoria.. 3.. DQ-RULES - PROPUESTA. Debido a la necesidad presente sobre las estrategias de calidad de datos existentes, con la investigación propuesta se buscó desarrollar un módulo que permitiera incluir reglas de negocio de un contexto determinado en procesos de validación y corrección de datos. El principal reto a enfrentar fue el entendimiento del modelo e integración del concepto de reglas de negocio en una solución tecnológica, para lo cual, se realizó un proceso de investigación sobre las bases que soportan la teoría; y se buscó la estrategia tecnológica para integrar la solución al mundo real. Adicionalmente, fue necesario construir varios componentes o elementos de software que conforman la solución tomando como base los conceptos de investigación tratados.. 3.1 PRINCIPIOS DE LA INVESTIGACIÓN Como primer reto se abordó el entendimiento del concepto de reglas de negocio en las organizaciones y como ellas pueden ser llevadas a una estrategia de uso tecnológico. En este punto fue necesario definir, el qué y el cómo las reglas de negocio se representan teórica y técnicamente para que fueran incorporadas en la solución.. 3.1.1. CONCEPTUALIZACIÓN DE LAS REGLAS DE NEGOCIO. Una regla de negocio es una sentencia que define o restringe algún aspecto del negocio. Con las reglas de negocio se pretende hacer valer la estructura empresarial, controlar o influenciar el comportamiento de la empresa [10, 11, 12]. Las reglas de negocio se pueden ver desde dos perspectivas, la primera desde la vista del negocio (Zachman fila dos) que se refiere a cualquiera de las restricciones que se aplican al comportamiento de las personas dentro de la organización, desde las restricciones personales hasta los procedimientos a su cargo que se deben ejecutar en su labor diaria. La otra perspectiva desde los sistema de información (Zachman fila tres), que corresponde a los hechos que son registrados como datos y las restricciones sobre los cambios que puedan afectar el valor de estos hechos. En la guía Business Rules Project se decide direccionar el desarrollo del tema reglas de negocio utilizando la perspectiva de sistema de información, la cual ofrece tres beneficios prácticos para el proyecto [10, 11, 12]: el enfoque de la perspectiva del sistema de información hace que el problema sea tratable, es decir, es posible entender y modelar reglas de negocio como restricciones sobre los datos; dos, el proyecto intencionalmente no trata con categorías de problemas generales relacionadas con el comportamiento de las personas en la organización, sino con la definición de las reglas de negocio asociada a los datos en su mínima expresión o mínimo nivel de granularidad; y por último, el estudio solamente trata con problemas de estructura de información, por esta razón, en el proyecto no se tiene que lidiar con acontecimientos de forma implícita..