Condividi tramite

Tipi di grafo GQL

Annotazioni

Questa funzionalità è attualmente disponibile in anteprima pubblica. Questa anteprima viene messa a disposizione senza contratto di servizio e non è consigliata per i carichi di lavoro di produzione. Alcune funzionalità potrebbero non essere supportate o potrebbero presentare funzionalità limitate. Per altre informazioni, vedere le Condizioni supplementari per l'uso delle anteprime di Microsoft Azure.

Un tipo di grafo descrive la struttura del grafo definendo quali nodi e archi possono esistere. Si pensi a un progetto o a uno schema, che specifica la forma di nodi e archi nel grafico in termini di etichette e proprietà. Per i bordi (le connessioni tra nodi), specifica anche quali tipi di archi possono connettere i tipi di nodi. Se si ha familiarità con i database relazionali, i tipi di grafo funzionano in modo analogo al modo in cui i diagrammi ER descrivono le tabelle e le relazioni di chiave esterna.

Importante

Questo articolo utilizza esclusivamente il dataset di esempio dei grafi dei social network.

I tipi di grafo offrono diversi vantaggi principali:

  • Convalida dei dati: verificare che il grafico contenga solo combinazioni di nodi e bordi validi.
  • Ottimizzazione query: consente al motore di query di comprendere la struttura dei dati per ottenere prestazioni migliori.
  • Documentazione: usare come una specifica chiara della struttura del grafo per sviluppatori e analisti.

Annotazioni

Questo articolo presenta i tipi di grafo concettualmente e ne illustra la definizione usando la sintassi definita nello standard GQL. Tuttavia, questa sintassi non è attualmente supportata direttamente per graph in Microsoft Fabric.

Strutturalmente, un tipo di grafo definisce i tipi di nodo consentiti e i tipi di arco dei grafici del tipo di grafo, nonché vincoli aggiuntivi che limitano ulteriormente tali grafici.

Annotazioni

I tipi di grafo vengono definiti assegnando un set di definizioni di tipo nodo, tipo di arco e vincolo. La modifica dell'ordine di queste definizioni non modifica il tipo di grafo definito.

Definire i tipi di nodo

Un tipo di nodo specifica quali etichette e tipi di proprietà possono avere i nodi. Ecco come specificare un tipo di nodo di base:

(:Organization => { 
  id :: UINT64 NOT NULL, 
  name :: STRING, 
  url :: STRING 
})

In questo esempio viene creato un tipo di nodo che definisce i nodi con:

  • OrganizationEtichetta .
  • Proprietà id che contiene valori integer senza segno e non può essere Null.
  • Proprietà name che contiene valori stringa (può essere Null).
  • Proprietà url che contiene valori stringa (può essere Null).

L'operatore :: specifica il tipo di dati per ogni proprietà, mentre NOT NULL indica che la proprietà deve avere sempre un valore.

Annotazioni

NOT NULL è considerato parte del tipo in GQL, che differisce da SQL.

I tipi di nodo possono anche essere più complessi, con più proprietà e tipi di dati:

(:Person => {
    id :: UINT64 NOT NULL,
    creationDate :: ZONED DATETIME,
    firstName :: STRING,
    lastName :: STRING,
    gender :: STRING,
    birthday :: UINT64,
    browserUsed :: STRING,
    locationIP :: STRING
})

Tipi di nodo con più etichette

I nodi possono avere più etichette per supportare l'ereditarietà e la categorizzazione. È possibile specificare più etichette per un tipo di nodo, ma un'etichetta (etichetta chiave) deve identificare in modo univoco il tipo di nodo (se viene specificata una sola etichetta, viene visualizzata l'etichetta chiave del tipo di nodo).

Si consideri ad esempio:

(:University => :Organization),

(:Company => :Organization)

University In questo caso e Company sono le etichette chiave dei due tipi di nodo definiti, mentre Organization è un'etichetta secondaria condivisa da entrambi i tipi. Si noti che l'etichetta chiave e le etichette secondarie sono separate da => in ogni tipo di nodo. Questo approccio crea una gerarchia di tipi in cui sia le università che le aziende sono tipi di organizzazioni.

Poiché le etichette chiave identificano i tipi di nodo, le proprietà dei tipi di nodo identificate dalle etichette secondarie vengono ereditate automaticamente quando si usa questa sintassi. Pertanto, è possibile comprendere la sintassi precedente per definire in modo efficace i tipi di nodo seguenti:

(:University => :Organization {
  id :: UINT64 NOT NULL, 
  name :: STRING, 
  url :: STRING 
}),

(:Company => :Organization {
  id :: UINT64 NOT NULL, 
  name :: STRING, 
  url :: STRING 
})

Annotazioni

Le etichette chiave sono essenziali quando si definiscono le gerarchie dei tipi di nodo. Consentono al sistema di comprendere il tipo di nodo a cui si fa riferimento quando più tipi condividono le stesse etichette.

Risparmiare tempo con i tasti di scelta rapida per l'ereditarietà

Le etichette e le proprietà ripetute dai tipi di nodo padre diventano noiose e soggette a errori. Graph in Microsoft Fabric fornisce l'operatore += in modo da poter specificare solo le etichette e i tipi di proprietà aggiuntivi (non inriti):

(:Post => :Message += {
    language :: STRING,
    imageFile :: STRING
})

Quando non vengono specificate proprietà aggiuntive, il grafico eredita tutte le proprietà necessarie dal tipo padre:

(:Comment => :Message)  -- Same as: (:Comment => :Message += {})

Usare i tipi di nodo astratti

È possibile definire i tipi di nodo esclusivamente per la compilazione di gerarchie, anche quando il grafico non contiene nodi concreti di quel tipo. I tipi di nodo astratti sono utili per la creazione di raggruppamenti concettuali e set di proprietà condivise. A questo scopo, è possibile definire un tipo di nodo come ABSTRACT nel grafico in Microsoft Fabric:

ABSTRACT (:Message => {
    id :: UINT64 NOT NULL,
    creationDate :: ZONED DATETIME,
    browserUsed :: STRING,
    locationIP :: STRING,
    content :: STRING,
    length :: UINT64
})

I tipi di nodo astratti non sono disponibili per il caricamento diretto del grafo, ma esistono solo per strutturare la gerarchia e definire le proprietà condivise. I tipi di nodo concreti che ereditano dai tipi astratti possono essere caricati con i dati.

Definire tipi e famiglie di archi

Un tipo di arco definisce l'etichetta chiave, i tipi di proprietà e i tipi di nodo endpoint per i bordi. Nei database a grafo i bordi rappresentano le connessioni tra i nodi. La definizione dei bordi indica al sistema quali relazioni sono consentite nel grafico:

(:Person)-[:knows { creationDate :: ZONED DATETIME }]->(:Person)

Questo tipo di arco definisce tutti i bordi con:

  • Etichetta (chiave) knows.
  • Proprietà creationDate che contiene ZONED DATETIME valori (timestamp insieme a un offset di fuso orario).
  • Endpoint di origine e di destinazione che devono essere Person entrambi nodi.

La freccia -> indica la direzione del bordo, dall'origine alla destinazione. Queste informazioni direzionali sono fondamentali per comprendere la semantica del grafo.

Ecco altri esempi di tipi di arco:

(:Person)-[:studyAt { classYear :: UINT64 }]->(:University)
(:Person)-[:workAt { workFrom :: UINT64 }]->(:Company)

È sufficiente specificare le etichette chiave (Person, Universityo Company) per i tipi di nodo endpoint. Non è necessario ripetere la definizione completa del tipo di nodo. Il sistema risolve questi riferimenti alle definizioni del tipo di nodo completo.

Famiglie di tipi di bordi del grafo

Le etichette delle chiavi dei bordi del grafo funzionano in modo diverso dalle etichette delle chiavi del nodo. È possibile avere più tipi di arco con la stessa etichetta chiave in un tipo di grafo, purché abbiano le stesse etichette e gli stessi tipi di proprietà. Tuttavia, due tipi di arco con la stessa etichetta chiave devono essere diversi in almeno un tipo di nodo endpoint. Viene chiamato un set di tipi di arco con la stessa etichetta chiave di una famiglia di tipi di arco.

Questo concetto consente di modellare lo stesso tipo di relazione tra diversi tipi di entità.

Esempio:

(:City)-[:isPartOf]->(:Country),
(:Country)-[:isPartOf]->(:Continent)

Entrambi i tipi di arco usano l'etichetta isPartOf , ma connettono tipi diversi di nodi, formando una famiglia di tipi di arco che rappresenta relazioni di contenimento gerarchico.

Usa la sottotipizzazione dei nodi nelle definizioni dei tipi di spigoli

Dover spiegare ogni possibile tipo di spigolo può essere un po' noioso. Per semplificare, è anche possibile definire famiglie di tipi di spigoli che si allineano con la gerarchia dei tipi di nodi implicita dai loro endpoint.

Esempio:

-- Node types
ABSTRACT (:Message { ... }),
(:Post => :Message { ... }),
(:Comment => :Message { ... }),

-- All edge types (x)-[:hasTag]->(:Tag) where x is at least a (:Message)
(<:Message)-[:hasTag]->(:Tag)

Questo definisce implicitamente i seguenti tipi di archi:

(:Post)-[:hasTag]->(:Tag) 
(:Comment)-[:hasTag]->(:Tag)

Tipi di proprietà supportati

Quando si definisce un tipo di proprietà, il tipo di valore della proprietà deve essere uno supportato dal grafico in Microsoft Fabric. La scelta dei tipi di dati corretti è importante per l'efficienza di archiviazione e le prestazioni delle query.

Ecco i tipi di dati che è possibile usare per i valori delle proprietà:

  • INT (anche: INT64)
  • UINT (anche: UINT64)
  • STRING
  • BOOL (anche: BOOLEAN)
  • DOUBLE (anche: FLOAT64, FLOAT)
  • T NOT NULL, dove T è uno dei tipi di dati precedenti.
  • LIST<T> e LIST<T> NOT NULL, dove T è uno dei tipi di dati precedenti.

Per informazioni complete sui tipi valore, vedere Valori e tipi di valore GQL.

Importante

Tutti i tipi di proprietà con lo stesso nome che si verificano in un tipo di nodo o in un tipo di bordo di un determinato tipo di grafo devono specificare lo stesso tipo di valore della proprietà. L'unica eccezione: può differire se includono il valore Null. Ad esempio, in base a questa regola, un tipo di grafo con (:A { id :: STRING }), (:B { id :: STRING NOT NULL}) sarebbe valido, mentre un tipo di grafo con (:A { id :: STRING }), (:B { id :: INT}) non sarebbe valido.

Configurare i vincoli di chiave del nodo

I vincoli di chiave del nodo definiscono il modo in cui ogni nodo del grafico viene identificato in modo univoco da uno o più dei relativi valori di proprietà. I vincoli di chiave funzionano come vincoli di chiave primaria nei database relazionali e garantiscono l'integrità dei dati. Un vincolo di chiave del nodo può essere destinato ai nodi tra più tipi di nodo, che consentono di definire le chiavi del nodo per intere gerarchie concettuali.

La comprensione dei vincoli chiave è fondamentale perché:

  • Garantire l'univocità: impedire nodi duplicati in base alla logica di business.
  • Abilitare ricerche efficienti: consente al sistema di ottimizzare le query che cercano nodi specifici.
  • Supportare l'integrazione dei dati: fornire un modo stabile per fare riferimento ai nodi tra origini dati diverse.

Importante

Per il grafico in Microsoft Fabric, un vincolo di chiave deve vincolare ogni nodo.

Funzionamento dei vincoli di chiave del nodo

È possibile specificare vincoli di chiave del nodo nel tipo di grafo. Ogni vincolo di chiave del nodo presenta caratteristiche specifiche che lo rendono efficace:

Componenti di un vincolo di chiave del nodo:

  • Ha un nome univoco all'interno del tipo di grafo per un riferimento semplice.
  • Definisce i nodi di destinazione usando un modello di vincolo semplice che specifica i nodi a cui si applica il vincolo.
  • Definisce le proprietà che formano il valore della chiave univoca.

Esempio:

CONSTRAINT person_pk
  FOR (n:Person) REQUIRE n.id IS KEY

Questa sintassi crea un vincolo di chiave del nodo chiamato person_pk per tutti i nodi con almeno l'etichetta Person . Il vincolo garantisce che ogni nodo del grafico venga identificato in modo univoco dalla relativa id proprietà. Nessun nodo con l'etichetta Person può avere lo stesso id valore.

È anche possibile definire chiavi composte che usano più proprietà insieme per garantire l'univocità usando la CONSTRAINT ... FOR ... REQUIRE (n.prop1, n.prop2) IS KEY sintassi .

Importante

Proprietà usate nei vincoli di chiave:

  • Non può essere null
  • Deve essere dichiarato come NOT NULL nei tipi di nodo e nei tipi di arco di destinazione del vincolo di chiave

Contenuti correlati

  • Last updated on