modeling-dimension-tables

建模维度表（星型模式）

维度表是描述性表（dim_country、dim_plan、dim_date），事实表会与它们连接，以便进行切片分析。这项技能会一次性、规范地构建这些表，让其他模型都能复用，而不是重复推导查找数据。请先阅读 modeling-warehouse-foundations（连接和 convertCurrency() 的内容在其中）。常见维度目录：references/dimension-catalog.md；配方见 references/posthog/ 和 references/dbt/。

一屏了解星型模式

事实表（事件、收费项目、收入项）数据较多，带有键，且可累加。维度表数据较少，每个实体一行，用于描述实体。建模一个维度分三步：

1. 确定来源——维度数据从哪里来？
   • 将查找表（国家→地区、套餐→层级）上传 / 设为种子数据，格式为 CSV（数据仓库源或 dbt 种子数据）。
   • 从记录系统（你的应用数据库、Stripe 产品）_同步_数据，将其作为数据仓库源。
   • 从事件中_推导_数据（出现过的不同国家、每个人观察到的套餐属性）。
2. 整理数据——使用列名整洁、带有别名的 SELECT，并确保每个实体只有一行（彻底去重）。 保存为视图；由于维度很少变化，却会被频繁读取，应使用较慢的 sync_frequency（7day/30day）进行物化。
3. 关联数据——保存连接（维度 → 事实表）或人员连接（维度 → persons），让其中的列成为任何查询、筛选或细分中的原生字段。参见基础内容 joins-and-dimensions.md。

货币已经是受管维度——不要自行构建

PostHog 提供 convertCurrency(from, to, amount, timestamp?) 汇率功能（Open Exchange Rates，历史汇率准确）。任何货币转换都可直接使用。只有在 dbt 中（它没有同等功能），或需要 PostHog 未提供的汇率服务商时，才自行构建货币维度。

建模前的规则

1. 每个实体一行，键必须唯一。 维度键重复会导致与其连接的每张事实表在不易察觉的情况下发生行数膨胀。请测试唯一性（PostHog：在整理数据的查询中验证；dbt：使用 unique + not_null）。
2. 从事件推导维度时，去掉 NULL 键。 如果筛选条件只将属性与 '' 比较，HogQL 会保留属性缺失的行，因此还要添加 isNotNull(...)。NULL 键会成为独立的维度行，且无法与事实表一侧匹配。
3. 使用整洁、稳定的别名——country_code、region、plan_tier。其他模型都依赖这些名称作为连接接口。
4. 按较慢的计划物化静态维度；不要让频繁读取的查找表一直保持虚拟状态。
5. 注册并认证。 为维度添加注释；如果它是关键表，还要在目录中为其认证（基础内容 governance.md），让其他模型能够发现它，并避免重复构建。
6. 优先使用内置货币功能（convertCurrency），而不是在 PostHog 中手动维护 FX 表。

开始构建

PostHog： 整理维度视图并添加别名，然后进行物化和连接。配方： references/posthog/dim_country.sql（从事件推导并补充数据）， dim_plan.sql（查找 / 上传模式）。

dbt： 构建一致的 dim_* 模型，添加 unique/not_null/relationships 测试，并生成 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。