维度建模基础：星型模型与雪花模型、事实表与维度表的概念、维度建模的4步设计流程
聊到数据仓库，绕不开的一个话题就是维度建模。说实话，我见过不少团队一上来就撸宽表，结果后面维护成本高得吓人。维度建模这套方法论，是 Kimball 老爷子留给我们的宝贵遗产。今天咱们就把它的核心骨架拆开看看。
事实表与维度表：数据仓库的左右手
先搞清楚两个最基础的概念。你想想看，业务过程产生的「度量值」放在哪？描述这些度量值的「业务环境」又放在哪？
事实表，记录的是业务事件的可量化指标。比如一笔订单的金额、数量、折扣。它通常很「瘦长」——行数爆炸，但列数不多。事实表里的外键，指向的就是维度表。
维度表，描述的是「谁、什么、何时、何地、为何」。比如客户姓名、产品分类、日期属性。它通常很「矮胖」——行数相对少，但列数多，包含丰富的描述性字段。
我记得刚入行时接手过一个销售分析项目。业务方说「我要看每个销售员上个月的业绩」。我直接建了一张大宽表，把销售员姓名、部门、区域、产品名称、价格、日期全塞进去。结果呢？产品改名后要更新几百万行数据，差点把生产库拖垮。后来改成维度建模，产品信息单独放一张维度表，改个名字只需要更新几十行。嗯，这就是教训。
核心原则：事实表关注「发生了什么」，维度表关注「描述发生了什么」。两者通过外键关联，互不干扰。
星型模型 vs 雪花模型
这两个模型，说白了就是维度表的设计风格不同。
星型模型：维度表直接与事实表关联，维度表不再往下细分。结构简单，查询性能好。适合大多数 OLAP 场景。
雪花模型：维度表进一步规范化，拆分成多个子维度表。比如「产品维度」拆成「产品表」和「品类表」。存储空间省了，但查询时要多 JOIN 几次。
我个人习惯，90% 的场景用星型模型。为什么？因为数据仓库的核心是查询性能，不是存储成本。硬盘便宜，但业务等不起那几秒的查询延迟。
| 对比维度 | 星型模型 | 雪花模型 |
|---|---|---|
| 维度表结构 | 非规范化，单层 | 规范化，多层 |
| 查询性能 | 高（JOIN 少） | 低（JOIN 多） |
| 存储空间 | 较大（数据冗余） | 较小（消除冗余） |
| 维护复杂度 | 低 | 高 |
| 适用场景 | 大多数数仓场景 | 维度层次深、存储敏感 |
我的建议：除非你明确知道雪花模型能带来显著收益（比如维度层次超过 3 层且查询模式固定），否则优先选星型。别为了「规范化」而规范化。
维度建模的 4 步设计流程
这套流程我用了十年，每次做新项目都按这个节奏走。它帮你从业务需求一步步落到物理模型，不容易跑偏。
- 选择业务过程：先搞清楚你要分析什么业务事件。是「下单」还是「退款」？是「点击」还是「浏览」？一个业务过程对应一张事实表。
- 声明粒度：明确事实表中每一行代表什么。是「每笔订单一行」还是「每个订单行项目一行」？粒度越细，分析越灵活，但数据量也越大。
- 确定维度：围绕业务过程，列出所有描述性角度。时间、客户、产品、门店、渠道……每个维度对应一张维度表。
- 确定事实：最后才看度量值。销售额、数量、成本、评分……把这些可加性的数值放进事实表。
我曾经接手过一个电商项目，业务方说「我要看每天的 GMV」。我按这四步走下来，发现他们其实还想按「新老客」「渠道来源」「商品类目」下钻。如果一上来就只建一张「日汇总表」，后面改起来就痛苦了。所以，第 2 步「声明粒度」特别关键——粒度决定了你能回答什么层次的问题。
避坑指南：我曾经跳过「声明粒度」直接建表，结果事实表里既有订单级数据又有订单行级数据，聚合时口径对不上。后来花了整整一周重新梳理。记住：粒度必须单一且明确。
知识体系总览
下面这张图把本章的核心脉络串起来了。你可以把它当作一个快速索引，回头复习时一眼就能抓住重点。
这张图从左到右展示了事实表和维度表的核心特征，下方对比了星型与雪花模型，最底部是四步设计流程。你可以把它当作一个快速索引，回头复习时一眼就能抓住重点。