La calidad de los datos en el repositorio es un requisito previo importante para obtener información valiosa. La mala calidad conduce a una reacción en cadena negativa a largo plazo.
Primero, se pierde la confianza en la información proporcionada. La gente está comenzando a usar menos las aplicaciones de Business Intelligence, el potencial de las aplicaciones permanece sin reclamar.
Como resultado, se ponen en duda nuevas inversiones en el proyecto analítico.
Responsabilidad por la calidad de los datos.
El aspecto asociado con la mejora de la calidad de los datos es un gran problema en los proyectos de BI. Sin embargo, no es privilegio de solo especialistas técnicos.
La calidad de los datos también está influenciada por aspectos como
Cultura corporativa- ¿Están los propios trabajadores interesados en producir buena calidad?
- Si no, ¿por qué? Puede haber un conflicto de intereses.
- ¿Quizás hay reglas corporativas que definen a los responsables de la calidad?
Los procesos- ¿Qué datos se crean al final de estas cadenas?
- Tal vez los sistemas operativos están configurados para que necesite "salir" para reflejar esta o aquella situación en la realidad.
- ¿Los sistemas operativos realizan validación y verificación de datos ellos mismos?
Todos en la organización son responsables de la calidad de los datos en los sistemas de informes.
Definición y significado
La calidad es una satisfacción confirmada de las expectativas del cliente.
Pero la calidad de los datos no contiene una definición. Siempre refleja el contexto de uso. El almacén de datos y el sistema de BI tienen diferentes propósitos que el sistema operativo, de donde se toman los datos.
Por ejemplo, en un sistema operativo, un atributo de cliente puede no ser un campo obligatorio. En el repositorio, este atributo se puede usar como una dimensión y su llenado es obligatorio. Lo que, a su vez, introduce la necesidad de rellenar con valores predeterminados.
Los requisitos del almacén de datos cambian constantemente y generalmente son más altos que los sistemas operativos. Pero puede ser al revés, cuando no es necesario almacenar información detallada del sistema operativo en el almacenamiento.
Para que la calidad de los datos sea medible, se deben describir sus estándares. Las personas que usan información y números para su trabajo deben participar en el proceso de descripción. El resultado de esta participación puede ser una regla, tras la cual, de un vistazo, puede decir si hay un error o no. Esta regla debe emitirse en forma de secuencia de comandos / código para su posterior verificación.
Mejora de la calidad de los datos.
Es imposible limpiar y corregir todos los errores hipotéticos en el proceso de carga de datos en el repositorio. La buena calidad de los datos solo se puede lograr a través del trabajo cercano de todos los participantes. Las personas que ingresan datos en los sistemas operativos deben averiguar qué acciones conducen a errores.
La calidad de los datos es un proceso. Desafortunadamente, en muchas organizaciones no existe una estrategia para la mejora continua. Muchos se limitan solo a guardar datos y no utilizan todo el potencial de los sistemas analíticos. Como regla general, al desarrollar almacenes de datos, el 70-80% del presupuesto se gasta en integración de datos. El proceso de control y mejora permanece inacabado, en todo caso.
Las herramientas
El uso de herramientas de software puede ayudar en el proceso de automatización de la mejora y el monitoreo de la calidad de los datos. Por ejemplo, pueden automatizar completamente la verificación técnica de las estructuras de almacenamiento: formato de campos, presencia de valores predeterminados, cumplimiento de los requisitos de los nombres de campo de la tabla.
Puede ser más difícil verificar el contenido. A medida que cambian los requisitos de almacenamiento, la interpretación de los datos puede cambiar. La herramienta en sí misma puede convertirse en un gran proyecto que requiere soporte.
Propina
Las bases de datos relacionales, en las que generalmente se diseñan los repositorios, tienen una gran oportunidad para crear vistas (vistas). Se pueden usar para verificar rápidamente los datos si conoce las características del contenido. Cada caso de encontrar un error o problema en los datos se puede registrar en forma de una consulta a la base de datos.
Por lo tanto, se formará una base de conocimiento de contenido. Por supuesto, tales solicitudes deberían ser rápidas. Como regla general, el mantenimiento de vistas requiere menos tiempo humano que las herramientas organizadas en tablas. La vista siempre está lista para mostrar el resultado de la verificación.
En el caso de informes importantes, la vista puede contener una columna con el destinatario. Tiene sentido usar las mismas herramientas de BI para informar sobre el estado de la calidad de los datos en el repositorio.
Ejemplo
La solicitud está escrita para la base de datos Oracle. En este ejemplo, las pruebas devuelven un valor numérico que se puede interpretar según sea necesario. Los valores T_MIN y T_MAX se pueden usar para ajustar el grado de alarma. El campo REPORT se utilizó una vez como mensaje en un producto ETL comercial que no sabía cómo enviar correos electrónicos de manera adecuada, por lo que rpad es una "muleta".
En el caso de una tabla grande, puede agregar, por ejemplo, AND ROWNUM <= 10, es decir Si hay 10 errores, esto es suficiente para la alarma.
CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS SELECT CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX THEN 'OK' ELSE 'ERROR' END AS RESULT, DESCRIPTION, TABLE_NAME, OUTPUT, T_MIN, T_MAX, rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT FROM (
La publicación utilizó materiales de libros.
Ronald Bachmann, Dr. Guido kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird