摘自《数据库设计与关系理论》:
R = (S, J, T)
{S, J} -> {T}
{T} -> {J}
这不符合BCNF,因为T -> J
成立而T
不是关键字。
将其分解为R1 = (T, J)
和R2 = (T, S)
,其中{T}
和{T,S}
分别是主键,符合BCNF。
然而,依赖关系{S,J} -> {T}
丢失了。
employeeId name jobTitle salary
假设 jobTitle -> salary
,也就是说,每个拥有相同工作职称的人都有相同的工资。假设 "developer" 职位等价于 $90,000 的薪水。如果您的数据库中有20个开发人员,将重复存储每行的 $90,000 值是愚蠢的。因此,您可以从雇员表中删除薪水列,并创建一个新的薪水表,其中包含:
jobTitle_[key] salary
接下来,如果要查询员工的薪资,需要在薪资表中查找。
具有FDs { A->B,AC->D,BD->E}的R(a b c d e)。 在此关系中,AC是候选键,而且该关系不符合2NF,因为非主属性B对关键字(AC)部分依赖。 要将此关系转换为BCNF,请将其分解为两个关系:R1(a b ) {a->b} key = a和R2(a c d e) {ac->de} key =a。 R1和R2都符合BCNF,因为每个决定因素都是一个键,但它们不保留依赖项,因为bd->e已经丢失。
Schema R=(V,W,X,Y,Z)
Functional dependencies:
V,W -> X
Y,Z -> X
W -> Y
分解到BCNF,你会发现所有的FD都不能在单个分解中保留。
S
如何成为R2
的键?难道不是因为(T, S)
是只有在 BCNF 中才有效的关系,因为T
和S
之间没有依赖关系吗? - underdisplaynameS
是R2
的一个键,他是在说{T,S}
作为一个整体是一个键。 - naicolas