Los tres módulos anteriores han sido, en el fondo, un curso de herramientas: sabemos qué es un SGBD, sabemos escribir CREATE TABLE, sabemos consultar con JOIN y agregados, sabemos proteger la integridad con claves ajenas y sabemos modelar documentos en MongoDB. Lo que no hemos hecho todavía es decidir qué tablas tienen que existir. El esquema de BiblioRed —esas siete tablas que llevamos usando desde la lección 02-02— apareció casi por generación espontánea: hacía falta guardar libros, pues libros; hacía falta guardar préstamos, pues prestamos. Funcionó porque el dominio era pequeño y evidente.

Ese margen se acaba hoy. El ayuntamiento de Vallmar acaba de encargar a BiblioRed una ampliación real del servicio: gestionar eventos culturales, inscripciones de socios, salas y aforos, multas y pagos, y un catálogo que ya no es solo de libros. Es un encargo lo bastante grande como para que el método de "abro el editor y voy escribiendo tablas" produzca un desastre caro. Y es exactamente el material con el que trabajaremos las cuatro lecciones de este módulo: aquí recogemos los requisitos y fijamos los principios, en 04-02 los dibujamos, en 04-03 los convertimos en tablas y en 04-04 los blindamos con tipos y restricciones.

Esta lección trata de lo que ocurre antes de teclear. Qué objetivos persigue un esquema, qué fases atraviesa un diseño, cómo se convierte una conversación con un cliente en material de trabajo, cómo se distingue una entidad de un atributo, cómo se nombran las cosas para que dentro de cinco años se sigan entendiendo, y qué patrones de diseño hay que reconocer para no caer en ellos. Es la lección menos "técnica" del módulo y probablemente la que más dinero ahorra.

1. Qué es diseñar un esquema y por qué se hace antes de teclear
2. Los seis objetivos de un buen esquema y sus tensiones
3. Las tres fases del diseño: conceptual, lógico y físico
4. La recogida de requisitos: de la conversación al documento
5. El encargo de BiblioRed: documento de requisitos v1.0
6. Detectar reglas implícitas y ambigüedades
7. Identificar entidades, atributos y relaciones en el texto
8. ¿Entidad o atributo? Criterios de decisión
9. Convenciones de nomenclatura
10. Clave natural frente a clave subrogada, ahora como decisión de diseño
11. "Una cosa, un sitio" y "un hecho, una fila"
12. Anti-patrones de diseño frecuentes
13. Documentar y versionar el esquema
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

Diseñar un esquema es decidir, antes de escribir una sola sentencia DDL, qué cosas del mundo real va a representar la base de datos, cómo se relacionan entre sí y qué reglas deben cumplir siempre.

La pregunta razonable de quien empieza es: ¿por qué no diseñar sobre la marcha? Al fin y al cabo ALTER TABLE existe, y en el módulo 2 lo usamos varias veces sin drama. La respuesta tiene tres partes:

El coste de cambiar crece con el tiempo, y no linealmente. Cambiar una tabla el primer día cuesta escribir una línea. Cambiarla cuando tiene 40.000 filas, tres aplicaciones que la consultan, un informe mensual que la agrega y una copia replicada en un sistema de análisis cuesta una migración coordinada, una ventana de parada y un plan de vuelta atrás. Este es el argumento económico y es el más fuerte.

Los datos sobreviven a las aplicaciones. La aplicación web de BiblioRed se reescribirá probablemente dos o tres veces en quince años; los préstamos de 2026 seguirán ahí. Un esquema mal diseñado es una deuda que se hereda.

Un esquema es una teoría del negocio, no un contenedor. Cuando decidimos que un préstamo relaciona un socio con un ejemplar y no con un libro, estamos afirmando algo sobre cómo funciona la biblioteca. Si esa afirmación es falsa, ninguna cantidad de código de aplicación lo arreglará. Diseñar es, sobre todo, entender el dominio, y por eso la fase más valiosa se hace hablando con personas, no con el gestor.

Una forma útil de verlo: el código de la aplicación expresa lo que el sistema hace; el esquema expresa lo que el sistema cree que es verdad. Lo segundo cambia mucho más despacio y equivocarse cuesta mucho más caro.

Un esquema no se juzga por ser "bonito". Se juzga contra seis objetivos concretos:

1. Integridad. El esquema debe hacer imposibles los estados inválidos, no solo improbables. Si una multa nunca puede ser negativa, el esquema —no el formulario web— debe impedirlo. Esto ya lo defendimos en 02-06 para las claves ajenas; en 04-04 lo extenderemos a CHECK, NOT NULL y dominios.
2. Ausencia de redundancia innecesaria. Cada hecho debe estar almacenado en un solo sitio. Si el nombre de una sucursal aparece copiado en tres tablas, tarde o temprano las tres discreparán. Nótese el adjetivo: innecesaria. Hay redundancia deliberada y justificada, y se llama desnormalización (módulo 5).
3. Capacidad de responder a las consultas del negocio. Un esquema elegantísimo que no puede responder "¿cuántas plazas libres quedan en el club de lectura del jueves?" es un esquema fallido. Por eso la lista de consultas es parte del documento de requisitos.
4. Mantenibilidad. Que una persona nueva entienda el esquema en una tarde. Nombres claros, estructura previsible, documentación.
5. Evolución sin migraciones traumáticas. Añadir un tipo nuevo de evento no debería requerir ALTER TABLE. Añadir un tipo nuevo de material tampoco debería requerir reescribir las consultas existentes. Un buen diseño anticipa qué eje va a crecer.
6. Rendimiento razonable. No "máximo": razonable. El rendimiento se trabaja después, con índices y optimización (lección 06-03), pero el diseño puede hacerlo imposible: una consulta que necesita recorrer siete tablas de unión para pintar la portada de la web es un problema de diseño, no de índices.

Estos seis objetivos no son compatibles entre sí. Diseñar es elegir el punto de equilibrio, y saber cuál se está sacrificando.

La regla práctica: cuando dos objetivos chocan, gana la integridad, salvo que exista una medición que demuestre que el coste es inasumible. Los datos incorrectos son el único problema que no se puede arreglar después.

El diseño de bases de datos se organiza clásicamente en tres fases. No son burocracia: cada una responde a preguntas distintas y mezclarlas es la causa más frecuente de diseños malos, porque quien empieza discutiendo si un campo es VARCHAR(50) o TEXT ya ha dejado de pensar en el dominio.

Las flechas discontinuas son importantes: el proceso no es una cascada. Cada fase descubre errores de la anterior, y volver atrás es señal de que el método funciona.

En la lección 01-04 vimos los tres niveles de ANSI/SPARC: externo, conceptual e interno. Las tres fases del diseño producen esos tres niveles, aunque la correspondencia no sea exactamente uno a uno:

La consecuencia práctica es que el diseño físico se puede cambiar sin tocar las consultas (esa es la independencia física), y por eso posponerlo no cuesta nada. En cambio, el diseño lógico es el contrato con las aplicaciones, y por eso cambiarlo sí duele.

Un detalle que a menudo se pasa por alto: el diseño conceptual es independiente incluso del paradigma. El mismo diagrama ER de BiblioRed serviría para derivar un esquema relacional o un modelo documental de MongoDB (con las técnicas de 03-03). Por eso se dibuja primero.

Nadie llega con un documento de requisitos. Llega con una frase: "queremos gestionar también los eventos de las bibliotecas". El trabajo consiste en convertir eso en material sobre el que se pueda diseñar.

• Entrevistas con quien va a usar el sistema (bibliotecarios, coordinación de actividades, administración).
• Documentos existentes: hojas de cálculo, formularios en papel, carteles, correos. Son oro: un formulario de inscripción en papel contiene la lista de atributos que alguien ya consideró necesarios.
• El sistema actual, si lo hay. BiblioRed ya tiene siete tablas: lo nuevo debe encajar con ellas, no ignorarlas.
• Normativa. Un ayuntamiento tiene reglamentos de uso de salas y ordenanzas de tasas. Ahí están los importes de las multas.

Esta lista es probablemente lo más reutilizable de la lección. Para cada cosa que el cliente mencione:

Las dos filas más productivas son excepciones y consultas.

La pregunta de excepciones —"¿ha pasado alguna vez que un evento se quedara sin ponente?"— es la que descubre las reglas que el cliente cree obvias y no lo son. Un cliente nunca dice "un evento puede no tener sala"; lo dice cuando le preguntas si eso ha pasado alguna vez y responde "bueno, el cuentacuentos de verano lo hacemos en el patio".

La pregunta de consultas es la que evita diseñar un esquema que no sirve. La lista de consultas es un requisito de primera clase y debe estar en el documento: en 04-03 la usaremos como criterio de validación del esquema resultante.

Cuando el cliente pide algo, hay tres respuestas posibles y solo dos son honestas: "sí, y esto es lo que implica", "sí, pero en la versión 2 y por este motivo" y "no, porque…". Aceptar todo sin dimensionarlo produce esquemas con veinte tablas para funcionalidades que nadie usará. El alcance es una decisión de diseño, y por eso el documento de requisitos lleva siempre un apartado explícito de "fuera de alcance".

Este es el resultado de tres reuniones con la coordinación de BiblioRed y con el área de Cultura del ayuntamiento de Vallmar. Es el documento que las tres lecciones siguientes van a usar: en 04-02 lo dibujaremos, en 04-03 lo convertiremos en tablas y en 04-04 lo blindaremos. Conviene leerlo entero antes de seguir.

Ampliación del servicio de BiblioRed — Documento de requisitos v1.0

Contexto. BiblioRed gestiona 4 sucursales (Centro, Norte, Sur y Este), 12.000 socios y 40.000 ejemplares, sobre un esquema PostgreSQL de siete tablas: sucursales, autores, socios, libros, ejemplares, prestamos y reservas. El ayuntamiento amplía el encargo a la gestión de actividades culturales, cobro de multas y catálogo multiformato.

A. Requisitos funcionales

R1 — Catálogo multiformato. El catálogo deja de ser solo de libros. Debe admitir libros, DVD, revistas y audiolibros. Todos comparten título, idioma, editorial o productora, año de publicación y fecha de alta en el catálogo. Además:

• los libros tienen ISBN, número de páginas y tipo de encuadernación;
• los DVD tienen duración en minutos, formato de vídeo, código de región y una lista de idiomas de subtítulos;
• las revistas tienen ISSN, número y periodicidad;
• los audiolibros tienen duración, narrador y formato de archivo.

Un material puede tener autor asociado; las revistas normalmente no lo tienen. Todo lo que hoy es un libro debe seguir funcionando exactamente igual.

R2 — Ejemplares. Cada material tiene de 0 a N ejemplares físicos, cada uno ubicado en una sucursal, con estado y fecha de adquisición. Los ejemplares se identifican con un código impreso (EJ-3081) y, además, se numeran dentro de su material: "el ejemplar 3 de El mapa del tiempo". Se prestan ejemplares; se reservan materiales.

R3 — Salas. Cada sucursal dispone de entre 1 y 6 salas. De cada sala interesa el nombre, el aforo máximo de personas, la planta y si es accesible para personas con movilidad reducida. El nombre de sala solo es único dentro de su sucursal: hay una "Sala Polivalente" en Centro y otra en Norte.

R4 — Eventos. Un evento cultural tiene título, descripción, tipo, sala donde se celebra, fecha y hora de inicio, fecha y hora de fin, número de plazas ofertadas, estado (programado, abierto, completo, celebrado, cancelado) y si está publicado en la web. Un evento se celebra en una sola sala; la sucursal del evento es la de su sala. En la versión 1.0, un evento es una sesión única.

R5 — Tipos de evento. Hoy son: club de lectura, taller, presentación, cuentacuentos y charla. El ayuntamiento quiere poder añadir tipos nuevos sin llamar al informático. De cada tipo interesa el nombre, una descripción y una duración estándar orientativa.

R6 — Inscripciones. Un socio se inscribe a un evento. Un evento admite muchos socios y un socio se inscribe a muchos eventos. De cada inscripción se guarda la fecha, el estado (confirmada, lista_espera, cancelada, asistida) y el número de acompañantes (de 0 a 3). Un socio no puede inscribirse dos veces al mismo evento.

R7 — Ponentes. Los eventos los conducen ponentes, que pueden ser personal propio de BiblioRed o profesionales externos. Un evento puede tener varios ponentes y un ponente participa en muchos eventos. En un mismo evento, una persona puede desempeñar más de un papel (moderar el coloquio y además impartir el taller). De cada participación se anotan los honorarios, que son 0 para el personal propio.

R8 — Materiales tratados en un evento. Un club de lectura comenta uno o varios materiales del catálogo; un taller puede recomendar bibliografía. Se anota si el material es el principal del evento o solo recomendado.

R9 — Informe posterior. Una vez celebrado un evento, la coordinación redacta un informe con el número real de asistentes, la valoración media de las encuestas y observaciones en texto libre. No todos los eventos tienen informe, y ninguno tiene más de uno.

R10 — Multas. Un préstamo devuelto fuera de plazo genera una multa por retraso. También pueden emitirse multas por deterioro o por pérdida del ejemplar. Un mismo préstamo puede generar como mucho una multa de cada motivo. La multa tiene importe en euros, fecha de emisión y estado (pendiente, pagada, condonada, anulada).

R11 — Pagos. Una multa se puede liquidar en varios pagos parciales, en efectivo en mostrador, con tarjeta o a través de la pasarela web del ayuntamiento. De cada pago se guarda la fecha y hora, el importe, el método y una referencia externa (número de recibo o identificador de la pasarela). El importe pendiente de una multa es su importe menos la suma de sus pagos.

R12 — Teléfonos de socio. Hoy hay un solo teléfono por socio. Se pide poder guardar hasta tres por socio, cada uno con su tipo (movil, fijo, trabajo).

R13 — Dirección de sucursal. Hoy la dirección es un único texto libre. La web nueva necesita mostrar la ciudad por separado y buscar sucursales por código postal.

R14 — Bloqueo por deuda. Un socio con más de 20 € pendientes de pago no puede inscribirse a eventos ni llevarse préstamos nuevos.

B. Reglas de negocio

Código	Regla
RN1	Las plazas ofertadas de un evento no pueden superar el aforo de su sala.
RN2	Las inscripciones confirmadas, contando acompañantes, no pueden superar las plazas ofertadas; a partir de ahí se pasa a lista de espera.
RN3	La fecha y hora de fin de un evento debe ser posterior a la de inicio.
RN4	Dos eventos no cancelados no pueden solaparse en el tiempo en la misma sala.
RN5	El importe de una multa nunca es negativo, y la suma de sus pagos nunca supera su importe.
RN6	Solo pueden inscribirse socios activos.
RN7	La fecha de inscripción no puede ser posterior al inicio del evento.
RN8	Un evento publicado en la web debe tener sala asignada y plazas ofertadas mayores que cero.
RN9	El ISBN identifica unívocamente un libro; el ISSN junto con el número identifica unívocamente una revista.
RN10	Un material no puede reservarse si no tiene ningún ejemplar en el catálogo.

C. Consultas que el sistema debe poder responder

Código	Consulta
C1	Agenda pública de eventos del mes, por sucursal, solo los publicados.
C2	Plazas libres de un evento concreto, en tiempo real.
C3	Lista de socios inscritos a un evento con su teléfono de contacto.
C4	Historial de eventos a los que se ha inscrito un socio.
C5	Ocupación media de cada sala por sucursal y trimestre.
C6	Recaudación de multas por mes y método de pago.
C7	Socios con deuda pendiente superior a 20 €.
C8	Catálogo filtrado por tipo de material e idioma.
C9	DVD que tengan subtítulos en catalán.
C10	Los diez materiales más prestados, desglosados por tipo de material.
C11	Ponentes que han participado en más de tres eventos, con sus honorarios totales.
C12	Eventos celebrados hace más de 15 días que todavía no tienen informe.

D. Volúmenes estimados a tres años

Concepto	Hoy	En 3 años
Socios	12.000	16.000
Materiales (títulos)	18.000	25.000
Ejemplares	40.000	55.000
Eventos	0	1.200 (≈400/año)
Inscripciones	0	30.000
Multas	0	9.000

E. Fuera de alcance en la versión 1.0

• Reserva de salas por parte de particulares o entidades ajenas.
• Eventos con varias sesiones (ciclos, cursos de varias semanas).
• Venta de entradas o eventos de pago.
• Gestión de personal, nóminas y contratos de los ponentes externos.
• Integración contable con el sistema del ayuntamiento (los pagos se registran, no se contabilizan).

Fíjate en tres cosas de este documento, porque son las que lo hacen útil:

1. Las cardinalidades están escritas en prosa, no dibujadas todavía ("un evento se celebra en una sola sala", "un socio se inscribe a muchos eventos"). Ese es el material de 04-02.
2. Las reglas de negocio están numeradas y separadas de los requisitos funcionales. En 04-04 las convertiremos, una por una, en CHECK, UNIQUE o lógica de aplicación.
3. Las consultas y el alcance están explícitos. Sin las primeras no se puede validar el diseño; sin el segundo, el diseño no termina nunca.

El documento anterior no salió así de la primera reunión. Salió de detectar ambigüedades en lo que decía el cliente y devolvérselas convertidas en preguntas. Estas son las cinco que aparecieron en BiblioRed, y son un catálogo bastante representativo de lo que uno se encuentra:

Y estas son las señales lingüísticas que delatan una regla implícita, útiles como lista de comprobación al leer cualquier enunciado:

• "Normalmente", "casi siempre", "en general" → hay excepciones sin documentar. "Normalmente el evento tiene un solo ponente" significa que a veces tiene dos, y eso cambia la cardinalidad.
• "Y también" al final de una frase → un requisito que se coló sin analizar.
• Un plural donde esperabas singular → "los idiomas de subtítulos" (R1) es literalmente un atributo multivaluado, y se ve en la palabra.
• Un adjetivo evaluativo → "eventos importantes", "socios problemáticos": hay que preguntar por la definición operativa, porque acabará siendo una columna o una regla.
• Un verbo en pasado o futuro → "los ponentes que participaron": implica historial, e implica que borrar no es una opción.
• "Ya lo sabéis" o "eso es obvio" → casi nunca lo es.

Hay una técnica clásica, casi mecánica, para arrancar: subrayar los sustantivos y los verbos del enunciado.

• Los sustantivos son candidatos a entidad (si son cosas con identidad propia) o a atributo (si son propiedades de otra cosa).
• Los verbos que conectan dos sustantivos son candidatos a relación: un socio se inscribe en un evento, un evento se celebra en una sala, un préstamo genera una multa.
• Los adjetivos y cuantificadores aportan cardinalidad y obligatoriedad: "una sola sala", "hasta tres", "de 0 a N".

Apliquémoslo a R4 y R6:

Un evento cultural tiene título, descripción, tipo, sala donde se celebra, fecha y hora de inicio… Un socio se inscribe a un evento… De cada inscripción se guarda la fecha, el estado y el número de acompañantes.

Resultado del primer barrido:

La técnica del subrayado arranca bien y luego engaña. Sus tres fallos típicos:

1. Sinónimos que parecen entidades distintas. "Socio", "usuario", "lector" y "abonado" pueden ser lo mismo dicho por cuatro personas distintas. Hay que consolidar el vocabulario, y de ahí sale el glosario del proyecto.
2. Homónimos que parecen la misma entidad. "Estado" aparece en ejemplares, en reservas, en eventos, en inscripciones y en multas, y son cinco conjuntos de valores completamente distintos.
3. Entidades que no se nombran nunca. Nadie dijo la palabra "participación" en R7, y sin embargo es una entidad (la relación entre ponente y evento con sus honorarios). Las entidades que emergen de una relación N:M casi nunca aparecen como sustantivo en el enunciado. Hay que buscarlas preguntando: "cuando esto se cruza con aquello, ¿hay algo que anotar del cruce?".

Por eso el subrayado es un punto de partida, no un algoritmo. La lista definitiva se cierra dibujando, que es lo que haremos en la lección siguiente.

Esta es la duda que más tiempo consume en un diseño real. Volvamos al "tipo de evento" de R5.

Opción A — atributo: eventos.tipo_evento es un texto con valores 'club_lectura', 'taller', 'presentacion'…

Opción B — entidad: existe una tabla tipos_evento y eventos apunta a ella con una clave ajena.

Cinco criterios para decidir, aplicados al caso:

Tres criterios claros a favor: tipos_evento será una entidad. Compáralo con el atributo idioma de un material: no tiene propiedades interesantes, la lista es estable (ISO 639) y nadie va a "gestionar idiomas". Ese se queda como atributo.

Es una entidad si tiene atributos propios, o ciclo de vida propio, o si el conjunto de valores lo gestiona alguien. Es un atributo si es un valor simple, estable y sin propiedades.

Y una regla de oro sobre el momento: ante la duda razonable, empieza por atributo. Convertir un atributo en entidad más adelante es una migración mecánica (crear tabla, poblarla con los distintos, sustituir la columna por una FK). Convertir una entidad en atributo también se puede, pero implica que has estado manteniendo una tabla vacía de sentido durante dos años. La asimetría de coste favorece a la simplicidad.

Los nombres del esquema son la interfaz que verán todas las personas que trabajen con él durante años. Estas son las decisiones que hay que tomar, con la elección de BiblioRed y su motivo:

Hay nombres que parecen naturales y son palabras reservadas de SQL. Usarlos obliga a entrecomillar para siempre, en todas las consultas, en todos los lenguajes, en todos los informes.

Palabras a evitar como nombres de tabla o columna: user, order, group, table, select, from, where, check, default, end, desc, all, any, case, column, constraint, grant, limit, offset, references, union, unique, values, window. En español el riesgo es menor, pero union, orden (no reservada, pero confusa) y check aparecen con frecuencia.

El principio que gobierna todo este apartado: casi ninguna de estas decisiones es objetivamente correcta. Plural o singular da igual. Lo que no da igual es que la mitad del esquema esté en plural y la otra mitad en singular, porque entonces nadie puede escribir una consulta sin mirar antes el catálogo. La consistencia vale más que la corrección.

En la lección 02-01 planteamos el debate con el ISBN: libros tiene isbn (clave natural candidata) y libro_id (subrogada). Entonces era una cuestión teórica. Ahora es una decisión que hay que tomar para cada una de las tablas nuevas, y merece criterios firmes.

1. Ninguna clave natural es tan estable como parece. El ISBN es el ejemplo canónico y sirve de escarmiento: pasó de 10 a 13 dígitos en 2007, se reutilizan por error, hay ediciones sin ISBN y hay libros con dos. El DNI cambia con la nacionalidad. El código de sala cambia cuando reforman la planta. Cualquier valor que gestione un tercero puede cambiar, y si es tu clave primaria, ese cambio se propaga por cascada a todas las tablas que lo referencian.

2. La clave subrogada no elimina la necesidad de la natural: la complementa. Este es el error frecuente. Poner material_id como PK no autoriza a olvidarse del ISBN: si no se declara UNIQUE sobre el ISBN, acabarán existiendo dos filas para el mismo libro y ninguna restricción lo impedirá. La combinación correcta es PK subrogada + UNIQUE sobre la clave natural, que es exactamente lo que hace el esquema actual de BiblioRed (libro_id PK, isbn UNIQUE).

3. La excepción son las tablas de unión. En inscripciones, la pareja (evento_id, socio_id) es una clave natural perfecta: no cambia (si cambiara, sería otra inscripción), es corta, y es exactamente la regla de negocio de R6 ("un socio no puede inscribirse dos veces"). Añadir un inscripcion_id subrogado ahí es a menudo ruido; solo se justifica si otra tabla tiene que referenciar la inscripción. Lo decidiremos tabla por tabla en 04-03.

Regla de BiblioRed para la ampliación: clave subrogada <entidad>_id en toda entidad fuerte, siempre acompañada de UNIQUE sobre la clave natural cuando exista; clave compuesta natural en las tablas de unión y en las entidades débiles, salvo que haga falta referenciarlas desde fuera.

Dos principios que se enuncian en una línea y explican la mayoría de los problemas de diseño.

Cada hecho debe estar almacenado exactamente una vez. Si el aforo de la Sala Polivalente de Centro está en salas y también copiado en cada fila de eventos, existe la posibilidad física de que discrepen. Y lo que puede discrepar, con suficiente tiempo, discrepa.

El daño concreto de incumplirlo son las tres anomalías clásicas:

Cada fila debe representar un solo hecho del mundo. Una fila de prestamos dice "el socio 14 se llevó el ejemplar EJ-3081 el día tal". Eso es un hecho. Si esa misma fila llevara también la dirección del socio, estaría representando dos hechos distintos —el préstamo y el domicilio— pegados por accidente, y sufriría las tres anomalías anteriores.

Estos dos principios, formalizados con matemáticas, se llaman normalización, y el proceso de aplicarlos produce las formas normales (1NF, 2NF, 3NF, BCNF…). Es un cuerpo de teoría con definiciones precisas de dependencia funcional, y es el módulo 5 completo del curso: los conceptos en 05-01, las formas normales una a una en 05-02, el proceso aplicado en 05-03 y los casos en que se decide deliberadamente romperlas —desnormalizar— en 05-04.

En este módulo trabajaremos con la versión intuitiva ("una cosa, un sitio") y volveremos sobre el esquema de BiblioRed en el módulo 5 con el instrumental formal para verificar que aguanta. No intentes aplicar formas normales todavía: el diseño de este módulo se hace por comprensión del dominio, y esa es precisamente la manera en que se hace en la práctica profesional.

Un anti-patrón es una solución que parece razonable, se usa mucho y causa un daño previsible. Reconocerlos por su nombre ahorra discusiones.

En lugar de columnas, una tabla genérica de tripletas:

Parece la solución perfecta a R1: cada tipo de material tiene sus atributos y así caben todos. Lo que se pierde:

• Los tipos de datos. duracion_min es texto; nada impide que valga 'ayer'.
• Las restricciones. No hay NOT NULL posible: no se puede exigir que un libro tenga ISBN.
• Las consultas. "DVD en catalán de más de 90 minutos" necesita dos auto-JOIN y una conversión de tipo.
• El rendimiento, por lo anterior.

Cuándo se justifica: cuando los atributos los define el usuario en tiempo de ejecución y son verdaderamente impredecibles (formularios configurables, catálogos de productos con miles de familias). Incluso entonces, hoy la respuesta suele ser una columna JSONB (03-03), que conserva tipos, permite índices GIN y valida con $jsonSchema o CHECK. Para BiblioRed, con cuatro tipos de material conocidos, EAV sería un error: la solución correcta es la jerarquía de generalización que veremos en 04-02 y 04-03.

Es la respuesta tentadora a R12 ("hasta tres teléfonos"), porque el requisito incluso pone el límite. Lo que falla:

• "¿Cuántos socios tienen móvil?" requiere mirar tres columnas y unirlas con UNION.
• El cuarto teléfono llega siempre, y trae un ALTER TABLE y un cambio en todas las consultas.
• El tipo se pierde: ¿cuál de las tres es el móvil?
• La mayoría de las filas tienen NULL en dos de las tres columnas.

La forma correcta es una tabla telefonos_socio, es decir, tratar el atributo multivaluado como lo que es. En 04-03 lo formalizaremos como regla de transformación.

Directamente en el camino de R1 y de la consulta C9 ("DVD con subtítulos en catalán"). Lo que ocurre en la práctica:

Esa consulta devuelve también los DVD con subtítulos en 'cat', en 'oc-ca' y cualquier valor que contenga las letras ca en cualquier posición. No hay forma de garantizar que los códigos sean válidos, no hay forma de contar cuántos DVD hay por idioma sin trocear cadenas, y no se puede poner una clave ajena a una tabla de idiomas. Es la violación más pura de "un hecho, una fila".

La alternativa correcta es una tabla subtitulos_dvd. Si de verdad hace falta la agrupación en un solo campo, PostgreSQL ofrece arrays y JSONB con operadores e índices propios (subtitulos @> ARRAY['ca']), que no son lo mismo que una cadena con comas: conservan la estructura. Lo veremos en 04-04.

Una tabla llamada datos, general, parametros o varios donde se van metiendo columnas que no encajaban en ningún sitio. Síntomas: nombre genérico, más de 40 columnas, la mitad NULL, y ninguna persona del equipo capaz de explicar qué representa una fila.

El diagnóstico es siempre el mismo: si no puedes completar la frase "cada fila de esta tabla es un/una ______", la tabla está mal. Una fila de prestamos es un préstamo. Una fila de datos es… nada.

El anti-patrón menos comentado y probablemente el más caro, porque quien lo comete cree estar haciéndolo especialmente bien. Consiste en modelar hoy la flexibilidad que quizá haga falta dentro de tres años: una tabla entidades genérica con tipo_entidad, un sistema de metadatos configurable, una jerarquía de cinco niveles porque "quién sabe".

Para BiblioRed la tentación concreta es real: "ya que hacemos eventos, hagamos ciclos de eventos, con sesiones, y plantillas de evento, y eventos recurrentes". El documento de requisitos lo cortó de raíz poniéndolo en el apartado E, fuera de alcance. Cuando llegue el requisito de verdad, se añade una tabla sesiones y eventos gana una FK opcional: media hora de trabajo, con el requisito real delante en lugar de imaginado.

El contrapeso honesto: hay un tipo de anticipación que sí compensa, y es la que evita perder información. Si hoy se guarda solo el saldo y mañana hacen falta los movimientos, esos movimientos ya no existen. Guardar hechos en lugar de resúmenes casi nunca se lamenta; construir maquinaria genérica, casi siempre.

Un esquema sin documentación es un esquema que solo entiende quien lo escribió, mientras se acuerde.

La regla es simple: nadie toca la base de producción a mano. Todo cambio de esquema es un fichero versionado en el repositorio, con número de orden, que se aplica una sola vez.

Cada migración debe ser idempotente en el resultado (aplicarla dos veces no debe romper nada) y, en lo posible, tener su vuelta atrás escrita. Herramientas como Flyway, Liquibase, Alembic o las migraciones integradas en los frameworks automatizan el registro de qué se ha aplicado; el detalle de herramientas concretas está en 09-03. Lo esencial es el hábito, no la herramienta.

PostgreSQL permite adjuntar comentarios al propio catálogo. La ventaja frente a un documento aparte es que no se puede desincronizar del esquema por descuido, porque vive dentro de él.

Se consultan desde psql con \d+ inscripciones, y cualquier herramienta gráfica los muestra. Ese último comentario, el de la columna obsoleta, es el que evita que dentro de dos años alguien construya un informe sobre un dato congelado.

Es la tabla que acompaña al diagrama y que cualquier persona puede leer sin saber SQL. Un extracto del de BiblioRed:

Y una última pieza que casi nadie escribe y que salva proyectos: un registro de decisiones. Tres columnas —decisión, alternativas descartadas, motivo— con entradas como "un evento es una sesión única; se descartó modelar ciclos; motivo: fuera de alcance v1.0, se prevé tabla sesiones si llega el requisito". Cuando dentro de un año alguien pregunte "¿por qué esto está así?", la respuesta existirá.

Empezar por el CREATE TABLE. Es el error raíz del que derivan casi todos los demás. Escribir DDL da sensación de avance y consolida decisiones que aún no se han pensado. Dibuja primero, aunque sea en una servilleta.

Diseñar a partir de las pantallas. Si el esquema copia la estructura de los formularios de la aplicación, quedará atado a una interfaz que cambiará el año que viene. Las pantallas son una fuente de requisitos, no un modelo de datos.

Confundir "no lo han pedido" con "no ocurre". El cliente no pidió guardar dos ponentes por evento; simplemente no se le ocurrió mencionarlo hasta que se le preguntó por las excepciones. Pregunta siempre por los casos raros: son los que rompen las cardinalidades.

Modelar el presente y olvidar el tiempo. "Guardamos el teléfono del socio" está bien; "guardamos a qué sucursal pertenece un socio" esconde una pregunta: ¿y si se cambia? ¿Interesa saber a cuál pertenecía cuando pidió aquel préstamo? Preguntar "¿necesitas el histórico?" en cada relación cuesta cinco segundos y evita rediseños completos.

Meter la unidad en el nombre y no en el tipo. duracion_min es aceptable como convención explícita, pero importe sin especificar moneda ni escala no lo es. Documenta las unidades en el diccionario de datos y refuérzalas con el tipo (04-04).

Usar el mismo nombre para conceptos distintos. Cinco columnas estado con cinco conjuntos de valores incompatibles es una fuente permanente de confusión. O se cualifican (estado_evento, estado_multa) o se documentan meticulosamente.

Consejo: valida el diseño leyéndolo en voz alta. "Un evento se celebra en una sala; una sala acoge muchos eventos; un evento puede no tener sala si es al aire libre." Si la frase suena rara, el diseño está mal. Este truco funciona sorprendentemente bien y no cuesta nada.

Consejo: recorre la lista de consultas antes de dar el diseño por bueno. Coge C1 a C12 y, para cada una, di en voz alta por qué tablas pasarías. Si alguna no se puede responder, falta algo. Lo haremos formalmente al final de 04-03.

Consejo: escribe el motivo, no solo la decisión. "Un evento = una sesión" sin el porqué se reabre cada seis meses. Con el porqué, se cierra.

El área de Cultura de Vallmar añade este párrafo al encargo:

"Además queremos llevar el control del material que se presta a las asociaciones del barrio para sus actividades: proyectores, altavoces y esas cosas. Normalmente lo pide el presidente de la asociación, y lo devuelven a los pocos días. Si se estropea algo, lo apuntamos."

Identifica al menos cuatro ambigüedades o reglas implícitas y escribe, para cada una, la pregunta concreta que harías al cliente. Indica también qué señal lingüística te alertó.

Para cada elemento, decide si en el esquema de BiblioRed debe ser entidad o atributo, aplicando los cinco criterios del apartado 8. Justifica en una frase.

1. El método de pago de un pago (efectivo, tarjeta, pasarela).
2. La editorial de un material.
3. El código postal de una sucursal.
4. El motivo de una multa (retraso, deterioro, perdida).
5. La nacionalidad de un autor.

Un equipo externo propone esta tabla para resolver los requisitos R4, R6 y R9 de una sola vez:

Nombra todos los anti-patrones presentes, explica el daño concreto que causa cada uno con un ejemplo de BiblioRed, y describe en dos o tres frases cómo lo reestructurarías (sin escribir SQL todavía: eso es 04-03).

Solución al Ejercicio 1

Cualquier cuatro de estas seis es una respuesta completa. Las más importantes son la 2 (introduce una entidad nueva, asociaciones, que no estaba en el modelo) y la 6 (cambia la cardinalidad del préstamo).

Solución al Ejercicio 2

Solución al Ejercicio 3

Anti-patrones presentes:

1. Tabla cajón de sastre. actividades con tipo_registro mezcla eventos, inscripciones e informes en una sola tabla. No se puede completar la frase "cada fila es un/una ___": unas son eventos y otras son inscripciones. Consecuencia: ninguna columna puede ser NOT NULL (lo que es obligatorio para un evento no lo es para una inscripción) y toda consulta arrastra un WHERE tipo_registro = ....
2. Columnas numeradas (dato1, dato2, dato3). Es EAV disfrazado: el significado de dato2 depende de tipo_registro. Nadie sabrá dentro de un año que para las inscripciones dato2 era el estado. Imposible restringir valores.
3. Lista separada por comas en socios_apuntados. Rompe C2 (plazas libres), C3 (inscritos con teléfono) y C4 (historial del socio), impide la clave ajena a socios y hace que borrar un socio deje basura textual. Además no hay dónde poner la fecha ni los acompañantes de R6.
4. Redundancia: aforo_sala copiado del catálogo de salas. Anomalía de actualización inmediata en cuanto se reforme una sala (apartado 11).
5. Sala como texto libre. "Sala Polivalente" no identifica nada: R3 dice que el nombre solo es único dentro de la sucursal. Habrá 'Polivalente', 'Sala Polivalente' y 'polivalente ' con espacio.
6. Tipos inadecuados: fecha VARCHAR(30) impide ordenar cronológicamente, comparar rangos y responder C1 y C12. Es un adelanto de 04-04.
7. Nombre de columna id en lugar de actividad_id: menor, pero incoherente con la convención del esquema existente.

Reestructuración propuesta: separar en entidades con identidad propia —eventos, salas, inscripciones, informes_evento— unidas por claves ajenas; convertir la lista de socios apuntados en filas de inscripciones, una por socio, con sus atributos de fecha, estado y acompañantes; eliminar aforo_sala de eventos y obtenerlo por JOIN con salas; y sustituir dato1..3 por columnas con nombre y tipo en la tabla que corresponda. Es exactamente el diagrama que dibujaremos en la lección siguiente.

Esta lección ha cambiado el modo de trabajo del curso: de escribir SQL a decidir qué SQL hay que escribir.

• Diseñar antes de teclear se justifica por tres razones: el coste de cambiar crece de forma no lineal, los datos sobreviven a las aplicaciones y un esquema es una teoría del negocio, no un contenedor.
• Un esquema se juzga contra seis objetivos —integridad, no redundancia, capacidad de responder al negocio, mantenibilidad, evolución y rendimiento razonable— que entran en conflicto entre sí. Cuando chocan, gana la integridad salvo prueba en contrario.
• El diseño tiene tres fases: conceptual (qué existe), lógica (qué tablas) y física (cómo se accede rápido). Se corresponden con los niveles de ANSI/SPARC de 01-04, y mezclarlas es la causa más frecuente de diseños malos.
• La recogida de requisitos es una técnica con preguntas concretas. Las dos más productivas son las de excepciones ("¿ha pasado alguna vez que…?") y las de consultas ("¿qué le vas a preguntar al sistema?").
• El documento de requisitos v1.0 de BiblioRed —R1 a R14, diez reglas de negocio, doce consultas, volúmenes y alcance— queda cerrado y es el material de las tres lecciones siguientes.
• Las ambigüedades se detectan por señales lingüísticas: "normalmente", plurales inesperados, adjetivos evaluativos, verbos en pasado. Cinco ambigüedades reales de BiblioRed quedaron resueltas y escritas.
• Subrayar sustantivos y verbos arranca la identificación de entidades y relaciones, pero falla con sinónimos, homónimos y con las entidades que nadie nombra —las que emergen de un cruce N:M, como la participación de un ponente.
• La duda entidad o atributo se resuelve con cinco criterios: atributos propios, ciclo de vida, relaciones propias, multiplicidad y estabilidad del conjunto de valores. Ante la duda, empieza por atributo: promocionarlo después es barato.
• Las convenciones de nomenclatura —plural, snake_case, sufijo _id, FK con el nombre de la PK referenciada, español, restricciones nombradas— importan menos por su contenido que por su aplicación uniforme: la consistencia vale más que la corrección.
• Natural frente a subrogada deja de ser teoría: PK subrogada en toda entidad fuerte, siempre con UNIQUE sobre la clave natural; clave compuesta natural en tablas de unión y entidades débiles.
• "Una cosa, un sitio" y "un hecho, una fila" evitan las anomalías de actualización, inserción y borrado. Su versión formal es la normalización, que es el módulo 5 entero (05-01 y 05-02); aquí trabajamos con la versión intuitiva.
• Cinco anti-patrones identificados y nombrados: EAV, columnas numeradas, listas con comas dentro de una columna, tabla cajón de sastre y sobre-ingeniería prematura.
• Documentar y versionar: migraciones numeradas en el repositorio, COMMENT ON pegado al catálogo, diccionario de datos legible y registro de decisiones con sus motivos.

Tenemos el encargo entendido, escrito y acotado, y tenemos criterios para tomar decisiones. Lo que no tenemos todavía es un dibujo. En la lección siguiente, 04-02 Diagramas Entidad-Relación, aprenderemos el lenguaje gráfico con el que se piensa un dominio antes de que exista ninguna tabla: entidades fuertes y débiles, atributos simples, compuestos, multivaluados y derivados, relaciones con sus cardinalidades y su participación, las notaciones de Chen y de pata de gallo, y las jerarquías de generalización que por fin resolverán el problema de tener libros, DVD, revistas y audiolibros en el mismo catálogo. Al final de esa lección tendremos el diagrama ER completo de BiblioRed ampliado, decisión a decisión.