依赖资金依赖职能
- K 是关系模式R 的超码 当且仅当 K ->R
- 只有当 K 是 R 关系模式的候选人时
K -> R, 并且
不存在 a属于 K, a-> R
- 功能依赖集:一系列互相依赖的功能。
- 如果关系 r 不违反取决于设定F的功能,请调用
关系 r 通过设置 F (r completes F) 满足功能 。 - 如果关系模式R中的所有连接都满足该函数对 Set F 的依赖,请调用
以F组为基础,根据关系模式R(对R的门槛)产生一项职能。
属性集关闭
视给定函数而定,依给定函数、依赖设定F、可能推出的所有属性集合、称为a的封闭软件包,记录为+
计算属性集的闭包
属性集闭包的用途:
确定一个属性集是否被多编码
简单看一个+,检查它是否包括R的超编码,以确定一个不是R的超编码。
是否存在一项函数取决于该函数是否已经建立。
要判断 a->b 是不是成立，只要看b属于a+ 是不是成立
最低限度癌症覆盖率/标准覆盖
删除基于重复功能并代之以“最低限度”功能的F集函数,该功能依赖最起码的重叠或称为F的规范。
该职能依赖某些集中职能是不必要的。
例如. {A ->B, B -> C, A ->C} 可以简化为等价的函数依赖集合
{A ->B, B -> C}
职能取决于多余的品质。
例如. {A ->B, B ->C, A ->CD} 可以简化为等价的函数依赖集合
{A ->B, B ->C, A -> D}
例如. {A ->B, B ->C, AC ->D} 可以简化为等价的函数依赖集合
{A -> B, B ->C, A -> D}
模式分解(模式分解)
(无损损)
完成一套部队依赖性
依据基于设定 F 的函数产生的所有函数都依赖于收藏,即一个名为F的封闭式软件包,以F+表示。
F+是F的反义词。
依赖关系起诉(依靠另一人来维持职能运作)
获得关系模式R1,R2,..,Rn 分解模式R。
创建仅包含 R1 属性的 F+ 函数的 F1 子组别 。
创建仅包含 R2 属性的 F+ 函数的 F2 子组合 。
如此类推
作为 Fn 的子组装, 请在 F+ 中写入仅包含 Rn 属性的函数 。
保持功能依赖性。 如果..
F1和F2是平等的,Fn和F也是平等的。
因此,这种分解取决于是否保留该功能(依赖性保全)。
(模式)正常格式
范式是关系的集合
模型1NF(第一普通表)
如果关系模式R的所有特征都是原子,R就是最初的范式。
原子在以下哪些字段中被发现?
可口可乐、薯条、鸡翅、面条、面包、汤等的餐具。
(可乐、薯条、鸡翅)、(面条、面包、汤)
车票 D7727 0220A, D7712 0804A, D7727 0220A, D7727 0220A, D7727 0220A, D7727 0220A, D7727 0220A, D
D7727、D7712
车辆=02,08,
座位是20A,04A和06A
答案
食物,汽车,汽车, 和更多的汽车。
3NF (Third Normal Form)
BCNF (Boyce-Codd Normal Form)
BCNF定义. 如果 F+ 里面的所有非平凡函数依赖 a->b的 a 都是 R 的超码，那么 R 属于 BCNF
实际上,仅确认F功能取决于F功能并不意味着所有F+功能都取决于F+功能。
BCNF不承认以下类型的关系:
instr_dept (ID, name, salary, dept_name, building, budget )
因为存在非平凡函数依赖 dept_name-> building, budget
但是,地名不是超级编码。
3NF vs BCNF
重复工作
BCNF 消除该函数对冗余的依赖。
有三个NF和几个冗余。
分解,依赖因分解而维持功能以维持职能的依分解的依附性
所有连接模式都有3个NF分解装置,保持功能依赖性。
在某些关系模式中,不列颠哥伦比亚民族阵线分解无法维持该职能受抚养人。
分解的比值
3NF 分解算法
为了保持该功能的依附性,采用了以下3个NF分解战略:
初始覆盖的 F 最小值
为 Fc 的每个函数依赖 a->b 生成一个新的关系模式 a U b
如果所创建的关系模式没有包含 R 的候选人代码,
与 R 的任何候选代码 A 建立新的关系模式 A 。
检查创建的关系模式。 如果R1涉及R2, 应删除 R1 。
分解以下关系模式:
cust_banker_branch = (customer_id, employee_id, branch_name, type )
函数依赖集:
customer_id, employee_id -> branch_name, type
employee_id -> branch_name
customer_id, branch_name -> employee_id
然后,确定最低覆盖率,FC。
- 第一个函数依赖的分支名称是不必要的。
FC = { customer_id, employee_id -> type
employee_id -> branch_name
customer_id, branch_name -> employee_id }
生成每个函数的关系模式时 :
(customer_id, employee_id, type )
(employee_id, branch_name)
(customer_id, branch_name, employee_id)
无需为候选代码建立新的关系模式,因为(客户_id、雇员_id、类型)已经包含原始关系代码。
第二个关系模式是第三个模式的一个子集,可以删除。
最终得到的分解:
(customer_id, employee_id, type)
(customer_id, branch_name, employee_id)
BCNF 分解算法
假设关系模式 R 有一个非平凡函数依赖 a->b （且a并b = 空 ），a不是超码
R可分为以下两种关系模式。
a R-b和 a Ub
如果两种关系模式不是不列颠哥伦比亚民族阵线,则继续解体。
N.B. 该函数取决于设定 Fi, 而不是设定 F 上的函数, 以决定分解后获得的关系模式是否为 BCNF 。
例如：
R = (A, B, C, D, E)
F = { A-> B, BC-> D}
考虑 A -> B，A 不是超码，所以把 R 分解为
R1 = (A,B)
R2 = (A,C,D,E)
F功能依赖于,而不仅仅是包含(A、C、D、E)。
因此,根据F,无法确定R2是否是BCNF的成员。
实际上, F+ 中的 AC-> D 使得 R2 不属于 BCNF
这就是为什么我们仍在分解R2的原因