Del via

GQL-graftyper

Notat

Denne funktion er i øjeblikket tilgængelig som offentlig prøveversion. Denne prøveversion leveres uden en serviceniveauaftale og anbefales ikke til produktionsarbejdsbelastninger. Visse funktioner understøttes muligvis ikke eller kan have begrænsede funktioner. Du kan finde flere oplysninger under Supplerende vilkår for anvendelse af Microsoft Azure Previews.

En graftype beskriver grafens struktur ved at definere, hvilke noder og kanter der kan findes. Tænk på det som en kursusplan eller et skema – det angiver formen af noder og kanter i grafen med hensyn til deres mærkater og egenskaber. For kanter (forbindelserne mellem noder) angiver den også, hvilke typer kanter der kan forbindes, hvilke typer noder der kan forbindes. Hvis du kender relationsdatabaser, fungerer graftyper på samme måde, som ER-diagrammer beskriver tabeller og relationer med fremmede nøgler.

Vigtigt

Denne artikel bruger udelukkende datasættet for eksempelgrafer på sociale netværk.

Graftyper giver flere vigtige fordele:

  • Datavalidering: Sørg for, at grafen kun indeholder gyldige node- og kantkombinationer.
  • Forespørgselsoptimering: Hjælp forespørgselsprogrammet med at forstå din datastruktur for at opnå en bedre ydeevne.
  • Dokumentation: Fungerer som en klar specifikation af din grafs struktur for udviklere og analytikere.

Notat

Denne artikel introducerer graftyper konceptuelt og illustrerer deres definition ved hjælp af den syntaks, der er defineret i GQL-standarden. Denne syntaks understøttes dog ikke direkte for graph i Microsoft Fabric.

Strukturelt definerer en graftype tilladte nodetyper og kanttyper af grafer af graftypen samt yderligere begrænsninger, der yderligere begrænser disse grafer.

Notat

Graftyper defineres ved at give et sæt nodetype-, kanttype- og begrænsningsdefinitioner. Ændring af rækkefølgen af disse definitioner ændrer ikke den graftype, der defineres.

Definer nodetyper

En nodetype angiver, hvilke navne og egenskabstyper dine noder kan have. Sådan angiver du en grundlæggende nodetype:

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

I dette eksempel oprettes en nodetype, der definerer noder med:

  • Navnet Organization.
  • En id egenskab, der indeholder heltalsværdier, der ikke er signeret, og som ikke kan være null.
  • En name egenskab, der indeholder strengværdier (kan være null).
  • En url egenskab, der indeholder strengværdier (kan være null).

Operatoren :: angiver datatypen for hver egenskab, mens NOT NULL angiver, at egenskaben altid skal have en værdi.

Notat

NOT NULL betragtes som en del af typen i GQL, som adskiller sig fra SQL.

Nodetyper kan også være mere komplekse med flere egenskaber 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 navne

Noder kan have flere mærkater, der understøtter nedarvning og kategorisering. Du kan angive flere navne for en nodetype, men én etiket ("nøglemærkaten") skal entydigt identificere nodetypen (Hvis der kun er angivet én etiket, anses dette for at være nodetypens nøglenavn).

Som et eksempel kan du overveje:

(:University => :Organization),

(:Company => :Organization)

University Her og Company er nøglenavnene for de to nodetyper defineret, mens Organization er en sekundær etiket, der deles af begge typer. Bemærk, hvordan nøglemærkaten og de sekundære navne adskilles af => i hver nodetype. Denne fremgangsmåde opretter et typehierarki, hvor både universiteter og virksomheder er typer af organisationer.

Da nøglemærkater identificerer nodetyper, nedarves egenskaberne for nodetyper, der identificeres af sekundære mærkater, automatisk, når du bruger denne syntaks. Derfor kan den forrige syntaks forstås for effektivt at definere følgende nodetyper:

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

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

Notat

Nøglemærkater er vigtige, når du definerer nodetypehierarkier. De hjælper systemet med at forstå, hvilken nodetype du refererer til, når flere typer deler de samme navne.

Spar tid med nedarvningsgenveje

Gentagne navne og egenskaber fra overordnede nodetyper bliver kedelige og fejlbehæftede. Graph i Microsoft Fabric leverer operatoren, += så du kun kan angive de ekstra (ikke-arvede) mærkater og egenskabstyper:

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

Når der ikke er angivet ekstra egenskaber, arver grafen alle påkrævede egenskaber fra den overordnede type:

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

Brug abstrakte nodetyper

Du kan definere nodetyper udelukkende til oprettelse af hierarkier, også selvom grafen ikke indeholder konkrete noder af denne type. Abstrakte nodetyper er nyttige til oprettelse af konceptuelle grupperinger og delte egenskabssæt. Til dette formål kan du definere en nodetype som ABSTRACT i graph i Microsoft Fabric:

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

Abstrakte nodetyper er ikke tilgængelige til direkte indlæsning af grafer. De findes kun til at strukturere dit hierarki og definere delte egenskaber. Konkrete nodetyper, der arver fra abstrakte typer, kan indlæses med data.

Definer kanttyper og -familier

En kanttype definerer nøglenavne, egenskabstyper og slutpunktsnodetyper for kanter. I grafdatabaser repræsenterer kanter forbindelser mellem noder. Edge-definitionen fortæller systemet, hvilke relationer der er tilladt i din graf:

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

Denne kanttype definerer alle kanter med:

  • Navnet (nøgle) knows.
  • En creationDate egenskab, der indeholder ZONED DATETIME værdier (tidsstempel sammen med en tidszoneforskydning).
  • Kilde- og destinationsslutpunkter, der begge skal være Person noder.

Pilen -> angiver retningen af kanten fra kilde til destination. Denne retningsbestemt information er afgørende for at forstå din grafs semantik.

Her er flere eksempler på kanttyper:

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

Du skal kun angive nøglenavnene (Person, Universityeller Company) for slutpunktsnodetyper – du behøver ikke at gentage definitionen af den komplette nodetype. Systemet fortolker disse referencer til definitioner af komplette nodetyper.

Grafkanttypefamilier

Diagramkantnøglenavne fungerer anderledes end nodenøglenavne. Du kan have flere kanttyper med samme nøglenavn i en graftype, så længe de har de samme navne og egenskabstyper. To kanttyper med samme nøglenavn skal dog variere i mindst én slutpunktsnodetype. Vi kalder et sæt kanttyper med det samme nøglenavn for en kanttypefamilie.

Dette koncept giver dig mulighed for at modellere den samme type relation mellem forskellige typer objekter.

Eksempel:

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

Begge kanttyper bruger mærkaten isPartOf , men de forbinder forskellige typer noder og danner en kanttypefamilie, der repræsenterer hierarkiske indeslutningsrelationer.

Brug node-subtyping i kanttypedefinitioner

At skulle stave hver mulig edge-type kan være lidt kedeligt. For at forenkle det er det også muligt at definere kanttypefamilier, der stemmer overens med hierarkiet af nodetyper, som deres endepunkter indebæ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 implicit følgende kanttyper:

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

Understøttede egenskabstyper

Når du definerer en egenskabstype, skal egenskabsværditypen være en, som grafen i Microsoft Fabric understøtter. Det er vigtigt at vælge de rigtige datatyper for at sikre lagereffektivitet og ydeevne af forespørgsler.

Her er de datatyper, du kan bruge til egenskabsværdier:

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

Du kan få detaljerede oplysninger om værdityper under GQL-værdier og værdityper.

Vigtigt

Alle egenskabstyper med det samme navn, der forekommer i en nodetype eller kanttype af en given graftype, skal angive den samme egenskabsværditype. Den eneste undtagelse: De kan variere, uanset om de indeholder null-værdien. I henhold til denne regel er en graftype (:A { id :: STRING }), (:B { id :: STRING NOT NULL}) f.eks. gyldig, mens en graftype med (:A { id :: STRING }), (:B { id :: INT}) ville være ugyldig.

Konfigurer nodenøglebegrænsninger

Nodenøglebegrænsninger definerer, hvordan hver node i grafen identificeres entydigt af en eller flere af dens egenskabsværdier. Nøglebegrænsninger fungerer som primære nøglebegrænsninger i relationsdatabaser og sikrer dataintegritet. En nodenøglebegrænsning kan målrette noder på tværs af flere nodetyper, hvilket giver dig mulighed for at definere nodenøgler for hele konceptuelle hierarkier.

Det er afgørende at forstå vigtige begrænsninger, fordi de:

  • Sørg for entydighed: Undgå dublerede noder baseret på din forretningslogik.
  • Aktivér effektive opslag: Tillad, at systemet optimerer forespørgsler, der søger efter bestemte noder.
  • Understøttelse af dataintegration: Gør det muligt at referere til noder på tværs af forskellige datakilder på en stabil måde.

Vigtigt

For graph i Microsoft Fabric skal præcis én nøglebegrænsning begrænse hver node.

Sådan fungerer nodenøglebegrænsninger

Du kan angive begrænsninger for nodenøgler i graftypen. Hver nodenøglebegrænsning har specifikke egenskaber, der får den til at fungere effektivt:

Komponenter i en nodenøglebegrænsning:

  • Har et entydigt navn i graftypen, som du nemt kan referere til.
  • Definerer målrettede noder ved hjælp af et simpelt begrænsningsmønster , der angiver, hvilke noder begrænsningen gælder for.
  • Definerer de egenskaber, der udgør den entydige nøgleværdi.

Eksempel:

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

Denne syntaks opretter en nodenøglebegrænsning, der kaldes person_pk for alle noder med mindst navnet Person . Begrænsningen sikrer, at hver node i grafen identificeres entydigt af dens id egenskab. Der kan ikke være to noder med Person etiketten, der har samme id værdi.

Du kan også definere sammensatte nøgler, der bruger flere egenskaber sammen for at sikre entydighed ved hjælp af syntaksen CONSTRAINT ... FOR ... REQUIRE (n.prop1, n.prop2) IS KEY .

Vigtigt

Egenskaber, der bruges i nøglebegrænsninger:

  • Må ikke være null
  • Skal erklæres som NOT NULL i nodetyperne og kanttyperne, der er målrettet af nøglebegrænsningen

Relateret indhold

  • Last updated on