1

在 DBMS 中，我们有

  1. Superkey - 唯一标识表中行的一个属性或一组属性。
  2. 候选键 - 唯一标识表中行的属性或属性集。超级密钥和候选密钥之间的区别在于，候选密钥的任何子集都不能作为候选密钥。
  3. 主键 - 选择的候选键，成为唯一标识行的属性。

如果我们想识别两个表之间的多对多关系，我们可以定义一个联结表，例如：

表：

Author(AuthorID, FirstName, LastName) -- AuthorID is primary key
Book(BookID, BookTitle) -- BookID is primary key

要创建两者之间的关系：

AuthorBook(authorID, BookID) -- together authorID and BookID are primary key

我在想 bookID 和 authorID 在他们自己方面都是主键。

由于候选键（因此也是主键）不能有包含候选键的子集，那么 authorID 加上 BookID 怎么能是主键呢？这似乎打破了主键的定义。

我知道这可能是现实世界和理论之间的区别，但是由于我读过的 DBMS 教科书似乎以这种方式定义联结表并以这种方式定义主键，因此那里似乎存在脱节。

我误解了这个概念吗？

4

1 回答 1

2

当我们使用其中一个术语时，我们必须谈论给定的表（变量、值或表达式）。一个表的超级键、CKs 和 PKs 不是由它的属性在其他表中扮演的角色决定的。它们取决于在给定的业务规则下该表可能出现的有效值。

Superkey - 一个属性或一组属性，用于唯一标识数据库中的一行。

给定表的超键可以定义为一组“唯一标识行”的属性。（不是数据库。）尽管引用的短语是一种速记，如果您还不知道它的含义，那么它的描述就不是很清楚。

给定表的超键可以定义为一组属性，其子行值只能在表中出现一次。或者作为一组属性，在功能上确定表中的每一组属性。

当一个超级键只有一个属性时，我们可以草率地谈论该属性是一个超级键。

候选键 - 唯一标识数据库中行的一个属性或一组属性。

确实，某个表的每个 CK（候选键）都是该表的超键。但是您的意思是，当/当且仅当某些其他条件成立时，根据定义，一组属性是超级键。但是你在写这部分的时候并没有清楚地说明这一点。

超级密钥和候选密钥之间的区别在于，候选密钥的任何子集都不能作为候选密钥。

不。一个集合是它自己的一个子集，所以一个CK是它自己的一个子集，所以一个CK总是有一个子集是一个CK——它自己。你的意思是，没有适当的/更小的子集。那么你的说法是正确的。但同样真实且更重要的是，CK 的任何适当/较小的子集都不是超级密钥。

您实际上并没有在本段中定义“CK”。给定表的 CK 可以定义为该表的超键，不包含作为该表超键的适当/较小子集。

主键 - 选择的候选键，成为唯一标识行的属性。

否。给定表的 PK（主键）定义为您决定调用 PK 的该表的一个 CK。（不是属性。）

请注意，CK 和 PK 是超级密钥。PK 与关系理论无关。

要创建两者之间的关系：

AuthorBook(authorID, BookID) -- together authorID and BookID are primary key

超级键和 CK 是什么以及 PK 可以是什么取决于表中的 FD（功能依赖关系）。但是如果你假设这是一个多对多表，那么它需要一个 authorID-bookID 对来唯一标识一行，所以只能有一个 CK，{authorID，bookID}。所以这是唯一可能的PK。所以 {authorID} 和 {bookID} 不能是超级键或 CK 或 PK。

您可以通过查看示例和应用定义来了解这一点。

authorID bookID
      1      a
      1      b

这里 authorID 不唯一标识一行。所以它不能是超级键。所以不可能是CK。所以不能PK。

我读过的教科书似乎以这种方式定义连接表并以这种方式定义主键

不，他们没有。

然而，他们确实说，联结表中的某些属性集和超级键、CK 和 PK 子集是联结表中的 FK（外键），它们是那些其他表的 CK（可能是 PK）/在那些其他表中表。

给定表的 FK 可以定义为表中的一组特定属性，其子行值必须作为某个其他表中的某些 CK 子行出现。

但既然你说这是一个联结表，大概 {authorID} 是作者表的 FK，其值出现在 CK/PK 下，而 {bookID} 是书籍表的 FK，其值出现在 CK/PK 下. 因此，AuthorBook 中的 FK {authorID} 引用了 Author 中的 {authorID} 和 AuthorBook 中的 FK {bookID} 引用 Book 中的 {bookID}。

PS PK 和其他术语在 SQL 中具有其他含义。声明的 SQL PK 可以在其中声明一个较小的 SQL UNIQUE。SQL“唯一性”本身是根据 SQL NULL 定义的。可以合理地说，SQL PK 更像是关系超键，而不是关系 PK。类似地，SQL FK 更让人联想到我们可以合理地称之为关系外键而不是关系外键。

于 2020-04-04T21:28:55.630 回答