在关系数据库理论中，码是用于唯一标识关系中元组（即表中的行）的关键概念，理解并正确判定候选码，是进行数据库设计、范式分析和保证数据完整性的基础，候选码并非一个单一的字段，而是一个或一组属性的组合，它必须满足两个核心条件：唯一性和最小性。
候选码的两个核心属性
要准确判定一个属性集是否为候选码,必须严格依据以下两个基本准则进行检验：
唯一性
唯一性是指候选码的值必须能够唯一地确定关系中的每一个元组，换句话说，在任何一个时刻，表中不允许存在两个不同的元组，它们在该候选码上的属性值完全相同，这个属性集是区分所有记录的“指纹”，确保了数据的可识别性，在一个学生表中，每个学生的“学号”都是独一无二的，学号”属性满足唯一性。
最小性
最小性，也称为不可缩减性，是区分候选码与超码的关键，它指的是在候选码的属性集中，任何一个属性都不能被移除，否则该属性集将不再满足唯一性，这意味着候选码是能够保证唯一性的“最小”属性组合，如果一个属性集满足唯一性，但其某个真子集也满足唯一性，那么这个属性集就不是候选码,而是一个超码。
如果（学号，姓名）这个组合能唯一标识一个学生，但单独的“学号”已经可以唯一标识了，学号，姓名）就不满足最小性，它只是一个超码，而“学号”才是候选码。
候选码的判定方法与步骤
在实际操作中,我们可以通过一个系统性的流程来寻找和判定一个关系模式中的所有候选码。
第一步：列出所有可能的属性集
从单个属性开始，逐一考察它们是否满足唯一性，如果单个属性不满足，则考虑包含两个属性的组合，然后是三个属性的组合，以此类推,直到找到所有满足唯一性的属性集。
第二步：验证唯一性
对于每一个在第一步中选定的属性集，扫描整个关系表（或在设计阶段分析数据语义和业务规则），确认是否存在重复的值，如果该属性集的值组合在表中是唯一的,那么它就是一个超码。
第三步：验证最小性
这是筛选候选码最关键的一步，对于每一个已经验证为唯一的超码，尝试从中逐一移除属性,并检查剩下的属性子集是否仍然满足唯一性。
- 如果移除任何一个属性后，唯一性被破坏（即出现重复），那么原始的超码就满足最小性,它是一个候选码。
- 如果移除某个属性后，剩下的子集依然能保证唯一性，说明原始的超码不是最小的,它只是候选码的一个超集。
示例说明
假设我们有一个“学生选课”关系表：SC（Sno, Cno, Grade, Sname），其中Sno是学号，Cno是课程号，Grade是成绩，Sname是学生姓名，并假设一个学生可以选修多门课程，一门课程可以被多个学生选修,学生姓名可能重复。
| 属性 | 唯一性分析 | 最小性分析 | |
|---|---|---|---|
| Sno | 否（一个学生选修多门课，Sno会重复） | 不是候选码 | |
| Cno | 否（一门课被多个学生选修，Cno会重复） | 不是候选码 | |
| (Sno, Cno) | 是（一个学生的一门课只有一个成绩记录） | 移除Sno剩Cno，不唯一；移除Cno剩Sno，不唯一。 | 是候选码 |
| (Sno, Cno, Sname) | 是 | 移除Sname后，(Sno, Cno)依然唯一。 | 是超码，非候选码 |
通过这个表格分析，我们可以清晰地看出，只有（Sno, Cno）这个属性组合同时满足了唯一性和最小性,因此它是该关系模式唯一的候选码。
候选码与其他相关概念的区别
在数据库设计中，有几个与候选码密切相关的概念,明确它们的区别至关重要。
候选码 vs. 主码：一个关系模式中可以存在多个候选码，但数据库设计者必须从所有候选码中选择一个作为主码，用于实现主要的唯一性约束，主码是物理层面的实现，而候选码是逻辑层面的概念，未被选中的候选码有时被称为“备用码”。
候选码 vs. 超码：如前所述，超码是所有能唯一标识元组的属性集的统称，候选码是超码的一个子集，特指那些满足最小性的超码，所有候选码都是超码,但并非所有超码都是候选码。
候选码 vs. 主属性：任何一个作为候选码一部分的属性，都被称为主属性，如果（A, B）和（C, D）都是候选码，那么属性A, B, C, D都是主属性,不包含在任何候选码中的属性则被称为非主属性。
判定数据库中的候选码是一个严谨的逻辑过程，核心在于紧扣“唯一性”和“最小性”两大原则，通过系统地分析属性组合，并依次进行唯一性和最小性的双重检验，我们就能准确地找出所有候选码，这不仅为后续选择主码提供了依据，也为进行数据库范式优化、消除数据冗余和保证数据一致性奠定了坚实的基础。
相关问答FAQs
问题1：如果一个表中有多个候选码，应该如何选择主码？
解答： 当一个表存在多个候选码时,选择哪一个作为主码需要综合考虑以下几个因素：
- 稳定性：选择那些值几乎从不改变的属性作为主码。“身份证号”比“手机号”更稳定,因为手机号可能会更换。
- 简洁性：在满足稳定性的前提下，选择数据类型最简单、长度最短的候选码，这有助于提高索引和查询的效率，整数类型的 surrogate key（代理键，如自增ID）在性能上优于长字符串或复合主键。
- 业务意义：选择对用户和业务逻辑最有意义的候选码，对于一个订单表，“订单号”比一个系统生成的无意义ID对用户更友好，但需要注意的是，业务主键有时可能违反稳定性原则。
最终的选择是一个在性能、稳定性和业务便利性之间的权衡。
问题2：在没有具体数据表的情况下，仅凭函数依赖集如何理论地找出候选码？
解答： 在数据库设计的理论分析阶段，我们通常通过函数依赖（FD）来推导候选码，而不是依赖实例数据，基本方法是寻找一个属性集X，使得X的闭包X⁺包含了关系模式中的所有属性,具体步骤如下：
- 属性分类：将关系模式R的所有属性分为四类：
- L类：仅在函数依赖集FD中出现在左侧的属性。
- R类：仅在FD中出现在右侧的属性。
- N类：在FD中既未出现在左侧也未出现在右侧的属性。
- LR类：在FD中既出现在左侧也出现在右侧的属性。
- 快速判断：
- 如果存在N类属性,它们必须包含在任何一个候选码中。
- L类属性通常也属于候选码,因为它们不被任何其他属性决定。
- R类属性绝不会出现在任何候选码中（除非它是L或LR类的一部分）。
- 构造与验证：从必然属于候选码的属性（如N类和L类）开始，计算它们的闭包，如果闭包已经包含了所有属性，那么这个属性集就是一个候选码，如果没有，则需要从LR类属性中逐步选择加入，直到闭包包含所有属性为止，这个过程可能需要多次尝试和组合,以找到所有可能的候选码。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复