Partager 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 Supplemental Conditions d’utilisation pour les préversions Microsoft Azure.

Un type de graphique définit la structure d’un graphe en spécifiant les nœuds et les arêtes qui peuvent exister, leurs étiquettes et leurs propriétés, ainsi que la façon dont ils se connectent les uns aux autres. Considérez un type de graphe comme un schéma ou un blueprint, similaire à la façon dont un diagramme ER (entity-relationship) décrit les tables et les relations de clé étrangère dans une base de données relationnelle.

Cet article explique comment définir des types de graphiques à l’aide de la syntaxe GQL, notamment les types de nœuds, les types de périphérie, les contraintes et l’héritage.

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 prise en charge directement pour le graphe.

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

Définissez des types de graphiques à l’aide d’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 que vous définissez.

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).

Utilisez l’opérateur :: pour spécifier le type de données de chaque propriété. Permet NOT NULL d’indiquer que la propriété doit toujours avoir une valeur.

Note

Dans GQL, NOT NULL fait partie du type, 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 fournit l’opérateur += pour que vous puissiez spécifier uniquement les étiquettes et les types de propriétés supplémentaires (non nonherited) :

(: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 graphique :

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. Elles 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. Un ensemble de types de bords avec la même étiquette de clé est 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

Avoir à expliquer chaque type de bord possible peut être fastidieux. Pour simplifier, définissez des familles de types de périphérie qui s’alignent sur la hiérarchie des types de nœuds implicites par leurs points de terminaison.

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)

Cette définition définit implicitement les types de bord suivants :

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

Types de propriétés pris en charge

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

Utilisez les types de données suivants 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}) est valide, tandis qu’un type de graphique avec n’est (:A { id :: STRING }), (:B { id :: INT}) 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, 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 nommé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