Del via

GQL-graftyper

Note

Denne funksjonen er for øyeblikket i offentlig forhåndsversjon. Denne forhåndsvisningen leveres uten en tjenesteavtale, og anbefales ikke for produksjonsarbeidsbelastninger. Enkelte funksjoner støttes kanskje ikke eller kan ha begrensede funksjoner. Hvis du vil ha mer informasjon, kan du se Supplerende vilkår for bruk for Microsoft Azure Previews.

En graftype beskriver grafens struktur ved å definere hvilke noder og kanter som kan eksistere. Tenk på det som en tegning eller et skjema – det angir formen på noder og kanter i grafen når det gjelder etiketter og egenskaper. For kanter (tilkoblingene mellom noder) angir den også hvilke typer kanter som kan koble sammen hvilke typer noder. Hvis du er kjent med relasjonsdatabaser, fungerer graftyper på samme måte som hvordan FEIL-diagrammer beskriver tabeller og sekundærnøkkelrelasjoner.

Viktig!

Denne artikkelen bruker utelukkende eksempeldatasett for sosiale nettverk.

Graftyper gir flere viktige fordeler:

  • Datavalidering: Kontroller at grafen bare inneholder gyldige node- og kantkombinasjoner.
  • Spørringsoptimalisering: Hjelp spørringsmotoren med å forstå datastrukturen for bedre ytelse.
  • Dokumentasjon: Fungerer som en klar spesifikasjon av grafens struktur for utviklere og analytikere.

Note

Denne artikkelen introduserer graftyper konseptuelt og illustrerer definisjonen ved hjelp av syntaksen som er definert i GQL-standarden. Denne syntaksen støttes imidlertid ikke direkte for grafen i Microsoft Fabric.

Strukturelt definerer en graftype tillatte nodetyper og kanttyper av graftyper av graftypen, samt flere begrensninger som ytterligere begrenser disse grafene.

Note

Graftyper defineres ved å gi et sett med nodetype, kanttype og betingelsesdefinisjoner. Hvis du endrer rekkefølgen på disse definisjonene, endres ikke graftypen som defineres.

Definer nodetyper

En nodetype angir hvilke etiketter og egenskapstyper nodene kan ha. Slik angir du en grunnleggende nodetype:

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

Dette eksemplet oppretter en nodetype som definerer noder med:

  • Etiketten Organization.
  • En id egenskap som inneholder heltallsverdier som ikke er signert, og som ikke kan være null.
  • En name egenskap som inneholder strengverdier (kan være null).
  • En url egenskap som inneholder strengverdier (kan være null).

Operatoren :: angir datatypen for hver egenskap, mens NOT NULL angir at egenskapen alltid må ha en verdi.

Note

NOT NULL regnes som en del av typen i GQL, som er forskjellig fra SQL.

Nodetyper kan også være mer komplekse, med flere egenskaper og datatyper:

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

Nodetyper med flere etiketter

Noder kan ha flere etiketter for å støtte arv og kategorisering. Du kan angi flere etiketter for en nodetype, men én etikett (nøkkeletiketten) må identifisere nodetypen unikt (Hvis bare én etikett er angitt, brukes dette til å være nøkkeletiketten for nodetypen).

Vurder som et eksempel:

(:University => :Organization),

(:Company => :Organization)

Her, University og Company er nøkkeletikettene for de to nodetypene som er definert, mens Organization er en sekundær etikett som deles av begge typer. Legg merke til hvordan nøkkeletiketten og sekundæretikettene er atskilt med => i hver nodetype. Denne tilnærmingen oppretter et typehierarki der både universiteter og firmaer er typer organisasjoner.

Siden nøkkeletiketter identifiserer nodetyper, arves egenskapene for nodetyper som identifiseres av sekundære etiketter automatisk når du bruker denne syntaksen. Derfor kan den forrige syntaksen forstås for effektivt å definere følgende nodetyper:

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

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

Note

Nøkkeletiketter er avgjørende når du definerer nodetypehierarkier. De hjelper systemet med å forstå hvilken nodetype du refererer til når flere typer deler de samme etikettene.

Spar tid med arvesnarveier

Gjentatte etiketter og egenskaper fra overordnede nodetyper blir kjedelig og feilutsatt. Graph i Microsoft Fabric gir operatoren += slik at du bare kan angi de ekstra (ikke arvede) etikettene og egenskapstypene:

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

Når ingen ekstra egenskaper er angitt, arver grafen alle nødvendige egenskaper fra den overordnede typen:

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

Bruk abstrakte nodetyper

Du kan definere nodetyper utelukkende for å bygge hierarkier, selv når grafen ikke inneholder betongnoder av denne typen. Abstrakte nodetyper er nyttige for å opprette begrepsmessige grupperinger og delte egenskapssett. For dette formålet kan du definere en nodetype som ABSTRACT i grafen i Microsoft Fabric:

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

Abstrakte nodetyper er ikke tilgjengelige for direkte innlasting av grafer – de finnes bare for å strukturere hierarkiet og definere delte egenskaper. Betongnodetyper som arver fra abstrakte typer, kan lastes inn med data.

Definer kanttyper og -familier

En kanttype definerer nøkkeletiketten, egenskapstypene og endepunktnodetypene for kanter. I grafdatabaser representerer kanter tilkoblinger mellom noder. Kantdefinisjonen forteller systemet hvilke relasjoner som er tillatt i grafen:

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

Denne kanttypen definerer alle kanter med:

  • (tast)-etiketten knows.
  • En creationDate egenskap som inneholder ZONED DATETIME verdier (tidsstempler sammen med en tidssoneforskyvning).
  • Kilde- og målendepunkter som begge må være Person noder.

Pilen -> angir retningen på kanten, fra kilde til mål. Denne retningsinformasjonen er avgjørende for å forstå grafens semantikk.

Her er flere eksempler på kanttyper:

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

Du trenger bare å angi nøkkeletikettene (Person, Universityeller Company) for endepunktnodetyper – du trenger ikke å gjenta den fullstendige nodetypedefinisjonen. Systemet løser disse referansene til de fullstendige nodetypedefinisjonene.

Diagramkanttypefamilier

Etiketter for grafkanttaster fungerer forskjellig fra nodenøkkeletiketter. Du kan ha flere kanttyper med samme nøkkeletikett i en graftype, så lenge de har de samme etikettene og egenskapstypene. To kanttyper med samme nøkkeletikett må imidlertid variere i minst én endepunktnodetype. Vi kaller et sett med kanttyper med samme nøkkeletikett som en kanttypefamilie.

Med dette konseptet kan du modellere samme type relasjon mellom ulike typer enheter.

Eksempel:

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

Begge kanttypene isPartOf bruker etiketten, men de kobler sammen ulike typer noder, og danner en kanttypefamilie som representerer hierarkiske innesperringsrelasjoner.

Bruk node-subtyping i kanttypedefinisjoner

Å måtte stave ut hver mulig edge-type kan være litt tidkrevende. For å forenkle det er det også mulig å definere kanttypefamilier som samsvarer med hierarkiet av nodetyper som deres endepunkter innebærer.

Eksempel:

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

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

Dette definerer implisitt følgende kanttyper:

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

Egenskapstyper som støttes

Når du definerer en egenskapstype, må egenskapsverditypen være en som grafen i Microsoft Fabric støtter. Å velge de riktige datatypene er viktig for lagringseffektivitet og spørringsytelse.

Her er datatypene du kan bruke for egenskapsverdier:

  • INT (også: INT64)
  • UINT (også: UINT64)
  • STRING
  • BOOL (også: BOOLEAN)
  • DOUBLE (også: FLOAT64, FLOAT)
  • T NOT NULL, hvor T er en av de foregående datatypene.
  • LIST<T> og LIST<T> NOT NULL, hvor T er en av de foregående datatypene.

Hvis du vil ha fullstendig informasjon om verdityper, kan du se GQL-verdier og verdityper.

Viktig!

Alle egenskapstyper med samme navn som forekommer i en nodetype eller kanttype for en gitt graftype, må angi samme egenskapsverditype. Det eneste unntaket: de kan variere i om de inkluderer nullverdien. I henhold til denne regelen vil for eksempel en graftype med (:A { id :: STRING }), (:B { id :: STRING NOT NULL}) være gyldig, mens en graftype med (:A { id :: STRING }), (:B { id :: INT}) ville vært ugyldig.

Konfigurere nodenøkkelbetingelser

Nodenøkkelbetingelser definerer hvordan hver node i grafen identifiseres unikt av én eller flere av egenskapsverdiene. Nøkkelbetingelser fungerer som primærnøkkelbetingelser i relasjonsdatabaser og sikrer dataintegritet. En nodenøkkelbetingelse kan målrette noder på tvers av flere nodetyper, som lar deg definere nodenøkler for hele begrepsmessige hierarkier.

Det er avgjørende å forstå viktige begrensninger fordi de:

  • Sikre unikhet: Forhindre duplikatnoder basert på forretningslogikken.
  • Aktiver effektive oppslag: Tillat at systemet optimaliserer spørringer som søker etter bestemte noder.
  • Integrasjon av støttedata: Gi en stabil måte å referere til noder på tvers av ulike datakilder på.

Viktig!

For graf i Microsoft Fabric må nøyaktig én nøkkelbetingelse begrense hver node.

Slik fungerer nodenøkkelbetingelser

Du kan angi nodenøkkelbetingelser i graftypen. Hver nodenøkkelbetingelse har spesifikke egenskaper som gjør at den fungerer effektivt:

Komponenter i en nodenøkkelbetingelse:

  • Har et unikt navn i graftypen for enkel referanse.
  • Definerer målrettede noder ved hjelp av et enkelt betingelsesmønster som angir hvilke noder betingelsen gjelder for.
  • Definerer egenskapene som utgjør den unike nøkkelverdien.

Eksempel:

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

Denne syntaksen oppretter en nodenøkkelbetingelse kalt person_pk for alle noder med minstPerson etiketten. Betingelsen sikrer at hver node i grafen identifiseres unikt av egenskapen id . Ingen to noder med Person etiketten kan ha samme id verdi.

Du kan også definere sammensatte nøkler som bruker flere egenskaper sammen for å sikre unikhet ved hjelp av syntaksen CONSTRAINT ... FOR ... REQUIRE (n.prop1, n.prop2) IS KEY .

Viktig!

Egenskaper som brukes i nøkkelbetingelser:

  • Kan ikke være null
  • Må deklareres som NOT NULL i nodetypene og kanttypene som er målrettet av nøkkelbetingelsen

Beslektet innhold

  • Last updated on