Salta el contingut

Introducció a les bases de dades

De la dada a la saviesa

Abans d'entrar en els SGBD, cal entendre quin tipus d'actiu gestionem. Existeix una jerarquia clàssica coneguda com la piràmide DIKW (Data, Information, Knowledge, Wisdom) que descriu com els elements en brut es transformen progressivament en valor:

Exemple: botiga en línia

Una botiga en línia registra cada venda. Observa com els mateixos fets pugen de nivell:

Dades (en brut) cliente_id=127, data=2025-11-25, import=349.99

Informació (contextualitzada) El client 127 va gastar 349,99 € el dia de Black Friday.

Coneixement (patró) Els clients recurrents compren electrònica en Black Friday amb un tiquet mitjà de 300 €.

Saviesa (decisió) Cal incrementar l'estoc d'electrònica al novembre i activar campanyes de fidelització prèvies al Black Friday.

flowchart TB
    D["Dades\n(Data)"]
    I["Informació\n(Information)"]
    K["Coneixement\n(Knowledge)"]
    W["Saviesa\n(Wisdom)"]

    D -->|"context + significat"| I
    I -->|"patrons + experiència"| K
    K -->|"judici + valors"| W

    style D fill:#1565c0,stroke:#42a5f5,color:#fff
    style I fill:#1b5e20,stroke:#4caf50,color:#fff
    style K fill:#4a148c,stroke:#ab47bc,color:#fff
    style W fill:#b71c1c,stroke:#ef5350,color:#fff
Dada
Un fet brut, sense context. Per si sola no transmet cap significat. Exemple: 37, Barcelona, 2025-06-21.
Informació
Dades organitzades i contextualitzades que responen a les preguntes qui, què, quan o on. Exemple: "La temperatura a Barcelona el 21 de juny de 2025 era de 37 °C".
Coneixement
Informació interioritzada i relacionada amb experiència prèvia, que permet comprendre patrons i prendre decisions. Exemple: "37 °C és inusualment alt per a Barcelona al juny, cosa que indica una onada de calor".
Saviesa
Capacitat de fer judicis encertats aplicant coneixement i valors. Va més enllà dels fets i incorpora criteri. Exemple: "Davant d'aquesta onada de calor, cal activar el protocol d'emergència sanitària i avisar els centres de dia".

Per què és important aquesta distinció?

Un SGBD emmagatzema dades. Però l'objectiu final és convertir-les en informació (amb consultes SQL), en coneixement (amb anàlisi i BI) i, en últim terme, en decisions (saviesa). Entendre aquesta jerarquia ajuda a dissenyar millors bases de dades i a formular millors preguntes.

Què és una base de dades?

Una base de dades és una col·lecció organitzada d'informació estructurada, emmagatzemada electrònicament en un sistema informàtic i gestionada normalment per un Sistema Gestor de Bases de Dades (SGBD). La diferència fonamental entre emmagatzemar dades en fitxers plans (com un CSV o un fitxer de text) i emmagatzemar-les en una base de dades rau en la capacitat del SGBD per garantir la integritat, la consistència, la seguretat i la disponibilitat concurrent de les dades.

Analogia

Si les dades fossin llibres, un fitxer pla seria una pila de llibres sobre la taula: accessible, però desorganitzada i difícil de consultar. Una base de dades seria una biblioteca: organitzada, catalogada, accessible simultàniament per múltiples usuaris i amb mecanismes per evitar que dos usuaris agafin el mateix exemplar al mateix temps.

Breu història dels SGBD

La gestió de dades informatitzada ha evolucionat enormement des dels anys seixanta:

Dècada Fites principals
1960s Fitxers plans i sistemes de procés per lots
IBM IMS (model jeràrquic) — 1968
1970s Model relacional — Edgar Codd (IBM) — 1970
System R (IBM) i INGRES (Berkeley): primers SGBD relacionals
Apareix SQL — 1974
1980s Oracle 2 (1979), IBM DB2 (1983)
SQL es converteix en estàndard ANSI — 1986
Popularització dels SGBD relacionals comercials
1990s MySQL (1995), PostgreSQL (evolució d'INGRES)
SQL Server (Microsoft, 1989)
Auge d'internet i aplicacions web
2000s Explosió de dades. Limitacions del model relacional
Apareixement del moviment NoSQL
MongoDB (2009), Cassandra (2008), Redis (2009)
2010s NewSQL: Google Spanner, CockroachDB
BD en el núvol: RDS, Cloud SQL, Azure SQL
Consolidació de PostgreSQL com a referència
2020s BD multimodel, BD vectorials per IA
PostgreSQL 17, MySQL 8.4 LTS, MariaDB 11.4

Arquitectura ANSI/SPARC

L'arquitectura de tres nivells ANSI/SPARC (1975) és el model conceptual de referència per entendre com s'organitza un SGBD. Estableix tres nivells d'abstracció que separen les dades físiques de la vista que en té l'usuari:

flowchart TB
    U1["Usuari 1\n(app web)"] & U2["Usuari 2\n(BI analyst)"] & U3["Usuari 3\n(DBA)"]

    subgraph Extern["nivell extern (vistes d'usuari)"]
        V1["Vista: clients_actius"]
        V2["Vista: vendes_mensuals"]
        V3["Vista: esquema complet"]
    end

    subgraph lògic["nivell conceptual (esquema lògic)"]
        T1["Taula: clients"]
        T2["Taula: comandes"]
        T3["Taula: productes"]
    end

    subgraph físic["nivell intern (emmagatzematge físic)"]
        F1["Fitxers de dades\n(pages, blocks)"]
        F2["índex B-tree"]
        F3["WAL / Redo log"]
    end

    U1 --> V1
    U2 --> V2
    U3 --> V3
    V1 & V2 & V3 --> T1 & T2 & T3
    T1 & T2 & T3 --> F1 & F2 & F3

    style U1 fill:#1e293b,stroke:#475569,color:#fff
    style U2 fill:#1e293b,stroke:#475569,color:#fff
    style U3 fill:#1e293b,stroke:#475569,color:#fff
    style V1 fill:#2563EB,stroke:#1d4ed8,color:#fff
    style V2 fill:#2563EB,stroke:#1d4ed8,color:#fff
    style V3 fill:#2563EB,stroke:#1d4ed8,color:#fff
    style T1 fill:#16A34A,stroke:#15803d,color:#fff
    style T2 fill:#16A34A,stroke:#15803d,color:#fff
    style T3 fill:#16A34A,stroke:#15803d,color:#fff
    style F1 fill:#7C3AED,stroke:#6d28d9,color:#fff
    style F2 fill:#7C3AED,stroke:#6d28d9,color:#fff
    style F3 fill:#7C3AED,stroke:#6d28d9,color:#fff
    style Extern fill:#1e3a8a,stroke:#3b82f6,color:#fff
    style lògic  fill:#14532d,stroke:#22c55e,color:#fff
    style físic  fill:#4c1d95,stroke:#a855f7,color:#fff
  • nivell extern (vistes): Cadascun dels usuaris o aplicacions veu una porció de les dades adaptada a les seves necessitats, sense necessitat de conèixer l'estructura interna.
  • nivell conceptual (esquema lògic): Descriu quines dades s'emmagatzemen i les relacions entre elles, independent del maquinari.
  • nivell intern (emmagatzematge): Descriu com les dades es guarden físicament: pàgines de disc, índexs, fitxers de log.

La independència entre nivells és clau: podem canviar com s'emmagatzemen les dades físicament sense modificar les aplicacions que hi accedeixen (independència física), i podem reorganitzar l'esquema lògic sense afectar les vistes dels usuaris (independència lògica).

Principals SGBD relacionals al mercat

PostgreSQL

PostgreSQL és un SGBD relacional de codi obert, considerat el més complet i estàndard-compliant dels SGBD lliures. Va néixer com a projecte POSTGRES a la Universitat de Berkeley el 1986, derivant del projecte INGRES. El 1996 va adoptar el nom PostgreSQL per reflectir el suport a SQL.

  • Punts forts: Compliment dels estàndards SQL, suport per a tipus de dades avançats (JSON, arrays, geometria GIS amb PostGIS), extensibilitat, robustesa en entorns de molta concurrència.
  • Casos d'ús típics: Aplicacions web escalables, sistemes GIS, analítica, datawarehousing.
  • Versió actual: PostgreSQL 18.
  • Llicència: PostgreSQL License (permissiva, similar a BSD/MIT).

MySQL i MariaDB

MySQL va ser creat per Michael Widenius (Monty) i David Axmark el 1995, i va contribuir de forma decisiva a la popularització de les aplicacions web dinàmiques (pila LAMP). El 2008 va ser adquirit per Sun Microsystems i el 2010 per Oracle Corporation.

MariaDB és un fork comunitari de MySQL, creat el 2009 pel propi Monty Widenius en resposta a les preocupacions sobre la gestió d'Oracle. Manté la compatibilitat binària amb MySQL però ha incorporat funcionalitats i optimitzacions pròpies.

  • Punts forts: Facilitat d'instal·lació i configuració, gran comunitat, ampli ecosistema de documentació i eines, rendiment excel·lent per a lectures massives.
  • Casos d'ús típics: Aplicacions web (WordPress, Drupal, Magento), e-commerce, CMS.
  • Versions actuals: MySQL 8 LTS / MariaDB 12 LTS.
  • Llicència: GPL v2 (amb excepcions comercials per a MySQL Enterprise).

SQL Server

Microsoft SQL Server va ser llançat el 1989 i és el SGBD líder en entorns corporatius Windows. A partir de la versió 2017 està disponible per a Linux, la qual cosa ha expandit considerablement el seu mercat.

  • Punts forts: Integració nativa amb l'ecosistema Microsoft (.NET, Azure, Power BI, SSIS), eines d'administració molt potents (SQL Server Management Studio), suport per a Always On Availability Groups.
  • Casos d'ús típics: Aplicacions corporatives Windows, sistemes ERP, BI i reporting, entorns amb Microsoft 365.
  • Versió actual: SQL Server 2025.
  • Llicència: Propietari (Microsoft). Disponible en edicions Express (gratuïta), Developer, Standard i Enterprise.

Oracle Database

Oracle Database va ser el primer SGBD relacional comercial disponible al mercat. Va ser creat per Larry Ellison, Bob Miner i Ed Oates el 1977 i llançat el 1979 com a Oracle V2. Des d'aleshores ha estat el SGBD de referència en grans corporacions, banca, telecomunicacions i administracions públiques de tot el món.

  • Punts forts: Maduresa i estabilitat contrastades durant dècades, funcionalitats empresarials avançades (particionament, compressió, auditing), RAC (Real Application Clusters) per a alta disponibilitat, Data Guard per a recuperació de desastres, PL/SQL com a llenguatge de procediments emmagatzemats molt potent.
  • Casos d'ús típics: Sistemes bancaris i financers de missió crítica, ERP corporatiu (SAP, Oracle E-Business Suite), telecomunicacions, administracions públiques de gran escala.
  • Versió actual: Oracle Database 23ai (versió de producció) / Oracle Database 21c XE (edició gratuïta per a aprenentatge).
  • Llicència: Propietari (Oracle Corporation). Disponible en edicions XE (gratuïta, amb limitacions), Standard Edition 2 i Enterprise Edition.

Oracle XE per a aprenentatge

Oracle Database 21c XE (Express Edition) és gratuïta i disponible com a imatge Docker oficial. Permet practicar PL/SQL, gestió d'esquemes, índexs i transaccions sense cap cost de llicència. Les limitacions (12 GB de dades, 2 CPU, 2 GB de RAM) són més que suficients per a entorns de pràctiques.

Comparativa de funcionalitats

Característica PostgreSQL 18 MySQL 8 SQL Server 2025 Oracle 21c XE
Llicència Open Source GPL / Comercial Propietari Propietari (XE gratuït)
Plataformes Linux, Win, Mac, Docker Linux, Win, Mac, Docker Linux, Win, Docker Linux, Win, Docker
ACID Complet Complet (InnoDB) Complet Complet
JSON/Document JSONB natiu JSON natiu JSON parcial JSON natiu (21c+)
Full-text search tsvector/tsquery FULLTEXT Full-Text Search Oracle Text
Particionament Declaratiu (PG 10+) Natiu Natiu Avançat (EE)
CTEs recursives Sí Sí (8.0+) Sí Sí
Window functions Sí Sí (8.0+) Sí Sí
Procediments emmagatzemats PL/pgSQL SQL/PSM T-SQL PL/SQL
Replicació Streaming/logical GTID, semi-sync Always On AG Data Guard / GoldenGate
Eina gràfica oficial pgAdmin 4 MySQL Workbench SSMS SQL Developer

AC0372/01/08 — Miniactivitat

RA1 · CA1.2, CA1.6

Accediu al lloc db-engines.com/en/ranking i consulteu el ranking de popularitat dels SGBD. Quins són els 5 primers? Quin SGBD no relacional apareix primer? Ha canviat molt el ranking en els últims 5 anys?

Propietats ACID

Les propietats ACID defineixen els criteris que ha de complir qualsevol transacció en un SGBD fiable:

flowchart LR
    A["Atomicitat\n(Atomicity)"]
    C["consistència\n(Consistency)"]
    I["Aïllament\n(Isolation)"]
    D["Durabilitat\n(Durability)"]

    A -->|"tot o res"| C
    C -->|"regles sempre valides"| I
    I -->|"transaccions separades"| D
    D -->|"persistència garantida"| A

    style A fill:#3949ab,color:#fff,stroke:#7986cb
    style C fill:#3949ab,color:#fff,stroke:#7986cb
    style I fill:#3949ab,color:#fff,stroke:#7986cb
    style D fill:#3949ab,color:#fff,stroke:#7986cb

  • Atomicitat: Una transacció és indivisible. O s'executen totes les operacions que la componen, o no s'executa cap. Si hi ha un error a la meitat d'una transacció, el SGBD desfà tots els canvis ja realitzats (ROLLBACK).

  • Consistència: Una transacció porta la base de dades d'un estat vàlid a un altre estat vàlid. Les regles d'integritat (restriccions de clau, restriccions CHECK, etc.) s'han de complir abans i després de cada transacció.

  • Aïllament: Les transaccions concurrents s'executen com si fossin seqüencials. Una transacció no veu els canvis a mig fer d'una altra transacció concurrent (llevat que s'hagi configurat un nivell d'aïllament menys estricte).

  • Durabilitat: Un cop una transacció ha estat confirmada (COMMIT), els seus canvis són permanents, fins i tot si el sistema falla immediatament després (talls de llum, crashes del servidor).

ACID i les BD NoSQL

No totes les bases de dades ofereixen propietats ACID completes. Molts sistemes NoSQL sacrifiquen l'aïllament o la consistència forta a favor de la disponibilitat i el rendiment distribuït (vegeu el teorema CAP). Coneguts com a sistemes BASE (Basically Available, Soft state, Eventually consistent).

Arquitectura interna d'un SGBD relacional

Internament, un SGBD com PostgreSQL o MySQL està compost per diversos subsistemes que treballen coordinadament:

flowchart TD
    Client["Client\n(app, DBeaver, psql)"]

    subgraph SGBD["SGBD"]
        Parser["Parser SQL\n(anàlisi sintàctica)"]
        Planner["Optimitzador\n(pla d'execució)"]
        Executor["Executor"]

        subgraph Storage["Capa d'emmagatzematge"]
            BufMgr["Gestor de buffer\n(cache de pàgines)"]
            TxMgr["Gestor de transaccions\n(MVCC / 2PL)"]
            WAL["WAL / Redo Log\n(durabilitat)"]
        end

        Catalog["Catàleg del sistema\n(metadades)"]
    end

    Disk["Disc\n(fitxers de dades)"]

    Client --> Parser --> Planner --> Executor
    Executor --> BufMgr
    BufMgr <--> TxMgr
    TxMgr --> WAL
    BufMgr <--> Disk
    WAL --> Disk
    Planner <--> Catalog

    style Client  fill:#2563EB,stroke:#1d4ed8,color:#fff
    style Parser  fill:#2563EB,stroke:#1d4ed8,color:#fff
    style Planner fill:#2563EB,stroke:#1d4ed8,color:#fff
    style Executor fill:#2563EB,stroke:#1d4ed8,color:#fff
    style BufMgr  fill:#16A34A,stroke:#15803d,color:#fff
    style TxMgr   fill:#16A34A,stroke:#15803d,color:#fff
    style WAL     fill:#16A34A,stroke:#15803d,color:#fff
    style Catalog fill:#7C3AED,stroke:#6d28d9,color:#fff
    style Disk    fill:#1e293b,stroke:#475569,color:#fff
    style SGBD    fill:#1e3a8a,stroke:#3b82f6,color:#fff
    style Storage fill:#14532d,stroke:#22c55e,color:#fff

Cada component té una responsabilitat clara:

  • El parser verifica la sintaxi SQL i construeix un arbre sintàctic.
  • L'optimitzador analitza com obtenir el resultat de la forma més eficient (quin índex usar, en quin ordre fer els JOINs).
  • L'executor porta a terme el pla d'execució.
  • El gestor de buffer manté a memòria les pàgines de disc accedides recentment (cache) per evitar lectures innecessàries.
  • El gestor de transaccions garanteix l'aïllament entre transaccions concurrents.
  • El WAL (Write-Ahead Log) garanteix la durabilitat: escriu els canvis al log abans d'aplicar-los al fitxer de dades.
  • El catàleg del sistema conté les metadades de tots els objectes (taules, columnes, índexs, usuaris, etc.).

AC0372/01/09 — Miniactivitat

RA1 · CA1.4, CA1.5

Connecteu-vos a un contenidor PostgreSQL amb Docker i exploreu el catàleg del sistema executant: 

SELECT tablename, tableowner FROM pg_tables WHERE schemaname = 'public';
SELECT * FROM information_schema.tables WHERE table_schema = 'public';
Quina diferència observeu entre pg_tables i information_schema.tables?