Partage via

Modèles de graphique 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.

Les modèles graphiques sont des blocs de construction principaux de vos requêtes GQL. Ils décrivent les structures que vous recherchez dans le graphe à l’aide de nœuds et de bords d’une manière intuitive et visuelle. Considérez les modèles de graphique en tant que modèles que le moteur de requête tente de faire correspondre aux données réelles de votre graphique.

Important

Cet article utilise exclusivement l’exemple de jeu de données de graphe de réseau social.

Modèles d’éléments simples

Les modèles d’éléments simples vous aident à faire correspondre des nœuds et des arêtes individuels de votre graphique qui répondent à des exigences spécifiques. Ces modèles constituent la base de la mise en correspondance de modèles plus complexes.

Modèles de nœud simples

Un modèle de nœud spécifie les étiquettes et les propriétés qu’un nœud doit avoir à faire correspondre :

(:City { name: "New York" })

Ce modèle correspond à tous les nœuds qui ont à la fois les étiquettes et les PlaceCity étiquettes (indiquées par l’opérateur) et dont & la name propriété est "New York"égale. Cette spécification des étiquettes et des propriétés requises est appelée remplissage du modèle de nœud.

Concepts clés :

  • Correspondance des étiquettes : utilisez-la & pour exiger plusieurs étiquettes.
  • Filtrage des propriétés : spécifiez des valeurs exactes que les propriétés doivent correspondre.
  • Correspondance flexible (« covariante ») : les nœuds mis en correspondance peuvent avoir plus d’étiquettes et de propriétés au-delà des étiquettes spécifiées.

Note

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

Modèles de bord simples

Les modèles de périphérie sont plus complexes que les modèles de nœud. Ils spécifient non seulement un remplissage, mais connectent également un modèle de nœud source à un modèle de nœud de destination. Les modèles de périphérie décrivent les exigences à la fois sur le bord et ses points de terminaison :

(:Person)-[:likes|knows { creationDate: ZONED_DATETIME("2010-08-31T13:16:54Z") }]->(:Comment)

La direction -[...]-> de la flèche est importante : elle détermine (:Person) comme modèle de nœud source et (:Comment) comme modèle de nœud de destination. Comprendre le sens de la périphérie est essentiel pour interroger correctement votre graphe.

Modèle en miroir équivalent :

Vous pouvez retourner la flèche et permuter les modèles de nœud pour créer le modèle de bord en miroir équivalent :

(:Comment)<-[:likes { creationDate: ZONED_DATETIME("2010-08-31T13:16:54Z") }]-(:Person)

Ce modèle trouve les mêmes relations, mais du point de vue opposé.

Modèles de bord dirigés vers n’importe quelle

Lorsque la direction d’un bord de graphe n’a pas d’importance pour votre requête, vous pouvez la laisser non spécifiée en créant un modèle de bord dirigé vers n’importe quel :

(:Song)-[:inspired]-(:Movie)

Ce modèle correspond aux mêmes arêtes que (:Song)-[:inspired]->(:Movie) et (:Movie)-[:inspired]->(:Song) combinées, quel que soit le nœud source et la destination (cet exemple ne provient pas du type de graphique de réseau social).

Raccourcis du modèle de bord du graphique

GQL fournit des raccourcis pratiques pour les modèles de périphérie courants pour rendre vos requêtes plus concises :

  • ()->() ()-[]->() représente (bord dirigé avec n’importe quelle étiquette)
  • ()<-() ()<-[]-() représente (bord dirigé dans l’inverse avec n’importe quelle étiquette)
  • ()-() ()-[]-() signifie (arête dirigée avec n’importe quelle étiquette)

Ces raccourcis peuvent être utiles lorsque vous vous intéressez à la connectivité, mais pas au type de bord de graphique spécifique.

Expressions d’étiquette

Les modèles peuvent exprimer des exigences complexes sur les étiquettes des nœuds et des arêtes correspondants.

Exemple :

MATCH (:Person|(Organization&!Company))-[:isLocatedIn]->(p:City|Country)
RETURN count(*) AS num_matches

Cela compte le nombre de isLocatedIn périphéries qui connectent Person des nœuds ou des nœuds (mais Organizationpas)Company (qui sont toujours University des nœuds dans le schéma de réseau social) ou des CityCountry nœuds.

Syntaxe :

Syntaxe Meaning
A&B Les étiquettes doivent inclure à la fois A et B.
A|B Les étiquettes doivent inclure au moins l’une des étiquettes A ou B.
!A Les étiquettes doivent exclure A.

En outre, utilisez des parenthèses pour contrôler l’ordre de l’évaluation d’expression d’étiquette. Par défaut, ! a la priorité la plus élevée et & a une priorité supérieure à |. Par conséquent !A&B|C|!D , il est identique à ((!A)&B)|C|(!D).

Variables de liaison

Les variables vous permettent de faire référence à des éléments de graphique mis en correspondance dans d’autres parties de votre requête. Comprendre comment lier et utiliser des variables est essentielle pour créer des requêtes puissantes.

Variables d’élément de liaison

Les modèles de nœud et de périphérie peuvent lier des nœuds et des arêtes mis en correspondance à des variables pour référence ultérieure.

(p:Person)-[w:workAt]->(c:Company)

Dans ce modèle, p est lié aux nœuds correspondants Person , w aux arêtes correspondantes workAt et c aux nœuds correspondants Company .

Réutilisation des variables pour les contraintes structurelles :

La réutilisation de la même variable dans un modèle plusieurs fois exprime une restriction sur la structure des correspondances. Chaque occurrence de la même variable doit toujours être liée au même élément de graphe dans une correspondance valide. La réutilisation des variables est puissante pour exprimer des exigences structurelles complexes.

(c:Company)<-[:workAt]-(x:Person)-[:knows]-(y:Person)-[:workAt]->(c:Company)

Le modèle recherche des Person nœuds x et y qui se connaissent et fonctionnent au même Companyniveau, qui est lié à la variable c. La réutilisation garantit c que les deux personnes travaillent dans la même entreprise.

Prédicats de modèle avec des variables d’élément :

Les variables d’élément de liaison vous permettent de spécifier des prédicats de modèle de nœud et de périphérie. Au lieu de fournir simplement un remplissage avec des valeurs de propriété exactes telles que { name: "New York, USA" }, un remplissage peut spécifier un prédicat qui est évalué pour chaque élément candidat. Le modèle correspond uniquement si le prédicat est évalué à TRUE:

(p:Person)-[e:knows WHERE e.creationDate >= ZONED_DATETIME("2000-01-01T18:00:00Z")]-(o:Person)

Le modèle de périphérie trouve les personnes qui se connaissaient depuis le 1er janvier 2000, à l’aide d’une condition flexible plutôt que d’une correspondance exacte.

Note

Les variables de modèle edge se lient toujours au bord individuel dans le prédicat de modèle de bord, même en cas d’utilisation de modèles de longueur variable. Cela peut vous aider à ne pas avoir à supprimer les variables de liste de groupes de périphérie pour effectuer un post-filtre. Consultez Lier des variables de périphérie de modèle de longueur variable.

Techniques avancées de prédicat de modèle :

Les prédicats de modèle fournissent des fonctionnalités de filtrage inline puissantes qui peuvent améliorer la lisibilité des requêtes :

-- Multiple conditions in node predicates
MATCH (p:Person WHERE p.age > 30 AND p.department = 'Engineering')
      -[:workAt]->
      (c:Company WHERE c.revenue > 1000000 AND c.location = 'Seattle')

-- Complex edge predicates with calculations
MATCH (p1:Person)-[w:workAt WHERE w.start_date < ZONED_DATETIME('2020-01-01T00:00:00Z') 
                              AND w.salary > 75000]-(c:Company)

-- MATCH WHERE: evaluated after pattern matching
MATCH (p:Person)-[:workAt]->(c:Company)
WHERE p.active = TRUE AND c.public = TRUE

-- Filter during matching and after
MATCH (p:Person WHERE p.department = 'Sales')-[:workAt]->(c:Company)
WHERE p.quota_achievement > 1.2 AND c.revenue > c.revenue_target

Conseil / Astuce

L’utilisation de prédicats de modèle lorsque les conditions sont hautement sélectives peut réduire la taille des résultats intermédiaires.

Variables de chemin d’accès de liaison

Vous pouvez également lier un chemin d’accès correspondant à une variable de chemin d’accès pour un traitement ultérieur ou retourner la structure de chemin d’accès complète à l’utilisateur :

p=(c:Company)<-[:workAt]-(x:Person)-[:knows]-(y:Person)-[:workAt]->(c:Company)

Ici, p est lié à une valeur de chemin représentant la structure complète du chemin d’accès correspondant, y compris les valeurs de référence pour tous les nœuds et arêtes dans l’ordre donné.

Les chemins liés peuvent soit être retournés à l’utilisateur, soit traités davantage à l’aide de fonctions telles que NODES ou EDGES:

MATCH p=(c:Company)<-[:workAt]-(x:Person)-[:knows]-(y:Person)-[:workAt]->(c:Company)
LET path_edges = edges(p)
RETURN path_edges, size(path_edges) AS num_edges
GROUP BY path_edges

Composer des modèles

Les requêtes réelles nécessitent souvent des modèles plus complexes que des structures de nœud-edge simples. GQL fournit plusieurs façons de composer des modèles pour les traversées de graphiques sophistiquées.

Composer des modèles de chemin d’accès

Les modèles de chemin d’accès peuvent être composés en concaténant des modèles de nœud et de bord simples pour créer des traversées plus longues.

(:Person)-[:knows]->(:Person)-[:workAt]->(:Company)-[:isLocatedIn]->(:Country)-[:isPartOf]->(:Continent)

Le modèle traverse une personne par le biais de ses liens sociaux et professionnels pour trouver où se trouve la société de son collègue.

Construction de modèle dans le sens des pièces : Vous pouvez également créer des modèles de chemin d’accès plus incrémentiels, ce qui permet de faciliter la lecture et la compréhension des modèles complexes :

(:Person)-[:knows]->(p:Person),
(p:Person)-[:workAt]->(c:Company),
(c:Company)-[:isLocatedIn]->(:Country)-[:isPartOf]->(:Continent)

Cette approche décompose la même traversée en étapes logiques, ce qui facilite la compréhension et le débogage.

Composer des modèles non linéaires

La forme résultante d’un motif n’a pas besoin d’être un chemin linéaire. Vous pouvez correspondre à des structures plus complexes telles que des modèles en forme d’étoile qui rayonnent à partir d’un nœud central :

(p:Person),
(p)-[:studyAt]->(u:University),
(p)-[:workAt]->(c:Company),
(p)-[:likes]-(m)

Le modèle recherche une personne ainsi que ses préférences d’éducation, d’emploi et de contenu en même temps , une requête de profil complète.

Correspondances avec les sentiers

Dans des modèles complexes, il est souvent indésirable de traverser le même bord plusieurs fois. La réutilisation des arêtes devient importante lorsque le graphe réel contient des cycles qui peuvent entraîner des chemins infinis ou trop longs. Pour gérer la réutilisation des arêtes, graph dans Microsoft Fabric prend en charge le TRAIL mode correspondance.

Le préfixe d’un modèle de chemin avec le mot clé TRAIL ignore toutes les correspondances qui lient le même bord plusieurs fois :

TRAIL (a)-[e1:knows]->(b)-[e2:knows]->(c)-[e3:knows]->(d)

En utilisant TRAIL, le modèle produit uniquement des correspondances dans lesquelles tous les bords sont différents. Par conséquent, même si c = a le chemin forme un cycle dans une correspondance donnée, e3 ne se lie jamais au même bord que e1.

Le TRAIL mode est essentiel pour empêcher les boucles infinies et s’assurer que vos requêtes retournent des chemins significatifs et nonredundants.

Utiliser des modèles de longueur variable

Les modèles de longueur variable sont des constructions puissantes qui vous permettent de trouver des chemins d’accès de longueurs variables sans écrire de spécifications de modèle répétitives. Ils sont essentiels pour parcourir les hiérarchies, les réseaux sociaux et d’autres structures où la longueur optimale du chemin n’est pas connue à l’avance.

Modèles de longueur variable délimités

Important

Les modèles de longueur variable limitée ne prennent actuellement en charge qu’une limite supérieure maximale de 8. Consultez l’article sur les limitations actuelles.

De nombreuses requêtes de graphe courantes nécessitent la répétition du même modèle de bord plusieurs fois. Au lieu d’écrire des modèles détaillés comme :

(:Person)-[:knows]->(:Person)-[:knows]->(:Person)-[:knows]->(:Person)

Vous pouvez utiliser la syntaxe de longueur variable plus concise :

(:Person)-[:knows]->{3}(:Person)

Spécifie {3} que le -[:knows]-> modèle de bord doit être répété exactement trois fois.

Plages de répétition flexibles : Pour plus de flexibilité, vous pouvez spécifier une limite inférieure et une limite supérieure pour la répétition :

(:Person)-[:knows]->{1, 3}(:Person)

Ce modèle trouve des amis directs, des amis des amis et des amis-de-amis-de-amis dans une seule requête.

Note

La limite inférieure peut également être 0. Dans ce cas, aucun bord n’est mis en correspondance et le modèle entier correspond uniquement si et seulement si les deux modèles de nœud de point de terminaison correspondent au même nœud.

Exemple :

(p1:Person)-[r:knows WHERE NOT p1=p2]->{0,1}(p2:Person)

Ce schéma correspond à des paires de personnes différentes qui se connaissent mais correspond aussi à la même personne en p1 tant que personne – p2 même si cette personne ne « se connaît » pas.

Lorsqu’aucune limite inférieure n’est spécifiée, elle est généralement égale à 0 (zéro).

Compositions complexes à longueur variable : Les motifs de longueur variable peuvent faire partie de motifs plus grands et plus complexes, comme dans la requête suivante :

MATCH (c1:Comment)<-[:likes]-(p1:Person)-[:knows]-(p2:Person)-[:likes]->(c2:Comment),
      (c1:Comment)<-[:replyOf]-{1,3}(m)-[:replyOf]->{1,3}(c2:Comment)
RETURN *
LIMIT 100

Le modèle recherche des paires de commentaires où les personnes qui se connaissent les uns les autres ont aimé des commentaires différents, et ces commentaires sont connectés par le biais de chaînes de réponse de 1 à 5 niveaux chacun.

Lier des variables de périphérie de modèle de longueur variable

Lorsque vous liez un modèle de bord de longueur variable, la valeur et le type de la variable de périphérie changent en fonction du contexte de référence. Comprendre ce comportement est essentiel pour traiter correctement les correspondances de longueur variable :

Deux degrés de référence :

  • À l’intérieur d’un modèle de longueur variable : les variables de bord de graphe se lient à chaque bord individuel le long du chemin correspondant (également appelé « degré singleton de référence »)
  • En dehors d’un modèle de longueur variable : les variables de bord du graphe sont liées à la séquence de tous les bords le long du chemin correspondant (également appelé « degré de référence de groupe »)

Exemple illustrant les deux contextes :

MATCH (:Person)-[e:knows WHERE e.creationDate >= ZONED_DATETIME("2000-01-01T00:00:00Z")]->{1,3}()
RETURN e[0]
LIMIT 100

L’évaluation de la variable e de périphérie se produit dans deux contextes :

  • Dans l’énoncéMATCH : La requête trouve des chaînes d’amis-d’amis-d’amis où chaque amitié a été établie depuis l’année 2000. Pendant la correspondance de modèle, le prédicat e.creationDate >= ZONED_DATETIME("2000-01-01T00:00:00Z") de modèle de bord est évalué une fois pour chaque arête candidate. Dans ce contexte, e est lié à une valeur de référence de périphérie unique.

  • Dans l’instruction RETURN: Ici, e est liée à une liste (groupe) de valeurs de référence de périphérie dans l’ordre dans lequel elles se produisent dans la chaîne correspondante. Le résultat est la première valeur de e[0] référence de périphérie dans chaque chaîne correspondante.

Variables de contours à longueur variable en agrégation horizontale :

Les variables d’arête liées par l’appariement de motifs de longueur variable sont des listes de groupes en dehors du motif à longueur variable et peuvent donc être utilisées en agrégation horizontale.

MATCH (a:Person)-[e:knows WHERE e.creationDate >= ZONED_DATETIME("2000-01-01T00:00:00Z")]->{1,3}(b)
RETURN a, b, size(e) AS num_edges
LIMIT 100

Voir la section sur l’agrégation horizontale pour plus de détails.

Contenu connexe

  • Last updated on