Basi di dati e modello relazionale

Approfondimento

Il servizio più sottile che un DBMS offre è la gestione delle transazioni: una transazione è una sequenza di operazioni trattata come un'unità indivisibile, e deve rispettare le proprietà ACID. L'atomicità (Atomicity) impone che si esegua «tutto o niente»: un bonifico che addebita un conto e accredita l'altro non può fermarsi a metà, altrimenti il denaro sparirebbe. La coerenza (Consistency) assicura che ogni transazione porti la base di dati da uno stato valido a un altro valido, rispettando i vincoli. L'isolamento (Isolation) fa sì che transazioni concorrenti non si disturbino, come se ciascuna girasse da sola. La durabilità (Durability) garantisce che, una volta confermata (commit), la modifica sopravviva anche a un guasto, ottenuta con un giornale (log) — la stessa idea del journaling dei file system. Senza controllo della concorrenza comparirebbero anomalie classiche come l'aggiornamento perduto (lost update), in cui due utenti leggono lo stesso valore e lo sovrascrivono a vicenda; il DBMS lo previene con meccanismi di blocco (locking) sulle risorse. Su tutto veglia l'amministratore della base di dati (DBA). Vale infine la pena ribadire l'indipendenza dei dati resa possibile dall'architettura a tre livelli: si può cambiare l'organizzazione fisica su disco (indici, file) senza toccare lo schema logico, e modificare lo schema logico senza riscrivere tutte le applicazioni, purché le loro viste restino valide — la stessa astrazione a strati che governa reti e sistemi operativi.

Approfondimento

Il modello E-R è più espressivo dei tre soli costrutti base. Gli attributi si articolano in vari tipi: semplici o composti (un «indirizzo» scomponibile in via, città, CAP), a valore singolo o multivalore (i «recapiti telefonici» di una persona) e derivati (l'«età», calcolabile dalla data di nascita, che quindi non si memorizza). Esistono poi le entità deboli, prive di un identificatore proprio, che si identificano solo attraverso un'entità forte a cui sono legate da un'associazione identificante (per esempio un «familiare a carico» identificato dal dipendente più dal nome). La generalizzazione (o gerarchia ISA) permette di modellare che un'entità generale (Persona) si specializza in sottotipi (Studente, Docente) che ne ereditano gli attributi e ne aggiungono di propri — lo stesso rapporto «è-un» dell'ereditarietà nella programmazione a oggetti, qui applicato ai dati. Sulle cardinalità, la notazione min-max è più precisa del semplice 1:N: a ciascun lato dell'associazione si indicano la partecipazione minima e massima di un'istanza, distinguendo la partecipazione totale (minimo 1: ogni istanza deve partecipare, ogni studente DEVE appartenere a una classe) da quella parziale (minimo 0: la partecipazione è facoltativa). Cogliere questi vincoli nel testo del problema è ciò che rende lo schema concettuale davvero fedele alla realtà che deve rappresentare, prima ancora di tradurlo in tabelle.

Approfondimento

Il modello relazionale non è solo un modo di disporre i dati in tabelle: è una teoria matematica, e su di essa poggia un'algebra relazionale che definisce le operazioni con cui interrogarle. Le operazioni fondamentali sono la selezione (σ), che estrae le righe che soddisfano una condizione; la proiezione (π), che estrae determinate colonne; il prodotto cartesiano e soprattutto la giunzione (join, ⋈), che combina due tabelle sulle righe con valori corrispondenti (tipicamente chiave esterna con chiave primaria); e le operazioni insiemistiche unione, differenza e intersezione, che trattano le relazioni come insiemi di tuple. Ogni interrogazione SQL che scriveremo si può ricondurre a una composizione di queste operazioni: è questo fondamento algebrico a garantire che le query abbiano un significato preciso e siano automaticamente ottimizzabili dal DBMS, che può riordinare le operazioni scegliendo il piano di esecuzione più efficiente. Un punto delicato è la semantica del valore nullo (NULL), che rappresenta un dato mancante o non applicabile: introduce una logica a tre valori (vero, falso, sconosciuto), per cui un confronto con NULL non restituisce «vero» né «falso» ma «sconosciuto», e va perciò gestito con operatori appositi (IS NULL). Comprendere che dietro le tabelle c'è un'algebra rigorosa è ciò che distingue chi «usa» un database da chi ne padroneggia i principi.

Approfondimento

Oltre alle tre regole di base, la traduzione deve saper gestire i costrutti più ricchi dell'E-R. Un attributo multivalore non può stare in una colonna, pena la violazione della 1FN: si estrae in una tabella separata, con una chiave esterna verso l'entità d'origine (i «telefoni» di un cliente diventano una tabella TELEFONO con la chiave del cliente). Un'entità debole diventa una tabella la cui chiave primaria è composta dalla chiave dell'entità forte identificante più il proprio identificatore parziale. La traduzione di una generalizzazione (gerarchia ISA) ammette invece tre strategie, da scegliere secondo il caso: accorpare tutto in un'unica tabella del genitore, con un attributo «tipo» e le colonne di tutti i sottotipi (semplice, ma con molti valori nulli); creare una tabella per ciascun sottotipo che include gli attributi ereditati (nessun nullo, ma dati del genitore ripetuti); oppure mantenere una tabella per il genitore e una per ciascun sottotipo, collegate da chiavi (la più normalizzata, al prezzo di join più frequenti). La scelta della politica referenziale, infine, va motivata caso per caso: CASCADE è adatto quando i dati figli non hanno senso senza il padre (le righe di un ordine spariscono con l'ordine), RESTRICT quando si vuole impedire una cancellazione che lascerebbe riferimenti orfani, SET NULL quando il legame è facoltativo. Padroneggiare questi casi meno banali è esattamente ciò che l'indirizzo Scienze Applicate richiede nelle prove di progettazione.

Approfondimento

Alla base della normalizzazione c'è il concetto di dipendenza funzionale: si scrive «X → Y» e si legge «X determina Y» quando, fissato il valore di X, il valore di Y è univocamente determinato (per esempio «matricola → nome_studente»). Le forme normali si definiscono proprio in termini di quali dipendenze sono ammesse. Vale la pena normalizzare un caso concreto. La tabella «ESAME(matricola, cod_corso, nome_studente, nome_corso, voto)» con chiave «(matricola, cod_corso)» è in 1FN (attributi atomici) ma non in 2FN, perché «nome_studente» dipende solo da «matricola» e «nome_corso» solo da «cod_corso»: sono dipendenze parziali dalla chiave composta. Si porta in 2FN scomponendola in «STUDENTE(matricola, nome_studente)», «CORSO(cod_corso, nome_corso)» ed «ESAME(matricola, cod_corso, voto)». Se comparisse un attributo come «dipartimento» dipendente da «nome_corso», a sua volta non chiave, si avrebbe una dipendenza transitiva, da eliminare per la 3FN spostandolo in un'altra tabella. La forma di Boyce-Codd (BCNF) è una versione più severa della 3FN, che richiede che ogni determinante sia una chiave. Attenzione però: normalizzare troppo moltiplica le tabelle e quindi i join, che costano; per questo, in sistemi con moltissime letture, si pratica talvolta una denormalizzazione controllata, reintroducendo consapevolmente una ridondanza per guadagnare in prestazioni — una scelta di ingegneria, non un errore, purché governata e documentata.