Modèle optimisé#

👥 Créée par	Ⓜ Manuella
📅 Date de création	@ 11 novembre 2022
⌗ Difficulté	3
⎊ Etiquette	Vue modèle

Modélisation :

Structure des tables
Disposition des tables (Kimball ou Collie)

Pourquoi il convient de mettre en place un modèle de donnée optimisé :

Warning

Cependant, modèle par défaut ne veut pas dire bon modèle.

Modèle par défaut	Bon modèle
Peut être confus	Clair et lisble
Peut être lent	Optimisé
Peut rendre les calculs compliqués	Simplifie le DAX
Peut générer des frustrations	Améliore l’expérience utilisateur

Modèles de données les plus courants :

Grande table Excel à plat (non optimisé)

id prod	Produit	Catégorie	Client	Ville	Pays	Date	Magasin	Ville	Pays	N° facture	Montant HT	Tva	Montant TTC
<>
<>

Produit#
id prod	Produit	Catégorie
<>
<>

Client#
Client	Ville	Pays
<>
<>

Date#
Date
<>
<>

Magasin#
Magasin	Ville	Pays
<>
<>

Transaction#
N° facture	Montant HT	Tva	Montant TTC
<>
<>

Dans Power Query, les grands ensembles ont pour objectif d’être stocké dans des tables dédiés (i.e produit, client, date et magasin) tandis que les calculs sont stockés dans des mesures.

Base de données relationnelle (non optimisé)

flowchart RL %%Nodes mag[Magasin] pay[Pays] vi1[ \nVille\n\n ] vi2[Ville] cli[Client] prom[Promotion] prd[ \nProduit\n\n ] tabl1[Table des\nfaits 1 :\nlocation]:::class1 tabl2[Table des\nfaits 2 :\nvente]:::class1 %%Workflow mag---vi2 & prd prd---tabl1 & tabl2 vi2---pay pay---vi1 vi1---cli tabl1---cli tabl2---cli & prom %%Styles classDef class1 fill:#F5D5CB

La confusion du point de vue utilisateur est au maximum à cause de la modélisation. Il faut remodéliser dans Power Query ou Dax.

Le modèle en flocon (moyennement optimisé pour PBI)

flowchart LR %%Nodes fil[filière] sect[secteur] soc[ \nSociété\n\n] adr[adresse] clicon[client contact] tabl[ \nTable des\nfaits\n\n]:::class1 date[ \nDate\n\n] prd[produit] cat[catégorie] four[fournisseur] %%Workflow fil---sect sect---soc soc---adr & clicon clicon---tabl tabl---prd & date prd---cat & four %%Styles classDef class1 fill:#F5D5CB

Le modèle en flocon permet de gérer les historiques. Attention, tout de fois, à ne pas avoir trop de tables imbriquées.

Le modèle en étoile (optimisé pour PBI)

classDiagram direction BT transactions "*" <-- "1" Datum transactions "*" <-- "1" Datum transactions "*" <-- "1" produits transactions "*" <-- "1" clients class Datum{ fa:fa-table Année fa:fa-table Année mois fa:fa-table Année Sem ISO fa:fa-table Date fa:fa-table Jour ouvré fa:fa-table Mois } class transactions{ fa:fa-low-vision date de commande fa:fa-low-vision date de livraison fa:fa-low-vision id client fa:fa-low-vision id produit fa:fa-low-vision quantité } class clients{ fa:fa-table code pays client fa:fa-low-vision id client fa:fa-table nom client fa:fa-table pays client fa:fa-table prénom client fa:fa-table ville client } class produits{ fa:fa-table couleur fa:fa-table famille produit fa:fa-low-vision id fournisseur fa:fa-low-vision id produit fa:fa-table nom fournisseur fa:fa-table nom produit fa:fa-table prix unitaire }

Le modèle en étoile (une table des faits au milieu avec des relations directe avec les dimensions).