Database relazionali: come tabelle, righe e chiavi organizzano i dati

Cos’è, in pratica, una tabella

Secondo la documentazione ufficiale di PostgreSQL, una tabella è un insieme di righe identificato da un nome, e ogni riga condivide lo stesso insieme di colonne, ciascuna con un tipo di dato preciso. Una tabella clienti ha quindi una riga per ogni cliente, con colonne come nome, indirizzo e codice fiscale; una tabella ordini ha una riga per ogni ordine, con colonne come data, importo e il cliente che l’ha fatto. Le tabelle di un’applicazione si raggruppano in un database vero e proprio, gestito da un DBMS come PostgreSQL o MySQL.

Esempio pratico: un negozio online tiene due tabelle, clienti e ordini. La tabella clienti ha una riga per ogni persona, con colonne come nome ed email. La tabella ordini ha una riga per ogni acquisto, con colonne come data, importo e una colonna che indica di chi è quell’ordine. Quella colonna contiene l’identificativo del cliente: basta quello per risalire al resto dei suoi dati.

Le chiavi che tengono insieme i dati

Ogni tabella ha una chiave primaria, un valore che identifica una riga e una sola. Secondo la documentazione di PostgreSQL, la chiave primaria richiede che i valori siano unici e mai nulli, e una tabella può averne al massimo una.

La chiave esterna fa il lavoro opposto e complementare: non identifica le righe della propria tabella, ma punta alla chiave primaria di un’altra. Nella tabella ordini, la colonna che indica il cliente è una chiave esterna verso la tabella clienti, e contiene l’identificativo del cliente. Se si prova a inserire un ordine con un identificativo di cliente che non esiste, il sistema rifiuta l’operazione con un errore di violazione del vincolo: è così che il modello mantiene coerenti i dati tra tabelle diverse, senza bisogno di controlli manuali a ogni inserimento.

Tre modi in cui le tabelle si collegano

Due tabelle possono collegarsi in tre modi diversi, a seconda di quante righe di una corrispondono a quante righe dell’altra.

Esempio pratico: in una tabella studenti e in una tabella corsi, uno studente può frequentare più corsi e un corso può avere più studenti iscritti. È una relazione molti a molti, diversa dal legame tra un cliente e i suoi ordini, dove ogni ordine appartiene a un solo cliente pur essendoci più ordini per lo stesso cliente.

Da dove viene questo modello

Il modello relazionale nasce nel 1970, quando Edgar F. Codd, ricercatore ai laboratori IBM di San Jose, pubblica su Communications of the ACM il paper che lo descrive. Nell’introduzione, Codd applica la teoria matematica delle relazioni alla gestione di grandi archivi di dati condivisi, con un obiettivo preciso: chi usa i dati non deve sapere come sono organizzati fisicamente nella macchina. È in quel testo che compaiono i termini che il modello porta dal 1970, relazione per tabella, tupla per riga, dominio per colonna, insieme alle definizioni di chiave primaria e chiave esterna. Codd sosteneva che il modello relazionale fosse superiore ai modelli gerarchico e a rete allora diffusi, perché descrive i dati secondo la loro struttura naturale, senza aggiungere strutture pensate solo per la macchina che li conserva.

SQL, il linguaggio per interrogare i dati

I database relazionali si interrogano con SQL, il linguaggio che DBMS come PostgreSQL implementano in gran parte per creare tabelle, inserire righe ed eseguire ricerche. Un sito scritto in PHP o in JavaScript parla con il database proprio tramite SQL, ed è quello che rende il web capace di ricordare ogni cliente, ogni ordine, ogni pagina visitata. Anche i dataset usati per il machine learning partono spesso da tabelle relazionali, prima di essere trasformati per l’addestramento.

Lo schema fisso che regge questo modello non va bene per ogni caso d’uso: database relazionali e non relazionali a confronto spiega quando conviene invece un database NoSQL come MongoDB o Redis.