Cos'è un database relazionale?
Scopri come funzionano i database relazionali e come si confrontano con altre opzioni di storage dei dati
Su uno schermo con uno sfondo blu ci sono numeri e lettere, che rappresentano un database complesso
Cos'è un database relazionale?

Un database relazionale organizza i dati in righe e colonne, che nel loro insieme formano una tabella. I dati sono in genere strutturati su più tabelle, che possono essere unite tramite una chiave primaria o una chiave esterna. Questi identificatori univoci rappresentano le diverse relazioni che esistono tra le tabelle e queste relazioni sono generalmente illustrate attraverso diversi tipi di modelli di dati. Gli analisti utilizzano le query SQL per combinare diversi punti dati e riepilogare le prestazioni aziendali, consentendo alle organizzazioni di ottenere insight, ottimizzare i flussi di lavoro e identificare nuove opportunità.

Ad esempio, immagina che la tua azienda gestisca una tabella di database con le informazioni sui clienti e che contenga dati aziendali a livello di account. Potrebbe esserci anche una tabella diversa, che descrive tutte le singole transazioni che si riferiscono a tale account. Insieme, queste tabelle possono fornire informazioni su diverse aziende che acquistano un prodotto software specifico.

Le colonne (o i campi) della tabella dei clienti potrebbero essere ID clienteNome aziendaIndirizzo aziendaSettore eccetera; le colonne di una tabella delle transazioni potrebbero essere Data transazioneID clienteImporto transazioneMetodo di pagamento, eccetera. Le tabelle possono essere unite con il campo ID cliente comune. È quindi possibile interrogare la tabella per produrre utili report, ad esempio report sulle vendite per settore o azienda, che possono essere utili per modellare le comunicazioni con i potenziali clienti.

I database relazionali sono anche tipicamente associati ai database transazionali, che eseguono comandi o transazioni, collettivamente. Un esempio popolare che viene utilizzato per illustrare queste transazioni è un bonifico bancario. Si preleva un importo definito da un conto, e poi lo si deposita in un altro. L'importo totale del denaro viene prelevato e depositato e questa transazione non può essere in alcun modo parziale. Le transazioni hanno proprietà specifiche. Rappresentate dall'acronimo, ACID, le proprietà ACID sono definite come:

  • Atomicità: Tutte le modifiche ai dati vengono eseguite come se fossero una singola operazione. Ossia, o si eseguono tutte le modifiche o non se ne esegue nessuna.
  • Congruenza: I dati rimangono in uno stato coerente da stato e fino alla fine, consolidando l'integrità dei dati.
  • Isolamento: Lo stato intermedio di una transazione non è visibile ad altre transazioni e, di conseguenza, le transazioni eseguite contemporaneamente appaiono come serializzate.
  • Durata: Dopo il corretto completamento di una transazione, le modifiche ai dati persistono e non vengono annullate, anche in caso di guasto del sistema.

Queste proprietà consentono un'elaborazione affidabile delle transazioni.

Confronto tra database relazionale e sistema di gestione dei database relazionali

Mentre un database relazionale organizza i dati sulla base di un modello di dati relazionale, un sistema di gestione dei database relazionali (relational database management system, RDBMS) rappresenta un riferimento più specifico al software di database sottostante che consente agli utenti di gestirlo. Questi programmi consentono agli utenti di creare, aggiornare, inserire o eliminare dati nel sistema e forniscono:

  • Struttura dei dati
  • Accesso multi-utente
  • Controllo privilegi
  • Accesso alla Rete

Esempi di sistemi RDBMS popolari includono MySQL, PostgreSQL e IBM DB2. Inoltre, un sistema di database relazionale differisce da un sistema di gestione dei database di base (basic database management system, DBMS) in quanto memorizza i dati nelle tabelle mentre un DBMS memorizza le informazioni come file.

Cos'è l'SQL?

Inventato da Don Chamberlin e Ray Boyce in IBM, lo Structured Query Language (SQL) è il linguaggio di programmazione standard per l'interazione con i sistemi di gestione di database relazionali, che consente ad un amministratore di database di aggiungere, aggiornare o eliminare facilmente righe di dati. Originariamente noto come SEQUEL, è stato semplificato in SQL per questioni legate alla registrazione del marchio. Le query SQL consentono inoltre agli utenti di recuperare i dati dai database utilizzando solo poche righe di codice. Data questa relazione, è facile capire perché a volte i database relazionali vengono anche chiamati "database SQL".  

Usando l'esempio precedente, con il seguente codice potresti creare una query che ti consenta di trovare le prime 10 transazioni per azienda in un anno specifico:

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

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

La capacità di unire i dati in questo modo ci permette di ridurre la ridondanza nei nostri sistemi di dati, consentendo ai team di dati di mantenere un'unica tabella principale per tutti i clienti anziché duplicare queste informazioni quando si effettua un'altra transazione. Per saperne di più, Don, nel suo documento riportato qui (link esterno a IBM), descrive nel dettaglio la storia dell'SQL.

Breve storia dei database relazionali

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) consentivano agli utenti di organizzare grandi quantità di dati. Tuttavia, erano complessi, spesso proprietari di una particolare applicazione e limitati nelle modalità di rilevamento all'interno dei dati. Queste limitazioni alla fine portarono il ricercatore IBM, Edgar F. Codd, a pubblicare nel 1970 un documento (link esterno a IBM) (PDF, 1,5 MB), 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 specifiche conoscenze informatiche. Egli propose di organizzare i dati in base a relazioni significative come tuple o coppie di attributi-valori. Gli insiemi di tuple erano indicati come relazioni, che alla fine consentivano l'unione di dati tra tabelle.

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

Nel 1983, IBM ha introdotto la famiglia DB2 di database relazionali, così chiamata perché era la seconda famiglia di software di gestione dei 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 pone le basi per le applicazioni di machine learning.

Per scoprire di più sulla storia di IBM, fai clic qui.

Confronto tra database relazionali e non relazionali

Mentre i database relazionali strutturano i dati in un formato tabulare, i database non relazionali non hanno uno schema di database così rigido. I database non relazionali, infatti, organizzano i dati in modo diverso in base al tipo di database. Indipendentemente dal tipo, ciascun database non relazionale mira a risolvere i problemi di flessibilità e scalabilità dei modelli relazionali che non sono ideali per formati di dati non strutturati, come testo, video e immagini. Questi tipi di database includono:

  • Archivio key-value: Questo modello di dati senza schema è organizzato in un dizionario di coppie chiave-valore, in cui ogni elemento ha una chiave e un valore. La chiave potrebbe essere qualcosa di simile a quanto presente in un database SQL, come un ID del carrello della spesa, mentre il valore è un array di dati, come ogni singolo articolo nel carrello della spesa dell'utente. Viene comunemente utilizzato per la memorizzazione nella cache e l'archiviazione delle informazioni sulla sessione utente, come i carrelli della spesa. Tuttavia, non è l'ideale quando è necessario estrarre più record alla volta. Redis e Memcached sono esempi di database open source con questo modello di dati.
  • Archivio Document: Come suggerisce il nome, i database document archiviano i dati come documenti. Possono essere utili nella gestione di dati semi-strutturati e i dati vengono generalmente archiviati nei formati JSON, XML o BSON. Ciò mantiene i dati insieme quando vengono utilizzati nelle applicazioni, riducendo la quantità di traduzione necessaria per utilizzare i dati. Gli sviluppatori acquisiscono anche una maggiore flessibilità poiché gli schemi di dati non devono necessariamente corrispondere tra i documenti (ad es. name rispetto a first_name). Tuttavia, ciò può risultare problematico per transazioni complesse, portando al danneggiamento dei dati. I casi d'uso più diffusi dei database di documenti includono sistemi di gestione dei contenuti e 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 specifiche colonne di cui hanno bisogno senza allocare memoria aggiuntiva per dati irrilevanti. Questo database tenta di risolvere le carenze legate agli archivi key-value e document, ma poiché può risultare un sistema più complesso da gestire, il suo utilizzo non è consigliato per i team e i progetti più recenti. Apache HBase e Apache Cassandra sono esempi di database open source wide-column. Apache HBase è basato su Hadoop Distributed Files System che fornisce un modo per archiviare set di dati sparsi, che è comunemente usato in molte applicazioni di big data. Apache Cassandra, al contrario, è stato progettato per gestire grandi quantità di dati su più server e cluster che si estendono su più data center. È stato utilizzato in diversi casi d'uso, come ad esempio per siti Web delle reti social e per l'analisi dei dati in tempo reale.
  • Archivio graph: Questo tipo di database ospita in genere i dati di un grafico della conoscenza. Gli elementi dati sono 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 Graph vengono utilizzati per archiviare e gestire una rete di connessioni tra gli elementi all'interno del grafico. Neo4j (link esterno a IBM ), un servizio di database basato su grafici su Java con un'edizione della community open source in cui gli utenti possono acquistare licenze per il backup online ed estensioni per l'high availability o una versione con licenza a pacchetto con backup ed estensioni inclusi.

I database NoSQL danno priorità alla disponibilità rispetto alla congruenza.

Quando i computer vengono eseguiti su una rete, invariabilmente devono decidere se dare priorità a risultati che siano congruenti (in cui ogni risposta è sempre la stessa) o ad un elevato tempo di attività, detto "disponibilità". Questo è noto come "Teorema CAP", dove "CAP" sta per Consistency, Availability o Partition Tolerance, ossia Coerenza, Disponibilità o 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 che ricevi da una query potrebbero non essere corrette di qualche secondo, forse fino a mezzo minuto. Sui siti di social media, questo significa visualizzare una vecchia foto del profilo quando quella più nuova è stata caricata solo qualche istante prima. L'alternativa potrebbe essere un timeout o un errore. Di contro, nelle transazioni bancarie e finanziarie, un errore ed un nuovo invio potrebbero essere preferibili a informazioni obsolete e non corrette.

Per una resoconto completo delle differenze tra SQL e NoSQL, consulta "SQL vs. NoSQL Databases: What's the Difference?"

Vantaggi dei database relazionali

Il vantaggio principale dell'approccio del database relazionale è la capacità di creare informazioni significative unendo le tabelle. Unire le tabelle ti consente di comprendere le relazioni tra i dati o come si connettono le tabelle. SQL consente di contare, aggiungere, raggruppare e anche combinare le query. SQL può eseguire delle funzioni matematiche e di totali parziali e delle trasformazioni logiche di base. Gli analisti possono ordinare i risultati in base alla data, al nome o a qualsiasi colonna. Queste funzioni fanno dell'approccio relazionale il singolo strumento di query oggi più diffuso in ambito aziendale.

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

Facilità di utilizzo

In virtù della loro lunga presenza sul mercato, attorno ai database relazionali si è sviluppata più di una community, che ne perpetua parzialmente il continuo utilizzo. SQL semplifica inoltre il recupero di set di dati da più tabelle e l'esecuzione di semplici trasformazioni come il filtraggio e l'aggregazione. L'uso di indici all'interno di database relazionali consente inoltre di individuare rapidamente queste informazioni senza dover cercare ogni riga nella tabella selezionata.

Mentre i database relazionali sono stati storicamente visti come un'opzione di storage dei dati più rigida e poco flessibile, i progressi nella tecnologia e le opzioni DBaaS stanno cambiando questa percezione. Sebbene vi sia ancora più sovraccarico nello sviluppo di schemi rispetto alle offerte di database NoSQL, i database relazionali stanno diventando più flessibili man mano che migrano verso ambienti cloud.

Ridondanza ridotta 

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 evidenziato in precedenza, una tabella clienti dove registrare solo record univoci delle informazioni sui clienti rispetto alla duplicazione di queste informazioni per più transazioni.

Anche le procedure memorizzate consentono di 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 liberano tempo per lo sviluppo dell'applicazione per affrontare il lavoro ad alto impatto.

Facilità di backup e disaster recovery 

I database relazionali sono transazionali, essi garantiscono che lo stato dell'intero sistema sia coerente in qualsiasi momento. La maggior parte dei database relazionali offre facili opzioni di esportazione e importazione, rendendo molto semplici backup e ripristino. Queste esportazioni possono avere luogo anche mentre il database è in esecuzione, rendendo facile il ripristino in caso di malfunzionamento. I moderni database relazionali basati sul cloud possono eseguire un mirroring continuo, rendendo la perdita di dati in fase di ripristino misurabile in secondi, se non di meno. La maggior parte dei servizi gestiti sul cloud ti consente di creare delle repliche di lettura, come in IBM Cloud Databases for PostgreSQL. Queste repliche di lettura di consentono di archiviare una copia di sola lettura dei tuoi dati in un data center su cloud. Le repliche possono anche essere promosse a istanze di lettura/scrittura per il disaster recovery.

Soluzioni correlate
IBM Db2 on Cloud

Scopri Db2 on Cloud, un database cloud SQL completamente gestito e ottimizzato per prestazioni solide.

Esplora IBM Db2 on Cloud
IBM Cloud Databases for PostgreSQL

Scopri PostgreSQL-as-a-service, predisposto per l'azienda con l'integrazione nativa nel cloud IBM.

Esplora IBM Cloud Databases for PostgreSQL
IBM Cloud Hyper Protect DBaaS

IBM Cloud Hyper Protect DBaaS è un ambiente database sul cloud altamente sicuro che ti consente di gestire più tipi di database tramite API standardizzate.

Esplora IBM Cloud Hyper Protect DBaaS
EDB Postgres Enterprise e Standard con IBM

Sviluppa ed esegui le applicazioni su un database con misure di sicurezza complete e di classe aziendale che è basato su PostgreSQL open source.

Esplora EDB Postgres Enterprise and Standard with IBM
Risorse Db2 and 50 Years of Relational Database Design

Risali agli albori del DB2.

Passa alla fase successiva

IBM supporta le versioni ospitate sul cloud di diversi database relazionali. IBM Db2 on Cloud è un database relazionale commerciale tra i più importanti, sviluppato per assicurare solide prestazioni e fornire un'opzione di alta disponibilità con uno SLA di tempo di attività pari al 99,99%.

Scopri di più su IBM Db2 on Cloud