Hasta ahora hemos visto cómo instalar Data Quality Services y cómo construir una base de conocimiento, el elemento básico de la herramienta y que nos va a permitir realizar prácticamente todas las acciones que nos van a aportar un valor de negocio a través de la calidad de nuestros datos.En este capítulo vamos a ver cómo entra en juego una base de conocimientos en uno de los apartados de SQLServer Data Quality Services, los proyectos de matching (correspondencia) y cleansing (limpieza).

Proyectos de Matching

Creando una regla de matching

Un proyecto de matching se basa en una regla de matching definida en una base de conocimiento. Mediante este tipo de proyectos, DQS nos va a permitir analizar los datos que le suministramos para hacernos sugerencias acerca de “qué datos se parecen a otros de nuestro conjunto”. Sería algo así como realizar una clusterización o agrupado de los datos, de manera que podamos simplificar el conjunto que tenemos. Esto puede ser muy interesante como punto de partida para un proyecto de Knowledge Discovery, como veremos más adelante.

Para generar la regla de matching necesaria para iniciar un proyecto de este tipo, empezaremos por editar nuestra base de conocimiento, seleccionando la actividad “Matching Policy”. Seleccionamos el servidor, la base de datos y la tabla o vista sobre la que queremos establecer la regla de matching (en nuestro caso la vista “Songs”) y la regla de dominio que queremos utilizar para nuestra regla de matching, mapeándola como se ve en la imagen con el campo correspondiente.

Pulsando “Next” pasaremos al siguiente paso, la definición de la regla de matching.

En esta fase tenemos 5 componentes básicos:

1. Minimum matching score: Indica el mínimo porcentaje de similitud para que se considere a dos registros parte del mismo conjunto o clúster. Por defecto, DQS no permite establecer este valor por debajo de 80%, aunque es modificable mediante el monitor de configuración de DQS.
2. Rule editor: nos permite ajustar las características para la regla de los diferentes dominios que hayamos seleccionado y mapeado en el paso anterior. Podemos establecer que la similitud sea “Similar” ó “Exact” (en cuyo caso el valor de “Minimum matching score” deja de tener validez), qué peso queremos que tenga este dominio sobre la regla en general (si estamos utilizando más de una regla de dominio para identificar el registro) y si el dominio regla es prerrequisito para la validez de la regla (si el registro no cumple con las características del dominio no se aplicará la regla de matching).
3. Run matching policy rule: Nos permite ejecutar la regla para observar cuales serían los resultados sobre nuestro conjunto de datos. Podremos visualizar estos resultados en la parte inferior de la pantalla, en las pestañas “Profiler” y “Matching Results”
4. Show overlapping / non overlapping clusters: Especificamos si queremos que se nos muestren los clústers o grupos que se solapen, en el caso de que haya elementos muy parecidos pero que DQS estime que forman parte de grupos separados (aunque nosotros sepamos que no lo son y tengamos que retocarlos a mano).
5. Create new matching rule: Nos permite crear una nueva regla de matching.

Si ejecutamos la regla para previsualizar los resultados de matching

Podemos observar una grandísima cantidad de elementos “unmatched”, es decir, únicos, pues esto quiere decir que no ha encontrado similitud suficiente como para incluirlos en un clúster. Si vemos los resultados de profiler de DQS.

Al pasar el ratón por encima del icono de advertencia, DQS nos muestra un mensaje avisándonos de que el campo tiene un alto grado de unicidad, lo que puede reducir los resultados de matching. Esto es precisamente lo que veíamos en el diagrama previo, dónde sólo un 0,2% de los resultados caen dentro de un clúster reconocible.

Lo que hemos visto hasta ahora es una ejecución de prueba, para realizar un test ajustando los dominios que usaremos y el resto de parámetros. Podríamos crear la regla de matching sin realizar ninguna ejecución, simplemente para tenerla preparada para un proyecto de matching. Al pulsar “Next”, pasaremos a la fase donde podremos hacer una prueba de ejecución con más detalle, generar nuestra regla de matching, incluirla en nuestra base de conocimiento y publicar ésta.

Al ejecutar la regla en el siguiente paso, el paso 3, tendremos algo como esto:

Una vez termine, podremos analizar los resultados mediante el visor de la parte inferior y mediante las pestañas que ya conocemos, “Profiler” y “Matching Results”

Aquí vemos que aquellas filas que considera “Matched”, es decir, para las que encuentra un clúster apropiado, son aquellas que presentan una similitud suficiente (en nuestro caso, mayor al 80%) a alguna otra.

Finalmente, podremos pulsar “Finish” para finalizar la creación de la regla de matching y publicar nuestra base de conocimiento con ésta añadida.

Ejecutando un proyecto de matching

Para crear y ejecutar un proyecto de matching, pulsaremos en “New Data Quality Project”

Pasaremos a una pantalla donde podremos configurar los parámetros iniciales del proyecto y crearlo.

Donde tenemos 3 elementos básicos:

1. La base de conocimiento a emplear en el proyecto
2. El tipo de proyecto que queremos crear
3. El botón para crear el proyecto

Esta pantalla es común a todos los proyectos de DQS. Si la base de conocimiento elegida no cumple los requisitos para algún proyecto en particular éste no será accesible. Por ejemplo, si nuestra base de conocimiento no tuviese la regla de matching que hemos creado en el paso anterior, el proyecto de matching no estaría disponible para elegir en el apartado 2.

Al crear el proyecto, nos encontraremos con una pantalla para mapear nuestro origen de datos, servidor o fichero (en el caso de que fuese un origen Excel), tabla o vista y finalmente, mapeos de campos con las reglas de dominio presentes en la base de conocimiento con la que estemos trabajando.

En nuestro caso tenemos un origen SQL Server, por lo que nos pregunta por la base de datos y la tabla o vista. Si tuviésemos un origen Excel, nos preguntaría por la ruta del fichero de origen.

Una vez tengamos todo correctamente mapeado, pasamos al siguiente paso, la ejecución del proceso de matching. Tendremos el mismo caso que en la ejecución de prueba vista anteriormente cuando generábamos la regla de matching, sólo que ahora podremos ver los resultados con más detalle y podremos exportarlos. Además, no podremos seguir al próximo paso (Survivorship) sin ejecutar el proceso de matching.

Como era de esperar, tenemos resultados iguales que en la ejecución de prueba que habíamos realizado en el apartado anterior.

Al pulsar “Next” pasamos a la fase de “Survivorship” o Supervivencia. En esta fase podremos especificar una política para que DQS decida qué elementos para los que ha encontrado un clúster reconocible queremos mantener como correctos.

Las posibilidades son:

• Most complete and longest record (el registro más completo y más largo): Aquel registro que tenga el mayor numero de campos poblados y con el mayor número de términos en cada campo. Un término puede ser un carácter o un dígito, en el caso de campos numéricos.
• Most complete record (el registro más completo): El registro que tenga mayor número de campos poblados. Se considera un campo poblado aquel que contiene al menos un valor de su tipo de datos.
• The longest record (el registro más largo): El registro con el mayor número de términos en sus campos de origen.

Todos los campos de la fuente de datos se analizan para las 3 políticas de elección de supervivientes, aunque no los hayamos mapeado en el paso que ilustra la figura 9.

En nuestro caso elegiremos la política del registro más completo y más largo, pero la elección dependerá del conocimiento que tengamos del dato subyacente y de qué queramos hacer con él. Podemos considerar, por ejemplo, que nos vale con que el nombre del artista ha de ser el de mayor longitud para ser el válido. En este caso, bastaría con elegir el registro más largo. Sin embargo, podemos considerar también que el nombre de artista más adecuado será aquel que esté acompañado de más información relacionada (el resto de campos del registro) en el origen de datos. Entonces, elegiríamos el más completo. O una combinación de ambas políticas, que combina lo mejor de ambas pero es algo más compleja de calcular para DQS.

Pulsamos Start para iniciar el proceso de matching. Los resultados nos muestran qué registros ha elegido DQS como correctos. Podremos filtrar por supervivencia (comparando los registros duplicados que ha encontrado)

o por aprobados (todos los registros que ha considerado dentro de los clústers, sin comparar contra los otros):

Pulsamos Next para pasar a la última fase, la exportación de los resultados. Podemos exportar los resultados o bien a un destino SQL Server o bien a un fichero CSV. Podemos exportar los siguientes resultados:

• Matching results: Todos los registros con información sobre su pertenencia o no a clústers.
• Survivorship result: Nuestros resultados ya clusterizados (agrupados), habiendo eliminado los duplicados encontrados

En nuestro caso, exportamos los resultados a tablas en nuestra base de datos SQL Server. Si realizamos una consulta a la tabla de Matching Results (le hemos dado el nombre de Matching_Songs)

Vemos que aquellas que ha encontrado como parte de un clúster tienen información acerca de su identificador de clúster, por qué regla de matching han sido identificados, que puntuación de similitud se les ha asignado y las columnas originales de la tabla (nombre de la canción y orden que ocupa cada registro). Además, tenemos el campo PIVOT_MARK, marcado en rojo en la imagen, que nos permite aplicar una operación PIVOT sobre la tabla para generar un informe de correspondencia organizado por filas. Es decir, que en una sola fila aparezcan todos los elementos del clúster que DQS ha reconocido.

Si consultamos la tabla de canciones “supervivientes”, en nuestro caso Survivorship_Songs

Tenemos simplemente la lista de registros que DQS ha considerado correctos después de seguir nuestras indicaciones. En nuestro caso utilizaremos esta tabla como base para realizar un descubrimiento de conocimiento previo a nuestro proyecto de limpieza de datos. A continuación veremos qué es esto y por qué seguimos esta lógica.

Proyectos de Cleansing

Descubriendo conocimiento.

Antes de pasar a intentar limpiar nuestros datos, necesitamos indicar a DQS cuáles son nuestros datos correctos, aquellos que sabemos que sí cumplen los estándares que queremos en nuestro sistema.

Hemos visto en capítulos anteriores de esta serie cómo generar nuestra base de conocimiento y cómo realizar un proceso de descubrimiento de conocimiento (knowledge discovery). En el ejemplo que teníamos, veíamos como utilizar una tabla que servía de origen, aunque también podríamos haber utilizado un fichero Excel (como un maestro de proveedores validado por nuestro departamento de negocio, por ejemplo). Este planteamiento es válido siempre y cuando esa tabla / vista / fichero Excel esté validado y sepamos que es correcto a todos los niveles. Corrección ortográfica, validez de negocio, datos actualizados, etcétera, son cuestiones a tener en cuenta. Si estas condiciones no se dan, estaremos creando nuestra referencia de datos, la biblia de nuestro sistema de calidad de datos, con datos erróneos, y en consecuencia, tendremos errores constantes al ejecutar cualquier actividad basada en ella.

En este caso, utilizaremos la tabla de canciones “supervivientes” ya que hemos recorrido un paso más en el filtrado de datos. Ya nos hemos quitado de encima los valores duplicados que DQS ha detectado con el proyecto de matching y esto, junto con otras medidas (los registros cumplen las características indicadas por el dominio de la base de conocimiento, los valores han sido revisados por un experto de negocio, etc.) nos ayuda a que nuestra base de conocimiento sea confiable.

Esta metodología es sólo un ejemplo de cómo combinar diferentes capacidades de DQS para conseguir resultados adecuados a nuestras necesidades. El descubrimiento de conocimiento podría ejecutarse también utilizando como fuente cualquier otro conjunto de datos fiable.

Para una referencia rápida acerca de la creación de una base de conocimiento y el proceso de descubrimiento de datos, ver el capítulo 2 de esta serie.

Limpiando nuestros datos.

Ahora que ya tenemos nuestra base de conocimiento alimentada con los resultados del proyecto de matching, podemos iniciar un proyecto de limpieza de datos.

Utilizaremos la misma tabla que habíamos usado para el proyecto de matching para ver así como DQS corrige los valores que anteriormente había identificado como pertenecientes a un clúster a los que finalmente hemos determinado como correctos.

Para crear un proyecto de limpieza de datos, repetiremos el mismo paso que para el de matching pero seleccionando “Cleansing” en el apartado 2 de la figura 8. El siguiente paso será muy parecido también al de matching, en la fase de mapeo.

Ahora, DQS basará sus cálculos en los valores que tiene marcados como correctos en la base de conocimiento. Es decir, aquellos que le hemos dado durante el proceso de descubrimiento de conocimiento (knowledge discovery).

El siguiente paso es el proceso de limpieza, sin ver los resultados. Sólo podremos ver un breve resumen de qué ha encontrado DQS y qué ha hecho con aquellos registros que podía o sabía corregir.

DQS nos advierte que hay relativamente pocas correcciones en este campo y nos sugiere posibles acciones, como eliminar el mapeo, ejecutar un proceso de descubrimiento de conocimiento o usar otra base de conocimiento que pueda corregir más valores. Esto es una simple sugerencia, en nuestro caso sabemos que estamos utilizando los valores correctos por ser un caso de prueba. Pero si, por ejemplo, estuviésemos utilizando una base de conocimiento que no hemos construido nosotros, podríamos querer preguntar a quien la elaboró para confirmar que estamos utilizando los dominios correctos o para informarnos de cómo se diseñó.

Al pulsar “Next” pasaremos a la fase de administración y análisis de resultados.

En este paso podremos explorar las siguientes pestañas de resultados:

• Suggested: Valores que DQS no está seguro de que esté corrigiendo bien, pero que sugiere cambios para que se amolden a las políticas del dominio de nuestra base de conocimiento. Poner la primera letra en mayúsculas, podría ser, si nuestro dominio así lo específica, o realizar una corrección completa si el nivel de confianza que DQS tiene está entre el 60% y el 80% (valores por defecto, aunque modificables mediante el monitor de configuración de DQS)
• New: Valores que DQS no tenía registrados como correctos en la base de conocimiento.
• Invalid: Valores que, por algún motivo, no cumplen las especificaciones del dominio correspondiente de la base de conocimiento (tipo de dato erróneo, longitud mayor o menor de la permitida, etc.)
• Corrected: Valores que DQS sabe corregir con seguridad porque tiene una correspondencia establecida. En nuestro caso de ejemplo los 10 valores encontrados para corregir caen en esta categoría porque tiene valores registrados como correctos con un altísimo porcentaje de similitud.
• Correct: Valores que ya estaban en la base de conocimiento y son reconocidos como correctos. Cumplen con las directrices del dominio y ya los teníamos “fichados”.

En cada pestaña podremos aprobar o rechazar la posible corrección que DQS nos haga. En el caso de ser inválidos no podremos. Para poder tratarlos deberemos modificar nuestra base de conocimiento.

En este caso, vamos a aceptar todas las correcciones.

Finalmente, al pulsar Next, podremos exportar nuestros resultados a una tabla de SQL Server o a un fichero CSV.

Tenemos los siguientes apartados:

1. Output Data Preview: Vista previa de los datos después de la estandarización. Viene dado por el punto 3 de esta lista.
2. Export cleansing results: Aquí podemos mapear el destino donde queremos volcar nuestros resultados.
3. Standarize output: Elegimos si queremos estandarizar la salida (primera letra mayúscula, eliminación de espacios en blanco sobrantes al principio y al final del registro, etc.)
4. Campos a exportar: Aquí podemos elegir qué queremos añadir a nuestros resultados.
5. Export: Volcar los resultados en nuestro destino

Al consultar la tabla donde hemos exportado los datos vemos

Observamos las columnas extra que se han añadido:

• Song_Output: El valor que DQS da como salida. Para saber cuál es y por qué deberemos analizar el resto de columnas.
• Song_Reason: La razón por la que DQS da la salida Song_Output. En nuestro ejemplo, especifica “DQS_Cleansing”, es decir, ha encontrado una correspondencia al aplicar las reglas propias del dominio para limpiar los datos. Podría ser también New Value o Failed Rule, por ejemplo.
• Song_Confidence: La fiabilidad que DQS nos da acerca de la decisión que ha tomado.
• Song_Status: El estado en el que se encuentra el registro. Como hemos visto antes, puede ser Correct, Corrected, Invalid, Suggested y Unknown.
• Song_AppendedData: En el caso de que estuviésemos consumiendo una base de conocimiento en la nube (utilizando Azure Marketplace) pudiera ser que nos devolviese datos extra con información sobre el registro analizado. Por ejemplo, si hablásemos de direcciones en un mapa, podría devolvernos la longitud y a latitud de dicha dirección. Estos datos irían añadidos en este campo.

A partir de aquí podríamos simplemente saber que registros pueden ser corregidos o, por ejemplo, generar una consulta TSQL o un paquete SSIS para limpiar nuestros datos partiendo de nuestra tabla de resultados exportada.

En el próximo y último capítulo veremos cómo se integra un proyecto de limpieza de datos de DQS en SSIS para simplificar este último paso, pues podemos utilizar toda la potencia de SSIS para exprimir nuestros resultados de la limpieza de datos en memoria (mapeando campos corregidos, seleccionando registros en función de su columna _Confidence, etc.)

Conclusiones

En este artículo hemos visto cómo se configuran, ejecutan y explotan los proyectos de matching y limpieza de datos en SQL Server Data Quality Services.

Hemos aprendido a crear una regla de matching y la manera de usarla para detectar candidatos a registros duplicados con los proyectos de matching.

También hemos aprendido de esos datos depurados, incorporándolos a nuestra base de conocimiento para, posteriormente, limpiar el grueso de los datos.

Todos estos procesos y técnicas, bien desarrolladas e implementadas, pueden ser de gran ayuda en un entorno de negocio real, donde hay gran cantidad de datos introducidos o mantenidos a mano en infinidad de orígenes heterogéneos. Podremos, por ejemplo, detectar que el proveedor “La Madrileña de Tornillos” también se encuentra referenciado como “La madrileña de tornillos”, con un ID diferente, y por eso nuestro informe muestra de manera errónea las gráficas. Y podremos, también, mediante un proceso relativamente simple, limpiar estos datos en poco tiempo para tener nuestro informe listo y bien presentado.

Sólo con estos ejemplos simples podemos intuir el valor de negocio que puede aportar esta herramienta, evitándonos tiempos de desarrollo y posibles errores debidos a datos de baja calidad.

Otros posts relacionados:

1. SQL Server Data Quality Services
2. Contruyendo un Data Quality Knowledge Base con SSDQS Studio
3. Proyectos ‘Cleansing’ y ‘Matching’ con SSDQS Studio.
4. SQL Server Data Quality Services e Integration Services (SSDQS y SSIS)