播面 事实表的设计流程是怎样的？（声明粒度 -> 确定维度 -> 确定事实）
根据数据仓库之父 Ralph Kimball 的经典理论，事实表设计的完整流程被称为 “维度设计四步法”。它决定了后续所有步骤的方向。
以下是完整、详细的事实表设计流程：
第一步：选择业务过程 (Select the Business Process)
（这是你遗漏的一步，也是起点）
- 定义：业务过程是企业进行的实际操作活动，通常由源系统（如ERP、CRM）中的事件触发。
- 如何做：
- 寻找动词：如“下单”、“支付”、“退款”、“浏览”、“入库”。
- 不要把“业务部门”误当作“业务过程”。例如，“营销部”不是业务过程，但“发送营销邮件”是。
- 目的：明确我们要分析的具体业务事件是什么。
第二步：声明粒度 (Declare the Grain)
（这是最关键的一步，决定了表的详细程度）
- 定义：精确定义事实表中一行数据代表什么。
- 原则：原子粒度（Atomic Grain）是首选。粒度越细，维度组合越丰富，分析的灵活性越高。
- 常见误区：不要在设计初期就为了性能而聚合数据（如“按天汇总”），这会丢失细节。
- 示例：
- 错误/模糊的粒度：每个订单一行。
- 正确的粒度：每个订单中的每个子项（SKU）一行。
第三步：确定维度 (Identify the Dimensions)
（描述环境：谁、在哪里、什么时候、是什么）
- 定义：维度提供了业务过程发生的背景（Context）。它们主要包含描述性的文本信息，用于过滤和分组。
- 如何做：
- 基于确定的粒度，问自己：这个事件与哪些实体相关？
- 通常包括：时间（When）、地点（Where）、人物（Who）、产品（What）、方式（How）。
- 关键点：
- 一致性维度：确保维度在不同事实表之间共享（如“日期维”、“用户维”），以便进行跨业务过程分析。
第二步：确定事实 (Identify the Facts)
（衡量指标：多少钱、多少个、时长）
- 定义：事实是业务过程产生的度量值，通常是数字，可以进行数学运算。
- 分类：
- 可加性事实：可以在任意维度上汇总（如：销售额、销量）。
- 半可加性事实：只能在部分维度上汇总（如：库存快照，不能把昨天的库存和今天的库存相加，但可以按仓库汇总）。
- 不可加性事实：比率或单价（如：毛利率）。通常需要分解为分子和分母存储。
- 注意：如果某个字段是数字（如订单号），但它不用于计算而是用于标识，那它通常是退化维度，而不是事实。
实战案例演示：电商下单业务
为了让你更直观地理解，我们用电商下单来走一遍流程：
选择业务过程：
- 用户在APP上点击“提交订单”并生成订单记录的瞬间。
声明粒度：
- 一行数据代表：一个父订单中的一个商品详情项（Order Line Item）。
- （注：如果粒度定为“一个父订单”，你就无法分析同一个订单里买了哪些不同的商品组合。）
确定维度（基于单商品粒度，环境是什么？）：
- 谁买的？ -> 用户维度 (User_ID)
- 买了什么？ -> 商品维度 (Product_ID)
- 什么时候？ -> 日期维度 (Date_ID)、时间维度 (Time_ID)
- 发到哪？ -> 地区维度 (Location_ID)
- 参加活动没？ -> 促销维度 (Promotion_ID)
- 哪个订单？ -> 订单号 (Order_No) —— 这是退化维度
确定事实（在这个粒度下，产生了哪些数值？）：
- 下单数量 (Quantity)
- 单价 (Unit_Price)
- 总金额 (Total_Amount)
- 优惠金额 (Discount_Amount)
- 实付金额 (Payment_Amount)
进阶：第五步（冗余与优化）
在完成上述四步标准流程后，在实际工程落地时，通常还会增加一步：
- 冗余维度属性：为了查询性能，将常用的维度属性（如商品一级类目、用户VIP等级）直接冗余到事实表中，形成宽表。
- 计算衍生指标：虽然理论上只存原子指标，但为了方便下游，可能会预计算一些常用的值（如：利润 = 销售额 - 成本）。
总结
完整的口诀是：
定业务 -> 定粒度 -> 定维度 -> 定指标。