数据库完整性约束是关系数据库理论中一道绕不过去的坎。在软考数据库系统工程师、软件设计师乃至系统架构设计师的考试中，它几乎年年出现，但命题形式变化多端，稍不留神就会失分。要真正掌握它，必须先回到关系模型的形式化定义本身。
关系数据库中的数据以关系为单位组织，而关系是一张二维表。这张表之所以能被称为"关系"，而不是随意堆放的数据集合，正是因为关系模型给它附加了一组约束条件。这些约束条件统称为完整性约束，它们是关系模式定义的有机组成部分，是数据库管理系统在数据更新时自动执行检查、拒绝非法操作的依据。
教材中对完整性约束有明确的分类表述。关系模型的完整性规则包括三类：实体完整性、参照完整性和用户定义完整性。这三类规则分别从不同的维度回答同一个问题——什么样的数据是"合法"的、可以进入数据库的，什么样的数据是"非法"的、必须被拒绝的。
实体完整性规定，关系的主键取值必须唯一，并且主键所包含的主属性不能取空值。所谓主键，就是能够唯一标识关系中每一个元组的最小属性集合。主键一旦确定，实体完整性就要求这个键值在整张表中不能重复、不能缺失。这是保证每一行数据可以被精确定位的底线。
参照完整性规定，一个关系中的外键取值，要么为空值，要么必须等于被参照关系中某个元组的主键值。外键是联系两张表的纽带，它指向另一张表的主键。参照完整性保证的是"引用必须有效"，杜绝出现悬空引用，也就是外键指向了一个并不存在的记录。
用户定义完整性是针对具体应用场景的语义约束。它没有统一的、放之四海皆准的形式，而是由用户根据业务规则自行定义。比如某张表的年龄字段取值必须在零到一百五十之间，某张会员表的余额字段不能小于某个下限，这些都属于用户定义完整性。
理解这三类约束的定义，是后续所有分析的基础。值得注意的是，很多人把"完整性"和"安全性"混为一谈。安全性回答的是"谁能访问数据"，完整性回答的是"数据本身对不对"。一个是访问控制问题，一个是数据语义问题，两者层次不同，不能混淆。
实体完整性之所以只约束主键，而不是约束关系中的每一个属性，根源在于关系模型对"实体"的抽象。关系中的一个元组代表现实世界的一个实体，而主键就是标识这个实体的身份标识符。如果没有主键的唯一性和非空性，数据库就无法回答"这一行到底是哪一个实体"这个最基本的问题。
主键非空这条规则，反映的是实体的存在性。现实世界中，一个真实存在的实体必然有身份标识。一个没有学号的学生、一个没有员工编号的职员，在业务上都是无法被指认的。因此主键不能为空，本质上是在维护"每个实体都可被唯一识别"这一前提。
主键唯一这条规则，反映的是实体的可区分性。如果两个元组拥有相同的主键值，系统就无法判断它们是同一个实体的两条记录，还是两个不同实体的记录被错误地合并。唯一性保证了主键到实体的映射是单射的，不会出现一个身份对应多个实体的混乱局面。
这里有一个细节需要特别指出：实体完整性约束的是主键整体，而不是主键中的单个属性。当一个主键由多个属性联合构成时，要求的是这个属性组合整体不重复、不取空，而不是每个属性都非空且唯一。联合主键中的某个属性单独看可以重复，但只要组合起来唯一即可。这是很多考生在做判断题时容易犯的错。
参照完整性约束的是外键，而外键本质上是一种跨表引用。设关系甲中有一个属性集合外键，它引用了关系乙的主键。那么参照完整性要求：甲中任意元组的外键值，要么为空，要么恰好等于乙中某个元组的主键值。
这条规则背后的逻辑是引用的有效性。外键存在的意义，是在两张表之间建立关联。比如订单表中的客户编号外键引用客户表中的客户编号主键，那么订单表里出现的每一个客户编号，都必须是客户表里真实存在的客户。如果订单里出现了一个不存在的客户编号，这条订单就成了无主数据，业务上无法追溯。
外键允许取空值，这一点至关重要。外键为空意味着"这条记录暂时没有关联对象"。比如一个员工可能还没有被分配部门，那么他的部门编号外键就可以暂时为空。空值在这里表示"无关联"，而不是"关联到一个不存在的东西"。很多考生把"外键不能为空"当成规则，这是完全错误的。实体完整性要求主键非空，参照完整性却允许外键为空，二者一字之差，含义天差地别。
参照完整性还引出了一个关键概念——被参照关系必须已经定义好主键。外键引用的是另一张表的主键，因此被参照表必须先确立主键，参照表才能声明外键。这也是外键约束在数据库设计中必须遵循的先后顺序。
用户定义完整性是三类约束中最灵活、也最容易在概念辨析题中出岔子的一类。它的核心在于"用户定义"四个字——没有统一的规则模板，完全由具体应用的语义决定。
从实现层面看，用户定义完整性可以进一步细分为域完整性、列约束、元组约束等不同层次。域完整性针对的是某一属性的取值集合，比如性别只能取"男"或"女"。列约束针对单列的取值条件，比如余额大于等于零。元组约束则针对同一元组内多个属性之间的联动关系，比如"开始日期必须早于结束日期"。
这里需要澄清一个常见误解：域完整性和用户定义完整性并不是并列的关系。在某些教材的表述中，域完整性被当作用户定义完整性的一个子类来讲解，也有教材把完整性约束分为实体完整性、参照完整性和用户定义完整性三大类，而域约束被归入用户定义完整性的范畴。考试中遇到这类表述差异，关键要看题干的具体语境和选项的完整程度，不能死记硬背某一种分类框架。
用户定义完整性的价值，在于弥补前两类约束无法覆盖的业务语义。实体完整性和参照完整性解决的是"结构上合不合法"的问题，而用户定义完整性解决的是"业务上合不合理"的问题。一个年龄字段值取五百，在结构上完全合法，但不合业务逻辑，这就需要用户定义完整性来拦截。
在具体实现层面，三类完整性约束都有对应的SQL声明方式。掌握这些声明方式，不仅能应付选择题中对语法细节的考查，也有助于在案例题中准确表达设计意图。
实体完整性在SQL中通过主键约束声明。在定义表时，使用主键关键字为表指定主键，数据库管理系统就会自动为该主键建立唯一性索引，并在每次插入和更新时检查唯一性与非空性。当一张表已经建好之后，也可以用修改表结构的语句补加主键约束。
参照完整性在SQL中通过外键约束声明。定义外键时，需要同时指明它引用了哪张表的哪个主键。数据库管理系统会保证外键的取值始终落在被参照表主键的取值范围内。一旦有数据违反了这一规则，插入或更新操作就会被拒绝。
用户定义完整性在SQL中通过多种机制共同实现。检查约束用来限定某列或某元组的取值范围；非空约束限定某列不能为空；唯一约束限定某列取值不重复；默认约束为某列指定缺省值。这些机制各自解决一类语义问题，可以组合使用。
需要强调的是，检查约束在逻辑上最接近"用户定义完整性"的本义，因为它直接表达业务规则。一道经典的真题是这样描述的：某会员管理系统的业务规则是账户余额不能小于一百，问这条规则采用什么约束实现。正确答案正是检查约束，因为它是唯一能表达这种数值范围语义的声明式手段。
外键约束建立之后，被参照表中的主键被删除或更新时，参照表中的相关外键就会面临失效风险。数据库管理系统处理这一风险的策略，就是级联操作。
常见的级联策略有四种。级联删除表示当父表记录被删除时，子表中所有引用它的记录一并删除。置空表示父表记录删除后，子表对应外键被置为空值。拒绝表示只要子表还有记录引用，父表记录就不允许删除或更新。无动作与拒绝类似，但检查时机不同，通常在语句执行结束时才检查。
这四种策略在软考中经常以"删除父表记录后子表会发生什么"的形式出现。正确理解它们的关键，是抓住"联动"这个核心：级联策略规定的是父表变化如何传导到子表，而不是子表变化如何影响父表。方向一旦搞反，就会掉进命题人设计的陷阱。
在
本篇完！