Modello relazionale

In informatica il modello relazionale è un modello matematico che offre gli strumenti concettuali per strutturare una base di dati in termini di valori atomici e relazioni tra di essi.

Proposto da Edgar F. Codd nel 1970 per semplificare la scrittura di interrogazioni sui database e per favorire l'indipendenza dei dati, venne reso disponibile come modello logico in DBMS reali nel 1981 e ad oggi è uno dei modelli logici più utilizzati, implementato su moltissimi DBMS sia commerciali che open source. Si basa sulla teoria degli insiemi e sulla logica del primo ordine, strutturato intorno al concetto matematico di relazione e per il suo trattamento ci si avvale di strumenti quali il calcolo relazionale e l'algebra relazionale.^[1]

Storia

Ideazione

Edgar F. Codd lavorava nella sede californiana di IBM come ricercatore sulla nascente tecnologia dei dischi rigidi quando osservò l'inefficienza dell'approccio CODASYL con la nuova modalità di memorizzazione dei dati, inefficienza principalmente dovuta all'assenza di una funzione di ricerca. Nel 1970 cominciò a produrre diversi documenti schematizzanti un nuovo approccio alla costruzione delle basi di dati, culminati nell'articolo "A Relational Model of Data for Large Shared Data Banks" (lett. "Un modello relazionale dei dati per banche dati condivise di grandi dimensioni" in italiano).^[2]

In questo articolo descrisse un nuovo sistema per archiviare e modificare grandi quantità di dati. Invece di utilizzare sequenze di record collegati tra loro attraverso un qualche tipo di struttura ad albero, come nel modello CODASYL, ritenne di utilizzare collezioni di tuple di dimensione fissata, chiamate "relazioni".

Questo sistema sarebbe risultato molto inefficiente per l'archiviazione di dati sparsi, ovvero nel caso di tuple che presentano sistematicamente diversi campi vuoti; tale errore di impostazione fu corretto spostando i campi opzionali in collezioni separate, in modo da produrre insiemi più compatti, risparmiando spazio.

Ad esempio, un utilizzo comune delle banche dati è quello di registrare delle informazioni sugli utenti: il loro nome, informazioni di accesso, indirizzo e numeri di telefono. In una banca dati navigazionale tutti questi dati sarebbero stati memorizzati in un unico "record", e gli elementi non presenti (ad esempio un utente di cui non sia noto l'indirizzo) sarebbero stati semplicemente omessi. Al contrario, in una banca dati relazionale, le informazioni vengono divise, ad esempio, nelle tabelle "utente", "indirizzi", "numeri di telefono" e solo se i dati sono presenti viene creata, nella rispettiva tabella, una tupla.

Uno degli aspetti interessanti introdotti nelle banche dati relazionali sta nel collegamento delle tuple attraverso i valori: nel modello relazionale per ogni relazione viene definita una "chiave", ovvero un campo (o insieme di campi) che assume un valore univoco per ogni tupla, fungendo da identificatore. La chiave può essere ricavata direttamente dai dati memorizzati (ad esempio, in un database di cittadini italiani si potrebbe utilizzare il codice fiscale di ognuno), o aggiunta in maniera artificiale (ad esempio aggiungendo un campo ID numerico, generato sequenzialmente per ogni tupla).

Questa operazione di "riunificazione" dei dati non è prevista nei linguaggi di programmazione tradizionali: mentre l'approccio navigazionale richiede semplicemente di "ciclare" per raccogliere i diversi "record", l'approccio relazionale richiede al programma di "ciclare" per raccogliere le informazioni riguardanti ogni record.^{[non chiaro]} Codd, propose, come soluzione, la creazione di un linguaggio dedicato a questo problema. Tale linguaggio, più tardi, si è sviluppato nella codifica che oggi è universalmente adottata e che è il mattone fondamentale delle basi di dati: SQL.

Utilizzando una branca della matematica chiamata "calcolo delle tuple", dimostrò che questo sistema era in grado di compiere tutte le normali operazioni di amministrazione delle banche dati e che inoltre consentiva di disporre di uno strumento semplice per trovare e visualizzare gruppi di dati tramite un'unica operazione.

Implementazione

IBM cominciò a implementare questa teoria in alcuni prototipi all'inizio degli anni settanta, come nel "System R". La prima versione fu realizzata nel 1974/75 con uno strumento "monotabella"; negli anni successivi furono studiati i primi sistemi che potessero supportare la suddivisione dei dati in tabelle separate. Versioni "multiutente" furono realizzate nel 1978 e nel 1979; negli stessi anni fu standardizzato il linguaggio SQL. La superiorità di questo sistema rispetto a CODASYL fu quindi evidente e IBM passò a sviluppare una versione commerciale di System R, che prese il nome di "SQL/DS" prima e "DB2" infine.^[3]

Il lavoro di Codd venne proseguito presso l'Università di Berkeley da Eugene Wong e Michael Stonebraker. Il loro progetto, chiamato INGRES e finanziato con fondi destinati alla creazione di un database geografico, vide la luce nel 1973 e produsse i primi risultati nel 1974 anche grazie all'opera di numerosi studenti che si prestarono come programmatori (quasi 30 persone lavorarono al progetto). INGRES era assai simile a System R e prevedeva un linguaggio alternativo a SQL, chiamato QUEL.^[4]

Molte delle persone coinvolte nel progetto si convinsero della fattibilità commerciale dello stesso e fondarono imprese per entrare nel mercato con questo prodotto. Sybase, Informix, NonStop SQL e alla fine Ingres stessa nacquero quali spin-off per la diffusione di INGRES all'inizio degli anni ottanta. Perfino Microsoft SQL Server è, per certi versi, una derivazione di Sybase e quindi di INGRES. Solamente la Oracle di Larry Ellison partì utilizzando un approccio diverso, basato sul System R di IBM, e alla fine prevalse sulle altre compagnie con il suo prodotto, lanciato nel 1978.^[5]

In Svezia il lavoro di Codd venne sviluppato all'Università di Uppsala che sviluppò un diverso prodotto, "Mimer SQL", commercializzato nel 1984. Una particolarità di questa soluzione sta nell'introduzione del concetto di transazione, successivamente importata in quasi tutti i DBMS.^[6]

Descrizione

Esempio di tabella di un RDBMS ovvero secondo il modello relazionale (Docenti e loro corsi). Visibile in alto in grigio l'intestazione o testata della tabella con i nomi dei vari campi o attributi e i valori assunti da questi nelle rispettive righe, record o tuple nel corpo sottostante (è presente un record duplicato).

L'assunto fondamentale del modello relazionale è che tutti i dati sono rappresentati come relazioni e manipolati con gli operatori dell'algebra relazionale o del calcolo relazionale, da cui appunto il nome.

Il modello relazionale consente al progettista di database di creare una rappresentazione consistente e logica dell'informazione. La consistenza è ottenuta inserendo nel progetto del database appropriati vincoli. La teoria comprende anche un processo di normalizzazione in base al quale viene selezionato tra le diverse alternative lo schema maggiormente "desiderabile".

La struttura base del modello relazionale è composta da:

uno o più attributi o campi dato;
un tipo di dato ed un dominio su quel tipo, definito come l'insieme dei valori che può assumere un determinato attributo o campo dato;
un valore per ciascun attributo all'interno del dominio o tipo di dato consentito;
una tupla, record o riga cioè l'insieme non ordinato di valori assunti dagli attributi.

La testata della relazione è l'insieme di attributi o campi dato, mentre il corpo è l'insieme di n tuple o record di dati o valori. La testata di una relazione è anche la testata di ciascuna delle sue tuple. La tabella è invece la rappresentazione grafica normalmente accettata per rappresentare la relazione tra attributi e valori.

Il principio base del modello relazionale è dunque che tutte le informazioni siano rappresentate da valori inseriti in relazioni (tabelle); dunque, un database relazionale è un insieme di relazioni contenenti valori e il risultato di qualunque interrogazione (o manipolazione) dei dati può essere rappresentato anch'esso da relazioni (tabelle).

Il modello relazionale risponde al requisito dell'indipendenza dei dati e prevede una distinzione tra il livello fisico e il livello logico: questa capacità di astrazione ha fatto la sua fortuna nel mondo della gestione dati.

Applicazione ai database

Esempio di relazione tra più tabelle. Due tabelle secondarie, attraverso le rispettive foreign key, puntano ovvero sono referenziate ad una tabella primaria che contiene un campo comune tra le tre detta chiave primaria (nell'esempio il campo Activity Code)

"Tabella" è il termine normalmente usato in sostituzione del termine teorico "relazione" per indicare l'insieme delle righe e delle colonne della matrice di dati. La struttura di una tabella è specificata da una lista di colonne, ciascuna delle quali ha un nome univoco (l'attributo o campo dato), un tipo di dato e un dominio, cioè un insieme di valori accettati (valori univoci non ripetuti se è una chiave primaria, oppure valori ripetibili; fra questi il valore NULL se l'attributo non è obbligatorio).

"Attributo" o campo dato è il termine usato per indicare l'intestazione iniziale di una colonna; ad esso si associa un certo tipo di dato con il suo dominio di possibili valori. Il tipo di dato usato nei database relazionali può essere un insieme di numeri interi, un insieme di caratteri alfanumerici, l'insieme delle date, i valori booleani vero e falso ecc... I corrispondenti "nomi di tipo", ad esempio, saranno dunque le stringhe "int", "char", "date", "boolean", etc. Da sottolineare che, da una parte, la teoria relazionale non definisce quali tipi vadano supportati, e dall'altra molti sistemi garantiscono la possibilità di definire tipi di dati definiti dall'utente cioè personalizzati, in aggiunta a quelli "standard" forniti dal sistema.

Valore di attributo è il dato o valore di una cella identificata da una specifica coppia riga - colonna, come ad esempio "Mario Rossi" o "2006", mentre una tupla è praticamente la stessa cosa di una riga o record di dati o valori.

Una relazione è dunque la definizione di una tabella, cioè un insieme di colonne e righe, cioè attributi o campi dato insieme ai rispettivi dati o valori che vi compaiono. La definizione della tabella è la testata iniziale e i dati che vi appaiono sono il corpo cioè un insieme di righe.

In tale ambito, il termine relazione a volte si riferisce anche alle relazioni o vincoli interrelazionali che intercorrono tra una tabella primaria (master) ed altre tabelle secondarie (slave) attraverso l'associazione tra una chiave primaria della tabella principale e le foreign key delle altre tabelle.

Le operazioni tipiche basilari che saranno possibili su una tabella precedentemente definita e creata nella sua struttura tramite il Data Definition Language (DDL) sono quelle cosiddette di CRUD ovvero C creazione (create) o inserimento dei record (insert), R lettura (read), U aggiornamento (update), D cancellazione (delete), attraverso il Data Query Language e il Data Manipulation Language (DML) del linguaggio standard SQL. Altre operazioni tipiche sono la definizione delle chiavi (primarie o esterne) sulle tabelle definite ed altre ancora sono definite nel linguaggio Data Control Language e nello stesso Data Definition Language.

Vincoli di integrità referenziale

I vincoli di integrità rappresentano una classe di proprietà che dovrebbero essere sempre soddisfatte dalle istanze della base di dati, pena la perdita dei dati conservati o la comparsa di errori di elaborazione. La verifica e la preservazione di questi vincoli rientra nei compiti dei sistemi di gestione delle basi di dati.

Dal punto di vista formale un vincolo è un predicato sulla base di dati o di un suo elemento. Valutando il predicato è possibile rilevare se la base di dati soddisfa o meno un dato vincolo. In generale a uno schema di base di dati si associa un insieme di vincoli e si considerano corrette solo le istanze che soddisfano tutti i vincoli specificati.

Esistono due grandi tipologie di vincoli: quelli intra-relazionali che interessano una sola relazione e quelli inter-relazionali o extra-relazionali che definiscono legami tra relazioni differenti.

Altri modelli

Prima dell'avvento del modello relazionale, le basi di dati venivano progettate seguendo principalmente due modelli: quello gerarchico e quello reticolare. Sebbene oggi la maggioranza dei DBMS supporti il modello relazionale, in alcuni centri elaborazione dati sono ancora utilizzati database gerarchici o reticolari, specialmente in casi in cui la migrazione avrebbe costi proibitivi.

Secondo alcuni autori^[Quali?] il modello relazionale potrebbe in futuro cedere il passo a un modello orientato agli oggetti, ma da una parte i DBMS ad oggetti stentano ad affermarsi, dall'altra i migliori DBMS relazionali stanno rilasciando funzionalità object-oriented, come la possibilità di definire tipi di dato "utente"^{[non chiaro]}.

Note

^ Atzeni 2018, p.15.
^ Codd 1970.
^ Breve storia dei database relazionali, su ibm.com. URL consultato il 18 marzo 2024.
^ (EN) Michael Stonebraker e Lawrence A. Rowe, The design of POSTGRES (PDF), in SIGMOD '86: Proceedings of the 1986 ACM SIGMOD international conference on Management of data, Washington, DC, Association for Computing Machinery, maggio 1986, p. 4, DOI:10.1145/16894, ISBN 0897911911.
^ (EN) Brief History of Oracle Database, su docs.oracle.com. URL consultato il 18 marzo 2024.
^ (EN) Database Technology | We made it possible, su wemadeitpossible.com, Università di Uppsala, gennaio 2011. URL consultato il 18 marzo 2024 (archiviato dall'url originale il 25 aprile 2018).