La lección anterior terminaba diciendo que queda una cosa que no se aprende leyendo: hacerlo tú. Aquí empieza. Durante once módulos has trabajado sobre TiendaVerde, una base de datos que te venía dada: el esquema estaba escrito, los datos cargados y los huecos deliberados colocados donde las lecciones los necesitaban. En un trabajo real eso no pasa nunca. Lo que llega es un correo, una reunión de cuarenta minutos y unas hojas de cálculo, y de ahí tienes que salir con un modelo, un DDL, unos datos y unas consultas que respondan a preguntas que nadie te ha formulado todavía con precisión.

Por eso el proyecto final no es TiendaVerde otra vez. Es un dominio nuevo —hermano, pero distinto— que ejercita exactamente lo mismo y te obliga a modelar desde cero: la red de bibliotecas públicas de Alvorada. Tiene dos giros que TiendaVerde no tenía y que son justamente donde se distingue a quien ha entendido el modelo relacional de quien ha memorizado consultas: el préstamo tiene estados y fechas, con sus retrasos y sus multas, y un mismo título tiene varios ejemplares físicos.

1. El encargo, tal como llega
2. Leer el encargo con ojos de modelador
3. El giro del proyecto: obra frente a ejemplar
4. Las reglas de negocio, numeradas
5. El ciclo de vida de un préstamo
6. Qué entregas y qué queda fuera del alcance
7. TiendaVerde como mapa: dónde sirve y dónde se rompe
8. Cómo se organiza el trabajo
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

Lo que sigue es el correo de Helena Corvo, directora de la red de bibliotecas municipales de Alvorada. Léelo entero antes de seguir, y léelo como lo que es: la palabra de alguien que sabe de bibliotecas y no de bases de datos.

Buenos días,

Somos tres bibliotecas municipales: la Central, la de Vila Nova y la Infantil do Parque, que abrimos hace poco. Entre las tres tenemos unos cuantos miles de socios y ahora mismo lo llevamos todo con hojas de cálculo, una por biblioteca, y ya no nos sirve. Necesitamos saber qué libros tenemos, dónde está cada uno y quién lo tiene ahora.

El problema principal es que un libro puede estar en varias bibliotecas a la vez. Del Jardín de las horas tenemos tres, dos en la Central y uno en Vila Nova, y en la hoja de cálculo está tres veces con el mismo título y el mismo ISBN, así que si alguien busca el libro no sabe cuál de las tres filas mirar. Y cuando lo prestamos apuntamos el título, no el libro concreto, con lo cual nunca sabemos cuál de los tres ha vuelto.

Los socios son de tres tipos: infantiles, generales y sénior, y no todos se llevan los libros el mismo tiempo. Hay que poder renovar el préstamo, pero no siempre, y si alguien se retrasa hay una pequeña multa por día. Si acumula mucha deuda le bloqueamos el carné hasta que pague. También queremos gestionar las reservas: cuando un libro está todo prestado, el socio se apunta y le avisamos cuando vuelve, por orden.

Nos interesa mucho poder sacar informes: los libros más leídos, los que no sale nadie nunca, los socios que no vienen desde hace tiempo, cuánto dinero se nos queda sin cobrar en multas y cómo va cada biblioteca comparada con las otras. Ahora mismo eso lo hacemos a mano y tardamos un día entero.

Del personal solo necesitamos saber quién trabaja en cada biblioteca y de quién depende, para los turnos.

Un saludo, Helena

Ese correo es tu especificación de partida. Contiene todo lo que necesitas y, como todas las especificaciones reales, contiene también ambigüedades, palabras usadas con dos significados y reglas mencionadas de pasada ("no siempre", "una pequeña multa", "mucha deuda"). El trabajo empieza aquí.

La primera pasada consiste en subrayar los sustantivos y clasificarlos. No todo sustantivo es una tabla: unos son entidades, otros son atributos de una entidad, y algunos son las dos cosas según el contexto.

Fíjate en tres cosas que el cliente no ha dicho y que tú tienes que preguntar o decidir y documentar:

• "Unos cuantos miles de socios" no es un número. Para el proyecto lo fijamos: el sistema debe funcionar con decenas de miles de socios y cientos de miles de préstamos históricos. Ese orden de magnitud es lo que justifica los índices del módulo 8; con quince filas, cualquier cosa funciona.
• "Una pequeña multa por día" no es una tarifa. Hay que fijarla, y hay que fijar desde qué día se cuenta y si tiene tope.
• "Los socios que no vienen desde hace tiempo" no es una definición. ¿Un año sin préstamos? ¿Sin préstamos desde el alta? Es exactamente el problema que 11-04 planteaba: la mitad de los errores de análisis no son de SQL, son de definición.

Este es el apartado más importante de la lección, y la parte del proyecto donde más gente se estrella.

Cuando Helena escribe "del Jardín de las horas tenemos tres", está usando la palabra libro con dos significados a la vez:

• La obra: El jardín de las horas, de Marina Solís, Editorial Aurora, 2015, ISBN 978-84-1001-001-1. Es una cosa. Tiene título, autor, editorial, año, ISBN y materia. Se busca en el catálogo, se reserva y se recomienda.
• El ejemplar: el volumen físico con el código de barras ALV-0002, comprado en marzo de 2016, que está en la Central, tiene una mancha de café en la página 40 y lo tiene ahora Sofía Terán. Es una de tres cosas distintas. Se presta, se devuelve, se repara y se da de baja.

Ese diagrama contiene toda la idea. Se presta un ejemplar; se reserva una obra. Cuando un socio reserva El jardín de las horas le da exactamente igual cuál de los tres le toque; cuando devuelve uno, importa muchísimo cuál es, porque hay que darlo de baja del préstamo correcto y volver a ponerlo en su sede.

La tentación, y es enorme, es hacer una sola tabla libros con una columna ejemplares INTEGER que diga "3". Es el mismo atajo que productos.stock en TiendaVerde, y aquí no vale. La diferencia:

La regla general, y conviene grabársela porque reaparece en mil dominios (vehículos de una flota, licencias de software, habitaciones de un hotel, asientos de un avión): si el objeto tiene atributos propios, ubicación propia o historia propia, necesita su propia fila. Si es intercambiable y solo te importa cuántos hay, basta un contador.

Y la consecuencia práctica en el proyecto, que verás en cada consulta del módulo:

• "¿Cuántas obras hay en el catálogo?" → COUNT(*) FROM obras → 12.
• "¿Cuántos libros hay en las estanterías?" → COUNT(*) FROM ejemplares → 20.
• Las dos preguntas son legítimas, las dos respuestas son correctas y quien confunde las dos publica informes que no cuadran.

Estas son las reglas que el proyecto debe cumplir. Están numeradas para poder referirse a ellas en el código, en los comentarios y en el informe final: "la restricción chk_prestamos_prevista implementa la RN-01" es una frase que un revisor entiende sin preguntar nada.

Las RN-09 y RN-10 juntas son el ejemplo de definición de métrica que 11-04 pedía: "multas del mes" y "dinero que nos deben" no son lo mismo, porque el segundo incluye la deuda potencial de los préstamos vencidos sin devolver y el primero no. Decidir cuál publicas es tu trabajo; no decirlo es el error.

TiendaVerde tenía un pedidos.estado con cinco valores guardados en una columna. Aquí el ciclo es más rico y, sobre todo, la mayor parte de él es derivable de las fechas: es una decisión de diseño que discutiremos en 12-03 y que tiene alternativas defendibles.

Léelo con atención, porque de este diagrama salen tres columnas y una tabla entera:

• fecha_prestamo y fecha_prevista nacen con la fila.
• fecha_devolucion es NULL mientras el préstamo está vivo. Ese NULL es el estado "activo", y es la columna sobre la que girará medio proyecto: el índice único parcial, la vista de vencidos y casi todas las consultas.
• renovaciones cuenta las vueltas del bucle activo → activo.
• vencido no es una columna: es fecha_devolucion IS NULL AND fecha_prevista < CURRENT_DATE. Guardarlo sería guardar algo que cambia solo con que pase la medianoche, y habría que actualizarlo todas las noches.
• multas es una tabla porque el nodo "con multa → pagada" tiene su propia fecha, su propio importe y su propia vida.

Lo que entregas son cuatro ficheros, detallados en 12-02:

Lo que queda fuera, y decirlo es parte del trabajo profesional —un alcance sin fronteras es un proyecto que no termina—:

• La interfaz de usuario. No hay pantallas, ni web, ni aplicación de mostrador. Todo se hace desde SQL.
• La catalogación bibliográfica real. Nada de MARC21, autoridades normalizadas ni ISBD. Aquí una obra tiene título, autor, editorial, año, ISBN y materia, y con eso basta.
• Compras, presupuesto y proveedores. El ejemplar aparece con su fecha de adquisición; de dónde vino y cuánto costó, no se modela.
• Usuarios del sistema, contraseñas y sesiones. Sí hay roles de base de datos (11-03), que es otra cosa.
• Actividades, salas y carnés digitales. Son bibliotecas de verdad y hacen muchas más cosas; el proyecto se ciñe a catálogo, préstamo, reserva y multa.

No empieces en blanco. Buena parte del proyecto es TiendaVerde con otros nombres, y aprovechar eso no es hacer trampa: es lo que hace un profesional cuando reconoce un patrón.

Y aquí es donde el paralelismo se rompe y hay que pensar de nuevo:

1. pedidos + lineas_pedido frente a prestamos. Un pedido es una cabecera con N líneas; un préstamo es una fila y un solo ejemplar. Si un socio se lleva tres libros, son tres préstamos, no un préstamo con tres líneas — porque cada uno se devuelve por su cuenta, se renueva por su cuenta y genera su multa por su cuenta. Si algún día hicieran falta "tickets de préstamo" para agrupar lo que se llevó alguien de una vez, entonces sí habría cabecera y detalle. Hoy no hace falta, y añadirla es sobreingeniería.
2. productos.stock frente a ejemplares. Ya visto en el apartado 3. Un número contra una tabla.
3. pedidos.estado frente al estado del préstamo. En TiendaVerde el estado es una columna con CHECK, porque enviado no se deduce de ninguna fecha. Aquí, activo, vencido y devuelto se deducen de dos fechas y del reloj, y almacenarlos sería mantener a mano algo que cambia solo.
4. La N:M cambia de sitio. En TiendaVerde la N:M (lineas_pedido) llevaba datos propios: cantidad, precio, descuento. Aquí la N:M es obras_autores, casi pura, con clave primaria compuesta y sin id propio — que es exactamente la alternativa que 05-01 planteó y que TiendaVerde no eligió. Ahora sí la eliges, y tienes que saber por qué.

El orden importa y el consejo es firme: no leas 12-04 antes de haberlo intentado. El solucionario enseña muchísimo comparado con tu trabajo y no enseña casi nada leído en frío. Haz el modelo, escribe el DDL, equivócate, corrige, y entonces compara.

• Empezar por el CREATE TABLE. El impulso de abrir el editor y escribir tablas es fortísimo y es un error. Primero el diagrama en papel, aunque sean quince minutos: cambiar una caja dibujada cuesta un tachón; cambiarla en un esquema con datos cargados cuesta una migración (05-06).
• Modelar lo que el cliente dijo en vez de lo que quiso decir. Helena dice "libro" y significa dos cosas. Tu trabajo es detectarlo y volver a preguntar, no adivinar en silencio.
• Modelar todo lo que se te ocurra. Podrías añadir salas, actividades, donaciones, encuadernaciones y sanciones disciplinarias. No lo hagas: cada tabla que no responde a un requisito es deuda. El alcance del apartado 6 es la frontera.
• Guardar lo que se puede calcular. Antes de crear una columna, pregúntate si es un hecho (la fecha en que se prestó) o una consecuencia (que esté vencido). Los hechos se guardan; las consecuencias se calculan — salvo la excepción de fecha_prevista, que 12-03 justifica.
• Confiar en la memoria para las reglas de negocio. Escríbelas numeradas, como el apartado 4, y cita el número en cada restricción y en cada consulta. Dentro de tres semanas no te acordarás de por qué el tope de la multa era 20 €.
• Consejo: pon nombre a todo desde el primer minuto. snake_case, PK id, FK <tabla>_id, restricciones con pk_, fk_, uq_, chk_ e índices con idx_ (05-01, 11-02). Renombrar después es tedioso y se olvida siempre alguna.
• Consejo: fija una "fecha de hoy" para el proyecto. Todas las consultas de este módulo usan DATE '2026-06-30' en lugar de CURRENT_DATE, para que los resultados sean reproducibles. En producción sería CURRENT_DATE; en un entregable que alguien va a corregir, una fecha fija es la diferencia entre "me sale distinto" y "me sale lo mismo".
• Consejo: relee este encargo al terminar. La prueba final de un modelo no es que sea bonito: es que responda a lo que pedía el correo de Helena, incluidos los informes del párrafo cinco.

Los ejercicios de 12-01 y 12-02 son tareas del proyecto. No tienen solución cerrada: tienen un esbozo y una rúbrica, porque la solución completa llega en 12-04 y compararte con ella antes de intentarlo te roba el ejercicio.

Escribe un glosario de una página con todos los términos del encargo, y para cada uno: qué significa exactamente, si es entidad o atributo, y —si es ambiguo— las dos lecturas posibles y cuál eliges. Incluye obligatoriamente: obra, ejemplar, socio, préstamo, renovación, reserva, multa, sede, materia, disponible, vencido, bloqueado.

El encargo tiene al menos ocho decisiones sin tomar. Localízalas y, para cada una, escribe (a) la pregunta que harías a Helena y (b) la decisión que tomas mientras no te contesta, con su justificación. Ejemplo resuelto: "¿Se puede reservar una obra que sí tiene ejemplares disponibles? Pregunta a Helena. Mientras tanto: no (RN-07), porque si hay uno en la estantería el socio puede llevárselo ya y la cola no aporta nada."

Sin escribir una línea de SQL, dibuja el diagrama entidad-relación del proyecto: cajas, relaciones con su cardinalidad (1:N, N:M, reflexiva) y las tres o cuatro columnas clave de cada caja. Marca con un color distinto las cajas que no existen en TiendaVerde y escribe al lado de cada una por qué hace falta.

Esbozo de la Tarea 1

Las cuatro entradas que decidan si el glosario está bien:

Rúbrica de la Tarea 2

Se espera que hayas encontrado, como mínimo, seis de estas ocho: (1) la tarifa y el tope de la multa; (2) desde qué día se cuenta el retraso; (3) el umbral de deuda que bloquea; (4) si un socio bloqueado puede reservar; (5) qué es "un socio que no viene desde hace tiempo"; (6) si un ejemplar puede cambiar de sede y si eso deja rastro; (7) qué pasa con un ejemplar extraviado y su préstamo abierto; (8) si el tipo de socio se recalcula al cumplir años o se queda como se dio de alta. Las tres primeras están resueltas en las RN-09 y RN-11; las cinco restantes son decisiones tuyas, y lo que se evalúa es que estén escritas, no cuál elijas.

Esbozo de la Tarea 3

El diagrama completo está en 12-03, así que compara solo estos cinco puntos, que son los que separan un boceto correcto de uno equivocado:

1. obras y ejemplares son dos cajas, unidas 1:N, y la flecha va de la obra al ejemplar.
2. prestamos cuelga de ejemplares, no de obras. Si tu flecha va a obras, el modelo no puede decir qué libro concreto está fuera.
3. reservas cuelga de obras, no de ejemplares. Si va a ejemplares, estás reservando un objeto que quizá nunca vuelva, en vez de un título.
4. obras_autores es una caja entre obras y autores, con clave primaria compuesta y sin id propio.
5. bibliotecarios tiene una flecha hacia sí misma (responsable_id) y otra hacia sedes.

Cajas nuevas respecto a TiendaVerde: ejemplares, reservas, obras_autores y multas (esta última es prima de devoluciones, pero con ciclo de pago propio).

Ya tienes el encargo y sabes leerlo:

• El proyecto es la red de bibliotecas de Alvorada: tres sedes, unos miles de socios, catálogo, préstamos, reservas y multas. Un dominio nuevo, elegido precisamente para que modeles desde cero en lugar de heredar un esquema hecho.
• El giro central es la distinción obra / ejemplar: se cataloga y se reserva una obra, se presta un ejemplar. Tres ejemplares de El jardín de las horas repartidos en dos sedes son tres filas con historia propia, no el número 3 en una columna stock. La regla que lo generaliza: atributos propios, ubicación propia o historia propia ⇒ fila propia.
• Las doce reglas de negocio (RN-01 a RN-12) fijan plazos por tipo de socio (14/21/30 días), máximos simultáneos (3/5/5), renovaciones (1/2/2) y cuándo no se puede renovar, la cola FIFO de reservas, la multa de 0,20 €/día con tope de 20 € generada en la devolución, el bloqueo por encima de 10 € impagados y el histórico que no se borra jamás.
• El ciclo de vida del préstamo es en su mayor parte derivable: fecha_devolucion IS NULL es "activo", y "vencido" es esa condición más una comparación de fechas. Lo que sí tiene vida propia —la multa y su pago— es una tabla.
• TiendaVerde sirve de mapa para materias, editoriales, socios y bibliotecarios, y se rompe en cuatro sitios: no hay cabecera y detalle, stock se convierte en tabla, el estado se deriva en vez de guardarse, y la N:M pasa a ser una tabla puente pura con clave compuesta.

Con el dominio entendido, toca convertir el correo de Helena en algo que se pueda verificar. En la lección siguiente, Requisitos del proyecto, tendrás el enunciado formal: los requisitos de datos con las entidades y atributos que no son negociables, los de integridad con las restricciones que deben estar declaradas en la base y no solo en la aplicación —incluido el difícil, el de los dos préstamos activos—, la lista numerada de las 15 consultas que hay que entregar con la técnica y la lección que ejercita cada una, los requisitos de rendimiento y de seguridad, los ficheros de entrega y la rúbrica de evaluación con la que podrás autoevaluarte.