企业官网建设流程全解析

简介：这份中南大学数据库试题资料面向高校计算机及相关专业学生，尤其是正在备考数据库原理课程、需要系统梳理考点与自测的读者。内容围绕DBMS基础、三级模式结构、ER模型与关系模型、SQL语言、索引、数据库保护与并发控制、关系规范化理论及数据库应用设计六大板块展开，配有选择题、填空题、术语解释与简答题等题型，并附有复习总纲与参考答案，便于对照查漏补缺。资源包共1个doc文件，约164KB，结构紧凑，适合打印或电子阅读。目前已有357人学习，可作为课程复习与考前冲刺的实用练习材料。

1. 数据库到底在管什么：从一张越改越乱的学生成绩表说起

如果你手头有一张学生成绩表，刚开始只有十几行，用表格软件管得挺顺；等到要加课程、加老师、加选课记录，同一名学生的姓名和所在系被反复抄了好几遍，改一处漏一处，你就已经踩到了「数据库」这个概念真正要解决的问题。数据库不是「一堆表的集合」这么简单，它是一套让数据存得下、找得到、改得对、多人同时用还不打架的组织方式。中南大学数据库试题这份资料，把数据库管理系统、数据模型、关系模型、SQL、数据库保护和设计理论串成一条线，正好覆盖了「数据库是什么、为什么要有它、怎么区分相近概念」这几个最容易懵的地方。搞懂这条线，你看任何一张表、任何一句查询，都能知道它在整个体系里站哪个位置。

2. 为什么要有数据库管理系统：文件系统到底差在哪

2.1 数据管理的三个阶段，其实是一部「越来越省心」的历史

要理解数据库管理系统（DBMS）为什么存在，得先看它之前的日子怎么过。数据管理大致走过三个阶段：人工管理阶段、文件管理阶段、数据库管理阶段。人工管理阶段，数据跟着程序走，程序一换，数据就得重录，几乎没有独立性可言；文件管理阶段，数据能存成文件长期保存了，但文件内部有结构、文件之间没结构，同一个学生的姓名在成绩文件、学籍文件里各存一份，冗余高、容易不一致；到了数据库管理阶段，数据由 DBMS 统一组织和管理，全局结构由它维护，应用程序不再直接面对文件，而是面对数据库。

打个比方，文件系统像每个人自己拿一个笔记本记事情，记得挺全，但两个人记的同一件事对不上，你没法判断谁对；DBMS 像一个统一的档案室，进门有登记、取件有编号、改动有记录，谁改了什么一清二楚。这个差别落到具体指标上，就是数据共享性高、冗余度低、易扩展、数据独立性高，并且由 DBMS 统一管理安全性、完整性、并发和恢复。

这里有个容易被忽略的点：DBMS 不是「数据库」本身。数据库是数据集合，DBMS 是管理这套数据的软件，两者加上应用程序、数据库管理员和用户，才构成完整的数据库系统（DBS）。试题里反复考 DB、DBMS、DBS、DBAS 的区别，就是因为这几个词日常被混着用，一考就露馅。

2.2 三级模式与两级映象：数据独立性从哪来

数据库系统在结构上被抽象成三层：模式、外模式、内模式。模式是全局逻辑结构，描述整个数据库有哪些表、哪些字段；外模式是用户视图，是某个用户或某类应用能看到的那部分；内模式是物理存储结构，管数据在磁盘上怎么放、要不要建索引。三层之间靠两级映象连起来：外模式/模式映象保证逻辑独立性，模式/内模式映象保证物理独立性。

通俗地说，模式是「图书馆的总书目」，外模式是「某个读者借阅卡上能看到的书单」，内模式是「书实际放在几号书架第几层」。书架重新排布（改内模式），只要映象跟着改，读者看到的书单不变，这就是物理独立性；总书目调整了分类（改模式），只要映象跟着改，读者那张书单也不变，这就是逻辑独立性。试题里问「要保证物理数据独立性需要修改什么」，答案就是模式与内模式的映射，而不是去动模式或外模式本身。

提示：判断数据独立性题目时，先问「变的是哪一层」，再问「谁跟着改」。物理独立性对应内模式变化，逻辑独立性对应模式变化，映象是那个「翻译层」。

2.3 数据库语言的三件套：DDL、DML、DCL

数据库语言按功能分成三块：DDL 是数据定义语言，负责建表、删表、改表结构，典型语句是 CREATE、DROP、ALTER；DML 是数据操纵语言，负责插入、删除、更新、查询，典型语句是 INSERT、DELETE、UPDATE、SELECT；DCL 是数据控制语言，负责授权和收权，典型语句是 GRANT、REVOKE。这三块的分工，本质上是「改结构」「改内容」「改权限」三件事分开管。

很多初学者把 SELECT 当成 DDL，因为它「也是语句」，其实 SELECT 属于 DML 里的查询部分。试题里专门有一题问「下列 SQL 语句属于 DDL 的是哪个」，选项里混进 SELECT、GRANT、DELETE，就是考这个边界。记住一句话：动表结构的是 DDL，动表里数据的是 DML，动谁能动的是 DCL。

3. 数据模型与关系模型：表、键、视图到底怎么摆

3.1 数据模型的三要素，和「怎么评价一个模型」

数据模型不是「画个图」那么简单，它由三要素组成：数据结构、数据操作、完整性约束。数据结构说这个模型用什么方式组织数据（比如关系模型用表），数据操作说能对它做什么（查询、插入、删除、更新），完整性约束说哪些状态是合法的（主键不能重复、外键必须存在等）。评价一个数据模型，也主要看这三点是否表达能力强、操作是否方便、约束是否够用。

ER 模型是最常用的概念模型，用实体、属性、联系来描述现实世界，键约束保证实体能被唯一标识。它属于信息世界的模型，是现实世界到机器世界的中间层，所以试题里问「反映现实世界实体及实体间联系的信息模型是什么」，答案是 E-R 模型，而不是关系模型或层次模型。关系模型则是当前应用最广泛的数据模型，用二维表表示实体和联系，有严格的数学基础，数据独立性也最高。

3.2 表内的约束和表间的约束，是两套机制

关系模型的完整性约束分两层。表内约束管一张表自己：域约束限制字段取值范围，主键约束保证唯一且非空，唯一性约束保证不重复但允许空值。表间约束管两张表的关系，最典型的是外键，它保证参照关系里的外码值必须在被参照关系里存在。实现表间完整性有两种常见方式：外键和触发器。外键是声明式的，由 DBMS 自动检查；触发器是程序式的，用一段逻辑在插入、删除、更新时主动执行检查或级联动作。

打个比方，外键像小区门禁，刷卡时系统自动比对名单，不在名单里就进不去；触发器像门口的保安，除了查名单，还能根据情况打电话确认、登记、甚至通知住户。两者都能维护参照完整性，但外键更轻、更标准，触发器更灵活、能处理复杂规则。试题里问「表间完整性维护的两种实现方式」，答的就是触发器和外键。

3.3 视图不是表，它和基表的关系要分清

视图是从一个或多个基表（或其他视图）导出的虚表，数据库里通常只存视图的定义，不存它的数据。查询视图时，DBMS 把视图定义展开成对基表的查询再执行。这就带来一个常考的边界：在视图上可以查询、可以定义新的视图，但「在视图上定义新的基本表」是不行的，因为视图本身不是基本表，不能作为建表的底座。

视图的价值在于两点：一是简化查询，把复杂的多表连接包装成一个看起来像单表的东西；二是做权限控制，只把某几列、某几行暴露给特定用户。试题里问「在视图上不能完成的操作是什么」，答案就是「在视图上定义新的基本表」，这个点不搞清楚，很容易把视图和基表当成一回事。

3.4 关系代数：五种基本运算撑起整个查询

关系代数是用运算表达查询的语言，分两类：传统的集合运算（并、交、差、笛卡儿积）和专门的关系运算（选择、投影、连接、除法）。其中五种基本运算是并、差、笛卡儿积、选择、投影，其他运算可以由这五种推导出来。试题里问「五种基本关系代数运算」，选项里混进交和连接，就是考这个「基本」二字。

选择是从行上挑，投影是从列上挑，连接是把两张表按条件拼起来，除法用来表达「对所有」这类查询。举个具体例子，设有学生（学号，姓名，性别，年龄，所在系）、课程（课程号，课程名，先行课）、选课（学号，课程号，成绩）三张表，要查「选修了课程号为 5 的学生的学号和姓名」，思路是先对选课做选择（课程号=5），再和学生对学号做连接，最后投影出学号和姓名。这个「选择—连接—投影」的顺序，是关系代数题最稳的套路。

4. 常见误区：这几个概念一混，题就做不对

4.1 误区一：把 DB、DBMS、DBS 当成同义词

易混点：三个缩写长得像，日常口语又都说「数据库」。为什么混：大家说「连数据库」时，实际连的是 DBMS，存的是 DB，用的是 DBS 的一部分。怎么区分：DB 是数据本身，DBMS 是管理软件，DBS 是「数据库+DBMS+应用+人」的完整系统。做题时看到「负责全面管理和控制数据库系统的人」，那是 DBA，属于 DBS 的组成部分，不是 DBMS。

4.2 误区二：把主键、候选键、外键混着叫「键」

易混点：都带一个「键」字。为什么混：它们都跟唯一标识或引用有关。怎么区分：候选键是能唯一标识元组的属性或属性组，主键是从候选键里选出来的那一个，外键是本表里引用别的表主键的属性。试题里问「借阅关系的码是什么」，同一本书允许一个读者多次借阅但不能同时借多本，码就是书号+读者号+借期，因为只有加上借期才能区分同一个人对同一本书的多次借阅。

4.3 误区三：把聚簇索引和唯一索引当成一回事

易混点：都叫索引，都能加快查询。为什么混：建索引的语句长得像，UNIQUE 和 CLUSTERED 又常一起出现。怎么区分：聚簇索引决定表中记录的物理顺序，一张表通常只能有一个；唯一索引保证索引列值不重复，和物理顺序无关。主键约束默认会建唯一索引，但不一定是聚簇索引。试题里问「索引项顺序与表中记录物理顺序一致的索引叫什么」，答案是聚簇索引。

4.4 误区四：把 1NF、2NF、3NF 当成「越高越好」的等级

易混点：像游戏段位一样往上爬。为什么混：教材确实按 1NF、2NF、3NF 递进讲。怎么区分：范式是消除异常的判断标准，不是越高越实用。1NF 要求列不可再分，2NF 在 1NF 基础上消除非主属性对码的部分函数依赖，3NF 再消除传递函数依赖。试题里问「一个只满足 1NF 的关系可能存在哪些问题」，答案是数据冗余度大、修改麻烦、删除异常、插入异常。实际设计里，过度规范化会带来更多连接，反而影响查询效率，所以才有「反规范化」这个说法。

4.5 误区五：把等值连接和自然连接当成同一种连接

易混点：都按条件把两张表拼起来。为什么混：自然连接看起来就是「去掉重复列的等值连接」。怎么区分：等值连接按任意条件比较，结果里保留两张表的所有列；自然连接要求比较的是同名属性，并且结果里去掉重复的属性列。试题里专门问「等值连接与自然连接的区别」，答的就是这一点。

5. 数据库保护与设计理论：安全、恢复、并发、规范化怎么串起来

5.1 数据库被破坏的四个来源，对应四道防线

数据库保护要防的东西大致有四类：安全性问题（未授权访问）、完整性问题（数据不符合规则）、故障（硬件、软件、人为、病毒等导致数据损坏）、并发问题（多事务同时执行互相干扰）。对应的四道防线是：安全性控制（授权、视图、加密）、完整性控制（约束、触发器）、故障恢复（转储加日志）、并发控制（封锁协议）。

事务是这四道防线共同的单位。事务有 ACID 四个性质：原子性（要么全做要么全不做）、一致性（从一个合法状态到另一个合法状态）、隔离性（并发事务互不干扰）、持久性（提交后不丢）。试题里问「DBMS 中实现事务隔离性的子系统」，答案是并发控制子系统；问「恢复涉及的两个技术」，答案是数据转储和登记日志文件。这两个点经常被混，隔离靠锁，恢复靠日志和副本。

5.2 并发三大问题与封锁协议

并发执行可能引起三类问题：丢失更新（两个事务读同一数据，后写的覆盖先写的）、不可重复读（同一事务两次读同一数据结果不同）、读脏数据（读到了别的事务还没提交的数据）。解决办法是可串行化调度和基于锁的并发控制。锁有共享锁和排它锁，排它锁一旦加上，其他事务既不能读也不能写。封锁粒度可以是数据库、表、记录、字段，粒度越小并发度越高，但管理开销越大。

试题里问「事务 T 获得数据项 Q 的排它锁后能做什么」，答案是既可读又可写；问「最小的封锁粒度」，答案是字段。死锁是两个事务互相等对方释放锁，预防办法有一次封锁法和顺序封锁法，前者一次把所有要用的数据全锁上，后者规定统一的封锁顺序。

5.3 规范化理论：四种异常和函数依赖

关系模式设计不好，会带来四类异常：数据冗余、修改麻烦、插入异常、删除异常。根源是函数依赖没处理好。函数依赖分完全函数依赖、部分函数依赖、传递函数依赖。部分依赖是非主属性只依赖码的一部分，传递依赖是非主属性通过另一个非主属性间接依赖码。2NF 消除部分依赖，3NF 消除传递依赖。

试题里给过一个学校关系模式：学号、姓名、所在系、系主任、课程名、成绩。函数依赖包括学号→姓名、学号→所在系、所在系→系主任、（学号，课程名）→成绩。候选码是（学号，课程名），姓名和所在系部分依赖候选码，系主任传递依赖于学号，所以这个模式不满足 2NF，也不满足 3NF。关系模式分解有两条准则：无损连接性和保持函数依赖，两者不一定能同时满足，这是设计时的取舍点。

5.4 数据库应用设计的六个步骤

数据库应用设计一般分六步：需求分析、概念结构设计、逻辑结构设计、物理设计、数据库实施、运行和维护。需求分析产出数据字典和数据流图；概念设计产出 E-R 图；逻辑设计把 E-R 图转成关系模型；物理设计定存储结构和存取路径；实施阶段建库、编程序、组织数据入库；运行维护阶段做评价、调整和修改。

试题里问「将 E-R 图转换成关系数据模型属于哪个阶段」，答案是逻辑设计阶段；问「概念结构设计阶段得到的结果是什么」，答案是 E-R 图表示的概念模型。这两题看着简单，但把「概念设计」和「逻辑设计」的产物对调，是最高频的失分点。

6. 什么时候该用这套知识，什么时候别硬套

这套数据库知识最该用的场景，是你要判断一个数据问题该从哪一层下手。比如有人抱怨「系统越用越慢」，你可以先分清是查询没走索引（物理设计/索引问题）、是表结构冗余导致连接太多（规范化问题）、还是并发锁等待（并发控制问题）。再比如有人问「视图能不能当表用」，你知道视图能查、能再建视图，但不能在它上面建基本表，权限控制才是它的主场。试题里那些选择题、填空题、SQL 写语句，本质上都是在训练这种分层判断：看到「物理独立性」想到映象，看到「排它锁」想到可读可写，看到「3NF」想到消除传递依赖。

但也别硬套。规范化不是越高越好，实际项目里为了查询性能，经常故意保留一点冗余，这叫反规范化；索引不是越多越好，每个索引都要占空间、拖慢写入；外键约束在数据量很大、写入频繁的场景里，有时会用应用层校验替代，换取吞吐。试题考的是「标准答案」，工程里考的是「权衡」，这两者不冲突，但也不能互相替代。我自己的习惯是，每看到一个数据库概念，先问它解决的是「存得对」还是「找得快」还是「多人不打架」，再决定要不要在具体场景里用它。当年第一次做关系代数除法题，我盯着「选修了全部课程」这几个字半天没思路，后来把「全部」翻译成「不存在一门课他没选」，两个 NOT EXISTS 一嵌套，逻辑一下就通了。从那以后我每次遇到「所有」「全部」这类词，都强制先把它翻成「不存在反例」再动笔。希望这套拆概念的思路，也能帮到你。

这份资料把七章总纲和四套试题放在一起，从 DBMS 基础一路铺到 SQL 实战和设计理论，适合拿来对着目录逐章过一遍、再用试题检验自己哪一层没打通。需要完整内容的话，按页面提示获取即可。

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