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.
Les relations de table dans Microsoft Dataverse définissent les façons dont les lignes de table peuvent être associées à des lignes d’autres tables ou à la même table. Il existe deux types de relations de table :
Relations 1 à N (un-à-plusieurs)
Dans une relation de table un-à-plusieurs, de nombreuses lignes de table de référence (connexes) peuvent être associées à une seule ligne de table référencée (primaire). La ligne de table référencée est parfois appelée « parent » et les lignes de la table de référencement sont appelées « enfants ». Une relation plusieurs-à-un est simplement la perspective enfant d’une relation un-à-plusieurs.
Par exemple, dans un scénario scolaire, plusieurs cours peuvent être offerts dans une classe unique, de sorte que la table de cours aurait une relation un-à-plusieurs avec la table de cours.
Relations plusieurs à plusieurs
Dans une relation de table plusieurs-à-plusieurs, de nombreuses lignes de table peuvent être associées à de nombreuses autres lignes de table. Les lignes liées par une relation plusieurs-à-plusieurs peuvent être considérées comme des égales et la relation est réciproque.
Par exemple, dans le même scénario scolaire mentionné précédemment, un seul étudiant peut s’inscrire à plusieurs cours, et chaque cours peut avoir plusieurs étudiants. Ce type de relation permet d’utiliser des associations de données plus complexes et est géré à l’aide de Power Apps dans Dataverse.
Fonctionnement des relations dans Dataverse
Les relations de table définissent la façon dont les lignes de table peuvent être liées les unes aux autres dans Dataverse. Au niveau le plus simple, l’ajout d’une colonne de recherche à une table crée une relation 1 :N (un-à-plusieurs) entre les deux tables et vous permet de placer cette colonne de recherche sur un formulaire. Avec la colonne de recherche, les utilisateurs peuvent associer plusieurs lignes enfants de cette table à une ligne de table parente unique.
Au-delà de la simple définition de la façon dont les lignes peuvent être liées à d’autres lignes, les relations de table 1 :N fournissent également des données pour répondre aux questions suivantes :
- Quand je supprime une ligne, les lignes associées à cette ligne doivent-elles également être supprimées ?
- Quand j’assigne une ligne, dois-je également affecter toutes les lignes associées à cette ligne au nouveau propriétaire ?
- Comment puis-je simplifier le processus d’entrée de données lorsque je crée une ligne associée dans le contexte d’une ligne existante ?
- Comment les utilisateurs qui consultent une ligne doivent-ils être en mesure d’afficher les lignes associées ?
Les tables peuvent également participer à une relation N :N (plusieurs-à-plusieurs) où un nombre quelconque de lignes pour deux tables peut être associé l’un à l’autre.
Décidez s’il faut utiliser des relations de table ou des connexions
Les relations de table sont des métadonnées qui apportent des modifications dans Dataverse. Ces relations permettent aux requêtes de récupérer efficacement les données associées. Utilisez des relations de table pour définir des relations formelles qui définissent la table ou que la plupart des lignes peuvent utiliser. Par exemple, une opportunité sans client potentiel ne serait pas utile. La table d’opportunités dans Dynamics 365 for Sales a également une relation N :N avec la table concurrente, également disponible avec Dynamics 365 for Sales. Cela permet à plusieurs concurrents d’être ajoutés à l’opportunité. Vous pouvez capturer ces données et créer un rapport qui affiche les concurrents.
Il existe d’autres types de relations moins formels entre les lignes appelées connexions. Par exemple, il peut être utile de savoir si deux contacts sont mariés, ou peut-être qu’ils sont amis en dehors du travail, ou peut-être un contact utilisé pour travailler pour un autre compte. La plupart des entreprises ne génèrent pas de rapports à l’aide de ce type d’informations ou nécessitent qu’elles soient entrées. Il n’est donc probablement pas utile de créer des relations de table. Plus d’informations : Configurer des rôles de connexion
Types de relations de table
Lorsque vous affichez des relations dans Power Apps, vous pouvez penser qu’il existe trois types de relations de table. En réalité, il n’en existe que deux, comme illustré dans le tableau suivant.
| Type de relation | Descriptif |
|---|---|
| 1 à N (un-à-plusieurs) | Relation de table où une ligne de table pour la table primaire peut être associée à de nombreuses autres lignes de table associées en raison d’une colonne de recherche sur la table associée. Lors de l’affichage d’une ligne de table principale, vous pouvez voir une liste des lignes de table associées qui y sont associées. Dans le portail Power Apps, la table actuelle représente la table principale. |
| Relations N à N (plusieurs à plusieurs) | Relation de table qui dépend d’une table de relations spéciale, parfois appelée table Intersect, permettant à de nombreuses lignes d'une table d'être associées à de nombreuses lignes d'une autre table. Lorsque vous affichez des lignes d’une table dans une relation N :N, vous pouvez voir la liste des lignes de l’autre table associée. |
Le type de relation N :1 (plusieurs-à-un) existe dans l’interface utilisateur, car le concepteur affiche une vue regroupée par tables. 1 :N les relations existent réellement entre les tables et font référence à chaque table en tant que table principale/actuelle ou table associée. La table associée, parfois appelée table enfant , a une colonne de recherche qui permet de stocker une référence à une ligne de la table primaire, parfois appelée table parente . Une relation N :1 n’est qu’une relation 1 :N vue à partir de la table associée.
Comportement de la relation entre tables
Les comportements des tables associées sont importants, car ils permettent de garantir l’intégrité des données et d’automatiser les processus métier pour vous.
Préserver l’intégrité des données
Certaines tables existent pour prendre en charge d’autres tables. Ils n’ont pas de sens en soi. Ils auront généralement une colonne de recherche obligatoire pour établir un lien vers la table primaire qu'ils soutiennent. Que doit-il se passer lorsqu’une ligne primaire est supprimée ?
Vous pouvez utiliser le comportement de relation pour définir ce qui se passe sur les lignes associées en fonction des règles de votre entreprise. Pour plus d’informations : Ajouter un comportement des relations avancées
Automatiser les processus d'entreprise
Supposons que vous disposez d’un nouveau vendeur et que vous souhaitez leur attribuer un certain nombre de comptes existants actuellement attribués à un autre vendeur. Chaque ligne de compte peut avoir un certain nombre d’activités de tâche associées. Vous pouvez facilement localiser les comptes actifs que vous souhaitez réaffecter et les affecter au nouvel vendeur. Mais qu’est-ce qui doit se passer pour l’une des activités de tâche associées aux comptes ? Souhaitez-vous ouvrir chaque tâche et déterminer si elle doit également être attribuée au nouveau vendeur ? Probablement pas. Par contre, vous pouvez laisser la relation appliquer automatiquement des règles standard. Ces règles s’appliquent uniquement aux lignes de tâche associées aux comptes que vous réaffectez. Voici les différents choix possibles :
- Réattribuer toutes les tâches actives.
- Réattribuer toutes les tâches.
- Ne réattribuer aucune tâche.
- Réaffectez toutes les tâches actuellement affectées à l’ancien propriétaire des comptes.
La relation peut contrôler la façon dont les actions effectuées sur une ligne pour la ligne de la table primaire se propagent vers toute ligne de table associée.
Behaviors
Il existe plusieurs types de comportements qui peuvent être appliqués lorsque certaines actions se produisent.
| Comportement | Descriptif |
|---|---|
| Cascade active | Effectuez l’action sur toutes les lignes de table associées actives. |
| Tout en cascade | Effectuez l’action sur toutes les lignes de table associées. |
| Sans mise en cascade | Ne rien faire. |
| Supprimer le lien | Supprimez la valeur de recherche pour toutes les lignes associées. |
| Restreindre | Empêchez la suppression de la ligne de table primaire lorsque des lignes de table associées existent. |
| Cascade propriétaire | Effectuez l’action sur toutes les lignes de table associées appartenant au même utilisateur que la ligne de table principale. |
Actions
Voici les actions qui peuvent déclencher certains comportements :
| Colonne | Descriptif | Options |
|---|---|---|
| Attribuer | Que doit-il se passer lorsque la ligne de la table primaire est affectée à une autre personne ? | Tout en cascade Cascade active Propriété en cascade par l’utilisateur Sans mise en cascade |
| Réparent | Que doit-il se passer lorsque la valeur de recherche d’une table associée dans une relation parentale est modifiée ? Plus d’informations : Relations de table parentale |
Tout en cascade Cascade active Propriété utilisateur en cascade Sans mise en cascade |
| Partager | Que doit-il se passer lorsque la ligne de la table primaire est partagée ? | Tout en cascade Cascade active Cascade à propriété utilisateur Sans mise en cascade |
| Supprimer | Que doit-il se passer lorsque la ligne de la table primaire est supprimée ? | Tout en cascade Supprimer le lien vers l’article Restreindre |
| Annuler le partage | Que doit-il se passer lorsqu’une ligne de table primaire est départagée ? | Tout en cascade Cascade active Cascade Propriétaire-utilisateur Sans mise en cascade |
| Fusionner | Que doit-il se passer lorsqu’une ligne de table primaire est fusionnée ? | Tout en cascade Sans mise en cascade |
| Vue cumulée | Quel est le comportement souhaité de l’affichage cumulatif associé à cette relation ? | Tout en cascade Cascade active "Contrôle en cascade par l'utilisateur" Sans mise en cascade |
Note
Les actions Assign, Delete, Merge et Reparent ne s’exécutent pas dans les situations suivantes :
- Si la ligne parente d’origine et l’action demandée contiennent les mêmes valeurs. Exemple : tentative de déclenchement d'une activation et en choisissant un contact qui est déjà le propriétaire de la ligne.
- Tentative d’exécution d’une action sur une ligne parente qui exécute déjà une action en cascade.
Lors de l’exécution d’un assign, tous les flux de travail ou règles métier actuellement actifs sur les lignes sont automatiquement désactivés lorsque la réaffectation se produit. Le nouveau propriétaire de la ligne doit réactiver le flux de travail ou la règle métier s’ils souhaitent continuer à l’utiliser.
Relations de table parentale
Chaque paire de tables éligible à une relation 1 :N peut avoir plusieurs relations 1 :N entre elles. Pourtant, généralement, une seule de ces relations peut être considérée comme une relation de table parentale.
Une relation de table parente est n’importe quelle relation de table 1 :N où l’une des options en cascade dans la colonne Parent de la table suivante est vraie.
| Action | Parental | Pas parental |
|---|---|---|
| Attribuer | Tout en cascade Cascade appartenant à l'utilisateur Cascade active |
Sans mise en cascade |
| Supprimer | Tout en cascade | RemoveLink Restreindre |
| Réparent | Tout en cascade Propriété de l’utilisateur cascade Cascade active |
Sans mise en cascade |
| Partager | Tout en cascade Cascade contrôlé par l’utilisateur Cascade active |
Sans mise en cascade |
| Annuler le partage | Tout en cascade Propriété en cascade détenue par l’utilisateur Cascade active |
Sans mise en cascade |
Par exemple, si vous créez une table personnalisée et ajoutez une relation de table 1 :N avec la table de compte où votre table personnalisée est la table associée, vous pouvez configurer les actions de cette relation de table pour utiliser les options de la colonne Parental . Si vous ajoutez ultérieurement une autre relation de table 1 :N avec votre table personnalisée en tant que table de référencement, vous pouvez uniquement configurer les actions pour utiliser les options de la colonne Not Parental .
Cela signifie généralement que pour chaque paire de tables, il existe une seule relation de parenté. Il existe certains cas où la recherche sur la table associée peut autoriser une relation avec plusieurs types de table.
Par exemple, si une table a une recherche client qui peut faire référence à une table de contacts ou de compte. Il existe deux relations de table parentes distinctes 1 :N.
Toute table d’activité a un ensemble similaire de relations de table parentale pour les tables qui peuvent être associées à l’aide de la colonne de recherche relative.
Limitations de comportements que vous pouvez définir
En raison des relations de dépendance, il existe certaines limitations que vous devez garder à l'esprit lorsque vous définissez des relations de table.
- Une table personnalisée ne peut pas être la table primaire dans une relation avec une table système associée qui se cascade. Cela signifie que vous ne pouvez pas avoir de relation avec une action définie sur Cascade All, Cascade Active ou Cascade User-Owned entre une table personnalisée principale et une table système associée.
- Aucune nouvelle relation ne peut avoir une action définie sur Cascade All, Cascade Active ou Cascade User-Owned si la table associée de cette relation existe déjà en tant que table associée dans une autre relation qui a une action définie sur Cascade All, Cascade Active ou Cascade User-Owned. Cela empêche les relations qui créent une relation à plusieurs parents.
Nettoyage des droits d’accès hérités
L'utilisation des comportements en cascade Reparentage et Partage est utile lorsque vous souhaitez fournir l'accès aux lignes entre les tables liées. Toutefois, il peut y avoir un changement de processus ou de conception qui nécessite une modification des paramètres de comportement en cascade.
Lorsqu’une relation de table utilise Reparent ou Share et que le comportement en cascade est remplacé par Cascade None, la relation de table empêche les nouvelles modifications d’autorisation de cascader vers les tables enfants associées. En outre, les autorisations héritées qui ont été accordées pendant que le comportement en cascade était actif doivent être révoquées.
Le nettoyage des droits d’accès hérités est un travail système qui supprime les droits d’accès hérités restants après que le comportement en cascade a été modifié en Cascade None. Ce nettoyage n’affecte aucun utilisateur à qui l’accès à une table a été directement accordé, cependant, il supprime l’accès de toute personne ayant reçu l’accès uniquement via l’héritage.
Voici comment fonctionne le nettoyage des droits d’accès hérités :
- Identifie et collecte toutes les tables ayant une relation en cascade avec l'élément parent mis à jour.
- Identifie et collecte les utilisateurs qui ont reçu l’accès aux tables associées par le biais de l’accès hérité.
- Recherche les utilisateurs qui ont reçu un accès direct à une table associée et les supprime de la collection.
- Supprime l’accès hérité pour les utilisateurs associés aux tables récupérées.
Une fois le nettoyage exécuté, les utilisateurs qui ont pu accéder aux tables associées uniquement en raison de la fonctionnalité en cascade ne peuvent plus accéder aux lignes, ce qui garantit une sécurité accrue. Il existe des cas où le nettoyage risque de ne pas réussir. En savoir plus sur le nettoyage de l’accès hérité
Voir aussi
Surveiller les tâches système
Créer et modifier des relations 1:N (un-à-plusieurs) ou N:1 (plusieurs-à-un)
Créer des relations de table plusieurs à plusieurs (N :N)