Problemas y Roles de Calidad de Datos - DQS

Es difícil encontrar una empresa que no tenga algún problema de calidad de datos. Incluso si una aplicación de línea de negocio (LOB) utiliza un modelo relacional adecuado con todas las restricciones, aún esto no garantiza que los datos siempre sean precisos. Los modelos de bases de datos y las restricciones realizan la integridad de datos. La integridad de datos significa que los datos cumplen con las reglas del negocio. La calidad de datos es un término muy estricto; incluso si los datos cumplen con las reglas del negocio, todavía pueden ser erróneos. Por ejemplo, considere una regla de negocio que dice que una columna que contiene enteros representando un porcentaje de descuento puede tomar valores de un dominio de enteros entre 0 y 100. Si la columna contiene un valor de 45 en lugar de 54, este cumple con las reglas de negocio, pero los datos aún no son precisos.

La calidad de datos trata con cuestiones tales como la precisión y problemas similares: ¿Está la información completa? ¿Es confiable? ¿Están los datos disponibles en el momento oportuno? Todos estos son problemas de calidad de datos. Puede resolver problemas de calidad de datos de una manera reactiva, por constantemente perfilar y corregir los datos. También puede resolver problemas de calidad de datos de una manera proactiva. Esto puede ser hecho definiendo los datos más importantes, los datos maestros, y luego implementar una solución de gestión de datos maestros (MDM). La base de datos de solución MDM es entonces un origen autorizado de datos maestros.

La calidad de datos utiliza dos características en la suite de Microsoft SQL Server 2014: Microsoft SQL Server 2014 Data Quality Services (DQS) y Microsoft SQL Server 2014 Master Data Services (MDS). El DQS ayuda a perfilar y corregir los datos, y el MDS es una solución de gestión de datos maestros.

La calidad de datos está indivisiblemente intercalada con la Gestión de Datos Maestros (MDM). El objetivo más importante de una solución MDM es elevar la calidad de los datos maestros. Los problemas de calidad de datos deben ser abordados en cualquier proyecto MDM. Sin embargo, las actividades de calidad de datos, tales como el perfilado de datos, encuentran la causa raíz de la pobreza de los datos, y las mejoras de la calidad pueden ser también independientes de un proyecto MDM. Es posible para una empresa definir las políticas y los procesos de calidad de datos a través de aplicaciones existentes, pero una solución especializada MDM puede mitigar mucho la implementación de estas políticas.

Antes de definir sus actividades de calidad de datos, debe decidir para qué aspectos medirá y mejorará la calidad de sus datos. Las dimensiones de calidad de datos capturan un aspecto específico de la calidad de datos en general. La medida de la calidad de datos, también conocida como perfilado de datos, debería ser una parte integral de la implementación de una solución MDM. Siempre debe obtener una comprensión a fondo de los datos de origen antes de empezar a fusionarlos. También debe medir las mejoras de calidad de datos sobre el tiempo, para entender y explicar el impacto de la solución MDM. Esta post empieza por describir las dimensiones de calidad de datos, explicando los diferentes aspectos de calidad de datos que pueden ser medidos y la mejor manera de medirlos. Entonces trata con actividades de calidad de datos y las personas que ejecutan estas actividades. Aprenderá acerca de los roles específicos de calidad de datos y de gestión de datos maestros.

Dimensiones de Calidad de Datos

Las dimensiones de calidad de datos pueden referirse a valores de datos o a su esquema. La evaluación de la calidad de un modelo relacional o dimensional no puede ser hecha con Data Quality Services. Este capítulo se centra en las dimensiones puras de calidad de datos y de Data Quality Services, aunque en aras de la exhaustividad, las dimensiones de calidad de esquema son también descritas en este post.

No hay un consenso sobre qué dimensiones de calidad de datos deberían ser inspeccionadas. Diferentes herramientas y diferentes libros enumeran diferentes conjuntos de dimensiones. Sin embargo, algunas dimensiones son analizadas con más frecuencia que otras. Esta lección se enfoca en las analizadas con más frecuencia.

Puede medir algunas dimensiones de calidad de datos con herramientas como las consultas Transact-SQL. Las dimensiones medibles son llamadas dimensiones duras. En contraste, algunas dimensiones dependen de la percepción de los usuarios de los datos; éstos se llaman dimensiones suaves. No puede medir las dimensiones suaves directamente; puede medirlas en forma indirecta a través de entrevistas con los usuarios de los datos o de cualquier otro tipo de comunicación con los usuarios. Tenga en cuenta que esta comunicación puede incluir lamentablemente eventos desagradables, como las quejas de los clientes, que son los eventos que desea evitar. Este post describe las dimensiones duras en detalle y toma sólo una visión rápida de las dimensiones suaves y de esquema.

Integridad (Completeness)    

La Integridad es una de las dimensiones más fáciles de medir. Puede empezar a medirlo a un nivel de población. En un supuesto mundo cerrado, se puede afirmar que no hay otros valores excepto los valores actualmente presentes en una tabla relacional, que representan hechos en el mundo real. Si la relación no tiene valores desconocidos (NULLs), la relación está completa desde la perspectiva de la población. En un supuesto mundo abierto, no se puede afirmar la integridad de la población, incluso si su relación no contiene valores desconocidos. Con el fin de evaluar la integridad de una relación en un supuesto mundo abierto, necesita obtener una relación de referencia que contiene toda la población. Cuando se tiene una relación de referencia, se puede definir la integridad como la proporción del número de tuplas presentadas en la relación y el número de tuplas en la relación de referencia. Debido a la privacidad y restricciones regladas, normalmente no es posible adquirir la relación de referencia. Sin embargo, usualmente puede obtener al menos el número de tuplas en una relación de referencia. Por ejemplo, puede obtener fácilmente el número de ciudadanos de un país. Desde un punto de vista técnico, es muy fácil medir la integridad de una relación cuando se tiene el número de tuplas en una relación de referencia.

En un supuesto mundo cerrado en una base de datos relacional, la presencia de NULLs es lo que define la integridad. Se podría medir la integridad de atributo (el número de NULLs en un atributo específico), la integridad de tupla (el número de valores desconocidos de los atributos en una tupla), y la integridad de relación (el número de tuplas con valores de atributos desconocidos en la relación). Por último, también se puede medir la integridad de valor, lo que tiene sentido para las columnas complejas, semi-estructuradas asi como las columnas de tipo de datos XML. En una instancia XML, un elemento completo o un atributo puede estar faltando. Además, los estándares XML también definen un atributo xsi:nil especial como un marcador de posición para los valores faltantes; esto es similar al NULL relacional.

Precisión (Accuracy)

La precisión es una dimensión complicada. Primero, tiene que determinar que es impreciso. La precisión es más estricta que sólo ajustarse a las reglas de negocio; esta última debe cumplir con la integridad de datos. Para los datos que deberían ser únicos, los valores duplicados son imprecisos. Encontrar valores duplicados podría llevarse a cabo con bastante facilidad con consultas simples, o puede ser muy difícil, si tiene que encontrar los duplicados a través de diferentes sistemas. Encontrar otros datos imprecisos puede implicar algún trabajo manual. Con varios algoritmos, puede extraer datos que son sólo potencialmente imprecisos.

Podemos ofrecer algunos consejos sobre cómo aislar los datos imprecisos. Para los valores de datos discretos, puede utilizar la distribución de frecuencias de los valores. Un valor con una frecuencia muy baja es potencialmente incorrecto. Para las cadenas, se puede buscar por distribución de longitud de cadena. Una cadena con una longitud muy atípica es potencialmente incorrecta. Para las cadenas, también puede tratar de encontrar patrones y luego crear la distribución de patrones. Los patrones con baja frecuencia probablemente denotaran valores erróneos. Para los atributos continuos, puede utilizar estadísticas descriptivas. Sólo mirando a los valores mínimos y máximos, se puede fácilmente detectar a los datos potencialmente problemáticos. No importa cómo encuentra los datos imprecisos, puede marcarlo y luego medir el nivel de precisión. Puede medir esto para las columnas y las tablas.

Información

Otra dimensión medible es la información. La Teoría de la Información, es una rama de las matemáticas aplicadas, define la entropía como la cuantificación de la información en un sistema. Puede medir la entropía sobre un nivel de columna y de tabla. Los valores más dispersos que tiene y los de mayor distribución de frecuencia de una columna discreta son igualmente repartidos entre los valores, cuanta más información tenga la columna. La información no es una dimensión directa de calidad de datos; sin embargo, puede decirle si sus datos son adecuados para el análisis o no.

Consistencia

La consistencia mide la equivalencia de la información almacenada en diferentes bases de datos. Puede encontrar muchos datos inconsistentes por comparar los valores con un conjunto predefinido de valores posibles; puede encontrar algunas inconsistencias por comparar los datos entre los sistemas. Puede encontrar algunas inconsistencias manualmente. No importa cómo encuentra las inconsistencias, puede marcarlas y luego medir el nivel de inconsistencia sobre el nivel de columna o de tabla.

Analizar tanto la dimensión de calidad de datos dura como la suave es considerada una buena práctica.

 

Dimensiones Suaves de Calidad de Datos

Puede medir la dimensión suave indirectamente, a través de la interacción con los usuarios. Los cuestionarios, encuestas rápidas, quejas de usuarios, o cualquier otro tipo de comunicación con los usuarios de datos, son sus herramientas para medir la calidad de las dimensiones de datos suaves. La siguiente lista incluye algunas de las dimensiones suaves típicas:

·         Disponibilidad (Timeliness). Esto le indica el grado en que los datos están actualizados y disponibles cuando se necesitan. Siempre hay un cierto retraso entre el cambio en el mundo real y el momento cuando este cambio es ingresado a un sistema. Aunque los datos obsoletos pueden aparecer en cualquier sistema, esta dimensión es especialmente importante para los sitios y aplicaciones web. Un problema común en la web es que los propietarios no actualizan los sitios en una manera oportuna; puede encontrar un montón de información obsoleta en la web.

·         Facilidad de Uso. Esta es una dimensión muy típica que confía en la percepción del usuario. La facilidad de uso depende de la aplicación o de la interfaz de usuario. Además, los usuarios de datos también perciben el uso como complejo porque no están capacitados.

·         Proposito (Intention). ¿Es el dato, el dato correcto para su uso previsto? A veces no tiene los datos exactos que necesita; sin embargo, puede sustituir los datos necesarios con los datos del que tiene información similar. Por ejemplo, puede utilizar los códigos de área telefónica en lugar de los códigos postales para localizar clientes aproximadamente. Aunque los números de teléfono no estaban destinados para el análisis, pueden darle resultados razonables. Un ejemplo de un uso no intencionado inútil es el uso de una columna en una tabla para almacenar la información no relacionada, tal como usar la columna del nombre del producto para almacenar la taxonomía del producto. Este es un uso no intencionado del esquema, que conduce a muchos problemas con la limpieza y la integración de datos.

·         Confianza (Trust). Tiene que preguntar a los usuarios si confían en los datos. Esta es una dimensión muy importante. Si los usuarios no confían en los datos de los sistemas operacionales, crearán sus propias pequeñas, probablemente no estructuradas, bases de datos. La integración de datos maestros de orígenes no estructurados es muy difícil. Si los usuarios no confían en los datos de las aplicaciones analíticas, simplemente dejaran de usarlos.

·         Calidad de Presentación. Esta es otra dimensión que depende de la percepción del usuario. Cuando una aplicación presenta datos, el formato y la apariencia deben apoyar el uso adecuado de la información. En los sistemas operacionales, esta dimensión está estrechamente relacionado con la facilidad de uso de la dimensión y depende mucho de la interfaz de usuario. Por ejemplo, una aplicación puede obligar a los usuarios a introducir fechas manualmente o guiarlos a través de un control de calendario. En los sistemas analíticos, la presentación es probablemente aún más importante. ¿Se muestran los datos en gráficos o en tablas? ¿Cuánta interactividad debería poner en sus reportes? Preguntas como esta y respuestas a estas preguntas pueden tener una gran influencia en el éxito o el fracaso de los sistemas analíticos.

 

Dimensiones Esquema de Calidad de Datos

Una percepción común es que la calidad del esquema no puede ser medida automáticamente. Bueno, esto es cierto para algunas dimensiones; no puede medirlas sin profundizar en un problema del negocio. Sin embargo, es posible encontrar algoritmos y crear procedimientos que ayuden a medir alguna parte de la calidad del esquema. Seguido se lista las dimensiones de calidad de esquema más importantes, con una breve descripción de cómo medirlos, cuando es aplicable.

·         Integridad de Esquema Esto le dice para extender a cual esquema cubre el problema del negocio. No se puede medir esta dimensión sin un análisis profundo del problema de negocio y sus necesidades.

·         Exactitud de Esquema. La exactitud de un modelo se refiere a la representación correcta de los objetos del mundo real en el esquema y la representación correcta de los requerimientos. Por ejemplo, un nombre puede ser modelado como una entidad con una relación uno-a-uno a la entidad Customers o como un atributo de la entidad Customers. Por supuesto, esta última es la correcta. El nombre no puede ser identificado únicamente, por lo que no es una entidad. Este es el problema con los intentos de representar correctamente los objetos del mundo real. Un ejemplo de inexactitud que tiene que ver con los requerimientos es el siguiente modelo de departamentos y directores. Si un requerimiento dice que un director puede gestionar un solo departamento y que cada departamento tiene un único director, entonces, la relación entre los directores y los departamentos debe ser uno a uno. Modelar esta relación como de muchos a muchos sería un esquema incorrecto. Puede medir esta dimensión manualmente, investigando los requerimientos del negocio y las definiciones de objetos y su representación en el esquema.

·         Documentación Esto le indica si el esquema está debidamente documentado. Los diagramas de esquema, como los diagramas entidad-relación, siempre deben ser parte de la documentación. Además, todas las reglas de negocio que no pueden ser  representadas en un diagrama, deberían ser documentadas en formato de texto. En resumen, debe tener la documentación completa de un esquema conceptual. Puede comprobar la calidad de esta dimensión manualmente, con una vista general de la documentación del esquema.

·         Conformidad con los modelos teóricos ¿Está el esquema de base de datos para aplicaciones transaccionales en un esquema relacional especializado y normalizado adecuadamente, y el esquema para un data warehouse consta de esquemas de Estrella? Esta dimensión debe ser parcialmente medida manualmente, con una visión general del modelo de datos. Sin embargo, se puede encontrar algunas áreas problemáticas en el esquema proceduralmente. Por ejemplo, puede comprobar las correlaciones entre los atributos no-llave; los atributos con muy alta correlación en una tabla pueden indicar que el esquema no está normalizado, o al menos no lo está en la tercera forma normal. Además, muchos NULLs pueden indicar que no hay suficiente especialización, es decir, subtipos en el esquema. Esto es especialmente cierto si algunos valores de un atributo siempre conducen a NULLs en otro atributo. Puede medir esto con consultas de base de datos.

·         Minimalización. La abstracción es una técnica de modelado muy importante. Esto significa que debería tener solo objetos en un modelo que sean importantes para los problemas del negocio que está resolviendo. El número de entidades de esquema debería ser mínimo y no debería incluir objetos que no son pertinentes al problema del esquema que está resolviendo. Una vez más, puede medir esta dimensión con una visión general manual y la comparación a los requerimientos del negocio.

 

Actividades y Roles de Calidad de Datos

Los proyectos de calidad de datos son muy intensivos en términos de recursos necesarios. Con el fin de ejecutar un proyecto exitosamente, tiene que mostrar los posibles beneficios a los principales interesados. En primer lugar, es necesario entender las necesidades del negocio. Puede utilizar entrevistas, descripciones de los organigramas, análisis de las prácticas existentes en una empresa, y otras fuentes de información. Debe priorizar los problemas del negocio y hacer un plan de proyecto claro. Para que un proyecto sea exitoso, es importante empezar con un área de negocio que sea muy critico para los interesados o con un problema de negocio que sea bastante simple de resolver. Siempre debe implementar proyectos de calidad de datos paso a paso.

Antes de empezar cualquier proyecto de calidad de datos o MDM, tiene que entender los orígenes y destinos de los datos problemáticos. Por lo tanto, las actividades de calidad de datos deben incluir una visión general. Debe tener una visión general amplia de todos los esquemas de las bases de datos que se refieren a los datos del problema. Deberia entrevistar a los expertos de dominio y usuarios de datos. Esto es especialmente importante para obtener una comprensión de la calidad de las dimensiones de esquema. Además, después de este paso, debe también tener un claro entendimiento de la tecnología que la empresa está utilizando. Si es necesario, puede necesitar planificar el incluir expertos en tecnología adecuados en el proyecto. Durante la visión general de los datos, también debe centrarse en el ciclo de vida de los datos de manera que pueda comprender los períodos de retención y similares.

El siguiente paso es la evaluación de la calidad de datos. Puede evaluar las dimensiones duras con el análisis procedural de los datos, también conocido como perfilado de datos. Hay muchas herramientas diferentes para el perfilado de datos. Debe aprovechar todo el conocimiento que tiene y todas las herramientas disponibles para esta tarea. Deberia medir las dimensiones suaves de calidad de datos en este paso también. Puede obtener una gran cantidad de conocimiento sobre el estado de la empresa por la comparación de las dimensiones duras y suaves. Si su evaluación de las dimensiones duras es mala, pero obtiene buenas evaluaciones de las dimensiones suaves, entonces la compañía no se dará cuenta de que tiene problemas con los datos. En tal caso, la valoración adicional de los potenciales daños causados​​ por los malos datos puede ayudar a los principales interesados a comprender los problemas de calidad de datos. Si ambas dimensiones suaves y duras son evaluadas bajas, entonces la empresa está lista para un proyecto de calidad de datos y/o MDM. Si las dimensiones duras obtienen buenas evaluaciones, mientras que las dimensiones suaves obtienen malas evaluaciones, esto significa que por alguna razón los expertos de dominio y los usuarios no confían en los datos. Por lo general, esta situación se debe a un sistema anterior, una versión anterior del sistema, o la falta de educación. Si ambas dimensiones duras y blandas obtienen buenas evaluaciones, la empresa no necesita un proyecto de calidad de datos especial; sin embargo, la empresa aún podría decidir iniciar un proyecto MDM con el fin de minimizar los gastos con el mantenimiento de datos maestros.

Después de terminar con la evaluación de los datos, puede volver a evaluar el impacto en el negocio de los datos de calidad baja. Debe reunirse de nuevo con los principales interesados a fin de revisar las prioridades y elaborar la parte de las mejoras del plan del proyecto en detalle.

Antes de que pueda empezar a mejorar la calidad de los datos, es necesario encontrar las causas raíces de los malos datos. Encontrar las causas raíces puede reducir sustancialmente el volumen de trabajo necesario para la mejora de la calidad de datos. Para encontrar las causas raíces, puede utilizar el método de los "cinco porqués" introducido por Sakichi Toyoda y utilizado primero en la Toyota Motor Corporation. Con este método, simplemente pregunta "por qué" cinco veces. Por ejemplo, supongamos que el problema es con los registros duplicados para los clientes. Aplicar el enfoque de los "cinco porqués" para encontrar la causa raíz, luce como esto:

·         Puede preguntar por qué hay registros duplicados. Una respuesta podría ser, debido a que los operadores con frecuencia insertan nuevos registros de clientes en lugar de utilizar los ya existentes.

·         Debe preguntar el segundo por qué: ¿Por qué los operadores crean nuevos registros para los clientes existentes? La respuesta podría ser, debido a que los operadores no buscan los registros existentes de un cliente.

·         A continuación, debe preguntar el tercer por qué: ¿Por qué no buscan? La respuesta podría ser, debido a que la búsqueda tarda mucho tiempo.

·         El siguiente por qué es, por supuesto, ¿Por qué tarda mucho tiempo? La respuesta podría ser, porque es muy difícil buscar los clientes existentes.

·         Ahora la pregunta final, el quinto por qué: ¿Por qué la búsqueda es tan difícil? La respuesta podría ser, debido a que el operador puede buscar sólo valores exactos, no por cadenas aproximadas, y el operador no tiene un nombre, una dirección o un número de teléfono exacto de un cliente en la memoria. Ha encontrado la causa raíz de la duplicación para este ejemplo, el problema es con la aplicación, específicamente con la interface de usuario. Ahora ya sabe dónde poner el esfuerzo con el fin de reducir el número de duplicados.

Por supuesto, el método de los "cinco porqués" no es la única técnica para la búsqueda de las causas raíces. También puede hacer un seguimiento de una pieza de información a través de su ciclo de vida. Por su seguimiento, puede fácilmente observar el momento en que se convierte en inexacta. Puede encontrar causas raíces para algunos problemas procedurales también. Por ejemplo, puede encontrar que los NULLs están en el sistema debido a la ausencia de subtipos con consultas. No importa cómo encuentres las causas raíces, tiene que utilizar esta información para preparar un plan de mejora detallado.

Un plan de mejora debería incluir dos partes: la corrección del dato existente y, aún más importante, la prevención de errores futuros. Si se centra en la corrección de los datos existentes solamente, tendrá que repetir la parte de corrección de las actividades de calidad de datos regularmente. Por supuesto, necesita dedicar algún tiempo a corregir los datos existentes; sin embargo, no hay que olvidar la parte de prevención. Cuando tiene las dos partes del plan de mejora, puede empezar a implementarla.

La implementación de medidas correctivas implica métodos de limpieza automática y manual. Los métodos de limpieza automática pueden incluir sus propios procedimientos y consultas. Si tiene conocimiento de la lógica para corregir los datos, debe utilizarla. Puede resolver problemas de consistencia por definir una sola manera de representar los datos en todos los sistemas y, entonces, reemplazar las representaciones inconsistentes con las recientemente definidas. Por ejemplo, si el género está representado en algún sistema con los números 1 y 2, pero han decidido que deben estar representados con las letras F y M, puede sustituir los números por letras en una sola sentencia de actualización. Para la de-duplicación y la fusión de diferentes orígenes, puede utilizar algoritmos de coincidencia de cadenas. Para corregir direcciones, puede utilizar herramientas de validación y de limpieza que ya existen en el mercado y utilizar algunos registros de direcciones válidas. Sin embargo, debería siempre estar preparado para el hecho de que parte de la limpieza de datos debe ser realizada manualmente.

Prevenir nuevas inserciones de datos inexactos implica diferentes técnicas también. La más importante es la implementación de una solución MDM. Para una solución MDM, necesita una aplicación MDM. SQL Server Master Data Services es un ejemplo de la herramienta que podría utilizar.

Además de permitir el almacenamiento central de datos maestros y sus metadatos, la aplicación MDM tiene que soportar flujos de trabajo de stewardship de datos explícitos, control de versiones, auditoría, y gobierno de datos  El gobierno de datos se refiere a las actividades realizadas para mejorar y mantener la calidad de los datos; los stewards de datos son las personas responsables de estas actividades. Para que un proyecto de calidad de datos y/o gestión de datos maestros sea exitoso, los roles para stewardship de datos explícitos deben ser definidos. Además de la solución de calidad de datos o MDM, también debería enfocarse en los sistemas de origen. Es muy poco probable que su solución siempre cubra todas las posibles entidades maestras con todos sus atributos. Por lo tanto, parte de los datos todavía serán mantenidos en el origen, en aplicaciones operacionales. Tiene que aplicar los modelos de datos apropiados, restricciones y buenas interfaces de usuario siempre que sea posible.

Después de haber implementado las soluciones correctivas y preventivas de calidad de datos, debería medir cómo se realizan. Incluso mejor, debería preparar la infraestructura de mejora de antemano, antes de comenzar a implementar sus soluciones. Midiendo las mejoras, se puede mostrar fácilmente el valor de las soluciones a los principales interesados. Además, este enfoque le permite un cierto grado de control sobre su trabajo, en caso de que su mejora falle y conduzca a problemas aún peores de calidad de datos. Puede medir las dimensiones suaves realizando entrevistas continuas con los usuarios finales y expertos de dominio. Puede guardar los resultados de las entrevistas en un data warehouse de calidad de datos especial para rastrear la calidad de datos a través del tiempo. Para las dimensiones duras, puede medirlas automáticamente en un calendario predefinido, y de nuevo almacenar los resultados en el data warehouse de calidad de datos.

Aunque esto no fue mencionado como un paso de la actividad de calidad de datos explicito, es muy importante comunicar acciones y resultados a través del proyecto. Mientras más comunicación tenga, mejor. Los expertos de dominio siempre pueden ayudarle con sus conocimientos. Los profesionales de TI y los usuarios finales ponen mucho más esfuerzo en ayudar a un proyecto a alcanzar el éxito si están involucrados, si consideran que el proyecto es su proyecto. Los principales interesados ​​siempre deben saber cómo avanza el proyecto y deben estar involucrados en todas las etapas de decisión.