modeling-dimension-tables

ディメンションテーブルのモデリング（スタースキーマ）

ディメンションは、ファクトテーブルがスライスに使う説明用テーブル（dim_country、dim_plan、dim_date）です。このスキルでは、ディメンションを一度きれいに作成し、ほかのすべてのモデルでルックアップを再導出するのではなく再利用できるようにします。まず modeling-warehouse-foundations をお読みください（JOIN と convertCurrency() はそちらで扱います）。一般的なディメンションの一覧は references/dimension-catalog.md、レシピは references/posthog/ と references/dbt/ にあります。

スタースキーマをひと目で

ファクト（イベント、請求、収益項目）は、行数が多く、キーを持ち、加算可能です。ディメンションは行数が少なく、エンティティごとに1行で、説明的な情報を持ちます。ディメンションは次の3つの手順でモデリングします。

1. ソースを決める — ディメンションデータはどこから取得しますか？
   • ルックアップ（国→地域、プラン→ティア）をCSV（ウェアハウスソースまたはdbt seed）として アップロード／シード します。
   • 信頼できる情報源（アプリのDB、Stripe製品）からウェアハウスソースとして 同期 します。
   • イベントから 導出 します（確認された国の一覧、ユーザーごとに観測されたプランプロパティなど）。
2. 形を整える — 列名を整え、エンティティごとに 1行 にした、別名を付けた SELECT を作成します（重複を確実に排除します）。ビューとして保存し、ディメンションはめったに変更されず常に参照されるため、遅い sync_frequency（7day／30day）で マテリアライズ します。
3. 関連付ける — 保存済みJOIN（ディメンション → ファクトテーブル）または ユーザーJOIN（ディメンション → persons）を作成し、あらゆるクエリ、フィルター、ブレークダウンで列をネイティブフィールドとして使えるようにします。基礎編の joins-and-dimensions.md を参照してください。

通貨はすでに管理対象のディメンションです — 作成しないでください

PostHogには、convertCurrency(from, to, amount, timestamp?) による為替レート機能があります（Open Exchange Ratesを使用し、過去のレートにも対応）。金額の換算には直接これを使用してください。独自の通貨ディメンションを作成するのは、同等の機能がない dbt の場合、またはPostHogが提供していないレートプロバイダーが必要な場合に限ります。

モデリング前のルール

1. エンティティごとに1行、一意のキーを使います。 重複キーのあるディメンションを結合すると、すべてのファクトが暗黙のうちにファンアウトします。一意性をテストしてください（PostHog：整形クエリで検証、dbt：unique と not_null）。
2. イベントからディメンションを導出する場合は、NULLキーを除外します。 HogQLでは、フィルターが値と '' を比較するだけだと、プロパティが欠落している行も残ります。そのため isNotNull(...) も追加してください。NULLキーは独立したディメンション行となり、ファクト側のどの行にも一致しません。
3. わかりやすく安定した名前を付けます — country_code、region、plan_tier などです。これらの名前が、ほかのすべての要素が依存するJOINの接点になります。
4. 静的なディメンションは遅いスケジュールでマテリアライズします。 常に参照されるルックアップを仮想のままにしないでください。
5. 登録して認定します。 ディメンションに注釈を付け、重要な基盤となるものはカタログで認定してください（基礎編の governance.md）。そうすることで、ほかのモデルから見つけやすくなり、競合するコピーの作成を防げます。
6. PostHogでは、手作りの為替テーブルよりも組み込みの通貨機能（convertCurrency）を優先してください。

作成する

PostHog： 別名を付けたディメンションビューを整形し、マテリアライズしてからJOINします。レシピ： references/posthog/dim_country.sql（イベントから導出して拡張）、 dim_plan.sql（ルックアップ／アップロードのパターン）。

dbt： unique／not_null／relationships テストを備えた、各ウェアハウスで統一された dim_* モデルと、生成された dim_date を使用します。レシピ：references/dbt/。

ファイルマップ

ファイル	次の場合に参照する
references/dimension-catalog.md	共通ディメンション、それぞれの取得方法、自然キー。
references/posthog/	HogQL のエイリアス付きディメンションビューのレシピ。
references/dbt/	dbt の dim_date / dim_country と schema.yml のテスト。

関連項目

modeling-warehouse-foundations（結合＋通貨）、setting-up-a-data-warehouse-source / suggesting-data-imports（ソースデータの同期／アップロード）、およびこれらのディメンションを利用するモデル： modeling-revenue-metrics、modeling-conversion-metrics、modeling-activation-metrics、 modeling-product-usage-metrics。