简介这份中南大学数据库试题资料面向高校计算机相关专业学生及备考数据库课程考试的学习者围绕数据库管理系统基础、数据模型、关系模型、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”的定义管用得多。从那以后我每次看到“设计一个某某管理系统”的题都强制自己先写函数依赖再动笔拆表翻车次数明显少了。希望这套思路帮到你。本文还有配套的精品资源点击获取