Hasta ahora, todas nuestras consultas han devuelto detalle: una fila del resultado por cada fila de la base de datos. Eso responde a preguntas del tipo "¿qué?" —qué préstamos hay abiertos, qué ejemplares no ha tocado nadie—, pero la dirección de BiblioRed hace otras preguntas: ¿cuántos préstamos hicimos el trimestre pasado?, ¿qué sucursal presta más?, ¿cuál es el título estrella?, ¿cuánto hemos recaudado en recargos?, ¿qué socios superan los dos préstamos?.

Esas preguntas exigen pasar del detalle al resumen: condensar muchas filas en una sola cifra. Es lo que hacen las funciones de agregado y la cláusula GROUP BY, y es el paso que convierte una base de datos en una herramienta de gestión.

Esta lección también aclara algo que llevas arrastrando desde la primera consulta: en qué orden se ejecuta realmente una instrucción SQL. No es el orden en que se escribe, y entenderlo resuelve de golpe media docena de errores aparentemente inexplicables.

Damos por sabidos los JOIN y las subconsultas de la lección 02-04: los usaremos sin volver a explicarlos.

1. Las funciones de agregado
2. COUNT y sus tres formas
3. SUM, AVG, MIN y MAX
4. Cómo tratan los agregados los valores NULL
5. GROUP BY: agregar por grupos
6. La regla de qué puede aparecer en el SELECT
7. GROUP BY por varias columnas
8. HAVING frente a WHERE
9. El orden lógico de ejecución de una consulta
10. Agregación combinada con JOIN
11. El problema de las filas infladas por un JOIN
12. COALESCE y CASE WHEN dentro de agregados
13. Introducción a las funciones de ventana
14. Errores comunes y consejos
15. Ejercicios
16. Conclusión

Una función de agregado recibe muchos valores y devuelve uno solo. Las cinco del estándar SQL, presentes en todos los gestores:

Sin GROUP BY, una función de agregado trata toda la tabla como un único grupo y devuelve una sola fila:

Puedes combinar varias en la misma consulta, siempre que todas resuman el mismo conjunto de filas:

Doce préstamos entre el 2 de marzo y el 25 de julio de 2026, con 7,00 € recaudados en recargos.

Fíjate en un detalle esencial: el resultado tiene una fila, no doce. La consulta ya no habla de préstamos individuales, habla del conjunto. Por eso no puedes mezclar libremente agregados con columnas de detalle; lo veremos en el apartado 6.

COUNT parece la función más simple y es la que más confusión genera, porque tiene tres variantes que cuentan cosas distintas.

La diferencia entre las dos primeras es la que más veces se pasa por alto, y en prestamos es especialmente elocuente:

COUNT(fecha_devolucion) cuenta 8 porque los cuatro préstamos abiertos tienen esa columna a NULL. Es un truco muy útil: contar los no nulos de una columna equivale a contar las filas que cumplen cierta condición, si esa condición se refleja en la nulidad.

Y COUNT(DISTINCT socio_id) devuelve 8, no 12: hay ocho socios distintos con préstamos, porque algunos tienen más de uno.

Sobre el rendimiento: existe la leyenda de que COUNT(1) es más rápido que COUNT(*). Es falso en PostgreSQL y en cualquier gestor moderno: son idénticos. COUNT(DISTINCT columna) sí es notablemente más caro, porque obliga a deduplicar.

ROUND(expresión, decimales) no es una función de agregado: redondea el resultado. Sin ella, AVG sobre NUMERIC en PostgreSQL devuelve un número con muchísimos decimales (2000.8888888888888889), poco práctico para un informe.

MIN y MAX funcionan también sobre texto (orden alfabético) y sobre fechas (orden cronológico):

Atención a una trampa clásica: esta consulta te dice cuál es el apellido mínimo y cuál es la fecha mínima, pero no te dice que sean de la misma persona. Cada agregado se calcula por separado. Para obtener la fila completa del socio más antiguo hace falta otra cosa:

Es la subconsulta escalar de la lección anterior, ahora con un agregado dentro. En el apartado 13 veremos una alternativa con funciones de ventana.

Aquí hay una regla y una excepción, y conviene grabarlas:

Todas las funciones de agregado ignoran los NULL. La única excepción es COUNT(*), que cuenta filas y no mira el contenido.

Veámoslo con la columna recargo, que tiene ocho valores y cuatro NULL:

Dos medias distintas para los mismos datos, y ninguna de las dos está mal: significan cosas diferentes.

• AVG(recargo) = 7,00 / 8 = 0,875 €. Es "el recargo medio de los préstamos ya cerrados", porque los abiertos aún no tienen recargo calculado.
• SUM(recargo) / COUNT(*) = 7,00 / 12 = 0,583 €. Es "el recargo medio por préstamo realizado", tratando los pendientes como cero.

La pregunta que debes hacerte siempre es: ¿qué significa el NULL en esta columna? Si significa "todavía no se sabe", ignorarlo es correcto. Si significa "cero", ignorarlo distorsiona la media. En el apartado 12 veremos COALESCE, la herramienta para convertir explícitamente NULL en cero cuando esa es la semántica correcta.

Un caso extremo que sorprende:

SUM de un conjunto donde todos los valores son NULL devuelve NULL, no cero. Y lo mismo si el conjunto está vacío. COUNT, en cambio, devuelve 0: es la única función de agregado que nunca devuelve NULL.

Hasta ahora resumíamos la tabla entera. GROUP BY la parte en grupos y calcula los agregados dentro de cada grupo, devolviendo una fila por grupo.

Cuatro filas, una por sucursal, y la suma de los recuentos es 15: el total de ejemplares. Conceptualmente ocurre esto:

Otro ejemplo, agrupando por una columna de texto:

Observa que se puede ordenar por el agregado usando su alias. Y observa también que los grupos salen de los datos que hay: si ningún ejemplar estuviera en reparación, esa fila simplemente no aparecería. GROUP BY nunca inventa grupos vacíos.

Un tercer ejemplo, con más de un agregado por grupo:

Esta es la regla que más errores produce al empezar:

Toda columna que aparezca en el SELECT y no esté dentro de una función de agregado debe figurar en el GROUP BY.

El motivo es puro sentido común. Si agrupas los ejemplares por sucursal, cada fila del resultado representa seis ejemplares distintos (los de la sucursal 1). ¿Qué codigo debería mostrar? ¿El de cuál de los seis? La pregunta no tiene respuesta, así que el gestor la rechaza:

Las tres formas legítimas de arreglarlo, según lo que quieras de verdad:

Resultado de la opción b):

PostgreSQL, desde la versión 9.1, admite una relajación muy práctica: si agrupas por la clave primaria de una tabla, puedes seleccionar cualquier otra columna de esa misma tabla sin listarla, porque la clave primaria la determina de forma unívoca.

Es una comodidad real, pero no es portable: en otros gestores tendrías que escribir GROUP BY s.socio_id, s.nombre, s.apellidos. Si tu SQL debe funcionar en varios motores, lista todas las columnas.

SQLite no aplica esta regla en absoluto. La consulta que en PostgreSQL da error, en SQLite se ejecuta y devuelve un codigo cualquiera de los del grupo, elegido de forma no documentada. No hay error, no hay aviso, y el informe está mal.

Ese EJ-3095 no representa nada. Es una de las diferencias más peligrosas entre ambos gestores: la permisividad de SQLite convierte un error en un dato falso. Escribe el SQL como si PostgreSQL te vigilara, aunque estés en SQLite.

Al agrupar por dos columnas, los grupos son las combinaciones distintas de ambas:

Ocho grupos, cuyos recuentos suman 15. Igual que antes: solo aparecen las combinaciones que existen. La sucursal 1 no tiene ningún ejemplar en reparación, así que esa fila no está —no sale con un 0—. Si necesitas la rejilla completa con ceros incluidos, hay dos caminos: un CROSS JOIN que genere todas las combinaciones (lección 02-04) y un LEFT JOIN contra los datos, o la tabulación con CASE WHEN del apartado 12.

El orden de las columnas en el GROUP BY no altera los grupos (GROUP BY a, b y GROUP BY b, a producen los mismos), pero sí conviene que coincida con el ORDER BY para que el informe se lea bien.

WHERE filtra filas, antes de agrupar. HAVING filta grupos, después de agrupar. La diferencia es de momento, no de sintaxis.

Pregunta: ¿qué socios tienen dos o más préstamos?

Intentar lo mismo con WHERE es imposible:

Y es lógico: cuando se evalúa el WHERE, los grupos todavía no existen, así que no hay nada que contar.

Es lo habitual, y cada uno hace su trabajo:

Regla práctica de eficiencia: si una condición se puede expresar en WHERE, ponla en WHERE. Filtrar antes de agrupar significa agrupar menos filas. Meter en HAVING una condición que no usa agregados (HAVING s.sucursal_id = 2) funciona en muchos gestores, pero es más lento y más confuso.

Ahora se entiende todo. Una consulta SQL no se evalúa en el orden en que se escribe. El orden lógico es este:

Este diagrama explica de un vistazo cuatro comportamientos que hasta ahora parecían caprichos:

1. WHERE no puede usar agregados. Se ejecuta en el paso 3; los grupos se forman en el 4.
2. WHERE no puede usar los alias del SELECT. El SELECT es el paso 6, posterior. WHERE prestamos >= 2 da error de columna inexistente.
3. ORDER BY sí puede usar los alias del SELECT. Es el paso 8, posterior al 6. Por eso ORDER BY prestamos DESC funcionaba.
4. LIMIT es lo último. Recorta el resultado final, no las filas leídas: LIMIT 3 en una consulta con GROUP BY devuelve tres grupos, no tres filas de la tabla.

Insistimos en lo de lógico: es el orden en que hay que razonar la consulta. El optimizador (lección 01-04) es libre de ejecutar las cosas en otro orden físico mientras el resultado sea el mismo.

Aquí es donde las dos últimas lecciones se juntan y BiblioRed empieza a producir informes de verdad.

Ojo al matiz: la sucursal de un préstamo es la del ejemplar prestado, que no tiene por qué ser la de alta del socio.

La sucursal Norte concentra la mitad de la actividad. Suman 12 ✓.

Importante: en este listado faltan dos libros. "Manual de jardinería urbana" y "Memoria del Ensanche (1904)" no se han prestado nunca, y el INNER JOIN los elimina antes de agrupar. Si el informe debe incluirlos con un 0, hay que combinar LEFT JOIN con COUNT(columna):

Aquí hay una lección que vale por sí sola: COUNT(*) habría devuelto 1 en lugar de 0 para los dos últimos, porque el LEFT JOIN genera una fila rellena de NULL y COUNT(*) cuenta filas. COUNT(p.prestamo_id) cuenta valores no nulos, y ahí no hay ninguno.

Con LEFT JOIN, nunca COUNT(*): siempre COUNT(columna_de_la_tabla_derecha).

Este es el informe completo de actividad de socios, con los inactivos incluidos. Compáralo con el anti-join de la lección anterior: allí solo obteníamos quiénes no tenían préstamos; ahora tenemos la foto entera.

Retomamos el ejercicio que dejamos a medias en la lección 02-04. Un responsable de BiblioRed pide: "cuántos socios y cuántos ejemplares hay en cada sucursal". La consulta que sale sola es esta:

Todos los números están mal, y el hecho de que las dos columnas sean idénticas es la señal de alarma. Centro tiene 4 socios y 6 ejemplares, no 24 y 24.

La causa: socios y ejemplares no están relacionadas entre sí; ambas cuelgan de sucursales de forma independiente. Al unirlas, dentro de cada sucursal se produce un producto cartesiano: 4 socios × 6 ejemplares = 24 filas, y cada COUNT cuenta esas 24. Es la explosión de filas (fan trap).

Las tres soluciones, de peor a mejor:

Correcto. Pero COUNT(DISTINCT) es caro y solo salva los recuentos: un SUM seguiría inflado, porque sumaría el mismo valor varias veces. Si en lugar de contar ejemplares sumaras importes, el resultado sería falso y DISTINCT no lo arreglaría.

Las tres devuelven la tabla correcta. La opción c) es la que debes interiorizar: cuando haya que resumir dos ramas independientes, agrega cada una por su lado y une los resúmenes. Es la única que escala a cualquier número de ramas y a cualquier agregado, no solo a COUNT.

Cómo detectar el problema en la práctica: si un total te parece sospechosamente grande, quita los agregados y ejecuta la consulta con SELECT *. Si salen muchas más filas de las que esperabas, tienes una explosión.

COALESCE(a, b, c, ...) devuelve el primer argumento que no sea NULL. Es la herramienta para decidir explícitamente qué hacer con la ausencia de valor.

Sin el COALESCE, cuatro socios mostrarían NULL en lugar de 0.00: los dos que no tienen ningún préstamo (Etxebarri y Roig) y los dos cuyo único préstamo sigue abierto y por tanto tiene el recargo sin calcular (Salom y Miralles). Un informe con NULL en una columna de dinero es un informe que nadie sabe leer.

Fíjate en el orden en que se aplica: COALESCE envuelve al agregado, no al revés. SUM(COALESCE(p.recargo, 0)) también funcionaría y sería incluso más preciso semánticamente (trata cada NULL individual como cero), pero para el total da lo mismo… salvo con AVG, donde sí cambia el resultado, porque altera el número de valores promediados. Compruébalo:

CASE es la estructura condicional de SQL:

Metido dentro de un SUM o un COUNT, permite tabular: producir varias columnas que cuentan cosas distintas del mismo grupo. Es la forma de construir un cuadro de mando en una sola consulta.

Esto es exactamente la rejilla completa que GROUP BY sucursal_id, estado no podía dar: aquí sí aparecen los ceros, porque las columnas están fijadas por la consulta y no dependen de los datos.

Cómo funciona: para cada fila, el CASE produce 1 o 0, y SUM los suma. Una alternativa muy usada es COUNT(CASE WHEN condición THEN 1 END) —sin ELSE, de modo que las filas que no cumplen dan NULL y COUNT las ignora—.

PostgreSQL ofrece además una sintaxis estándar más elegante, la cláusula FILTER:

Mismo resultado, mucho más legible. FILTER no existe en SQLite ni en MySQL; ahí toca CASE WHEN. Y CASE WHEN funciona en todas partes, así que es la opción segura.

Terminamos con una capacidad que resuelve un problema que GROUP BY no puede: calcular un agregado sin perder el detalle.

Fíjate en la limitación. Esta consulta te dice cuántos préstamos tiene cada socio, pero pierde los préstamos individuales:

¿Y si quieres ver cada préstamo y, al lado, cuántos tiene ese socio en total? Ahí entran las funciones de ventana (window functions): calculan un agregado sobre un conjunto de filas relacionadas, pero devuelven una fila por cada fila original.

Doce filas, una por préstamo, cada una con el total de su socio repetido al lado. Eso es imposible con GROUP BY.

PARTITION BY es a las ventanas lo que GROUP BY es a los agregados: define los subconjuntos. Si lo omites (OVER ()), la ventana es la tabla entera.

"El préstamo número N de cada socio". Este patrón —numerar dentro de cada grupo y quedarse con el n_prestamo = 1— es la forma estándar de obtener "el registro más reciente de cada X", una consulta que sin ventanas es sorprendentemente incómoda.

RANK es como ROW_NUMBER pero empata:

Las tres funciones se diferencian justo en los empates:

• ROW_NUMBER nunca empata: numera 1, 2, 3, 4, 5, 6, 7 aunque los valores sean iguales.
• RANK empata y salta: los cinco libros con un préstamo son todos "puesto 3"; si hubiera un sexto valor distinto, sería el puesto 8.
• DENSE_RANK empata y no salta: el siguiente valor distinto sería el puesto 4.

Aquí lo dejamos. Las funciones de ventana dan para mucho más —medias móviles, sumas acumuladas, LAG y LEAD para comparar con la fila anterior, marcos de ventana con ROWS BETWEEN— y son el pan de cada día del análisis de datos. Están disponibles en PostgreSQL desde la versión 8.4 y en SQLite desde la 3.25.

• Olvidar una columna en el GROUP BY. En PostgreSQL da error; en SQLite se ejecuta y devuelve un valor arbitrario, que es infinitamente peor. Escribe siempre el GROUP BY completo.
• Usar COUNT(*) con un LEFT JOIN. Devuelve 1 donde debería devolver 0, porque cuenta la fila rellena de NULL. Usa COUNT(columna_de_la_tabla_derecha).
• Contar sobre un JOIN que infla filas. Si dos tablas independientes cuelgan de una tercera, cada COUNT cuenta el producto cartesiano. Agrega cada rama por separado.
• Poner una condición con agregado en WHERE. Error seguro: los agregados van en HAVING.
• Poner en HAVING una condición que no usa agregados. Funciona, pero filtra más tarde de lo necesario y confunde a quien lo lea. Va en WHERE.
• Usar un alias del SELECT dentro del WHERE. El SELECT se evalúa después. En ORDER BY sí se puede.
• Suponer que SUM de puros NULL da cero. Da NULL. Envuélvelo en COALESCE(SUM(x), 0) si el informe necesita un número.
• Comparar AVG sin decidir qué hacer con los NULL. AVG(x) y AVG(COALESCE(x, 0)) dan cifras distintas y ambas pueden ser correctas: la pregunta es qué significa la ausencia.
• Creer que MIN(a) y MAX(b) vienen de la misma fila. No lo hacen. Cada agregado se calcula por su cuenta.
• Consejo: cuando un agregado te dé un número que no te cuadre, quita las funciones y ejecuta la consulta en modo detalle con SELECT *. Contar las filas a ojo revela las explosiones al instante.
• Consejo: escribe siempre el GROUP BY empezando por la clave primaria de la tabla que estás resumiendo (GROUP BY l.libro_id, l.titulo, no solo GROUP BY l.titulo). Si hubiera dos libros con el mismo título, agrupar por el título los fundiría en uno.

1. ¿Cuántos socios hay en cada sucursal? Muestra el nombre de la sucursal, incluidas las que no tuvieran ninguno.
2. ¿Cuántos libros hay por idioma?
3. ¿Cuántos ejemplares tiene cada libro? Incluye el título y ordena de más a menos.
4. ¿Cuál es el recargo total cobrado en cada sucursal (por la sucursal del ejemplar prestado)? Muestra 0.00 donde no haya habido ninguno.

1. ¿Qué autores tienen más de una obra en el fondo?
2. ¿Qué libros tienen ejemplares en tres o más sucursales distintas?
3. ¿Qué socios han devuelto algún libro con retraso, y cuántas veces? Ordena de más a menos.
4. ¿Qué sucursales tienen tres o más ejemplares disponibles?

1. Construye el cuadro de préstamos por mes: año-mes, número de préstamos y recargo total. Pista: en PostgreSQL, TO_CHAR(fecha_prestamo, 'YYYY-MM'); en SQLite, strftime('%Y-%m', fecha_prestamo).
2. Para cada socio, muestra su nombre, el número de préstamos, el número de reservas y el recargo acumulado, en una sola consulta y con las cifras correctas. Ten cuidado con la explosión de filas.
3. Usando funciones de ventana, muestra cada préstamo con: el socio, la fecha, el recargo, y el recargo total acumulado por ese socio.

Solución 1

Total: 7,00 €, que coincide con el SUM(recargo) global del apartado 1. Aquí no hay explosión de filas, porque las tres tablas están encadenadas en línea (sucursal → ejemplar → préstamo), no colgando en paralelo.

Solución 2

El DISTINCT es imprescindible: si un libro tuviera dos ejemplares en la misma sucursal, COUNT(e.sucursal_id) los contaría dos veces.

Nota: la condición va en WHERE porque filtra filas (préstamos), no grupos. Es el filtrado eficiente.

Solución 3

Los cuatro préstamos de julio están abiertos, así que su recargo es NULL y SUM devuelve NULL; el COALESCE lo convierte en 0.00. Y fíjate en que junio no aparece: no hubo ningún préstamo ese mes y GROUP BY no inventa grupos vacíos. Para que salga con un 0 habría que generar la serie de meses y hacerle un LEFT JOIN.

Si lo hubieras resuelto con dos LEFT JOIN directos a prestamos y reservas, Marta Alsina habría salido con 3 préstamos y 3 reservas (3 × 1 = 3 filas), y Nuria Bastos con 2 y 2. La explosión de filas en estado puro.

Al añadir ORDER BY dentro del OVER, SUM deja de ser un total y pasa a ser una suma acumulada: cada fila incluye todas las anteriores de su partición. Es el mecanismo detrás de cualquier gráfico de evolución acumulada.

Con esta lección BiblioRed ya puede responder no solo "qué hay", sino "cuánto hay":

• Las funciones de agregado COUNT, SUM, AVG, MIN y MAX condensan muchas filas en un valor. Sin GROUP BY, la tabla entera es un solo grupo.
• COUNT tiene tres formas: COUNT(*) cuenta filas, COUNT(columna) cuenta valores no nulos y COUNT(DISTINCT columna) cuenta valores distintos.
• Todos los agregados ignoran los NULL salvo COUNT(*), y SUM de puros nulos devuelve NULL, no cero. Decidir qué significa la ausencia es una decisión de negocio, no técnica.
• GROUP BY parte el resultado en grupos y devuelve una fila por grupo; toda columna del SELECT que no sea agregado debe estar en el GROUP BY (y SQLite no lo comprueba, lo cual es una trampa seria).
• HAVING filtra grupos; WHERE filtra filas. Lo que se pueda poner en WHERE, va en WHERE.
• El orden lógico de ejecución —FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT— explica por qué WHERE no ve los alias ni los agregados y ORDER BY sí.
• La agregación combinada con JOIN produce los informes reales: préstamos por sucursal, libros más prestados, actividad por socio. Con una regla de oro: con LEFT JOIN, COUNT(columna), nunca COUNT(*).
• La explosión de filas infla los recuentos cuando dos tablas independientes cuelgan de una tercera. Se detecta porque las cifras salen sospechosamente altas e idénticas, y se resuelve agregando cada rama por separado con CTE.
• COALESCE convierte NULL en un valor presentable y CASE WHEN (o FILTER en PostgreSQL) permite tabular varias columnas condicionales en una sola pasada.
• Las funciones de ventana con OVER (PARTITION BY ...) calculan agregados sin perder el detalle, y ROW_NUMBER, RANK y DENSE_RANK numeran y clasifican con distinto tratamiento de los empates.

Ya sabemos definir el esquema, poblarlo, consultarlo, cruzarlo y resumirlo. Falta la pregunta que sostiene todo lo demás: ¿quién garantiza que estos datos sigan siendo ciertos dentro de cinco años? Nuestros informes son fiables solo porque todos los socio_id de prestamos apuntan a socios que existen, y todos los libro_id de ejemplares, a libros del catálogo.

Eso lo garantiza la integridad referencial, y es el tema de la lección 02-06, con la que cerramos el módulo: cómo se declaran las claves ajenas, qué comprueba el gestor en cada INSERT, UPDATE y DELETE, qué hacer cuando se borra una fila de la que dependen otras (CASCADE, RESTRICT, SET NULL…), cómo detectar y limpiar las filas huérfanas que ya existen, y por qué SQLite no protege nada si no se lo pides expresamente.