一个关系是否可以在3NF中包含多个外键?

Question

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

• TALENTPAYMENT (PAYMENTNUMBER，日期，小计，税，总数，人才，代理号码)

还是需要分解成:

• TALENTPAYMENT (PAYMENTNUMBER, date, subtotal, tax, total)

• 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 -> agentnumber"或相反不是依赖项，模式是3NF的，但是您的(subtotal, tax, total)表基本上是无用的，因为存储这三个表是明显的冗余。最好直接使用:

PAYMENTNUMBER | date | subtotal | tax | talentid | agentnumber

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

Answer 3

反正也不是3NF，因为total = subtotal + tax(或者反过来;我不太会区分合计和小计。

要在3NF中，您必须没有具有非素数属性的传递函数依赖。消除派生属性(总计或小计)，我相信您的解决方案是A OK。

对于这个问题，原来的可能是好的，但对于我提到的问题。

Answer 4

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

另一方面，人才/代理关系往往是脆弱的，所以发现相同的人才在不同的时间由不同的代理代表并不奇怪。在这种情况下，你可能需要保留"支付时的人才代理"的记录，并且你的原始方案比三部分方案更好(因为三部分方案的数据更改会更改历史记录)。