Categorías
Donaciones

Todo el contenido es gratuito y en beneficio de la comunidad. Puedes reconocer el esfuerzo con una donación si lo deseas.

Inserte aquí su publicidad

Archivo de la categoría ‘Calidad de datos’

Hoy surgió esta necesidad. Trabajando en un conjunto de funciones de búsqueda difusa, pero así online (no en modo batch, para eso ya tenemos DQS), vimos que la forma en la que están implementados los algoritmos típicos, como Jaro-Winkler o Jaccard, en las funciones de Master Data Service era especialmente eficiente. Así, haciendo uso de la función “mdq.Similarity” se obtiene una búsqueda para usar en un procedimiento almacenado con un resultado bastante apañado. El problemilla estaba en querer usarlo en una instancia sin MDS instalado, ni ganas de instalarlo, ya que siendo SQL Server 2008 R2, aun siendo factible, no es especialmente fácil de mantener.

Empleamos la vía rápida. Tomar un script del assembly (de los de botón derecho + create script) y de la función de una instancia 2012 y crearlo en la instancia 2008 R2, y hete aquí que funciona. ¿Soportado? No creo. ¿Buena idea? No lo sé aún. Pero el caso es que funciona y, bueno, habrá que probar a ver cómo va.

CREATE ASSEMBLY [Microsoft.MasterDataServices.DataQuality]
FROM 0x4D5A90000300000004000000FFF ....--> lo corto por razones estéticas
WITH PERMISSION_SET = SAFE

GO

--Cambiar el esquema de "mdq" a otro
CREATE FUNCTION [dbo].[Similarity](@input1 [nvarchar](4000), @input2 [nvarchar](4000), @method [tinyint], @containmentBias [float], @minScoreHint [float])
RETURNS [float] WITH EXECUTE AS CALLER, RETURNS NULL ON NULL INPUT
AS 
EXTERNAL NAME [Microsoft.MasterDataServices.DataQuality].[Microsoft.MasterDataServices.DataQuality.SqlClr].[Similarity]

GO

Un link con más info sobre estas funciones de búsqueda difusa en MDS: http://sqlblog.com/blogs/jamie_thomson/archive/2009/11/09/fuzzy-logic-and-regex-come-to-t-sql-in-sql-server-2008-r2-available-now.aspx

Continuando con esta serie de post (ver 1 y 2), quisiera tratar aquí un punto que a mí personalmente me echa bastante para atrás en general, pero que no quita para que sea una cuestión de enorme importancia para la calidad de datos, y estos son la definición y mantenimiento de diccionarios de datos.

Puestos a diseñar un proyecto de calidad de datos, la definición de los metadatos serían eso, los planos sobre los que luego se edificará lo demás. Lo que pasa es que es una tarea árdua y notablemente desagradecida, ya que unificar tipos de datos entre modelos que serán heterogéneos, que llevan años de una determinada forma y que hay que cambiar, que requieren de la intervención de otros equipos no directamente implicados en el proyecto (pero que mantienen esta o aquella aplicación donde se emplean o recogen los datos) para que, después de todo el esfuerzo, el entregable sea ninguno, pues oye, no es algo como para entusiasmarse si a uno le encomiendan pilotar este cometido. Por el contrario, una vez que existe, es algo de un gran valor que facilita y agiliza mucho todos los desarrollos posteriores, donde ya no habrá que pensar tanto a la hora de modelar, y además es muy posible que por el camino se haya dotado a la organización de un conjunto de servicios que se ocupen de unificar, por ejemplo, el alta de un usuario, y que ya contendrán todas las verificaciones de calidad de datos que queremos imponer. Y eso por mencionar aspectos ajenos a la propia calidad de la información en sí. Sin un diccionario de datos, la definición, implantación y seguimiento del éxito de las políticas que se van implantando es mucho más complicado.

El problema es, por tanto, quién le pone el cascabel al gato. Si te ha tocado en suerte, bueno, herramientas hay. Tenemos Master Data Services, que es la que viene de serie con SQL Server desde hace un par de versiones, pero igual que esa otro montón de ellas, ya que es un nicho de negocio que viene de antaño y que ha dado lugar a que numerosas compañías traten de cubrirlo. Pero no te engañes, son herramientas, no resolverán ninguno de los problemas importantes que deben afrontarse, que son, por citar algunos:

  1. Definir las características de cada atributo de cada entidad existente.
  2. Asignar cada campo de cada tabla a uno de esos atributos definidos.
  3. Implantar el diccionario en los nuevos desarrollos (fácil) y en los existentes (muuuuuy difícil).
  4. Mantener actualizado el diccionario.

Las herramientas te dan las vías de actualización, mantenimiento, incluso te pueden ayudar a propagar los cambios. Y eso sí, una vez que existe, todo es mucho más llevadero.

Como referencia final, dejo un par de enlaces más sobre MDS:

  1. Blog del equipo de desarrollo: http://blogs.msdn.com/b/mds/
  2. Zona de aprendizaje: http://msdn.microsoft.com/en-us/sqlserver/ff943581.aspx

Proseguimos esta serie de apuntes, o reflexiones más bien, acerca de este tema tan amplio. Me centraré en esta entrada en una circunstancia bastante curiosa por la que estamos atravesando en el proyecto de estas características que ahora mismo tengo entre manos, y que entiendo que es un punto común a cualquier proyecto similar.

Lo habitual cuando se inician estos trabajos, como ya indicaba en la anterior entrada, es hacerse una composición de lugar. Eso consiste en hacer unos perfilados, unos simples recuentos que nos permitan saber en qué punto nos encontramos. Eso conduce a sentenciar “Tenemos el teléfono del 75% de nuestros clientes”. Pero vaya, eso no es del todo correcto. Dentro de esos datos de contacto habrá un gran cúmulo de datos que no sean válidos, sino que se rellenaron sin cabeza ninguna para que el formulario dejara grabar el resto de las informaciones. A lo mejor, alguno habrá que piense que colocando un asterisco junto al nombre de un datos en una pantalla ya sólo con eso conseguimos que el usuario introduzca ahí datos fiables y de garantías. Pero no, nada más lejos de la realidad. Con eso sólo consigues que ponga algo ahí, no que eso sea correcto. Y es más, prueba a pedirlos dos veces, verás qué grandes resultados obtienes.

Me estoy refiriendo a que antes de nada, hay que sacar la basura. Para ello, triste es decirlo, hay que limpiar de datos “bote” nuestras bases de datos. Su detección es bastante empírica, pero bastante simple, incluso con T-SQL (yo recomendaría el uso de Data Profiling Task and Tools, de SSIS http://msdn.microsoft.com/es-es/library/bb895310.aspx), para ver si tenemos teléfonos que aparecen en una docena de clientes distintos y sin relación aparente. Pero ha de dar lugar a algo que será muy importante a lo largo de la vida del proyecto: el catálogo de datos no válidos, listas negras o como queramos llamarlo. Son teléfonos, emails, DNIs, e incluso nombres y apellidos que tenemos que almacenar para no tratarlos. Así, teléfonos como el “666 666 666”, emails como “a@a.es” y nombres como “Pepito Pérez” aparecerán con frecuencia referenciando muchas entradas. Hay que limpiarlos y anotarlos en la lista. Con esa lista luego se pueden hacer cosas como una base de conocimiento para DQS, eso está claro, pero también, comprobar que el dato no esté ahí en el proceso de alta de un nuevo cliente, y que si alguno quiere registrarse en tu web como “Pepito Pérez” se lo tenga que currar un pelín más.

Lo malo de esto es que el ratio de datos bajará, lo que quizá no agrade al jefe, que fácilmente podría argumentar, vaya, teníamos el 75% de teléfonos, y ahora tenemos sólo el 60%”. La cuestión es que nunca se tuvo ese porcentaje. De hecho, si se hizo el estudio con habilidad, ya debieron filtrarse esos casos, lo que pasa es que no siempre es tan sencillo percatarse.

Además de una limpieza que mejora la calidad, un efecto también muy deseable es que consigues huecos para completar con datos de verdad, y que los datos dummy estaban ocupando sin sentido. Si bien, insisto, esto a barridos no se arregla, una de las mayores dificultades para la depuración es lo que obliga a discernir, dados dos datos, elegir uno de ellos como el bueno. Si podemos facilitar la tarea haciendo unas discriminaciones por mera frecuencia, ya solo con eso habremos ahorrado la revisión de muchos registros y reducido el coste de la tarea de depuración manual en la que siempre han de acabar estos procesos de calidad.

Pero a eso ya llegaremos.

Por el foro y por mi propio trabajo, vengo notando que últimamente está cogiendo cada vez más fuerza la cuestión de la calidad de los datos que se manejan. Inicio aquí una serie de post sobre este tema, creo también una categoría dentro del blog para agruparlos. No es que sea un experto en la materia. He realizado y participo actualmente en este tipo de proyectos, aunque de hecho, pido que me los hagan más que implementarlos yo. Pero en ese camino de perfeccionamiento creo que puedo aportar los errores que cometa para que los que vengan detrás… Los repitan a pesar de todo. Y por eso justamente empezaré, los errores que he visto y sigo viendo al afrontar la cuestión.

Al menos a mí, me llama la atención en contraposición a otro gran tema del momento (no es que venga de ahora), como Big Data. Esto es,  por un lado lo acaparo todo, me vale todo para ser tratado, si está estructurado mejor, si no, me da lo mismo, que ya me ocupo yo. Y por otro, vaya, que tengo dos veces un señor (o lo parece), de otro tengo su email, pero que es “a@a.es” y de otros tres no tengo ni siquiera eso.

Obviamente, no es de extrañar que si no se es riguroso con la toma de datos, el resultado no puede tener una calidad adecuada. Más grave es cuando los datos que sí se pretende que sean estructurados presentan lagunas más que notables, inconsistencias, huecos, etc. Y esto teniendo en cuenta que son los datos personales de la gente que una vez adquirió tus productos, o que te los regaló para una acción concreta. Cuando más en boga está lo relacionado con la conservación de clientes frente la obtención de los nuevos, resulta que ni siquiera es posible establecer una comunicación con un cliente porque no sabes su teléfono. No nos rasguemos las vestiduras, somos clientes de datos muchas más veces que poseedores de los datos de los demás y, en general, no le prestamos especial atención a ello, con lo que la tarea de mantener una base de datos de calidad y actualizada es muy compleja.

Me contaron una anécdota sucedida con los datos de contacto del colegio de los niños, que lo ilustra bien a las claras. Hubo que realizar un cambio en las cuentas bancarias donde se domiciliaban los pagos del comedor (cuestiones de fusiones y desaparición de cajas de ahorro). La dirección del colegio tenía que comunicárselo a los papás y recibir una respuesta, no es lo mismo que hacer un comunicado o publicar un anuncio, y recurrió a las bases de datos que se recopilan con el alta inicial del alumno, cuando éste entra al colegio. Son unos pocos años los que han transcurrido y lo que allí se encontró fue bastante desolador, a la par que normal. Descartado el envío postal, ya que se requería respuesta, quedaban los emails y los teléfonos. Los emails, no valía ni la décima parte. De los que había, una gran parte pertenecían a cuentas de correo del trabajo. Aunque yo no lo entienda, es mucha la gente que emplea la cuenta de correo electrónico profesional para cuestiones personales. Y claro, ya no es sólo que haya mucha gente que haya perdido su trabajo, a eso hay que sumarle la gente que ha cambiado de empresa y la que su empresa ha cambiado, no ya de nombre, sino de dominio. Hasta “hotmail” es ahora “outlook”. Lo de los teléfonos sí estaban algo mejor, y bien de forma directa (ojo, también ayuda que pidan tres, el del papá, la mamá y el fijo de casa) o indirecta, pero seguían teniendo un buen montón de niños a los que  hubo que enviar para casa con una notita en la bolsa del desayuno.

Si en algo como el colegio de tus hijos se es descuidado a la hora de mantener al día los datos de contacto, por si te tienen que avisar de alguna cosa poco importante, como que tu hijo está enfermo o ha sufrido un accidente , ¿qué se puede esperar de… Todo lo demás? Así que primer error: pensar que los datos están bien o que están bien ahora.

Donde se podría observar un pantano de desesperación, y que yo veo como un nicho de negocio con mucho recorrido, es donde entra el siguiente punto en el catálogo de confusiones. Como el que confunde la parte con el todo, he tenido que escuchar ya muchas veces que el responsable de la base de datos es el departamento de IT. Y sí, de la base sí, pero de los datos es responsable el conjunto de la compañía. En otras palabras, un adecuado mantra, a barridos no se arregla. Es una cuestión transversal que implica a un gran número de áreas, que pasa primeramente por la definición de unas políticas, de una revisión continua, de medir el impacto de las medidas que se tomen para ver si se va por el buen camino.

De aquí se desprende otro error común. Llegado el momento, se decide “externalizar” y se contrata a una empresa especializada en estas lides para que haga un trabajo de depuración de la información. Suponiendo que ese trabajo se haga bien (algo que yo no he tenido la suerte de vivir, no digo que sea imposible), el que lo contrata piensa que, una vez hecho ese proyecto nuestra base de datos estará inmaculada hasta el fin de los tiempos. Craso error: la calidad de datos es una tarea continua, no puntual. Como decía en el párrafo anterior, a barridos no se arregla, y estas acciones puntuales son eso, un barrido, que podrá suponer un punto de inflexión (aunque sólo sea por el escarmiento de la factura del trabajo externalizado), pero no una solución.

Y aquí finalizo este primer post sobre este tema, vendrán más, porque da para mucho más.

 


Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies