A la primera lliçó vam definir el SGBD des de fora: el programari que s'interposa entre les aplicacions i els fitxers del disc. Ha arribat el moment d'obrir la caixa. Entendre què hi ha dins d'un gestor de bases de dades no és un luxe teòric: és el que et permetrà, més endavant, comprendre per què una consulta triga deu mil·lisegons i una altra gairebé idèntica en triga trenta segons, per què existeixen els índexs, què garanteix realment una transacció i què està passant quan alguna cosa es bloqueja.

La lliçó té dues parts. La primera és conceptual: els components interns d'un SGBD, el viatge complet d'una consulta, l'arquitectura de tres nivells que fa possible la independència de dades, la diferència entre client-servidor i incrustat, i els rols humans que treballen al voltant d'una base de dades. La segona és pràctica: en acabar-la tindràs PostgreSQL i SQLite instal·lats, sabràs connectar-te a tots dos i hauràs creat la base de dades biblioredb, on s'executarà tot el SQL de la resta del curs. No deixis aquesta lliçó a mitges: el mòdul 2 comença escrivint SQL, i necessitaràs l'entorn a punt.

1. Els components interns d'un SGBD
2. El viatge d'una consulta, pas a pas
3. L'arquitectura ANSI/SPARC de tres nivells
4. Independència de dades lògica i física
5. Client-servidor davant de base de dades incrustada
6. Rols humans al voltant d'una base de dades
7. Instal·lació de PostgreSQL
8. Primers passos amb psql i creació de biblioredb
9. Instal·lació i primers passos amb SQLite
10. Alternatives: Docker i consoles en línia
11. Errors habituals i consells
12. Exercicis
13. Conclusió

Un SGBD modern és un sistema complex, però s'organitza en un conjunt de components força estable, comuns a PostgreSQL, MySQL, Oracle o SQL Server (SQLite també els té tots, encara que en versió reduïda).

És la porta d'entrada. Rep la connexió del client, autentica l'usuari (contrasenya, certificat, sistema operatiu) i li assigna una sessió. A partir d'aquí, cada operació passa pel control d'autorització: comprovar que aquest usuari té permís sobre aquesta taula i aquesta operació.

A BiblioRed, aquest component és el que farà que l'usuari del taulell pugui inserir préstecs però no esborrar socis. Els permisos en detall es veuen a la lliçó 06-04.

El cervell del sistema. Rep una consulta en SQL —un text que diu què es vol— i produeix un pla d'execució que diu com obtenir-ho. Les seves fases:

• Anàlisi sintàctica (parser): comprova que el SQL està ben escrit i el converteix en un arbre.
• Anàlisi semàntica: verifica contra el catàleg que les taules i columnes existeixen i que els tipus encaixen.
• Reescriptura: aplica transformacions equivalents (expandir vistes, simplificar condicions).
• Optimització: genera diversos plans possibles, estima el cost de cadascun fent servir estadístiques sobre les dades i tria el més barat.
• Execució: recorre el pla escollit i produeix les files.

Aquesta peça és l'herència directa de System R (lliçó 01-03) i és la que fa que SQL pugui ser declaratiu.

És qui sap com són realment les dades al disc: en quins fitxers, organitzades en pàgines o blocs (habitualment de 4 o 8 KB), amb quin format de fila, i quins índexs existeixen per arribar abans a una fila concreta. Ofereix a la resta del sistema operacions elementals: "dóna'm la fila X", "recorre aquesta taula", "cerca en aquest índex".

Llegir de disc és ordres de magnitud més lent que llegir de memòria. El gestor de memòries intermèdies manté a la RAM les pàgines més utilitzades i decideix quines expulsar quan falta espai. És responsable que la segona vegada que consultes alguna cosa sigui molt més ràpida que la primera.

A PostgreSQL aquest espai s'anomena shared buffers; a la pràctica, un servidor ben dimensionat serveix la immensa majoria de les lectures des de memòria.

Garanteix que un conjunt d'operacions s'apliqui sencer o gens, fins i tot si es talla la llum a mitges. Es recolza en dos mecanismes:

• El registre d'escriptura anticipada (write-ahead log, WAL): abans de modificar les dades, s'escriu en un registre seqüencial el que es farà. Si el sistema cau, en arrencar es rellegeix aquest registre i es reconstrueix l'estat coherent.
• El control de concurrència: bloqueigs o versionat (PostgreSQL fa servir MVCC, Multi-Version Concurrency Control) perquè moltes sessions simultànies no es corrompin entre si.

És el que impedeix que dos taulells de BiblioRed prestin el mateix exemplar alhora. Les transaccions i els nivells d'aïllament són el contingut de les lliçons 06-01 i 06-02.

La base de dades sobre la mateixa base de dades: quines taules existeixen, amb quines columnes, tipus, restriccions, índexs, vistes, usuaris i permisos. I també estadístiques sobre les dades (quantes files té cada taula, com es distribueixen els valors), que l'optimitzador fa servir per decidir.

L'interessant és que en un sistema relacional el catàleg són taules normals, consultables amb SQL com qualsevol altra. A PostgreSQL viu a l'esquema information_schema i a les taules pg_catalog.

Al voltant del nucli hi ha eines de càrrega massiva, còpia de seguretat i restauració, replicació i monitoratge. Solen ser programes independents (pg_dump, pg_restore, psql).

Vegem el recorregut complet amb una consulta concreta de BiblioRed. Encara no cal entendre la sintaxi —això és el mòdul 2—; el que importa és el camí.

En llenguatge planer: "digues-me quins préstecs continuen oberts a la sucursal Nord, amb el nom del soci i el títol del llibre".

Recorrem les decisions interessants:

1. Connexió i autenticació. El client obre una sessió. A PostgreSQL, el procés principal llança un procés dedicat per atendre-la.

2. Parser. Si vas escriure SELCT en comptes de SELECT, aquí s'atura amb un error de sintaxi. Encara no s'ha mirat cap dada.

3. Anàlisi semàntica. Es consulta el catàleg: existeix la taula prestecs? té columna data_devolucio? e.sucursal_id és comparable amb el número 2? Els errors de "columna inexistent" neixen aquí.

4. Reescriptura. Si prestecs fos una vista, se substituiria per la seva definició.

5. Optimització. Aquí hi ha el més substanciós. El sistema ha de decidir, entre moltes opcions:

   • En quin ordre unir les quatre taules? Unir primer prestecs amb exemplars filtrant per sucursal pot deixar 300 files; començar per llibres en deixaria 40.000. L'ordre canvia el temps d'execució en ordres de magnitud.
   • Recórrer la taula sencera (sequential scan) o fer servir un índex? Si només hi ha 300 préstecs oberts entre un milió de files històriques, un índex guanya; si cal llegir el 80 % de la taula, recórrer-la sencera és més ràpid.
   • Quin algorisme d'unió? Bucle imbricat, unió per barreja o unió per dispersió (hash join), segons les mides.

   Aquestes decisions es prenen amb les estadístiques del catàleg. Per això una base de dades amb estadístiques desactualitzades tria malament. A la lliçó 06-03 aprendràs a llegir el pla escollit amb EXPLAIN.

6. Execució. L'executor recorre el pla demanant pàgines. Cada petició passa pel gestor de memòries intermèdies: si la pàgina és a la memòria, se serveix a l'instant; si no, es llegeix de disc i es desa a la memòria cau.

7. Visibilitat transaccional. Cada fila candidata es comprova contra el gestor de transaccions: sota MVCC, una fila modificada per una transacció encara no confirmada no és visible per a aquesta sessió. Així es llegeix sense bloquejar qui escriu.

8. Permisos i resultat. Es verifica que l'usuari pot llegir aquestes taules i les files viatgen de tornada al client.

La idea que t'ha de quedar: tu escrius el què; el SGBD decideix el com, i aquesta decisió és on es juga el rendiment. És exactament la independència que va proposar Codd, funcionant.

El 1975, el comitè ANSI/X3/SPARC va proposar un marc per organitzar qualsevol SGBD en tres nivells d'abstracció. Continua sent la referència conceptual amb què s'expliquen les bases de dades, perquè descriu per què es pot canviar una capa sense trencar les altres.

El que cada tipus d'usuari veu. No n'hi ha un de sol: n'hi ha tants com perfils d'ús. Cada vista externa mostra un subconjunt de les dades, potser reorganitzat o calculat, i amaga la resta.

A BiblioRed:

• El taulell veu els préstecs i els socis de la seva sucursal, amb les dades de contacte necessàries per reclamar una devolució.
• El catàleg públic del web veu títol, autor, portada i disponibilitat. No veu qui té prestat cada exemplar: seria una bretxa de privacitat.
• La direcció veu totals agregats per sucursal i mes, sense noms de socis.

Els tres perfils estan mirant les mateixes dades, presentades de manera diferent.

La descripció completa i única de quines dades conté la base de dades: totes les entitats, tots els atributs, totes les relacions i totes les restriccions d'integritat. És independent de qui les faci servir i de com es guardin.

És el nivell on treballa el dissenyador, i el que produirem al mòdul 4 amb els diagrames entitat-relació i la seva transformació a esquema relacional.

Com s'emmagatzema realment: quins fitxers hi ha, com s'agrupen les files en pàgines, quins índexs existeixen i de quin tipus, què es comprimeix, a quin disc viu cada taula.

És responsabilitat de l'administrador i del mateix SGBD, i l'usuari normal no hauria de necessitar conèixer-lo per escriure consultes correctes (sí per escriure-les ràpides, i d'aquí la lliçó 06-03).

El motiu d'existir dels tres nivells són les dues independències. Són la propietat més valuosa d'un SGBD, i la que faltava per complet en els models anteriors al relacional.

Es pot canviar el nivell intern sense tocar el nivell conceptual ni les aplicacions.

Exemples a BiblioRed:

• L'administrador crea un índex sobre prestecs.data_prestec perquè els informes mensuals van lents. Cap consulta no canvia; simplement passen a executar-se més ràpid.
• Es mou la taula històrica de préstecs a un disc diferent, o es comprimeix. Les aplicacions no se n'assabenten.
• Es migra el servidor a un altre emmagatzematge. El SQL continua sent el mateix.

Aquesta independència és molt sòlida en els SGBD actuals: és pràcticament total.

Es pot canviar el nivell conceptual sense tocar les vistes externes ni les aplicacions que les fan servir.

Exemples a BiblioRed:

• Es decideix dividir la taula socis en socis i socis_contacte per separar les dades personals. Si les aplicacions consulten una vista anomenada socis que reuneix totes dues taules, continuen funcionant sense canvis.
• S'afegeix una columna idioma_preferit a socis. Cap aplicació existent no es veu afectada, perquè cap no la demanava.
• S'afegeix l'entitat reserves, nova al sistema. Les aplicacions de préstecs ni se n'assabenten.

Aquesta independència és més difícil d'assolir que la física, i només s'aconsegueix si s'ha tingut la disciplina que les aplicacions accedeixin a través de vistes en comptes de directament a les taules. És una decisió de disseny, no un regal del sistema.

Els dos gestors del curs representen els dos extrems de l'arquitectura de desplegament, i comparar-los aclareix molt.

El SGBD és un procés independent —sovint en una altra màquina— que escolta en un port de xarxa (5432 a PostgreSQL). Els clients es connecten per xarxa, envien SQL i reben resultats.

Implica:

• Accés concurrent real des de moltes màquines, gestionat pel servidor.
• Control d'accés centralitzat: usuaris, rols i permisos.
• Administració: cal instal·lar-lo, arrencar-lo, configurar-lo, actualitzar-lo i fer-ne còpies (o pagar algú que ho faci, com vam veure amb els serveis gestionats a la lliçó 01-03).
• Latència de xarxa a cada operació, normalment menyspreable però no nul·la.

No hi ha servidor. El motor és una biblioteca enllaçada dins del mateix programa, i la base de dades sencera és un fitxer al disc local. Quan la teva aplicació consulta, no parla per xarxa: crida una funció.

Implica:

• Zero administració: no hi ha servei, ni port, ni usuaris. Copiar la base de dades és copiar un fitxer.
• Latència mínima: no hi ha xarxa ni serialització entre processos.
• Concurrència limitada: molts lectors simultanis sí, però un sol escriptor alhora sobre el fitxer.
• Sense control d'accés propi: la seguretat és la del sistema de fitxers. Qui pot llegir el fitxer, ho llegeix tot.

Cap no és millor que l'altra: resolen problemes diferents. SQLite és, de bon tros, el motor de base de dades més desplegat del món (és a cada telèfon, cada navegador i cada avió), i no competeix amb PostgreSQL: competeix amb fopen().

Per a BiblioRed en producció l'elecció és PostgreSQL, perquè hi ha quatre sucursals escrivint alhora i dades personals per protegir. Per aprendre, SQLite és perfecte i per això el tindrem com a alternativa durant tot el curs.

En una organització petita una sola persona fa els tres papers; en una de gran són equips diferents. Convé saber què s'espera de cadascun.

Responsable que el sistema funcioni, sigui segur i no perdi dades:

• Instal·lar, configurar i actualitzar el SGBD.
• Definir usuaris, rols i permisos.
• Planificar i provar les còpies de seguretat i la restauració (una còpia no verificada no és una còpia).
• Monitorar el rendiment, ajustar la configuració i crear índexs.
• Planificar capacitat, replicació i recuperació davant de desastres.

A BiblioRed seria qui garanteix que el servidor de la sucursal central tingui còpia cada nit i que el personal només vegi el que li pertoca.

Responsable que l'esquema i les consultes siguin correctes i eficients:

• Dissenyar taules, relacions i restriccions (mòduls 4 i 5).
• Escriure i optimitzar consultes SQL.
• Gestionar les migracions d'esquema amb control de versions.
• Integrar la base de dades amb l'aplicació.

És el rol per al qual aquest curs prepara de manera més directa.

Responsable d'extreure informació de les dades existents:

• Escriure consultes d'anàlisi i agregació (lliçó 02-05).
• Construir informes i quadres de comandament.
• Detectar problemes de qualitat de dades.

A BiblioRed, qui respon a "quins gèneres convé reforçar a la sucursal Sud?".

Un quart rol, l'arquitecte de dades, decideix en sistemes grans quines tecnologies es fan servir i com s'integren; és qui prendria les decisions de la lliçó 01-02.

A partir d'aquí, mans a l'obra. Tria el teu sistema operatiu.

postgresql instal·la el servidor; postgresql-contrib afegeix extensions útils. A Debian i Ubuntu el servei arrenca sol després de la instal·lació.

L'alternativa gràfica és Postgres.app, que es descarrega, s'arrossega a Aplicacions i arrenca amb un clic. És l'opció més còmoda si prefereixes no fer servir Homebrew.

1. Descarrega l'instal·lador d'EDB des de postgresql.org/download/windows.
2. Executa'l i accepta les opcions per defecte, anotant la contrasenya que defineixis per a l'usuari postgres: la necessitaràs per connectar-te.
3. Deixa marcat pgAdmin si vols una interfície gràfica, i Command Line Tools (imprescindible, inclou psql).

Després, des del menú d'inici, obre SQL Shell (psql) i prem Enter a cada pregunta fins a la contrasenya.

En qualsevol sistema, verifica que el client respon:

Si l'ordre no es troba a macOS amb Homebrew, afegeix el directori al PATH:

psql és el client de línia d'ordres de PostgreSQL. És l'eina que farem servir durant tot el curs: és la més directa i la que està disponible a qualsevol servidor.

A Linux, la instal·lació crea un usuari del sistema anomenat postgres que és el superusuari de la base de dades:

A macOS amb Homebrew, el teu propi usuari sol ser superusuari:

A Windows, fes servir l'accés directe SQL Shell (psql).

Veuràs un avís com aquest:

El prompt postgres=# indica: base de dades actual postgres, i # significa superusuari (un > indicaria usuari normal).

Fixa't en dues coses: la instrucció acaba en punt i coma (sense ell, psql esperarà més text), i el resultat es presenta com una taula amb el nombre de files al final.

Treballar sempre com a superusuari és mala pràctica. Crea un usuari amb el teu nom:

CREATEDB li permet crear bases de dades, que és el que necessitem.

Aquesta resposta escarida és la confirmació que ha funcionat. biblioredb és la base de dades on executarem tot el SQL del curs: les taules de socis, llibres, exemplars i préstecs que dissenyarem a partir del mòdul 2 viuran aquí.

Les ordres que comencen per barra invertida no són SQL: són instruccions per al client psql i no porten punt i coma.

Provem-les:

Aquí està biblioredb. Les bases template0 i template1 són plantilles internes del sistema: no les toquis.

El prompt ha canviat a biblioredb=#: ja som a dins. I \dt diu que no hi ha taules, cosa que és correcta: la base de dades és buida i l'omplirem al mòdul 2.

Per a les properes sessions, estalvia passos connectant-te d'un sol cop:

• -U alumne: usuari.
• -d biblioredb: base de dades.
• -h localhost: servidor (necessari perquè demani contrasenya en comptes de fer servir l'autenticació del sistema).

També pots executar una consulta sense entrar a la sessió interactiva:

SQLite és el pla B (i de vegades el pla A) per practicar: no hi ha servidor que arrencar.

A Windows, descarrega el paquet sqlite-tools des de sqlite.org/download.html, descomprimeix-lo en una carpeta (per exemple C:\sqlite) i afegeix aquesta carpeta al PATH, o simplement executa sqlite3.exe des d'allà.

A SQLite, crear una base de dades és crear un fitxer. No hi ha CREATE DATABASE:

Un detall important: el fitxer no es crea al disc fins que hi escriguis alguna cosa a dins. Si surts sense crear cap taula, no hi haurà fitxer.

Aquí les ordres del client comencen per punt, no per barra invertida:

Els dos primers que hauries d'executar sempre en obrir sqlite3, perquè la sortida per defecte és molt austera:

Buit, com esperàvem.

Perquè .headers on i .mode box s'apliquin sempre, crea un fitxer .sqliterc a la teva carpeta personal amb aquestes dues línies.

La diferència de tipus és la més rellevant per aprendre: SQLite és permissiu i deixarà passar coses que PostgreSQL rebutjaria. Si practiques a SQLite, sigues conscient que PostgreSQL serà més estricte — i aquesta estrictesa és una virtut, no un obstacle, com vam veure a la lliçó 01-01.

Si no pots o no vols instal·lar res al teu equip, hi ha dues sortides perfectament vàlides.

Aixeca un PostgreSQL exprés en un contenidor:

Què fa cada opció:

• --name pg-biblioredb: nom del contenidor, per referir-t'hi després.
• -e POSTGRES_PASSWORD=...: contrasenya de l'usuari postgres (obligatòria).
• -e POSTGRES_DB=biblioredb: crea la base de dades del curs en arrencar.
• -p 5432:5432: exposa el port a la teva màquina.
• -d: en segon pla.

Per entrar amb psql sense instal·lar-lo localment:

Gestió del contenidor:

Tingues present aquest darrer advertiment: sense un volum muntat, esborrar el contenidor esborra la base de dades.

Sense instal·lar absolutament res, serveixen per seguir el curs i fer els exercicis:

• db-fiddle.com i sqliteonline.com: permeten triar PostgreSQL o SQLite i executar SQL al navegador.
• pgexercises.com: PostgreSQL amb exercicis integrats.

La seva limitació és que no persisteixen entre sessions: guarda els teus scripts en un fitxer .sql a part. Per al mòdul 2 són suficients; per treballar amb comoditat a partir del mòdul 4, és preferible una instal·lació local o Docker.

Si prefereixes una interfície visual, pgAdmin (ve amb l'instal·lador de Windows), DBeaver (multiplataforma, serveix per a PostgreSQL, SQLite i MongoDB) o DB Browser for SQLite són bones opcions. Recomanació: aprèn primer amb psql i sqlite3. La línia d'ordres t'obliga a entendre el que passa i està disponible a qualsevol servidor al qual et connectis.

• Oblidar el punt i coma a psql. Si escrius SELECT version() i prems Enter, el prompt canvia a postgres-# i sembla que s'ha penjat. No ho està: espera que acabis la instrucció. Escriu ; i Enter.
• Confondre metaordres amb SQL. \dt no porta punt i coma i només funciona a psql; .tables només funciona a sqlite3. No formen part del llenguatge SQL i no funcionen des d'una aplicació.
• psql: FATAL: role "tu_usuario" does not exist a Linux. Passa en executar psql a seques: PostgreSQL intenta autenticar-te amb el nom del teu usuari del sistema, que no existeix com a rol. Solució: sudo -u postgres psql i crea el teu usuari, com a l'apartat 8.
• could not connect to server. El servidor no està arrencat. Comprova-ho amb sudo systemctl status postgresql (Linux) o brew services list (macOS) i arrenca'l si cal.
• Creure que SQLite crea el fitxer en obrir-lo. Només es materialitza quan hi escrius alguna cosa. Si ls no mostra biblioredb.sqlite, no és cap fallada: és que encara no has creat cap taula.
• Practicar només a SQLite i endur-se una sorpresa. SQLite accepta text en una columna INTEGER; PostgreSQL no. Si l'objectiu és treballar amb PostgreSQL, practica a PostgreSQL sempre que puguis.
• Treballar sempre com a superusuari. Funciona, però no ensenya res sobre permisos i en un entorn real és perillós. Crear un usuari alumne costa una línia.
• Consell: guarda les teves consultes en fitxers .sql des del primer dia, i executa'ls amb psql -f script.sql o amb .read script.sql a SQLite. Tenir la feina en fitxers versionables és la diferència entre practicar i construir alguna cosa.

Per a cada situació, indica quin component del SGBD intervé principalment i en quin nivell ANSI/SPARC se situa el canvi (si escau):

1. Escrius SELCT * FROM socis; i reps un error de sintaxi.
2. Escrius SELECT nom FROM socsi; i reps "la relació no existeix".
3. La mateixa consulta triga 400 ms la primera vegada i 8 ms la segona.
4. L'administrador crea un índex i un informe passa de 30 s a 0,2 s, sense canviar la consulta.
5. Es talla la llum a mitja realització d'un préstec i, en arrencar, la base de dades és coherent.
6. L'usuari del taulell executa DELETE FROM socis; i rep "permís denegat".
7. Es divideix la taula socis en dues, però les aplicacions continuen funcionant gràcies a una vista.

Fes aquestes comprovacions i anota la sortida de cadascuna:

1. Comprova la versió de psql des del terminal.
2. Connecta't a PostgreSQL i mostra la versió del servidor amb SQL.
3. Crea la base de dades biblioredb si encara no la tens, i comprova amb una metaordre que apareix al llistat.
4. Connecta't a biblioredb i comprova que no té taules.
5. Amb SQLite, crea biblioredb.sqlite, activa capçaleres i mode taula, i mostra la versió.
6. A psql, esbrina a quina base de dades i amb quin usuari estàs connectat fent servir una sola metaordre.

Per a cada escenari, decideix entre PostgreSQL (client-servidor) i SQLite (incrustada), i justifica-ho en dues frases:

1. El sistema real de BiblioRed, amb quatre sucursals registrant préstecs simultàniament.
2. Una aplicació mòbil que permet als socis consultar el seu historial sense connexió a internet.
3. Les proves automatitzades de l'aplicació de BiblioRed, que han de crear i destruir una base de dades neta a cada execució.
4. Un tauler de direcció al qual accedeixen vuit persones des d'edificis diferents.
5. Un programa d'escriptori que un bibliotecari fa servir per preparar l'inventari anual al seu portàtil.

Solució 1

Solució 2

biblioredb ha d'aparèixer al llistat.

Si els sis passos funcionen, tens l'entorn del curs a punt.

Solució 3

Amb aquesta lliçó tanquem el mòdul introductori, i ho fem amb l'entorn de treball en marxa. Hem vist:

• Els components interns d'un SGBD: gestor de connexions i control d'accés, processador i optimitzador de consultes, motor d'emmagatzematge, gestor de memòries intermèdies, gestor de transaccions i recuperació, i catàleg de dades.
• El viatge complet d'una consulta, des de l'anàlisi sintàctica fins a les files retornades, amb l'optimització basada en costos com a peça decisiva del rendiment.
• L'arquitectura ANSI/SPARC de tres nivells —extern, conceptual i intern— i les dues independències de dades: la física (canviar l'emmagatzematge sense tocar les consultes) i la lògica (canviar l'esquema sense trencar les aplicacions que fan servir vistes).
• La diferència entre client-servidor i incrustat, amb PostgreSQL i SQLite com a representants de cada extrem, i per què BiblioRed farà servir el primer en producció i el segon per practicar.
• Els rols humans: administrador, desenvolupador i analista.
• I, a la pràctica: instal·lació de PostgreSQL i SQLite a Linux, macOS i Windows, connexió amb psql i sqlite3, comprovació de versions, creació de la base de dades biblioredb i maneig de les metaordres bàsiques (\l, \c, \dt, \d, .tables, .schema), a més de les alternatives amb Docker i consoles en línia.

Ja sabem què és una base de dades i quins problemes resol, quines famílies existeixen i com triar entre elles, d'on ve tot això, què passa dins del gestor i com s'organitza. I, sobretot, tenim biblioredb esperant, buida. Al mòdul 2, Bases de Dades Relacionals, comencem a omplir-la: la lliçó 02-01, Model Relacional, formalitza què és exactament una relació, què són les claus primàries i foranes i quines regles d'integritat regeixen el model; a partir d'aquí, la lliçó 02-02 introdueix SQL i escriurem les primeres instruccions reals sobre les taules de socis, llibres, exemplars i préstecs de BiblioRed. La teoria s'acaba aquí; a partir de la propera lliçó, es tecleja.