候选键的特殊用法，最小的性质

Question

我知道，

“候选键是超级键的最小子集”

这意味着Candidate键中不能有任何其他超级键。

我不明白的是，

我们在数据库设计中可以在哪里使用候选键的这个特殊属性。 特殊属性意味着： - “候选键中不能有超级键。”

示例解释非常感谢。

注意：此问题取决于最常见的问题参考between keys，Finding/Identifying Candidate keys

Answer 1

我认为候选键的最小特性对于主键中的唯一约束以及用户定义的唯一约束是有用的。这些允许我们确保在数据库中唯一地表示功能依赖性，这对于数据一致性很重要。

如果我们使用非最小超级密钥作为主键，我们可以为主键的子集记录具有相同值的多个行，仅在子集的补码中变化。如果子集是函数依赖的决定因素，我们可能会有不一致的数据。

例如，让我们考虑一个简化的车辆登记表。每辆车都有唯一的注册号和唯一的引擎号，因此这两个属性都是候选键。这些超集都是超级密钥，例如两者的结合。

我用蓝色表示主键。如您所见，每行的主键值都是唯一的，但该表允许使用不同的关联属性多次记录相同的vehicle_registration和engine_number。注册“abc123”的车辆是XC60还是XC90？我们不知道，我们的数据不一致。

更好的设计会将每个候选键作为单独的唯一约束处理（无论哪个被选为主键）。这样可以防止同一车辆登记或发动机号码被记录两次。

Answer 2

DBMS使用唯一性约束强制执行功能依赖性。对候选键的唯一性约束意味着保证满足包括候选键的每个超键的每个依赖性。因此，从数据完整性的角度来看，确定正确的候选键非常重要，这样才能强制执行正确的超级键依赖关系。例如，对表的属性{A，B}的唯一性约束将强制执行超级密钥{A，B，C}，{A，B，D}，{A，B，C，D}但不强制{A，C， d}。识别正确的候选键可以使数据库设计人员无需单独执行每个超级密钥。

识别候选键是有意义的第二个原因是确保用户可以准确地使用和解释数据。数据的用户和消费者需要理解记录在数据库中的事实并将它们与数据库外的真实对象或概念相关联。候选键是识别属性，可以执行从数据库到现实的映射。如果使用非最小超级密钥来执行这样的映射，则可能存在更大的模糊和错误的可能性。

例如，假设公司数据库中员工的密钥是{EmpNum}。如果数据库的用户错误地认为密钥是{EmpNum，DeptCode}，那么她可能会错误地认为以下信息指的是两个不同的员工，而不是一个。

+-------+---------+
|EmpNum |DeptCode |
+-------+---------+
|14972  |SALES    |
+-------+---------+

+-------+---------+
|EmpNum |DeptCode |
+-------+---------+
|14972  |HR       |
+-------+---------+

实际上，也许单个员工14972已从一个部门转移到另一个部门。或者也许这名员工真正同时被分配到多个DeptCode。无论哪种方式，这些解释取决于用户理解只有一个人被密钥EmpNum = 14972识别。

成功的数据库设计要求设计人员识别密钥，验证密钥的适用性并确保数据库用户熟悉密钥的内容 - 至少对于用户需要理解和使用的重要实体而言。