取舍看什么
星型与雪花不是对错问题，而是把冗余放在哪里的问题。判断依据集中在四点：下游工具能否处理多层 join、维度是否被大量事实表共享、维度层次变更是否频繁、团队是否有统一约定。分析型场景通常倾向星型，共享度高且变更频繁的维度可局部雪花化。
基本信息
| 星型特征 | 维度直接连事实，维表内允许冗余 |
|---|---|
| 雪花特征 | 维度再拆子维，用 join 换取低冗余 |
| 常见折中 | 主体星型，仅对深层次维度做雪花化 |
| 关键前提 | 选择必须写进建模规范并统一执行 |
| 注意 | 同一仓库混用两套风格而无约定，使用体验割裂 |
典型使用场景
- 新建主题域：判断维度是否直接挂事实，或先拆一层子维
- 自查现有模型：找出为省存储而过度拆分的维度
- 工具选型联动：BI 工具的 join 能力弱时优先星型
- 维度变更频繁：评估把变化部分独立成子维，隔离变更影响
- 模型评审：把取舍结论固化成规范，避免不同开发者各行其是
折中落法
折中落法
-- 主体星型：商品维度内直接冗余类目层级名称列，避免三层 join
-- dim_product(product_sk, product_id, brand,
-- cat_l1_code, cat_l1_name,
-- cat_l2_code, cat_l2_name,
-- cat_l3_code, cat_l3_name)
-- 查询只需一次关联，按一级类目汇总
SELECT p.cat_l1_name, sum(f.amount) AS amt
FROM fact_sale f
JOIN dim_product p ON f.product_sk = p.product_sk
WHERE f.dt = '2026-10-12'
GROUP BY p.cat_l1_name;
-- 类目调整时只重刷商品维度的层级列，事实表不受影响对比读法
| 对比维度 | 星型 | 雪花 |
|---|---|---|
| join 层数 | 少，通常一次关联到手 | 多，层次越深 join 越多 |
| 存储冗余 | 高，层次名称重复存放 | 低，层次只存一份 |
| 可读性 | 好，字段自解释 | 一般，需理解层次关系 |
| 维护成本 | 层次变更要重刷维表 | 改层次表，影响面集中 |
| 对工具要求 | 低，BI 直接可用 | 高，依赖语义层或宽表补救 |
取舍结论要落到规范里：哪些维度可以冗余层级列、哪些必须拆子维、宽表冗余到什么程度，都写明。没有约定的仓库最终会同时存在两种风格，使用者每次都要重新判断。
只看单表存储成本容易倾向雪花，但查询与人力成本通常远高于存储节省。评估时应把下游每次查询多写的 join、排障多花的时间一并计入。