刚开始学数据库的人，画图那一步最容易卡住：ER 图、UML 类图、维度模型、文档模型都能描述业务，但到底该用哪个、各自会坑在哪，教材上往往一句话带过。这篇不背定义，给你一张按场景对照的清单和一套排查顺序，让你面对一个具体需求时能自己说出「先用哪个、什么情况下不适用」，并顺手把名词查清楚。
刚开始学数据库的人，画图那一步最容易卡住：ER 图、UML 类图、维度模型、文档式结构草图都能描述业务，可到底该用哪个、各自会坑在哪，教材上往往一句话带过。结果就是有人上来就画表结构，有人画完图再没人看。
这篇不背定义，给你一张按场景对照的清单和一套排查顺序，让你面对一个具体需求时能自己说出「先用哪个、什么情况下不适用」。顺手把术语查清楚，遇到拿不准的名词，可以到 /tools 里的工具目录转转，很多概念在站内都有对应的解释页。
概念模型到底在解决什么
概念模型只描述业务里的实体、属性和关系，不碰字段类型、索引和分表，目的是让业务方和开发对同一件事有共同理解。判断标志很简单：如果一张图里出现了字段类型、长度限制、主键定义，它已经不是概念模型，而是往逻辑模型走了。
- 常见误区是把概念模型当一次性的文档写一遍就丢，实际上它的价值在于后续每次需求变更都能回到这张图对齐
- 如果团队里没人愿意维护它，画得再漂亮也只是一张图片，不如只保留核心实体和关键关系
- 不适用的情况：单人小项目、需求一天一变且没有外部对接方时，画正式概念图的收益可能低于直接开工
- 一旦出现跨团队协作或外部接口，概念模型的收益会迅速上升，因为它把歧义提前暴露出来
几类常见概念模型的优劣对照
| 模型类型 | 优势 | 容易踩的坑 | 适合谁 |
|---|---|---|---|
| ER 模型 | 实体和联系表达最直观，业务方容易看懂 | 复杂业务里关系线缠成一团，对继承、多态表达吃力 | 传统关系型项目、教学场景 |
| UML 类图 | 能表达继承和组合，面向对象团队顺手 | 纯业务同学看不懂，容易被当成代码设计图提前锁死实现 | 有面向对象背景的开发团队 |
| 维度模型 | 面向分析统计，问「按什么维度看什么指标」时最顺 | 对事务型系统的日常增删改不够自然 | 报表、数据仓库类需求 |
| 文档式结构草图 | 字段可嵌套、迭代快，适合早期探索 | 没有约束，容易堆成一坨无法校验的嵌套结构 | 需求未定的快速原型 |
这张表不是让你选一个永远用下去，而是让你知道每个模型的边界在哪。比如维度模型不是不能做事务，而是做完之后你会发现每次改一条记录都要绕一圈。具体哪种模型对应的官方资料和价格参考，可以到 /models 页面核对当时的数字。
按场景选：一套可执行的判断顺序
- 先问三个问题这套系统的核心是记录事务还是出报表；团队里有没有非技术的业务方要一起看图；未来半年大概率会不会拆分子系统。三个问题的答案基本能锁定方向。
- 事务型 + 有业务方参与优先 ER 模型，先把实体和关系画全，再往逻辑模型细化。验证方式是拿图给业务方讲一遍，对方能指出错误就说明图有用。
- 分析型 + 指标口径争议多优先维度模型，先把事实和维度分开，避免把指标算在维度里。验证方式是随便挑一个指标，看能不能从图上说清它的来源。
- 快速原型 + 需求未定先用最轻的结构草图跑通，等需求稳定再补成正式概念模型。这一步别省，省了后面就是返工，补图的成本远低于改表。
如果你在选型时同时纠结「用哪家数据库的官方 API」，可以先到 /price-watch 看价格追踪，再决定要不要把模型落在那套体系上。模型选型和技术选型是两件事，别混在一起做决定。
画完怎么自查：四步排查顺序
- 第一步查冗余：同一个业务概念是不是在两个实体里各写了一份，是就合并掉
- 第二步查关系方向：一对多有没有画反，多对多有没有漏掉中间实体
- 第三步查命名：实体名和关系名业务方能否读懂，读不懂说明抽象层级错了
- 第四步查边界：系统外部的东西（第三方、人工环节）有没有画进来，没画进来后面一定扯皮
自查通不过就先别进逻辑模型。改概念的代价远小于改表结构，这句话在项目里几乎每次都成立，前提是概念图确实有人看、有人维护。
概念模型的价值不在画得对不对，而在改需求时大家能不能指着同一张图说话。下一步把你手头那个需求按上面三步走一遍，再对照站内的模型资料库确认字段和接口口径，避免选完模型才发现技术侧对不上。→
常见问题
初学者到底该先学 ER 模型还是 UML 类图？
看你下一步要干什么。如果目标是关系型数据库和 SQL，先学 ER 模型，它和表结构的对应关系最直接；如果本来就写 Java、Python 这类面向对象代码，UML 类图更顺手。两个都不是必须精通，先能画出实体、属性和关系这三样就够用，剩下的边做边补。
概念模型和逻辑模型、物理模型有什么区别？
一句话：概念模型讲业务里有什么、怎么关联；逻辑模型把它落成表、字段和约束；物理模型再管存储、索引和分区。越往后越贴近具体数据库。初学者最常见的错误是跳过概念直接建表，结果需求一变，改的不是一张图而是一堆已经写进代码的表结构。
小项目或者个人项目有必要画概念模型吗？
如果只有你一个人做、表数量在个位数、需求基本不会再变，画正式概念图的性价比确实不高，脑子里过一遍就够。但只要出现下面任意一条——有第二个开发、要给非技术的人解释、半年内还会加功能——花半小时画一下，通常能省掉后面几小时的返工。
