Salta el contingut

Sistemes basats en fitxers

Abans que existissin els sistemes gestors de bases de dades, les organitzacions emmagatzemaven la informació en fitxers. Entendre com funcionen aquests sistemes i quines eren les seves limitacions és essencial per comprendre per què es van crear els SGBD i quins problemes resolen.

Concepte de fitxer

Un fitxer és una seqüència de números binaris que organitza informació relacionada a un mateix aspecte, emmagatzemada en un suport físic (disc dur, cinta magnètica, memòria) i identificada per un nom.

Un fitxer conté registres (estructures lògiques que agrupen dades sobre una mateixa entitat) i cada registre conté camps (unitats elementals d'informació). Per exemple, un fitxer d'alumnes amb 10.000 registres té 10.000 entrades individuals.

Fitxer CLIENTS.dat — vista lògica:

Registre ID_CLIENT NOM TELEFON CIUTAT
Registre 1 001 Maria Puig 972 123 456 Girona
Registre 2 002 Joan Mas 93 456 789 Barcelona
Registre 3 003 Anna Soler 977 654 321 Tarragona 
flowchart TB
    subgraph logic["CLIENTS.dat — Vista lògica"]
        R1["Registre 1\n001 · Maria Puig · 972 123 456 · Girona"]
        R2["Registre 2\n002 · Joan Mas · 93 456 789 · Barcelona"]
        R3["Registre 3\n003 · Anna Soler · 977 654 321 · Tarragona"]
        R1 --- R2 --- R3
    end

    subgraph disc["Disc dur — Vista física  (Cilindre 3, Pista 1)"]
        S1["Sector 1  ·  512 bytes\n001 · Maria Puig · 972 123 456 · Girona"]
        S2["Sector 2  ·  512 bytes\n002 · Joan Mas · 93 456 789 · Barcelona"]
        S3["Sector 3  ·  512 bytes\n003 · Anna Soler · 977 654 321 · Tarragona"]
        S1 --- S2 --- S3
    end

    R1 -->|"s'emmagatzema a"| S1
    R2 --> S2
    R3 --> S3

    style logic fill:#1e3a5f,color:#e2e8f0,stroke:#3b82f6
    style disc fill:#1a2e1a,color:#e2e8f0,stroke:#22c55e
    style R1 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style R2 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style R3 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style S1 fill:#166534,color:#ffffff,stroke:#22c55e
    style S2 fill:#166534,color:#ffffff,stroke:#22c55e
    style S3 fill:#166534,color:#ffffff,stroke:#22c55e

Tipus de fitxers per format

Una primera classificació dels fitxers es fa pel seu format intern:

Fitxers de text

El contingut és llegible directament per un ésser humà amb qualsevol editor. Els caràcters s'emmagatzemen en codificacions com ASCII o UTF-8.

Exemples: .txt, .ini, .html, .csv, .json, .xml

Avui en dia, formats com CSV, JSON i XML s'utilitzen massivament com a formats d'intercanvi de dades entre sistemes.

Fitxers binaris

El contingut no és llegible directament; requereix programari específic per interpretar-lo. La informació s'emmagatzema de manera compacta i eficient.

Exemples: .jpg, .mp3, .zip, .parquet, .avro

Formats com Parquet i Avro s'usen en pipelines de Big Data per emmagatzemar grans volums de dades estructurades de manera molt eficient.

Formats d'intercanvi moderns

CSV, JSON i XML han sobreviscut a l'era dels SGBD perquè resolen un problema diferent: transferir dades entre sistemes heterogenis. Quan exportes dades d'una base de dades a un full de càlcul o envies dades a una API externa, probablement usaràs un d'aquests formats.

Tipus de fitxers segons la funció

Fitxers mestres

Contenen informació permanent o semipermanent sobre les entitats principals del sistema. S'actualitzen periòdicament i representen l'estat actual.

Exemples: fitxer de clients, fitxer d'empleats, fitxer d'articles d'inventari.

Fitxers de moviments (transaccionals)

Contenen els canvis que s'han produït en un període determinat. Serveixen per actualitzar el fitxer mestre i solen tenir vida curta (un dia, una setmana).

Exemples: comandes del dia, factures del mes, moviments bancaris de la jornada.

Fitxers d'historial

Arxiven les dades antigues per a consulta posterior o auditoria. No s'actualitzen; creixen de manera acumulativa.

Exemples: historial de vendes dels darrers 5 anys, registre de canvis de preu.

Fitxers de taula o referència

Contenen dades de suport que s'utilitzen per a càlculs o validacions. Canvien rarament.

Exemples: taula de codis postals, taula de tipus d'IVA, taula de països.

Fitxers de treball (temporals)

Es creen durant el processament i s'eliminen un cop acabada l'operació. S'utilitzen com a suport intermedi.

Exemples: fitxer d'ordenació temporal, resultat parcial d'una fusió.

Operacions sobre fitxers

Independentment de l'organització, sobre qualsevol fitxer es poden realitzar les operacions bàsiques següents:

Operació Descripció
Obrir / tancar Estableix i allibera el canal d'accés entre el programa i el fitxer
Llegir Obté el valor d'un o més registres del fitxer
Escriure Afegeix o modifica registres al fitxer
Posicionament Mou el punter de lectura/escriptura a un registre concret
Fragmentació / compactació Gestiona l'espai buit generat per les eliminacions
Compressió Redueix la mida del fitxer per estalviar espai d'emmagatzematge
Xifratge Protegeix el contingut del fitxer davant accessos no autoritzats

Fragmentació

Quan s'eliminen registres d'un fitxer, l'espai que ocupaven queda buit però no és reutilitza automàticament. Amb el temps, el fitxer es fragmenta i el rendiment es degrada. La compactació és el procés de reorganitzar el fitxer per eliminar aquests forats. En els SGBD moderns, aquest procés es gestiona automàticament (VACUUM a PostgreSQL, OPTIMIZE TABLE a MySQL).

Organitzacions de fitxers

L'organització d'un fitxer determina com s'emmagatzemen físicament els registres al suport i, per tant, com s'hi pot accedir.

Organització seqüencial

Els registres s'emmagatzemen en ordre d'arribada, un darrere l'altre. Per trobar un registre concret cal recórrer tots els anteriors. Històricament era l'única opció amb cintes magnètiques.

Existeixen dues variants de fitxers seqüencials:

Seqüencial encadenat: cada registre conté un punter a l'adreça del registre següent. Permet una certa flexibilitat en l'ordenació lògica sense moure físicament els registres.

flowchart LR
    subgraph fisic["Ordre físic al fitxer"]
        direction LR
        R1["R1<br/>ptr → R3"]
        R2["R2<br/>ptr → null"]
        R3["R3<br/>ptr → R2"]
    end
    R1 -.->|"punter"| R3
    R3 -.->|"punter"| R2

    style fisic fill:#1e3a5f,color:#e2e8f0,stroke:#3b82f6
    style R1 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style R2 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style R3 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6

Ordre físic: R1, R2, R3. Ordre lògic (seguint els punters): R1 → R3 → R2.

Seqüencial indexat: estructura de doble zona — una zona de dades seqüencial i una zona d'índex separada que funciona com un índex de continguts, permetent localitzar registres sense recórrer tot el fitxer.

flowchart LR
    subgraph index["Zona d'índex"]
        direction TB
        I1["Clau 001 → Pos 0"]
        I2["Clau 050 → Pos 49"]
        I3["Clau 100 → Pos 99"]
    end
    subgraph dades["Zona de dades (seqüencial)"]
        direction TB
        D0["Pos 0-48"]
        D49["Pos 49-98"]
        D99["Pos 99-..."]
    end
    I1 --> D0
    I2 --> D49
    I3 --> D99

    style index fill:#1e3a5f,color:#e2e8f0,stroke:#3b82f6
    style dades fill:#1a2e1a,color:#e2e8f0,stroke:#22c55e
    style I1 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style I2 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style I3 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style D0 fill:#166534,color:#ffffff,stroke:#22c55e
    style D49 fill:#166534,color:#ffffff,stroke:#22c55e
    style D99 fill:#166534,color:#ffffff,stroke:#22c55e
Avantatge Inconvenient
Simple d'implementar Accés lent (cal llegir des del principi)
Aprofita bé la cinta magnètica Inserció i eliminació costoses
Adequat per a processament per lots No permet accés directe pur

Quan s'usa: processament per lots (batch), còpies de seguretat, generació d'informes.

Organització directa o aleatòria (hash)

La posició física del registre es calcula a partir d'una funció de dispersió (hash) aplicada a la clau del registre. Permet accedir directament a qualsevol registre sense recórrer els anteriors.

flowchart LR
    A["Clau"] -->|"funció_hash(clau)"| B["Posició física"] --> C["Registre"]

    style A fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style B fill:#7c3aed,color:#ffffff,stroke:#a78bfa
    style C fill:#166534,color:#ffffff,stroke:#22c55e
Avantatge Inconvenient
Accés molt ràpid per clau Pot haver col·lisions (dues claus → mateixa posició)
Adequat per a consultes puntuals No permet accés seqüencial ordenat
Inserció ràpida La funció hash s'ha de dissenyar bé

Quan s'usa: taules de cerca, fitxers d'índex, operacions de consulta puntual per clau.

Organització indexada (ISAM)

Combina l'accés seqüencial i el directe. El fitxer conté les dades en ordre seqüencial i un índex separat que mapeja les claus a les posicions físiques.

flowchart LR
    subgraph index["Índex"]
        direction TB
        I1["001 → Pos 0"]
        I2["002 → Pos 1"]
        I3["003 → Pos 2"]
    end
    subgraph dades["Fitxer de dades"]
        direction TB
        D0["Pos 0: 001, Maria, Girona"]
        D1["Pos 1: 002, Joan, Barcelona"]
        D2["Pos 2: 003, Anna, Tarragona"]
    end
    I1 --> D0
    I2 --> D1
    I3 --> D2

    style index fill:#1e3a5f,color:#e2e8f0,stroke:#3b82f6
    style dades fill:#1a2e1a,color:#e2e8f0,stroke:#22c55e
    style I1 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style I2 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style I3 fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style D0 fill:#166534,color:#ffffff,stroke:#22c55e
    style D1 fill:#166534,color:#ffffff,stroke:#22c55e
    style D2 fill:#166534,color:#ffffff,stroke:#22c55e
Avantatge Inconvenient
Accés ràpid per clau (via índex) L'índex ocupa espai addicional
Accés seqüencial possible L'índex s'ha de mantenir actualitzat
Adequat per a grans volums rendiment degradat amb moltes insercions/esborrats

Quan s'usa: aplicacions de gestió clàssiques (comptabilitat, nòmines), arxius grans amb consultes variades.

Organització seqüencial indexada (VSAM)

Evolució de l'ISAM, molt usada en sistemes IBM mainframe. Utilitza una estructura d'índex en arbre (B-tree) que és manté equilibrat automàticament, evitant la degradació del rendiment en fitxers amb moltes modificacions.

Mètodes d'accés

L'organització del fitxer condiciona els mètodes d'accés disponibles:

Organització Accés seqüencial Accés directe Accés per índex
Seqüencial Sí No No
Directa (hash) Possible (ineficient) Sí No
Indexada (ISAM/VSAM) Sí Sí Sí

Limitacions dels sistemes basats en fitxers

Els sistemes de fitxers van ser adequats durant dècades, però presentaven problemes greus que van motivar la creació dels SGBD.

1. Acoblament físic-lògic (dependència dades-programes)

Cada aplicació estava íntimament lligada a l'estructura física dels fitxers que feia servir. Si es canviava el format d'un fitxer (per exemple, s'afegía un camp nou), calia modificar tots els programes que hi accedien. Això feia que compartir dades entre aplicacions fos pràcticament impossible i que qualsevol canvi fos costosíssim.

flowchart LR
    A["Aplicació A"] --> FA["fitxer_clients_A.dat<br/>(format propi)"]
    B["Aplicació B"] --> FB["fitxer_clients_B.dat<br/>(format diferent!)"]
    C["Aplicació C"] --> FC["fitxer_clients_C.dat<br/>(format diferent!)"]

    style A fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style B fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style C fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
    style FA fill:#6b7280,color:#ffffff,stroke:#4b5563
    style FB fill:#6b7280,color:#ffffff,stroke:#4b5563
    style FC fill:#6b7280,color:#ffffff,stroke:#4b5563

Cap de les tres aplicacions pot llegir les dades de les altres.

2. Redundància i inconsistència de dades

Cada aplicació tenia els seus propis fitxers. La mateixa informació (p. ex., l'adreça d'un client) apareixia duplicada en múltiples fitxers, amb el risc que s'actualitzés en un lloc però no en un altre.

Fitxer Adreça del client 001
fitxer_vendes.dat Carrer Major 5, Blanes
fitxer_factures.dat Carrer Major 7, Blanes — inconsistent!

3. Dificultat per accedir a les dades

Cada nova consulta requeria escriure un nou programa. No existia un llenguatge de consulta estàndard; calia codi específic per a cada accés. Obtenir una llista de clients de Girona que haguessin comprat el mes passat implicava dies de programació.

4. Aïllament de dades

Les dades estaven disperses en formats heterogenis. Relacionar informació de fitxers diferents era complex i propens a errors.

5. Problemes d'integritat

Era difícil garantir restriccions com "l'edat d'un empleat ha de ser entre 16 i 70 anys". Calia escriure codi de validació en cada programa que hi accedís, sense garantia que tots els programes ho fessin.

6. Problemes d'atomicitat

Si una operació fallava a mig fer (p. ex., transferència bancària: s'ha deduït l'import del compte origen però no s'ha afegit al compte destí), no hi havia mecanisme automàtic per tornar enrere els canvis parcialment aplicats.

7. Anomalies d'accés concurrent

Quan dos programes llegien i escrivien el mateix fitxer simultàniament, les dades podien corrompre's sense mecanismes de control d'accés concurrent.

8. Problemes de seguretat

Els sistemes de fitxers oferien control d'accés molt bàsic (lectura/escriptura a nivell de fitxer sencer). No era possible restringir l'accés a camps o registres concrets (p. ex., que un empleat pugui veure el nom dels col·legues però no el salari).

De fitxers a bases de dades

flowchart LR
    A["Sistemes de<br/>fitxers tradicionals<br/>(anys 50-60)"]
    B["SGBD jeràrquics<br/>i en xarxa<br/>(anys 60-70)"]
    C["SGBD relacionals<br/>(anys 70-90)"]
    D["SGBD actuals<br/>+ NoSQL<br/>(anys 2000-)"]

    A -->|"Redundancia,<br/>acoblament"| B
    B -->|"Complexitat,<br/>rigidesa"| C
    C -->|"Escalabilitat,<br/>Big Data"| D

    style A fill:#6b7280,color:#fff,stroke:#4b5563
    style B fill:#3b82f6,color:#fff,stroke:#2563eb
    style C fill:#1d4ed8,color:#fff,stroke:#1e40af
    style D fill:#312e81,color:#fff,stroke:#1e1b4b

Els Sistemes Gestors de Bases de Dades (SGBD) van néixer precisament per resoldre totes aquestes limitacions. Una base de dades es pot definir com un conjunt de dades interrelacionades, amb característiques d'integritat i redundància mínima, accessibles per diversos usuaris i aplicacions.

Avantatges del SGBD respecte als fitxers

Problema del fitxer Solució del SGBD
Acoblament físic-lògic Independència dades-programes (3 nivells ANSI/SPARC)
Redundància Disseny normalitzat (una sola font de veritat)
Inconsistència Restriccions d'integritat referencial
Accés complex Llenguatge SQL estàndard
Atomicitat Transaccions (propietats ACID)
Concurrència Gestió de bloquejos i MVCC
Seguretat Control d'accés granular (usuari, taula, columna, fila)
Documentació Catàleg del sistema (metadades)

Desavantatges del SGBD

L'adopció d'un SGBD també té costos que cal considerar:

  • Cost d'instal·lació i llicències elevat per a productes comercials (Oracle, SQL Server)
  • Requereix personal qualificat (DBA) per a la instal·lació, configuració i manteniment
  • Implementació llarga i costosa: migrar dades de fitxers a un SGBD és un projecte complex
  • Manca d'estàndards universals: tot i que SQL és estàndard, cada SGBD té extensions i comportaments propis

AC0372/01/01 — Miniactivitat

RA1 · CA1.1, CA1.4

Pensa en una empresa de comerç electrònic que gestiona les comandes amb fitxers separats per a clients, productes i comandes. Identifica almenys 3 problemes concrets que podrien sorgir amb aquest enfocament i com els resoldria un SGBD.

Avui en dia

Tot i que els SGBD han substituït els sistemes de fitxers per a la gestió de dades estructurades, els fitxers segueixen presents: CSV, JSON, XML i Parquet s'usen com a formats d'intercanvi i en pipelines de dades (ETL). La diferència és que ara els gestiona un SGBD o un motor analític, no programes ad-hoc.

Confusió habitual

El sistema de fitxers del sistema operatiu (NTFS, ext4, APFS) no és el que estem descrivint aquí. Els SGBD també usen el sistema de fitxers del SO per emmagatzemar físicament les dades, però ofereixen una capa d'abstracció molt superior per damunt.