Nivel 10 · Desafío final: revisión de calidad de datos

Las comprobaciones de calidad de datos son una gran parte de la semana de un analista, sobre todo antes de un cierre o de un informe para la junta. También son una excelente forma de practicar el filtrado, porque cada comprobación es solo una cláusula WHERE precisa.

Paso 1: productos activos sin costo

Un producto activo sin costo rompe todos los informes de margen. Dos condiciones, ambas obligatorias:

WHERE is_active
  AND unit_cost IS NULL

Los productos inactivos se excluyen a propósito: ya no se venden, así que Kevin no los necesita en la lista de limpieza. Recuerda del quiz que unit_cost = NULL no devolvería nada en silencio y haría que los datos parecieran más limpios de lo que son.

Paso 2: cantidades imposibles

Una línea vendida con cantidad 0 o menor es un error de datos: quizá una devolución registrada como venta negativa, quizá una transacción de prueba. WHERE quantity <= 0 encuentra tanto los valores cero como los negativos. En capítulos posteriores, cuando calcules los ingresos, excluirás estas filas con quantity > 0 y lo dirás en tus notas. Los analistas que las incluyen en silencio reportan ingresos que no cuadran con finanzas.

Paso 3: pedidos pendientes en 2025

Tres condiciones: status, un par de canales y un año. Los pedidos de marketplace los gestiona el socio del marketplace, así que Kevin solo quiere web y app.

WHERE status = 'pending'
  AND channel IN ('web', 'app')
  AND order_date >= '2025-01-01'
  AND order_date <  '2026-01-01'

Usar IN evita la trampa de la precedencia de AND/OR. Si escribieras channel = 'web' OR channel = 'app' sin paréntesis, los filtros de estado pendiente y de fecha solo se aplicarían a la mitad de app, y la lista incluiría todos los pedidos web hechos alguna vez.

Por qué una revisión antes del cierre

Cada una de estas listas alimenta una corrección distinta. Los costos faltantes van a merchandising, que es dueño de los precios de proveedores. Las cantidades imposibles van a ingeniería, porque algo en el checkout o en el proceso de importación las escribió. Los pedidos pendientes antiguos van a operaciones, que decide si enviar o cancelar. Dividir los resultados por responsable convierte un vago “los datos están desordenados” en tres tickets que de verdad se resuelven.

Cómo reportar

Cuando envíes resultados como estos, incluye el conteo y la regla que usaste, por ejemplo: “8 productos activos no tienen costo registrado (is_active = true y unit_cost IS NULL)”. Declarar la regla permite que quien lee detecte un malentendido antes de que alguien pase un día arreglando las filas equivocadas.

Errores comunes

• Comprobar un costo faltante con unit_cost = NULL. No devuelve nada y hace que los datos parezcan más limpios de lo que son. Usa unit_cost IS NULL.
• Usar quantity < 0 para cantidades imposibles. Eso pierde las líneas con cantidad exactamente 0. Usa quantity <= 0.
• Mezclar AND y OR sin paréntesis. status = 'pending' AND channel = 'web' OR channel = 'app' conserva todos los pedidos de app, sin importar su estado ni año. Usa channel IN ('web', 'app'), o envuelve el OR entre paréntesis.
• Terminar el año con order_date <= '2025-12-31'. Si order_date tiene hora, los pedidos hechos después de la medianoche del 31 de diciembre quedan fuera. Usa order_date < '2026-01-01'.

En SQL Server

Los tres filtros se traducen directamente. Allí los booleanos son columnas BIT, así que el paso 1 se lee WHERE is_active = 1 AND unit_cost IS NULL. El año del paso 3 puede seguir siendo un rango semiabierto; YEAR(order_date) = 2025 da las mismas filas pero no puede usar un índice sobre la fecha.