我对候选键，主键，迷你超级键有些疑惑。
根据定义：
主键：只有1个属性，所以它必须是最小的超级键，它也是候选键（因为它的minial超级键）
第一个结论：如果一个键是主键，那么它也是一个候选键和一个最小的超级键
以下观点我认为这是真的，但我不确定。有人可以和我一起确认吗？
如果它是最小的超级密钥，那并不意味着它是主键。但这意味着它是候选人的关键。
如果它是候选键，它不一定是mininal键，也不需要是 主键。
结论：
主键：只有1个值，可以识别整行。它也是候选键和最小
最小超级密钥：1个值或字段组合可以识别整行，因此它是候选键，但不是必需的主键。但如果取出任何一个字段，那么它就不再是一个关键
候选键：1个值或字段组合可以识别整行但不必是最小值或主要行。
答案 0 :(得分：1)
根据Wikipedia，候选键是关系的最小超级键，它可以由多个属性组成。
您的关系可能有多个候选键;每个候选键都可以作为主键 - 每个候选键都唯一且可靠地识别您关系中的每个元组。
从那些（可能是几个）候选键中，您选择一个作为主键（基于某些要求或其他因素）。
关系只能有一个主键 - 但主键可以由多个属性（表列）组成。
答案 1 :(得分：1)
简短的回答比你描述的简单得多。密钥（也称为候选密钥或主密钥或辅助密钥或备用密钥）是一个密钥最小的超级钥匙。换句话说，键是属性的集，它们保证是不可简化的唯一且永远不为空。键可能包含一个或多个属性，有时也包含零属性（零属性键相对不常见，不经常讨论，但仍然可用作键）。
更长的解释：
按照惯例，为方便起见，每个关系的一个密钥通常被指定为“主要”密钥，这意味着它被认为在某种程度上具有特殊意义。特殊意义可以是任何东西 - 通常它是在其他关系中被引用为外键的键或者是该关系的“首选”标识符的键。
重要的是要理解，“主要”密钥与任何其他密钥根本没有区别，除非您选择这样做（或者由于DBMS软件的限制而被迫）。因此，原则上没有绝对的理由说明为什么必须始终指定一个“主”键。假设每个关系至少有一个候选键（根据定义它必须），那么你也可以调用零，这些键中的一个或多个“主”。然而，这是一个非常强大的约定，只指定一个且只有一个主键，这是基于SQL的DBMS语法支持的约定。
作为历史细节问题，应该注意的是，关系模型的发明者EFCodd最初使用术语主键来表示任何和所有键关系，而不仅仅是一个。然而，在现代使用中，术语候选键用于最初称为主键的术语，而“主要”的名称以我上面描述的方式使用。不幸的是，在这一点上存在很多混淆，你会经常看到声称“主要”键以某种方式与其他候选键有某种不同。
这是Hugh Darwen关于键的主题：
relvar可以有多个键，但我们只选择一个用于下划线 并将其称为主键。选择是任意的，所以 从逻辑上讲，初级概念并不是非常重要 观点。然而，关键的一般概念非常重要！该 术语候选键意味着与键完全相同（即，添加 候选人没有真正的意义 - 这是特德·科德提出的 因为他认为每把钥匙都被提名为候选人 主键）。
答案 2 :(得分：1)
因此，我从您的问题中得出的结论是，您对DBMS中通常使用的基本3键（或更确切地说是4）感到困惑。我将尝试用简短易懂的语言解释它们：
1） SUPER KEYS ：
可用于唯一标识表中每个元组（行）的单个属性或属性集称为超级密钥（将其视为大量密钥，可以将其称为超级密钥，因为那里可以是许多属性组合，使其可以唯一识别） - 但只记得超级键“UNIQUENESS”的一件事。
2）候选钥匙（MINIMAL SUPER KEYS）：
在我们获得的所有超级键中，我们开始识别最小的键，即。不能进一步细分（在属性的构成方面），如果它们被打破，我们就失去了CANDIDATE KEYS类别的唯一性 - 只记得候选键的一件事“ UNIQUENESS”+“IRREDUCIBILITY”< /强>
3） PRIMARY KEY ：
现在，我们选择了一个最优化的方法来搜索表格中的任何一行以使其成为主键。现在，我们选择了一个最优化的方法来设置主键。设计师可以选择哪个键能够使其成为主键。候选键，但仍然，它更喜欢遵循一些规则：
A）喜欢用数字而不是文字作为PK。
B）更喜欢拿一个数据所有者拥有控制权的密钥。
C）更喜欢长度较短的那个。
d）并且，如果它们恰好存在，则更喜欢非复合键。
我希望这可以帮助您明确这个概念。