Question

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

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

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

实施例：我们假设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确定了产品的卖家。在每种情况下，卖方必须在发件人和＃34;列或收件人＆＃34;柱。关键是[Sender]或/和[Recipient]无法确定idObject，正如我们在上面的例子中看到的那样。因此，我们有3NF，因为所有非键列仅在功能上依赖，并且仅在主键上。

Answer 1

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

不确定我是否完全理解idObject属性，但如果[idMessage]通过[Recipient]或[Sender]确定[idObject]，那么我们就会有一个传递函数依赖，因此不会是3NF。如果[idObject]由[idMessage]属性确定，那么所有非关键属性都完全依赖于主键[idMessage]，而将一个3NF。

您可能想要对什么是idObject添加一些解释？希望这会有所帮助。

Answer 2

您滥用术语＆＃34;确定＆＃34;。

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

除了idMessage所暗示的PK之外，您的描述和常识并未表明任何功能依赖性。所以这是在3NF和BCNF。

事实上，如果我给你一个idObject值，你就不能告诉我这个表看起来像什么，而不是它的标题和idMessage PK告诉你。所以它在5NF。（和DKNF。）

（我甚至无法找出＆＃34的定义;确定＆＃34;这可以理解你写的内容。也许你认为某个对象的所有者参与其中在＆＃34;确定＆＃34;。如果您要求邮件的发件人或收件人是其对象的所有者，那么每当出现idObject值时，每个人都必须出现一个值（发件人，收件人）作为发件人或收件人进行子订单。但该约束不是函数依赖，并且它并不意味着存在函数依赖。因此关系仍然在3NF中。）

第三种（？）关系的正常形式

2 个答案: