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

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.

Deja un comentario


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