-1

昨天我参加了数据库考试，关于标准化的问题很奇怪。我们有表 R(ABCDEFG) 和函数依赖 G->B、C->DG、CF->E、FA。哪些是 R 的候选键？我只找到了一个：CF。那么 R1(DFG)，哪些是 R1 的候选键？我只找到了一个：DFG。为 R 陈述一个正确的 3NF 归一化。我陈述了 ((C,F), E), ((G, B)), ((F), A), ((C), D)

然后添加了功能依赖 GDF->C。现在 R 的正确 3NF 归一化是什么？我说 ((G, D, F, C)), ((G), B), ((F, ); A), ((C), D), ((C, F), E)

我解决了吗？

那么更奇怪的是，当列出以下内容时，我们应该说明什么是什么：

  • 产品编号
  • 订单号
  • 客户ID
  • 数量
  • 顾客姓名
  • 产品名称
  • 日期

我得出结论

G= Product ID
C= Order number
F= Customer ID
D= Quantity
A= Customer name
B= Product name
E= Date

它是否正确？FD GDF->C 在简单的英语中是什么意思？

4

1 回答 1

2

“昨天我参加了一个数据库考试，关于规范化的问题很奇怪。我们有表 R(ABCDEFG) 和函数依赖关系 G->B、C->DG、CF->E、FA。哪些是 R 的候选键？我只找到了一个：CF。

这似乎没问题。

那么 R1(DFG)，哪些是 R1 的候选键？我只找到了一个：DFG。

用同一套FD的？？？根本没有FD？？？无论如何，这似乎也是正确的。

为 R 陈述一个正确的 3NF 归一化。我陈述了 ((C,F), E), ((G, B)), ((F), A), ((C), D)

((G), B) 而不是 ((G, B)) 会更像它。

((C), DG) 而不是 ((C), D) 也会更像它。

然后添加了功能依赖 GDF->C。现在 R 的正确 3NF 归一化是什么？我说 ((G, D, F, C)), ((G), B), ((F, ); A), ((C), D), ((C, F), E)

添加此 FD (/constraint) 不会改变 3NF 形式。在 3NF 设计中可表达的所有依赖项仍然是“不完整的键”。分解无法保留这种额外的依赖关系这一事实并没有降低范式。这是一个依赖关系保留问题，而不是正常形式的问题。

我解决了吗？

最好的办法是问老师。

“那更奇怪的是，下面列出来的时候，我们应该说明是什么：”

愚蠢的。问题本身迫使你做出假设。日期。那是什么日子？下订单的客户的出生日期？为订购的产品指定当前名称的日期？或者下订单的日期？大概是这样，但问题是，这应该在规范中明确说明，并且应该真正教导数据库设计人员永远不要假设任何关于规范的事情。假设是所有错误的根源。

FD GDF->C 在简单的英语中是什么意思？

用简单的英语，假设你的回答，这意味着一旦在一个订单中使用了{customer id, product id and quantity}的某种组合，就不能再出现第二个订单（具有不同的订单id）非常相同的{客户 ID、产品 ID 和数量}。或者，iow ：每个客户只能订购特定数量的特定产品一次。

于 2012-06-18T07:37:21.470 回答