Il modello a grafi e i benefici per il tuo business

Quando pensi alle basi di dati che hai in azienda, nella maggioranza dei casi starai pensando ai classici database relazionali.

Questo modello, inventato negli anni settanta, si traduce nell’implementazione di tabelle formate da colonne e da righe collegate tra loro.

Da allora le necessità e i modelli di business sono cambiati al punto che abbiamo dovuto trovare anche altri sistemi per descrivere l’informazione.

Questo non significa che i database relazionali siano diventati obsoleti, anzi! Oggi sono sempre alla base della maggioranza dei processi di business!

Ma si è visto che in alcuni casi specifici si doveva ricorrere ad altro. Hai anche tu la necessità di gestire relazioni molto complesse? Hai necessità di descrivere la dipendenza di oggetti in modo flessibile ed espandibile? Allora questo articolo fa per te, perchè potresti guadagnarci la soluzione alle tue necessità di business.

Cosa è un modello a grafi?

Hai mai sentito parlare di basi di dati a grafi? Oppure di “graph database”? Se la tua risposta è no, allora continua a leggere qui sotto. Se la risposta invece è positiva, potresti comunque trovare spunti interessanti (anche con alcuni esempi di codice).

Un database a grafo è una tipologia di base di dati che utilizza un concetto di “nodi” che sono collegati tra di loro da “archi” per rappresentare l’informazione.

Ad esempio si può utilizzare questo modello per rappresentare le relazioni esistenti tra più persone. Supponi di avere un numero “x” di persone, sarai d’accordo con me che possono esistere diverse relazioni tra di loro: ad esempio potresti voler descrivere le relazioni di amicizia tra di loro (Tizio è amico di Caio e Sempronio). Oppure voler rappresentare chi segue gli aggiornamenti di un’altra persona (Caio segue il feed di Sempronio). O ancora voler evidenziare eventuali parentele (Tizio è fratello di Caio), e tanto altro.

Alla base ci sono i nodi, le entità. Nel nostro esempio ogni nodo rappresenta una persona.

Esistono poi gli archi, dove ogni arco rappresenta un tipo di relazione.

Potremmo poi aggiungere ancora altri tipi di nodi, ad esempio le città. Quindi potremmo voler descrivere chi ha visitato le città e se gli sono piaciute, e via dicendo…

Così andiamo a costruire quello che si chiama knowledge graph o “grafo della conoscenza.”

Quali problemi risolve questo approccio?

Questa soluzione è decisamente più flessibile di un classico database relazionale ma non significa che sia sempre la scelta migliore. Un database relazionale ad esempio sarà adatto per lavorare schemi di dati fissi e molto grandi. Mentre un database a grafo sarà più indicato la dove si voglia descrivere una situazione mutevole nel tempo.

Ad esempio i database a grafi vengono usati per costruirvi sopra social network (anche aziendali) dove si vogliono evidenziare le relazioni tra le persone.

Ma sono anche la soluzione per applicazioni anti frode (fraud detection), dove è necessario analizzare le relazioni che intercorrono tra soggetti diversi. Si potrebbe usare questa struttura per individuare persone differenti che vivono in luoghi differenti ma che utilizzano il solito indirizzo mail (uno dei due evidentemente ha rubato le credenziali all’altro, in modo molto semplicistico).

Ancora si potrebbe voler realizzare un grafo della conoscenza per un motore di ricerca semantico (esempio: se un utente cerca un’automobile di un determinato produttore lo si potrebbe portare a visitare informazioni di altre aziende che producono automobili).

O infine si potrebbe convertire una distinta base di un prodotto (ad esempio, una bicicletta e tutte le parti e insiemi che la compongono) in un grafo in modo da evidenziare le relazioni tra gli assiemi meccanici e i prodotti che li compongono.

Questi sono solo alcuni esempi, ma se anche tu sei nella condizione di dover rappresentare relazioni molto complesse, potresti pensare a questo approccio. E sopratutto chiedimi un consiglio gratuito!

Tutto molto bello, ma vogliamo fare qualche esempio di codice?

Ebbene per fare qualche esempio pratico utilizzerò la versione di anteprima di SQL Server 2019.

SQL Server già nelle versione 2017 introduceva il supporto ai grafi, e la possibilità di interrogarli utilizzando la sintassi T-SQL a cui siamo abituati. Infatti la stessa Microsoft afferma che tutto quello che vogliamo fare con i grafi lo si può fare anche con il modello relazionale, è vero, ma sarebbe molto più complesso ed inefficiente.

Di seguito lo script per creare alcuni dati di prova.

create database GraphDemo
go
use GraphDemo
go

drop table if exists dbo.Persons;
create table dbo.Persons (
    Id int identity(1,1) not null,
    FullName varchar(255)
) as node;
go 

drop table if exists dbo.Cities;
create table dbo.Cities (
    CityName varchar(255)
) as node;
go

drop table if exists dbo.Visits;
create table dbo.Visits (
    Id int identity primary key,
    VisitDate datetime
) as edge;
go

drop table if exists dbo.Likes;
create table dbo.Likes (
    Id int identity primary key
) as edge;
go

-- popoliamo i nodi
insert into dbo.Persons (FullName) values ('Daniele Perugini'), ('Debora Rinaldi'), ('Giuseppe Garibaldi'), ('Franklin Delano Roosvelt');
insert into dbo.Cities (CityName) values ('Pisa'), ('Roma'), ('Tirana'), ('Barcellona');

-- popoliamo gli archi: città visitate
insert into dbo.Visits($from_id, $to_id, VisitDate) values (
(select $node_id from dbo.Persons where FullName = 'Daniele Perugini'),
(select $node_id from dbo.Cities where CityName = 'Tirana'),
'20180301');

insert into dbo.Visits($from_id, $to_id, VisitDate) values (
(select $node_id from dbo.Persons where FullName = 'Daniele Perugini'),
(select $node_id from dbo.Cities where CityName = 'Barcellona'),
'20180301');

insert into dbo.Visits($from_id, $to_id, VisitDate) values (
(select $node_id from dbo.Persons where FullName = 'Giuseppe Garibaldi'),
(select $node_id from dbo.Cities where CityName = 'Roma'),
'18670101');

insert into dbo.Visits($from_id, $to_id, VisitDate) values (
(select $node_id from dbo.Persons where FullName = 'Debora Rinaldi'),
(select $node_id from dbo.Cities where CityName = 'Pisa'),
'20130914');

-- popoliamo gli archi: i 'likes'
insert into dbo.Likes($from_id, $to_id) values (
(select $node_id from dbo.Persons where FullName = 'Daniele Perugini'),
(select $node_id from dbo.Persons where FullName = 'Debora Rinaldi'));

insert into dbo.Likes($from_id, $to_id) values (
(select $node_id from dbo.Persons where FullName = 'Debora Rinaldi'),
(select $node_id from dbo.Persons where FullName = 'Franklin Delano Roosvelt'));

insert into dbo.Likes($from_id, $to_id) values (
(select $node_id from dbo.Persons where FullName = 'Debora Rinaldi'),
(select $node_id from dbo.Cities where CityName = 'Barcellona'));

Come vedi le tabelle Persons e Cities sono state create con l’attributo “as node” ad indicare che rappresentano un nodo.

Le tabelle Visits e Likes che invece rappresentano delle relazioni sono state create con l’attributo “as edge”.

Così facendo SQL Server creerà la struttura sottostante (alcune colonne aggiuntive) per supportare l’utilizzo dei grafi. Di seguito vediamo la struttura di un nodo, ma anche gli archi avranno una struttura aggiuntiva.

Come puoi vedere c’è una colonna in più che non useremo direttamente ma serve all’engine di SQL Server per gestire il nodo

Inoltre come hai visto nello script precedente per inserire le relazioni dobbiamo usare le colonne $from_id, $to_id e $node_id che non avevamo creato e che ha fatto SQL Server per noi.

Ma come eseguire alcune query?

Ecco un esempio di seguito.

SELECT
    Person1.FullName AS Person_1_Name, 
    Person2.FullName AS Destination,
    'Likes person' as RelationType
FROM
    Persons AS Person1,
    Likes AS Likes,
    Persons AS Person2
WHERE 1=1 
    AND MATCH(Person1-(Likes)->Person2)
    AND Person1.FullName = 'Debora Rinaldi'

UNION ALL 

SELECT
    Person.FullName AS Person_1_Name, 
    City.CityName AS Destination,
    'Likes city' as RelationType
FROM
    Persons AS Person,
    Likes AS Likes,
    Cities AS City
WHERE 1=1 
    AND MATCH(Person-(Likes)->City)
    AND Person.FullName = 'Debora Rinaldi'

Come vedi la “magia” sta nella clausola MATCH della condizione WHERE. In questa clausola si descrive il tipo di relazione che si vuole ricercare. Ma questa è suolo una prima banale query per analizzare i dati.

Ed il risultato è il seguente:

Ecco il risultato della query precedente

Da questa query ad esempio si evince come il solito tipo di relazione (“likes”) sia diretta verso nodi di tipo diverso (in un caso una persona, nell’altro una città).

Ma potremmo ad esempio voler esplorare il grafo di “likes” che si genera partendo da “Daniele Perugini” con la seguente query ricorsiva:

with Fmly
AS
(
    SELECT 
        r1.FullName AS TopNode,
        r2.FullName AS ChildNode,
        CAST(CONCAT(r1.FullName,' -> ',r2.FullName) AS varchar(250)) AS Output,
        r1.$node_id AS parentid, 
        r2.$node_id as bottomnode,
        1 as Tree
    FROM Persons r1 
    JOIN Likes e ON e.$from_id = r1.$node_id 
    JOIN Persons r2 ON r2.$node_id = e.$to_id AND r1.FullName IN( 'Daniele Perugini')

    UNION ALL

    SELECT 
        c.ChildNode,
        r.FullName,
        CAST(CONCAT(c.Output,' -> ',r.FullName) AS varchar(250)),
        c.bottomnode,
        r.$node_id,
        Tree + 1
    FROM Fmly c
    JOIN Likes e ON e.$from_id = c.bottomnode
    JOIN Persons r ON r.$node_id = e.$to_id
)
SELECT output FROM Fmly	

Ed ecco il risultato:

Ma alla fine, che vantaggi ne traggo?

A questo punto come puoi vedere le possibilità sono davvero infinite e ti permettono di esplorare in modo flessibile il grafo di relazioni tra tutti i nodi.

In SQL Server 2019 è stata aggiunta una funzione per il processing dei grafi chiamata “SHORTEST_PATH”, ma te ne parlerò in un altro articolo.

Hai anche tu situazioni dove l’imperativo è analizzare un gruppo di relazioni complesse? Allora questo approccio potrebbe fare al caso tuo.

Un approccio simile può mettere in luce particolari del tuo business di cui non eri a conoscenza, oppure dare evidenza di opportunità che non erano così scontate. Insomma, ti darà una visione decisamente più chiara delle parti che lo compongono.

L’importante è NON IMPROVVISARE!!

Nel mio percorso ho raccolto molte informazioni interessanti in merito agli argomenti di cui ti ho parlato in questo articolo, ed ho scritto un libro “Why Your Data Matter”.

Essendo il frutto della mia passione ed esperienza diretta, ho scelto di mettere questo libro gratuitamente a disposizione di tutti gli IT Manager ed i CIO delle aziende che come te vogliono ottenere grandi risultati dalle loro scelte e dal loro lavoro (evitando di trovarsi in situazioni scomode e da risolvere con urgenza).

Ti invito a leggere le prime pagine scaricandole!
Se poi ti piacerà sarò felice di inviartene una copia GRATUITA direttamente nel tuo ufficio.  

Clicca qui per scaricare l’estratto del mio libro (se ti piacerà te lo invierò in formato cartaceo!) ==> il mio libro