我将下面的单个表分解为3个表，以便根据以下依赖关系和组合键（FirstName，LastName，Career）将其转换为3NF：
第一范式：
FirstName, LastName, Address, Career, Pay, Managerial
依赖关系：
FirstName, LastName -> Address
Career -> Pay, Managerial
第三范式：
People (FirstName, LastName, Career)
Addresses (FirstName, LastName, Address)
Careers (Career, Pay, Managerial)
出于本示例的目的，我们可以假设（FirstName，LastName）是唯一的以及（职业），以避免在Addresses和Careers表中为这些创建ID。
我认为这个架构中没有外键吗？地址和职业中的键仅部分构成了People中的键。或者人们实际上有2个外键：FK（FirstName，LastName）和FK（职业）和1个主键：PK（FirstName，LastName，Career）？
通过分解归一化到更高的NF会将一个表替换为自然联接回来的其他表，这些表是它的投影。因此，对于任何共享列，两个组件具有相同的子行值集，因为它们都是原始列的投影。因此，当/ iff后一列集合在后一个表中形成CK（候选键）时，从列集和表到另一个列集和表有一个FK（外键）。
在这里，如果您的原始FD形成封面：您有人CK {{FirstName，LastName，Career}}，地址CK {{FirstName，LastName}}＆Careers CKs {{Career}}。所以FKs是人民FKs {FirstName，LastName}到地址和{Career}到职业。
PS经常在规范化时我们意识到我们不想要原始表的投影，而是我们希望表格像某些组件一样但是包含更多行。 （有时这被误解为规范化的一部分。）（我们检测并重新设计删除和插入异常，尽管规范化只解决更新异常。）然后我们选择的这些不同的表通常不具有相同的CK或子行值集规范化组件。
PS归一化到更高的NF不会引入新的列。这包括id列。
PS关系“FK”通常涉及列集。但它可能意味着列表引用另一个列表。或列列表，其中每个名称在引用另一个名称时出现。但SQL“FK”并不意味着任何关于FK的关系概念 - 它或多或少意味着外国超级钥匙。类似地，SQL“PK”或多或少意味着主要超级密钥。 See this answer.
你错了。我不同意你的架构，但Person.Career是Careers.Career的外键引用。
同样，在模式中的某个地方可能应该有一个地址id和一个person id。
实际上你有多对多的关系。因此，许多人可以采用一个地址。一个人可以有很多地址。在这种情况下，您将在人员表中重复，并在地址表中重复。外键会有所不同，但其他部分会重复。有桌子是很常见的：
人物地址（person_id，address_id，occulied_from，occupied_till）
PersonCareers（person_id，career_id，employee_from，employee_till）
另一部分是没有像你提到的那样提供复杂密钥的RDBMS，正如关系db理论中所描述的那样