Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
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,FILTERetRETURNpour 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
Personouknows. 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"oubirthday: "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.
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 :
-
MATCHrecherche tous les nœuds étiquetésPerson -
RETURNaffiche 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 :
-
MATCHtrouve tous les nœuds (p) étiquetés Person -
FILTERnœuds (p) dont le prénom est Alice -
RETURNMontre 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 :
-
MATCHrecherche toutes les paires dePersonnœuds qui se connaissent les uns les autres -
FILTERgarde uniquement les paires où les deux personnes ont le même anniversaire -
RETURNcompte 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. -
OFFSETetLIMIT: 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 :
-
MATCHtrouve des personnes travaillant dans des entreprises avec « Air » dans leur nom -
LETcrée des noms complets en combinant prénoms et noms de famille -
FILTERne garde que des employés Contoso -
ORDER BYtris par nom complet -
LIMITPrend les 10 premiers résultats -
RETURNNoms 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 :
- Variables de modèle - liées par des modèles de graphique correspondants
- Variables régulières - liées par d’autres constructions de langage
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
RETURNinstruction. - 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
WHEREune 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
LETsont é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/ORavec 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 :
NULLest 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 :
STRINGpour les noms, les descriptions et les données textuelles -
Logique :
BOOLavec trois valeurs : TRUE, FALSE et UNKNOWN (pour la gestion null) -
Heure :
ZONED DATETIMEpour les horodatages avec des informations de fuseau horaire -
Collections :
LIST<T>pour plusieurs valeurs du même typeT,PATHpour les résultats de parcours de graphes -
Éléments de graphe :
NODEetEDGEpour 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()pourmax()résumer les données -
Fonctions de chaîne :
char_length(),upper(),lower(),trim()pour le traitement du texte -
Fonctions de graphe :
nodes(),edges()pourlabels()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 :
- Accès aux propriétés (
.) - Multiplication/Division (
*,/) - Addition/Soustraction (
+,-) - Comparaison (
=, ,<>,<>,<=,>=) - Négation logique (
NOT) - Combinaison logique (
AND) - 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 :
- Essayez le guide de démarrage rapide - Suivez notre didacticiel pratique pour une expérience pratique
- Pratiquez des requêtes de base - Essayez les exemples de ce guide avec vos propres données
- Découvrir les modèles de graphe - Maîtriser la syntaxe complète des modèles
- Explorer les types de données - Comprendre les valeurs et les types de valeurs GQL
Pour les utilisateurs expérimentés :
- Expressions avancées - Principales expressions et fonctions GQL
- Conception de schéma - Découvrir les types et contraintes de graphique GQL
- Explorer les types de données - Comprendre les valeurs et les types de valeurs GQL
Documents de référence
Gardez ces références pratiques pour les recherches rapides :
- Référence rapide GQL - Référence rapide de syntaxe
- Codes d’état GQL - Référence complète du code d’erreur
- Mots réservés GQL - Liste complète des mots clés réservés
Explorer Microsoft Fabric
Découvrez la plateforme :
- Modèles de données de graphe - Présentation des concepts et de la modélisation des graphiques
- Bases de données graphes et relationnelles - Choisir l’approche appropriée
- Essayez Gratuitement Microsoft Fabric - Bénéficier d’une expérience pratique
- Tutoriels de bout en bout - Scénarios d’apprentissage complets
Ê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.
Contenu connexe
Plus d’informations sur les rubriques clés :
- Exemple de schéma de réseau social - Exemple complet de schéma de graphe
- Modèles de graphique GQL - Syntaxe complète des modèles et techniques de correspondance avancées
- Expressions et fonctions GQL - Tous les types d’expressions et fonctions intégrées
- Types de graphiques GQL - Types de graphiques et contraintes de graphique
- Valeurs et types valeur GQL - Référence système de type complète et gestion des valeurs
Références rapides :
- Référence abrégée GQL - Référence rapide de la syntaxe
- Codes d’état GQL - Référence complète du code d’erreur
- Mots réservés GQL - Liste complète des mots clés réservés
Graph dans Microsoft Fabric :
- Modèles de données de graphe - Présentation des concepts et de la modélisation des graphiques
- Bases de données graphiques et relationnelles - Différences et moments d’utilisation de chaque base de données
- Essayer Microsoft Fabric gratuitement
- Tutoriels de bout en bout dans Microsoft Fabric