MODULE : 3 MODÉLISER DES DONNÉES AVEC POWER BI
La modélisation des données configure et met en forme vos données préparées pour
concevoir un modèle sémantique avec les relations et calculs nécessaires à l’aide de DAX
(Data Analysis Expressions). Ce processus garantit une analyse précise et vous permet de
créer des états Power BI clairs et impactant.
Leçon : 1 Présentation
Cette leçon explique comment concevoir un modèle sémantique, à savoir la tâche que
vous entreprenez en tant que modélisateur de données après avoir appliqué vos requêtes
Power Query. À ce stade de votre développement, vous disposez d’un modèle comprenant
une ou éventuellement plusieurs tables, mais il reste encore du travail à faire. Votre objectif
consiste à développer un modèle qui prend en charge les exigences de reporting, et qui est
convivial et intuitif. En substance, vous développez une couche sémantique sur les données.
Vos premiers efforts de conception doivent se concentrer sur la configuration des
relations entre les tables de modèle. Vous pouvez ensuite améliorer la conception du modèle
en définissant les propriétés de table et de colonne et en créant d’autres objets de modèle tels
que des hiérarchies, des mesures et des paramètres.
Notes
Ce module porte sur les conceptions de modèles d’importation. Par conséquent, il ne
couvre pas l’utilisation de différentes infrastructures de modèle telles que DirectQuery et les
modèles composites. En outre, il ne couvre pas les agrégations définies par l’utilisateur, la
Sécurité au niveau des lignes (SNL) ni les tâches de développement qui impliquent l’écriture
de formules DAX (Data Analysis Expressions).
Leçon : 2 Configurer des relations
Lorsque votre modèle comprend plusieurs tables, vous devez vous assurer que des
relations appropriées existent entre les tables. Les relations propagent des filtres appliqués
d’une table de modèle à une autre. Elles continuent à se propager tant qu’il existe un chemin
de relation à suivre, ce qui peut impliquer une propagation à plusieurs tables.
Par exemple, lorsqu’un visuel filtre la colonne Year de la table Date, une relation avec
la table Sales filtre automatiquement cette table afin que les lignes représentant les ventes de
cette année soient résumées. Pour les auteurs d’états, il s’agit d’un comportement normal et
attendu.
Voici un exemple animé qui montre comment les relations propagent les filtres à
d’autres tables :
Configurer les options de chargement des données
Avant d’appliquer vos requêtes Power Query pour charger les données de votre
modèle, vous devez d’abord inspecter les options Power BI Desktop de Chargement des
données et les ajuster si nécessaire.
Plus précisément, vous pouvez activer ou désactiver les paramètres de relation.
Lorsqu’ils sont activés, ces paramètres peuvent importer les relations détectées dans les
données source, mettre à jour ou supprimer les relations lors de l’actualisation des données et
détecter automatiquement les nouvelles relations.
Lorsque les relations ne sont pas créées automatiquement, vous pouvez en créer dans
la fenêtre Gérer les relations ou en basculant vers la vue Modèle.
Parfois, une table n’a pas besoin d’une relation avec une autre table de modèle, ce que
l’on appelle une table déconnectée. Une table déconnectée est utile lorsque vous souhaitez
prendre en charge un scénario de simulation ou des paramètres de champ. Les deux scénarios
sont décrits plus loin dans ce module.
Notes
Pour obtenir une explication complète des relations de modèle et des liens vers des articles de
conseils associés, consultez Relations de modèle dans Power BI Desktop.
Colonnes
Chaque relation se compose d’une seule colonne « De » et d’une seule colonne « À ».
Il est important que les types de données de ces colonnes soient identiques (ou équivalents) et
qu’elles comportent des valeurs correspondantes.
Vous devez prendre en compte les relations dont votre modèle a besoin lors de la
définition des structures de table dans Power Query. Pour prendre en charge le côté « un »
d’une relation (décrit ci-dessous), vous devez vous assurer que la colonne comporte des
valeurs uniques. De plus, si votre source de données dispose d’une clé à plusieurs colonnes,
vous devez transformer les données pour produire des clés à une seule colonne pour les tables
associées. Si les types de données de colonne associés ne correspondent pas, vous pouvez
ajuster les types de données avec Power Query.
Comprendre la cardinalité
Chaque relation a un type de cardinalité, à savoir l’un des suivants :
Un-à-plusieurs (1:*)
Plusieurs-à-un (*:1)
Un à un (1:1)
Plusieurs-à-plusieurs (*:*)
Lorsque Power BI Desktop crée automatiquement une relation, il détermine la
cardinalité en fonction des valeurs déjà chargées dans les colonnes. Parfois, il peut ne pas la
définir correctement (car la table n’a pas encore été chargée avec des lignes de données).
Vous devez donc mettre à jour le paramètre.
Les relations Un-à-plusieurs et Plusieurs-à-un sont essentiellement les mêmes, mais
dans des directions différentes. Ce sont les types de cardinalité les plus couramment définis,
prenant généralement en charge les relations entre les tables dimensionnelles (le côté « un »)
et les tables de faits (le côté « plusieurs ») dans une conception de schéma en étoile.
Par exemple, la colonne Product Key de la table Product a une relation un-à-plusieurs
avec la colonne Product Key de la table Sales.
Notes
Les captures d’écran des diagrammes de modèles de cette unité présentent uniquement les
colonnes utilisées dans les relations.
La cardinalité un-à-un vous permet d’associer deux tables qui ont chacune une
colonne unique. Ce type de relation n’est pas courant, car il est recommandé de fusionner des
requêtes à l’aide de Power Query pour produire une table de modèle unique. Ainsi, vous
réduisez le nombre de tables de modèle et offrez une expérience plus intuitive aux auteurs
d’états, qui peuvent rechercher des champs associés dans une seule table.
Prenons l’exemple d’un scénario dans lequel une table Product Cost comporte la
colonne Cost Price provenant d’un magasin de données supplémentaire. Sa colonne SKU
comporte l’unité de gestion de stock (SKU) du produit. Lorsqu’une relation est créée avec la
table Product sur la colonne Product Key, une relation un-à-un est établi, car les deux
colonnes comportent des valeurs uniques.
Dans un deuxième scénario, le modélisateur adopte une approche différente. Il
fusionne les requêtes Power Query et ajoute la colonne Cost Price à la requête Product. Il
désactive ensuite le chargement de la requête Cost Price. Il n’en résulte qu’une seule table
Product.
La cardinalité plusieurs-à-plusieurs vous permet de configurer des relations
complexes entre des tables de modèle. Elle est utile en l’absence d’une colonne de valeurs
uniques. Par exemple, la table Target stocke les faits au niveau de la catégorie de produits,
mais la table Product stocke les produits au niveau de la SKU de produit. Alors que la colonne
Product Key stocke la SKU, la colonne Category stocke le nom de la catégorie, dont il existe de
nombreux doublons. Lorsque vous associez la colonne Category de la table Product à la colonne
Category de la table Target, la cardinalité doit être définie sur Plusieurs-à-plusieurs. Dans ce
cas, cela permet d’associer une table dimensionnelle à une table de faits à un niveau ou une
granularité supérieur(e).
Comprendre la direction du filtre croisé
Une relation de modèle est définie avec une direction de filtre croisé. La direction
détermine la façon dont les filtres se propagent. Lorsqu’il y a un côté « un », les filtres se
propagent toujours de l’autre côté. Lorsqu’il y a un côté « plusieurs », il est également
possible d’autoriser la propagation à l’autre côté.
Les options de filtrage croisé possibles dépendent du type de cardinalité de la relation :
Un-à-plusieurs (ou Plusieurs-à-un) : unique ou les deux
Un-à-un : les deux
Plusieurs-à-plusieurs : unique vers chacune des tables ou les deux
En général, il est recommandé d’éviter les filtres croisés dans les deux sens ou d’en
réduire le nombre. En effet, cela se traduit par de meilleures performances des requêtes et
produit généralement une expérience intuitive pour les utilisateurs d’états.
Une raison valable pour autoriser le filtrage croisé d’une relation un-à-plusieurs dans
les deux sens est de permettre une analyse plusieurs-à-plusieurs entre deux tables
dimensionnelles. Prenons un exemple où des vendeurs sont affectés à plusieurs régions et
inversement, plusieurs vendeurs peuvent être affectés à des régions. Pour implémenter cette
conception, votre modèle a besoin d’une table de pontage associant des vendeurs et des
régions.
La capture d’écran suivante illustre un diagramme de modèle qui relie la table Sales
Person à la table Sales. La table Sales person Region, qui est une table de pointage, comporte les
colonnes Employée Key et Sales Territory Key, dont aucune ne comporte de valeurs uniques.
Notez comment fonctionne la propagation du filtre :
1. Les filtres appliqués à la table Sales Person se propagent à la table Sales person Region.
2. Les filtres appliqués à la table Sales person Region se propagent à la table Region, car le
filtrage croisé est pris en charge dans les deux sens.
3. Les filtres appliqués à la table Region se propagent à la table Sales.
Relations actives et relations inactives
Il ne peut y avoir qu’un seul chemin de propagation de filtre actif entre deux tables de
modèle. Cependant, il est possible d’introduire d’autres chemins de relation, mais vous devez
définir ces relations comme inactives. Les relations inactives peuvent être activées
uniquement lors de l’évaluation d’un calcul de modèle à l’aide de la fonction DAX
USERELATIONSHIP.
Il est assez courant qu’il existe plusieurs relations avec une table dimensionnelle, ce
que l’on appelle une dimension de rôle actif. Par exemple, supposons que la table Sales
comporte deux colonnes de date : OrderDate et ShipDate. Cependant, si vous associez les deux
colonnes à la table Date, une seule relation peut être active.
Pour permettre le filtrage simultané par date de commande, date d’expédition ou les
deux, vous avez besoin de deux tables de dates. En créant les tables Order Date et Ship Date,
chacune peut avoir des relations actives avec la table Sales.
La capture d’écran suivante compare deux scénarios de conception de modèle. Le
premier scénario montre une seule table de dates avec une relation active et une relation
inactive. Le deuxième scénario montre deux tables de dates, chacune avec des relations
actives. (Les relations actives sont représentées par des lignes continues ; les relations
inactives sont représentées par des traits en pointillé.)
Utiliser le diagramme du modèle
Dans le diagramme du modèle, les relations sont représentées par les lignes qui connectent
les tables.
Un moyen simple de créer une relation consiste à glisser-déplacer des colonnes entre
les tables du diagramme du modèle. Un moyen simple de modifier une relation consiste à
double-cliquer dessus.
Vous pouvez interpréter les propriétés d’une relation en l’affichant dans le diagramme du
modèle :
La cardinalité d’une relation est décrite par les icônes « un » (1) ou « plusieurs » (*)
situées aux extrémités de la ligne de relation.
Le sens du filtre croisé d’une relation est décrit par les flèches situées au milieu de la
ligne de relation.
Une relation active est une ligne continue ; une relation inactive est un trait en pointillé.
Pour déterminer les colonnes associées, vous pouvez survoler la relation pour les mettre en
surbrillance.
Leçon : 3 Configurer des tables
Vous êtes prêt à améliorer sa conception lorsque votre modèle comporte les tables et
colonnes requises et que les relations sont configurées. Vous améliorez le modèle en
définissant les propriétés des objets de modèle, comme les tables et les colonnes. Vous
pouvez également créer des objets de modèle tels que des hiérarchies, des mesures et des
paramètres.
Configurer les propriétés de table
Power BI Desktop vous offre plusieurs choix lors de la création d’objets de modèle et
de la définition de leurs propriétés. Vous pouvez utiliser le ruban, le volet Données ou le
diagramme du modèle et son volet Propriétés associé. En général, il est plus facile de
travailler dans la vue Modèle et d’utiliser le volet Propriétés, car il prend en charge la
sélection multiple et les mises à jour de propriétés en bloc.
Chaque table de modèle comporte une propriété Nom qui vous permet de la
renommer. Son nom est toujours hérité du nom de la requête Power Query. Par conséquent, si
vous renommez une table dans Power BI Desktop, le nom Power Query est mis à jour. Les
noms des tables de modèle doivent être uniques dans le modèle et vous devez vous efforcer
de définir des noms conviviaux.
Une table de modèle comporte également une propriété Description, qui est
facultative. Elle vous permet de définir une définition détaillée de la table qui s’affiche
lorsque les auteurs d’états survolent la table dans le volet Données.
La propriété Synonymes vous permet de définir un ou plusieurs autres noms pour la
table, afin que Questions et réponses ou Copilot puisse mieux comprendre et résoudre les
requêtes relatives à la génération automatique de visuels ou de formules DAX.
Une table de modèle peut être masquée, auquel cas elle n’est pas répertoriée dans le
volet Données (sauf si l’auteur de l’état souhaite expressément que les objets masqués
s’affichent). Vous devez masquer les objets de modèle qui ne doivent pas être utilisés
directement par les auteurs d’états. Par exemple, vous devez masquer une table de pointage
permettant de prendre en charge une relation plusieurs-à-plusieurs entre des tables
dimensionnelles, comme la table Sales personRegion décrite dans l’unité précédente.
Marquer des tables de dates
Par défaut, Power BI comprend une fonctionnalité Date/heure automatique pour
prendre en charge l'assistant Time Intelligence. Lorsqu’elle est activée, elle crée des tables de
dates masquées pour chaque colonne dont le type de données est Date ou Date/Heure.
Bien que cette option puisse être utile pour les modélisateurs de données novices ou
pour l’expérimentation, il est préférable de la désactiver. Vous pouvez utiliser une table de
données source existante ou créer une table calculée avec DAX. Chaque table de dates de
votre modèle doit comporter une colonne de dates et être marquée comme table de dates.
Ainsi, les fonctions Time Intelligence DAX renvoient des résultats appropriés.
Le marquage d’une table de dates implique de sélectionner la colonne comportant des
valeurs de date.
Power BI Desktop effectue des vérifications pour s’assurer que la colonne de dates
que vous sélectionnez comporte des valeurs uniques, ne comporte aucune valeur BLANK et
comprend des valeurs contiguës du début à la fin.
Leçon : 4 Configurer des colonnes
Vous pouvez définir de nombreuses propriétés de colonne. Comme pour les tables, vous
pouvez définir le nom, la description, les synonymes et les propriétés « est masquée ». Il est
courant de masquer les colonnes utilisées par les relations, en particulier lorsqu’elles sont
basées sur des valeurs de clé non significatives.
Les noms de colonne doivent être uniques au sein de la table de modèle et, si la colonne
est visible, vous devez définir un nom convivial. Si vous modifiez le nom de la colonne dans
Power BI Desktop, une nouvelle étape est ajoutée à la requête Power Query pour y modifier
le nom de la colonne.
Vous pouvez affecter des colonnes à un dossier d’affichage, ce qui permet d’organiser les
champs d’une table. Envisagez d’utiliser des dossiers d’affichage lorsque votre table
comprend de nombreux champs visibles.
Configurer la mise en forme des colonnes
Chaque colonne possède une propriété Type de données, héritée de la requête Power Query.
Elle concerne la façon dont les valeurs sont stockées. Si vous modifiez le type de données
dans Power BI Desktop, une nouvelle étape est ajoutée à la requête pour y modifier le type de
données.
La propriété Format est liée, bien que différente. Cette propriété concerne la façon dont les
valeurs sont présentées dans les visuels. Par exemple, une colonne avec un type de données
Nombre décimal fixe peut être mise au format devise.
Définir l’ordre du tri
Parfois, l’ordre naturel des valeurs de colonne ne répond pas à vos besoins. Les valeurs de
texte sont triées naturellement par ordre alphabétique, tandis que les nombres et les dates sont
triés naturellement du plus petit (ou ancien) au plus grand (ou plus récent). Lorsque vous avez
besoin que les valeurs soient triées différemment, vous pouvez vous référer à une colonne de
la même table qui comporte des valeurs adaptées au tri de la colonne.
Par exemple, dans la table Date, la colonne Month comporte le nom anglais des mois, par
exemple 2017 Aug (pour août 2017). L’ordre de tri naturel donne les mois classés par ordre
alphabétique, et non chronologique (auquel cas août est classé avant tous les autres mois).
Dans ce cas, vous pouvez ajouter la colonne MonthKey à la table, qui stocke une valeur
numérique comprenant le numéro de l’année et le numéro du mois.
Vous pouvez ensuite définir la propriété Trier par colonne de la colonne Month pour utiliser
la colonne MonthKey. Ensuite, vous devez masquer la colonne MonthKey, car elle ne doit
pas être utilisée directement par les auteurs d’états.
Catégoriser les données
Vous pouvez définir la propriété Catégorie de données pour décrire le contenu d’une colonne.
La définition de cette propriété est particulièrement utile lorsqu’une colonne stocke une
valeur spatiale, soit sous forme de texte, soit sous forme de latitude ou longitude décimale.
Les colonnes classées avec une valeur spatiale s’affichent dans le volet Données avec une
icône spatiale et Power BI peut géocoder et visualiser plus précisément les données
lorsqu’elles sont utilisées dans des visuels cartographiques.
Vous pouvez également classer les colonnes comportant une URL.
Si l’URL comporte un lien web général, définissez la propriété Catégorie de données sur
URL web. En cas d’utilisation dans un visuel Table ou Matrice, l’auteur de l’état peut
configurer les options de format pour condenser l’URL en une icône de lien compacte et
facilement reconnaissable.
Si l’URL comporte un lien vers une image, définissez la propriété sur URL d’image. En cas
d’utilisation dans un visuel Table, Matrice, Segment ou Carte multiligne, l’auteur de l’état
peut configurer les options de format pour afficher les images.
Définir le résumé
Vous pouvez définir la propriété Résumer par pour les colonnes numériques afin de
déterminer comment elles résument (ou non) par défaut. Les options sont Sum, Min, Max,
Average, Count et Discount Count (ou Aucun).
Les colonnes récapitulatives s’affichent dans le volet Données avec un symbole sigma (Ʃ), et
les auteurs d’états peuvent déterminer comment elles sont résumées en cas d’utilisation par
un visuel.
Conseil
Lorsque vous souhaitez contrôler la manière dont les auteurs d’états (ou Questions et
réponses) résument une colonne numérique, créez une mesure (décrite dans une unité
ultérieure) et masquez la colonne.
Leçon : 5 Configurer des hiérarchies
Les hiérarchies sont facultatives. En les créant, vous fournissez des indices aux
auteurs d’états sur les relations entre les colonnes d’une table. Si vous ne créez pas la
hiérarchie, les auteurs d’états peuvent toujours obtenir le même résultat en ajoutant plusieurs
colonnes à un visuel, mais cela implique davantage de connaissances et d’efforts.
Vous pouvez ajouter une ou plusieurs hiérarchies à toute table de modèle. Les niveaux
hiérarchiques doivent être basés sur des colonnes de cette table et fournissent un chemin de
navigation entre ces colonnes.
Par exemple, vous pouvez ajouter une hiérarchie nommée Fiscal à la table Date avec
des niveaux basés sur les colonnes Year, Quarter et Month.
La capture d’écran suivante illustre un visuel Matrice comportant la hiérarchie Fiscal sur ses
lignes :
Comme pour les colonnes de modèle, vous pouvez définir les propriétés de description,
synonyme, dossier d’affichage et « est masquée » pour les hiérarchies.
Leçon : 6 Configurer des mesures
Bien que les auteurs d’états puissent résumer toute colonne dans des visuels Power BI,
ils ne peuvent pas répondre aux exigences de résumé complexes, comme un calcul depuis le
début de l’année (YTD). Dans ce cas, vous devez créer une mesure.
Une mesure est une formule DAX nommée ajoutée à une table de modèle. Elle réalise
un résumé et s’affiche dans le volet Données avec une icône représentant une calculatrice.
Les noms de mesure doivent être uniques au sein du modèle. Les mesures peuvent être
simples, par exemple SUM ou AVERAGE. Les mesures peuvent également être complexes
et effectuer le calcul Sales Amount moins Product Cost pour trouver la valeur Profit.
Ces calculs étendent les données de votre modèle sémantique en fournissant les
calculs essentiels nécessaires à une visualisation efficace des données, vous permettant ainsi
de découvrir des insights et des tendances plus approfondies dans vos données.
Notes
Si le modèle est interrogé à l’aide de Multi-Dimensional Expressions (MDX), ce qui est le
cas lorsque vous utilisez Analyser dans Excel, vous devez également créer des mesures.
Si vous n’avez pas de compétences DAX, vous pouvez générer une mesure basée sur
une invite à l’aide de Copilot pour Power BI. Vous pouvez également utiliser la
fonctionnalité Mesures rapides.
Utiliser des mesures rapides
Les mesures rapides vous permettent de créer une mesure en sélectionnant un modèle
de calcul et en faisant glisser les champs pour le configurer. Power BI Desktop crée ensuite
une mesure basée sur votre configuration.
Comme pour les colonnes de modèle, vous pouvez définir les propriétés de
description, synonyme, dossier d’affichage et « est masquée » pour les mesures. Vous pouvez
également définir les propriétés de mise en forme. La propriété Table principale permet
d’affecter la mesure à toute table de modèle.
Conseil
Vous pouvez également générer automatiquement une valeur de description pour la mesure à
l’aide de Copilot, ce qu’il fait en inspectant la formule DAX. Pour en savoir plus, consultez la
Documentation Copilot pour Power BI.
LEçon : 7 Configurer des paramètres
Un paramètre dans Power BI permet aux utilisateurs de modifier les paramètres d’état,
comme les filtres ou les calculs, sans modifier les données d’origine. Vous pouvez ajouter
deux types de paramètres à votre modèle : Plage numérique et Champs.
Créer un paramètre de plage numérique
Vous définissez un paramètre Plage numérique en définissant un type de données
numérique, des valeurs minimale et maximale, une valeur d’incrémentation et une valeur par
défaut. Power BI Desktop crée ensuite une table calculée à l’aide de DAX. Il crée également
une mesure qui représente la valeur permettant de filtrer la table. La table n’a pas besoin
d’une relation avec une autre table de modèle, créant une table déconnectée.
Un paramètre de plage numérique peut prendre en charge un scénario de simulation,
dans lequel l’utilisateur de l’état filtre la table à l’aide d’un segment et les mesures font
quelque chose de pertinent avec la valeur sélectionnée. Par exemple, un état pourrait
permettre à son utilisateur de définir un taux de change hypothétique. Un visuel d’état
pourrait alors afficher une mesure qui applique le taux de change de manière significative.
Les paramètres s’affichent dans le volet Données avec un symbole de point d’interrogation
(?).
Dans la capture d’écran suivante, la table Exchange Rate est la table calculée et la colonne
Exchange Rate comporte les valeurs de plage numérique. Exchange Rate Value est une
mesure qui renvoie la valeur sélectionnée dans la plage.
Créer un paramètre Champs
Vous pouvez définir un paramètre Champs en créant un groupe de champs différents.
Le champ de paramètres peut ensuite être utilisé dans des visuels et permettre de configurer
un segment. La sélection du segment permet aux utilisateurs d’états de choisir le champ à
visualiser.
Prenons un exemple dans lequel un paramètre Champs nommé Product Grouping comprend
quatre colonnes de la table Product : Category, Subcategory, Product et Color. Lorsque le
paramètre est ajouté à la page d’état, l’utilisateur de l’état peut sélectionner le champ.
L’histogramme correspondant place le champ sélectionné sur son axe des Y.
Exercice : configurer un modèle sémantique dans Power BI
Desktop
Cette unité inclut un laboratoire à effectuer.
Utilisez les ressources gratuites fournies dans le lab pour effectuer les
exercices de cette unité. Vous ne serez pas facturé pour
l’environnement lab; toutefois, vous devrez peut-être apporter votre
propre abonnement selon le labo concerné.
Microsoft fournit cette expérience de laboratoire et le contenu connexe à
des fins éducatives. Toutes les informations présentées sont la propriété
de Microsoft et destinées exclusivement à l'apprentissage des produits et
services couverts dans ce module Microsoft Learn.
Dans cet exercice, vous allez découvrir comment :
créer des relations de modèle ;
configurer des propriétés de table et de colonne ;
créer des hiérarchies.
Ce labo prend environ 45 minutes.
Notes
Une machine virtuelle comportant les outils client nécessaires est fournie,
ainsi que les instructions de l’exercice. Lancez la machine virtuelle à l’aide
du bouton « Lancer le labo ».
Un nombre limité de sessions simultanées est disponible. Si
l’environnement hébergé n’est pas disponible, veuillez réessayer
ultérieurement.
Vous pouvez également ouvrir les instructions dans une fenêtre
distincte.
Accéder à votre environnement
Avant de commencer ce labo (sauf si vous continuez à partir d’un labo
précédent), cliquez sur Lancer le labo ci-dessus.
Vous êtes automatiquement connecté à votre environnement de labo en
tant que data-ai\student.
Vous pouvez maintenant commencer à travailler sur ce labo.
Conseil
Pour ancrer l’environnement du labo afin qu’il remplisse la fenêtre, cliquez
sur l’icône représentant un PC en haut de l’écran, puis sélectionnez
Ajuster la fenêtre à la machine.
Contrôle de vos connaissances
1. Quel type de cardinalité devez-vous définir pour créer une
relation entre une table dimensionnelle et une table de faits ?
Plusieurs-à-plusieurs
Réponse incorrecte. Une table dimensionnelle doit
comporter une colonne clé unique qui constitue le côté un
de la relation.
Un-à-plusieurs
Réponse correcte. Les tables dimensionnelles comportent
une colonne clé unique qui forme le côté « un ». La colonne
clé de dimension de la table de faits stocke les valeurs en
double, donc est le côté « plusieurs ».
Un-à-un
2. Laquelle des affirmations suivantes sur les hiérarchies est vraie
?
Une hiérarchie ordonne les valeurs de colonne.
Réponse incorrecte. Une hiérarchie n’ordonne pas les
valeurs de colonne. Ordonnez les valeurs de colonne à l’aide
de la propriété Trier par colonne.
Au maximum, une seule hiérarchie peut être ajoutée à une table de
modèle.
Les niveaux hiérarchiques doivent être basés sur les colonnes d’une
seule table de modèle.
Réponse correcte. Les niveaux d’une hiérarchie sont
toujours basés sur des colonnes d’une même table de
modèle.
3. Quel type d’objet pouvez-vous ajouter à un modèle pour
résumer des données ?
Hiérarchie
Mesure
Réponse correcte. Une mesure est une formule DAX nommée
qui résume les données d’un modèle.
Paramètre
Conclusion
Dans ce module, vous avez découvert comment développer une couche sémantique sur vos
données.
Tout d’abord, vous avez découvert l’importance des relations de modèle et leur rôle dans la
propagation automatique des filtres à d’autres tables de modèle.
Ensuite, vous avez découvert comment créer et configurer des objets de modèle, notamment
des tables, des colonnes, des hiérarchies, des mesures et des paramètres. Le résultat final est
un modèle convivial et intuitif qui répond à vos besoins de reporting.