5-9 概念模型、逻辑模型、物理模型-E-R图的种类

📄 一句话概括

数据模型分三层，由粗到细：概念模型（实体和关系，用户视角）→ 逻辑模型（表和列，与具体数据库无关）→ 物理模型（列类型、索引、具体到 MySQL 还是 SQLite）——从抽象到落地，三层各画一次。

📝 本节和前面几节的关系

前三节的 E-R 图其实只是概念层。本节给整个设计过程立「楼层数」：设计就是从概念层一步步下楼梯到物理层，5-10 起的规范化、类型、命名全发生在逻辑→物理的两层里。

一、三层各管什么

层	回答的问题	内容	谁看
概念模型	业务里有什么？	实体、关系（E-R 图）	用户、评审
逻辑模型	表怎么组织？	表、列、主外键（不提类型）	设计者、开发者
物理模型	具体怎么建？	列类型、约束、索引、命名	数据库本身

二、同一个「学生」在三层的样子

概念层：  [学生] ──◇属于◇── [班级]          （方框菱形）
逻辑层：  students(id PK, name, class_id FK)  （表和列）
物理层：  CREATE TABLE students (
            id INT PRIMARY KEY,
            name VARCHAR(20) NOT NULL,
            class_id INT,
            FOREIGN KEY ... ) ENGINE=InnoDB   （类型/引擎/索引全定死）

一次设计、三层表达——概念层错了全错，物理层错了改语句；越往下错越便宜，所以评审先看概念层。

三、为什么分三层

沟通分层：用户只参与概念层评审（看得懂）
移植性：逻辑模型不提 MySQL/SQLite，换数据库时概念、逻辑两层原样带走，只重写物理层
职责清楚：分析师生概念、设计者画逻辑、DBA 定物理

四、动手 Demo：书评网站爬三楼

概念：用户—撰写—书评—属于—书（5-7 已画）
逻辑：users(id, nickname) / reviews(id, user_id FK, book_id FK, score, body, created_at) / books(isbn, title)——三表两外键，未提类型
物理：给每列补上类型与约束（5-16~5-19 实战完成这一步）

五、30 秒实验

回看第四章任何一个 CREATE TABLE：它是三层里的哪层？（物理层）——把类型全抹掉、留表名列名主外键，就成了逻辑层。一层之差，口算完成。

六、常见误区

「E-R 图画完直接建表」：中间还差逻辑层（规范化、定列）——跳层是最常见的返工之源
「逻辑模型也写上 VARCHAR(20)」：类型是物理层的事；逻辑层保持与具体产品无关，换库才不伤筋骨

自测三问

1. 三层各自回答什么问题？（业务有什么/表怎么组织/具体怎么建） 2. 换数据库时哪层要重写？（只重写物理层） 3. 规范化和类型各发生在哪层？（规范化在逻辑层、类型在物理层）

☐ 下一节（5-10 规范化-统一数据的格式）