📄 一句话概括
同样的数据可以有三种放法：层次模型（树）、网状模型（网）、关系模型（表）——最后是【表】赢了天下，本章标题里的【关系型】说的就是它。
📝 本节和前面几节的关系
第一章说了【数据要成体系地放】（1-2 整理）；本节回答【体系有哪几种搭法】。这也是第二章的定调节：先看完三种模型的较量，才知道教材为什么接下来全在讲【表】。
一、数据模型：放数据的世界观
数据模型＝决定数据怎么组织、怎么关联的一套规矩。
同样是【公司里的人】，可以有三种记法：
- 按【老板→部门经理→员工】一层层记——层次模型
- 按【谁和谁有关系】画线连起来记——网状模型
- 按【一张张表】记，人和人的关系也用表记——关系模型
二、层次模型：一棵树
数据组织成树形：一个父节点带多个子节点，每个子节点只有一个父节点。
- 生活原型：公司的组织架构图、电脑里的文件夹
- 优点：结构清晰、找【上下级】快
- 死穴：现实不总是树。一个员工如果同时属于两个项目组，在树里就没地方放——【一个孩子只能有一个爹】这个规矩太死
三、网状模型：一张网
把树的限制放开：一个节点可以有多个父节点，数据之间任意连线。
- 生活原型：社交关系——你既是我同学又是我球友
- 优点：能表达【多对多】的复杂关系
- 死穴：线太多太乱。数据一多，连线密如蛛网；改一个节点，要顺着线检查一大片——程序员叫苦不迭
四、关系模型：一张表
把所有数据都放进二维表，表和表之间靠【公共的列】关联。
- 生活原型：Excel 那样的表格（但规矩严格得多）
- 数据之间的关系不再是【画线】，而是【两张表都有【学号】这一列，一对就对上了】
三种模型一张总表：
| 模型 | 形状 | 一个节点的爹 | 强项 | 死穴 |
|---|---|---|---|---|
| 层次模型 | 树 | 只能 1 个 | 上下级查询快 | 表达不了多归属 |
| 网状模型 | 网 | 可以多个 | 多对多 | 线乱难维护 |
| 关系模型 | 表 | ——（不连线） | 简单、直观、通用 | （2-4 再说缺点） |
五、为什么是关系模型赢了
- 简单：一张表人人看得懂，不需要懂【指针怎么连】
- 有数学底子：关系模型建立在【关系代数】上——不是拍脑袋设计，是能证明对错的
- 通用语言：操作表的 SQL（1-6）一套打天下；层次/网状模型各家各一套命令，换个产品全重学
- 数据与访问分开：你怎么存（表结构）和怎么查（SQL）各管各的，换存储方式不用改查询习惯
从 1980 年代至今，银行、网站、App 后台——绝大多数系统都是关系型数据库（1-3 点名的那批）。本章标题【关系型数据库的特征】由此而来。
六、动手 Demo：同一份数据，三种模型各画一遍
数据：张三是销售部员工，同时是【足球队】和【读书会】两个社团的成员。
- 层次画法：公司→部门→员工。试着把张三挂进两个社团——你会发现挂不进去（一棵树里一个节点只有一个位置）
- 网状画法：张三点分别连线到【销售部】【足球队】【读书会】——能画，但画出第 10 个人后线开始乱
- 关系画法：
- 员工表：
张三 | 销售部 - 社团表：
足球队、读书会 - 成员表：
张三 | 足球队、张三 | 读书会——多归属变成多加两行，毫无压力
看到什么算成功：三张画法都画出来，并且能说出【关系模型把关系也变成表】这句话。
七、30 秒实验
打开手机文件管理器看目录树——这就是层次模型活着的证据；再打开微信【通讯录→标签】，一个联系人可以打多个标签——这个【多对多】用树就装不下，正是当年网状模型要解决的问题。
八、常见误区
- "关系模型的关系＝人和人的关系" —— 这里的【关系（relation）】是数学名词，指的就是二维表本身。【关系型】＝【用表组织数据的】，不是【擅长拉关系的】。
- "层次/网状模型已经被彻底淘汰" —— 概念活在各处：文件系统是树（层次），社交网络分析用图数据库（网状思想的现代版，2-7 会讲到）。淘汰的是【用它们做通用数据库】。
- "关系模型赢了是因为最快" —— 赢在简单＋有数学底子＋语言通用；单论某些查询速度，专门的模型可以更快（2-5 之后你会见到反例场景）。
自测三问（点开对答案）
1. 三种数据模型分别是什么形状？ **层次＝树、网状＝网、关系＝表**。 2. 层次模型的死穴是什么？网状模型的死穴是什么？ **层次＝一个节点只能有一个父节点，表达不了多归属；网状＝连线太多太乱难维护**。 3. 关系模型胜出的四个理由？ **简单、有数学底子、SQL 通用、存取分离**。- ☐ 下一节（2-2 表、列、记录、字段-以表格形式存储数据）
相关笔记
- 数据的登记、整理和查询-数据库的特征 —— 上一章的【整理＝结构化】，本节展开成三种结构
- 🗄️ 数据库基础 · 索引 —— 全课路线图