数据模型间的边界划分：维度建模与事实表职责、星型/雪花型适用场景

1. 核心职责边界：事实表 vs 维度表

在维度建模中，事实表与维度表的边界划分是数据产品语义层的基石。混淆二者职责将直接导致数据产品查询性能下降与治理混乱。

2. 模式选型权衡：星型 vs 雪花型

星型与雪花型的本质差异在于是否对维度表进行规范化。它是在“查询性能”与“存储/维护成本”之间的边界选择。

3. 一致性维度与信任链路

当数据产品包含多业务过程（如销售、仓储、售后）时，必须建立“一致性维度”作为跨模型的信任边界。这意味着不同事实表共享相同的维度表或视图定义。

• 共享维度： 严格使用同一份“日期”、“用户”或“产品”维度表，拒绝重复创建。
• 代理键： 采用代理键作为事实表与维度表的关联字段，避免 OLTP 业务键变更导致数据链路断裂。
• 下行控制： 维度变化必须经过一致性验证，不允许下游应用私自修改共享维度属性。

以下配置示例定义了事实表与维度表之间的边界映射关系：

data_product:
  name: "统一销售分析"
  version: "1.0"
  models:
    - name: "fct_sales"
      type: "fact"
      granularity: "transaction_line_item"
      measures:
        - name: "revenue"  type: "summable"
        - name: "qty"      type: "summable"
        - name: "discount" type: "semi_summable"
      foreign_keys:
        - "dim_date"
        - "dim_product"
        - "dim_customer"
    - name: "dim_product"
      type: "dimension"
      scd_type: "2"
      attributes: ["product_id", "name", "category", "price"]
    - name: "dim_customer"
      type: "dimension"
      scd_type: "1"
      attributes: ["customer_id", "name", "region", "segment"]

4. 数据模型边界设计图

下图展示了星型维度建模的边界结构及雪花型分支的选型取舍点。

5. 落地步骤与验收标准

落地步骤

1. 声明业务过程边界： 明确需要建模的单一业务过程（如“订单下单”），避免将多个过程（如“订单”与“物流”）强行合并于一张事实表。
2. 定义原子粒度： 确定一条事实记录到底代表什么（例如“每笔订单行”、“每天库存快照”）。粒度是事实表最严格的边界规则。
3. 识别关联维度： 列出业务过程所牵连的所有上下文实体（时间、用户、产品、门店），并检查是否存在跨模型共用维度的可能。
4. 确定度量字段： 区分可加事实（金额）、半可加事实（库存量）与不可加事实（比率）。将不可加事实留至上层计算，避免污染事实表。
5. 执行选型决策： 对高频查询维度维持非规范化（星型），对低频、大字典、强治理维度采用规范化拆分（雪花型）。

关键风险点

• 粒度不一致： 混合行级别与汇总级别数据导致严重查询结果异常。
• 维度孤岛： 不同团队各自建立“用户维度”但属性定义不同，口径冲突频发。
• 过度雪花化： 拆解出50+张子维度表，ETL逻辑复杂，查询性能急剧下降。
• 外键信任缺失： 事实表外键未严格执行引用完整性，导致事实记录“悬空”。

验收标准