Question

昨天我参加了数据库考试，关于规范化的问题很奇怪。我们具有表R（ABCDEFG）和功能依赖性G-> B，C-> DG，CF-> E，F-A。哪个是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
订单号
客户ID
数量
客户名称
产品名称
日期

我总结了

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

这是对的吗？ FD GDF-> C用简单的英语表示什么？

Answer 1

“昨天我参加了数据库考试和关于规范化的问题很奇怪我们有表R（ABCDEFG）和功能依赖性G-> B， C-> DG，CF-> E，F-A。哪个是R的候选键？我才发现一：CF。

这似乎没问题。

那么R1（DFG），它们是R1的候选键？我只找到一个： DFG。

使用相同的FD组合???没有FD根本没有？无论如何，这个似乎也是正确的。

陈述正确的3NF归一化R.我说（（C，F），E），（（G， B）），（（F），A），（（C），D）

<（>（（G），B）代替（（G，B））会更像它。

<（>（（C），DG）代替（（C），D）也会更像。

然后添加功能依赖性GDF-> C.什么是现在正确的3NF标准化R？我说（（G，D，F，C）），（（G），B），（（F，）; A），（（C），D），（（C，F），E）

添加此FD（/约束）不会改变3NF形式。在3NF设计中可以表达的所有依赖关系仍然“完全没有关键”。这种额外的依赖性无法通过分解保留的事实不会降低正常形式。这是一个依赖保留问题，而不是正常的表单问题。

我解决了吗？

最好的选择是问老师。

“然后更奇怪的是，我们应该说出什么是什么时候的列出如下：“

愚蠢。问题本身迫使你做出假设。日期。那是几号？下订单的客户的出生日期？订购产品的当前名称的日期？或者也许是下订单时的日期？可能是这样，但事实是，这应该在规范中清楚地说明，数据库设计师应该真正被教导，永远不要假设任何关于规范的东西。假设是所有搞砸的母亲。

FD GDF-> C用简单的英语表示什么？

用简单的英语，并假设您的答案，这意味着一旦订单中使用了{客户ID，产品ID和数量}的特定组合，就不再出现第二个订单（具有不同的订单ID））具有相同的{客户ID，产品ID和数量}。或者，iow：每个客户只能订购一定特定数量的特定产品一次。

我的答案是否正确？

1 个答案: