关系可以是具有多个外键的 3NF 关系吗？
我认为这是非常基本的，但我对此很陌生。我正在尝试标准化表格。关系可以是具有多个外键的 3NF 关系吗？这是 3NF：
- TALENTPAYMENT（PAYMENTNUMBER、日期、小计、税收、总计、talentid、agentnumber）
还是需要进一步细分为：
TALENTPAYMENT（PAYMENTNUMBER、日期、小计、税收、总计）
TALENTPAYMENTID（PAYMENTNUMBER、 Talentid）
TALENTAGENT（TALENTID，代理编号）
I think this is pretty basic, but I am new to this. I am trying to normalize a table. Can a relation be 3NF with multiple foreign keys? Is this 3NF:
- TALENTPAYMENT (PAYMENTNUMBER, date, subtotal, tax, total, talentid, agentnumber)
or would it need to be broken down more to:
TALENTPAYMENT (PAYMENTNUMBER, date, subtotal, tax, total)
TALENTPAYMENTID (PAYMENTNUMBER, talentid)
TALENTAGENT (TALENTID, agentnumber)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为大多数其他答案更倾向于你的例子而不是你的问题。
直接回答这个问题，是的，一个关系可以是 3NF，即使它有多个外键。 3NF 的关键（咳嗽）点是消除传递依赖，而不是减少外键的数量。
换句话说，不存在“我有太多外键”的正常形式。
I think most of the other answers are more oriented toward your example than toward your question.
To speak directly to the question, yes, a relation can be in 3NF even if it has multiple foreign keys. The key (cough) point of 3NF is to remove transitive dependencies, not to reduce the number of foreign keys.
To put it another way, there's no such thing as "I have too many foreign keys" normal form.
这不是 3NF，但不是因为你的外键。您有一些函数依赖项，其中左侧不是候选键：
减少到 3NF 的算法会将您的模式拆分为：
PAYMENTNUMBER | PAYMENTNUMBER |日期 |小计 |税 |人才标识 |代理编号和
小计 |税 |此时，假设“talentid -> agentnumber”或相反的不是依赖项，架构处于 3NF 中，但您的（小计、税、总计）表基本上没有用，因为存储所有三个明显的冗余。最好使用：
PAYMENTNUMBER |日期 |小计 |税 |人才号 | agentnumber并且根本不存储总计。如果您希望在查询中使用它，则只需
SELECT（小计+税）作为总计，假设小计和税都是数字类型。It's not 3NF, but not because of your foreign keys. You have some functional dependencies of which the left side is not a candidate key:
The algorithm for reducing to 3NF would say to split your schema into:
PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumberand
subtotal | tax | totalAt which point, assuming "talentid -> agentnumber" or the reverse are not dependencies, the schema is in 3NF, but your (subtotal, tax, total) table is basically useless since storing all three an obvious redunancy. It would be better just to use:
PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumberAnd not store total at all. If you want it in a query you can just
SELECT (subtotal+tax) as totalassuming subtotal and tax are both numeric types.无论如何，它不在 3NF 中，因为总计 = 小计 + 税（或相反；我不擅长总计和小计之间的差异）。
要处于 3NF 中，您不得具有与非素数属性的传递函数依赖关系。消除派生属性（总计或小计），我相信您的解决方案是可以的。
就此而言，原件可能没问题，但对于我提到的问题。
It's not in 3NF anyway since total = subtotal + tax (or the other way around; I'm bad at the difference between total and subtotal).
To be in 3NF, you must not have transitive functional dependencies with non-prime attributes. Eliminate the derived attribute (total or subtotal) and I believe your solution is A OK.
For that matter, the original might be OK, but for the problem I mention.
您的三部分架构表明可能存在功能依赖性 talentid ⟶ agentnumber，在这种情况下，您的关系不能采用 BCNF (3NF)，因为 talendtid > 不是关系的键之一。
另一方面，人才/经纪人关系往往很脆弱，因此发现同一人才在不同时间由不同经纪人代表也就不足为奇了。在这种情况下，您可能需要保留“付款时的人才代理人”记录，并且您的原始架构比三部分方案更好（因为三部分方案的数据更改会发生变化）历史记载）。
Your three part schema suggests that there might be a functional dependency talentid ⟶ agentnumber, in which case your relation cannot be in BCNF (3NF) because talendtid is not one of the keys for the relation.
On the other hand, talent/agent relationships tend to be fragile, so it would not be surprising to find that the same talent is represented by different agents at different times. In that case, you probably need to keep the 'agent of the talent at the time of the payment' on record, and your original schema is better than the three-part one (because changes in the data of the three-part scheme changes historical records).