简介这份中南大学数据库试题资料面向高校计算机及相关专业学生尤其适合正在备考数据库原理课程、需要系统梳理考点与自测的读者。内容围绕数据库管理系统基础、三级模式结构、ER模型与关系模型、SQL语言、索引机制、数据库保护与并发控制以及关系规范化理论等核心知识展开并配有选择题、填空题、术语解释与简答题等题型可帮助读者对照复习总纲逐章查漏补缺。资源包共1个doc文件约164KB以文档形式集中呈现复习提纲与试卷题目便于打印或电子阅读。目前已有357人学习适合作为课程期末复习与考前自测的参考材料读者可借助其中的章节总纲和典型题目快速定位薄弱环节理解模式映射、关系代数运算、事务ACID准则与范式分解等高频考点从而提升应试与实际问题分析能力。1. 数据库到底是什么从一张永远对不上的 Excel 表说起你有没有遇到过这种场面同一个客户的名字销售表里写“张三”财务表里写“张 三”售后表里又变成了“张三华东”。三张表各自都没错可一旦要把它们拼在一起看就对不上了。数据库这个概念本质上就是为了终结这种混乱而存在的。通俗地说数据库不是“一堆表”而是一套有规矩的数据保管体系——它规定了数据怎么存、谁能改、改坏了怎么救回来。很多人第一次接触“数据库”这个词是在复习资料或试题里看到 DB、DBMS、DBS 一连串缩写当场就懵了。其实只要抓住一句话数据库管的是“数据以及数据之间的联系”而不只是数据本身。搞懂这一点后面那些模式、范式、事务、锁全都是围绕“怎么把这份联系守住”展开的。这也是为什么一套成体系的数据库试题值得认真过一遍——它逼你把散落的概念串成一条线。2. 为什么需要数据库文件系统的三个老大难2.1 从“人工管理”到“数据库管理”的三级跳数据管理并不是一开始就长成今天这样。早期是人工管理阶段数据跟着程序走程序一换数据就得重录后来进入文件管理阶段数据能单独存成文件了但文件与文件之间还是各过各的。真正的转折点是数据库管理阶段的到来标志就是 DBMS数据库管理系统的引入。打个比方文件系统像一排各自上锁的抽屉每个抽屉里放什么、怎么放只有负责那个抽屉的人清楚DBMS 则像一个统一的库房管理员所有抽屉归他调度谁要取什么、能不能取、取完要不要登记都由他按规则办。这个转变带来的好处试题里反复考数据结构化、共享性高、冗余度低、易扩展、数据独立性高并且由 DBMS 统一管理控制。注意“统一管理控制”这几个字它对应的正是安全性、完整性、并发控制和故障恢复这四件事——后面第 5 章会专门展开。换句话说DBMS 不只是个存数据的软件它还是个带保安、带账本、带急救箱的管理员。2.2 三级模式与两级映象数据库的“分层图纸”数据库系统最容易被考、也最容易被学糊涂的是它的抽象层次。这里有三层模式、外模式、内模式。用一栋楼来类比最直观——内模式是这栋楼真正的水电管线和承重结构也就是数据在磁盘上怎么摆模式是整栋楼的户型总图描述有哪些房间、房间之间怎么连通对应全局逻辑结构外模式则是每个住户拿到的那张“我家视角图”只画跟他有关的房间对应不同用户看到的数据视图。三层之间靠两级映象连起来模式与内模式之间的映象保证了物理存储结构变了、逻辑结构可以不动这叫物理数据独立性模式与外模式之间的映象保证了全局逻辑结构变了、局部视图可以不动这叫逻辑数据独立性。试题里常问“要保证物理数据独立性需要修改什么”答案就是模式与内模式的映射——因为改的是底层存储靠这层映象把变化挡在逻辑层之外。这个点如果只背答案很容易忘理解了“映象是缓冲垫”就不会再错。2.3 数据库语言的三件套DDL、DML、DCL数据库语言不是一门单一语言而是一组分工明确的工具。DDL 是数据定义语言负责“画图纸”——建表、删表、改表结构典型动词是 CREATE、DROP、ALTERDML 是数据操作语言负责“搬东西”——插入、删除、更新、查询典型动词是 INSERT、DELETE、UPDATE、SELECTDCL 是数据控制语言负责“发门禁卡”——授权与收权典型语句是 GRANT 和 REVOKE。初学者最容易把 SELECT 归错类以为查询是“定义”其实它属于 DML。还有一处高频混淆GRANT 是 DCL 不是 DDL虽然它看起来也在“改东西”但它改的是权限而不是结构。把这三件套和具体动词对上号选择题里那种“下列属于 DDL 的是”基本就是送分题。3. 数据模型与关系模型图纸怎么画表怎么立3.1 数据模型的三要素与 ER 图的位置数据模型不是“一种模型”而是一套描述世界的规矩它由三部分组成数据结构静态地描述有哪些数据、怎么组织、数据操作动态地描述能对这些数据做什么、完整性约束规定数据必须满足的条件。评价一个数据模型好不好就看这三方面表达得够不够、准不准。在众多模型里ER 模型实体—联系模型位置很特殊它属于信息世界的模型是现实世界到机器世界之间的中间层次最常用的表示方法就是 ER 图。试题里问“反映现实世界中实体及实体间联系的信息模型是什么”答案就是 ER 模型而不是关系模型。这个区分很关键——ER 模型是给人看的草图关系模型才是最终落到机器里的表。逻辑设计阶段的核心任务正是把 ER 图转换成关系模型。3.2 关系模型表、键与三类完整性关系模型是当前应用最广泛的数据模型落到操作层面就是一张张表。表里有几样东西必须分清域是某一列取值的范围主键是能唯一标识一行的属性或属性组候选键是所有能当主键的候选者外键是本表中引用另一张表主键的那个属性。完整性约束分三类。实体完整性要求主键不能为空、不能重复参照完整性要求外键的取值必须能在被参照表里找到对应或者允许为空用户定义完整性则是业务自己加的规则比如年龄必须在 18 到 22 之间。表间的参照完整性有两种实现方式外键和触发器。外键是声明式的写清楚规则由 DBMS 自动把关触发器是程序式的用一段逻辑在特定操作发生时执行检查。打个比方外键像门禁系统预设的白名单触发器像门口临时站了个保安能做的事更灵活但也要自己维护。3.3 关系代数用集合运算“问”数据关系代数是关系模型的操作表示分两大类。传统集合运算是并、交、差、笛卡尔积专门的关系运算则是选择、投影、连接、除法。这里有一组极易混淆的对照选择是从行里挑元组投影是从列里挑属性。试题里专门用“从关系中挑选出指定的属性组成新关系”和“挑选出指定的元组组成新关系”两道题来卡人就是在考这个方向感。五种基本关系代数运算常被考到并、差、笛卡尔积、投影、选择也就是 ∪、-、×、π、σ。注意交和连接虽然常用但可以由基本运算推导出来所以不算“基本”。至于“选修了全部课程的学生”这类题本质是除法或者用双重 NOT EXISTS 表达属于关系代数里的硬骨头理解了“全部”等于“不存在一门没选的课”逻辑就顺了。4. 常见误区这几个概念一混题就白做了4.1 误区一DB、DBMS、DBS、DBAS 是一回事易混点在于四个缩写长得像、又总一起出现。为什么混因为日常口语里大家统称“数据库”把边界抹平了。怎么区分DB 是数据库本身也就是那份数据集合DBMS 是管理它的软件比如某类关系型数据库管理系统DBS 是数据库系统等于数据库加 DBMS 加应用加人DBAS 是数据库应用系统偏重面向具体业务的那一层。一句话记DB 是货DBMS 是管理员DBS 是整个仓库加管理员加制度DBAS 是仓库对外开的那个店。4.2 误区二视图就是一张存了数据的表易混点在于视图查起来跟表一模一样。为什么混因为用起来没差别。怎么区分数据库中只存放视图的定义不存放它对应的数据数据仍然来自基本表。所以“在视图上定义新的基本表”这种操作是不成立的视图上能查询、能在一定条件下更新、能再定义视图但不能反过来长出基本表。这个点在选择题里几乎年年出现。4.3 误区三聚簇索引和唯一索引是一类东西易混点在于两者都叫“索引”还都能加在列上。为什么混因为名字里都带“索引”容易以为只是性能差别。怎么区分聚簇索引说的是物理顺序——索引项的顺序与表中记录的物理顺序一致一张表通常只能有一个唯一索引说的是约束——它对应候选键保证列值不重复。主键约束会自动带来唯一性而聚簇是存储层面的安排。试题里“索引项的顺序与表中记录的物理顺序一致”问的就是聚簇索引别答成唯一索引。4.4 误区四安全性、完整性、并发控制、故障恢复可以互相替代易混点在于四者都属于“数据库保护”听起来都是“防出事”。为什么混因为目标都是让数据别坏。怎么区分安全性防的是“不该看的人看了”靠授权和视图控制完整性防的是“不该有的数据进来了”靠约束和触发器并发控制防的是“多人同时改改乱了”靠锁和可串行化调度故障恢复防的是“系统崩了数据没了”靠转储和日志。试题问“数据库保护不包括的是”往往就是拿“控制数据冗余”这种不属于保护范畴的选项来干扰。4.5 误区五范式越高越好直接上 3NF 准没错易混点在于规范化程度越高听起来越“高级”。为什么混因为教材主线就是 1NF 往 3NF 推。怎么区分范式解决的是冗余和异常但分解过度会带来连接代价上升查询变慢。实际设计里常做适度反规范化。试题里“关系规范化程度最高的是”问的是满足哪个范式那是概念题真到工程里范式是工具不是信仰这一点要分清楚。5. 数据库保护与设计理论出事了怎么救设计时怎么防5.1 事务与 ACID一组操作要么全成要么全败事务是并发控制的基本单位也是恢复的基本单位。它有一个很贴切的类比转账。从 A 账户扣钱和给 B 账户加钱必须捆成一个不可分割的动作不能扣了钱却没加上。这就是原子性。一致性指事务前后数据都满足约束隔离性指并发事务之间互不干扰持久性指一旦提交即使系统崩溃也不能丢。四条合称 ACID。数据库被破坏的来源通常归为四类硬件故障、软件错误、操作失误、人为破坏。恢复靠两样技术数据转储和登记日志文件。转储是定期留副本日志是记录每一步改动出事时用副本加日志把数据推回一致状态。这里有个高频考点日志文件必须“先写日志后写数据库”顺序反了恢复时就可能对不上账。5.2 并发控制锁的粒度与可串行化并发执行会带来三类经典问题丢失更新、不可重复读、读脏数据。判断一个并发调度是否“正确”标准是可串行化——它的执行效果等价于某个串行执行。实现手段是基于锁的并发控制协议锁的目的就是让冲突的操作排队。锁有粒度之分从大到小可以是数据库、表、记录、字段。粒度越大管理开销越小但并发度越低粒度越小并发度高但锁管理更复杂。试题里问“最小的封锁粒度”答案通常是字段。还有两个概念要分清排它锁写锁拿到后既可读又可写其他事务不能访问共享锁读锁只允许读。死锁则是两个事务互相等对方释放锁预防办法有一次封锁法和顺序封锁法——前者一次锁全安全但并发度低后者规定统一加锁顺序从源头避免循环等待。5.3 函数依赖与范式异常是怎么长出来的关系模式设计不好会冒出四类异常数据冗余度大、修改麻烦、插入异常、删除异常。根子在函数依赖上。函数依赖描述的是“一个属性定了另一个属性就跟着定”比如学号定了姓名就定了。部分函数依赖是指非主属性只依赖候选键的一部分传递函数依赖是指 A 定 B、B 定 C于是 A 间接定 C比如学号定所在系、所在系定系主任。范式就是逐层消除这些毛病1NF 要求每列不可再分2NF 在 1NF 基础上消除非主属性对候选键的部分依赖3NF 再消除传递依赖。转换条件要记牢满足 2NF 一定满足 1NF反之不成立。关系模式分解有两条准则无损连接性和保持函数依赖两者都满足才算理想分解。这里有个反直觉的结论值得留意——任何包含两个属性的关系模式一定满足 3NF也一定满足 BCNF因为属性太少压根凑不出部分依赖和传递依赖。5.4 数据库设计的六个步骤应用设计是一条流水线需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、运行和维护。每一步的产出要能对上号需求分析出数据字典和数据流图概念设计出 ER 图逻辑设计把 ER 图转成关系模型物理设计定存储结构、存取路径和索引实施阶段建库、编程序、试运行最后是长期的评价、调整与维护。数据字典本身又分五部分数据项、数据结构、数据流、数据存储、处理过程其中数据项是不可再分的数据单位。6. 什么时候该用这套知识什么时候别硬套先说该用的场景。如果你正在准备数据库相关的考试这套“概念—模型—SQL—保护—设计”的骨架就是最省力的复习路径因为它把零散知识点挂在了同一条逻辑链上先有数据管理的需求才有三级模式和语言分工先有表间联系才有完整性和参照策略先有并发和故障才有事务和锁。按这条链走选择题里的“下列不属于”“下列说法不正确”就不容易翻车。再往实际工作里说做业务系统建模时ER 图转关系模型、主键与外键的取舍、什么时候加索引、什么时候适度反规范化这些判断都直接来自这套理论。比如一张表频繁按某列范围查询聚簇索引可能比多建几个普通索引更划算而一张更新极频繁的表索引建太多反而拖慢写入。再说别硬套的地方。第一别把范式当教条。3NF 是设计起点不是终点报表类、日志类场景里适度冗余换查询速度是常规操作硬推到 BCNF 有时得不偿失。第二别把锁粒度往最小处调。字段级锁听起来精细但锁管理开销可能吃掉并发收益实际系统多在记录级和表级之间权衡。第三别把“视图能更新”当成普遍能力。视图更新有诸多限制涉及聚合、分组、多表连接的视图往往不可更新设计时就要想清楚这层视图是给人查的还是给人改的。第四别把关系代数的“全部课程”写法只当考试技巧它背后是“双重否定表达全称量词”的思维写复杂 SQL 时同样管用。我自己的习惯是每拿到一个关系模式先不急着写 SQL而是先问三件事——候选键是什么、有没有部分依赖或传递依赖、表间参照关系怎么落地。这三问走完后面建表、加约束、写查询基本不会返工。早些年我图快直接照业务字段堆表结果一个删除操作牵出一串异常回头改结构比从头设计还费劲。从那以后我每次动手前都强制走一遍“键—依赖—参照”的检查哪怕只是个小 Demo。希望这套梳理帮到你把数据库这团线真正捋成一条。本文还有配套的精品资源点击获取