数据库设计之规范化.pptVIP

7.3 范式 例1：判断R（教师编号，教师地址，课程号，课程名）是否属于第二范式。 候选码：（教师编号，课程号） 非主属性：教师地址，课程名 因为: (教师编号，课程号) 教师地址 (教师编号，课程号) 课程名 所以本关系模式不属于第二范式。 SQL Server 2000 例2：判断 选课（学号，课程号，成绩）是否属于2NF ，假如规定一个学生一门课只有一个成绩 候选码：（学号，课程号） 非主属性：成绩 因为成绩完全函数依赖于（学号，课程号） 所以属于2NF 7.3 范式 SQL Server 2000 例3：判断教师上课teach(teacher,class,course) ∈2NF? 假定一位教师给同一个班至多上一门课，一门课可以由多位教师上，一名老师也可上多门课。 候选码：（teacher,class） 非主属性： course 因为course完全函数依赖于（ teacher,class） 所以属于2NF 7.3 范式 不满足第二范式的关系模式必然存在各种存储异常。如例1 满足了2NF是不是就不存在存储异常呢？不是。 例：学生（学号，姓名，年龄，系名，系主任） 它满足2NF，但还存如下问题； 存在数据冗余：大量的系信息冗余； 它存在插入异常：系刚成立，没有学生时不能添加系； 它存在删除异常：某系学生全部毕业，系的信息丢失； 它存在修改异常：系主任改动，需要改动多处。 ? 因此，满足了2NF还不够。 7.3 范式 如果关系模式R∈2NF，且R的任一非主属性都不传递函数依赖于任何候选码，则称R属于第三范式，R∈3NF。 通俗理解：要求一个表中不包含已在其他表中包含的非主关键字。 三、第三范式（3NF） 7.3 范式 不满足3NF的关系模式存在各种存储异常。那么满足3NF的关系模式是不是就不存在存储异常呢？一般情况下是可以了，但有些特殊情况下依然还存在存储异常。 例4：判断关系模式选课（学号，姓名，课程号，成绩）∈3NF？ 步骤：它是否满足2NF？不是。 既然不满足2NF，当然不满足3NF。 7.3 范式 如：教学（学生，教师，课程），假定每一教师只能讲一门课，每门课由若干教师讲授，每个学生选修某门课时就对应一个固定的教师。 候选码：（学生，教师），（学生，课程） 三个属性都是主属性，没有非主属性，满足2NF和3NF。 但该关系模式还是有数据冗余和存储异常。如 插入异常：无法存储不选课的学生和不开课的教师 删除异常：无法删除一个学生的选课信息 更新异常：某门课的某位教师换了，则选该教师的所有记录均需修改。 数据冗余大：一个学生选多门课，需重复存放该学生的信息 7.3 范式 问题存在的原因： 主属性部分函数依赖于侯选码 （注2NF，3NF是要求非主属性对侯选码的要求，而不是主属性对侯选码的要求） 如（学生，教师）→课程，而教师→课程，所以课程部分依赖于码（学生，教师） 7.3 范式 四、BC范式（BCNF） 设关系模式R（U）∈1NF，如果对于R的每个非平凡函数依赖X→Y（Y X），则X必包含候选码，那么R∈BCNF。即若每一个决定因素都包含候选码，则R∈BCNF。 7.3 范式 SQL Server 2000 由BCNF的定义可以看出，每个BCNF的关系模式都具有如下性质： 所有非主属性都完全函数依赖于每个侯选码 所有主属性都完全函数依赖于每个不包含它的侯选码 没有任何属性完全函数依赖于非码的任何一组属性(即每一个决定因素都包含码) 从函数依赖范畴内，BCNF已经达到了最高的要求。 推论：如果R只有一个侯选码，且R∈3NF，则R必属于BCNF 7.3 范式 BCNF与3NF的区别：3NF只强调非主属性对码的完全直接依赖，而BCNF不仅强调非主属性对码的完全直接依赖，而且强调主属性对码的完全直接依赖，它包括3NF。 7.3 范式 将关系模式转化为较高级的范式称为关系模式的规范化。 关系模式属于范式的级别越高，出现异常的概率越小，所以我们应该让关系模式尽可能属于较高级的范式。 规范化的目的：解决插入、修改、删除异常以及数据冗余度高等问题。 规范化的方法：从模式中各属性间的依赖关系入手，尽可能做到每个模式表示客观世界中的一个“事物”。 规范化的实现手段：关系模式的规范化通常是采用分解的办法，也就是将关系模式分解为几个关系模式，使每个关系模式都达到更高的范式级别。但这种分解要求信息不能有损失。 五、关系模式的规范化 7.3 范式 范式小结： 1NF ↓ 消除非主属性对侯选码的部分依赖 2NF ↓ 消除非主