Database relazionali
Negli anni '70, Edgar F. Codd ha introdotto il modello di database relazionale, che ha spostato l'attenzione dall'approccio basato sulla navigazione a un approccio incentrato sui dati. Nel modello relazionale i dati vengono archiviati come campi a lunghezza fissa in tabelle normalizzate (figura 17). Con la normalizzazione, le tabelle di grandi dimensioni possono essere divise in tabelle più piccole e meno ridondanti ed è possibile definire relazioni tra di esse. Codd ha quindi definito vari gradi di normalizzazione per i dati archiviati nel modello relazionale. È stato inoltre sviluppato da IBM il linguaggio SQL (Structured Query Language), per fornire un linguaggio ragionevolmente intuitivo per la creazione e la gestione di database.
Figura 17: Tabelle di database relazionali
I concetti dei database relazionali sono stati combinati con SQL e usati da IBM, che ha progettato i sistemi di gestione di database relazionali (RDBMS) DB2 e System R, precursori di tutti i sistemi RDBMS moderni.
Di seguito sono illustrate le caratteristiche tipiche dei sistemi RDBMS moderni:
- I dati vengono modellati come record nelle tabelle e i record correlati tra le tabelle sono espressi come relazioni.
- Le tabelle sono definite dagli schemi, che impongono regole sui tipi e sugli input validi per ogni colonna, detta anche campo, in una tabella.
- Per definire e modificare le tabelle, nonché accedervi, viene usato un linguaggio di query (in genere SQL).
I moderni sistemi RDBMS offrono agli sviluppatori di applicazioni una soluzione di gestione dati completa che astrae la nozione di gestione dei dati dallo sviluppatore di applicazioni. Una volta progettato uno schema, le applicazioni possono archiviare, recuperare e modificare i record in base alle regole specificate nello schema. Specificando i vincoli sulle informazioni in un database, le applicazioni possono gestire i dati in modo più affidabile, aspetto fondamentale per evitare incoerenze dei dati nei programmi applicativi. Un database utente può ad esempio verificare che l'età di ogni utente sia un numero intero non negativo compreso tra 1 e 130. Il database può quindi rifiutare di aggiungere un utente la cui età non soddisfi questo vincolo e può fornire un meccanismo di convalida automatica da usare quando i dati vengono archiviati.
Ridimensionamento nei database tradizionali
I sistemi RDBMS tradizionali sono stati progettati per essere eseguiti in un singolo computer, ma, con l'aumentare della quantità di dati o del numero di utenti simultanei, il database deve essere ridimensionato. Tenere presente che è possibile ridimensionare i database verticalmente o orizzontalmente.
Garantire le proprietà ACID in un database distribuito in cui non c'è un singolo nodo responsabile di tutti i dati che interessano una transazione presenta ulteriori complicazioni. Possono verificarsi errori delle connessioni di rete oppure un nodo può completare correttamente la propria parte della transazione e quindi può venire richiesto di eseguire il rollback delle modifiche apportate a causa di un errore in un altro nodo. Diventa quindi necessario un meccanismo di controllo della concorrenza distribuito.
Uno tra i primi esempi di controllo della concorrenza distribuito è stato il protocollo 2PC. Il protocollo 2PC fornisce atomicità e coerenza per le transazioni distribuite, per garantire che ogni partecipante alla transazione confermi se il commit della transazione deve essere eseguito oppure no. Nella prima fase, un nodo (il coordinatore) interroga gli altri nodi (i partecipanti) e invia un messaggio VOTE_REQUEST a tutti i partecipanti (figura 18). I partecipanti inviano quindi il voto sulla transazione da completare, che può essere VOTE_COMMIT o VOTE_ABORT. Nella seconda fase, il coordinatore registra i voti di ogni partecipante e rilascia un messaggio GLOBAL_COMMIT se ogni partecipante ha votato a favore della transazione o un messaggio GLOBAL_ABORT se anche uno solo dei partecipanti ha votato contro la transazione (figura 19). Infine, i partecipanti eseguono il commit o il rollback della transazione in base al messaggio ricevuto dal coordinatore. Il protocollo 2PC garantisce quindi la coerenza assoluta, in quanto ogni transazione richiede il consenso globale tra tutti i nodi. Le varianti di 2PC includono il protocollo 3PC e il protocollo di blocco a 2 fasi. Questi protocolli di controllo della concorrenza, tuttavia, sono costosi e influiscono sulle prestazioni su larga scala.
Figura 18: 2PC - Fase 1
Figura 19: 2PC - Fase 2