应用错误收集

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

关系＆＃34;超级键＆＃34;

在数学中，一个意思是＆＃34;关系＆＃34;是一组类似行的＆＃34;元组＆＃34;这是价值清单。它代表一种关系（船舶）/关联。这就是＆＃34; R＆＃34; in＆＃34; RM＆＃34;来自，这是术语＆＃34;关系数据库＆＃34;来自。 (Codd 1970) (Date 2015)同样＆＃34; ERM＆＃34; （实体 - 关系模型）来自＆＃34;关系＆＃34;作为关系/关联。 (Chen 1976)在RM上下文中，＆＃34;关系＆＃34;也像桌子一样，但通常拥有一组＆＃34;元组＆＃34;这是一组＆＃34;属性＆＃34;姓名＆amp;值。（或者它可能是数学关系或混合。）有两种RM感觉＆＃34;超级键＆＃34; - 关系值＆amp;关系变量或表达式。关系值的超级键是一组属性，其中关系不包含具有该子组的两行。关系变量或表达式的超级键是一组属性，在每种情况/状态中，它不包含具有该子元素的两行。因此，当一个变量可以容纳的所有值都具有该超级密钥时，它就具有某个超级密钥。

（在已发表的学术教科书中找到一个定义。请注意，当定义说＆＃34;对于每个＆＃34;或＆＃34;对于所有＆＃34;名称的值，它们意味着满足这样的条件时没有这样的价值。同样地，对于某些＆＃34;＆amp;＆＃34;存在（s）＆＃34;参考命名值，他们并不意味着名称必须命名不同的值。）

空的值碰巧将每个属性子集都作为超级键。包含变量的变量或表达式的超级键的定义考虑了它可以评估的所有可能值，因此其当前值不会影响其超级键的含义。

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

SQL与关系

SQL表不是关系。这让人联想到数学与数学的混乱。属性关系允许重复和空值。所以SQL数据库被称为＆＃34;关系＆＃34;但他们很难体现RM。

由于SQL表与关系的相似性，涉及关系的术语被粗略地应用于表。但是，虽然你可以借用术语并赋予它们SQL的含义（值，表，超级键，CK，PK，FK，连接，谓词，NF，规范化等），但你不能仅仅用那些SQL意义来代替那些SQL意义。 RM定义，定理或算法中的单词，得到一些明智或真实的东西。此外，RM概念的SQL演示文稿几乎从未实际告诉您如何将RM概念合理地应用于SQL数据库。他们只是嘲笑RM演示文稿，不知道他们是否使用SQL术语来使术语变得荒谬或无效。（＆＃34;几乎＆＃34;因为我希望有一些。）

如果你替换＆＃34;关系＆＃34;通过＆＃34; table＆＃34; （某些 RM超级密钥定义中的重复和/或空值）然后您将SQL超级密钥的定义作为满足primary key或{{{ 1}}约束。对于某些其他 RM超级键定义，当表最多包含一行时，您将获得这些设置加{}。（因为它＆＃34;标识＆＃34;任何一行。）（你可能只会找到使用第二种语法的人但认为它定义了第一种语句的作用。而且他们不知道他们是通过误解术语来滥用定义。）有些人可能只是使用约束定义。你可能会发现＆＃34; UK＆＃34; （唯一密钥）用于三者中的任何一个。

当一个表既没有重复的行也没有空值时，我们可以将它解释为一个关系，行为元组和＆amp;列作为属性。然后我们可以合理地说表格的超级密钥是关系的超级密钥。

PS：＆＃34; CK＆＃34; 不要将超级密钥与CK（候选密钥）混淆。 CK是超级密钥，不包含任何较小的超级密钥。（因此，CK是一个＆＃34;最小＆＃34;或＆＃34;不可减少的＆＃34;超级密钥。）一个关系可以有多个超级密钥＆amp;中正。 PK（主键）是选择为PK的一些CK。 SQL unique not null＆amp; primary key声明我们可以称之为SQL超级密钥，但不一定是最小的，我们称之为SQL CK。所以当你听到＆＃34; PK＆＃34;在SQL上下文中，您必须确定它是否意味着＆＃34;（SQL超级键）列列表通过unique not null＆＃34;和/或＆＃34;区分SQL超级密钥（可能或可能不通过primary key声明）＆＃34;和/或＆＃34;区分SQL CK（最小SQL超级密钥）＆＃34;。并且总是必须询问＆＃34; key＆＃34;手段。（通常，SQL超级密钥，无论这意味着什么。）

PS：＆＃34;关系（发货）＆＃34; 直截了当地说出每个＆＃34;关系＆＃34; ＆安培; ＆＃34;关系＆＃34; - 关联？表？ FK（外键）？在RM数据库中的每个关系值（变量或表达式）represents a relation(ship)/association。但是＆＃34;关系＆＃34; （有时，＆＃34;关系＆＃34;）也被（错误地）用于FK - 不是在RM或ERM中，而是在pseudo-RM & -ERM methods that misinterpret/misunderstand/misrepresent them中，其根源在它们之前。（不幸的是，数据库行业的RM教育非常糟糕。）FKs，PKs，CKs，superkeys＆amp; other约束为not needed to query & update。（他们是为了诚信。）

以下是 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-relation：一组 X-元组。例如。 {{(city, Paris), (country, France)}, {(city, Berlin), (country, Germany)}}。

X-constraint：域的函数，X-关系和codomain {0, 1} 的集合。对于将 X 关系 R 映射到 1 的 X-约束 σ，据说 R 服从 σ并且σ 保持在R中。

关系模式：第一个条目一组属性 X 和第二个条目一组 X 约束的元组。

数据库模式：一组关系模式。

关系模式实例：一个X关系，它具有关系模式的属性并遵守关系模式的约束。

函数依赖 (FD) 约束：A → B 其中 A, B em> ⊆ 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 被称为关系模式（及其实例）的超级键（当它不可约时，也称为键）具有键依赖约束 KEY(A).

<块引用>

空的 SQL 表总是有一个超级键吗？

每个 SQL 表总是有一个超级键吗？

是的，因为空的 X 关系服从任何键依赖约束 KEY(A) where A ⊆ X。

证明。对于{}中的所有t1、t2，(t1[A< /em>] = t2[A] ⇒ t1[X] = t2[X])，相当于对于所有 t1, t2, (t1, t2 在 {} ⇒ (t1[A] = t2[A] ⇒ t1[X] = t2[X]))，这是一个 vacuous truth 作为前因 <第一个条件的 {} 中的 em>t1、t2 为假。

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

证明。让 R 成为 X 关系。对于R中的所有t1、t2，(t1[X] = < em>t2[X] ⇒ t1[X] = t2[X ]）。

空SQL表是否有超级密钥？每个SQL表都有吗？

3 个答案: