目录一、域关系的原子材料二、笛卡尔积与关系从全组合到有意义的事实三、关系模式与关系实例结构的恒常与内容的流变四、码不可再少的身份标识五、外码与参照完整性关系之间的逻辑契约六、形式化的价值从规则到保证一、域关系的原子材料在关系模型中一切结构的起点是一个看似简单却极易被忽视的概念——域。域Domain的形式化定义是一组具有相同数据类型和语义的原子值的集合。这一定义包含三重约束。其一域中的值必须是原子的——从关系模型的理论视角看它不可再分。这并非物理意义上的不可拆分所有数据在物理上最终都是比特而是逻辑意义上的不可拆分关系模型不再关心域内值的内部结构域值被视为操作的基本单元。其二域中的值具有共同的数据类型如整数、字符串、日期等。其三域中的值共享某种语义这种语义规定了这些值在现实世界中代表什么——例如域“年龄”不仅是0到150之间的整数更重要的是这个整数表示的是“一个人存活的年数”而非别的任何意义。域与编程语言中“类型”的概念有相似之处但域的内涵更为丰富。一个类型通常只限定值的表示范围如32位有符号整数的取值范围而域在此基础上还附加了业务语义约束。例如域“课程编号”和域“学生人数”在物理上都可能是整数类型但一个合法的课程编号如C001的某种数值编码未必是一个合法的学生人数它不可能为负也不太可能超过一个合理的上限。数据库管理系统在执行比较、连接等操作时通常是基于域来进行类型相容性判定的——两个值只有来自同一个域或域之间定义了相容关系比较才有逻辑意义。为域赋予一个语义名称并将其置于关系的某个位置上这个带有角色的域便成为属性。从形式化的角度属性是从关系模式到域的映射给定关系模式R其属性A是R上的一个函数该函数将关系模式中的每一列映射到一个特定的域。正是这种映射关系保证了每一列数据的取值都受到域的严格约束。二、笛卡尔积与关系从全组合到有意义的事实有了域的严格定义笛卡尔积和关系的形式化定义便可以精确展开。设有n个域D₁, D₂, ..., Dₙ它们可以相同也可以不同这些域的笛卡尔积记作D₁ × D₂ × ... × Dₙ定义为所有n元有序组(d₁, d₂, ..., dₙ)的集合其中dᵢ ∈ Dᵢ即第i个分量取自第i个域。用集合论的记法D₁ × D₂ × ... × Dₙ { (d₁, d₂, ..., dₙ) | dᵢ ∈ Dᵢ, i 1, 2, ..., n }每一个这样的n元有序组被称为一个元组。笛卡尔积的基数元素个数等于各域基数的乘积|D₁| × |D₂| × ... × |Dₙ|。当n和域基数增大时笛卡尔积的规模呈指数级膨胀——这种组合爆炸是后续讨论查询优化时反复出现的话题。笛卡尔积本身是一个数学构造它包含了所有可能的组合不管这些组合在现实世界中是否有意义。关系正是从这些可能的组合中筛选出那些在业务上真实成立的组合。其形式化定义为给定一组域D₁, D₂, ..., Dₙ这组域上的一个关系Relationr是笛卡尔积D₁ × D₂ × ... × Dₙ的任意一个有限子集。记作r ⊆ D₁ × D₂ × ... × Dₙ。这个定义的两个限定词值得强调。其一关系是子集——它不必包含笛卡尔积的全部元组。事实上在实际业务中关系包含的元组数通常远小于笛卡尔积的规模。子集关系精确定义了“关系表达了域之间某种有意义的关联”这一直觉——只有那些在现实世界中成立的关联才会被纳入子集。其二关系是有限子集——尽管理论上笛卡尔积可能是无限的但实际数据库中存储的关系实例始终是有限的。这一限定将关系模型牢牢锚定在可实现的计算范畴之内。设关系r包含m个元组每个元组包含n个分量对应n个属性我们称r是一个m行n列的关系。行的顺序无关紧要——因为关系是集合集合的元素间没有顺序列的顺序在理论层面也无关紧要因为列通过属性名而非物理位置来标识。这两个“无关紧要”在工程实践中并非总能完全兑现物理存储总是有序的但它们是衡量一个数据库系统“关系纯度”的理论标尺。三、关系模式与关系实例结构的恒常与内容的流变初学者极易混淆的一对概念是关系模式与关系实例。这一区分类似于编程语言中“类型”与“变量值”之间的区分——类型定义了结构变量值是该结构在某一时刻的具体填充。关系模式Relation Schema是对一个关系结构的描述。它可以形式化地记作R(A₁:D₁, A₂:D₂, ..., Aₙ:Dₙ)其中R是关系的名称Aᵢ是属性名Dᵢ是属性Aᵢ所基于的域。关系模式是相对稳定的——一旦设计完成一个关系模式通常会保持很长一段时间不发生结构性变化。所有符合该模式的数据都将遵循相同的结构约束。关系实例Relation Instance则是关系模式在某一特定时刻的具体内容——即当前实际存储在数据库中的元组集合。关系实例是动态的随着插入、删除、更新操作的发生而不断变化。一个关系模式在任何时刻都有且仅有一个关系实例可能为空而同一关系模式在时间轴上对应于一个不断演化的实例序列。这一区分之所以关键是因为后续讨论的所有完整性约束域约束、实体完整性、参照完整性都是施加在关系模式上的永久性规则而数据库系统运行时的具体工作则是确保每一个关系实例都满足这些规则。当用户插入一条数据、更新一个字段时系统本质上是在执行一次“从当前合法实例到另一个合法实例”的状态跃迁检查——任何试图生成非法实例的操作都将被拒绝。将关系的数学定义与关系模式/实例的区分结合起来我们可以得到如下精确表述设关系模式为R(A₁:D₁, A₂:D₂, ..., Aₙ:Dₙ)则R的一个合法关系实例r满足r ⊆ D₁ × D₂ × ... × Dₙ且r是有限集合。数据库Database则是多个关系实例的集合而数据库模式Database Schema是多个关系模式的集合外加模式间约束的集合。四、码不可再少的身份标识在关系实例包含的所有元组中如何唯一地标识某一行是实现数据定位、关联和更新的基本前提。关系模型使用“码”这一概念来承担此责。超码Superkey是关系模式中一个属性或一组属性的集合其取值足以唯一标识关系中的每一个元组。形式化地设K是关系模式R的属性子集若对于R的任意合法实例rr中不存在两个不同的元组在K的各个属性上取值完全相同则K是R的一个超码。超码的定义保证了在属性集K上的取值组合具有全局唯一性。超码的问题在于它可能包含冗余。如果K已经是超码那么任何包含K的属性集也必然是超码——因为增加属性不会破坏唯一性。例如在“学生”关系中{学号}是超码那么{学号, 姓名}、{学号, 姓名, 出生日期}也都是超码但后面这些超码携带了不必要的额外属性。候选码Candidate Key是“最小”的超码——它是一个超码且其任意真子集都不再是超码。换言之候选码中的每一个属性都是维持唯一性所不可或缺的去掉任何一个唯一性就不再成立。一个关系模式可以同时存在多个候选码。例如在“学生”关系中如果“学号”和“身份证号”各自都能唯一标识学生且“学号”不需要借助身份证号来维持唯一性反之亦然那么{学号}和{身份证号}都是候选码。主码Primary Key是设计者从候选码中人为选定的一个作为关系实例中元组的首要标识方式。未被选中的候选码则称为替代码Alternate Key。主码的选择通常是出于工程考虑而非理论必需——优先选择属性个数少、长度短、取值稳定且不易变更的候选码作为主码。主码的选定意味着设计者承诺该关系的每一个合法实例中主码属性的取值绝不为空且绝不重复。上述对于主码取值不为空的承诺被形式化为实体完整性规则在任何关系实例中主码的任何属性都不得取空值NULL。这一规则的合理性源于对实体可标识性的基本要求——如果主码为空或部分为空对应的元组就无法被可靠地标识与引用它作为一个“独立实体”的存在根基就被动摇了。实体完整性是关系模型中最基本、最不可动摇的约束之一。五、外码与参照完整性关系之间的逻辑契约单个关系内部的完整性由域约束和实体完整性来保障。但一个数据库通常包含多个关系这些关系之间存在着千丝万缕的语义关联——学生隶属于某个院系订单属于某个顾客选课记录引用了学生和课程。这些跨关系的关联必须同样受到严格的逻辑约束。承担这一使命的机制就是外码与参照完整性规则。外码Foreign Key的形式化定义涉及两个关系模式。设R₁和R₂是两个关系模式它们可以是同一个模式——自引用场景设FK是R₁的一个属性或属性组。如果满足以下两个条件则称FK是R₁的一个外码它参照Reference了R₂其一FK中的属性与R₂的主码属性必须基于相同的域。这一要求保证了外码取值与被参照目标在数据类型和语义上的可比性。其二在任意合法的数据库实例中R₁中任意元组在FK上的取值要么全部为空每个属性均为NULL要么与R₂中某个元组在主码上的取值完全匹配。换言之R₁在FK上的每一个非空值都必须在R₂的主码中找到一个“指涉对象”。这第二个条件便是参照完整性规则Referential Integrity Rule——外码取值要么为空要么等于被参照关系中某个主码值。空值在此处的语义是“该元组在这一关联上尚未建立指涉”例如一个暂未分配导师的研究生其“导师工号”外码可以暂时为空。但一旦它被赋予了一个非空值这个值就必须对应一位真实存在的教师。外码定义的深刻之处在于它建立了一种跨越关系边界的逻辑约束。它不是物理指针不携带任何存储地址信息不要求连接算法是什么不关心索引结构。它只声明一条铁律在A表中声称与B表有关联的任何记录都必须能在B表中找到被关联的那个对象。这条铁律是关系数据库中跨表数据一致性的最后一道防线——数据库管理系统通过强制执行参照完整性确保整个关系网络不会出现“孤儿记录”一个订单不可能属于一个不存在的顾客一条选课记录不可能引用一门已被删除的课程。六、形式化的价值从规则到保证行文至此我们完成了对关系数据结构最核心概念的形式化构建。这些概念——域、笛卡尔积、关系、关系模式与实例、超码与候选码、主码、外码——共同构成了关系模型的骨架。它们不是各自孤立的知识点而是一个逐级推导、环环相扣的定义体系域定义了取值的原子范围笛卡尔积定义了域之间的全组合关系从全组合中筛选出有意义的事实关系模式固定了这种筛选的框架码确保了框架内每一行的可标识性外码则跨越框架建立了逻辑契约。这一整套形式化体系之所以重要是因为它将数据库管理从经验技艺提升为可证明的工程科学。实体完整性、参照完整性、域完整性——这三大完整性约束分别守护着数据在行内、行间和跨表三个维度的逻辑自洽。当数据库系统在每一次数据修改操作时强制执行这些约束它就为上层应用提供了强有力的担保无论程序逻辑多么复杂无论并发操作如何交叠数据的基本逻辑结构不会腐坏。下一篇我们将在这套形式化基石之上系统展开三大完整性的完整论述——它们如何具体地保护数据库免于逻辑污染以及它们在实际工程场景中的实施策略与取舍。