我对部分键有点困惑。“Korth 的数据库系统概念”说：
尽管弱实体集没有主键，但我们仍然需要一种方法来区分弱实体集中依赖于一个特定强实体的所有实体。弱实体集的鉴别器是允许进行这种区分的一组属性。弱实体集的判别器也称为实体集的部分键。
我的困惑是，如果弱实体的鉴别器/部分键能够唯一识别属性集，那么它应该被称为主键，而不是部分键，因为主键是那些可以唯一识别所有属性的键关系。
另外，在网上冲浪时，我遇到了部分键的定义，它说：
'部分键是不能唯一标识表中所有记录的键'
它在我的脑海中提出了一个问题，假设如果一个表包含一个由两个或多个属性组成的主键，那么如果我们从中选择一个属性，那么它是否会被称为部分键，作为那个属性是主键的一部分，但它本身不能唯一标识关系中的所有属性。
该定义并没有说“弱实体的鉴别器/部分键能够在表中唯一标识”。它说一个人在一个特定的强实体中识别一个弱实体。
技术术语仅表示它们在特定假设上下文中的定义，包括其他定义。你不能指望同一个词在任何地方都意味着同样的事情。您不能只查看定义的文本并对其适用的情况及其技术术语的含义做出假设，甚至不能假设一个词是否用于技术或日常含义。当有人使用一个术语时，你必须确保你知道他们的意思。
关系超键唯一标识一行。CK（候选密钥）是不包含更小的超级密钥的超级密钥。PK（主键）只是您决定将其称为 PK 的某个 CK。）因此，唯一性并不是将某物称为 PK 或 CK 的理由。（SQL PK/UNIQUE 类似于关系超键。）
book 方法生成不是超键的鉴别器。所以我们可以说它与网络定义一致——对于以这种方法出现的情况。但是，如果一种方法允许生成 CK 或 PK 的鉴别器，那么它使用该教科书的措辞会将“部分密钥”定义为与 Web 定义不同的事物。这种方法不能使用（关系）“PK”作为强 id 加鉴别器，因为它是一个超级密钥，而不是一个 CK 或 PK。（但它仍然可以使用 SQL “PK”，因为这大约意味着主超级键。）
我真的认为这种类型的描述源于任何建模过程的第一步，任何具有任何数据建模经验的人都会不假思索地修复它。
“弱实体”上的 wiki 页面给出了 Header/Detail 对的经典示例，其中详细信息本身没有对标题的引用。考虑一个两页的文档，其中第一页是标题，第二页是详细信息。
就其本身而言，第二页不能唯一标识一行，但当然任何人都会自动添加标题 FK，以便我们可以唯一标识一行。
没有看过你正在读的书，但我认为这就是它的意思。所以我认为你所有的后续推理都是正确的。查看 wiki 页面了解更多信息。