Inventato da Don Chamberlin e Ray Boyce presso IBM, il linguaggio SQL (Structured Query Language) è il linguaggio di programmazione standard per interagire con i sistemi di gestione di database relazionali, che consente all'amministratore del database di aggiungere, aggiornare o eliminare facilmente righe di dati. Originariamente noto come SEQUEL, è stato semplificato in SQL a causa di un problema relativo al marchio. Le query SQL consentono inoltre di recuperare dati dai database utilizzando solo poche righe di codice. Data questa relazione, è facile capire perché i database relazionali vengono talvolta chiamati anche "database SQL".  

Utilizzando l'esempio riportato sopra, potresti creare una query per trovare le prime 10 transazioni per azienda per un anno specifico con il seguente codice:

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

RAGGRUPPA PER 1

ORDER BY 2 DESC

LIMIT 10

La possibilità di unire i dati in questo modo ci aiuta a ridurre la ridondanza all'interno dei nostri sistemi di dati, consentendo ai team che lavorano con i dati di mantenere una tabella principale per i clienti anziché duplicare queste informazioni in caso di un'altra transazione futura. Per maggiori informazioni, consulta il paper di Don che illustra in dettaglio la storia di SQL qui (link esterno a IBM).

Prima dei database relazionali, le aziende utilizzavano un sistema di database gerarchico con una struttura ad albero per le tabelle di dati. Questi primi sistemi di gestione dei database (DBMS) permettevano agli utenti di organizzare grandi quantità di dati. Tuttavia, erano complessi, spesso legati a una particolare applicazione e limitati nelle modalità di scoperta dei dati. Queste limitazioni hanno portato il ricercatore IBM Edgar F. Codd a pubblicare un paper (link esterno a IBM) (PDF, 1,5 MB) nel 1970, intitolato "A Relational Model of Data for Large Shared Data Banks", che teorizzava il modello di database relazionale. In questo modello proposto, le informazioni potevano essere recuperate senza conoscenze avanzate in ambito informatico. Codd proponeva di organizzare i dati in base a relazioni significative come tuple o coppie attributo-valore. Gli insiemi di tuple venivano definiti relazioni, il che alla fine consentiva l'unione dei dati tra le tabelle.

Nel 1973, il San Jose Research Laboratory, oggi noto come Almaden Research Center, avviò un programma chiamato System R (R per relational) per dimostrare questa teoria relazionale con quella che definì "un'implementazione di livello industriale". Alla fine è diventato anche un banco di prova per SQL, consentendogli di essere adottato più ampiamente in un breve periodo di tempo. Tuttavia, l'adozione di SQL da parte di Oracle non ha compromesso la sua popolarità tra gli amministratori di database.

Nel 1983, IBM introdusse la famiglia di database relazionali DB2, così chiamata perché era la seconda famiglia di software di gestione di database di IBM. Oggi è uno dei prodotti di maggior successo di IBM, che continua a gestire miliardi di transazioni ogni giorno sull'infrastruttura cloud e definisce il livello di base per le applicazioni di machine learning.

Mentre i database relazionali strutturano i dati in un formato tabulare, i database non relazionali non sono rigidi come uno schema di database. Infatti, i database non relazionali organizzano i dati in modo diverso in base al tipo di database. Indipendentemente dal tipo di database non relazionale, tutti puntano a risolvere i problemi di flessibilità e scalabilità intrinseci nei modelli relazionali che non risultano ideali per i formati di dati non strutturati come testo, video e immagini. Questi tipi di database comprendono:

• Archivio chiave/valore: questo modello di dati senza schema è organizzato in un dizionario di coppie chiave/valore, in cui ogni elemento è dotato di una chiave e un valore. La chiave potrebbe essere qualcosa di simile a un SQL Database, come l'ID di un carrello, mentre il valore è un array di dati, come ogni singolo articolo del carrello dell'utente. Viene comunemente utilizzato per il caching e l'archiviazione delle informazioni sulla sessione utente, ad esempio i carrelli. Tuttavia, non è l'ideale quando è necessario estrarre più record contemporaneamente. Redis e Memcached sono esempi di database open source con questo modello di dati.

• Archivio documenti: come suggerisce il nome, i database di documenti archiviano i dati come documenti. Possono essere utili nella gestione dei dati semistrutturati, e i dati vengono generalmente archiviati nei formati JSON, XML o BSON. Ciò mantiene insieme i dati quando vengono utilizzati nelle applicazioni, riducendo la quantità di traduzioni necessarie per utilizzarli. Gli sviluppatori ottengono inoltre maggiore flessibilità perché non è necessario che gli schemi di dati corrispondano tra i documenti (ad es. name vs. first_name). Tuttavia, questo può essere problematico per transazioni complesse, e portare alla corruzione dei dati. I casi d'uso più diffusi dei database di documenti includono i sistemi di gestione dei contenuti e i profili utente. Un esempio di database orientato ai documenti è MongoDB, il componente database dello stack MEAN.

• Archivio wide-column: questi database memorizzano le informazioni in colonne, consentendo agli utenti di accedere solo alle colonne specifiche di cui hanno bisogno senza allocare memoria aggiuntiva su dati irrilevanti. Questo database cerca di risolvere le carenze degli archivi valore-chiave e degli archivi di documenti, ma poiché può essere un sistema più complesso da gestire, se ne sconsiglia l'uso per i team e i progetti più recenti. Apache HBase e Apache Cassandra sono esempi di database open-source wide-column. Apache HBase è costruito sulla base di Hadoop Distributed Files System, che fornisce un modo per memorizzare insiemi di dati sparsi, comunemente utilizzati in molte applicazioni di big data. Apache Cassandra, invece, è stato progettato per gestire grandi quantità di dati su più server e clustering che si estendono su più data center. È stato utilizzato per una varietà di casi d'uso, come siti web di social network e data analytics in tempo reale.

• Archivio di grafi: questo tipo di database ospita tipicamente i dati di un grafo di conoscenza. Gli elementi dei dati vengono memorizzati come nodi, archi e proprietà. Qualsiasi oggetto, luogo o persona può essere un nodo. Un arco definisce la relazione tra i nodi. I database a grafo vengono utilizzati per archiviare e gestire una rete di connessioni tra elementi all'interno del grafo. Neo4j (link esterno a IBM), un servizio di database a grafo basato su Java con una community edition open-source in cui gli utenti possono acquistare licenze per il backup online e le estensioni per l'high availability, oppure una versione preconfezionata con licenza con backup ed estensioni incluse.

I database NoSQL danno inoltre priorità alla disponibilità rispetto alla coerenza.

Quando i computer operano su una rete, devono inevitabilmente decidere se dare la priorità a risultati coerenti (in cui ogni risposta è sempre la stessa) o a tempi di attività elevati, definiti "disponibilità". Questa è chiamata "Teorema CAP", che sta per Consistency (coerenza), Availability (disponibilità) e Partition Tolerance (tolleranza di partizione). I database relazionali garantiscono che le informazioni siano sempre sincronizzate e coerenti. Alcuni database NoSQL, come Redis, preferiscono fornire sempre una risposta. Ciò significa che le informazioni ricevute da una query potrebbero essere errate di alcuni secondi, o persino fino a mezzo minuto. Sui siti di social media, questo significa vedere una vecchia immagine del profilo quando quella più recente ha solo pochi istanti. L'alternativa potrebbe essere un timeout o un errore. D'altra parte, nelle transazioni bancarie e finanziarie, un errore e un nuovo invio possono rappresentare un'alternativa migliore a informazioni datate ed errate.

Per un riepilogo completo delle differenze tra SQL e NoSQL, vedi "Database SQL e NoSQL: qual è la differenza?"

Il vantaggio principale dell'approccio del database relazionale è la possibilità di creare informazioni significative unendo le tabelle. L'unione di tabelle consente di comprendere le relazioni tra i dati o la connessione tra le tabelle. SQL include la possibilità di contare, aggiungere, raggruppare e combinare le query. SQL può eseguire funzioni matematiche e subtotali di base e trasformazioni logiche. Gli analisti possono ordinare i risultati per data, nome o qualsiasi colonna. Queste caratteristiche rendono l'approccio relazionale lo strumento di query più popolare nelle aziende odierne.

I database relazionali hanno diversi vantaggi rispetto ad altri formati di database:

Facilità d’uso

In virtù della durata di vita del prodotto, esiste più di una comunità attorno ai database relazionali, che ne perpetua parzialmente l'uso continuato. SQL facilita inoltre il recupero di set di dati da più tabelle e l'esecuzione di semplici trasformazioni come il filtraggio e l'aggregazione. L'uso degli indici all'interno dei database relazionali consente inoltre di individuare rapidamente queste informazioni senza dover cercare ogni riga nella tabella selezionata.

Sebbene i database relazionali siano sempre stati considerati come un'opzione di archiviazione dei dati più rigida e poco flessibile, i progressi nella tecnologia e nelle opzioni DBaaS stanno cambiando questa percezione. Nonostante lo sviluppo di schemi sia ancora più gravoso rispetto alle offerte di database NoSQL, i database relazionali stanno diventando più flessibili man mano che migrano agli ambienti cloud.

Riduzione della ridondanza 

I database relazionali possono eliminare la ridondanza in due modi. Il modello relazionale stesso riduce la ridondanza dei dati tramite un processo noto come normalizzazione. Come già detto, una tabella clienti dovrebbe registrare solo record univoci di informazioni sui clienti, anziché duplicare tali informazioni per più transazioni.

Le procedure memorizzate aiutano anche a ridurre il lavoro ripetitivo. Ad esempio, se l'accesso al database è limitato a determinati ruoli, funzioni o team, una procedura memorizzata può aiutare a gestire il controllo degli accessi. Queste funzioni riutilizzabili consentono agli sviluppatori di guadagnare tempo da dedicare ad attività di maggiore impatto.

Facilità di backup e disaster recovery 

I database relazionali sono transazionali: garantiscono che lo stato dell'intero sistema sia coerente in qualsiasi momento. La maggior parte dei database relazionali offre opzioni di esportazione e importazione semplici, rendendo il backup e il ripristino estremamente facili. Queste esportazioni possono avvenire anche mentre il database è in esecuzione, facilitando il ripristino in caso di errore. I moderni database relazionali basati sul cloud possono eseguire il mirroring continuo, rendendo la perdita di dati al momento del ripristino misurabile in pochi secondi o meno. La maggior parte dei servizi gestiti nel cloud consente di creare repliche di lettura, come in IBM® Cloud Databases for PostgreSQL. Queste repliche di lettura consentono di archiviare una copia di sola lettura dei dati in un data center sul cloud. Le repliche possono essere promosse anche a istanze di lettura/scrittura per il disaster recovery.