Introduzione alle Basi di Dati
Sistemi Informativi e Gestione della Conoscenza
Un sistema organizzativo è una struttura complessa di risorse e regole coordinate per obiettivi specifici. Il Sistema Informativo (SI) ne costituisce la componente dedicata alla gestione dei flussi informativi.
Le sue mansioni si articolano in un ciclo vitale preciso: Acquisizione (input), Elaborazione (trasformazione), Conservazione (archiviazione a lungo termine) e Produzione (output di valore).
È una distinzione fondamentale: il Sistema Informativo è un concetto logico/organizzativo che prescinde dalla tecnologia (esiste anche in forma cartacea). Il Sistema Informatico è invece l'insieme di infrastrutture ICT (hardware, software, reti) che automatizza il SI.
La Gerarchia dei Dati: DIKW
In ingegneria dei dati, non tutto ciò che salviamo ha lo stesso valore. Esiste una scala di astrazione crescente:
Fatti grezzi e simboli isolati (es. "30"). Non hanno valore decisionale finché restano decontestualizzati.
Dati inseriti in un contesto che ne chiarisce il significato (es. "30 è il voto dell'esame di Basi di Dati").
L'elaborazione delle informazioni genera Conoscenza, la risorsa più stabile di un'azienda. Mentre l'hardware diventa obsoleto, il patrimonio dei dati (anagrafiche, bilanci, log) rimane una risorsa strategica costante.
Caratteristiche di una Base di Dati
Una Base di Dati è una collezione di dati gestita in modo da garantire standard industriali che un semplice file system non potrebbe offrire. Le sue proprietà cardine sono:
I dati devono sopravvivere alle sessioni di lavoro. Il sistema deve garantire che le informazioni non vadano perse in caso di guasti hardware o software (Recovery).
Capacità di operare su Grandi Dimensioni (terabyte) mantenendo tempi di risposta millisecondali, grazie all'uso di indici e ottimizzazione delle query.
Più utenti devono poter accedere ai dati simultaneamente (Concorrenza). L'obiettivo è eliminare la Ridondanza (duplicazione inutile) e l'Incoerenza (versioni diverse dello stesso dato).
Controllo granulare degli accessi. Utenti diversi hanno privilegi diversi, garantendo che ognuno veda solo i dati di sua competenza.
Il DBMS e le sue Garanzie
Il DBMS (Database Management System) è l'interfaccia software tra l'utente e i dati fisici. I suoi compiti principali sono:
Gestisce l'autenticazione e i permessi, impedendo accessi non autorizzati.
Applica vincoli per evitare dati incoerenti o logicamente errati.
Permette di cambiare la struttura fisica dei file senza dover modificare i programmi.
Il DBMS non è un semplice "contenitore", ma un gestore attivo che risolve i problemi storici della gestione dei dati su file (ridondanza e inconsistenza). Per farlo, implementa un'architettura a tre livelli:
L'efficienza della Condivisione
Senza un DBMS, se due programmi scrivessero sullo stesso file contemporaneamente, i dati verrebbero corrotti. Il DBMS utilizza un componente chiamato Gestore della Concorrenza che coordina gli accessi simultanei, garantendo che ogni utente veda una versione coerente dei dati.
Transazioni e Proprietà ACID
Una Transazione è un'unità logica di lavoro. Deve essere completata interamente o non deve essere eseguita affatto. Ogni transazione segue il modello ACID:
Le proprietà ACID definiscono i requisiti che garantiscono che le transazioni in un database siano elaborate in modo affidabile. Senza queste garanzie, un semplice crash del server potrebbe corrompere i dati in modo irreversibile.
La transazione è considerata un'unità di lavoro indivisibile. Il DBMS deve garantire che, se una transazione viene interrotta (per un errore hardware, un crash software o una violazione dei vincoli), tutte le operazioni parziali già eseguite vengano annullate tramite una procedura di Rollback, riportando il DB allo stato iniziale.
Una transazione deve portare il database da uno stato valido a un altro stato valido. Ciò significa che non può violare mai i Vincoli di Integrità predefiniti (es. chiavi primarie duplicate, saldi negativi non ammessi). Se l'esecuzione della transazione produrrebbe uno stato inconsistente, il DBMS la blocca immediatamente.
Garantisce che l'esecuzione simultanea di più transazioni produca lo stesso risultato che si otterrebbe eseguendole una dopo l'altra (serializzazione). Anche se migliaia di utenti operano insieme, ogni transazione deve "credere" di essere l'unica in esecuzione sul sistema, evitando fenomeni come la lettura sporca di dati temporanei.
Una volta che l'utente riceve la conferma del successo (Commit), le modifiche devono essere permanenti. Anche in caso di un'interruzione di corrente un secondo dopo il Commit, al riavvio il DBMS deve essere in grado di recuperare i dati grazie alla scrittura fisica immediata nei registri sicuri.
Le proprietà ACID non sono solo concetti teorici, ma vengono realizzate tramite algoritmi complessi che il DBMS esegue in background:
Per assicurare il "tutto o niente", il DBMS scrive ogni operazione in un file temporaneo chiamato Undo Log. Se la transazione fallisce (Abort), il DBMS legge il log all'indietro e annulla le modifiche fatte fino a quel momento (procedura di Rollback).
Per evitare interferenze, il DBMS mette dei "lucchetti" (Lock) sui dati usati da una transazione. Se la Transazione A sta modificando il saldo di un conto, la Transazione B dovrà attendere che A finisca prima di poter leggere o scrivere quel dato.
I dati non vengono scritti immediatamente sul disco perché sarebbe troppo lento. Vengono tenuti in RAM. Per garantire la durabilità, il DBMS usa un Redo Log che permette di ricostruire i dati in RAM se il server si spegne improvvisamente prima del salvataggio finale sul disco.
Architettura a Livelli e Linguaggi SQL
Per garantire l'Indipendenza dei Dati, i moderni DBMS adottano un'architettura suddivisa in tre livelli logici. Questa separazione permette di modificare un livello senza dover riscrivere quelli superiori.
Per interagire con questi livelli, si utilizza il linguaggio SQL (Structured Query Language), che si articola in quattro sotto-famiglie funzionali:
DDL (Data Definition Language):
Serve a definire, modificare o eliminare lo Schema.
Comandi principali: CREATE, ALTER, DROP.
DML (Data Manipulation Language):
Serve a manipolare le Istanze (i record).
Comandi principali: INSERT, UPDATE, DELETE.
DQL (Data Query Language):
Sotto-insieme del DML dedicato esclusivamente al Recupero delle informazioni.
Comando cardine: SELECT.
DCL (Data Control Language):
Gestisce la Sicurezza, i permessi e il controllo degli accessi.
Comandi principali: GRANT, REVOKE.
Grazie a questa struttura, se l'amministratore sposta il database su un disco SSD più veloce (cambio livello fisico), lo schema logico e le query DQL degli utenti rimangono identici.
Il Modello Relazionale: Storia e Visione
Proposto da E.F. Codd nel 1970 presso i laboratori IBM, il Modello Relazionale ha segnato il passaggio da una gestione dei dati "orientata alle macchine" a una "orientata alla logica". È oggi lo standard indiscusso per l'organizzazione delle basi di dati strutturate.
I Pilastri dell'Indipendenza
La vera rivoluzione introdotta da Codd risiede nella separazione dei livelli, garantendo due forme fondamentali di autonomia:
Dalla Logica dei Puntatori alla Logica dei Valori
A differenza dei modelli precedenti (come quello Gerarchico o Reticolare) che usavano puntatori fisici (indirizzi di memoria) per collegare i dati, il modello relazionale è rigorosamente basato sui valori.
In questo sistema, i collegamenti tra tabelle diverse avvengono esclusivamente tramite la corrispondenza di dati espliciti (es: una Matricola che appare sia nell'anagrafica che nel registro esami). Questo approccio elimina i "fili invisibili" tra i dati, rendendo la struttura trasparente e facile da interrogare.
Basi Matematiche del Modello
Il modello relazionale non è solo una convenzione grafica, ma poggia su rigorosi concetti della teoria degli insiemi. Capire la matematica che sta dietro una tabella è fondamentale per comprendere come il DBMS esegue le interrogazioni (query).
Un dominio è un insieme di valori atomici (indivisibili). Ad esempio, il dominio Voto è l'insieme degli interi tra 18 e 30. In informatica, questo concetto si sovrappone a quello di Tipo di Dato.
Dato un insieme di n domini, il prodotto cartesiano è l'insieme di tutte le possibili combinazioni (n-uple) che si possono formare prendendo un elemento da ciascun dominio.
Una relazione è un sottoinsieme del prodotto cartesiano. Rappresenta solo le combinazioni di valori che hanno un senso logico nella realtà che stiamo modellando. In termini di database, la relazione è la Tabella.
Data una famiglia di domini D1, D2, …, Dn, una relazione r è un sottoinsieme del prodotto cartesiano:
r ⊆ D1 × D2 × … × Dn
Proprietà della Relazione
Poiché una relazione è un insieme, eredita proprietà matematiche precise che la distinguono dai semplici file di dati:
- Tupla (n-upla): Ogni elemento dell'insieme (riga).
- Grado: Il numero n di domini coinvolti (numero di colonne). È una proprietà dello Schema.
- Cardinalità: Il numero di tuple presenti nella relazione. È una proprietà dell'Istanza e cambia nel tempo.
- Assenza di ordinamento: Essendo un insieme, l'ordine delle tuple non ha rilevanza matematica.
Attributi e Strutture Non Posizionali
In un database relazionale, la tabella è l'astrazione logica di una relazione matematica. A differenza di un file CSV o di un foglio Excel tradizionale, non identifichiamo le colonne per la loro posizione fisica (es. "la prima colonna"), ma attraverso un nome univoco detto Attributo.
Questa è la base della struttura non posizionale: l'informazione è legata al nome del campo, non al suo ordine. Se l'amministratore del DB sposta la colonna "Email" dall'ultimo al secondo posto, le query e le applicazioni continueranno a funzionare senza errori.
- Unicità delle Tuple: Essendo un insieme matematico, non possono esistere due righe identiche in una tabella.
- Disordine Intrinseco: L'ordine delle righe e delle colonne è irrilevante ai fini del significato dei dati.
- Atomicità dei Valori: Ogni cella (intersezione riga/colonna) deve contenere un valore elementare, non scomponibile e non una lista di valori (Prima Forma Normale).
Gestione dell'Informazione Incompleta
Il modello relazionale adotta una "ipotesi di mondo aperto": se un dato non è presente, non significa necessariamente che non esista. Per gestire l'assenza di dati senza ricorrere a valori fittizi (come 0 o stringhe vuote), si utilizza il segnaposto NULL.
- Valore Sconosciuto: Il dato esiste nella realtà (es. "Data di Nascita"), ma non è stato ancora registrato nel sistema.
- Valore Inesistente: Il dato non può esistere per quella specifica entità (es. "Interno ufficio" per un dipendente che lavora da remoto).
- Valore Senza Informazione: Non sappiamo se il dato esista o meno (incertezza totale).
Voto > 18 applicata a un record dove il voto è NULL restituirà Unknown, influenzando il modo in cui i dati vengono estratti.
Schema e Istanza: Struttura vs Dati
Per comprendere l'evoluzione di un database, dobbiamo separare nettamente la sua intensione (lo schema) dalla sua estensione (l'istanza).
Definisce l'aspetto strutturale e i vincoli. È stabile nel tempo.
Formalmente: R(A1:D1, A2:D2, ...), dove A sono gli attributi e D i domini.
È l'insieme effettivo delle n-uple (i dati reali). È estremamente dinamica e cambia con ogni operazione di INSERT o DELETE.
Mentre lo Schema di Relazione riguarda la singola tabella, lo Schema di Base di Dati è l'insieme di tutti gli schemi di relazione, definiti con nomi univoci, che formano il sistema informativo integrato.
I Vincoli di Integrità
I Vincoli di Integrità sono predicati (condizioni logiche) che devono essere soddisfatti da ogni istanza della base di dati per essere considerata valida. Essi fungono da "filtri di qualità" che impediscono l'inserimento di informazioni incoerenti o impossibili.
Vincoli Intra-relazionali
I vincoli intra-relazionali sono regole il cui soddisfacimento può essere verificato analizzando una singola relazione alla volta. Si suddividono in base alla "portata" del controllo:
Agiscono sul singolo attributo. Impongono che il valore inserito appartenga a un insieme predefinito o rispetti determinate proprietà tipologiche.
Esempio: L'attributo "Età" deve essere un intero positivo; l'attributo "Sesso" deve essere scelto tra {'M', 'F'}.
Esprimono condizioni che coinvolgono più attributi della stessa riga. Ogni riga deve poter essere valutata come "Vera" rispetto a questa espressione booleana.
Esempio: In una tabella di magazzino, il vincolo (PrezzoScontato <= PrezzoListino) deve essere sempre rispettato per ogni n-upla.
È un caso specifico di vincolo di n-upla che proibisce a un attributo di assumere il valore NULL. Si applica a tutti i campi obbligatori per i quali l'assenza di informazione renderebbe il record inutile o inconsistente.
A differenza dei precedenti, questi coinvolgono l'intera istanza della relazione. Impongono che non esistano due n-uple distinte con lo stesso valore per un determinato insieme di attributi.
Esempio: Due studenti diversi non possono avere lo stesso numero di matricola.
I vincoli permettono al DBMS di automatizzare il controllo della coerenza. Senza di essi, l'integrità dei dati dipenderebbe esclusivamente dalla bravura del programmatore che scrive l'applicazione, aumentando drasticamente il rischio di corruzione dei dati nel tempo.
INSERT o UPDATE che tenti di violare anche uno solo di questi predicati.
Superchiavi e Chiavi
In una relazione, le righe devono essere tutte diverse tra loro. Per identificare univocamente una tupla, usiamo il concetto di chiave:
La Chiave Primaria (Primary Key)
Tra le varie chiavi candidate, ne scegliamo una come Chiave Primaria. È l'attributo principale per i collegamenti e ha due regole ferree: deve essere unica e non può mai essere NULL.
Integrità Referenziale e Chiavi Esterne
A differenza dei vincoli intra-relazionali, i vincoli inter-relazionali permettono di definire legami tra tabelle diverse. Il più importante tra questi è il Vincolo di Integrità Referenziale (o Referential Integrity).
Questo vincolo viene implementato tramite la Chiave Esterna (Foreign Key): un insieme di attributi di una relazione R1 che fa riferimento alla chiave primaria di una relazione R2. Il sistema garantisce che ogni valore non nullo della chiave esterna in R1 corrisponda esattamente a un valore esistente nella chiave primaria di R2.
Gestione delle Violazioni (Azioni Compensative)
Cosa succede se effettuiamo operazioni che rompono questo legame? Ad esempio, se cancelliamo un "Padre" che ha ancora dei "Figli" collegati, o se ne modifichiamo la Chiave Primaria. Il progettista può istruire il DBMS a reagire con diverse politiche:
È la politica più sicura: il DBMS impedisce l'operazione. Non puoi cancellare un cliente se ci sono ancora fatture a lui intestate. L'utente deve prima gestire manualmente i record correlati.
L'operazione si propaga sui figli. Se cancelli un dipartimento, il sistema cancella automaticamente tutti i dipendenti che vi appartengono. Se modifichi l'ID di un progetto, tutti i riferimenti nelle altre tabelle si aggiornano istantaneamente.
In caso di cancellazione del record padre, il riferimento nella tabella figlia viene impostato a NULL (o a un valore predefinito). Utile se vuoi mantenere i dati dei figli rendendoli "orfani" (es. se un venditore lascia l'azienda, le sue vendite vengono messe in 'Non Assegnato').
In un database universitario, la
Matricola nella tabella ESAMI è una Foreign Key verso la tabella STUDENTI.
Il vincolo impedisce di inserire un voto per una matricola che non esiste, garantendo che ogni esame sia associato a una persona reale.