¿Qué es la validación de datos? Definición, métodos y ejemplos

En qué se diferencia la validación de datos del testing, la observabilidad y la limpieza, los cuatro métodos que cubren casi cualquier comprobación real y dónde se ejecuta cada uno.

2026-09-10 · 9 min read

La validación de datos es el proceso de comprobar que unos datos cumplen un conjunto definido de expectativas —su estructura, sus tipos, sus valores permitidos, sus relaciones y su frescura— antes de confiar en ellos o de usarlos. Cada expectativa se declara de antemano, se evalúa contra los datos reales y produce un pass o un fail junto con el recuento de registros que la incumplieron. La validación no repara nada; su trabajo es decidir si los datos sirven para el propósito con el que están a punto de usarse y decir exactamente qué falla cuando no es así.

Esa definición tiene tres piezas que soportan el peso. Las expectativas se declaran de antemano, que es lo que separa la validación de darse cuenta de un problema cuando un dashboard ya se ve raro. La comprobación se evalúa contra datos reales, no contra una muestra ni contra una descripción de los datos. Y el resultado es una decisión —este lote es aceptable o no lo es— y no un informe que quizá alguien lea más adelante.

Qué no es la validación de datos

La palabra se usa con ligereza para cuatro actividades distintas. Ser preciso con las fronteras facilita muchísimo decidir qué herramienta necesitas de verdad.

Actividad	Pregunta que responde	Expectativas	Salida habitual
Validación de datos	¿Estos datos cumplen las reglas que acordamos?	Declaradas explícitamente y por adelantado	Pass/fail por regla, recuentos de incumplimientos
Testing de datos	¿El código de este pipeline se comporta correctamente?	Aserciones escritas por quien desarrolla	La build pasa o falla
Observabilidad de datos	¿Ha cambiado algo de forma inesperada?	Aprendidas del histórico, estadísticas	Alertas de anomalías, líneas de tendencia
Limpieza de datos	¿Podemos arreglar los registros defectuosos?	N/A — es una transformación	Datos modificados

Las distinciones importan en la práctica:

Validación frente a testing. Un dbt test es una regla de validación que resulta ejecutarse dentro de una build. La diferencia está en el alcance y en la propiedad: los tests cubren los modelos que el pipeline controla y se ejecutan cuando se ejecuta el pipeline; la validación cubre las garantías de un dataset con independencia de qué pipeline lo haya producido hoy, y se ejecuta con una programación propia. Una tabla cargada por Fivetran, transformada por dbt y a la que añade filas un job de Python hecho a mano tiene un solo conjunto de garantías y tres pipelines.
Validación frente a observabilidad. La observabilidad no es supervisada: vigila recuentos de filas, tasas de nulos y distribuciones, y avisa cuando lo de hoy no se parece a lo de la semana pasada. Encuentra problemas que no se te habría ocurrido buscar, y también salta cuando el negocio cambia de forma legítima. La validación sí es supervisada: dijiste que status debe ser uno de cuatro valores, y o lo es o no lo es. La observabilidad te da recall; la validación te da precisión. Los equipos maduros usan ambas.
Validación frente a limpieza. La limpieza muta los datos: recorta espacios, fuerza tipos, deduplica, imputa. La validación es de solo lectura por diseño. Confundirlas es la vía directa a la corrupción silenciosa: un paso de coerción que convierte "N/A" en 0 hace que una regla de validación pase mientras deja el número mal.

Los cuatro métodos de validación de datos

Casi toda comprobación en producción entra en una de estas cuatro familias.

1. Comprobaciones de esquema y de tipos

¿Tiene el dataset las columnas que debería tener, con los tipos que debería tener y con la nulabilidad declarada correctamente? Son las comprobaciones más baratas y detectan los fallos más disruptivos: una columna renombrada, un tipo ampliado de integer a text, una columna eliminada en silencio por una migración aguas arriba. La deriva de esquema rompe a los consumidores de forma inmediata y ruidosa, y por eso merece la pena detectarla en la frontera y no en un dashboard.

2. Comprobaciones de restricciones

Reglas a nivel de fila que un registro concreto cumple o incumple: una columna obligatoria no es nula, una clave es única, un valor pertenece a un conjunto permitido, un número cae dentro de un rango plausible, una cadena cumple un patrón, una clave foránea resuelve. Esta familia cubre el grueso de las reglas reales, y cada una se compila a una única consulta de agregación que devuelve un recuento de incumplimientos.

SELECT
    count(*) FILTER (WHERE order_id IS NULL)                       AS null_ids,
    count(*) FILTER (WHERE total_amount < 0 OR total_amount > 1e5) AS bad_amounts,
    count(*) FILTER (
        WHERE status IS NOT NULL
          AND status NOT IN ('pending', 'paid', 'shipped', 'refunded')
    )                                                              AS bad_status
FROM sales.orders;

Fíjate en la protección status IS NOT NULL. Comparar un NULL con cualquier cosa da NULL, nunca true, así que un NOT IN sin protección excluye discretamente todas las filas nulas de su propio recuento de incumplimientos. Una comprobación de restricción escrita así se mantiene en verde mientras la columna se vacía, y ese es el argumento permanente para emparejar cada regla de restricción con una regla de completitud sobre la misma columna.

3. Comprobaciones estadísticas

Propiedades agregadas en lugar de filas individuales: recuento de filas dentro de una banda, tasa de nulos por debajo de un porcentaje, media o mediana dentro de un rango, cardinalidad estable, distribución entre categorías más o menos como se espera. Estas detectan fallos que ninguna regla a nivel de fila puede ver: una carga parcial en la que cada fila superviviente es válida por separado pero falta un tercio de los datos.

4. Comprobaciones de reglas de negocio

Lógica entre columnas o entre tablas que codifica un invariante del dominio: shipped_at nunca es anterior a ordered_at, las líneas de una factura suman su total, una devolución nunca supera el pago original, toda suscripción activa tiene una cuenta de facturación. Son las reglas que detectan errores de negocio genuinos en lugar de errores de fontanería, y normalmente son las que una herramienta de validación expresa como SQL personalizado.

Dónde se ejecuta la validación

La misma regla significa cosas distintas según dónde la coloques, y la mayoría de los equipos necesitan más de una ubicación.

En la ingesta. Valida en la frontera, antes de que los datos aterricen en una tabla compartida. Aquí es donde rechazas un CSV mal formado, un payload JSON al que le falta un campo obligatorio o una respuesta de API con un esquema inesperado. Fallar aquí sale barato: todavía no se ha calculado nada aguas abajo, y poner el lote en cuarentena te cuesta un reintento.

En el warehouse, después de la carga. Valida la propia tabla ya cargada, con una programación atada a la carga y no a un cron de hora redonda. Aquí vive la mayor parte de la monitorización de calidad de datos, porque es el único sitio que ve los datos tal y como los ven realmente los consumidores: después de que cada pipeline, merge y corrección tardía hayan dicho lo suyo. Una tabla diaria validada a las 06:00 cuando la carga termina a las 06:40 falla todas las mañanas por motivos que no tienen nada que ver con la calidad.

En el consumo. Valida justo antes de un uso crítico: un informe regulatorio, una métrica que ve el cliente, un conjunto de entrenamiento para un modelo. Estas comprobaciones son más estrechas y más estrictas que las generales, porque la tolerancia es distinta: una tasa de nulos del 0,1 % puede estar bien en un dashboard interno y ser inaceptable en una presentación financiera.

Una regla práctica: rechaza en la ingesta, monitoriza en el warehouse, bloquea en el consumo.

De comprobaciones improvisadas a expectativas versionadas

El SQL de validación escrito a mano funciona hasta que hay cuarenta reglas repartidas por una docena de tablas, momento en el que desarrolla los problemas de siempre. Las reglas se desincronizan de los esquemas que comprueban. Nadie sabe responder a “¿qué garantizamos exactamente sobre esta tabla?” sin leerse un script. Un cambio de umbral no deja rastro de quién lo cambió ni por qué.

La solución es convertir las expectativas en un artefacto declarativo en lugar de en código: un documento que declare lo que el dataset promete, versionado en el mismo repositorio que todo lo demás y compilado a SQL por un runner. Ese documento es un contrato de datos, y el Open Data Contract Standard es el formato abierto para escribirlo. Catalyst sigue esta vía: las reglas son YAML de ODCS, el YAML es la fuente de la verdad y cada regla se compila al SQL específico del motor que se muestra arriba.

Organizar las reglas por dimensión de calidad de datos —completitud, unicidad, validez, consistencia, exactitud y actualidad— es lo que convierte un montón de comprobaciones en una vista de cobertura. Para la mecánica de escribir y programar las comprobaciones, consulta la guía para validar datos.

Preguntas frecuentes

¿Qué es la validación de datos en palabras sencillas?

La validación de datos consiste en comprobar que los datos cumplen las reglas que decidiste que debían cumplir: las columnas y los tipos correctos, ningún valor ausente donde es obligatorio, ninguna clave duplicada, valores dentro del conjunto o el rango permitidos y datos lo bastante recientes como para resultar útiles. Cada regla se comprueba contra los datos reales y devuelve un pass o un fail con el recuento de registros infractores.

¿Cuál es la diferencia entre validación y verificación de datos?

La validación pregunta si los datos satisfacen las reglas definidas para ellos: ¿son estructural y semánticamente aceptables? La verificación pregunta si los datos se corresponden fielmente con su origen: si llegaron intactos y sin alterar, por ejemplo comparando recuentos de filas o checksums entre el sistema de origen y el destino. Un registro puede estar perfectamente verificado y aun así fallar la validación si el propio origen contenía valores incorrectos.

¿Cuáles son los principales tipos de validación de datos?

Cuatro familias cubren casi todo: comprobaciones de esquema y tipos (las columnas correctas, con los tipos correctos), comprobaciones de restricciones (no nulo, único, valores permitidos, rangos, patrones, integridad referencial), comprobaciones estadísticas (recuentos de filas, tasas de nulos, distribuciones) y comprobaciones de reglas de negocio (invariantes entre columnas y entre tablas, propios de tu dominio).

¿Cuándo debe ejecutarse la validación de datos?

En tres puntos, por motivos distintos. En la ingesta, para rechazar datos mal formados en la frontera antes de que aterricen. En el warehouse después de la carga, con una programación disparada por la propia carga, para monitorizar las tablas que los consumidores consultan de verdad. Y en el consumo, como una barrera más estricta antes de un uso crítico, como un informe regulatorio o el entrenamiento de un modelo.

¿La validación de datos modifica mis datos?

No. Una comprobación de validación es una consulta de solo lectura que devuelve un recuento de incumplimientos. Modificar registros es limpieza de datos, un paso aparte que debería ocurrir después de que la validación te haya dicho qué falla, nunca como efecto secundario de la propia comprobación, porque eso ocultaría el problema en lugar de sacarlo a la luz.