Introduction
La création d’un bon modèle sémantique est l’une des tâches les plus importantes qu’un analyste de données peut accomplir dans Microsoft Power BI. Si le travail est bien fait, les utilisateurs comprendront plus facilement les données, et la création de rapports Power BI utiles, aussi bien pour eux que pour vous, s’en trouvera facilitée.
Les pages de ce module constituent uniquement des instructions. Aucun fichier de données n’est fourni. Vous avez l’occasion de travailler avec des données réelles dans les labos.
Un bon modèle sémantique offre les avantages suivants :
L’exploration des données est plus rapide.
Les agrégations sont plus simples à générer.
Les rapports sont plus précis.
La génération de rapports prend moins de temps.
Les rapports sont plus faciles à gérer à l’avenir.
Il est difficile de définir les règles d’un bon modèle sémantique, car toutes les données sont différentes et l’utilisation de ces données varie. En général, il est recommandé de créer un petit modèle sémantique parce qu’il s’exécute plus rapidement et qu’il est plus simple à utiliser. Toutefois, il est tout aussi problématique de définir ce qu’implique un petit modèle sémantique car ce concept est heuristique et subjectif.
En général, un petit modèle sémantique présente à l’utilisateur un nombre moins important de tables et de colonnes. Si une base de données de ventes comprend 30 tables et que vous les importez toutes, l’utilisateur ne trouvera pas cela intuitif. En passant à cinq tables, vous rendez le modèle sémantique beaucoup plus convivial pour l’utilisateur. De même, si l’utilisateur ouvre une table et qu’il trouve 100 colonnes, il risque de se sentir débordé. Il y a plus de chances qu’un utilisateur lise tous les noms de colonnes d’une table si vous supprimez les colonnes inutiles. En résumé, vous devez faire preuve de simplicité quand vous concevez des modèles sémantiques.
L’image suivante montre un exemple de modèle sémantique. Les zones contiennent des tables de données où chaque élément de ligne dans la zone est une colonne. Les lignes qui connectent les zones représentent les relations entre les tables. Ces relations peuvent être complexes, même dans le cas d’un modèle simpliste. Le modèle sémantique peut facilement se désorganiser, et le nombre total de tables dans le modèle peut augmenter progressivement. Des efforts constants sont nécessaires pour maintenir un modèle sémantique simple, complet et précis.
Les relations sont définies entre les tables par le biais de clés primaires et étrangères. Les clés primaires sont des colonnes qui identifient chaque ligne de données unique et non-Null. Par exemple, dans une table Customers, vous pouvez avoir un index qui identifie chaque client unique. La première ligne a un ID de 1, la deuxième ligne un ID de 2 et ainsi de suite. Chaque ligne se voit attribuer une valeur unique qui peut être référencée par une valeur simple : la clé primaire. Ce processus devient important quand vous référencez des lignes dans une table différente avec des clés étrangères. Les relations entre les tables sont formées quand des tables différentes ont des clés primaires et étrangères en commun.
Power BI permet de créer des relations à partir de tables avec des sources de données différentes, une fonction puissante qui vous permet d’extraire une table de Microsoft Excel et une autre d’une base de données relationnelle. Vous créez ensuite la relation entre ces deux tables et les traitez comme un modèle sémantique unifié.
Maintenant que vous avez appris les relations qui composent le schéma de données, vous allez explorer un type spécifique de conception de schéma, le schéma en étoile, qui optimise les performances et la convivialité.
Schémas en étoile
Pour simplifier vos données, vous pouvez concevoir un schéma en étoile. Ce schéma n’est pas le seul moyen de simplifier vos données, mais comme il est largement utilisé, chaque analyste de données Power BI doit comprendre son fonctionnement. Dans un schéma en étoile, chaque table de votre modèle sémantique est définie comme une table de dimension ou une table de faits, comme le montre l’illustration suivante.
Les tables de faits contiennent des valeurs d’observation ou des valeurs de données d’événement : commandes client, nombre de produits, prix, dates et heures des transactions et quantités. Les tables de faits peuvent contenir plusieurs valeurs répétées. Par exemple, un produit peut apparaître plusieurs fois dans plusieurs lignes, pour différents clients à des dates différentes. Ces valeurs peuvent être agrégées pour créer des visuels. Par exemple, un visuel du total des commandes est une agrégation de toutes les commandes de la table de faits. Dans les tables de faits, les colonnes sont couramment remplies avec des nombres et des dates. Les nombres peuvent être des unités de mesure, comme un montant de vente, ou bien des clés, comme un ID client. Les dates représentent la valeur de temps qui est enregistrée, comme la date de la commande ou la date d’expédition.
Les tables de dimension contiennent les détails des données contenues dans les tables de faits : produits, emplacements, employés et types de commandes. Ces tables sont connectées à la table de faits par le biais de colonnes clés. Les tables de dimension sont utilisées pour filtrer et regrouper les données dans des tables de faits. Les tables de faits, en revanche, contiennent les données mesurables, comme les ventes et le chiffre d’affaires. Chaque ligne représente une combinaison unique de valeurs des tables de dimension. Pour le visuel des commandes totales, vous pouvez regrouper les données de façon à voir les ventes totales par produit (le produit étant constitué de données dans la table de dimension).
Les tables de faits sont beaucoup plus grandes que les tables de dimension dans la mesure où de nombreux événements se produisent dans ces tables, comme des ventes individuelles. Les tables de dimension sont généralement plus petites, car vous êtes limité au nombre d’éléments que vous pouvez filtrer et regrouper. Par exemple, une année contient un nombre fixe de mois et les États-Unis sont constitués d’un certain nombre d’États.
En tenant compte de ces informations sur les tables de faits et les tables de dimension, vous vous demandez peut-être comment vous pouvez créer ce visuel dans Power BI.
Les données pertinentes se trouvent dans deux tables, Employee et Sales, comme indiqué dans le modèle sémantique suivant. Étant donné que la table Sales contient les valeurs des commandes, lesquelles peuvent être agrégées, elle est considérée comme une table de faits. La table Employés contient le nom des employés, ce qui permet de filtrer les commandes client. Il s’agit donc d’une table de dimension. La colonne commune aux deux tables, qui est la clé primaire de la table Employés, est IDEmployé. Vous pouvez donc établir une relation entre les deux tables en fonction de cette colonne.
Au moment de créer cette relation, vous pouvez générer le visuel en fonction des besoins, comme le montre l’illustration suivante. Si vous n’aviez pas établi cette relation, tout en gardant à l’esprit les caractéristiques communes aux deux tables, vous auriez eu davantage de difficultés à créer votre visuel.
Les schémas en étoile et le modèle sémantique sous-jacent constituent la base des rapports organisés. Plus vous passerez de temps à créer ces connexions et la conception, plus il sera facile de créer et gérer les rapports.