4. 数据模型设计：概念模型、逻辑模型、物理模型、维度建模与事实建模

数据模型设计，说白了就是给数据「搭骨架」。骨架搭得好，后面做报表、跑分析、建应用，都顺风顺水。骨架搭歪了，后面填数据就像往歪楼里塞家具——怎么塞怎么别扭。

我这些年踩过的坑，十有八九都跟模型设计有关。有一次项目赶工期，我跳过概念模型直接画物理表，结果业务方看了说「这不是我要的东西」。嗯，从那以后我再也不敢偷懒了。

4.1 三层次模型：从抽象到具体

数据模型分三个层次：概念模型、逻辑模型、物理模型。它们的关系，我习惯用一个比喻来理解：

• 概念模型：画房子的草图，告诉别人「我要一栋三室两厅的房子」
• 逻辑模型：出施工图，标清楚每个房间多大、门窗在哪
• 物理模型：列材料清单，用什么砖、什么水管、什么电线

你想想看，如果连草图都没画清楚就跑去买砖，大概率会买错。

4.1.1 概念模型（Conceptual Model）

概念模型关注的是「业务世界有什么」。它用业务语言描述实体和关系，不涉及任何技术细节。

我在项目中遇到过最典型的场景：业务方说「我要看客户买了什么」。这句话翻译成概念模型，就是「客户」和「订单」两个实体，它们之间是「一对多」的关系。

4.1.2 逻辑模型（Logical Model）

逻辑模型在概念模型的基础上，把每个实体的属性、主键、外键都定义清楚。它仍然独立于具体的数据库产品。

举个例子：概念模型里的「客户」实体，在逻辑模型里会展开成：

客户（客户ID，姓名，手机号，注册时间，会员等级）
订单（订单ID，客户ID，订单金额，下单时间，订单状态）

这里「客户ID」是客户表的主键，也是订单表的外键。逻辑模型要回答的问题是：「这些数据存成什么结构，才能支持业务查询？」

4.1.3 物理模型（Physical Model）

物理模型是真正落地到数据库里的东西。它要考虑：用什么数据类型、要不要建索引、怎么分区、用哪种存储引擎。

我记得有一次做电商数据平台，逻辑模型里「订单金额」是 DECIMAL(10,2)，但到了物理模型，我改成了 DECIMAL(12,2)。为什么？因为双十一的订单金额可能超过 10 位数。这种细节，逻辑模型不会告诉你，但物理模型必须管。

层次	关注点	受众	产出物
概念模型	业务实体与关系	业务方、产品经理	实体关系草图
逻辑模型	属性、主键、外键	数据架构师、分析师	逻辑 ERD、属性清单
物理模型	数据类型、索引、分区	DBA、开发工程师	建表 DDL、索引策略

4.2 维度建模与事实建模

聊完三层次，咱们再来看两种主流的建模方法：维度建模和事实建模。说白了，它们解决的是「怎么组织数据才能让查询更快」的问题。

4.2.1 维度建模（Dimensional Modeling）

维度建模是 Kimball 老爷子提出的，核心思想就四个字：星型模型。中间一张事实表，周围一圈维度表。

• 事实表：存度量值，比如销售额、订单数量。特点是行数多、增长快。
• 维度表：存描述信息，比如客户姓名、产品名称、时间。特点是行数少、变化慢。

我习惯用「超市小票」来理解：小票上的「金额」「数量」是事实，小票上的「商品名」「收银员」「收银台」是维度。

4.2.2 事实建模（Fact Modeling）

事实建模更关注「事实本身」的粒度。同一个业务过程，不同粒度的设计会直接影响查询能力。

举个例子：电商订单。

• 事务事实表：每下一单，记一条。粒度是「订单」。
• 周期快照事实表：每天记录每个订单的状态。粒度是「订单+日期」。
• 累积快照事实表：每个订单一条记录，但包含多个时间字段（下单时间、支付时间、发货时间、完成时间）。

我在项目中遇到过这样的需求：运营要分析「从下单到支付平均耗时多久」。如果用事务事实表，你得算时间差；如果用累积快照事实表，字段直接摆在那，查起来快得多。

4.2.3 维度建模 vs 事实建模：怎么选？

对比维度	维度建模	事实建模
核心目标	易用性、查询性能	数据完整性、灵活性
适用场景	BI 报表、OLAP	数据仓库底层、ETL
表结构	星型/雪花型	3NF/宽表
典型代表	Kimball 方法论	Inmon 方法论

你想想看，如果业务方天天要「按维度下钻」，维度建模是首选。如果数据团队要「保证数据不丢不重」，事实建模更靠谱。

4.3 本章知识体系

下面这张图，把本章的核心逻辑串起来了。我建议你保存下来，做模型设计时对照着看。

4.4 实战建议

最后，分享几个我自己的实操习惯：

1. 先画概念模型，再写逻辑模型。哪怕只花 30 分钟，也要跟业务方确认实体和关系对不对。
2. 逻辑模型阶段，把属性清单列全。我见过太多人到了物理模型才发现「哎呀，这个字段漏了」。
3. 物理模型阶段，考虑数据量级。百万级和亿级，索引策略完全不同。
4. 维度建模优先选星型。雪花模型虽然省空间，但查询性能差，得不偿失。
5. 事实建模先定粒度。粒度定错了，后面所有分析都跑偏。