逻辑模型和概念模型的区别

做数据建模时，最容易卡在第一步：需求方说的是业务语言，数据库里要的是表结构，中间到底该画几张图、每张图管什么，没人说明白。结果要么直接把业务画成表，改一次牵一片；要么概念图越画越细，反而不像给人看的。这篇把两类模型的分工、先后顺序和常见误用讲清楚，给你一套能照着走的判断标准。

做数据建模，最容易卡在第一步：需求方说的是业务语言，数据库里要的却是表结构。中间到底该画几张图、每张图管什么，没人讲清楚。结果常见两种翻车：一种是直接把业务描述画成表，业务改一次口径，表结构跟着牵一片；另一种是概念图越画越细，字段、类型全堆上去，最后反而没人能读懂，业务方看一眼就合上了。

这篇从初学者的视角，把概念模型和逻辑模型各自的分工、谁先谁后、什么情况下可以停在概念层讲清楚。不讨论画图工具的优劣，只解决一个问题：手上这份需求，现在该画哪一种图、画到什么程度就该停手。看完你应该能判断自己和团队当前处在哪一层。

先分清两者各自回答什么问题

概念模型回答的是「这门生意里有哪些东西、它们之间怎么关联」。用词全是业务词汇，比如订单、客户、门店，不会出现字段类型、主键、索引这类实现细节。它的读者是业务方，检验标准很简单：把图放到业务方桌上，他能指着某一根连线说「这条画错了，我们不是这么算的」，这张概念图就算合格。

逻辑模型回答的是「这些关系落到结构上长什么样」。这时才开始出现实体、属性、标识属性、一对多、多对多等约束，但仍然不绑定具体哪一种数据库。它的读者是开发和数据工程师，检验标准是：拿着这张图能不能直接开始设计表结构，不用回头再问业务方「这两个东西到底是什么关系」。

概念模型

回答有哪些业务对象、怎么关联，用业务词，给业务方看

逻辑模型

回答关系落到结构上长什么样，出现实体与约束，给开发看

判断口诀

能被业务方读懂并当面修改的是概念模型；能被开发直接拿去设计结构的是逻辑模型

常见的误解

以为两者只是粗细之别，其实面向的人群和要支持的决策根本不同

先后顺序，以及什么时候从概念走到逻辑

推荐的顺序是概念、逻辑、物理，逐层往下。跳步最容易返工：概念还没对齐就急着画逻辑模型，等于替业务方把还没定的规则先拍死了。等业务方回头说口径不对，改的就不是图上一根线，而是已经落地的结构，代价差很远。

1. 第一步：先把概念图画完只写业务对象和它们的关系，命名全部用业务词。画完拿给业务方过一遍，让他指出哪些关系不对、哪些对象漏了。这一步的产出物是一张业务方能指着说话的白板图。
2. 第二步：确认争议是否收敛把概念图上的争议点列出来，逐条确认是否已有结论。判断信号很直接：业务方之间不再有新分歧，剩下的只是表达细节，这时才具备往下走的前提。
3. 第三步：判断要不要进逻辑层如果需求要进入开发排期、要落地成系统，就往逻辑层走，补上实体属性、标识属性和关系基数。如果只是梳理一次需求、写方案给上级看，或者模型只服务于一次性的数据分析，停在概念层就够了，不必强行往下画。

这里有个容易忽略的点：从概念走到逻辑，不是把概念图细化一遍，而是换一套语言重新表达。概念图上的一个业务对象，在逻辑模型里可能拆成两张实体，也可能两个对象合并成一个，都是正常的。真正要保证的是，概念里的每一项在逻辑模型里都有对应，没有凭空多出来、也没有悄悄丢掉。

这几种情况，区别会被模糊掉

现实中很少有团队严格按三层走，下面几种情况会让概念和逻辑的边界变得模糊。重要的不是图符规范，而是这张图给谁看、看完要能做什么决定。读者和决策目的变了，该画的图也就变了。

还有一种情况值得单独说：当团队里只有一个人既懂业务又懂结构时，他脑子里两层的边界是模糊的，画出来的图可能两头不讨好。这时候找人复述一遍图上的内容，对方能不能听懂、能不能提出问题，就是最直接的检验方式。听不出问题的图，往往不是画得清楚，而是没人真正看。

上手时按这份清单自查

下面这份清单按「画之前、画完、交接」三个节点整理，可以直接拿去对照自己手上的模型。每一条都是能当场判断对错的，不需要额外工具，也不需要等待评审会。

• 概念模型自查：命名是否全部用业务语言，有没有混进字段类型这类实现细节，业务方能不能指出哪条关系画错了
• 逻辑模型自查：每个实体是否都有能唯一标识它的属性，关系基数是否写清，图上是否还残留「大概是这样」这类模糊描述
• 转换自查：概念里的每个业务对象在逻辑模型里是否都有落点，每一处一对多在逻辑里是否表达明确，没有凭空多出来的实体
• 交接自查：把两张图并排放，能不能对开发解释清楚「为什么这里要拆成两个实体」，解释不出来说明中间缺了一步
• 反向自查：让一位不了解项目的人只看概念图复述业务规则，复述偏离的地方就是概念层没对齐的地方

概念模型管「说的是不是同一件事」，逻辑模型管「做出来是不是同一个结构」，两件事都不能省，但不必同时做。