Partage via

Types de graphiques 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.

Un type de graphique décrit la structure de votre graphe en définissant les nœuds et les arêtes qui peuvent exister. Considérez-le comme un blueprint ou un schéma , il spécifie la forme des nœuds et des arêtes dans le graphique en termes d’étiquettes et de propriétés. Pour les arêtes (les connexions entre les nœuds), elle spécifie également quels types de bords peuvent connecter les types de nœuds. Si vous êtes familiarisé avec les bases de données relationnelles, les types de graphiques fonctionnent de la même façon que les diagrammes ER décrivent les tables et les relations de clé étrangère.

Important

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

Les types de graphiques offrent plusieurs avantages clés :

  • Validation des données : vérifiez que votre graphique contient uniquement des combinaisons de nœuds et de périphérie valides.
  • Optimisation des requêtes : aidez le moteur de requête à comprendre votre structure de données pour améliorer les performances.
  • Documentation : Servez-vous d’une spécification claire de la structure de votre graphe pour les développeurs et les analystes.

Note

Cet article présente des types de graphiques conceptuellement et illustre leur définition à l’aide de la syntaxe définie dans la norme GQL. Toutefois, cette syntaxe n’est actuellement pas directement prise en charge pour le graphe dans Microsoft Fabric.

Structurellement, un type de graphique définit les types de nœuds autorisés et les types de bord des graphiques du type de graphique, ainsi que des contraintes supplémentaires qui limitent davantage ces graphiques.

Note

Les types de graphiques sont définis en donnant un ensemble de définitions de type de nœud, de type de périphérie et de contrainte. La modification de l’ordre de ces définitions ne modifie pas le type de graphique défini.

Définir des types de nœuds

Un type de nœud spécifie les étiquettes et les types de propriétés que vos nœuds peuvent avoir. Voici comment spécifier un type de nœud de base :

(:Organization => { 
  id :: UINT64 NOT NULL, 
  name :: STRING, 
  url :: STRING 
})

Cet exemple crée un type de nœud qui définit des nœuds avec :

  • OrganizationÉtiquette .
  • Propriété id qui contient des valeurs entières non signées et qui ne peut pas être null.
  • Propriété name qui contient des valeurs de chaîne (peut être null).
  • Propriété url qui contient des valeurs de chaîne (peut être null).

L’opérateur :: spécifie le type de données de chaque propriété, tandis qu’il NOT NULL indique que la propriété doit toujours avoir une valeur.

Note

NOT NULL est considéré comme faisant partie du type dans GQL, qui diffère de SQL.

Les types de nœuds peuvent également être plus complexes, avec plus de propriétés et de types de données :

(:Person => {
    id :: UINT64 NOT NULL,
    creationDate :: ZONED DATETIME,
    firstName :: STRING,
    lastName :: STRING,
    gender :: STRING,
    birthday :: UINT64,
    browserUsed :: STRING,
    locationIP :: STRING
})

Types de nœuds avec plusieurs étiquettes

Les nœuds peuvent avoir plusieurs étiquettes pour prendre en charge l’héritage et la catégorisation. Vous pouvez spécifier plusieurs étiquettes pour un type de nœud, mais une étiquette (l’étiquette de clé) doit identifier de manière unique le type de nœud (si une seule étiquette est spécifiée, il s’agit de l’étiquette de clé du type de nœud).

Prenons l’exemple suivant :

(:University => :Organization),

(:Company => :Organization)

University Company Voici les étiquettes clés des deux types de nœuds définis, tandis qu’il Organization s’agit d’une étiquette secondaire partagée par les deux types. Notez comment l’étiquette de clé et les étiquettes secondaires sont séparées par => chaque type de nœud. Cette approche crée une hiérarchie de types où les universités et les entreprises sont des types d’organisations.

Étant donné que les étiquettes clés identifient les types de nœuds, les propriétés des types de nœuds identifiés par les étiquettes secondaires sont automatiquement héritées lors de l’utilisation de cette syntaxe. Par conséquent, la syntaxe précédente peut être comprise pour définir efficacement les types de nœuds suivants :

(:University => :Organization {
  id :: UINT64 NOT NULL, 
  name :: STRING, 
  url :: STRING 
}),

(:Company => :Organization {
  id :: UINT64 NOT NULL, 
  name :: STRING, 
  url :: STRING 
})

Note

Les étiquettes clés sont essentielles lorsque vous définissez des hiérarchies de type de nœud. Ils aident le système à comprendre le type de nœud auquel vous faites référence lorsque plusieurs types partagent les mêmes étiquettes.

Gagner du temps avec les raccourcis d’héritage

La répétition d’étiquettes et de propriétés à partir de types de nœuds parents est fastidieuse et sujette aux erreurs. Graph dans Microsoft Fabric fournit l’opérateur += pour que vous puissiez spécifier uniquement les étiquettes et les types de propriétés supplémentaires (non nonhherited) :

(:Post => :Message += {
    language :: STRING,
    imageFile :: STRING
})

Quand aucune propriété supplémentaire n’est spécifiée, le graphique hérite de toutes les propriétés requises du type parent :

(:Comment => :Message)  -- Same as: (:Comment => :Message += {})

Utiliser des types de nœuds abstraits

Vous pouvez définir des types de nœuds uniquement pour la création de hiérarchies, même si votre graphe ne contient pas de nœuds concrets de ce type. Les types de nœuds abstraits sont utiles pour créer des regroupements conceptuels et des jeux de propriétés partagées. À cet effet, vous pouvez définir un type de nœud comme ABSTRACT dans le graphe dans Microsoft Fabric :

ABSTRACT (:Message => {
    id :: UINT64 NOT NULL,
    creationDate :: ZONED DATETIME,
    browserUsed :: STRING,
    locationIP :: STRING,
    content :: STRING,
    length :: UINT64
})

Les types de nœuds abstraits ne sont pas disponibles pour le chargement direct de graphiques. Ils existent uniquement pour structurer votre hiérarchie et définir des propriétés partagées. Les types de nœuds concrets qui héritent des types abstraits peuvent être chargés avec des données.

Définir des types de périphérie et des familles

Un type de périphérie définit l’étiquette de clé, les types de propriétés et les types de nœuds de point de terminaison pour les arêtes. Dans les bases de données de graphiques, les arêtes représentent les connexions entre les nœuds. La définition de périphérie indique au système quelles relations sont autorisées dans votre graphique :

(:Person)-[:knows { creationDate :: ZONED DATETIME }]->(:Person)

Ce type de bord définit tous les bords avec :

  • Étiquette knows(clé).
  • Propriété creationDate qui contient des ZONED DATETIME valeurs (horodatages avec un décalage de fuseau horaire).
  • Points de terminaison source et de destination qui doivent être Person des nœuds.

La flèche -> indique la direction du bord, de la source à la destination. Ces informations directionnelles sont essentielles pour comprendre la sémantique de votre graphe.

Voici d’autres exemples de types de périphérie :

(:Person)-[:studyAt { classYear :: UINT64 }]->(:University)
(:Person)-[:workAt { workFrom :: UINT64 }]->(:Company)

Vous devez uniquement spécifier les étiquettes de clé (Personou UniversityCompany) pour les types de nœuds de point de terminaison. Vous n’avez pas besoin de répéter la définition complète du type de nœud. Le système résout ces références aux définitions de type de nœud complètes.

Familles de types de bords graphes

Les étiquettes de clé de bord du graphe fonctionnent différemment des étiquettes de clé de nœud. Vous pouvez avoir plusieurs types de périphérie avec la même étiquette de clé dans un type de graphique, tant qu’ils ont les mêmes étiquettes et les mêmes types de propriétés. Toutefois, deux types de périphérie avec la même étiquette de clé doivent différer dans au moins un type de nœud de point de terminaison. Nous appelons un ensemble de types de bords avec la même étiquette de clé qu’une famille de types de bords.

Ce concept vous permet de modéliser le même type de relation entre différents types d’entités.

Exemple :

(:City)-[:isPartOf]->(:Country),
(:Country)-[:isPartOf]->(:Continent)

Les deux types de périphérie utilisent l’étiquette isPartOf , mais ils connectent différents types de nœuds, formant une famille de types de bord qui représente des relations hiérarchiques de confinement.

Utiliser le sous-typage des nœuds dans les définitions de types d’arête

Devoir épeler chaque type d’arête possible peut être un peu fastidieux. Pour simplifier, il est également possible de définir des familles de types d’arêtes qui correspondent à la hiérarchie des types de nœuds impliquée par leurs extrémités.

Exemple :

-- Node types
ABSTRACT (:Message { ... }),
(:Post => :Message { ... }),
(:Comment => :Message { ... }),

-- All edge types (x)-[:hasTag]->(:Tag) where x is at least a (:Message)
(<:Message)-[:hasTag]->(:Tag)

Cela définit implicitement les types d’arêtes suivants :

(:Post)-[:hasTag]->(:Tag) 
(:Comment)-[:hasTag]->(:Tag)

Types de propriétés pris en charge

Lorsque vous définissez un type de propriété, le type de valeur de propriété doit être un graphique pris en charge dans Microsoft Fabric. Le choix des types de données appropriés est important pour l’efficacité du stockage et les performances des requêtes.

Voici les types de données que vous pouvez utiliser pour les valeurs de propriété :

  • INT (également : INT64)
  • UINT (également : UINT64)
  • STRING
  • BOOL (également : BOOLEAN)
  • DOUBLE (également : FLOAT64, FLOAT)
  • T NOT NULL, où T se trouve l’un des types de données précédents.
  • LIST<T> et LIST<T> NOT NULL, où T se trouve l’un des types de données précédents.

Pour obtenir des informations complètes sur les types valeur, consultez les valeurs GQL et les types valeur.

Important

Tous les types de propriétés portant le même nom qui se produisent dans un type de nœud ou un type de bord d’un type de graphique donné doivent spécifier le même type de valeur de propriété. La seule exception : elles peuvent différer si elles incluent la valeur Null. Par exemple, selon cette règle, un type de graphique avec (:A { id :: STRING }), (:B { id :: STRING NOT NULL}) lequel il serait valide, tandis qu’un type de graphique avec (:A { id :: STRING }), (:B { id :: INT}) n’est pas valide.

Configurer des contraintes de clé de nœud

Les contraintes de clé de nœud définissent la façon dont chaque nœud de votre graphique est identifié de manière unique par une ou plusieurs de ses valeurs de propriété. Les contraintes clés fonctionnent comme les contraintes de clé primaire dans les bases de données relationnelles et garantissent l’intégrité des données. Une contrainte de clé de nœud peut cibler des nœuds sur plusieurs types de nœuds, ce qui vous permet de définir des clés de nœud pour des hiérarchies conceptuelles entières.

Comprendre les contraintes clés est cruciale car elles :

  • Assurez-vous de l’unicité : empêchez les nœuds dupliqués en fonction de votre logique métier.
  • Activez des recherches efficaces : autorisez le système à optimiser les requêtes qui recherchent des nœuds spécifiques.
  • Prise en charge de l’intégration des données : fournissez un moyen stable de référencer des nœuds entre différentes sources de données.

Important

Pour le graphique dans Microsoft Fabric, une seule contrainte clé doit limiter chaque nœud.

Fonctionnement des contraintes de clé de nœud

Vous pouvez spécifier des contraintes de clé de nœud dans votre type de graphique. Chaque contrainte de clé de nœud a des caractéristiques spécifiques qui le rendent efficace :

Composants d’une contrainte de clé de nœud :

  • Possède un nom unique dans le type de graphique pour une référence simple.
  • Définit des nœuds ciblés à l’aide d’un modèle de contrainte simple qui spécifie les nœuds auxquels la contrainte s’applique.
  • Définit les propriétés qui forment la valeur de clé unique.

Exemple :

CONSTRAINT person_pk
  FOR (n:Person) REQUIRE n.id IS KEY

Cette syntaxe crée une contrainte de clé de nœud appelée person_pk pour tous les nœuds avec au moins l’étiquette Person . La contrainte garantit que chaque nœud du graphique est identifié de manière unique par sa id propriété. Aucun nœud avec l’étiquette Person ne peut avoir la même id valeur.

Vous pouvez également définir des clés composées qui utilisent plusieurs propriétés ensemble pour garantir l’unicité à l’aide de la CONSTRAINT ... FOR ... REQUIRE (n.prop1, n.prop2) IS KEY syntaxe.

Important

Propriétés utilisées dans les contraintes de clé :

  • Impossible d’avoir la valeur Null
  • Doit être déclaré comme NOT NULL dans les types de nœuds et les types de périphérie ciblés par la contrainte de clé

Contenu connexe

  • Last updated on