A la lliçó anterior vam arribar a una conclusió clara: BiblioRed necessita una base de dades. Però "base de dades" no designa una sola cosa. Hi ha famílies molt diferents entre si, cadascuna amb una manera pròpia d'estructurar la informació, nascuda per resoldre un problema concret. Triar malament en aquesta fase es paga car: significa forçar durant anys una eina a fer alguna cosa per a la qual no va ser pensada.

Aquesta lliçó és un panorama: un mapa del territori. No entrarem en el detall de cap família —això correspon al mòdul 2 per a les relacionals i al mòdul 3 per a NoSQL—, sinó que busquem que sàpigues què existeix, quina forma té cada opció i amb quins criteris es tria. Al final aplicarem aquests criteris a BiblioRed i decidirem, amb arguments, quina tecnologia farem servir a cada part del sistema.

1. Com es classifiquen les bases de dades
2. Bases de dades relacionals (RDBMS)
3. Panorama NoSQL: les quatre famílies
4. Models històrics: jeràrquic i en xarxa
5. Altres models especialitzats
6. OLTP davant d'OLAP
7. Taula comparativa general
8. Un exemple de codi per família
9. Com triar: criteris de decisió
10. Decisió aplicada a BiblioRed
11. Errors habituals i consells
12. Exercicis
13. Conclusió

Les bases de dades es poden classificar per diversos eixos, i convé no barrejar-los:

• Per model de dades: com s'estructura la informació. És l'eix principal (relacional, documental, clau-valor, columnar, graf, jeràrquic, en xarxa, objectes).
• Per càrrega de treball: per a què es fa servir (OLTP, operacions del dia a dia, davant d'OLAP, anàlisi).
• Per arquitectura de desplegament: client-servidor davant d'incrustada; en un sol node davant de distribuïda; autogestionada davant de servei gestionat al núvol.
• Per ubicació de la dada: en disc davant d'en memòria.

Una mateixa base de dades ocupa una posició a cada eix. PostgreSQL és relacional, OLTP, client-servidor i en disc. SQLite és relacional, OLTP, incrustada i en disc. Redis és clau-valor, en memòria i client-servidor. No són categories excloents.

En aquesta lliçó recorrerem sobretot l'eix del model de dades, i tancarem amb OLTP/OLAP perquè és la distinció que provoca més decisions d'arquitectura.

Són la família dominant des dels anys vuitanta i l'eix del curs.

Com estructuren les dades: en taules formades per files i columnes. Cada taula representa una entitat, cada fila una ocurrència, i les taules es connecten mitjançant claus (una columna d'una taula que apunta a l'identificador d'una altra). L'esquema es defineix per endavant: abans de guardar res, es declara quines columnes hi ha i de quin tipus.

Què garanteixen: integritat estricta (el gestor rebutja les dades que violen les regles), transaccions ACID (o tot o res, fins i tot davant de fallades) i un llenguatge de consulta estàndard i potentíssim, SQL.

Per a què són bones: qualsevol domini on les dades tinguin una estructura estable i ben coneguda, on les relacions importin i on la correcció no sigui negociable. Banca, facturació, gestió d'inventari, ERP, reserves... i biblioteques.

Quan costen: quan l'esquema canvia constantment, quan el volum exigeix repartir-se entre centenars de màquines, o quan la forma natural de la dada és molt jeràrquica i imbricada.

Productes representatius: PostgreSQL, MySQL/MariaDB, SQLite, Oracle Database, Microsoft SQL Server, IBM Db2.

En aquest curs, PostgreSQL serà la referència principal i SQLite l'alternativa lleugera per practicar. El model relacional formal i SQL són el contingut complet del mòdul 2.

"NoSQL" és un nom desafortunat —s'entén millor com a Not Only SQL— que agrupa sistemes sorgits a partir del 2007 amb un tret comú: renuncien a alguna garantia o rigidesa del model relacional a canvi de flexibilitat d'esquema o de capacitat de distribució. No són un model, sinó quatre famílies molt diferents entre si.

Aquí només veurem què són i per a què serveixen. El detall de cada família, les seves estructures internes i les seves operacions són la lliçó 03-02, i com es modelen les dades en cadascuna, la 03-03.

Guarden documents autocontinguts, típicament en JSON o BSON, agrupats en col·leccions. Cada document pot tenir camps diferents dels seus veïns, i pot contenir estructures imbricades (llistes, objectes dins d'objectes).

• Serveixen per a: dades amb estructura variable o jeràrquica que es llegeixen gairebé sempre senceres: catàlegs de producte, perfils, continguts editorials, ressenyes.
• Productes: MongoDB (el nostre exemple al mòdul 3), CouchDB, Amazon DocumentDB. PostgreSQL també emmagatzema JSON amb el seu tipus jsonb.

El model més simple possible: un diccionari gegant. Una clau única apunta a un valor, i el sistema gairebé no sap res de l'estructura d'aquest valor.

• Serveixen per a: accés extremadament ràpid per clau coneguda. Memòries cau, sessions d'usuari, comptadors, cues, límits de peticions.
• Productes: Redis, Memcached, Amazon DynamoDB (en el seu ús més simple), etcd.

Organitzen les dades per columnes en comptes de per files, i es dissenyen per repartir-se entre molts nodes. Permeten escriptures massives i lectures de rangs enormes.

• Serveixen per a: sèries d'esdeveniments de gran volum, telemetria, historials que creixen sense parar i es consulten per rangs.
• Productes: Apache Cassandra, HBase, ScyllaDB. (Compte: el terme "columnar" també es fa servir per a magatzems analítics com ClickHouse; el parentiu és real però el propòsit difereix.)

Modelen explícitament nodes i relacions entre ells, i totes dues coses poden tenir propietats. Recórrer relacions és l'operació barata.

• Serveixen per a: xarxes socials, recomanacions, detecció de frau, grafs de coneixement, anàlisi de rutes. Tot allò on la pregunta interessant és "com es connecta A amb B?".
• Productes: Neo4j, Amazon Neptune, ArangoDB.

Aquests dos models van precedir el relacional i avui pràcticament no es fan servir en projectes nous, però continuen vius en sistemes heretats de banca, assegurances i administració pública. El curs no hi tornarà, així que convé saber què són.

Model jeràrquic (anys 60). Organitza les dades en una estructura d'arbre: cada registre té un únic pare i pot tenir diversos fills. L'accés es fa navegant des de l'arrel.

• Avantatge: molt ràpid per a consultes que segueixen la jerarquia.
• Límit: un fill no pot tenir dos pares, així que les relacions "molts a molts" obliguen a duplicar dades. A BiblioRed, un llibre escrit per dos autors ja trenca el model.
• Producte emblemàtic: IBM IMS.

Model en xarxa (CODASYL, anys 70). Generalitza el jeràrquic permetent que un registre tingui diversos pares, mitjançant punters explícits.

• Avantatge: representa molts-a-molts sense duplicar.
• Límit: el programador ha de navegar manualment pels punters. Canviar l'estructura obliga a reescriure els programes.
• Producte emblemàtic: IDMS.

El problema comú a tots dos: no hi ha independència de dades. La manera d'accedir està soldada a la manera d'emmagatzemar. Aquesta és exactament la mancança que va atacar el model relacional, com veurem a la lliçó 01-03.

Famílies que existeixen, que et pots trobar a la pràctica i que aquest curs no torna a tractar.

Emmagatzemen objectes tal com existeixen en un llenguatge de programació, amb herència i mètodes inclosos, evitant la traducció entre objectes i taules. Prometien molt als anys noranta i van tenir una adopció limitada: l'ecosistema relacional era massa sòlid i van aparèixer els ORM, que resolien el problema de manera menys radical. Productes: db4o, ObjectDB. PostgreSQL conserva trets objecte-relacionals (tipus definits per l'usuari, herència de taules).

No són un model, sinó una arquitectura: el motor és una biblioteca que s'enllaça dins de l'aplicació, sense procés servidor ni xarxa. La base de dades és un fitxer local.

• Serveixen per a: aplicacions d'escriptori i mòbils, dispositius, formats de fitxer d'aplicació, proves automatitzades i aprenentatge.
• Productes: SQLite (el més desplegat del món: és a cada mòbil i cada navegador), DuckDB, LevelDB.

Farem servir SQLite al curs precisament per això: permet practicar SQL real sense instal·lar ni administrar un servidor.

Mantenen tot el conjunt de dades a la RAM, amb persistència en disc opcional. Guanyen un o dos ordres de magnitud en latència a canvi d'estar limitades per la memòria disponible i d'assumir risc de pèrdua si no persisteixen.

• Serveixen per a: memòries cau, rànquings en temps real, sessions, cues de treball.
• Productes: Redis, Memcached, SAP HANA (analítica en memòria).

Especialitzades en dades indexades per temps que arriben de manera contínua i gairebé mai no es modifiquen. Optimitzen la compressió, l'escriptura seqüencial i les consultes per finestra temporal, i solen incorporar agregacions i polítiques de retenció integrades.

• Serveixen per a: mètriques de sistemes, sensors IoT, cotitzacions, consum energètic.
• Productes: InfluxDB, TimescaleDB (extensió de PostgreSQL), Prometheus.

Les més recents. Emmagatzemen vectors d'alta dimensió (embeddings) que representen el significat de textos, imatges o àudio, i la seva operació característica és la cerca per similitud: donat un vector, trobar els més semblants. No busquen coincidències exactes, sinó proximitat semàntica.

• Serveixen per a: cerca semàntica, recomanació per contingut, sistemes que recuperen documents rellevants per alimentar un model de llenguatge.
• Productes: Pinecone, Milvus, Qdrant, Weaviate, i l'extensió pgvector de PostgreSQL.

La seva irrupció, molt recent, la situarem històricament a la lliçó 01-03.

Aquesta distinció no va de model de dades sinó de càrrega de treball, i explica per què moltes organitzacions tenen dues bases de dades amb les mateixes dades.

• OLTP (Online Transaction Processing): el sistema operatiu del dia a dia. Moltíssimes operacions petites i concurrents: registrar un préstec, donar d'alta un soci, actualitzar un estat. Prioritza la latència baixa per operació i la integritat transaccional. Es dissenya normalitzat (mòdul 5).
• OLAP (Online Analytical Processing) i data warehouse: el sistema d'anàlisi. Poques consultes, però enormes: agregar milions de files per dimensions. Prioritza el rendiment de lectura massiva. Es dissenya desnormalitzat (lliçó 05-04), sovint amb emmagatzematge columnar.

BiblioRed començarà només amb OLTP. Si d'aquí a uns anys la direcció vol quadres de comandament sobre una dècada d'historial, es plantejarà copiar periòdicament les dades a un magatzem analític. És una evolució normal, no un fracàs del disseny inicial.

L'objectiu d'aquest apartat és purament visual: que vegis la diferència de forma entre els models. Encara no cal entendre la sintaxi; cadascuna s'explica al seu mòdul.

Les dades del préstec estan repartides en taules i es recomponen en consultar:

El que és rellevant per a aquesta lliçó: la dada del soci viu a socis, la del llibre a llibres, i la consulta les ajunta sota demanda. Cada fet està escrit una sola vegada. La sintaxi completa de SELECT i JOIN arriba a les lliçons 02-03 i 02-04.

La mateixa informació, però autocontinguda en un document:

Diferències de forma que ja pots apreciar:

• No hi ha taules ni columnes: hi ha camps, i poden imbricar-se (llibre.titol).
• etiquetes és una llista dins del mateix document. En el model relacional això exigiria una taula a part.
• Un altre document de la mateixa col·lecció podria tenir camps diferents (per exemple, un amb spoiler: true) sense que ningú es queixi. Això és l'esquema flexible.
• El preu d'aquesta comoditat és que el títol del llibre es repeteix a cada ressenya. Quan compensa pagar-lo és justament el que s'estudia a la lliçó 03-03.

Aquí no hi ha consultes: hi ha accés directe per clau. No es pot preguntar "dóna'm totes les sessions de la sucursal nord" sense recórrer-ho tot, perquè el sistema no sap què hi ha dins del valor. A canvi, cada operació triga microsegons.

El que és característic: les fletxes són part de la consulta. -[:VA_LLEGIR]-> és una relació explícita emmagatzemada, no una unió calculada. Preguntes del tipus "qui es connecta amb qui a través de què" s'expressen de manera directa; en SQL exigirien diversos JOIN encadenats i es compliquen molt quan la profunditat és variable.

Aquesta és la part que de debò importa en un projecte. Els criteris, en ordre de pes pràctic:

1. Quina forma tenen les dades? Estructura estable i ben coneguda, o variable d'un registre a un altre? Plana o profundament imbricada?
2. Quines preguntes faràs? Aquest criteri decideix més que l'anterior. Si les consultes creuen cinc entitats i agreguen, vols relacional. Si sempre llegeixes un objecte sencer pel seu identificador, un documental o un clau-valor ja fan el fet.
3. Quant importa la integritat? Si una dada incorrecta té conseqüències legals o econòmiques, vols un sistema que les impedeixi per construcció.
4. Quin volum i quin creixement? Milions de files no són cap problema per a PostgreSQL. Centenars de terabytes distribuïts geogràficament sí que exigeixen una altra cosa.
5. Canviarà l'esquema sovint? Un esquema que canvia cada setmana pateix en un model rígid.
6. Què sap l'equip i què pot operar? Un sistema distribuït mal administrat és pitjor que un de senzill ben administrat. És un criteri infravalorat i decisiu.

I dues regles pràctiques que estalvien molts disgustos:

• Per defecte, relacional. És l'opció amb més eines, més documentació, més gent que la coneix i més garanties. Cal justificar apartar-se'n, no al revés.
• No és una decisió única. Un sistema pot fer servir PostgreSQL per al transaccional, Redis per a la memòria cau i MongoDB per als continguts. S'anomena persistència poliglota i és el tema de la lliçó 08-03.

Aquest diagrama és una simplificació deliberada: serveix com a primera aproximació, no com a veredicte.

Apliquem els criteris al nostre cas, part per part.

Socis, llibres, exemplars, autors, préstecs, reserves i sucursals formen un domini clàssicament relacional:

• L'estructura és estable: un soci té sempre les mateixes dades; un préstec, també.
• Les relacions són el cor del sistema: un préstec no té sentit sense un soci i un exemplar.
• La integritat és crítica: no pot existir un préstec d'un exemplar inexistent, ni el mateix exemplar prestat dues vegades alhora.
• Cal concurrència amb transaccions: quatre taulells prestant alhora del mateix fons.
• El volum és modest: 12.000 socis i uns centenars de milers de préstecs a l'any són xifres que PostgreSQL gestiona sense despentinar-se.

Decisió: PostgreSQL per a tot el nucli, i SQLite com a entorn equivalent per practicar. És el que construirem als mòduls 2, 4 i 5.

Les ressenyes que els lectors deixen sobre els llibres, i la fitxa enriquida del catàleg (sinopsi, portades, premis, etiquetes lliures, enllaços externs), tenen un altre perfil:

• Estructura variable: unes ressenyes tenen puntuació, altres només text; unes fitxes tenen premis, altres no.
• Es llegeixen senceres i de cop, per pintar una pàgina; no es creuen amb cinc taules.
• La integritat és menys crítica: una ressenya amb un camp estrany no trenca res.
• Encaixen de manera natural amb llistes imbricades (etiquetes, edicions, enllaços).

Decisió: MongoDB per a ressenyes, catàleg enriquit i registre d'activitat. És el que treballarem al mòdul 3 i al cas d'estudi 08-02.

Cap d'aquestes peces no s'implementarà al curs, però convé que en vegis el mapa complet: un sistema real acaba combinant diverses tecnologies, cadascuna allà on aporta.

• Triar NoSQL perquè "és modern". NoSQL no és una versió millorada del relacional; és un conjunt de compromisos diferents. Si les teves dades són estructurades i relacionals, fer servir un documental t'obligarà a reimplementar a mà la integritat que el RDBMS et regalava.
• Creure que NoSQL vol dir "sense esquema". Vol dir que l'esquema no l'imposa la base de dades; continua existint, però ara viu al codi de la teva aplicació, dispers i sense validar. És més llibertat i més responsabilitat.
• Triar pel volum que imagines tenir, no pel que tindràs. La majoria de projectes que adopten sistemes distribuïts "per si creixem" mai no assoleixen el volum que els justificava, i paguen la complexitat des del primer dia. PostgreSQL aguanta moltíssim més del que la gent suposa.
• Confondre el model amb el producte. PostgreSQL és relacional, però emmagatzema JSON (jsonb), vectors (pgvector) i sèries temporals (TimescaleDB). Les fronteres entre famílies són cada cop més poroses; sovint la resposta correcta és "amplia el teu relacional" en comptes d'"afegeix un altre sistema".
• Ignorar el cost operatiu. Cada tecnologia nova significa monitoratge, còpies de seguretat, actualitzacions i algú que sàpiga arreglar-la a les tres de la matinada. Afegir un sistema ha de compensar aquest cost amb claredat.
• Consell: quan dubtis entre dues opcions, escriu les cinc consultes més freqüents que farà la teva aplicació i comprova quina les expressa de manera més natural. El model de dades es tria per les preguntes, no per la manera d'emmagatzemar.

Per a cada necessitat de BiblioRed, indica quina família de bases de dades és la més adequada i justifica-ho en una o dues frases:

1. Registrar que la sòcia 14 s'emporta l'exemplar 3081 el 18/04/2026 i garantir que aquest exemplar no es pot prestar simultàniament en una altra sucursal.
2. Guardar el "carret de reserva" temporal d'un usuari al web, que caduca als 20 minuts si no el confirma.
3. Emmagatzemar fitxes de catàleg on uns llibres tenen premis i adaptacions cinematogràfiques i altres només títol i sinopsi.
4. Respondre a "quins socis estan connectats amb la Marta a través de dos o menys llibres compartits?".
5. Guardar cada esdeveniment de temperatura i humitat dels quatre sensors de la sala de fons antic, un per minut, durant anys.
6. Produir un informe anual amb préstecs per sucursal, gènere i franja d'edat dels últims vuit anys.

Se't dóna aquesta informació sobre un exemplar de BiblioRed:

L'exemplar amb codi EJ-3081 correspon al llibre "El mapa del temps" (ISBN 9788401339097), és a la sucursal Nord, en estat "bo", i es va adquirir el 12/01/2024.

1. Representa'l com a files de taules relacionals (dibuixa les taules implicades i les seves columnes, amb dades).
2. Representa'l com un únic document JSON.
3. Explica quin avantatge i quin inconvenient té cada representació si BiblioRed tingués 40.000 exemplars.

Una responsable de BiblioRed ha llegit que "les bases de dades relacionals no escalen" i proposa fer tot el sistema en MongoDB, inclosos socis i préstecs. Redacta una resposta breu (5-8 línies) que: (a) reconegui en què té part de raó, (b) expliqui per què el nucli ha de ser relacional en aquest cas concret i (c) proposi on sí que encaixa MongoDB a BiblioRed.

Solució 1

Solució 2

(1) Representació relacional — tres taules:

(2) Representació documental:

(3) Comparació amb 40.000 exemplars:

• Relacional: el títol i l'ISBN s'escriuen una sola vegada per obra, encara que hi hagi sis còpies. Corregir una errada al títol és una única actualització. A canvi, mostrar la fitxa d'un exemplar exigeix unir tres taules.
• Documental: llegir la fitxa completa és una sola operació, molt ràpida. A canvi, el títol es repeteix als 40.000 documents: corregir l'errada implica actualitzar tots els exemplars d'aquesta obra, i si el procés falla a mitges queden documents amb el títol vell i altres amb el nou.

Aquesta tensió entre duplicar per llegir ràpid i normalitzar per mantenir coherència és una de les decisions centrals del disseny de dades. S'estudia a fons a les lliçons 03-03 i 05-04.

Solució 3

Resposta model:

Tens raó que l'escalat horitzontal és més senzill en sistemes com MongoDB, dissenyats des del principi per repartir-se entre molts nodes, i que un esquema flexible accelera el desenvolupament quan les dades canvien de forma sovint. Ara bé, aquest problema no és el nostre: 12.000 socis i uns centenars de milers de préstecs anuals són molt lluny del límit d'un únic servidor PostgreSQL. El que sí que és el nostre problema —ho vam veure al full de càlcul actual— és la integritat: necessitem que sigui impossible prestar dues vegades el mateix exemplar o registrar un préstec d'un soci inexistent. Un RDBMS ho garanteix per construcció amb claus foranes i transaccions; a MongoDB ho hauríem de programar a mà a cada punt de l'aplicació, i n'hi hauria prou d'oblidar-ho una vegada per reintroduir el caos que volem eliminar. La meva proposta és fer servir PostgreSQL per al nucli (socis, exemplars, préstecs, reserves) i MongoDB on de debò aporta: ressenyes de lectors, catàleg enriquit i registre d'activitat, que són dades d'estructura variable i amb exigències d'integritat molt menors.

En aquesta lliçó hem aixecat el mapa complet del territori:

• Les bases de dades es classifiquen per model de dades, càrrega de treball, arquitectura de desplegament i ubicació de la dada, eixos independents que es combinen.
• Les relacionals continuen sent l'opció per defecte: estructura estable, relacions explícites, integritat garantida i SQL.
• NoSQL agrupa quatre famílies diferents —documentals, clau-valor, columnars i de grafs— que canvien garanties o rigidesa per flexibilitat i capacitat de distribució.
• Existeixen, a més, models històrics (jeràrquic i en xarxa), especialitzats (objectes, incrustades, en memòria, sèries temporals, vectorials) i la distinció de càrrega OLTP davant d'OLAP.
• La tria es fa per les preguntes que faràs, no per la moda: forma de la dada, consultes previstes, exigència d'integritat, volum real, estabilitat de l'esquema i capacitat de l'equip.
• Per a BiblioRed hem decidit amb arguments: PostgreSQL (i SQLite per practicar) al nucli transaccional, i MongoDB per a ressenyes, catàleg enriquit i activitat.

Hem vist què hi ha disponible avui. Falta entendre per què el panorama té aquesta forma: per què el model relacional va desplaçar els que hi havia abans, per què SQL es va convertir en un estàndard universal i quines pressions concretes van fer aparèixer NoSQL quaranta anys després. Això és la lliçó 01-03, Història i Evolució de les Bases de Dades, i no és una lliçó de dates: entendre quin problema va resoldre cada generació és la millor manera de saber quan convé cadascuna.