数据库系统核心原理与设计：从三级模式到SQL实践

简介这份中南大学数据库试题资料面向高校计算机及相关专业学生尤其适合正在备考数据库原理课程、需要系统梳理考点与自测的读者。内容覆盖DBMS基础、三级模式结构、ER模型与关系模型、SQL语言、索引与完整性约束、数据库保护与并发控制、关系规范化理论及数据库应用设计六步骤等核心章节并附有选择题、填空题、术语解释与简答题等多种题型可帮助读者对照复习总纲逐章查漏补缺。资源包共1个doc文件约164KB以复习提纲加试卷的形式组织目录按章节推进便于按知识点定位练习。目前已有357人学习适合需要借助真题检验掌握程度、强化易错概念理解的学习者使用。1. 数据库到底是什么从“文件柜”到“智能仓库”的认知跃迁很多人第一次听到“数据库”这个词脑子里浮现的可能是电脑里一个叫“数据”的文件夹或者一张密密麻麻的 Excel 表格。这其实是个挺常见的误会。打个比方你家里的文件柜每个人都能往里塞东西找起来全靠记忆和运气这就是早期的“文件系统”。而数据库更像是一个配备了专业管理员、智能索引系统和严格安保措施的现代化智能仓库。你告诉管理员“我要找去年所有经管系学生的成绩单”他能在几秒内精准地把东西递到你手上而不是让你自己去一堆纸箱里翻。这个“智能仓库”之所以值得搞懂是因为它几乎支撑着你日常生活的每一个数字角落——从手机里的通讯录、银行账户的流水到购物网站的订单记录背后都是一个数据库在默默运转。而“中南大学数据库试题”这份资料本质上就是一张带你熟悉这个仓库运作逻辑的“全景地图”。它不教你搬砖而是让你理解仓库的分区规则数据模型、存取指令SQL 语言、安保系统数据库保护以及空间规划设计理论。搞懂这些你再看任何信息系统都不会觉得它是个黑匣子。2. 数据库系统的骨架三级模式与数据独立性2.1 为什么需要“三级模式”给数据穿上三层衣服想象一下你是一个服装品牌的总设计师。你脑子里有一个完整的服装系列构想全局逻辑结构这是第一层。各地的门店店长根据当地气候和顾客喜好向你申请特定款式的上架清单用户视图这是第二层。而工厂里的缝纫机具体用什么型号的线、布料存放在哪个货架的哪个格子里物理存储这是第三层。这三层分别对应数据库的模式Schema、外模式External Schema和内模式Internal Schema。为什么非要搞这么复杂核心目的是为了“解耦”。如果没有这三层工厂换个缝纫机存储结构改变所有门店的清单用户视图都得跟着重写这显然不现实。数据库用两级映象模式/内模式映象、外模式/模式映象把这三层隔离开。当内模式物理存储变了只要调整模式/内模式的映象模式逻辑结构可以保持不变这叫物理数据独立性。当模式变了调整外模式/模式的映象外模式用户看到的视图可以不变这叫逻辑数据独立性。试题里反复考“要保证物理数据独立性需要修改的是模式与内模式的映射”就是在考这个解耦机制。提示很多初学者会把“模式”和“内模式”搞反。记住模式是“表长什么样”内模式是“表在硬盘上怎么存”。2.2 数据管理的三个阶段从“散养”到“精装”要理解 DBMS数据库管理系统为什么存在得先看看没有它的日子。数据管理经历了三个阶段人工管理阶段数据不保存、不共享、无结构、文件系统阶段数据可以文件形式长期保存但共享性差、冗余度高、独立性差、数据库系统阶段数据结构化、共享性高、冗余度低、独立性高。文件系统阶段就像每家每户自己挖一口井取水数据是面向特定程序的A 程序产生的文件B 程序很难直接用想用就得复制一份导致同样的数据存了好几遍冗余改了一处忘了另一处不一致。DBMS 的出现相当于建了一个自来水厂所有程序都从同一个管道取水数据由 DBMS 统一管理。试题里问“不属于数据库特点的是”答案往往指向“数据独立性低”或“数据冗余大”因为那恰恰是文件系统的毛病。2.3 DB、DBMS、DBS、DBAS四个容易“串门”的概念这四个缩写是选择题的常客它们的关系像一套俄罗斯套娃。DBDatabase数据库是那个智能仓库本身是数据的集合。DBMSDatabase Management System数据库管理系统是仓库的管理员是位于用户和操作系统之间的一层软件负责建库、存取、控制。DBSDatabase System数据库系统是整套班子包括仓库DB、管理员DBMS、硬件、软件以及使用它的人DBA 和用户。DBASDatabase Application System数据库应用系统则是基于这套班子开发出来的具体业务系统比如学校的教务系统。通俗地说DB 是“货”DBMS 是“叉车和仓管”DBS 是“整个物流中心”DBAS 是“你在手机上用的那个购物 App”。试题里让你解释“数据库系统”标准答案必须包含 DBMS、DB 和相关人员缺一不可。3. 数据模型与关系模型从画草图到建表格3.1 数据模型的三要素结构、操作与约束数据模型不是一张具体的表而是一套“设计图纸的规范”。它由三要素组成数据结构描述数据库的组成对象以及对象之间的联系比如“学生”和“课程”是两个对象它们之间有“选课”联系、数据操作对数据允许执行的操作集合比如增删改查、完整性约束保证数据正确有效的规则比如“学号必须唯一”。评价一个数据模型好不好就看这三点是否清晰、是否易于理解、是否便于实现。试题里问“如何评价数据模型”其实就是让你从这三要素的完备性和实用性去谈。ER 模型实体-联系模型之所以常被用作概念设计工具就是因为它的三要素实体、属性、联系极其贴近人的思维画出来的 E-R 图连非技术人员都能看懂。3.2 关系模型的核心表、键与完整性关系模型是目前应用最广的模型没有之一。它把世界看作一张张二维表。表里的每一行叫元组每一列叫属性。为了让表里的数据不打架需要完整性约束来镇场子。表内的约束包括域约束列的值必须来自同一个域比如年龄不能填“张三”、主键约束唯一标识一行且不能为空、唯一性约束某列值不能重复但可以为空。表间的约束主要靠外键和触发器来维护。这里有个血泪经验主键和唯一性约束经常被混为一谈。主键是“身份证”一人一号不能空唯一性约束是“手机号”理论上也可以唯一但允许你暂时没填空值。试题里考“索引与 UNIQUE 和 PRIMARY 的关系”就是在问主键上会自动建唯一索引但唯一索引的列不一定是主键。3.3 关系代数数据库的“数学方言”关系代数是用数学运算的方式来表达查询需求。它分两类传统的集合运算并、交、差、笛卡尔积和专门的集合运算选择、投影、连接、除法。选择是“挑行”投影是“挑列”连接是把两张表按条件拼起来。试题里反复出现的“求选修了全部课程的学生”就是除法运算的经典场景。用大白话讲你有一张“学生-课程”选课表还有一张“课程”全表除法就是问“哪些学生把课程表里的课全选了一遍”。在 SQL 里这个除法通常用双重NOT EXISTS来实现逻辑是“不存在一门课这个学生没有选”。这个双重否定绕晕过无数人但理解了“全部”等于“没有遗漏”就通了。4. SQL 语言与索引跟数据库对话的“普通话”4.1 DDL 与 DML建房子和住房子SQL 语言按功能分最核心的是DDL数据定义语言和DML数据操纵语言。DDL 负责“建房子”包括CREATE建表、建视图、建索引、ALTER改结构、DROP拆房子。DML 负责“住房子”包括INSERT插入、DELETE删除、UPDATE更新、SELECT查询。试题里让你写“建立教师工资表”的 SQL用的就是CREATE TABLE里面要定义列名、类型和主键。让你“增加一个误餐费列”用的是ALTER TABLE ... ADD COLUMN。让你“删除基本表”用的是DROP TABLE。这些语句的动词就是命令改一个字意思全变。比如DELETE是删行表还在DROP是删表连锅端TRUNCATE是清空行表还在但不可回滚这三个在考试和工作中都是高频踩坑点。4.2 视图与基表窗户和房子视图View是从一个或多个基表或视图导出的“虚拟表”。它不存储实际数据只存储定义。打个比方基表是房子里的房间视图是你在墙上开的一扇窗。你透过窗户能看到房间里的东西但窗户本身不占房间面积。试题里问“在视图上不能完成的操作”答案通常是“在视图上定义新的基本表”——你可以基于视图再建视图窗上开窗但你不能把窗户变成一间实体房间。视图的好处是安全只暴露部分列和简化查询把复杂的连接封装起来。但更新视图有限制因为最终要落到基表上如果视图定义里包含了聚合函数或DISTINCT通常就不可更新了。4.3 聚簇索引与非聚簇索引字典的两种排法索引是为了加速查询。聚簇索引Clustered Index决定了表中数据的物理存储顺序就像一本按拼音排序的字典正文本身就是按拼音排的一个表只能有一个聚簇索引。非聚簇索引Non-clustered Index是另外建的一本“目录”目录里记着拼音和页码正文还是乱序的一个表可以有多个。试题里考“索引项的顺序与表中记录的物理顺序一致的索引称为什么”答案就是聚簇索引。聚簇索引适合范围查询比如按日期查因为数据物理上挨着非聚簇索引适合精确匹配比如按学号查因为要回表。主键上默认建的是聚簇索引在多数数据库里而UNIQUE约束上建的是非聚簇的唯一索引。这个区别在写 SQL 时不用显式指定但面试和考试常问。5. 数据库保护与设计理论给数据上保险和做体检5.1 事务与 ACID要么全做要么全不做事务Transaction是数据库保护的基石。它是一组不可分割的操作序列要么全部成功要么全部失败回滚。事务有四个特性简称ACID原子性Atomicity不可分割、一致性Consistency从一个合法状态到另一个合法状态、隔离性Isolation并发事务互不干扰、持久性Durability提交后永久生效。试题里问“DBMS 中实现事务隔离性的子系统”答案是并发控制子系统。因为隔离性就是靠锁机制来实现的。并发操作如果不加控制会带来三类问题丢失更新两个事务同时改后改的覆盖了先改的、不可重复读同一事务内两次读同一数据结果不一样、读脏数据读到了别的事务还没提交的数据。解决这些问题靠封锁协议比如一级封锁协议改前加排它锁、二级读前加共享锁、三级读前加共享锁并保持到事务结束。5.2 规范化理论给表做“瘦身手术”关系模式设计不好会带来四种异常数据冗余同样的信息存多遍、修改麻烦改一处要改多处、插入异常想插一条数据但缺主键信息插不进去、删除异常删一条数据把别的信息也带走了。解决之道是规范化通过函数依赖分析把大表拆成小表。1NF要求列不可再分原子性。2NF在 1NF 基础上要求非主属性完全依赖于候选码消除部分函数依赖。3NF在 2NF 基础上要求非主属性不传递依赖于候选码消除传递函数依赖。打个比方1NF 是“每个格子里只能放一个值”2NF 是“每个格子里的值必须由整个身份证号决定不能只由身份证号的一部分决定”3NF 是“每个格子里的值不能通过别的格子间接决定”。试题里问“一个只满足 1NF 的关系可能存在的四方面问题”答案就是那四种异常。5.3 数据库设计的六个步骤从需求到运维数据库应用设计不是上来就建表而是一个六步流程需求分析搞清楚要存什么、怎么用产出数据字典和数据流图、概念结构设计画 E-R 图把现实世界抽象成实体和联系、逻辑结构设计把 E-R 图转换成关系模式即建哪些表、物理设计选存储结构、建索引、实施建库、写程序、录数据、运行维护监控、调优、备份。试题里问“将 E-R 图转换成关系数据模型的过程属于哪个阶段”答案是逻辑设计阶段。这个顺序不能乱需求没搞清楚就画 E-R 图等于没打地基就砌墙。很多项目翻车不是 SQL 写错了而是需求分析阶段漏了一个关键业务规则导致后面表结构怎么改都别扭。6. 什么时候该用数据库思维什么时候别硬套数据库这套东西虽然强大但不是所有场景都值得搬出来。判断标准其实就一条数据之间有没有复杂的关联以及有没有多人同时读写的一致性要求。如果你只是存几十条配置项用一个 JSON 文件或键值对存储就够了上数据库属于“用高射炮打蚊子”反而增加了部署和维护成本。如果你要做的是日志采集数据只追加不修改那用专门的日志系统或列式存储比传统关系库更合适。但如果你面对的是“学生选课”“订单支付”“库存扣减”这类场景数据之间有关联学生关联课程订单关联商品且必须保证“扣了库存就得生成订单”这种原子性那就必须用数据库的事务和约束来兜底。注意规范化不是越高级越好。3NF 能消除大部分异常但过度规范化会导致表拆得太碎查询时要做大量连接性能反而下降。实际工程中经常会在 3NF 的基础上做适度反规范化比如冗余一两个字段用空间换时间。试题里考“关系规范化程度最高的是关系满足”答案是 3NF在 1NF、2NF、3NF 中但 BCNF 比 3NF 更严格只是试题范围通常到 3NF 为止。举个具体例子。试题里有一道综合题查询“选修了全部课程的学生学号和姓名”。如果你用关系代数就是除法如果你用 SQL就是双重NOT EXISTS。这个查询之所以经典是因为它逼着你理解“全部”这个量词在集合运算里的表达方式——不是去数数而是去验证“不存在反例”。这种思维在写业务代码时同样有用比如“找出所有没有未读消息的用户”本质也是“不存在一条未读消息关联到该用户”。我刚开始学数据库时总觉得范式理论是纸上谈兵直到有一次帮人改一个选课系统发现成绩表里存了学生姓名和课程名结果学生转系后姓名没同步成绩单上出现了两个不同系的名字。从那以后我每次设计表结构都强制自己先问三句话这张表的主键是什么有没有非主属性依赖了非主键字段有没有字段可以通过其他字段推导出来这三问基本能挡住 80% 的异常隐患。希望这份梳理能帮你在面对数据库试题或实际设计时少一点懵多一点笃定。本文还有配套的精品资源点击获取