简介：这份中南大学数据库试题资料面向高校计算机相关专业学生及备考数据库课程考试的学习者，围绕数据库管理系统基础、数据模型、关系模型、SQL语言、数据库保护与设计理论等核心考点组织内容，可用于期末复习、知识点梳理与自测检验。资源包共1个doc文件，约164KB，以复习总纲加试卷的形式呈现，涵盖概述、ER模型、关系模型、SQL语言、数据库保护、关系数据库设计理论、数据库应用设计等章节要点，并附有选择题、填空题、术语解释与简答题等题型。已有357人学习，适合需要系统过一遍考点、对照题目查漏补缺的读者，也可作为课堂学习之外的补充练习材料。

1. 数据库到底在管什么：从“文件柜”到“智能仓库”的认知跃迁

很多人第一次听到“数据库”三个字，脑子里浮现的是一张张 Excel 表格，或者电脑里某个叫“数据”的文件夹。这并不奇怪，因为日常接触的数据管理确实停留在“文件”层面。但如果你翻开一份数据库试题，第一道选择题往往就会问：数据库系统的体系结构是两级模式还是三级模式？这个问题背后藏着一个关键认知——数据库不是“存数据的文件”，而是一套有严格分层、有语言、有保护机制的信息管理系统。

打个比方，文件系统像家里堆满杂物的储藏室，东西能放进去，但找起来费劲，还容易放重复；数据库则像一个现代化智能仓库，有货架编号（模式）、有取货窗口（外模式）、有底层货道（内模式），还有管理员（DBMS）负责登记、校验、防冲突。数据库这门学科要解决的，就是“怎么把数据管得既安全又高效”的问题。搞懂它，你才能明白为什么考试里反复考三级模式、关系代数、范式分解——这些不是死记硬背的考点，而是这套仓库管理规则的核心条款。

2. 三级模式与数据独立性：为什么改底层不用动上层

2.1 三种模式各管什么：外模式、模式与内模式的角色分工

数据库系统最核心的架构设计，是把“数据长什么样”拆成三个视角来看。外模式是用户视角，也叫子模式或用户视图，描述的是某个用户或应用能看到的局部数据。模式是全局视角，也叫概念模式或逻辑模式，描述整个数据库的逻辑结构——有哪些表、哪些字段、哪些约束。内模式是存储视角，也叫物理模式，描述数据在磁盘上怎么存、有没有索引、压缩方式是什么。

用一个图书馆类比：外模式是读者面前的检索终端，只显示书名、作者、索书号；模式是馆藏总目录，记录所有书籍的分类和位置规则；内模式是书库里的实际排架方式，按什么顺序上架、用什么标签。读者不需要知道书库怎么排架，只需要会查终端。这就是数据库系统对外提供不同层次视图的意义——让不同角色只关心自己需要的那一层。

考试里常考的一道题是：“单个用户使用的数据视图的描述称为什么？”答案就是外模式。另一道题问“子模式 DDL 用来描述什么”，答案是数据库的局部逻辑结构。这两道题考的是同一个知识点：外模式对应局部、对应 user view、对应子模式，三个词说的是同一件事。

2.2 两级映象如何撑起数据独立性

三种模式之间靠两级映象连接。外模式/模式映象负责把用户视图映射到全局逻辑结构，模式/内模式映象负责把逻辑结构映射到物理存储。这两层映射的存在，直接支撑了数据库最引以为傲的特性——数据独立性。

数据独立性分两种。逻辑独立性是指全局逻辑结构改变时，比如增加一张表、修改一个字段，用户视图可以不变，应用程序也不用改。物理独立性是指存储结构改变时，比如换一种索引方式、调整文件组织，逻辑结构可以不变。考试里有一道经典选择题：“要保证数据库物理数据独立性，需要修改的是哪一层？”正确答案是模式与内模式的映射。因为物理存储变了，只要调整这层映射，让逻辑模式保持不变，上层就感知不到。

这里有个容易翻车的点：很多初学者把“修改内模式”当成答案，觉得存储变了当然改内模式。但题目问的是“保证独立性需要修改什么”，独立性是靠映射来吸收变化的，不是靠改模式本身。这个区别在选择题里反复出现，属于血泪经验级别的易错点。

提示：三级模式是“视角”，两级映象是“适配器”。视角可以不变，适配器负责吸收底层变化，这才是数据独立性的实现机制。

2.3 数据管理三阶段：为什么 DBMS 会取代文件系统

数据库管理系统（DBMS）不是凭空出现的，它是在文件系统管理数据暴露出严重问题之后才被引入的。数据管理经历了三个阶段：人工管理阶段、文件系统阶段、数据库系统阶段。

人工管理阶段，数据不保存、不共享、没有结构，程序和数据混在一起。文件系统阶段，数据可以长期保存了，文件内部有结构，但文件之间没有联系，数据冗余大、一致性差、程序与数据之间只有很弱的独立性。数据库系统阶段，数据面向全局组织，冗余度低，共享性高，由 DBMS 统一管理，具备安全性、完整性、并发控制和恢复能力。

考试里经常用一道选择题来区分：“下列四项中，不属于数据库特点的是？”选项里往往混入“数据独立性低”这样的干扰项。数据库的特点恰恰是数据独立性高、冗余度低、共享性高、由 DBMS 统一管理。把文件系统的缺点安到数据库头上，是出题人常用的套路。

3. 关系模型与关系代数：表背后的数学规则

3.1 关系模型的三根支柱：表、完整性约束与视图

关系模型是当前应用最广泛的数据模型，没有之一。考试里问“当前应用最广泛的数据模型是什么”，答案永远是关系模型。它的基本结构就是表，但一张表要成为合格的关系，必须满足几条硬规则：每一列是不可再分的数据项（原子性），每一列的数据类型相同，任意两行不能完全相同，行和列的顺序都无所谓。

完整性约束是关系模型的第二根支柱。表内约束包括域约束（字段取值范围）、主键约束（唯一标识一行）、唯一性约束（某列值不能重复）。表间约束主要靠外键和触发器实现，保证参照完整性——比如选课表里的学号必须在学生表里存在。考试里有一道填空题问“参照完整性规则是定义什么之间的引用规则”，答案是参照关系与被参照关系。

视图是第三根支柱。视图是从基本表或其他视图导出的虚表，数据库里只存视图的定义，不存视图的数据。考试里反复考一个限制：在视图上不能完成的操作是什么？答案是“在视图上定义新的基本表”。视图可以再定义视图、可以查询、在一定条件下可以更新，但不能反过来生出基本表。

3.2 关系代数：用集合运算描述“查什么”

关系代数是关系模型的操作语言，分两大类。传统集合运算包括并、交、差、笛卡尔积，专门的关系运算包括选择、投影、连接、除法。考试里有一道高频选择题：“五种基本关系代数运算是哪五个？”正确答案是并、差、笛卡尔积、投影、选择，也就是 ∪、-、×、π、σ。交和连接可以由这五个推导出来，所以不算基本运算。

选择是从行的角度筛，投影是从列的角度筛。这两个概念在选择题里经常被互换来制造干扰。有一道题问“从关系中挑选出指定的属性组成新关系的运算称为什么”，答案是投影；另一道题问“从关系中挑选出指定的元组组成新关系的运算称为什么”，答案是选择。属性对应列，元组对应行，记住这个对应关系就不会混。

连接运算里，等值连接和自然连接的区别也是简答题常客。等值连接按指定条件相等来拼接，自然连接要求比较的字段必须是同名属性，并且在结果里去掉重复列。通俗地说，自然连接是“自动去重的等值连接”。

3.3 用关系代数表达复杂查询：除法与“全部”的套路

关系代数应用题里最让人头疼的是“选修了全部课程的学生”这类查询。这类题的核心是除法运算，或者用差和笛卡尔积组合来表达“不存在没选过的课”。

以学生选课为例，求选修了全部课程的学生学号，思路是：先取所有课程的集合，再取每个学生已选的课程集合，看哪个学生的已选集合包含了全部课程集合。用关系代数写就是：π学号(选课) ÷ π课程号(课程)。除法在这里的含义是“对所有课程都成立”。

考试里还有一类题是“求没有选修某门课的学生学号”，用差集：π学号(学生) - π学号(σ课程号='5'(选课))。先找出选了这门课的人，再从全体学生里减掉。这个套路在 SQL 里对应 NOT IN 或 NOT EXISTS，关系代数和 SQL 是同一套逻辑的两种表达。

注意：关系代数里的除法和数学除法不是一回事，它解决的是“对所有”类查询。看到“全部”“所有”字样，优先想除法或双重否定。

4. SQL 语言与索引：从定义到查询的完整链条

4.1 DDL 与 DML 的分界线：建表归谁管，查数据归谁管

SQL 语言按功能分三块：DDL（数据定义语言）、DML（数据操纵语言）、DCL（数据控制语言）。DDL 负责建、删、改表结构，核心动词是 CREATE、DROP、ALTER。DML 负责操作表里的数据，核心动词是 INSERT、DELETE、UPDATE、SELECT。DCL 负责权限，核心动词是 GRANT、REVOKE。

考试里经常用选择题来区分：“下列 SQL 语句命令中，属于 DDL 语言的是哪个？”选项里混入 SELECT、GRANT、DELETE，正确答案是 CREATE。另一道题问“SQL 语言称为什么”，答案是结构化查询语言。虽然名字叫查询语言，但它远不止查询功能，定义、操纵、控制都归它管。

这里有个容易混淆的点：SELECT 属于 DML，不属于 DDL。很多人因为 SELECT 是“查询”就以为它单独一类，其实在经典分类里它就是 DML 的一部分。考试里还有一道题问“以下操作不属于数据更新的是哪个”，答案是查询。插入、删除、修改都算更新，查询不算。

4.2 索引的两种面孔：聚簇索引与非聚簇索引

索引是提高查询速度的关键结构，考试里主要考两种：聚簇索引和非聚簇索引。聚簇索引的索引项顺序与表中记录的物理顺序一致，也就是说数据行本身就是按索引键排好序存放的。非聚簇索引的索引项顺序与物理顺序无关，索引里存的是指向数据行的指针。

打个比方，聚簇索引像字典本身按拼音排好，你要找“阿”字直接翻到开头；非聚簇索引像书后面的索引页，告诉你“数据库”这个词在第 128 页，你还得再翻到那一页。一个表只能有一个聚簇索引，因为物理顺序只有一种；非聚簇索引可以有多个。

索引和约束的关系也是考点。主键约束和唯一性约束会自动创建唯一索引，但索引本身不等于约束。你可以手动建一个普通索引来加速查询，但它不保证唯一性。考试里有一道题问“索引项的顺序与表中记录的物理顺序一致的索引称为什么”，答案是聚簇索引。另一道题问“在 Sno 列上建立一个聚簇索引”的 SQL 写法，关键词是 CLUSTERED INDEX。

4.3 视图的能与不能：虚表的边界在哪里

视图在 SQL 里用 CREATE VIEW 定义，本质是一条被命名的查询语句。数据库只存这条查询的定义，不存结果数据。查询视图时，DBMS 把视图定义展开成对基本表的查询再执行。

视图的好处是简化查询、提供逻辑独立性、控制访问粒度。但视图有明确的边界：可以在视图上再建视图，可以查询视图，在一定条件下可以更新视图，但不能在视图上定义新的基本表。考试里这道题几乎年年出现：“在视图上不能完成的操作是什么？”答案就是定义新的基本表。

视图更新还有额外限制。如果视图定义里包含聚合函数、GROUP BY、DISTINCT、多表连接等，通常不可更新。定义视图时加 WITH CHECK OPTION 子句，可以保证通过视图插入或更新的行满足视图的筛选条件，防止“插进去却查不到”的尴尬。

5. 数据库保护与设计理论：安全、并发与范式

5.1 事务与 ACID：并发控制的基石

事务是数据库保护的原子单位。考试里对事务的定义是：用户定义的一个操作序列，这些操作要么全做要么全不做，是不可分割的工作单位。事务有四个特性，简称 ACID：原子性、一致性、隔离性、持久性。

并发操作如果不加控制，会带来三类问题：丢失更新、不可重复读、读脏数据。丢失更新是两个事务同时改同一数据，后写的覆盖先写的；不可重复读是一个事务两次读同一数据，中间被别的事务改了；读脏数据是读到了别的事务还没提交的中间值。考试里填空题经常考这三个名词，选择题则常问“数据库并发操作有可能带来的三个问题中包括什么”，答案是丢失更新。

解决并发问题靠封锁。排它锁（写锁）一旦加上，其他事务既不能读也不能写；共享锁（读锁）加上后，其他事务可以读但不能写。封锁协议分三级，一级解决丢失更新，二级解决读脏数据，三级解决不可重复读。死锁是两个事务互相等待对方释放锁，预防方法有一次封锁法和顺序封锁法。

5.2 常见误区：那些容易搞混的数据库概念

误区一：DB、DBMS、DBS 是一回事。这三个词长得像，但层次完全不同。DB 是数据库本身，就是存数据的仓库；DBMS 是管理数据库的软件，比如常见的数据库管理系统产品；DBS 是数据库系统，包含数据库、DBMS、应用程序和人员。混淆的原因是中英文缩写太接近。区分方法：DB 是数据集合，DBMS 是工具，DBS 是整套系统。

误区二：主键和候选码没有区别。候选码是能唯一标识元组的属性组，一个关系可以有多个候选码；主键是从候选码里选出来当家的那一个。考试里解释“候选码”时，要答“能唯一标识元组的最小属性组”，不能直接说主键。区分方法：候选码是候选集合，主键是最终当选者。

误区三：3NF 和 BCNF 是一回事。3NF 要求非主属性不传递依赖于候选码，BCNF 要求所有属性都不传递依赖于候选码。BCNF 比 3NF 更严格。考试里有一道选择题说“任何一个包含两个属性的关系模式一定满足 3NF 和 BCNF”，这是对的，因为两个属性的关系不可能有传递依赖。区分方法：3NF 只管非主属性，BCNF 管所有属性。

误区四：视图就是一张存起来的表。视图不存数据，只存定义。查询视图时动态展开。混淆的原因是视图用起来像表，能 SELECT。区分方法：基本表存数据，视图存查询语句。

误区五：聚簇索引和主键索引是一回事。主键约束会自动创建唯一索引，但不一定是聚簇索引。聚簇索引强调的是物理顺序一致，一个表只能有一个。区分方法：主键是逻辑约束，聚簇索引是物理组织方式。

5.3 范式与函数依赖：为什么表要拆开

关系数据库设计理论的核心问题是：一张表设计得不好，会出什么问题？答案是四类异常：数据冗余、修改麻烦、插入异常、删除异常。比如把学生信息和系主任信息放在一张表里，一个系有多个学生，系主任名字就重复多次，改一次要改多行，插入一个新系但没有学生时插不进去，删除最后一个学生时系主任信息也跟着丢了。

解决异常靠规范化。1NF 要求每个字段不可再分；2NF 在 1NF 基础上要求非主属性完全依赖于候选码，不能只依赖候选码的一部分；3NF 在 2NF 基础上要求非主属性不传递依赖于候选码。考试里填空题常考“如果一个关系满足 2NF，则该关系一定也满足什么”，答案是 1NF。

函数依赖是规范化的分析工具。完全函数依赖是决定因素整个属性组都起作用；部分函数依赖是只靠属性组的一部分就能决定；传递函数依赖是 A 决定 B、B 决定 C，于是 A 决定 C。考试里有一道分析题：学校关系模式包含学号、姓名、所在系、系主任、课程名、成绩，问候选码是什么。答案是（学号，课程名），因为成绩需要学号和课程名共同决定。所在系依赖学号，系主任依赖所在系，所以系主任传递依赖于学号，这张表不满足 3NF。

关系模式分解有两条准则：无损连接性和保持函数依赖。无损连接是指分解后再连接能还原原表，不丢信息也不多出假行；保持函数依赖是指分解后的关系模式集合能推出原来的所有函数依赖。考试里填空题直接考这两个准则的名字。

6. 什么时候该用数据库思维，什么时候别硬套

数据库这套体系不是万能药。判断什么时候用、什么时候别用，比背熟范式更重要。

适合用关系数据库的场景很明确：数据结构清晰、关系复杂、需要事务保证、需要多用户并发访问、需要长期维护数据一致性。比如学生选课系统、工资管理、图书借阅，这些场景里表与表之间有明确的参照关系，数据不能乱、不能丢、不能重复，关系模型加 SQL 加事务控制就是最合适的组合。考试里那些应用题——建表、建索引、建视图、写查询、做关系代数运算——练的就是这套场景下的基本功。

不适合硬套的场景同样值得注意。如果数据是非结构化的，比如大量文本、图片、日志流，关系表的行列结构反而成了束缚；如果数据量极大且写入频率极高，严格的事务和约束会拖慢吞吐；如果业务逻辑简单到只需要键值存取，上完整的关系模型就是杀鸡用牛刀。这些判断在考试里不会直接考，但在实际工作中踩坑的人不少。

还有一个边界是“范式不是越高越好”。考试里问“关系规范化程度最高的是哪个”，选项里 3NF 比 2NF 高、2NF 比 1NF 高，这是理论排序。但实际设计时，过度分解会导致表数量膨胀、连接查询变慢，有时候反范式冗余一两个字段反而更实用。考试考的是“知道范式怎么来的”，不是“无脑追求最高范式”。

我自己的习惯是：拿到一个设计题，先画 E-R 图，再转关系模式，然后逐条检查函数依赖，看有没有部分依赖和传递依赖，最后才决定拆到第几范式。这个顺序走一遍，比直接背“1NF 2NF 3NF”的定义管用得多。从那以后我每次看到“设计一个某某管理系统”的题，都强制自己先写函数依赖再动笔拆表，翻车次数明显少了。希望这套思路帮到你。

本文还有配套的精品资源，点击获取