Database 数据库功能依赖分解

表-人员{ID、姓名、年龄、第1行、城市、州、邮编}

FD集

1） ID->每一个其他属性都是PK

2） 我无法确定

 zip -> {Line1, City, State} or.. 

{Line1, City, State} -> zip?  

[both of these are candidate keys I guess]

在这两种情况下，它都成为可传递依赖项，因为

ID->Zip->其他地址（或ID->地址相关->Zip）

它违反了3NF（传递依赖项）

请您解释一下我如何分解给定的关系，以及在另一个包含地址相关的关系中，什么变成了PK。

如果您知道（第1行，城市，州），您可以确定zip。所以

{Line1, City, State} -> zip

而不是相反。因为同一个zip可能包含同一城市和州的多个Line1值（例如，同一条街上的不同门牌号）

对于3NF，关系可以是

• 个人{ID、姓名、年龄、第1行、城市、州}
• 地址{Line1，城市，州，邮编}

---

从实用性来看，数据库表中似乎存在冗余和空间浪费。

假设{Line1，City，State}->{Zip}和{Zip}->{City，State}，则以下分解为3NF：

Person {ID, Name, Age, Line1, Zip} (key= {ID})
Address {City, State, Zip} (keys = {City, State} and {Zip])

---

实际上，这可能没有用，因为实际地址数据经常不一致或缺少部分。真正的问题是，您实际上希望在数据库中实施哪些依赖项。这就是为什么依赖于仅从属性名称列表中识别依赖项的练习是如此主观的原因。给出明确答案的唯一方法是从您希望模式满足的一组依赖项开始。

完全同意。谢谢你的帮助。看到你的答案后，我想到了两件事：（1）为什么我们不喜欢=>Person{ID，Name，Age}；地址{Line1，City，State，Zip，ID}[我认为PK应该是所有属性的组合。]（2）Zip->{City，State}。。所以，我们的分解仍然违反了3NF。。我很严格，因为这是针对课程作业的。对于课程作业，通常会给出函数依赖关系。但是，如果您正在寻找现实世界中的依赖关系，则邮政编码不能确定城市或州。（有些城市跨越州际甚至国家边界。）邮政编码更多地与邮递员的投递路线有关，而不是与地理位置有关。谢谢你的建议。在课程作业中，“国家”被排除（或遗漏）。这让我有机会直接假设所有地址都属于一个国家，这使得zip->{city，state}为真；）无论如何，在现实世界中，至少在“地址”表的情况下，不鼓励进行适当的3NF分解，这会导致属于多个关系的属性的奇怪组合。zip->{city，state}在美国是不正确的。有许多城市跨越州边界。邮政编码与邮递员的投递路线有关，而与地理位置无关。