«Estos datos no son de fiar» es probablemente la frase que más veces he escuchado en reuniones de datos, casi siempre sin que nadie explique por qué no lo son. Collibra aborda esto con dimensiones de calidad concretas y reglas que se pueden monitorizar, no con opiniones.
Qué son las dimensiones de calidad de datos
Las dimensiones de calidad de datos son las categorías con las que se mide, de forma objetiva, si un dato es «bueno» o no. Collibra identifica seis dimensiones principales, cada una respondiendo a una pregunta distinta sobre el dato:
| Dimensión | Qué mide |
|---|---|
| Completitud | Si existe la información mínima imprescindible para que el dato sea útil en una decisión. |
| Exactitud | Si el dato representa fielmente la realidad y puede verificarse contra una fuente fiable. |
| Consistencia | Si la misma información, almacenada o usada en varios sistemas, coincide entre sí. |
| Validez | Si los valores de un atributo se ajustan al dominio o al requisito esperado (formato, rango, catálogo de valores). |
| Unicidad | Si cada registro aparece una única vez, sin duplicados ni solapamientos. |
| Integridad | Si los atributos se mantienen correctos a medida que el dato se almacena y se usa en sistemas distintos. |
Ninguna de estas dimensiones sirve de mucho por separado: un dato puede ser perfectamente «válido» (con el formato correcto) y a la vez completamente «inexacto» si nadie lo actualiza. Por eso lo interesante no es memorizar la lista, sino decidir qué dimensiones importan más para cada activo de datos concreto.
De la dimensión a la regla
Collibra convierte estas dimensiones en algo accionable a través de su módulo de Data Quality and Observability, que permite definir reglas de calidad sobre los activos catalogados y monitorizar su cumplimiento de forma continua, en lugar de hacer auditorías puntuales una vez al trimestre.
En la práctica, esto significa poder tomar una dimensión —por ejemplo, completitud— y traducirla en una regla concreta: «el campo email de la tabla de clientes no puede estar vacío en más del 2% de los registros». Cuando esa regla se incumple, la plataforma lo detecta y lo expone junto al propio activo en el catálogo, de modo que cualquiera que vaya a usar esa tabla vea, antes de trabajar con ella, si su calidad está por debajo del umbral aceptable.
Esta es, para mí, la diferencia real entre «tener un diccionario de datos» y «tener gobierno de datos»: no basta con documentar qué significa un campo, hay que poder demostrar, con métricas, si ese campo cumple lo que promete.
Por qué esto conecta con el resto del gobierno de datos
La calidad de datos no vive aislada del resto de piezas que hemos visto en artículos anteriores. Una regla de calidad se aplica sobre un activo que pertenece a un dominio, ese activo probablemente está enlazado a un término del Business Glossary, y cualquier cambio relevante en una regla de calidad —por ejemplo, subir el umbral de tolerancia a valores nulos— puede (y debería) pasar por un workflow de aprobación, exactamente igual que la aprobación de un término de negocio.
Esto refuerza una idea que se repite en toda la plataforma: comunidades, dominios, glosario, workflows y calidad de datos no son módulos independientes, sino piezas de un mismo modelo operativo de gobierno.
- No definas reglas de calidad para todos los campos de golpe: prioriza los activos que ya están certificados o enlazados a términos de negocio críticos.
- Combina dimensiones: una tabla puede ser «completa» y aun así «inconsistente» si dos sistemas la alimentan con criterios distintos.
- Haz visible el resultado de las reglas de calidad directamente en el catálogo, no en un informe aparte que nadie consulta.
En el último artículo de esta serie vemos cómo encaja todo esto con el Data Catalog de Collibra y, de paso, cómo convive un catálogo de gobierno corporativo con el catálogo de una capa de virtualización de datos como Denodo.
¿Quieres ver cómo se organizan y monitorizan los ciclos de aprobación de reglas y políticas de gobierno?
Leer sobre los workflows de Collibra