Day 2:数据库灵魂 - 设计、范式与运算

【全量通关版】整合设计六阶段、E-R 转换与关系代数

1. 数据库设计六阶段

“数据库不是敲出来的,是设计出来的。考纲要求严格遵守这六个脚步。”
1 需求分析:搞清楚用户要存什么。
2 概念结构设计:【核心】画出 E-R 图,独立于具体机器。
3 逻辑结构设计:【高频】把 E-R 图转成具体的关系模式(表)
4 物理结构设计:确定存储结构(如索引、聚簇)。
5 数据库实施:写 SQL 语句,正式建库、载入数据。
6 运行与维护:性能监控、数据备份、扩容。

2. E-R 图与逻辑转换铁律

“考场口诀:1对多合到多,多对多必建表。”

E-R 图三大元素:

转换规则(必考)

1. 1:1 联系:可在任意一方加外键,不需要新表。

2. 1:N 联系:把“1”端的主键加到“N”端做外键(例:学院号加到学生表)。

3. M:N 联系必须独立建新表。主键为两端实体主键的组合。

下午题真题模拟

情景:教师(工号)和设备(设备号)是 M:N 关系,申请时记录“申请日期”。

问:生成的“申请关系模式”中,主键是什么?

答案:(工号, 设备号)
解析:多对多联系转换后的新表,必须由两端的物理主键共同构成复合主键。

3. 关系运算:数据的数学舞步

“关系代数是 SQL 语句的逻辑原型。符号看懂了,逻辑就通了。”
运算真题

题目:关系 R(3列, 4行),关系 S(5列, 2行)。执行 R × S 后,结果有几列几行?

答案:8 列,8 行。
解析:列数相加 (3+5),行数相乘 (4*2)。

4. 范式理论:数据库的“拆分手术”

“范式就是为了解决:数据重复、改不掉、删不掉的尴尬。”

1NF:原子性

每一格只能有一个值,不能再拆分。(如:地址不能同时存省和市)

2NF:消除部分依赖

非主属性必须依赖【整个】复合主键,不能只依赖其中一部分。

3NF:消除传递依赖

非主属性不能通过另一个非主属性间接依赖主键。(如:学号→系名,系名→系主任)

范式判断真题

“供应商表 S 中存在 Sno → Zip,Zip → City。” 该表属于第几范式?

答案:2NF
解析:由于存在 Zip → City 的传递依赖,所以不满足 3NF,最高只到 2NF。

5. 树:索引的物理基石

“数据库之所以快,是因为它像翻字典。B+ 树就是那个最高效的页码索引。”

二叉树遍历规律

左子树永远在右子树前面! 根的位置决定名称:根在前(前序)、根在后(后序)、根在中(中序)。

遍历真题

一颗树:A 是根,左边是 B(B 下面有左儿子 D),右边是 C。

中序遍历结果是?

答案:DBAC
推导:左(D->B) -> 根(A) -> 右(C)。

B+ 树:数据库索引之王

6. 易错点总结 ⚠️

  1. 自然连接 vs 笛卡尔积:自然连接会自动去掉重复列,笛卡尔积会全部保留。
  2. 左外连接:左表的所有行必须出现,右表没匹配上的补 NULL。
  3. 逻辑独立性:对应的是【外模式/模式映像】。
  4. 物理独立性:对应的是【模式/内模式映像】。