概念模型 逻辑模型 物理模型 区别

做数据或系统设计时，常听到「先画概念模型、再定逻辑模型、最后落物理模型」，但真动手就分不清哪层该画什么、哪层该改。评审时被人问「你这个是逻辑层还是物理层」，答不上来就要返工。这篇按「给谁看、回答什么问题、什么时候该往下走」三个角度把三层拆开，并给一份从需求到建表的推进顺序，帮你在评审前先自查一遍。

做数据或系统设计时，常听到「先画概念模型、再定逻辑模型、最后落物理模型」，但真动手就分不清哪层该画什么、哪层该改。评审时被人问「你这个是逻辑层还是物理层」，答不上来就要返工。这篇按三个角度把三层拆开：给谁看、回答什么问题、什么时候该往下走，并给一份从需求到建表的推进顺序，帮你在评审前先自查一遍。

先把最容易混的一点说透：三层不是三份文档的厚薄差异，而是三种读者、三种问题。同一件事在三层里的表达可以完全不同，但必须能互相追得回去。下面按「定位—转换—评审—变更」四段来走，每段都给你能直接照着做的动作。如果你在做 API 对接或选型，也可以顺带去站内的模型资料库核对概念口径，避免业务方和你说的不是一件事。

三层模型各回答什么问题

判断自己在哪一层，最快的办法是问「这份东西给谁看」。概念模型是给业务方看的，只描述有哪些实体、它们之间什么关系，不谈字段类型和表结构，用来对齐「我们说的是一件事吗」。逻辑模型是给设计与开发看的，把实体拆成属性、确定主键外键、定义一对多还是多对多，但还不管具体用哪种数据库。物理模型是给数据库本身和运维看的，字段类型、长度、索引、分区、存储引擎、命名规范都在这一层定。

概念层管「是什么」

有哪些业务对象、它们之间是什么关系，用业务语言写

逻辑层管「怎么组织」

实体如何拆成属性、主键外键怎么定、关系基数是多少

物理层管「怎么存」

落到具体数据库的类型、索引、分区与命名规范

这里有个常见误区：把物理细节提前写进逻辑模型，比如直接标字段长度和索引名。结果换一次存储方案，整个逻辑设计都要重画。判断标准很简单——这个信息会不会因为换了数据库而改变？会，就属于物理层，不该出现在逻辑层里。

三层之间怎么一步步转换

转换有固定方向，但每一步都有「先确认再往下」的检查点。从概念到逻辑：给每个实体补属性、判断关系基数、把多对多拆出中间实体，这一步最容易漏掉业务口径的确认，属性加错后面全白做。从逻辑到物理：按目标数据库的类型体系做字段映射，再决定索引与拆分方式；换数据库通常只动这一层。

1. 先冻结概念层让业务方用他们自己的话把实体和关系复述一遍，能复述对再往下走，别急着建表。
2. 再补逻辑层给实体加属性、标主键、写清关系基数；多对多关系必须拆出中间实体，别留在口头。
3. 最后落物理层按目标数据库映射字段类型，定索引和拆分；决定索引时对着主要查询语句一条条过。
4. 反向检查如果物理层改动会牵动业务方重新确认需求，说明前面两层没定干净，先回去补，别硬改。

顺序也有不适用的时候：一次性小工具、临时脚本、数据量很小的内部表格，直接建表更快，不必硬套三层。判断标准是这件事有没有第二个读者——只有你自己用，跳过概念层没问题；要交接给别人，就得补上。

每层给谁看、评审时盯什么

评审时最怕大家各看各的。把每层的读者和检查点固定下来，会议效率会高很多。概念模型评审盯实体有没有漏、关系方向对不对，让业务方用他们的话复述一遍确认。逻辑模型评审盯主键唯一性、关系基数、必填与可选、状态字段的取值范围。物理模型评审盯字段类型是否够用又不过度、索引是否覆盖主要查询、命名是否和团队规范一致。

跨团队协作时，把概念模型当共同语言；开发内部用逻辑模型吵架，DBA 或运维只关心物理层。一份文档里同时放三层不是不行，但要标清楚哪块属于哪层，否则评审时吵的其实是两个层级的问题。命名规范这类约定，可以到站内工具目录里找团队常参考的规范示例，统一口径。

改需求时先动哪一层

需求变更时先问一句：这次改动影响到的读者是谁？答案决定从哪层开始改。新增一个业务概念，从概念层加实体，再往下传导，别直接加字段了事。只换数据库或存储方案，理想情况只动物理层；如果被迫改逻辑层，说明当初把存储细节写进了逻辑设计，这是个信号。业务口径变了，比如一个订单能不能拆成多张单，这是概念层变更，影响面最大，必须回头和业务重新确认。

• 受影响的是业务方 → 从概念层改起，改完往下传导
• 只换存储方案 → 只动物理层，动不了就说明分层没分干净
• 业务口径变了 → 概念层变更，先回业务确认再动模型
• 开发内部调整 → 通常只动逻辑层，别顺手改物理层
• 只加一个查询 → 可能只加索引，动物理层就够

要查这类变更对下游的连带影响，可以去站内的价格追踪和工具目录页面看当时的对照信息，确认改动是否会牵动依赖方。判断标准始终是那一条：谁需要为此重新确认，就从哪层开始改。