Partager via


Guide de langue GQL

Note

Cette fonctionnalité est actuellement disponible en préversion publique. Cette préversion est fournie sans contrat de niveau de service, et n’est pas recommandée pour les charges de travail de production. Certaines fonctionnalités peuvent être limitées ou non prises en charge. Pour plus d’informations, consultez Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure.

Le langage de requête graphique GQL est le langage de requête normalisé ISO pour les bases de données de graphe. Il vous permet d’interroger et d’utiliser efficacement les données de graphe.

GQL est développé par le même groupe de travail ISO qui standardise SQL, garantissant cohérence et rigueur. Si vous connaissez SQL, vous trouverez de nombreuses similitudes dans GQL (expressions, prédicats, types) – ce qui facilite le démarrage. Ce guide sert à la fois les nouveaux arrivants à apprendre les principes fondamentaux de GQL et les utilisateurs expérimentés cherchant des techniques avancées et des informations de référence complètes.

Note

La norme internationale officielle pour GQL est ISO/IEC 39075 Information Technology - Database Languages - GQL.

Prerequisites

Avant de vous plonger dans GQL, vous devez être familiarisé avec ces concepts :

  • Compréhension de base des bases de données - Une expérience avec tout système de bases de données (comme relationnel (SQL), NoSQL ou graph) est utile
  • Concepts du graphe - Présentation des nœuds, des arêtes et des relations dans les données connectées
  • Notions de base de la requête - Connaissance des concepts de base de requête tels que le filtrage, le tri et l’agrégation

Arrière-plan recommandé :

  • L’expérience avec les langages SQL ou openCypher facilite l’apprentissage de la syntaxe GQL (ce sont les racines de GQL)
  • La connaissance de la modélisation des données permet de concevoir des schémas de graphe
  • Compréhension de votre cas d’usage spécifique pour les données de graphe

Ce dont vous aurez besoin :

  • Accès à Microsoft Fabric avec des fonctionnalités de graphe
  • Exemples de données ou de volonté d’utiliser nos exemples de réseaux sociaux
  • Éditeur de texte de base pour l’écriture de requêtes

Conseil / Astuce

Si vous débutez avec les bases de données de graphe, commencez par la vue d’ensemble des modèles de données de graphe avant de continuer avec ce guide.

Ce qui rend GQL spécial

GQL est conçu spécifiquement pour les données de graphe. Cela rend naturel et intuitif l’utilisation des informations connectées.

Contrairement à SQL, qui s’appuie sur les jointures de tables pour exprimer les relations, GQL utilise des motifs graphiques visuels, qui reflètent directement la façon dont les entités sont connectées, facilitant la lecture et la raisonnement des requêtes.

Disons que vous voulez trouver des personnes et leurs amis (des gens qui se connaissent) qui sont tous deux nés avant 1999. Voici comment GQL exprime cela en utilisant un motif graphique visuel :

MATCH (person:Person)-[:knows]-(friend:Person)
WHERE person.birthday < 19990101 
  AND friend.birthday < 19990101
RETURN person.firstName || ' ' || person.lastName AS person_name, 
       friend.firstName || ' ' || friend.lastName AS friend_name

Cette requête trouve des amis (des gens qui se connaissent) qui sont nés avant 1999. Le modèle (person:Person)-[:knows]-(friend:Person) montre visuellement la structure de relation que vous recherchez, comme dessiner un diagramme de vos données.

Principes fondamentaux de GQL

Avant de vous plonger dans des requêtes, comprenez ces concepts fondamentaux qui constituent la base de GQL :

  • Les graphes stockent vos données sous forme de nœuds (entités) et d’arêtes (relations), chacun avec des étiquettes et des propriétés
  • Les types de graphiques agissent comme des schémas, en définissant les nœuds et les arêtes qui peuvent exister dans votre graphique
  • Les contraintes sont des règles et restrictions supplémentaires imposées par les types de graphes sur les graphes pour garantir l’intégrité des données
  • Les requêtes utilisent des instructions telles que MATCH, FILTERet RETURN pour traiter les données et afficher les résultats
  • Les modèles décrivent les structures de graphe que vous souhaitez trouver à l’aide d’une syntaxe visuelle intuitive
  • Les expressions effectuent des calculs et des comparaisons sur vos données, comme les expressions SQL
  • Les prédicats sont des expressions de valeurs booléennes utilisées pour filtrer les résultats au sein des requêtes
  • Les types de valeurs définissent les types de valeurs que vous pouvez traiter et stocker

Présentation des données de graphe

Pour travailler efficacement avec GQL, vous devez comprendre comment les données de graphe sont structurées. Cette base vous aide à écrire de meilleures requêtes et à modéliser efficacement vos données.

Nœuds et arêtes : blocs de construction

Dans GQL, vous utilisez des graphiques de propriétés étiquetés. Un graphique se compose de deux types d’éléments :

Les nœuds représentent généralement les entités (les « noms ») dans votre système, comme les personnes, les organisations, les publications ou les produits. Ils sont des objets indépendants qui existent dans votre domaine. Les nœuds sont parfois également appelés sommets.

Les arêtes représentent les relations entre les entités (les « verbes ») : comment vos entités se connectent et interagissent. Par exemple, des personnes se connaissent (:knows), des organisations opérant dans des régions spécifiques (:operates), ou des clients ayant acheté des produits (:purchased).
Les arêtes sont parfois également appelées relations.

Chaque élément de graphe présente les caractéristiques suivantes :

  • ID interne qui l’identifie de manière unique
  • Une ou plusieurs étiquettes ( noms descriptifs tels que Person ou knows. Dans Microsoft Fabric, les arêtes des graphes ont toujours exactement une étiquette.
  • Propriétés — paires nom-valeur qui stockent des données sur l’élément (telles que firstName: "Alice" ou birthday: "19730108").

Comment les graphiques sont structurés

Chaque périphérie connecte exactement deux nœuds : une source et une destination. Cette connexion crée la structure du graphique et montre comment les entités se rapportent les unes aux autres. La direction des arêtes importe : une Person personne follows qui Person crée une relation dirigée.

Note

Graph dans Microsoft Fabric ne prend actuellement pas en charge les arêtes non dirigées.

Les graphes de propriétés tels que pris en charge dans Microsoft Fabric sont toujours bien formés, ce qui signifie que chaque arête relie deux nœuds valides. Si vous voyez un bord dans un graphique, ses deux points de terminaison existent dans le même graphique.

Modèles de graphe et types de graphiques

La structure d’un graphique dans Microsoft Fabric est décrite par son modèle de graphe, qui agit comme un schéma de base de données pour votre domaine d’application. Les modèles graphiques définissent :

  • Quels nœuds et arêtes peuvent exister
  • Quelles étiquettes et propriétés elles peuvent avoir
  • Comment les nœuds et les arêtes peuvent se connecter

Les modèles graphiques garantissent également l’intégrité des données par le biais de contraintes, en particulier les contraintes de clé de nœud qui spécifient les propriétés qui identifient de manière unique chaque nœud.

Note

Les modèles de graphe peuvent être spécifiés à l’aide de la syntaxe standard GQL, auquel cas ils sont appelés types de graphiques.

Exemple pratique : réseau social

Tout au long de cette documentation, nous utilisons un exemple de réseau social pour illustrer les concepts GQL. Comprendre ce domaine vous aide à suivre les exemples et à appliquer des modèles similaires à vos propres données.

Diagramme montrant le schéma du réseau social.

Note

Le réseau social est un exemple dérivé du LDBC SNB (LDBC Social Network Benchmark) publié par le GDC (Graph Data Council). Pour plus d’informations, consultez l’article « The LDBC Social Network Benchmark ».

Entités de réseau social

Notre réseau social comprend ces principaux types de nœuds, représentant des entités du domaine :

Les personnes ont des informations personnelles telles que les noms, les anniversaires et les sexes. Ils vivent dans des villes et forment des liens sociaux.

Les emplacements forment une hiérarchie géographique :

  • Villes comme « New York » ou « Londres »
  • Pays/régions tels que « États-Unis » ou « Royaume-Uni »
  • Continents comme « Amérique du Nord » ou « Europe »

Organisations où les personnes passent du temps :

  • Universités où les gens étudient
  • Entreprises où travaillent les personnes

Contenu et discussions :

  • Forums avec des titres qui contiennent des billets
  • Publications avec du contenu, une langue et des images facultatives
  • Commentaires qui répondent aux publications ou à d’autres commentaires
  • Balises qui catégorisent le contenu et représentent les intérêts

Comment tout se connecte

Les connexions entre les entités rendent le réseau intéressant :

  • Les gens se connaissent (amitiés, :knows)
  • Les gens travaillent dans des entreprises (:workAt) ou étudient à l’université (:studyAt)
  • Les gens créent des publications et des commentaires (:hasCreator)
  • Les gens aiment les publications et commentaires (:likes)
  • Les publications, forums, commentaires peuvent avoir des tags (:hasTag)
  • Les gens s’intéressent à des tags spécifiques (:hasInterest)
  • Les forums contiennent des publications (:containerOf) et comptent des membres (:hasMember) et des modérateurs (:hasModerator)

Les arêtes du graphique représentent des relations de domaine. Ce réseau enrichi crée de nombreuses opportunités pour les requêtes et l’analyse intéressantes.

Vos premières requêtes GQL

Maintenant que vous comprenez les principes de base du graphique, voyons comment interroger des données de graphe à l’aide de GQL. Ces exemples proviennent de simples à complexes, montrant comment l’approche de GQL rend les requêtes graphiques intuitives et puissantes.

Démarrer simple : trouver toutes les personnes

Commençons par la requête la plus basique possible, trouvez les noms (prénom, nom de famille) de toutes les personnes (:Persons) du graphe.

MATCH (p:Person)
RETURN p.firstName, p.lastName

Cette requête s’exécute comme suit :

  1. MATCH recherche tous les nœuds étiquetés Person
  2. RETURN affiche leur prénom et leur nom

Ajouter un filtrage : rechercher des personnes spécifiques

Maintenant, trouvons des personnes avec des caractéristiques spécifiques, dans ce cas, tout le monde nommé Alice, et montrons leurs noms et dates de naissance.

MATCH (p:Person)
FILTER p.firstName = 'Annemarie'
RETURN p.firstName, p.lastName, p.birthday

Cette requête s’exécute comme suit :

  1. MATCH trouve tous les nœuds (p) étiquetés Person
  2. FILTER nœuds (p) dont le prénom est Alice
  3. RETURN Montre leur prénom, son nom de famille et leur date de naissance

Structure de requête de base

Les requêtes GQL de base suivent tous un modèle cohérent : une séquence d’instructions qui fonctionnent ensemble pour rechercher, filtrer et retourner des données. La plupart des requêtes commencent par MATCH trouver des motifs dans le graphe et se terminent par RETURN spécifier la sortie.

Voici une requête simple qui trouve des paires de personnes qui se connaissent et ont la même date de naissance, puis retourne le total de ces paires d’amis.

MATCH (n:Person)-[:knows]-(m:Person)
FILTER n.birthday = m.birthday
RETURN count(*) AS same_age_friends

Cette requête s’exécute comme suit :

  1. MATCH recherche toutes les paires de Person nœuds qui se connaissent les uns les autres
  2. FILTER garde uniquement les paires où les deux personnes ont le même anniversaire
  3. RETURN compte combien de paires d’amis existent

Conseil / Astuce

Le filtrage peut également être effectué directement dans le cadre d’un modèle en ajoutant une WHERE clause. Par exemple, MATCH (n:Person WHERE n.age > 23) ne correspondra qu’aux Person nœuds dont age la propriété est supérieure à 23.

Note

GQL prend en charge les commentaires de ligne de style // C, les commentaires de ligne de style -- SQL et les commentaires de bloc de style /* */ C.

Énoncés courants

  • MATCH: Identifie le motif graphique à rechercher — c’est là que vous définissez la structure des données qui vous intéressent.
  • LET: Attribue de nouvelles variables ou des valeurs calculées en fonction de données appariées — ajoute des colonnes dérivées au résultat.
  • FILTER: Réduit les résultats en appliquant des conditions — supprime les lignes qui ne remplissent pas les critères.
  • ORDER BY: Trie les données filtrées — aide à organiser la sortie selon un ou plusieurs champs.
  • OFFSET et LIMIT: Restreignez le nombre de lignes retournées — utile pour la pagination ou les requêtes top-k.
  • RETURN: Spécifie la sortie finale — définit quelles données doivent être incluses dans l’ensemble de résultats et effectue l’agrégation.

Fonctionnement des instructions

Les instructions GQL forment un pipeline, où chaque instruction traite la sortie de la précédente. Cette exécution séquentielle facilite la lecture et le débogage des requêtes car l’ordre d’exécution correspond à l’ordre de lecture.

Points clés :

  • Les instructions s’exécutent efficacement de manière séquentielle.
  • Chaque instruction transforme les données et les transmet à la suivante.
  • Cela crée un flux de données clair et prévisible qui simplifie les requêtes complexes.

Important

En interne, l’exécution des instructions peut être réorganisée et les instructions individuelles peuvent être exécutées en parallèle par Microsoft Fabric pour maximiser les performances. Cependant, cela n’affectera pas la justesse des résultats.

Exemple

La requête GQL suivante montre les 10 premières personnes travaillant dans les entreprises avec « Air » dans leur nom, les trie par nom complet, puis retourne leur nom complet ainsi que celui de leur entreprise.

-- Data flows: Match → Let → Filter → Order → Limit → Return
MATCH (p:Person)-[:workAt]->(c:Company)           -- Input: unit table, Output: (p, c) table
LET fullName = p.firstName || ' ' || p.lastName   -- Input: (p, c) table, Output: (p, c, fullName) table
FILTER c.name CONTAINS 'Air'                      -- Input: (p, c, fullName) table, Output: filtered table
ORDER BY fullName                                 -- Input: filtered table, Output: sorted table
LIMIT 10                                          -- Input: sorted table, Output: top 10 rows table
RETURN fullName, c.name AS companyName            -- Input: top 10 rows table
                                                  -- Output: projected (fullName, companyName) result table

Cette requête s’exécute comme suit :

  1. MATCH trouve des personnes travaillant dans des entreprises avec « Air » dans leur nom
  2. LET crée des noms complets en combinant prénoms et noms de famille
  3. FILTER ne garde que des employés Contoso
  4. ORDER BY tris par nom complet
  5. LIMIT Prend les 10 premiers résultats
  6. RETURN Noms de retours et emplacements des entreprises

Les variables connectent vos données

Les variables (comme p, cet fullName dans les exemples précédents) portent des données entre des instructions. Lorsque vous réutilisez un nom de variable, GQL garantit automatiquement qu’il fait référence aux mêmes données, créant des conditions de jointure puissantes. Les variables sont parfois également appelées variables de liaison.

Les variables peuvent être classées de différentes manières :

Par source de liaison :

Types de variables de modèle :

  • Variables d’élément : liaison à des valeurs de référence d’élément de graphe
    • Variables de nœud : liaison à des nœuds individuels
    • Variables de périphérie : liaison à des arêtes individuelles
  • Variables de chemin d’accès : liaison à des valeurs de chemin représentant des chemins correspondants

Par degré de référence :

  • Variables Singleton : liaison à des valeurs de référence d’élément individuelles à partir de modèles
  • Variables de groupe : liaison à des listes de valeurs de référence d’élément à partir de modèles de longueur variable (voir Advanced Aggregation Techniques)

Résultats et résultats d’exécution

Lorsque vous exécutez une requête, vous obtenez un résultat d’exécution composé des éléments suivants :

  • Table de résultats (facultative) avec les données de votre RETURN instruction.
  • Informations d’état indiquant si la requête a réussi ou non.

Tables de résultats

La table de résultats ( le cas échéant) est le résultat réel de l’exécution de la requête.

Une table de résultats inclut des informations sur le nom et le type de ses colonnes, une séquence de noms de colonne préférée à utiliser pour afficher les résultats, si la table est ordonnée et les lignes réelles elles-mêmes.

Note

En cas d’échec d’exécution, aucune table de résultats n’est incluse dans le résultat de l’exécution.

Informations d’état

Diverses conditions notables (telles que les erreurs ou les avertissements) sont détectées pendant l’exécution de la requête. Chaque condition de ce type est enregistrée par un objet d’état dans les informations d’état du résultat d’exécution.

Les informations d’état se composent d’un objet d’état principal et d’une liste (éventuellement vide) d’objets d’état supplémentaires. L’objet d’état principal est toujours présent et indique si l’exécution de la requête a réussi ou échoué.

Chaque objet d’état inclut un code d’état à 5 chiffres (appelé GQLSTATUS) qui identifie la condition enregistrée ainsi qu’un message qui le décrit.

Codes d’état de réussite :

GQLSTATUS Message Quand
00000 remarque : réussite de la saisie semi-automatique Réussite avec au moins une ligne
00001 remarque : réussite de l’exécution - résultat omis Réussite sans table (actuellement inutilisée)
02000 remarque : aucune donnée Réussite avec zéro ligne

D’autres codes d’état indiquent d’autres erreurs ou avertissements détectés lors de l’exécution de la requête.

Important

Dans le code de l’application, utilisez toujours les codes d’état pour tester certaines conditions. Les codes d’état sont garantis comme stables et leur signification générale ne changera pas à l’avenir. Ne testez pas le contenu des messages, car le message concret rapporté pour un code d’état peut évoluer à l’avenir selon la requête ou même entre les exécutions d’une même requête.

En outre, les objets d’état peuvent contenir un objet d’état de cause sous-jacent et un enregistrement de diagnostic avec des informations supplémentaires qui caractérisent la condition enregistrée.

Concepts et instructions essentiels

Cette section couvre les blocs de construction principaux dont vous avez besoin pour écrire des requêtes GQL effectives. Chaque concept s’appuie sur des compétences pratiques en écriture de requêtes.

Modèles graphiques : recherche de structure

Les modèles de graphique sont le cœur des requêtes GQL. Ils vous permettent de décrire la structure de données que vous recherchez à l’aide d’une syntaxe visuelle intuitive qui ressemble aux relations que vous souhaitez trouver.

Modèles simples :

Commencez par les modèles de relation de base :

-- Find direct friendships
(p:Person)-[:knows]->(f:Person)

-- Find people working at any company
(p:Person)-[:workAt]->(c:Company)

-- Find cities in any country/region
(ci:City)-[:isPartOf]->(co:Country)  

Modèles avec des données spécifiques :

-- Find who works at Microsoft specifically
(p:Person)-[:workAt]->(c:Company)
WHERE p.firstName = 'Annemarie'

-- Find friends who are both young
(p:Person)-[:knows]->(f:Person)  
WHERE p.birthday > 19950101 AND f.birthday > 19950101

Expressions d’étiquette pour la sélection d’entité flexible :

(:Person|Company)-[:isLocatedIn]->(p:City|Country)  -- OR with |
(:Place&City)                                       -- AND with &  
(:Person&!Company)                                  -- NOT with !

Note

Les modèles de graphes avec plusieurs étiquettes d’éléments ne sont pas encore pris en charge (problème connu).

Les expressions d’étiquette vous permettent de faire correspondre différents types de nœuds dans un modèle unique, ce qui rend vos requêtes plus flexibles.

La réutilisation des variables crée des jointures puissantes :

-- Find coworkers: people who work at the same company
(c:Company)<-[:workAt]-(x:Person)-[:knows]-(y:Person)-[:workAt]->(c)

La réutilisation de variable c garantit que les deux personnes travaillent dans la même entreprise, en créant une contrainte de jointure automatique. Ce modèle est un modèle clé pour exprimer des relations « mêmes entités ».

Important

Insights critiques : la réutilisation des variables dans les modèles crée des contraintes structurelles. Cette technique est la façon dont vous exprimez des relations graphiques complexes telles que « amis qui travaillent dans la même entreprise » ou « personnes dans la même ville ».

Filtrage au niveau du modèle avec WHERE :

-- Filter during pattern matching (more efficient)
(p:Person WHERE p.birthday < 19940101)-[:workAt]->(c:Company WHERE c.id > 1000)

-- Filter edges during matching  
(p:Person)-[w:workAt WHERE w.workFrom >= 2000]->(c:Company)

Modèles de longueur variable délimitée :

(:Person)-[:knows]->{1,3}(:Person)  -- Friends up to 3 degrees away

Modèles TRAIL pour la traversée sans cycle :

Utilisez TRAIL des modèles pour empêcher les cycles pendant la traversée de graphe, en veillant à ce que chaque bord soit visité au plus une fois :

-- Find paths without visiting the same :knows edge twice
MATCH TRAIL (src:Person)-[:knows]->{1,4}(dst:Person)
WHERE src.firstName = 'Alice' AND dst.firstName = 'Bob'
RETURN count(*) AS num_connections
-- Find acyclic paths in social networks
MATCH TRAIL (p:Person)-[e:knows]->{,3}(celebrity:Person)
RETURN 
  p.firstName || ' ' || p.lastName AS person_name, 
  celebrity.firstName || ' ' || celebrity.lastName AS celebrity_name, 
  count(e) AS distance
LIMIT 1000

Liaison de bord de longueur variable :

Dans les modèles de longueur variable, les variables de périphérie capturent différentes informations en fonction du contexte :

-- Edge variable 'e' binds to a single edge for each result row
MATCH (p:Person)-[e:knows]->(friend:Person)
RETURN p.firstName, e.creationDate, friend.firstName  -- e refers to one specific relationship
LIMIT 1000

-- Edge variable 'e' binds to a group list of all edges in the path
MATCH (p:Person)-[e:knows]->{2,4}(friend:Person)  
RETURN 
  p.firstName || ' ' || p.lastName AS person_name, 
  friend.firstName || ' ' || friend.lastName AS friend_name, 
  -- e is a list
  size(e) AS num_edges
LIMIT 1000

Cette distinction est cruciale pour l’utilisation correcte de variables de périphérie.

Modèles complexes avec plusieurs relations :

MATCH (p:Person), (p)-[:workAt]->(c:Company), (p)-[:isLocatedIn]->(city:City)
RETURN p.firstName, p.lastName, c.name AS company_name, city.name AS city_name
LIMIT 1000

Ce modèle recherche les personnes avec leur lieu de travail et leur résidence, montrant comment une personne se connecte à plusieurs autres entités.

Instructions principales

GQL fournit des types d’instructions spécifiques qui fonctionnent ensemble pour traiter vos données de graphe pas à pas. La compréhension de ces instructions est essentielle pour générer des requêtes efficaces.

Instruction MATCH

Syntaxe :

MATCH <graph pattern>, <graph pattern>, ... [ WHERE <predicate> ]

L’instruction MATCH prend des données d’entrée et recherche des modèles de graphique, en joignant des variables d’entrée avec des variables de modèle et en démettant toutes les combinaisons correspondantes.

Variables d’entrée et de sortie :

-- Input: unit table (no columns, one row)
-- Pattern variables: p, c  
-- Output: table with (p, c) columns for each person-company match
MATCH (p:Person)-[:workAt]->(c:Company)

Filtrage au niveau de l’instruction avec WHERE :

-- Filter pattern matches
MATCH (p:Person)-[:workAt]->(c:Company) WHERE p.lastName = c.name

Toutes les correspondances peuvent être post-filtrées à l’aide WHEREd’une instruction distincte FILTER .

Jointure à des variables d’entrée :

Quand MATCH n’est pas la première instruction, elle joint les données d’entrée avec des correspondances de modèle :

...
-- Input: table with 'targetCompany' column
-- Implicit join: targetCompany (equality join)
-- Output: table with (targetCompany, p, r) columns
MATCH (p:Person)-[r:workAt]->(targetCompany)

Important

Graph dans Microsoft Fabric ne prend pas encore en charge la composition d’instructions arbitraires. Consultez l’article sur les limitations actuelles.

Comportements de jointure de clés :

Comment MATCH gère la jonction de données :

  • Égalité des variables : jointure de variables d’entrée avec des variables de modèle à l’aide de la correspondance d’égalité
  • Jointure interne : les lignes d’entrée sans correspondances de modèle sont ignorées (aucune jointure gauche/droite)
  • Ordre de filtrage : filtres au niveau WHERE une fois la correspondance de modèle terminée
  • Connectivité de modèle : plusieurs modèles doivent partager au moins une variable pour une jointure appropriée
  • Performances : les variables partagées créent des contraintes de jointure efficaces

Important

Restriction : Si ce MATCH n’est pas la première instruction, au moins une variable d’entrée doit se joindre à une variable de modèle. Plusieurs modèles doivent avoir une variable en commun.

Plusieurs modèles nécessitent des variables partagées :

-- Shared variable 'p' joins the two patterns
-- Output: people with both workplace and residence data
MATCH (p:Person)-[:workAt]->(c:Company), 
      (p)-[:isLocatedIn]->(city:City)

Instruction LET

Syntaxe :

LET <variable> = <expression>, <variable> = <expression>, ...

L’instruction LET crée des variables calculées et active la transformation des données dans votre pipeline de requête.

Création de variables de base :

MATCH (p:Person)
LET fullName = p.firstName || ' ' || p.lastName
RETURN *
LIMIT 1000

Calculs complexes :

MATCH (p:Person)
LET adjustedAge = 2000 - (p.birthday / 10000),
    fullProfile = p.firstName || ' ' || p.lastName || ' (' || p.gender || ')'
RETURN *
LIMIT 1000

Comportements clés :

  • Les expressions sont évaluées pour chaque ligne d’entrée
  • Les résultats deviennent de nouvelles colonnes dans la table de sortie
  • Les variables peuvent uniquement référencer des variables existantes à partir d’instructions précédentes
  • Plusieurs affectations d’un seul LET sont évaluées en parallèle (aucune référence croisée)

Instruction FILTER

Syntaxe :

FILTER [ WHERE ] <predicate>

L’instruction FILTER fournit un contrôle précis sur les données qui transitent par votre pipeline de requête.

Filtrage de base :

MATCH (p:Person)
FILTER p.birthday < 19980101 AND p.gender = 'female'
RETURN *

Conditions logiques complexes :

MATCH (p:Person)
FILTER (p.gender = 'male' AND p.birthday < 19940101) 
  OR (p.gender = 'female' AND p.birthday < 19990101)
  OR p.browserUsed = 'Edge'
RETURN *

Modèles de filtrage prenant en compte les valeurs Null :

Utilisez ces modèles pour gérer les valeurs Null en toute sécurité :

  • Rechercher les valeurs : p.firstName IS NOT NULL - a un prénom
  • Valider les données : p.id > 0 - ID valide
  • Gérer les données manquantes : - NOT coalesce(p.locationIP, '127.0.0.1') STARTS WITH '127.0.0' n’a pas été connecté à partir du réseau local
  • Combiner des conditions : Utiliser AND/OR avec des vérifications null explicites pour une logique complexe

Caution

N’oubliez pas que les conditions impliquant des valeurs Null retournent UNKNOWN, ce qui filtre ces lignes. Utilisez des vérifications explicites IS NULL lorsque vous avez besoin d’une logique inclusive null.

Instruction ORDER BY

Syntaxe :

ORDER BY <expression> [ ASC | DESC ], <expression> [ ASC | DESC ], ...

Tri à plusieurs niveaux avec des expressions calculées :

MATCH (p:Person)
RETURN *
ORDER BY p.firstName DESC,               -- Primary: by first name (Z-A)
         p.birthday ASC,                 -- Secondary: by age (oldest first)
         p.id DESC                       -- Tertiary: by ID (highest first)

Gestion des valeurs Null dans le tri :

ORDER BY coalesce(p.gender, 'not specified') DESC -- Treat NULL as 'not specified'

Détails du comportement de tri :

ORDER BY Présentation du fonctionnement :

  • Évaluation d’expression : les expressions sont évaluées pour chaque ligne, puis les résultats déterminent l’ordre des lignes
  • Plusieurs clés de tri : Créer un ordre hiérarchique (primaire, secondaire, tertiaire, etc.)
  • Gestion null : NULL est toujours traitée comme la plus petite valeur dans les comparaisons
  • Ordre par défaut : ASC (croissant) est par défaut, DESC (décroissant) doit être spécifié explicitement
  • Tri calculé : vous pouvez trier en fonction des valeurs calculées, et pas seulement des propriétés stockées

Caution

L’ordre de tri établi par ORDER BY n’est visible que par l’instruction immédiatement suivante. Par conséquent, ORDER BY suivi RETURN * de ne produit pas de résultat ordonné.

Comparer:

MATCH (a:Person)-[r:knows]->(b:Person)
LET aName = a.firstName || ' ' || a.lastName
LET bName = b.firstName || ' ' || b.lastName
ORDER BY r.creationDate DESC
/* intermediary result _IS_ guaranteed to be ordered here */
RETURN aName, bName, r.creationDate AS since
/* final result _IS_ _NOT_ guaranteed to be ordered here  */

avec :

MATCH (a:Person)-[r:knows]->(b:Person)
LET aName = a.firstName || ' ' || a.lastName
LET bName = b.firstName || ' ' || b.lastName
/* intermediary result _IS_ _NOT_ guaranteed to be ordered here */
RETURN aName, bName, r.creationDate AS since
ORDER BY r.creationDate DESC
/* final result _IS_ guaranteed to be ordered here              */

Cela a des conséquences immédiates pour les requêtes « Top-k » : LIMIT doit toujours suivre l’instruction ORDER BY qui a établi l’ordre de tri prévu.

Déclarations OFFSET et LIMIT

Syntaxe :

  OFFSET <offset> [ LIMIT <limit> ]
| LIMIT <limit>

Modèles courants :

-- Basic top-N query
MATCH (p:Person)
RETURN *
ORDER BY p.id DESC
LIMIT 10                                 -- Top 10 by ID

Important

Pour les résultats de pagination prévisibles, utilisez ORDER BY toujours avant OFFSET et LIMIT pour garantir l’ordre cohérent des lignes entre les requêtes.

RETURN: projection de résultats de base

Syntaxe :

RETURN [ DISTINCT ] <expression> [ AS <alias> ], <expression> [ AS <alias> ], ...
[ ORDER BY <expression> [ ASC | DESC ], <expression> [ ASC | DESC ], ... ]
[ OFFSET <offset> ]
[ LIMIT <limit> ]

L’instruction RETURN produit la sortie finale de votre requête en spécifiant les données qui apparaissent dans la table de résultats.

Sortie de base :

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName || ' ' || p.lastName AS name, 
       p.birthday, 
       c.name

Utilisation d’alias pour plus de clarté :

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName AS first_name, 
       p.lastName AS last_name,
       c.name AS company_name

Combiner avec le tri et le top-k :

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName || ' ' || p.lastName AS name, 
       p.birthday AS birth_year, 
       c.name AS company
ORDER BY birth_year ASC
LIMIT 10

Gestion dupliquée avec DISTINCT :

-- Remove duplicate combinations
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN DISTINCT p.gender, p.browserUsed, p.birthday AS birth_year
ORDER BY p.gender, p.browserUsed, birth_year

Combiner avec l’agrégation :

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN count(DISTINCT p) AS employee_count

RETURN avec GROUP BY: projection de résultat groupée

Syntaxe :

RETURN [ DISTINCT ] <expression> [ AS <alias> ], <expression> [ AS <alias> ], ...
GROUP BY <variable>, <variable>, ...
[ ORDER BY <expression> [ ASC | DESC ], <expression> [ ASC | DESC ], ... ]
[ OFFSET <offset> ]
[ LIMIT <limit> ]

Permet GROUP BY de regrouper des lignes par valeurs partagées et de calculer des fonctions d’agrégation au sein de chaque groupe.

Regroupement de base avec agrégation :

MATCH (p:Person)-[:workAt]->(c:Company)
LET companyName = c.name
RETURN companyName, 
       count(*) AS employeeCount,
       avg(p.birthday) AS avg_birth_year
GROUP BY companyName
ORDER BY employeeCount DESC

Regroupement à plusieurs colonnes :

MATCH (p:Person)
LET gender = p.gender
LET browser = p.browserUsed
RETURN gender,
       browser,
       count(*) AS person_count,
       avg(p.birthday) AS avg_birth_year,
       min(p.creationDate) AS first_joined,
       max(p.id) AS highest_id
GROUP BY gender, browser
ORDER BY avg_birth_year DESC
LIMIT 10

Note

Pour connaître les techniques d’agrégation avancées, notamment l’agrégation horizontale sur des modèles de longueur variable, consultez Techniques d’agrégation avancées.

Types de données : utilisation de valeurs

GQL prend en charge les types de données enrichis pour stocker et manipuler différents types d’informations dans votre graphique.

Types de valeurs de base :

  • Nombres : INT64, UINT64DOUBLEpour les calculs et les mesures
  • Texte : STRING pour les noms, les descriptions et les données textuelles
  • Logique : BOOL avec trois valeurs : TRUE, FALSE et UNKNOWN (pour la gestion null)
  • Heure : ZONED DATETIME pour les horodatages avec des informations de fuseau horaire
  • Collections : LIST<T> pour plusieurs valeurs du même type T, PATH pour les résultats de parcours de graphes
  • Éléments de graphe : NODE et EDGE pour référencer des données de graphe

Important

Certains types de valeurs ne sont pas pris en compte comme types de valeurs immobilières. En particulier, toutes les valeurs impliquant des valeurs de référence d’éléments de graphe ne peuvent pas être utilisées comme valeurs de propriété (telles que des listes de nœuds ou de chemins).

Exemples de littéraux :

42                                     -- Integer literal
"Hello, graph!"                        -- String  literal
TRUE                                   -- Boolean literal
ZONED_DATETIME('2024-01-15T10:30:00Z') -- DateTime with timezone literakl
[1, 2, 3]                              -- Literal list of integers

Modèles de gestion null critiques :

-- Equality predicates with NULL always returns UNKNOWN
5 = NULL                              -- Evaluates to UNKNOWN (not FALSE!)
NULL = NULL                           -- Evaluates to UNKNOWN (not TRUE!)

-- Use IS NULL predicates for explicit null testing
p.nickname IS NULL                    -- Evaluates to TRUE if nickname is null
p.nickname IS NOT NULL                -- Evaluates to TRUE if nickname has a value

-- Use the COALESCE function for null-safe value selection
coalesce(p.nickname, p.firstName, '???')  -- Evaluates to first non-null value

Implications logiques à trois valeurs :

-- In FILTER statements, only TRUE values pass through
FILTER p.birthday > 0        -- Removes rows where birthday is null or missing or zero

-- It's important to understand that NOT UNKNOWN = UNKNOWN
FILTER NOT (p.birthday > 0)  -- Removes rows where birthday is null or missing or positive

-- Use explicit null handling for inclusive filtering
FILTER p.birthday < 19980101 OR p.birthday IS NULL -- Includes null birthdays

Caution

La logique à trois valeurs signifie NULL = NULL que retourne UNKNOWN, et non TRUE. Ce comportement affecte le filtrage et les jointures. Toujours utiliser IS NULL pour les tests Null.

Expressions : transformation et analyse des données

Les expressions vous permettent de calculer, comparer et transformer des données dans vos requêtes. Ils sont similaires aux expressions dans SQL, mais ont des fonctionnalités supplémentaires pour la gestion des données de graphe.

Types d’expressions courants :

p.birthday < 19980101   -- Birth year comparison  
p.firstName || ' ' || p.lastName               -- String concatenation
count(*)                                       -- Aggregation
p.firstName IN ['Alice', 'Bob']                -- List membership
coalesce(p.firstName, p.lastName)              -- Null handling

Composition de prédicat complexe :

-- Combine conditions with proper precedence
FILTER (p.birthday > 19560101 AND p.birthday < 20061231) 
  AND ((p.gender IN ['male', 'female']) OR (p.browserUsed IS NOT NULL))

-- Use parentheses for clarity and correctness
FILTER p.gender = 'female' AND (p.firstName STARTS WITH 'A' OR p.id > 1000)

Correspondance de modèle de chaîne :

-- Pattern matching with different operators
p.locationIP CONTAINS '192.168'      -- Substring search
p.firstName STARTS WITH 'John'       -- Prefix matching  
p.lastName ENDS WITH 'son'           -- Suffix matching

-- Case-insensitive operations
upper(p.firstName) = 'ALICE'         -- Convert to uppercase for comparison

Fonctions intégrées par catégorie :

GQL fournit ces catégories de fonctions pour différents besoins de traitement des données :

  • Fonctions d’agrégation : count(), , sum()avg(), min()pour max() résumer les données
  • Fonctions de chaîne : char_length(), upper(), lower(), trim() pour le traitement du texte
  • Fonctions de graphe : nodes(), edges()pour labels() l’analyse des structures de graphe
  • Fonctions générales : coalesce() pour gérer correctement les valeurs Null

Priorité des opérateurs pour les expressions complexes :

  1. Accès aux propriétés (.)
  2. Multiplication/Division (*, /)
  3. Addition/Soustraction (+, -)
  4. Comparaison (=, , <>, <>, <=, >=)
  5. Négation logique ( NOT )
  6. Combinaison logique (AND)
  7. Disjonction logique (OR)

Dans la liste ci-dessus, un opérateur avec un nombre plus bas « se lie plus fort » qu’un opérateur avec un nombre plus élevé. Exemple : NOT n.prop OR m.prop est (NOT n.prop) OR m.prop mais pas 'NOT (n.prop OU m.prop)

Conseil / Astuce

Utilisez des parenthèses pour rendre la priorité explicite. Les expressions complexes sont plus faciles à lire et à déboguer lorsque le regroupement est clair.

Techniques avancées de requête

Cette section traite des modèles et techniques sophistiqués pour la création de requêtes graphiques complexes et efficaces. Ces modèles vont au-delà de l’utilisation des instructions de base pour vous aider à composer de puissantes requêtes analytiques.

Composition multi-instructions complexe

Important

Graph dans Microsoft Fabric ne prend pas encore en charge la composition d’instructions arbitraires. Consultez l’article sur les limitations actuelles.

Comprendre comment composer efficacement des requêtes complexes est essentiel pour l’interrogation de graphiques avancées.

Progression de modèle à plusieurs étapes :

-- Build complex analysis step by step
MATCH (company:Company)<-[:workAt]-(employee:Person)
LET companyName = company.name
MATCH (employee)-[:isLocatedIn]->(city:City)
FILTER employee.birthday < 19850101
LET cityName = city.name
RETURN companyName, cityName, avg(employee.birthday) AS avgBirthday, count(employee) AS employeeCount
GROUP BY companyName, cityName
ORDER BY avgBirthday DESC

Cette requête crée progressivement de complexité : trouver les entreprises, leurs employés, les emplacements des employés, filtrer les entreprises avec des employés nés avant 1985, calculer la date de naissance moyenne, et résumer et trier les résultats.

Utilisation de l’agrégation horizontale :

-- Find people and their minimum distance to people working at Microsoft
MATCH TRAIL (p:Person)-[e:knows]->{,5}(:Person)-[:workAt]->(:Company { name: 'Microsoft'})
LET p_name = p.lastName || ', ' || p.firstName
RETURN p_name, min(count(e)) AS minDistance 
GROUP BY p_name
ORDER BY minDistance DESC

Note

Cette requête n’est pas encore prise en charge (problème connu).

Étendue variable et contrôle de flux avancé

Les variables connectent les données entre les instructions de requête et activent des traversées de graphique complexes. La compréhension des règles d’étendue avancée vous permet d’écrire des requêtes multi-instructions sophistiquées.

Modèles de liaison et d’étendue de variables :

-- Variables flow forward through subsequent statements 
MATCH (p:Person)                                    -- Bind p 
LET fullName = p.firstName || ' ' || p.lastName     -- Bind concatenation of p.firstName and p.lastName as fullNume
FILTER fullName CONTAINS 'Smith'                    -- Filter for fullNames with “Smith” substring (p is still bound)
RETURN p.id, fullName                               -- Only return p.id and fullName (p is dropped from scope) 

Réutilisation des variables pour les jointures entre les instructions :

-- Multi-statement joins using variable reuse
MATCH (p:Person)-[:workAt]->(:Company)          -- Find people with jobs
MATCH (p)-[:isLocatedIn]->(:City)               -- Same p: people with both job and residence
MATCH (p)-[:knows]->(friend:Person)             -- Same p: their social connections
RETURN *

Règles et limitations d’étendue critiques :

-- ✅ Backward references work
MATCH (p:Person)
LET adult = p.birthday < 20061231  -- Can reference p from previous statement
RETURN *

-- ❌ Forward references don't work  
LET adult = p.birthday < 20061231  -- Error: p not yet defined
MATCH (p:Person)
RETURN *

-- ❌ Variables in same LET statement can't reference each other
MATCH (p:Person)
LET name = p.firstName || ' ' || p.lastName,
    greeting = 'Hello, ' || name     -- Error: name not visible yet
RETURN *

-- ✅ Use separate statements for dependent variables
MATCH (p:Person)
LET name = p.firstName || ' ' || p.lastName
LET greeting = 'Hello, ' || name     -- Works: name now available
RETURN *

Visibilité des variables dans les requêtes complexes :

-- Variables remain visible until overridden or query ends
MATCH (p:Person)                     -- p available from here
LET gender = p.gender                -- gender available from here  
MATCH (p)-[:knows]->(e:Person)       -- p still refers to original person
                                     -- e is new variable for managed employee
RETURN p.firstName AS manager, e.firstName AS friend, gender

Caution

Les variables de la même instruction ne peuvent pas se référencer les unes les autres (sauf dans les modèles de graphique). Utilisez des instructions distinctes pour la création de variables dépendantes.

Techniques d’agrégation avancées

GQL prend en charge deux types distincts d’agrégation pour l’analyse des données entre des groupes et des collections : l’agrégation verticale avec GROUP BY et l’agrégation horizontale sur des modèles de longueur variable.

Agrégation verticale avec GROUP BY

L’agrégation verticale (couverte avecRETURNGROUP BY) regroupe les lignes par valeurs partagées et calcule les agrégats au sein de chaque groupe :

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN c.name AS companyName, 
       count(*) AS employee_count, 
       avg(p.birthday) AS avg_birth_year
GROUP BY companyName

Cette approche crée une ligne de résultat par entreprise, en agrégeant tous les employés au sein de chaque groupe.

Agrégation horizontale avec des variables de liste de groupes

L’agrégation horizontale calcule les agrégats sur les collections liées par des modèles de longueur variable. Lorsque vous utilisez des arêtes de longueur variable, la variable de périmètre devient une variable de liste de groupes qui contient tous les bords dans chaque chemin correspondant :

-- Group list variable 'edges' enables horizontal aggregation
MATCH (p:Person)-[edges:knows]->{2,4}(friend:Person)
RETURN p.firstName || ' ' || p.lastName AS person_name, 
       friend.firstName || ' ' || friend.lastName AS friend_name,
       size(edges) AS degrees_of_separation,
       avg(edges.creationDate) AS avg_connection_age,
       min(edges.creationDate) AS oldest_connection

Note

Cette requête n’est pas encore prise en charge (problème connu).

Principales différences :

  • L’agrégation verticale récapitule les lignes - ou - regroupe les lignes et résume les lignes de chaque groupe
  • L’agrégation horizontale récapitule les éléments au sein de collections de périphérie individuelles
  • Les variables de liste de groupes proviennent uniquement de modèles de bord de longueur variable

Contextes de liaison de périphérie de longueur variable

Comprendre comment les variables de périphérie se lient dans les modèles de longueur variable est cruciale :

Pendant la correspondance de modèle (contexte singleton) :

-- Edge variable 'e' refers to each individual edge during filtering
MATCH (p:Person)-[e:knows WHERE e.creationDate > zoned_datetime('2000-01-01T00:00:00Z')]->{2,4}(friend:Person)
-- 'e' is evaluated for each edge in the path during matching
RETURN *

Dans les expressions de résultat (contexte de groupe) :

-- Edge variable 'edges' becomes a list of all qualifying edges
MATCH (p:Person)-[e:knows]->{2,4}(friend:Person)
RETURN size(e) AS num_edges,                    -- Number of edges in path
       e[0].creationDate AS first_edge,         -- First edge in path
       avg(e.creationDate) AS avg_age           -- Horizontal aggregation

Note

Cette requête n’est pas encore prise en charge (problème connu).

Combinaison d’agrégation verticale et horizontale

Vous pouvez combiner les deux types d’agrégation dans des modèles d’analyse sophistiqués :

-- Find average connection age by city pairs
MATCH (p1:Person)-[:isLocatedIn]->(c1:City)
MATCH (p2:Person)-[:isLocatedIn]->(c2:City)
MATCH (p1)-[e:knows]->{1,3}(p2)
RETURN c1.name AS city1,
       c2.name AS city2,
       count(*) AS connection_paths,                  -- Vertical: count paths per city pair
       avg(size(e)) AS avg_degrees,                   -- Horizontal then vertical: path lengths
       avg(avg(e.creationDate)) AS avg_connection_age -- Horizontal then vertical: connection ages
GROUP BY city1, city2

Note

Cette requête n’est pas encore prise en charge (problème connu).

Conseil / Astuce

L’agrégation horizontale est toujours prioritaire sur l’agrégation verticale. Pour convertir une liste de groupes en liste régulière, utilisez collect_list(edges).

Note

Pour obtenir une référence détaillée des fonctions d’agrégation, consultez les expressions et fonctions GQL.

Stratégies de gestion des erreurs

Comprendre les modèles d’erreur courants vous aide à écrire des requêtes robustes.

Gérez correctement les données manquantes :

MATCH (p:Person)
-- Use COALESCE for missing properties
LET displayName = coalesce(p.firstName, p.lastName, 'Unknown')
LET contact = coalesce(p.locationIP, p.browserUsed, 'No info')
RETURN *

Utilisez des vérifications null explicites :

MATCH (p:Person)
-- Be explicit about null handling
FILTER p.id IS NOT NULL AND p.id > 0
-- Instead of just: FILTER p.id > 0
RETURN *

Informations supplémentaires

Codes GQLSTATUS

Comme expliqué dans la section sur les résultats de la requête, GQL signale des informations d’état enrichies liées à la réussite ou à l’échec potentiel de l’exécution. Consultez la référence des codes d’état GQL pour obtenir la liste complète.

Mots réservés

GQL réserve certains mots clés que vous ne pouvez pas utiliser comme identificateurs tels que des variables, des noms de propriétés ou des noms d’étiquettes. Consultez la référence des mots réservés GQL pour la liste complète.

Si vous devez utiliser des mots réservés en tant qu’identificateurs, placez-les en échappement avec des backticks : `match`, `return`.

Pour éviter d’échapper aux mots réservés, utilisez cette convention d’affectation de noms :

  • Pour les identificateurs à mot unique, ajoutez un trait de soulignement : :Product_
  • Pour les identificateurs à plusieurs mots, utilisez camelCase ou PascalCase : :MyEntity, :hasAttribute, textColor

Étapes suivantes

Maintenant que vous comprenez les principes fondamentaux de GQL, voici votre parcours d’apprentissage recommandé :

Continuer à développer vos compétences GQL

Pour les débutants :

Pour les utilisateurs expérimentés :

Documents de référence

Gardez ces références pratiques pour les recherches rapides :

Explorer Microsoft Fabric

Découvrez la plateforme :

Être impliqué

  • Partager des commentaires - Aidez-vous à améliorer notre documentation et nos outils
  • Rejoindre la communauté - Se connecter à d’autres praticiens de base de données graphes
  • Restez à jour - Suivez les annonces de Microsoft Fabric pour les nouvelles fonctionnalités

Conseil / Astuce

Commencez par le didacticiel de démarrage rapide si vous préférez apprendre en effectuant ou en plongeant dans les modèles de graphique si vous souhaitez maîtriser le langage de requête en premier.

Plus d’informations sur les rubriques clés :

Références rapides :

Graph dans Microsoft Fabric :