3.4.1 逻辑结构设计概述
本课核心知识点整理
从概念模型走向数据模型
逻辑结构设计承接概念设计：前面已经用 E-R 图把业务对象、属性和联系抽象出来，这一节开始要把它转换成某一种数据库数据模型能够表达的逻辑结构。
这里的“逻辑”不是磁盘上的存储方式，而是数据在数据库中如何组织、如何操作、受哪些约束。对于软件设计师考试，最核心的数据模型是关系模型，也就是把概念模型转换为关系模式。
数据模型的几种形态
字幕提到四类典型数据模型。它们体现了数据库技术从“贴近存储和导航”逐步走向“结构统一、查询声明式、约束清晰”的演进。
| 数据模型 | 组织方式 | 适合表达 | 局限与被替代原因 |
|---|---|---|---|
| 层次模型 | 树形父子结构 | 组织机构、目录树等天然层级 | 多对多表达困难，访问路径僵硬 |
| 网状模型 | 记录之间可形成复杂网状连接 | 复杂实体关联 | 结构灵活但难理解、难维护，应用程序依赖路径 |
| 关系模型 | 二维表及关系运算 | 大多数结构化业务数据 | 对复杂对象和嵌套结构表达不如对象模型自然 |
| 面向对象模型 | 以对象、类、继承封装数据 | CAD、多媒体、复杂对象 | 通用查询、标准化和生态不如关系数据库成熟 |
关系模型能成为考试重点，是因为它把复杂数据组织统一到二维表上，再用关系代数、SQL、完整性约束描述操作与规则，学习成本和工程可维护性都更好。
数据模型的三要素
字幕强调，数据模型不是只看表结构，还包括操作和约束：
| 要素 | 在关系模型中的体现 | 常见考点 |
|---|---|---|
| 数据结构 | 关系模式、属性、元组、域 | 表名、列名、主键、外键 |
| 数据操作 | 选择、投影、连接、增删改查 | 关系代数、SQL 查询 |
| 数据约束 | 实体完整性、参照完整性、用户定义完整性 | 主键非空、外键引用、取值范围 |
这里的“数据结构”不要和算法章节的数据结构混为一谈。数据库里的数据结构强调“数据模型如何组织数据”，例如关系模型把数据组织成二维表；算法里的数据结构强调程序内存中的组织方式，例如栈、队列、树、图。
逻辑结构设计的输入和输出
逻辑设计的输入通常是概念设计产物，输出是某个数据模型下的逻辑模式。在关系数据库课程语境下，可以写成：
| 阶段 | 核心问题 | 典型产物 |
|---|---|---|
| 需求分析 | 用户要管理什么 | 需求说明、数据流、业务规则 |
| 概念设计 | 现实对象和联系是什么 | E-R 图 |
| 逻辑设计 | 如何用关系模型表达 | 关系模式、主键、外键、完整性约束 |
| 物理设计 | 如何高效存储和访问 | 索引、文件组织、存储路径 |
逻辑设计已经开始接近实现，但仍不关心“这张表放在哪个磁盘块、索引用 B+ 树还是哈希”这类物理细节。它关心的是：表怎么分、列怎么放、主键如何唯一标识、外键如何表达联系、模式是否存在冗余和异常。
做题路线
- 看到“E-R 图转换为关系模式”，直接定位逻辑结构设计。
- 看到“索引、存储路径、文件组织”，定位物理设计。
- 看到“数据模型三要素”，按结构、操作、约束回答，不要只写结构。
- 看到“层次、网状、关系、面向对象模型”，优先记住关系模型是本章主线，后续规范化、SQL、并发控制都围绕它展开。
例题
关系数据库逻辑结构设计的主要产物是：
确定索引和存储路径主要属于：
自查要点
- 逻辑设计的输入和输出分别是什么？
- 关系模式为什么属于逻辑结构？
- 逻辑设计和物理设计的边界是什么？