如果带有代理键的表的列已知具有唯一的非空值（例如SSN），是否违反3NF？

据我了解，第三范式（3NF）基本上意味着应该只有一个密钥。

如果带有自动递增id列的表还具有一个已知唯一且不为空的列（例如，社会保险号），则该另一列可用作键。

从严格的架构设计方面，忽略实际/业务问题（例如，将SSN作为密钥/ FK传递时的安全性/隐私风险），由于有效地有2个密钥，这样的表是否不会出现在3NF中？

答案是否会在另一列上是否有唯一键上有所不同？如果是这样，为什么？

如果R的每个非素数属性非传递性地依赖于R的每个候选键，则关系R为第三范式

EFCodd，1971年，数据库关系模型的进一步规范化

在关系的定义中隐含了一个关系必须至少具有一个键。3NF或任何其他范式都不需要关系只有一个键。

不幸的是，有关数据库设计和规范化的书籍仅提供了一个键的大量关系示例，而具有多个键的示例却很少。鉴于这些天来多个按键似乎很普遍，这让我感到奇怪。非学术文献中缺乏实际示例，这似乎是导致键在数据库设计中作用混乱的原因之一。造成混淆的另一个原因是流行的助记符“仅键就好”。该短语通常归因于Bill Kent，但它不是3NF的准确定义。

由于问题是基于对规则的解释，因此我们应该首先查看该链接信息，即（强调我的）：

2. 一个表中的所有属性仅由该表的候选键确定，而不由任何非素数属性确定。

我认为混淆是对“候选密钥”一词的误解的结果。一个表中可以有多个候选键。这就是为什么我们要在该组中进一步指定修饰语的原因：主要和替代。如果表可以有一个键，而只有一个键，则术语“主键”将具有误导性，应改为其他名称（例如“父项”或“来源”或“标识”，等等）。但是“ Primary”意味着可以有“ secondary”键，这些键称为“ Alternate”键。

备用键在物理模型中通过唯一约束或唯一索引指示。还应当指出的是，这两种类型的候选键（主要和备用），可以通过外键引用（即使一个一般不会/不应该做这样的事情没有一个非常好的理由！）。

答案是否会在另一列上是否有唯一键上有所不同？如果是这样，为什么？

不，因为这是物理建模还是逻辑建模的问题。您可以有一个具有IDENTITY字段但尚未定义主键的表。即使物理模型不强制执行该表及其数据，也可以轻松地将其存储在3NF中。这种区别类似于是否定义外键。您可以肯定地联接表，并且没有孤立的记录，无论是否已定义任何PK / FK。如果没有这些构造，数据可以100％正确。但是，定义PK和FK就是引用完整性（逻辑）和声明性引用完整性（物理）之间的差异。在物理模型中具有约束条件仅有助于实施逻辑模型的规则。

关于SSN（对于那些不熟悉该首字母缩写的人，称为“ 社会保险号 ”），它是备用密钥，并且具有唯一索引/约束：

我建议不要考虑将SSN作为备用密钥，并在其上施加唯一约束或索引，即使这样做很常见（SSN通常被认为是“自然”密钥-现实世界中已经存在） 。主要有两个原因：

1. 准确性：在大多数情况下，这些值都是由人填写的表格（无论是纸上的还是在线的）输入到系统中的。人们在进行数据输入时总是会犯错误，特别是如果源是纸质表格，而该纸张表格是由阅读他人草率笔迹的人（例如我的，很难辨认）输入的。

   即使数据来自另一个系统，也可以确定源系统已验证信息吗？您可以确定其数据导出中没有错误吗？如果数据导入中有错误怎么办？

2. 唯一性：即使主要的社会保障管理部门从未发布过重复的ID，也并不意味着没有发生重复。除了身份盗用问题之外，我还记得几年前有人曾在美国税务局担任DBA（我相信）并且必须处理社会保障福利，以及他们如何处理“医疗保险”问题。将死者的SSN重新分配给尚存的配偶（通常是寡妇）的较旧做法，以便尚存的配偶更容易继续收取福利金。我敢肯定这种做法已经结束了一段时间，但是“重复”数据仍在系统中。

据我了解，第三范式（3NF）基本上意味着应该只有一个密钥。

2NF，3NF和Boyce Codd范式（BCNF）涉及功能依赖性。2NF中的表表示不存在部分键依赖关系，其中非键列依赖于多列键的某些适当子集。诸如我们示例中的表之类的表已经在2NF中，因为每个候选键都是一列。在3NF甲表装置每一个非键列也并不功能依赖于某些其他非键列，并因此产生一个传递依赖。有一个或一百个候选密钥都没有关系。实际上是BCNF，而不是3NF，这是关于功能依赖性的“最终”正常形式。这是因为表可以位于3NF中，但不能位于BCNF中，因为可能存在多个重叠的候选键。因此，当我们使用术语3NF来表示关于功能依赖性的“完全规范化”时，我们真正的意思是BCNF。

如果带有自动递增id列的表还具有一个已知唯一且不为null的列（例如，社会保险号），则可以将该另一列用作键。

它不仅可能是，它必须是，如果我们要确保存储在数据库中的数据保持与我们在现实世界中已经确定的规则相一致！

从严格的架构设计方面，忽略实际/业务问题（例如，将SSN作为密钥/ FK传递时的安全性/隐私风险），由于有效地有2个密钥，这样的表是否不会出现在3NF中？

如上所述，该表是否位于3NF（或更重要的是BCNF）中与该表包含多少个候选键正交。

答案是否会在另一列上是否有唯一键上有所不同？如果是这样，为什么？

不，只是因为确定表是否在3NF中与它具有多少个候选键无关。相反，它与确保所有非键列在功能上完全依赖于那些候选键有关。

但这确实提出了一个有趣的观点。需要注意的是，当定义为在DBMS约束的唯一关键是不一样的独特的标识符定义为一个概念的商业模式业务规则。也许在我们的世界中，我们总是知道该人的SSN，因此它可以作为一个人的候选键，并且也许在我们称为Person Id的逻辑模式中也引入了替代键。我们的业务模型包括规则，该规则说明SSN是我们这个人的唯一标识符。这意味着功能上的依赖此标识属性上的所有描述性属性。该规则不会因为我们忘记或选择不通知DBMS而改变。这正是声明约束至关重要的原因，以便DBMS可以确保存储的数据与业务模型的规则一致！如果我们没有在SSN上创建唯一约束，那么我们现在可能会无意中为具有相同SSN的同一个人创建多行；每行都有不同的人ID！

关于这些主题的出色入门文章是Fabian Pascal的实用数据库基础丛书和Chris Date的数据库设计与关系理论，从中得出了这个答案。尽管Fabian的每篇论文都是必读的，但论文＃1（明确定义了概念，逻辑和物理级别之间的区别）和论文＃4（明确定义了各种键）明确地解决了这个问题。同样，克里斯的整本书是必读的内容，而第二部分是专门针对功能依赖性进行规范化的部分。