Vue d'ensemble
Architecture du Store
Flux général
Le flux cible est:
Sources
->
Interfaces et staging
->
Marts Kimball par vertical métier
->
Couche reporting dénormalisée
->
Power BI
Cette architecture est volontairement hybride. Les marts gardent une logique Kimball pour stabiliser les concepts métier. La couche de reporting prépare des tables larges, aplaties et pré-calculées pour simplifier Power BI.
Rôle des couches
| Couche | Rôle principal |
|---|---|
| Interfaces et staging | Lire les sources, sélectionner, renommer et normaliser les colonnes. |
| Marts | Stabiliser les faits, dimensions, grains et définitions métier réutilisables. |
| Reporting | Préparer les tables finales, souvent dénormalisées, attendues par les dashboards. |
| Power BI | Présenter les données, filtrer, naviguer et interagir avec l'utilisateur. |
Principe directeur
La logique métier lourde doit être calculée en SQL/dbt, dans une couche versionnée et testable. Power BI doit rester une couche de présentation.
SQL/dbt calcule
Power BI présente
Page à lire
La page Marts et couche reporting explique le rôle de chaque couche, les différences entre Kimball et OBT, et la règle de promotion des métriques.
Exécuter l'ETL
dbt contient un orchestrateur intégré qui permet d'exécuter l'ETL. Seuls les modèles activés avec la syntaxe +enabled: true seront exécutés. Comme tous les modèles sont désactivés par défaut, seuls les modèles ou dashboards que vous activez manuellement seront exécutés.
Marts et couche reporting
Le Store ne demande pas à Power BI d'être l'entrepôt analytique.