企业官网建设流程全解析

很多自学《数据库系统概论》第五版的同学，基本都会卡在同一个地方：基础篇（一）学数据模型还行，（二）学关系代数、关系演算也还行，（三）学SQL更是信心满满，结果到了基础篇（四），突然感觉知识点变碎。自主存取控制、强制存取控制、审计、加密、实体完整性、参照完整性、触发器……每个名词单独看都能理解，合上书却说不清它们各自到底在解决什么问题，更别提考试时那些需要自己写SQL授权的题目了。

这种“断层感”其实非常正常。因为前半部分学的是“数据怎么组织、怎么查询、怎么写”，后半部分学的是“数据怎么防、怎么守、怎么保证不出错”。一个是功能逻辑，一个是安全与质量逻辑，思维方式完全不同。这篇文章我就围绕《数据库系统概论》第五版基础篇（四）的核心内容，把安全性与完整性这两大块拆开揉碎：它们各自的边界在哪、教材里的机制是怎么设计的、放在真实数据库里又该怎么用、考试里有哪些高频场景，一次性捋清楚。

如果你正在准备专业课考试、考研复试，或者只是想把数据库的“防护体系”真正搞懂，这篇文章就是按我的复习思路整理出来的“图解式”笔记，可以直接照着用。

1. 基础篇（四）到底学什么：安全性与完整性的作用边界

1.1 为什么这两章会让人越学越散

先说说这两章在整本教材里的位置。基础篇前三章解决的是数据库“怎么用”：数据用什么结构存、关系怎么表达、SQL怎么写。到了第四章数据库安全性和第五章数据库完整性，教材的视角从“你会不会操作”切换到了“数据能不能被信任、被合法访问”。

你会发现这两章有一个共同点：它们的知识点不是一条主线下来的，而是围绕“用户访问数据”这条路径上的多个关卡展开的。安全性的主线可以理解为一条访问链路：

用户发起连接 → 身份鉴别 → 存取控制判断权限 → 视图进一步隔离 → 审计记录行为 → 加密保护存储和传输

完整性则是另一条独立路线：数据写入数据库之前，数据库系统自己先当一次“质检员”，检查这条记录合不合规则，不合规则就不让进。

理解了这个结构，你再去看那些名词就不会觉得它们是一盘散沙。它们其实是守在不同关卡上的“保安”和“质检员”，各自负责一段。

1.2 安全性不等于完整性：一道经典辨析题

很多同学一开始会混淆这两个概念，总觉得“安全了数据自然就完整了”。这属于把两个维度的问题叠在一起了。我在复习时反复给自己强调一句话：

• 安全性：管的是“谁”能访问、能做什么操作。重点在“人”和“权限”。防止的是非法用户、越权访问、恶意篡改。
• 完整性：管的是“数据本身”对不对、合不合语义。重点在“数据质量”。防止的是不合法、不正确、不相容的数据混进数据库。

举个很直观的例子：某同学通过身份鉴别和授权，合法登录了教务系统，他有权限查看成绩——这是安全性在放行。但是成绩列里被写入了“-30”这种物理上不可能存在的负数，数据库系统必须拒绝这条记录——这是完整性在拦截。

所以二者是两条平行且互补的防线。安全性再强，也拦不住一个合法用户误录入了错误数据；完整性约束再多，也管不了有人用合法账号导出整张表。这也是教材为什么把这两章放在一起的原因：它们合在一起，才构成数据库基础层面的“可信数据环境”。

2. 存取控制机制：从GRANT/REVOKE到强制存取控制

2.1 自主存取控制DAC：权限像钥匙，而且可以转赠

自主存取控制（Discretionary Access Control，DAC）是教材重点介绍的第一种控制方式，也是主流关系数据库默认采用的方式。它的核心思想非常朴素：数据对象的所有者自己决定把访问权限给谁，而且收了权限的人如果被授权了“转赠资格”，还可以继续往下传。这就是“自主”二字的含义——授权行为是用户可以自己主导的。

对应到SQL上，最核心的两个语句就是：

-- 把 Student 表的查询权限授予 U1 GRANT SELECT ON TABLE Student TO U1; -- 把 Student 表的查询和 Sage 列的修改权限授予 U2，并允许 U2 再转授给别人 GRANT SELECT, UPDATE(Sage) ON TABLE Student TO U2 WITH GRANT OPTION; -- 回收 U1 的查询权限 REVOKE SELECT ON TABLE Student FROM U1;

这里有几个细节值得展开说。

第一，权限粒度是可以到列的。UPDATE(Sage)这种方式表示只允许用户修改Sage这一个列，甚至还可以通过后面的视图机制实现行级权限。很多初学者以为授权的最小单位是表，其实教材里已经给出了列级授权的写法，这在考试简答题里是常考点。

第二，WITH GRANT OPTION是真正的“大坑”。它意味着 U2 不仅自己能查，还能把SELECT权限继续授给 U3、U4……一旦 U1 的权限被回收，U2 先前授予出去的权限怎么办？教材明确给出了结论：默认情况下，回收是级联（CASCADE）的，U3、U4 的权限也会一并被收回。虽然标准SQL里还区分了CASCADE和RESTRICT两种回收方式，但DAC体系下的级联回收才是你答题时需要优先掌握的默认逻辑。

第三，从实践角度看，主流数据库对GRANT的支持和教材有一点差异。比如 MySQL 8.0 之后，建用户和授权已经分离了，你得先CREATE USER，再GRANT，而且GRANT语句不能再顺带创建用户。PostgreSQL 里则统一叫“角色（ROLE）”，用户和角色在概念上是打通的。这个差异不影响你理解教材的DAC模型，但如果你在真实环境里敲命令发现报错，先检查版本和语法差异。

2.2 强制存取控制MAC：用安全标签锁死数据通路

自主存取控制的缺点很明显：权限在用户手里流通，一个用户可以把权限转给别人，系统对这种“流通”的控制不够强。如果数据库存储的是绝密级或高度敏感的数据，这种自由度就不是优点而是隐患了。

强制存取控制（Mandatory Access Control，MAC）的思路完全不同：权限不再由用户“自主”决定，而是由系统强制规则决定。每一个数据对象（表、行、文件）都被标上密级（比如绝密、机密、可信、公开），每一个主体（用户进程）也都有一个许可证级别。能不能操作，不看你“想要什么权限”，而看你的级别和数据密级之间的支配关系。

教材给出的两条核心规则可以记成一张表：

这两条规则合起来就是经典的“不向下写”。为什么要禁止高级别主体向低密级客体写？因为一旦高级别数据被写入了一个低密级的文件，低密级用户就可以从那个文件里读到他本不该看到的高敏感内容——这是典型的信息泄露路径。

MAC 的实现机制比DAC要复杂，真实数据库系统里通常不会对普通业务表全面启用MAC，但在军方、政务、高保密要求的行业系统里它是一种基础能力。举个例子，Oracle 的 Label Security、SELinux 的强制访问控制策略，走的都是类似思路。理解MAC的关键不在于你会不会用某个具体产品，而在于掌握“主体级别、客体密级、读规则、写规则”这四个要素的排列组合，考试里给你一个新场景，你能判断这个访问“放行还是不放行”。

2.3 角色机制：给批量授权做“中间层”

DAC和MAC是两种控制模型，但在实际管理数据库时，还有一个非常实用的机制：角色（ROLE）。教材里对角色机制的描述是“权限的集合”。我觉得更好的类比是快递柜里的“团长”：你不需要给每个用户逐一派发权限，而是先定义一个“角色”，把权限一次性授予角色，再把角色授予用户。

SQL里的大致流程是：

-- 1. 创建一个角色 CREATE ROLE R1; -- 2. 把表 Student 的查询权限授予角色 GRANT SELECT ON TABLE Student TO R1; -- 3. 把角色授予用户，用户就自动拥有了角色的权限 GRANT R1 TO U1, U2, U3; -- 4. 还可以回收 REVOKE R1 FROM U1;

这个机制最大的价值是“降维管理”。想想看，如果公司有二十个实习生都需要只读权限，你挨个授权的话，离职时需要挨个回收。有了角色，你只需要维护“实习生”这一个角色，入职就授予、离职就回收，权限的粒度完全由角色统一控制。在 PostgreSQL 里，这种用户和角色打通的设计尤其明显，整个权限体系就是围绕“角色”构建的。

3. 安全性的三道补充防线：视图、审计与加密

3.1 视图：从逻辑层隔离敏感列

很多同学在学SQL章节时把视图当成“查着方便的临时表”，学到安全性章节才发现，视图其实是天然的权限隔离工具。它的原理很简单：你给用户开放的并不是底表，而是表的一个“裁剪后投影”。

比如有一张学生成绩表 Score(Sno, Cno, Score, Comment)，你不想让普通老师看到Comment列（可能含评语），也不想让他们按学号查到某个特定学生的成绩，于是就可以建一个视图：

CREATE VIEW V_Score_Avg AS SELECT Cno, AVG(Score) AS AvgScore FROM Score GROUP BY Cno; -- 授权：只让老师查看视图，不给他底表的查询权限 GRANT SELECT ON VIEW V_Score_Avg TO Teacher_Role;

这样用户能查到的只有“课程号和平均分”，既看不到个人成绩细节，也碰不到评语列。视图真正的价值就在这里——它把“数据权限”从行、列的物理层面，转化成了“你只能看到我定义好的那一部分逻辑数据”，不管底层表结构怎么变，用户能访问的边界都牢牢锁在视图里面。

需要注意的是，视图本身并不能完全自治地保证安全。如果创建视图的人对底表执行了允许更新的话，某些数据库里通过视图还是可能反查到底层结构的，所以实际生产环境里，视图通常是和授权一起配合使用的，而不是二选一。

3.2 审计：事后追责与异常排查

审计是整个安全体系里经常被轻视、但事故排查时最救命的一环。教材里的定义很明确：审计功能把用户对数据库的所有操作自动记录下来，放入审计日志，一旦发现问题，DBA可以根据日志重现操作链条，追查是谁在什么时间执行了什么操作。

教材给的语句语义很简洁：

-- 对 Score 表的插入、修改、删除操作进行审计 AUDIT INSERT, UPDATE, DELETE ON Score; -- 取消审计 NOAUDIT INSERT, UPDATE, DELETE ON Score;

落地到真实数据库时会发现，不同产品对审计的实现差异很大。MySQL 社区版默认没有完整的内建审计功能，通常需要借助插件或者开启 general log；PostgreSQL 可以通过配置参数和扩展来实现比较细粒度的审计；商业数据库则往往自带相对完整的审计体系。无论在哪个平台，开启审计都是有代价的：日志会持续增长，磁盘I/O和写放大也不小。所以在生产环境里，审计开关往往只针对敏感表、合规表开启，而不是全库全表一把抓。

如果你在准备考试，审计相关的考点主要是“审计是什么”“有什么用”“用哪个语句”，知道这些就够了。但如果你在做真实的系统设计，我的建议是：涉及资金、权限、个人敏感信息的表，一定要开审计，而且要定期把审计日志异地转储。

3.3 数据加密：存储与传输的最后防线

教材把数据加密作为数据库安全性的最后一大模块。数据加密解决的是“数据即使被拿到也读不懂”的问题。加密分为存储加密和传输加密两个方向。

存储层面，最常见的实践是密码字段不存明文。注册用户输入密码后，数据库里存的是经过哈希处理后的散列值，即使DBA直接翻数据表也看不到原始密码。教材里提到的对称加密和非对称加密在这里都有应用：对称加密适合大批量数据，速度快；非对称加密适合少量敏感信息的交换，安全性更高。很多云数据库还提供透明数据加密（TDE），对上层应用完全无感，数据落盘时自动加密，读取时自动解密。

传输层面，教材强调的是防止数据在网络上被截获和篡改。现在主流数据库都已经支持SSL/TLS加密传输。别忘了，如果应用和数据库之间的链路是明文传输，那么链路劫持者可以截获账号密码、SQL语句、查询结果——之前数据库层面的所有权限控制就全部失去意义了。所以我在看项目时，只要业务环境允许，都会确认数据库连接串上有没有启用 SSL。

4. 完整性约束：实体、参照、用户定义三类约束的一次讲透

4.1 实体完整性：主码不能为空且唯一

完整性约束的第一个层次叫实体完整性。它针对的是关系模型里的“实体”概念：每个元组都应该有唯一的、可区分的身份。落到SQL实现上就是主码（PRIMARY KEY）的两个铁律：主码属性不能取空值，主码不能重复。

这里有一个新手很容易踩的误区：复合主码。如果主码由两个列共同组成，比如选课表里的(Sno, Cno)，那么Sno和Cno的每一个都不允许为空，而不是“其中一个为空也可以，只要两个不同时为空”。DBMS在插入和修改主码值时都会自动检查这条规则，一旦违反就直接拒绝操作。

实体完整性的实现通常会在主码上自动建立唯一索引，这也是为什么按主码查询总是很快的原因之一。在教材里，这种自动检查是关系系统必须提供的基本能力，不需要用户额外写代码。

4.2 参照完整性：外键的“引用即存在”契约

参照完整性解决的是“引用”的合法性问题。简单说就是：A表里的外键一旦写了值，这个值必须在B表的主码里真实存在；外键如果为空，则表示不存在联系，是可以接受的；但外键非空却指向一个不存在的主码，就破坏了引用关系。

外键违约的处理策略，是这节最重要的考点。教材给出的策略可以从两个方向理解：

方向一：对参照表（子表）的插入、外码修改

• 如果新外码不是 NULL，但在被参照表中找不到对应主码，拒绝执行。

方向二：对被参照表（父表）的主码删除、主码修改

• 这时系统有几种选择：拒绝（NO ACTION / RESTRICT）、级联（CASCADE）、置空（SET NULL）。

比如删除一门课程，如果该课程已有学生选课记录，默认策略是拒绝删除，防止“选课记录指向一门不存在的课”。但如果业务要求“删课之后选课记录也一并清除”，就可以定义外键时带上级联删除：

CREATE TABLE SC ( Sno CHAR(9), Cno CHAR(4), Score DECIMAL(4,1), PRIMARY KEY (Sno, Cno), FOREIGN KEY (Sno) REFERENCES Student(Sno) ON DELETE CASCADE, FOREIGN KEY (Cno) REFERENCES Course(Cno) ON DELETE CASCADE );

在真实生产环境里，我发现很多团队因为性能问题干脆不建外键约束，把“引用完整性”放到应用层去维护。这种做法要承担风险：应用层的并行操作总有照顾不到的死角，一旦产生孤儿数据，排查成本非常高。稳妥的做法是：读多写少、对一致性要求高的核心关系，老老实实建外键；正确性让数据库来保证，应用层只做业务校验。

4.3 用户定义完整性与约束命名：把规则写到表结构里

实体完整性管主码，参照完整性管外码，但业务里还有大量约束不属于这两类。比如年龄不能为负、性别只能是男女、邮箱格式要合法、股票数量必须是整数且大于0。这些规则统称用户定义完整性，落到SQL里就是三样东西：NOT NULL、UNIQUE、CHECK。

教材特别强调了完整性约束命名子句的用法，目的是让约束有名字，便于后续通过名字删除或修改：

CREATE TABLE Student ( Sno CHAR(9), Sname CHAR(20) NOT NULL, Sage SMALLINT, CONSTRAINT CS_Sno PRIMARY KEY(Sno), CONSTRAINT CS_Sname UNIQUE(Sname), CONSTRAINT CS_Sage CHECK (Sage BETWEEN 16 AND 40) );

有了CONSTRAINT CS_Sage这样的命名，你可以用一句话把具体约束去掉或替换，而不用删表重建。这在项目迭代时尤其好用。

还要注意UNIQUE的一个隐蔽行为：多数数据库允许UNIQUE列中存在多个NULL值，因为“每次为空表示未知”，彼此不算重复。如果你期望“这一列除空值外不能重复”，那么UNIQUE是符合预期的；如果你期望“空值也不允许出现”，就得额外加NOT NULL。这个坑在真实业务里经常引发线上bug，值得记一下。

4.4 约束的检查时机与常见误区

完整性约束不是“写进表结构就万事大吉”，它有一整套检查时机。教材和考试里需要掌握的是：插入、修改、删除操作时，DBMS都会自动检查相关约束，不符合就语句整体失败。这里面最容易忽略的是“修改主码”这种操作——它既可能触发实体完整性检查，也可能触发参照完整性检查。

另外还有一个和索引相关的实操经验：外键列尽量建索引。原因很简单，删除父表一行时，DBMS需要快速找到所有引用它的子表记录来执行级联或拒绝判断，没有索引就只能全表扫。很多大表删除慢，不是删除本身慢，而是外键关联的查找慢。这是我处理线上故障时踩过的很实际的坑。

还有一个误区：不是所以约束都能像“写死规则”一样随意叠加。约束越厚，写入性能越差，尤其是带有跨表检查的外键和CHECK。在设计表结构时，约束要“该用的用足”，但也不要为了“看起来严谨”在每列上堆七八个约束，要平衡正确性、开发效率、运行性能三者的关系。

5. 触发器：约束不够用时，让数据库自己做个守卫

5.1 触发器的ECA结构与两种粒度

完整性约束解决的是“规则型”问题，但业务里经常有“规则不好用SQL声明”的场景。比如某个操作同时要检查多个表、要自动写日志、要同步更新汇总字段。这时候，教材就翻出了触发器这张牌。

触发器的全称叫“事件-条件-动作”（Event-Condition-Action），可以理解为一段被数据库自动执行的小程序。它包含四个关键要素：

• 触发事件：INSERT、UPDATE、DELETE 等操作
• 触发时机：BEFORE（操作前触发）或 AFTER（操作后触发）
• 触发条件：只有满足条件才执行动作
• 触发动作：要执行的一组SQL语句或过程

而“行级触发器”和“语句级触发器”的区别，是考试里最容易被问到的点。FOR EACH ROW表示对被影响的每一行执行一次动作；FOR EACH STATEMENT则无论这次语句影响了多少行，整体只触发一次。

举个例子，写一个简单的工资审计触发器，把“工资突然大幅下降”的更新行为记录下来：

CREATE TRIGGER Tg_Salary_Log AFTER UPDATE OF Sal ON Employee FOR EACH ROW WHEN (NEW.Sal < OLD.Sal * 0.8) BEGIN INSERT INTO Sal_Log(EID, Old_Sal, New_Sal, Change_Time) VALUES (NEW.EID, OLD.Sal, NEW.Sal, CURRENT_TIMESTAMP); END;

这段触发器的逻辑就是：每当 Employee 表 Sal 列发生更新，如果新工资比旧工资下降了超过20%，就自动往日志表里插一条记录。整个过程对业务层完全透明，不需要应用端写任何额外代码。

5.2 典型触发场景与“别滥用”的提醒

触发器真正好用的场景，我经历过的有几类：一是敏感表变更的自动审计日志；二是数据同步，比如订单表插入后自动往统计表里更新汇总值；三是复杂完整性校验，比如“库存不能超卖”这种需要跨表判断的规则。

但是，触发器是把双刃剑。我的建议是：能用约束解决的，不要用触发器。约束是声明式的，数据库可以优化执行路径；触发器是过程式的，一旦触发，会带来额外的隐式操作，复杂触发器还可能造成连锁触发、死锁，而且排障时非常不好查。你执行一条看似简单的UPDATE，实际背后跑了一长串触发器，这不是什么好体验。

如果要上线含触发器的功能，我有三个实操习惯：第一，在测试环境里分别用单行更新和批量更新验证行级触发器和语句级触发器的行为差异；第二，在触发器中统一加日志输出，方便事后定位；第三，评估触发器的性能权重，避免把高频写入路径变成“触发器瓶颈”。这些经验在教材里没有，但真实的数据库运维里很重要。

6. 备考时最容易翻车的三个细节与复习主线

6.1 细节一：WITH GRANT OPTION的回收链条

考试里经常出这样的题：A给B授权并带WITH GRANT OPTION，B又把同一权限给了C，现在A要回收B的权限，问C的权限是否还能保留？答案取决于实现，但教材默认是级联回收，即C的权限也会被回收。答题时如果不确定，最好把条件写清楚：“默认按级联方式回收，如果回收语句指定了 RESTRICT，且有下游授权存在，则回收失败”。这才是完整拿分的思路。

6.2 细节二：完整性约束与触发器的辨析

简答题里很容易出现“这个规则用什么实现更好”。判据很简单：如果规则能用一条CHECK、UNIQUE、NOT NULL或外键声明清楚，就用约束；只有规则涉及多表联动、操作时机、自定义过程逻辑时，才上触发器。答题时可以用“约束是声明式，触发器是过程式”作为第一句定调，然后结合实际场景说明。

6.3 细节三：安全方案的层次顺序

更考验综合能力的题长这样：为一套成绩系统设计安全方案，要求只有教务处人员能查看统计结果，并且每次查询都要留痕。回答这类题要按层来：先建“统计视图”隔离敏感明细，再通过角色授权仅给教务处角色，最后开启对该视图的审计。这三步对应视图机制、存取控制、审计，答出来就是一条完整的链路。掌握了这种“分层答题”思路，安全性的论述题基本都能踩在得分点上。

6.4 复习建议：把概念题改造成场景题

回过头去看，基础篇（四）的内容看起来是“背概念”，但真正拉开差距的恰恰是“能不能把概念落成SQL、落成设计”。我的复习方法很简单：把每一道概念题都改造成“给一个场景，自己写一段建表、授权、触发器的SQL”，再对照教材核对。比如教材说“用户定义完整性”，你就亲手在本地数据库里建一张带CHECK的表，试一下插入非法值会发生什么；教材说“参照完整性的级联删除”，你就建两张带外键的表实际删一行看看；教材说“审计”，你就开一下general log，看看自己刚才的操作被记成了什么样。

数据库这个学科，看十遍不如动手一遍。安全性与完整性这两章尤其如此，你把权限、约束、触发器都真正跑过一遍之后，那些零散的知识点会自动串成一张网。后面再去做系统设计或备考复试，你会发现很多所谓难题，其实都是你早就跑通过的操作场景。