database - 用户消息关系的功能依赖

Question

更新:关系模型可能无法按我希望的方式工作，请参阅:Database normalization for facebook-like messaging systemNoSQL 时代来临!

我无法将数据库放入 2nf。为此，您必须先确定所有函数依赖性，然后才能确定属性是质数还是非质数。

看这里:

--------------------------------------------
   to   |  from  |   msg          |  time  
--------|--------|----------------|---------
  joe   |  jim   | hello          |   1
  jim   |  joe   | hey            |   2
  jim   |  joe   | how are you    |   3
 victor |  bryce | i love carrots |   4
  joe   |  jim   | im doin great  |   5
  bryce |  jim   | hello          |   6

注意:时间将是唯一的。它将被交易。

是否time->message尽管

time1->"hello"
time6->"hello"

因为我听说只要有独特的消息实例，就可以了。但是，我对此感到困惑。

此外，我想添加一个消息 ID 列。这是好的做法吗？

Answer 1

函数依赖性会问:“如果我知道‘X’的一个值，我是否知道‘Y’的一个且唯一的值？”，其中“X”和“Y”是关系的属性。 (“X”和“Y”指的是属性的集。)

如果属性“time”的值实际上是唯一的，那么知道“time”的一个值就意味着您知道一个且只有一个“msg”的值。这意味着函数依赖 time->msg 对这种关系成立。

相比之下，函数依赖性“to”->“msg”在此关系中不成立，因为知道值“joe”意味着我知道“msg”的两个值:'hello '，和'我做得很好'。它不适用于这种关系，所以我们说“to”->“msg”不是这种关系中的函数依赖。

出于完全相同的原因，“to, from”->“msg”在此关系中不成立。所以“to, from”->“msg”不是这个关系中的函数依赖。

Also, I want to add a message id column. Is that good practice?

添加不在原始关系中的属性与数据压缩有关，与规范化无关。规范化从不引入新的属性或新的依赖关系。添加“msg_id”作为属性会引入两个新的函数依赖性(取决于“msg_id”的含义):“msg_id”->“msg”和“time”->“msg_id”。

因此，添加“msg_id”属性有时可能是个好主意(比您想象的要少)，但它与规范化无关。假设您打算将“msg_id, msg”投影为一个新表并从原始关系中删除“msg”，您也需要将“msg”声明为唯一。