文章目录 Boyce – Codd范式检查是否为BCNFBCNF 分解算法BCNF与保持依赖 第三范式（3NF）- 动机BCNF 与 3NF的比较检查是否为3NF3NF分解算法练习设计目标 多值依赖多值依赖定义多值依赖理论 第四范式（4NF）更多的范式数据库设计过程E- R模型和规范化为了性能去规范化其他设计问题 总结
Boyce – Codd范式
具有函数依赖集合F的关系模式R属于BCNF的条件是，当且仅当对F+中所有函数依赖α → β（其中，α包含于β，且β包含于R），下列至少有一项成立：
α → β是平凡的函数依赖（即，β包含于α）α是R的超码（即，R包含于α+，α → R）
回顾：公共部分是否已子关系的键 → 无损连接分解
检查是否为BCNF
为检查非平凡依赖α →β 是违反BCNF的要求
计算α+检验α+是否包含R的所有属性（即，是否为R的超码）
简化的测试：为检查具有函数依赖集合F的关系模式R是否属于BCNF，只需检查F中的函数依赖是否违反BCNF即可，而不需要检查F+中的所有函数依赖
可以证明如果F中没有违反BCNF的依赖，则F+中也没有违反BCNF的依赖
—因为F+是由Armstrong的3个公理从F推出的而任何公理都会使函数依赖的左边变小（拆分），故若果F中没有违反BCNF的函数依赖（即，左边是超码），则F+中也不会。
但是，当检查R的分解后的关系时仅用F是错误的。
BCNF 分解算法
BCNF分解示例
BCNF与保持依赖
BCNF分解不总是保持依赖的
因此，我们并不总能满足这三个设计目标：
无损连接BCNF保持依赖 第三范式（3NF）- 动机
存在这样的情况
BCNF不保持依赖但是，有效检查更新是违反函数依赖是重要的
解决方法：定义一种较弱的范式，称为第三范式（3NF）
允许出现一些冗余（从而会带来一些问题）但函数依赖可以在当个关系中检查，不必计算链接总是存在到3NF的无损连接分解，且是保持依赖的
定义： 关系模式R属于第三范式（3NF）当且仅当对所有F+中的函数依赖α → β使得下列条件中至少一个成立：
α → β是平凡的函数依赖（即，β∈α）α是β的超码β – α中的每个属性A都包含于R的一个候选码中（即A∈β – α 是主属性，若α ∩ β = ∅，则A = β是主属性）
注：各属性可能包含在不同的候选码中。
推论：
若一个关系属于BCNF则一定属于3NF；第三范式相对于BCNF来说放款了约束，允许非平凡函数依赖的左边不是超码。因为候选码是最小的超码，他在任何一个真子集都不是超码；第三个条件是对BCNF条件的最小放宽，以确保每一个模式都有保持依赖的3NF分解。
BCNF 与 3NF的比较
总是可以将一个关系分解到3NF并且满足
分解是无损的保持依赖
总是可以将一个关系分解到BCNF并且满足
分解是无损的但可能不保持依赖 检查是否为3NF
优化：只需要检查F中的函数依赖，而不必检查F+中所有的函数依赖；
对于每一个依赖α→β，利用属性闭包来检查α是否为超码；
若果α不是超码，必须检查β中的每个属性是否包含在R的某个候选码中
这个检查较昂贵，因为它涉及求候选码检查是否属于3NF是NP-hard的有趣的是，分解到第三范式可以在多项式时间内完成 3NF分解算法
3NF示例
练习
视频讲解
设计目标
关系数据库设计目的是：
BCNF无损连接依赖保持
如果不能达到这些，也可以接受：
缺少保持依赖因3NF引起的冗余
除了超码之外，SQL并没有提供直接声明函数依赖的方法。可以通过断言声明函数依赖，但是检测代价太大；
因此即使我们有一个保持依赖的分解，使用SQL，我们也不能有效的检测左部不是码的函数依赖。
多值依赖
有时属于BCNF的模式qcdbwb未充分规范化
考虑数据库
classes（course，teacher，book）
定义（c，t，b）∈ classes，分别代表课程c由教师t来教，需要用到该课程的教材b。
数据库将为每门课程列出能讲授该科的教师的集合，以及需要用的教材的集合（不管谁讲授该课程）。
course：teacher = 1：n，course：book = 1：nteacher和book是多值属性，并且teacher和book相互独立
由于没有非平凡依赖，（course，teacher，book）是唯一的键，因此该关系模式属于BCNF。
冗余与插入异常：如果zddxj是能教数据库的新教师，必须插入两条元组教材不同
（database，zddxj，DB Concepts）（database，zddxj，UIIman）
多值依赖定义
在前面的例子中：
course →→ teachercourse →→ book
上述形式定义表达了这种概念：
给定Y（course）的特定值，则有一个Z（teacher）值的集合和一个W（book）值的集合与之相关联，而这两个集合在某种意义上是相互独立的。 多值依赖理论
根据多值依赖定义，课导出下列规则：
若α → β，则α →→ β，即函数依赖是多值依赖的特例
D的闭包D+是D逻辑蕴含的所有函数依赖和多值依赖的集合
可根据函数依赖与多值依赖的形式定义来从D计算D+我们只对在实践中较常见的简单多值依赖可用这样的推理对于复杂的依赖，最好利用一套推理规则来对依赖集合进行推理 第四范式（4NF）
关系模式R关于函数依赖及多值依赖集合D属于4NF当且仅当对D+中所有形如α →→ β的多值依赖，其中α包含于R且β包含于R，下列条件中至少一个成立：
α →→ β是平凡的（即，β包含于α 或 α ∪ β = R）α是模式R的超码
若关系属于4NF，则它必属于BCNF
更多的范式
链接依赖概化了多值依赖
并引出了另一种范式投影 – 链接范式（PJNF）
还有一类更一般化的约束，它引出一种称作域 – 码范式（domain – key normal form）
使用这些一般化的约束的一个实际问题是，他们不仅难以推导，而且也还没有形成一套具有正确有效性和完备性的推理规则用于约束的推导，因此，很少使用。
数据库设计过程
假设给定了模式R
R可能是经转换E-R图到表而生成的R可能是单个包含所有属性的关系（称为全关系）规范化将R分解成较小的关系R可能是某种特定设计的结果，然而再测试/转换成范式 E- R模型和规范化
当我们小心地定义当E – R图，并正确地标识所有实体，则从E – R图生成的关系模式就不需要太多进一步的规范化；
但是，在现实（不完善的）设计中可能存在从实体的非码属性到其他属性的函数依赖
例如：employee实体具有属性department_name和building，以及函数依赖department_name → building好的设计应该将department作为实体
从联系集的非码属性引出函数依赖是可能的，但极少一一多数联系是二元的
为了性能去规范化
当我们小心地定义当E – R图，并正确地标识所有实体，则从E – R图生成的关系模式就不需要太多进一步的规范化；
为了提高性能可能使用非规范化的模式。
例如：假定每次访问一门课程时，所有先修课都必须和课程信息一起显示，需将course和preq链接。
做法1：使用包括course以及preq的所有上述属性的反规范化关系
查找迅速额外空间以及额外更新执行时间程序员的额外编码工作以及更多出错可能性
做法2：如下定义的物化视图
其他设计问题
有些数据库设计问题不能被规范解决
总结 我们概述了一个将关系分解成BCNF的算法，有一些关系不存在保持依赖的BCNF分解；用正则覆盖将关系分解成3NF，它比BCNF的条件弱一些。属于3NF的关系也会含有冗余，但是总存在保持依赖的3NF分解；介绍了多值依赖的概念，它指明仅用函数依赖无法指明的约束；用多值依赖定义了4NF；其他的范式，如PJNF和DKNF，消除了更多细微形式的冗余。但是，他们难以操作而且很少使用；数据库设计过程中，要考虑的规范化问题。