Salta el contingut

Models de dades

Què és un model de dades?

Un model de dades és un conjunt de conceptes, regles i notacions que permeten descriure l'estructura d'una base de dades: quines dades s'emmagatzemen, com s'organitzen i quines relacions existeixen entre elles. El model de dades determina com els usuaris i les aplicacions perceben les dades i com el SGBD les gestiona internament.

Al llarg de la història de la informàtica han aparegut diversos models de dades, cadascun com a resposta a les limitacions dels anteriors o per respondre a nous tipus de problemes.

Model jeràrquic

El model jeràrquic va ser el primer model de BD estructurat, popularitzat pel sistema IMS (Information Management System) d'IBM el 1968, usat per la NASA per a la missió Apollo.

En aquest model, les dades s'organitzen en una estructura d'arbre: cada node (registre) te un pare (excepte l'arrel) i pot tenir múltiples fills. Les relacions són sempre 1:N de pare a fill.

flowchart TD
    D["Departament: Informàtica"]
    D --> E1["Empleat: Ana Garcia"]
    D --> E2["Empleat: Pere Bosch"]
    E1 --> P1["Projecte: Web corporativa"]
    E1 --> P2["Projecte: App mobil"]
    E2 --> P3["Projecte: Migració BD"]

Avantatges: - Molt eficient per a consultes que segueixen la jerarquia de dalt a baix. - Model simple de comprendre.

Limitacions: - Dificultat per representar relacions M:N (molts a molts). - Redundancia de dades quan un fill te múltiples pares. - Poca flexibilitat davant canvis en l'estructura.

AC0372/01/02 — Miniactivitat

RA1 · CA1.2

Intenteu representar en un model jeràrquic la relació "un alumne pot estar matriculat a múltiples assignatures i una assignatura pot tenir múltiples alumnes". Quins problemes trobeu?

Model en xarxa (network model)

El model en xarxa (CODASYL, anys 70) va ser dissenyat per superar les limitacions del model jeràrquic. En comptes d'arbres, usa un graf: els registres es connecten entre si per "sets" (conjunts), i un registre pot tenir múltiples pares.

flowchart LR
    A["Alumne: Joan"] --> P1["Assignatura: Matematiques"]
    A --> P2["Assignatura: física"]
    B["Alumne: Maria"] --> P1
    B --> P3["Assignatura: Quimica"]

Avantatges: - Permet relacions M:N de forma nativa. - Bon rendiment per a navegació de dades relacionades.

Limitacions: - Molt complex per a l'usuari: cal navegar explicitament pels apuntadors. - El codi de les aplicacions esta molt acoblat a l'estructura de la BD. - Dificultat per fer consultes ad-hoc.

Model relacional

El model relacional va ser proposat per Edgar F. Codd (IBM) en el seu article "A Relational Model of Data for Large Shared Data Banks" (1970). Va representar una revolució conceptual: en lloc de navegar per apuntadors, les dades s'organitzen en taules (relacions) i es consulten amb un llenguatge declaratiu (SQL) on l'usuari especifica que vol, no com obtenir-ho.

Conceptes clau del model relacional

  • Relació (taula): Un conjunt de tuples (files) amb els mateixos atributs (columnes).
  • Tupla (fila): Un registre individual que representa una entitat del món real.
  • Atribut (columna): Una propietat de les entitats descrites per la taula.
  • Domini: El conjunt de valors vàlids per a un atribut (INTEGER, VARCHAR(50), DATE, etc.).
  • Clau primària: Un atribut o conjunt d'atributs que identifica unívocament cada tupla.
  • Clau forana: Un atribut que referencía la clau primaria d'una altra taula, establint la relació entre elles.
erDiagram
    CLIENTS {
        int id_client PK
        varchar nom
        varchar email
        date data_alta
    }
    COMANDES {
        int id_comanda PK
        int id_client FK
        date data_comanda
        decimal total
    }
    CLIENTS ||--o{ COMANDES : "realitza"

Avantatges:

  • independència de les dades respecte les aplicacions.
  • Consultes ad-hoc flexibles amb SQL.
  • Fonament matemàtic solid (àlgebra relacional).
  • Suport per a la integritat de les dades.
  • Gran ecosistema d'eines i professionals.

Limitacions:

  • rendiment limitat per a certes operacions (grafs, documents JSON profunds, grans volums en write-heavy).
  • Impedance mismatch amb la programació orientada a objectes.
  • Escalabilitat horitzontal complex (sharding).

Model orientat a objectes

A finals dels anys 80 i principis dels 90, amb l'auge de la programació orientada a objectes (OOP), van aparèixer els SGBD orientats a objectes (OODB), com ObjectStore o GemStone. L'objectiu era eliminar el "desajust d'impedància" (impedance mismatch) entre el model relacional i el model d'objectes dels llenguatges com C++ o Java.

En un model orientat a objectes:

  • Les dades s'emmagatzemen com objectes amb atributs i mètodes.
  • Es suporta l'herència: una classe pot heretar atributs d'una classe pare.
  • Les relacions es representen com referències entre objectes.

Tot i que els OODB purs no van triomfar (la complexitat per als administradors i la manca d'un estàndard clar hi van contribuir), els conceptes han perviscut en els SGBD objecte-relacionals (PostgreSQL, Oracle) que permeten definir tipus de dades personalitzats i herència de taules.

Model document (NoSQL)

Els sistemes NoSQL de documents emmagatzemen les dades com a documents semiestructurats, normalment en format JSON o BSON. Cada document pot tenir una estructura diferent i pot contenir documents niuats (nested).

{
  "id": "client_001",
  "nom": "Joan Garcia",
  "adreca": {
    "carrer": "Carrer Major, 15",
    "poblacio": "Blanes",
    "cp": "17300"
  },
  "comandes": [
    {"id_comanda": "C001", "total": 125.50, "data": "2025-10-01"},
    {"id_comanda": "C002", "total": 89.90, "data": "2025-11-15"}
  ]
}

Exemples: MongoDB, CouchDB, Elasticsearch, Firebase.

Avantatges:

  • Flexibilitat d'esquema: els documents no han de tenir la mateixa estructura.
  • Escalabilitat horitzontal nativa.
  • Adequat per a dades poc estructurades o amb estructura variable.
  • rendiment elevat en lectures i escriptures simples.

Limitacions:

  • Sense transaccions ACID completes (alguns sistemes moderns les suporten parcialment).
  • Consultes complexes (JOINs) són costoses o impossibles nativament.
  • Risc de dades inconsistents si no és gestiona be.

Altres models NoSQL

Model Concepte clau Exemples Cas d'us típic
Clau-valor Diccionari simple: clau → valor Redis, DynamoDB Cache, sessions, comptadors
Columnar Dades organitzades per columnes, no per files Cassandra, HBase, BigTable Analítica de big data, sèries temporals
Graf Nodes i arestes amb propietats Neo4j, Amazon Neptune Xarxes socials, recomanacions, frau
Sèries temporals Dades indexades pel temps InfluxDB, TimescaleDB IoT, monitoratge, mètriques

Com triar el model?

No hi ha un model universalment superior. La tria depèn del tipus de dades, dels patrons de consulta, dels requisits de consistència i de la mida de l'equip. Per a la majoria d'aplicacions empresarials convencionals, el model relacional continua sent la millor opció.

AC0372/01/03 — Miniactivitat

RA1 · CA1.2, CA1.3

Per a cadascun dels escenaris següents, identifiqueu quin model de dades seria més adequat i justifiqueu-ho:

  1. Sistema de gestió d'una escola (alumnes, assignatures, professors, notes).
  2. Plataforma de xarxa social (amics d'amics, recomanacions).
  3. Sistema de monitoratge de sensors IoT que registra temperatura cada segon.
  4. Cataleg de productes d'una botiga en línia on cada producte te atributs molt diferents (un ordinador te CPU/RAM, una samarreta te talla/color).
  5. Sistema de cache d'una aplicació web d'alta concurrència.