Este es el segundo de una serie de cuatro artículos sobre Data Quality Services de SQL Server 2012
- SQL Server Data Quality Services
- Contruyendo un Data Quality Knowledge Base con SSDQS Studio
- Proyectos ‘Cleansing’ y ‘Matching’ con SSDQS Studio.
- SQL Server Data Quality Services e Integration Services (SSDQS y SSIS)
SQL Server Data Quality Services Studio
Esta aplicación se instala marcando la característica Data Quality Client en el asistente de instalación de SQL Server 2012 CTP3, como vimos en la entrada anterior de esta serie. En el menú de iniciotodos los programas se crean accesos directos para esta aplicación para las versiones 32 bits y 64 bits en caso de que se haya efectuado la instalación para plataformas x64:
Al inicio aparece la ventana de conexión con la instancia SQL que hospeda el servicio SSDQS. Se puede trabajar de forma distribuida, la donde se abra el SSQS Studio puede variar del que ejecute el servicio.
Una vez conectados al servicio el cliente muestra varias secciones que enumeramos brevemente:
Knowledge Base Management: En esta sección disponemos de los botones New y Open Knowlege Base. Podremos crear, publicar, bloquear, eliminar base de conocimiento y todo lo necesario para su gestión de la piedra angular de este servicio.
Data Quality Projects: Los proyectos son la aplicación de los conocimientos generados sobre conjuntos de datos. Cleansing permite la modificación, eliminación, enriquecimiento y en definitiva la aplicación de las definiciones de una base de conocimiento de calidad de los datos (DQKB). Por otra parte, los proyectos de Matching utilizan políticas en las que se definen reglas y se validan contra el conjunto de datos que seleccionemos (Orígenes Excel o SQL).
Administration: El Monitor de Actividad registra las operaciones realizadas por el servicio, tales como modificar una base de conocimiento, la creación de un proyecto y eventos similares. También podremos configurar Datos de referencias externos (Windows Azure Marketplace DataMarket) y algunas opciones para los proyectos.
Construyendo una Base de Conocimiento (Knowledge Base)
Para crear una nueva Base de Conocimiento tenemos tres posibilidades:
- Crear una nueva
- Importar un fichero de datos (.dqs)
- Crear a partir de una existente
En cualquiera de los casos es necesario asignarle un nombre y seleccionar que actividad queremos desarrollar tras la creación. De nuevo, disponemos de tres opciones
- Domain Management
- Knowlege Discovery
- Matching Policy
Vamos a indagar un poco más en cada una de ellas.
Domain Management
Los dominios de datos agrupan una serie de valores y reglas que definen una entidad. Un ejemplo de domino pudiera ser País: el conjunto de nombre de países son los valores que ampara el domino.
Para comenzar a trabajar con una Base de Conocimiento vacía es la actividad más apropiada ya que podemos definir distintos dominios y sus propiedades, valores, reglas a aplicar o relaciones entre términos.
Para orientarnos en el proceso hagamos una de ejemplo. Creamos una Knowledge Base vacía, en mi caso la llamé Music Sample Blog, seleccionando la actividad Domain Management y pulsamos Create
En la siguiente ventana podremos gestionar los dominios de la KB, importándolos desde un archivo .dqs (previamente exportado desde el SSDQS Studio) o creándolos nuevos. Vamos a pulsar en esta última opción y añadir el dominio Artists, en el que definiremos nombres de artistas y las reglas que deben seguir estos nombres.
Aparece la ventana de creación de dominio en la que establecemos sus propiedades, con especial atención a la opción Use Leading Values. Si se marca tomará el valor principal en una lista de sinónimos del dominio:
Ya tenemos el dominio creado, aunque en estos momentos no sería de ninguna utilidad si quisiéramos aplicarlos en proyectos de Cleansing o Matching.
Una vez hayamos creado el dominio, nos aparecen una serie de pestañas para definirlo:
Reference data
Se puede vincular un dominio con datos de referencia externa, ubicados en el Marketplace DataMarket de Windows Azure. Para lograrlo debemos configurarlo previamente en la sección Administration Configuration desde el mismo SSDQS Studio. Hablaremos en profundidad sobre este tema en una próxima entrada del blog.
Domain Rules
En esta sección se definen las reglas (de formato, patrones o valor) que deben seguir los datos que se comprueban contra este dominio. La reglas de validación permiten asegurarnos de que los valores cumplen un patrón, contienen determinadas palabras o longitud, etc… Para elaborar estas reglas tenemos una variedad de condicionales que evaluarán los valores:
Con esta condición (Longitud es igual o mayor que : 3) me he creado la regla ‘Longitud mínima’. Cualquier valor definido en el dominio que no cumpla esta regla (o cualquier otra) se marcará como inválido, lo verificaremos en la siguiente sección Domain Values.
Domain Values
En esta pestaña se definen los valores contenidos por el dominio, pudiendo ser de tipo válidos, inválidos o erróneos. La primera pregunta que nos puede surgir es ¿qué diferencia hay entre valores erróneos e inválidos?
Los valores inválidos son los que no se aplican al dominio, por ejemplo para el dominio Artists el valor 20070101 sería inválido, mientras que Kueen sería erróneo, ya que puede corregirse por Queen (Agradecer a James Beresford el planteamiento en el Foro MSDN de Data Quality Services).
Vamos a definir algunos valores, nombres de grupos o artistas, para nutrir nuestro dominio:
- Bob Marley
- Bob Marley & The Wailers
- Bob Marley and The Wailers
- Queen
- Kueen
- Marillion
- Moby
- H2
Hemos introducido los valores 2 y 3 de la lista, que en realidad son el mismo grupo con la diferencia de ‘&’ por ‘and’. Vamos a vincularlos como sinónimos para proveer de solidez a la calidad de datos y evitar que en las operaciones de Cleansing nos mantenga las dos versiones del nombre.
Para vincular dos o más valores como sinónimos debemos marcarlos en el grid (Ctrl+clic) y cuando los tengamos seleccionados pulsamos en el botón ‘Set selected domain values as synonymous‘(Establecer valores de dominios seleccionados como sinónimos)
Aquí es donde hay que tener en cuenta si hemos marcado o no la opción ‘Use Leading Values’ como propiedad del dominio. Podemos cambiar el valor principal del conjunto de sinónimos para que se utilice en las coincidencias de cualquiera de ellos:
Vemos que el último valor introducido, ‘H2’ se marca como inválido. Esto se debe a la regla que creamos en la sección anterior, dónde la longitud del valor se restringía a 3 o más caracteres. Si intentamos modificar el Tipo a correcto, nos aparecerá un mensaje de error avisándonos de que no cumple la restricción:
Está bien, es lo que esperábamos. Esto supone que si encuentra el valor ‘H2’ lo definirá como inválido, no para el dominio Artist (espero que ellos y sus fans sepan perdonarme por el ejemplo ;)).
Por defecto el valor nulo siempre existe como inválido, para mantener coherencia con las tareas para aportar calidad a los datos.
Para lograr que el valor 5 Kueen lo reconozca como erróneo y lo sustituya por Queen cambiamos el Tipo de valor y establecemos como erróneo, y en la columna Correct To escribimos ‘Queen’. Automáticamente nos crea una relación entre el valor correcto y el incorrecto, tomando como principal el correcto:
Term-Based Relations
En esta sección podemos definir términos y correcciones, sin que estas se reflejen como tal en las estadísticas Profiling. Puede utilizarse para realizar correcciones o sustituciones básicas como Sr. por Senior, o Corp. por Corporation.
Revise la documentación completa de esta función en MSDN
Composite Domains
Data Quality Services permite la construcción de dominios ‘compuestos’ uniendo varios dominios. En futuras operaciones de Cleansing o Matching podremos mapear una columna con el dominio compuesto, y el motor DQS se encargará de reconocer cada parte como dominio individual. Siguiendo el ejemplo anterior, hemos creado el domino Artist y supongamos que también el dominio Song, definiendo como valores de dominio el título de una canción por cada artista al menos.
Creamos el dominio compuesto Artist – Song en el que incluimos, por orden, los dominios Artist y Song.
Al pulsar Ok nos lleva a la ventana de propiedades, en la que es importante desplegar el apartado ‘Advanced’ y cambiar el orden de análisis de los dominios involucrados. Por defecto se asigna ‘Reference Data’ que solo es válido cuando se utilizan datos de referencia externa (Azure Datamarket)
Composite Domain Rules
Una de las ventajas de estos dominios compuestos es la posibilidad de definir reglas entre los dominios individuales que lo forman.
En este tipo de reglas IF … Then… podemos declarar restricciones como
IF Song = ‘Everloving’ Then Artist=’Moby’
Es posible complicar estas reglas añadiendo condiciones con los operadores OR y AND en ambas partes del condicional:
En esta KB asignar un nombre de canción a un solo artista puede ser un equívoco, ¿Qué hay de las versiones? Como ejemplo, vamos a dejarlo así.
Knowledge Discovery
Este es un proceso asistido por la aplicación mediante el cual podemos crear o enriquecer el contenido de uno o varios dominios de una Knowledge Base.
Para iniciar este proceso en la creación de una Knowledge Base, seleccionando el tipo de actividad que queremos realizar tras la creación. En nuestro caso, vamos a acceder desde el menú inicial de SSDQS Studio, pulsando en Open Knowledge Base de la sección Knowledge Base Management.
Seleccionamos la KB con la hemos trabajado en este artículo y seleccionamos la actividad Knowledge Discovery
Podemos utilizar datos desde orígenes Excel o SQL Server. En caso de utilizar una tabla de SQL Server para el descubrimiento de conocimiento, la base de datos debe estar en el mismo servidor que la base de datos del servicio SSDQS (DQS_MAIN), los login ##MS_dqs_service_login## y ##MS_dqs_db_owner_login## deben tener los permisos adecuados. En caso de utilizar Excel como fuente de datos, este debe estar instalado en el equipo cliente.
Vamos a utilizar una base de datos con nombres de artistas y canciones, que puedes descargarte para realizar tus pruebas.
Mapeamos los campos de origen con los dominios, creándolos si no existieran:
Una vez finalizado el mapeo de campos pasamos a la ventana de proceso Discovery en el que pulsamos en el botón Start para que comience el análisis.
Observemos que aparece una pestaña que no habíamos visto hasta ahora: Profiler.
Contiene los datos detallados producidos por el análisis del conjunto de datos proporcionado. Podemos ver que de nuestra muestra de datos de 1000 registros (la tabla contiene un millón de registros, para no alargar mucho el proceso creé una vista con un top 1000 de la tabla ArtistName) el análisis ha definido 1000 valores como nuevos y ‘únicos, pero sólo son válidos para el dominio 999. ¿A qué se debe esto? Recordemos que el dominio Artist tiene definida una regla de validación que exige que los nombres de artistas tengan una longitud mínima de 3 caracteres. Hacemos una consulta en la muestra de datos y efectivamente existe un registro que no cumple esta regla:
¿Qué pasa con el resto de valores válidos? Tras el proceso de análisis, podemos continuar a la pantalla Manage Domain Values en la que podemos asociar, corregir o cambiar el tipo de valores (igual que en la pestaña Domain Values de un dominio). Los valores que no cumplan las reglas de validación también se añadirán a la Knowledge Base con el tipo Inválido
Cuando finalizamos el proceso se actualiza la Knowledge base con los nuevo valores ‘aprendidos’. Podemos comprobarlo repitiendo el mismo análisis y comprobando los resultados en el Profiler.
Conclusiones
A través del SQL Server Data Quality Services Studio tenemos la capacidad de crear base de conocimiento sobre la calidad de los datos por distintas vías:
- Domain Management para la creación de forma manual de valores para el dominio
- Knowlegde Discovery, proceso asistido que permite la inserción de multiples valores para dominios
- Reference Data Services para vincular un dominio con datos de Azure (tema del que no hemos hablado en esta entrada).
En el futuro podremos contar con la API del servicio para vincular datos de referencia ‘privados’.
En los dos capítulos que llevamos de la serie Data Quality Services hemos visto como instalar y configurar el servicio y el cliente, y como crear una base de conocimiento por varios métodos. En próximos capítulos nos ocuparemos de la creación de Matching Policies, comenzaremos la aplicación de estos conocimientos sobre la calidad de los datos a través de proyectos de Cleansing y Matching, y posteriormente a través de SQL Server Integration Services
Referencias de interés
MSDN Introducing Data Quality Services
MSDN DQS Knowledge Bases and Domains
1 comment