GQL-graftyper

En graftype definerer strukturen af en graf ved at angive, hvilke noder og kanter der kan findes, deres mærkater og egenskaber, og hvordan de opretter forbindelse til hinanden. Tænk på en graftype som et skema eller en kursusplan – på samme måde som et ER-diagram (objektrelation) beskriver tabeller og relationer med fremmede nøgler i en relationsdatabase.

I denne artikel forklares det, hvordan du definerer graftyper ved hjælp af GQL-syntaks, herunder nodetyper, kanttyper, begrænsninger og nedarvning.

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.

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

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).

Brug operatoren :: til at angive datatypen for hver egenskab. Bruges NOT NULL til at angive, at egenskaben altid skal have en værdi.

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 
})

Spar tid med nedarvningsgenveje

Gentagne navne og egenskaber fra overordnede nodetyper bliver kedelige og fejlbehæftede. Graph leverer operatoren, += så du kun kan angive de ekstra (ikke-heriterede) navne 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 grafen:

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 for 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. Et sæt kanttyper med samme nøglenavn er 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

Det kan være kedeligt at skulle præcisere hver mulige kanttype. For at forenkle skal du definere kanttypefamilier, der er i overensstemmelse med hierarkiet af nodetyper, der er underforstået af deres slutpunkter.

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) 

Denne definition definerer implicit følgende kanttyper:

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

Understøttede egenskabstyper

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

Brug følgende datatyper 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.

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.

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 er navngivet 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 .

Relateret indhold

• GQL-sprogvejledning
• Eksempel på skema på sociale netværk
• GQL-værdier og værdityper
• Optimer ydeevnen af GQL-forespørgsler til graf
• Try Microsoft Fabric gratis