我知道SQL中的术语“SuperKey”代表什么，但我无法理解具体的东西，我想要一些帮助。
在没有数据的表中，有超级密钥吗？
在任何表中，总会存在一个吗？
TL; DR“Superkey”是RM (Relational Model of Data)术语。 SQL中没有标准用法。 SQL表的超级键可以合理地非正式地说是可以声明primary key或unique not null的列集，当表最多保存一行时可以声明{}尽管你不能声明它。 “合理非正式地”，因为SQL表不是RM关系。但是如果一个表没有重复的行并且没有空值，那么我们可以合理地说它是一个关系，并且像每个关系一样，它有一个或多个超级键。基本关系或关系表达式的超级键的定义考虑了它可以容纳的所有可能的值，因此其当前值不会影响其超级键。根据超级键的定义，在空关系值中，每个属性子集都是超级键。
关系“超级钥匙”
在数学中，“关系”的一个含义是一组类似于行的“元组”，它们是值列表。它代表一种关系（船舶）/关联。这就是“RM”中的“R”来自哪里，这就是术语“关系数据库”的来源。 (Codd 1970) (Date 2015)类似地，“ERM”（实体 - 关系模型）来自“关系”作为关系/关联。 (Chen 1976)在RM上下文中，“关系”也是表格式的，但通常包含一组“元组”，这些“元组”是“属性”名称和值对的集合。 （或者它可能是数学关系或混合。）有两种RM“超级钥匙” - 关系值和关系变量或表达式。关系值的超级键是一组属性，其中关系不包含具有该子组的两行。关系变量或表达式的超级键是一组属性，在每种情况/状态中，它不包含具有该子元素的两行。因此，当一个变量所拥有的所有值都具有该超级密钥时，它就具有某个超级密钥。
（在已发表的学术教科书中找到一个定义。请注意，当定义为名称表示“为每个”或“为所有”时，它们意味着在没有这样的值时满足这样的条件。同样，当“为某些”时“存在（s）”指的是命名值，它们并不意味着名称必须命名不同的值。）
空值恰好将每个属性子集都作为超级键。涉及变量的变量或表达式的超级键的定义考虑了它可以评估的所有可能值，因此其当前值不会影响其超级键。
每个关系都有一个或多个超级键：一个关系包含一组元组，因此元组值最多出现一次，因此所有属性的子元素值最多出现一次，因此所有属性的集合都是超级键。
SQL与关系
SQL表不是关系。它让人想起混乱的数学和属性关系，允许重复和空值。所以SQL数据库被称为“关系型”，但它们很难体现RM。
由于SQL表与关系的相似性，涉及关系的术语被粗略地应用于表。但是，尽管你可以借用术语并赋予它们SQL的含义（值，表，超级键，CK，PK，FK，连接，谓词，NF，规范化等），你不能只用这些SQL的含义替换这些词的含义。 RM定义，定理或算法，并获得明智或真实的东西。此外，RM概念的SQL演示几乎从未实际告诉您如何将RM概念合理地应用于SQL数据库。他们只是嘲笑RM演示文稿，不知道他们是否使用SQL术语来使术语变得荒谬或无效。 （“差不多”，因为我希望有一些。）
如果在某些RM超级键定义中将“关系”替换为“table”（允许重复和/或空值），则可以获得SQL超级键的定义，作为满足primary key或unique not null约束的列集。对于某些其他RM超级键定义，当表最多包含一行时，您可以获得这些集加{}。 （因为它“识别”任何一行。）（你可能只会找到使用第二种语法的人，但认为它定义了第一种语句的作用。他们不会因为误解术语而误解定义。有些人可能只使用约束定义。您可能会发现三者中任何一个都使用“UK”（唯一键）。
当表不包含重复行或空值时，我们可以将其解释为关系，将行作为元组和列作为属性。然后我们可以合理地说表的超级键是关系的超级键。
PS：“CK”不要将超级密钥与CK（候选键）混淆。 CK是超级密钥，不包含任何较小的超级密钥。 （因此，CK是一个“最小”或“不可简化”的超级密钥。）一个关系可以有多个超级密钥和CK。 PK（主键）是选择为PK的一些CK。 SQL primary key和unique not null声明我们可以称之为SQL超级密钥，但不一定是最小的，我们称之为SQL CK。因此，当您在SQL上下文中听到“PK”时，您必须确定它是否意味着“（SQL超级密钥）列列表通过primary key声明”和/或“区分SQL超级密钥（可能或可能不是通过primary key声明）”和/或“尊重SQL CK（最小SQL超级密钥）”。你总是要问“关键”是什么意思。 （通常，SQL超级密钥，无论这意味着什么。）
PS：“关系（船舶）”直截了当地说出“关系”和“关系” - 关联？表？ FK（外键）？在RM数据库中的每个关系值（变量或表达式）represents a relation(ship)/association。但是“关系”（有时候，“关系”）也被（错误地）用于（错误地）用于FK - 不是在RM或ERM中，而是在pseudo-RM & -ERM methods that misinterpret/misunderstand/misrepresent them中，其根源早于它们。 （不幸的是，数据库行业的RM教育非常糟糕。）FKs，PKs，CKs，superkeys和other约束是not needed to query & update。 （他们是为了诚信。）
超级键只是唯一标识记录的列或列组。例如员工表中的员工编号。