Utiliser des relations plusieurs-à-plusieurs

Effectué

Les relations plusieurs-à-plusieurs vous offrent la possibilité de savoir lorsque plusieurs lignes ont les mêmes données associées. Contrairement aux relations un-à-plusieurs, les relations plusieurs-à-plusieurs n’ont pas de concept de table principale. La relation est entièrement symétrique et vous pouvez accéder à l’ensemble des lignes associées, en commençant de n’importe quel côté de la relation plusieurs-à-plusieurs. Reprenons le modèle de données de partage d’espace de travail Contoso. Les sections suivantes expliquent comment utiliser les relations plusieurs-à-plusieurs dans une application canevas à l’aide des éléments Bureau et fonctionnalités de bureau. Le diagramme suivant présente la relation et des données correspondantes.

Chaque bureau peut avoir plusieurs lignes de fonctionnalités de bureau associées et vous pouvez associer chaque fonctionnalité des bureaux à plusieurs bureaux. Vous pouvez accéder à l’ensemble des fonctionnalités de bureau à partir d’une ligne de bureau en utilisant l’expression ThisItem.’Desk Features’. À partir de la ligne des fonctionnalités de bureau, vous pouvez utiliser l’expression ThisItem.’Desk Features’ pour accéder à tous les bureaux associés à cette fonctionnalité des bureaux spécifique.

Vous pouvez utiliser cette expression pour afficher une liste de valeurs séparées par des virgules pour chaque bureau dans une galerie, comme illustré dans l’exemple suivant.

Pour réaliser la tâche consistant à renseigner le texte de l’étiquette, définissez la propriété Text sur l’étiquette sur la formule suivante :

Concat(ThisItem.'Desk Features',Name ,",")

Soyez conscient des implications sur les performances lorsque vous utilisez cette formule, en particulier si vous avez de nombreux enregistrements, en raison de la façon dont les données sont accessibles à partir de Dataverse. L’image suivante montre que, depuis le Monitor, un appel à getRows est complété pour obtenir la liste des bureaux. Pour chaque bureau, un appel à getNavigatedRowInTableRow est effectué pour récupérer les fonctionnalités du bureau.

Vous pouvez également trouver plus intéressant de n’afficher les fonctionnalités de bureau qu’une fois que l’utilisateur a sélectionné une seule ligne de bureau dans une galerie ou après qu’il a exploré les détails de la ligne de bureau.

Une autre façon d’utiliser la relation est de permettre à un utilisateur de choisir une fonctionnalité des bureaux, puis d’utiliser la propriété controlName.Selected.Desks pour renseigner des éléments dans une galerie.

Cette approche fonctionne bien lorsque vous n’autorisez qu’une seule sélection dans la zone de liste déroulante. Si vous activez plusieurs sélections, la logique devient plus complexe. À l’heure actuelle, Power Fx n’a pas de moyen simple d’exprimer une intersection de deux collections, ce qui est nécessaire pour que le scénario fonctionne. Des solutions de contournement sont possibles : par exemple, vous pouvez parcourir toutes les fonctionnalités sélectionnées, collecter les bureaux associés dans une seule collection, supprimer les doublons, puis utiliser la collection comme source de l’élément. Cependant, en raison des multiples demandes Dataverse (une pour chaque fonctionnalité sélectionnée), les performances de cette approche se dégradent rapidement à mesure que les tables s’étendent.

Établir la relation

Le principal moyen d’établir une relation plusieurs-à-plusieurs consiste à utiliser la fonction Relate(), de la même manière que vous le feriez avec une relation un-à-plusieurs. La principale différence est que peu importe quel enregistrement est le premier ou le deuxième paramètre de Relate(), car aucune table principale n’est dans la relation.

La gestion des relations plusieurs-à-plusieurs sur un formulaire est plus complexe que les colonnes de recherche plusieurs-à-un. La relation plusieurs-à-plusieurs est disponible dans la liste des champs ; toutefois, lorsque vous ajoutez le champ au formulaire, le système ne génère pas les formules pour que le contrôle fonctionne, et vous recevez une erreur semblable à l’exemple suivant.

Pour résoudre le problème, mettez à jour la fonction Choices() dans la propriété Items de la table qui se trouve de l’autre côté de la relation plusieurs-à-plusieurs. Pour accomplir cette tâche, déverrouillez la carte dans l’onglet Avancée.

Dans l’exemple Contoso, vous souhaitez utiliser les fonctionnalités de bureau. Après avoir déverrouillé le contrôle, vérifiez que la propriété Items affiche ’Desk Features’ comme source de données.

Remarque

Le scénario précédent utilise le formulaire pour ajouter une ligne. Pour prendre en charge les fonctionnalités d’édition, assurez-vous de modifier la propriété DisplayMode de la carte en remplaçant le paramètre Afficher par défaut par Modifier.

Après avoir ajusté les propriétés, l’interface utilisateur du formulaire fonctionnera et vous pourrez choisir des éléments dans la zone de liste déroulante. Cependant, si vous essayez d’envoyer le formulaire, vous générerez une erreur semblable à l’exemple suivant.

Pour contourner le problème, effacez la propriété Update et traiter manuellement l’association plusieurs-à-plusieurs après l’envoi du formulaire.

Après avoir effacé la propriété Update, l’envoi du formulaire fonctionnera. Cependant, les relations entre les lignes des tables Desk et Desk Feature ne seront pas créées. Pour établir les relations, ajoutez la logique suivante à la propriété OnSelect de l’icône représentant une coche qui est utilisée pour envoyer le formulaire par défaut :

  1. Enregistrez les fonctionnalités de bureau sélectionnées dans la zone de liste déroulante en tant que collection. Cette étape est obligatoire, car l’envoi du formulaire réinitialisera les champs et la valeur sera perdue.

  2. Envoyez le formulaire.

  3. Utilisez la collection enregistrée des fonctionnalités de bureau pour établir la relation.

Autres options de conception

L’expérience utilisateur avec des relations plusieurs-à-plusieurs est similaire aux expériences dans lesquelles la colonne Choix est utilisée. Les valeurs des choix sont prédéterminées par le créateur et ne peuvent être ni désactivées ni sécurisées. Pour cette raison, les champs Choix conviennent aux scénarios avec des données rarement modifiées, comme une liste de pays/régions. De plus, les lignes des tables associées peuvent être désactivées, sécurisées et ajoutées au moment de l’exécution. Cette capacité fait d’une relation plusieurs-à-plusieurs une bonne option dans les scénarios où une certaine flexibilité est nécessaire au moment de l’exécution, comme lorsque vous marquez une solution dans laquelle le contact a une relation plusieurs-à-plusieurs avec une balise et où les balises doivent être ajoutés par les utilisateurs.

Les relations plusieurs-à-plusieurs sont utiles dans les situations où vous souhaitez capturer l’association entre les lignes de deux tables. La relation entre les lignes ne peut pas stocker d’autres données. Par exemple, si vous aviez une relation entre une table Contact et une table Language, vous pourriez vérifier qu’une personne parle deux langues.

Cependant, vous ne sauriez pas depuis combien de temps la personne parle chaque langue et à quel point elle la maîtrise.

Un autre modèle de conception courant consiste à créer votre propre table d’intersection. La table Language Spoken suivante est une autre table Dataverse personnalisée. Vous pouvez ajouter des colonnes à cette table pour toute autre propriété décrivant la relation spécifique. Ensuite, cette nouvelle table aura des relations N:1 avec Contact et Language.

L’utilisation de ces tables à partir de votre application est similaire à l’utilisation de toute autre table ayant des relations un-à-plusieurs ou plusieurs-à-un. Étant donné qu’une table supplémentaire est impliquée, vous découvrirez peut-être qu’une logique supplémentaire sera nécessaire pour garantir une expérience utilisateur fluide. Il est important de comprendre les exigences de votre application et de savoir si une relation plusieurs-à-plusieurs doit suivre d’autres données, d’autant plus que vous devez prendre cette décision au moment où les tables sont liées.