Validar las transformaciones

Aquí vive el valor (y el riesgo)

Extraer y cargar mueve datos. Transformar los cambia — y ahí es donde un ETL agrega valor y donde más se equivoca. Convertir monedas, calcular impuestos, aplicar descuentos, unir fuentes, normalizar formatos: cada regla es una oportunidad de bug.

La técnica maestra: recalcular independiente

No confíes en que la fórmula del ETL es correcta. Recalcula el resultado esperado por tu cuenta y compáralo:

-- El ETL calculó precio_final; verificamos recalculándolo
SELECT id, precio_neto, precio_final,
       ROUND(precio_neto * 1.19) AS esperado
FROM stg_precios
WHERE precio_final <> ROUND(precio_neto * 1.19);

Si esa consulta devuelve filas, esas transformaciones están mal. Es la misma idea del "recalcular independiente" que en cualquier prueba: no repetir la lógica del sistema, sino verificarla desde afuera.

Tipos, formatos y redondeo

Otras verificaciones de formato:

-- Fechas que perdieron la hora o la zona horaria
SELECT * FROM stg_ventas WHERE fecha::time = '00:00:00' AND fecha_origen::time <> '00:00:00';

-- Texto truncado (el destino tiene menos capacidad que el origen)
SELECT * FROM stg_clientes WHERE LENGTH(nombre) = 50;  -- ¿justo el máximo? sospechoso

Prueba los bordes de las reglas

Las reglas de negocio se rompen en los casos especiales, igual que en el testing de caja negra:

• Cero y negativos: ¿qué pasa con un precio 0 o un descuento del 100%?
• Nulos: ¿la regla asume que el campo siempre viene? ¿qué hace si es null?
• Orden de operaciones: ¿el descuento va antes o después del IVA? Un clásico mal implementado.
• Categorías nuevas: ¿qué hace la transformación con un tipo de cliente que no existía?

Cada uno de esos es un caso de prueba. La transformación bien validada es la diferencia entre un reporte confiable y uno que engaña.

Comprueba lo aprendido en el quiz y valida la regla en el reto.