Partager via

Conseils relatifs aux relations actives et inactives

  • Article

Cet article vous cible en tant que modélisateur de données qui fonctionne avec Power BI Desktop. Vous trouverez ici des conseils pour savoir quand créer des relations de modèle actives ou inactives. Par défaut, les relations actives propagent des filtres à d’autres tables. Toutefois, la relation inactive ne propage que les filtres lorsqu’une expression DAX active (utilise) la relation.

Note

Une introduction aux relations de modèle n’est pas abordée dans cet article. Si vous n’êtes pas complètement familiarisé avec les relations, leurs propriétés ou comment les configurer, nous vous recommandons de lire d’abord les relations de modèle dans l’article Power BI Desktop.

Il est également important de comprendre la conception de schémas en étoile. Pour plus d’informations, consultez Comprendre le schéma en étoile et son importance pour Power BI.

Relations actives

En règle générale, nous vous recommandons de définir des relations actives dans la mesure du possible. Ils élargissent l’étendue et le potentiel de l’utilisation de votre modèle par les auteurs de rapports et les utilisateurs travaillant avec Q&A.

Prenons l’exemple d’un Modèle d’importation conçu pour analyser les performances de ponctualité des liaisons aériennes (OTP). Le modèle a une table Flight, qui est une table de faits qui stocke une ligne par vol. Chaque ligne enregistre la date de vol, le numéro de vol, le départ et les aéroports d’arrivée, ainsi que toute heure de retard (en minutes). Il existe également une table Airport, qui est une table de dimension qui stocke une ligne par aéroport. Chaque ligne décrit le code de l’aéroport, le nom de l’aéroport et le pays ou la région.

Voici un diagramme de modèle partiel des deux tables.

Diagramme montrant un modèle contenant deux tables : Flight and Airport. La conception des relations est décrite dans le paragraphe suivant.

Il existe deux relations de modèle entre les tables Flight et Airport. Dans la table Flight, les colonnes DepartureAirport et ArrivalAirport sont liées à la colonne Airport de la table Airport. Dans la conception de schéma en étoile, la table Airport est décrite comme une dimension de rôle actif. Dans ce modèle, les deux rôles sont l’aéroport de départ et l’aéroport d’arrivée .

Bien que cette conception fonctionne bien pour les conceptions de schémas en étoile relationnelle, elle ne fonctionne pas correctement pour les modèles Power BI. Cela est dû au fait que les relations de modèle sont des chemins de propagation du filtre, et que ces chemins doivent être déterministes. Pour plus d’informations sur la manière de s’assurer que les chemins de propagation de filtre sont déterministes, consultez résolution de l’ambiguïté des chemins de relation. Par conséquent, comme présenté dans cet exemple, une relation est active tandis que l’autre est inactive (représentée par la ligne en pointillés). Plus précisément, il s’agit de la relation avec la colonne ArrivalAirport active, ce qui signifie que les filtres appliqués à la table Airport se propagent automatiquement à la colonne ArrivalAirport de la table Flight.

Cette conception de modèle impose des limitations graves sur la façon dont les données peuvent être signalées. Plus précisément, il n’est pas possible de filtrer la table Airport pour isoler automatiquement les détails de vol d’un aéroport de départ. Comme les rapports doivent filtrer (ou regrouper) par départ et par aéroport d’arrivée en même temps, deux relations actives sont requises. La traduction de cette exigence en conception de modèle Power BI signifie que le modèle doit avoir deux tables d’aéroport.

Voici la conception améliorée du modèle.

Diagramme montrant un modèle contenant quatre tables : Date, Vol, Aéroport de départ et Aéroport d’arrivée.

Le modèle a maintenant deux tables d’aéroport : Departure Airport et Arrival Airport. Chaque relation de modèle entre ces tables et la table Flight est active. Notez également que les noms de colonnes dans les tables Departure Airport et Arrival Airport sont précédés du mot Départ ou Arrivée .

La conception améliorée du modèle permet d'élaborer la conception du rapport suivant.

Diagramme montrant une page de rapport avec deux segments et un visuel de table. Les segments sont Mois et Aéroport de départ.

La page de rapport filtre par Melbourne comme aéroport de départ, et les groupes de visuels de table filtrent par aéroports d’arrivée.

Note

Pour les modèles d’importation, l’ajout d’une autre table de dimension a entraîné une augmentation de la taille du modèle et des temps d’actualisation plus longs. Par conséquent, elle contredit les recommandations décrites dans l'article Techniques de réduction des données pour la modélisation des importations. Toutefois, dans l’exemple, la nécessité d’avoir uniquement des relations actives remplace ces recommandations.

En outre, il est courant que les tables de dimension stockent un faible nombre de lignes par rapport à celui des tables de faits. Par conséquent, la taille et les heures d’actualisation accrues du modèle ne sont pas susceptibles d’être excessivement importantes.

Méthodologie de refactorisation

Voici une méthodologie permettant de réorganiser un modèle d'une table de dimension unique pour les jeux de rôles, vers une conception avec une table par rôle.

  1. Supprimez les relations inactives.

  2. Envisagez de renommer la table de dimension de rôle actif pour mieux décrire son rôle. Dans l’exemple de cet article, la table Airport est liée à la colonne ArrivalAirport de la table Flight. Elle est donc renommée Arrival Airport.

  3. Créez une copie de la table de jeu de rôles, en lui fournissant un nom qui reflète son rôle. S’il s’agit d’une table Import, nous vous recommandons de créer une table calculée. S’il s’agit d’une table DirectQuery, vous pouvez dupliquer la requête Power Query.

    Dans l’exemple, la table Departure Airport a été créée à l’aide de la définition de table calculée suivante.

    Departure Airport = 'Arrival Airport'

  4. Créez une relation active pour associer la nouvelle table.

  5. Envisagez de renommer les colonnes des tables afin qu’elles reflètent précisément leur rôle. Dans l’exemple de cet article, toutes les colonnes sont précédées du mot Départ ou d’arrivée. Ces noms garantissent que, par défaut, les visuels du rapport auront des étiquettes autodescriptives et non ambiguës. Il améliore également l’expérience Q&A, ce qui permet aux utilisateurs d’écrire facilement des questions précises.

  6. Envisagez d’ajouter des descriptions aux tables de jeu de rôle. (Dans le volet Données, une description apparaît dans une info-bulle lorsqu’un auteur de rapport pointe son curseur sur la table.) De cette façon, vous pouvez communiquer d’autres détails de propagation de filtre aux auteurs de rapports.

Relations inactives

Dans certaines circonstances, les relations inactives peuvent répondre à des besoins spécifiques en matière de création de rapports.

Tenez compte des différentes exigences de modèle et de création de rapports :

  • Un modèle de vente contient une table Sales qui a deux colonnes de date : OrderDate et ShipDate.
  • Chaque ligne de la table Sales enregistre un ordre unique.
  • Les filtres de date sont presque toujours appliqués à la colonne OrderDate, qui stocke toujours une date valide.
  • Une seule mesure nécessite la propagation du filtre de date vers la colonne ShipDate, qui peut contenir des BLANK (jusqu’à ce que la commande soit livrée).
  • Il n’est pas nécessaire de filtrer simultanément (ou regrouper) les périodes de dates d’expédition des commandes et.

Voici un diagramme de modèle partiel des deux tables.

Diagramme montrant un modèle contenant deux tables : Sales and Date. La table Sales comprend six mesures.

Il existe deux relations de modèle entre les tables Sales et Date. Dans la table Sales, les colonnes OrderDate et ShipDate sont liées à la colonne Date de la table Date. Dans ce modèle, les deux rôles de la table Date sont date de commande et date d’expédition. C'est la relation avec la colonne OrderDate qui est active.

Toutes les six mesures, à l’exception d’une, doivent être filtrées par la colonne OrderDate. Toutefois, la mesure Orders Shipped doit être filtrée par la colonne ShipDate.

Voici la définition de mesure Orders. Il compte simplement les lignes de la table Sales dans le contexte de filtre. Tous les filtres appliqués à la table Date se propagent à la colonne OrderDate.

Orders = COUNTROWS(Sales)

Voici la définition de mesure Orders Shipped. La fonction DAX USERELATIONSHIP est utilisée pour activer la propagation des filtres pour une relation spécifique, mais uniquement pendant l’évaluation de l’expression. Dans cet exemple, la relation avec la colonne ShipDate est utilisée.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Cette conception de modèle prend en charge la production du rapport suivant.

Diagramme montrant une page de rapport avec un seul segment et un visuel de table. Le segment est Trimestre et le visuel de table liste les statistiques des ventes mensuelles.

La page du rapport est filtrée par trimestre 2019 Q4. Les visuels de table sont regroupés par mois et affichent différentes statistiques de ventes. Les mesures Orders et Orders Shipped produisent des résultats différents. Ils utilisent chacun la même logique de synthèse (compter les lignes de la table Sales), mais une propagation différente du filtre de la table Date.

Notez que le segment trimestre comprend une option VIDE. Cette option de segment s’affiche à la suite de l'expansion de table. Bien que chaque ligne de la table Sales ait une date de commande valide, certaines lignes ont une date d’expédition VIDE. Ces commandes n’ont pas encore été expédiées. L’expansion de table prend également en compte les relations inactives. Des VIDES peuvent donc apparaître en raison des VIDES du côté « plusieurs » de la relation (ou en raison de problèmes d’intégrité des données).

Note

Les filtres de sécurité au niveau des lignes (RLS) se propagent uniquement par le biais de relations actives. Les filtres RLS ne se propagent jamais pour les relations inactives, même lorsque la fonction USERELATIONSHIP DAX est utilisée par une définition de mesure.

Recommandations

Nous vous recommandons de définir des relations actives dans la mesure du possible, en particulier lorsque les rôles RLS sont définis pour votre modèle de données. Ils élargissent l’étendue et le potentiel de l’utilisation de votre modèle par les auteurs de rapports et les utilisateurs travaillant avec Q&A. Cela signifie que les tables de dimension de rôle actif doivent être dupliquées dans votre modèle.

Toutefois, dans des circonstances spécifiques, vous pouvez définir une ou plusieurs relations inactives pour une table de dimension de rôle actif. Vous pouvez envisager cette approche quand :

  • Il n’est pas obligatoire que les visuels de rapport filtrent simultanément par différents rôles.
  • Vous utilisez la fonction USERELATIONSHIP DAX pour activer une relation spécifique pour les calculs de modèle pertinents.

Contenu connexe

Pour plus d’informations sur cet article, consultez les ressources suivantes :