functional-dependencies - 考虑以下关系模式 r(A,B,C,D,E,F) : 上的函数依赖集 F

标签 functional-dependencies database-theory

我试图联系我的导师,但没有运气,我真的很想了解这个过程,但是无论我阅读了多少 Material ,我似乎都无法在我的小脑袋里找到它。有人可以帮我解决以下问题吗?

A-->BCD
BC-->DE
B-->D
D-->A

a. Compute B+.


我相信这是如下。这似乎是正确的吗?
B+ 表示 B 的闭包。
乙 --> 乙
B+ = {BD}
D --> A
B+ = {ABD}
A --> BCD
B+ = {ABCD}
BC --> 德
B+ = {ABCDE}
B 可以找到关系的所有属性。因此,B 是关系的主键。

b. Prove (using Armstrong’s axioms) that AF is a superkey.


我不明白用 F 做什么,因为它没有出现在上面的关系中。

c. Compute a canonical cover for the above set of functional dependencies F; give each step of your derivation with an explanation.

d. Give a 3NF decomposition of r based on the canonical cover.

最佳答案

All the attributes of the relation can be found by B. So, B is the primary key of the relation.



不。如果 B 可以确定关系的所有属性,则 B 将是候选键。可能存在多个候选键,并且没有正式的理由将一个候选键标识为“主要”而将其他候选键标识为“次要”。

但是 B 并不能确定关系的所有属性。它不决定 F。

I do not understand what to do with F, because it does not show up in the above relationships.



非正式地说,如果某个属性没有出现在任何函数依赖项的右侧,则它必须是每个 super 键的一部分。
r = {ABCDEF}

为了证明 AF 是一个超键(或候选键),计算关系 R = {ABCDEF} 的 AF 的闭包。使用上述相同的 FD。

关于functional-dependencies - 考虑以下关系模式 r(A,B,C,D,E,F) : 上的函数依赖集 F,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5051267/

相关文章:

database - 依附理论

sql - 当两个用户使用手动生成的用户 ID 在同一个表中插入记录时如何避免竞争条件

gradle - 添加优雅按钮依赖后出现错误

database - BCNF分解和数据库的无损联接

database - 规范化依赖

database - 计算一组 FD 的闭包的算法

haskell - 什么是 "coverage condition"?

database-design - 没有 FD 的关系的 BCNF