【发布时间】：2016-03-08 05:34:11
【问题描述】：
问题
主键是否在功能上确定表中的所有其他属性？
我的想法
肯定是必须的，不是吗？这不就是主键的意义吗？
【问题讨论】：
-
关于“主键点”，请参阅我的答案及其链接。
标签： relational-database primary-key functional-dependencies
【发布时间】：2016-03-08 05:34:11
【问题描述】：
根据定义，关系的 all 超键（不仅仅是主键）和该关系中的 all 属性（不仅仅是非键属性）之间存在功能依赖关系)。
【讨论】：
在至少处于第一范式的表中，主键决定了表中的每个属性。正如您所说，这就是主键（以及一般的候选键）的意义所在。
【讨论】：
-
@SwaroopJoshi 范式描述关系，正如 philipxy 解释的那样，主键在关系理论中不起任何作用。为了澄清我的观点，在具有主键并表示关系（相当于至少处于 1NF 中）的表中，该主键必然会在功能上确定表中的每个属性。在不代表关系的表中，我们不一定能做出这样的保证。正如其他受访者指出的那样，在任何关系中，所有超键都将决定关系的所有属性。
表的超级键（UNIQUE NOT NULL 列集）是“在功能上确定表中所有其他属性”的列集。表的候选键（不包含更小的超键的超键）对于规范化很重要。 主键只是一个可区分的候选键。
为什么区分一个？
主键在关系理论中不起作用。主要的实际作用是在其他表中通过外键识别行/实体/关联时保持一致性。
-
Codd（与理论相反）允许在候选键列中使用 NULL。 （SQL 也是如此。）来自他的"Understanding Relations" 文章：
与候选密钥相关的基本完整性原则 是，对于每个基本关系，至少有一个 禁止候选键取空值。
通常，没有必要禁止空值 在多个候选键中 - 因此，常见做法 精确地指定一个这样的键作为主键： 即，空值的唯一候选键 禁止。
（DBMS、CASE 工具和 ORM 通常使用主键作为与候选键关联的默认值，通常是物理/实现键。但这begs the question。）
所以超键起识别作用，候选键是特殊超键，主键不是特别特殊的候选键。
【讨论】：