我的数据库设计目前处于 3NF 阶段。值得关注的问题是外键，在某些情况下是复合键。
我的问题是这样的:
如果与复合键/外键关联的属性不依赖于主键，您能否移动复合键和/或外键来创建其他表？
由于此链接，我认为答案是肯定的:
这让我想知道我当前正在处理的标准化阶段是否实际上是在 3NF 中。
由于我是新手并且没有足够的积分，因此我无法发布有关此问题的表格。
最佳答案
我不确定我是否理解你的问题。如果您问:“您能否在不违反 3NF 的情况下在表中使用外键？”答案是绝对肯定的。规范化的任何阶段都没有说你应该消除外键。事实上，几乎不可能在不使用外键的情况下规范化除最琐碎的数据之外的所有数据。
** 更新 **
好的，也许现在我明白你的问题了，但我想你已经为自己回答了。是的，在完全规范化的数据库中，您不应该有非键依赖项。如果您有不依赖于 PK 的 FK，则应将它们移至另一个表。
举一个简单的例子，假设您想跟踪人们、他们居住的城市以及该城市所在的国家。因此，对于您的初稿，您制作了以下结构:(星号标记 PK。)
Person (person_id*, person_name, city_id, country_id)
City (city_id*, city_name)
Country (country_id*, country_name)
这不是标准化的。无论我们谈论的是哪个城市的居民，一个城市都在同一个国家。当我们谈论皮埃尔时，巴黎不是在法国，而是在我们谈论弗朗索瓦时在德国。 (如果有两个同名的城市，当然它们是不同的城市，应该有不同的记录。我想一个城市可以跨越国界，但为了我们的目的，我们假设如果是这样，我们认为它是两个城市碰巧碰上。他们肯定会有不同的市政府、不同的邮政系统等。)所以我们有一个非关键依赖。 country_id 取决于 city_id，而不是 person_id。
所以为了规范这个模式，我们应该将 country_id 移动到一个表中，它只依赖于 PK。据推测，城市表:
Person (person_id*, person_name, city_id)
City (city_id*, city_name, country_id)
Country (country_id*, country_name)
关于foreign-keys - 规范化为 3NF(第三范式)时，您能否将复合键和/或外键移动到其他表，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/12322080/