Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite 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 Supplémentaires d’utilisation pour les Préversions Microsoft Azure.
Un schéma de graphe est la collection de types de nœuds, de types de bord et de leurs propriétés qui définissent la structure de votre graphe. Un schéma de graphe bien conçu facilite l’interrogation, la maintenance et l’extension de vos données. Cet article fournit les meilleures pratiques pour transformer des données tabulaires dans un lakehouse en un graphique de propriétés labeled property graph efficace dans Microsoft Fabric.
Utilisez ces instructions avant de commencer la modélisation dans l’éditeur de modèle de graphe. Pour obtenir des instructions pas à pas sur la création de nœuds et de bords, consultez le didacticiel sur le graphique. Les exemples de cet article utilisent l’exemple de jeu de données Adventure Works.
Important
Graph ne prend actuellement pas en charge l’évolution du schéma. Après avoir modélisé vos données, la structure des nœuds, des arêtes et des propriétés est fixe. Les modifications structurelles, telles que l’ajout de propriétés, la modification d’étiquettes ou la modification des types de relation, vous obligent à créer un modèle de graphe et à recharger toutes les données. Ce processus prend du temps et consomme de la capacité. Planifiez donc soigneusement votre schéma avant de commencer la modélisation.
Prerequisites
- Un espace de travail Fabric avec un lakehouse, qui contient vos tables sources.
- Connaissance de l’éditeur de modèle de graphe.
- Facultatif : l’exemple de jeu de données Adventure Works pour suivre les exemples de cet article.
Comprendre les types de nœuds et les types de périphérie
Avant de concevoir un schéma, comprenez ces concepts fondamentaux :
Un type de nœud définit un type d’entité dans votre graphique, tel qu’un client, un produit ou une commande. Elle comprend :
-
Étiquette, qui est le nom qui identifie cette catégorie de nœud. Par exemple :
Customer. Vous utilisez l’étiquette dans les requêtes pour faire référence aux nœuds de ce type. - Table de mappage, qui est la table lakehouse qui fournit les données sources pour le type de nœud. Par exemple, la table adventureworks_customers .
- Colonne clé qui identifie de manière unique chaque nœud ( ID étiqueté dans l’éditeur de modèle de graphique). Par exemple :
CustomerID_K. -
Propriétés, qui sont des colonnes de la table qui deviennent des attributs sur chaque nœud. Par exemple,
FirstName,LastNameetEmailAddress.
Un nœud est une instance individuelle d’un type de nœud : une ligne dans la table de mappage. Par exemple, chaque ligne de adventureworks_customers devient un Customer nœud.
Un type de périphérie définit un type de relation entre deux types de nœuds. Elle comprend :
-
Étiquette, qui est le nom qui identifie cette catégorie de relation. Par exemple :
purchases. - Table de mappage qui contient les données de relation entre les nœuds source et cible. Par exemple, la table adventureworks_orders .
- Type de nœud source et type de nœud cible que l'arête connecte. Par exemple,
Customeren tant que source etOrderen tant que cible.
Un bord est une instance individuelle d’un type de périphérie : une ligne dans la table de mappage qui connecte deux nœuds spécifiques.
Note
Dans l’éditeur de modèle de graphique, les boutons Ajouter un nœud et Ajouter des arêtes créent des types de nœuds et des types de bord, et non des nœuds ou des arêtes individuels.
Identifier les entités et les relations
Commencez par identifier les entités (éléments) et les relations (connexions ) dans vos données. Les entités deviennent des types de nœuds. Les connexions entre entités deviennent des types d'arêtes.
Posez ces questions sur vos tables sources :
- Quelles sont les entités principales ? Les lignes qui représentent des éléments réels distincts sont des candidats pour les types de nœuds. Par exemple, les clients, les produits, les commandes et les employés.
- Comment ces entités sont-elles liées les unes aux autres ? Les colonnes qui référencent des lignes dans une autre table (clés étrangères) suggèrent des types de bord. Par exemple,
CustomerID_FKdans uneorderstable pointe vers lacustomerstable, ce qui suggère la modélisation d’unpurchasesbord. - Existe-t-il des entités incorporées ? Une colonne à l'intérieur d'une table peut représenter une entité distincte qu'il convient d'extraire en tant que type de nœud à part entière. Pour obtenir un exemple, consultez Choisir des types de nœuds. Pour obtenir une procédure pas à pas, consultez Ajouter plusieurs types de nœuds et de périphérie à partir d’une table de mappage.
Choisir des types de nœuds
Créez un type de nœud pour chaque entité que vous devez interroger ou parcourir indépendamment. Utilisez ces instructions :
| Définissez l’entité comme type de nœud lorsque... | Conservez-le en tant que propriété quand... |
|---|---|
| Vous devez parcourir jusqu'à ou à travers cela. | Il s’agit de métadonnées descriptives que vous lisez uniquement, et non pas parcourir. |
| Plusieurs entités partagent une relation avec elle. | Il est unique à l’entité à laquelle il appartient. |
| Vous devez faire des correspondances ou regrouper par cela directement dans les requêtes. | Vous appliquez ce filtre uniquement comme propriété d'une autre entité. |
Exemple: Dans le jeu de données Adventure Works, Country commence en tant que colonne sur la employees table. Si vous devez interroger « quels employés vivent dans le même pays ? » ou « quels pays ont le plus d’employés ? », extrayez Country en son propre type de nœud. Si vous n’avez besoin d’afficher le pays d’un employé qu’en tant qu’étiquette, laissez-le comme propriété.
Choisir des colonnes clés
Chaque type de nœud nécessite une colonne clé (ou une clé composée) qui identifie de manière unique chaque nœud. Choisissez soigneusement les clés :
-
Utilisez des identificateurs uniques existants à partir de vos tables sources. Par exemple,
CustomerID_KouProductID_K. -
Évitez les clés de substitution qui n’ont pas de signification métier , sauf si aucune clé naturelle n’existe. Par exemple, préférez
CustomerIDà un numéro de ligne s'incrémentant automatiquement. -
Utilisez des clés composées lorsqu’une seule colonne ne garantit pas l’unicité. Par exemple, un
ProductVersionnœud peut avoir besoin à la foisProductIDetVersionNumberen tant que clé. - Mettre en correspondance les types de données entre les colonnes clés et les colonnes clés étrangères utilisées dans les mappages de périphérie. Les types incompatibles provoquent des échecs lors de la création d'arêtes.
Conseil / Astuce
Définissez des contraintes de clé de nœud pour permettre au moteur de requête d’effectuer des recherches directes sur les propriétés de clé. Cette optimisation accélère les requêtes qui recherchent des nœuds spécifiques par clé.
Choisir des types de bordure
Les types edge définissent les relations entre les types de nœuds. Chaque type de périphérie connecte un type de nœud source à un type de nœud cible via une table de mappage.
Suivez ces instructions :
-
Utilisez des étiquettes descriptives qui agissent comme des verbes ou des expressions verbales. Par exemple,
purchases, ,sells,livesInetbelongsTo. Un bord bien nommé facilite la lecture des requêtes. - Réfléchissez soigneusement à la direction. Les arêtes du graphique sont dirigées. Choisissez la direction qui représente le mieux la relation réelle. Par exemple,
Customer--les achats -->Orderse lit plus naturellement queOrder--purchasedBy -->Customer. - Donnez des noms distincts aux types de périphérie qui connectent différentes paires de types de nœud. Si « commande vendue par l'employé » et « commande achetée par le client » se connectent à
Order, nommez-lessellsetpurchasesplutôt que de leur donner à la fois la même étiquette. Pour plus d’informations, consultez les limitations de création de périphérie. -
Ajoutez des propriétés aux types de périphérie lorsque la relation elle-même a des attributs. Par exemple, un
quantitysur uncontainsbord ou unorderDatesur unpurchasesbord.
Important
La table de mappage d’un bord doit contenir des colonnes qui correspondent aux colonnes clés des types de nœuds source et cible dans les valeurs et le type de données. Les tables que vous utilisez pour créer des types de nœuds peuvent également servir de tables de mappage de périphérie si elles répondent à cette exigence.
Supprimer les propriétés inutiles
Lorsque vous créez un type de nœud à partir d’une table de mappage, chaque colonne de la table devient une propriété par défaut. Supprimez les propriétés dont vous n’avez pas besoin pour les requêtes ou l’analyse.
Les propriétés excessives augmentent le stockage, les requêtes lentes et rendent le graphique plus difficile à gérer. Pour chaque type de nœud, conservez uniquement les propriétés suivantes :
- Requis pour l’unicité du nœud (colonnes clés)
- Utilisé dans
WHEREfiltres ouRETURNprojections dans vos requêtes - Nécessaire pour l’analyse ou la visualisation en aval
Pour plus d’informations sur la façon dont le nombre de propriétés affecte les performances des requêtes, consultez Renvoyer uniquement les propriétés dont vous avez besoin.
Choisir des types de données
Sélectionnez le type de données le plus spécifique pour chaque propriété. Les types appropriés améliorent l’efficacité du stockage et les performances des requêtes :
- Utilisez
INTouUINT64pour les identificateurs numériques et les nombres. Les comparaisons numériques sont plus rapides que les comparaisons de chaînes. - Utilisez
ZONED DATETIMEpour les horodatages au lieu des dates formatées en chaîne. - Utilisez
BOOLEANpour les indicateurs true/false au lieu de valeurs de chaîne comme"yes"ou"no".
Pour obtenir la liste complète des types pris en charge, consultez limitations actuelles : types de données.
Modèles courants de conversion de tableaux en graphiques
Le tableau suivant résume la façon dont certaines structures de données tabulaires courantes se traduisent en éléments de graphique :
| Structure tabulaire | Résultat du graphique | Exemple |
|---|---|---|
| Un-à-plusieurs : Table parente + table enfant avec clé étrangère | Deux types de nœuds connectés par un type d'arête. |
Customer
--
achats -->Order |
| Plusieurs-à-plusieurs : Table de jonction reliant deux tables | Type d'arête entre deux types de nœuds. |
Vendor
--
produit-->Product |
| Entité incorporée : Colonne représentant une entité partagée | Type de nœud extrait avec arête. |
Employee
--
résideDans-->Country |
| Hiérarchie: Chaîne de tables parent-enfant | Types de nœuds liés par arêtes à chaque niveau. |
Product
--
isOfType-->Subcategory --belongsTo-->Category |
Pour obtenir une procédure pas à pas du modèle d’entité incorporée, consultez Ajouter plusieurs types de nœuds et de périphérie à partir d’une table de mappage.