第3章 关系数据库设计理论.pptVIP

非规范化关系，满足1 NF的关系称为规范化关系。在任何一个关系数据库系统中，关系至少应该是1 NF。不满足1NF的数据库模式不能称为关系数据库。在以后的讨论中，我们假定所有关系模式都是1NF。但是满足第一范式的关系模式并不一定是好的关系模式，不能排除数据冗余和更新异常等情况。 3.4.2第二范式（2NF） 对于关系R，若R∈1NF，且每一个非主属性完全函数依赖于码，则R∈2NF。 第二范式不允许关系模式中的非主属性部分依赖于键码。如果数据库模式中每个关系模式都是2NF，则称数据库模式为2NF的数据库模式。 2NF 在 1NF基础上消除了非主属性对码的部分函数依赖。 分解成2NF模式集的算法： 设关系模式R（U），主键是W，R上还存在函数依赖 X → Z，并且Z是非主属性和X ? W，那么W → Z就是一个部分依赖。此时应把R分解成两个模式： R1（X Z），主键是X； R2（Y），其中Y=U -Z，主键仍是W，外键是X（REFERENCES R1）。 利用外键和主键的联接可以从R1和R2重新得到R。 如果R1和R2还不是2NF，则重复上述过程， 一直到数据库模式中每一个关系模式都是2NF为止。 第二范式只要求每个非主属性完全依赖于键码，并未限定非主属性不能函数依赖于其它非主属性，即允许S1中的Sdept → Mname 存在，从而也允许传递依赖的存在。所以，将一个不满足第二范式的关系分解成多个满足第二范式的关系，只能在一定程度上减轻了原关系中的更新异常和信息冗余，但并不能保证完全消除关系模式中的各种异常和信息冗余。 2NF的关系模式解决了1NF中存在的一些问题，2NF规范化的程度比1NF前进了一步，但2NF的关系模式在进行数据操作时，仍然存在着一些问 题： ⑴ 数据冗余。每个系名和系主任的名字存储的次数等于该系的学生人数。 ⑵ 插入异常。当一个新系没有招生时，有关该系的信息无法插入。 ⑶ 删除异常。某系学生全部毕业而没有招生时，删除全部学生的记录也随之删除了该系的有关信息。 ⑷ 更新异常。更换系主任时，仍需改动较多的学生记录。 3.4.3第三范式（3NF） 第二范式的关系模式消去了非主属性对键码的部分依赖，但属性之间还存在传递依赖，传递 依赖也会给数据库的维护带来一系列的问题，因此，我们希望消去关系中传递依赖，并由此引入满足这种要求的第三范式。 如果关系模式R是1NF，且每个非主属性都不传递依赖于R的候选键，那么称R是第三范式（3NF）的模式。如果数据库模式中每个关系模式都是3NF，则称其为3NF的数据库模式 。 分解成3NF模式集的算法： 设关系模式R（U），主键是W，R上还存在FD X→Z。并且Z是非主属性，Z ? X，X不是候选键，这样W → Z就是一个传递依赖。此时应把R分解成两个模式： R1（X Z），主键是X； R2（Y），其中Y = U - Z，主键仍是W，外键是X（REFERENCES R1）。 利用外键和主键相匹配机制，R1和R2通过联接可以重新得到R。 如果R1和R2还不是3NF，则重复上述过程，一直到数据库模式中每一个关系模式都是3NF为止。 需要说明一点：属于第三范式的关系模式必然属于第二范式。因为可以证明部分依赖蕴含着传递依赖。 证明过程：设A是关系模式R的一个非主属性，K是R的键码，且K → A是部分依赖，则A必然函数依赖于K的某个真子集K’,即K’→ A. 因为K’? K,所以K→K’（平凡依赖）但K’→ K。从K→K’和 K’→ A 可知K → A是传递依赖。因此，可把部分依赖看作是传递依赖的特例。 3.4.4 BC范式（BCNF） 第三范式的关系模式消除了非主属性对键码的传递依赖和部分依赖，但这并不彻底，因为它不能很好地解决键码含有多个属性的属性组情况，仍然可能存在主属性对键码的部分依赖和传递依赖，并由此也会造成数据的冗余和给操作带来问题。 若关系模式R属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式(BCNF). 通常BCNF的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须 包含键码。 从定义可以看出，BCNF既检查非主属性，又检查主属性，显然比第三范式限制更要。当只检查非主属性而不检查主属性时，就成了第三范式。因此可以说任何满足BCNF的关系都必然满足第三范式。 BCNF具有三个性质: （1）所有非主属性都完全函数依赖于每个候选码。 （2）所有主属性都完全函数依赖于每个不包含它的候选码。 （3）没有任何属性完全函数依赖于非码的任何一组属性。 *3.4.5 分解的原则 对关系模式进行分解的目的是使模式更加规范化，从而减