简介这份《数据库原理与应用(第四版)》PDF是计算机专业学习数据库基础的实用教材适合正在学习数据库原理的本科生、备考期末考试或自学数据库技术的读者。内容系统梳理了数据与数据库、数据库管理系统、数据库系统组成、数据模型、三级模式与两级映像等核心知识点并对数据库安全性、视图更新、DBA职责等常见考点作了复习式归纳可帮助读者在短时间内建立完整的数据库知识框架。包体为1个PDF文件压缩包整体仅399KB方便下载后随时查阅。资源已有4854人浏览学习适合配合课程讲解用于考前冲刺、概念复习或入门自学尤其是需要掌握数据模型、模式结构和数据库系统组成等高频考点的人群。内容预览中还覆盖了选择题、填空题、问答题等典型复习题型便于对照知识点进行查漏补缺。1. 数据库原理与应用第四版 PDF一本教材背后的完整知识边界大学教材这个标签很容易让从业者低估《数据库原理与应用(第四版)》这类 PDF 的价值。目录翻下来关系代数、ER 图、范式、事务并发每个词都眼熟但真被问到为什么要这么写查询两个事务同时改一行会发生什么很多人答不到点子上。这本教材把数据库原理里最稳定的部分——关系模型、设计方法、事务理论——按顺序铺开这些内容二十年没怎么变恰恰是 MySQL、达梦、人大金仓这些具体产品背后共同的底座。它适合两类人想系统补一遍原理但没耐心的开发以及准备数据库面试却只会背概念的候选人。读法不是从头翻到尾而是按建模→查询→事务三条线对照实际数据库逐个验证。至于向量数据库这类新话题教材本身不会展开但索引与查询的底层逻辑仍然是这套原理的延伸吃透原书再迁移过去并不难。2. 关系模型与关系代数教材的第一个分水岭2.1 为什么已经在写 SQL还要回头读关系模型关系模型的价值不在表这个形态而在它的数学约束。Codd 把 Relation 定义为集合元组无序、无重复、每个属性落在确定域上。这些约束现在看像是理论上的清规戒律却直接决定了 SQL 的语义。SELECT DISTINCT之所以存在是因为关系语义不允许重复元组ORDER BY只改变查询结果的展示顺序不代表表里有物理顺序这两点直接影响你对索引和分页的理解。我一般会建议把教材里关系的基本性质一节反复读几遍。主键为什么不能为空外键为什么能被数据库约束检查NULL 为什么不能跟空字符串画等号答案都在这一节。最容易翻车的是 NULL 的语义NULL 表示未知跟它做任何比较的结果也是未知所以 WHERE 条件遇到 NULL 会整行被过滤。排查线上数据少了几行的时候十有八九是这里出了问题而不是查询写错。还有一个常被忽略的差异关系代数是集合运算而 SQL 实际执行是多重集运算。SELECT不加DISTINCT时结果允许重复行因为 SQL 走了 bag 语义而非 set 语义。教材在讲投影时说结果要去重但 MySQL 不加DISTINCT就不去重。面试问UNION和UNION ALL的区别时本质就是问这两种语义的取舍前者去重后者保留全部行。2.2 五种基本运算与 SQL 语句的对应关系关系代数是 SQL 的语义基础。教材讲五种基本运算选择、投影、并、差、笛卡尔积其中乘积配合条件可以演化出连接。把它们逐一对上 SQL写复杂查询时你对优化器在背后做什么就会更清晰。下面这张表是教材第二章到 SQL 之间的翻译表建议贴在工位旁边。关系运算符号对应 SQL作用选择σWHERE按条件过滤行不改变列集合投影πSELECT 列清单按列裁剪可加 DISTINCT 去重并∪UNION两个关系纵向合并隐式去重差−EXCEPT / NOT EXISTS保留左集合中不在右集合的行连接⋈JOIN按连接条件横向拼接两个关系2.3 用数据库增删改查的视角验证关系代数把教材结论搬到真实数据库里验证最快的方式是对着增删改查各写一遍。下面这组 SQL 可以在商品表和订单明细表上直接跑MySQL 和达梦都兼容-- 选择运算过滤价格大于 100 的商品行列保持不变 SELECT * FROM product WHERE price 100; -- 投影运算只取两列DISTINCT 体现关系无重复元组的集合特征 SELECT DISTINCT category_id, price FROM product; -- 连接运算订单明细关联商品补上商品名称 SELECT oi.order_id, p.product_name, oi.quantity FROM order_item oi JOIN product p ON oi.product_id p.product_id WHERE oi.quantity 2; -- 选择下推先过滤再连接缩小中间结果第一句对应选择运算WHERE 条件里的列有没有索引决定它是全表扫描还是索引过滤。第二句对应投影DISTINCT 去重背后有一次排序或哈希操作列多时开销不小没必要就别加。第三句最值得琢磨WHERE 里的 quantity 条件可以先于 JOIN 执行这叫选择下推。优化器通常会自动做这件事但如果你写的是子查询某些数据库不一定能把条件推导到最内层手动把过滤条件挪近表引用执行计划往往更快。三条命令都跑一遍关系代数运算的封闭性——运算结果还是关系、还能继续参加运算——就变成直觉了。提示在 MySQL 里执行EXPLAIN看执行计划时关注select_type和possible_keys两列能直接观察选择下推是否真的生效。3. 从 ER 图到关系模式数据库设计落地路径3.1 建模顺序与三要素判断教材里数据库设计的标准路线是需求分析 → 概念结构设计ER 图→ 逻辑结构设计关系模式→ 物理设计。实际项目和课程设计里大家总想跳过后两步直接建表结果就是表建到一半发现缺字段、多冗余返工成本比画图高得多。我第一次做订单模块时就吃过大意亏漏了中间表后面每个查询都在拼接脏数据。画 ER 图时抓住三个要素实体、属性、联系。判断一个对象应该建模成实体还是属性标准是它有没有独立描述的必要。订单金额是订单的属性但优惠券有自己的一堆字段就应该独立成实体。联系则必须判断基数1:1、1:N、M:N这三种情况转关系模式时的处理方式完全不同是最容易出错、也是面试最常考的点。M:N 联系必须拆成中间表这是课程设计里最常见的遗漏。学生选课、订单和商品、角色和权限都是 M:N。漏拆中间表的后果很典型要么 R 端信息在表中重复存储多行要么无法记录关联发生时点的数量、时间等附加属性。记住一个口诀M:N 一旦存在中间表就是唯一正解附加属性全部放到中间表上。3.2 订单系统的 ER 转关系模式实例用一个最小订单系统说明转换规则。实体包括客户、订单、商品客户和订单是 1:N订单和商品是 M:N所以订单明细是中间实体。转换方式如下表之后建表顺序按主表 → 从表 → 中间表执行保证外键引用的表先存在。联系基数转换方式客户-订单1:N在 N 端订单表加外键 customer_id订单-商品M:N拆出中间表 order_item存两个外键和数量客户-会员卡1:1外键放在任意一端通常放访问频繁的会员卡表CREATE TABLE customer ( customer_id INT PRIMARY KEY, -- 客户主键关系模型要求的完整性 customer_name VARCHAR(64) NOT NULL ); CREATE TABLE orders ( -- 订单N 端放外键 order_id INT PRIMARY KEY, customer_id INT NOT NULL, -- 外键列对应 1:N 的 N 端 order_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_orders_customer FOREIGN KEY (customer_id) REFERENCES customer(customer_id) ); CREATE TABLE order_item ( -- M:N 中间表联合主键 order_id INT NOT NULL, product_id INT NOT NULL, quantity INT NOT NULL DEFAULT 1, price DECIMAL(10,2) NOT NULL, -- 快照价格商品改价不影响历史订单 PRIMARY KEY (order_id, product_id), FOREIGN KEY (order_id) REFERENCES orders(order_id), FOREIGN KEY (product_id) REFERENCES product(product_id) );代码里三个参数细节值得说明。order_item用(order_id, product_id)联合主键防止同一商品在同一订单里重复录入这是 M:N 中间表的标准写法。price字段存下单时的快照价而不是去商品表实时读历史数据不可变是交易系统的硬约束。外键约束默认RESTRICT删除父记录时如果存在引用会被拒绝避免数据悬空。真实系统里为了写入性能会去掉部分外键但设计阶段保留它们能让约束关系显式化这是教材和工程实践的主要差异点。3.3 范式判断步骤与反范式场景范式是检验关系模式好坏的标准。实际工作中判断到 3NF 就够用BCNF 和更高范式主要出现在面试题里。判断步骤我习惯固定成三问有没有重复组1NF非主属性是否完全依赖主键2NF非主属性之间有没有传递依赖3NF。一个典型的 2NF 违反例子订单明细表里同时存 customer_name客户名称依赖订单而不是订单明细属于对联合主键的部分依赖拆出去才对。3NF 违反则是员工表里同时存部门编号和部门地址部门地址传递依赖员工主键。判断时先找主键再列所有非主属性与主键的依赖关系把不满足的列挪到它真正依赖的那张表。这套动作熟练之后看任何一张表都能在三秒内说出它破坏了几条范式。反范式不是不讲范式而是明确知道代价后的选择。报表查询需要跨五张表 JOIN 时预聚合列或状态冗余能把响应时间从秒级降到毫秒级代价是写入时要维护一致性通常用应用层双写或定时任务补偿。教材强调规范化工程强调权衡两个视角合起来才是完整的判断力。4. 事务、并发锁与恢复原理里最难嚼、系统里最要命的部分4.1 ACID 不是口号是日志与锁的分工教材关于事务的章节核心是 ACID 四个性质和它们在真实数据库里的落地方式。隔离性靠锁和版本控制持久性和原子性靠日志。最常见的学习误区是把 ACID 背成口号原子性不是操作要么全做要么全不做这么简单它依赖 undo log 在失败时回滚持久性依赖 redo log 先落盘再做数据页修改这就是预写日志 WAL 的基本思路。理解日志之后故障排查就有方向了。数据库崩溃重启后redo log 保证已提交事务不丢undo log 保证未提交事务被回滚。教材里日志先行那一页值得画一张时间线图推演事务提交时什么先写、什么后写崩溃点落在不同位置时恢复结果分别是什么。把这个推演做一遍比背十遍ACID 是什么有用得多面试问commit 之后断电会不会丢数据时你能直接说出关键参数和落盘顺序而不是含糊回答应该不会。4.2 隔离级别与锁的粒度对照四种隔离级别是教材与数据库面试题交汇最密集的部分。脏读、不可重复读、幻读三种异常分别对应隔离级别的递进。实现机制上基于锁的数据库用读锁、写锁和锁的持有时间来区分而 MySQL InnoDB 用 MVCC 版本链实现快照读。下面这张表把异常、级别和常见实现一条线串起来。隔离级别脏读不可重复读幻读常见实现READ UNCOMMITTED可能可能可能读不加锁READ COMMITTED避免可能可能语句级快照读锁即时释放REPEATABLE READ避免避免可能事务级快照MVCCSERIALIZABLE避免避免避免加锁读或串行化执行注意一个容易答错的细节MySQL 的 REPEATABLE READ 用 MVCC 快照加 next-key lock在绝大多数场景下避免了幻读所以它敢拿这个级别当默认值Oracle 和 PostgreSQL 默认是 READ COMMITTED达梦数据库的默认隔离级别也是读提交。面试里如果说MySQL RR 会幻读并不严谨更准确的表述是在 RR 下通过间隙锁实现了可重复读同时消除了大部分幻读。-- 事务级设置隔离级别MySQL 语法 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN; SELECT amount FROM account WHERE id 1 FOR UPDATE; -- 排他锁锁定行 UPDATE account SET amount amount - 100 WHERE id 1; COMMIT;FOR UPDATE是排查并发写问题时第一个要认识的语法。它给命中的行加排他锁直到事务结束才释放其他事务的更新会被阻塞。如果不加锁读在 READ COMMITTED 下两次读取之间别的会话改了数据就会看到不可重复读换成 REPEATABLE READ 的快照读则能稳定读到同一版本。锁的粒度也要心里有数行锁、间隙锁、表锁的冲突范围和性能开销完全不同间隙锁只出现在 RR 及以上级别。4.3 数据库死锁与锁等待的排查命令并发实操里真正头疼的数据库死锁。死锁是事务之间互相持有对方需要的锁形成等待环MySQL 检测到死锁会立刻回滚其中一个事务所以你看到的是 ERROR 1213 而不是挂死真正让系统变慢的通常是长时间的锁等待大量堆积之后就是连接池耗尽。排查时按下面两步走-- 第一步查看当前锁等待关系确认谁在等谁的锁 SELECT * FROM performance_schema.data_lock_waits\G -- 第二步死锁发生后的现场分析重点看 LATEST DETECTED DEADLOCK 段 SHOW ENGINE INNODB STATUS\GSHOW ENGINE INNODB STATUS输出的死锁段会记录双方执行的最近一条 SQL、持有的锁类型和等待的锁类型。看的时候优先找两条 SQL 的加锁顺序事务 A 先更新 order 再更新 order_item事务 B 相反死锁就发生在交叉点上。解决方向是让所有事务按相同顺序加锁其次把大事务拆小减少锁的持有时间。Oracle、达梦的排查思路一致只是视图名不同达梦可以通过等锁监控视图定位阻塞源会话。注意调小innodb_lock_wait_timeout只能让锁等待报错更早暴露不能解决死锁本身根治要靠减少加锁范围和控制事务长度。5. 把教材结论转成数据库面试答案与验证技巧5.1 高频问题的教材化回答口径数据库面试题里很多题直接长在教材目录上。三道最典型的为什么数据库用 B 树做索引四种隔离级别怎么区分范式设计到第几范式够用。回答口径我在前面各章已经给出这里补一个更通用的思路任何一道为什么题都要落到数据访问路径和代价上。B 树矮、支持范围扫描、叶节点顺序链接这就是索引题答案的骨架隔离级别题说出来哪个异常被哪个级别解决再补一句 MVCC 实现就已经超过大部分候选人。5.2 用北风数据库复现教材案例教材给的实例数据库最常用的是北风数据库Northwind它有客户、订单、商品、供应商一整套表结构天然适合练手。下载 SQL 脚本导入 MySQL 之后按下面几步验证教材结论-- 1. 验证外键约束删除被订单引用的客户预期报错或提示有依赖 DELETE FROM customers WHERE customer_id ALFKI; -- 2. 验证 3NF 设计统计每个客户的累计订单金额 SELECT c.customer_id, c.company_name, SUM(od.unit_price * od.quantity) AS total FROM customers c JOIN orders o ON c.customer_id o.customer_id JOIN order_details od ON o.order_id od.order_id GROUP BY c.customer_id, c.company_name ORDER BY total DESC;第一条命令如果成功删除说明导入脚本时外键约束没生效应该补开SET FOREIGN_KEY_CHECKS1再试顺便观察级联行为和RESTRICT的区别。第二条命令把三张表串起来同时检验连接条件、聚合和分组逻辑是订单分析报表的雏形。这套 SQL 在达梦、人大金仓和 Oracle 上同样通用差别只在字段类型细节这也验证了教材一句话SQL 标准是跨产品的最大公约数。5.3 课程设计搭不上线时的解法做数据库课程设计时最常卡住的是第一步题目拿到手不知道建几张表。回到教材的方法先画 ER 图确定实体间基数再转关系模式最后写建表和增删改查。全程用一个本地 MySQL 就够配合 DBeaver 这类客户端看执行计划教材里每个原理都能在半小时内验证一遍。这个闭环走通之后再去做数据库同步、连接池调优这些具体工程问题你会清楚地知道它们在原理体系中处于什么位置而不是东拼西凑找答案。本文还有配套的精品资源点击获取