问题标签 [candidate-key]

在维基百科 BCNF 定义如下

一个关系模式 R 是 Boyce-Codd 范式当且仅当对于它的每一个依赖关系 X → Y，至少满足以下条件之一：

X → Y 是一个平凡的函数依赖 (Y ⊆ X)

X 是模式 R 的超键

我想知道，为什么它被定义为“超级密钥”而不是“最小超级密钥”。

考虑一个关系模式 R(A,B,C,D,E) ，让 (A,B) 是一个键（它的最小）。然后 AB->CDE 成立（在此特定示例中，根据模式的定义，也不存在其他重要的功能依赖项）。(A,B,C) 也是一个超级键。ABC->DE 也成立，但它微不足道。我的疑问是，如果我们只指定最小 superkey 的条件，那么 superkey 的条件已经暗示了不是吗？在我做的所有 BCNF 示例问题中，检查模式是否在 BCNF 中。如果存在所有非平凡函数依赖的 LHS，则为“关键”。然后架构在 BCNF 中。如果它持有一个密钥，那么基于该密钥的所有超级密钥都是如此，不是吗？

在给定与属性 ABCD 和功能依赖 A → B 的关系的情况下，如何编写一个 SQL 语句来证明候选键 ACD 成立？我知道这里有类似的东西：SQL statement to proof that A->B in a R(ABCD)，但不知道如何为这个约束编写查询。

我有下表：

在没有任何知识的情况下，我必须确定可能的候选键。显然它将是 {Book_Name, Author, Edition}。从我教授的解决方案来看，这是正确的。但我会更进一步说 {Book_Name, Author, Year} 也是正确的。但在这方面，他说“我们应该考虑到某些书籍可能有一个发行周期，这会导致在给定年份出现多个版本。” 但是为什么有人（像他所说的那样来自“常识”）在同一年（或根本）发行两本或更多同名和版本的书？

对此你们怎么看？我不明白。

我有一个具有函数依赖关系的关系 R(V,W,X,Y,Z)

V → W

WX → Z

ZY → V

由于 X 和 Y 不在 LHS 上，我发现 {XY} 的闭包等于 {V,W,X,Y,Z}，使 XY 成为候选键。当我使用这个工具检查我的答案时，它说 XYV、XYW 和 XYZ 是候选键，而闭包 XY 是 {X,Y}。为什么 XY 不是候选键？

我很困惑如何识别第一范式中的主键

在第一个示例中：我可以理解 SR_ID 和 Cus_No 是主键的原因。但是为什么 Mngr_ID 不是主键呢？为什么 Mngr_ID 取决于 SR_ID 和 Cus_No

在另一个例子中：为什么 staff_No 不是主键？因为在讲座中，我教授考的第一步就是从找PK开始。但我不知道该怎么做？在本例中，所有其他属性都可以依赖于 property_no 和 IDate，因此它们是 pk。但我不明白为什么 staff_no 依赖于 property_no 和 IDate

我试图找到关系 R = ABCDE 的键，具有功能依赖 AB->C、C->D、C->E、D->A、E->B

当依赖项的右侧缺少一些属性时，我知道如何找到键。但是这里所有的属性都出现在右侧。我不确定如何找到密钥，也找不到这个特定示例的解释。

假设我们有一个关系 R(A,B,C,D,E) 与候选键 {A,B} , {C,D} 并让 E 是一个非素数属性。

如果存在依赖 C->E 则它是部分依赖，因为 E 依赖于候选键 {C,D} 的一部分

依赖 BC->E 是部分的吗？

关系 R: [A,B,C,D,E,F] FD1: (A,B) - C,F FD2: (C,D) - E FD3: (D,E) - B

(x,y) 是这里的候选键吗？如果不是，那是什么？

我试图了解如何找到最少的密钥。该作业为我提供了以下任务：

找到 3 个相关的最小键（每个键是一组属性）。

答案是：

我不明白如何得到答案。我将不胜感激任何指导。

对于我的家庭作业，我必须为图片中的图表开发 sql 代码，但对于医生关系，我如何显示候选键？有没有特殊的声明方式？