I Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación TRABAJO DE DIPLOMA Título: “Sistema para el análisis de datos DBAnalyzer, una nueva versión”. Autor: Arazay Armas Santos Tutores: MSc. Beatriz López Porrero Dr. Ramiro Pérez Vázquez Villa Clara 2009 DECLARACIÓN DE AUDITORĺA Hago constar que el presente trabajo fue realizado en la Universidad Central Marta Abreu de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencias de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad. ____________________________ Firma de los autores Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada. _________________________ __________________________ Firma de los tutores Firma del jefe del Seminario I PENSAMIENTO “Inteligencia más carácter, el objetivo de una verdadera educación.” Dr. Martin Luther King Jr II DEDICATORIA A mis padres por la buena educación que me han dado y por siempre estar de mi lado. A mis hermanos por apoyarme y ayudarme en todo lo que necesité. Los quiero mucho a todos. III AGRADECIMIENTOS Le agradezco a mi familia en especial a todos los que siempre me apoyaron, mis padres y mis hermanos. A mis amigos: Mavelyn, Daylin, Analylis, Diagnyt, Noraida y Yuniesky, por ser quienes aguantan mis lágrimas, mis risas y mis genios, sin ellos no hubiese logrado llegar al final. A mi novio Yandy que me ha ayudado y apoyado en todo este proyecto con mucho cariño. A mis otros amigos que también sé que puedo contar con ellos para lo que haga falta. A mis tutores Beatriz López y Ramiro Vázquez por asesorarme y ayudarme en el transcurso de la investigación. A todos los profesores que a lo largo de estos años han influido en mi formación profesional. IV RESUMEN La detección de errores en los datos mediante el análisis de datos es fundamental en el proceso de limpieza. En esta fase se encontrarán varios tipos de errores y se podrá, según la taxonomía trazada, determinar de qué manera corregir los mismos. La herramienta de detección de errores DBAnalyzer, realiza el perfil de los datos para, según medidas estadísticas, determinar, en el caso de valores de atributos individuales, errores potenciales, y además determina relaciones entre pares de atributos del mismo dominio cuyo incumplimiento debe ser analizado también como posible error. Teniendo en cuenta que pueden existir en los datos de diferentes dominios relaciones que no han sido descubiertas es que nuestro trabajo se ha encaminado a dotar al DBAnalyzer de la posibilidad de utilizar la técnica de minería de datos por reglas de asociación, en este caso reglas que involucren más de dos atributos con la utilización del algoritmo Apriori, para detectar otros tipos de errores que puedan aparecer en Sistemas de Bases de datos de nuestro entorno. V ABSTRACT The detection of errors in the data by means of the analysis of data is essential in the cleaning process. During this phase, it will be found different types of errors and it will be able to, according to the traced taxonomy, determine the best way to correct them. DBAnalyzer program to find errors carries out the profile of the data for, according to statistical measures, to determine, in the case of individual attributes values, potential errors, and it also determines relationships between two pairs of attributes of the same domain whose nonfulfillment should be also analyzed as a possible error. Having in mind that, there might be in the different domains data relationships that have not been discovered yet, our work has been guided to provide the DBAnalyzer with the possibility of using the data mining technique based on association rules, and in this case, rules that involve more than two attributes with the use of the Apriori algorithm, to detect some other types of errors that might appear in Data bases Systems around us. VI TABLA DE CONTENIDOS INTRODUCCIÓN....................................................................................................... 1 CAPÍTULO I Marco teórico........................................................................................ 4 1.1 Limpieza de datos .............................................................................................. 4 1.2 Herramientas existentes en Limpieza de datos. ................................................. 7 1.3 Detección de errores......................................................................................... 14 1.4 Reglas de asociación. ....................................................................................... 17 1.4.1 Ideas básicas de reglas de asociación. ....................................................... 18 1.4.2 Clasificación de reglas de asociación ........................................................ 19 1.5 Algoritmos de búsqueda de reglas de asociación............................................. 20 1.6 Reglas de asociación en la detección de errores .............................................. 21 1.7 Conclusiones del capítulo ................................................................................ 23 CAPÍTULO II Análisis y diseño de una nueva versión del software DBAnalyzer... 24 2.1 Descripción del algoritmo Apriori. .................................................................. 24 2.2 Remodelación del sistema................................................................................ 28 2.2.1 Diagrama de casos de uso.......................................................................... 28 2.2.2 Tabla de eventos ........................................................................................ 32 2.2.3 Descripción de las clases ........................................................................... 35 2.3 Conclusiones del capítulo. ............................................................................... 40 CAPÍTULO III Análisis de errores en bases de datos reales..................................... 41 3.1 Errores determinados por el DBAnalyzer 4.0. ................................................. 42 3.1.1 Perfil de los datos. ..................................................................................... 42 VII 3.1.2 Reglas de asociación ordinales binarias. ................................................... 47 3.1.3 Reglas de asociación de longitud k. .......................................................... 51 3.2 Conclusiones del capítulo. ............................................................................... 54 CONCLUSIONES..................................................................................................... 55 RECOMENDACIONES............................................................................................ 56 REFERENCIAS BIBLIOGRAFICAS ...................................................................... 57 VIII INTRODUCCIÓN El valor de la información es considerablemente importante para los procesos, la historia y trayectoria de las organizaciones, dado que la información está directamente relacionada con la utilidad que representa la toma de decisiones y los riesgos asumidos en el cumplimiento de las metas de la organización. Debido a la complejidad, la heterogeneidad, y el factor de error humano de los mecanismos de captura de datos de un sistema, se ha mostrado estadísticamente que cualquier base de datos con una dimensión promedio, siempre contará con al menos un cinco por ciento de errores, sin importar los procesos de calidad que implemente.(Redman, 1998) En cualquier ámbito donde se realice un análisis de datos se requiere un alto nivel de corrección en los mismos, por lo que se deben “limpiar” los datos de alguna manera, es decir, explorarlos para encontrar posibles errores y tratar de corregirlos. Se han desarrollado varias herramientas de limpieza de datos de dominio específico, por ejemplo para limpiar direcciones de Estados Unidos, limpiar listas de nombres, limpiar fechas, entre otras. Muchas de ellas son tan específicas que no son aplicables en nuestro país. Por este motivo hace cuatro años en nuestro centro se desarrolla la idea de crear un software que cumpliera con la fase de análisis de datos dentro del proceso de limpieza de datos, así surge la primera versión de la herramienta DBAnalyzer, realizada por Daynel Marmol Lacal, el que lleva a cabo el análisis de datos utilizando el perfil de los mismos, donde se utilizaron varias medidas estadísticas como la moda, la mediana, la desviación típica, entre otras. Como continuidad de este trabajo fue realizada una segunda versión en un proyecto de práctica laboral que estuvo destinada a ampliar el análisis según el perfil de los datos de la versión anterior, agregándole validación de fechas, chequeo de carné de identidad, entre otros. Este método que utiliza el perfil de los datos detecta los errores a nivel de atributos individuales por lo que se pensó incorporar las técnicas de minería de datos para obtener a través de patrones de comportamientos entre grupos de atributos posibles errores. Se implementó un módulo para la detección de errores usando reglas de asociaciones ordinales binarias y así surge una tercera versión del software de detección de errores DBAnalyzer. 1 Con estos resultados se plantea el siguiente problema de investigación: Los métodos de detección de errores implementados en el DBAnalyzer determinan posibles errores en atributos individuales usando el perfil de los datos y en relaciones binarias de atributos mediante las reglas de asociación ordinales, sin embargo no son consideradas las relaciones de más de dos atributos que también pueden ser una fuente de detección de errores en los datos. Esta investigación tiene como objetivo general, obtener una nueva versión de la herramienta DBAnalyzer que utilice, en el proceso de detección de errores, relaciones que puedan descubrirse entre atributos. Y como objetivos específicos: • Mejorar la interfaz de forma tal que su uso resulte más fácil para el usuario. • Incorporar a la herramienta otro algoritmo como el Apriori basado en la búsqueda de reglas de asociación para la detección errores en los datos. • Constatar con bases de datos reales la detección de posibles errores del Software DBAnalyzer. Se plantean las siguientes preguntas de investigación: 1. ¿Cómo mejorar la interfaz de manera que sea más manejable para el usuario? 2. ¿En qué medida el algoritmo Apriori es eficiente en la búsqueda de reglas de asociación que involucren más de dos atributos? 3. ¿Hasta qué punto la herramienta DBAnalyzer es factible en la detección de errores en las bases de datos de Recursos Humanos y del Departamento de Economía de la Universidad Central de las Villas? Este proyecto se justifica, dada la calidad que requiere la información en el mundo de hoy, la detección de errores en los datos tiene un valor muy alto. Para ello es necesario realizar un análisis eficiente de los datos y de todas las vías posibles, es decir por el perfil de los datos o por minería de datos, ya que existen errores que no se detectan con solo el análisis individual de un atributo. En muchas ocasiones las asociaciones entre atributos pueden dar lugar a una regla interesante con la que se determinaran posibles errores que no fueron descubiertos en el análisis individual. 2 Este proyecto esta estructurado en tres capítulos: Capítulo 1 “Marco teórico” Aborda diferentes generalidades de la fase de detección de errores en el proceso de limpieza de datos y las reglas de asociación como forma de realizar el análisis de los datos. Hace una breve investigación del estado de arte de la limpieza de datos. Capítulo 2 “Análisis y Diseño de una nueva versión del software DBAnalyzer” Describe el algoritmo Apriori seleccionado para la búsqueda de reglas de asociación. Se presenta el diseño de la nueva versión del software DBAnalyzer y las características generales de su implementación. Capítulo 3 “Análisis de errores en bases de datos reales” Muestra errores que se detectaron en las bases de datos de Recursos Humanos y del Departamento de economía de la Universidad Central de Las Villas, según el análisis que realizó la herramienta DBAnalyzer. 3 CAPÍTULO I Marco teórico. Prevenir los errores en los datos es mucho más efectivo que detectarlos para limpiarlos. Evitar las ocurrencias de errores tiene menor costo que encontrarlos y luego corregirlos. Independientemente de ello, siempre se cometen errores en los datos que pueden traer consigo toma de decisiones incorrectas en muchas empresas u organismos. Es necesario entonces, realizar una exploración de los datos con el objetivo de detectar errores para luego proceder al proceso de limpieza. Este capítulo muestra generalidades sobre el proceso de limpieza de datos, y del primer paso denominado análisis de datos, particularizando en la utilización de reglas de asociación en la detección de errores haciendo un estudio del estado de arte de las mismas. 1.1 Limpieza de datos La limpieza de datos se centra principalmente en mejorar la calidad de los datos para hacerlos “apropiados para su uso” por los usuarios. No importa cuan eficiente sea el proceso de entrada de datos, los errores siempre ocurrirán, por lo que no pueden ignorarse ni la validación de datos ni la corrección de los mismos. En áreas de trabajo como el descubrimiento de conocimientos en bases de datos (KDD, Knowledge Data Discovery), los almacenes de datos (DW, Datawarehouse) y el manejo de la calidad de los datos (TQMD, Total Quality Management Data), el proceso de limpieza de datos es decisivo para alcanzar un buen procesamiento de datos y con ello, toma de decisiones correctas. La aparición de anomalías y errores en los datos constituye un problema grave para su procesamiento e influye negativamente en los resultados que se obtienen. Las anomalías pueden ser originadas por mediciones erróneas, entradas de datos sin validaciones, omisiones ocurridas mientras se coleccionan o se mantienen los datos o también puede ser el resultado de malas interpretaciones del universo que se está modelando. Los errores que la limpieza de datos trata de corregir se agrupan y presentan de múltiples formas. 4 Una clasificación de los tipos de errores fundamentales sobre los que la limpieza de datos trabaja se encuentran en (Heiko Müller, 2003) y estos son agrupados en: anomalías sintácticas, anomalías semánticas y anomalías de contexto. Las sintácticas se refieren a errores léxicos, errores de formatos y dominios, y no estandardización de la información. Las anomalías semánticas incluyen violaciones en las restricciones de integridad en las tuplas, contradicciones en valores de datos que violan algún tipo de dependencia entre ellos, tuplas duplicadas y tuplas no válidas. Las anomalías de contexto por su parte incluyen la ausencia de valores de datos en las tuplas o ausencia de tuplas completas que existen en el mini mundo y no han sido representadas. (Heiko Müller, 2003) Algunos autores también distinguen entre los errores o anomalías a nivel del esquema y a nivel de instancia y también si estos errores en los datos provienen de una única fuente o de la integración de múltiples fuentes. (Rahm and Do, 2000) Una forma de solucionar el problema de eliminación de errores e inconsistencias en los datos resultaría de la exploración de los datos hasta encontrar posibles errores para luego proceder a su corrección. La práctica manual de este proceso no es factible, pues serían empleadas muchas horas-hombres para su realización. Debido a esto la comunidad científica ha dedicado grandes esfuerzos al desarrollo de algoritmos y métodos computacionales que se responsabilicen de la detección y eliminación de estas anomalías en los datos. Estos métodos y algoritmos computacionales han sido agrupados bajo el término de limpieza de datos. Aunque no existe una definición general constituida sobre el proceso de limpieza de datos, ya que el mismo depende del área a la que es aplicado, una idea sencilla pudiera estar dada por: “La limpieza de datos trata de detectar y remover errores e inconsistencias de los datos para darle una mejor calidad“ (Rahm and Do, 2000). La limpieza de datos se realiza habitualmente de forma interactiva, para que en dependencia del conjunto de datos en específico, los expertos puedan decidir como solucionar el problema, precisando las reglas que permitirán establecer la validez de los datos. 5 Los procesos de limpieza de datos por lo general son muy costosos en tiempo. Dado que estos no previenen la aparición de nuevos errores dada la manipulación de las fuentes de datos involucradas, en muchas ocasiones es preciso repetir el proceso periódicamente. Es indispensable contar con una estrategia para la limpieza de datos, que no requiera incurrir en el costo de repetir todo el proceso, sino sólo sobre los datos nuevos o los alterados después de la limpieza. El proceso de limpieza de datos es descrito según (Rahm and Do, 2000) por las siguientes tareas: 1. Análisis de los Datos. 2. Determinación del flujo de trabajo para las transformaciones y las reglas de correspondencia. 3. Verificación 4. Transformación 5. Flujo inverso de datos limpios. El análisis de los datos es la base del proceso de limpieza de datos con la que se determinan que tipos de errores e inconsistencias deben ser limpiados y se deciden qué métodos y herramientas emplear para realizar la limpieza. En la segunda etapa se realizan un número grande de transformaciones en los datos dependiendo del número de fuentes de datos y de su grado de heterogeneidad y grado de “suciedad”, entre las que se encuentran la necesidad de hacer corresponder datos de diversas fuentes. Luego se pasa a la verificación, donde es evaluada y aprobada la corrección y efectividad del flujo de trabajo de las transformaciones y la definición de las transformaciones. Terminado esto se procede a la ejecución del paso de transformación ya sea por la ejecución del flujo de trabajo del ETL (Extracción, Transformación y Carga) para la carga o por la ejecución de las consultas sobre las fuentes. Después que los datos son limpiados, no solo deben servir para cargar el almacén de datos sino también deben ser utilizados para reemplazar los datos “sucios” originales, por ello la última etapa de la limpieza de datos es el flujo inverso de datos limpios. 6 1.2 Herramientas existentes en Limpieza de datos. Actualmente existen herramientas para realizar el proceso de limpieza de datos, algunas de éstas están preparadas para trabajar sobre dominios específicos, por ejemplo se dedican a la limpieza de nombres y direcciones, otras se dedican a una fase específica del proceso de limpieza de datos como por ejemplo al análisis de datos, o a la eliminación de duplicados. A continuación presentamos un resumen de las más conocidas ordenadas por las principales funciones que realizan dentro del proceso de limpieza de datos. (Galhardas) Herramientas que corrigen, estandarizan y mejoran listas de nombres y direcciones: 1. Trillium Software System. Es una herramienta escrita en lenguaje C, desarrollada por Trillium software entre sus principales características están las siguientes: ♦ Consta de un analizador, una herramienta de frecuencia automatizada y una de correspondencia. ♦ El analizador para la estandardización de campos hace un procesamiento sensitivo al contexto para derivar el significado de palabras dentro de los campos de formato libre. ♦ La herramienta Igualador (Matcher) brinda un conjunto estándar personalizable de “mejores prácticas” para resolver la eliminación de duplicados. ♦ La herramienta automatizada de frecuencias: realiza el análisis de los datos a través de máscaras. ♦ Otras funcionalidades adicionales son que permite la transformación y validación del formato de los campos y conversión de múltiples campos para búsqueda. 2. MatchMarker: Producida por la compañía Info Tech Ltd está diseñada para limpiar y estandardizar direcciones. Hace correcciones de errores ortográficos comunes e identifica direcciones duplicadas. 7 3. QuickAdress Batch: Esta herramienta es un producto de la compañía QAS Systems entre sus principales características están: ♦ Mejora las listas de direcciones haciendo correcciones a los códigos postales, añadiendo códigos postales cuando este dato está ausente, y eliminando errores ortográficos en las direcciones y modificándolas a un formato estándar. ♦ Usa PAF (Royal Mail’s Postcode Adress File) y el Electoral Roll de UK como tablas de búsqueda para direcciones y nombres. ♦ Para la eliminación de duplicados en las direcciones usa búsqueda de caracteres especiales, métodos de correspondencia borrosos, y búsqueda de palabras claves. ♦ Ofrece un ambiente interactivo para la búsqueda de direcciones iguales que no hayan sido detectadas automáticamente. 4. PureName PureAddress, producida por Carleton es una herramienta especializada para la limpieza de nombres y direcciones y resuelve los problemas de usos de diferentes formatos para la representación de nombres y direcciones, uso de abreviaturas, datos ausentes, información fuera de fecha, trasposiciones ortográficas e inconsistencias. Entre las principales funciones que realiza están: analizador de nombres y direcciones, corrector de direcciones, estandarización de nombres y direcciones. 5. NADIS: es un producto del Groupl Software y MasterSoft Internacional. Está constituida por tres módulos, denominados ScrubMaster, SearchMaster, y OnLooker. Resuelve la estandardización de nombres y direcciones de varios países. Hace corresponder nombres y direcciones con un formato estándar (Universal Name and Address). Usa funciones de gramática y fonética para encontrar correspondencias entre nombres y direcciones exactas o difusas. 6. Ultra Address Management producida por The Computing Group también limpia nombres y direcciones, para esto emplea técnicas de búsqueda difusas avanzadas y fonéticas, y además hace correcciones ortográficas. 8 Herramientas para eliminar registros duplicados: 1. DataCleanser DataBlade Module, ésta herramienta es un producto de la compañía Electronic Digital Documents, Inc que asiste en la limpieza de bases de datos de Informix. Para detectar los duplicados la herramienta usa el método de vecindades realizando múltiples pasadas. 2. Integrity es una herramienta de la compañía Validity está diseñada para resolver problemas cuando se hace reingeniería en sistemas legados, por ejemplo llaves no comunes, pérdida de dominios y formatos comunes, para el mismo campo, entre otros. Hace minería de datos para descubrir metadatos, en los datos tecleados a través de análisis léxico, e identifica entidades a través de comparaciones estadísticas. El proceso de limpieza en esta herramienta consta de cuatro estados: investigación, estandarización, comparación y verificación. Utiliza un conjunto de operadores para realizar transformaciones de columnas (mover, dividir, eliminar, etc.), transformación de filas (mezclar, dividir, etc.) y contar. 3. ETI*Data Cleanse es una herramienta producida por Evolutionary Technologies International que tiene tres componentes: limpieza de datos, comparación de datos y revisión de calidad. La función de limpieza de datos maneja tablas, y consta de una función personalizable que estandariza datos. La función de comparación de datos identifica interrelaciones entre registros de datos, encuentra duplicados, detectando errores ortográficos, transposición de caracteres, etc. La función de revisión de calidad posibilita la revisión por inspección visual de ficheros que contienen datos que el software no pudo estandardizar. Realiza además procesos iterativos y consta de un repositorio de metadatos, MetaStore. 4. Centrus Merge/Purge es una herramienta de la compañía Quality Marketing Software que además de resolver el problema de los registros duplicados, permite ordenar, consolidar y añadir registros de los clientes y de los prospectos a partir de los criterios personalizados que brindan los usuarios de la herramienta. Cuando la lista de los clientes reside en múltiples sistemas operativos esta herramienta posibilita la obtención de una vista unificada con la información de los clientes, entre otras facilidades están que los usuarios pueden definir 9 múltiples llaves para hacer la correspondencia entre registros en una sola corrida, dando la posibilidad de seleccionar y usar varios algoritmos para hacer esta tarea. En la detección de registros duplicados esta herramienta es capaz de encontrar muchos de ellos con muy pocos falsos positivos. Esta herramienta ofrece el servicio de determinar registros duplicados en línea a través del comando Merge /Purge. 5. SSA-Name/Data Clustering Engine de Search Software America resuelve los siguientes problemas en los datos: errores ortográficos, errores de tecleo y trascripción, sinónimos, abreviaturas, prefijos y sufijos, concatenación y división de palabras, puntuación, palabras que faltan, nombres de personas y compañías mezcladas, etc. Limpia la información no formateada sobre clientes relacionando los nombres, direcciones, nombres de compañías, etc. 6. DfPower es una herramienta de Dataflux Corporation que analiza los datos para identificar los diferentes valores de datos que ocurren en un campo dado y determina el número de ocurrencias, estandariza campos de datos seleccionando un valor de dato entre los valores que ocurren en dicho campo. Los registros de datos son agrupados por ocurrencias alfabéticamente o agrupados de acuerdo a algún criterio. Especifica la definición para igualar los campos usados para la comparación de los registros. Genera código que permite agrupar los registros duplicados juntos para luego mezclarlos. Permite conectarse a bases de datos vía ODBC. 7. MatchIT es una herramienta producida por la compañía helpIT Systems limited consta de interfaz interactiva escrita en Visual C++ y Visual Foxpro, entre sus principales funcionalidades están que permita la corrección de direcciones de acuerdo a Royal Mail’s address File, los usuarios pueden especificar las llaves para hacer la comparación para detectar registros duplicados, a través de la combinación de funciones aplicadas a los campos, así como llaves fonéticas, solamente los registros que se correspondan en los valores de esas llaves serán comparados, realizando varias búsquedas por diferentes llaves. Los usuarios pueden establecer pesos a los campos para realizar la comparación según estos pesos. Los duplicados que tienen correspondencia en el 10 valor de la llave se agrupan juntos, y luego la mezcla es realizada a nivel de registro. 8. Holmes: Es un producto de Kimoce que a partir del análisis fonético detecta duplicados. Permite además encontrar similitudes ortográficas y homónimos fonéticos. 9. Centric, es un producto de firsLogic que realiza limpieza a la información relativa a los clientes, y desarrolla este proceso en seis pasos: Parsing el cual asegura que los valores correctos están insertados en cada campo. Correction usa algoritmos para chequear la información de las direcciones, Standardization convierte los campos de clientes a un formato estándar. Data enhancement añade datos a los campos con información faltante, y completa la información con datos que vienen de fuentes secundarias. Matching para cada registro entrado, busca los registros de clientes existentes para detectar registros similares. Consolidation combina los registros que se corresponden de la fase anterior, para obtener una vista más completa de la lista de clientes. 10. ReUnion and MasterMerge de PitneyBowes. Verifica, corrige y estandariza nombres y direcciones, iguala los registros con información de clientes con una base de datos de marketing, hace la corrección de nombres, valida la residencia, estandariza nombres, direcciones, ciudad, y realiza la corrección de los datos de ciudad, estado, código postal, etc. MasterMerge identifica los registros duplicados de clientes desde varias fuentes, y realiza la consolidación de éstos. Implementa varios algoritmos para determinar los duplicados, que incluyen fonética, patrones de direcciones, y otros. Los usuarios pueden asignar prioridades para asignar un registro desde un conjunto de duplicados. 11. PureIntegrate es una herramienta de Carleton está diseñada para resolver los siguientes problemas en los datos: formatos diferentes, inconsistencias, valores ausentes, valores ilegales, interrelaciones no válidas, identificadores no comunes. Soporta la búsqueda de duplicados basada en llaves, correspondencia difusa y reglas para las mezclas en función de varios factores como son la prioridad de la fuente, la de más reciente actualización, o la que más frecuentemente ocurre. Posee una interfaz de usuario gráfica para la construcción del proceso de transformación, integración y refinamiento de las reglas. 11 12. DoubleTake StyleList, Personator, es una herramienta de Peoplesmith divide nombres, direcciones, ciudad, estado y códigos postales, para esto usa varios metacódigos: exactos, fonéticos, soundex, etc. Permite a los usuarios la definición de otros metacódigos. Puede ser aplicada a más de un fichero fuente. Personator divide nombres y direcciones, y construye saludos. StyleList: da formatos a nombres y direcciones. 13. TwinFinder es un producto de Omikron trata errores ortográficos, trasposiciones y abreviaturas, usa el algoritmo FACT para resolver la correspondencia difusa de patrones y también realiza correspondencia fonética. En la detección de duplicados combina limpieza manual y automática. 14. Data Tools Twins, es un producto de Data Tools que brinda analizadores para direcciones, estados, y nombres de personas. Usa la base de datos PAF para la estandardización de direcciones, predefine técnicas de correspondencia para encontrar duplicados de la información del personal (nombre y dirección), duplicados de la información de compañías de negocios. Permite la edición de los duplicados encontrados y realizar operaciones sobre ellos para lograr la consolidación. Posibilita la definición de pesos y criterios de calidad para seleccionar un registro del grupo formado con los duplicados. Esta herramienta puede trabajar con una o dos tablas y realiza la conexión vía ODBC. 15. NoDupes, de Quess Inc limpia datos de un dominio específico relativos a individuos, compañías y productos. Permite a los usuarios seleccionar el nivel para la correspondencia entre registros al buscar duplicados. Permite diferentes acciones al encontrar los registros duplicados, añadirlo, actualizarlo, eliminarlo, o exportarlo. Esta herramienta puede ser aplicada a múltiples ficheros, buscando los duplicados en ellos contra el primero de los ficheros. 16. DeDuce, de The Computing Group realiza la correspondencia entre registros a partir de 17 campos llaves, la decisión de si los artículos son o no duplicados puede ser tomada manual o automáticamente. Facilita la revisión de cada grupo de registros duplicados para mezclarlos. 17. DeDupe es una herramienta de International Software Publishing que brinda varios operadores de correspondencia: fonética, palabras, números de fax y teléfono, nombres e iniciales, etc. Para el módulo de fonética usa el software 12 FoneX. Utiliza listas de referencias para resolver las abreviaturas y las palabras, que pueden ser actualizadas. Permite correr varias sesiones con diferentes criterios de correspondencia y refinar los resultados. Pueden ser realizadas varias operaciones con los duplicados encontrados, permite encontrar de los registros duplicados el principal y eliminar los restantes. Permite usar sentencias del lenguaje SQL para filtrar registros de la búsqueda. Puede aplicarse a más de una tabla y conectarse a cualquier base de datos directamente o vía ODBC. 18. Merge/Purge Plus de Group1 Software limpia nombres y direcciones, establece niveles para la correspondencia entre registros, se puede aplicar a múltiples ficheros. Herramientas de análisis de datos: (no limpian). 1. Migration Architect es una herramienta de Evoke Software la cual ofrece un panorama de los datos y su contenido basado en los datos físicos no en metadatos. Realiza dos pasos: determina el perfil de los datos y el mapeo de los datos. En el perfil de los datos analiza el valor de cada columna, determina dependencia entre columnas, busca pares de columnas que contienen la misma información o información similar. En el paso de mapeo de datos, crea un modelo correcto normalizado de las tablas de origen, permite una modificación manual de las tablas normalizadas para incluir otros requerimientos, posee una interfaz interactiva y utiliza descubrimiento por inferencia para extraer significado de los datos. Es una de las pocas herramientas considerada como herramienta de análisis a partir del perfil de los datos. 2. WizWhy & WizRule, es una herramienta de WizSoft Inc. Esta herramienta determina cómo los valores de un campo son afectados por los valores de los otros campos. Da como salida un conjunto de reglas que serán usadas para predecir por ejemplo los patrones esperados y fenómenos inesperados en los datos, ya que los errores en los datos son las desviaciones de las reglas encontradas. Es una herramienta que realiza el análisis de los datos usando minería de datos. 3. Conversion Package de Gladstone Computer Services escrita en COBOL. Incluye un módulo de integridad y un módulo de mapeo de datos. El módulo de integridad realiza la cuantificación de cada campo de la base de datos, de forma 13 que son detectadas anomalías en los datos e inconsistencias. El módulo de mapeo permite la especificación de cuales datos serán movidos desde la las fuentes hasta el sistema origen. La herramienta realiza estos procesos de forma iterativa, y están sujetos a un refinamiento sucesivo. 4. DQGuard, de Knowledge Integrity Incorporated captura las reglas de calidad de los datos y reglas de negocios en un lenguaje formal. Presenta un marco para definir las reglas de calidad de datos, manejando estas como contenido y genera aplicaciones para medir y reportar los resultados de probar estas reglas. 5. DataMiningSuite, es un producto de InformationDiscovery es otra herramienta de análisis de datos que se basa en la minería de los datos para la detección de los errores, ésta infiere interrelaciones entre atributos y sus valores y calcula una razón de confianza indicando el número de filas calificadas (Rahm and Do, 2000). Otras herramientas menos conocidas son: 1. DBAssitant de BloodHound Software, 2. SENDA, Marketing Technology S.A. 3. Polk. 1.3 Detección de errores Determinar qué constituye un error, depende del contexto que se esté analizando, y de determinadas reglas de negocio que son específicas para el universo de trabajo. Esta búsqueda de contexto también se conoce como “datos sucios” (Mauricio A Hernández and Stolfo, 1998), (Kimball, 1996) y tiene como objetivo la determinación de taxonomías para datos sucios. La detección de los errores y la determinación de las instancias en que éstos ocurren son problemas complejos, y aunque el análisis de la integridad de los datos puede revelar algunos tipos de errores, existen otros muy difíciles de detectar como por ejemplo los casos en que los errores involucran varios campos interrelacionados. Un procedimiento general que permitiría descubrir este tipo de errores es detectar los datos que se comportan de forma diferente, o sea, determinar las excepciones en el comportamiento general de los datos, de esta forma si en un conjunto de datos, el 14 99,9% de los elementos de datos se comportan de una forma, y solo el 0,1% restante lo hace de manera diferente, entonces pudiéramos establecer que el 0,1% puede ser considerado como un posible error. No obstante debe considerarse que la naturaleza de los datos del mundo real es muy diversa y poco ajustable a una distribución estática estándar. La detección de errores es la acción que se realiza en la primera fase del proceso de limpieza de datos. Es la etapa donde se debe determinar que clases de errores e inconsistencias deben ser eliminadas, o sea, examinar de alguna forma los datos con el objetivo de verificar su corrección. El examen de los metadatos, es decir, las características o información que las bases de datos guardan sobre los datos, constituye una forma de revisar los mismos. Sin embargo, generalmente los metadatos resultan insuficientes para evaluar la calidad de los datos, principalmente en aquellos casos en que son muy pocas las restricciones de integridad que se establecen sobre los datos. Es en estos casos, en que es útil revisar las instancias de datos para obtener nuevos metadatos, nuevas características o patrones de valores inusuales. El descubrimiento de errores se lleva a cabo mediante un análisis detallado de los datos, para lo cual existen dos enfoques, el primero examina el perfil de los datos para el análisis de atributos individuales aplicando determinados estadígrafos y el segundo enfoque aplica técnicas de minería de datos que ayudan a descubrir patrones específicos en el conjunto de datos, a partir de los modelos de minería de datos llamados descriptivos entre los que se encuentran el agrupamiento, el descubrimiento de asociaciones y de secuencias. Por ejemplo, una regla de asociación con un nivel de confianza alto, sugiere problemas en la calidad de los datos de las instancias que violen esta regla. El perfil de los datos realiza un análisis individual de las instancias de los atributos, es decir, según el tipo de dato del atributo se obtienen estadísticos tales como: tipo de dato, longitud, valor mínimo y valor máximo, valores discretos y su frecuencia, varianza, unicidad, ocurrencia de nulos, patrones típicos de cadena, entre otros. En la tabla siguiente se describen algunos ejemplos de que podría ser un posible error detectado mediante la obtención de estos metadatos. 15 Problemas Metadato Ejemplos/heurísticas cardinalidad Ej. Si cardinalidad(sexo) > 2 indica problemas. max, min Los valores max, min no deben estar fuera del rango permitido. Valores ilegales varianza, desviación La varianza y desviación no deben ser mayores que el umbral. Errores ortográficos valores de atributos Ordenando los valores de un atributo, hace que datos con errores ortográficos queden cerca y puedan detectarse. valores nulos Por ciento / número de valores nulos. Valores ausentes valores por defecto La presencia de valores por defecto puede indicar realmente un valor nulo. cardinalidad+unicidad La cardinalidad del atributo debe coincidir con el número de filas. Duplicados valores de atributos Ordenar los valores por el número de ocurrencia; Más de una ocurrencia indica duplicados. Tabla 1.1 Ejemplo de posibles errores. Por otra parte, la minería de datos ayuda a descubrir patrones de datos en conjuntos grandes de datos con la utilización de modelos descriptivos que incluyen, clusterización, descubrimiento de asociaciones y otros. Un conjunto de métodos generales que son ampliamente empleados en la detección de errores son los siguientes (Marcus and Maletic, 2005): 16 Métodos estadísticos: Métodos del cálculo de la media, la desviación estándar y rango, basados en el teorema de Chebyshev, y considerando un intervalo de confianza para cada campo. Sirve para determinar valores excepcionales en campos y registros de datos. Son métodos rápidos y simples aunque pueden generar muchos falsos positivos. Pueden además ser combinados con otros métodos. Método de agrupamientos: Métodos que implementan algoritmos de agrupamientos o clusterización utilizando alguna distancia, por ejemplo la distancia euclidiana, para identificar excepciones en los registros de datos que representan posibles errores. Estos métodos tienen una elevada complejidad computacional. Métodos basados en patrones: Un patrón es definido por un conjunto de registros que tienen características o comportamiento similar para un p% de campos en el conjunto de datos, donde p es un valor definido por el usuario, 90 habitualmente. Usando estos patrones se examinan los registros de datos y las excepciones son consideradas como posibles errores. La combinación de técnicas como particiones, clusterización y clasificación son usadas generalmente para encontrar patrones que pueden ser aplicados a muchos datos. Métodos basados en reglas de asociación: Las reglas de asociación con altos valores de confianza y soporte, determinan un tipo de patrón oculto que ocurre en los registros de datos. Los registros de datos que no cumplan con las reglas se consideran posibles errores. Lo que hace diferente y poderoso este método es que puede ser aplicado a diferentes tipos de datos. 1.4 Reglas de asociación. Las reglas de asociación encuentran asociaciones o correlaciones entre objetos de una base de datos transaccional, relacional o almacenes de datos (datawarehouse). Estas tienen numerosas aplicaciones como por ejemplo en el soporte para la toma de decisiones, análisis de información de ventas, entre otras. La identificación de reglas de asociación entre los datos es una técnica de gran valor para la minería de datos. Esta técnica permite a los analistas determinar relaciones entre determinadas variables de los datos que no son obvias. En la minería de datos se narra una bonita historia conocida como “la cerveza y los pañales”. Se dice que en una gran cadena estadounidense de supermercados, Wal- 17 Mart, se realizó a finales de los años 90 un análisis de los hábitos de compra de sus clientes. Después de un análisis detallado, este resultado se explica de forma bastante curiosa. Como los pañales son bastante voluminosos, las mujeres habitualmente mandaban a sus maridos a comprarlos. Los maridos y padres, jóvenes entre 25 y 35 años, rango medio de edad para tener niños tan pequeños, solían ir a la compra los viernes, algo reticentes, en el último momento posible. Estos padres, con una vida social no demasiado feliz, a la vez que compraban pañales para sus bebés, aprovechaban para comprar cerveza, ya que no podrían salir a tomarlas. Se cuenta además que Wal-Mart utilizó este resultado para reubicar estos productos en lugares estratégicamente dispuestos, es decir, pusieron la cerveza junto a los pañales. El resultado fue que los padres que habitualmente compraban cerveza después compraron todavía más, al estar tan cómodamente situada. Además, los que antes no compraban cerveza, empezaron a hacerlo al estar tan a mano. Así, las ventas de cerveza tuvieron un aumento espectacular. Éste es un buen ejemplo para analizar cómo reubicar los productos en un mercado, cuyo problema puede ser resuelto con la búsqueda de reglas de asociación aplicadas al análisis de ventas en particular. 1.4.1 Ideas básicas de reglas de asociación. Las reglas de asociación han sido usadas para encontrar pares de atributo-valor que ocurren juntos frecuentemente en un conjunto de datos. El par atributo-valor es denominado ítem. Una regla de asociación esta compuesta por dos conjuntos de ítems llamados antecedentes y consecuentes, que se unen en la regla con una flecha (A => B), donde A y B son conjuntos de ítems, intuitivamente indica que los registros de la base de datos que contienen A tienden a contener B (Human Factors, 1999), (Sotiris Kotsiantis, 2006). Para cada regla se calculan valores de soporte y confianza. Longitud de una regla La longitud de una regla de asociación es igual a la cantidad de ítem que intervienen en la regla. 18 Soporte de una regla El soporte de una regla es el porcentaje de ejemplos que la regla cubre con sus restricciones atributo – valor. El soporte para una regla de la forma A => B es la probabilidad de que un registro contenga {A} y {B}. Se puede leer como: Soporte (A => B) = P(A U B) Confianza de una regla La confianza de una regla es el porcentaje de ejemplos que una regla cubre completamente, por ciento de aciertos de la regla. La confianza para una regla de la forma A => B es la probabilidad condicional de que un registro que contenga {A} también contenga {B}. Se puede expresar como: Soporte(A U B) Confianza(A => B) = P (B|A) = --------------------- Soporte(A) El descubrimiento de reglas de asociación obtendrá todas las reglas de asociación que excedan los valores mínimos de soporte y confianza establecidos por el usuario, permitiéndole al mismo identificar qué reglas tienen mayor valor. 1.4.2 Clasificación de reglas de asociación En (Jiawei Han, 2001) se clasifican las reglas de asociación según criterios específicos, de la siguiente manera: 1- Basado en los tipos de valores tratados en la regla: ♦ Si una regla presenta una asociación entre la presencia o ausencia de ítems, entonces es clasificada como una regla de asociación booleana. ♦ Si una regla describe asociaciones entre ítems o atributos cuantitativos entonces es una regla de asociación cuantitativa. En esas reglas los valores cuantitativos de ítems o atributos, son particionados en intervalos. 2- Basado en la dimensión de los datos involucrados en la regla: 19 ♦ Si los ítems o atributos en una regla de asociación referencia una sola dimensión entonces es una regla de asociación unidimensional y si referencia a dos o más dimensiones es una regla de asociación multidimensional. 3- Basado en el nivel de abstracción involucrado en el conjunto de reglas: ♦ Algunos métodos para minería de reglas de asociación pueden buscar reglas de diferentes niveles de abstracción, este tipo de regla es denominada regla de asociación multinivel. Si, en cambio, las reglas dentro de un conjunto dado no referencia ítems o atributos en diferentes niveles de abstracción, entonces el conjunto contiene reglas de asociación de nivel simple. 4- Basado en la naturaleza de la asociación involucrada en la regla: ♦ La minería de asociaciones puede ser extendida a análisis de correlación, donde la ausencia o presencia de ítems correlacionados pueden ser identificado. 1.5 Algoritmos de búsqueda de reglas de asociación. Un algoritmo básico para la búsqueda de reglas de asociación, consideraría cada posible combinación simple de antecedentes y consecuentes, evaluaría el soporte y la confianza, y desecharía todas las asociaciones que no satisfagan los valores de soporte y confianza especificados. Sin embargo, la elaboración de un algoritmo siguiendo estos pasos no resulta eficiente ya que el número de posibles combinaciones puede resultar muy grande, por ejemplo si se tiene 1000 ítems el número de conjuntos de ítems que pueden ser formados seria 2^1000, aproximadamente 10^300 (Human Factors, 1999). Está claro que el espacio de búsqueda de posibles reglas de asociación es sumamente grande y para la búsqueda de ellas se requiere un gran esfuerzo computacional. Para la búsqueda de reglas de asociación, aquellas que se presentan de forma general, es decir, antecedente => consecuente, el problema de descubrimiento de las mismas puede ser dividido en tres partes según (Ramakrishnan Srikant, 1995): 1. Se buscan todos los conjuntos de ítems (itemsets) cuyo soporte es mayor que el soporte mínimo especificado por el usuario, denominados itemsets frecuentes. 20 2. Se utilizan los itemsets frecuentes para generar las reglas deseadas y se calculan los valores de confianza para cada una de ellas. 3. Se eliminan aquellas reglas que no son interesantes. Esta división resulta un poco menos costosa puesto que al encontrar un conjunto de ítems frecuente se calcula el soporte para el mismo, por lo que no será necesario realizar el cálculo de la confianza para la regla si el itemset encontrado no cumple con el valor de soporte mínimo. La búsqueda de itemsets frecuentes no es más que determinar que pares de atributo- valor ocurren juntos frecuentemente en el conjunto de datos. Existen varios algoritmos que resuelven este problema, uno de ellos es el algoritmo Apriori, un influyente algoritmo para reglas de asociaciones booleanas capaz de determinar conjuntos de ítems de cualquier longitud cuyo soporte sea mayor que el soporte mínimo establecido. Luego de generar las reglas el tercer paso resulta eliminar aquellas que no son interesantes. Una regla de asociación se dice interesante cuando su soporte s y su confianza c son mayores o iguales a los valores mínimos de soporte y confianza especificados por el usuario. (Alina Campan, 2006) Al generar una regla se calcula para ella su confianza y se verifica si excede el valor mínimo de confianza. Este paso puede realizarse junto a la generación de las reglas ya que no será necesario almacenar todas las reglas para luego verificar si son interesantes o no, simplemente al generar una se determina si cumple con los valores de confianza y soporte y se almacena solo si resulta serlo. 1.6 Reglas de asociación en la detección de errores La detección de errores soportada por reglas de asociación requiere un proceso costoso para identificar las reglas, sobretodo si se quieren contemplar varias combinaciones de atributos. La identificación de las reglas requiere un conjunto de datos suficientemente grande y representativo. Las reglas de asociación son utilizadas en el proceso de detección de errores en los datos estableciendo un comportamiento general de los mismos, y a partir de las excepciones determinar un posible error. En particular las reglas de asociación 21 ordinales y relacionales ((Maletic and Marcus, 2000),(Alina Campan, 2006) se han usado con este propósito. En nuestro grupo de investigación se creo una herramienta que utiliza reglas de asociación ordinales para detectar errores en los datos, estamos hablando del DBAnalyzer 3.0. Su utilización vino dada por un análisis que se hizo del software con bases de datos del Banco Popular de ahorro. Aquí se descubre que se pudieran establecer varias restricciones que deben cumplirse entre los datos, tales como: “La fecha de emitido de un cheque, debe se anterior a la fecha en que el cheque regresa al banco” “El saldo final de la cuentas de ahorro a plazos fijos debe ser mayor o igual al saldo inicial”. Una solución a este problema fue el descubrimiento de reglas de asociación ordinales y para ello existe un algoritmo que busca relaciones de dos o más atributos, como máximo la cantidad total de atributos de la tabla, denominado DOAR por sus siglas en inglés Discovery of Ordinal Association Rules. Este método hace una pasada por la base de datos para cada conjunto de diferente tamaño, por tanto, para minimizar el esfuerzo computacional y atendiendo a las bases de datos nuestras se decidió determinar solamente las reglas entre pares de atributos, es decir, utilizar reglas de asociación ordinales binarias entre atributos del mismo dominio. Las reglas de asociación ordinales binarias se presentan en la herramienta de la forma A µ B, donde A y B son atributos y µ es una relación de orden, tal que µ ∈ {<, =, >} y para el descubrimiento de las mismas se establecen valores altos de soporte y confianza. Se muestra la regla encontrada y sus medidas de soporte y confianza, luego se detectan posibles errores analizando por cada registro de la base de datos si no cumple con alguna de las reglas. Puesto que solo se consideran atributos del mismo dominio se decide buscar reglas de asociación que encuentre relaciones entre atributos de cualquier dominio y descubra regla de cualquier longitud. 22 1.7 Conclusiones del capítulo En el proceso de limpieza de datos es sumamente importante la detección de aquellos errores que ocurren el las bases de datos y que serán limpiados posteriormente. El análisis de los datos brinda la posibilidad de encontrar errores y el mismo presenta dos enfoques, el perfil de los datos y las reglas de asociación. Con el uso de las reglas de asociación se obtienen resultados más fiables y se puede completar el análisis de los datos obtenidos con el perfil de los mismos. 23 CAPÍTULO II Análisis y diseño de una nueva versión del software DBAnalyzer En este capítulo se describirá la solución dada a nuestro problema de investigación donde se explicará el uso del algoritmo Apriori para generar reglas de asociación de longitud k que serán utilizadas en el proceso de detección de errores. Además se explicarán detalles del diseño de una nueva versión de la herramienta de detección de errores, DBAnalyzer. 2.1 Descripción del algoritmo Apriori. El Apriori es un algoritmo no supervisado, es decir, no existen relaciones conocidas a priori con las que contrastar la validez de los resultados, sino que se evalúa si esas reglas son estadísticamente significativas. Emplea un proceso iterativo de acceso, conocido como un nivel o modo de búsqueda, donde los k-itemsets son usados para explorar los (k + 1)-itemsets. Primero el conjunto de ítems frecuentes de longitud uno, es encontrado. El conjunto es denotado L1 y es usado para buscar L2, el conjunto de ítems frecuentes de longitud dos, que es usado para buscar L3, y así sucesivamente hasta que no más el conjunto de ítems de longitud k pueda ser encontrado. El descubrimiento de cada Lk (Tabla 2.1) requiere una búsqueda completa de la base de datos. Para mejorar la eficiencia del modo de generación de conjuntos de ítems frecuentes el algoritmo se basa en una propiedad importante llamada propiedad Apriori y es usada para reducir el espacio de búsqueda del mismo. Propiedad Apiori: Todo subconjunto no vacío de un conjunto de ítems frecuente tiene que también ser frecuente. La propiedad Apriori está basada en la siguiente observación. Por definición, si un itemset I no satisface el mínimo de soporte min_sup, entonces I no es frecuente, que es, P(I) < min_sup. Si un ítem A es adicionado en el itemset I entonces el itemset resultante (I U A) no puede ocurrir más frecuentemente que I. Por lo tanto, (I U A) no es frecuente, es decir, la probabilidad de ocurrencia de (I U A) es menor que el mínimo de soporte especificado por el usuario, P(I U A) < min_sup. (Jiawei Han, 2001) 24 Conjunto de ítems de longitud k Un conjunto de ítems teniendo k-ítems Lk Conjunto de k-itemset frecuentes (aquellos con un mínimo de soporte). Cada miembro de este conjunto tiene dos campos: i) itemset ii)valor de soporte. Ck Conjunto de k-itemset candidatos (itemsets potencialmente frecuentes). Cada miembro de este conjunto tiene dos campos: i) itemset ii)valor de soporte Tabla 2.1. Notación Dada esta propiedad describiremos ahora el algoritmo: Algoritmo Apriori: Busca conjuntos frecuentes de ítems usando un nivel o modo iterativo de acceso basado en generación de candidatos. Entrada: Base de datos de transacciones: D, soporte mínimo: min_sup. Salida: Conjunto de ítems frecuente en D: L Método: ………………………..Inicio……………………………….. L[1] = Buscar_itemsets_frecuentes_long1(D); Para (k=2; L[k-1] ≠ ø; k++ ) hacer C[k] = apriori_gen (L[k-1], min_sup); Por cada transacción t є D hacer C[1] = Subconjunto(C[k],t) ; Por cada candidato c є C[1] c.count++; } L[k] = {c є C[k] | c.count >= min_sup} 25 } Devolver L= UkL[k] …………………………. Fin…………………………………. Itemsets frecuentes de longitud uno Los itemsets frecuentes de longitud uno son aquellos pares de atributo-valor, analizados individualmente, cuyo por ciento de ocurrencia es mayor o igual que el soporte especificado por el usuario. La búsqueda de este conjunto de ítems es el primer paso a realizar en el algoritmo Apriori y es usado luego para ir generando los conjuntos de ítems candidatos de mayor longitud. Generación de candidatos El algoritmo Apriori utiliza el método apriori_gen, cuya función tiene como argumento el conjunto de ítems L[k-1] que se utiliza en la generación del conjunto de ítems candidato C[k] (Tabla #1), dado como resultado de este método. Se supone además que todo conjunto de ítems que pertenece a L[k-1] esta ordenado lexicográficamente. Representando un itemset c de longitud k, c[1]x c[2]x…x c[k] , consistiendo en el ítem c[1], c[2],…,c[k] donde c[1]< c[2]<… (l - a) si la confianza de 27 esta es mayor que el mínimo de confianza que el usuario especifica (si es una regla interesante), es decir, Soporte(l) Confianza(a => (l - a)) = --------------- < min_conf Soporte(a) Podemos mejorar el procedimiento anterior por la generación de subconjuntos de un itemset grande mediante un método recursivo primero en profundidad. Por ejemplo, dado un itemset ABCD, primero se considera el subconjunto ABC, luego AB, etc. Entonces, si un subconjunto a de un itemset grande l no genera una regla, los subconjuntos de a no necesitan ser considerados para generar reglas usando l. Si ABC => D no tiene suficiente confianza, no se necesita chequear la regla AB => CD. No se pierde ninguna regla porque el soporte de cualquier subconjunto â de a es mayor que el soporte de a. Por lo tanto, la confianza de la regla â => (l - â) no puede ser mayor que la confianza de la regla a => (l - a). (Agrawal and Srikant, 1994) 2.2 Remodelación del sistema La versión anterior de la herramienta DBAnalyzer está modelada utilizando la notación UML (Unified Modeling Language), que es un lenguaje visual estándar que se utiliza para especificar, visualizar, construir y documentar los diferentes aspectos relativos al desarrollo de un software. En la identificación de casos de usos y actores de este software son identificados nueve casos de uso y un actor, el analista. El analista realiza tres casos de usos ya que la herramienta es capaz de conectarse a tres gestores de bases de datos Access, SQL y FoxPro y los demás casos de usos están incluidos en ellos. La remodelación del sistema, en la construcción de la versión 4.0 fue realizada utilizando la notación UML de igual manera. 2.2.1 Diagrama de casos de uso En la construcción de la nueva versión de la herramienta DBAnalyzer se reestructuró el diseño anterior del software con el objetivo de realizar una conexión a cualquier gestor y agregarle nuevos métodos de detección de errores. Se identificaron cuatro casos de uso, Conectar a la Base de Datos, Analizar Campos, Buscar RAOB (Reglas 28 de asociación Ordinales Binarias) y Buscar RAK (Reglas de asociación de longitud k) y un actor, que es el analista. En la Figura 2.1 se presenta el Diagrama de Casos de Uso del actor analista. Figura 2.1 Casos de uso para el actor analista. Figura 2.2 Especificación del caso de uso Conexión a la Base de datos. 29 Figura 2.3 Especificación del caso de uso Analizar campos. Figura 2.4 Especificación del caso de uso Buscar RAO binarias. 30 Figura 2.5 Especificación del caso de uso Buscar RA de longitud k. A continuación describimos los casos de uso para este actor: 1. Conectar a la BD: este caso de uso es el encargado de realizar la conexión a la base de datos. Ver Figura 2.2. ♦ Realizar conexión: El actor del sistema es el responsable de seleccionar el proveedor y la base de datos y se lleva a cabo la conexión. ♦ Seleccionar tabla: Se selecciona la tabla a la cual se le desea hacer el análisis. 2. Analizar campos: Este caso de uso (Figura 2.3) realiza un análisis de los atributos o campos de la tabla seleccionada según el perfil de los datos. Tiene como precondición que se debe haber realizado la conexión a alguna base de datos. ♦ Analizar perfil: Se examina el perfil de los campos y muestra medidas estadísticas de los mismos. ♦ Guardar resultados: El actor guarda los resultados mostrados. ♦ Grabar reporte total: El actor guarda un reporte con el análisis del perfil de los datos de todas las tablas de la base de datos sin mostrarlo en la forma visual. 31 3. Buscar RAO binarias: Este caso de uso (Figura 2.4) asocia pares de atributo del mismo dominio para formar una relación de orden y muestra las reglas encontradas y sus excepciones. Tiene como precondición que se debe haber realizado la conexión a alguna base de datos. ♦ Establecer soporte y confianza: El actor establece los valores mínimos de soporte y confianza para la regla. ♦ Buscar reglas: Encuentra reglas entre pares de atributos del mismo dominio y las muestra. ♦ Guardar resultados: El actor guarda los resultados en un fichero txt si lo desea. 4. Buscar RA de longitud k: Busca itemsets frecuentes de longitud mayor o igual que dos y encuentra y muestra reglas interesantes y sus excepciones en el conjunto de datos (Figura 2.5) Tiene como precondición que se debe haber realizado la conexión a alguna base de datos. ♦ Establecer soporte y confianza: El actor establece los valores mínimos de soporte y confianza para la regla. ♦ Buscar reglas de longitud k: Encuentra reglas de longitud mayor o igual que dos y las muestra. ♦ Guardar reporte: El actor guarda los resultados en un fichero txt si lo desea. 2.2.2 Tabla de eventos Se muestra a continuación las tablas de eventos correspondientes a las ventanas modificadas en la herramienta DBAnalyzer mostrando la secuencia de acciones que puede causar la transición del objeto de un estado a otro y la respuesta que recibe el sistema al ejecutarse cada una de estas acciones. Ventana Principal: Flujo básico. ¿Qué hace el actor? ¿Qué hace el sistema? 32 1. Seleccionar en el menú la opción Conexión a la BD. 2. Abrir la ventana de conexión a la BD. 3. Seleccionar en el menú la Ayuda. 4. Abrir la Ayuda General de la aplicación. 5. Seleccionar en el menú la opción Salir. 6. Cerrar la aplicación Tabla 2.2 Tabla de eventos correspondiente a la ventana Principal. Flujo básico. ¿Qué hace el actor? ¿Qué hace el sistema? 1. Presionar el botón Conectar 2. Mostrar el cuadro de dialogo para elegir el proveedor y los datos necesarios para la construcción de la cadena de conexión. 3. Seleccionar tabla de la base de datos 4. Comprueba que es una tabla válida (que pertenece a la base de datos conectada). 5. Cambiar el foco hacia la selección. 6. Presionar el botón Aceptar. 7. Chequear si ha sido construida la cadena de conexión. 8. Mostrar la ventana principal habilitando el menú correspondiente al análisis de datos 9. Presionar botón Cerrar Conexión. 10. Borra la cadena de conexión 11. Habilitar el botón Conectar. Fujo alterno 4a No es una tabla válida 4a-1 Comprueba que no es una tabla válida 33 4a-2 Muestra un mensaje de advertencia. Fujo alterno 7a No se creo la cadena de conexión 7a-1 Mostrar un mensaje de error Tabla 2.3 Tabla de eventos correspondiente a la ventana Conexión a la BD. Flujo básico. ¿Qué hace el actor? ¿Qué hace el sistema? 1. Seleccionar una tabla de la base de datos 2. Comprueba que es una tabla válida (que pertenece a la base de datos conectada). 3. Cambiar el foco hacia la selección. 4. Presionar el botón Buscar Reglas o seleccionar en el menú la opción Análisis/Buscar Reglas. 5. Desplegar la ventana Datos para establecer valores de soporte y confianza. 6. Mostar en un Memo las reglas encontradas. 7. Presionar los botones de desplazamiento >> y <<. 8. Mover las reglas encontradas según su longitud. 9. Seleccionar en el menú la opción Editar/Seleccionar 10. Selecciona todo el contenido del Memo. 11. Seleccionar en el menú la opción Editar/Copiar 12. Copia lo que esta seleccionado. 13. Seleccionar en el menú la opción Editar/Cortar 14. Corta lo seleccionado. 15. Seleccionar en el menú la opción Editar/Salvar 16. Salva en un fichero txt las reglas encontradas. 34 17. Seleccionar en el menú la opción Editar/Salir 18. Cierra la ventana. Fujo alterno 2a No es una tabla válida 2a-1 Comprueba que no es una tabla válida 2a-2 Muestra un mensaje de advertencia. Tabla 2.4 Tabla de eventos correspondiente a la ventana Reglas de asociación ordinales de long k: Flujo básico. ¿Qué hace el actor? ¿Qué hace el sistema? 1. Verifica o modifica el soporte y la confianza y presionar el botón Aceptar 2. Verifica si se han establecido los valores 3. Pasar el control a la ventana Buscar reglas de longitud k 4. Presionar el botón Ayuda. 5. Abrir la ayuda de la aplicación. 6. Presionar el botón Cancelar. 7. Cerrar la aplicación. 8. Mostrar un mensaje de alerta. Fujo alterno 2a No se establecieron los valores 2a-1 Mostrar un mensaje de error. Tabla 2.4 Tabla de eventos correspondiente a la ventana Datos. 2.2.3 Descripción de las clases En la herramienta se implementaron dos nuevas clases la clase TApriori que tiene todos los métodos utilizados para buscar las reglas de asociación de longitud k y 35 TFormOrdinalesLongitud_k que tiene todo lo referente a la forma visual. A continuación se hará una breve descripción de ambas clases. Clase TApriori Para guardar los itemset frecuentes desde la longitud dos hasta k se utilizó la estructura de datos Lista y para almacenar las reglas de una longitud dada se utilizó la estructura TRules, ambas creadas en la unit UTipos que almacena los tipos utilizados en la elaboración del sistema. Figura 2.6 Visualización de la estructura de datos List. Un Itemset es un registro que contiene un Items de tipo TStringList que almacena un conjunto de ítems y una variable suport de tipo entero que guarda la cantidad de registros que contienen los Items. Entonces, un Itemsets es un arreglo de Itemset. Con estas definiciones se forma un Registro que contiene el conjunto de Itemset Lk y el valor de k para el mismo. La estructura de datos List no es más que un arreglo de Registro. Ver Figura 2.6. La estructura de datos TRules esta compuesta por un arreglo de reglas. Una regla esta formada por un antecedente y un consecuente de tipo cadena y su valor de soporte y confianza de tipo real, además contiene un arreglo incumplen que almacena los registros que no cumplen la regla. A continuación se presenta la descripción de los atributos y métodos de la clase. 36 Atributos: ♦ L : List; Almacena los itemsets frecuentes desde la longitud 2 hasta k ♦ R : TRules; Almacena las reglas de una longitud dada Métodos: ♦ procedure Find_itemset_len1 (var L1: Itemsets; suport_min: real); Busca los itemsets frecuentes de longitud uno. ♦ function CompareItemset (v1,v2 : Itemset): integer; Compara los itemset devolviendo cero si no son iguales, uno si lo son y dos si la diferencia es el último elemento. Si este método devuelve dos entonces se podrá hacer la unión. ♦ function CombineItemset (v1, v2: Itemset) : Itemset; Combina los itemset v1 y v2. ♦ procedure AddCandidate (c : Itemset; var Ck: Itemsets); Adiciona del conjunto de itemset candidatos Ck el itemset c. ♦ function DeleteCadidate (c : Itemset; var Ck : Itemsets): boolean; Elimina del conjunto de itemset candidatos Ck el itemset c. ♦ procedure CountSuport (c: Itemset; k: integer; var sop: real); Cuenta el soporte del itemset c guardándolo en la variable sop. ♦ procedure Get_Atribute_Value (Str: string; var atribute: string; var value: string); Separa en las variables attribute y value, el nombre del atributo y su valor respectivamente, según el carácter ‘|’ que los separa en el ítem. ♦ procedure Assign (var Lk : Itemsets; Ck : Itemsets); overload; Asigna al conjunto de itemset Lk, el conjunto de candidatos Ck. ♦ procedure Assign (var Lk : Itemset; Ck : Itemset); overload; Asigna a un itemset Lk un itemset candidato Ck. ♦ function Pertenece (sub: Itemset; Lk : Itemsets): boolean; Devuelve verdadero si el nuevo itemset sub pertenece al conjunto de itemset anterior Lk {en este caso seria Lk-1}. 37 ♦ procedure Join (Lk: Itemsets; k : integer; var Ck: Itemsets); Realiza la unión para buscar candidatos. ♦ procedure Apriori_gen (Lk : Itemsets; k : integer; var Ck :Itemsets; var b : boolean); Utiliza el conjunto de itemset frecuentes anterior para generar candidatos. En este caso Lk indica Lk-1, la variable k guarda la longitud que tiene los itemset a generar, en la variable Ck se almacenara el conjunto de itemset candidatos si se logró generar alguno y la variable b tomará el valor verdadero, de lo contrario Ck estará vacío y b será falso. ♦ procedure Apriori (suport_min: real; var max_k: integer); Busca los conjuntos de itemset frecuentes. Aquellos que cumplan con el soporte mínimo, soport_min. Almacena en la variable max_k el valor máximo que tomo k, es decir la máxima longitud que tomaron los itemset encontrados. ♦ procedure Buscar_Reglas_k (Ite: Itemsets; conf_min: real; k: integer; var Memo: TMemo; var Edit: TEdit); Busca las reglas de longitud k que cumplan con la confianza mínima utilizando el conjunto de itemset Ite y manda a mostrarlas en la forma visual. ♦ procedure Calcular_Confianza (c: TStringList; j: integer; cant_cump: integer; var incumplen: StrArr; var conf: real); Calcula la confianza de un regla utilizando en itemset de la conclusión de la misma y la cantidad de registros que cumplen todo el itemsets de la regla. Amacena en el arreglo incumplen aquellos registros que no cumplen la regla. ♦ procedure Divide_Items(c: TStringList; j: integer; var cad1: string; var cad2: string); Forma dos cadenas cad1 y cad2 dividiendo un itemsets por el índice j. ♦ procedure Mostrar_Reglas (var Memo : TMemo; var Edit : TEdit; k : integer); Muestra las reglas de longitud k en la forma visual. ♦ procedure Buscar_Reglas (conf_min: real; var Memo: TMemo; var Edit: TEdit; k: integer); Genera las reglas de asociación utilizando los itemset encontrados. Clase TFormOrdinalesLongitud_k Esta clase utiliza la clase descrita anteriormente. 38 Atributos: ♦ Index: integer; Valor de k en el que estoy actualmente. Se utiliza para ir mostrando las reglas de esa longitud. ♦ max: integer; Esta variable almacena la máxima longitud de los itemset frecuentes encontrados. ♦ Ap: TApriori; Objeto de la clase TApriori. Métodos: ♦ procedure TFormOrdinalesLongitud_k.FormCreate (Sender: TObject); Se inicializan todos los componentes y las variables. ♦ procedure TFormOrdinalesLongitud_k.BreglasClick (Sender: TObject); Muestra la ventana Datos donde se establecen los valores de soporte y confianza mínimos. Luego ejecuta el Apriori y manda a buscar y mostrar las reglas de longitud dos. Actualiza el valor de la variable index en dos. ♦ procedure TFormOrdinalesLongitud_k.BPosClick (Sender: TObject); Busca y muestra las reglas de longitud uno mayor que el valor de index. Actualiza el valor de la variable index ♦ procedure TFormOrdinalesLongitud_k.BAntClick (Sender: TObject); Busca y muestra las reglas de longitud uno menor que el valor de index. Actualiza el valor de la variable index ♦ procedure TFormOrdinalesLongitud_k.SalvarClick (Sender: TObject); Salva los resultados que estén en el Memo para un fichero de extensión txt. ♦ procedure TFormOrdinalesLongitud_k.Ayuda_GralClick (Sender: TObject); Muestra la ventana de ayuda general. ♦ procedure TFormOrdinalesLongitud_k.CBtabla1Change (Sender: TObject); Actualiza en valor de la variable TablaSeleccionada con el valor seleccionado en el ComboBox. ♦ procedure TFormOrdinalesLongitud_k.Salir1Click (Sender: TObject); Cierra la ventana. 39 2.3 Conclusiones del capítulo. El algoritmo empleado para descubrir las reglas, denominado Apriori, fue seleccionado para usar en esta herramienta debido a que ha sido descrito en la literatura como básico en la técnica de reglas de asociación en la Minería de Datos. Además se revisaron algunos software profesionales de minería de datos como el WEKA en los cuales estaba implementado. Este algoritmo permite descubrir relaciones entre varios atributos independientemente de su dominio, y así esto posibilita que en la detección de errores se tenga en cuenta el incumplimiento de estas relaciones. El capítulo ofrece además algunos diagramas del UML que permitieron la elaboración de una nueva versión de la herramienta DBAnalyzer. 40 CAPÍTULO III Análisis de errores en bases de datos reales. El manejo de grandes volúmenes de información es un rasgo distintivo de los sistemas de información en la actualidad, aspecto este que ha motivado el estudio de la calidad de los datos que son procesados en ellos. En los sistemas de bases de datos actuales se favorecen la calidad de los datos que ellos almacenan a través de los metadatos y las restricciones de integridad, no obstante, cuando estos datos son analizados se observa que también están permeados de errores. Esto se debe a varias razones y algunas de ellas son presentadas en (Dasu, 2003), por ejemplo: • Una cantidad significativa de datos está almacenada en bases de datos prerrelaciónales, hojas de cálculos, ficheros log y estructuras ad-hoc. • Los datos son entrados al sistema de forma incorrecta debido por ejemplo a errores tipográficos, y algunos otros errores. • El administrador de la base de datos no entiende como aplicar las facilidades que ofrece el gestor para mantener la integridad de los datos, o no las usa, porque el chequeo de restricciones es muy costoso y por tanto lo deshabilita o pierde tiempo en asignar las restricciones y decide no hacerlo. La definición de una taxonomía de errores no es tan obvia, pues no solo depende del contexto en el que se estén analizando los datos sino también de cómo clasificarlos en un tipo de error determinado. En la literatura se reporta el trabajo de Greenfield, (Greenfield, 1997) que aporta una taxonomía informal con 26 tipos de errores y un poco más reciente fue publicada la “Taxonomía de datos sucios” de Kim et al.(Won and Choi, 2003) En nuestra localidad varias empresas u organismos cuentan con grandes volúmenes de información y algunas de sus bases de datos han sido seleccionadas para realizar el estudio sobre la calidad de los datos. Es decir, mediante el análisis de estas bases de datos reales según la nueva versión de la herramienta de detección de errores DBAnalyzer, se determinará posibles errores encontrados lo que servirá 41 posteriormente para establecer una taxonomía de errores propia para enfrentar el proceso de limpieza de datos. 3.1 Errores determinados por el DBAnalyzer 4.0. En la Universidad Central “Marta Abreu” de Las Villas se maneja grandes volúmenes de información para los cuales se necesita de una alta precisión de los datos. En la misma existen dos departamentos donde la información se encuentra almacenada en bases de datos creadas en SQL Server, el Departamento de Economía y el de Recursos Humanos. Estas bases de datos han sido utilizadas para constatar la funcionalidad del software DBAnalyzer versión 4.0, es decir, determinar si son encontrados posibles errores mediante el análisis de los datos que realiza la herramienta. 3.1.1 Perfil de los datos. El análisis de los datos mediante el perfil de los mismos muestra datos capaces de revelarnos algunos posibles errores que existen en las bases de datos. Según los resultados obtenidos del reporte realizado sobre las bases de datos del Departamento de Economía y de Recursos Humanos por el perfil de los datos fueron corroborados algunos de los criterios que se tenía a priori, uno de ellos fue que muchos de los errores detectados se deben a errores de diseño de la base de datos y a la no utilización de las restricciones de integridad, a las que el modelo relacional da tanta importancia. Analicemos ahora con más detalles los posibles errores encontrados. Base de datos de Recursos Humanos. Errores relativos al diseño de la base de datos: La base de datos de Recursos Humanos contiene un total de 166 tablas de las cuales 47 se encuentran vacías y 20 contienen menos de tres registros lo que constituye un tipo de error que revela problemas de diseño de la base de datos. El mal diseño está dado generalmente que las personas que lo realizan no son especialistas del tema y construyen tablas pensando en una futura utilización y que en realidad no son necesarias o crean tablas con resultados de un reporte que se llenará temporalmente en un momento dado y que pudiera ser sustituida por una consulta. 42 Existen dos tablas con un campo vacío y dos con cuatro campos vacíos lo cual constituye también, un problema de diseño. Errores por la utilización de valor por defecto como valor ausente: En la base de datos existen 16 tablas que tienen campos con valores por defecto que representan ausencia de valor, en particular la utilización de valores por defecto como el cero y la cadena vacía en lugar del uso del Null para indicar la ausencia del dato. Por ejemplo, en campos de tipo entero se registraron seis tablas que utilizaban el cero como valor por defecto y en una de ellas existía siete campos con este problema. Se hallaron 15 tablas con campos de tipo moneda con todos sus datos ceros, de ellas cuatro con nueve campos en iguales condiciones, y una con 24 campos y con 7333 registros. Además se detectaron dos tablas con un campo y una con diez campos de tipo cadena con todos sus datos igual a la cadena vacía, todas con más de 10412 registros. Errores de información incorrecta entrada al sistema: Existe una tabla Empeado_Gral que contiene información de los trabajadores del centro, la misma contiene un campo denominado Nombre_Madre, campo que tiene 4503 datos igual a la cadena vacía y presenta datos que no representan nombres tales como: Cadena: '-' Número de ocurrencias: 348 Cadena: 'A' Número de ocurrencias: 15 Cadena: 'AA' Número de ocurrencias: 25 Cadena: 'AB' Número de ocurrencias: 1 Cadena: 'b' Número de ocurrencias: 1 Cadena: '`A' Número de ocurrencias: 1 Cadena: 'a' Número de ocurrencias: 1 Estos datos indican error de información incorrecta entrada al sistema, es el error que se comete en el proceso de entrada, por errores tipográficos u de otro tipo. Este tipo de error de igual forma fue descubierto en la misma tabla con el campo 43 Nombre_Padre el cual contiene 4514 cadenas vacías y cadenas presentadas de la forma siguiente: Cadena: '_' Número de ocurrencias: 1 Cadena: '____' Número de ocurrencias: 1 Cadena: '-' Número de ocurrencias: 39 Cadena: '- -' Número de ocurrencias: 11 Cadena: '--' Número de ocurrencias: 11 Cadena: '---' Número de ocurrencias: 7 Cadena: '----' Número de ocurrencias: 23 Cadena: ' ----' Número de ocurrencias: 15 Cadena: ' --' Número de ocurrencias: 1 Cadena: 'G' Número de ocurrencias: 6 Cadena: 'E' Número de ocurrencias: 8 Cadena: 'A' Número de ocurrencias: 3 Cadena: 'AA' Número de ocurrencias: 2 La tabla Empleado_Gral tiene un campo Teléfono cuyo atributo contiene 10188 cadenas vacías, dato no muy relevante puesto que no todo trabajador tiene un teléfono pero a su vez puede que sea un error puesto que de 10412 empleados solo 224 lo tienen. Este campo además tiene errores de entrada al sistema ya que existen cadenas tales como ‘.’ y ‘0’ repetidas dos veces en el conjunto de datos y que no indican un número telefónico. Existe una tabla RH_Expedientes_Deducciones que tiene un campo Nombre, el cual contiene cadenas con números delante, un campo Dirección con cadenas como ‘0.0’, ’59.’, ’62.’, y un campo Nota con cadenas iguales a ‘.’, ‘0’, ’00’, lo que representa un error. Existe además la tabla RH_Generales_Reporte_Ajustes con la cadena vacía en 69 registros y con la cadena ‘101 ’ en seis registros del campo Id_User. 44 Errores en la definición del tipo de campo: En la tabla Empleado_Gral también existe un campo Estatura definido de tipo moneda cuando debe ser un campo de tipo real, con ello es detectado un error en la definición del tipo de campo. Además este campo presenta 10411 ceros de 10412 registros de la tabla. Errores en el carné de identidad: Otro campo detectado con errores fue el carné de identidad de la tabla Empleado_Gral, donde se encontraron carnés de longitud menor que 11 caracteres y 15 ocurrencias de la cadena vacía, además se pudo apreciar falta de restricciones en el diseño de la base de datos. Otros errores: En tabla Empeado_Gral existe un campo denominado AñosServicio cuyo campo presenta 7750 ceros de un total de 10412 registros, esto es un posible error ya que todo trabajador debe tener algún tiempo de servicio. Base de datos del Departamento de Economía. Errores relativos al diseño de la base de datos: Con el análisis realizado a la base de datos del Departamento de Economía de la UCLV se detectó 310 tablas que se encuentran vacías y 24 que tienen menos de cinco registros de un total de 456 tablas, este error está dado por el mal diseño de la base de datos. Existen 29 tablas con campos vacíos entre ellas hay una con 27 campos, de 34 que presenta la tabla, que están vacíos; además hay una tabla con 13, una con 11 y dos con siete campos vacíos de más de 50 000 registros cada una, lo cual constituye también, un problema de diseño. Errores por la utilización de valor por defecto como valor ausente: Conjuntamente se hallaron varias tablas que tienen campos con valores por defecto que representan ausencia de valor. Se utilizan valores por defecto como el cero y el uno para campos de tipo entero y moneda, y la cadena vacía para campos de tipo 45 cadena en lugar del uso del Null para indicar la ausencia de valor. En la base de datos se detectaron 37 tablas con campos de tipo entero con todos sus datos ceros y 13 con sus valores igual a uno, se hallaron además 32 tablas con campos tipo moneda iguales a cero y cinco con valor uno, una de estas tablas contiene 39 campos con sus datos igual a cero y 25277 registros. Así mismo se encontraron 32 tablas con campos de tipo cadena con todos sus valores igual a la cadena vacía. Errores de información incorrecta entrada al sistema: Existe una tabla Empleado_Gral que contiene un campo Telefono que, al igual que en la base de datos de Recursos Humanos, presenta los mismos errores, datos como las cadenas ‘.’, ‘0’.’2’, que no representan un número telefónico. Esta tabla también contiene un campo Direccion que tiene datos como cadenas de números o un carácter, detectado como un error ya que en muestro país las direcciones están constituidas por más datos como el nombre del municipio, el de la provincia y en el caso que en la base de datos estos datos se almacenen como otro atributo el campo dirección debe contener la localidad, etc. También se halla una tabla Recepcion con un campo Chofer y uno Pais que en sus datos tienen cadenas como ‘.’, ‘01’respectivamente, siendo los demás valores nombres. Errores en el carné de identidad: En el campo Nro_CI de la tabla Empleado_Gral se encontró un carné de identidad con longitud menor de 11 caracteres y 22 ocurrencias de la cadena vacía. Otros tipos de errores: Esta base de datos del departamento de Economía tiene una tabla denominada Acceso la que contiene un campo Id_User que almacena el nombre de usuario de los trabajadores del sistema. Este campo tiene datos tales como: Cadena: '0001 ' Número de ocurrencias: 343 Cadena: '09 ' Número de ocurrencias: 305 Cadena: '1505 ' Número de ocurrencias: 343 Cadena: '50 ' Número de ocurrencias: 305 46 Cadena: '72081 ' Número de ocurrencias: 305 Cadena: '90 ' Número de ocurrencias: 305 Cadena: '94 ' Número de ocurrencias: 305 Estos datos son repetidos en 18 tablas de la base de datos y fueron seleccionados como posible error porque un nombre de usuario representa una persona, y una cadena de números no le da claridad al dato. Nos referimos a que un número no da idea de cual es la persona que hemos referenciado con él, lo que no indica que no sea posible utilizarlo con este objetivo. 3.1.2 Reglas de asociación ordinales binarias. La herramienta de detección de errores DBAnalyzer 4.0 reporta relaciones de orden entre atributos del mismo dominio. En el análisis de la información almacenada en las bases de datos del departamento de Economía y el de Recursos Humanos se detectaron mayormente relaciones entre atributos de tipo fecha y de tipo moneda, aunque también fueron descubiertas relaciones de tipo cadena pero sin ningún valor significativo. Para la búsqueda de las reglas se determinó la utilización de valores de soporte y confianza altos y se escogió el valor 0,96 con este fin. Base de datos de Recursos Humanos. En la base de datos de Recursos humanos se realizó la búsqueda en 119 tablas que no se encontraban vacías, de las cuales existen 53 tablas donde no se obtuvieron asociaciones entre pares de atributos. En la tabla RH_AjustesSubmayorRetenciones se encontraron reglas entre atributos de tipo moneda que reportan registros que no la cumplen que pueden ser considerados como posibles errores, reglas tales como: Valor_Deduccion menor que (<) Saldo soporte = 1 y confianza = 0,992125984251969 Registros que no la cumplen: 69, 196 Saldo mayor que (>) Ajuste soporte = 1 y confianza = 0,968503937007874 47 Registros que no la cumplen: 69, 105, 110, 116, 196, 232, 237, 243 En la tabla RH_Detalles_Reporte_CLA existen relaciones binarias de tipo moneda tales como: Horas mayor que (>) Tarifa soporte = 1 y confianza = 0,999689054726368 Horas mayor que (>) Importe soporte = 1 y confianza = 0,999689054726368 Estas reglas no son cumplidas al ciento por ciento, solo el registro 1126 constituye un posible error si es tomada en cuenta la misma como una regla significativa. Se detectaron reglas de tipo moneda en la tabla RH_Detalles_Reporte_Nominillas_Mov donde son varios los registros detectados como posibles errores, alguna de estas reglas se muestran a continuación: Importe mayor que (>) Salario_Acumulado soporte = 1 y confianza = 0,999905612293055 Registros que no la cumplen: 7924, 14453, 14454, 49760, 14455 Importe mayor que (>) Tarifa_Divisa soporte = 1 y confianza = 0,999905612293055 Registros que no la cumplen: 14453, 49760, 14455, 14454 Importe mayor que (>) Divisa_Factura soporte = 1 y confianza = 0,999905612293055 Registros que no la cumplen: 14453, 14454, 14455, 49760 En la base de datos hay una tabla denominada RH_Historico_Empleados_Bajas donde fueron detectadas 156 reglas entre atributos de tipo moneda, entre estas 134 con soporte y confianza de valor uno, esto puede suceder ya que se realizó el análisis de la base de datos considerando todas las tablas y en el resultado obtenido con el análisis individual se detectó varios campos con valores por defecto igual a cero por lo que al buscar las reglas se encontraron varias en que un atributo es igual a otro en todos sus instancias. A pesar de ello existen reglas como por ejemplo, el 48 Salario_Basico es mayor que el Estimulo, que el Porciento_Estimulo y mayor que la Antigüedad que deben cumplirse siempre en toda base de datos que almacene datos semejantes. También se encontraron reglas como: Salario_por_Cargo menor que (<) CoeficienteTarifa soporte = 1 y confianza = 0.960629921259842 Registros que no la cumplen: 10, 35, 72, 75, 122 Para esta regla existen cinco registros que no cumplen con ella los cuales son detectados como posibles errores. Además de las reglas de tipo moneda descubiertas en la tabla RH_Historico_Empleados_Bajas se encontraron reglas que involucran atributos de tipo fecha tal como, la Fecha_Contratacion es menor que la Fecha_Baja con un soporte igual a uno y una confianza de 0.984251968503937 lo que indica que existen posibles errores, es decir, los registros 0 y 23 no cumplen con esta regla constituyendo un error. Otra regla de tipo fecha fue encontrada en la tabla RH_Variaciones_Plantilla donde la Fecha_Propuesta se relaciona con la Fecha_Aprobada en igual orden, en otras palabras son iguales con un 100 por ciento de soporte y un 98,7 por ciento de confianza. Existen 58 registros que la incumplen. Base de datos del Departamento de Economía. La base de datos del Departamento de Economía contiene 146 tablas que no se encuentran vacías de un total de 456 tablas, las cuales fueron analizadas en busca de relaciones binarias de orden entre sus atributos del mismo dominio. Como resultado de esta búsqueda se encontraron 104 tablas donde no se obtuvieron asociaciones entre pares de atributos. Según el reporte obtenido se detectó reglas entre atributos de tipo cadena, moneda, entero, de tipo fecha, sin embargo las reglas entre cadenas y enteros no brindan información relevante. Por ejemplo, el Nombre es mayor que el Id_Ccosto en la tabla Empleado_Gral lo cual entre cadenas puede ser cierto o no. En la tabla Activo_Fijo formada por 143902 registros se obtuvieron reglas de tipo moneda como por ejemplo el Valor_InicialMC es mayor que la 49 Depreciacion_Mensual y mayor que Depreciacion_MensualMC, ambas con un soporte de uno y una confianza de 0,965921251963142 y 0,96651888090506 respectivamente. Se descubrieron varios registros que no cumplen estas reglas. Además se reportaron en esta misma tabla reglas entre atributos de tipo fecha tales como: Fecha_Alta menor que (<) Fecha_EstadoActual soporte = 1 y confianza = 0,984058595433003 Fecha_Alta menor que (<) Fecha_Conteo soporte = 1 y confianza = 0,990813192311434 Fecha_EstadoActual menor que (<) Fecha_Conteo soporte = 1 y confianza = 0,986212839293408 En la tabla Detalle_Ajuste resultaron interesantes reglas de tipo moneda como por ejemplo: Costo_NuevoMB igual que (=) Precio_CostoUmAlmacenMB soporte = 1 y confianza = 0,972288744440643 Precio_CostoUmAlmacenMC mayor que (>) ImporteA_MB soporte = 1 y confianza = 0,960998973657202 Precio_CostoUmAlmacenMC mayor que (>) ImporteD_MB soporte = 1 y confianza = 0,962025316455696 Precio_CostoUmAlmacenMC mayor que (>) ImporteCosto_MB soporte = 1 y confianza = 0,976052001368457 ImporteA_MB igual que (=) ImporteCosto_MB soporte = 1 y confianza = 0,965446459117345 También en la tabla Detalle_PPagos se encontraron relaciones en los atributos de tipo fecha Fecha_Emision, Fecha_Despacho y Fecha_Vence, donde la primera es menor que las dos últimas con un soporte de uno y una confianza de 0,984 para ambas reglas. 50 3.1.3 Reglas de asociación de longitud k. En la búsqueda de resultados aceptables según el descubrimiento de reglas de asociación de longitud k implementado en la nueva versión del software DBAnalyzer se analizaron aquellas tablas que contenían gran cantidad de información desechando aquellas que tenían menos de 40 registros. Además para la prueba del algoritmo se utilizaron valores de soporte y confianza altos tomando el valor 0,96. Base de datos de Recursos Humanos. De un total de 166 tablas que almacena la base de datos de Recursos Humanos se analizaron 95 y se encontraron relaciones entre atributos en 10 tablas. El resultado obtenido muestra relaciones entre dos atributos en ocho tablas y solo en dos se encontraron asociaciones entre más de dos atributos. Por ejemplo, en las tablas RH_Tablas_Comm con solo 75 registros y RH_Detalles_Reporte_Nominillas_Mov con 50 registros se descubrieron reglas tales como las siguientes: ♦ Enviar|False, Recibir|False, Fecha_Recibo|27/03/2007 15:08:00, Recibido|False, Rwhere|n/a, OKSend|True => OKReceive|True Soporte: 0,973333333333333 Confianza: 1 Record que la incumplen: 27, 44 ♦ Recibir|False, Fecha_Recibo|27/03/2007 15:08:00, Recibido|False, Rwhere|n/a, Truncar_Tabla|False, OKSend|True => OKReceive|True Soporte: 0,96 Confianza: 1 Record que la incumplen: 9, 26, 44 ♦ Clasificacion|1, Nivel|5, Otros|0, Estimulacion|0, Porciento_Estimulacion|0, Impresa|False => Impresa_Grupo|0 Soporte: 0,96 Confianza: 1 Record que la incumplen: 18, 21 51 Las dos primeras correspondientes a la tabla RH_Tablas_Comm y la última a la tabla RH_Detalles_Reporte_Nominillas_Mov. También en la tabla RH_Historico_Subsidio conteniendo 12607 registros se detectó registros que no cumplen con dos de las reglas encontradas mostrados a continuación. ♦ Perfeccionamiento|0 => Marca|N Soporte: 0,995240739271833 Confianza: 1 Record que la incumplen: 45, 96, 101, 273, 393, 473, 535, 882, 1022, 1453, 1616, 1648, 1788, 1908, 2040, 2176, 2293, 2415, 2584, 2787, 2976, 3140, 3143, 3204, 3238, 3277, 3315, 3378, 3535, 3646, 3737, 3934, 4075, 4201, 4349, 4498, 4644, 4775, 4929, 5056, 5160, 5281, 5424, 5561, 5702, 5836, 5991, 6140, 6283, 6424, 6567, 6690, 6782, 6907, 7050, 7192, 7329, 7448, 7581, 7722 ♦ Marca|N => AjusteCentavos|0 Soporte: 0,995240739271833 Confianza: 1 Record que la incumplen: 45, 96, 101, 273, 393, 473, 535, 882, 1022, 1453, 1616, 1648, 1788, 1908, 2040, 2176, 2293, 2415, 2584, 2787, 2976, 3140, 3143, 3204, 3238, 3277, 3315, 3378, 3535, 3646, 3737, 3934, 4075, 4201, 4349, 4498, 4644, 4775, 4929, 5056, 5160, 5281, 5424, 5561, 5702, 5836, 5991, 6140, 6283, 6424, 6567, 6690, 6782, 6907, 7050, 7192, 7329, 7448, 7581, 7722 En la tabla RH_Detalles_Reporte_Vacaciones_Ret se detectaron 229 registros que no cumplen que siempre que el Mes sea igual a 7 tiende a que el atributo Del_Mark sea igual a False con un soporte de 0,970442672532307 y uno de confianza. Base de datos del Departamen