业务驱动建模：从业务需求出发，识别核心业务过程与度量
很多刚入行的朋友问我：「建星型模型，到底从哪下手？」
我的回答永远是：别碰数据，先看业务。
你想想看，如果连业务在干什么都不清楚，建出来的模型就是空中楼阁。我在项目里见过太多「技术完美、业务用不了」的模型——维度拆得漂亮，事实表设计精巧，但业务方一问「我的核心指标在哪」，全傻眼。
为什么会这样？因为建模的起点错了。
2.1 业务驱动 vs 数据驱动：两种建模思维
先澄清一个概念。很多人以为「数据驱动」就是看表建模，这是误区。
| 对比维度 | 业务驱动建模 | 数据驱动建模 |
|---|---|---|
| 起点 | 业务需求、分析场景 | 现有数据表、字段 |
| 核心问题 | 业务要分析什么？ | 数据里有什么？ |
| 产出 | 业务可理解的模型 | 技术可实现的模型 |
| 风险 | 初期沟通成本高 | 后期返工概率大 |
| 我的建议 | 优先采用 | 仅用于快速验证 |
我个人习惯，拿到需求后第一件事不是打开数据库，而是约业务方聊半小时。聊什么？就聊三个问题：
- 你们每天最关心的数字是什么？
- 这些数字怎么算出来的？
- 想从哪些角度去看这些数字？
聊完这三个问题，模型的大致轮廓就有了。
核心原则：模型是业务的映射，不是数据的搬运。先理解业务过程，再设计事实表；先明确分析维度，再构建维度表。
2.2 识别核心业务过程
业务过程，说白了就是业务里「发生的一件事」。比如：
- 电商：用户下单、支付、发货、退货
- 金融：客户开户、交易、还款、销户
- 制造：采购入库、生产投料、成品出库
每个业务过程，对应一个事实表。这是星型模型的骨架。
怎么识别？我有一套「四步法」：
- 梳理业务流程：画出业务的主干流程，标注关键节点
- 定位事件节点：每个节点是不是「发生了某件事」？是，就标记
- 区分过程与状态：过程是「下单」，状态是「已下单」——我们要的是过程
- 评估分析价值：这个事件值得分析吗？业务方会频繁查询吗？
举个例子。我在做一个零售项目时，业务方一开始列了20多个「指标」。我带着他们走了一遍四步法，最后只保留了5个核心业务过程：采购入库、调拨出库、销售开单、销售退货、库存盘点。其他那些「过程」要么是状态，要么是子过程，合并到主过程里了。
小技巧：如果某个「过程」没有明确的度量值（比如金额、数量），或者没有可枚举的维度（比如时间、产品、门店），那它大概率不是核心业务过程。
2.3 定义关键度量
业务过程确定了，接下来就是找度量。度量就是事实表里的数值字段，是分析的核心。
我一般把度量分成三类：
| 度量类型 | 说明 | 示例 |
|---|---|---|
| 可加性度量 | 跨所有维度都能累加 | 销售额、订单数量 |
| 半可加性度量 | 部分维度可累加 | 库存量（时间维度不可加） |
| 不可加性度量 | 不能直接累加 | 比率、单价、折扣率 |
这里有个坑。我曾经遇到一个项目，业务方把「折扣率」直接放进了事实表，然后按月份汇总。结果呢？汇总后的折扣率完全不对——因为折扣率是比率，不能简单累加。正确的做法是存「折扣金额」和「原价金额」，需要比率时再计算。
避坑指南：我曾经在金融项目中，把「利率」作为度量直接存入事实表。结果按产品汇总时，利率被累加成了几百倍。后来我养成了一个习惯：事实表只存原子度量，衍生指标在查询时计算。
2.4 从业务需求到模型设计的完整流程
说了这么多，咱们串起来看一个完整案例。
假设我们做一个电商分析系统。业务方提的需求是：
- 每天看各品类的销售额
- 按城市分析订单量
- 看不同支付方式的退款率
按业务驱动建模的思路，我这样走：
- 识别业务过程：下单、支付、退款
- 定义度量：订单金额、支付金额、退款金额、订单数量
- 确定维度：时间、产品品类、城市、支付方式
- 设计模型：3个事实表（订单事实、支付事实、退款事实），4个维度表
你看，整个过程没碰一行数据，但模型结构已经清晰了。
下面这张图，就是整个流程的框架：
2.5 实战：用业务驱动法设计一个订单模型
咱们拿「订单」这个最常见的业务过程，走一遍完整的设计。
第一步：和业务方确认分析场景
业务方说：我要看每天的订单量、订单金额，按产品品类和城市维度。
第二步：识别业务过程
这里要注意，「订单」本身是一个过程，但「订单状态变更」是另一个过程。我建议分开建模：
- 订单事实表：记录订单创建事件
- 订单状态事实表：记录状态变更事件（如果需要分析转化率）
第三步：定义度量
订单事实表的度量：
- 订单金额（可加）
- 订单数量（可加，通常为1）
- 运费（可加）
- 折扣金额（可加）
第四步：确定维度
- 时间维度（下单日期）
- 产品维度（关联到品类）
- 客户维度（关联到城市）
- 门店维度（如果有多门店）
你看，模型结构已经出来了。接下来就是建表的事，那是技术活，但骨架已经搭好了。
我的经验：业务驱动建模最花时间的不是建模本身，而是和业务方对齐认知。我一般会画一张「业务过程-度量-维度」的矩阵图，和业务方一起过一遍。确认无误再动手。这一步省了，后面返工的成本至少翻三倍。
2.6 常见误区与避坑
做业务驱动建模这些年，我踩过不少坑。挑几个典型的说说：
- 误区一：把状态当过程。比如「已支付」是状态，「支付」才是过程。状态变化应该用缓慢变化维处理，不是事实表。
- 误区二：度量定义不清晰。比如「销售额」是含税还是不含税？是订单金额还是实付金额？这些必须在建模前和业务方确认。
- 误区三：维度过度设计。我见过一个模型，维度表有30多张，但业务方常用的就5张。其他那些「可能有用」的维度，最后全成了摆设。
避坑指南：我曾经在一个项目中，把「客户年龄」作为维度属性放进了客户维度表。结果业务方要按「年龄段」分析，但年龄是变化的，每年都要更新。后来我改成了「出生年份」，用计算字段生成年龄段。记住：维度属性要选稳定的、不随时间变化的。
好了，这一章的核心就这些。业务驱动建模，说白了就是先想清楚业务要什么，再动手建模型。别急着写SQL，别急着画ER图。拿张纸，和业务方聊半小时，比你在数据库里折腾一天都管用。