Els tres mòduls anteriors han estat, en el fons, un curs d'eines: sabem què és un SGBD, sabem escriure CREATE TABLE, sabem consultar amb JOIN i agregats, sabem protegir la integritat amb claus foranes i sabem modelar documents a MongoDB. El que encara no hem fet és decidir quines taules han d'existir. L'esquema de BiblioRed —aquestes set taules que fem servir des de la lliçó 02-02— va aparèixer gairebé per generació espontània: calia desar llibres, doncs llibres; calia desar préstecs, doncs prestecs. Va funcionar perquè el domini era petit i evident.

Aquest marge s'acaba avui. L'ajuntament de Vallmar acaba d'encarregar a BiblioRed una ampliació real del servei: gestionar esdeveniments culturals, inscripcions de socis, sales i aforaments, multes i pagaments, i un catàleg que ja no és només de llibres. És un encàrrec prou gran perquè el mètode d'"obro l'editor i vaig escrivint taules" produeixi un desastre car. I és exactament el material amb què treballarem les quatre lliçons d'aquest mòdul: aquí recollim els requisits i fixem els principis, a 04-02 els dibuixem, a 04-03 els convertim en taules i a 04-04 els blindem amb tipus i restriccions.

Aquesta lliçó tracta del que passa abans de teclejar. Quins objectius persegueix un esquema, quines fases travessa un disseny, com es converteix una conversa amb un client en material de treball, com es distingeix una entitat d'un atribut, com s'anomenen les coses perquè d'aquí a cinc anys se segueixin entenent, i quins patrons de disseny cal reconèixer per no caure-hi. És la lliçó menys "tècnica" del mòdul i probablement la que més diners estalvia.

1. Què és dissenyar un esquema i per què es fa abans de teclejar
2. Els sis objectius d'un bon esquema i les seves tensions
3. Les tres fases del disseny: conceptual, lògica i física
4. La recollida de requisits: de la conversa al document
5. L'encàrrec de BiblioRed: document de requisits v1.0
6. Detectar regles implícites i ambigüitats
7. Identificar entitats, atributs i relacions en el text
8. Entitat o atribut? Criteris de decisió
9. Convencions de nomenclatura
10. Clau natural enfront de clau subrogada, ara com a decisió de disseny
11. "Una cosa, un lloc" i "un fet, una fila"
12. Antipatrons de disseny freqüents
13. Documentar i versionar l'esquema
14. Errors Habituals i Consells
15. Exercicis
16. Conclusió

Dissenyar un esquema és decidir, abans d'escriure ni una sola sentència DDL, quines coses del món real representarà la base de dades, com es relacionen entre si i quines regles han de complir sempre.

La pregunta raonable de qui comença és: per què no dissenyar sobre la marxa? Al capdavall ALTER TABLE existeix, i al mòdul 2 el vam fer servir diverses vegades sense drama. La resposta té tres parts:

El cost de canviar creix amb el temps, i no linealment. Canviar una taula el primer dia costa escriure una línia. Canviar-la quan té 40.000 files, tres aplicacions que la consulten, un informe mensual que l'agrega i una còpia replicada en un sistema d'anàlisi costa una migració coordinada, una finestra d'aturada i un pla de tornada enrere. Aquest és l'argument econòmic i és el més fort.

Les dades sobreviuen a les aplicacions. L'aplicació web de BiblioRed es reescriurà probablement dues o tres vegades en quinze anys; els préstecs del 2026 hi continuaran sent. Un esquema mal dissenyat és un deute que s'hereta.

Un esquema és una teoria del negoci, no un contenidor. Quan decidim que un préstec relaciona un soci amb un exemplar i no amb un llibre, estem afirmant alguna cosa sobre com funciona la biblioteca. Si aquesta afirmació és falsa, cap quantitat de codi d'aplicació ho arreglarà. Dissenyar és, sobretot, entendre el domini, i per això la fase més valuosa es fa parlant amb persones, no amb el gestor.

Una manera útil de veure-ho: el codi de l'aplicació expressa el que el sistema fa; l'esquema expressa el que el sistema creu que és veritat. El segon canvia molt més a poc a poc i equivocar-s'hi costa molt més car.

Un esquema no es jutja per ser "bonic". Es jutja contra sis objectius concrets:

1. Integritat. L'esquema ha de fer impossibles els estats invàlids, no només improbables. Si una multa mai no pot ser negativa, l'esquema —no el formulari web— ho ha d'impedir. Això ja ho vam defensar a 02-06 per a les claus foranes; a 04-04 ho estendrem a CHECK, NOT NULL i dominis.
2. Absència de redundància innecessària. Cada fet ha d'estar emmagatzemat en un sol lloc. Si el nom d'una sucursal apareix copiat en tres taules, tard o d'hora les tres discreparan. Fixa't en l'adjectiu: innecessària. Hi ha redundància deliberada i justificada, i es diu desnormalització (mòdul 5).
3. Capacitat de respondre a les consultes del negoci. Un esquema elegantíssim que no pot respondre "quantes places lliures queden al club de lectura de dijous?" és un esquema fallit. Per això la llista de consultes forma part del document de requisits.
4. Mantenibilitat. Que una persona nova entengui l'esquema en una tarda. Noms clars, estructura previsible, documentació.
5. Evolució sense migracions traumàtiques. Afegir un tipus nou d'esdeveniment no hauria de requerir ALTER TABLE. Afegir un tipus nou de material tampoc no hauria de requerir reescriure les consultes existents. Un bon disseny anticipa quin eix creixerà.
6. Rendiment raonable. No "màxim": raonable. El rendiment es treballa després, amb índexs i optimització (lliçó 06-03), però el disseny pot fer-lo impossible: una consulta que necessita recórrer set taules d'unió per pintar la portada del web és un problema de disseny, no d'índexs.

Aquests sis objectius no són compatibles entre si. Dissenyar és triar el punt d'equilibri, i saber quin s'està sacrificant.

La regla pràctica: quan dos objectius xoquen, guanya la integritat, llevat que hi hagi un mesurament que demostri que el cost és inassumible. Les dades incorrectes són l'únic problema que no es pot arreglar després.

El disseny de bases de dades s'organitza clàssicament en tres fases. No són burocràcia: cadascuna respon a preguntes diferents i barrejar-les és la causa més freqüent de dissenys dolents, perquè qui comença discutint si un camp és VARCHAR(50) o TEXT ja ha deixat de pensar en el domini.

Les fletxes discontínues són importants: el procés no és una cascada. Cada fase descobreix errors de l'anterior, i tornar enrere és senyal que el mètode funciona.

A la lliçó 01-04 vam veure els tres nivells d'ANSI/SPARC: extern, conceptual i intern. Les tres fases del disseny produeixen aquests tres nivells, encara que la correspondència no sigui exactament un a un:

La conseqüència pràctica és que el disseny físic es pot canviar sense tocar les consultes (aquesta és la independència física), i per això posposar-lo no costa res. En canvi, el disseny lògic és el contracte amb les aplicacions, i per això canviar-lo sí que fa mal.

Un detall que sovint es passa per alt: el disseny conceptual és independent fins i tot del paradigma. El mateix diagrama ER de BiblioRed serviria per derivar un esquema relacional o un model documental de MongoDB (amb les tècniques de 03-03). Per això es dibuixa primer.

Ningú no arriba amb un document de requisits. Arriba amb una frase: "volem gestionar també els esdeveniments de les biblioteques". La feina consisteix a convertir això en material sobre el qual es pugui dissenyar.

• Entrevistes amb qui farà servir el sistema (bibliotecaris, coordinació d'activitats, administració).
• Documents existents: fulls de càlcul, formularis en paper, cartells, correus. Són or: un formulari d'inscripció en paper conté la llista d'atributs que algú ja va considerar necessaris.
• El sistema actual, si n'hi ha. BiblioRed ja té set taules: el que és nou hi ha d'encaixar, no ignorar-les.
• Normativa. Un ajuntament té reglaments d'ús de sales i ordenances de taxes. Allà hi ha els imports de les multes.

Aquesta llista és probablement el més reutilitzable de la lliçó. Per a cada cosa que el client esmenti:

Les dues files més productives són excepcions i consultes.

La pregunta d'excepcions —"ha passat mai que un esdeveniment es quedés sense ponent?"— és la que descobreix les regles que el client creu òbvies i no ho són. Un client no diu mai "un esdeveniment pot no tenir sala"; ho diu quan li preguntes si això ha passat mai i respon "bé, el contacontes d'estiu el fem al pati".

La pregunta de consultes és la que evita dissenyar un esquema que no serveix. La llista de consultes és un requisit de primera classe i ha de constar al document: a 04-03 la farem servir com a criteri de validació de l'esquema resultant.

Quan el client demana alguna cosa, hi ha tres respostes possibles i només dues són honestes: "sí, i això és el que implica", "sí, però a la versió 2 i per aquest motiu" i "no, perquè…". Acceptar-ho tot sense dimensionar-ho produeix esquemes amb vint taules per a funcionalitats que ningú no farà servir. L'abast és una decisió de disseny, i per això el document de requisits porta sempre un apartat explícit de "fora d'abast".

Aquest és el resultat de tres reunions amb la coordinació de BiblioRed i amb l'àrea de Cultura de l'ajuntament de Vallmar. És el document que les tres lliçons següents faran servir: a 04-02 el dibuixarem, a 04-03 el convertirem en taules i a 04-04 el blindarem. Convé llegir-lo sencer abans de continuar.

Ampliació del servei de BiblioRed — Document de requisits v1.0

Context. BiblioRed gestiona 4 sucursals (Centre, Nord, Sud i Est), 12.000 socis i 40.000 exemplars, sobre un esquema PostgreSQL de set taules: sucursals, autors, socis, llibres, exemplars, prestecs i reserves. L'ajuntament amplia l'encàrrec a la gestió d'activitats culturals, cobrament de multes i catàleg multiformat.

A. Requisits funcionals

R1 — Catàleg multiformat. El catàleg deixa de ser només de llibres. Ha d'admetre llibres, DVD, revistes i audiollibres. Tots comparteixen títol, idioma, editorial o productora, any de publicació i data d'alta al catàleg. A més:

• els llibres tenen ISBN, nombre de pàgines i tipus d'enquadernació;
• els DVD tenen durada en minuts, format de vídeo, codi de regió i una llista d'idiomes de subtítols;
• les revistes tenen ISSN, número i periodicitat;
• els audiollibres tenen durada, narrador i format de fitxer.

Un material pot tenir autor associat; les revistes normalment no en tenen. Tot el que avui és un llibre ha de continuar funcionant exactament igual.

R2 — Exemplars. Cada material té de 0 a N exemplars físics, cadascun ubicat en una sucursal, amb estat i data d'adquisició. Els exemplars s'identifiquen amb un codi imprès (EJ-3081) i, a més, es numeren dins del seu material: "l'exemplar 3 d'El mapa del temps". Es presten exemplars; es reserven materials.

R3 — Sales. Cada sucursal disposa d'entre 1 i 6 sales. De cada sala interessa el nom, l'aforament màxim de persones, la planta i si és accessible per a persones amb mobilitat reduïda. El nom de sala només és únic dins de la seva sucursal: hi ha una "Sala Polivalent" a Centre i una altra a Nord.

R4 — Esdeveniments. Un esdeveniment cultural té títol, descripció, tipus, sala on se celebra, data i hora d'inici, data i hora de fi, nombre de places ofertes, estat (programat, obert, complet, celebrat, cancellat) i si està publicat al web. Un esdeveniment se celebra en una sola sala; la sucursal de l'esdeveniment és la de la seva sala. A la versió 1.0, un esdeveniment és una sessió única.

R5 — Tipus d'esdeveniment. Avui són: club de lectura, taller, presentació, contacontes i xerrada. L'ajuntament vol poder afegir tipus nous sense trucar a l'informàtic. De cada tipus interessa el nom, una descripció i una durada estàndard orientativa.

R6 — Inscripcions. Un soci s'inscriu a un esdeveniment. Un esdeveniment admet molts socis i un soci s'inscriu a molts esdeveniments. De cada inscripció es desa la data, l'estat (confirmada, llista_espera, cancellada, assistida) i el nombre d'acompanyants (de 0 a 3). Un soci no es pot inscriure dues vegades al mateix esdeveniment.

R7 — Ponents. Els esdeveniments els condueixen ponents, que poden ser personal propi de BiblioRed o professionals externs. Un esdeveniment pot tenir diversos ponents i un ponent participa en molts esdeveniments. En un mateix esdeveniment, una persona pot exercir més d'un paper (moderar el col·loqui i a més impartir el taller). De cada participació s'anoten els honoraris, que són 0 per al personal propi.

R8 — Materials tractats en un esdeveniment. Un club de lectura comenta un o diversos materials del catàleg; un taller pot recomanar bibliografia. S'anota si el material és el principal de l'esdeveniment o només recomanat.

R9 — Informe posterior. Un cop celebrat un esdeveniment, la coordinació redacta un informe amb el nombre real d'assistents, la valoració mitjana de les enquestes i observacions en text lliure. No tots els esdeveniments tenen informe, i cap no en té més d'un.

R10 — Multes. Un préstec retornat fora de termini genera una multa per retard. També es poden emetre multes per deteriorament o per pèrdua de l'exemplar. Un mateix préstec pot generar com a molt una multa de cada motiu. La multa té import en euros, data d'emissió i estat (pendent, pagada, condonada, anullada).

R11 — Pagaments. Una multa es pot liquidar en diversos pagaments parcials, en efectiu al taulell, amb targeta o a través de la passarel·la web de l'ajuntament. De cada pagament es desa la data i hora, l'import, el mètode i una referència externa (número de rebut o identificador de la passarel·la). L'import pendent d'una multa és el seu import menys la suma dels seus pagaments.

R12 — Telèfons de soci. Avui hi ha un sol telèfon per soci. Es demana poder desar-ne fins a tres per soci, cadascun amb el seu tipus (mobil, fix, feina).

R13 — Adreça de sucursal. Avui l'adreça és un únic text lliure. El web nou necessita mostrar la ciutat per separat i cercar sucursals per codi postal.

R14 — Bloqueig per deute. Un soci amb més de 20 € pendents de pagament no es pot inscriure a esdeveniments ni endur-se préstecs nous.

B. Regles de negoci

Codi	Regla
RN1	Les places ofertes d'un esdeveniment no poden superar l'aforament de la seva sala.
RN2	Les inscripcions confirmades, comptant acompanyants, no poden superar les places ofertes; a partir d'aquí es passa a llista d'espera.
RN3	La data i hora de fi d'un esdeveniment ha de ser posterior a la d'inici.
RN4	Dos esdeveniments no cancel·lats no es poden encavalcar en el temps a la mateixa sala.
RN5	L'import d'una multa mai no és negatiu, i la suma dels seus pagaments mai no supera el seu import.
RN6	Només s'hi poden inscriure socis actius.
RN7	La data d'inscripció no pot ser posterior a l'inici de l'esdeveniment.
RN8	Un esdeveniment publicat al web ha de tenir sala assignada i places ofertes més grans que zero.
RN9	L'ISBN identifica unívocament un llibre; l'ISSN juntament amb el número identifica unívocament una revista.
RN10	Un material no es pot reservar si no té cap exemplar al catàleg.

C. Consultes que el sistema ha de poder respondre

Codi	Consulta
C1	Agenda pública d'esdeveniments del mes, per sucursal, només els publicats.
C2	Places lliures d'un esdeveniment concret, en temps real.
C3	Llista de socis inscrits a un esdeveniment amb el seu telèfon de contacte.
C4	Historial d'esdeveniments als quals s'ha inscrit un soci.
C5	Ocupació mitjana de cada sala per sucursal i trimestre.
C6	Recaptació de multes per mes i mètode de pagament.
C7	Socis amb deute pendent superior a 20 €.
C8	Catàleg filtrat per tipus de material i idioma.
C9	DVD que tinguin subtítols en català.
C10	Els deu materials més prestats, desglossats per tipus de material.
C11	Ponents que han participat en més de tres esdeveniments, amb els seus honoraris totals.
C12	Esdeveniments celebrats fa més de 15 dies que encara no tenen informe.

D. Volums estimats a tres anys

Concepte	Avui	D'aquí a 3 anys
Socis	12.000	16.000
Materials (títols)	18.000	25.000
Exemplars	40.000	55.000
Esdeveniments	0	1.200 (≈400/any)
Inscripcions	0	30.000
Multes	0	9.000

E. Fora d'abast a la versió 1.0

• Reserva de sales per part de particulars o entitats alienes.
• Esdeveniments amb diverses sessions (cicles, cursos de diverses setmanes).
• Venda d'entrades o esdeveniments de pagament.
• Gestió de personal, nòmines i contractes dels ponents externs.
• Integració comptable amb el sistema de l'ajuntament (els pagaments es registren, no es comptabilitzen).

Fixa't en tres coses d'aquest document, perquè són les que el fan útil:

1. Les cardinalitats estan escrites en prosa, encara no dibuixades ("un esdeveniment se celebra en una sola sala", "un soci s'inscriu a molts esdeveniments"). Aquest és el material de 04-02.
2. Les regles de negoci estan numerades i separades dels requisits funcionals. A 04-04 les convertirem, una per una, en CHECK, UNIQUE o lògica d'aplicació.
3. Les consultes i l'abast són explícits. Sense les primeres no es pot validar el disseny; sense el segon, el disseny no acaba mai.

El document anterior no va sortir així de la primera reunió. Va sortir de detectar ambigüitats en el que deia el client i tornar-les-hi convertides en preguntes. Aquestes són les cinc que van aparèixer a BiblioRed, i són un catàleg força representatiu del que un es troba:

I aquests són els senyals lingüístics que delaten una regla implícita, útils com a llista de comprovació en llegir qualsevol enunciat:

• "Normalment", "gairebé sempre", "en general" → hi ha excepcions sense documentar. "Normalment l'esdeveniment té un sol ponent" significa que de vegades en té dos, i això canvia la cardinalitat.
• "I també" al final d'una frase → un requisit que s'hi ha colat sense analitzar.
• Un plural on esperaves singular → "els idiomes de subtítols" (R1) és literalment un atribut multivaluat, i es veu en la paraula.
• Un adjectiu avaluatiu → "esdeveniments importants", "socis problemàtics": cal preguntar per la definició operativa, perquè acabarà sent una columna o una regla.
• Un verb en passat o futur → "els ponents que hi van participar": implica historial, i implica que esborrar no és una opció.
• "Ja ho sabeu" o "això és obvi" → gairebé mai no ho és.

Hi ha una tècnica clàssica, gairebé mecànica, per arrencar: subratllar els substantius i els verbs de l'enunciat.

• Els substantius són candidats a entitat (si són coses amb identitat pròpia) o a atribut (si són propietats d'una altra cosa).
• Els verbs que connecten dos substantius són candidats a relació: un soci s'inscriu en un esdeveniment, un esdeveniment se celebra en una sala, un préstec genera una multa.
• Els adjectius i quantificadors aporten cardinalitat i obligatorietat: "una sola sala", "fins a tres", "de 0 a N".

Apliquem-ho a R4 i R6:

Un esdeveniment cultural té títol, descripció, tipus, sala on se celebra, data i hora d'inici… Un soci s'inscriu a un esdeveniment… De cada inscripció es desa la data, l'estat i el nombre d'acompanyants.

Resultat del primer escombrat:

La tècnica del subratllat arrenca bé i després enganya. Els seus tres errors típics:

1. Sinònims que semblen entitats diferents. "Soci", "usuari", "lector" i "abonat" poden ser el mateix dit per quatre persones diferents. Cal consolidar el vocabulari, i d'aquí surt el glossari del projecte.
2. Homònims que semblen la mateixa entitat. "Estat" apareix a exemplars, a reserves, a esdeveniments, a inscripcions i a multes, i són cinc conjunts de valors completament diferents.
3. Entitats que no s'anomenen mai. Ningú no va dir la paraula "participació" a R7, i tanmateix és una entitat (la relació entre ponent i esdeveniment amb els seus honoraris). Les entitats que emergeixen d'una relació N:M gairebé mai no apareixen com a substantiu a l'enunciat. Cal buscar-les preguntant: "quan això es creua amb allò, hi ha alguna cosa a anotar del creuament?".

Per això el subratllat és un punt de partida, no un algorisme. La llista definitiva es tanca dibuixant, que és el que farem a la lliçó següent.

Aquest és el dubte que més temps consumeix en un disseny real. Tornem al "tipus d'esdeveniment" de R5.

Opció A — atribut: esdeveniments.tipus_esdeveniment és un text amb valors 'club_lectura', 'taller', 'presentacio'…

Opció B — entitat: existeix una taula tipus_esdeveniment i esdeveniments hi apunta amb una clau forana.

Cinc criteris per decidir, aplicats al cas:

Tres criteris clars a favor: tipus_esdeveniment serà una entitat. Compara-ho amb l'atribut idioma d'un material: no té propietats interessants, la llista és estable (ISO 639) i ningú no "gestionarà idiomes". Aquest es queda com a atribut.

És una entitat si té atributs propis, o cicle de vida propi, o si el conjunt de valors el gestiona algú. És un atribut si és un valor simple, estable i sense propietats.

I una regla d'or sobre el moment: davant del dubte raonable, comença per atribut. Convertir un atribut en entitat més endavant és una migració mecànica (crear taula, poblar-la amb els distints, substituir la columna per una FK). Convertir una entitat en atribut també es pot fer, però implica que has estat mantenint una taula buida de sentit durant dos anys. L'asimetria de cost afavoreix la simplicitat.

Els noms de l'esquema són la interfície que veuran totes les persones que hi treballin durant anys. Aquestes són les decisions que cal prendre, amb l'elecció de BiblioRed i el seu motiu:

Hi ha noms que semblen naturals i són paraules reservades de SQL. Fer-los servir obliga a entrecometar per sempre, en totes les consultes, en tots els llenguatges, en tots els informes.

Paraules que cal evitar com a noms de taula 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 català el risc és menor, però union, ordre (no reservada, però confusa) i check apareixen amb freqüència.

El principi que governa tot aquest apartat: gairebé cap d'aquestes decisions no és objectivament correcta. Plural o singular tant és. El que no tant és és que la meitat de l'esquema estigui en plural i l'altra meitat en singular, perquè aleshores ningú no pot escriure una consulta sense mirar abans el catàleg. La consistència val més que la correcció.

A la lliçó 02-01 vam plantejar el debat amb l'ISBN: llibres té isbn (clau natural candidata) i llibre_id (subrogada). Aleshores era una qüestió teòrica. Ara és una decisió que cal prendre per a cadascuna de les taules noves, i mereix criteris ferms.

1. Cap clau natural no és tan estable com sembla. L'ISBN és l'exemple canònic i serveix d'escarment: va passar de 10 a 13 dígits el 2007, es reutilitzen per error, hi ha edicions sense ISBN i hi ha llibres amb dos. El DNI canvia amb la nacionalitat. El codi de sala canvia quan es reforma la planta. Qualsevol valor que gestioni un tercer pot canviar, i si és la teva clau primària, aquest canvi es propaga en cascada a totes les taules que el referencien.

2. La clau subrogada no elimina la necessitat de la natural: la complementa. Aquest és l'error freqüent. Posar material_id com a PK no autoritza a oblidar-se de l'ISBN: si no es declara UNIQUE sobre l'ISBN, acabaran existint dues files per al mateix llibre i cap restricció no ho impedirà. La combinació correcta és PK subrogada + UNIQUE sobre la clau natural, que és exactament el que fa l'esquema actual de BiblioRed (llibre_id PK, isbn UNIQUE).

3. L'excepció són les taules d'unió. A inscripcions, la parella (esdeveniment_id, soci_id) és una clau natural perfecta: no canvia (si canviés, seria una altra inscripció), és curta, i és exactament la regla de negoci de R6 ("un soci no es pot inscriure dues vegades"). Afegir-hi un inscripcio_id subrogat sovint és soroll; només es justifica si una altra taula ha de referenciar la inscripció. Ho decidirem taula per taula a 04-03.

Regla de BiblioRed per a l'ampliació: clau subrogada <entitat>_id en tota entitat forta, sempre acompanyada d'UNIQUE sobre la clau natural quan n'hi hagi; clau composta natural a les taules d'unió i a les entitats febles, llevat que calgui referenciar-les des de fora.

Dos principis que s'enuncien en una línia i expliquen la majoria dels problemes de disseny.

Cada fet ha d'estar emmagatzemat exactament una vegada. Si l'aforament de la Sala Polivalent de Centre és a sales i també copiat a cada fila d'esdeveniments, existeix la possibilitat física que discrepin. I el que pot discrepar, amb prou temps, discrepa.

El dany concret d'incomplir-ho són les tres anomalies clàssiques:

Cada fila ha de representar un sol fet del món. Una fila de prestecs diu "el soci 14 es va endur l'exemplar EJ-3081 el dia tal". Això és un fet. Si aquesta mateixa fila portés també l'adreça del soci, estaria representant dos fets diferents —el préstec i el domicili— enganxats per accident, i patiria les tres anomalies anteriors.

Aquests dos principis, formalitzats amb matemàtiques, s'anomenen normalització, i el procés d'aplicar-los produeix les formes normals (1NF, 2NF, 3NF, BCNF…). És un cos de teoria amb definicions precises de dependència funcional, i és el mòdul 5 complet del curs: els conceptes a 05-01, les formes normals una a una a 05-02, el procés aplicat a 05-03 i els casos en què es decideix deliberadament trencar-les —desnormalitzar— a 05-04.

En aquest mòdul treballarem amb la versió intuïtiva ("una cosa, un lloc") i tornarem sobre l'esquema de BiblioRed al mòdul 5 amb l'instrumental formal per verificar que aguanta. No intentis aplicar formes normals encara: el disseny d'aquest mòdul es fa per comprensió del domini, i aquesta és precisament la manera com es fa a la pràctica professional.

Un antipatró és una solució que sembla raonable, es fa servir molt i causa un dany previsible. Reconèixer-los pel seu nom estalvia discussions.

En lloc de columnes, una taula genèrica de tripletes:

Sembla la solució perfecta a R1: cada tipus de material té els seus atributs i així hi caben tots. El que es perd:

• Els tipus de dades. durada_min és text; res no impedeix que valgui 'ahir'.
• Les restriccions. No hi ha NOT NULL possible: no es pot exigir que un llibre tingui ISBN.
• Les consultes. "DVD en català de més de 90 minuts" necessita dos auto-JOIN i una conversió de tipus.
• El rendiment, per l'anterior.

Quan es justifica: quan els atributs els defineix l'usuari en temps d'execució i són veritablement impredictibles (formularis configurables, catàlegs de productes amb milers de famílies). Fins i tot aleshores, avui la resposta acostuma a ser una columna JSONB (03-03), que conserva tipus, permet índexs GIN i valida amb $jsonSchema o CHECK. Per a BiblioRed, amb quatre tipus de material coneguts, EAV seria un error: la solució correcta és la jerarquia de generalització que veurem a 04-02 i 04-03.

És la resposta temptadora a R12 ("fins a tres telèfons"), perquè el requisit fins i tot hi posa el límit. El que falla:

• "Quants socis tenen mòbil?" requereix mirar tres columnes i unir-les amb UNION.
• El quart telèfon arriba sempre, i porta un ALTER TABLE i un canvi en totes les consultes.
• El tipus es perd: quina de les tres és el mòbil?
• La majoria de les files tenen NULL en dues de les tres columnes.

La forma correcta és una taula telefons_soci, és a dir, tractar l'atribut multivaluat com el que és. A 04-03 ho formalitzarem com a regla de transformació.

Directament al camí de R1 i de la consulta C9 ("DVD amb subtítols en català"). El que passa a la pràctica:

Aquesta consulta retorna també els DVD amb subtítols en 'cat', en 'oc-ca' i qualsevol valor que contingui les lletres ca en qualsevol posició. No hi ha manera de garantir que els codis siguin vàlids, no hi ha manera de comptar quants DVD hi ha per idioma sense trossejar cadenes, i no s'hi pot posar una clau forana a una taula d'idiomes. És la violació més pura d'"un fet, una fila".

L'alternativa correcta és una taula subtitols_dvd. Si de debò cal l'agrupació en un sol camp, PostgreSQL ofereix arrays i JSONB amb operadors i índexs propis (subtitols @> ARRAY['ca']), que no són el mateix que una cadena amb comes: conserven l'estructura. Ho veurem a 04-04.

Una taula anomenada dades, general, parametres o varis on es van ficant columnes que no encaixaven enlloc. Símptomes: nom genèric, més de 40 columnes, la meitat NULL, i cap persona de l'equip capaç d'explicar què representa una fila.

El diagnòstic és sempre el mateix: si no pots completar la frase "cada fila d'aquesta taula és un/una ______", la taula està malament. Una fila de prestecs és un préstec. Una fila de dades és… res.

L'antipatró menys comentat i probablement el més car, perquè qui el comet creu que ho està fent especialment bé. Consisteix a modelar avui la flexibilitat que potser caldrà d'aquí a tres anys: una taula entitats genèrica amb tipus_entitat, un sistema de metadades configurable, una jerarquia de cinc nivells perquè "qui sap".

Per a BiblioRed la temptació concreta és real: "ja que fem esdeveniments, fem cicles d'esdeveniments, amb sessions, i plantilles d'esdeveniment, i esdeveniments recurrents". El document de requisits ho va tallar d'arrel posant-ho a l'apartat E, fora d'abast. Quan arribi el requisit de debò, s'afegeix una taula sessions i esdeveniments guanya una FK opcional: mitja hora de feina, amb el requisit real al davant en lloc d'imaginat.

El contrapès honest: hi ha un tipus d'anticipació que sí que compensa, i és la que evita perdre informació. Si avui es desa només el saldo i demà calen els moviments, aquests moviments ja no existeixen. Desar fets en lloc de resums gairebé mai no es lamenta; construir maquinària genèrica, gairebé sempre.

Un esquema sense documentació és un esquema que només entén qui el va escriure, mentre se'n recordi.

La regla és simple: ningú no toca la base de producció a mà. Tot canvi d'esquema és un fitxer versionat al repositori, amb número d'ordre, que s'aplica una sola vegada.

Cada migració ha de ser idempotent en el resultat (aplicar-la dues vegades no ha de trencar res) i, en la mesura del possible, tenir la seva tornada enrere escrita. Eines com Flyway, Liquibase, Alembic o les migracions integrades als frameworks automatitzen el registre del que s'ha aplicat; el detall d'eines concretes és a 09-03. L'essencial és l'hàbit, no l'eina.

PostgreSQL permet adjuntar comentaris al mateix catàleg. L'avantatge davant d'un document a part és que no es pot desincronitzar de l'esquema per descuit, perquè viu dins seu.

Es consulten des de psql amb \d+ inscripcions, i qualsevol eina gràfica els mostra. Aquest últim comentari, el de la columna obsoleta, és el que evita que d'aquí a dos anys algú construeixi un informe sobre una dada congelada.

És la taula que acompanya el diagrama i que qualsevol persona pot llegir sense saber SQL. Un extracte del de BiblioRed:

I una última peça que gairebé ningú no escriu i que salva projectes: un registre de decisions. Tres columnes —decisió, alternatives descartades, motiu— amb entrades com "un esdeveniment és una sessió única; es va descartar modelar cicles; motiu: fora d'abast v1.0, es preveu una taula sessions si arriba el requisit". Quan d'aquí a un any algú pregunti "per què això està així?", la resposta existirà.

Començar pel CREATE TABLE. És l'error arrel del qual deriven gairebé tots els altres. Escriure DDL dóna sensació d'avanç i consolida decisions que encara no s'han pensat. Dibuixa primer, encara que sigui en un tovalló.

Dissenyar a partir de les pantalles. Si l'esquema copia l'estructura dels formularis de l'aplicació, quedarà lligat a una interfície que canviarà l'any vinent. Les pantalles són una font de requisits, no un model de dades.

Confondre "no ho han demanat" amb "no passa". El client no va demanar desar dos ponents per esdeveniment; simplement no se li va acudir esmentar-ho fins que se li va preguntar per les excepcions. Pregunta sempre pels casos rars: són els que trenquen les cardinalitats.

Modelar el present i oblidar el temps. "Desem el telèfon del soci" està bé; "desem a quina sucursal pertany un soci" amaga una pregunta: i si canvia? Interessa saber a quina pertanyia quan va demanar aquell préstec? Preguntar "necessites l'històric?" a cada relació costa cinc segons i evita redissenys complets.

Ficar la unitat al nom i no al tipus. durada_min és acceptable com a convenció explícita, però import sense especificar moneda ni escala no ho és. Documenta les unitats al diccionari de dades i reforça-les amb el tipus (04-04).

Fer servir el mateix nom per a conceptes diferents. Cinc columnes estat amb cinc conjunts de valors incompatibles és una font permanent de confusió. O es qualifiquen (estat_esdeveniment, estat_multa) o es documenten meticulosament.

Consell: valida el disseny llegint-lo en veu alta. "Un esdeveniment se celebra en una sala; una sala acull molts esdeveniments; un esdeveniment pot no tenir sala si és a l'aire lliure." Si la frase sona estranya, el disseny està malament. Aquest truc funciona sorprenentment bé i no costa res.

Consell: recorre la llista de consultes abans de donar el disseny per bo. Agafa de C1 a C12 i, per a cadascuna, digues en veu alta per quines taules passaries. Si alguna no es pot respondre, hi falta alguna cosa. Ho farem formalment al final de 04-03.

Consell: escriu el motiu, no només la decisió. "Un esdeveniment = una sessió" sense el perquè es reobre cada sis mesos. Amb el perquè, es tanca.

L'àrea de Cultura de Vallmar afegeix aquest paràgraf a l'encàrrec:

"A més volem portar el control del material que es presta a les associacions del barri per a les seves activitats: projectors, altaveus i aquestes coses. Normalment ho demana el president de l'associació, i ho tornen al cap de pocs dies. Si s'espatlla alguna cosa, ho apuntem."

Identifica almenys quatre ambigüitats o regles implícites i escriu, per a cadascuna, la pregunta concreta que faries al client. Indica també quin senyal lingüístic t'hi va alertar.

Per a cada element, decideix si a l'esquema de BiblioRed ha de ser entitat o atribut, aplicant els cinc criteris de l'apartat 8. Justifica-ho en una frase.

1. El mètode de pagament d'un pagament (efectiu, targeta, passarella).
2. L'editorial d'un material.
3. El codi postal d'una sucursal.
4. El motiu d'una multa (retard, deteriorament, perdua).
5. La nacionalitat d'un autor.

Un equip extern proposa aquesta taula per resoldre els requisits R4, R6 i R9 d'una sola vegada:

Anomena tots els antipatrons presents, explica el dany concret que causa cadascun amb un exemple de BiblioRed, i descriu en dues o tres frases com ho reestructuraries (sense escriure SQL encara: això és 04-03).

Solució a l'Exercici 1

Qualsevol quatre d'aquestes sis és una resposta completa. Les més importants són la 2 (introdueix una entitat nova, associacions, que no era al model) i la 6 (canvia la cardinalitat del préstec).

Solució a l'Exercici 2

Solució a l'Exercici 3

Antipatrons presents:

1. Taula calaix de sastre. activitats amb tipus_registre barreja esdeveniments, inscripcions i informes en una sola taula. No es pot completar la frase "cada fila és un/una ___": unes són esdeveniments i altres són inscripcions. Conseqüència: cap columna no pot ser NOT NULL (el que és obligatori per a un esdeveniment no ho és per a una inscripció) i tota consulta arrossega un WHERE tipus_registre = ....
2. Columnes numerades (dada1, dada2, dada3). És EAV disfressat: el significat de dada2 depèn de tipus_registre. Ningú no sabrà d'aquí a un any que per a les inscripcions dada2 era l'estat. Impossible restringir valors.
3. Llista separada per comes a socis_apuntats. Trenca C2 (places lliures), C3 (inscrits amb telèfon) i C4 (historial del soci), impedeix la clau forana a socis i fa que esborrar un soci deixi brossa textual. A més no hi ha on posar la data ni els acompanyants de R6.
4. Redundància: aforament_sala copiat del catàleg de sales. Anomalia d'actualització immediata tan bon punt es reformi una sala (apartat 11).
5. Sala com a text lliure. "Sala Polivalent" no identifica res: R3 diu que el nom només és únic dins de la sucursal. Hi haurà 'Polivalent', 'Sala Polivalent' i 'polivalent ' amb espai.
6. Tipus inadequats: data VARCHAR(30) impedeix ordenar cronològicament, comparar rangs i respondre C1 i C12. És un avançament de 04-04.
7. Nom de columna id en lloc d'activitat_id: menor, però incoherent amb la convenció de l'esquema existent.

Reestructuració proposada: separar en entitats amb identitat pròpia —esdeveniments, sales, inscripcions, informes_esdeveniment— unides per claus foranes; convertir la llista de socis apuntats en files d'inscripcions, una per soci, amb els seus atributs de data, estat i acompanyants; eliminar aforament_sala d'esdeveniments i obtenir-lo per JOIN amb sales; i substituir dada1..3 per columnes amb nom i tipus a la taula que correspongui. És exactament el diagrama que dibuixarem a la lliçó següent.

Aquesta lliçó ha canviat la manera de treballar del curs: d'escriure SQL a decidir quin SQL cal escriure.

• Dissenyar abans de teclejar es justifica per tres raons: el cost de canviar creix de manera no lineal, les dades sobreviuen a les aplicacions i un esquema és una teoria del negoci, no un contenidor.
• Un esquema es jutja contra sis objectius —integritat, no-redundància, capacitat de respondre al negoci, mantenibilitat, evolució i rendiment raonable— que entren en conflicte entre si. Quan xoquen, guanya la integritat llevat de prova en contra.
• El disseny té tres fases: conceptual (què existeix), lògica (quines taules) i física (com s'hi accedeix ràpid). Es corresponen amb els nivells d'ANSI/SPARC de 01-04, i barrejar-les és la causa més freqüent de dissenys dolents.
• La recollida de requisits és una tècnica amb preguntes concretes. Les dues més productives són les d'excepcions ("ha passat mai que…?") i les de consultes ("què li preguntaràs al sistema?").
• El document de requisits v1.0 de BiblioRed —R1 a R14, deu regles de negoci, dotze consultes, volums i abast— queda tancat i és el material de les tres lliçons següents.
• Les ambigüitats es detecten per senyals lingüístics: "normalment", plurals inesperats, adjectius avaluatius, verbs en passat. Cinc ambigüitats reals de BiblioRed van quedar resoltes i escrites.
• Subratllar substantius i verbs arrenca la identificació d'entitats i relacions, però falla amb sinònims, homònims i amb les entitats que ningú no anomena —les que emergeixen d'un creuament N:M, com la participació d'un ponent.
• El dubte entitat o atribut es resol amb cinc criteris: atributs propis, cicle de vida, relacions pròpies, multiplicitat i estabilitat del conjunt de valors. Davant del dubte, comença per atribut: promocionar-lo després és barat.
• Les convencions de nomenclatura —plural, snake_case, sufix _id, FK amb el nom de la PK referenciada, català, restriccions anomenades— importen menys pel seu contingut que per la seva aplicació uniforme: la consistència val més que la correcció.
• Natural enfront de subrogada deixa de ser teoria: PK subrogada en tota entitat forta, sempre amb UNIQUE sobre la clau natural; clau composta natural a taules d'unió i entitats febles.
• "Una cosa, un lloc" i "un fet, una fila" eviten les anomalies d'actualització, inserció i esborrat. La seva versió formal és la normalització, que és el mòdul 5 sencer (05-01 i 05-02); aquí treballem amb la versió intuïtiva.
• Cinc antipatrons identificats i anomenats: EAV, columnes numerades, llistes amb comes dins d'una columna, taula calaix de sastre i sobreenginyeria prematura.
• Documentar i versionar: migracions numerades al repositori, COMMENT ON enganxat al catàleg, diccionari de dades llegible i registre de decisions amb els seus motius.

Tenim l'encàrrec entès, escrit i acotat, i tenim criteris per prendre decisions. El que encara no tenim és un dibuix. A la lliçó següent, 04-02 Diagrames Entitat-Relació, aprendrem el llenguatge gràfic amb què es pensa un domini abans que existeixi cap taula: entitats fortes i febles, atributs simples, compostos, multivaluats i derivats, relacions amb les seves cardinalitats i la seva participació, les notacions de Chen i de pota de gall, i les jerarquies de generalització que per fi resoldran el problema de tenir llibres, DVD, revistes i audiollibres al mateix catàleg. Al final d'aquella lliçó tindrem el diagrama ER complet de BiblioRed ampliat, decisió a decisió.