Graph Query Language

Ej att förväxla med GraphQL eller gsql.org.

GQL ( Graph Query Language ) är ett föreslaget standardspråk för graffrågefrågor . I september 2019 godkändes ett förslag till ett projekt för att skapa ett nytt standardgraffrågespråk (ISO/IEC 39075 Information Technology — Database Languages ​​— GQL) genom en omröstning av nationella standardiseringsorgan som är medlemmar i ISO/IEC Joint Technical Committee 1( ISO/IEC JTC 1 ). JTC 1 ansvarar för internationella IT-standarder. GQL är avsett att vara ett deklarativt databasfrågespråk, som SQL .

Projekt för ett nytt International Standard Graph Query Language

GQL-projektförslaget säger:

"Att använda graf som en grundläggande representation för datamodellering är ett framväxande tillvägagångssätt inom datahantering. I detta tillvägagångssätt modelleras datamängden som en graf, som representerar varje dataenhet som en vertex (även kallad en nod) av grafen och varje relation mellan två enheter som en kant mellan motsvarande hörn. Grafdatamodellen har uppmärksammats för sina unika fördelar. För det första kan grafmodellen vara en naturlig passform för datamängder som har hierarkiska, komplexa eller till och med godtyckliga strukturer. Sådana strukturer kan enkelt kodas in i grafmodellen som kanter. Detta kan vara bekvämare än relationsmodellen, som kräver normalisering av datamängden till en uppsättning tabeller med fasta radtyper. För det andra möjliggör grafmodellen effektiv exekvering av dyra frågor eller dataanalytiska funktioner som behöver observera multi-hop-relationer mellan dataenheter, såsom nåbarhetsfrågor, kortaste eller billigaste sökvägsfrågor eller centralitetsanalys. Det finns två grafmodeller som används för närvarande: Resource Description Framework (RDF)-modellen och Property Grafisk modell. RDF-modellen har standardiserats av W3C i ett antal specifikationer. Property Graph-modellen, å andra sidan, har en mängd implementeringar i grafdatabaser, grafalgoritmer och grafbehandlingsfaciliteter. Ett vanligt, standardiserat frågespråk för egenskapsgrafer (som SQL för relationsdatabassystem) saknas dock. GQL föreslås fylla detta tomrum."

GQL-projektet är kulmen på konvergerande initiativ som går tillbaka till 2016, särskilt ett privat förslag från Neo4j till andra databasleverantörer i juli 2016, och ett förslag från Oracles tekniska personal inom ISO/IEC JTC 1-standardprocessen senare samma år.

GQL-projektet leds av Stefan Plantikow (som var den första huvudingenjören i Neo4j :s Cypher for Apache Spark -projekt) och Stephen Cannan (Technical Corrigenda redaktör för SQL). De är också redaktörer för de första tidiga arbetsutkasten till GQL-specifikationen.

Som ursprungligen motiverades syftar GQL-projektet till att komplettera arbetet med att skapa en implementerbar normativ specifikation för naturligt språk med stödjande gemenskapsinsatser som möjliggör bidrag från dem som inte kan eller är ointresserade av att delta i den formella processen att definiera en JTC 1 International Standard. I juli 2019 gick Linked Data Benchmark Council (LDBC) överens om att bli paraplyorganisationen för insatserna av tekniska arbetsgrupper i samhället. Arbetsgrupperna Existing Languages ​​och Property Graph Schema bildades i slutet av 2018 respektive början av 2019. En arbetsgrupp för att definiera formell denotationssemantik för GQL föreslogs vid den tredje GQL Community Update i oktober 2019.

GQL-egenskapsgrafdatamodellen

GQL är ett frågespråk specifikt för egenskapsdiagram. En egenskapsgraf påminner mycket om en konceptuell datamodell, uttryckt i en entitet-relationsmodell eller i ett UML- klassdiagram (även om det inte inkluderar n-ära relationer som länkar mer än två entiteter). Entiteter eller koncept modelleras som noder, och relationer som kanter, i en graf. Egenskapsgrafer är multigrafer : det kan finnas många kanter mellan samma nodpar. GQL-grafer kan blandas : de kan innehålla riktade kanter, där en av ändpunktsnoderna på en kant är svansen (eller källan) och den andra noden är huvudet (eller målet eller destinationen), men de kan också innehålla oriktade (dubbelriktade) eller reflexiva) kanter.

Noder och kanter, gemensamt kända som element, har attribut. Dessa attribut kan vara datavärden eller etiketter (taggar). Värden på egenskaper kan inte vara element i grafer, och de kan inte heller vara hela grafer: dessa begränsningar tvingar avsiktligt fram en ren separation mellan en grafs topologi och de attribut som bär datavärden i en graftopologis kontext. Egenskapsgrafdatamodellen förhindrar därför medvetet kapsling av grafer, eller behandlar noder i en graf som kanter i en annan. Varje egenskapsdiagram kan ha en uppsättning etiketter och en uppsättning egenskaper som är associerade med grafen som helhet.

Aktuella grafdatabasprodukter och projekt stöder ofta en begränsad version av modellen som beskrivs här. Till exempel tvingar Apache Tinkerpop varje nod och varje kant att ha en enda etikett; Cypher tillåter noder att ha noll till många etiketter, men relationer har bara en enda etikett (kallad reltype). Neo4js databas stöder odokumenterade grafomfattande egenskaper, Tinkerpop har grafvärden som spelar samma roll, och stöder även "metaegenskaper" eller egenskaper på egenskaper. Oracles PGQL stöder noll till många etiketter på noder och på kanter, medan SQL/PGQ stöder en till många etiketter för varje typ av element. NGSI -LD- informationsmodellen specificerad av ETSI är ett försök att formellt specificera egenskapsgrafer, med nod- och relationstyper (kant) som kan spela rollen som etiketter i tidigare nämnda modeller och stödja semantisk referens genom att ärva klasser definierade i delade ontologier .

GQL-projektet kommer att definiera en standarddatamodell, som sannolikt kommer att vara superuppsättningen av dessa varianter, och åtminstone den första versionen av GQL kommer sannolikt att tillåta leverantörer att besluta om kardinaliteterna för etiketter i varje implementering, liksom SQL/PGQ och att välja om man vill stödja oriktade relationer.

Ytterligare aspekter av ERM- eller UML-modellerna (som generalisering eller subtypning, eller entitets- eller relationskardinaliteter) kan fångas upp av GQL-scheman eller -typer som beskriver möjliga instanser av den allmänna datamodellen.

Den första implementeringen

Även om GQL-standarden ännu inte är allmänt tillgänglig, är den första grafdatabasen i minnet som kan tolka GQL tillgänglig. Bortsett från implementeringen kan man också hitta en formalisering och läsa syntaxen för den specifika delmängden av GQL.

WG3: Utöka SQL och skapa GQL

GQL-projektet har en tidsperiod på fyra år. Sju nationella standardiseringsorgan (de i USA, Kina, Korea, Nederländerna, Storbritannien, Danmark och Sverige) har nominerat nationella ämnesexperter att arbeta med projektet, som genomförs av arbetsgrupp 3 (Databasspråk) av ISO/IEC JTC 1:s underkommitté 32 (Data Management and Interchange), vanligtvis förkortat som ISO/IEC JTC 1/SC 32 WG3, eller bara WG3 för kort. WG3 (och dess direkta föregångare inom JTC 1) har ansvarat för SQL-standarden sedan 1987.

Utöka befintliga graffrågespråk

GQL-projektet bygger på flera källor eller indata, särskilt befintliga industrispråk och en ny del av SQL-standarden. I förberedande diskussioner inom WG3 presenterades undersökningar av historien och det jämförande innehållet i några av dessa insatser. GQL kommer att vara ett deklarativt språk med sin egen distinkta syntax, som spelar en liknande roll som SQL i byggandet av en databasapplikation. Andra graffrågespråk har definierats som erbjuder direkta procedurfunktioner såsom förgrening och looping (Apache Tinkerpop's Gremlin,) och GSQL, vilket gör det möjligt att korsa en graf iterativt för att utföra en klass av grafalgoritmer, men GQL kommer inte direkt att införliva sådana Funktioner. GQL är dock tänkt som ett specifikt fall av en mer allmän klass av grafspråk, som kommer att dela ett graftypsystem och ett anropsgränssnitt för procedurer som behandlar grafer.

SQL/PGQ Property Graph Query

Tidigare arbete av WG3 och SC32 spegelkroppar, särskilt i INCITS DM32, har hjälpt till att definiera en ny planerad del 16 av SQL Standard, som gör att en skrivskyddad graffråga kan anropas i en SQL SELECT-sats, som matchar ett grafmönster med syntax som ligger mycket nära Cypher, PGQL och G-CORE, och returnerar en tabell med datavärden som resultat. SQL/PGQ innehåller också DDL för att tillåta att SQL-tabeller mappas till ett grafvyschemaobjekt med noder och kanter kopplade till uppsättningar av etiketter och dataegenskaper. GQL-projektet koordinerar nära med SQL/PGQ "projektdelning" av (utvidgning till) ISO 9075 SQL, och de tekniska arbetsgrupperna i USA (INCITS DM32) och på internationell nivå (SC32/WG3) har flera expertbidragsgivare som arbeta med båda projekten. GQL-projektförslaget kräver en nära anpassning av SQL/PGQ och GQL, vilket indikerar att GQL i allmänhet kommer att vara en superuppsättning av SQL/PGQ.

Mer information om mönstermatchningsspråket finns i artikeln "Graph Pattern Matching in GQL and SQL/PGQ"

Cypher

Cypher är ett språk som ursprungligen designades av Andrés Taylor och kollegor på Neo4j Inc., och implementerades först av det företaget 2011. Sedan 2015 har det gjorts tillgängligt som en språkbeskrivning med öppen källkod med grammatikverktyg, ett JVM-gränssnitt som analyserar Cypher frågor och ett Technology Compatibility Kit (TCK) med över 2000 testscenarier, med hjälp av Cucumber för implementering av språkportabilitet. TCK:n återspeglar språkbeskrivningen och en förbättring av temporala datatyper och funktioner som dokumenterats i ett Cypher Improvement Proposal.

Cypher tillåter skapande, läsning, uppdatering och radering av grafelement, och är ett språk som därför kan användas för analysmotorer och transaktionsdatabaser.

Fråga med visuella vägmönster

Cypher använder kompakta mönster med fast och variabel längd som kombinerar visuella representationer av nod- och relationstopologier (kant) med etikettexistens och egenskapsvärdepredikat. (Dessa mönster kallas vanligtvis " ASCII art "-mönster och uppstod ursprungligen som ett sätt att kommentera program som använde ett graf-API på lägre nivå.) Genom att matcha ett sådant mönster mot grafdataelement kan en fråga extrahera referenser till noder , relationer och vägar av intresse. Dessa referenser sänds ut som en "bindande tabell" där kolumnnamn är bundna till en multiuppsättning av grafelement. Namnet på en kolumn blir namnet på en "bindande variabel", vars värde är en specifik grafelementreferens för varje rad i tabellen.

Till exempel kommer ett mönster MATCH (p:Person)-[:LIVES_IN]->(c:City) att generera en utdatatabell med två kolumner. Den första kolumnen med namnet p kommer att innehålla referenser till noder med etiketten Person . Den andra kolumnen med namnet c kommer att innehålla referenser till noder med etiketten City , som anger staden där personen bor.

Bindningsvariablerna p och c kan sedan avreferenseras för att erhålla tillgång till egenskapsvärden associerade med elementen som refereras till av en variabel. Exempelfrågan kan avslutas med en RETURN , vilket resulterar i en fullständig fråga så här: 

 
     MATCH  (  p  :  Person  )  -[  :  LIVES_IN  ]->  (  c  :  City  )  RETURN  p  .  förnamn  ,  sid  .  efternamn  ,  c  .  namn  ,  c  .  stat

Detta skulle resultera i en sista tabell med fyra kolumner som listar namnen på invånarna i städerna som lagras i grafen.

Mönsterbaserade frågor kan uttrycka kopplingar genom att kombinera flera mönster som använder samma bindningsvariabel för att uttrycka en naturlig koppling med hjälp av MATCH- satsen: 

  
     MATCH  (  p  :  Person  )  -[  :  LIVES_IN  ]->  (  c  :  City  ),  (  p  :  Person  )  -[  :  NATIONAL_OF  ]->  (  EUCountry  )  RETUR  p  .  förnamn  ,  sid  .  efternamn  ,  c  .  namn  ,  c  .  stat

Denna fråga skulle endast returnera bostäder för EU-medborgare.

En yttre sammanfogning kan uttryckas med MATCH ... VALFRI MATCH : 

    
      MATCH  (  p  :  Person  )  -[  :  LIVES_IN  ]->  (  c  :  City  )  VALFRI  MATCH  (  p  :  Person  )  -[  :  NATIONAL_OF  ]->  (  ec  :  EUCountry  )  RETUR  p  .  förnamn  ,  sid  .  efternamn  ,  c  .  namn  ,  c  .  tillstånd  ,  ec  .  namn

Denna fråga skulle returnera bostadsorten för varje person i diagrammet med bostadsinformation och, om en EU-medborgare, vilket land de kommer från.

Frågor kan därför först projicera en subgraf av grafen som matas in i frågan och sedan extrahera datavärdena som är associerade med den subgrafen. Datavärden kan också bearbetas av funktioner, inklusive aggregeringsfunktioner, vilket leder till projicering av beräknade värden som återger informationen i den projicerade grafen på olika sätt. Efter ledning av G-CORE och Morpheus, syftar GQL till att projicera undergraferna som definieras av matchande mönster (och grafer som sedan beräknas över dessa undergrafer) som nya grafer som ska returneras av en fråga.

Mönster av detta slag har blivit genomträngande i egenskapsgraffrågespråk och är grunden för att det avancerade mönsterunderspråket definieras i SQL/PGQ, som sannolikt kommer att bli en delmängd av GQL-språket. Cypher använder också mönster för insättnings- och modifieringssatser ( CREATE och MERGE ), och förslag har gjorts i GQL-projektet för att samla nod- och kantmönster för att beskriva graftyper.

Cypher 9 och Cypher 10

Den nuvarande versionen av Cypher (inklusive den tidsmässiga förlängningen) hänvisas till som Cypher 9. Före GQL-projektet var det planerat att skapa en ny version, Cypher 10 [ REF HEADING BELOW ], som skulle innehålla funktioner som schema och komponerbara graffrågor och vyer. De första designerna för Cypher 10, inklusive grafkonstruktion och projektion, implementerades i Cypher for Apache Spark-projektet med start 2016.

PGQL

PGQL är ett språk designat och implementerat av Oracle Inc., men gjort tillgängligt som en öppen källkodsspecifikation, tillsammans med JVM-parsingprogramvara. PGQL kombinerar välbekant SQL SELECT-syntax inklusive SQL-uttryck och resultatordning och aggregering med ett mönstermatchande språk som mycket liknar det för Cypher. Det gör att specifikationen av grafen kan frågas, och inkluderar en möjlighet för makron att fånga "mönstervyer", eller namngivna undermönster. Den stöder inte insättnings- eller uppdateringsoperationer, eftersom den främst har designats för en analysmiljö, såsom Oracles PGX-produkt. PGQL har även implementerats i Oracle Big Data Spatial and Graph, och i ett forskningsprojekt, PGX.D/Async.

G-CORE

G-CORE är ett forskningsspråk designat av en grupp akademiska och industriella forskare och språkdesigners som bygger på funktionerna i Cypher, PGQL och SPARQL . Projektet genomfördes under överinseende av Linked Data Benchmark Council (LDBC), som började med bildandet av en arbetsgrupp för Graph Query Language i slutet av 2015, med huvuddelen av arbetet med att skriva papper under 2017. G-CORE är en komponerbart språk som är stängt över grafer: grafinmatningar bearbetas för att skapa en grafutdata, med hjälp av grafprojektioner och grafuppsättningsoperationer för att konstruera den nya grafen. G-CORE-frågor är rena funktioner över grafer, utan biverkningar, vilket innebär att språket inte definierar operationer som muterar (uppdatera eller raderar) lagrad data. G-CORE introducerar vyer (namngivna frågor). Den införlivar också banor som element i en graf ("vägar som förstklassiga medborgare"), som kan frågas oberoende av projicerade banor (som beräknas vid frågetid över nod- och kantelement). G-CORE har delvis implementerats i forskningsprojekt med öppen källkod i LDBC GitHub-organisationen.

GSQL

GSQL är ett språk designat för TigerGraph Inc.:s egenutvecklade grafdatabas. Sedan oktober 2018 har TigerGraphs språkdesigners främjat och arbetat med GQL-projektet. GSQL är ett Turing-komplett språk som innehåller processuell flödeskontroll och iteration, och en möjlighet för att samla in och modifiera beräknade värden som är associerade med en programexekvering för hela grafen eller för element i en graf som kallas ackumulatorer. Dessa funktioner är utformade för att möjliggöra iterativa grafberäkningar som kan kombineras med datautforskning och hämtning. GSQL-grafer måste beskrivas av ett schema av hörn och kanter, vilket begränsar alla infogningar och uppdateringar. Detta schema har därför egenskapen för sluten värld av ett SQL-schema, och denna aspekt av GSQL (även återspeglas i designförslag som härrör från Morpheus-projektet) föreslås som en viktig valfri egenskap hos GQL.

Vertex och kanter kallas schemaobjekt som innehåller data men också definierar en imputerad typ, ungefär som SQL-tabeller är databehållare, med en tillhörande implicit radtyp. GSQL-grafer är sedan sammansatta av dessa vertex- och kantuppsättningar, och flera namngivna grafer kan inkludera samma vertex eller kantuppsättning. GSQL har utvecklat nya funktioner sedan lanseringen i september 2017, framför allt genom att introducera mönstermatchning med variabel längd med hjälp av en syntax som är relaterad till den som ses i Cypher, PGQL och SQL/PGQ, men också nära de fasta mönster som erbjuds av Microsoft SQL/Server Graph

GSQL stöder också konceptet Multigraphs som tillåter delmängder av en graf att ha rollbaserad åtkomstkontroll. Multigrafer är viktiga för grafer i företagsskala som behöver finkornig åtkomstkontroll för olika användare.

Morpheus: flera grafer och komponerbara graffrågor i Apache Spark

Openencypher Morpheus-projektet implementerar Cypher för Apache Spark-användare. Detta projekt startade 2016 och körde ursprungligen tillsammans med tre relaterade insatser, där Morpheus designers också deltog: SQL/PGQ, G-CORE och design av Cypher-tillägg för att fråga och konstruera flera grafer. Morpheus-projektet fungerade som en testbädd för tillägg till Cypher (känd som "Cypher 10") i de två områdena graf-DDL och frågespråktillägg.

Graf DDL funktioner inkluderar

  1. definition av egenskapsdiagramvyer över JDBC -anslutna SQL-tabeller och Spark DataFrames
  2. definition av grafscheman eller typer definierade genom att sätta samman nodtyp och kanttypmönster, med subtyping
  3. begränsa innehållet i en graf med ett slutet eller fast schema
  4. skapa katalogposter för flera namngivna grafer i en hierarkiskt organiserad katalog
  5. grafiska datakällor för att bilda en federerad, heterogen katalog
  6. skapa katalogposter för namngivna frågor (vyer)

Språktillägg för graffrågor inkluderar

  1. grafförbund
  2. projektion av grafer beräknade från resultaten av mönstermatchningar på flera indatagrafer
  3. stöd för tabeller (Spark DataFrames) som indata till frågor ("driving tables")
  4. vyer som accepterar namngivna eller projicerade grafer som parametrar.

Dessa funktioner har föreslagits som input till standardiseringen av frågespråk för egenskapsdiagram i GQL-projektet.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Graph_Query_Language&oldid=1139125440 "