Modéliser les tables de dimension (schéma en étoile)

Les dimensions sont les tables descriptives (dim_country, dim_plan, dim_date) que les tables de faits joignent pour les filtrer. Ce skill les construit une fois, proprement, afin que tous les autres modèles les réutilisent au lieu de re-dériver les lookups. Lisez d'abord modeling-warehouse-foundations (les jointures et convertCurrency() s'y trouvent). Catalogue des dimensions courantes : references/dimension-catalog.md ; recettes dans references/posthog/ et references/dbt/.

Schéma en étoile en un coup d'œil

Les faits (événements, charges, éléments de revenu) sont longs, clés et additifs. Les dimensions sont courtes, une ligne par entité, descriptives. Vous modélisez une dimension en trois étapes :

1. Sourcer — d'où viennent les données de dimension ?
   • Télécharger / ensemencer un lookup (pays→région, plan→tier) en CSV (source warehouse ou dbt seed).
   • Synchroniser depuis un système de référence (votre base de données applicative, produits Stripe) en tant que source warehouse.
   • Dériver à partir d'événements (pays distincts observés, propriété de plan observée par personne).
2. Façonner — un SELECT aliasé avec des noms de colonnes propres, une ligne par entité (dédupliquer dur). Enregistrer comme vue ; matérialiser sur une sync_frequency lente (7day/30day) puisque les dimensions changent rarement et sont lues constamment.
3. Attacher — une jointure enregistrée (dimension → table de faits) ou person join (dimension → persons) afin que ses colonnes apparaissent comme champs natifs dans toute requête, filtre ou ventilation. Voir foundations joins-and-dimensions.md.

La devise est déjà une dimension gérée — ne la construisez pas

PostHog fournit les taux de change derrière convertCurrency(from, to, amount, timestamp?) (Open Exchange Rates, historiquement correct). Utilisez-le directement pour toute conversion monétaire. Construisez une dimension devise vous-même dans dbt (qui n'a pas d'équivalent) seulement, ou si vous avez besoin d'un fournisseur de taux que PostHog ne propose pas.

Règles avant de modéliser

1. Une ligne par entité, clé unique. Une dimension avec des clés dupliquées crée silencieusement un fan-out pour chaque fait qu'elle joint. Testez l'unicité (PostHog : vérifier dans la requête de façonnage ; dbt : unique + not_null).
2. Aliaser avec des noms propres, stables — country_code, region, plan_tier. Ces noms deviennent la surface de jointure sur laquelle tout le reste dépend.
3. Matérialiser les dimensions statiques sur un calendrier lent ; ne laissez pas un lookup constamment lu virtuel.
4. Enregistrer et certifier. Annoter la dimension et, si elle est critique, la certifier dans le catalogue (foundations governance.md) afin que d'autres modèles la découvrent et ne construisent pas une copie rivale.
5. Préférer la devise intégrée (convertCurrency) à une table FX bricolée sur PostHog.

La construire

PostHog : façonner une vue de dimension aliasée, puis matérialiser + joindre. Recettes : references/posthog/dim_country.sql (dériver + enrichir à partir d'événements), dim_plan.sql (pattern lookup/upload).

dbt : modèles dim_* conformés avec tests unique/not_null/relationships, plus une dim_date générée. Recettes : references/dbt/.

Carte des fichiers

Compléments

modeling-warehouse-foundations (jointures + devise), setting-up-a-data-warehouse-source / suggesting-data-imports (synchroniser/télécharger les données source), et les modèles qui consomment ces dimensions : modeling-revenue-metrics, modeling-conversion-metrics, modeling-activation-metrics, modeling-product-usage-metrics.