GQL ( Graph Query Language ) est un langage de requête standardisé pour les graphes de propriétés décrit pour la première fois dans la norme ISO/IEC 39075, publiée en avril 2024...
Le projet GQL est l'aboutissement d'initiatives convergentes remontant à 2016, notamment une proposition privée de Neo4j à d'autres fournisseurs de bases de données en juillet 2016, et une proposition du personnel technique d'Oracle dans le cadre du processus de normalisation ISO/IEC JTC 1 plus tard cette année-là.
Proposition de projet GQL 2019
En septembre 2019, une proposition de projet visant à créer un nouveau langage de requêtes graphiques standard (ISO/IEC 39075 Technologies de l'information — Langages de bases de données — GQL) a été approuvée par un vote des organismes nationaux de normalisation membres du Comité technique mixte ISO/IEC 1 ( ISO/IEC JTC 1 ). Le JTC 1 est responsable des normes internationales en matière de technologies de l'information. GQL se veut un langage de requêtes de bases de données déclaratif, à l'instar de SQL .
La proposition de projet GQL 2019 stipule :
L'utilisation de graphes comme représentation fondamentale pour la modélisation des données est une approche émergente en gestion des données . Dans cette approche, l' ensemble de données est modélisé sous forme de graphe, chaque entité étant représentée par un sommet (ou nœud) et chaque relation entre deux entités par une arête (ou lien) reliant les sommets correspondants. Le modèle de données sous forme de graphes suscite un intérêt croissant en raison de ses avantages uniques.
Tout d'abord, le modèle de graphe est particulièrement adapté aux ensembles de données présentant des structures hiérarchiques, complexes, voire arbitraires. Ces structures peuvent être facilement représentées par des arêtes dans le modèle de graphe. Cette approche peut s'avérer plus pratique que le modèle relationnel, qui exige la normalisation des données en un ensemble de tables aux types de lignes fixes .
Deuxièmement, le modèle de graphe permet l'exécution efficace de requêtes complexes ou de fonctions d'analyse de données nécessitant l'observation de relations à plusieurs sauts entre les entités de données, telles que les requêtes d'accessibilité , les requêtes de chemin le plus court ou le moins coûteux , ou encore l'analyse de centralité . Deux modèles de graphes sont actuellement utilisés : le modèle RDF ( Resource Description Framework ) et le modèle de graphe de propriétés. Le modèle RDF a été normalisé par le W3C dans plusieurs spécifications. Le modèle de graphe de propriétés, quant à lui, compte de nombreuses implémentations dans les bases de données graphiques , les algorithmes de graphes et les outils de traitement de graphes. Cependant, il manque un langage de requête standardisé et commun pour les graphes de propriétés (à l'instar de SQL pour les systèmes de bases de données relationnelles). GQL est proposé pour combler cette lacune.
Norme ISO officielle
La norme GQL, ISO/IEC 39075:2024 Technologies de l'information – Langages de bases de données – GQL, a été officiellement publiée par l'ISO le 12 avril 2024.
organisation du projet GQL
Le projet GQL est dirigé par Stefan Plantikow (qui fut le premier ingénieur principal du projet Cypher pour Apache Spark de Neo4j ) et Stephen Cannan (rédacteur des corrections techniques de SQL). Ils sont également les rédacteurs des premières versions de travail de la spécification GQL.
Conformément à ses objectifs initiaux , le projet GQL vise à compléter le travail de création d'une spécification normative en langage naturel implémentable par des initiatives communautaires de soutien permettant la contribution de ceux qui ne peuvent ou ne souhaitent pas participer au processus formel de définition d'une norme internationale JTC 1 . En juillet 2019, le sémantique dénotationnelle formelle de GQL a été proposé lors de la troisième mise à jour de la communauté GQL en octobre 2019
ISO/IEC JTC 1/SC 32 WG3
Sept organismes nationaux de normalisation (États-Unis, Chine, Corée, Pays-Bas, Royaume-Uni, Danemark et Suède) ont désigné des experts nationaux pour travailler sur ce projet, mené par le Groupe de travail 3 (Langages de bases de données) du Sous-comité 32 (Gestion et échange de données) de l’ISO/CEI JTC 1, généralement abrégé en ISO/CEI JTC 1/SC 32 WG3 , ou simplement WG3 . Le WG3 (et ses comités prédécesseurs directs au sein du JTC 1) est responsable de la norme SQL depuis 1987.
Étapes ISO
Requête SQL/PGQ sur le graphe de propriétés
Les travaux antérieurs des groupes de travail WG3 et SC32, notamment au sein d' INCITS Data Management (anciennement INCITS DM32), ont contribué à la définition d'une nouvelle partie 16 de la norme SQL. Celle-ci autorise l'exécution d'une requête de graphe en lecture seule au sein d'une instruction SQL SELECT, en faisant correspondre un modèle de graphe à l'aide d'une syntaxe très proche de Cypher, PGQL et G-CORE, et en renvoyant une table de valeurs de données. SQL/PGQ intègre également un langage de description de données (DDL) permettant de mapper des tables SQL à un objet de schéma de vue de graphe, dont les nœuds et les arêtes sont associés à des ensembles d'étiquettes et de propriétés de données. Le projet GQL est étroitement coordonné avec le projet SQL/PGQ (extension de la norme ISO 9075 SQL). Les groupes de travail techniques aux États-Unis (INCITS DM32) et au niveau international (SC32/WG3) comptent plusieurs contributeurs experts qui participent aux deux projets. La proposition de projet GQL exige un alignement étroit entre SQL/PGQ et GQL, indiquant que GQL sera en général un sur-ensemble de SQL/PGQ.
Vous trouverez plus de détails sur le langage de correspondance de modèles dans l'article « Graph Pattern Matching in GQL and SQL/PGQ »
Zéro
Cypher est un langage initialement conçu par Andrés Taylor et ses collègues de Neo4j Inc., et implémenté pour la première fois par cette société en 2011. Depuis 2015, il est disponible en open source sous forme de description de langage , avec des outils de grammaire, une interface JVM qui analyse les requêtes Cypher et un kit de compatibilité technologique (TCK) comprenant plus de 2 000 scénarios de test, utilisant Cucumber pour assurer la portabilité du langage d'implémentation. Le TCK reflète la description du langage et une amélioration concernant les types de données et les fonctions temporelles, documentée dans une proposition d'amélioration de Cypher.
Cypher permet la création, la lecture, la mise à jour et la suppression d'éléments graphiques, et constitue un langage qui peut donc être utilisé pour les moteurs d'analyse et les bases de données transactionnelles.
Interrogation avec des modèles de chemin visuel
Cypher utilise des motifs compacts de longueur fixe et variable qui combinent des représentations visuelles des topologies des nœuds et des relations (arêtes), avec des prédicats d'existence d'étiquettes et de valeurs de propriétés. (Ces motifs sont généralement appelés motifs « art ASCII » et ont été initialement conçus pour commenter les programmes utilisant une API graphique de bas niveau. ) En comparant un tel motif aux éléments de données du graphe, une requête peut extraire des références aux nœuds, relations et chemins d'intérêt. Ces références sont émises sous forme de « table de liaison » où les noms de colonnes sont associés à un multi-ensemble d'éléments du graphe. Le nom d'une colonne devient le nom d'une « variable de liaison », dont la valeur est une référence spécifique à un élément du graphe pour chaque ligne de la table.
Par exemple, un modèle générera un tableau de sortie à deux colonnes. La première colonne, nommée , contiendra des références aux nœuds portant l'étiquette . La seconde colonne, nommée , contiendra des références aux nœuds portant l'étiquette , indiquant la ville de résidence de la personne.
Les variables de liaison peuvent ensuite être déréférencées pour accéder aux valeurs des propriétés associées aux éléments référencés par une variable. La requête d'exemple pourrait se terminer par un , ce qui donnerait une requête complète comme celle-ci :MATCH ( p : Personne ) -[ : RÉSIDE_À ]-> ( c : Ville ) RETURN p . prénom , p . nom , c . nom , c . état
On obtiendrait ainsi un tableau final à quatre colonnes répertoriant les noms des habitants des villes représentées dans le graphique.
Les requêtes basées sur des modèles permettent d'exprimer des jointures en combinant plusieurs modèles qui utilisent la même variable de liaison pour exprimer une jointure naturelle à l'aide de la clause :
MATCH ( p : Person ) -[ : LIVES_IN ]-> ( c : City ), ( p : Person ) -[ : NATIONAL_OF ]-> ( EUCountry ) RETURN p . first_name , p . last_name , c . name , c . state
Cette requête ne renverrait que le lieu de résidence des ressortissants de l'UE.
Une jointure externe peut être exprimée par :
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
Cette requête renverrait la ville de résidence de chaque personne du graphique disposant d'informations résidentielles et, s'il s'agit d'un ressortissant de l'UE, le pays d'origine.
Les requêtes peuvent ainsi projeter un sous-graphe du graphe d'entrée dans la requête, puis extraire les valeurs de données associées à ce sous-graphe. Ces valeurs peuvent également être traitées par des fonctions, notamment des fonctions d'agrégation, permettant la projection de valeurs calculées qui rendent l'information contenue dans le graphe projeté de diverses manières. À l'instar de G-CORE et Morpheus, GQL vise à projeter les sous-graphes définis par la correspondance de motifs (et les graphes ensuite calculés sur ces sous-graphes) sous forme de nouveaux graphes à renvoyer par une requête.
D'un point de vue général, GQL surveille trois éléments clés lors de l'évaluation et de l'exécution des requêtes :
le graphe actif - le graphe de propriétés actuellement utilisé pour la correspondance de modèles ;
la table active – où sont stockées les informations calculées jusqu'à présent ; et
l'enregistrement actif - qui contient le tuple de résultat actuellement utilisé.
Ce type de modèles est devenu omniprésent dans les langages de requêtes de graphes de propriétés et constitue la base du sous-langage de modèles avancé défini dans SQL/PGQ, qui deviendra probablement un sous-ensemble du langage GQL. Cypher utilise également des modèles pour les clauses d'insertion et de modification ( et ), et des propositions ont été faites dans le cadre du projet GQL pour collecter les modèles de nœuds et d'arêtes afin de décrire les types de graphes.
Cypher 9 et Cypher 10
La version actuelle de Cypher (y compris l'extension temporelle) est appelée Cypher 9. Avant le projet GQL, il était prévu de créer une nouvelle version, Cypher 10 [ REF HEADING BELOW ], qui intégrerait des fonctionnalités telles que les schémas et les requêtes et vues de graphes composables. Les premières ébauches de Cypher 10, incluant la construction et la projection de graphes, ont été implémentées dans le cadre du projet Cypher pour Apache Spark à partir de 2016.
PGQL
PGQL est un langage conçu et implémenté par Oracle Inc., mais disponible en tant que spécification open source , accompagné d'un logiciel d'analyse syntaxique pour la JVM . PGQL combine la syntaxe SQL SELECT classique, incluant les expressions SQL, le tri et l'agrégation des résultats, avec un langage de correspondance de motifs très similaire à celui de Cypher. Il permet d'interroger la spécification du graphe et offre la possibilité d'utiliser des macros pour capturer des « vues de motifs », ou sous-motifs nommés. Il ne prend pas en charge les opérations d'insertion ou de mise à jour, ayant été conçu principalement pour un environnement analytique, tel que le produit PGX d'Oracle. PGQL a également été implémenté dans Oracle Big Data Spatial and Graph, ainsi que dans le cadre du projet de recherche PGX.D/Async
G-CORE
G-CORE est un langage de recherche conçu par un groupe de chercheurs et de concepteurs de langages issus du monde académique et industriel. Il s'inspire de fonctionnalités de Cypher, PGQL et SPARQL . Ce projet a été mené sous l'égide du Linked Data Benchmark Council (LDBC), avec la création d'un groupe de travail sur les langages de requêtes graphiques fin 2015 et la rédaction de la majeure partie des articles scientifiques en 2017. G-CORE est un langage composable fermé sur les graphes : les entrées graphiques sont traitées pour créer une sortie graphique, grâce à des projections et des opérations sur les ensembles de graphes. Les requêtes G-CORE sont des fonctions pures sur les graphes, sans effets de bord. Autrement dit, le langage ne définit pas d'opérations modifiant (mise à jour ou suppression) les données stockées. G-CORE introduit les vues (requêtes nommées). Il intègre également les chemins comme éléments d'un graphe (« chemins comme éléments de première classe »), qui peuvent être interrogés indépendamment des chemins projetés (calculés lors de la requête à partir des nœuds et des arêtes). G-CORE a été partiellement implémenté dans des projets de recherche open source de l'organisation LDBC sur GitHub.
GSQL
GSQL est un langage conçu pour la base de données graphiques propriétaire de TigerGraph Inc. Depuis octobre 2018, les concepteurs du langage TigerGraph promeuvent et développent le projet GSQL. GSQL est un langage Turing-complet qui intègre le contrôle de flux procédural et l'itération, ainsi qu'un mécanisme permettant de collecter et de modifier les valeurs calculées lors de l'exécution d'un programme, que ce soit pour l'ensemble du graphe ou pour des éléments spécifiques appelés accumulateurs. Ces fonctionnalités permettent de combiner les calculs itératifs sur les graphes avec l'exploration et la récupération de données. Les graphes GSQL doivent être décrits par un schéma de sommets et d'arêtes, qui contraint toutes les insertions et mises à jour. Ce schéma possède donc la propriété de monde clos d'un schéma SQL, et cet aspect de GSQL (également présent dans les propositions de conception issues du projet Morpheus ) est proposé comme une fonctionnalité optionnelle importante.
Les sommets et les arêtes sont des objets de schéma nommés qui contiennent des données et définissent un type imputé, à l'instar des tables SQL qui sont des conteneurs de données, avec un type de ligne implicite associé. Les graphes GSQL sont ensuite composés de ces ensembles de sommets et d'arêtes, et plusieurs graphes nommés peuvent inclure le même ensemble de sommets ou d'arêtes. Depuis sa sortie en septembre 2017 , GSQL a développé de nouvelles fonctionnalités , notamment l'introduction de la correspondance de motifs d'arêtes de longueur variable , utilisant une syntaxe apparentée à celle de Cypher, PGQL et SQL/PGQ, mais également proche, dans son style, des motifs de longueur fixe proposés par Morpheus : plusieurs graphes et requêtes de graphes composables dans Apache Spark
définition de schémas ou de types de graphes définis par assemblage de modèles de types de nœuds et de types d'arêtes, avec sous-typage
contraindre le contenu d'un graphe par un schéma fermé ou fixe
création d'entrées de catalogue pour plusieurs graphes nommés dans un catalogue organisé hiérarchiquement
sources de données graphiques pour former un catalogue fédéré et hétérogène
création d'entrées de catalogue pour les requêtes nommées (vues)
Les extensions du langage de requêtes graphiques incluent
union de graphes
projection de graphes calculés à partir des résultats de correspondances de motifs sur plusieurs graphes d'entrée
prise en charge des tables (Spark DataFrames) comme entrées de requêtes (« tables de pilotage »)
vues qui acceptent des graphiques nommés ou projetés comme paramètres.
Ces fonctionnalités ont été proposées comme éléments d'entrée pour la normalisation des langages de requêtes de graphes de propriétés dans le cadre du projet GQL.
Limites
Les requêtes GQL permettent de renvoyer différents types de chemins entre deux nœuds (le plus court, le plus simple, le chemin complet, le chemin acyclique, etc.). Cependant, elles ne vérifient que l'existence du chemin. La prise en charge des propriétés complexes des chemins, telles que les poids et les coûts, est limitée. Par exemple, la comparaison des poids des arêtes adjacentes n'est pas possible.