Business intelligence
Luis Enrique
Sánchez Crespo
Data Cleaning para Data Warehouse
Realizado por:
Luis Enrique Sánchez Crespo.
Daniel Villafranca Alberca.
Dirigido por:
Mario Gerardo Piattini Velthuis
Curso de doctorado: Tecnologias Avanzadas de
Informática.
Asignatura: Tecnología y Diseño de Bases de Datos
Avanzados.
Departamento de Lenguajes y Sistemas
Informáticos.
Universidad de Castilla
Ciudad Real, 2000
Ó Todos los derechos reservados
ÍNDICE
1.- Introducción al data warehousing.
2.- Introducción al data cleaning.
3.- Importancia del data cleaning.
4.- Principales fuentes de impurezas en los datos.
4.1.- Ejemplos de errores clásicos.
5.- ¿ limpiar o no limpiar?.
6.- Plan para la elaboración de un data cleaning.
7.- Funciones clásicas de las herramientas de limpieza.
7.1.- conversión y normalización de funciones.
7.2.- limpieza de proposito-especial.
7.3.- limpieza de dominio-independiente.
7.4.- limpieza basada en reglas.
7.4.1.- reglas especificadas por el usuario.
7.4.2.- reglas derivadas de forma automática.
7.5.- Ejemplo de herramienta comercial: datacleanser.
8.- Fases en que se divide el data cleaning.
8.1.- Limpieza post-integración.
8.2.- Similitudes entre registros.
8.2.1.- Herramientas de post-integración: soundex codes.
9.- Como implementar un algortimo de data-cleaning.
9.1.- fichero de control.
9.2.- fichero de datos.
9.3.- fichero de salida.
9.4.- implementación de un algoritmo de data cleaning en pseudocodigo.
10.- Ejemplos reales de aplicación de data cleaning.
10.1.- Limpieza de datos tóxicos y costes asociados.
10.1.1.- Introdución.
10.1.2.- Aplicación práctica.
10.2.- Data cleaning para modelos de computación: un caso de estudio en inmunología.
10.2.1.- Introducción.
10.2.2.- Métodos y materiales.
10.2.3.- Resultados y conclusiones.
10.2.4.- Discusión.
11.- Data-cleaning: en aplicaciones web.
12.- Conclusiones sobre la limpieza de datos.
13.- Referencias.
13.1.- Direcciones web sobre data warehouse y data cleaning.
13.2.- Bibliografia utilizada.
14.- Vocabulario asociado.
Planteamiento del
problema y objetivos:
Actualmente, toda la teoría de mercados financieros se encuentra basada en el estudio de la evolución de los índices y valores disponibles en estos mercados. Los índices son formulas matemáticas que han sido desarrolladas de forma minuciosa para cumplir un objetivo especificado (obtención de un valor indicativo del objetivo perseguido), y que en la mayor parte de los casos son obtenidos a partir de los valores de las empresas cotizadas en dichos mercados.
El mercado de corros, que es el que se usaba inicialmente y que hoy tiende a desaparecer, era un mercado poco dinámico y en el que los analistas disponían de tiempo para realizar un estudio de la situación y en base a ello tomar decisiones.
Con la aparición del mercado continuo que usaba un tratamiento informatizado de la situación, el volumen de datos manejados por sesión se multiplico por mil, con lo que los analistas ya no disponían del tiempo necesario para realizar los cálculos, y la capacidad de la mente humana quedo limitada en la toma de decisiones ante la incapacidad de poder analizar los datos de una forma que permitiera la correcta toma de decisiones.
En un contexto tan caótico, en el que los expertos se ven incapacitados para usar los conocimientos que adquieren de forma correcta, ya que una vez analizados los datos estos se encuentran desfasados con respecto a la nueva situación, aparecen unas nuevas herramientas desarrolladas a partir de las ciencias de la computación y que dan una solución a esta situación.
La idea básica de este nuevo conjunto de herramientas consiste en crear sistemas que sean capaces, por una parte de mantener toda la información necesaria para la correcta toma de decisiones y por otra parte aprender de los expertos la forma en que estos tomaban las decisiones, de esta forma y dado que la potencia de calculo de las computadoras actualmente es mucho mayor que el de las personas, las maquinas se encontrarán en una posición privilegiada con respecto a los expertos para la toma de decisiones.
Es decir, los problemas que han aparecido son debidos a la cantidad de datos que permiten manejar las computadoras, los cuales tienen que ser interpretados por expertos humanos y aplicados de nuevo sobre computadora, a lo largo de este proceso máquina - humano - máquina, se produce un cuello de botella debido a la limitada capacidad de calculo de la mente humana, luego la solución pasa por eliminar este cuello de botella y sustituirlo por un elemento que tenga la misma capacidad de calculo que los extremos del proceso.
El estudio de cual podría ser este elemento, nos lleva a la solución más sencilla, el elemento conocido con mayor capacidad de calculo son las computadoras, luego esta deberá ser la herramienta que sustituya a los expertos, pero está sustitución debe ir acompañada de otro tipo de herramientas, las necesarias para que las computadoras puedan tomar las mismas decisiones que tomaría un experto si tuviera su capacidad de calculo, es decir, necesitan el conocimiento.
Después de este análisis vemos como la problemática actual en los mercados financieros queda reducida a un sencillo problema, debemos enseñar a las computadoras a adquirir conocimiento y a usarlo de forma correcta, y estos son precisamente los objetivos en los que se basa este proyecto.
Para poder llevar a cabo los objetivos, se necesita un sistema que permita tener los datos necesarios para que el sistema pueda aprender como un niño hasta obtener el conocimiento de un experto, y por tanto la primera fase del proyecto implicaba el diseño y construcción de una base de datos.
Una vez que el sistema tiene los datos necesarios para aprender, nos falta desarrollar una herramienta que le permita aprender a predecir la evolución de una determinada variable a partir de los datos que tenemos en la base de datos.
La elección de esta herramienta es un proceso difícil, ya que no existen herramientas especificas para el problema planteado. La solución aparece de la mano de las ciencias de la computación, a través de las redes neuronales, que junto a los datos necesarios y la potencia de las computadoras se convierten en los elementos ideales para sustituir a los expertos, esto es posible gracias a la potencia de aprendizaje que tienen la redes neuronales, y que aplicando los parámetros adecuados a los datos adecuados, no solo aprenderá a tomar las decisiones de un experto, sino también a mejorarlas.
Luego, este proyecto pretende
desarrollar un sistema que permita usar las nuevas tecnologías de la
información para poder predecir la evolución de ciertas variables relacionadas
con los mercados financieros y el desarrollo de nuevas técnicas de control en
los sistemas financieros que permitan, un mayor control sobre el sistema
económico actual.
Dado que la magnitud del proyecto es
demasiado ambiciosa para un proyecto final de carrera, se ha considerado la
conveniencia de dividirlo en fases, de forma que puedan ser unidas después en
un sólo módulo funcional, que permita realizar los objetivos fijados. Para ello
a lo largo de las fases del proyecto se desarrollarán herramientas que puedan
funcionar de manera independiente, y que además permitan la mayor versatilidad
y manejabilidad posible, de forma que puedan funcionar como módulos
independientes con la posibilidad de poder conectarse entre sí, para formar un
modelo de predicción complejo a partir de objetos mucho más sencillos.
Los procedimientos y funciones que
compongan el núcleo de las herramientas se construirán en un lenguaje con la
máxima portabilidad (C++), de forma que el esfuerzo para llevarlo a otras
estructuras (portabilidad) sea el mínimo posible, además, se tratará de
desarrollar y explicar paso a paso tanto las operaciones que se implementen,
como el funcionamiento de los algoritmos principales, para que, en caso de que
no se pueda usar el código desarrollado en el sistema deseado, sea lo más fácil
posible su implementación en el sistema al que se quiera portar.
Para desarrollar el interface para
las herramientas usaremos entornos visuales, ya que nos permiten construir
objetos independientes en los que podemos definir los métodos y eventos de una
forma sencilla.
La
viabilidad del proyecto, se sustenta en el hecho de que los mercados
financieros se asientan sobre modelos matemáticos computables y, por tanto,
computable, y que aunque algunos "gurús" hayan dado un significado
esotérico a la predicción de mercados financieros, esta forma de ver los
mercados no es la correcta. Por lo tanto, el sistema intenta aunar los métodos
clásicos de funcionamiento de los mercados financieros con las herramientas más
modernas de la inteligencia artificial, para poder llegar a desarrollar nuevos
mecanismos o herramientas de control financiero.
Por todo lo expuesto anteriormente, es fácil deducir que en el proyecto se han previsto los siguientes objetivos:
1ª) fase: Desarrollo de una base de
datos, que contenga las variables más importantes para la predicción de índices
y valores.
2ª)
fase: Desarrollo de una red neuronal de tipo Backpropagation que usando la
base de datos desarrollada en el punto anterior sea capaz de predecir con una
desviación aceptable la evolución de una serie de valores o índices.
CAPÍTULO 1:
Introducción al data
warehousing.
El data warehouse (data warehouse)
es una colección de datos integrados, bases de datos orientadas al sujeto
(subject-oriented) diseñadas para funciones de soporte de decisiones, donde
cada unidad de datos es relevante en algún momento puntual. La fuente de datos
que componen el data warehouse pueden ser de diferentes bases de datos,
incluyendo los sistemas heredados (legacy systems). Los datos de un data
warehouse no son usados para las operaciones diarias de negocios, pero sí para
la toma de decisiones que pueden afectar a la rentabilidad. Por consiguiente
los datos no cambian cada minuto y normalmente representa un instante puntual
estático. Los datos se introducen en el data warehouse en el momento que estos
empiezan a ser estables, lo cual significa que los datos del data warehouse no
son volátiles. Un diagrama que muestra la arquitectura de un
data warehouse sería el siguiente:
El mayor problema al que se enfrenta
un data warehouse es la existencia de datos redundantes. Lo ideal es que las
grandes bases de datos sean reemplazadas por un solo subconjunto de modelos de datos.
El problema reside en definir esos modelos. Según la teoría del aprendizaje
(rissanen 1989; haussler, kearns, y schapire, 1991; mackay, 1992) dado a un
modelo de entrenamiento con una secuencia de patrones, un nuevo modelo contiene
información si es difícil de predecir a partir del modelo de datos original. A
partir de esta nueva información se derivan algoritmos on-line y por
procesamiento para extracción de información. Los modelos de obtención de
información son a menudo interconectados con otros algoritmos que corrigen los
errores introducidos de forma accidental en la base de datos y que se denominan
algoritmos de data cleaning (data cleaning).
El data cleaning es parte de un paso
mostrado como “extracción, transformación, carga y refresco” (extract,
transform, load and refresh). Se define como el proceso de transformación de
los datos a un formato consistente con una estructura lógica, sintaxis y
semántica. Ello también implica identificadores y resolución de entradas
duplicadas. El resultado del data cleaning es la validación de los datos
presentes en el data warehouse y representa una de las fase más importante del
data warehouse ya que el éxito o fracaso dependerá de que las decisiones
tomadas sean correctas y estas a su vez dependen de la integridad de los datos
en los que se han basado.
CAPÍTULO 2:
Introducción al data
cleaning.
Ni siquiera la tecnología de base de
datos más sofisticada, el directorio de información más comprensivo, o la
interface gráfica más amigable pueden hacer que un data warehouse tenga éxito
si los datos son incorrectos. Consideremos algunos ejemplos claros:
o
Ejemplo1: una compañía industrial desechó casi unos 12 millones de dólares en
proyectos de data warehouse porque los datos del producto estaban
incoherentemente definidos y la calidad de los datos era pobre.
o
Ejemplo2: una compañía de publicidad se pasó cuatro años limpiando los datos de
clientes que vinieron de una docena de fuentes diferentes.
o
Ejemplo3: cuando una compañía de seguros creó un almacén de los datos para
analizar los códigos de los diagnósticos médicos por que estaba pagando
demandas, encontró una tasa extraordinariamente alta de “hemorroides”
diagnosticada en una región. El gerente encargado de las demandas de esa región
confesó, “nosotros ponemos ese código a todos los demandantes con dolor en la
misma zona que el producido por las hemorroides".
Las mentiras voluntarias o
involuntarias son un dilema fundamental para los esfuerzos de almacenamiento de
datos: los datos pueden ser aceptables en calidad para las bases de datos
operacionales, pero ese mismos datos pueden ser inutilizables en data warehouse
que van dirigidos a apoyar procesos comerciales, tácticos y estratégicos.
CAPÍTULO 3:
Importancia del data
cleaning.
La limpieza de datos (data cleaning,
data cleaning, o data scrubbing) es un proceso fundamental en la migración de
datos. Su preocupación principal es la calidad de datos obtenida al final de la
migración. La limpieza de datos es particularmente importante cuando los datos
vienen de fuentes de datos heterogéneas que no pueden compartir el mismo
esquema de datos o pueden representar la misma entidad real de maneras
diferentes.
El proceso de limpieza constituye
parte del estado de transformación de los datos durante la construcción de un
data warehouse. En general, la transformación de los datos define cómo el
proceso en que se convierten los datos que residen en sistemas operacionales en
los datos en el data warehouse que refleja las necesidades comerciales. En
particular, además de la limpieza de datos, la transformación de los datos
involucra la integración de valores diferentes y formatos según las tablas de
transformación, la aprobación de datos integrados según el esquema del almacén
y suma de los datos y agregación según los requisitos de la aplicación. Esta
basado en un conjunto de metadatos que mantiene información estructural
construyendo el almacén como el mapa entre la fuente y esquema objetivo y el
formato de los datos codificados.
Para apoyar bien decisiones
comerciales, los datos guardados en un data warehouse deben ser exactos,
relevantes a los requisitos comerciales, consistente a través de las fuentes
redundantes y tener una información competa. Los datos de los data warehouse
procederán de fuentes diversas para que el nivel de resultados obtenido en la
toma de decisiones sea el máximo posible según las demandas de las aplicaciones
del data warehouse. Normalmente, antes de la fase de transformación, se dice
que los datos están "sucios",
o que son “tóxicos”. La suciedad de datos puede verificarse como la desigualdad
o distancia entre el formato de datos origen y el esperado en el formato de
datos integrados, o en un sistema multifuente cuando se pasa al unir
información de dos fuentes sobre la misma entidad y esta información es
incoherente. De hoy en adelante, nosotros nos referimos a los casos de datos
sucios sin diferenciar entre los que sea por un origen o por multiples fuentes.
Un data warehouse es solo como una
réplica exacta y útil de los datos que sustenta. Un data warehouse con
información incompleta o errónea derrota el mismo propósito del data warehouse,
de proveer rapidez y exactitud de los datos sobre la base de las decisiones de
negocios críticas. Es peor para una compañía el tener información incorrecta o
tóxica en un data warehouse que no tener ningún data warehouse. El hecho que un
dato proviene de varias fuentes hace al data warehouse muy propenso a datos
impuros (dirty) e inconsistentes. Esto hace del data cleaning es un paso
central en el proceso de creación del data warehouse, del que depende en gran
medida el existo o fracaso del data warehouse a la hora de tomar decisiones.
Los “datos sucios” son un problema
creciente en las empresas. Es algo con lo que se ha convivido durante décadas,
pero ¿por qué es un problema hoy? Esto se debe a la promesa de desarrollar data
warehouses con “datos limpios, integrados, históricos en un corto periodo de
tiempo y a bajo coste”. Debido a la dualidad de esta promesa, fallan muchos data
warehouses, ya que el proceso de limpieza de un data warehouse es lento y
costoso por definición dado que requiere un análisis exhaustivo de los datos
para detectar las inconsistencias y la toxicidad.
CAPÍTULO 4:
Principales fuentes de
impurezas de datos.
Algunas de los principales
contaminantes de datos que son causa de la impureza de los mismos son:
o
Deslices
(mistakes): ejemplos son los errores tipográficos. Veamos algunos ejemplos:
Supongamos que deletreamos dos
nombre casi idénticos, y que tiene la misma dirección. Podríamos inferir que
son la misma persona. Por otro lado, supongamos dos archivos tienen exactamente
el mismo número de la seguridad social, pero los nombres y direcciones son
completamente diferentes. Podríamos asumir que los archivos representan a la
misma persona que cambió su nombre y se traslado, o los archivos representan a
las personas diferentes, y el campo con el número de la seguridad social es
incorrecto para uno de ellos. Si la información que se posee no es muy grande,
tan solo podremos asumir, pero no tener una. La información que tenemos en los
registros, es la que nos permite hacer las mejores inferencias. Por ejemplo,
michael smith y michele smith podrían tener la misma dirección, y sus nombres
son “razonablemente parecidos”'. Si el género y la información de edad está
disponible en algún campo de los datos, nosotros podríamos inferir que “quizás”
ese michael y michele o están casados o son hermanos, o son incluso la misma
persona.
Esta es la regla en que se basa ese
razonamiento:
Dado dos
archivos, r1 y r2.
Si el
último nombre de r1 iguala el último nombre de r2,
Y los
primeros nombres difieren ligeramente,
Y la
dirección de r1 iguala la dirección de r2
Entonces
R1 son equivalentes a r2.
La aplicación en la realidad de esta
regla es llevada a cabo por una función de distancia aplicada a los primeros
campos del nombre de dos archivos, y la comparación de sus resultados con un
umbral, para capturar errores tipográficos obvios que suelen ocurrir en los
datos.
Normalmente las aplicaciones de data
cleaning poseen varias herramientas para construir las funciones de distancia
incluido la edición de esa cadena de distancia, distancia fonética y distancia
de la máquina de escribir. Los usuarios pueden escribir fácilmente su propias
reglas, o el sistema detectar errores y aprender de ellos. (ej:
siempre escribo “arxon” por proximidad de x con c en el teclado y luego la
cambio a c.)
Es importante hacer notar que las
reglas pueden escribirse para una gama amplia de aplicaciones que tratan con
tipos de datos arbitrarios. La reglas también se pueden extender para limpiar
bases de datos de imágenes, donde se define igualdad con respecto a los rasgos
de la imagen, es decir dos imágenes son equivalentes si las dos contienen un
rasgo de la imagen común, como puede ser el color.
La tabla siguiente despliega
archivos con una variedad de errores que normalmente pueden encontrarse
mandando por listas de correo. ¡de hecho, los sistemas
pobres de gestión de información de las empresas llegan típicamente a mandar
varias copias del mismo correo (un gasto mayor a largo plazo) a la misma casa
(como casi todos ha experimentado), lo que supone un enorme e innecesario
gasto. Los pares adyacentes de registros de la tabla se identificarían mediante
los sitemas de reglas como equivalentes:
|
Id |
Name
(first, initial, last) |
Address |
|
334600443 |
Lisa
boardman |
144 wars st |
|
334600443 |
Lisa brown |
144 ward
st. |
|
525520001 |
Ramon
bonilla |
38 ward st.
|
|
525250001 |
Raymond
bonilla |
38 ward st. |
|
0 |
Diana d.
Ambrosion |
40 brik
church av. |
|
0 |
Diana a.
Dambrosion |
40 brick
church av. |
|
0 |
Colette
johnen |
600 113th
st. Apt. 5a5 |
|
0 |
John
colette |
600 113th
st. Ap. 585 |
|
850982319 |
Ivette a
keegan |
23 florida
av. |
|
950982319 |
Yvette a
kegan |
23 florida
st. |
o
Homónimos: palabras que se escriben igual y significan diferente.
o
Ausencia de estándares: los mismos objetos o palabras pueden ser escritos
de diferentes formas. Ej. Pc, personal computer y ordenador se refieren al
mismo objeto
o
Datos fantasmas: un ejemplo es datos artificiales o falsos
(phony) usados para marcar un registro.
o
Datos ausentes o invisibles: datos que pueden tener diferentes significados
sin fomentar descripciones. Ej. Leslie smith puede ser hombre o mujer.
o
Diferentes formatos de datos para el mismo campo: por ejemplo la información sobre el estado en un
campo de la situación puede ser la abreviación estatal, el nombre estatal o
incluso el código estatal). Otro tipo de errores suelen ser poner una longitud
inapropiada de los campos, con frecuencia se debate para anticipar los
requerimientos del campo de un sistema, y hay gran tentación en pensar que las
respuestas son obvias. Elegir el campo apropiado con la correcta longitud
requiere un cuidadoso estudio.
o
Valores ficticios: un valor ficticio será por ejemplo un número de
seguridad social 999-99-9999, o una edad 999. En estos casos, la existencia de
chequeos de campos parece ser la culpable, porque se obliga a rellenar estos
campos. Estos valores son fáciles de detectar, pero que solución se puede dar
para los campos obligatorios?. En algunos casos
encontramos valores ficticios que tienen significado en la actualidad. Si se
tiene que calcular la media de ingresos mensuales de todos los clientes, los
resultados pueden ser defectuosos.
o
Ausencia de datos: una de las más razones más comunes de que
aparezcan “datos sucios” es la ausencia de datos. Esto no siempre es atribuible
a la dejadez de los hábitos de entrada, pero si al hecho de que diferentes
negocios pueden tener diferentes necesidades para la existencia de ciertos
valores de datos para ejecutar sus operaciones. Debemos recordar que el
principal propósito para los sistemas operacionales es facilitar las
operaciones del día a día del negocio, no proveer información para mejorar o
aumentar la estrategia global de dirección.
o
Campos multipropósito: para hacer las cosas cada vez más interesantes
para los desarrolladores del data warehouse, dos departamentos podrían
compartir el mismo sistema operacional. Aquí el problema aparece en aquellos
campos de datos que son usados para múltiples propósitos, donde los mismos
valores de datos en un campo acaban significando diferentes cosas dependiendo
del departamento que los introduce y de los valores específicos en uno u otros
campos.
Por ejemplo si dos departamentos
tienen una tabla de datos denominada estados formada por (identificador,
descripción) y en ambas tablas coinciden las descripciones, pero en una se
comenzó a etiquetar desde el identificador 0 y en otra desde el identificador
1, los datos que se transformen basándose en la tabla resultado serán
incorrectos, dado que aunque los identificadores coincidan y el conjunto de estados
sea el mismo, no existe una relación directa entre ambos conjuntos de datos.
Además se da el problema añadido de que esta transformación se puede realizar
de múltiples formas y que según la forma elegida la información corrupta será
una u otra, por ejemplo:
o
Si
transformamos a partir del identificador sin darnos cuenta de que no existe una
relación directa entre las descripciones, el resultado será que los datos
obtenidos de uno de los conjuntos serán erróneos y además se habrá perdido la
información.
o
Si
transformamos los datos a partir de las descripciones, modificando los
identificadores, nos encontraremos con el problema de que en otras tablas que
se utilicen esos identificadores en lugar de las descripciones hemos dejado
datos inconsistentes.
La forma correcta de atacar este
problema: si encontramos dos tablas que se utilizan para el mismo propósito,
pero cuyos datos son diferentes deberemos hacer un plan de fusión, que incluya
a todos los objetos de sus sistemas de origen que se vean afectados por el
cambio, el problema reside en que este proceso es lento y caro.
o
Datos anticuados u obsoletos: uno de los mayores costes para las empresas
suele ser el no tener una politica de actualización de datos correcta que se termina
convirtiendo en un coste añadido , como podemos ver en el siguiente ejemplo:
Algo tan
obvio como el gestor de cambios de dirección, puede ayudar para reducir los
costes postales. Estudios recientes muestran que el ratio de descomposición
para direcciones de negocios en los u.s. Es de aproximadamente el 27%. Esto
incluye la descomposición debida a los negocios traspasados y cerrados. Esto
significa que más de una de cada cuatro direcciones de un fichero de negocios
serán incorrectas dentro de un año. Para mantener los datos recientes en un
sistema, las actualizaciones deben ser frecuentes.
La
actualización de los datos puede hacerse de varias formas. Las direcciones
pueden ser actualizadas por un servicio de actualización de dirección. Los
cambios también pueden ser hechos mediante un uso continuo de un proceso de
racionalización. Frecuentemente la descomposición de los datos impacta con
varios elementos de datos a la vez. Por ejemplo, cuando un negocio se traslada,
debe ser cambiado en dirección o propietario, o el teléfono debe cambiar. En
muchas situaciones, es deseable proveer todos estos cambios en el sistema, no
simplemente el cambio de dirección, y la mejor forma de obtener los datos
cambiados es a través del proceso de racionalización de los datos.
Sobre un
examen cerrado, el tamaño y contenido de tales registros puede ser algo desde
una cadena de datos, redefinida como una cifra, o como un mezcla de texto y
números... ¿como puede alguien llegar a inicializar tales registros?
o
Datos encriptados: si analizamos los valores de datos de un fichero
operacional, descubriremos campos “encriptados” en nuestro registro. Estos
campos son usados para múltiples propósitos, están en un estado no reconocible.
Esto ocurre en el intervalo de muchos años. Y así como se amplia el significado
de los campos, también lo hacen sus valores. Por ejemplo, en un sistema de
préstamos hipotético puede existir un campo de préstamo por hipoteca, con un
código “i” que se significa que “no existe un embargo”, otro “t” que es “no
asegurado”. Después de un tiempo se puede añadir otro que código “f” de
“excepciones al pago”... En algunos casos se necesitará combinar varias letras
para definir un campo, sin tener que utilizar todo el abecedario.
o
Datos contradictorios: semanas después de haber empezado el análisis de
los “datos sucios”, descubriremos información contradictoria entre dos o más
campos. Por ejemplo, una dirección apropiada en nuestro fichero puede mostrar
el código postal de una provincia y la dirección en otra provincia. En este
caso cogeremos la dirección como correcta. Un ejemplo más serio puede ser que
una propiedad está codificada como residencia familiar única y muestra unos
ingresos de alquileres de 10 unidades separadas.
Por lo
general los datos contradictorios, representan una información muy interesante
para las empresas, ya que les permite obtener una nueva información que en la
mayoría de los casos será debido a entradas erróneas de datos, no actualización
de los mismos, ... Pero que en otros casos serán debidos a intentos de estafas,
delitos, ... Cometidos por los clientes.
o
Uso inapropiado de las líneas de dirección: cuando se construyen direcciones en varias
líneas (datos complejos). Representa un autentico desafío para el data cleaning
encontrar variables que le permitan identificar direcciones iguales.
Ej: los
formularios de texto pueden esconder información importante como el
"c/o" especificación que puede aparecer en un nombre o un campo de
dirección;
o
Claves primarias rehusadas: uno de los más críticos “datos sucios” que se
encuentran los desarrolladores de data warehouse es con las claves primarias
rehusadas. Puesto que los sistemas operacionales raramente almacenan históricos
de más de 90 o 180 días, los valores de las claves primarias son a menudo
rehusados.
o
Identificadores no únicos: uno de los imprevistos que pueden surgir es
cuando una sucursal física tiene dos o más identificadores. Por ejemplo, una
sucursal puede ser identificada en un sistema de préstamos de una forma y en
uno de ahorros de otra. Otro ejemplo es en el caso de que un cliente es
identificado con diferentes números de clientes.
o
Problemas de integración de datos: por último pero no menos importante, nos encontramos
con los problemas de integración debido a los “datos sucios”. Estos problemas
se dan en dos sentidos:
o
Datos que
deben estar relacionados y no lo están, y
o
Datos que
por descuido están relacionados y no deben.
Lo
último pasa más frecuentemente cuando campos o registros son rehusados por
múltiples propósitos. El problema es mucho más serio cuando los datos deben de
estar relacionados y no lo están. Esto está a veces asociado al problema
anterior de “claves primarias no únicas”, pero más frecuentemente es debido a
la ausencia de claves. Las alternativas a esto pasan por cambiar los ficheros y
programas. Sin embargo si el sistema es un paquete o si ha ido creciendo
después de muchos años, quizá esté escrito en ensamblador, y esta simple
solución no será efectiva por el coste.
4.1.- Ejemplos de
errores clásicos.
La
figura 1 muestra cuatro ejemplos de registros típicos que se pueden encontrar
en un fichero de negocios. Los registros #1 y #4 son típicos en la forma de
identificación de datos de negocios, se encuentra navegando en los ficheros de
una compañía. El registro #2 puede originarse del marketing o la prospección de
ficheros. El registro #3 puede originarse del departamento de contabilidad y
puede ser usado para facturación. Dentro de estos pocos registros, hay algunos
ejemplos de los problemas de calidad de los datos, algunos de los cuales son
obvios y otros son difíciles de ver. Todos estos problemas pueden tener un
impacto negativo en la efectividad del uso de estos datos, independientemente
de si se usan para aplicaciones específicas o integración dentro de un data
warehouse.
Figura 1
Los datos aparente publicados en
estos registros incluyen:
o
Ficheros
truncados por la longitud inadecuada de un campo (hardata warehouseare es
truncado en el registro #3).
o
Uso de
formatos no estandarizados (el campo dirección a veces contiene direcciones
física y otras un apartado de correo).
o
Antigüedad,
datos sospechosos en el fichero (no actualizados en el registro #4).
o
El campo
owner es un dato de domicilio (registro #4).
o
Campos de
datos críticos desaparecen en cada registro
Lo que no resulta obvio, es que
estos registros representan a la misma compañía. Tener esta noción es crítica
para el adecuado uso de los datos. Un negocio puede parecer muy diferente
dependiendo de la forma en que se represente los datos. Por ejemplo, puede
haber varias visiones diferentes de un negocio, y sistemas que tengan varias
vistas representadas. Es imperante discutir en conjunto todas las vistas para
entender completamente la relación y oportunidades que existen. En otras
palabras, los datos en un data warehouse pueden ser racionalizados y una parte
crítica del proceso de racionalización es el data cleaning y la devolución de
datos estandarizados y limpios.
El
proceso de racionalización: uno de más importantes beneficios del proceso
de racionalización es el establecimiento de un formato de datos estándar y
adecuado. En los ejemplos de la figura 1, los datos fueron truncados debido a
que los campos eran demasiado cortos, y se necesitaban dos campos para la
dirección en lugar de. Limitaciones de los campos pueden evitar la correcta
profundidad de los datos desde que son alojados.
Otra parte importante del proceso de
racionalización es la devolución de los datos limpios. Para cumplir esto, el
emparejamiento de los registros en un fichero de datos estándar de alta calidad
es importante. La tabla 2 es un ejemplo de cómo representar la información de
las cuatro tablas anteriores en un solo fichero de referencia estándar:
Tabla 2
|
Business name: |
Abc co inc |
|
Trading name: |
John's hardata warehouseare |
|
Address: |
123 main st |
|
City: |
Allentown |
|
State: |
Pa |
|
Zip: |
18103 |
|
Mail address: |
Po box 500 |
|
City: |
Allentown |
|
State: |
Pa |
|
Telephone: |
610 882-5555 |
|
Owner: |
John smith |
Ya que los
datos en el registro de referencia de un fichero son mucho más completos y
representa varias vistas de un negocio, los registros #1, #2 y #3 pueden
igualarse. Los tres registros del fichero pueden reunirse. Un beneficio de
calidad adicional es que el dato incorrecto en los registros puede ser
actualizado (la ciudad incorrecta en el registro #2 puede ser corregida, el
código de área antiguo en el registro #1 puede ser actualizado) y los datos
ausentes en los tres pueden ser añadidos de un registro estandarizado
Descomposición de datos (data decay): otro uso
importante de un fichero de referencia de alta calidad en el proceso de
racionalización, es para el progreso y actualización del data cleaning. El
tiempo es el peor enemigo de los datos, y los datos comienzan a ser menos
exactos según pasa el tiempo. En los ejemplos previos, el registro #4 es como
si john’s hardata warehouseare se viera varios años atrás, antes de ser
trasladado al presente.
Una vez
que un fichero es racionalizado, las actualizaciones desde el fichero
estandarizado pueden dispararse. Esto es ideal para mantener los datos
recientes.
CAPÍTULO 5:
¿Limpiar o no limpiar?
La
limpieza de datos (data cleaning) es un problema engorroso en el data warehousing.
De un lado, un data warehouse presupone que suministra datos limpios, íntegros,
consistentes y coherentes de múltiples fuentes. Por otro parte, nos enfrentamos
con un programa de desarrollo de 6 a 12 meses. Es casi imposible alcanzar ambas
cosas sin hacer algunos compromisos. La dificultad consiste en determinar que
compromiso se hace.
Esto nos
lleva a la esencia y la dualidad del data warehousing:
la promesa de entregar datos “limpios”, “integros”, “historicos” en un “corto”
espacio de tiempo a un “bajo” coste. Después comprenderemos completamente el
tiempo y coste “real” para alcanzar la primera parte de la promesa, cayendo en
la cuenta que fuimos desorientados por la segunda parte de la promesa.
La
primera cuestión que debemos preguntarnos es : ¿se puede hacer la limpieza?. La respuesta que más frecuentemente nos encontraremos es
no. Hay situaciones reales donde no existen datos y no pueden ser reproducidos.
Hay otras situaciones donde los valores están enrevesados o se encuentran en
diferentes sitios con diferentes apariencias y significados opuestos para el
mismo hecho.
La
siguiente cuestión es más difícil: ¿deben ser limpiados? Aquí también, la
respuesta frecuente es no. Se debe hacer alguna limpieza de datos. Sin embargo,
hay que afrontar la realidad de los negocios hoy en día, y las expectativas
para dar valor añadido a la información en un espacio corto de tiempo y bajo
coste.
Una vez
que se decide que datos deben ser limpiados, la cuestión es: ¿Dónde deben limpiarse? ¿Se debe hacer en
los sistemas operacionales? Normalmente nuestra primera reacción es hacerlo
ahí, y en algunos casos puede y debe ser así. En un gran número de casos esto
es una labor intensa o imposible de hacer.
Hay que
tener en cuenta que la mejor manera de minimizar el coste de la limpieza de
datos, es cortar de raíz la fuente de infección de los datos que suelen ser los
sistemas operacionales, de hecho esta demostrado que limpiando los datos en el
sistema operacional aumenta la calidad de los mismos a la vez que disminuye el
coste global, además de minimizar la perdida de información. Estos hechos han
producido que la tendencia actual sea precisamente la limpieza y mejora de la
calidad de los datos en los sistemas operacionales de forma que la carga del
data cleaning en el data warehouse sea menor y más viable.
Una vez
que se decide donde van a ser limpiados, la cuestión es: ¿Que datos limpiar y porqué? Para tomar
esta decisión hay que empezar preguntándose: ¿Por qué se ha construido un data
warehouse? ¿Qué cuestiones se intentan resolver?
Las
respuestas a estas cuestiones deben venir de los usuarios y no de los expertos
en las tecnologías de la información (it). Ellos son los que deben decidir por
qué se debe construir un data warehouse.
Una de
las metas y objetivos para el data warehouse ha sido establecer y aclarar que
cuestiones del negocio no pueden ser respondidas hoy y por qué, lo que es
responsabilidad del grupo de it descubrir los “datos sucios” a los usuarios.
Los usuarios y expertos deben evaluar conjuntamente cada cuestión del negocio
que puede ser respondida por el data warehouse. Asimismo, comprender como cada
“dato sucio” debe prevenirse e intentar su limpieza.
Si los
beneficios pesan más que los costos del esfuerzo, los datos deben ser
limpiados. Ahora la decisión debe tomarse tanto si son necesarios o no cambios
en los sistemas operacionales para:
o
Limpiar los datos existentes y
o
Prevenir futuros “datos sucios” en futuras entradas.
La realidad
es que, la mayoría de la limpieza acaba en el proceso de extracción y carga.
Si los
costes superan los beneficios, ¿se deben introducir los “datos sucios” en el
data warehouse o deben omitirse?. Se estudiará de
nuevo, usuarios y expertos conjuntamente, que posible perjuicio se puede hacer,
tal como la poda de los resultados de un análisis de tendencia importante y la
consecuencia de la interpretación de información errónea que pueda permitir
decisiones de negocio equivocadas.
La
cuestión final, es: ¿cómo se debe hacer la limpieza para que queden
razonablemente limpio los datos? ¿Pueden los productos que hay en el mercado
manejar un montón de problemas de calidad comunes a los datos compartidos por
la mayoría de organizaciones? La respuesta es sí, pero estos productos no son
capaces de resolver situaciones muy complicadas y situaciones muy concretas.
La
realidad actual es que el mercado se encuentra lleno de herramientas de data
cleaning pero son solo eficientes para limpiar casos muy concretos de datos
tóxicos, por lo tanto lo que se debe valorar es cuales son los datos que
merecen la pena limpiar, lo ideal es dividir los datos a limpiar en dos
conjuntos:
o
Aquellos que pueden limpiarse de forma automática y por tanto tienen un
coste de limpieza modesto.
o
Aquellos que requieren de un análisis y el desarrollo de un plan de
limpieza previo, que por sus características tienen un coste elevado de
limpieza y que por lo tanto solo será interesante limpiarlos en caso de que el
beneficio o el perjuicio que produciría el no limpiarlos fuera elevado.
Por lo
general tendrán que ser las personas encargadas de cada departamento (usuarios)
junto a los encargados del data cleaning los que realicen la labor de
identificar que datos deben ser limpiados y cuales no, según la importancia que
para ellos tenga la información que se puede obtener, de forma que se pueda
obtener un plan que relacione “importancia información – coste limpieza” de
forma que se pueda entregar a la empresa demandante de la limpieza un claro análisis
de que partes se verán afectadas y cuales no.
El mayor
problema de limpiar parte de los datos, mientras que otros no, es los efectos
que pueden tener los datos inconsistentes sobre los que se limpian, pudiéndose
producir una contaminación en cascada de los nuevos datos que se vayan
introduciendo. Es por ello que todo proceso de limpieza debe ir acompañado de
un “plan de limpieza” que determine cuales son los datos que se limpiarán y
cuales no, indicando a los responsables de la empresa los peligros de usar los
datos sobre los que no se ha aplicada data cleaning, mediante un factor de
“calidad de datos” o incertidumbre en las decisiones del sistema, es decir, lo
ideal es que se valore la calidad de los datos y mediante un algoritmo de
calidad, se de una valoración al tomar una decisión de la calidad de los datos
en que se ha basado la misma, de forma que el solicitante de la decisión tenga
un punto más de apoyo para determinar si la decisión esta basada en datos
limpios, independientemente de que sea correcta o no.
CAPÍTULO 6:
Plan para la
elaboración de un data cleaning.
Damos
aquí algunas directivas para determinar las metas específicas para limpiar la
fuente de datos:
1.
Nunca intentar limpiar todos los datos. Todo el mundo
prefiere tener todos los datos perfectamente limpios, pero nadie desea pagar la
limpieza o esperar a obtenerla. Para limpiar se necesita mucho tiempo. El
tiempo y el coste involucrado frecuentemente exceden los beneficios.
2.
Nunca limpiar nada. En otras palabras, siempre
planear limpiar algo. Después de todo, uno de las razones para construir el
data warehouse es suministrar datos limpios y de más confianza que los
existentes en los sistemas oltp (on line transactions processing) o dss.
3.
Determinar los beneficios de tener datos limpios.
Examinar las razones para construir el data warehouse:
·
¿Tiene informes inconsistentes?
·
¿Cual es la causa de estas inconsistencias?
·
¿Es la causa los datos sucios o los errores de
programación?
·
¿Cuanto dinero se pierde debido a los datos sucios?
·
¿Qué dato está sucio?
4.
Determinar el coste de la limpieza de datos. Antes
de hacer la limpieza de todos los datos sucios, el objetivo será determinar el
coste de la limpieza de cada elemento del dato sucio. Examinar cuanto tiempo se
debe tomar para desarrollar las siguientes tareas:
·
Analizar el dato.
·
Determinar los valores de dato correctos y los
algoritmos de corrección.
·
Escribir los programas de limpieza de datos.
·
Corregir todos los ficheros y bases de datos
antiguos (si es apropiado).
5.
Comparar los costes de la limpieza con el dinero
perdido al dejar datos corruptos. Todo en los negocios tiene que tener un coste
justificado. Esto también es aplicable a la limpieza de datos. Para cada
elemento de dato, comparar el coste de limpieza con el negocio perdido por
dejar el dato sucio y decidir si se incluye como objetivo de la limpieza de
datos. Si el dinero perdido excede los costes de la limpieza, poner el dato en
la lista de limpieza. Si los costes de la misma exceden el dinero perdido no
incluirlo.
6.
Ordenar los datos sucios apuntados como objetivos en
la limpieza de datos. Una parte difícil del compromiso es el equilibrio del
tiempo que se tiene en el proyecto con los objetivos que se intentan alcanzar.
Cada vez se debe ser cauteloso en la selección de los datos sucios de los
objetivos de limpieza para no tener una lista demasiado larga. Se debe ordenar
la lista.
7.
Para cada item ordenado de dato sucio preguntar:
¿puede limpiarse?. Se debe tener algo que buscar para encontrar
si el “dato bueno” existe en algún sitio. Sitios para buscar pueden ser otros
ficheros y bases de datos, documentación antigua, carpetas de manuales y
archivadores. A veces, los valores de los datos están envueltos que hay que
hacer una transformación lógica, se debe hacer para encontrar otros “viejos”
que recuerden el valor de los datos. Entonces tendremos tiempo, varios días
para buscar, encontrar lo que no puede limpiarse de un elemento y se quiere; y
eliminar el elemento de los objetivos a limpiar.
Como
documento de los objetivos de la limpieza de datos, se debe incluir la
siguiente información:
o
El grado habitual de “suciedad” (dado en porcentaje o número de
registros)
o
El dinero perdido debido a la “suciedad”
o
El coste de la limpieza
o
El grado de “limpieza” que se quiere alcanzar (dado en porcentaje o
número de registros)
Todos
estos pasos tendrán como resultado final un plan o análisis de que datos se
tienen que limpiar así como la valoración que se asignará a cada uno de los
datos que componen el sistema (grado de limpieza), muy importante para
justificar el grado de información utilizado a la hora de tomar una decisión,
ya que no será lo mismo tomar una decisión con datos cuyo grado de limpieza es
muy alto que con datos con información errónea.
CAPÍTULO 7:
Funciones clásicas de
las herramientas de limpieza.
La
herramientas existentes de data warehouse y herramientas de migración de datos
intentan resolver todos los problemas derivados de datos sucios mediante sus
módulos de limpieza. Las funcionalidades principales de estos módulos son:
o
Conversión y normalización de funciones que transforman y estandarizan
formatos de datos heterogéneos.
o
Limpieza de proposito-especial que limpia campos específicos usando
diccionarios para buscar sinónimos.
o
Limpieza de dominio-independiente que aplica algoritmos de
emparejamiento de campos a los campos equivalentes de las fuentes diferentes
para decidir como emparejarlos.
o
Limpieza basada en reglas que esta basada en un conjunto de
"reglas de negocio" que especifican las reglas en las cuales dos
valores de diferentes fuentes se corresponden.
Los últimos dos métodos de limpieza se
aplican al caso donde los datos integrados residen en fuentes diferentes que
tienen que ser unidas para poblar el data warehouse. La estandarización de
formatos de datos y la limpieza por campos pueden usarse en un sistema por
fuente única o multi-fuente.
7.1 conversión y
normalización de funciones.
Dado un
formato de datos comunes en la vista integrada del data warehouse, la mayoría
de las herramientas del data warehouse proporcionan un módulo que convierte
distintos formatos de datos a el formato esperado. El ejemplo más simple es el
módulo sql*loader de oracle que transforma datos de registros externos o tablas
y bases de datos de oracle. En resumen, sql*loader carga datos en varios
formatos, los filtra y carga el resultado en tablas. Otros procedimiento de
conversión de formatos es atacar un modulo de software llamado envoltura (wrapper)
o traductor para cada fuente que se vaya a exportar a el data warehouse. La
envoltura proporciona una interface para traducir los datos fuente ea el
formato común necesario para que el data warehouse pueda proceder a su
almacenamiento.
La
normalización de los datos de este campo esta relacionada con la limpieza de
campos. Por normalización de los campos de los datos, queremos decir que
usaremos un formato común para todos los datos que pertenecen al mismo tipo, de
forma que sea posible realizar la comparación de los campos. Un ejemplo de
normalización de cadena es su conversión a letras mayúsculas; las fechas
también deben estar normalizadas siguiendo el formato "dd/mm/yyyy".
Pueden pensarse otros tipos de normalización que faciliten la comparación de campos
equivalentes, como agruparse palabras en las frases, corregir los guiones que
separan entre líneas una palabra o usar técnicas para guardar raíces comunes de
palabras.
En
general la experiencia demuestra que la falta de estándares en la bases de datos
operaciones para cosas tan clásicas como la fecha, produce un coste añadido al
realizar el data warehouse ya que cada formato de fecha utilizado en las
fuentes es diferente y en algunos casos puede producir datos incompletos (ej:
12/12/00 es equivalente a 12/12/2000, 12/12/2100 ... Que para sistemas
operaciones no tiene sentido, ya que sus
históricos son muy pequeños pero para data warehouse si ya que sus históricos
son muy grandes.
7.2 limpieza de
proposito-especial.
Cuando el
dominio de datos a limpiar esta especificado, (ej., Los nombres farmacéuticos),
o cuando los campos para limpiar pertenecen a un dominio específico de la
aplicación (por ejemplo, nombre y campos de dirección) las herramientas de
limpieza de proposito-especial (light-cleaning) pueden resolver anomalías
comunes. Estas herramientas de limpieza usan las tablas para buscar datos
válidos (ej., Las direcciones de envío americanas) y diccionarios de datos para
buscar sinónimos y abreviaciones (ej., "st." Y "street")
para los datos en los campos. De esta forma, se obtienen correcciones de
ortografía y la aprobación de la información especifica de un dominio.
Estas
herramientas dan muy buenos resultados cuando el dominio de la información esta
restringido. Algunos ejemplos son: postalsoft ace, ssa (search software
america), biblioteca de postalsoft y mailers +4. Algunos datos de productos
relacionados con data warehouse son carleton´s pure integrate (anteriormente
conocido como enterprise/integrator) y eti data cleanse.
7.3 limpieza de
dominio-independiente.
El
problema de tener la misma entidad descrita por dos valores diferentes puede
ocurrir y tiene que ser reparado. Para unir registros que pueden contener
diferentes alternativas, se debe realizar un trabajo que nos permita no perder
información entre los registros. Además, los resultados obtenidos pueden tener
determinadas aplicaciones en términos de esquemas de bases de datos, en los que
los atributos se refieren a categorías de la misma entidad.
Los
algoritmos descritos por monge y elkan están basados en el principio de definir
el grado de emparejamiento entre dos campos como el número de sus cadenas
atómicas emparejadas y divididas por el número medio de cadenas atómicas. Se
dice que dos cadenas están emparejadas si son iguales o una es un prefijo de la
otra. Este articulo describe tres algoritmos para emparejamiento por campos
(básico, recursivo y el de smith-waterman) con complejidades de tiempo
diferentes. El algoritmo recursivo, esta basado en la partición de cada campo
en sub-campos que se emparejan entonces entre sí, se aplica en herramientas de
búsqueda on-line en las web llamadas webfind.
Carleton´s
pure integran se basa en los productos basados en claves (cuando los registros
son identificados por claves no deterioradas) y el emparejando no basado en
claves (también llamado "emparejando difuso (fuzzy matching)”) para
comparar posibles registros sucios de fuentes diferentes.
7.4 limpieza basada en
reglas.
Es otro conjunto
de métodos que se usa para descubrir campos que emparejar cuando se mezclan
diferentes fuentes. Los métodos basados en reglas, además de usar los
resultados obtenidos mediante el análisis sintáctico, tienen en cuenta un
conjunto de reglas que establece equivalencias entre los registros de
diferentes bases de datos, teniendo en cuenta la combinación de varios campos a
emparejar. Estas reglas pueden ser especificadas por el usuario, por la persona
encargada de implementar el data warehouse o pueden ser obtenidas
automáticamente aplicando técnicas de extracción de información (data mining) a
las fuentes de datos.
7.4.1 reglas
especificadas por el usuario.
Un
ejemplo de un sistema de reglas especificadas por el usuario es el edd “data
cleanser tool” que utiliza un buen fundamento tecnológico para resolver el
problema de la "mezcla/filtrado (merge/purge)". El algoritmo de
mezcla/filtrado se utiliza siempre que uno quiera unir volúmenes grandes de
datos (que pueden estar alterados o inconsistentes) de las múltiples fuentes
tan rápidamente como sea posible y los datos resultantes se exige que sean tan
exacto como sea posible (su uso es ideal cuando la condición impuesta es la de
máxima velocidad y máxima calidad posible en el tiempo estipulado). Los datos
sucios que nos interesan en esta fase son los que existen principalmente porque
había errores tipográficos o la existencia de registros dobles sobre la misma
entidad real. El método aplicado de eliminar duplicados y unir registros es un
método denominado “sorted neighborhood” que obliga a la creación de claves para
poder analizar cada registro de la fuente de datos, entonces ordena los
registros según una de esas claves, y finalmente empareja los registros dentro
de una ventana de tamaño fijo de registros. La función de emparejamiento usa la
comparación de registros de datos basada en conjuntos de reglas (formando una
teoría de igualdad) de esa manera se establecen correspondencias entre los
registros. Dos registros son emparejados por la aplicación si difieren
ligeramente según su función de distancia. Un ejemplo de este procedimiento de
codificación realizado en c, es:
Ejemplo 1: la meta
es unir registros (persona 1 y persona 2) con atributos: ssn, nombre,
dirección, ciudad, estado, cp. Los registros comparados pertenecen a una
ventana de tamaño fijo.
Para (todo el conjunto de tuplas a considerar) {
Para (todo el conjunto
de tuplas a considerar dentro de la ventana de tamaño fijo) {
Boolean similar-ssns = same-ssn-p(ssn1,
ssn2)
Similar-nombres
Si (similar-ssns y similar-nombres)
Merge-tuples(person1, person2)
Boolean
similar-addrs = comparar-addrs (stret1, street2)
Similar-ciudad
Similar-silbido del boolean = same-zip(zip1,
zip2)
Similar-estado
del boolean = !strcmp(state1,state2)
Muy-similar-addrs
= (similar-addrs && la similar-ciudad &&(similar-estado
|| el similar-silbido));
Si
((similar-ssns || los similar-nombres) && muy-similar-addrs)
Unir-tuples
(person1, person2);
...
}
}
El método
denominado “sorted neighborhood” puede aparecer de dos formas. En una aproximación
por múltiples pasos, el algoritmo básico se ejecuta en varios tiempos, en cada
tiempo se utilizará una clave diferente para ordenar y los registros
resultantes son obtenidos por la unión de cierres transitivos sobre los
resultados del intermedio. Otro acercamiento, el acercamiento de la eliminación
doble, elimina de forma exacta o muy aproximada, emparejando registros durante
la fase ordenando. Este perfeccionamiento permite una reducción de tiempo al
hacerse la eliminación de duplicados antes de la fase de fusión.
Otros dos
ejemplos que usan un conjunto de reglas para guiar la limpieza de datos son.
Pure integrate de carleton y eti data cleanse. El anterior permite la
especificación de reglas basadas en fusión según criterios previamente definidos
(por ejemplo, escogiendo el valor que ocurre con más frecuencia).
Las
desventajas principales de este tipo de solución es que las reglas de escritura
están consideradas como tareas que consumen mucho tiempo y esas reglas nunca
cubrirán cada posible anomalía en los datos. Esta última situación lleva a
excepciones que tienen que ser manejadas a mano por el usuario.
7.4.2 reglas derivadas
de forma automática.
Otro
conjunto de herramientas que usan reglas para resolver los conflictos producidos
entre los registros de fuentes diferentes y que describen la misma entidad
real, son las que derivan esas reglas de forma automática por medio de técnicas
de data mining. De hecho, se analizan los volúmenes de cada fuente de los datos
léxicamente y se encuentran estadísticas que involucran palabras y relaciones
entre ellas. Existen múltiples herramientas (árboles de decisión o reglas
asociativas, redes neuronales) para encontrar modelos de los datos. El
resultado de tal cómputo es un conjunto de reglas que permite limpiar y
gestionar cada fuente de datos. Un ejemplo de una herramienta comercial es
wizrule y algunos ejemplos de bases de datos basadas en reglas aplicando
técnicas de data mining son:
Ejemplo 2: Regla
matemática:
A = b * c
Donde
A = total, b = la
cantidad, c = el precio de la unidad
Nivel de exactitud de
la regla: 0.99
La regla existe en
1890 registros
Siendo el
nivel de exactitud = la proporción o
el ratio entre el numero de casos en los que la fórmula es valida (acierta) y
el número total de casos.
Regla de si-entonces:
Si cliente es
"summit"
Y el artículo es tipo de la computadora x
Entonces vendedor = "dan wilson"
Probabilidad de la regla: 0.98
La regla existe en 102 registros
Probabilidad del error <0.1
Siendo la
probabilidad de la regla = la
proporción entre el número de registros en los que las condiciones y el
resultado son validos y el número de registros con condiciones con o sin el
resultado.
Y la probabilidad del error = posibilidad de
que la regla no contenga la población entera, es decir, no contempla todos los
casos.
Otra
herramienta comercial que sigue el mismo acercamiento es la de integridad de
vality. El inconveniente mayor de estos acercamientos es el nivel de
incertidumbre que las reglas derivadas implican.
7.5.- Ejemplo de
herramienta comercial: datacleanser.
La manera
clásica de comenzar la limpieza de datos es hacer un cómputo de los registros duplicados
que se deben eliminar, o ejecutar una comparación total de todos los registros.
Estas estrategias, sin embargo, asumen una clasificación total de los datos
existe y el que los datos no se adulteran. En muchos conjuntos de datos del
mundo real se asume por defecto que existe una clasificación total, no un
proceso simple de doble-emparejamiento, derivando errores en la integridad de
los datos.
La
herramienta datacleanser esta basada en algoritmos que resuelven estos
problemas de forma rápida, y con la máxima precisión en grandes conjuntos de
datos.
Por
ejemplo, no puede especificarse la igualdad de dos archivos fácilmente como un
predicado de la aritmética simple, sino por un juego de reglas. Las reglas de usuario
especificadas determinan cuando dos archivos distintos (posiblemente de dos
bancos de datos diferentes) proporcionan información sobre la misma entidad. El
datacleanser proporciona una base de conocimiento (basada en lenguajes de alto
nivel) la cual contiene reglas de conocimiento que incluyen algunas reglas que
pueden ser utilizadas directamente en los datos. Éste es un beneficio muy
importante para empresas que trabajan bajo restricciones de tiempo muy
estrictas y su tiempo es muy valioso para experimentar con alternativas que
emparejan criterios especificados en idiomas de bajo nivel.
El
datacleanser primero ordena el conjunto de datos, extrae los identificadores
definidos por el usuario de los datos, y
junta los registros potencialmente emparejados en una lista. Mediante rigurosos
estudios se ha llegado a la conclusión de que una pasada no es suficiente si se
utiliza el esquema de clasificación por clave, o si se combinan los resultados
de varias ejecuciones independientes usando diferentes claves para ordenar los
datos. Se ha demostrado que múltiples pasos acompañados de la “clausuara
transitiva” (transitive closure) dan resultados mucho más exactos.
La
conclusión obtenida es que varias pasadas poco costosas computacionalmente
producen mejores resultados que una pasada costosa.
Dada una
colección de dos o más bases de datos, se encadenan en una lista secuencial de
archivos y entonces aplicamos el método de ordenación-binario. El método del
ordenación-binario para datacleansing puede resumirse en tres fases:
o
Generación de claves: consiste en generar y asignar una clave para cada
registro de una lista para extracción de campos relevantes o partes de campos
de las bases de datos fuente.
o
Ordenación de datos: ordenar los registros en una lista de datos usando
la clave.
o
Mezclar (merge): asigna ventanas clasificadas según su tamaño y asigna
una lista secuencial de registros a esa ventana, limitando el cómputo de
comparaciones al conjunto de registros de esa ventana.
CAPÍTULO 8:
Fases en que se divide
el data cleaning.
El data
cleaning es un proceso de múltiples pasos que ocurren en poco tiempo sobre un
periodo en el cual los datos de fuentes dispares se combinan para formar un
data warehouse. Los múltiples pasos del Data Cleaning son los siguientes:
o
Limpieza pre-integración: un data warehouse tiene datos de entrada de
diferentes fuentes. La limpieza pre-integración consiste en limpiar los datos
de las fuentes de datos individuales antes de combinarlas en forma de data
warehouse. En esta etapa, el mecanismo de limpieza en cada fuente de datos
suele estar consciente del metadato de otra fuente de datos y del metadato del
resultado del data warehouse. Un ejemplo de limpieza pre-integración puede ser
hacer cierto que un campo particular que es resultado de combinar diferentes
fuentes es acotado dentro del mismo dominio
o
Limpieza post-integración: después de la limpieza pre-integración el
dato es integrado para formar un sencillo data warehouse. Los datos combinados pueden
no tener integridad a pesar del hecho que las fuentes de datos individuales son
íntegros. Esto puede ser debido a varias razones. Una de las principales es que
se han referenciado enteramente nuevos metadatos y las condiciones que
permitieron la integridad de cada una de las fuentes de datos individuales no
son ya aplicables.
o
Refinamiento post-integración: este paso puede ser considerado parte de
la limpieza post-integración. Aquí las inconsistencias encontradas en pasos
previos son eliminadas y los datos son realimentados al algoritmo de la
limpieza post-integración hasta alcanzar un grado satisfactorio de limpieza.
El
siguiente diagrama muestra las distintas etapas implicadas en el data cleaning.
A continuación
veremos con detalle en que consiste la limpieza post-integración, ya que la
limpieza pre-integración requiere de un estudio muy especifico
para cada caso, complementado mediante técnicas clásicas que se han comentado
en apartados anteriores.
8.1. Limpieza
post-integración.
Este es
el paso de limpieza que se da después que los datos son integrados a partir de
diferentes fuentes. Esto sólo se puede hacer si el metadato para el dato
integrado esta detallado. Los diferentes tipos de discrepancias que pueden
aparecer en las tablas de bases de datos integradas son las siguientes:
o
Dos o más registros en los datos integrados pueden ser idénticos, por
consiguiente violarían los requerimientos de la clave primaria. Esto es debido
al hecho que los registros en las fuentes individuales pueden ser diferentes,
pero sus combinaciones pueden resultar en registros idénticos. En este caso
todos los registros menos uno son borrados.
o
Debido a las mismas razones dadas anteriormente, debemos obtener dos o
más registros que no son idénticos pero que tienen la misma clave primaria. En
este caso, si los campos en los dos registros son mutuamente exclusivos, pueden
combinarse. Si los campos no son exclusivos mútuamente, los registros son
ambiguos.
o
El rango de restricción en las fuentes de datos individuales pueden ser
diferentes desde el rango de restricción en los datos integrados. Esta
diferencia en el rango de restricción se ha de tener en cuenta.
o
La restricción de ‘not null’ puede ser diferente en la fuente de datos
integrada en contraposición a las fuentes de datos individuales.
o
Los registros en los datos integrados pueden ser similares (similarity)
pero no idénticos. Esto puede ser debido a errores tipográficos en los
registros. Lo clásico con estos registros es identificarlos y que la corrección
de los mismos sea decisión del usuario.
o
Otro tipo de discrepancias pueden originarse porque nombres de personas
pueden ser escritas de forma diferente pero pronunciadas de la misma forma.
Diferentes fuentes de datos pueden tener diferentes formas de escritura para el
mismo nombre. Esto tiene que ser identificado en el proceso del data cleaning.
8.2. Similitudes entre
registros.
Data
cleaning escudriña (scrubs) los datos para limpiarlos de la información incorrecta.
Muy frecuentemente, esto implica emparejar registros que son similares pero no
idénticos. Si estos registros no son descubiertos, podrían confundirse como dos
registros diferentes, y serán tratados como tales. Esto podría permitir errores
costosos cuando los mismos datos son usados para analizar en una etapa
posterior una vez que los datos estén dentro del data warehouse. Normalmente
una métrica denominada de ‘distancia’ (distance) se usa para cuantificar la
similitud entre palabras.
Esta
métrica de distancia nos permite transformar la palabra ‘x’ de longitud ‘m’ en
la palabra ‘y’ de longitud ‘n’ usando tres tipos de operaciones básicas: la
sustitución de una letra ‘x’ por una letra ‘y’, el borrado de una letra de ‘x’,
o la inserción de una letra de ‘y’. Se asocia un coste a cada una de estas
operaciones:
1.
Sub(a,b) es el coste de la sustitución de la letra
‘a’ por la letra ‘b’;
2.
Del(a) es el coste del borrado de la letra ‘a’;
3.
Ins(b) es el coste de la inserción de la letra ‘b’;
Definición del problema: El
problema general consiste en encontrar una secuencia de operaciones básicas que
transformen ‘x’ en ‘y’ minimizando el coste total de las operaciones usadas. El
coste total se define como la suma de los costes de cada una de las operaciones
básicas. Estamos intentando minimizar la distancia entre ‘x’ e ‘y’, la cual es
generalmente la misma (pero no siempre) que maximiza la similaridad entre estas
dos palabras.
Una
solución puede darse como una secuencia de operaciones básicas de
sustituciones, borradas e inserciones. Dejando que a sea la letra del alfabeto.
1.
Un par alineado de typewith a, b perteneciente a a
indica la sustitución de la letra a por la letra b.
2.
Un par alineado de typewith a perteneciente a a
indica el borrado de la letra a.
3.
Un par alineado de typewith b perteneciente a a
indica la inserción de la letra b.
Este
problema puede ser fácilmente indicado en términos de un grafo. Siendo g=(v,e) un etiquetado grafo con pesos con una aplicación de
costes: e->r, la cual asocia un coste a cada uno de los bordes de e y una
aplicación etiquetada que asocia un par alineado a cada uno de los bordes de e.
El grafo g se define de la siguiente forma:
1.
V es un conjunto de vértices definidos de la forma:
V =
((i-1,j-1), (i,j)) e for i
[0,m-1] y j [0,n-1] y coste ((i-1,j-1), (i,j)) = sub(xi, yj)
((i-1,j), (i,j)) e for i [0,m-1]
y j [-1,n-1]
y coste ((i-1,j), (i,j)) = del(xi)
((i,j-1), (i,j)) e for i [-1,m-1] y j [0,n-1] y coste ((i,j-1), (i,j)) = ins(yj)
Solución al problema: solo es
necesario encontrar la ruta más corta desde el vértice (-1,-1) hasta el (m-1,n-1). El menor de los costes es la menor distancia que hay
entre dos palabras x e y. Como el grafo g es acíclico, es posible encontrar una
ruta más corta considerando en un orden topológico. Tal orden puede ser
obtenido considerando los vértices fila por fila y de izquierda a derecha por
cada fila.
La
programación dinámica resuelve este problema. Sea t una tabla de dos
dimensiones con m+1 filas y n+1 columnas. El valor de cada celda t[i,j], para -1<= i <= m-1 y -1 <= j <= n-1
depende solo de tres celdas t[i-1,j], t[i,j-1] y t[i-1,j-1]. Entonces para 0
<= i <= m-1 y 0 <= j <= n-1, t[i,j] es el
coste mínimo de la ruta desde (-1,-1) hasta (i,j). El siguiente algoritmo
calcula todos los valores de la tabla t.
Min-distance (x,m,y,n)
t[-1,-1] <- 0
for j <- 0 to n-1
do
t[-1,j] <- t[-1,j-1] + ins(yi)
for i<- 0 to m-1
do
t[i-1] <- t[i1, -1] + del(xi)
for
j <- 0 to n-1
do
t[ij] <- min{t[i1,j-1] +
Sub(xi,yj),
t[i-1,j] +
del(xi), t[i,j-1] + ins(yj)}
Return t[m-1, n-1]
Este
algoritmo devuelve la distancia mínima entre palabras. Esto a su vez nos
facilita encontrar la distancia mínima entre claves primarias de diferentes
registros. Si esta distancia está por debajo de un particular umbral, se asume
que los registros son repetidos y se apunta en un fichero de salida. Si la
distancia es mayor que el umbral, se asume que asume que los registros son
diferentes.
8.2.1. Herramientas de
post-integración: soundex codes.
El
soundex es un código fonético indexado basado en la forma de los sonidos de
palabras inglesas, y en la manera que se escriben. Palabras que suenan de forma
similar, pero que se escriben de forma diferente, como smith y smyth, tiene el
mismo código asociado. El sistema de codificación soundex fue desarrollado
originalmente para que se pudiera encontrar cada nombre aún cuando pudiera
haber sido guardado con diferentes letras. Cada código soundex consiste en una
letra y tres números, como b-536, representando nombres como bender. La letra
es siempre la primera del apellido, tanto si es una vocal como una consonante.
El algoritmo usado por el código soundex es el siguiente:
1.
Borrar primero todos los espacios y símbolos no
alfabéticos. Borrar todos los acentos, diéresis, y otras marcas diacríticas.
Borrar todas las h y w, a no ser que sean una inicial. (scmidtzel).
2.
La primera letra del nombre se convierte en la
primera letra del soundex. (scmidtzel).
3.
Para las letras restantes del nombre, anotar el
código numérico de la tabla siguiente. (ej: scmidtzel=s25033204).
A, e, i, o, u, y = 0
B, f, p, v = 1
C, g, j, k, q, s, x, z = 2
D, t = 3
L = 4
M, n = 5
R = 6
4.
Combinar todos los números dobles en uno (s2503204).
5.
Si el primer número es el mismo tiene el mismo
código que la letra inicial, borrar ese número (s503204).
6.
Borrar los ceros. (s5324).
7.
Guardar una letra y tres números (s532).
8.
Si hay menos de tres números, añadir ceros al final
hasta hacer tres. Por ejemplo, schell=s400.
Es
importante no borrar los ceros (vocales) hasta el paso 6, porque los números
dobles separados por ceros no se combinan.
Este
algoritmo de data cleaning usa soundex codes para identificar nombre que se
pronuncian de la misma forma pero que se escriben diferentes, e informan de
estos registros como candidatos a un análisis adicional.
CAPÍTULO 9:
Como implementar un
algoritmo de data cleaning.
Para
implementar un algoritmo de data cleaning se requieren dos ficheros de entrada.
Uno de los ficheros es de datos y contendrá los datos que son limpiados y otro
fichero de control que contiene metadatos así como otra información que será
necesaria durante el proceso de data cleaning. La salida consiste en dos
ficheros. Un fichero contiene los errores encontrados durante el proceso de
data cleaning y advertencias (warning) acerca de posibles discrepancias en los
datos, y el otro fichero contiene los datos limpios.
9.1.- fichero de
control.
El
fichero de control contendrá toda la información necesaria para limpiar los
datos. Es un fichero formado por varias filas, y cada una contiene información
perteneciente a una columna del fichero de datos. Cada fila tendrá un aspecto
parecido a:
Label(m)|domain(m)|pr_key(m)|range(o)|not_null(o)|default(o)
El significado de estos
parámetros es:
o
Label: simboliza el nombre de la columna.
o
Domain: simboliza el domino en que la columna se acota en forma de integer,
float, char, etc.
o
Pr_key: es ‘1’ si su columna es parte de la clave primaria y es ‘0’ en
otro caso. La ‘m’ significa que el parámetro es obligatorio.
o
Range: es un parámetro opcional y que es incluido solo si se requiere
comprobar el rango. El formato para especificar el rango es como sigue: a,b-c,d-e,f,g. Dos parametros separados por un guión
significan un rango. Parámetros separados por una coma implican una lista
enumerada.
o
Not_null: Especifica si la columna puede tener un valor nulo. Si es 0,
entonces se aceptan valores nulos en una columna particular de un fichero de
datos.
o
Default: en este caso el último parámetro ‘default’ no tendrá ningún
valor. Si ‘not_null’ es 1, la columna no puede tener datos nulos asociados. En
este caso, la columna ‘default’ puede especificar el dato con el que una
columna nula ha sido reemplazado. El parámetro ‘default’ es opcional y si
‘not_null’ es 1 y ‘default’ está ausente, entonces se anota un error en el
fichero de salida, indicando una inconsistencia en los datos de salida.
El
fichero de control también especifica un número para el valor umbral de la
primera línea. Este valor umbral es usado mientras se determinan similitudes
entre dos registros. Si la distancia entre los registros es mayor que el valor umbral,
los registros son considerados diferentes. Si es menor, se consideran
similares.
9.2.- fichero de
datos.
El
fichero de datos será un fichero ascii. Cada línea de los datos del fichero
corresponde a una fila de datos en la base de datos. Cada fila de datos tiene
columnas acotadas. Este formato de representación de los datos ha sido elegido
porque es muy fácil escribir programas simples para volcar los datos desde una
base de datos en ficheros que contengan columnas acotadas. Al mismo tiempo,
algunas bases de datos comerciales tienen funciones para cargar una base de
datos encauzando los datos desde un fichero. Dado que el carácter del cauce ha
sido delimitar caracteres, hemos asumido que los datos por sí solos no
contienen caracteres acotados. Dos cauces derechos hacia otro representan datos
nulos. Cada fila suele tener el mismo número de columnas y este número suele
ser el mismo que el número de columnas de información en el fichero de control.
9.3.- fichero de
salida.
Los datos
de salida se anotan en dos ficheros diferentes:
o
El fichero de anotaciones de salida tiene un
registro por cada cambio que se ha hecho en el fichero de datos. También se
anota cada registro (con un error) que es inconsistente con lo que se
especifica en el fichero de control y cada registro (con un aviso) que puede
posiblemente ser una discrepancia. En cualquier caso, el fichero de anotaciones
tiene el número de registro, la razón por la cual una discrepancia puede estar
presente en el fichero de datos así como también el propio registro.
o
El fichero de salida contiene los datos limpios. Los
datos limpios consisten en datos con modificaciones hechas donde es posible y
registros borrados cuando se han encontrado errores. Un error en el fichero de
anotaciones significa que el registro ha sido borrado y un aviso supone que no
ha sido borrado. Un aviso denota que una modificación ha sido hecha en el
registro (como la mezcla de dos registros) o que hay posibilidades de un error
en el registro.
El
fundamento para eliminar registros con un error definido será: que dichos
registros violaran la integridad y cualquier registro que viole la integridad
no puede estar presente en la salida.
9.4.- implementación
de un algoritmo de data cleaning en pseudocodigo.
Definimos
las clases:
o
Nodecon: es el nodo de la lista enlazada que
contiene el fichero de control. Cada objeto ‘nodecon’ contiene todos los
detalles relevantes a un campo en el fichero de datos, el cual corresponde a
una fila en el fichero de control.
o
Listcon: es una lista enlazada simple que consiste
en nodos del tipo ‘nodecon’. Este enlace mantiene el fichero de control.
o
Recordnode: es el nodo de la lista enlazada que
contiene el fichero de datos. Un objeto ‘recordnode’ contiene todos los datos
dentro de una fila del fichero de datos.
o
Recordlist: es una lista enlazada simple que
contiene los datos. Esta compuesta de nodos de la clase 'recordnode'.
El
fichero de control y el de datos se mantienen enlazados mediante estructuras de
listas.
Algoritmo
en pseudocodigo:
1.- El
fichero de control es inicialmente leído dentro del objeto ‘listcon’.
2.- El
fichero de datos lee entonces un registro cada vez.
3.- Se
comprueba la integridad del registro
4.- Se
compara con los registros en el objeto ‘recordlist’.
5.- Si
no se encuentran errores
5.1.-
Entonces se añade al objeto ‘recordlist’.
5.2.-
Sino se anota en el fichero de errores.
6.-
Hasta que no haya más registros que leer en el fichero de datos.
CAPÍTULO 10:
Ejemplos reales de
aplicaciones de data cleaning.
A continuación se muestran
de forma detallada dos ejemplos de aplicaciones de data cleaning a casos
reales:
o
En el primero se ve los problemas a los que se
enfrento una empresa por la toxicidad de sus datos y los beneficios que obtuvo de
la implantación del data warehouse aplicando un buen sistema de data cleaning.
o
El segundo es un artículo de investigación que
muestra la potencia y la importancia que ofrecen las herramientas de
inteligencia artificial, aplicadas a la obtención de conocimiento y a la
limpieza de datos.
10.1.- Limpieza de
datos tóxicos y costes asociados.
10.1.1.- Introdución.
Los
esfuerzos de limpieza de datos se pueden comparar con el tratamiento que se le
da a una planta que vierte toxinas a un río ¿no sería mejor ir a las fuentes
que producen la polución para prevenir los venenos que entran en el río en el
primer lugar? De la misma manera, será más eficaz si, en lugar de usar recursos
en un esfuerzo de limpieza de nunca acabar, se van analizando las causas de las
toxicidad de los datos y se eliminan selectivamente así sus sistemas fuentes
producirán datos limpios en lugar de datos tóxicos.
Pero
modificar los sistemas fuentes basados en metodología tradicionales consumirá
tiempo, y será demasiado costoso y, demasiado arriesgado. Para que la
renovación de un sistema fuente pueda tener éxito, lo que se necesita es
información sobre definiciones de los datos incoherentes, y otras incompatibilidades de sistema de
fuente antes de que se empiece. En otras palabras, se necesitan saber cuales de
las reglas de negocios de los sistemas fuentes esta produciendo resultados de
los datos incoherentes.
Una buena
estrategia para descubrir disfunciones en las reglas de negocios comerciales es
el data mining del data warehouse/data mart. Se puede hacer esto extrayendo y
cargando las transacciones comerciales que definen el historial de la vida del
data mart´s. Las transacciones comerciales son grabaciones de respuestas del
sistema a los eventos comerciales. Cada asunto de mercado de implique datos
potenciales (clientes, productos, los órdenes, cuentas, etc.) Tiene asociado
histórico de eventos. Por ejemplo, una orden puede empezar su vida como una
propuesta y entonces puede volverse una orden de entrada, una orden aceptada,
una orden cumplida y finalmente una orden a cargar en cuenta-y-pagada. Primero
se proponen pólizas de seguro, entonces tasamos, limites, se pagan primas, se
hacen demandas, se pagan demandas, y se renueva o se cancela.
Cuando
guardamos cada transacción comercial en el data mart´s, se aplica a él un nuevo
juego de reglas de negocio o de negocios. Estas validaciones, llamadas
históricas basadas en reglas de negocios, esta basada en la sucesión esperada
de eventos. Por ejemplo, al grabar la instalación de un equipo en un cliente,
se debe verificar que una transacción del embarque la ha precedido. Si no la
tiene, se tiene un milagro. Nunca pagamos por equipo que hemos construido. Por
supuesto, después, de un "envió no instalado" el informe del data mart´s
dirá sobre aquellos productos que dejaron la planta y al parecer se
vaporizaron. Cuando se hace chequea en historial basado en reglas de negocios,
se descubren gran número de problemas reales asociados al negocio y muchos de
ellos son raros y esclarecedores.
Por lo
tanto lo mejor es carga el data mart/data warehouse, pero no dejarlo
inmediatamente disponible a los usuarios, por lo menos no sin advertencias
sobre calidad de los datos. Es decir, la política a seguir es no vender que el
valor del data warehouse es la información que se puede extraer de forma
inmediata, sino que primero hay que descubrir las reglas de negocios que han
llevado al empobrecimiento de los datos.
10.1.2.- Aplicación
práctica.
Un
fabricante de ordenadores muy conocido necesitaba datos fiables sobre la
instalación de sus equipos base (coste, ...). Esta
información podría ayudar a las personas a hacer un trabajo mejor en diferentes
áreas del negocio y también suponía una gran oportunidad para comercializar
nuevos productos y servicios.
La
persona que más sufrió por falta de información en las instalaciones era el
vicepresidente de ingeniería -fred. Cuando se realizo un cambio en ingeniería
(ci), el vicepresidente de ingenieria (vi) quiso información sobre cuántos equipos
estaban involucrados, su localización, y la fase actual del ci, así como el
seguimiento y el esfuerzo del ci. Él no podía hacerlo. ¡era
imposible! Unos cuantos equipos no se encontraron en el sitio del cliente en el
que los sistemas del vi dijeron que estaban, algunos números de serie eran
erróneos y los diseños de niveles de
cambio o sustitución eran a menudo incorrectos.
Para
mejorar la cantidad y exactitud de la información disponible, el vi consolidó y
abanderó (¡esto es importante!) Un proyecto de data mart. El vi actuó como un
buen soldado corporativo porque supo que otros departamentos --marketing, por
ejemplo-- también se beneficiarían de la disponibilidad de una buena
información de las instalaciones de los equipo base. El data mart del vi
identificaba a cada equipo de forma individual basándose en un único número de
serie. Después se verá que al igual que suele ocurrir con los números de la
seguridad social, los números de serie resultaron no ser siempre únicos.
El primer
paso para el acercamiento fue identificar el historial de transacciones que
definian la vida de un equipo. Ver figura 1.
Después
se entrevistaron con los representantes de la organización funcional y
analizarón los sistemas fuente para documentar las reglas de negocio, incluidas
la reglas de definición y verificación de datos. Esto
podía ser un ejercicio muy interesante. En este punto, si quedaba alguna
esperanza sobre la calidad de los datos estas terminaron. Por ejemplo, se encontro
que los campos de nombre y código estaban sin relacionar y no contenían
información sobre un solo hecho relevante.
Luego,
los analistas entrevistaron a los consumidores potenciales de los datos en
secciones diferentes (Ej: comercialización), para determinar los tipos de
preguntas que podrían encontrarse al instalar la base del data mart.
Construyeron un modelo de datos simple para el data mart que incluía una "pila de la transacción" para
guardar transacciones por fecha. Establecieron un almacén de meta-datos. Este
almacén contaba con un sistema fuente, de transformación y reglas de negocio
para el data mart.
El equipo
del proyecto escribió programas que insertaron en el sistema fuente por la
noche. Estos programas extrajeron las transacciones del día y los transmitieron
al sistema del data mart para que fueran procesadas.
Al mismo
tiempo, se creo un equipo dedicado a mantener la integridad de los datos,
apodado norad. Las responsabilidades de norad incluyeron un mando operacional por
encima del sistema fuente para poder extraer todos los datos del data mart, y
lo que era más importante, poder realizar la extracción y análisis de los
resultados para analizar los problemas en la calidad de los datos.
En el
mercado de los datos, norad anunció transacciones individuales ordenadas por
fecha. Después se aplico el historial de las reglas de negocio a cada evento,
verificando que para la vida del evento se producía la secuencia esperada. Por
ejemplo, cada retorno de la transacción del cliente debe ser precedido por un
desistalación de la transacción de sitio del cliente. Cada excepción encontrada
fue anunciada, junto con la transacción y los eventos relacionados, a un banco
de datos de excepciones. ¡había tantas excepciones que
el banco de datos de excepciones era más grande que el del propio mercado!
Norad
minó el banco de datos de excepciones y analizó los resultados. De esta forma
se establecieron y midieron la calidad
de los datos.
Aquí está
algunos ejemplos de los problemas que norad identificó:
o
La duplicación de los números de serie en los
equipos estaba produciendo una bajada en la producción debido a que el
rendimiento de los empleados era pobre.
o
El número de serie que se ponía en todos los
sistemas era inexacto. ¡estos números de serie se transmitieron cada noche
entre los departamentos intentando cargar los gastos al cliente en la cuenta,
administración de contrato de mantenimiento, la dirección del recurso, etc.,
Que usa estos números de serie! No estaban pagándose muchas facturas del
cliente debido a los números de serie de equipo inexactos. El costo en esfuerzo
improductivo del personal era enorme, y la solución fue poner un programa en la
computadora que dedicaba el 40% de su rendimiento a controlar la duplicidad en
los números de serie sospechosos.
o
En algunos sitios los extractos de transacciones no
constituyeron un evento comercial. Por ejemplo, un evento de instalación de
equipo se grabó como una agregación y enviada por correo al banco de datos, y
un evento de movimiento de equipo se grababa como dos transacciones - 1º una
anulación y luego una agregación. Como resultado, cuando se producía una
agregación por una transacción no se podía identificar si era por una
instalación o la segunda mitad de un movimiento.
o
No se grabaron las fechas en las que los eventos
comerciales ocurrían. Los sistemas fuentes usados para modificar los datos de
la base de datos son transacciones de datos. Luego la planificación de los
datos de entrada tenia un impacto en el análisis del
histórico basado en fechas de evento comerciales.
Después
de varios meses, se mostraron los detalles y el listado de excepciones de la
base de datos. Con toda esta información (incluyendo ejemplos reales) sobre la
calidad de los datos pobres y su coste (para no mencionar su impacto en
construir data marts eficientes), la dirección de la empresa tomo medidas
radicales. Se establecieron nuevas reglas de negocio. Por ejemplo, ningún
equipo dejó que se completará un envío hasta que el nuevo número de serie y el
número del modelo era revisado, aun cuando el envío tenia que ser retenido e
incluso ser abierto. Estos procedimientos retardaban la función de
distribución. El beneficio al resto de la compañía, sin embargo, era enorme.
Las mismas reglas de aprobación de número de serie se reutilizarón en todos los
sistemas.
Después
de un año, los datos de los data marts estaban lo suficientemente limpios como
para poder ponerse a disposición del consumidor.
La
principal lección que se deben aprender de este ejemplo es que os siguientes
puntos no son opcionales a la hora de construir un
data mart/data warehouse:
o
El apoyo de alguien con poder en la compañía.
o
El gasto inicial de dinero no es representativo, ya que
posteriormente la limpieza de los datos supondrá mucho más dinero.
o
Realizar un foco orientado a los requerimientos del
negocio para la información.
o
Un modelo simple de datos. Guárdelo simple. No sobre
otros modelos. El mercado siempre evolucionará.
o
Un almacén de metadatos con reglas de negocio. Este
interpretará las reglas de negocio mediante un análisis de su impacto y después
rechazará.
o
Un equipo dedicado a mantener la calidad de los
datos del data warehouse / data marts.
o
Criterio de calidad de datos, medida constante,
regeneración y las acciones para la corrección.
o
Estimar el coste que producirá la calidad probre de
los datos en actividades comerciales. Por ejemplo, las facturas impagadas y los
equipos instalados reemplazados por productos competitivos.
o
Cuando el data marts es completamente operativo en
su negocio, habrá tenido éxito.
Beneficios: Enfocando de forma correcta
las reglas de negocio disminuirá enormemente el riego de fracaso del data
warehouse/ data mart. Se pueden obtener medidas del estado de los datos y el
coste de tener datos corruptos en la organización, valorando las perdidas que
ocasionan los mismos. Con el acercamiento de las reglas de negocio se podrá
comprometer a más personas en el proyecto consiguiendo el apoyo necesario para
que tenga éxito.
Este
acercamiento produce que el personal de la empresa vaya entrenándose con la
nueva herramienta lo que da lugar a un ahorro de coste en formación y eleva las
posibilidades de existo al conocer el personal ya la herramienta.
Conclusiones: Invierta en calidad de los
datos. El factor más importante para que un data warehouse / data mart tenga
exito en un mercado es la calidad de sus datos. La ejecución entera del almacén
basada en modelos de datos inteligentes y usando los últimos servidores,
middleware y herramientas de olap no pueden compensar los volúmenes de datos
inexactos, incompletos e incoherentes. Ahorrar dinero es invertir tiempo y
dinero en la calidad de los datos. Usando el historial de reglas de neogcio pasadas
de la empresa aumenta la posibilidad de éxito. Un éxito inicial generará la
demanda para el desarrollo del data warehouse/ data mart más extenso.
10.2.- Data cleaning
para modelos de computación: un caso de estudio en inmunología.
El
descubrimiento del conocimiento de las bds (knowledge discovery from databases,
kdd) en biología principalmente depende de la precisión de los modelos de
computación de los procesos biológicos. Las aplicaciones kdd en inmunología
incluyen el descubrimiento de objetivos de vacunación y nuevas relaciones
funcionales dentro del sistema inmunológico. Describimos un proceso de
desarrollo y refinamieto de un modelo de red neuronal artificial de la molécula
humana hla-dr1, muy utilizada en el descubrimiento de vacunas peptid (compuesto
hecho de dos o más aminoácidos). La alta precisión de estos modelos fue
alcanzada mediante técnicas de data cleaning y readaptaciones cíclicas usando
nuevos datos.
10.2.1.- Introducción.
El
proceso convencional de descubrimiento de nuevo conocimiento en biología
incluye tres pasos consecutivos:
o
Formulación de hipótesis,
o
Realización de experimentos en laboratorios embebidos (in vitro, in
vivo, o ambos) y
o
Interpretación de resultados. La interpretación de resultados puede usarse
para modificar las hipótesis o postular una nueva, resultando un proceso
cíclico de descubrimiento del conocimiento (fig. 1).
Fig.1. El ciclo convencional del descubrimiento del conocimiento en biología.
El
crecimiento explosivo de la biotecnología ha producido sendas acumulaciones de
datos y la rápida expansión de las bases de datos biológicas. Este crecimiento
ha producido que se deban manejar una enorme cantidad de datos y se aceleré el
desarrollo de utilidades computacionales para el análisis de estos datos. El
análisis computacional tiene cada vez más importancia para cada uno de los
pasos dentro del proceso de descubrimiento del conocimiento. Por ejemplo, las
búsquedas en bds biológicas son comúnmente usadas en sendas formaciones de
hipótesis y para la interpretación de resultados. La planificación de
experimentos esta frecuentemente ayudada por el análisis computacional o la
simulación de los procesos biológicos. El campo emergente del descubrimiento
del conocimiento de las bds (kdd) depende casi exclusivamente del análisis
computacional.
Los
modelos de computación juegan un importante y creciente papel en la búsqueda
biológica. Miller propuso que:
o
Los modelos de computación pueden ser requeridos para ayudar al entendimiento
científico de la completa implicación de sus datos
o
Estos modelos pueden estar basados en datos experimentales y ser usados
para sugerir experimentos adicionales
o
Aquellos con los mejores modelos de computación pueden ejecutar la
mejor búsqueda.
Recientemente,
los modelos de computación han sido usados para complementar la experimentación
en la investigación inmunologica. Los modelos de interacción inmune incluyen
matrices cuantitativas, redes neuronales artificiales (anns), y modelos ocultos
de markov (hmms). Tales modelos han sido usados para determinar objetivos de
respuestas inmunes, las cuales son el primer paso en el descubrimiento de
componentes peptid(es) para diseño de vacunas. Los procesos asistidos por
computador en el descubrimiento del conocimiento en biología son representados
en la fig. 2. Brusic aplicó modelos ann en kdd para extraer nuevo conocimiento
en las relaciones de proceso involucrados y presentación de antigénicos
petid(es).
Fig.2. Descubrimiento del conocimiento asistido por computador en biología.
Múltiples bucles entre pasos pueden ser ejecutados antes de la interpretación
de los resultados (o descubrimiento del conocimiento).
La
principal función del sistema inmune es reconocer agentes extraños al organismo
anfitrión y construir respuestas apropiadas. Estos agentes extraños incluyen
microorganismos (ej. Bacterias, virus, parásitos, hongos), mutaciones (ej.
Tumores), y células o tejidos extraños (ej. Transplantes). Células t del sistema
inmune reconocen moléculas extrañas colocadas en la superficie de la célula y
responden a ellas. Este proceso involucra a las moléculas mhc (major
histocompatibility complex, mhc), conocidas en los humanos como moleculas hla
(human leukocyte antigen, hla), las cuales aglutinan pequeños peptid(es) y las
colocan en la superficie de la célula. Estos pequeños peptid(es) son
etiquetados, presentando el contenido de una célula a las células del sistema
inmune, activando de esta manera dicho sistema para construir las respuestas
apropiadas. Por ejemplo, un sistema inmune sano reconocerá peptid(es) de un
origen viral colocado en la superficie de la célula, y consecuentemente
destruirá la célula infectada y su contenido viral.
Hay dos
clases de moléculas hla más relevantes para el reconocimiento inmune, con más
de 400 variantes conocidas en cada clase. Diferentes variantes de moléculas hla
aglutinan diferentes conjuntos de peptid(es), caracterizados por su específico
tema de aglutinamiento. Algunos de estos conjuntos están solapados, algunos de
ellos de forma clara. Un individuo tiene entre 3 y 6 clases i de moléculas hla
y al menos otras tantas clases ii de moléculas hla. La mayoría de los
peptid(es) que las moléculas hla aglutinan son entre 8 y 11 aminoácidos de la
clase i, y entre 11 y 20 aminoácidos de las moléculas de la clase ii. El número
de “9-mer” compuestos de peptides de origen natural aminoácido es 5,12x1011.
Individuos diferentes reconocerán diferentes conjuntos de peptid(es) de la
misma proteína, aún si tienen una o más moléculas hla comunes. La
identificación de los objetivos específicos de respuesta inmune, de esta forma
llegará a ser un problema combinatorio. Una determinación eficiente de los
objetivos de respuesta inmune requiere combinaciones de experimentos y métodos
computacionales.
La alta
precisión es el principal requerimiento para el desarrollo de modelos de
computación usados en la simulación de experimentos y particularmente en
aplicaciones kdd. En los modelos conducidos por los datos, tales como los
basados en ann o hmm, el refinamiento puede ser alcanzado de varias formas como
la optimización del algoritmo, incorporación de nuevos datos (bucles interiores
en fig.2), o por el data cleaning usado para el desarrollo de modelos. En el siguiente
apartado se describe un caso de estudio en el cual el refinamiento de un modelo
ann del peptid aglutina a una molecula humana hla drb1*0101 que fue alcanzada
por combinación de data cleaning y la adición de nuevos datos.
10.2.2.- Métodos y
materiales.
Descripción del problema: La meta inicial fue
desarrollar un modelo predictivo ann de peptid vinculado a la clase humana ii
molécula hla-drb1*0101 (dr1). Aproximadamente el 10% de los caucásicos y un 5%
de asiáticos tienen variante el hla-drb1*0101. La metodología para el
desarrollo del modelo ha sido previamente descrita. Brevemente, el algoritmo
involucra la extracción de datos, pre-procesamiento del peptid, y entrenamiento
de la ann. El paso de extracción de datos produce un conjunto de datos no redundantes
de peptid(es) aglutinantes y no aglutinantes. Cada uno de los peptid(es)
aglutinados tiene un núcleo con nueve aminoácidos, los cuales intervienen en el
aglutinamiento de las moléculas dr1. La disposición de los núcleos aglutinados
se alcanza por alineamiento de peptid(es) relativo a sus núcleos aglutinados.
Previamente, para modelar la molécula humana hla-drb1*0101 (dr4), el
alineamiento fue ejecutado usando u algoritmo evolutivo; la alineación final
fue seleccionada por su mayor poder discriminador entre aglutinados y no
aglutinados. Núcleos aglutinados y todos solapados “9-mer” no aglutinados son
usados en el paso final para entrenar al mdelo ann para predicción de
aglutinamietnos de peptid(e).
Dado
que el histórico de dr1 (ejemplos de peptid), se esperaba alcanzar gran
exactitud en las predicciones. Sorprendentemente, el modelo derivado usando
algoritmos evolutivos tuvo una precisión pobre. Hay varias explicaciones
posibles para diferenciar entre precisión del modelo dr1 y el modelo previo derivado
dr4, incluyendo:
a. Alto nivel de ruido en el
conjunto de datos
b. Pobre entrenamiento de la
ann
c. Arquitectura del modelo
inadecuada
d. Pobre calidad en el conjunto
de tests.
La meta
inicial fue desarrollar un modelo dr1 con alta precisión. La segunda meta que
surgió fue la explicación de la falta de precisión en el modelo inicial a pesar
de un gran número de puntos de datos y un ejemplo previo de sucesivas
derivaciones del modelo similar (dr4).
La estrategia para alcanzar las metas
restantes incluyeron:
a.
Evaluaciones comparativas de
varios modelos
b.
Data cleaning para
refinamiento de modelos, y
c.
Refinamiento de modelos
usando nuevos datos de alta calidad.
Modelos usados para estimar comparativamente
incluyen:
a.
Varios modelos ann derivados
usando varias estrategias de alineación peptid(es)
b.
Un modelo derivado usando
los motivos de agrupamiento dr1
c.
Modelo de matrices
cuantitativas derivado experimental o teoricamente.
La descripción de los datos y modelos es
expuesta más abajo. El conjunto del proceso es mostrado en la fig. 3.
Fig. 3. Un proceso multi-etapa de derivación de modelos ann de alta precisión
Datos: las secuencias de peptid(e) fueron tomadas de la bd mhcpep y de un depósito de
agrupamientos de peptid(es) (v. Brusic, no publicado). Los datos brutos
incluían 228 baja-, 696 moderada- y 409 alta-compatibilidad de agrupamiento así
como 560 no agrupamientos de peptid(es) al dr1. Los datos en bruto estaban
caracterizados por un alto nivel de redundancia. El paso inicial de filtrado
implicaba:
a. Descomposición de secuencias
de peptid(es) no agrupadas en 9-mers
b. Eliminación de puntos de
datos duplicados.
El
conjunto de datos resultante “datos filtrados” (filtered data, ver fig.3)
abarcando 77 baja-, 342 moderada-, y 215 alta-compatibilidad de agrupamiento
así como 2895 no agrupamientos 9-mer peptid(es). El conjunto de tests “ts” (t.
Sturniolo, e. Bono, y j. Hammer, no publicado) comprendía 343 solapamientos
15-mer peptid(es) de tres proteínas (4 alta-, 31 moderada-, 43
baja-compatibilidad así como 265 no agrupamientos).
Modelos predictivos: los modelos ann fueron derivados
como anteriormente se describió. Concretamente, planet software fue usado para
entrenar una ann “feed forward” con tres capas completamente conectadas. El
conjunto de entrenamiento consistió en 9-mer de núcleos agrupados y no
agrupados determinados por varias estrategias de alineamiento:
a. Por inspección de cada
peptid
b. Causante dr1,
c. Matrices cuantitativas
d. Algoritmos evolutivos.
La
arquitectura comprendió 180 unidades de entrada, correspondientes a la
representación binaria de 9-mer peptid(es), dos unidades de capas ocultas, y
una unidad simple de salida. Las medidas difusas (fuzzy) de alta-, moderada-,
baja-, y no-compatibilidad fueron definidas como se describe arriba. El
algoritmo de aprendizaje fue de back-propagation del error. El entrenamiento
fue desarrollado en 300 ciclos. Los respectivos valores en impulso y el ratio
de aprendizaje fueron 0.5 y 0.2. Cada predicción es la media de cuatro
ejecuciones independientes.
El
motivo de agrupamiento de dr1 es dado en la tabla 1. Un sistema de incisión
simple en el cual el residuo de amarre primario da un peso 6 (y,v,l, f) o 4 (i,a,m,w) y el secundario da un peso 2. La
puntuación fue calculada por la suma de los coeficientes de un peptid dado.
Southwood
et al. Determinó experimentalmente los coeficientes por cada 20 ocurrencias
naturales de aminoácidos en cada una de las nueve posiciones. La puntuación
para cada peptide es calculada como el producto escalar de los coeficientes por
sus 9-mer sub-secuencias. Mallios definió una matriz cuantitativa usando un
algoritmo de análisis discriminante paso a paso y datos para agrupamientos de
una bd mhcpep. Los modelos basados en motivos de agrupamiento o matrices
cuantitativas fueron testeados por su poder predictivo; también fueron usados
para alinear peptid(es) en el entrenamiento de modelos ann, y fueron comparadas
sus ejecuciones.
|
Posición relativa |
||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
|
Y |
|
|
L |
|
A |
|
|
L |
|
V |
|
|
A |
|
G |
|
|
A |
|
L |
|
|
I |
|
S |
|
|
I |
|
F |
|
|
V |
|
T |
|
|
V |
|
I |
|
|
M |
|
P |
|
|
N |
|
A |
|
|
N |
|
|
|
|
F |
|
M |
|
|
Q |
|
|
|
|
Y |
|
W |
|
|
|
|
|
|
|
|
Tabla 1. Agrupamiento causal de hla-drb1*0101 (de 11). El causante indica aminoácidos
que son de anclaje aceptable. Residuos de anclaje primarios son dados en
negrita y los secundarios en normal.
Validación: La validación de varios
modelos predictivos fue ejecutada usando un conjunto de test de agrupamiento determinado
experimentalmente. La predicción de agrupamientos de peptide fue evaluada para
tres umbrales de definición de agrupamiento: alta-compatibilidad sólo, moderada
y alto agrupamiento, o baja-compatibilidad de agrupamiento y por encima. La
ejecución predictiva fue evaluada usando el análisis roc (relative operating
cararacteristic). En el análisis roc, una curva de proporción positiva de
verdad, o sensibilidad (se) es enfrentada contra la proporción positiva falsa
(1-sp; sp se mantiene para especificaciones) para varios umbrales de
clasificación. La fórmula para sensibilidad y especificidad es: se=tp/(tp+fn) y sp=tn/(tn+fp), donde tp, tn, fp y fn se mantiene
para los respectivos números de verdad positivos, verdad negativos, falsos
positivos y falsos negativos. El área bajo la curva (aroc) suministra un valor
de semifallo para la evaluación de la ejecución predictiva. El valor de aroc=1
se refiere a una predicción perfecta, y aroc=0.5 una predicción por elección
aleatoria. Empiricamente, valros de aroc>0.9 indica un poder de predicción
excelente, mientras que aroc<0.7 indica una laguna en el poder predictivo.
Consideramos un valor aroc=0.8 como el umbral para una buena exactitud en las
predicciones.
Un
formulario de 10 pliegues (10-fold) de validación cruzada fue ejecutada para evaluar la precisión de los modelos finales.
El conjunto de test ts fue dividido en 10 particiones mutuamente excluyentes.
Cada partición contenía datos de entrenamiento y test. Los datos de
entrenamiento fueron combinados con los datos limpiados para entrenar un modelo
de ann refinado, el cual fue testeado posteriormente usando un conjunto de test
parecido. Los resultados fueron combinados y el modelo evaluado para sus
precisiones en el análisis roc.
Data cleaning: La matriz cuantitativa de
southwood et al. Alcanzó la mejor precisión de todos los modelos inicialmente
testeados (ver resultados) y fue elegido para el data cleaning. Cada uno de los
peptid(es) en los datos filtrados fue puntuado usando la matriz experimental; la puntuaciones fueron escaladas entre –5 y 5. Dos umbrales
fueron definidos: tn para no agrupados y tb para agrupados. Data cleaning
constituyó la eliminación de los ejemplos positivos cuya puntuación fue menos
que tb y los ejemplos negativos cuya puntuación fue mayor que tn. Varias
combinaciones de valores para tn y tb fueron evaluadas. El data cleaning fue
ejecutado sobre el conjunto de datos filtrados (ver fig. 3, y sección “datos”)
y los tres mejores modelos fueron elegidos para un paso de refinamiento.
Modelo de refinamiento: Los modelos finales ann
fueron obtenidos combinando conjuntos de datos limpios y peptides del conjunto
de test experimental ts.
Medidas
experimentales del agrupamiento peptide: el ensayo experimental fue ejecutado
como previamente se describió. Pronto, los 15-mer peptides fueron sintetizados
y purificados. La compatibilidad de agrupación fue estimada directamente
midiendo la competición para agrupamiento de dr1 del test peptide contra los
etiquetados estándar. Esta prueba es sensible para bajas compatibilidades
nanomolares y altamente reproducible.
10.2.3.- Resultados y
conclusiones.
Cinco
modelos ann para predicción del agrupamiento del dr1 peptid(es) fueron
inicialmente desarrollados usando varias estrategias de alineación para definir
conjuntos de entrenamiento. La precisión predictiva de estos modelos fue
evaluada. La mayoría de las variaciones fueron en la capacidad para predecir
alta compatibilidad de agrupamiento; las anns derivadas de los datos alineados
manualmente fueron las peores predicciones de alto agrupamiento de dr1. La
predicción de baja- (lmh), o moderada-compatibilidad (mh) dr1 agrupamiento fue
similar para todos los modelos. Como control, evaluamos el modelo de agrupación
de peptide para dr4 por sus capacidades para predecir dr1 agrupamiento; la
precisión del modelo dr4 fue comparable a la de otros modelos, aunque fue algo
baja para predecir los altos agrupamientos. El modelo basado en alineación
manual obtuvo la precisión global más baja. En conjunto, la ejecución predictiva
de estos modelos muestra una pobre precisión. Concluimos con que estos modelos
no son utiles para predecir el agrupamiento de los peptide dr1.
Los
tres modelos no ann fueron testeados a continuación para evaluar sus
predicciones. Incluyeron un esquema de puntuación basado en la causa (mots)
(descrito en la sección modelos predictivos), la matriz experimentalmente
derivada (mats), y la matriz teóricamente derivada (matm). La evaluación de los
modelos mots y matm fue comparable a los modelos iniciales ann. Sin embargo, la
evaluación del modelo mats para predicciones del dr1 fue comparable a la
precisión de los modelos previamente desarrollados para dr4 en predicción de
agrupamientos de pepetid(es) dr4 (dr4-dr4). Estos resultados indican que el
conjunto de test ts es por sí solo de alta precisión experimental, consistente
con nociones empíricas anteriores en las que la sensibilidad de los
agrupamientos experimentalmente empleados donde la prueba es alta. Asímismo
descartamos la posibilidad que la baja precisión predictiva de los modelos
iniciales ann fuera consecuencia de un conjunto de test con ruido.
Veinticinco
combinaciones de diferentes valores para tn y tb fueron testeados como se
describe en la sección data cleaning. El data cleaning produjo conjuntos de
datos que eran subsecuentemente usados para entrenar modelos ann “limpios” (ver
fig. 3). Los modelos de ann cleansed fueron evaluados para sus precisiones de
predicción en el dr1 (tabla 2). La comparación de la precisión de los modelos
limpios 01, 02 y 07 con independencia del modelo mats indica una precisión
mejorada (mejora media del 2,5 % relativa a la predicción por la línea inicial
de elección aleatoria), particularmente para las bajas-, y
moderadas-compatibilidades de agrupamiento umbrales (la media de mejora del
3,3%). Estos modelos fueron comparados con el modelo de ann derivado solo de
los conjuntos de test ts (fig 5c); los modelos limpiados fueron en media 14%
más precisos que los modelos derivados de los conjuntos ts solos. La limpieza resultó
un descenso significativo en el número de ejemplos positivos. Los modelos
limpiados 01 y 02 abarcaban sólo 13% de bajo-, 25% de moderado-, y 36% de alto
agrupamiento del conjunto de datos filtrados. Los respectivos valores para el
conjunto 07 fueron 27%, 38% y 52%. El número de no ligados 9-mer peptid(es)
eliminados en el paso de limpieza fue más pequeño: más del 88% de no
agrupamientos permanecieron en los conjuntos de datos limpios 01, 02 y 07.
|
ANN |
Thr |
Nº de Petides |
Aroc |
||||||
|
Tn |
Tb |
NB |
LB |
MB |
HB |
LMH |
MH |
H |
|
|
0 |
- |
- |
2895 |
77 |
342 |
215 |
0.78 |
0.76 |
0.77 |
|
1 |
2 |
2 |
2755 |
10 |
85 |
77 |
0.77 |
0.83 |
0.91 |
|
2 |
1 |
2 |
2554 |
10 |
85 |
77 |
0.78 |
0.82 |
0.94 |
|
3 |
0 |
2 |
2257 |
10 |
85 |
77 |
0.74 |
0.82 |
0.89 |
|
4 |
-1 |
2 |
1854 |
10 |
85 |
77 |
0.78 |
0.81 |
0.90 |
|
5 |
-2 |
2 |
1391 |
10 |
85 |
77 |
0.78 |
0.83 |
0.88 |
|
6 |
2 |
1 |
2744 |
21 |
130 |
113 |
0.73 |
0.81 |
0.93 |
|
7 |
1 |
1 |
2554 |
21 |
130 |
113 |
0.77 |
0.85 |
0.91 |
|
8 |
0 |
1 |
2257 |
21 |
130 |
113 |
0.72 |
0.81 |
0.88 |
|
9 |
-1 |
1 |
1854 |
21 |
130 |
113 |
0.74 |
0.79 |
0.86 |
|
10 |
-2 |
1 |
1391 |
21 |
130 |
113 |
0.75 |
0.82 |
0.88 |
Tabla 2. Representación de los modelos
ann. El valor aroc para los restantes modelos (11-25) es más pequeño y no están
incluidos en la tabla. Modelos 01, 02 y 07 tiene la mejor precisión y fueron
seleccionados por el paso de refinamiento. Nb: no agrupados; lb: bajo
agrupamiento; mb: moderado agrupamiento; hb: alto agrupamiento.
Estos
resultados indican un alto contenido en ruido en los datos de peptide
agrupados. Consecuentemente, podemos concluir que la principal razón para la pobre
exactitud en la predicción de los modelos ann iniciales fue un conjunto de
entrenamiento ruidoso, principalmente entre los subconjuntos de agrupamiento.
Demostramos que los datos limpios pueden ser aplicados para el refinamiento de
los modelos ann en inmunología, y la mejora de la precisión de los modelos
actuales puede ser alcanzada usando datos antiguos de baja precisión
experimental.
El paso
final incluyó el refinamiento de los modelos ann para precisiones mejoradas en
la predicción mediante la integración de nuevos, datos de alta calidad. Tres
modelos ann finales deducidos de la combinación de datos del conjunto ts y
conjuntos de datos limpios 01, 02, y 08 fueron evaluados en la exactitud de la
predicción. El modelo refinado mostró una media superior al 3,2% de incremento
en la exactitud de predicción.
La
evaluación de precisión en el refinamiento final es estadísticamente
significativa (t-test, p<0,008). La precisión de los modelos finales es
comparable a los modelos previamente descritos de la molécula humana dr4. Los
modelos refinados excedieron la precisión de un modelo de matriz
experimentalmente derivado, en media un 5,6%. Globalmente, nuestros resultados
demostraron que los modelos de computación de alta precisión puede ser
alcanzados combinando datos antiguos con alto contenido en ruido, tecnicas de
data cleaning, y pequeños conjuntos de medidos precisamente y datos
experimentalmente reproducibles.
10.2.4.- Discusión.
Brusic
et al. Informaron previamente del refinamiento de los modelos ann mediante la
readaptación con nuevos datos. El refinamiento en este estudio incluyó la
síntesis y testeo de peptid(es) generados aleatoriamente. En este estudio
mostramos que los refinamientos usando conjuntos de datos agrupados de
peptid(es) solapados con intervalos de proteinas de ocurrencia natural. Para
nuestro conocimiento, este el el primer informe de un refinamiento cíclico de
modelos de computación de agrupamiento de peptide en la clase ii hla. Modelos
de computación de alta precisión, junto con la capacidad de impulsar el
refinamiento, suministra métodos para más eficiencia en el descubrimiento del
conocimiento en inmunología.
Los
modelos de computación tales como las matrices cuantitativas o ann han sido ya
usados para identificar objetivos de respuesta inmune usando un pequeño número
de experimentos apuntados. Estos modelos de computación fueron desarrollados
usando medidas experimentales de alta calidad. Hemos demostrado que los modelos
de computación pueden ser desarrollados a partir de conjuntos de datos
históricos (caracterizados por un alto contenido en ruido) usando técnicas de
data cleaning. Data cleaning de los conjuntos de datos puede ser desarrrollado
usando resultados experimentales, como en este estudio, y conjuntos
relativamente pequeños de tests de datos de alta calidad. Alternativamente,
data cleaning puede ser conseguido empleando métodos de búsqueda basado en
computadores y conjuntos de test. Debido a la fórmula sencilla de data cleaning
usada para este trabajo, es muy probable que algunos de los mejores puntos de
datos hubieran sido eliminados. Los algoritmos de búsqueda sofisticados pueden
ejecutarse para mejorar los data cleaning y resultar modelos más precisos.
El alto
contenido de ruido en los datos dr1 es probablemente consecuencia del legado
histórico. Hla-dr1 fue la primera molécula humana de la clase ii que fue
descubierta. Los primeros métodos experimentales fueron de baja precisión y los
primeros datos no solían estar clasificados. Además, una variedad de métodos
están disponibles para medidas directas o indirectas del agrupamiento del
peptide. Estos métodos varían en precisión y exactitud. Prevemos que las
técnicas de data cleaning crecerán en importancia en la búsqueda inmunológica y
permitirán una mejor utilización de los datos disponibles de la literatura.
Se
pueden alcanzar mejoras posteriores mediante la optimización del data cleaning.
Usamos solo un número limitado de umbrales de data cleaning y es posible que
los valores intermedios para los umbrales puedan suministrar modelos más
precisos. Las aplicaciones kdd de data cleaning pueden ampliar el alcance
incluyendo:
o
Limpieza de bds, tales como mhcpep
o
Uso de modelos de alta precisión para filtrado de secuencias de bds
para objetivos de vacunación potenciales,
o
Secuencia de minado de bds para clarificar nuevo conocimiento acerca
del funcionamiento del sistema inmunológico.
La
principal dificultad en el estudio del sistema inmunológico es su naturaleza
combinatoria y los requerimientos para una completa experimentación. Con la
acumulación de datos biologicos, no es posible conducir la experimentación
sistematica. Experimentos simulados utilizando modelos de computación precisos
serán instrumentos en la ejecución de búsqueda en campos que requieren una
experimentación extensiva o donde la experimentación no es posible.
Aplicaciones kdd anteriores con éxito en inmunologia demuestran que los modelos
de computación pueden ser usados para descubrir nuevo conocimiento. El modelo
dr1 junto con los modelos dr4, por ejemplo, puede ser usado para estudiar la
distribución de peptid(es) inmunizados dentro de diferentes dominios de
proteínas.
El
desarrollo de aplicaciones de kdd en biología es obstaculizada por la enorme
complejidad del campo y por la naturaleza difusa de las medidas biológicas y la
enorme cantidad de datos. Los modelos ann son particularmente adecuados para el
uso en biología. Las principales ventajas son:
o
Las ann pueden manejar datos ruidosos e imperfectos,
o
Son conductores de datos y puede fácilmente ser perfeccionados mediante
la adición de nuevos datos y readaptaciones,
o
Mayor perfeccionamiento puede ser alcanzado con datos entrenados
limpios, y
o
Pueden tratar problemas no lineales.
El
descubrimiento del conocimiento en biología se incrementará involucrando
múltiples pasos:
o
Kdd para selección de hipótesis,
o
Experimentos simulados para selección de experimentos de laboratorio
críticos,
o
Un pequeño número de objetivos de experimentación, y
o
Interpretación de resultados, posiblemente incluyen un paso adicional
kdd.
Los
modelos de computación son cruciales para los dos primeros pasos, la eficacia
de búsqueda dependerá enormemente en la precisión de los modelos de computación
empleados.
CAPÍTULO 11:
Data cleaning en
aplicaciones web.
Las
técnicas para limpiar un servidor lógico y eliminar aquellos registros que
contengan información irrelevante esta tomando gran importancia en algunos
tipos de web, no sólo en el datamining. Las relaciones descubiertas o informes
estadísticos son sólo útiles si los datos representados en el servidor lógico
dan una información exacta de las forma de interactuar del usuario. La
eliminación de información no pertinente puede ser lograda verificando el
sufijo del nombre de url. Por ejemplo, todas las entradas lógicas con sufijos
del filename como, gif, jpeg, gif, jpeg, jpg, jpg, y bmp pueden ser
eliminadas.
Un
problema relacionado pero mucho más duro de resolver es determinar si hay
accesos importantes que no se graban en la lógica de acceso. Los mecanismos
como "caches locales" y los "servidores proxy" pueden
distorsionar el cuadro de información de ese usuario a través del sitio web.
Una página que se accede una vez en un servidor lógico puede estar siendo
referenciada por múltiples usuarios. Los métodos actuales para intentar superar
este problema incluyen el uso de cookies, anulación de caches, y el registro
del usuario explícito. Estos métodos presentan inconvenientes serios. Las
cookies pueden ser anuladas por el usuario, la anulación de caches supone una
desventaja de velocidad en la carga que es la razón por la que fueron creadas y
puede desactivarse, y el registro del usuario es voluntario y los usuarios
proporcionan a menudo información falsa. Los métodos para acabar con el
problema de las caches incluyen el uso de topologías o referencias largas,
junto con información temporal para inferir referencias perdidas.
Otro
problema asociado con servidores proxy es el de identificación del usuario y el
número de estos. El uso del nombre de la máquina para identificar a los
usuarios puede producir que varios usuarios se agrupan erróneamente como un
solo usuario. Algunos algoritmos chequean para ver si cada demanda entrante es
alcanzada por las páginas que han sido visitadas. Si una página que se pide no
se une directamente a las páginas anteriores, se asumen que varios usuarios
pueden estar accediendo a la misma máquina. La longitud de la sesión de un
usuario permite determinar automáticamente basándose en modelos de la navegación
el número de usuarios que están accediendo. Otros algoritmos usan mecanismos
heurísticos para identificar a los usuarios a partir de una combinación de
dirección de ip, nombre de la máquina, agente del browser, y la información
temporal.
En general
se están aplicando mucho e innovadores mecanismos para intentar extrapolar la
máxima información sobre los gustos, hábitos, ... De los usuarios de las
aplicaciones web sin que ello suponga una molestia adicional para los mismos,
por lo que la exactitud de esta información y las técnicas de data cleaning que
permitan alcanzarla, están tomando una importancia fuera de lo normal, y esta
suponiendo una inversión millonaria por parte de las empresas que desean a toda
costa obtener el mayor número de información posible y útil sobre sus usuarios.
CAPÍTULO 12:
Conclusiones.
Del
análisis de las técnicas de limpieza presentado, se pueden sacar varias
conclusiones
o
La actual investigación es muy pobre excepto en lo que concierne a limpieza
con múltiples fuentes, mientras que los algoritmos de limpieza que involucran a
una sola fuente son bastante sistemáticos y no necesitan técnicas
innovadoras.
o
Respecto al contexto de la aplicación de las técnicas de limpieza en la
construcción y mantenimiento de un data warehouse. Normalmente la limpieza se
hace durante la transformación de los datos, pero se debe hacer una distinción
entre las transformación de los datos que tiene lugar durante la carga inicial
del sistema de los datos de bases de datos operacionales y la transformación de
datos complementaria que tiene lugar durante el refresco de las bases de datos.
En general, el proceso de refresco de datos pone al día el data warehouse según
los cambios en la fuentes de los datos. En términos de limpieza de datos, la
diferencia obvia es la cantidad de datos a limpiar qué es normalmente más
pequeña en la situación del refresco. Afortunadamente, todas las técnicas de
limpieza de datos descritas pueden utilizarse tanto en el proceso de carga como
en el proceso de refresco. Sin embargo, la estrategia a seguir al utilizar
estas técnicas es diferente en un proceso de refresco, en particular cuando se
utilizan para limpieza de datos de procedentes de múltiples fuentes. En este
caso, el data warehouse existe y los cambios que se produzcan según vayan
llegando los datos tienen que se comparados y limpiados de algún modo para
poder integrarlos con el conjunto de datos del data warehouse según algún
criterio pre-establecido. Es más, los cambios de diferentes fuentes de datos no
pueden ser detectados todos al mismo tiempo: por consiguiente, no realizar un
emparejamiento de todas las fuentes de los datos operacionales puede hacer que
no se valoren los datos convenientemente para la correcta integración de las
vistas. Se pueden valorar varias opciones para la limpieza de datos según el
tiempo de la propagación y la calidad de los datos requerida. De hecho, el
estudio de la posible semántica de limpieza y estrategias para usar durante el
refresco de un data warehouse alimentado por varias fuentes es una área abierta
de investigación.
o
Otra cuestión que se puede destacar de este estudio es que la mayor
parte de las herramientas de data cleaning que actualmente existen han sido
desarrolladas por empresas privadas que mantienen un secretismo total sobre
ellas, así como sobre las técnicas que utilizan para realizar el proceso de
limpieza.
o
La mayoría de los algoritmos actuales de data cleaning que tienen un
alto grado de eficiencia, están basados en técnicas avanzadas de inteligencia
artificial, o en errores que se cometen de forma más o menos habitual.
o
Al final el data cleaning se puede dividir en dos grupos de
herramientas:
a) Lo que son un grupo de
algoritmos clásicos que pueden ser aplicados de forma sistemática y sin apenas
coste sobre una aplicación produciendo muy buenos resultados en la limpieza, ya
que corrige errores habituales.
b) Y aquellos algoritmos que
podemos considerar de propósito específico, que serán desarrollados después de
un minucioso estudio, que serán costosos y que solo se realizarán si el
conocimiento que se espera obtener de su aplicación compensa al coste.
Las
expectativas del data cleaning en el futuro pasan sobre todo por el trabajo de
investigación publico, ya que el poco interés de las empresas por colaborar
para obtener unos mecanismos estándar de limpieza y una herramienta global más
potente esta produciendo que ninguna herramienta de data cleaning de las que
actualmente existen en el mercado de unos resultados altamente satisfactorios.
Hay un
gran número de temas abiertos candidatos ha ser investigados. Como se describió
anteriormente, el data cleaning para data warehouse no es realmente un proceso
de una sola vez, ni algo que actualmente pueda ser aplicado de forma
sistemática. Es un proceso formado por etapas, que puede ser realizado en
diferentes fuentes, con cientos de algoritmos y herramientas que permiten
descubrir un conocimiento donde para el usuario solo hay datos sin ningún
valor. Nuestra principal intención en este proyecto fue explorar los diversos
asuntos que toman parte en el data cleaning y la
investigación de algunos algoritmos básicos que puedan hacer el trabajo. Esto
es un trabajo muy preliminar y hay un montón de áreas para mejorar.
De
hecho las principales conclusiones que se puede obtener de este trabajo son:
o
Que el data cleaning es un mundo abierto a la investigación, del que
hoy se conoce menos del 1% de sus verdaderas posibilidades, y que dado el grado
de importancia que esta empezando a tener para organizaciones, empresas, ... Tendrá un futuro muy brillante.
o
Que dada la complejidad que representa el problema que pretende
solucionar el data cleaning, requerirá de gente cada vez más especializadas y
herramientas cada vez más complejas.
CAPÍTULO 13:
Referencias.
13.1.- Direcciones web
sobre data warehouse y data cleaning.
·
Http://www.l-ags.org/sndxhow.html
(for information on soundex)
·
Http://www.tjp.washington.edu/bdm/genealogy/overviewofsoundex.html
(for information on soundex)
·
Http://www.dir.univ-rouen.fr/~charras/seqcomp/node1.html
(for approximate word matching)
·
Http://www.dbaint.com/pdf/v10n61.pdf
·
Http://www.trilliumsoft.com/trilliumsoft.nsf/pages/white.htm
- 'achieving enterprise wide data quality'
·
Http://www.carleton.com/resource/white%20papers/index.htm
- 'meeting the data integration challenge'
·
Http://w3.mor.itesm.mx/~portillo/thesis/kdd.html
·
Http://www.mtsa.com/espanyol/senda.htm
·
Http://www.empresas400.com/oct97/tecnooct.html
·
Http://w3.mor.itesm.mx/~emorales/cursos/kdd/node6.html
·
Http://www.informatik.th-darmstadt.de/dvs1/staff/wu/data
warehouse.html
·
Http://www.data
warehouseinfocenter.org/search.html
·
Http://www.sonda.cl/data
warehouse/datamarts.stm
·
Http://www.datawarehousingonline.com/
·
Http://www.vality.com/
·
Http://www.trilliumsoft.com/index2.html
·
Http://www.firstlogic.com/default.htm
·
Http://www.npsa.com/edd/
·
Http://www.db2mag.com/98fsaar.html
·
Http://cac.psu.edu/beatnic/sas/seminars.html
·
Http://www.dmreview.com/
·
Http://searchpdf.adobe.com/
·
Http://www.apertus.com/approds/esg/eiwp.htm
(apertus technologie inc. Enterprise/integrator white paper )
·
Http://www.ibi.com/eda/copymgr.htm
(information builders. Eda/sql enterprise copy manager )
·
Http://www.data-warehouse.com/articles/burch.htm
( george burch. Five common excuses for not
reengineering legacy data )
·
Http://www.datamation.com/plugin/issues/oct15/10bsw100.html
(joe celko and jackie mcdonald. Don't warehouse dirty data.
Datamation, 15. October 1995. )
·
Http://www.dbmsmag.com/category.html
(sudarshan s. Chawathe, anand rajaraman, hector garcia-molina, and jennifer widom. Change detection in hierarchically
structured information stanford university, acm sigmod
conference,
·
Http://techweb.cmp.com/iw/600/00oldat.htm
(larry p. English. Help for data quality. Information
week, october 1996. )
·
Http://qb.island.net/~gordon/whystds.htm
( k.
·
Http://www.dbmsmag.com/9606d05.html
(ralph kimball. Mastering data extraction. Dbms
online, june 1996. )
·
Http://www-db.stanford.edu/pub/papers/window-short.ps (wilburt juan
labio and hector garcia-molina. Efficient
snapshot differential algorithms for data warehousing stanford
university, submitted for publication, 1996. )
·
Http://www.kismeta.com/extract.html
( r. Orli and f.
·
Http://www.data
cleaning.enews.com/data/magazines/alpha/df/data_pd/archive/040195.2 ( kamran parsaye. The sandata warehouseich paradigm for data
warehousing and mining. Database programming & design, april
1995. )
13.2.- Bibliografia
utilizada.
·
Joyce bischoff and ted
alexander. Data warehouse - practical advice from the experts
·
Michael h. Brackett. The
data warehouse challenge.
·
W. H. Inmon, j. D. Welch and
katherine l. Glassey. Managing the data warehouse
·
The merge-purge problem and
the data cleaner, prof. Salvatore j. Stolfo, department of computer science,
·
Data mining - an
introduction, shula gross, baruch college, cuny, october 1, 1998
·
Data warehouse architect:
preparing for data mining, ralph kimball
·
Mining for gold by herb edelstein , information week: april 21, 1997, copyright 1997
cmp media, inc.
·
Data mining and intelligent
data analysis, dr. Liu bing, dr. Lu hong jun
·
Data mining - beyond
algorithms, by dr akeel al-attar, md of attar software
·
Knowledge discovery in
perioperative databases using rule induction: hypothesis testing, decision
support, and clinical guideline assessment by lemuel r. Waitman, dissertation
proposal, submitted to drs., Jerry c. Collins, douglas h. Fisher, michael s.
Higgins, paul h. King, randolph a. Miller, vanderbilt university, nashville,
tennessee 1999
·
Data extraction, cleansing
and migration tools, to support data warehouse, database consolidation, and
systems reengineering projects, 1996 richard j. Orli
·
Ascend improves data
integrity with truename library, by sabu
·
Consolidating customer
information: different technical approaches to integrating customer
information, march 1999
·
Next generation data
warehousing, by mark hwang and robert woerner, july 1998
·
Paladyne focuses on a
customer-centric approach with code-1 plus and merge/purge plus by martin bradley, july 1999
·
Migration architect key to
data quality for design data systems by patricia klauer published, july 1998
·
Migration architect key to
data quality for design data systems by patricia klauer published, february
1998
·
Plain english on data
quality: data cleaning in the data warehouse by larry p. English published,
december 1999
·
Advances in knowledge discovery
and data mining by usama m. Fayyad, gregory piatetsky-shapiro, padhraic smyth,
and ramasamy uthurusamy
·
Data cleaning: the first
step to knowledge by sandy stoker, february 2000
·
Toxic data by neville
haggerty, june 1998
·
Business intelligence in
healthcare: data cleaning by steve glover, march 1999
·
Challenges of efficient data
cleaning by arkady maydanchik, september 1999
·
Consolidating customer
information: different technical approaches to integrating customer
information, by mitchell i. Kramer, john e. Mann, and patricia b. Seybold,
march 1999
·
Customer relationship
management begins with enterprise-wide data quality by len dubois, august 1999
·
Paladyne focuses on a
customer-centric approach with code-1 plus and merge/purge plus
·
By martin bradley published
in dm review in july 1999
·
Royal bank standardizes and
cleanses data with integrity by mohammed (moe) rifaie published in dm review in
april 1999
·
Hidden complexities in
changed data propagation by meryl surgan and gil comeaux and george fisher
published in dm direct in august 1998
·
Starting a data warehousing
project? by david marco published in dm direct in july 1998
·
Strategies to solutions: a
primer on building a data warehouse by
·
The data warehouse diary:
data quality assessment for data warehouse design by richard kachur published
in dm review online in april 2000
·
The four challenges of
customer-centric data warehousing by don leick published in dm direct in
december 1998
·
Transforming disparate data
by michael h. Brackett published in dm review in october 1998
·
Don't warehouse dirty data
by joe celko and jackie mcdonald, october 15, 1995
·
Arkidata delivers cleansed
data conversion files and comprehensive audit reports for hewitt associates, by
greg haecker published in dm review gonow in april 2000
·
·
By satya sachdeva published
in dm review in april 1998
·
Manfred soeffky.
Replikationsmechanismen im überblick: weit und breit keine standards. Datenbank fokus, pages
41-47, september 1996.
·
Modelos de información y limpieza de los datos, isabelle guyon, n. Matic, y vladimir
vapnik
·
J. Pitkow. In search of
reliable usage data on the www. In sixth international world
wide web conference, pages 451--463,
·
P. Pirolli, j. Pitkow, and
r. Rao. Silk from a sow's ear: extracting usable structures from the web. In proc.
Of 1996 conference on human factors in computing systems (chi-96),
vancouver, british columbia, canada, 1996.
·
R. Cooley, b. Mobasher, and
j. Srivastava. Grouping web page references into transactions for mining world wide web browsing patterns. Technical report tr 97-021,
·
Wing-kay kan, john sum and
gilbert h. Young, parallel extended kalman filter approach for neural network
learning and data cleaning, to be presented international symposium on
operations research nd its applications (isora'98) august 20-22, 1998, kunming,
china.
·
Using recon for data
cleaning. (proc. 1995 1st intl. Conf. On knowledge discovery & data mining)
·
Data warehouse goals &
objetives:part 2:short-term objetives” de larissa moss
·
Data
cleaning: una dualidad
·
Un algoritmo dominio-independiente eficaz para detectar de forma
aproximada los registros duplicados de la base de datos, alvaro e. Monge y
charles p. Elkan
·
Dm review toxic data, por
neville haggerty published en dm review en 1998 de junio
·
Data cleaning para modelos
de computación: un caso de estudio en inmunología, vladimir brusic, john
zeleznikow, tiziana sturniolo, elisa bono y jürgen hammer, kent ridge digital
labs, singapore, la trobe university, bundoora, australia, roche milano
richerche, milan italia
·
Data cleaning: el primer paso hacia el
conocimiento , sandy
stoker, published in dm direct in february 2000
CAPÍTULO 14:
Vocabulario asociado.
A
Adquisición del
conocimiento. Proceso de
creación de la base de conocimiento de un sistema experto.
Algoritmo. Procedimiento matemático o lógico para realizar un
cálculo o para resolver un problema. Sucesión de operaciones elementales,
perfectamente especificadas y ordenadas, que sirven para hacer algo preciso.
Algoritmos
genéticos: técnicas de
optimización usadas comúnmente en el data mining que usan procesos tales como
combinaciones genéticas, mutaciones y selección natural en un diseño basado en
los conceptos de evolución natural.
Análisis
chaid. Análisis
estadístico de variables cuyo objetivo es la definición de la importancia
relativa de las mismas en un comportamiento determinado. El resultado se obtiene
en forma de árbol que presenta en la rama superior la variable más influyente
y, a partir de ella, las demás.
Análisis
cluster. Técnica de
análisis que consiste en la agrupación de clientes/suministros en base a su
comportamiento común frente a un grupo de variables.
Análisis de
riesgo. Estudio
sistemático para analizar cuáles son los riesgos relativos a la calidad y a la
seguridad a los que se encuentra sometido un proceso en una organización, sus
costes asociados y las contramedidas más eficientes para reducir o eliminar los
riesgos identificados.
Análisis del
sistema. Fase de la
metodología de desarrollo de sistemas en la que se definen objetivos,
funciones, pantallas, menús, modelos de datos, arquitecturas y, en general,
todas las cuestiones necesarias antes de proceder al diseño de programas para
el lenguaje que se haya elegido.
Análisis de
series de tiempo (time-series): análisis de una secuencia de medidas hechas a intervalos específicos.
El tiempo es usualmente la dimensión dominanate de los datos.
Análisis
exploratorio de datos: uso de
técnicas estadísticas tanto gráficas como descriptivas para aprender acerca de
la estructura de un conjunto de datos.
Análisis
prospectivo de datos: análisis de
datos que predice futuras tendencias, comportamientos o eventos basado en datos
históticos.
Análisis
retrospectivo de datos: análisis de
datos que provee una visión de las tendencias, comportamientos o eventos basado
en datos históricos.
Arbol. Estructura de representación de la información que
consiste en un único registro "padre" del que dependen cero o más
registros "hijos" que, a su vez, pueden dar origen a nuevos
subárboles.
Arbol de
decisión. Técnicas
usadas comúnmente en el data mining que se definen como estructuras de forma de
árbol que representan conjuntos de decisiones. Estas decisiones generan reglas
para la clasificación de un conjunto de datos. Métodos específicos de árboles
de decisión incluyen arboles de clasificación y regresión (cart: classification
and regression tree) y detección de interacción automática de chi cuadrado
(chai: chi square automatic interaction detection)
Asignación
de riesgo. Método para
asignar valores cuantitativos a las situaciones de riesgo que se identifiquen
dentro de una organización.
B
Base de
conocimiento. Parte
principal de un sistema experto, consistente en una estructura de datos que
contiene los conocimientos del experto del dominio (experiencia, estrategias de
razonamiento y conocimiento).
Base de
datos. Data
base. Conjunto de datos no redundantes, almacenados en un soporte
informático, organizados de forma independiente de su utilización y accesibles
simultáneamente por distintos usuarios y aplicaciones. La diferencia de una bd
respecto a otro sistema de almacenamiento de datos es que estos se almacenan en
la bd de forma que cumplen tres requisitos básicos: no redundancia,
independencia y concurrencia.
Base de
datos multidimensional: base de datos diseñada para procesamiento analítico on-line (olap). Estructurada como un hipercubo
con un eje por dimensión.
Base de
hechos. Elemento de
un sistema experto formado por una memoria auxiliar que contiene
simultáneamente los hechos iniciales que describen el problema a resolver y los
resultados intermedios obtenidos en el proceso de razonamiento y resolución.
Bases de
datos documentales. Son bases
de datos textuales con características de búsqueda documental asociadas:
diccionario, tesauros, operadores de proximidad, operadores booleanos,
truncamientos, etc.
Bloqueo. Cuando una transacción necesita asegurarse de que el
contenido de un recurso de la bd (un fichero, un registro u otro) no cambiará
hasta que la transacción finalice, se bloquea. El bloqueo impide que otras
transacciones lo modifiquen. Existen dos tipos principales de bloqueos:
bloqueos exclusivos y bloqueos compartidos. Si una transacción realiza un
bloqueo exclusivo sobre un recurso, ninguna otra podrá ejecutar ningún tipo de
bloqueo contra el recurso. Si una transacción realiza un bloqueo compartido,
otras transacciones podrán realizar bloqueos compartidos (pero no exclusivos)
sobre el mismo recurso. Esta última técnica se utiliza cuando la transacción no
va a actualizar los datos pero desea evitar que otras transacciones puedan
modificarlos.
C
Cart árboles
de clasificación y regresión: una técnica de árbol de decisión
usada para la clasificación de un
conjunto da datos. Provee un conjunto de reglas que se pueden aplicar a un
nuevo (sin clasificar) conjunto de datos para predecir cuáles registros darán
un cierto resultado. Segmenta un conjunto de datos creando 2 divisiones.
Requiere menos preparación de datos que chaid.
Clustering
(agrupamiento): proceso de
dividir un conjunto de datos en grupos mutuamente excluyentes de tal manera que
cada miembro de un grupo esté lo "más cercano" posible a otro, y
grupos diferentes estén lo "más lejos" posible uno del otro, donde la
distancia está medida con respecto a todas las variables disponibles.
Codasyl. Conference
on data sytem languages. Organización que fijó el estándar para el modelo de
bases de datos en red.
Commit. Los sgbds ofrecen sentencias especializadas para la
gestión de transacciones. La nomenclatura habitual en bases de datos
relacionales es: commit work para finalizar una transacción y rollback
para deshacerla.
D
Data base. Véase base de datos.
Data
cleaning: proceso de
asegurar que todos los valores en un conjunto de datos sean consistentes y
correctamente registrados.
Data cleansing: ver data cleaning
Data mart. Alplicación de data warehouse, contruida rápidamente
para soportar una línea de negocio simple y con un alcance limitado.
Data mining
(minería de datos). Proceso que
permite el descubrimiento y cuantificación de relaciones predictivas en los
datos, permitiendo transformar la información disponible en conocimiento útil
de negocio (extracción de información predecible escondida en grandes bases de
datos).
Data scrubbing: ver data cleaning
Data
warehouse: Sistema
para el almacenamiento y distribución de cantidades masivas de datos. Almacén
de datos, integrado en una estructura consistente, organizado por temas, con
valores históricos e información no volátil.
Datos
anormales: datos que
resultan de errores (por ej.: Errores en el tipeado durante la carga) o que
representan eventos inusuales.
Dbms. Data base management system.
Véase sgbd.
Diccionario. Estructura de datos que representa un conjunto de
elementos con posibilidad de soportar la inserción y eliminación de estos, así
como la comprobación de pertenencia al conjunto. Son ficheros inversos a los
que se ha dotado de características documentales. Soportan el proceso
informático de definición de palabras vacías, sinónimos y de tesauros.
Diccionario
de datos. Descripción
lógica de los datos para el usuario. Reúne la información sobre los datos
almacenados en la bd (descripciones, significado, estructuras, consideraciones
de seguridad, edición y uso de las aplicaciones, etc.).
Diccionario
de seguridad. Base de
datos que guarda los usuarios de un sistema, los recursos disponibles y los
derechos de acceso de cada usuario a esos recursos.
Directorio
de datos. Es un
subsistema del sgbd que describe dónde y cómo se almacenan los datos en la bd
(modo de acceso y características físicas de los mismos).
Drill-down. Técnica que permite la navegación de los datos
obtenidos en una consulta, al poder visualizar los distintos subniveles en que
se ha dividido la dimensión de la misma.
E
Experiencia. La capacidad y conocimiento que poseen los expertos en
un determinado dominio que les permite llevar a cabo eficientemente una tarea.
Experto en
el dominio. Profesional
que transfiere el conocimiento al sistema experto.
Explicaciones. Información que proporciona el sistema experto sobre
cómo y porqué ha llegado a una determinada solución o un estado intermedio.
F
Factor de
incertidumbre. Véase
coeficiente de verosimilitud.
H
Herencia. Notación ligada a los objetos estructurados que
permite a los objetos relacionados jerárquicamente heredar atributos.
Heurística. Regla basada en la experiencia que nos ayuda a
determinar cómo debemos proceder.
I
Ia. Inteligencia artificial. Ciencia cuyo objetivo es la
modelización y reproducción artificial del comportamiento humano. Engloba a los
sistemas basados en el conocimiento, la robótica, la visión artificial, el
reconocimiento de la voz, sistemas expertos, etc.
Inconsistencia. El contenido de una base de datos es inconsistente
si dos datos que deberían ser iguales no lo son. Por ejemplo, un empleado
aparece en una tabla como activo y en otra como jubilado.
Indexación. Proceso automático de generación de índices.
Ingeniero
del conocimiento. Profesional
encargado de extraer el conocimiento de un experto para transferirlo a la base
de conocimiento del sistema experto.
K
Kdd (Knowledge discovery from databases): Descrubrimiento del conocimiento
en una base de datos.
L
Lógica de
primer orden. Lógica que
autoriza el empleo de variables y cuantificadores.
Lógica
difusa. Lógica diseñada
para manejar conceptos relativos y aproximados.
M
Mantenimiento
de un sistema experto. Los
sistemas expertos necesitan estar en continua evolución para completar o
modificar el conocimiento añadiendo o cambiando reglas.
Metaconocimiento. Conocimiento que expresa la forma de razonar y
operar de un sistema experto.
Metadatos. Datos acerca de los datos. Fichero que debe existir
en todo data warehouse, que incluye todas las características de los datos que
se almacenan en él y las transformaciones que sufren del entorno operacional al data warehouse: campos que lo componen, estructura,
procedencia, proceso de tranformación, acumulación, forma de cálculo, etc.
Metarreglas. Reglas que describen cómo deben ser utilizadas o
modificadas las reglas que componen la base de conocimiento de un sistema de
producción.
Metodología. Conjunto de métodos que basados en unos mismos
principios, se integran en el marco del ciclo de vida de los sistemas. Aplicado
a la informática conjunto de métodos, procedimientos y técnicas utilizados para
llevar a cabo una planificación y desarrollo eficiente de los sistemas de
información.
Metodología
de desarrollo. Conjunto de
normas y principios a aplicar en el proceso de construcción de equipo lógico
Métodos
formales. Metodologías
tendentes a conseguir demostrar matemáticamente si un diseño de un sistema de
información es correcto.
Modelo
analítico: una
estructura y proceso para analizar un conjunto de datos. Por ejemplo, un árbol de decisión es un modelo para la clasificación de un conjunto de datos
Modelo
conceptual de datos. Diseño
previo de una base de datos en el que se realiza la primera aproximación.
Modelo de
datos. Un conjunto
de reglas que especifican a alto nivel la estructura de la base de datos. Según
el modelo utilizado, los mismos datos se almacenarán de forma muy distinta.
Modelo
lineal: un modelo analítico que asume relaciones
lineales entre una variable seleccionada (dependiente) y sus predictores
(variables independientes).
Modelo no
lineal: un modelo analítico que no asume una
relación lineal en los coeficientes de las variables que son estudiadas.
Modelo
predictivo: estructura y
proceso para predecir valores de variables especificadas en un conjunto de
datos.
Modelo
relacional. Propuesto
por codd a finales de los sesenta. Introduce la teoría de las relaciones en el
campo de las bd. En este modelo, los datos se estructuran en tablas manteniendo
la independencia de esta estructura lógica respecto al modo de almacenamiento u
otras características físicas. Las tablas se manejan mediante operaciones de la
teoría de conjuntos y el álgebra relacional.
Motor de
inferencia. Núcleo del
sistema experto que contiene las estrategias de control e inferencia.
N
Navegación
de los datos. Proceso por
el que el usuario puede profundizar en el significado de los resultados
obtenidos en una consulta multidimensional, mediante técnicas como el
drill-down de las consultas e indicadores de consulta, intercambio de variables
(swap) y formatos de presentación. Proceso de visualizar diferentes
dimensiones, "fetas" y niveles de una base de datos multidimensional. Ver olap.
Navegación
documental. Proceso por
el que un sgbdd nos permite pasar de un documento a otro con el que mantiene
algún tipo de relación (normalmente dinámica).
Normalización. Según el modelo relacional, las tablas deben
definirse siguiendo una serie de reglas precisas para asegurarse que no se
producirán anomalías en la actualización de la base de datos. Para ello, es
habitual que se necesite descomponer las tablas iniciales en otras más
simplificadas que no presenten dichos problemas. Este proceso es lo que se
conoce como normalización y es un método formalizado con diferentes niveles, a
cada uno de los cuales se le llama forma normal. || Acto de producción de normas y estándares.
O
Odbc. Open data base conectivity.
Conectividad abierta de bases de datos. Es el pilar principal del estándar wosa
(windows open system arquitecture),
arquitectura de sistemas abiertos windows.
Olap
procesamiento analítico on-line (on line analitic prossesing): sistemas que se caracterizan por ser un análisis
mutidimensional de datos corporativos. Se refiere a aplicaciones de bases de
datos orientadas a array que permite a los usuarios ver, navegar en base a la
información a obtener, manipular y analizar bases
de datos multidimensionales.
Ole. Object linking and embedding.
Enlace e
incrustación de objetos. Norma para la compartición de información entre
aplicaciones del sistema windows. Característica del entorno gráfico windows
que extiende las capacidades de "cortar y pegar", permitiendo
establecer vínculos entre diferentes programas. El procedimiento para vincular
e incrustar objetos es idéntico. La diferencia estriba en que el objeto
incrustado reside en la aplicación cliente. El objeto vinculado, por su parte,
contiene una representación gráfica e información del objeto que identifica el
fichero original y la aplicación cliente.
Oltp. On
line transaction processing. Proceso transaccional en línea. Método de proceso
continúo de transacciones.
P
Procedimientos
almacenados. Dispositivo
para almacenar código procedural asociado con sistemas de gestión de bases de datos
relacionales (sgbdr), que hace obligatorio su uso durante cualquier operación
de la base de datos.
Pseudocódigo. Forma del lenguaje natural que permite representar
un algoritmo de un proceso de bajo nivel. Es una de las técnicas empleadas para
completar las especificaciones en los diagramas de flujo de datos.
Q
Qbe. Query by example. Es una forma de
realizar una pregunta (query) en una base de datos en la
que se utiliza como patrón un ejemplo de lo que se quiere encontrar.
R
Redes
neuronal artificial: técnicas
usadas comúnmente en el data minig que se definen como modelos predecible
no-lineales que aprenden a través del entrenamiento y que tratan de emular el
funcionamiento de las redes neuronales del cerebro humano. La mayoría de las
veces son modelos teóricos que se plasman en programas de ordenador y unas
pocas modelos sobre silicio para aprovechar la velocidad de proceso paralelo de
estas arquitecturas.
Redundancia. Repetición de los mismos datos en varios lugares.
Redundancia
controlada. En
ocasiones, es necesario introducir voluntariamente redundancia en la bd por
consideraciones de rendimiento. En estos casos los administradores del sistema
repiten conscientemente algunos datos y, a la vez, preparan al sistema para
mantener automáticamente las distintas copias y que no se pierda la integridad.
Registro. Grupo de elementos de datos relacionados entre sí que
son tratados como una sola unidad. Soporte interno (informático) de la
estructura de la información a grabar. Su diseño responde a los datos
contenidos en la información que se desea grabar.
Regla de
inducción: técnicas
usadas comúnmente en el data mining que consisten en la extracción de reglas
if-then de datos basados en significado estadístico.
Reglas de
producción. Formalismo
lógico de representación del conocimiento de la forma "si premisa entonces
conclusión".
Regresión
lineal: técnica
estadística utilizada para encontrar la mejor relación lineal que encaja entre
una variable seleccionada (dependiente) y sus predicados (variables
independientes).
Regresión
logística: una regresión
lineal que predice las proporciones de una variable seleccionada categórica,
tal como tipo de consumidor, en una población.
Reingeniería de negocio. Bpr, business processing reengeneering.
Técnica que formalmente
se define como la revisión fundamental y rediseño radical de los procesos de
negocio con el fin de alcanzar mejoras espectaculares en medidas críticas de
rendimiento, tales como costes, calidad, servicio y rapidez.
Reingeniería. Es la modificación de los componentes de una
aplicación sin cambiar sus funcionalidades, por ejemplo la mejora de la
codificación de un programa. A veces también se emplea este término para
referirse conjuntamente a la ingeniería directa e inversa.
Relación. Matemáticamente, una relación es un subconjunto del
producto cartesiano de n dominios no necesariamente distintos. La teoría
matemática de las relaciones, adaptada y modificada, fue la base del modelo
relacional de bases de datos.
Repositorio. Base de datos central en herramientas de ayuda al
desarrollo. El repositorio amplía el concepto de diccionario de datos para
incluir toda la información que se va generando a lo largo del ciclo de vida
del sistema, como por ejemplo: componentes de análisis y diseño (diagramas de
flujo de datos, diagramas entidad-relación, esquemas de bases de datos, diseños
de pantallas, etc.), Estructuras de programas, algoritmos, etc. En algunas
referencias se le denomina diccionario de recursos de información.
Rollback. Véase commit.
S
Sgbd. Sistema de gestión de bases de datos. Conjunto de
programas que permite crear una base de datos, manipular la información que
contiene y realizar todas las tareas de administración necesarias para
mantenerla operativa.
Sgbdd. Sistema de gestión de bases de datos documentales.
Si. Véase sistema de información.
Sistema de
información. Si.
Conjunto de elementos físicos, lógicos, de comunicación, datos y personal que,
interrelacionados, permiten el almacenamiento, transmisión y proceso de la
información.
Sistema
experto. Programa o
programas de ordenador capaces de actuar como un experto humano en un dominio
específico y que incorporan el conocimiento y la experiencia humanos.
Sistema
abierto. Conjunto de
equipo físico (hardata warehouseare) y/o
equipo lógico (software) destinado a
cualquier propósito que está basado en las normas de la organización osi para
sistemas abiertos. Se caracterizan por mantener públicos los diseños y las
especificaciones de todos sus componentes, de forma que sea posible la
comunicación por parte de otros usuarios sin más barreras que los requisitos de
seguridad y, por parte de los fabricantes, sea posible el diseño de sistemas
que se puedan acoplar y/o comunicar con ellos.
Sistemas
basados en el conocimiento. Knowledge based system (kbs). Programa de ordenador que utiliza
el conocimiento y un sistema de inferencia para resolver problemas difíciles,
siendo capaces de actuar como un experto en un dominio específico.
Sistemas
query&reporting. Sistemas
que permiten consultas e informes libres. Trabajan tanto sobre la información
de detalle como sobre la agregada.
Sql. Structured query language. Lenguaje
de interrogación normalizado para bases de datos relacionales. El sql es un
lenguaje de alto nivel, no procedural, normalizado que permite la consulta y
actualización de los datos de bd relacionales. Se ha convertido en el estándar
para acceder a bd relacionales. La primera versión se aprobó como norma iso en
1987 y la segunda, conocida como sql2 y vigente actualmente, en 1992.
Actualmente se trabaja en la norma sql3 que soportará bases de datos orientadas
a objeto y bases de datos activas. El sql facilita un lenguaje de definición de
datos y un lenguaje de manipulación de datos. Además, incluye un interfaz que
permite el acceso y manipulación de la bd a usuarios finales.
T
Transacción. Transaction. Cada una de las
operaciones agrupadas que deben realizarse todas juntas o no realizarse en
absoluto. Cada uno de los cambios en una base de datos que deben realizarse al
mismo tiempo o no realizarse en absoluto. ||
Operación o tarea completa individual dentro de un proceso interactivo o de
dialogo con el ordenador. Comienza con una entrada de datos y termina con una
respuesta del ordenador.
Trigger. Desencadenante.
Suceso que no es parte del proceso pero hace que este arranque.
Tupla. Fila de una tabla de un sgbd relacional. Representa
una ocurrencia.
Two-phase commit. Protocolo necesario para dar commit (sentencias especializadas en la gestión de transacciones)
en bd distribuidas. Para garantizar que todas las bd involucradas quedarán
correctamente modificadas, el commit
se divide en dos fases. Primero se comprueba que todos los nodos involucrados
están listos para realizar la actualización. En segundo lugar, se modifican las
bases de datos si, y solo si, todos los nodos están preparados.
Ultima actualización, el 01 de Enero de 2009