第三章-规范化理论(09OK1).pptVIP

* hh * BC范式（续） BCNF的定义是： 如果关系模式R属于1NF，并且R的所有属性（包括主属性和非主属性）既不部分依赖也不传递依赖于R的码，则R∈BCNF。 BCNF(Boyce Codd Normal Form)是由Boyce和Codd提出的，比3NF更进了一步。通常认为BCNF是修正了的第三范式，所以只要不引起混淆或误解，有时统称它们为第三范式。 * hh * BC范式（续） 采用投影分解法将一个3NF的关系分解为多个BCNF的关系，可以进一步解决原3NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。 如果一个关系数据库中的所有关系模式都属于BCNF，那么在函数依赖范畴内，它已实现了模式的彻底分解，达到了最高的规范化程度，消除了插入异常和删除异常。 * hh * 3.3 规范化举例 一个不好的关系模式会导致 插入异常 删除异常 数据冗余度大 修改复杂 规范化的目的： 逐步消除数据依赖中不合适的部分 使模式中的各关系模式达到某种程度的‘分离’，让一个关系描述一个概念、一个实体或者实体间的一种联系。 若多于一个概念就把它‘分离’出去。 因此，所谓规范化实质上是概念的单一化。 * hh * 属于1NF的关系模式 属于2NF的关系模式 消除非主属性对码的部分函数依赖 属于3NF的关系模式 消除非主属性对码的传递函数依赖 属于BCNF的关系模式 消除所有属性对码的部分和传递函数依赖 规范化的过程 原始的关系模式 横向或纵向展开（去掉表中有表的情况） * hh * 规范化举例 例3-1 将下列模式转变为第一范式 横向展开 * hh * 规范化举例 例3-2 ：判断下列模式中，哪些是第二范式，指出非主属性对码的部分函数依赖。并将非第二范式的关系模式转换为第二范式。 （1）关系模式R1（A,B,C,D）,具有如下函数依赖 A→B， A，C→D * hh * A C B D 完全函数依赖 部分函数依赖 A C D 完全函数依赖 A B 完全函数依赖 R11（A , B）（2NF） R12（A , C , D）（2NF） 规范化举例 * hh * 规范化举例 （2）关系模式R2（A,B,C,D）,具有如下函数依赖 AB→C， AC→D, C→B 关系模式R2的码是AB,AC，不存在非主属性对码的部分函数依赖，R2是第二范式。 是第二范式吗？ * hh * 规范化举例 例3-3：判断下列模式中，哪些是第二范式，但不是第三范式，将其转换为第三范式。 （1）关系模式R1（A,B,C,D）,具有如下函数依赖 AB→C， C→D 关系模式R1的码是AB,不存在非主属性对码的部分函数依赖，属于第二范式。 是第二范式吗？ * hh * 规范化举例 AB→C，C→D， AB →D但由于存在非主属性D对码AB的传递函数依赖，故不属于第三范式。需要进行如下分解： 去掉函数依赖AB →D，就必须使他们分别属于不同的关系模式 R11（A,B，C），具有函数依赖AB→C R12（C,D），具有函数依赖C→D R11和R12消除了非主属性对码的传递函数依赖，属于第三范式。 * hh * 规范化举例 （2）第二个关系模式R2（A,B,C,D）,具有如下函数依赖 AB→C， D→A, D→B 关系模式R2的码是D,不存在非主属性对码的部分函数依赖，属于第二范式。 是第二范式吗？ * hh * AB→C，D→A,D→B，D →C D 传递函数决定C R2（A,B,C,D）不属于3NF R11（A,B,C) （ AB→C），属于3NF R12（D,A,B）（ D→A,D→B ）属于3NF 怎样分解？思路是什么？ 投影分解, 使D和C分别属于不同的关系模式 * hh * 规范化举例 例3-4： 右图表示了一个证券公司的客户关系E-R图。请将其中的每一个实体和每一个联系直接转化为关系模式，并判断它们分别属于第几范式 * hh * 规范化举例 关于实体客户的关系模式可以转换为： R1(姓名，股东代码，类型) 该关系模式的码是股东代码。属性类型是指股民的投资类别。如散户，大户等。 该关系模式所包含的函数依赖是： 股东代码→姓名 股东代码→类型 由于不存在任何属性对码的部分函数依赖和传递函数依赖，属于BCNF。 * hh * 规范化举例 关于联系开户的关系模式可以转换为： R2(股东代码，营业部名称，开户日期，开户账号)。 需要说明的是，一个客户可以在不同的营业部开户，每一个客户在同一个营业部只能有一个账号。(语义规定) 因此关系模式R2包含如下函数依赖： （股东代码，营业部名称）→开户日期 （股东代码，营业部名称）→开户账号 （营业