标签: functional-dependencies

函数依赖中的增强规则指出

当 X -> Y 时，

然后XZ-> YZ。

有人可以举一个真实世界的例子吗？

我对确定功能依赖项感到非常困惑，并且需要确认我拥有所有依赖项列表。我有一张桌子。

从下表中我发现：

我的问题是，我是否在这里正确列出了所有可能的功能依赖项？另外（如果我是对的），我看到model --> make，我还需要等等吗model, color --> make？而且make, msrp --> model, year，我还需要model, year --> make, msrp在列表中吗？

我看了将一个关系分解为BCNF答案，并在作业中进行了尝试，但是我没有得到正确的答案，所以我寻求BCNF分解的帮助

考虑R=(ABCDEG)＆F={BG->CD, G->A, CD->AE, C->AG, A->D}。
我开始选择A->D。
现在S=(AD), R'=(ABCEG).
我选了G->A。
现在我明白了S=(AD,AG) R'=(BCEG)。
我选C->G。现在我想我需要得到S=(AD,AG,CG)和R'=(BCE)，但最终答案(AD,AG,CGE,BC)。什么出了问题？还是更好的算法？

R = ( A, B, C, D )- 关系模式 R 中没有有效的函数依赖关系

对于上述关系，最高范式是什么？我有一个问题，如果它不在 BCNF 中，我应该识别最高范式并将其分解为 BCNF 。

我想创建一个类/结构，其中一个属性在功能上依赖于其他属性。如何做到这一点？

struct Numbers {
  int a;
  int b;
  int c; // c == a+b
}


Numbers n1 {1, 2, 3}; // Ok.
Numbers n2 {1, 2, 4}; // Error! 

在我的用例a, b, c中，如果这很重要（因此const int可以使用），则是恒定的。

所有属性都会在 class/struct 方法中多次出现，因此目标是缓存 value a+b。以加法为例，依赖函数可能更复杂。

题

主键是否在功能上决定了表中的所有其他属性？

我的想法

当然必须不是吗？这不是主键的重点吗？