空 SQL 表是否有超键？每个 SQL 表都有一个吗？

Question

我知道超级键在 SQL 中的含义，但我有以下问题：

1. 空 SQL 表是否总是有超级键？
2. 是否每个 SQL 表都始终有一个超级键？

Answer 1

TL;DR“超级密钥”是一个RM (Relational Model of Data) 术语。 SQL 中没有标准用法。 SQL 表的超键可以合理地非正式地称为列集，您可以声明 primary key 或 unique not null，当表最多包含一行时可能加上 {}（尽管您不能声明它）。 “合理地非正式地”，因为 SQL 表不是 RM 关系。但是如果一个表不包含重复行和空值，那么我们可以合理地说它是一个关系，并且像每个关系一样，它有一个或多个超级键。 基本关系或关系表达式的超键的定义考虑了它可以持有的所有可能值，因此它的当前值不会影响它的超键是什么。根据 superkey 的定义，在空关系 value 中，每个属性子集都是一个 superkey。

关系“超级键”

在数学中，“关系”的一个含义是一组类似表格的行状“元组”，它们是值的列表。它表示关系（船）/关联——在数学中也称为“关系”。这就是“RM”中的“R”的来源，也就是“关系数据库”一词的来源。 (Codd 1970) (Date 2015) 同样，“ERM”（实体-关系模型）来自“关系”作为关系/关联。 (Chen 1976) 在 RM 上下文中，“关系”也类似于表，但通常包含一组“元组”，它们是成对的“属性”名称和值的集合。 （或者它可能是数学关系或混合关系。）“超级键”有两种 RM 意义——关系值和关系变量或表达式。关系值的超键是一组属性，其中关系不包含具有该子元组的两行。关系变量或表达式的超键是一组属性，在每种情况/状态下，它都不包含带有该子元组的两行。因此，当变量可以保存的所有值都具有该超键时，该变量具有某个超键。

（在已出版的学术教科书中找到一个定义。请注意，当定义说名称的“forever”或“for all”值时，它们意味着当没有这样的值时满足这样的条件。类似地，当“for some" & "there exists(s)" 指的是命名值，它们并不意味着名称必须命名不同的值。）

一个空的值恰好将每个属性子集都作为一个超键。 变量或涉及变量的表达式的超键的定义考虑了它可以评估的所有可能值，因此它的当前值不会影响它的超键是什么。

每个关系都有一个或多个超键：一个关系包含一组元组，所以一个元组值最多出现一次，所以所有属性上的子元组的值最多出现一次，所以所有属性的集合是超级键。

SQL 与关系

SQL 表不是关系。它让人联想到允许重复和空值的数学和属性关系的混乱。所以 SQL 数据库被称为“关系型”，但它们很难体现 RM。

由于 SQL 表与关系的相似之处，涉及关系的术语被草率地应用于表。但是虽然你可以借用术语并赋予它们 SQL 含义——值、表、FD（函数依赖）、超键、CK（候选键）、PK（主键）、FK（外键）、连接、谓词、NF （范式）、规范化、1NF 等——你不能仅仅用这些 SQL 含义代替 RM 定义、定理或算法中的那些词，并得到一些合理或真实的东西。此外，RM 概念的 SQL 演示几乎从不实际上告诉您如何将 RM 概念正确地应用于 SQL 数据库。他们只是鹦鹉学舌 RM 演示文稿，不知道他们对术语的 SQL 含义的使用是否会使事情变得荒谬或无效。 （“几乎”，因为我希望有一些。）

如果您在某些 RM superkey definitions 中将“relation”替换为“table”（允许重复和/或空值），那么您将获得 SQL superkey 的定义作为满足primary key 或unique not null 约束的列集。对于某些 other RM 超级键定义，当表最多包含一行时，您会得到这些集合加上 {}。 （因为它“识别”了任何行。）（您可能只会发现使用第二种风格的措辞的人，但认为它定义了第一种风格的措辞的作用。他们不会知道他们通过误解术语来滥用定义。）有些人可能只使用约束定义。您可能会发现这三个中的任何一个都使用了“UK”（唯一键）。

当一个表既不包含重复行也不包含空值时，我们可以将其解释为关系，将行作为元组，将列作为属性。那么我们可以合理地说表的超级键是关系的超级键。

"1NF" has no single meaning.“规范化”或“非规范化”或“UNF”或“0NF”或就此而言的“关系”。
What to do with null values when modeling and normalizing?

PS：“CK”不要将超级键与 CK 混淆。 CK 是一个不包含更小的超级密钥的超级密钥。 （因此，我们说 CK 是“最小”或“不可约”的超键。）关系可以有多个超键和 CK。 PK 是选择用来区分为 PK 的某个 CK。 SQL primary key & unique not null 声明我们可以称之为 SQL 超级键，但不一定是最小的，我们可以称之为 SQL CK。因此，当您在 SQL 上下文中听到“PK”时，您必须确定它是否意味着“通过primary key 声明的（SQL 超级键）列列表（可能是也可能不是 SQL CK）”和/或“可区分的 SQL 超级键（可能或者可能没有通过primary key) 声明”和/或“可区分的SQL CK（可能或可能没有通过primary key 声明）”。你总是必须问“key”是什么意思。通常，SQL 超级键——不管是什么意思。

PS：“Relation(ship)”弄清楚“relation”和“relationship”中的每一个是什么意思——关联？桌子？ FK？在 RM 数据库中，每个关系值（变量或表达式的）represents a relation(ship)/association。但是“关系”（有时，“关系”）也（以一种根深蒂固的方式）用于 FK——不是在 RM 或 ERM 中，而是在 pseudo-RM & -ERM methods that misinterpret/misunderstand/misrepresent them 中，其根源早于它们。 （不幸的是，数据库行业的 RM 教育非常差。）FKs、PK、CK、超级键和other 约束是not needed to query & update。 （他们是为了诚信。）

Answer 2

超级键只是唯一标识记录的列或列组。例如员工表中的员工编号。

1. 当该表为空时（即尚未输入任何员工），该表的键仍然是员工编号。键是表的属性，与其中的记录无关。
2. 在某些情况下，表没有超级键。这些情况很少见。大多数情况下，这些是列表，例如“员工在什么时间拨打了哪个号码”。您将存储员工编号、小时数和电话号码。如果员工在同一小时内两次拨打同一号码，则有两条相似的记录，因此没有唯一键。但是，大多数情况下，这种情况是可以避免的（在给出的示例中，我们可以将完整时间存储到秒甚至毫秒而不是小时，从而获得由员工编号和通话时间组成的唯一键）。

Answer 3

以下是 Ronald Fagin 1981 年的 A Normal Form for Relational Databases that Is Based on Domains and Keys（定义域键范式的论文，D.K.N.F.）中的一些精确定义：

• 属性：一组X。 例如。 {城市，国家}。
• X-tuple：域的函数集合属性X。 例如。 {(city, Paris), (country, France)}。
• X-关系：一组X-元组。 例如。 {{(city, Paris), (country, France)}, {(city, Berlin), (country, Germany)}}。
• X-约束：域X-关系集和codomain {0, 1} 的函数。对于将X-关系R映射到1的X-约束σ，则称R 服从 σ并且σ 持有在R中。
• 关系模式：第一个条目一组属性 X 和第二个条目一组 X-约束的元组。
• 数据库模式：一组关系模式。
• 关系模式实例：一个X-关系，具有属性并遵守关系模式的约束。
• 功能依赖（FD）约束：A → B 其中A, B ⊆ X 在 X-关系 R 中成立，因此对于所有 t1，t2 在R, (t1[A] = t2[A] ⇒ t1[B] = t2[B])。
• 密钥依赖 (KD) 约束：KEY(A) 其中 A ⊆ X 在 X-关系 R 使得 A → X 在 R 中成立。 A 被称为关系模式（及其实例）的 superkey（当它不可约时也称为 key）键依赖约束 KEY(A)。

1. 空 SQL 表是否总是有超级键？
2. 是否每个 SQL 表都始终有一个超级键？

1. 是的，因为空的 X-关系服从任何键依赖约束 KEY(A) 其中 A ⊆ X.

   证明。 对于 {} 中的所有 t1、t2，(t1[A] = t2[A] ⇒ t1[X] = t2[X])，相当于对所有t1, t2, (t1, {} 中的 t2 ⇒ (t1[A] = t2[A] ⇒ t1[X] = t2[X]))，这是一个vacuous truth作为先行词 t1, t2 in {} 的第一个条件为假。

2. 是的，因为每个 X-关系都遵循键依赖约束 KEY(X)。

   证明。 令 R 为 X-关系。对于R中的所有t1、t2，(t1[X] = t2[X] ⇒ t1[X] = t2[X ]）。