扫码获取 VIP 码
添加管理员微信获取 VIP 码
数据库系统工程师是软考中级里技术密度相当高的一科，凡是学过这门课的人，几乎没有不被"完整性约束"这道概念题绊倒过的。题目本身不难，难的是命题人总喜欢在几个长得极其相似的术语之间制造混淆，让考生在实体完整性、参照完整性、用户定义完整性三者之间来回摇摆。这篇文章不打算停留在"背三句话就能过"的层面，而是要把三类完整性约束的定义、底层机制、分类边界、命题挖坑套路和历年真题全部拆开，让你彻底看清这道必考点的全貌。
在正式进入三类完整性约束之前，必须先厘清一个更上位的概念——数据完整性本身指的是什么。它描述的是数据库中存储的数据必须满足的正确性、有效性和相容性要求。所谓正确性，是指数据必须真实反映客观世界的实际情况；所谓有效性，是指数据必须落在合法的取值范围内；所谓相容性，是指同一数据在多处出现时必须保持一致，不能互相矛盾。
数据库存在的根本目的，是持久、可靠地保存和管理现实世界的信息。如果一个数据库允许用户写入年龄为负数的记录、允许两个员工拥有完全相同的主键编号、允许订单表引用一个根本不存在的客户编号，那么这个数据库即使性能再好、结构再精巧，也失去了它作为信息系统的价值。因此，完整性约束不是数据库的可选功能，而是关系模型能够成立的一块基石。
从数据库发展的历史来看，关系模型的提出者埃德加·科德在奠定关系理论的经典论文中，就已经把完整性规则作为关系模型不可分割的组成部分写进了理论框架。这意味着一套真正符合关系模型规范的数据库管理系统，必须在引擎层面提供维护完整性的能力，而不是把这份责任推给上层的应用程序开发者。理解这一点，有助于考生在遇到"完整性由谁维护"这类题目时，果断选择数据库管理系统而非应用程序。
关系模型一共定义了三大类完整性约束，这是软考命题的直接依据。第一类是实体完整性，它要求基本关系的主属性不能取空值。所谓主属性，就是组成主码的那些属性。简单地说，一张表一旦确定了主键，主键列就绝对不允许出现空值，也不允许出现重复值。第二类是参照完整性，它规定如果关系中的一个属性或属性组是另一个关系的主键，那么这个属性的取值要么等于被参照关系中的某个主键值，要么为空。这条规则保证了跨表引用不会出现"悬空指针"。第三类是用户定义的完整性，它是针对某一具体应用场景设定的、由用户自己定义的约束条件，比如账户余额不能小于一百、性别只能取男或女、年龄必须在零到一百五十之间。
这里需要特别厘清"主属性"与"非主属性"这对术语。主属性是指包含在任何一个候选码中的属性，而非主属性则是完全不参与任何候选码的属性。实体完整性约束的对象正是主属性，它要求主属性的值非空且唯一。很多考生在记忆时只记住了"主键不能为空"，却忽略了实体完整性在术语上的准确表述是"主属性不能取空值"，这两者虽然在多数场景下等价，但在涉及复合主键或候选码的题目中，措辞的准确性会直接影响判断。
理解这三类约束的关键，在于看清它们的抽象层级。实体完整性和参照完整性是关系模型对任何关系数据库都普遍适用的、与具体业务无关的通用规则，它们由数据库管理系统统一自动维护；而用户定义的完整性则是面向具体业务领域的个性化规则，它既可以通过约束声明实现，也可以通过触发器、存储过程等机制实现。这条"通用规则与业务规则"的分界线，恰恰是命题人最爱做文章的地方。
进一步说，这三类约束之间存在一种从"模型层"到"应用层"的递进关系。实体完整性和参照完整性回答的是"关系模型本身要求什么"，它们的规则在所有关系数据库中都是同一套；用户定义完整性回答的则是"这个具体系统还额外要求什么"，规则完全取决于业务语义。掌握这个递进框架，考生就能在遇到"下列哪项不属于关系模型固有约束"这类题目时快速锁定答案。
完整性约束要真正发挥作用，不能只停留在纸面定义上，必须有底层机制来落地执行。理解这些机制，是区分"背过"和"真懂"的关键。
实体完整性的落地，依赖数据库管理系统在定义主键时自动创建的唯一索引。当用户试图插入一条主键值已存在的记录，或者试图把主键列更新为空值时，数据库管理系统会通过索引快速定位并拒绝这次写入操作。需要注意的是，主键约束在语义上等价于"非空约束加唯一约束"的组合，但在物理实现上，主键只能有一个，而唯一约束可以有多个，这是两者在考试中反复出现的一个区分点。
从索引的实现角度看，绝大多数关系数据库都会为主键自动建立一个聚集索引或与之等效的唯一索引结构。索引的存在让主键值的唯一性校验从全表扫描的线性开销降到了树形查找的对数开销，这是数据库引擎能够在不牺牲性能的前提下强制执行实体完整性的根本原因。考生如果能把这个"约束靠索引落地"的机制想明白，就不难理解为什么频繁更新主键会带来额外开销，也不难理解为什么数据库设计规范会建议主键尽量保持稳定。
参照完整性的实现核心是外键约束。当一个表的某列被声明为外键时，数据库管理系统会在该列上建立与被参照表主键之间的引用关系。当用户试图插入或更新外键值、而该值在被参照表中不存在时，操作会被拒绝。更复杂的是级联动作的设计：当被参照表的主键值被删除或修改时，外键表可以有四种处理策略，分别是级联删除、级联更新、置空和拒绝执行。命题人经常拿"级联删除"和"置空"这两种策略让考生做区分，前者会连带删除外键表中的相关记录，后者只是把外键列置为空值而保留记录本身。
除了四种级联动作，参照完整性的实现还涉及一个容易被忽略的细节——外键列本身允不允许为空。按照标准定义，外键列是允许取空值的，因为空值意味着"该记录暂时不引用任何被参照记录"，这在业务上是合法的。但如果业务上要求每条记录都必须引用一个有效对象，开发者就会在外键约束之外再叠加一个非空约束。这个"外键允许为空、是否允许空取决于业务"的细节，是命题人在设计辨析题时的经典素材。
完整性约束的检查时机，是底层机制中容易被忽略却又十分重要的一个细节。在绝大多数数据库管理系统中，约束默认采用立即检查模式，也就是每执行一条语句就立刻校验一次约束是否满足。但某些系统也支持延迟检查模式，允许在一个事务提交时才统一检查约束。理解这个区别，能帮助考生在遇到"触发时机"类题目时做出正确判断，尤其是当题目涉及批量更新操作时，立即检查与延迟检查会产生截然不同的结果。
检查时机的差异在实务中有非常现实的意义。以批量导入数据为例，如果导入过程中某些记录暂时违反了约束、但整个批次完成后约束又能恢复满足，那么在立即检查模式下这些中间状态会被拒绝，而在延迟检查模式下则可以被接受。软考虽然较少直接深入延迟检查的细节，但"约束在写入时即被校验"这一基本认知，是理解触发器、事务回滚等相邻知识点的必要前提。
这一节把三类完整性约束逐一展开，讲清楚各自的适用场景和边界条件。
实体完整性约束的典型应用，就是为每一张表选择一个合适的主键。在数据库设计实践中，主键的选择直接关系到实体完整性的实现质量。一个理想的主键应当满足唯一、稳定、非空且尽可能简短的原则。实务中常见的主键设计有自然主键和代理主键两种思路：自然主键直接采用现实世界已有的唯一标识，如身份证号；代理主键则引入一个人为生成的自增编号。两者各有优劣，软考在关系模式设计题中常要求考生判断某个属性是否适合做主键，其判断依据正是实体完整性的要求。
在复合主键的场景下，实体完整性的内涵会更加具体：只要组成主键的任意一个属性为空，整条记录的主键值就无法构成有效标识，因此复合主键中的每一个属性都必须非空。这一要求在关系模式转换题中体现得尤为明显，例如多对多关系在转换为关系模式时，往往需要把两个实体的主键组合起来作为新表的主键，此时这两个外键属性都不得为空，正是实体完整性约束的直接体现。
参照完整性约束是关系数据库维系表与表之间关联的骨架。在实际设计中，它最常见的载体是一对多关系中的外键。例如订单表通过客户编号引用客户表，就构成了一对多的参照关系。需要特别注意的是，参照完整性的对象不一定是另一个表的主键，也可以是另一个表的唯一键，这一点常被考生忽略。此外，自参照的情形也属于参照完整性的范畴，例如员工表中的上级编号引用本表员工编号，这类设计在树形组织结构中非常普遍，考试中偶尔也会出现。
在关系模式转换的语境下，参
本篇完！