数据库-关系数据库设计

#6
这一章理解得太虚了，后面补充消化后的总结笔记。
1.如何设计更小的表结构？
(1)可以把冗余信息处理掉，减少字段数量
(2)有时候减少字段会导致信息的丢失及模糊

2.第一范式(first normal form)
(1)如果关系模式R的所有属性域都是原子的(域的元素被认为是不可分割的单元)，则关系模式R是第一范式
(2)非原子值使存储复杂化，并鼓励数据的冗余(重复)存储，比如存储在每个客户中的帐户集，以及存储在每个帐户中的所有者集
(3)原子性实际上是域元素如何使用的属性。举例来说，字符串往往是不可分割的，如果我们用学生的roll number = CS0012中的前两位表示学生所在专业，提取前两个字符来查找部门，则roll number的域不是原子域。并且这样做是一个坏主意，将导致在应用程序中而不是在数据库中对信息进行编码。
(4)因此我们需要判断一个关系集R是否处于一个好的状态，如果R不是一个好的状态，那么我们把R分解成{R1,R2,R3…Rn}确保每个关系都处于一个好的状态，并且分解要求是无损分解(lossless-join )

3.函数依赖functional dependencies
(1)法律性质的约束
(2)要求某一属性集的值惟一地确定另一属性集的值
(3)函数依赖是键概念的概括
(4)设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意两个可能的关系r1、r2，若r1[x]=r2[x],则r1[y]=r2[y]，或者若r1[y]不等于r2[y],则r1[x]不等于r2[x]，称X决定Y，或者Y依赖X。比如在设计学生表时，一个学生的学号能决定学生的姓名，也可称姓名属性依赖于学号，对于现实来说，就是如果知道一个学生的学号，就一定能知道学生的姓名，这种情况就是姓名依赖于学号，这就是函数依赖，函数依赖又分为非平凡依赖，平凡依赖；从性质上还可以分为完全函数依赖、部分函数依赖和传递函数依赖。

(5)K是一个候选键，当且仅当没有K的子集决定R而K决定R
(6)函数依赖关系允许我们表示不能使用超键表示的约束。我们一般使用函数依赖去测试关系，看看它们在一组给定的功能依赖项下是否合法，如果关系r在函数依赖的集合F下是合法的，我们说r满足F(r satisfies F)。同时我们还可以指定对一组法律关系的约束，如果所有关于R的法律关系都满足函数依赖集F，那么我们说F对R成立( F holds on R)。
(7)关系模式的特定实例可能满足功能依赖项，即使功能依赖项不包含所有合法实例。贷款的特定实例可能碰巧满足amount→customer_name(贷款额和顾客)。
(8)如果关系的所有实例都能满足函数依赖关系，那么函数依赖关系就是无关紧要的

(9)给定一组函数依赖项F, F在逻辑上暗示了某些其他函数依赖项。
F逻辑上隐含的所有函数依赖的集合是F的闭包。我们用F+表示F的闭包。F+是F的超集。

(10)BC范式：设关系模式R∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有候选码，那么R∈BCNF。举例来说，假如有个关系a->b严重违反了BC范式，我们可以把R分解成（a并b）与（R-（b-a））两个表。

(11)Constraints约束(包括函数依赖关系)在实践中检查成本很高，除非它们只涉及一个关系。如果只测试分解中每个独立关系上的依赖关系就足以确保所有功能依赖关系都保持不变，那么分解就是保留依赖关系。

4.第三范式
并不总是有可能实现BCNF和依赖保存,所以,我们考虑一个较弱的正常形式,被称为第三范式3NF。第三范式(Third Normal Form,3rd NF)就是指表中的所有数据元素不但要能惟一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。也就是说，对于一个满足2nd NF 的数据结构来说，表中有可能存在某些数据元素依赖于其他非关键字数据元素的现象,必须消除。
举例来说就是，如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性 分别代表学号，姓名， 所在系，系名称，系地址。关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是 2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION 将重复存 储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在， DNO -> LOCATION, 因此关键字 SNO 对 LOCATION 函数决定是通过传递依 赖 DNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性 LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

5.闭包
闭包就是由一个属性直接或间接推导出的所有属性的集合。
例如：f={a->b，b->c，a->d，e->f}；由a可直接得到b和d，间接得到c，则a的闭包就是{a，b，c，d}
(1)Reflexivity：b是a的组成，那么a决定b
(2)Augmentation：a决定b那么ra决定rb
(3)Transitivity：传输性
(4)Union：a决定b，a决定c那么a决定bc
(5)Decomposition：a决定br，那么a决定b，a决定r
(6)Pseudotransitivity（伪递移法则）：如果a决定b以及cd决定e，那么ac决定e

6.属性闭包的使用
(1)超码测试:测试如果属性a是超码,我们计算a,检查a+闭包在 R中，是否包含所有属性。
(2)F的计算闭包：对每个R中的属性a，我们计算其闭包，对每个闭包中的属性b，我们输出一个函数依赖——a决定b
(3)测试函数依赖：如果要检查是否有函数依赖a决定b存在，只需要检查b是否在a的属性闭包中。

7.正则覆盖
(1)功能依赖项集可能具有冗余依赖项，这些冗余依赖项可以从其他依赖项推断出来，功能依赖项的某些部分可能是多余的。

(2)直观地说，F的规范覆盖是一组与F等价的“最小”功能依赖项，没有冗余依赖项或依赖项的冗余部分。
(3)那么如何判断函数依赖是否有必要分解呢？我们考虑一个集合R中的一个函数依赖a决定b，为了检验a中的属性A是否无关，我们可以计算a中除A以外元素的闭包，如果包含b那么A就是无关的属性。
(4)判断左部属性是否多余:
已知alpha --> beta F(函数依赖集合)
A为alpha的一个子属性,若其多余,则
alpha-A --> beta (在F上求闭包)
alpha-A在F上求出来的闭包如果和alpha的闭包一致，则左部属性A多余。
(5)判断右部属性是否多余:
已知alpha --> beta F(函数依赖集合)
A为beta的一个子属性,若其多余,则
alpha --> beta (在F’上求闭包 其中F’是 F-{alpha–>beta}∪{alpha–>beta-A})
alpha在F’上求出来的闭包如果和alpha在F上求出来的闭包一致，则右部属性A 多余。

8.Lossless-join Decomposition无损分解

9.Dependency Preservation依赖保持
要保证原有的依赖关系均能够直接体现而并非是需要进行join操作才可以查询。

10.测试BCNF
要检查关系模式R是符合BCNF，只检查给定集合F中的依赖关系是否违反BCNF就足够了，而不是检查F+中的所有依赖关系。很明显如果F中的任何依赖项都不会违反BCNF，那么F+中的任何依赖项也不会违反BCNF。
然而，当测试R分解中的关系时，只使用F是不正确的。可能有些依赖函数没有被考虑进来，但是其他的依赖都满足BCNF。

若要检查R分解中的关系Ri是否在BCNF中，那么就根据F对Ri的限制对BCNF的Ri进行测试(即F+中所有只包含Ri属性的FDs)

11.Third Normal Form
在某些情况下，BCNF不能保持依赖关系，因此在更新时有效地检查FD冲突非常重要，我们定义一个较弱的范式，称为第三范式(3NF)。
允许一些冗余(稍后我们将看到例子),但可以对个人检查函数依赖关系。没有计算加入。总是有一个有损连接，依赖关系保持分解成3NF。

12.测试3NF
优化:只需要检查FDs在F，不需要检查所有FDs在F+。
使用属性闭包检查每个依赖项a-b，是否a是超键。如果a不是超键，则必须验证b中的每个属性是否包含在R的候选键中。
3NF分解算法保证每个关系模式Ri在3NF分解是保存和lossless-join的依赖。

13.BCNF与3NF比较
总是可以分解成一组关系为3NF的关系:分解是无损的，依赖关系被保留。
总是可以分解成一组关系为BCNF的关系:分解是无损的，可能不会保持依赖关系。

14.Design Goals
关系型数据库的设计的目标是BCNF，无损的连接，函数依赖保持的。
如果我们无法保持函数依赖，我们可以选择缺乏依赖项或保存冗余。
有趣的是，除了超键之外，SQL没有提供指定函数依赖项的直接方法。可以使用断言指定FDs，但是测试它们的成本很高。即使我们有一个保持依赖关系的分解，使用SQL我们也不能有效地测试一个函数依赖关系，它的左边字段不是键值。

15.Multivalued Dependencies多值依赖
有这样一个关系 <仓库管理员，仓库号，库存产品号> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个 <仓库管理员，库存产品号>有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖。每个函数依赖项也是一个多值依赖项。D的闭包D+是D逻辑上隐含的所有函数和多值依赖关系的集合。

16.我们以两种方式使用多值依赖关系:
(1)测试以确定他们是否关系是合法的在一个给定的一组功能和多值依赖下
(2)指定对一组合法关系的约束。因此，我们只关心满足给定的一组函数和多值依赖关系的关系。
(3)如果一个关系r不能满足给定的多值依赖关系，我们可以通过向r中添加元组来构造一个关系r来满足多值依赖关系。

17.4NF
4NF就是限制关系模式的属性之间 不允许有非平凡且非函数依赖的多值依赖。因为根据定义，对于每一个非平凡的多值依赖X→→Y，X都含有候选码，于是就有X→Y，所以4NF所允许的 非平凡的多值依赖实际上是函数依赖。

18.多值依赖的约束