0

假设我有一个网站，任何人都可以在其中买卖商品，并且 2 个注册用户可以互相发送有关产品的消息。我的数据库中的关系之一是：

Message
--------
idMessage (PK)
Sender
Recipient
idObject
Subject

当然，发件人或收件人之一应该是产品的卖方或买方。我的问题是这种关系是否处于第三范式。当然它是第二范式，因为每个非键列在功能上都完全依赖于主键。

示例：假设userB是产品的卖家（所有者）#1234并且userA是产品的卖家（所有者）#1000。我们有下表：

idMessage| Sender| Recipient | idObject| Subject
________________________________________________
    1    | userA |   userB   | #1234   | size  
    2    | userB |   userC   | #1234   | discount
    3    | userA |   userB   | #1000   | size

显然，idObject在上表中确定了产品的卖家。在每种情况下，卖方都必须在“发件人”列或“收件人”列中。关键是 [Sender] 或/和 [Recipient] 无法确定 idObject，如我们在上面的示例中所见。因此，我们有 3NF，因为所有非键列在功能上仅依赖于主键。

4

2 回答 2

1

您误用了“确定”一词。

当第一个的子行值仅与另一个的子行值最多出现时，一个属性集确定另一个。由于 idObject 可以与多个 Sender 值和多个 Recipient 值一起出现，因此它在功能上不能确定它们中的任何一个。

您的描述和常识并未暗示任何功能依赖关系，除了 idMessage 是 PK 所暗示的那些。所以这是在 3NF 和 BCNF 中。

事实上，如果我给你一个 idObject 值，除了它的标题和 idMessage 是 PK 告诉你的内容之外，你根本无法告诉我这个表的外观。所以它在 5NF 中。（还有 DKNF。）

（我什至无法弄清楚你所写内容的“确定”定义。也许你认为对象的所有者参与了“确定”。如果你要求消息的发件人或收件人其对象的所有者然后每当出现 idObject 值时，必须有一个值出现在每个（发件人，收件人）子行中作为发件人或收件人。但该约束不是功能依赖，并不意味着存在一个函数依赖。所以关系仍然在 3NF 中。）

于 2016-10-24T23:02:01.980 回答
1

那么，问题应该是，是否存在传递函数依赖？如果答案是肯定的，那么这不是 3NF。

不确定我是否完全理解该idObject属性，但如果 [idMessage] 通过 [Recipient] 或 [Sender] 确定 [idObject]，那么我们有传递函数依赖，因此这不会是 3NF。如果 [idObject] 由 [idMessage] 属性确定，则所有非键属性的功能完全取决于主键 [idMessage]，这将是3NF。

您可能想添加一些关于 What is 的解释idObject？希望这可以帮助。

于 2016-10-24T21:28:22.530 回答