Las 6 dimensiones de la calidad de datos, explicadas

Completitud, unicidad, validez, consistencia, exactitud y actualidad — qué significa cada dimensión, un ejemplo de incumplimiento y la comprobación que lo detecta.

2026-09-10 · 9 min read

Las seis dimensiones de la calidad de datos son completitud, unicidad, validez, consistencia, exactitud y actualidad. Cada una nombra una forma distinta en la que los datos pueden estar mal y, juntas, forman el marco estándar para describir, medir y reportar la salud de un dataset. Una dimensión no es una comprobación: es una categoría de comprobaciones, y eso es justo lo que la hace útil. Una sola regla que falla te dice que una columna está rota, mientras que la cobertura por dimensión te dice si siquiera estás vigilando los tipos de fallo adecuados.

El marco procede de la literatura de gestión de datos (DAMA-DMBOK y el documento de dimensiones de DAMA UK son las referencias habituales) y está lo bastante asentado como para que un informe de cobertura signifique aproximadamente lo mismo entre equipos y herramientas. Algunas taxonomías renombran alguna dimensión —conformidad en lugar de validez, frescura en lugar de actualidad— pero las seis de abajo son el conjunto de trabajo.

Resumen

Dimensión	Pregunta que responde	Comprobación de ejemplo
Completitud	¿Están realmente ahí los datos que esperamos?	`nullCount` en columnas obligatorias = 0
Unicidad	¿Aparece cada cosa del mundo real exactamente una vez?	`duplicateCount` sobre la clave de negocio = 0
Validez	¿Cumple cada valor su formato o su conjunto permitido?	`validValues`, `regex`, `between`
Consistencia	¿Concuerdan entre sí los valores relacionados?	`referentialIntegrity`, SQL entre campos
Exactitud	¿Reflejan los valores correctamente el mundo real?	Conciliación contra una fuente de la verdad
Actualidad	¿Son los datos lo bastante recientes para resultar útiles?	`freshness` sobre la marca de tiempo de carga

1. Completitud

Definición. La completitud mide si están presentes todos los datos que deberían estarlo: a nivel de valor (sin nulos en campos obligatorios), a nivel de registro (sin filas ausentes) y a nivel de dataset (sin particiones ausentes).

Ejemplo de incumplimiento. Una carga nocturna falla a mitad de camino. Cada fila que aterrizó es perfecta por separado, pero customer_id es nulo en el 4 % de los pedidos porque el join se ejecutó contra una tabla de clientes que aún no se había refrescado. No se lanzó ningún error; las filas simplemente llevan nulos.

La comprobación. Cuenta los nulos de cada columna obligatoria y compara el número de filas con un mínimo esperado:

SELECT
    count(*)                                      AS row_count,
    count(*) FILTER (WHERE customer_id IS NULL)   AS missing_customer,
    count(*) FILTER (WHERE order_id IS NULL)      AS missing_order_id
FROM sales.orders
WHERE created_at >= current_date - 1;

Las comprobaciones de recuento de filas son la mitad infravalorada de la completitud: una comprobación de nulos sobre una tabla que no recibió ninguna fila aprueba con nota.

2. Unicidad

Definición. La unicidad mide si cada entidad del mundo real está representada exactamente una vez. Abarca tanto los duplicados exactos de una clave como los casi duplicados que representan la misma entidad con valores distintos.

Ejemplo de incumplimiento. Se vuelve a lanzar un backfill sin truncar antes, y ahora todos los pedidos de los últimos siete días existen por duplicado. No hay ningún nulo, ningún valor fuera de rango, y todos los agregados aguas abajo están mal.

La comprobación. Cuenta los valores de clave que aparecen más de una vez:

SELECT count(*) AS violations
FROM (
    SELECT order_id
    FROM sales.orders
    WHERE order_id IS NOT NULL
    GROUP BY order_id
    HAVING count(*) > 1
) dupes;

Un índice único lo impediría en el momento de la escritura, pero las tablas analíticas rara vez tienen uno: CREATE TABLE AS SELECT no arrastra restricciones, así que un modelo de dbt reconstruido no tiene nada que imponga su clave. La comprobación de duplicados es lo único que ocupa ese lugar.

3. Validez

Definición. La validez —también llamada conformidad— mide si cada valor cumple el formato, el tipo, el rango o el conjunto permitido definidos para su campo. Es una propiedad sintáctica: un valor válido está bien formado, lo cual no significa que sea correcto.

Ejemplo de incumplimiento. Una nueva integración aguas arriba empieza a escribir "COMPLETE" en una columna status cuyos consumidores discriminan entre 'pending', 'paid', 'shipped' y 'refunded'. Todos los CASE aguas abajo caen en su rama ELSE, y los pedidos desaparecen sin ruido del informe de embudo.

La comprobación. Prueba pertenencia, patrón y rango:

SELECT count(*) AS violations
FROM sales.orders
WHERE status IS NOT NULL
  AND status NOT IN ('pending', 'paid', 'shipped', 'refunded');

La protección IS NOT NULL no es decorativa. La lógica trivaluada de SQL resuelve NULL NOT IN (...) como NULL en lugar de como true, así que un status nulo nunca satisface la cláusula WHERE y nunca llega al recuento. Quita la protección y una columna que ha dejado de rellenarse por completo puntúa como perfectamente válida, que es la razón por la que validez y completitud tienen que medirse como reglas separadas en lugar de fundirse en una sola consulta.

4. Consistencia

Definición. La consistencia mide si los valores relacionados concuerdan entre sí: entre columnas de una misma fila, entre tablas de una base de datos o entre sistemas. Abarca la integridad referencial, la lógica entre campos y la conciliación entre sistemas.

Ejemplo de incumplimiento. Una recarga parcial deja 12 000 pedidos cuyo customer_id no existe en la tabla de clientes. Cada fila es completa, única y válida de forma aislada, e invisible hasta que el inner join de un dashboard las descarta en silencio y los ingresos parecen caer un 3 %.

La comprobación. Claves foráneas huérfanas y combinaciones de campos imposibles:

SELECT count(*) AS orphans
FROM sales.orders o
LEFT JOIN sales.customers c ON o.customer_id = c.id
WHERE o.customer_id IS NOT NULL
  AND c.id IS NULL;

La consistencia entre campos es la misma idea dentro de una única tabla: shipped_at >= ordered_at, una devolución que nunca supera su pago, líneas que suman el total de la factura. Codifican invariantes del dominio y son las comprobaciones que detectan errores de negocio genuinos en lugar de errores de fontanería.

5. Exactitud

Definición. La exactitud mide si los valores describen correctamente la cosa del mundo real a la que se refieren. Es la dimensión más difícil, porque verificarla exige una fuente de la verdad fuera del propio dataset.

Ejemplo de incumplimiento. La dirección de un cliente está bien formada, completa, es única y coherente internamente, y corresponde al edificio del que se mudó hace dos años. Todas las comprobaciones sintácticas pasan; el paquete va al sitio equivocado.

La comprobación. Tres enfoques, en orden descendente de rigor:

Conciliación. Compara contra un sistema autoritativo: los ingresos del warehouse contra el libro mayor de finanzas, el número de clientes contra el CRM. Es la única comprobación que mide la exactitud de forma directa, y merece el esfuerzo para el puñado de cifras que el negocio publica.
Datos de referencia. Valida contra una lista externa: códigos postales que existen, códigos de moneda ISO 4217, números de IVA que resuelven.
Límites de plausibilidad. Comprobaciones de rango como aproximación. Un total de pedido de -40 o de 4,000,000 no es demostrablemente erróneo, pero lo es con la frecuencia suficiente como para detectarlo:

SELECT count(*) AS violations
FROM sales.orders
WHERE total_amount IS NOT NULL
  AND (total_amount < 0 OR total_amount > 100000);

Sé honesto con la distinción: los límites de plausibilidad son una comprobación de validez disfrazada de exactitud. Detectan valores atípicos, no errores.

6. Actualidad

Definición. La actualidad —a menudo llamada frescura— mide si los datos son lo bastante recientes para la decisión que sostienen. Tiene dos mitades: la latencia (cuánto pasa entre que ocurre un evento y que se puede consultar) y la vigencia (cómo de antigua es ahora mismo la fila más nueva).

Ejemplo de incumplimiento. Un pipeline se para el viernes por la tarde. El dashboard del lunes se renderiza a la perfección, todas las comprobaciones pasan, y todas las cifras son del viernes. Ninguna regla sobre el contenido de los datos puede detectar esto, porque el contenido está bien.

La comprobación. Compara la marca de tiempo más reciente con un umbral:

SELECT count(*) AS violations
FROM sales.orders
WHERE created_at < now() - interval '24 hours';

Prefiere un tipo de marca de tiempo con zona horaria: un timestamp a secas se compara contra la zona que tenga la sesión, así que la misma comprobación da respuestas distintas a dos clientes. Y fija el umbral a partir de la decisión, no de la programación: una tabla que carga cada hora pero que solo alimenta un informe semanal no necesita ninguna alerta horaria.

Usar las dimensiones, no solo nombrarlas

El marco empieza a rentar cuando tienes cien reglas. Por separado son una lista; agrupadas por dimensión se convierten en una matriz de cobertura, y los huecos de esa matriz suelen ser más informativos que cualquier comprobación fallida concreta.

El hueco característico: mucha cobertura en completitud y validez, porque esas comprobaciones son fáciles de escribir, y casi nada en consistencia o actualidad, porque esas exigen pensar en relaciones y en programaciones. El equipo acaba bien defendido frente a los fallos baratos de detectar e indefenso frente a los que tumban un dashboard. De ahí se derivan dos prácticas:

Etiqueta cada regla con su dimensión y reporta la cobertura por dataset. Una tabla crítica con cero reglas de actualidad es un hallazgo aunque todas las comprobaciones estén en verde.
Pondera por criticidad, no por número de tablas. Cobertura completa de las seis dimensiones en tus diez datasets más consumidos vale más que cobertura parcial en cuatrocientos.

El Open Data Contract Standard convierte la dimensión en un campo de primera clase en cada regla de calidad, que es lo que permite calcular la cobertura en lugar de estimarla. Catalyst modela directamente esas mismas seis dimensiones: cada regla lleva una, y los resultados se agregan en una vista de cobertura por dataset junto al detalle de pass/fail.

Ver también: qué es la validación de datos, qué es un contrato de datos y la guía para validar datos para el SQL y la programación.

Preguntas frecuentes

¿Cuáles son las 6 dimensiones de la calidad de datos?

Completitud (¿están presentes los datos esperados?), unicidad (¿aparece cada entidad exactamente una vez?), validez (¿cumple cada valor su formato o conjunto permitido?), consistencia (¿concuerdan entre sí los valores relacionados?), exactitud (¿describen los valores correctamente el mundo real?) y actualidad (¿son los datos lo bastante recientes para resultar útiles?).

¿Solo hay seis dimensiones de calidad de datos?

Seis es el conjunto de trabajo habitual, pero las taxonomías varían. El documento de DAMA UK enumera seis; otros marcos añaden integridad, precisión, relevancia o accesibilidad. El número exacto importa mucho menos que elegir un conjunto y usarlo de forma consistente, para que los informes de cobertura signifiquen lo mismo en todos los equipos.

¿Cuál es la diferencia entre validez y exactitud?

La validez es sintáctica: el valor está bien formado y pertenece al conjunto o al rango permitidos. La exactitud es semántica: el valor describe correctamente la cosa del mundo real. Un valor válido pero inexacto es el caso difícil clásico: una dirección postal correctamente formateada del edificio del que el cliente se mudó hace dos años pasa todas las comprobaciones de validez y sigue estando mal.

¿Qué dimensión de calidad de datos es la más importante?

Depende de la decisión que sostengan los datos, pero en la práctica la actualidad y la completitud causan la mayoría de los incidentes: un pipeline parado o una carga parcial rompen todo lo que hay aguas abajo de golpe, dejando cada valor individualmente correcto. La exactitud es la que más importa para las cifras que se publican fuera, y es la única dimensión que exige una fuente de la verdad ajena al dataset.

¿Cómo se miden las dimensiones de calidad de datos?

Asocia cada regla a una dimensión, exprésala como una consulta que devuelve un recuento de incumplimientos, y reporta tanto la tasa de aprobados por regla como la cobertura por dimensión. La cobertura es la parte que los equipos se saltan: saber que noventa y ocho de cien comprobaciones pasaron es mucho menos útil que saber que ninguna de las cien era una comprobación de actualidad.