📅 日期:2026-05-15
📚 科目:软件设计师 · 数据库系统
🏷️ 标签: 数据库关系代数范式 SQL事务并发控制
⭐ 重要度:高频考点(选择题 + 案例分析 + 论文)
| 阶段 | 数据模型 | 特点 | 代表 |
|---|---|---|---|
| 第一代 | 层次模型 | 树形结构,一对多 | IMS |
| 第一代 | 网状模型 | 图结构,多对多 | DBTG |
| 第二代 | 关系模型 | 二维表结构,数学基础坚实 | Oracle, MySQL |
| 第三代 | 对象关系模型 | 面向对象 + 关系 | PostgreSQL |
| 新型 | NoSQL | 非关系型,高可扩展 | MongoDB, Redis |
| 层次 | 名称 | 别名 | 内容 | 对应对象 |
|---|---|---|---|---|
| 外层 | 外模式 | 子模式 / 用户模式 | 用户看到的数据视图 | 视图(VIEW) |
| 中层 | 模式 | 概念模式 / 逻辑模式 | 全局数据的逻辑结构 | 基本表 |
| 内层 | 内模式 | 存储模式 | 数据的物理存储方式 | 物理文件 |
保证:逻辑数据独立性
模式改变时,修改映射即可,外模式不变 → 应用程序不用改
保证:物理数据独立性
存储结构改变时,修改映射即可,模式不变 → 逻辑结构不用改
"外视内物中逻辑" → 外模式看视图,内模式管物理,模式是逻辑
"外/模式保逻辑独立,模式/内保物理独立"
| 架构 | 特点 | 优点 | 缺点 |
|---|---|---|---|
| 集中式 | 所有处理在主机完成 | 管理简单 | 扩展性差 |
| C/S | 客户端负责表示逻辑,服务器负责数据管理 | 响应快,交互好 | 客户端维护成本高 |
| B/S | 浏览器为客户端,Web服务器+数据库服务器 | 部署简单,跨平台 | 响应较慢 |
| 术语 | 定义 | 对应概念 |
|---|---|---|
| 关系 | 一张二维表 | 表 |
| 元组 | 表中的一行 | 行 / 记录 |
| 属性 | 表中的一列 | 列 / 字段 |
| 域 | 属性的取值范围 | 如:性别={男, 女} |
| 基数 | 关系中元组的个数 | 行数 |
| 度(目) | 关系中属性的个数 | 列数 |
| 候选键 | 能唯一标识元组的最小属性集 | 可能有多个 |
| 主键 | 从候选键中选定的一个 | PRIMARY KEY |
| 外键 | 引用其他关系主键的属性 | FOREIGN KEY |
| 超键 | 能唯一标识元组的属性集(可含多余属性) | 候选键的超集 |
| 约束类型 | 定义 | 说明 | 示例 |
|---|---|---|---|
| 实体完整性 | 主键不能为空(NOT NULL) | 主键是元组的唯一标识 | 学生表的学号不能为空 |
| 参照完整性 | 外键值必须是被参照表中主键的有效值或NULL | 外键引用必须有效 | 选课表的学号必须在学生表中存在 |
| 用户自定义完整性 | 用户定义的业务规则约束 | CHECK、UNIQUE等 | 成绩在0-100之间 |
| 作用 | 说明 |
|---|---|
| 简化操作 | 将复杂查询封装为视图 |
| 多方式查询 | 不同用户通过不同视图访问数据 |
| 逻辑独立性 | 模式改变时通过视图保持外模式不变 |
| 安全保护 | 只暴露需要的数据给用户,隐藏敏感列 |
| 对比 | 普通视图 | 物化视图 |
|---|---|---|
| 存储 | 不存储数据(虚表) | 物理存储查询结果 |
| 查询速度 | 每次查询重新计算 | 直接读取,速度快 |
| 更新 | 实时反映基表变化 | 需刷新才能同步 |
| 空间 | 不占空间 | 占用存储空间 |
| 类型 | 特点 | 影响 |
|---|---|---|
| 聚簇索引 | 数据物理存储顺序与索引顺序一致 | 一个表只能有一个,影响内模式 |
| 非聚簇索引 | 索引顺序与数据物理存储无关 | 一个表可以有多个 |
| 唯一索引 | 索引列的值不能重复 | 保证数据唯一性 |
| B+树索引 | 最常用的索引结构 | 查询效率O(log n) |
适合建索引:查询频繁的列、WHERE/JOIN条件中的列、值分布广的列
不适合建索引:修改频繁的列、值很少的列(如性别)、小表
关系代数是案例分析必考内容,常考:选择、投影、连接、除法的表达式书写。
| 运算 | 符号 | 定义 | 要求 |
|---|---|---|---|
| 并 | R ∪ S | 属于R或属于S的元组 | R和S同目(度相同) |
| 交 | R ∩ S | 既属于R又属于S的元组 | R和S同目 |
| 差 | R - S | 属于R但不属于S的元组 | R和S同目 |
| 笛卡尔积 | R × S | R的每个元组与S的每个元组组合 | 无要求 |
符号:σ条件(R)
含义:从关系R中选取满足条件的元组(相当于SQL的WHERE)
// 示例:查询年龄大于20的学生
σ年龄>20(Student)
// 等价SQL: SELECT * FROM Student WHERE 年龄 > 20
符号:π属性列表(R)
含义:从关系R中选取指定的列(相当于SQL的SELECT列)
// 示例:查询学生的姓名和年龄
π姓名,年龄(Student)
// 等价SQL: SELECT 姓名, 年龄 FROM Student
// 注意:投影会自动去除重复行!
| 连接类型 | 符号 | 含义 | SQL对应 |
|---|---|---|---|
| 等值连接 | R ⋈A=B S | 在笛卡尔积中选取A=B的元组 | WHERE R.A = S.B |
| 自然连接 | R ⋈ S | 等值连接 + 去除重复列 | NATURAL JOIN / USING |
| 外连接 | R ⟕ S / R ⟖ S / R ⟗ S | 保留不匹配的元组(用NULL填充) | LEFT/RIGHT/FULL OUTER JOIN |
| 左外连接 | R ⟕ S | 保留R中所有元组 | LEFT OUTER JOIN |
| 右外连接 | R ⟖ S | 保留S中所有元组 | RIGHT OUTER JOIN |
| 全外连接 | R ⟗ S | 保留R和S中所有元组 | FULL OUTER JOIN |
符号:R ÷ S
含义:找出R中与S的所有元组都能匹配的元组在非公共属性上的投影
记忆:"找出...全部..."的问题就用除法
// R: 选课表(学号, 课程号)
// S: 某课程集合
// 查询"选修了S中所有课程的学生学号"
// 表达式:π学号,课程号(R) ÷ S
// 例:S = {C1, C2}
// R中选了C1和C2的学生才出现在结果中
R ÷ S = πR-S的属性(R) - πR-S的属性((πR-S的属性(R) × S) - R)
简单理解:从R中去掉那些"没覆盖S全部"的元组
| 运算 | 符号 | 对应SQL | 操作对象 |
|---|---|---|---|
| 选择 | σ | WHERE | 行 |
| 投影 | π | SELECT 列 | 列 |
| 连接 | ⋈ | JOIN | 表 |
| 除法 | ÷ | NOT EXISTS嵌套 | "全部"问题 |
| 并 | ∪ | UNION | 元组 |
| 交 | ∩ | INTERSECT | 元组 |
| 差 | - | EXCEPT | 元组 |
| 笛卡尔积 | × | CROSS JOIN | 元组 |
σ选行,π选列,⋈连接,÷全部
并交差积是集合运算,选投连除是关系运算
规范化理论是案例分析的高频考点,必须掌握:判断范式级别、分解到3NF/BCNF。
| 类型 | 定义 | 示例 |
|---|---|---|
| 完全函数依赖 | X的任何真子集都不能决定Y,则Y完全依赖于X | (学号,课程号) → 成绩(去掉任一个都不能确定成绩) |
| 部分函数依赖 | X的某个真子集就能决定Y | (学号,课程号) → 姓名(学号 alone 就能决定姓名) |
| 传递函数依赖 | X→Y,Y→Z,且Y↛X,则Z传递依赖于X | 学号→院系,院系→院长,则学号→院长(传递) |
| 规则 | 内容 | 说明 |
|---|---|---|
| 自反律 | 若Y⊆X,则X→Y | 属性集决定其子集 |
| 增广律 | 若X→Y,则XZ→YZ | 两边同时加属性 |
| 传递律 | 若X→Y,Y→Z,则X→Z | 依赖的传递 |
| 合并规则 | 若X→Y,X→Z,则X→YZ | 合并右侧 |
| 分解规则 | 若X→YZ,则X→Y,X→Z | 拆分右侧 |
1NF ⊃ 2NF ⊃ 3NF ⊃ BCNF ⊃ 4NF
规范化程度越高,数据冗余越少,但查询越复杂(需要连接)
| 范式 | 条件 | 消除的问题 | 关键词 |
|---|---|---|---|
| 1NF | 每个属性都是不可再分的原子值 | — | 属性不可再分 |
| 2NF | 在1NF基础上,消除非主属性对候选键的部分函数依赖 | 部分依赖 | 非主属性完全依赖于候选键 |
| 3NF | 在2NF基础上,消除非主属性对候选键的传递函数依赖 | 传递依赖 | 非主属性不传递依赖于候选键 |
| BCNF | 在3NF基础上,消除主属性对候选键的部分和传递依赖 | 主属性的部分/传递依赖 | 每个决定因素都是候选键 |
| 4NF | 在BCNF基础上,消除非平凡的多值依赖 | 多值依赖 | 消除多值依赖 |
BCNF定义:关系R中,若每个决定因素都是候选键,则R属于BCNF。
判断方法:检查每个函数依赖X→Y,看X是否为超键。
// 例:关系 R(A,B,C),函数依赖:A→B, B→C
// 候选键:A
// 检查:A→B,A是候选键 ✓
// 检查:B→C,B不是候选键 ✗
// 结论:R属于3NF,但不属于BCNF
// 原因:B是决定因素但不是候选键
// 分解为BCNF:
// R1(B,C) 函数依赖:B→C
// R2(A,B) 函数依赖:A→B
// 两个关系的决定因素都是候选键,属于BCNF
多值依赖:若X→→Y,则X的每个值对应Y的一组值,且这组值与R的其他属性无关。
平凡多值依赖:Y⊆X 或 X∪Y=R
4NF条件:消除非平凡的多值依赖
// 例:关系(课程, 教师, 参考书)
// 一门课有多个教师,同时有多个参考书
// 教师和参考书之间没有直接关系
// 存在多值依赖:课程→→教师,课程→→参考书
// 不属于4NF,需要分解
| 原则 | 说明 |
|---|---|
| 无损连接性 | 分解后能通过自然连接恢复原关系(必须满足) |
| 函数依赖保持 | 分解后函数依赖不丢失(尽量满足) |
判断无损连接:若 R1∩R2 → R1-R2 或 R1∩R2 → R2-R1 成立,则分解是无损的。
1NF:属性是否可再分?(可再分→不满足)
2NF:非主属性是否部分依赖于候选键?(是→不满足)
3NF:非主属性是否传递依赖于候选键?(是→不满足)
BCNF:每个决定因素是否都是候选键?(不是→不满足)
SQL是案例分析必考内容,常考:查询语句编写、连接查询、子查询、GROUP BY/HAVING。
| 分类 | 全称 | 功能 | 关键字 |
|---|---|---|---|
| DDL | 数据定义语言 | 定义和修改数据库结构 | CREATE, ALTER, DROP |
| DML | 数据操纵语言 | 查询和修改数据 | SELECT, INSERT, UPDATE, DELETE |
| DCL | 数据控制语言 | 权限控制 | GRANT, REVOKE |
| TCL | 事务控制语言 | 事务管理 | COMMIT, ROLLBACK |
-- 创建表
CREATE TABLE Student (
Sno CHAR(10) PRIMARY KEY, -- 主键
Sname VARCHAR(20) NOT NULL, -- 非空
Sage INT CHECK(Sage>=0), -- 检查约束
Sdept CHAR(10) DEFAULT '计算机系' -- 默认值
);
-- 创建索引
CREATE INDEX idx_sname ON Student(Sname); -- 非唯一索引
CREATE UNIQUE INDEX idx_sno ON Student(Sno); -- 唯一索引
-- 修改表
ALTER TABLE Student ADD Sgender CHAR(2); -- 添加列
ALTER TABLE Student DROP COLUMN Sgender; -- 删除列
ALTER TABLE Student MODIFY Sname VARCHAR(30); -- 修改列
-- 删除表
DROP TABLE Student;
-- 插入
INSERT INTO Student VALUES ('2024001', '张三', 20, '计算机系');
INSERT INTO Student(Sno, Sname) VALUES ('2024002', '李四');
-- 更新
UPDATE Student SET Sage = 21 WHERE Sno = '2024001';
-- 删除
DELETE FROM Student WHERE Sno = '2024001';
-- 基本查询
SELECT Sname, Sage FROM Student WHERE Sage > 20;
-- 去重
SELECT DISTINCT Sdept FROM Student;
-- 排序
SELECT * FROM Student ORDER BY Sage DESC; -- 降序
-- 模糊查询
SELECT * FROM Student WHERE Sname LIKE '张%'; -- 张开头
SELECT * FROM Student WHERE Sname LIKE '_三'; -- 第二字为三
-- 聚合函数
SELECT COUNT(*), AVG(Sage), MAX(Sage), MIN(Sage), SUM(Sage)
FROM Student;
-- 分组查询(重点!)
SELECT Sdept, COUNT(*) AS 人数, AVG(Sage) AS 平均年龄
FROM Student
GROUP BY Sdept
HAVING COUNT(*) > 5; -- 分组后过滤
WHERE:分组前过滤(不能用聚合函数)
HAVING:分组后过滤(可以用聚合函数)
-- 正确:HAVING用聚合函数
SELECT Sdept, COUNT(*) FROM Student GROUP BY Sdept HAVING COUNT(*) > 5;
-- 错误:WHERE不能用聚合函数
-- SELECT Sdept FROM Student WHERE COUNT(*) > 5; ← 语法错误!
-- 等值连接
SELECT Student.Sname, SC.Grade
FROM Student, SC
WHERE Student.Sno = SC.Sno;
-- 内连接(推荐写法)
SELECT S.Sname, SC.Grade
FROM Student S INNER JOIN SC ON S.Sno = SC.Sno;
-- 左外连接(保留左表所有行)
SELECT S.Sname, SC.Grade
FROM Student S LEFT JOIN SC ON S.Sno = SC.Sno;
-- 右外连接(保留右表所有行)
SELECT S.Sname, SC.Grade
FROM Student S RIGHT JOIN SC ON S.Sno = SC.Sno;
-- 全外连接(保留两表所有行)
SELECT S.Sname, SC.Grade
FROM Student S FULL JOIN SC ON S.Sno = SC.Sno;
-- 非相关子查询(独立子查询,先执行内层)
SELECT Sname FROM Student
WHERE Sno IN (SELECT Sno FROM SC WHERE Cno = 'C1');
-- 相关子查询(内层引用外层变量,逐行执行)
SELECT Sname FROM Student S
WHERE EXISTS (
SELECT * FROM SC
WHERE SC.Sno = S.Sno AND SC.Cno = 'C1'
);
-- "全部"问题 → 用 NOT EXISTS + 双重否定
-- 查询选修了全部课程的学生姓名
SELECT Sname FROM Student S
WHERE NOT EXISTS (
SELECT * FROM Course C
WHERE NOT EXISTS (
SELECT * FROM SC
WHERE SC.Sno = S.Sno AND SC.Cno = C.Cno
)
);
查询"选修了全部课程的学生" → NOT EXISTS + NOT EXISTS(双重否定表全称)
等价于关系代数的除法运算。
口诀:"没有一门课他没选" = "他选了全部课"
-- 创建视图
CREATE VIEW CS_Student AS
SELECT Sno, Sname, Sage FROM Student WHERE Sdept = '计算机系';
-- 查询视图(与表操作相同)
SELECT * FROM CS_Student WHERE Sage > 20;
-- 删除视图
DROP VIEW CS_Student;
-- 授权
GRANT SELECT, INSERT ON Student TO user1;
GRANT ALL PRIVILEGES ON Student TO user1;
-- 收权
REVOKE SELECT ON Student FROM user1;
| 概念 | 图形 | 含义 | 示例 |
|---|---|---|---|
| 实体 | 矩形 | 现实世界中可区分的对象 | 学生、课程 |
| 属性 | 椭圆 | 实体的特征 | 姓名、年龄 |
| 联系 | 菱形 | 实体之间的关系 | 选课 |
| 主键 | 属性名加下划线 | 唯一标识实体的属性 | 学号 |
| 类型 | 表示 | 示例 | 转换规则 |
|---|---|---|---|
| 1:1 | 一对一 | 一个班级有一个班长 | 可将联系并入任一实体 |
| 1:N | 一对多 | 一个班级有多个学生 | 将联系并入N端实体(加外键) |
| M:N | 多对多 | 学生与课程(选课) | 必须独立建表(关系表) |
| E-R元素 | 转换方式 | 说明 |
|---|---|---|
| 实体 | 转换为一个关系模式 | 实体属性→关系属性,主键不变 |
| 1:1联系 | 并入任一实体 | 在任一方加入对方主键作为外键 |
| 1:N联系 | 并入N端实体 | 在N端加入1端主键作为外键 |
| M:N联系 | 独立建表 | 关系表包含双方主键(联合主键)+ 联系属性 |
| 三个以上实体的多元联系 | 独立建表 | 包含各实体主键 + 联系属性 |
| 冲突类型 | 说明 | 示例 |
|---|---|---|
| 属性冲突 | 同一属性在不同E-R图中类型/范围不同 | 学号:一个用CHAR(10),一个用INT |
| 命名冲突 | 同名异义或异名同义 | "部门"和"处室"指同一概念 |
| 结构冲突 | 同一实体在不同E-R图中结构不同 | 一个E-R图中学生有年龄,另一个有出生日期 |
| 阶段 | 任务 | 产出 | 关键方法 |
|---|---|---|---|
| 需求分析 | 收集和分析用户需求 | 数据流图、数据字典、需求说明书 | 访谈、问卷、原型法 |
| 概念设计 | 建立概念模型 | E-R图 | E-R模型、视图集成法 |
| 逻辑设计 | 概念模型→关系模式 | 关系模式、规范化处理 | E-R转关系模式、范式化 |
| 物理设计 | 确定存储结构和存取方法 | 物理存储方案 | 索引、聚簇、分区 |
当规范化导致查询需要大量连接、性能下降时,可适当反规范化。
| 技术 | 方法 | 适用场景 |
|---|---|---|
| 增加冗余列 | 在表中存储常用但来自其他表的列 | 频繁连接查询 |
| 增加派生列 | 存储计算结果(如总价=单价×数量) | 频繁计算 |
| 合并表 | 将频繁一起查询的表合并 | 1:1关系的表 |
| 分割表 | 水平分割(按行)或垂直分割(按列) | 表过大、访问模式不同 |
| 优化点 | 建议 | 原因 |
|---|---|---|
| SELECT | 避免 SELECT *,只选需要的列 | 减少数据传输和内存占用 |
| 子查询 | 用不相关子查询代替相关子查询 | 相关子查询逐行执行,效率低 |
| IN vs OR | 用 IN 代替 OR | IN可利用索引 |
| EXISTS vs IN | 大表用EXISTS,小表用IN | EXISTS适合外表小内表大 |
| JOIN | 合理使用JOIN代替子查询 | JOIN通常比嵌套子查询效率高 |
| 索引 | 在WHERE/JOIN条件列上建索引 | 加速查询 |
| LIKE | 避免 LIKE '%abc'(左模糊) | 无法利用索引 |
| 连接池 | 使用数据库连接池 | 减少连接创建开销 |
| 特性 | 含义 | 实现机制 |
|---|---|---|
| A 原子性 | 事务中的操作要么全做,要么全不做 | UNDO日志、回滚机制 |
| C 一致性 | 事务执行前后数据库从一个一致状态到另一个一致状态 | 由其他三个特性共同保证 |
| I 隔离性 | 并发事务之间互不干扰 | 封锁机制、MVCC |
| D 持久性 | 事务一旦提交,对数据库的改变是永久的 | REDO日志 |
"原一隔永"(原子、一致、隔离、持久)
"一致性是目标,原子/隔离/持久是手段"
| 问题 | 定义 | 示例 |
|---|---|---|
| 丢失更新 | 两个事务同时更新同一数据,一个的更新被覆盖 | T1读A=10写A=20,T2读A=10写A=30,最终A=30(T1丢失) |
| 不可重复读 | 同一事务内两次读取同一数据,结果不同(被其他事务修改) | T1读A=10,T2改A=20并提交,T1再读A=20 |
| 读脏数据 | 读到其他事务未提交的数据(该事务可能回滚) | T1改A=20但未提交,T2读A=20,T1回滚,T2读到无效数据 |
| 项目 | 内容 |
|---|---|
| 加锁条件 | 事务对数据进行写操作时加X锁 |
| 兼容性 | 与其他任何锁不兼容 |
| 效果 | 其他事务不能读也不能写 |
| 项目 | 内容 |
|---|---|
| 加锁条件 | 事务对数据进行读操作时加S锁 |
| 兼容性 | 与其他S锁兼容,与X锁不兼容 |
| 效果 | 其他事务可以读但不能写 |
| 锁兼容矩阵 | S锁 | X锁 |
|---|---|---|
| S锁 | 兼容 ✓ | 不兼容 ✗ |
| X锁 | 不兼容 ✗ | 不兼容 ✗ |
| 协议 | 规则 | 解决问题 | 不能解决 |
|---|---|---|---|
| 一级封锁 | 修改数据前必须加X锁,事务结束释放 | 丢失更新 | 不可重复读、脏读 |
| 二级封锁 | 一级 + 读数据前加S锁,读后即可释放 | 丢失更新 + 脏读 | 不可重复读 |
| 三级封锁 | 一级 + 读数据前加S锁,事务结束才释放 | 丢失更新 + 脏读 + 不可重复读 | — |
一级:只管写(X锁,事务结束释放)→ 防丢失更新
二级:管写+短读(X锁+S锁,读后释放)→ 防丢失更新+脏读
三级:管写+长读(X锁+S锁,事务结束释放)→ 防全部
口诀:"一写二短三长"
定义:两个或多个事务互相等待对方释放锁,形成循环等待
解决方法:
定义:某个事务一直等待锁,但总被其他事务插队
解决方法:采用先来先服务策略
与死锁区别:活锁的事务有机会获得锁(理论上),死锁永远等不到
可串行化调度:一个并发调度的结果等价于某个串行调度的结果,则该调度是可串行化的。
意义:可串行化是并发调度正确性的唯一标准。
冲突操作:不同事务对同一数据的操作中至少有一个是写操作。
判断方法:交换不冲突的操作,若能变成某个串行调度,则冲突可串行化。
优先图法:构造事务优先图,若图中无环则冲突可串行化。
| 阶段 | 规则 | 说明 |
|---|---|---|
| 增长阶段 | 只能获得锁,不能释放锁 | 不断加锁 |
| 收缩阶段 | 只能释放锁,不能获得锁 | 不断解锁 |
2PL是可串行化的充分条件:遵循2PL的调度一定是可串行化的。
但2PL不能防止死锁:2PL可能导致死锁!
原理:为每个事务创建数据的"快照",读操作不阻塞写操作,写操作不阻塞读操作。
| 对比 | 封锁机制 | MVCC |
|---|---|---|
| 读写冲突 | 读阻塞写,写阻塞读 | 读写互不阻塞 |
| 并发度 | 较低 | 较高 |
| 实现 | 锁表 | 版本链 |
| 代表 | 传统数据库 | PostgreSQL, MySQL InnoDB |
| 故障类型 | 原因 | 恢复策略 |
|---|---|---|
| 事务故障 | 事务执行中被撤销(运算溢出、违反约束等) | UNDO(反向扫描日志,撤销修改) |
| 系统故障 | 系统崩溃(断电、OS故障),内存丢失 | UNDO未提交事务 + REDO已提交事务 |
| 介质故障 | 磁盘损坏,数据丢失 | 重装备份 + REDO(日志+备份恢复) |
| 策略 | 规则 | 日志要求 | 性能 |
|---|---|---|---|
| UNDO | 撤销未提交事务的修改 | 记录修改前的值(Before Image) | 回滚较慢 |
| REDO | 重做已提交事务的修改 | 记录修改后的值(After Image) | 恢复较快 |
| UNDO+REDO | 先UNDO未提交,再REDO已提交 | 同时记录前值和后值 | 最安全但日志量大 |
| 类型 | 说明 |
|---|---|
| 冷备份 | 停止数据库后备份,简单但影响可用性 |
| 热备份 | 数据库运行时备份,不影响正常使用 |
| 类型 | 说明 |
|---|---|
| 完全备份 | 备份所有数据 |
| 差量备份 | 备份自上次完全备份后的变化 |
| 增量备份 | 备份自上次备份(任何类型)后的变化 |
作用:定期将内存中的数据写入磁盘,减少恢复时需要扫描的日志量。
恢复步骤:
原理:将数据库实时复制到另一个磁盘(镜像盘),当主盘故障时自动切换到镜像盘。
优点:提高可用性,减少介质故障恢复时间。
实现:通过日志传送或同步复制。
| 措施 | 说明 |
|---|---|
| 用户标识与鉴定 | 用户名/密码、生物识别 |
| 存取控制 | 自主存取控制(DAC)、强制存取控制(MAC) |
| 视图机制 | 通过视图限制用户可见的数据 |
| 审计 | 记录用户操作日志,事后追查 |
| 数据加密 | 存储加密、传输加密 |
| 对比 | 完整性 | 安全性 |
|---|---|---|
| 关注点 | 数据的正确性和一致性 | 数据的保护,防止未授权访问 |
| 防范对象 | 不合语义的数据(如成绩为负数) | 非法用户和非法操作 |
| 实现方式 | CHECK、主键、外键、触发器 | 用户认证、权限控制、加密 |
触发器:一种特殊的存储过程,在特定事件(INSERT/UPDATE/DELETE)发生时自动执行。
-- 创建触发器示例
CREATE TRIGGER check_grade
BEFORE INSERT ON SC
FOR EACH ROW
BEGIN
IF NEW.Grade < 0 OR NEW.Grade > 100 THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = '成绩必须在0-100之间';
END IF;
END;
| 特点 | 说明 |
|---|---|
| 数据独立性 | 数据分布对用户透明 |
| 集中与自治结合 | 局部DBMS独立管理,全局统一协调 |
| 适当冗余 | 多副本提高可用性和性能 |
| 全局一致性 | 各节点数据保持一致 |
| 透明性 | 含义 | 层次 |
|---|---|---|
| 分片透明 | 用户不必关心数据如何分片 | 最高级 |
| 位置透明 | 用户不必关心数据存储在哪个节点 | 中级 |
| 复制透明 | 用户不必关心数据是否有副本 | 低级 |
"分片位置复制"(从高到低)
分片透明 > 位置透明 > 复制透明
在分布式系统中,以下三者最多只能同时满足两个:
| 属性 | 含义 | 说明 |
|---|---|---|
| C(一致性) | 所有节点看到相同的数据 | 强一致性 |
| A(可用性) | 每个请求都能得到响应 | 不保证是最新数据 |
| P(分区容忍性) | 网络分区时系统仍能运行 | 分布式系统必须满足 |
CP系统:放弃可用性,保证一致性和分区容忍(如 ZooKeeper、HBase)
AP系统:放弃强一致性,保证可用性和分区容忍(如 Cassandra、DynamoDB)
CA系统:不存在真正的CA系统(分布式必须容忍分区)
| 类型 | 特点 | 代表产品 | 适用场景 |
|---|---|---|---|
| 键值型 | 简单的Key-Value存储 | Redis, Memcached | 缓存、会话管理 |
| 文档型 | 存储JSON/BSON文档 | MongoDB, CouchDB | 内容管理、日志 |
| 列族型 | 按列存储,适合分析 | HBase, Cassandra | 大数据分析 |
| 图数据库 | 存储节点和关系 | Neo4j, JanusGraph | 社交网络、推荐 |
| 特征 | 说明 |
|---|---|
| 面向主题 | 按主题组织数据(如客户、产品) |
| 集成的 | 从多个数据源整合 |
| 非易失的 | 数据加载后一般不修改 |
| 时变的 | 记录历史变化,支持时间维度分析 |
| # | 考点 | 答案 |
|---|---|---|
| 1 | 三级模式对应什么? | 外模式=视图,模式=基本表,内模式=物理文件 |
| 2 | 两层映射保证什么? | 外/模式映射→逻辑独立性,模式/内→物理独立性 |
| 3 | 关系的性质? | 列无序、行无序、分量原子值、无重复行 |
| 4 | 范式排序? | 1NF⊃2NF⊃3NF⊃BCNF⊃4NF |
| 5 | 2NF消除了什么? | 非主属性对候选键的部分依赖 |
| 6 | 3NF消除了什么? | 非主属性对候选键的传递依赖 |
| 7 | BCNF的条件? | 每个决定因素都是候选键 |
| 8 | ACID是什么? | 原子性、一致性、隔离性、持久性 |
| 9 | 一级封锁防什么? | 丢失更新 |
| 10 | 二级封锁防什么? | 丢失更新+脏读 |
| 11 | 三级封锁防什么? | 丢失更新+脏读+不可重复读 |
| 12 | 2PL的性质? | 可串行化的充分条件,但不能防死锁 |
| 13 | CAP定理? | 一致性、可用性、分区容忍性最多满足两个 |
| 14 | 分布式透明性排序? | 分片>位置>复制 |
| 15 | M:N联系怎么转换? | 独立建表 |
| # | 考点 | 答题要点 |
|---|---|---|
| 1 | SQL查询语句编写 | SELECT-FROM-WHERE-GROUP BY-HAVING-ORDER BY |
| 2 | E-R图设计与转换 | 识别实体/联系/属性→画E-R图→按规则转换关系模式 |
| 3 | 范式判断与分解 | 找候选键→判断依赖类型→确定范式级别→分解 |
| 4 | 关系代数表达式 | σ选行、π选列、⋈连接、÷全部 |
| 5 | 并发控制问题分析 | 识别丢失更新/脏读/不可重复读→选择封锁协议 |
| 考点 | 口诀 | 解释 |
|---|---|---|
| 三级模式 | "外视内物中逻辑" | 外模式看视图,内模式管物理,模式是逻辑 |
| 独立性 | "外/模式保逻辑,模式/内保物理" | 两层映射对应的独立性 |
| 范式排序 | "一二三BC四" | 1NF→2NF→3NF→BCNF→4NF |
| 2NF/3NF | "二消部三消传" | 2NF消部分依赖,3NF消传递依赖 |
| 封锁协议 | "一写二短三长" | 一级管写,二级短读,三级长读 |
| ACID | "原一隔永" | 原子、一致、隔离、持久 |
| 关系代数 | "σ选行π选列,⋈连接÷全部" | 四种关系运算的含义 |
| 分布式透明 | "分片位置复制" | 从高到低排序 |
| CAP | "CAP三选二" | 一致性、可用性、分区容忍性最多满足两个 |
| E-R转换 | "一对一归任一,一对多归多,多对多独立建表" | 三种联系的转换规则 |
| "全部"问题 | "没有一门他没选" | NOT EXISTS双重否定 |
| WHERE vs HAVING | "WHERE分前不能聚,HAVING分后可用聚" | WHERE在分组前不能用聚合函数,HAVING在分组后可以 |
📚 相关笔记链接
[[关系代数]] [[数据控制]] [[数据库概述]] [[数据库设计过程]]
📅 生成日期:2026-05-15 | 📝 综合整理自数据库系统目录下4篇笔记并补充完善