一个关系可以在3NF中使用多个外键吗？

Question

我认为这是非常基本的，但我是新手。我正在尝试规范化表格。一个关系可以是多个外键的3NF吗？这是3NF：

• TALENTPAYMENT（付款人，日期，小计，税，​​总计，talentid，代理人数）

还是需要将其细分为：

• TALENTPAYMENT（付款金额，日期，小计，税金，总额）

• TALENTPAYMENTID（PAYMENTNUMBER，talentid）

• TALENTAGENT（TALENTID，agentnumber）

Answer 1

我认为大多数其他答案都更倾向于你的例子，而不是你的问题。

直接说出这个问题，是的，即使它有多个外键，关系也可以是3NF。 3NF的关键（咳嗽）点是删除传递依赖，而不是减少外键的数量。

换句话说，没有“我有太多外键”的正常形式。

Answer 2

这不是3NF，但不是因为你的外键。你有一些功能依赖，左侧不是候选键：

subtotal,tax   -> total
subtotal,total -> tax
tax,total -> subtotal

减少到3NF的算法会将您的架构拆分为：

PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber

和

subtotal | tax | total

此时，假设“talentid - ＆gt; agentnumber”或反过来不是依赖关系，架构是3NF，但是你的（小计，税，​​总）表基本没用，因为存储所有三个表明显冗余。最好只使用：

PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber

根本不存储总数。如果您想在查询中使用SELECT (subtotal+tax) as total，则假设小计和税都是数字类型。

Answer 3

无论如何，它不在3NF，因为总数=小计+税（或者反过来;我对总数和小计之间的差异不好）。

要在3NF中，您必须不具有非素数属性的传递函数依赖性。消除派生属性（总计或小计），我相信你的解决方案是好的。

就此而言，原件可能没问题，但对于我提到的问题。

Answer 4

你的三部分模式表明可能存在功能依赖 talentid ⟶ agentnumber ，在这种情况下你的关系不能在BCNF（3NF）中，因为 talendtid 不是关系的关键之一。

另一方面，人才/代理人关系往往很脆弱，因此在不同时间发现不同代理人代表同一人才并不奇怪。在这种情况下，您可能需要在记录时保留“付款时的人才代理”，并且您的原始模式优于三部分模式（因为三部分方案的数据更改发生变化历史记录）。