Tota organització que funciona durant prou temps acaba acumulant dades: clients, productes, moviments, incidències. Al principi aquestes dades caben en un full de càlcul i tot sembla anar bé. El problema apareix més tard, quan el full creix, l'utilitzen diverses persones alhora i ja ningú no sap quina de les tres versions del fitxer és la bona. En aquesta lliçó entendrem per què existeixen les bases de dades: quins problemes concrets resolen, quin vocabulari es fa servir per parlar-ne i quin paper té el programari que les gestiona. Encara no escriurem ni una línia de SQL; el que busquem és que, quan hi arribem, sàpigues exactament què estàs resolent i per què.

Perquè res no quedi en abstracte, tot el curs gira al voltant d'un cas únic: BiblioRed, la xarxa de biblioteques municipals d'una ciutat fictícia. El coneixeràs en aquesta mateixa lliçó i l'anirem construint mòdul a mòdul fins a tenir un sistema d'informació complet.

1. L'escenari: BiblioRed i els seus fulls de càlcul
2. Dada i informació: no són el mateix
3. Què és una base de dades
4. Què és un SGBD (definició funcional)
5. Vocabulari essencial: entitat, atribut, taula, fila, columna, clau
6. Esquema i instància
7. Els sis problemes que resol una base de dades
8. Diagnòstic del full de càlcul de BiblioRed
9. Errors habituals i consells
10. Exercicis
11. Conclusió

BiblioRed és la xarxa de biblioteques municipals d'una ciutat fictícia. Té quatre sucursals, uns 12.000 socis registrats i un fons d'uns 40.000 exemplars. Avui funciona així:

• Cada sucursal manté el seu propi full de càlcul de préstecs, en una carpeta compartida.
• El catàleg de llibres és en un altre full diferent, que manté una persona de la sucursal central.
• Les altes de socis s'apunten en un tercer fitxer, i en algunes sucursals encara en paper.
• Quan algú vol saber si un llibre està disponible, truca per telèfon a l'altra sucursal.

El sistema "funciona" en el sentit que la biblioteca obre cada dia. Però produeix errors constants: préstecs duplicats, socis amb dues fitxes, llibres que consten com a disponibles i no ho estan. La direcció ha decidit migrar a una base de dades de debò, i nosaltres som l'equip que la dissenyarà.

En aquesta lliçó ens limitem a entendre el problema. El disseny comença al mòdul 4.

És la distinció fundacional de tota la disciplina, i convé tenir-la clara des del principi.

• Una dada és un fet en brut, sense context: 2026-03-14, 9788420412146, 14.
• La informació és el resultat d'interpretar dades en un context: "el 14 de març de 2026, la sòcia número 14 va agafar en préstec el llibre amb ISBN 9788420412146".
• El coneixement apareix quan la informació s'agrega i permet decidir: "els préstecs de narrativa pugen un 20 % al març, convé reforçar el fons".

Una base de dades emmagatzema dades, però està dissenyada perquè sigui barat i fiable convertir-les en informació. Aquesta és la seva raó de ser: no guardar, sinó permetre preguntar.

Una base de dades és una col·lecció de dades relacionades entre si, organitzada segons una estructura definida, emmagatzemada de manera persistent i gestionada de manera que diversos usuaris i aplicacions puguin consultar-la i modificar-la de forma controlada.

Val la pena desgranar la definició, perquè cada paraula en descarta alguna cosa:

• Col·lecció de dades relacionades: no és una pila de fitxers solts. Els préstecs apunten a socis, els socis a sucursals, els exemplars a llibres. Les relacions formen part de la base de dades tant com les dades.
• Estructura definida: abans de guardar res es decideix quina forma tenen les dades. Aquesta decisió s'anomena esquema i la veurem a l'apartat 6.
• Persistent: sobreviu al tancament del programa, al reinici del servidor i, si està ben administrada, a una fallada del disc.
• Accés controlat i compartit: diverses persones poden treballar alhora sense trepitjar-se, i cadascuna veu només allò que li pertoca.

Un full de càlcul compleix això de "persistent" i poca cosa més. Per això funciona fins a una certa mida i després deixa de funcionar.

La base de dades són les dades. El SGBD (Sistema Gestor de Bases de Dades, en anglès DBMS) és el programari que les gestiona. És la peça que s'interposa entre les aplicacions i els fitxers del disc perquè ningú no hagi de tocar aquests fitxers directament.

Funcionalment, un SGBD ofereix:

• Definició de dades: permet declarar quines estructures existeixen (taules, columnes, tipus, restriccions).
• Manipulació de dades: inserir, consultar, modificar i esborrar.
• Control d'accés: qui pot fer què.
• Control de concurrència: coordinar molts usuaris simultanis sense corrompre res.
• Recuperació davant de fallades: si marxa la llum a mitja operació, deixar les dades en un estat coherent.
• Optimització: decidir com executar una consulta de la manera més ràpida possible.

Fixa't en la idea clau del diagrama: cap aplicació no toca el disc. Totes parlen amb el SGBD, i el SGBD és l'únic que sap com estan guardades realment les dades. Això és el que permet canviar l'emmagatzematge sense trencar les aplicacions.

Exemples de SGBD que farem servir al curs: PostgreSQL (servidor complet, serà la nostra referència), SQLite (motor incrustat, per practicar sense instal·lar res pesat) i MongoDB (documental, al mòdul 3).

Allò que hi ha dins d'un SGBD —optimitzador, motor d'emmagatzematge, gestor de memòries intermèdies, catàleg— i com s'organitza la seva arquitectura ho veurem en detall a la lliçó 01-04. Aquí en tenim prou de saber què fa vist des de fora.

Aquest és el vocabulari mínim per poder parlar de la resta del curs. El presentem amb l'exemple de BiblioRed.

Visualment, la taula socis de BiblioRed podria tenir aquest aspecte:

Dues precisions que solen confondre qui comença:

• Entitat és un concepte de disseny; taula és la seva materialització. Es dissenya pensant en entitats i s'implementa en taules. Quan arribem als diagrames entitat-relació (lliçó 04-02) aquesta distinció serà central.
• Fila i registre es fan servir gairebé com a sinònims, igual que columna i camp. "Fila" i "columna" són els termes del model relacional; "registre" i "camp" venen del món dels fitxers. Trobaràs tots dos a la literatura.

Una clau és simplement un atribut (o combinació) que serveix per identificar. És un concepte tan important que li dedicarem part del mòdul 2: sense claus no hi ha manera de relacionar taules, i sense relacions no hi ha model relacional.

Una altra distinció que cal interioritzar aviat:

• L'esquema és la definició de l'estructura: quines taules existeixen, quines columnes té cadascuna, de quin tipus són, quines restriccions compleixen. Canvia poc, i quan canvia és un esdeveniment (una "migració").
• La instància (o estat) és el contingut en un moment donat: les files concretes que hi ha ara mateix. Canvia constantment, cada vegada que algú presta un llibre.

L'analogia habitual: l'esquema és com la definició d'un formulari en blanc; la instància són tots els formularis emplenats que hi ha avui a l'arxivador.

Aquesta separació és el que fa possible raonar sobre una base de dades sense mirar-ne les dades: si coneixes l'esquema, saps quines preguntes es poden respondre. Al mòdul 4 aprendràs a dissenyar esquemes i al mòdul 5 a millorar-los mitjançant normalització.

Aquí hi ha el nucli de la lliçó. Una base de dades no és "un full de càlcul més gran": resol sis problemes que un full no pot resoldre.

El problema: la mateixa dada guardada en diversos llocs. A BiblioRed, el nom del soci apareix a cada fila de préstec, al full d'altes i a la llista de morosos.

Què provoca: ocupa espai (això és el de menys) i, sobretot, obliga a actualitzar en N llocs. Si el soci canvia de correu, cal recordar-los tots.

Com es resol: guardant cada dada una sola vegada a la seva taula i referenciant-la des d'on calgui. És el principi que formalitza la normalització (mòdul 5).

El problema: conseqüència directa de l'anterior. Si la dada és en cinc llocs i només n'actualitzes quatre, ara tens dues veritats contradictòries i cap manera de saber quina val.

Com es resol: eliminant la redundància i afegint restriccions d'integritat que el SGBD fa complir sempre, sense dependre de la disciplina de ningú.

El problema: res no impedeix escriure barbaritats. Una data de devolució anterior a la de préstec. Un préstec associat a un soci que no existeix. Un DNI repetit.

Com es resol: el SGBD permet declarar regles —tipus de dades, NOT NULL, unicitat, claus foranes, comprovacions— i rebutja qualsevol operació que les violi. La diferència amb un full de càlcul és que la regla viu a les dades, no a la bona voluntat de qui tecleja. Ho veurem a la lliçó 02-06 i a la 04-04.

El problema: dos bibliotecaris obren el full alhora, cadascun anota el seu préstec i el segon a desar sobreviu; el primer préstec desapareix. O pitjor: l'últim exemplar d'un llibre es presta dues vegades perquè tots dos van llegir "disponible: 1".

Com es resol: el SGBD gestiona transaccions i bloqueigs, de manera que les operacions simultànies produeixen el mateix resultat que si s'haguessin fet una darrere l'altra. És el tema del mòdul 6 (lliçons 06-01 i 06-02).

El problema: qui té accés al fitxer ho veu tot. El becari que registra préstecs veu també les dades personals de 12.000 socis i podria esborrar-les per accident.

Com es resol: usuaris, rols i permisos per taula i per operació. El taulell pot inserir préstecs però no esborrar socis; direcció pot llegir estadístiques però no modificar el catàleg. Es tracta a la lliçó 06-04.

El problema: al full de càlcul, la manera de guardar i la manera d'usar són la mateixa cosa. Si reorganitzes les columnes, es trenquen totes les fórmules i tots els informes. I si el fitxer es corromp, l'única còpia és la que algú va recordar de fer.

Com es resol: el SGBD separa com es guarden les dades de com es consulten. Pots afegir un índex, canviar l'emmagatzematge o moure la taula de disc sense tocar ni una sola consulta. Això s'anomena independència de dades i ho formalitzarem a la lliçó 01-04. La persistència fiable, per la seva banda, es recolza en registres de transaccions i còpies de seguretat.

Vegem el problema amb dades reals (fictícies). Aquesta és una part del full prestecs_sucursal_nord.xlsx tal com és avui:

Un examen atent revela almenys vuit defectes, i tots són instàncies dels problemes de l'apartat anterior:

1. Redundància de soci: el correu i el telèfon de Marta Alsina estan escrits tres vegades. Si canvia de telèfon, cal corregir tres files (i les de les altres tres sucursals).
2. Redundància de llibre: el títol, l'autor i l'ISBN de "El mapa del temps" es repeteixen a cada préstec. Amb 40.000 exemplars i anys d'historial, això multiplica el fitxer.
3. Inconsistència en el nom del soci: "Marta Alsina" i "M. Alsina" són la mateixa persona, però cap programa no ho sap. Comptar socis diferents dóna un número equivocat.
4. Inconsistència en l'autor: "Ken Follet" i "Ken Follett", "Félix Palma" i "Félix J. Palma". Cercar per autor retorna resultats incomplets.
5. Dada errònia sense detectar: [email protected] (una lletra canviada) i l'ISBN 978840133909 (li falta un dígit). Res no va validar aquests camps en escriure'ls.
6. Violació d'una regla de negoci: el préstec d'Ivan Pereda té data de devolució (01/04) anterior a la de préstec (07/04). És impossible, i hi és.
7. Format incoherent: "Nord" i "nord"; telèfons amb espais i sense. Qualsevol agrupació per sucursal tractarà "Nord" i "nord" com a valors diferents.
8. Fragmentació: la fila de Núria Bastos diu "Sud", però aquest és el full de la sucursal Nord. La mateixa informació viu en dos fitxers i ningú no sap quin mana.

A això cal afegir-hi dos problemes que la taula no mostra però que passen cada dia:

• Concurrència: si dues persones del taulell obren el full alhora, un dels dos préstecs es perdrà en desar.
• Sense control d'accés: qualsevol amb accés a la carpeta compartida veu telèfons i correus de tots els socis.

La solució consistirà a deixar de tenir una taula que ho barreja tot i passar a tenir diverses taules, cadascuna amb una responsabilitat, unides per claus:

Amb aquesta estructura, el correu de Marta Alsina s'escriu una sola vegada; l'ISBN de "El mapa del temps", una sola vegada; el SGBD impedeix registrar un préstec d'un soci inexistent, i una restricció impedeix que la data de devolució sigui anterior a la de préstec.

Com s'arriba a aquest disseny, com es justifica i com s'escriu en SQL és exactament el recorregut dels mòduls 2, 4 i 5. De moment queda't amb el diagnòstic: tots els mals del full de càlcul tenen nom propi i solució coneguda.

• Confondre "base de dades" amb "SGBD". Es diu "treballo amb PostgreSQL" quan PostgreSQL és el gestor, no la base de dades. És una imprecisió inofensiva en una conversa, però convé tenir-ho clar: un mateix SGBD allotja moltes bases de dades.
• Creure que una base de dades és només un magatzem més ràpid. El seu valor principal no és la velocitat, sinó la garantia: integritat, concurrència i recuperació. Un full de càlcul petit pot ser més ràpid d'obrir; el que no pot fer és garantir res.
• Pensar que la redundància és un problema d'espai. L'espai és barat. El problema de la redundància és que fa inevitable la inconsistència: tan bon punt una dada és en dos llocs, tard o d'hora divergiran.
• Dissenyar la base de dades copiant el full de càlcul tal qual. És la temptació número u en migrar. Una taula ampla amb 30 columnes que ho barreja tot reprodueix a la base de dades exactament els mateixos problemes. Migrar implica redissenyar.
• Començar a escriure taules abans d'entendre el domini. Abans de crear res cal saber quines entitats existeixen i com es relacionen. Dedicar una hora a parlar amb els bibliotecaris estalvia setmanes de correccions.
• Consell pràctic: quan analitzis un sistema existent, fes sempre l'exercici de l'apartat 8. Agafa una mostra real de dades i busca duplicats, valors contradictoris i regles violades. Aquest inventari és la millor justificació possible del projecte davant de qui el paga.

Per a cada element, indica si és una dada, informació o coneixement, i justifica-ho breument:

1. 9788401337208
2. "L'exemplar 3 d'Els pilars de la Terra està prestat fins al 24/04/2026."
3. "La sucursal Nord concentra el 45 % dels préstecs de la xarxa."
4. Marta Alsina
5. "Els socis menors de 25 anys demanen més còmic que la resta."

A partir de la descripció de BiblioRed i del full de càlcul de l'apartat 8, enumera almenys quatre entitats que haurien d'existir a la base de dades, amb tres atributs cadascuna. No dissenyis taules ni claus foranes encara: només identifica les "coses" del domini i les seves característiques.

Aquest és un altre full de BiblioRed, reserves.xlsx:

Enumera tots els problemes que detectis, indicant en cada cas a quin dels sis problemes de l'apartat 7 correspon.

Solució 1

1. Dada. Un número aïllat; sense context no sabem ni que és un ISBN.
2. Informació. Dades (exemplar, títol, data) posades en relació i amb significat.
3. Coneixement. És un patró agregat sobre molts préstecs, útil per decidir (per exemple, reforçar personal a Nord).
4. Dada. Una cadena de text; per si sola no diu si és un soci, un autor o una empleada.
5. Coneixement. Patró extret de l'encreuament de dues dimensions (edat i categoria), directament accionable per a la política de compres.

Solució 2

Una resposta raonable (hi ha variants vàlides):

El punt clau de l'exercici és distingir Llibre d'Exemplar. "Els pilars de la Terra" és una obra, però BiblioRed en té sis còpies físiques repartides entre sucursals. El que es presta és un exemplar, no un llibre. Confondre'ls és un dels errors de modelatge més freqüents en sistemes de biblioteques, i ja s'intueix al full de càlcul: no hi ha manera de saber quina còpia es va endur la Marta.

Solució 3

Observa que el problema 6 és especialment greu: no és un error de format, és que el sistema no té ni idea de quin és l'estat real de la reserva. Aquest és el moment en què una organització descobreix que necessita una base de dades.

En aquesta lliçó hem establert els fonaments conceptuals del curs:

• Hem distingit dada, informació i coneixement: la base de dades guarda el primer perquè sigui barat obtenir el segon i el tercer.
• Hem definit base de dades (col·lecció estructurada, persistent i compartida de dades relacionades) i SGBD (el programari que la gestiona, garantint definició, manipulació, seguretat, concurrència i recuperació).
• Hem fixat el vocabulari que farem servir tot el curs: entitat, atribut, taula, fila, columna, clau primària i clau forana, i hem separat esquema (l'estructura) d'instància (les dades d'ara mateix).
• Hem identificat els sis problemes que resol una base de dades: redundància, inconsistència, manca d'integritat, manca de control de concurrència, manca de seguretat i manca d'independència de dades.
• Hem aplicat tot això a BiblioRed, diagnosticant un full de càlcul real i anticipant —sense dissenyar-la encara— l'estructura de diverses taules relacionades que el substituirà.

Ja sabem què és una base de dades i per què la necessitem. La pregunta següent natural és: totes les bases de dades són iguals? La resposta és que no, ni de bon tros. A la lliçó 01-02, Tipus de Bases de Dades, recorrerem les grans famílies —relacionals, documentals, clau-valor, columnars, de grafs, i unes quantes més— per entendre quina estructura de dades proposa cadascuna, per a quin problema va néixer i com es decideix quina convé. I tornarem a BiblioRed per preguntar-nos quines parts del seu sistema demanen una base de dades relacional i quines potser demanen una altra cosa.