Kaaviokyselyn kieli - Graph Query Language

GQL ( Graph Query Language ) on ehdotettu vakiokuvaajakielen kieli . Syyskuussa 2019 hyväksyttiin ehdotus uuden vakiokaavion kyselykielen (ISO / IEC 39075 Information Technology - Database Languages - GQL) luomiseksi ISO / IEC: n teknisen sekakomitean 1 jäseninä olevien kansallisten standardointielinten äänestyksellä ( ISO / IEC JTC 1 ). JTC 1 vastaa kansainvälisistä tietotekniikan standardeista. GQL on tarkoitettu deklaratiiviseksi tietokannan kyselykieleksi, kuten SQL .

Uuden kansainvälisen standardikaavio-kyselykielen projekti

GQL-hanke-ehdotuksessa todetaan:

"Kuvaajan käyttäminen perusesityksenä tietomallinnuksessa on nouseva lähestymistapa tiedonhallinnassa. Tässä lähestymistavassa tietojoukko mallinnetaan kaaviona, joka edustaa kutakin dataentiteettiä kaavion kärjeksi (jota kutsutaan myös solmuksi) ja kutakin suhdetta kahden yksikön välisenä reunana vastaavien pisteiden välillä. Graafidatamalli on kiinnittänyt huomiota sen ainutlaatuisiin etuihin. Ensinnäkin, graafimalli voi olla luonnollinen sovitus tietojoukoille, joilla on hierarkkinen, monimutkainen tai jopa mielivaltainen rakenne. Tällaiset rakenteet voivat koodata helposti kaaviomalliin reunoina. Tämä voi olla helpompaa kuin relaatiomalli, joka vaatii tietojoukon normalisointia taulukkoryhmäksi, jolla on kiinteät rivityypit. Toiseksi kaaviomalli mahdollistaa kalliiden kyselyjen tehokkaan suorittamisen tai datan analyyttiset toiminnot, joiden on tarkkailtava multi-hypysuhteita datakokonaisuuksien välillä, kuten saavutettavuuskyselyt, lyhimmän tai halvimman polun kyselyt tai keskitetty analyysi. ovat kaksi nykyisessä käytössä olevaa kaaviomallia: Resurssikuvakehyksen (RDF) malli ja Ominaisuuskaavio-malli. W3C on standardoinut RDF-mallin useissa eritelmissä. Property Graph -mallilla on toisaalta lukuisia toteutuksia kaaviotietokannoissa, kaavioalgoritmeissa ja kaavioiden käsittelytoiminnoissa. Yhteinen, standardoitu kyselykieli ominaisuuskaavioille (kuten SQL relaatiotietokantajärjestelmille) puuttuu. GQL: n ehdotetaan täyttävän tämä aukko. "

GQL-projekti on huipentuma lähentyviin aloitteisiin, jotka ovat peräisin vuodelta 2016, erityisesti Neo4j: n yksityinen ehdotus muille tietokantatoimittajille heinäkuussa 2016 ja Oraclen teknisen henkilöstön ehdotus myöhemmin samana vuonna ISO / IEC JTC 1 -standardiprosessissa.

GQL Projektia johtaa Stefan Plantikow (joka oli ensimmäinen johtaa insinööri ollut Neo4j n Cypher for Apache Spark -hanke) ja Stephen Cannan (Technical Oikaisut toimittaja SQL). He ovat myös toimittajia GQL-spesifikaation ensimmäisille varhaisille työhön.

Alun perin motivoituneen GQL-projektin tarkoituksena on täydentää toteutettavan normatiivisen luonnollisen kielen määrittelyn luomista tukevilla yhteisön toimilla, jotka mahdollistavat osallistumisen niille, jotka eivät kykene tai eivät ole kiinnostuneita osallistumaan JTC 1: n kansainvälisen standardin määrittelyn muodolliseen prosessiin. Linked Data Benchmark Council (LDBC) päätti heinäkuussa 2019 tulla katto-organisaatioksi yhteisön teknisten työryhmien ponnisteluille. Olemassa olevat kielet ja Property Graph Schema -työryhmät perustettiin vastaavasti vuoden 2018 lopulla ja vuoden 2019 alussa. GQL: n muodollisen merkitsevän semantiikan määrittelemistä käsittelevää työryhmää ehdotettiin kolmannelle GQL-yhteisöpäivitykselle lokakuussa 2019.

GQL-ominaisuuskaaviotietomalli

GQL on kyselykieli erityisesti ominaisuuskaavioille. Ominaisuuskaavio muistuttaa läheisesti käsitteellistä tietomallia, joka ilmaistaan kokonaisuuden suhdemallissa tai UML- luokkakaaviossa (vaikka se ei sisällä n-ary-suhteita, jotka yhdistävät enemmän kuin kaksi kokonaisuutta). Entiteetit tai käsitteet mallinnetaan solmuina ja suhteet reunoina kaaviossa. Ominaisuuskaaviot ovat monikuvia : saman solmuparin välillä voi olla useita reunoja. GQL-kaaviot voivat olla sekoitettuja : ne voivat sisältää suunnattuja reunoja, joissa yksi reunan päätepisteen solmuista on häntä (tai lähde) ja toinen solmu on pää (tai kohde tai kohde), mutta ne voivat sisältää myös suuntaamattomia (kaksisuuntaisia) tai heijastavat) reunat.

Solmuilla ja reunoilla, jotka yhdessä kutsutaan elementeiksi, on määritteitä. Nämä määritteet voivat olla data-arvoja tai tarroja (tunnisteita). Ominaisuuksien arvot eivät voi olla kaavioiden elementtejä, eivätkä ne voi olla kokonaisia kaavioita: nämä rajoitukset pakottavat tahallaan selkeän eron graafin topologian ja data-arvoja kantavien attribuuttien välillä graafin topologian yhteydessä. Ominaisgraafidatamalli estää siten tarkoituksella kaaviokuvien pesimisen tai yhden kaavion solmujen käsittelyn toisen reunana. Jokaisessa ominaisuuskaaviossa voi olla joukko tarroja ja joukko ominaisuuksia, jotka liittyvät kaavioon kokonaisuutena.

Nykyiset kaaviotietokantatuotteet ja projektit tukevat usein rajoitettua versiota tässä kuvatusta mallista. Esimerkiksi Apache Tinkerpop pakottaa jokaisella solmulla ja jokaisella reunalla olevan yksi tarra; Cypher sallii solmujen olla nolla monille tarroille, mutta suhteilla on vain yksi tunniste (kutsutaan reltype). Neo4j: n tietokanta tukee dokumentoimattomia kuvaajan laajuisia ominaisuuksia, Tinkerpopilla on kuvaajan arvot, joilla on sama rooli, ja tukee myös "metaproperties" -ominaisuuksia tai ominaisuuksien ominaisuuksia. Oraclen PGQL tukee nollasta moniin tarroihin solmuissa ja reunoissa, kun taas SQL / PGQ tukee yhtä tai useampaa tarraa kullekin elementille. NGSI-LD tietomalli määritelty ETSI on yritetty muodollisesti määritellään ominaisuus kaavioita, solmun ja suhde (reuna) tyypit, jotka voivat näytellä etikettien aiemmin mainittuja malleja ja tukevat semanttinen linkitykset perimällä, jotka on määritelty jaettu ontologioihin .

GQL-projekti määrittelee standardidatamallin, joka on todennäköisesti näiden varianttien pääjoukko, ja ainakin GQL: n ensimmäinen versio antaa toimittajien todennäköisesti päättää kullekin toteutukselle asetettujen tarrojen pääkohdista, kuten SQL / PGQ ja valita, tuetaanko ohjaamattomia suhteita.

ERM- tai UML-mallien muita näkökohtia (kuten yleistys tai alatyypit tai entiteetin tai suhteen kardinaalit) voidaan siepata GQL-kaavioilla tai -tyypeillä, jotka kuvaavat yleisen tietomallin mahdollisia esiintymiä.

WG3: SQL: n laajentaminen ja GQL: n luominen

GQL-projektilla on neljä vuotta. Seitsemän kansallista standardointielintä (Yhdysvaltojen, Kiinan, Korean, Alankomaiden, Ison-Britannian, Tanskan ja Ruotsin) on nimittänyt kansalliset aihe-asiantuntijat työskentelemään projektissa, jonka johtaa työryhmä 3 (tietokannan kielet) ISO / IEC JTC 1: n alakomiteasta 32 (tiedonhallinta ja tiedonvaihto), yleensä lyhennettynä ISO / IEC JTC 1 / SC 32 WG3 tai vain WG3 . WG3 (ja sen suorat edeltäjäkomiteat JTC 1: ssä) on vastannut SQL-standardista vuodesta 1987.

Laajentamalla olemassa olevia kaavakyselykieliä

GQL-projekti perustuu useisiin lähteisiin tai syötteisiin, erityisesti olemassa oleviin teollisuuskieliin ja SQL-standardin uuteen osaan. WG3: n valmistelevissa keskusteluissa esiteltiin kyselyjä joidenkin näiden syötteiden historiasta ja vertailevasta sisällöstä. GQL on deklaratiivinen kieli, jolla on oma erillinen syntaksinsa ja jolla on samanlainen rooli kuin SQL: llä tietokantasovelluksen rakentamisessa. Muut graafikyselykielet on määritelty, jotka tarjoavat suoria menettelytapoja, kuten haarautuminen ja silmukointi (Apache Tinkerpop's Gremlin,) ja GSQL, mikä mahdollistaa graafin kulkemisen iteratiivisesti suorittamaan luokan graafi-algoritmeja, mutta GQL ei sisälly suoraan sellaisiin ominaisuudet. GQL on kuitenkin suunniteltu erityistapaukseksi yleisemmälle graafikielien luokalle, joka jakaa kaaviotyyppisen järjestelmän ja kutsuvan käyttöliittymän kaavioita käsitteleville menettelyille.

SQL / PGQ-ominaisuuskaavakysely

Aikaisempi WG3- ja SC32-peilirunkojen työ, erityisesti INCITS DM32: ssä, on auttanut määrittelemään uuden suunnitellun SQL-standardin osan 16, joka sallii vain luku -kuvaajakyselyn kutsumisen SQL SELECT -käskyyn sisältäen kuvaajakuvion syntaksi, joka on hyvin lähellä Cypheriä, PGQL: ää ja G-CORE: ta, ja palauttaa tuloksena data-arvotaulukon. SQL / PGQ sisältää myös DDL: n, jonka avulla SQL-taulukot voidaan yhdistää kaavionäkymäkohdeobjektiin, jossa solmut ja reunat liitetään tarrasarjoihin ja dataominaisuuksiin. GQL-projekti koordinoi tiiviisti ISO / ISO 9075 SQL: n (laajennus) SQL / PGQ "projektijaon" kanssa, ja Yhdysvalloissa (INCITS DM32) ja kansainvälisellä tasolla (SC32 / WG3) toimivilla teknisillä työryhmillä on useita asiantuntija-avustajia, jotka työtä molemmissa projekteissa. GQL-projektiehdotus edellyttää SQL / PGQ: n ja GQL: n läheistä yhdenmukaistamista, mikä osoittaa, että GQL on yleensä SQL / PGQ: n pääjoukko.

Cypher

Cypher on kieli, jonka alun perin on suunnitellut Andrés Taylor ja kollegat Neo4j Inc. -yrityksestä ja jonka yritys otti ensimmäisen kerran käyttöön vuonna 2011. Vuodesta 2015 lähtien se on ollut saatavana avoimen lähdekielen kuvauksena kielioppityökaluilla, JVM- käyttöliittymällä, joka jäsentää Cypheriä kyselyt ja yli 2000 testiskenaariota sisältävä tekniikan yhteensopivuuspaketti (TCK), jossa Cucumberia käytetään kielen siirrettävyyteen. TCK heijastaa kielen kuvausta ja parannusta ajallisille tietotyypeille ja toiminnoille, jotka on dokumentoitu Cypher Improvement -ehdotuksessa.

Cypher sallii kaavioelementtien luomisen, lukemisen, päivittämisen ja poistamisen. Sitä voidaan käyttää kielellä, jota voidaan käyttää analyysimoottoreissa ja transaktiotietokannoissa.

Kysely visuaalisten reittikuvioiden avulla

Cypher käyttää pienikokoisia kiinteän ja vaihtelevan pituisia malleja, joissa yhdistyvät solmujen ja suhde (reuna) topologioiden visuaaliset esitykset etikettien olemassaolon ja ominaisuusarvojen predikaattien kanssa. (Näitä kuvioita kutsutaan yleensä " ASCII art " -malleiksi, ja ne syntyivät alun perin tapana kommentoida ohjelmia, jotka käyttivät alemman tason graafisen sovellusliittymän.) Yhdistämällä tällainen kuvio graafin tietoelementteihin, kysely voi poimia viittauksia solmuihin , suhteet ja kiinnostavat polut. Nämä viitteet lähetetään "sitovana taulukkona", jossa sarakkeiden nimet on sidottu moniin graafi-elementteihin. Sarakkeen nimestä tulee "sitovan muuttujan" nimi, jonka arvo on erityinen kaavioelementtiviittaus taulukon jokaiselle riville.

Esimerkiksi kuvio MATCH (p:Person)-[:LIVES_IN]->(c:City) luo kahden sarakkeen tulostaulukon. Ensimmäinen nimetty sarake p sisältää viitteet solmuihin, joissa on tunniste Person . Toinen nimetty sarake c sisältää viitteet solmuihin, joissa on tunniste City , joka merkitsee kaupunkia, jossa henkilö asuu.

Sitovat muuttujat p ja niistä c voidaan sitten päättää päästäksesi ominaisuuksien arvoihin, jotka liittyvät muuttujan viittaamiin elementteihin. Esimerkkikysely voidaan lopettaa a: lla RETURN , jolloin tuloksena on täydellinen kysely:

MATCH (p:Person)-[:LIVES_IN]->(c:City)
RETURN p.first_name, p.last_name, c.name, c.state

Tämä johtaisi lopulliseen neljän sarakkeen taulukkoon, jossa luetellaan kaavioon tallennettujen kaupunkien asukkaiden nimet.

Kuvioon perustuvat kyselyt pystyvät ilmaisemaan liitoksia yhdistämällä useita malleja, jotka käyttävät samaa sidosmuuttujaa luonnollisen liitoksen ilmaisemiseksi MATCH lausekkeen avulla:

MATCH (p:Person)-[:LIVES_IN]->(c:City), (p:Person)-[:NATIONAL_OF]->(EUCountry)
RETURN p.first_name, p.last_name, c.name, c.state

Tämä kysely palauttaisi vain EU: n kansalaisten asuinpaikan.

Ulkopuolinen liitos voidaan ilmaista seuraavasti MATCH ... OPTIONAL MATCH :

MATCH (p:Person)-[:LIVES_IN]->(c:City) OPTIONAL MATCH (p:Person)-[:NATIONAL_OF]->(ec:EUCountry)
RETURN p.first_name, p.last_name, c.name, c.state, ec.name

Tämä kysely palauttaisi kaavion jokaisen henkilön asuinkaupungin, jossa on asumistiedot, ja jos EU-kansalainen, mistä maasta he tulevat.

Kyselyt pystyvät siis projisoimaan ensin kyselyyn syötetyn kaavion alikaavion ja sitten purkamaan kyseiseen aligrafiikkaan liittyvät data-arvot. Data-arvoja voidaan käsitellä myös funktioilla, mukaan lukien aggregaatiofunktiot, mikä johtaa laskettujen arvojen projektioon, joka tuottaa projisoidussa kaaviossa olevan informaation eri tavoin. G-CORE: n ja Morpheuksen johdolla GQL pyrkii heijastamaan vastaavien kuvioiden (ja sitten näiden alikaavioiden yli laskettujen kaavioiden) määrittelemät alikaaviot uusiksi kaavioiksi, jotka palautetaan kyselyllä.

Tämän tyyppisistä malleista on tullut yleisiä ominaisuuskaaviokyselykielissä, ja ne ovat perusta kehittyneelle mallikielelle, joka määritetään SQL / PGQ: ssa, josta todennäköisesti tulee GQL-kielen osajoukko. Cypher käyttää myös malleja lisäys- ja muokkauslausekkeisiin ( CREATE ja MERGE ), ja GQL-projektissa on tehty ehdotuksia solmu- ja reunakuvioiden keräämiseksi kaaviotyyppien kuvaamiseksi.

Cypher-toteutukset

Cypher toteutetaan ollut Neo4j tietokantaan, SAP: n HANA Kaavio, jota Redis Graph., Cambridge semantiikka Anzograph, jonka Bitnine n AgensGraph, jonka Memgraph ja avoimen lähdekoodin projekteihin Cypher varten Gremlin ylläpitämä Neueda Labs Riiassa ja Cypher Apache Spark (nyt nimetty uudelleen Morpheukseksi), samoin kuin tutkimushankkeissa, kuten Cypher.PL ja Ingraph. Cypheriä kielenä hallitsee epävirallinen yhteisö openCypher-projektina, joka on pitänyt viisi kasvotusten avointa Cypher-toteuttajien kokousta helmikuusta 2017 lähtien.

Cypher 9 ja Cypher 10

Nykyiseen Cypher-versioon (mukaan lukien ajallinen laajennus) viitataan nimellä Cypher 9. Ennen GQL-projektia oli tarkoitus luoda uusi versio, Cypher 10 [ REF HEADING BELOW ], joka sisältäisi ominaisuuksia, kuten skeema ja säveltämättömät graafikyselyt. ja näkymät. Ensimmäiset Cypher 10 -mallit, mukaan lukien kaavion rakentaminen ja projektio, toteutettiin Cypher for Apache Spark -projektissa vuodesta 2016 alkaen.

PGQL

PGQL on Oracle Inc.:n suunnittelema ja toteuttama kieli, mutta se on saatavana avoimen lähdekoodin määrityksenä yhdessä JVM-jäsentelyohjelmiston kanssa. PGQL yhdistää tutun SQL SELECT -syntaksin, mukaan lukien SQL-lausekkeet ja tulosten järjestämisen ja yhdistämisen, Cypheriä vastaavan kielen kanssa. Se sallii kaavion määrittelyn kyselyn ja sisältää makrojen mahdollisuuden kaapata "kuvionäkymiä" tai nimettyjä alikuvioita. Se ei tue lisäys- tai päivitystoimintoja, koska ne on suunniteltu ensisijaisesti analyysiympäristöön, kuten Oraclen PGX-tuotteeseen. PGQL on toteutettu myös Oracle Big Data Spatial and Graph -sovelluksessa ja tutkimusprojektissa PGX.D / Async.

G-ydin

G-CORE on akateemisten ja teollisten tutkijoiden ja kielisuunnittelijoiden ryhmän suunnittelema tutkimuskieli, joka hyödyntää Cypherin, PGQL: n ja SPARQL: n ominaisuuksia . Projekti toteutettiin Linked Data Benchmark Councilin (LDBC) alaisuudessa, aloittaen Graph Query Language -työryhmän perustamisesta loppuvuodesta 2015, ja suurin osa paperinkirjoittamisesta tehtiin vuonna 2017. G-CORE on yhdistettävä kieli, joka on suljettu kaavioiden yli: kaaviotulokset käsitellään kaaviolähdön luomiseksi, uuden kaavion rakentamiseen käytetään kuvaajan projektioita ja kuvaajasarjaoperaatioita. G-CORE-kyselyt ovat puhtaita funktioita kaavioissa, joilla ei ole sivuvaikutuksia, mikä tarkoittaa, että kieli ei määritä toimintoja, jotka muuttavat (päivittävät tai poistavat) tallennettua tietoa. G-CORE esittelee näkymiä (nimettyjä kyselyjä). Se sisältää myös polut elementteinä kaaviossa ("polut ensimmäisen luokan kansalaisina"), joita voidaan kysyä riippumatta ennustetuista poluista (jotka lasketaan kyselyhetkellä solmu- ja reunaelementtien yli). G-CORE on osittain toteutettu avoimen lähdekoodin tutkimushankkeissa LDBC GitHub -organisaatiossa.

GSQL

GSQL on kieli, joka on suunniteltu TigerGraph Inc: n kiinteistökäyrätietokantaan. TigerGraph-kielisuunnittelijat ovat lokakuusta 2018 lähtien mainostaneet ja työskennelleet GQL-projektin parissa. GSQL on Turingin kokonainen kieli, joka sisältää proseduurivirtauksen hallinnan ja iteroinnin sekä mahdollisuuden kerätä ja muokata ohjelman suoritukseen liittyviä laskettuja arvoja koko kuvaajalle tai kuvaajille, joita kutsutaan akuumeiksi. Nämä ominaisuudet on suunniteltu mahdollistamaan iteratiivisten kaaviolaskelmien yhdistäminen tietojen etsintään ja hakuun. GSQL-kaaviot on kuvattava pisteiden ja reunojen kaavalla, joka rajoittaa kaikkia lisäyksiä ja päivityksiä. Tällä kaavalla on siis SQL-skeeman suljettu maailmaominaisuus, ja tätä GSQL: n näkökohtaa (heijastuu myös Morpheus-projektista johtuviin suunnitteluehdotuksiin) ehdotetaan GQL: n tärkeäksi valinnaiseksi ominaisuudeksi.

Vertexit ja reunat ovat nimeltään skeemaobjekteja, jotka sisältävät tietoja, mutta määrittelevät myös laskennallisen tyypin, aivan kuten SQL-taulukot ovat tietosäiliöitä, joihin liittyy implisiittinen rivityyppi. GSQL-kaaviot koostetaan sitten näistä kärkipisteistä ja reunaryhmistä, ja useat nimetyt kaaviot voivat sisältää saman kärkipisteen tai reunaryhmän. GSQL on kehittänyt uusia ominaisuuksia sen julkaisemisesta syyskuussa 2017 lähtien, etenkin ottamalla käyttöön vaihtuvan pituisen reunamallien sovituksen käyttäen syntaksia, joka liittyy Cypherissä, PGQL: ssä ja SQL / PGQ: ssa, mutta myös tyyliltään lähellä kiinteän pituisia malleja Microsoft SQL / Server-kaavio

GSQL tukee myös multigrafien käsitettä, jonka avulla kaavion osajoukoilla on roolipohjainen pääsynhallinta. Monigrafiikat ovat tärkeitä yritystason kaavioille, jotka tarvitsevat hienorakeista pääsynhallintaa eri käyttäjille.

Morpheus: useita kuvaajia ja yhdistettäviä kaaviokyselyjä Apache Sparkissa

Opencypher Morpheus -projekti toteuttaa Cypherin Apache Spark -käyttäjille. Vuodesta 2016 lähtien tämä projekti toteutettiin alun perin kolmen siihen liittyvän työn rinnalla, joihin myös Morpheus-suunnittelijat osallistuivat: SQL / PGQ, G-CORE ja Cypher-laajennusten suunnittelu useiden kaavioiden kyselyä ja rakentamista varten. Morpheus-projekti toimi testikenttänä Cypher-laajennuksille (tunnetaan nimellä "Cypher 10") kaavion DDL- ja kyselykielilaajennusten kahdella alueella.

Kaavio DDL-ominaisuudet sisältävät

määritys ominaisuuskäyränäkymistä JDBC- liitettyjen SQL-taulukkojen ja Spark DataFrame -kehysten yli
kaaviomallien tai -tyyppien määrittely, joka määritetään yhdistämällä solmu- ja reunatyyppikuviot alatyypillä
rajoittaa kaavion sisältöä suljetulla tai kiinteällä kaavalla
luodaan luettelomerkintöjä useille nimetyille kaavioille hierarkkisesti järjestetyssä luettelossa
Kuvaa tietolähteet yhdistetyn, heterogeenisen luettelon muodostamiseksi
luettelomerkintöjen luominen nimetyille kyselyille (näkymille)

Kaaviokyselykielen laajennukset sisältävät

kuvaajan liitos
kuvion osumien tuloksista laskettujen kaavioiden projektio useilla syöttökaavioilla
tuki taulukoille (Spark DataFrames) kyselyjen syötteinä ("ohjaustaulukot")
näkymät, jotka hyväksyvät nimettyjä tai projisoituja kaavioita parametreiksi.

Näitä ominaisuuksia on ehdotettu tuloiksi ominaisuusgraafikyselykielien standardointiin GQL-projektissa.

Languages

In other projects