对码有部分依赖、对码有部分依赖，如果限定在非主属性。消除不好的依赖，达到2、3NF。如果进一步扩大到主属性，则消除不好的依赖后，达到BCNF，
BCNF的例子复杂一些：
这个是满足3NF，但是不满足BCNF的例子，运用模式分解
分解之后，达到了BCNF，
是否存在什么副作用？
前边讲2NF、3N，给人的感觉似乎是越来越好
只有好处没有坏处
那么，3NF->BCNF
是否也是 只有好处没有坏处？
BCNF解决了函数依赖的所有问题，再往上
需要分析新的数据依赖，多值依赖
每门课程有一组参考书，每门课程也有一组教师，并且，参考书和教师互相独立，即，不管哪个人上课，用的一套书都一样
这个例子做成关系表，Teach（课程, 教师, 参考书）
参考书和教师互相独立
课程,->->教师，课程,->->参考书
表示一门课程可以决定一组教师，或者，一门课程可以决定一组参考书
并且，这种依赖关系不会受其它因素影响
这个就是多值依赖的含义
这里特别注意，不会受其它因素影响 这句话
如果不加这句话，就没有意义了
因为给定一个X，肯定对应了 一组Y
关键是，X对应的这一组Y
不会受到其它因素影响，直观地说
就是把一个关系的所有列分成 X、Y、Z 三部分
X决定一组Y，不受Z影响
X决定一组Y，不受Z影响 称为 X->->Y
读作，X多值决定Y或者，Y多值依赖于X
现在来看一个特例，如果把关系的所有列分成两组，X和Y
那么，会怎么样？
结论是，必然有 X->->Y，因为这时候没有Z
当然也无所谓 受Z的影响
把关系的所有列分成两组 X和Y，则必然有 X->->Y
这样的多值依赖称为平凡多值依赖
和前边 平凡函数依赖 类似
平凡多值依赖 对数据库设计没有用，所以，我们分析的都是 非平凡多值依赖
也就是，把所有属性分成三份X、Y、Z的多值依赖
接下来看上边的例子
教师对课程有 非平凡多值依赖那么会带来什么影响？
假如，数据库课程 有3位教师有5本参考书
那么，表达数据库课程信息需要几行？15
那现在换一个人上数据库有5本参考书
那么，就需要换掉5行的内容
从这里可以看出多值依赖也会造成数据冗余性和数据操作复杂
能不能改善这个问题？
答案是：可以
但是，函数依赖在这里不起作用。因为现在的问题是 多值依赖
类似前边。我们找到了 有问题的数据依赖，就针对 有问题的地方 进行模式分解
课程->->教师 有问题，我们就对这里进行分解
大家看一下上边的分解
C是课程、T是教师、B是参考书
分解以后，显然 非平凡多值依赖不见了，只剩下两列，变成了 平凡多值依赖
大家再看刚才的问题：冗余度、数据操作
更换一名课程教师，这时候只需要在 R（课程，教师） 关系里
改动一行就够了，3名教师占3行
5门课程，在另一张表里占5行
这个就是，按照 非平凡多值依赖 进行模式分解
我们再观察一个现象
选出一门课，改一种画法
离散数学、二分图
二分图可以看出什么呢
这就是 非平凡多值依赖 的一个特征
叫做 对称性
关系的所有列分成 X、Y、Z 三部分
如果有 X->->Y
那么，同时也必然有 X->->Z
就是说， X->->Y 和 X->->Z 一定是成对出现的
所以，大家分析关系模式
就等于也发现了 X->->Z
消除了 非平凡多值依赖
就达到了更高级别的范式4NF
还有一个问题大家考虑一下
函数依赖 和 多值依赖 有什么联系？
函数依赖，X决定一个Y
多值依赖，X决定一组Y
一个 是 一组 的 特例
所以，函数依赖 一定是 多值依赖
X->Y
表达，X可以明确确定一个Y
并且隐含了不受其它因素影响
所以，可以把 函数依赖 看作是 多值依赖 的特殊情况
假如，一张表有5列现在把这张表分解成5张
每张表1列，大家说，这样分解以后满足几范式？4NF
因为高一级范式包含了低一级范式的条件
分成5个单列表，有没有意义？
这个直观上看没有意义
我们把数据放进表，就是因为列跟列之间有联系
全都分开了，比如，你的名字和你的身高
这样对处理问题完全没有帮助。但是，这是直观的说法
研究数据库的科学家。从理论上提出了两个概念
无损连接性和 保持函数依赖
无损连接性 表示模式分解之后
分解成的小表可以通过自然连接还原成原来的大表
可以回想我们前边的例题全都是符合 无损连接性 的
也就是说找到有问题的数据依赖
从这里入手进行分解
一定满足 无损连接性
这就提醒我们模式分解不能凭感觉
分解的前提是找到有问题的数据依赖
如果你凭感觉随便分。那么，有可能分完了以后
回头做连接数据会对不上
再来看另外一项，保持函数依赖
这一项的字面意思是，原来的大表中有多少函数依赖
分解以后的小表里，函数依赖 一个都不能少
当然，具体含义更复杂一些
保持函数依赖 比较麻烦
我们现在回头看前边BCNF的例子
分解前后函数依赖有没有变少？
这两个实际上是一个
因为 T->J，显然有 （S，T）->J
比如，身份证号可以决定你的身高，身份证号 再附加一个 姓名，肯定可以决定 身高
抽象地表示是 X一方可以扩大
分解前：
分解后：
分解后还有没有
没有
直观的原因是左边（S，J）已经不在一张表里了
或者说（S，J）是原先大表里的一个 候选码
模式分解以后
这个候选码不存在了
书上并没有说 原先某个候选码不存在 和 函数依赖丢失 之间是否有什么联系
但就这个例子而言似乎是这总原因造成的
这是我的个人看法，未必正确
大家听了以后自己思考
这个例子至少提醒我们
BCNF面临的问题是
通过 主属性对码的部分依赖、传递依赖 进行分解
得到的结果
主属性，即 某一个候选码 的属性
（这种分解
可能会破坏一部分候选码
进一步破坏掉一部分函数依赖，老师个人看法）
书上只给出了一个结论：若要求分解保持函数依赖，那么模式分解一定能够达到3NF，但不一定能够达到BCNF
大家看一下这句话。意思是，函数依赖一个都不丢失，可以保证达到3NF
但是，从3NF再向BCNF走
也许在 不丢失函数依赖 的条件下可以走到，但也可能无法走到，不一定能够达到BCNF
模式分解的要求
⒈ 分解具有无损连接性
⒉ 分解要保持函数依赖
⒊ 分解既要保持函数依赖，又要具有无损连接性
无损连接性和分解保持函数依赖是两个互相独立的标准
互相独立，表示满足一个跟满足另一个无关
即
具有无损连接性的分解不一定能够保持函数依赖
保持函数依赖的分解也不一定具有无损连接性
若要求分解具有无损连接性，那么模式分解一定能够达到4NF
若要求分解保持函数依赖，那么模式分解一定能够达到3NF，但不一定能够达到BCNF
若要求分解既具有无损连接性，又保持函数依赖，则模式分解一定能够达到3NF，但不一定能够达到BCNF
再强调一点：根据 有问题的数据依赖 为线索，去做模式分解，一定满足 无损连接性
关系数据库最有创造性的内容 范式理论
数据库设计的核心任务=找出数据项+参照完整性+数据依赖
找出数据项这是需求分析的任务
动词在数据库设计里 表达，联系表 对 基本表 的 参照
第一步，根据 需求 的描述，把 名词、动词 分离出来
第二步，名词对应基本表，动词对应联系表
联系表 参照 基本表,所以，数据库设计的结果大体是
数据库设计的结果
1 是一组表
2 里边的关键因素是，表之间的 参照 联系
跟你们的UML类图很象
但是比UML类图简单,因为UML里class之间的联系比较复杂
动词----联系表,名词---基本表
联系表 参照 基本表,把这个说法形象的表示
书上叫做E -R图
数据库的 参照前边讲过
本质是 数量关系
1：m表示 1个对应多个
所以，数据库设计通常提取出名词、动词以后
把它们画成E-R图的形式,容易看
当然,画E-R图不算是必须的,你也可以直接画 关系图,许多设计数据库熟练的人会采取这种做法
E-R图向关系模型的转换
⒈ 一个实体型转换为一个关系模式。
⒉ 一个m:n联系转换为一个关系模式（两边实体的主码加联系自身的属性）。
⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。
⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
⒎ 具有相同码的关系模式可合并。
大意是:
m:n必须有独立的 联系表,而1:m，可以把 联系表 吸收进 基本表
1：m 比如，学生表，系表两张表
学生表 里有一列 系号，参照 系表
相当于，把 联系表 吸收进 学生表
你也可以不在学生表里放 系号
而是单独建一张表 R（学号，系号）
这样就把联系表独立出来
两种做法都可以
数据库设计基本工作完成
但是，这时候的表因为是凭主观设计的,可能存在 不好的表
所以，接下来，还需要用 数据依赖进行细致分析
看看有哪些表不好需要分解
数据库的物理设计：数据库在物理设备上的存储结构与存取方法的设计
数据库实施：建表，输入数据，系统访问数据库试运行
数据库运行与维护：系统日常运行与数据库维护
数据库设计=1 提取 名词、动词 2 建立 联系表 参照 基本表 3 用范式理论优化表
HOMEWORK:
