Proyecto SQL: análisis y auditoría de ventas

Escenario y regla de negocio

Trabajas con la base educativa de la tienda. La dirección quiere un informe sencillo para revisar ventas y detectar incoherencias antes de compartir cifras. Para este proyecto, un pedido con estado 'cancelado' no cuenta como venta válida; esa es una regla del ejercicio, no una regla universal de SQL.

Plan del proyecto

1. Resume el importe registrado por método de pago y valida el total.
2. Encuentra clientes con al menos 200 € de facturación válida.
3. Calcula qué productos aportan más ingreso a partir de las líneas.
4. Compara el total del pedido con la suma de sus líneas para localizar discrepancias.
5. Detecta clientes sin ninguna venta válida y explica por qué NOT EXISTS encaja con la pregunta.

Las 15 filas de pagos se resumen en tres métodos y suman 2.659,00 €. Ese total coincide con la suma de los pedidos no cancelados de este dataset, pero no conviertas esa coincidencia en una regla universal: otro sistema podría admitir pagos parciales, reembolsos o varios pagos por pedido.

SELECT pg.metodo,
       COUNT(*) AS pagos,
       ROUND(SUM(pg.importe), 2) AS importe
FROM pagos AS pg
JOIN pedidos AS p ON p.id = pg.pedido_id
WHERE p.estado <> 'cancelado'
GROUP BY pg.metodo
ORDER BY importe DESC, pg.metodo;

Empieza con una métrica de la tabla pagos. Una fila intermedia representa un pago registrado; une pedidos solo para aplicar la regla del proyecto y excluir cancelados antes de agrupar por método.

Etapa 1 · Importe registrado por método de pago

Un error que puede inflar la facturación

SELECT SUM(p.total)
FROM pedidos AS p
JOIN detalle_pedido AS d ON d.pedido_id = p.id
WHERE p.estado <> 'cancelado';

Etapa 2 · Clientes con al menos 200 €

SELECT c.nombre,
       COUNT(p.id) AS pedidos,
       ROUND(SUM(p.total), 2) AS facturacion
FROM clientes AS c
JOIN pedidos AS p ON p.cliente_id = c.id
WHERE p.estado <> 'cancelado'
GROUP BY c.id, c.nombre
HAVING SUM(p.total) >= 200
ORDER BY facturacion DESC, c.nombre;

Etapa 3 · Productos que más ingreso aportan

SELECT pr.nombre,
       SUM(d.cantidad) AS unidades,
       ROUND(SUM(d.cantidad * d.precio_unitario), 2) AS ingreso
FROM detalle_pedido AS d
JOIN pedidos AS p ON p.id = d.pedido_id
JOIN productos AS pr ON pr.id = d.producto_id
WHERE p.estado <> 'cancelado'
GROUP BY pr.id, pr.nombre
ORDER BY ingreso DESC, pr.nombre
LIMIT 5;

Etapa 4 · Audita cabecera contra líneas

El proyecto contiene deliberadamente una discrepancia para que practiques una comprobación de integridad. Agrupa las líneas por pedido y compara su suma con pedidos.total.

SELECT p.id,
       p.total AS total_cabecera,
       ROUND(SUM(d.cantidad * d.precio_unitario), 2) AS total_lineas
FROM pedidos AS p
JOIN detalle_pedido AS d ON d.pedido_id = p.id
GROUP BY p.id, p.total
HAVING ABS(p.total - SUM(d.cantidad * d.precio_unitario)) > 0.001
ORDER BY p.id;

La consulta detecta el pedido 113, cuya cabecera dice 98,00 € y cuyas líneas suman 93,90 €. SQL te permite localizar la diferencia; no te dice qué valor es el correcto. Corregirlo requeriría conocer la regla del sistema origen, impuestos, descuentos u otros ajustes que este dataset no modela.

Etapa 5 · Clientes sin ventas válidas

SELECT c.nombre
FROM clientes AS c
WHERE NOT EXISTS (
  SELECT 1
  FROM pedidos AS p
  WHERE p.cliente_id = c.id
    AND p.estado <> 'cancelado'
)
ORDER BY c.nombre;

Criterios para considerar terminado el proyecto

Fuentes técnicas consultadas

• PostgreSQL: FROM, JOIN, GROUP BY y HAVING
• PostgreSQL: EXISTS y expresiones de subconsulta
• MySQL 8.4: SELECT, JOIN, GROUP BY y HAVING
• MySQL 8.4: EXISTS y NOT EXISTS
• SQLite: SELECT, JOIN, GROUP BY y HAVING
• SQL Server: TOP con ORDER BY