Dans cette conférence, je souhaite aborder
certaines approches courantes de modélisation des données dans Power BI,
particulier les schémas Store et Snowflake.
Avec ces deux approches,
il est important de classer
vos tables en tant que dimension ou fait.
Qu'est-ce qu'un tableau de dimensions ou de facteurs ?
Permettez-moi de commencer par le tableau des dimensions.
Les tables de dimensions stockent des attributs,
également appelés dimensions.
Ces dimensions sont utilisées pour
décrire les objets dans un tableau de faits.
Les tables de faits stockent des observations ou des événements.
Ainsi, dans notre exemple,
il s'agirait de la position finale dans
laquelle le pilote a terminé chaque course,
ou du nombre de points qu'il a marqués, etc.
Une table de faits contient des colonnes de clés de dimension
qui se rapportent aux tables de dimensions.
Il contient également des colonnes numériques
qui peuvent être résumées.
Ces colonnes sont également appelées mesures.
À l'écran, nous avons quatre tables.
Vous pouvez voir le nom de la table en haut,
suivi de toutes les colonnes constituées par
la table.
Alors pourquoi ne pas faire une pause et essayer de déterminer si
chaque table est une table de faits ou de dimensions ?
OK ?
Laissez-moi donc classer chaque table.
Eh bien, le tableau des résultats
contient des colonnes qui peuvent être utilisées comme clés,
telles que l'ID du constructeur,
ID du pilote et le CD ray.
Mais il contient également des mesures et des
observations telles que
le nombre de points marqués et la position d'arrivée.
Il s'agit donc d'un tableau de faits.
Les autres tables contiennent des attributs descriptifs.
Par exemple, le nom du Grand Prix, le nom du circuit
ou la référence du circuit,
ou la date de naissance et la nationalité du conducteur.
Les autres tables sont donc toutes des tables de dimensions.
Dans de nombreux cas, lorsque vous recevez des informations,
vous devrez peut-être effectuer certaines transformations
vous-même pour déplacer des colonnes
entre les différentes tables à l'aide d'opérations telles que la
fusion,
dont je parlerai lors des prochaines conférences.
Cela vous permet de disposer de tables contenant des
attributs et peuvent donc être des tables de dimensions.
Et vous avez également des tables contenant des mesures,
et elles peuvent être des tables de faits.
Vous pouvez ensuite créer des relations
entre ces tables avec les colonnes communes,
comme nous l'avons fait dans notre modèle de données.
Pourquoi nos données sommes-nous divisées entre plusieurs tables ?
Eh bien, nous pourrions avoir toutes nos données dans une seule table,
mais cela serait inefficace
et entraînerait une redondance des données.
Laissez-moi illustrer.
Supposons que nous ayons des données sur les employés
dans le tableau ici.
Nous avons l'identifiant de l'employé, le nom,
le salaire,
puis l' identifiant du département et le nom du département.
En regardant ce tableau,
vous pouvez constater qu'il y a beaucoup d'employés qui ont
les mêmes services qui répétaient des informations.
Toutes ces informations utilisent un espace de stockage supplémentaire.
Maintenant, si nous divisons les tables,
nous avons donc une autre table qui ne
contient que les informations du département,
nous avons moins de répétitions.
Maintenant, nous avons juste l'identifiant du département dans
le tableau de gauche et nous ne répétons plus
le nom du département plusieurs fois.
Cela peut être plus efficace,
surtout à plus grande échelle lorsque vous disposez de
nombreuses colonnes et de nombreuses données redondantes.
Le processus que je viens de décrire s'appelle la normalisation.
La normalisation consiste à supprimer les données redondantes.
Alors que la dénormalisation est le contraire.
Il combine les données de
plusieurs tables en une seule table.
En règle générale, la normalisation est meilleure
pour le stockage et la dénormalisation
peut être plus efficace lorsque vous effectuez des requêtes
sur votre modèle de données, car la complexité est moindre.
Je peux enfin parler
l'approche de modélisation des schémas en étoile.
Avec un schéma en étoile,
vous avez une table de faits
entourée de tables de dimensions.
La table de faits a des relations avec chaque table de dimensions.
Ce que nous avons à l' écran, c'est un schéma en étoile.
Maintenant, permettez-moi de vous montrer le schéma du floc de neige.
Remarquez donc la table raciste.
À l'heure actuelle. Il ne ressemble pas à
la table raciste de notre modèle de données.
schéma Snowflake ressemblerait à ceci.
Ce que nous avons fait, c'est que nous avons encore plus normalisé la table raciste
pour la diviser en une autre table appelée circuits.
Il s'agit également d'un tableau de dimensions.
Cependant, dans le tableau précédent,
qui utilisait le schéma en étoile,
nous avions des données redondantes.
Avec le schéma Floon de neige.
Il n'y a pas de redondance
et les tables sont entièrement normalisées.
C'est donc la différence entre les
deux approches de modélisation, les
schémas étoile et Snowflake.
n'y a pas de réponse claire à laquelle est la meilleure.
Cela dépend simplement de vos besoins.
Comme les schémas Snowflake ont beaucoup moins de redondance,
ils stockent les tables plus efficacement.
Cependant, elles peuvent également entraîner
requêtes plus lentes car elles ont introduit une complexité accrue.
C'est donc vraiment un compromis.
Et selon votre situation,
vous pouvez juger de la meilleure approche.