企业官网建设流程全解析

简介：这份中南大学数据库试题资料面向高校计算机及相关专业学生，尤其适合正在备考数据库原理课程、需要系统梳理考点与自测的读者。内容围绕数据库管理系统基础、三级模式结构、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、ALTER；DML 是数据操作语言，负责“搬东西”——插入、删除、更新、查询，典型动词是 INSERT、DELETE、UPDATE、SELECT；DCL 是数据控制语言，负责“发门禁卡”——授权与收权，典型语句是 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。希望这套梳理帮到你，把数据库这团线真正捋成一条。

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