Conèixer la història de les bases de dades no és erudició: és la manera més eficient d'entendre per què les eines actuals són com són. Cada decisió de disseny que avui ens sembla òbvia —que les taules no tinguin ordre, que existeixi un llenguatge declaratiu, que la base de dades garanteixi la integritat— va ser al seu moment una resposta a un problema dolorós i concret. I cada model que avui sembla obsolet va ser durant anys la millor solució disponible.

Aquesta lliçó recorre seixanta anys d'evolució amb el fil dels problemes, no de les dates. En acabar entendràs per què el model relacional va ser una ruptura, per què SQL va sobreviure a totes les modes, quines pressions reals van donar lloc a NoSQL i per què el resultat de tot això no és un guanyador únic, sinó un ecosistema on cada opció conserva el seu nínxol.

1. Abans de les bases de dades: fitxers plans i procés per lots
2. Els primers models: jeràrquic i en xarxa
3. 1970: l'article de Codd i la ruptura relacional
4. System R, Ingres i el naixement de SQL
5. L'era comercial i l'estandardització de SQL
6. Els 2000: el web, l'ORM i el problema de l'escalat
7. El moviment NoSQL i les pressions que el van provocar
8. NewSQL i bases de dades distribuïdes
9. El núvol: bases de dades gestionades i serverless
10. L'etapa recent: bases de dades vectorials
11. Línia temporal completa
12. Les lliçons que deixa la història
13. Errors habituals i consells
14. Exercicis
15. Conclusió

Anys cinquanta i seixanta. Els ordinadors existeixen, però l'emmagatzematge és cinta magnètica: un mitjà estrictament seqüencial. Per llegir el registre número 8.000 cal passar abans pels 7.999 anteriors.

Això ho condiciona tot. La feina s'organitza en processament per lots (batch): durant el dia s'acumulen les transaccions en paper o en targetes perforades; de nit, un programa recorre la cinta mestra de principi a fi, aplica els canvis i escriu una cinta mestra nova. No existeix "consultar el saldo ara": existeix el llistat d'aquest matí.

Les dades viuen en fitxers plans, i cada aplicació té els seus, amb el seu propi format definit dins del codi del programa. Els problemes que això genera són exactament els que vam diagnosticar al full de càlcul de BiblioRed a la lliçó 01-01, multiplicats:

• Redundància massiva: nòmina, comptabilitat i personal guarden cadascuna la seva còpia de les dades de l'empleat.
• Inconsistència garantida: s'actualitza una còpia i no les altres.
• Dependència total entre programa i dades: si s'afegeix un camp al fitxer, cal recompilar tots els programes que el llegeixen, encara que no facin servir aquest camp. El format físic està escrit dins del codi.
• Sense consultes ad hoc: qualsevol pregunta nova exigeix que un programador escrigui un programa nou. Setmanes d'espera per saber quants socis hi ha a la sucursal Nord.

L'arribada del disc d'accés directe a mitjan anys seixanta canvia l'equació: per primera vegada és viable anar directament al registre 8.000. Això obre la porta al processament en línia, interactiu, i amb ell a la idea mateixa d'un sistema gestor de bases de dades: un programari comú, separat de les aplicacions, que centralitzi les dades.

IBM desenvolupa IMS (Information Management System) per al programa Apollo, per gestionar la llista de materials del coet Saturn V: milions de peces organitzades en subconjunts. Un problema naturalment jeràrquic, i el model ho reflecteix: les dades s'organitzen en arbre, cada registre té un pare i pot tenir diversos fills.

Va ser un èxit enorme —IMS continua en producció avui a bancs i asseguradores, seixanta anys després— però el seu límit és estructural:

• Un fill només pot tenir un pare. Una relació molts-a-molts no es pot representar sense duplicar dades. A BiblioRed, un llibre amb dos autors obliga a repetir el llibre sota cada autor, o l'autor sota cada llibre.
• El programador ha de navegar l'arbre explícitament, des de l'arrel i en l'ordre previst.
• Canviar l'estructura de l'arbre trenca els programes.

El consorci CODASYL —el mateix que va estandarditzar COBOL— defineix el model en xarxa, del qual IDMS és el producte més conegut. Charles Bachman, el seu principal impulsor, rep el Premi Turing el 1973.

El model en xarxa generalitza el jeràrquic: un registre pot pertànyer a diversos conjunts, mitjançant punters explícits. Ja es poden representar relacions molts-a-molts.

Però el problema de fons persisteix, i és el que dóna sentit a tot el que ve després:

El programador ha de conèixer i recórrer l'estructura física d'emmagatzematge. Per respondre "quins llibres ha llegit la Marta" cal escriure un programa que obri el conjunt de socis, localitzi la Marta, segueixi el punter al primer préstec, avanci al següent, i així successivament. El com arribar a la dada és responsabilitat de qui programa.

Això significa que no hi ha independència de dades: si l'administrador reorganitza l'emmagatzematge per guanyar rendiment, tots els programes deixen de funcionar. Els sistemes d'informació esdevenen impossibles de fer evolucionar. Aquest és el punt exacte on intervé Codd.

El juny de 1970, Edgar Frank Codd, matemàtic britànic que treballava al laboratori d'IBM a San José, publica "A Relational Model of Data for Large Shared Data Banks" a Communications of the ACM. Són tretze pàgines que reorganitzen la disciplina sencera.

La proposta, en essència:

1. Les dades es representen com a relacions (taules): conjunts de tuples (files) amb atributs (columnes). Res més. Sense punters, sense jerarquies, sense ordre implícit.
2. Les relacions entre dades s'expressen mitjançant valors, no mitjançant punters: si un préstec es refereix al soci 14, ho fa guardant el valor 14, no una adreça de disc.
3. L'accés és declaratiu: l'usuari descriu què vol, no com obtenir-ho. El sistema decideix el camí. Codd proposa dos formalismes equivalents per fer-ho, l'àlgebra relacional i el càlcul relacional.
4. Fonament matemàtic: en basar-se en la teoria de conjunts i la lògica de predicats, les propietats del model són demostrables, no qüestió d'opinió.

Per què va ser una ruptura i no una millora incremental?

La conseqüència pràctica és la independència de dades: es pot canviar com s'emmagatzema sense tocar com es consulta. Això és el que converteix una base de dades en una inversió duradora. Formalitzarem aquest concepte a la lliçó 01-04 i estudiarem el model relacional en detall a la 02-01.

Codd va rebre el Premi Turing el 1981. És notable que la mateixa IBM trigués anys a apostar per la seva idea: tenia IMS venent-se molt bé i poc interès a canibalitzar-lo. La crítica habitual de l'època era que el model relacional seria massa lent, precisament perquè deixava al sistema, i no al programador, l'elecció del camí d'accés. Demostrar que aquesta crítica era infundada va ser la feina de la dècada següent.

Dos projectes de recerca, en paral·lel, converteixen la teoria en programari funcionant.

El prototip amb el qual IBM demostra que un sistema relacional pot ser ràpid. Les seves aportacions sobreviuen fins avui en qualsevol base de dades que facis servir:

• L'optimitzador basat en costos: el sistema estima el cost de diversos plans d'execució possibles i tria el millor. És la peça que fa viable l'accés declaratiu, i és la raó per la qual avui escrius una consulta sense pensar en com s'executarà.
• El gestor de transaccions amb registre d'operacions (write-ahead log) i bloqueig en dues fases, base del que més tard s'anomenaria ACID (lliçó 06-01).
• El llenguatge SEQUEL (Structured English Query Language), dissenyat per Donald Chamberlin i Raymond Boyce, pensat perquè fos llegible per persones no matemàtiques. Per un conflicte de marca es va reanomenar SQL.

Compara la intenció amb el que hi havia abans:

Davant de l'equivalent en un sistema CODASYL, que seria un programa de desenes de línies obrint conjunts i seguint punters. Aquest salt expressiu, juntament amb l'optimitzador que el feia competitiu en velocitat, és el que va guanyar la partida.

Michael Stonebraker i Eugene Wong construeixen Ingres amb finançament públic i el distribueixen amb el seu codi font a universitats. Fa servir un llenguatge propi, QUEL, tècnicament molt elegant, que acabarà perdent davant de SQL per raons comercials més que tècniques.

El seu llegat és enorme per una altra via: d'Ingres i de la gent que hi va passar surten Sybase, Microsoft SQL Server, Informix i, sobretot, Postgres (1986), el successor de Stonebraker, que anys després adoptaria SQL i passaria a dir-se PostgreSQL. El gestor que farem servir en aquest curs descendeix directament d'aquell projecte universitari. Stonebraker va rebre el Premi Turing el 2014.

El 1979, una petita empresa anomenada Relational Software llança Oracle V2, el primer RDBMS comercial amb SQL, avançant-se a la mateixa IBM (que treu SQL/DS el 1981 i DB2 el 1983). L'empresa acabaria dient-se Oracle Corporation.

Els anys vuitanta consoliden el model: Informix (1980), Sybase (1984), i al món del PC dBase i després Access. Als anys noranta apareixen les alternatives lliures que democratitzen l'accés: MySQL (1995), PostgreSQL amb el seu nom actual (1996) i, el 2000, SQLite, que porta un motor relacional complet a un fitxer de menys d'un megabyte.

Mentrestant, SQL s'estandarditza. Aquesta és l'evolució que importa entendre:

Dues observacions importants:

• Cap producte no implementa l'estàndard complet, i tots hi afegeixen extensions pròpies. Per això parlem de "dialectes": PostgreSQL, MySQL, Oracle i SQLite comparteixen la immensa majoria del SQL quotidià, però difereixen en tipus, funcions i sintaxi avançada. En aquest curs farem servir SQL estàndard amb PostgreSQL com a referència, assenyalant les diferències amb SQLite quan n'hi hagi.
• Fixa't en SQL:2016 i SQL:2023: l'estàndard relacional va absorbir JSON i grafs, és a dir, va incorporar allò que les bases NoSQL havien popularitzat. És un patró que es repeteix en tota aquesta història.

Internet canvia el perfil de càrrega. Una base de dades empresarial dels noranta servia uns centenars d'empleats en horari d'oficina; un lloc web serveix milions d'usuaris anònims les vint-i-quatre hores i des de qualsevol lloc del món.

Apareixen dues tensions simultànies.

Els llenguatges dominants (Java, C#, després Python, Ruby, PHP) són orientats a objectes: grafs d'objectes amb herència i referències. Les bases de dades són relacionals: taules planes. Traduir entre tots dos mons a mà és tediós i repetitiu. Aquesta fricció s'anomena object-relational impedance mismatch.

La resposta són els ORM (Hibernate el 2001, Django ORM, Active Record, Entity Framework, SQLAlchemy): capes que tradueixen automàticament objectes a files i a la inversa. Acceleren el desenvolupament enormement, però tenen un efecte secundari que arriba fins avui: moltes persones desenvolupen sobre bases de dades relacionals sense entendre quin SQL s'està executant, i només ho descobreixen quan el rendiment s'enfonsa. És una de les raons per les quals un curs com aquest continua tenint sentit.

Fins llavors, la resposta a "la base de dades va lenta" era escalar verticalment: comprar una màquina més gran. Funciona fins que deixa de funcionar: hi ha un límit físic, el preu creix de manera no lineal i continua havent-hi un únic punt de fallada.

L'alternativa és escalar horitzontalment: repartir la càrrega entre moltes màquines barates. Però un RDBMS clàssic està dissenyat al voltant d'un node amb una vista coherent de totes les dades. Repartir una base relacional entre nodes (sharding) obliga a renunciar a les unions entre fragments i a les transaccions globals, i a fer-ho a mà, a l'aplicació.

Empreses com Google, Amazon o Facebook topen amb aquest mur abans que ningú, senzillament perquè arriben abans a aquesta escala. I publiquen el que fan: BigTable (Google, 2006) i Dynamo (Amazon, 2007) són els dos articles que encenen la metxa.

El terme "NoSQL" es popularitza el 2009, en una trobada a San Francisco sobre bases de dades distribuïdes no relacionals. Aviat es reinterpreta com a "Not Only SQL", que descriu millor el que va passar.

Van ser quatre pressions reals, no una moda:

1. Volum. Petabytes de dades que no caben en un servidor, per gran que sigui.
2. Distribució geogràfica. Serveis globals que necessiten replicar dades entre continents i continuar funcionant encara que caigui un centre de dades sencer.
3. Esquemes canviants. Productes web que despleguen diverses vegades al dia i les dades dels quals canvien de forma constantment. Una migració d'esquema sobre una taula de mil milions de files pot bloquejar el servei durant hores.
4. Dades poc estructurades. Documents, registres d'activitat, contingut generat per usuaris, que no encaixen de manera natural en files i columnes.

El compromís que accepten aquests sistemes s'articula al voltant del teorema CAP (Eric Brewer, 2000): en un sistema distribuït que pot patir particions de xarxa, cal triar entre coherència i disponibilitat. Molts sistemes NoSQL trien disponibilitat i coherència eventual: després d'una escriptura, les rèpliques convergeixen al mateix valor, però no instantàniament. Per a un carret de la compra és acceptable; per a un assentament comptable, no. El teorema CAP i les seves implicacions s'estudien en detall a la lliçó 03-04.

La cronologia de productes és densa: BigTable (2006), Dynamo (2007), Cassandra (Facebook, 2008), Redis i MongoDB (2009), Neo4j popularitzant els grafs, DynamoDB com a servei (2012).

I després va venir la correcció. Entre 2012 i 2016 moltes organitzacions descobreixen que havien adoptat NoSQL per a problemes que no tenien: sense el volum que ho justifiqués, havien perdut integritat, transaccions i SQL a canvi de res. El mateix ecosistema NoSQL reacciona: MongoDB afegeix transaccions multidocument el 2018 i validació d'esquema, és a dir, recupera part del que havia descartat. En paral·lel, PostgreSQL incorpora jsonb (2014) i es converteix en un documental perfectament capaç.

El resultat net no va ser la substitució d'un model per un altre, sinó l'ampliació del catàleg d'opcions i la convergència de les famílies.

Cap al 2011 sorgeix la pregunta natural: és realment inevitable triar entre escalat horitzontal i garanties transaccionals? La resposta d'una nova generació de sistemes —batejada NewSQL— és que no, si es redissenya el motor des de zero per funcionar distribuït.

• Google Spanner (2012) és la fita: una base de dades distribuïda globalment, amb transaccions ACID i coherència externa, recolzada en rellotges atòmics i GPS (l'API TrueTime) per ordenar les transaccions entre continents.
• CockroachDB (2015) i YugabyteDB porten aquestes idees al programari lliure, amb compatibilitat amb el protocol de PostgreSQL.
• VoltDB, TiDB, Vitess (el sistema amb què YouTube va escalar MySQL) i Citus (extensió de PostgreSQL) ataquen el mateix problema des d'angles diferents.

La idea comuna: SQL i ACID no eren l'obstacle per escalar; ho era l'arquitectura monolítica dels motors tradicionals. Amb consens distribuït (Raft, Paxos) i particionat automàtic, es poden tenir totes dues coses, al preu d'una latència més gran en les escriptures que creuen regions.

En paral·lel a l'evolució dels models, canvia radicalment qui opera la base de dades.

• Amazon RDS (2009) inaugura la base de dades gestionada: el proveïdor s'ocupa d'instal·lació, pedaços, còpies de seguretat, rèpliques i commutació per error. L'equip es limita a fer-la servir.
• El segueixen Azure SQL Database, Google Cloud SQL i les ofertes gestionades de gairebé tots els productes (MongoDB Atlas, Redis Cloud).
• Amazon Aurora (2014) redissenya el motor separant el càlcul de l'emmagatzematge, mantenint compatibilitat amb MySQL i PostgreSQL.
• L'etapa serverless (Aurora Serverless, Neon, PlanetScale, Supabase, Turso) porta la idea més lluny: no hi ha servidor que dimensionar, la capacitat s'ajusta sola i es paga per ús, fins i tot baixant a zero quan no hi ha activitat.

L'efecte per a qui aprèn avui és doble. D'una banda, baixa moltíssim la barrera d'entrada: es pot tenir un PostgreSQL productiu en dos minuts i sense administrar res. De l'altra, el coneixement que importa es desplaça: administrar el servidor perd pes, i dissenyar bé l'esquema i escriure bones consultes ho guanyen tot. Que és exactament el que ensenya aquest curs.

La darrera incorporació al panorama arriba amb els models de llenguatge i de visió. Aquests models converteixen un text, una imatge o un àudio en un vector de centenars o milers de dimensions —un embedding— la propietat clau del qual és que dos continguts amb significat semblant produeixen vectors propers a l'espai.

Això planteja una necessitat d'emmagatzematge nova: guardar milions de vectors i respondre ràpid a "dóna'm els cent més semblants a aquest", amb índexs aproximats de veïns propers (HNSW, IVF) que sacrifiquen exactitud a canvi de velocitat.

Entre 2019 i 2023 apareixen Milvus, Pinecone, Weaviate i Qdrant, i la tècnica es torna massiva amb els sistemes que recuperen documents rellevants per donar-los com a context a un model de llenguatge.

I es repeteix el patró de sempre: els sistemes establerts absorbeixen la novetat. pgvector converteix PostgreSQL en una base de dades vectorial competent, i els motors de cerca i els documentals afegeixen la seva pròpia cerca vectorial. La història suggereix que les bases vectorials especialitzades conservaran el seu nínxol a l'escala més alta, mentre que la majoria de projectes faran servir l'extensió de la seva base de dades habitual.

Aquest és el contingut que de debò cal retenir.

1. Cada model va néixer per resoldre un problema concret. El jeràrquic, per a estructures d'arbre com la llista de materials d'un coet. El relacional, per acabar amb la dependència entre programes i emmagatzematge. NoSQL, per a volum i distribució a escala planetària. Les vectorials, per a la cerca per similitud semàntica. Preguntar-se "quin problema resolia això?" és la millor manera de saber si és el teu problema.

2. Cap model no va substituir del tot l'anterior. IMS continua processant transaccions bancàries seixanta anys després. COBOL i CODASYL continuen vius. El relacional no va eliminar el jeràrquic, i NoSQL no va eliminar el relacional: el relacional continua sent, de bon tros, la família més utilitzada del món. La tecnologia s'acumula molt més del que es reemplaça.

3. El declaratiu guanya al procedimental. El gran encert de Codd va ser separar el què del com. Cada vegada que el sector ha tornat a exigir als programadors que gestionin a mà el camí d'accés —els primers NoSQL, en bona mesura—, ha acabat reintroduint capes declaratives per damunt.

4. Les garanties que es descarten s'han de reimplementar. Si la base de dades no garanteix la integritat, algú ho farà al codi de l'aplicació, pitjor i en més llocs. Que MongoDB acabés afegint transaccions i validació d'esquema és la prova històrica d'aquest principi.

5. Les famílies convergeixen. PostgreSQL emmagatzema JSON i vectors; MongoDB té transaccions; l'estàndard SQL incorpora grafs. La frontera entre "SQL" i "NoSQL" és avui molt més borrosa que el 2010, i la pregunta útil ja no és "SQL o NoSQL?" sinó "quines garanties necessito i quina càrrega hauré de suportar?".

6. L'escala real gairebé mai no és l'escala imaginada. Bona part de les adopcions de NoSQL dels anys 2010 resolien problemes de Google en organitzacions que no eren Google. Per a BiblioRed —12.000 socis— la resposta correcta és l'avorrida i provada: PostgreSQL.

• Llegir la història com una escala de progrés. No hi ha una successió de models cada cop millors; hi ha una acumulació d'eines amb compromisos diferents. El "més modern" no és el més adequat per defecte.
• Creure que NoSQL va néixer contra SQL. Va néixer contra l'escalat d'un servidor únic, no contra el llenguatge ni contra el model relacional. Prova d'això és que avui molts sistemes NoSQL ofereixen interfícies de tipus SQL.
• Suposar que els sistemes heretats són sistemes dolents. Un IMS que porta quaranta anys sense perdre una transacció té un historial de fiabilitat que poques tecnologies modernes poden exhibir. Migrar té costos i riscos que cal justificar.
• Confondre l'estàndard SQL amb el que fa el teu gestor. Cap producte no l'implementa complet i tots hi afegeixen extensions. Abans de donar per bona una consulta "estàndard", comprova-la al teu dialecte.
• Consell: quan avaluïs una tecnologia de dades, busca l'article original que la va introduir (els de Dynamo, BigTable, Spanner o Codd estan disponibles i són llegibles). Solen dir amb molta claredat quin problema ataquen i quines renúncies assumeixen; el material de màrqueting posterior, molt menys.

Aparella cada problema històric amb la innovació que el va resoldre i explica el vincle en una frase:

Problemes

1. Canviar el format físic d'un fitxer obligava a recompilar tots els programes.
2. Un llibre amb dos autors no es podia representar sense duplicar dades.
3. Les dades d'una empresa global no caben en un únic servidor.
4. Traduir a mà entre objectes de Java i files de taules era lent i repetitiu.
5. No es podia cercar "documents que parlin d'alguna cosa semblant a això".
6. Escalar horitzontalment obligava a renunciar a les transaccions ACID.

Innovacions: ORM · model relacional i la seva independència de dades · NewSQL i consens distribuït · bases de dades vectorials · model en xarxa (CODASYL) · NoSQL distribuït

Ordena cronològicament aquestes fites i indica la dècada de cadascuna:

• Publicació de l'article de Codd
• Aparició de MongoDB i Redis
• SQL-92
• IMS per al programa Apollo
• Google Spanner
• Llançament de SQLite
• Oracle V2, primer RDBMS comercial amb SQL
• Amazon RDS

Un consultor proposa a BiblioRed migrar tot el seu sistema a una base de dades distribuïda NewSQL "perquè és el que fan servir Google i els bancs moderns". Redacta una valoració de 6-10 línies que faci servir arguments històrics d'aquesta lliçó: quin problema resolia cada tecnologia, si BiblioRed té aquest problema, i què recomanaries.

Solució 1

Solució 2

(MongoDB, Redis i RDS són del mateix any; l'ordre entre ells és indiferent.)

Solució 3

Resposta model:

Les bases NewSQL com Spanner o CockroachDB es van dissenyar per a un problema molt concret: mantenir transaccions ACID quan les dades estan repartides entre desenes o centenars de nodes, sovint en diversos continents. Google ho necessitava perquè el seu volum i la seva distribució geogràfica feien impossible un servidor únic; un banc global, per raons semblants. BiblioRed no té aquest problema: 12.000 socis, quatre sucursals en una mateixa ciutat i uns centenars de milers de préstecs a l'any caben amb folgança en un sol PostgreSQL, amb marge per a anys de creixement. Adoptar un sistema distribuït implicaria assumir la complexitat operativa del consens, la replicació i l'observabilitat, a més d'una latència més gran en les escriptures, sense obtenir a canvi res que no tinguem ja. La lliçó històrica és justament aquesta: bona part de les migracions de la dècada del 2010 van resoldre problemes de Google en organitzacions que no eren Google. Recomano PostgreSQL autogestionat o en servei gestionat, amb còpies de seguretat i una rèplica de lectura, i reconsiderar la qüestió únicament si algun dia apareixen requisits reals de multiregió o de volum que avui no existeixen.

Hem recorregut seixanta anys seguint el fil dels problemes, no de les dates:

• Els fitxers plans i el procés per lots generaven redundància, inconsistència i una dependència total entre programes i emmagatzematge.
• Els models jeràrquic (IMS) i en xarxa (CODASYL) van centralitzar les dades, però obligaven el programador a navegar l'estructura física.
• L'article de Codd del 1970 va trencar amb això: dades com a relacions, vincles per valors, accés declaratiu i fonament matemàtic. El seu fruit pràctic és la independència de dades.
• System R i Ingres ho van fer viable, aportant l'optimitzador basat en costos, les transaccions i el llenguatge SQL, que es va estandarditzar des de SQL-86 fins a SQL:2023.
• El web i l'ORM van portar noves escales i noves friccions; el límit de l'escalat vertical va portar a NoSQL, empès per volum, distribució, esquemes canviants i dades poc estructurades.
• NewSQL va demostrar que ACID i escalat horitzontal podien conviure; el núvol va canviar qui opera les bases de dades; les vectorials hi van afegir la cerca per similitud.
• I la conclusió de fons: cada model va resoldre un problema real, cap no va substituir del tot l'anterior, i les famílies convergeixen.

Ja sabem què són les bases de dades, quins tipus hi ha i d'on ve cadascun. Queda obrir la caixa: què hi ha exactament dins del programari que les gestiona. A la lliçó 01-04, Sistemes Gestors de Bases de Dades i Arquitectura, veurem el recorregut complet d'una consulta des que s'escriu fins que retorna files, l'arquitectura de tres nivells que fa possible la independència de dades que Codd va proposar, la diferència entre client-servidor i incrustat —PostgreSQL i SQLite, cadascun en un extrem— i, molt en concret, instal·larem l'entorn i crearem la base de dades biblioredb on executarem tot el SQL del curs.