Los dos terminales están abiertos y el esquema de BiblioRed está a mano, tal como quedamos al cerrar el módulo 6. A partir de aquí el curso cambia de registro: no vas a leer conceptos nuevos, vas a escribir SQL. Esta lección es un banco de quince ejercicios sobre la red de bibliotecas municipales de Vallmar, ordenados por dificultad creciente, y su forma de uso es muy concreta.

Cómo trabajar esta lección. Lee el enunciado. Antes de mirar nada más, escribe tu consulta en la sesión psql y ejecútala. Compara tu resultado con el bloque Resultado esperado. Solo entonces despliega la Solución y compárala con la tuya: es perfectamente normal —y con frecuencia deseable— que tu consulta sea distinta de la propuesta y dé el mismo resultado, porque en SQL casi siempre hay más de un camino. Lo que no es normal es leer la solución primero: en ese caso el ejercicio no te enseña nada, solo te da la sensación de haber entendido.

Si una consulta no te sale, resiste al menos cinco minutos antes de mirar la Pista. El músculo que estás entrenando aquí no es el de recordar la sintaxis de HAVING, sino el de traducir una pregunta en lenguaje humano a una consulta, y eso solo se entrena fallando.

Esta lección cubre SELECT, WHERE, JOIN, agregación y subconsultas. Las funciones de ventana, las transacciones y los planes de ejecución no aparecen aquí: son el material de la lección 07-04.

Los ejercicios usan un juego de datos concreto y pequeño —8 socios, 12 materiales, 15 ejemplares, 20 préstamos— para que puedas verificar cada resultado a ojo. Si has ido construyendo BiblioRed a lo largo del curso, tus datos serán distintos y los resultados no coincidirán. Por eso conviene partir de cero con el script de esta lección.

Crea una base de datos limpia y ejecuta este script completo. En PostgreSQL:

Ejecuta esta consulta antes de empezar. Si algún número no coincide, el script no se ha ejecutado entero:

La fecha de referencia. Varios ejercicios calculan retrasos. Para que los resultados sean reproducibles hoy y dentro de dos años, las soluciones usan la fecha literal DATE '2026-08-02' en lugar de CURRENT_DATE. En producción escribirías CURRENT_DATE; aquí necesitamos que el número de días no cambie.

SQLite. El juego de datos funciona en SQLite cambiando SERIAL/BOOLEAN por enteros y NUMERIC(8,2) por REAL. Donde haya diferencias relevantes en una consulta, la solución lo indica.

1. Bloque A — Básico: consultas sobre una sola tabla (ejercicios 1-3)
2. Bloque B — Intermedio: consultas sobre varias tablas (ejercicios 4-7)
3. Bloque C — Intermedio: agregación y agrupación (ejercicios 8-10)
4. Bloque D — Avanzado: subconsultas, tablas derivadas y CTE (ejercicios 11-12)
5. Bloque E — Avanzado: informes de gestión reales (ejercicios 13-15)
6. Errores comunes y consejos
7. Ejercicios de refuerzo

Dificultad: Básico

Enunciado. El servicio de patrimonio quiere el listado de los cinco materiales más antiguos del catálogo. Devuelve tres columnas con estos encabezados exactos: Título, Editorial y Año. Ordena de más antiguo a más moderno y, cuando dos materiales sean del mismo año, alfabéticamente por título.

Solución

Resultado esperado

Explicación. Hay tres detalles que separan una consulta correcta de una consulta descuidada:

• Las comillas dobles en los alias. AS Título fallaría o se convertiría en título en minúsculas, porque PostgreSQL pasa a minúsculas todo identificador sin comillas. Para conservar la mayúscula y la tilde hacen falta comillas dobles, no simples: las comillas simples delimitan cadenas de texto, no identificadores. AS 'Título' es un error de sintaxis.
• El segundo criterio de ordenación. Sin , titulo ASC, las dos filas de 2007 saldrían en un orden que el motor no garantiza. Puede parecerte estable hoy y cambiar mañana al añadir una fila o al crear un índice. Un ORDER BY que no desempata no es determinista, y en un listado con LIMIT eso significa que la fila que ves puede variar entre ejecuciones.
• LIMIT va después de ORDER BY, no antes: primero se ordena el conjunto entero, luego se cortan cinco filas. Si lo hicieras al revés obtendrías cinco filas cualesquiera y luego ordenadas, que es una pregunta distinta.

En SQLite la consulta funciona igual, pero los alias entrecomillados se comportan de forma más laxa (acepta comillas dobles y también corchetes).

Dificultad: Básico

Enunciado. Resuelve las cinco preguntas siguientes, cada una con su propia consulta:

• (a) Materiales publicados entre 2000 y 2010, ambos incluidos, con título y año.
• (b) Ejemplares cuyo estado sea prestado o reservado, con código, estado y sucursal.
• (c) Materiales cuyo título contenga la palabra «Chernóbil», sin importar mayúsculas ni minúsculas.
• (d) Materiales sin portada (portada_url no informada) y autores sin año de nacimiento.
• (e) Los tipos de material distintos que hay en el catálogo y cuántas editoriales distintas aparecen.

Pista. Para (c), en PostgreSQL existe ILIKE; para (d), recuerda que = NULL nunca es verdadero.

Solución

Resultado esperado

(a) 5 filas: Kafka en la orilla (2002), El corazón helado (2007), Un mundo sin fin (2007), El mapa del tiempo (2008), Los pilares de la Tierra (serie) (2010).

(b)

(c) 2 filas: 909 «Documental: la voz de Chernóbil» y 912 «Voces de Chernóbil».

(d) 6 materiales sin portada (903, 905, 907, 909, 910, 911) y 1 autor sin año de nacimiento (Delia Marchetti).

(e) 4 tipos (audiolibro, dvd, libro, revista) y 8 editoriales distintas.

Explicación. Cada apartado esconde una trampa clásica:

• BETWEEN 2000 AND 2010 incluye los dos extremos. Si necesitas excluirlos, BETWEEN no sirve: hay que escribir > 2000 AND < 2010. Y el orden importa: BETWEEN 2010 AND 2000 devuelve cero filas, sin error y sin aviso.
• IN ('prestado','reservado') es exactamente equivalente a estado = 'prestado' OR estado = 'reservado'. Es más legible y, sobre todo, evita el error de precedencia de escribir WHERE material_id = 901 AND estado = 'prestado' OR estado = 'reservado', que no significa lo que parece: AND liga más fuerte que OR.
• ILIKE es una extensión de PostgreSQL. En SQLite, LIKE ya es insensible a mayúsculas para caracteres ASCII, pero no para las tildes ni para la Ó de «Chernóbil»; allí lo portable es WHERE lower(titulo) LIKE lower('%chernóbil%').
• portada_url = NULL devuelve NULL, que en un WHERE se comporta como falso: la consulta no da error, da cero filas. Es uno de los fallos más difíciles de detectar porque no hay ningún síntoma.
• count(DISTINCT editorial) cuenta 8 y no 9: hay 12 materiales pero solo 8 editoriales distintas, y count(DISTINCT ...) ignora los NULL (aquí no hay editoriales nulas, pero conviene recordarlo).

Dificultad: Básico

Enunciado. Tres operaciones de mantenimiento. En las tres, antes de modificar nada, escribe y ejecuta el SELECT con el mismo WHERE para ver exactamente qué filas vas a tocar.

• (a) Da de alta al socio 19, Rubén Ortells, correo [email protected], alta hoy (2026-08-02), sucursal Este, activo.
• (b) El socio 18 (Berta Quintana) se traslada de la sucursal Sur a la sucursal Norte. Actualiza su sucursal.
• (c) Borra las reservas expiradas cuya fecha de expiración sea anterior al 30 de junio de 2026.

Solución

Resultado esperado

Explicación. Tres hábitos que evitan casi todos los desastres de un mostrador:

1. Lista de columnas explícita en el INSERT. INSERT INTO socios VALUES (...) funciona hasta el día en que alguien añade una columna a socios; entonces todos los INSERT sin lista se rompen o, peor, colocan los valores en la columna equivocada.
2. El SELECT con el mismo WHERE, primero. No es una recomendación de estilo: es la única forma de saber cuántas filas vas a tocar antes de tocarlas. Un UPDATE socios SET sucursal_id = 2 sin WHERE afecta a los ocho socios y no hay «deshacer» fuera de una transacción.
3. RETURNING (PostgreSQL) devuelve las filas realmente afectadas. Es la confirmación posterior de que el WHERE hizo lo previsto. SQLite lo soporta desde la versión 3.35; en MySQL no existe y hay que consultar de nuevo.

Sobre (c): si intentaras borrar la reserva 501 (atendida), no fallaría nada porque ninguna tabla apunta a reservas. Pero si intentaras borrar el socio 14 sí fallaría, porque prestamos, reservas, multas e inscripciones lo referencian. Es la integridad referencial del módulo 2 haciendo su trabajo.

Deshaz los cambios antes de seguir, para que los resultados posteriores coincidan: DELETE FROM socios WHERE socio_id = 19; UPDATE socios SET sucursal_id = 3 WHERE socio_id = 18; INSERT INTO reservas VALUES (503,16,906,'2026-06-01','2026-06-15','expirada'), (506,12,901,'2026-03-30','2026-04-13','expirada');

Dificultad: Intermedio

Enunciado. Un socio pregunta en el mostrador dónde puede encontrar «Los pilares de la Tierra» (material 901). Devuelve todos sus ejemplares con el código, el estado y el nombre de la sucursal donde está cada uno, ordenados por sucursal.

Pista. La sucursal está en ejemplares.sucursal_id, no en materiales.

Solución

Resultado esperado

Explicación. El JOIN conecta dos tablas por la pareja clave ajena → clave primaria: ejemplares.sucursal_id apunta a sucursales.sucursal_id. Los alias e y s no son decorativos: en cuanto haya dos tablas con una columna del mismo nombre —y aquí sucursal_id está en las dos— escribir sucursal_id a secas produce el error column reference "sucursal_id" is ambiguous.

El error fácil aquí es olvidar la condición del ON. Un FROM ejemplares e, sucursales s WHERE e.material_id = 901 sin condición de reunión produce un producto cartesiano: 3 ejemplares × 4 sucursales = 12 filas, todas con aspecto plausible. Es un error que no salta a la vista con tres filas y que con 40.000 ejemplares tumba el servidor.

Dificultad: Intermedio

Enunciado. Lista todos los préstamos abiertos (los que aún no se han devuelto) con: nombre y apellidos del socio, código del ejemplar, título del material, sucursal a la que pertenece el ejemplar y fecha de devolución prevista. Ordena por fecha prevista.

Pista. La cadena es socios → prestamos → ejemplares → materiales, y la sucursal cuelga de ejemplares.

Solución

Resultado esperado

Explicación. Cuatro JOIN encadenados no son más difíciles que uno: cada JOIN añade una tabla y su condición, y el resultado acumulado va creciendo hacia la derecha. La clave está en empezar por la tabla que contiene las filas que quieres contar —aquí prestamos, porque una fila del resultado es un préstamo— y colgar las demás como decoración.

Dos observaciones:

• p.fecha_devolucion IS NULL es la definición de «préstamo abierto» en este esquema. No hay una columna abierto; el hecho de no tener fecha de devolución es el hecho de estar abierto. Es un uso de NULL legítimo: significa «todavía no ha ocurrido».
• La sucursal viene de ejemplares, no de socios. Marta Alsina está adscrita a Centro y sus dos préstamos son de ejemplares de Centro, así que la diferencia no se nota; pero si hubiera tomado prestado un ejemplar de Norte, su.nombre diría Norte. Confundir «la sucursal del socio» con «la sucursal del ejemplar» es el error de modelo más frecuente en este esquema. En SQLite, || concatena igual que en PostgreSQL.

Dificultad: Intermedio

Enunciado. Dos preguntas de la memoria anual:

• (a) ¿Qué materiales no se han prestado nunca? Incluye también los que ni siquiera tienen ejemplares.
• (b) ¿Qué socios no tienen ningún préstamo registrado? Indica si están activos.

Pista. Un LEFT JOIN seguido de WHERE <columna de la tabla derecha> IS NULL deja exactamente las filas que no encontraron pareja.

Solución

Resultado esperado

(a)

(b)

Explicación. El patrón anti-join tiene tres partes que hay que respetar juntas:

1. LEFT JOIN, no INNER JOIN. El INNER descarta precisamente las filas que buscamos.
2. La condición del emparejamiento va en el ON.
3. El filtro IS NULL va en el WHERE y debe apuntar a una columna de la tabla derecha que nunca sea nula por sí misma: por eso usamos p.prestamo_id (clave primaria, jamás nula) y no p.fecha_devolucion, que es nula en los préstamos abiertos y nos colaría cinco falsos positivos.

En (a) el segundo LEFT JOIN es imprescindible. Los materiales 907 y 911 no tienen ejemplares: tras el primer LEFT JOIN, e.ejemplar_id ya es NULL, y el segundo LEFT JOIN propaga ese NULL a p.prestamo_id, de modo que entran en el resultado. Si hubieras usado INNER JOIN ejemplares, esos dos materiales habrían desaparecido y el informe habría dicho que solo hay un material sin prestar. El anti-join no falla con error: falla dando menos filas de la cuenta.

El material 910 es distinto: sí tiene ejemplar (EJ-3094), pero ese ejemplar nunca ha salido. Los tres casos —sin ejemplares y con ejemplares sin salida— caen en el mismo resultado, que es justo lo que pedía el enunciado.

Dificultad: Intermedio

Enunciado. Para una campaña de «si te gustó, te gustará», necesitamos las parejas de materiales del mismo autor. Cada pareja debe aparecer una sola vez (no queremos ver A-B y también B-A) y ningún material debe emparejarse consigo mismo. Muestra el autor y los dos títulos.

Pista. La condición m1.material_id < m2.material_id resuelve los dos problemas a la vez.

Solución

Resultado esperado

Explicación. Un SELF JOIN es un JOIN de una tabla consigo misma; lo único que lo hace posible son los alias obligatorios (m1, m2), que convierten una tabla en dos «copias» independientes para el motor.

La condición m1.material_id < m2.material_id hace dos trabajos:

• Con <> en su lugar obtendrías 10 filas: cada pareja duplicada en los dos órdenes.
• Sin ninguna condición adicional (solo m2.autor_id = m1.autor_id) obtendrías 15 filas: las 10 anteriores más las 5 de cada material consigo mismo.

Fíjate también en que los materiales 910 y 911 (las revistas, con autor_id nulo) no aparecen, y es correcto: NULL = NULL no es verdadero, así que dos filas con autor desconocido nunca se emparejan. Ese comportamiento, que en otros contextos molesta, aquí es exactamente el deseado: no sabemos si son del mismo autor.

Dificultad: Intermedio

Enunciado. Tres informes de inventario y economía:

• (a) Número de ejemplares por sucursal, de mayor a menor.
• (b) Número de ejemplares por sucursal y estado.
• (c) Número, importe total e importe medio de las multas por motivo, mostrando solo los motivos con más de una multa.

Solución

Resultado esperado

(a)

(b)

(c)

Explicación. El punto que hay que interiorizar es el orden lógico de ejecución que vimos en 02-05: FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.

De ahí salen las dos reglas prácticas:

• WHERE filtra filas antes de agrupar; HAVING filtra grupos después. WHERE count(*) > 1 es un error de sintaxis, y no por capricho: cuando se evalúa el WHERE los grupos todavía no existen.
• Todo lo que va en el SELECT y no está dentro de una función de agregado tiene que estar en el GROUP BY. Si en (a) añadieras s.sucursal_id al SELECT sin añadirlo al GROUP BY, PostgreSQL daría error. (Curiosamente sí lo aceptaría si agruparas por s.sucursal_id, porque es clave primaria y determina funcionalmente a s.nombre: PostgreSQL reconoce esa dependencia. SQLite y MySQL en modo laxo no dan error nunca y devuelven un valor arbitrario, que es mucho peor.)

En (c), el motivo perdida desaparece por el HAVING pese a ser la multa más cara (24,00 €). Es un recordatorio de que un HAVING mal elegido puede ocultar justo lo importante.

round(avg(...), 2) necesita que el argumento sea numeric; como importe es NUMERIC(8,2), funciona. Si la columna fuera double precision, PostgreSQL exigiría round(avg(importe)::numeric, 2).

Dificultad: Intermedio

Enunciado. Queremos el número de préstamos de cada socio, incluidos los socios que no han pedido nada nunca (deben aparecer con 0). Escribe la consulta y explica por qué count(*) daría un resultado incorrecto.

Pista. Cuenta lo que el LEFT JOIN no ha encontrado.

Solución

Resultado esperado

Explicación. Esta es probablemente la trampa más cara del SQL de informes, porque no produce ningún error: produce un número plausible y equivocado.

• count(*) cuenta filas. Tras el LEFT JOIN, Óscar Vilanova genera una fila —la suya, con todas las columnas de prestamos a NULL—, así que count(*) devuelve 1.
• count(p.prestamo_id) cuenta valores no nulos de esa columna. En la fila de Óscar, p.prestamo_id es NULL, así que no cuenta nada: 0.

La regla que conviene memorizar: en un LEFT JOIN, cuenta siempre una columna de la tabla derecha, y que esa columna sea su clave primaria. Si contaras count(p.fecha_devolucion), obtendrías el número de préstamos ya devueltos (Marta Alsina daría 3 en lugar de 5), que es otra pregunta perfectamente válida... pero no la que te han hecho.

Lo mismo aplica a sum(): sum(importe) sobre un grupo sin filas devuelve NULL, no 0. Si el informe se va a mostrar en pantalla, envuélvelo: COALESCE(sum(importe), 0).

Dificultad: Intermedio

Enunciado. Los cinco materiales más prestados de todo el histórico, con el título, el nombre del autor (o (sin autor) si no lo tiene) y el número de préstamos. Desempata alfabéticamente por título.

Pista. El préstamo apunta al ejemplar, no al material: hay que subir un escalón.

Solución

Resultado esperado

Explicación. Tres decisiones deliberadas en esta consulta:

• Agrupar por m.material_id, no por m.titulo. Si dos materiales distintos compartieran título —cosa perfectamente posible: una edición en papel y otra en audiolibro— agrupar por el título los fundiría en una sola fila. Agrupar por la clave primaria y añadir el título al GROUP BY para poder proyectarlo es el patrón seguro.
• LEFT JOIN autores, no INNER JOIN. Las revistas 910 y 911 tienen autor_id nulo. Aquí no se nota porque no están entre las más prestadas, pero un INNER JOIN las expulsaría silenciosamente de cualquier ranking futuro.
• COALESCE en la concatenación completa, no en cada trozo. a.nombre || ' ' || a.apellidos con a.nombre nulo devuelve NULL entero, porque cualquier concatenación con NULL es NULL. Por eso el COALESCE envuelve la expresión ya montada.

El empate entre «Kafka en la orilla» y «Los pilares de la Tierra» (3 préstamos cada uno) se resuelve por título: K antes que L. Sin ese segundo criterio, el orden entre ambos no estaría garantizado y el «top 5» podría cambiar de una ejecución a otra.

Este ranking es un LIMIT 5 global. La versión «el más prestado de cada sucursal» necesita funciones de ventana y la verás en 07-04.

Dificultad: Avanzado

Enunciado. Cinco preguntas, cada una con la herramienta que le corresponde:

• (a) Materiales anteriores al año medio del catálogo (subconsulta escalar).
• (b) Socios con alguna multa pendiente, usando IN.
• (c) Socios con algún préstamo sin devolver, usando EXISTS.
• (d) Sucursales sin ningún ejemplar extraviado, usando NOT EXISTS.
• (e) Para cada socio, la fecha de su último préstamo (subconsulta correlacionada); los socios sin préstamos deben salir con NULL.

Solución

Resultado esperado

(a) La media del catálogo es 2009,58, así que salen 6 filas: Tokio blues (1987), Los pilares de la Tierra (1989), Kafka en la orilla (2002), El corazón helado (2007), Un mundo sin fin (2007), El mapa del tiempo (2008).

(b) Socios 13 (Mestre), 14 (Alsina) y 15 (Pereda).

(c) Socios 13, 14, 15 y 16.

(d)

(e)

Explicación. Cada forma de subconsulta responde a una forma distinta de pregunta:

Dos advertencias que valen su peso en horas de depuración:

1. NOT IN y los NULL no se llevan bien. Si escribieras WHERE sucursal_id NOT IN (SELECT sucursal_id FROM ejemplares WHERE estado = 'extraviado') y esa subconsulta pudiera devolver un NULL, el resultado sería cero filas siempre, porque x NOT IN (1, NULL) se evalúa a NULL. NOT EXISTS no tiene ese problema: por eso es la forma recomendada para los anti-joins con subconsulta.
2. SELECT 1 dentro de EXISTS no es una superstición ni una optimización: es una declaración de intenciones. A EXISTS le da igual lo que proyectes —el motor ni siquiera lo evalúa—, y escribir SELECT 1 deja claro al siguiente lector que las columnas no importan.

En (e), la correlacionada devuelve NULL para los socios sin préstamos porque max() sobre un conjunto vacío es NULL. Es exactamente lo que pedía el enunciado; si quisieras un texto, COALESCE(..., 'nunca') requeriría convertir la fecha a texto primero.

Dificultad: Avanzado

Enunciado. Tres consultas que reorganizan el problema antes de responderlo:

• (a) El número medio de préstamos por socio activo, usando una tabla derivada.
• (b) Una ficha por sucursal con su número de socios y su número de ejemplares, usando dos CTE.
• (c) Una agenda unificada de contactos: todos los correos de socios activos y de ponentes, en una sola lista, con una columna que indique de dónde sale cada uno.

Pista. En (b), no intentes hacerlo con dos JOIN directos sobre sucursales: los conteos se multiplicarían entre sí.

Solución

Resultado esperado

(a) 2.86 — hay 7 socios activos (todos menos Óscar Vilanova) que suman 20 préstamos: 20 / 7 = 2,857...

(b)

(c) 10 filas: 3 ponentes (Calduch, Lemus, Marchetti) y 7 socios activos.

Explicación. Las tres son variantes del mismo movimiento: calcular un resultado intermedio y consultarlo como si fuera una tabla.

En (a), la agregación doble es obligatoria. avg(count(*)) no existe: no se pueden anidar funciones de agregado. Hay que agregar una vez (préstamos por socio), materializar ese resultado como tabla derivada y agregar otra vez. Fíjate en el AS conteos: en PostgreSQL una tabla derivada necesita alias o el motor da error, aunque no lo uses.

En (b) está la lección importante. Si escribieras esto:

...el count(DISTINCT ...) te salvaría de milagro, pero un count(*) daría 3 × 8 = 24 para Centro. El JOIN de dos ramas independientes contra la misma tabla produce un producto cartesiano dentro de cada sucursal. Este es el error de agregación más caro que existe porque el resultado parece razonable. La solución robusta es agregar cada rama por separado —en CTE o en subconsultas— y reunir después.

En (c), UNION elimina duplicados y UNION ALL no. Aquí no hay duplicados posibles porque la primera columna ya los distingue, así que UNION ALL sería más rápido. Las dos ramas deben tener el mismo número de columnas y tipos compatibles, y los nombres los pone siempre la primera rama: por eso los alias solo hacen falta arriba. El ORDER BY va una sola vez, al final, y afecta al conjunto unido.

Dificultad: Avanzado

Enunciado. Intervención municipal pide la recaudación de multas: por mes y método de pago, el número de pagos y el importe total, más una columna canal que valga 'presencial' para efectivo y tarjeta y 'en línea' para pasarela. Añade una última consulta con el total pendiente de cobro (multas en estado pendiente).

Pista. to_char(fecha_pago, 'YYYY-MM') agrupa por mes en PostgreSQL.

Solución

Resultado esperado

Total recaudado: 11,70 €. Pendiente: 3 multas por 30,60 €.

Explicación. El informe tiene tres puntos finos:

• Se agrupa por pagos, no por multas. Una multa puede cobrarse en varios plazos: la multa 5 (6,50 €, deterioro, Nuria Bastos) se cobró en dos pagos, 4,00 € con tarjeta en mayo y 2,50 € por pasarela también en mayo. Si el informe se construyera sobre multas, ese caso se contaría mal en cuanto los dos plazos cayeran en meses distintos. La pregunta «cuánto entró en caja en marzo» se responde siempre sobre la tabla de movimientos, no sobre la de deudas.
• GROUP BY 1, 2, 3 agrupa por posición en el SELECT. Es cómodo, pero frágil: si insertas una columna al principio, la agrupación cambia sin avisar. En consultas que van a durar, escribe los nombres o repite la expresión CASE completa en el GROUP BY.
• Las multas condonada y anulada no aparecen en ninguna parte del informe, y es correcto: no se han cobrado ni se van a cobrar. La multa 6 (4,00 €, condonada) y la 8 (3,20 €, anulada) suman 7,20 € que no son ni ingreso ni deuda. Un informe que las mezclara con las pendientes inflaría la previsión de cobro en un 23 %.

En SQLite, to_char no existe: se usa strftime('%Y-%m', fecha_pago).

Dificultad: Avanzado

Enunciado. A fecha 2 de agosto de 2026, lista los préstamos vencidos y sin devolver: socio, código y título, fecha prevista, días de retraso y el recargo a razón de 0,20 €/día con un tope de 15,00 €. Ordena por recargo descendente.

Pista. La resta de dos DATE en PostgreSQL devuelve un entero de días. El tope se aplica con LEAST.

Solución

Resultado esperado

Explicación. Tres cosas que hay que mirar con lupa:

• El WHERE lleva dos condiciones y las dos son imprescindibles. fecha_devolucion IS NULL selecciona los préstamos abiertos; fecha_devolucion_prevista < '2026-08-02' selecciona los vencidos. Con solo la primera, los préstamos 17 y 19 (previstos para el 10 y el 12 de agosto) aparecerían con días de retraso negativos y un recargo negativo: la biblioteca debiéndole dinero al socio.
• El tope se aplica y se nota. Sin LEAST, Sonia Mestre pagaría 19,60 € (98 × 0,20). El reglamento fija 15,00 €, y LEAST(a, b) devuelve el menor de los dos. En MySQL la función también se llama LEAST; en SQLite es MIN(a, b) con dos argumentos, que no es la función de agregado MIN() pese al nombre.
• La aritmética de fechas es específica de cada motor. En PostgreSQL, date - date devuelve integer (días). En SQLite hay que escribir julianday('2026-08-02') - julianday(fecha_devolucion_prevista), y en MySQL DATEDIFF('2026-08-02', fecha_devolucion_prevista). Es de los primeros sitios donde una consulta portable deja de serlo.

Nota de coherencia: el ejemplar EJ-3093 figura como extraviado y su préstamo sigue abierto. Ya tiene una multa por pérdida (24,00 €), así que en el proceso real habría que excluirlo de los recargos por retraso. Añadir AND e.estado <> 'extraviado' es una decisión de negocio perfectamente defendible; el enunciado no la pedía, pero un informe que se entrega a dirección debería documentarla.

Dificultad: Avanzado

Enunciado. Para los eventos ya celebrados, calcula por sucursal: número de eventos, plazas ofertadas, plazas ocupadas y porcentaje de ocupación con un decimal. Solo cuentan como ocupadas las inscripciones en estado confirmada o asistida (las canceladas y las de lista de espera, no).

Pista. Si unes eventos con inscripciones y sumas plazas_ofertadas, el resultado estará inflado. Agrega primero por evento.

Solución

Resultado esperado

Explicación. Este ejercicio reúne casi todo el bloque en una sola consulta, y su valor está en la CTE.

Por qué la CTE es obligatoria. Si sumaras plazas_ofertadas directamente sobre el JOIN de eventos con inscripciones, cada evento aparecería tantas veces como inscripciones tenga. El evento 101 tiene 5 inscripciones, así que sus 12 plazas ofertadas se contarían 5 veces: 60. Centro pasaría de 52 a 100 plazas ofertadas y la ocupación caería del 28,8 % al 15 %. El error no da ningún síntoma: los números siguen siendo enteros razonables. La regla general es: cuando un informe suma un atributo del «uno» y otro atributo del «muchos», el del «uno» hay que agregarlo aparte.

El filtro por estado va en el FILTER, no en el WHERE. sum(...) FILTER (WHERE ...) aplica la condición solo al agregado, dejando intactas las demás filas del grupo. Si pusieras i.estado IN ('confirmada','asistida') en el WHERE de la CTE, un evento cuyas inscripciones fueran todas canceladas desaparecería del informe en lugar de aparecer con 0 ocupadas. FILTER es SQL estándar y PostgreSQL lo soporta; el equivalente portable es sum(CASE WHEN i.estado IN ('confirmada','asistida') THEN i.plazas_ocupadas ELSE 0 END), que funciona también en SQLite y MySQL.

100.0 y no 100. Si escribes 100 * sum(ocupadas) / sum(ofertadas) con enteros, PostgreSQL hace división entera y Centro daría 28 en lugar de 28.8, y un caso como 5/8 daría 62 en vez de 62.5. Multiplicar primero por 100.0 fuerza la aritmética decimal. Este error aparece en producción constantemente.

El LEFT JOIN sigue siendo necesario aunque en estos datos todos los eventos celebrados tengan inscripciones: si mañana se celebra un evento al que no se apuntó nadie, con INNER JOIN desaparecería del denominador y la ocupación media saldría artificialmente alta.

1. = NULL en lugar de IS NULL. No da error: da cero filas. Cada vez que una consulta te devuelva un conjunto vacío inesperado, esta es la primera sospecha.

2. count(*) en un LEFT JOIN. Cuenta 1 donde debería contar 0. Cuenta siempre la clave primaria de la tabla derecha.

3. Sumar atributos del «uno» sobre un JOIN con el «muchos». Los totales se multiplican por el número de filas hijas. Agrega cada rama en su propia CTE o subconsulta.

4. HAVING y WHERE intercambiados. WHERE filtra filas antes de agrupar, HAVING filtra grupos después. Poner en HAVING una condición que podría ir en WHERE funciona pero es más lento: obliga a agrupar filas que se van a descartar.

5. ORDER BY sin desempate. Un LIMIT sobre un orden no determinista devuelve filas distintas en ejecuciones distintas. Añade siempre un criterio único como último desempate.

6. División entera. 100 * a / b con enteros trunca. Fuerza decimales con 100.0 o con ::numeric.

7. NOT IN con subconsultas que pueden devolver NULL. Devuelve cero filas siempre. Usa NOT EXISTS.

8. Confundir la sucursal del socio con la sucursal del ejemplar. Son dos claves ajenas distintas hacia la misma tabla. Cuando la pregunta dice «por sucursal», averigua qué sucursal antes de escribir el JOIN.

9. Olvidar el ON de un JOIN. Producto cartesiano silencioso. Con tablas pequeñas parece que funciona; con 40.000 ejemplares no.

10. Concatenar con NULL. 'a' || NULL es NULL. Envuelve la expresión completa en COALESCE, no cada trozo.

Consejo de método. Construye las consultas grandes de dentro hacia fuera: escribe primero el FROM con sus JOIN y un SELECT *, comprueba el número de filas, añade el WHERE, vuelve a comprobar, y solo al final agrupa y proyecta. El 90 % de los errores de agregación se detectan mirando cuántas filas hay antes de agrupar.

Consejo de lectura. Cuando heredes una consulta ajena, léela en el orden lógico de ejecución (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY), no en el orden en que está escrita. Es el orden en el que el motor la entiende.

Sin pistas y más exigentes. Escribe cada uno como una sola consulta.

Para Marta Alsina (socio 14), devuelve una única fila con: apellidos, número total de préstamos, número de préstamos devueltos con retraso, número de préstamos abiertos, importe total de sus multas, importe efectivamente pagado e importe pendiente.

Lista los materiales que tienen ejemplares en tres o más sucursales distintas, con el título, el número de sucursales y el número total de ejemplares. Un material con cinco ejemplares en la misma sucursal no cuenta.

Devuelve una lista de socios en riesgo con una columna motivo. Un socio está en riesgo si tiene algún préstamo vencido sin devolver a 2026-08-02 (motivo 'préstamo vencido') o si acumula más de 10 € en multas pendientes (motivo 'deuda alta'). Un socio puede aparecer por los dos motivos.

Solución A

Las tres cifras económicas van en subconsultas escalares precisamente para evitar el problema del ejercicio 15: si unieras multas y pagos al mismo JOIN que prestamos, cada multa se repetiría cinco veces (una por préstamo) y el total saltaría de 26,20 € a 131,00 €. Los FILTER sobre count(*) funcionan aquí porque el LEFT JOIN con prestamos no duplica nada: cada préstamo es una fila.

Solución B

Solo «Los pilares de la Tierra» está repartido en tres sucursales (Centro, Sur y Este). El DISTINCT dentro del count es lo que distingue «tres sucursales» de «tres ejemplares»: sin él, el material 906 (dos ejemplares, en Sur y Centro) seguiría sin colarse, pero un material con tres ejemplares en Centro sí lo haría, y sería un error.

Solución C

Marta Alsina aparece dos veces, que es justo lo que pedía el enunciado; por eso hay que usar UNION ALL y no UNION (aunque aquí UNION daría lo mismo, porque la columna motivo ya diferencia las filas). Nota que Iván Pereda no sale: tiene una multa pendiente, pero de 1,60 €, y su préstamo abierto vence el 12 de agosto. Y Sonia Mestre sale solo por el préstamo, porque sus 5,00 € pendientes no llegan al umbral.

Has escrito quince consultas sobre BiblioRed que recorren todo el SQL del módulo 2, esta vez sin red: proyección con alias, filtros con BETWEEN, IN, LIKE e IS NULL, ordenación determinista con LIMIT, DML con la disciplina del SELECT previo, INNER JOIN de dos y de cuatro tablas, LEFT JOIN con el patrón anti-join, SELF JOIN, agregación con GROUP BY de una y dos columnas, HAVING, la diferencia entre COUNT(*) y COUNT(columna), las cinco formas de subconsulta, tablas derivadas, CTE, UNION y tres informes de gestión que ya se parecen a lo que pide una dirección de servicio.

Más importante que la sintaxis son los tres reflejos que deberían haberse instalado: mirar antes de modificar, comprobar el número de filas antes de agregar y desconfiar de todo informe que suma un atributo del lado «uno» a través de un JOIN con el lado «muchos». Ninguno de los tres se lo enseña a nadie un mensaje de error, porque los tres fallan en silencio.

La siguiente lección cambia de músculo. En 07-02, Ejercicios de Diseño de Esquemas, no habrá tablas que consultar: habrá enunciados de requisitos —un videoclub, una plataforma de cursos, una clínica, un sistema de tarifas históricas— y tendrás que construir el esquema desde cero, pasando por el diagrama ER, el CREATE TABLE y las restricciones que codifican las reglas de negocio. Uno de los cinco casos será una ampliación de BiblioRed, para que compruebes lo distinto que es diseñar sobre un esquema que ya existe y no puedes romper.