Marts et couche reporting
Marts et couche reporting
Le Store ne demande pas à Power BI d'être l'entrepôt analytique.
La séparation est la suivante:
Marts
= vérité analytique gouvernée
Couche reporting
= tables de service pour Power BI
Les deux couches peuvent être construites en SQL/dbt, mais elles n'ont pas le même rôle.
Marts: la vérité analytique
Un mart est la couche où les concepts métier sont stabilisés.
Il sert à définir une information une fois, avec un grain clair, des clés stables et des dimensions réutilisables. Une table de mart doit pouvoir servir plusieurs usages, plusieurs pages ou plusieurs dashboards.
Un mart contient typiquement:
faits au grain explicite
dimensions conformes
clés stables
définitions métier propres
historisation maîtrisée
indicateurs réutilisables
Exemples:
fact_resultats_examens
dim_ecole
dim_date
dim_eleve
dim_matiere
fact_absences_personnel
dim_ecole
dim_date
dim_personnel
dim_corps_emploi
fact_sondages
dim_ecole
dim_campagne
dim_theme
dim_population
Le mart répond à des questions comme:
Quel est le grain officiel de cette donnée?
Quelle dimension école doit être utilisée?
Comment définit-on une absence?
Quelle est la définition stable du taux de réussite?
Cette métrique doit-elle être réutilisable par plusieurs rapports?
Le mart ne devrait pas contenir une table simplement parce qu'elle est pratique pour une page Power BI. Il doit porter les définitions qui méritent d'être gouvernées.
Reporting: la couche de service Power BI
La couche de reporting prépare les tables finales consommées par les dashboards.
Elle peut être volontairement dénormalisée. Une table de reporting peut répéter des libellés, embarquer des seuils, précalculer des variations et exposer directement les colonnes nécessaires à une page Power BI.
Elle contient typiquement:
tables larges
one-big-tables
sorties préagrégées
valeurs calculées
variations
statuts
libellés
seuils
rangs
scores
indicateurs composites
colonnes de tri ou d'affichage
La couche de reporting répond à des questions comme:
De quelles colonnes cette page Power BI a-t-elle besoin?
Quels calculs doivent être prêts avant l'ouverture du rapport?
Quels libellés, statuts ou seuils doivent être affichés?
Quelle table rend le modèle Power BI plus simple?
Le but n'est pas de faire du Kimball pur dans Power BI. Le but est de livrer à Power BI des tables faciles à utiliser, pré-calculées et stables du point de vue du rapport.
Différence entre les deux couches
| Question | Mart | Reporting |
|---|---|---|
| Rôle | Gouverner la vérité analytique. | Servir un ou plusieurs rapports Power BI. |
| Modèle | Kimball: faits, dimensions, grain explicite. | OBT, tables larges, sorties préagrégées. |
| Réutilisation | Pensé pour plusieurs usages. | Pensé pour un usage de restitution. |
| Grain | Strict et documenté. | Adapté au besoin du visuel ou du rapport. |
| Calculs | Définitions métier canoniques. | Calculs de restitution, statuts, variations, seuils. |
| Consommateur | Autres modèles dbt, autres dashboards, analyses. | Power BI. |
| Risque à éviter | Trop de logique locale ou de colonnes de présentation. | Devenir une deuxième vérité métier. |
Kimball et OBT ne s'opposent pas ici
Dans cette architecture, Kimball et OBT ne sont pas deux choix concurrents.
Ils répondent à deux moments différents du flux:
Kimball en amont
-> gouvernance, cohérence, réutilisation
OBT en aval
-> simplicité Power BI, performance, lisibilité
Une OBT de reporting est acceptable lorsqu'elle est alimentée par des marts propres et qu'elle ne redéfinit pas silencieusement les concepts métier.
Règle de promotion
Une information peut commencer dans la couche de reporting si elle sert un besoin local.
Elle doit être promue vers un mart lorsqu'elle devient réutilisée, stable ou structurante.
Information utilisée par un seul dashboard
-> reste dans reporting
Information utilisée par plusieurs dashboards
-> candidat pour un mart
Information transversale, stratégique ou gouvernée
-> doit être dans un mart
Cette règle évite que la couche de reporting devienne une deuxième vérité métier.
Exemples de promotion
Ces métriques peuvent commencer dans un rapport, mais devraient être promues si elles deviennent communes:
taux d'absentéisme normalisé
indice de climat par école
score de risque RH
taux de réussite ajusté
ratio ressources / résultats
statut de performance institutionnel
La question à poser n'est pas seulement: "Cette métrique est-elle utile?"
La bonne question est:
Cette métrique doit-elle devenir une définition commune du Store?
Tables de filtres par grain
Pour Power BI, la couche de reporting peut exposer des tables de filtres adaptées au grain du domaine ou du rapport.
Exemples:
filter_ecole_annee
filter_sondage_theme_population
filter_resultat_matiere_niveau
filter_rh_ecole_corps_emploi
Ces tables servent à synchroniser les filtres entre les pages, contrôler les combinaisons valides et éviter de répéter les mêmes colonnes de filtre partout.
Le principe est de créer des filter spines par grain plutôt qu'une table de filtres universelle qui mélange tous les domaines.
Rôle attendu de Power BI
Power BI doit principalement:
afficher
filtrer
naviguer
mettre en forme
gérer l'interaction utilisateur
Power BI ne devrait pas porter la logique métier lourde lorsque cette logique peut être calculée en SQL/dbt.
Cela limite:
les définitions divergentes entre rapports
la logique cachée dans les mesures DAX
les calculs difficiles à tester
la dépendance au modèle sémantique Power BI
Doctrine
La doctrine peut se résumer ainsi:
Les marts constituent la couche analytique canonique, organisée selon une modélisation Kimball par vertical métier. La couche Power BI ne porte pas la logique métier lourde. Elle consomme des tables de reporting dénormalisées, pré-calculées en SQL, et reliées à des tables de filtres par grain. Les métriques qui deviennent réutilisables ou structurantes sont progressivement promues vers les marts canoniques.