Introducció als Sistemes Gestors de Bases de Dades

Proposta didàctica

Aquesta unitat constitueix el punt de partida del mòdul M0377. Abans d'instal·lar ni configurar cap motor, necessitem entendre per què existeixen els SGBD, quins problemes resolen i per què hi ha diversos motors al mercat amb característiques tan diferents. Analitzarem la seva arquitectura fonamental, els tipus existents i farem una comparativa detallada dels quatre motors que treballarem al llarg del mòdul.

1. Què és un Sistema Gestor de Bases de Dades?

Un Sistema Gestor de Bases de Dades (SGBD) — o Database Management System (DBMS) en anglès — és un conjunt de programes que permeten emmagatzemar, recuperar, actualitzar i gestionar dades de forma persistent, segura i eficient. Va molt més enllà d'un simple sistema d'arxius: un SGBD garanteix que les dades siguin consistents, que múltiples usuaris hi puguin accedir simultàniament sense conflictes, i que es recuperin correctament davant d'una fallada del sistema.

1.1 El problema que resol

Abans dels SGBD, les aplicacions emmagatzemaven les dades directament en arxius plans (fitxers de text, fitxers binaris). Això generava problemes seriosos:

Redundància de dades: La mateixa informació apareixia en múltiples fitxers, amb el risc de inconsistències.
Dependència entre programes i dades: Si canviava el format d'un fitxer, calia modificar tots els programes que l'usaven.
Accés concurrent insegur: Dos processos escrivint al mateix fitxer simultàniament podien corrompre les dades.
Absència de control d'accés: Era difícil restringir quines parts de les dades podia veure cada usuari.
Sense mecanismes de recuperació: Una interrupció sobtada podia deixar els fitxers en un estat inconsistent.

Els SGBD van néixer per resoldre exactament aquests problemes, abstraient la complexitat de la persistència i proporcionant una interfície unificada (SQL, en el cas dels relacionals) per interactuar amb les dades.

1.2 Components principals d'un SGBD

Un SGBD modern és un sistema complex format per diversos subsistemes que cooperen:

graph TD
    subgraph App["Usuaris i Aplicacions"]
        U1[Aplicacio web]
        U2[Client SQL]
        U3[Administracio]
    end

    subgraph Motor["SGBD"]
        PA[Query Parser] --> OPT[Query Optimizer]
        OPT --> EX[Execution Engine]
        EX --> TM[Transaction Manager]
        TM --> LM[Lock Manager]
        EX --> BM[Buffer Manager]
        BM --> SE[Storage Engine]
    end

    subgraph Disc["Emmagatzematge"]
        DF[Fitxers de dades]
        WF[WAL - Redo Log]
        IX[Indexos]
    end

    App --> PA
    SE --> Disc

    classDef app fill:#e8f5e9,stroke:#388e3c,color:#000
    classDef sgbd fill:#e0f2f1,stroke:#00897b,color:#000
    classDef disc fill:#fce4ec,stroke:#c62828,color:#000
    class U1,U2,U3 app
    class PA,OPT,EX,TM,LM,BM,SE sgbd
    class DF,WF,IX disc

2. Arquitectura ANSI/SPARC

L'any 1975, l'organisme de normalització ANSI (American National Standards Institute), a través del seu comitè SPARC (Standards Planning and Requirements Committee), va proposar una arquitectura de tres nivells per als sistemes de bases de dades. Aquesta arquitectura, coneguda com a model ANSI/SPARC, continua sent la referència teòrica fonamental dels SGBD moderns i és la base per entendre la independència de dades.

2.1 Els tres nivells

graph TD
    subgraph Ext["Nivell Extern - Vistes"]
        V1[Vista Vendes]
        V2[Vista RRHH]
        V3[Vista Aplicacio]
    end

    subgraph Con["Nivell Conceptual - Esquema logic"]
        ES[Esquema conceptual\nTaules, relacions, restriccions]
    end

    subgraph Int["Nivell Intern - Fisic"]
        FI[Esquema intern\nFitxers, indexos, pagines, blocs]
    end

    Ext -->|Mapeig extern-conceptual| Con
    Con -->|Mapeig conceptual-intern| Int

    classDef ext fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef con fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef int fill:#fff8e1,stroke:#f57f17,color:#000
    class V1,V2,V3 ext
    class ES con
    class FI int

Nivell extern (o de vistes): És la capa més propera a l'usuari final. Cada usuari o aplicació veu únicament la part de les dades que li és rellevant, a través d'una vista personalitzada. Dos usuaris del mateix SGBD poden tenir visions completament diferents de les mateixes dades subjacents. Aquí és on el DBA defineix les vistes de seguretat i aplica les restriccions d'accés.

Nivell conceptual (o lògic): És la representació global i unificada de totes les dades de l'organització, independent de com s'emmagatzemen físicament. Descriu quines entitats existeixen, quins atributs tenen i com es relacionen entre elles. En un SGBD relacional, aquest nivell es correspon amb les taules, columnes, claus primàries i foranes, i restriccions d'integritat.

Nivell intern (o físic): Descriu com les dades s'emmagatzemen realment al disc: en quins fitxers, amb quin format de pàgina, quins índexos existeixen, com s'organitzen els registres. Aquest nivell és gestionat íntegrament pel motor del SGBD i és transparent per a l'usuari.

2.2 Independència de dades

La separació en tres nivells permet dos tipus d'independència de dades:

Independència lògica: Podem modificar l'esquema conceptual (afegir columnes, canviar relacions) sense que les aplicacions que usen les vistes del nivell extern hagin de canviar.
Independència física: Podem canviar l'organització física de les dades (canviar d'índex, moure fitxers, canviar el format d'emmagatzematge) sense que l'esquema conceptual ni les aplicacions es vegin afectades.

3. Tipus de Sistemes Gestors de Bases de Dades

Tot i que el model relacional domina el mercat des dels anys 80, existeixen diversos paradigmes d'SGBD, cadascun optimitzat per a casos d'ús específics.

3.1 SGBD relacionals (RDBMS)

Els SGBD relacionals organitzen les dades en taules (relacions), amb files (tuples) i columnes (atributs). Utilitzen SQL (Structured Query Language) com a llenguatge estàndard de consulta i manipulació. Implementen les propietats ACID (Atomicitat, Consistència, Aïllament, Durabilitat) i gestionen la integritat referencial mitjançant claus foranes.

Exemples: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle Database, SQLite, IBM Db2.

Casos d'ús: Aplicacions transaccionals (banca, e-commerce, ERP, CRM), sistemes on la consistència de les dades és crítica.

3.2 SGBD NoSQL

Els SGBD NoSQL van aparèixer a principis dels anys 2000 per respondre a les limitacions dels RDBMS davant de volums massius de dades i estructures no tabulars. El terme "NoSQL" significa habitualment "Not Only SQL" i engloba quatre grans categories:

Categoria	Descripció	Exemples
Clau-valor	Estructura simplíssima: cada element és un parell clau-valor. Molt ràpid per a caches.	Redis, DynamoDB, Memcached
Document	Emmagatzema documents semi-estructurats (JSON, BSON). Flexible, sense esquema fix.	MongoDB, CouchDB, Firestore
Columnar	Organitza les dades per columnes, no per files. Excel·lent per a analítica i OLAP.	Cassandra, HBase, ClickHouse
Graf	Les dades són nodes i arestes d'un graf. Ideal per a xarxes socials i recomanadors.	Neo4j, Amazon Neptune, ArangoDB

3.3 SGBD NewSQL

Els SGBD NewSQL intenten combinar la consistència ACID dels SGBD relacionals amb l'escalabilitat horitzontal dels NoSQL. Estan dissenyats per a entorns de núvol i càrregues de treball OLTP massives.

Exemples: Google Spanner, CockroachDB, TiDB, YugabyteDB.

3.4 SGBD de sèries temporals

Optimitzats per emmagatzemar i consultar dades indexades pel temps, com ara mètriques de monitoratge, logs o dades de sensors IoT.

Exemples: InfluxDB, TimescaleDB (extensió de PostgreSQL), Prometheus, OpenTSDB.

4. Comparativa dels quatre motors principals

Al llarg d'aquest mòdul treballarem amb els quatre SGBD relacionals més presents al mercat professional. A continuació, una comparativa detallada:

4.1 Taula comparativa

Característica	PostgreSQL 17	MySQL 8.4 LTS	SQL Server 2025	Oracle Database
Tipus	RDBMS Open Source	RDBMS Open Source	RDBMS Propietari	RDBMS Propietari
Llicència	PostgreSQL License (permissiva)	GPL v2 / GPL v2	Propietari (Microsoft)	Propietari (Oracle Corp.)
Primera versió	1989 (POSTGRES)	1995 / 2009	1989	1979
Mida màx. BD	Il·limitada (pràctica: PB)	64 TB (InnoDB)	524 PB	Il·limitada (pràctica: PB)
Mida màx. taula	32 TB	64 TB	524 PB	Il·limitada
Mida màx. fila	1,6 GB	65.535 bytes	8.060 bytes	Il·limitada
ACID complet	Sí	Sí (InnoDB)	Sí	Sí
Procediments	PL/pgSQL, PL/Python, PL/Perl...	SQL/PSM	T-SQL	PL/SQL
Particionament	Natiu (v10+)	Natiu	Natiu	Natiu (avançat)
Replicació	Streaming, Logical	Async, Semi-sync, Group	Always On AG, Mirroring	Data Guard, RAC
JSON nadiu	Sí (JSONB indexable)	Sí (JSON)	Sí (JSON)	Sí (JSON)
Extensions	PostGIS, pgvector, TimescaleDB...	Limitades	Limitades	Oracle Spatial, Text...
Cost	Gratuït	Gratuït (Community)	Des de ~1.400€/core	Des de ~10.000€/core
Comunitat	Molt activa	Molt activa (MySQL+MariaDB)	Activa (Microsoft suport)	Corporativa (Oracle suport)

4.2 Posicionament al mercat

graph LR
    subgraph Quad["Cost vs Funcionalitat"]
        PG["PostgreSQL<br/>Open Source · Alta funcionalitat<br/>Cost: Baix"]
        MY["MySQL / MariaDB<br/>Open Source · Funcionalitat mitjana<br/>Cost: Baix"]
        SS["SQL Server<br/>Propietari · Alta funcionalitat<br/>Cost: Mitja-Alt"]
        OR["Oracle<br/>Propietari · Funcionalitat maxima<br/>Cost: Alt"]
    end
    PG --- SS
    MY --- OR
    classDef os fill:#e8f5e9,stroke:#388e3c,color:#000
    classDef prop fill:#fce4ec,stroke:#c62828,color:#000
    class PG,MY os
    class SS,OR prop

4.3 Quan triar cada motor?

PostgreSQL és la millor opció quan:

Necessitem funcionalitats SQL avançades (CTE recursives, window functions, arrays, JSON/JSONB).
Volem una solució open source sense limitacions de llicència.
El projecte té requisits de dades geoespacials (PostGIS).
Necessitem extensions com vectors d'IA (pgvector) o sèries temporals (TimescaleDB).
El pressupost és limitat però la robustesa és crítica.

MySQL / MariaDB és la millor opció quan:

L'aplicació és una pila LAMP (Linux, Apache, MySQL, PHP) estàndard.
Necessitem compatibilitat amb sistemes existents basats en MySQL.
Volem MariaDB per les seves funcionalitats addicionals i millor rendiment en lectura.
El cas d'ús principal és servir aplicacions web amb moltes lectures (WordPress, Magento, Drupal).

SQL Server és la millor opció quan:

L'entorn és predominantment Microsoft (.NET, Windows Server, Active Directory).
Cal integrar amb eines Microsoft (Power BI, SSRS, SSIS, Azure).
L'organització ja té llicències Microsoft (SA — Software Assurance).
Necessitem eines de BI i reporting integrades de forma nativa.

Oracle Database és la millor opció quan:

L'empresa té un ERP SAP o aplicació Oracle (E-Business Suite, Fusion).
Necessitem les funcionalitats més avançades: Oracle RAC, Data Guard, Advanced Security.
El SLA és extrem (99,999% disponibilitat) i hi ha pressupost per a suport Enterprise.
La base de codi existent és PL/SQL i la migració seria inassolible.

5. El rol de l'Administrador/a de Bases de Dades (DBA)

L'administrador/a de bases de dades (DBA, Database Administrator) és el professional responsable de la instal·lació, configuració, seguretat, rendiment i disponibilitat dels SGBD d'una organització. Les seves responsabilitats inclouen:

Disseny i manteniment de l'esquema: Crear i modificar taules, índexos, vistes i restriccions.
Gestió de la seguretat: Crear usuaris, assignar rols i auditar accessos.
Monitoratge del rendiment: Detectar consultes lentes, analitzar plans d'execució i optimitzar.
Backup i recuperació: Dissenyar i implementar estratègies de còpia de seguretat.
Alta disponibilitat: Configurar replicació, failover automàtic i balanceig de càrrega.
Actualitzacions i pegats: Mantenir el motor actualitzat sense interrompre el servei.
Capacity planning: Preveure el creixement de les dades i planejar l'escalada.

DBA vs Desenvolupador de BD

Un DBA se centra en l'administració i operació del motor (infraestructura de dades), mentre que un desenvolupador de bases de dades (Database Developer) se centra en el disseny d'esquemes i l'escriptura de consultes SQL complexes i procediments. En empreses petites, sovint un sol perfil fa ambdues tasques.

6. Questionari inicial

Questionari inicial — Comprovació de coneixements previs

Respon les preguntes següents per identificar els teus coneixements de partida. No puntuen, però t'ajudaran a detectar on cal aprofundir.

Quina diferència hi ha entre una base de dades i un sistema gestor de bases de dades?
Quin és l'objectiu principal de l'arquitectura ANSI/SPARC?
Explica amb les teves paraules la diferència entre independència lògica i física de dades.
Quines propietats ACID coneixes? Explica breument cadascuna.
Què significa que un SGBD és "transaccional"?
Quin és el principal avantatge dels SGBD NoSQL sobre els relacionals?
En quin cas triaries un SGBD de documents (com MongoDB) per sobre d'un relacional?
Quin motor de bases de dades és el més utilitzat en aplicacions web de tipus WordPress/Drupal i per què?
Quina diferència hi ha entre MySQL i MariaDB?
Quin és el llenguatge de programació procedural de PostgreSQL? I el d'Oracle?
Quines eines gràfiques coneixes per administrar bases de dades?
Què és un pla d'execució i per a què serveix?
Explica la diferència entre una clau primària i una clau forana.
Quin problema resol un índex a una taula de base de dades? Quin és el seu cost?
Explica amb les teves paraules quin és el paper d'un DBA en una empresa.

7. Miniactivitat — AC0101

Miniactivitat — AC0101 · Investigació inicial

Objectiu: Familiaritzar-se amb els principals SGBD i les seves comunitats.

Tasques:

Accedeix a db-engines.com/en/ranking i anota el rànquing actual dels quatre motors que treballarem (PostgreSQL, MySQL, SQL Server, Oracle). Ha canviat molt respecte a fa 5 anys?
Consulta el lloc oficial de cada motor i apunta la versió estable actual:
Busca tres ofertes de feina reals (Infojobs, LinkedIn, Tecnoempleo) que demanin experiència en administració de bases de dades. Quin motor és el més demanat? Quines eines s'hi mencionen?
Comparteix els resultats amb la resta de la classe i construïu conjuntament una taula comparativa a la pissarra digital.

Temps estimat: 30 minuts.