Nivel 7 · De la pregunta a la respuesta comprobada

Todo análisis sigue más o menos el mismo camino, sea cual sea la herramienta. Escribirlo como etapas hace el SQL más fácil de construir, más fácil de revisar y mucho más fácil de defender cuando alguien cuestiona el número.

Las etapas

1. Entender la petición. ¿Qué decisión alimenta? Aquí: la dotación de personal para devoluciones. ¿Qué se cuenta exactamente? Una tasa de devolución por categoría, como proporción de líneas de pedido, en 2025.
2. Explorar claves y grano. order_items tiene una fila por línea; returns tiene como máximo una fila por order_item_id; products da la categoría. El grano de la respuesta es una fila por categoría.
3. Extraer las filas del alcance: líneas de pedidos completados realizados en 2025.
4. Limpiar: descartar las líneas con cantidad cero o menor.
5. Agregar al grano solicitado.
6. Estructurar los pasos como CTE con nombre para poder ejecutar y comprobar cada una por separado.
7. Analizar más si hace falta (rankings, participaciones, tendencias con funciones de ventana).
8. Validar: ¿las partes suman el todo? ¿Son plausibles los conteos de filas en cada paso?
9. Presentar: una tabla ordenada con una frase de interpretación.

La consulta, etapa por etapa

El starter es la etapa 3. Ejecutarlo solo devuelve 10,810 líneas, la primera comprobación de sensatez. La CTE de limpieza elimina 10 líneas con una cantidad mala, dejando 10,800. El agregado une products y hace LEFT JOIN con returns: un LEFT JOIN, porque las líneas sin devolución deben quedarse en el denominador, y COUNT(r.return_id) cuenta solo las coincidentes.

La validación es una columna, no un memorándum aparte:

SUM(lines) OVER () = (SELECT COUNT(*) FROM clean_lines) AS total_check

SUM(lines) OVER () suma los seis conteos por categoría; la subconsulta cuenta directamente las líneas limpias. Si a un producto le faltara una categoría, o un join duplicara líneas, los dos diferirían y la columna diría falso.

El resultado: Textiles 4.2% (92 de 2,195 líneas), Lighting 3.9%, Outdoor 3.7%, Furniture 3.6%, Decor 2.9% y Kitchen 2.0% (51 de 2,548). Furniture tiene menos líneas (586), así que su tasa se mueve más con un puñado de devoluciones; dilo cuando lo presentes.

Valida antes de presentar

Comprobaciones útiles para casi cualquier análisis:

• Conteos de filas tras cada CTE, comparados con lo que esperas según la documentación de los datos.
• Partes frente al todo, como arriba.
• Una entidad rastreada de principio a fin: elige un pedido y confirma sus líneas y devoluciones a mano.
• Una comparación con un número en el que alguien ya confía, como el informe del mes pasado.

Errores comunes

• Saltarse la etapa 1 y responder otra pregunta: devoluciones por pedido en lugar de por línea, o dólares reembolsados en lugar de conteos.
• INNER JOIN a returns, que hace que todas las tasas sean 100%.
• Incluir pedidos reembolsados, cuyas líneas están todas devueltas por definición, sin decirlo.
• Presentar una tasa sin su denominador.

En SQL Server

La cadena de CTE, el LEFT JOIN y COUNT(column) son idénticos en T-SQL. Dos diferencias: una expresión booleana no puede ser una columna, así que escribe la comprobación como CASE WHEN SUM(lines) OVER () = (SELECT COUNT(*) FROM clean_lines) THEN 1 ELSE 0 END, y 100.0 * returned_lines / lines necesita el 100.0, porque / entre dos enteros trunca en SQL Server.