El proyecto está hecho: el esquema se crea, los datos cargan, las quince consultas devuelven lo que deben y los índices están justificados. Y aun así falta la mitad del trabajo, porque hay una cosa que casi nadie enseña y que decide cómo se valora todo lo anterior: contarlo. Un modelo excelente mal explicado se corrige como un modelo mediocre; un número correcto presentado sin su definición se lee como un número equivocado; y un repositorio que nadie consigue ejecutar en cinco minutos es, a efectos prácticos, un repositorio vacío.

Esta lección es esa mitad: el informe apartado por apartado, cómo se presentan resultados de datos sin engañar de buena fe, las preguntas de la defensa y cómo prepararlas, cómo se publica el proyecto para que alguien pueda ejecutarlo, y la autoevaluación con la rúbrica de 12-02 convertida en checklist. Y después, el cierre de todo el curso.

1. El informe: 04-informe.md
2. Cómo presentar resultados de datos
3. La defensa: las preguntas que te van a hacer
4. Publicar el proyecto
5. Autoevaluación: la rúbrica como checklist
6. Errores Comunes y Consejos
7. Ejercicios
8. Conclusión del curso

El informe no es documentación técnica —para eso están los comentarios del DDL— ni un diario de lo que hiciste. Es un documento que responde a tres preguntas: qué has construido, por qué así y qué sabes que no está bien todavía. Entre 4 y 8 páginas; más de eso no se lee, y menos de eso suele significar que no hay decisiones contadas.

• Escribe en presente y en primera persona del plural o impersonal: "el préstamo cuelga de ejemplares porque…", no "decidí que…" ni "se podría haber hecho…". Firme, sin arrogancia.
• Una decisión, un párrafo, un porqué. El patrón que funciona es siempre el mismo: qué hice · qué alternativa había · por qué esta · qué me cuesta. Ese cuarto elemento —el precio que pagas— es lo que distingue a alguien que ha decidido de alguien que ha acertado por casualidad.
• Nada de adjetivos sin dato. "El rendimiento es excelente" no dice nada; "la consulta de vencidos pasa de 340 ms a 4 ms con el índice parcial, sobre 50 000 préstamos" sí.
• Ni una captura de pantalla de código. Bloques de texto, que se copian, se buscan y se leen en cualquier pantalla.

El diagrama ER no habla solo. Un lector que ve doce cajas y dieciséis flechas no entiende nada si no le dices por dónde empezar. La secuencia que funciona, y cabe en un párrafo bajo el diagrama:

1. La columna vertebral primero. "El sistema gira sobre prestamos: una fila por ejemplar prestado a un socio." Una frase, y el lector ya sabe dónde mirar.
2. El giro, con un ejemplo concreto. "obras guarda el título; ejemplares, cada volumen físico. De El jardín de las horas hay tres ejemplares en dos sedes." Un ejemplo con nombres propios vale más que tres párrafos de teoría.
3. Las dos relaciones que hay que mirar dos veces. La N:M obras_autores y la reflexiva de bibliotecarios.
4. Las tablas satélite en una línea cada una. multas, reservas, materias, editoriales: no necesitan más.

Y una decisión de formato: el diagrama va como imagen, no como código. Exporta el mermaid a PNG o SVG y déjalo en informe/modelo-er.png. Quien lea el informe en cualquier visor de Markdown lo verá; quien lea el código fuente, también.

Cuatro elementos, siempre en el mismo orden, y una sola consulta por página:

La pregunta — ¿qué ejemplares llevan más tiempo fuera de plazo, y de quién son?

La definición — préstamo vencido = sin fecha_devolucion y con fecha_prevista anterior a hoy. La multa aún no existe (RN-10): la columna es una estimación.

La consulta y su resultado — la vista v_prestamos_vencidos, con las tres filas: 36 días y 7,20 € de Lena Fuentes, y dos préstamos de un día.

La lectura — tres préstamos vencidos sobre seis activos es una tasa alta, pero dos de los tres se han pasado un solo día: el problema real es uno, y lleva más de un mes.

Ese cuarto elemento es el que casi nadie escribe y el único que interesa a quien decide. Una tabla sin lectura obliga al lector a hacer tu trabajo; y si la hace, sacará su propia conclusión, que puede no ser la correcta.

Reconocer los límites no resta, suma, porque demuestra que entiendes el sistema mejor que quien cree haberlo cerrado. Para este proyecto, cinco limitaciones honestas y bien escogidas:

1. El índice parcial impide dos préstamos activos, no dos préstamos históricos solapados; la solución sería EXCLUDE con btree_gist (12-04).
2. El estado del socio (bloqueado) se mantiene fuera de la base: nada garantiza que corresponda con su deuda real. Sería un trabajo programado nocturno o un trigger sobre multas.
3. No hay auditoría: si alguien cambia una fecha_devolucion a mano, no queda rastro.
4. La cola de reservas no contempla prioridades, solo FIFO puro, y la caducidad de 3 días no se aplica sola.
5. El sistema es de una red, no multiinstitución: no hay préstamo interbibliotecario ni tabla de organizaciones.

Todo esto es 11-04 aplicado a tu propio informe, y es lo que separa una tabla de un argumento.

Define la métrica antes de enseñarla, siempre. No hay excepciones. En este proyecto hay tres pares de definiciones que se confunden con facilidad y que hay que fijar por escrito:

Tabla o gráfico. La regla práctica: tabla cuando el lector va a leer valores concretos o son menos de una decena de filas; gráfico cuando lo que importa es la forma —una tendencia, una comparación de magnitudes, una distribución—. La serie mensual de RC-12 pide gráfico; el pivote sede × materia de RC-15, con sus tres filas, pide tabla. Y el pivote nunca un gráfico de tarta con seis porciones, que es la forma más eficaz de que nadie compare nada.

Todo número necesita su denominador. "6 multas" no significa nada; "6 multas sobre 30 préstamos devueltos, un 20,0 %" sí. Y al revés: un porcentaje sin la cifra absoluta es igual de tramposo. La regla del proyecto, que sale directamente de 11-04: si el denominador baja de unas decenas, publica el número absoluto y no el porcentaje. Decir que la Biblioteca Infantil tiene "un 100 % de préstamos infantiles" es cierto y es ruido: son 6 préstamos.

Redondeo y unidades. Redondea solo al presentar, nunca en los pasos intermedios. El dinero, a dos decimales y con el símbolo (7,20 €); los días, enteros; las medias, a un decimal (32,3 días) porque el segundo decimal es falsa precisión con 36 filas. Y la unidad en la cabecera de la columna, no repetida en cada celda.

Honestidad sobre el tamaño de la muestra. Este proyecto tiene 36 préstamos. Cualquier frase del tipo "la materia más leída es Narrativa" debe ir con su "con 12 de 36 préstamos" al lado. Y hay dos resultados que el informe debe presentar con su aviso: el "tercer socio más lector" de la Biblioteca Infantil tiene cero préstamos porque esa sede solo tiene tres socios (RC-13), y la media de días por materia se calcula sobre 6 u 8 préstamos, no sobre miles. Escribirlo no te hace parecer inseguro: te hace parecer alguien de quien fiarse.

Y la cifra de control, siempre visible. Cada tabla del informe debería poder cuadrarse con un total conocido. Las de este proyecto: 36 préstamos, 20 ejemplares, 12 obras, 27,20 € en multas. Si un desglose no suma eso, el desglose está mal — y si el lector puede comprobarlo de un vistazo, confía en el resto.

Da igual que sea un tribunal, una revisión con tu equipo o una entrevista de trabajo con el proyecto encima de la mesa: las preguntas son casi siempre las mismas seis. Prepáralas por escrito, en dos o tres frases cada una.

Tres consejos de preparación que valen más que ensayar el discurso:

• Ten el EXPLAIN a mano, en un fichero, junto al antes y el después. Es la respuesta a media docena de preguntas y no se puede improvisar.
• Ten la base cargada y psql abierto. Si alguien pregunta "¿y cuántos socios tienen deuda?", responderlo ejecutando vale diez veces más que responderlo de memoria.
• Prepara el resumen de dos minutos. Dominio, giro central (obra/ejemplar), lo que más te costó y una limitación conocida. Es lo que dirás en el ascensor, en la entrevista y en la primera frase de la defensa.

Un proyecto que no se puede ejecutar no existe. El listón es concreto: alguien que nunca lo ha visto debe tenerlo funcionando en cinco minutos.

Cinco apartados y ni uno más: qué es (dos líneas), requisitos (PostgreSQL 16), cómo ejecutarlo (los comandos, copiables), qué esperar (la tabla de recuentos, para que sepa si ha ido bien) y dónde está el informe.

Esa última línea es el detalle que distingue un README bueno de uno correcto: le dice al lector cómo saber que ha funcionado. Sin ella, ejecuta los tres ficheros, no ve errores y se queda sin saber si la carga está completa.

01-esquema.sql es idempotente porque borra y recrea: perfecto para un entregable, imposible en producción, donde borrar las tablas es borrar los datos. Un apartado del informe que diga "para producción, esto se convertiría en migraciones versionadas con Flyway o Liquibase, y el cambio del índice de título sería un CREATE INDEX CONCURRENTLY para no bloquear la tabla" demuestra que sabes la diferencia (05-06, 11-05). Añadir dos ficheros de migración de ejemplo cuesta diez minutos y se nota.

• Credenciales. Ni en el README, ni en un .env, ni en un comentario, ni "temporalmente". Git recuerda: una contraseña subida y borrada después sigue estando en el historial. Usa un .env.example con valores falsos y un .gitignore que excluya el .env real.
• Datos personales reales. Ni de clientes, ni de compañeros, ni tuyos. Los del proyecto son inventados y los correos van a @example.com, que es un dominio reservado justo para esto (RS-07).
• Volcados de producción. Un pg_dump de una base real en un repositorio es una fuga de datos, no un fichero de pruebas.
• Ficheros de 200 MB. Si necesitas volumen, sube el generador (generate_series), no los datos generados.

La rúbrica de 12-02, convertida en preguntas de sí o no. Respóndelas antes de entregar, con el proyecto delante y siendo duro contigo mismo.

Modelo (25 %)

• [ ] ¿obras y ejemplares son dos tablas, y prestamos cuelga de ejemplares?
• [ ] ¿reservas cuelga de obras, no de ejemplares?
• [ ] ¿La N:M obras_autores tiene PK compuesta y datos propios (rol, orden)?
• [ ] ¿bibliotecarios tiene su FK reflexiva, nulable solo en la dirección?
• [ ] ¿Cada desnormalización está escrita y justificada en el informe?

Integridad (20 %)

• [ ] ¿Están declaradas las 14 RI, con nombre y anotadas con su número?
• [ ] ¿RI-03 está resuelta en la base con el índice único parcial?
• [ ] ¿Has ejecutado los INSERT que deben fallar, y fallan?
• [ ] ¿Cada ON DELETE es coherente con la semántica de su relación?

Consultas (25 %)

• [ ] ¿Las quince ejecutan sin un solo error?
• [ ] ¿Ninguna pierde filas por un JOIN mal elegido ni las duplica?
• [ ] ¿Todos los rankings tienen desempate explícito?
• [ ] ¿Cada métrica lleva su definición en un comentario?
• [ ] ¿Has validado al menos dos totales por dos caminos?

Rendimiento (10 %) · Seguridad (10 %) · Entrega (10 %)

• [ ] ¿Cada índice tiene una consulta concreta que lo usa, y has escrito lo que decides no indexar?
• [ ] ¿Hay dos EXPLAIN antes/después con volumen suficiente para que signifiquen algo?
• [ ] ¿Los tres roles existen, ninguno tiene DELETE sobre el histórico y lo demuestras con has_table_privilege?
• [ ] ¿Todos los datos personales son ficticios y las bajas son lógicas?
• [ ] ¿Los cuatro ficheros se ejecutan en orden sobre una base vacía, dos veces seguidas?
• [ ] ¿El informe tiene los siete apartados, incluido el de limitaciones?

Si respondes que no a alguna, arréglala antes de entregar. Ninguna de estas casillas cuesta más de media hora, y cada una vale más que reescribir una consulta que ya funcionaba.

• Escribir el informe la última noche. Las decisiones se justifican mucho mejor el día que se toman. Un fichero decisiones.md abierto desde el primer día se convierte solo en el apartado 3.
• Contar el proceso en lugar del resultado. A nadie le interesa que primero pusieras una tabla libros y luego la dividieras. Interesa el modelo final y por qué. El proceso solo aparece si explica una decisión.
• Enseñar las quince consultas en el informe. Están en 03-consultas.sql. En el informe van tres o cuatro, elegidas, con su resultado y su lectura.
• Publicar un porcentaje sobre 6 casos. Con estos volúmenes, casi todo porcentaje miente. Cifra absoluta y denominador.
• Decir "nada" cuando te preguntan qué harías distinto. Es la respuesta que peor sienta: significa que no has mirado tu trabajo con distancia. Ten dos preparadas.
• Un README que empieza por la arquitectura. Empieza por cómo se ejecuta. La arquitectura la lee quien ya lo tiene funcionando.
• Consejo: pide a alguien que lo ejecute delante de ti sin ayudarle. En diez minutos sabrás qué falta en el README, y no hay forma más barata de averiguarlo.
• Consejo: lee el informe en voz alta. Las frases que no puedes leer sin tropezar son las que nadie va a entender.
• Consejo: guarda una versión del proyecto tal como lo entregaste. Dentro de un año querrás enseñarlo, y querrás que sea el que defendiste, no uno que tocaste después.

Escribe el apartado 3 del informe (decisiones de diseño) completo: entre seis y ocho decisiones, cada una con su alternativa descartada, el motivo y el precio que pagas. Debe incluir obligatoriamente la separación obra/ejemplar, fecha_prevista, el índice parcial y la cola de reservas.

Prepara la defensa de dos minutos: escríbela, cronométrala y recórtala hasta que quepa. Debe contener el dominio, el giro central del modelo, la decisión técnica de la que estés más orgulloso, una cifra concreta y una limitación conocida.

Un compañero escribe en su informe: "La Biblioteca Central es claramente la más eficiente de la red: concentra el 55,6 % de los préstamos." (1) ¿Es cierto el dato? (2) Da tres razones por las que la conclusión no se sostiene. (3) ¿Qué escribirías en su lugar?

Solución 1 — No hay una respuesta única, pero sí una plantilla que se corrige bien, cuatro elementos por decisión. Ejemplo, para que veas el nivel de detalle esperado:

ejemplares como tabla propia. Alternativa descartada: una columna num_ejemplares en obras, como el stock de un catálogo comercial. Por qué: el ejemplar tiene sede propia, estado físico propio e historia propia, y sin fila propia sería imposible saber cuál de los tres volvió; el préstamo dejaría de poder apuntar a un objeto concreto. Qué me cuesta: una tabla más, un JOIN más en casi todas las consultas del catálogo, y que "cuántos libros hay" pase a tener dos respuestas legítimas —12 obras y 20 ejemplares— que hay que distinguir en cada informe.

Y las señales de que el apartado está mal escrito: decisiones sin alternativa ("usé claves subrogadas"), alternativas de paja (comparar tu solución con una absurda), y ninguna mención al precio. Toda decisión de diseño tiene un coste; si no lo encuentras, es que no has decidido nada.

Solución 2 — La estructura que cabe en dos minutos, con los tiempos:

El error típico es gastar 90 segundos en la lista de tablas. Nadie recuerda una lista de tablas; todo el mundo recuerda "tres ejemplares en dos sedes".

Solución 3 — (1) El dato es cierto: 20 de 36 préstamos son de la Central, que es el 55,6 %. La aritmética está bien. (2) La conclusión no se sostiene por tres motivos. (a) "Eficiencia" no es "volumen". La Central tiene 10 de los 20 ejemplares y 7 de los 15 socios; con la mitad del fondo hacer el 56 % de los préstamos es casi exactamente lo esperado. Una métrica de eficiencia sería préstamos por ejemplar —2,0 en la Central frente a 2,0 en la Infantil, que con 3 ejemplares hizo 6 préstamos—, y entonces la conclusión desaparece. (b) Las sedes no son comparables: la Infantil abrió en 2024 y las otras en 2018 y 2021, y su público y su fondo son de otra naturaleza. (c) El tamaño de muestra: 36 préstamos en total y 6 en la Infantil; un solo préstamo mueve varios puntos porcentuales.

(3) Algo así: "La Central concentra 20 de los 36 préstamos (55,6 %), en línea con su peso en el fondo: custodia 10 de los 20 ejemplares. Normalizado por ejemplar, las tres sedes rinden de forma parecida (2,0 · 1,4 · 2,0 préstamos por ejemplar), sobre volúmenes demasiado pequeños para afirmar diferencias." Menos rotundo y mucho más útil — que es, casi siempre, la diferencia entre un análisis y un titular.

Aquí se acaba, así que conviene mirar atrás antes de cerrar.

Empezaste sin saber qué era una tabla y acabas de diseñar un sistema entero. Ese es el recorrido:

• Módulos 1 y 2 — los cimientos. Qué es SQL y qué lugar ocupa, PostgreSQL instalado, los tipos de datos, el modelo relacional con sus claves y su normalización, y TiendaVerde cargada. Después, SELECT: columnas, alias, WHERE, DISTINCT, ORDER BY y la paginación con LIMIT y con keyset.
• Módulos 3 y 4 — combinar y resumir. Los JOIN en todas sus formas, el LEFT JOIN y el anti-join que encuentran lo que no está, el self join sobre relaciones reflexivas y los operadores de conjuntos. Y el filtrado fino —LIKE, IN, BETWEEN, la lógica de tres valores de los NULL— con la agregación, el GROUP BY y el HAVING.
• Módulos 5 y 6 — escribir y transformar. CREATE TABLE con sus seis restricciones, INSERT, UPDATE, DELETE y el borrado lógico, el upsert y las migraciones con ALTER TABLE. Y las funciones: cadenas, números, fechas, CAST, COALESCE, CASE y el pivote.
• Módulos 7 y 8 — profundidad y velocidad. Subconsultas escalares, correlacionadas, EXISTS, derivadas y LATERAL, con el criterio para elegir entre JOIN, subconsulta y CTE. Y los índices: cómo funciona un B-tree, cuáles crear y cuáles no, y EXPLAIN para dejar de adivinar.
• Módulos 9 y 10 — fiabilidad y potencia. Transacciones, ACID, MVCC, SAVEPOINT, niveles de aislamiento, bloqueos y SKIP LOCKED. Y las herramientas grandes: vistas y materializadas, CTE y recursivas, funciones de ventana, procedimientos, triggers y JSON.
• Módulo 11 — el oficio. Los casos de uso que reaparecen siempre, las buenas prácticas y sus antipatrones, la seguridad con la inyección SQL y el modelo de roles, el análisis de datos donde definir importa más que consultar, y el SQL real de una aplicación web con su pool, su ORM y su N+1.
• Módulo 12 — hacerlo tú. Un dominio nuevo, un encargo con las imprecisiones de un encargo real, y de ahí a un sistema completo: doce tablas, catorce restricciones declaradas, quince consultas, siete índices justificados, tres roles y un informe.

Qué sabes hacer ahora que no sabías al empezar. No es "escribir consultas": eso es la parte fácil. Es esto:

• Leer un enunciado de negocio y sacar de él un modelo, distinguiendo entidades de atributos y detectando cuándo una misma palabra significa dos cosas.
• Hacer que la base de datos defienda sus propias reglas, en lugar de confiar en que todo el mundo se acuerde de validar.
• Escribir una consulta y saber si está bien, comprobando recuentos y validando totales por dos caminos.
• Saber por qué una consulta es lenta y qué índice la arregla, con un plan de ejecución delante en vez de una corazonada.
• Decidir qué se guarda y qué se calcula, qué se encapsula y qué no, y defender cada decisión con su alternativa y su precio.
• Presentar un resultado sin engañar de buena fe: con su definición, su denominador y su tamaño de muestra.

Hacia dónde seguir. Ninguno de estos caminos es obligatorio, y todos empiezan donde este curso termina:

Y la lectura, corta y bien elegida: la documentación oficial de PostgreSQL, que es de las mejores que existen y se lee sorprendentemente bien; SQL Performance Explained, de Markus Winand, para índices y planes; Designing Data-Intensive Applications, de Martin Kleppmann, para entender qué hay debajo de todo esto; y The Art of PostgreSQL, de Dimitri Fontaine, para seguir escribiendo mejor SQL.

Queda una última cosa, y es la que de verdad marca la diferencia: usarlo. El SQL que se aprende y no se practica se olvida en seis meses, y el que se usa se afila solo. Coge el proyecto que acabas de hacer y estíralo —añade el préstamo interbibliotecario, la auditoría, las notificaciones—; ofrécete a escribir el informe que en tu equipo saca alguien a mano cada mes; abre la consola de la base de datos que ya usas y pregúntale algo que nadie le haya preguntado.

Doce módulos después, la frase con la que empezó el curso vuelve con otro sentido: SQL es el lenguaje con el que se habla con los datos. Ya lo hablas. Lo que digas con él depende de ti.