En la lección anterior aprendimos a interrogar una tabla. Pero las preguntas que de verdad le interesan a BiblioRed no caben en una tabla sola: "¿quién tiene ahora mismo el ejemplar EJ-3081?", "¿qué socios no han cogido nunca nada prestado?", "¿de qué autor es el libro que más se retrasa?". Las respuestas están repartidas entre socios, prestamos, ejemplares, libros y autores.

Ese reparto no es un defecto: es exactamente lo que decidimos en la lección 02-01 al separar la obra (libros) del objeto físico (ejemplares), y al no repetir el nombre del socio en cada préstamo. La información se guarda una sola vez, en el sitio que le corresponde, y se recompone cuando hace falta. La herramienta que la recompone es el JOIN, la reunión ⋈ del álgebra relacional.

Esta es la lección donde SQL deja de parecer un buscador de tablas y empieza a parecer un lenguaje de consulta de verdad. Es larga y densa; tómatela con calma y ejecuta cada ejemplo sobre tu biblioredb.

1. Por qué hay que recomponer los datos
2. Producto cartesiano y CROSS JOIN
3. INNER JOIN: la reunión básica
4. LEFT JOIN y las preguntas negativas
5. RIGHT JOIN y FULL OUTER JOIN
6. Resumen visual de los tipos de JOIN
7. SELF JOIN: unir una tabla consigo misma
8. Encadenar tres o más tablas
9. Filtrar en ON o filtrar en WHERE
10. Subconsultas escalares
11. Subconsultas con IN, EXISTS y NOT EXISTS
12. Subconsultas correlacionadas
13. Tablas derivadas: subconsultas en FROM
14. Expresiones de tabla común: WITH
15. Operadores de conjunto: UNION, INTERSECT, EXCEPT
16. Errores comunes y consejos
17. Ejercicios
18. Conclusión

Mira la tabla prestamos en crudo:

Para un ser humano esto no dice nada: 14, 2, 15, 1… son referencias. El nombre del socio está en socios, el código del ejemplar en ejemplares y el título en libros. La alternativa —guardar el nombre y el título dentro de cada préstamo— es justamente lo que hacía la hoja de cálculo, y ya vimos el resultado: redundancia, inconsistencia y errores de tecleo.

El trato del modelo relacional es este: se guarda sin repetir, y se paga un JOIN al consultar. Es un trato excelente, porque escribir bien ocurre una vez y leer mal ocurre para siempre.

Antes de emparejar filas correctamente, hay que entender qué pasa si no las emparejas. El producto cartesiano × combina cada fila de una tabla con cada fila de la otra.

Primeras filas:

4 sucursales × 8 autores = 32 filas. Con socios (10) y libros (9) serían 90; con las tablas reales de BiblioRed, 12.000 × 8.000 = 96 millones.

¿Sirve para algo? Sí, en un caso concreto: generar todas las combinaciones posibles de dos conjuntos, por ejemplo para construir una rejilla de "cada sucursal × cada estado posible" que después se rellena con datos. Fuera de eso, un producto cartesiano en producción casi siempre es un accidente.

Antes de SQL-92 no existía la palabra JOIN: las tablas se listaban en el FROM separadas por comas y la condición de emparejamiento se escribía en el WHERE.

El peligro es evidente: si olvidas la condición del WHERE, obtienes un producto cartesiano en silencio. Doce préstamos por diez socios son 120 filas que parecen datos legítimos. Con tablas grandes, la consulta se cuelga.

Con la sintaxis moderna, JOIN ... ON, la condición está pegada a la unión y no se puede perder de vista. Usa siempre JOIN explícito.

INNER JOIN es un producto cartesiano seguido de un filtro: devuelve solo las parejas de filas que cumplen la condición. La palabra INNER es opcional (JOIN a secas significa INNER JOIN), pero escribirla deja claro que no es un LEFT.

Doce filas: una por préstamo. Marta Alsina aparece tres veces porque tiene tres préstamos; eso no es duplicación, es la realidad.

p y s son alias de tabla. No son obligatorios, pero sí muy recomendables:

• Acortan las referencias: s.apellidos en lugar de socios.apellidos.
• Son imprescindibles cuando dos tablas tienen columnas con el mismo nombre. Si escribes SELECT socio_id FROM prestamos JOIN socios ON ..., el gestor no sabe de cuál de las dos hablas:

• Son obligatorios en un SELF JOIN (apartado 7).

Consejo de estilo: usa iniciales reconocibles (s socios, p prestamos, e ejemplares, l libros, a autores, su sucursales) y sé coherente en todo el proyecto. En este curso siempre usaremos esas mismas.

Los cuatro socios que tienen algo pendiente de devolver, con el plazo de cada uno.

Cuando las columnas de ambas tablas se llaman exactamente igual, existe una abreviatura:

USING (socio_id) equivale a ON s.socio_id = p.socio_id, y además fusiona las dos columnas en una sola en el resultado. Es cómodo y nuestro esquema lo permite, porque nombramos las claves ajenas igual que las primarias.

Existe también NATURAL JOIN, que empareja automáticamente por todas las columnas de nombre coincidente:

Aquí ejemplares y libros comparten libro_id… pero si algún día alguien añade a ambas una columna observaciones, el NATURAL JOIN empezará a emparejar también por ella y la consulta cambiará de significado sin que nadie la haya tocado. Es magia implícita: evítala. ON explícito o, como mucho, USING.

INNER JOIN descarta lo que no empareja. A veces eso es justo lo que no quieres.

Devuelve 12 filas y solo aparecen 8 socios: Ramón Etxebarri (13) y Elena Roig (20) se han esfumado.

LEFT JOIN (abreviatura de LEFT OUTER JOIN) conserva todas las filas de la tabla izquierda; cuando no hay pareja a la derecha, rellena esas columnas con NULL.

14 filas: los 12 préstamos más las dos filas "vacías" de Etxebarri y Roig.

Y aquí llega uno de los patrones más útiles de todo SQL. Si las filas sin pareja son las que tienen NULL en las columnas de la derecha, basta con filtrarlas:

Los dos socios que nunca han tomado nada prestado. Es la diferencia − del álgebra relacional, implementada con un LEFT JOIN.

Detalle crucial: la columna que compruebas con IS NULL debe ser una que nunca pueda ser nula en la tabla derecha —la clave primaria es la elección segura—. Si comprobaras WHERE p.fecha_devolucion IS NULL obtendrías otra cosa completamente distinta (los préstamos abiertos, más los socios sin préstamos).

Otro caso real de BiblioRed: los ejemplares que nunca se han prestado, candidatos a expurgo.

Seis ejemplares que llevan en la estantería sin salir nunca. Justo el tipo de informe que la hoja de cálculo no podía producir.

RIGHT JOIN es la imagen especular de LEFT JOIN: conserva todas las filas de la tabla derecha.

Nueve filas: los ocho autores, con Óscar Barreda repetido por sus dos obras y Marina Escolá con NULL porque aún no tiene ninguna. Observa que "Memoria del Ensanche (1904)" no aparece: es el libro sin autor catalogado, y RIGHT JOIN conserva los autores, no los libros.

Toda consulta RIGHT JOIN se puede reescribir como LEFT JOIN invirtiendo las tablas, y esa es la forma que verás en el 95 % del código profesional:

Consejo: quédate con LEFT JOIN. Leer una consulta larga en la que unos JOIN van hacia la izquierda y otros hacia la derecha es innecesariamente difícil.

Conserva las filas sin pareja de ambos lados:

Diez filas: aparece tanto la autora sin libros como el libro sin autor. Es la consulta de auditoría por excelencia: enseña los dos lados descosidos de una vez.

RIGHT JOIN y FULL OUTER JOIN no existieron en SQLite hasta la versión 3.39 (junio de 2022). Si tu sqlite3 es anterior, esas dos consultas darán error de sintaxis. Comprueba tu versión con SELECT sqlite_version();. Soluciones:

• Reescribir el RIGHT JOIN como LEFT JOIN con las tablas invertidas (siempre posible).
• Simular el FULL OUTER JOIN con dos LEFT JOIN unidos por UNION (apartado 15).

LEFT JOIN e INNER JOIN, en cambio, funcionan en SQLite desde siempre.

Imagina dos tablas mínimas emparejadas por una clave:

• IZQ con claves 1, 2, 3
• DER con claves 2, 3, 4

Y el árbol de decisión que conviene tener en la cabeza al escribir una consulta:

No es un tipo distinto de JOIN: es un INNER o LEFT JOIN normal en el que las dos tablas son la misma. Sirve para comparar filas de una tabla entre sí, y por eso los alias son obligatorios: hay que poder distinguir las dos "copias".

Pregunta: ¿qué parejas de socios están dados de alta en la misma sucursal?

Diez parejas. La condición b.socio_id > a.socio_id hace dos cosas a la vez y es el truco que hay que memorizar:

1. Evita emparejar a cada socio consigo mismo (que sería a.socio_id = b.socio_id).
2. Evita el duplicado simétrico: si sale (Ferrán, Roig), no sale también (Roig, Ferrán).

Sin esa condición obtendrías 4×4 + 3×3 + 2×2 + 1×1 = 30 filas en lugar de 10.

Otro SELF JOIN útil en BiblioRed: otras obras del mismo autor.

Aquí sí queremos las dos direcciones (para poder recomendar desde cualquiera de los dos libros), por eso usamos <> en lugar de >. Óscar Barreda es el único autor con dos obras en el fondo.

El uso canónico del SELF JOIN en el mundo real son las jerarquías: una tabla empleados con una columna jefe_id que apunta a la propia tabla. BiblioRed no tiene ninguna, pero el mecanismo es idéntico.

Los JOIN se encadenan de arriba abajo: el resultado del primero se une con la tabla siguiente, y así sucesivamente. La consulta estrella de BiblioRed recorre cinco tablas.

Este es el listado que el bibliotecario quiere ver cada mañana. Y ya podemos responder a la pregunta del principio: quien tiene ahora mismo EJ-3081 es Marta Alsina, y debe devolverlo el 4 de agosto de 2026.

Tres decisiones de esa consulta merecen comentario:

• Empezamos por prestamos, no por socios. Cuando encadenas varias tablas, arrancar por la tabla "central" —la que tiene las claves ajenas hacia las demás— hace la consulta mucho más natural de leer.
• autores se une con LEFT JOIN. ¿Por qué? Porque libros.autor_id admite NULL (recuerda "Memoria del Ensanche"). Con un INNER JOIN, si alguien prestara ese ejemplar, el préstamo desaparecería del informe matinal sin que nadie se enterara. Es el error silencioso más frecuente al encadenar tablas: un INNER JOIN sobre una clave ajena opcional pierde filas.
• El orden en que escribes los JOIN no determina el orden de ejecución. El optimizador (lección 01-04) decide por su cuenta. Tú escribes para que se lea bien; él ejecuta para que corra rápido.

Esta distinción es sutil, se pregunta en todas las entrevistas y provoca resultados incorrectos a diario. Con INNER JOIN da exactamente igual dónde pongas la condición. Con LEFT JOIN, cambia el resultado por completo.

La razón está en el orden de evaluación:

1. ON se aplica mientras se emparejan las filas: decide qué es pareja y qué no.
2. WHERE se aplica después de construida la unión: descarta filas del resultado ya montado, incluidas las filas rellenas de NULL que el LEFT JOIN acababa de conservar.

Pregunta: "lista de todos los socios, indicando qué préstamos han hecho a partir de julio de 2026".

Diez filas: están todos los socios, que es lo que pedía la pregunta. Los que no tienen préstamos en julio salen con NULL.

Cuatro filas. El WHERE ha eliminado todas las filas con p.fecha_prestamo a NULL, porque NULL >= '2026-07-01' es DESCONOCIDO. El LEFT JOIN se ha convertido, de hecho, en un INNER JOIN.

Regla práctica: en un LEFT JOIN, las condiciones sobre la tabla derecha van en el ON; las condiciones sobre la tabla izquierda van en el WHERE. La única excepción es el patrón anti-join WHERE clave_derecha IS NULL, donde quieres deliberadamente ese efecto.

Una subconsulta es un SELECT dentro de otro SELECT, entre paréntesis. La variedad más simple es la escalar: devuelve exactamente una fila y una columna, es decir, un valor suelto, y por tanto se puede usar en cualquier sitio donde encaje un valor.

La subconsulta se ejecuta una vez, devuelve 2008, y la consulta externa lo usa como si lo hubieras escrito a mano. La ventaja es que no tienes que saber el valor de antemano: si mañana se corrige el año de ese libro, la consulta sigue siendo correcta.

Si una subconsulta escalar devuelve más de una fila, el gestor da error:

Si devuelve cero filas, en cambio, no hay error: el resultado es NULL, y la comparación entera pasa a DESCONOCIDO, así que la consulta externa devuelve cero filas… en silencio. Otra aplicación de la lógica de tres valores.

Esto es equivalente a un LEFT JOIN con libros. Como norma general, prefiere el JOIN: es más legible, más flexible (puedes traer varias columnas de la tabla unida) y el optimizador suele tratarlo mejor. La subconsulta en el SELECT se reserva para cuando necesitas un único dato calculado y el JOIN complicaría la consulta.

Cuando la subconsulta devuelve varias filas, no se puede comparar con =, pero sí preguntar por pertenencia o por existencia.

Compáralo con la versión JOIN. Con JOIN habría que añadir DISTINCT para no repetir a los socios con varios préstamos abiertos; con IN no hace falta, porque la pertenencia a un conjunto es sí o no. Esa es su ventaja principal.

Funciona porque reservas.libro_id es NOT NULL. Ahora la misma idea sobre una columna que sí admite nulos:

Cero filas, cuando la respuesta correcta es "Marina Escolá". El motivo lo vimos en 02-01: la subconsulta devuelve {1, 2, 3, 4, 5, 6, 7, NULL} (el NULL es el de "Memoria del Ensanche"), y 8 NOT IN (..., NULL) se traduce en 8 <> 1 AND ... AND 8 <> NULL, cuyo último término es DESCONOCIDO. Y VERDADERO AND DESCONOCIDO es DESCONOCIDO, que no pasa el filtro. Con un solo NULL en la lista, NOT IN no devuelve jamás ninguna fila.

Las tres soluciones, de peor a mejor:

Las tres devuelven ahora:

EXISTS no compara valores: pregunta si la subconsulta devuelve al menos una fila. Devuelve TRUE o FALSE, nunca DESCONOCIDO, y por eso es inmune a la trampa anterior.

El SELECT 1 es una convención: como solo importa si hay filas, no qué filas, se pone una constante. SELECT * funcionaría igual y el gestor lo optimiza idénticamente.

Mismo resultado que el anti-join del apartado 4. Tres formas de expresar la misma pregunta:

Las subconsultas de EXISTS que acabas de ver tienen una particularidad: mencionan una columna de la consulta externa (s.socio_id). Eso las convierte en correlacionadas: no se pueden ejecutar por sí solas, porque dependen de la fila que se esté evaluando en cada momento.

Un ejemplo de BiblioRed que responde a una pregunta genuinamente difícil de otro modo: ¿qué ejemplares pertenecen a un libro que tiene alguna reserva activa? (son los que hay que apartar en cuanto vuelvan al mostrador).

Cinco ejemplares en alerta: los tres de "El mapa del tiempo" (dos reservas activas) y los dos de "Los pilares de la Tierra" (una).

Sobre el rendimiento: la descripción "se evalúa una vez por fila externa" es el modelo mental, no lo que ocurre necesariamente. Los optimizadores modernos suelen transformar una subconsulta correlacionada en un JOIN internamente. Aun así, sobre tablas grandes conviene medirlo; en la lección 06-03 aprenderás a comprobarlo con EXPLAIN.

Una subconsulta también puede ocupar el lugar de una tabla en el FROM. Se llama tabla derivada y, como cualquier tabla, necesita un alias.

Los cuatro préstamos abiertos, repartidos entre las sucursales donde vive cada ejemplar. La tabla derivada ab (de "abiertos") existe solo durante la consulta.

Las tablas derivadas resuelven casos en los que necesitas trabajar sobre un resultado intermedio, sobre todo cuando ese intermedio incluye agregados —cosa que veremos en la lección 02-05—. Su inconveniente es la legibilidad: si anidas dos o tres, la consulta se vuelve un laberinto de paréntesis que hay que leer de dentro afuera.

Una CTE (Common Table Expression, expresión de tabla común) es una tabla derivada a la que se le da nombre antes de usarla. Misma potencia, legibilidad incomparablemente mejor.

Devuelve exactamente lo mismo que el apartado anterior, pero ahora la consulta se lee de arriba abajo, como un procedimiento: "primero calculo los abiertos, después los cruzo con las sucursales".

Se separan por comas, y cada una puede usar las anteriores:

Tres de los cuatro préstamos abiertos corresponden a socios de la sucursal Norte; el cuarto es de Diego Salom, dado de alta en Sur.

Ventajas de las CTE:

• Legibilidad: cada bloque tiene nombre y propósito.
• Reutilización: una CTE se puede referenciar varias veces en la consulta principal, mientras que una tabla derivada habría que escribirla dos veces.
• Depuración: puedes ejecutar el contenido de la CTE por separado para ver qué produce.

Notas de dialecto:

• WITH es estándar y funciona en PostgreSQL (desde 8.4) y SQLite (desde 3.8.3).
• Existe WITH RECURSIVE para recorrer jerarquías y grafos (árboles de categorías, listas de materiales). Es potente y queda fuera del alcance de este curso introductorio.
• Históricamente PostgreSQL trataba cada CTE como una barrera de optimización; desde la versión 12 las integra en la consulta principal salvo que escribas MATERIALIZED. Si trabajas con una versión anterior y notas lentitud, esa puede ser la causa.

Los JOIN combinan tablas a lo ancho (añaden columnas). Los operadores de conjunto las combinan a lo alto (apilan filas). Son la unión ∪, la intersección ∩ y la diferencia − del álgebra relacional.

Para usarlos, las dos consultas deben ser compatibles: mismo número de columnas y tipos compatibles, en el mismo orden. Los nombres de columna los pone la primera consulta.

Seis socios. La primera consulta devuelve {14, 15, 17, 19} y la segunda {16, 18, 15}; Iván Pereda (15) está en las dos y aparece una sola vez, porque UNION elimina duplicados.

Siete filas: UNION ALL no elimina duplicados. Y precisamente por eso es más rápido: no tiene que ordenar ni comparar nada. Regla práctica: usa UNION ALL salvo que necesites la deduplicación. Mucha gente escribe UNION por costumbre y paga el coste sin motivo.

Iván Pereda: tiene "Los pilares de la Tierra" en préstamo y "El mapa del tiempo" reservado.

EXCEPT no es simétrico: A EXCEPT B no es lo mismo que B EXCEPT A. Si invirtieras el orden obtendrías {16, 18}, los socios con reserva activa y sin préstamos abiertos.

• INTERSECT y EXCEPT también eliminan duplicados por defecto; existen INTERSECT ALL y EXCEPT ALL.
• El ORDER BY va al final, una sola vez, y ordena el resultado combinado. No puedes poner uno en cada rama (salvo entre paréntesis con LIMIT).
• En Oracle, EXCEPT se llama MINUS.
• SQLite admite UNION, UNION ALL, INTERSECT y EXCEPT desde siempre; es su punto fuerte frente a los JOIN externos.

Un uso muy práctico en SQLite antiguo: simular un FULL OUTER JOIN.

Las diez filas del apartado 5, sin necesitar FULL OUTER JOIN.

• Olvidar la condición de unión. Con la sintaxis antigua de comas produce un producto cartesiano silencioso. Usa siempre JOIN ... ON.
• Usar INNER JOIN sobre una clave ajena que admite NULL. Pierdes filas sin previo aviso. Si la columna puede ser nula, LEFT JOIN.
• Poner la condición de la tabla derecha en el WHERE de un LEFT JOIN. Lo convierte en INNER JOIN y te quedas sin las filas que querías conservar. Va en el ON.
• Comprobar IS NULL sobre la columna equivocada en un anti-join. Usa siempre la clave primaria de la tabla derecha, que nunca puede ser nula por sí misma.
• NOT IN con una subconsulta que puede devolver NULL. Cero filas, siempre, en silencio. Usa NOT EXISTS.
• Confundir "más filas de las esperadas" con un error del JOIN. Si un socio tiene tres préstamos, aparecerá tres veces: eso es correcto. El problema surge al contar (COUNT) sobre ese resultado, y lo veremos en la lección 02-05.
• Encadenar JOIN sin alias. Con cinco tablas y columnas homónimas, una consulta sin alias es ilegible e incluso ambigua para el gestor.
• Usar NATURAL JOIN. Empareja por nombres coincidentes y cambia de significado cuando alguien añade una columna.
• Anidar tablas derivadas de tres niveles. Conviértelas en CTE con WITH: mismo resultado, la mitad de tiempo para entenderla.
• Consejo: cuando una consulta multitabla devuelva algo raro, quítale cláusulas hasta que funcione. Ejecuta primero el JOIN a pelo con SELECT *, mira cuántas filas salen y ve añadiendo condiciones de una en una.
• Consejo: escribe siempre la condición de unión en el orden ON tabla_nueva.columna = tabla_ya_presente.columna. Es una convención menor, pero al leer una consulta de cinco tablas se agradece muchísimo.

1. Lista los ejemplares con el título del libro al que pertenecen y el nombre de su sucursal. Ordena por sucursal y código.
2. Muestra las reservas activas con el nombre del socio y el título del libro reservado.
3. Lista todos los libros con el apellido de su autor, incluidos los que no tienen autor catalogado.
4. Muestra los préstamos devueltos con retraso, indicando socio, título y las dos fechas.

1. ¿Qué libros no tienen ningún ejemplar en la sucursal Centro (sucursal_id = 1)? Resuélvelo con NOT EXISTS.
2. ¿Qué socios no han hecho ninguna reserva nunca? Resuélvelo de dos maneras: con anti-join y con NOT EXISTS.
3. ¿Qué sucursales no tienen ningún ejemplar en estado prestado?
4. ¿Qué autores tienen obra en el fondo pero ninguna de sus obras se ha prestado jamás?

1. Usando una CTE, obtén los ejemplares disponibles de libros que tienen alguna reserva activa, con su código, título y sucursal. Es la lista de "apartar para reservas".
2. Con operadores de conjunto, obtén los identificadores de los socios que han hecho alguna reserva pero nunca un préstamo.
3. Lista, para cada sucursal, los socios dados de alta en ella y los ejemplares que custodia… y explica por qué no debe hacerse con un solo JOIN de tres tablas.

Solución 1

Quince filas. Las dos primeras y las dos últimas:

Con INNER JOIN habrías perdido "Memoria del Ensanche (1904)".

Solución 2

Han reservado alguna vez los socios 11, 14, 15, 16 y 18; los otros cinco, nunca.

Ningún autor cumple las dos condiciones. Óscar Barreda (4) parecía candidato, porque "Manual de jardinería urbana" no se ha prestado nunca, pero su otra obra, "Álgebra para impacientes", sí (préstamo 4). Es un buen recordatorio de que en una condición "ninguna de sus obras" hay que examinar todas las obras del autor, no una a una.

Solución 3

Tres ejemplares que el personal debe apartar. El DISTINCT de la CTE es importante: "El mapa del tiempo" tiene dos reservas activas, y sin él cada ejemplar suyo aparecería duplicado.

Los cinco socios que han reservado alguna vez (11, 14, 15, 16, 18) han hecho también algún préstamo. Prueba la operación inversa para ver la diferencia:

Por qué no debe hacerse así: socios y ejemplares no están relacionadas entre sí; ambas cuelgan de sucursales de forma independiente. Al unirlas en la misma consulta se produce un producto cartesiano dentro de cada sucursal: la sucursal Centro tiene 4 socios y 6 ejemplares, así que genera 24 filas. El total es 4×6 + 3×4 + 2×3 + 1×2 = 24 + 12 + 6 + 2 = 44 filas, ninguna de las cuales significa nada: emparejan a Nuria Bastos con un ejemplar que no ha tocado.

Este fenómeno tiene nombre —explosión de filas o fan trap— y es una de las causas más frecuentes de recuentos inflados. Las dos soluciones correctas:

Esta lección ha convertido las siete tablas aisladas de BiblioRed en un sistema consultable:

• Los datos están repartidos a propósito —cada hecho en un solo sitio— y se recomponen al consultar con la reunión ⋈ del álgebra relacional.
• El producto cartesiano (CROSS JOIN) es el punto de partida conceptual y el accidente clásico de la sintaxis antigua de comas.
• INNER JOIN ... ON devuelve solo lo que empareja; los alias de tabla son casi obligatorios y NATURAL JOIN es magia que conviene evitar.
• LEFT JOIN conserva la tabla izquierda, y su combinación con WHERE clave_derecha IS NULL —el anti-join— es el patrón para responder a toda pregunta que empiece por "los que nunca…": socios sin préstamos, ejemplares nunca prestados.
• RIGHT JOIN y FULL OUTER JOIN completan el cuadro (y llegaron tarde a SQLite, en la versión 3.39).
• El SELF JOIN compara filas de una tabla consigo misma, con la condición > para no duplicar parejas simétricas.
• Encadenar cinco tablas —socio → préstamo → ejemplar → libro → autor— responde a las preguntas reales del mostrador, siempre que uses LEFT JOIN donde la clave ajena admita nulos.
• Filtrar en ON no es lo mismo que filtrar en WHERE en un LEFT JOIN: el WHERE lo degrada a INNER JOIN.
• Las subconsultas en sus cinco formas: escalar, con IN, con EXISTS/NOT EXISTS, correlacionadas y como tabla derivada en el FROM. Con una regla grabada a fuego: NOT EXISTS en vez de NOT IN cuando pueda haber NULL.
• Las CTE con WITH, que convierten una consulta laberíntica en un procedimiento legible de arriba abajo.
• Los operadores de conjunto: UNION (deduplica), UNION ALL (más rápido), INTERSECT y EXCEPT (que no es simétrico).

Fíjate en que hemos rozado repetidamente un límite: podemos listar los préstamos de cada socio, pero no contarlos; podemos ver los ejemplares de cada sucursal, pero no cuántos hay; el ejercicio 3.3 se ha quedado a medias porque para resumir dos ramas hacía falta algo que aún no tenemos.

Ese algo llega en la lección 02-05, Agregación y Agrupación de Datos: COUNT, SUM, AVG, MIN y MAX, la cláusula GROUP BY, la diferencia entre HAVING y WHERE, el orden lógico en que se ejecuta realmente una consulta y —muy importante después de lo que acabamos de ver— el problema de contar filas infladas por un JOIN. Con ella, BiblioRed pasará de responder "qué hay" a responder "cuánto hay".