第三（？）关系的正常形式
Third (?) normal form of a relation
假设我有一个网站，任何人都可以在其中买卖商品，并且 2 个注册用户可以就产品相互发送消息。我的数据库中的关系之一是：
Message
--------
idMessage (PK)
Sender
Recipient
idObject
Subject
当然，发件人或收件人之一应该是产品的卖家或买家。我的问题是这种关系是否符合第三范式。当然是第二范式，因为每个非键列在功能上完全依赖于主键。
示例：
假设 userB 是产品 #1234 的卖家（所有者），userA 是产品 #1000 的卖家（所有者）。我们有以下 table:
idMessage| Sender| Recipient | idObject| Subject
________________________________________________
1 | userA | userB | #1234 | size
2 | userB | userC | #1234 | discount
3 | userA | userB | #1000 | size
显然，上面table中的idObject决定了商品的卖家。在每种情况下，卖家都必须在 "Sender" 列或 "Recipient" 列中。关键是 [Sender] or/and [Recipient] 无法确定 idObject，正如我们在上面的示例中看到的那样。因此，我们有 3NF，因为所有非键列在功能上仅依赖于主键。
那么，问题应该是，是否存在传递函数依赖？如果答案是肯定的，那么这不是 3NF。
不确定我是否完全理解 idObject 属性，但是如果 [idMessage] 通过 [Recipient] 或 [Sender] 确定 [idObject] 那么我们有一个传递函数依赖因此这个 不会 是 3NF。如果 [idObject] 由 [idMessage] 属性确定，则所有非键属性的功能完全依赖于主键 [idMessage]，并且此 将是 3NF。
您可能想对什么是 idObject 添加一些解释？
希望这有帮助。
您误用了术语 "determines"。
当第一个的子行值只出现在另一个的至多一个子行值时，一个属性集决定另一个。由于 idObject 可以与 Sender 的多个值和 Recipient 的多个值一起出现，因此它不会在功能上确定它们中的任何一个。
您的描述和常识并未表明除了 idMessage 隐含的功能依赖性是 PK 之外，还存在任何功能依赖性。所以这是在 3NF 和 BCNF 中。
事实上，如果我给你一个 idObject 值，除了它的标题和 idMessage 之外，你无法告诉我任何关于这个 table 看起来像什么的东西被PK告诉你。所以它在 5NF 中。 （还有 DKNF。）
（我什至无法弄清楚 "determines" 的定义使您写的内容有意义。也许您考虑 owner object 参与 "determining"。如果您要求消息的发件人或收件人是其 object 的所有者，那么无论何时出现 idObject 值，都必须有一个值出现在每个（发件人，收件人）子行作为发件人或收件人。但该约束不是功能依赖性，并不意味着存在功能依赖性。因此该关系仍处于 3NF。）
假设我有一个网站，任何人都可以在其中买卖商品，并且 2 个注册用户可以就产品相互发送消息。我的数据库中的关系之一是：
Message
--------
idMessage (PK)
Sender
Recipient
idObject
Subject
当然，发件人或收件人之一应该是产品的卖家或买家。我的问题是这种关系是否符合第三范式。当然是第二范式，因为每个非键列在功能上完全依赖于主键。
示例：
假设 userB 是产品 #1234 的卖家（所有者），userA 是产品 #1000 的卖家（所有者）。我们有以下 table:
idMessage| Sender| Recipient | idObject| Subject
________________________________________________
1 | userA | userB | #1234 | size
2 | userB | userC | #1234 | discount
3 | userA | userB | #1000 | size
显然，上面table中的idObject决定了商品的卖家。在每种情况下，卖家都必须在 "Sender" 列或 "Recipient" 列中。关键是 [Sender] or/and [Recipient] 无法确定 idObject，正如我们在上面的示例中看到的那样。因此，我们有 3NF，因为所有非键列在功能上仅依赖于主键。
那么，问题应该是，是否存在传递函数依赖？如果答案是肯定的，那么这不是 3NF。
不确定我是否完全理解 idObject 属性，但是如果 [idMessage] 通过 [Recipient] 或 [Sender] 确定 [idObject] 那么我们有一个传递函数依赖因此这个 不会 是 3NF。如果 [idObject] 由 [idMessage] 属性确定，则所有非键属性的功能完全依赖于主键 [idMessage]，并且此 将是 3NF。
您可能想对什么是 idObject 添加一些解释？
希望这有帮助。
您误用了术语 "determines"。
当第一个的子行值只出现在另一个的至多一个子行值时，一个属性集决定另一个。由于 idObject 可以与 Sender 的多个值和 Recipient 的多个值一起出现，因此它不会在功能上确定它们中的任何一个。
您的描述和常识并未表明除了 idMessage 隐含的功能依赖性是 PK 之外，还存在任何功能依赖性。所以这是在 3NF 和 BCNF 中。
事实上，如果我给你一个 idObject 值，除了它的标题和 idMessage 之外，你无法告诉我任何关于这个 table 看起来像什么的东西被PK告诉你。所以它在 5NF 中。 （还有 DKNF。）
（我什至无法弄清楚 "determines" 的定义使您写的内容有意义。也许您考虑 owner object 参与 "determining"。如果您要求消息的发件人或收件人是其 object 的所有者，那么无论何时出现 idObject 值，都必须有一个值出现在每个（发件人，收件人）子行作为发件人或收件人。但该约束不是功能依赖性，并不意味着存在功能依赖性。因此该关系仍处于 3NF。）