Quando si parla di Relational Database si fa riferimento ad una tipologia di database tabellari, il cui linguaggio standard è comunemente indicato come SQL e che vengono, per questo, definiti anche come SQL Database System. La loro peculiarità sta nell’essere fondati su di un sistema di tabelle correlate secondo il cd. Relational Model, ideato nel 1969 dal computer scientist inglese Edgar F. Codd e descritto nel suo paper intitolato: “A Relational Model of Data for Large Shared Data Banks“.
Nel modello di Codd, i dati vengono organizzati in una o più tabelle legate da relazioni e articolate in colonne e righe, con una “key” che identifica in modo univoco ogni riga.
In genere, ogni tabella/relazione rappresenta un “tipo di entità” (come cliente o prodotto). Le righe rappresentano istanze di quel tipo di entità e le colonne rappresentano i valori attribuiti a tale istanza. Questo tipo di database continua a rappresentare ancora oggi la soluzione più utilizzata negli scenari di business, anche se non sempre è la più idonea.
A partire dagli anni 2000 (risale a questo periodo il modello delle 3 V dei “Big Data”, coniato dall’analista Douglas Laney), l’aumentare della complessità e della quantità dei flussi di dati hanno determinato la necessità di creare strumenti di archiviazione alternativi.
Nei database tabellari, infatti, per esprimere una relazione tra entità è necessario creare nuove colonne di dati o nuove tabelle. Effettuare delle query volte ad evidenziare relazioni tra milioni di dati, in un sistema tabellare come quello relazionale, può diventare macchinoso e computazionalmente molto dispendioso.
I database non relazionali (ad esempio i NoSQL Databases e gli XML Databases) sono stati introdotti in quegli anni proprio allo scopo di ricostruire e gestire più rapidamente le connessioni esistenti tra entità appartenenti a data lake divenuti, oramai, di dimensioni “oceaniche”.
I Graph Databases, detti anche Semantic Databases, si sono così diffusi in tutti quegli ambiti caratterizzati da un importante e rapido afflusso di dati, come ad esempio nella fraud detection, nella social media analysis, nelle supply chain, nell’ottimizzazione dei motori di ricerca e nel campo dell’Internet of Things.
Ma qual è il loro funzionamento e cosa li rende così efficaci in questi ambiti?
I Graph Databases devono la loro denominazione al termine matematico “grafo”, utilizzato per esprimere un insieme di nodi (o vertici), ciascuno contenente informazioni (proprietà) e con relazioni (o bordi) tra i nodi.
L’elemento che li contraddistingue è quindi l’essere mappati su grafici composti da punti (che esprimono i nodi) e da linee (che esprimono i bordi). Il modello risulta essere così più flessibile ed in grado di mettere in evidenza le relazioni esistenti con query più rapide.
Mentre, infatti, nel database relazionale la velocità d’interrogazione dipende dal numero di tabelle che devono essere unite e dalla quantità di dati presente in ogni tabella interrogata, nel database a grafo la velocità delle query dipende solo dal numero di relazioni concrete e non dal volume totale dei dati presenti nel database.
D’altro canto, i database relazionali si rivelano ancora molto utili sotto diversi aspetti.
Innanzitutto, presentando i dati in forma tabellare sono facili da interpretare e comprendere, mentre i grafi possono non essere alla portata di tutti; inoltre, i database relazionali sono dotati di un linguaggio unificato per le query, ovvero un SQL standardizzato, per consentire lo sviluppo e l’esecuzione delle diverse applicazioni. I database a grafo, al contrario, sono dotati di linguaggi propri differenziati per ogni vendor proprietario del servizio: ad esempio Neo4j presenta il linguaggio Cypher, TigergGraph il GSQL e ArangoDB l’AQL.
In conclusione, si può facilmente immaginare che i database a grafo siano destinati a diffondersi sempre di più nelle aziende, date le loro elevate performances, ma non a soppiantare del tutto i database relazionali, che conservano comunque una loro utilità pratica in molti ambiti.
Autore: Claudia Paniconi | Responsabile Marketing DMBI
Photo by Clint Adair on Unsplash
