数据库chap08规范化.pptVIP

? Pearson Education Limited, 2004 Chapter 8 规范化 Chapter 8 – 目标 存在冗余数据的表在更新异常的时候有什么表现，这可能将不一致性引入数据库。 最经常使用的规范化规则，即第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。 不符合1NF、2NF、3NF的表怎样含有冗余数据，在更新异常时有什么后果。 怎样重建不符合1NF、2NF、3NF的表。 规范化（Normalization） 规范化（Normalization）：是指创建的一些具有预期实用性的表的一项技术。这些表具有符合要求的属性，并能支持用户或公司的需求。 常用范式：1FN，2NF，3NF 这些范式是基于表中的列之间的关系的。 数据冗余和更新异常 关系数据库设计的一个主要目的是把列组合成表使数据的冗余最小，并减少实现基表所需的文件存储空间。 为了说明数据冗余的相关问题，比较Staff 和 Branch 表与StaffBranch表。 数据冗余和更新异常 数据冗余和更新异常 数据冗余和更新异常 StaffBranch 表有冗余数据，分公司的详细信息在分公司每个员工那里被重复一遍。 相反的，在Branch表中，每一个分公司的详细信息仅出现一次，而且在Staff表中只有分公司编号(branchNo) 被重复，它用来指出每个员工属于哪个分公司。 有冗余数据的表可能产生：插入、删除和更新异常。 插入异常 删除异常 更新异常 第一范式 (1NF) 1NF：每个列和行的交叉处包含一个而且仅包含一个值的表。即表中不包含多值属性。 对于关系数据库来说，只有第一范式在创建适当的表中是关键的。所有接下来的范式都是可选的。 Branch 表不是 1NF 的一个例子 转换 Branch 表为 1NF 第二范式（2NF） 2NF：一个第一范式的表并且每个非主键列都可以从构成主键的全部的列（复合主键）得到。 第二范式仅仅应用于具有复合主键的表。 单列主键的1NF，一定是2NF。 TempStaffAllocation 表不是 2NF 功能依赖 功能依赖是表中列的含义的性质，表明了各列是如何相互依赖。 例如，假设一个表含有列A和列B，列B功能上依赖于列A（用A-B表示）。如果我们知道了A的值，则在任何时候，我们在所有记录总只能找到对应这个A值的唯一B值。因此，当两个记录还有相同的A值的时候，它们都含有相同的B值。但对于给定的B值就可能有几个不同的A值。 第二范式的形式化定义 第二范式的形式化定义是一个属于第一范式的表，并且它的每一非主键列在功能上都完全依赖于主键。 严谨定义：如果一个关系R属于1NF，且他的所有非主属性（非候选码的属性）都完全函数依赖于R的任一候选码（简称码），则R属于2NF。 完全功能依赖是指，如果B不依赖于A的任何子集，则B完全功能依赖于A，如果B依赖于A的子集，则就称其为部分依赖。 如果主键中存在部分依赖，则这个表就不属于2NF。去掉部分依赖，才可变为2NF。 转换 TempStaffAllocation表为2NF 2NF例二 职工信息（职工号,姓名,职称,系名,系办公地址,学历,毕业年份） 由于包含了部分函数依赖，不符合2NF的定义，可将其分解为下面两个关系模式： 职工信息（职工号 ,姓名,职称,系名,系办公地址） 学历（职工号,学历 ,毕业年份） 第三范式（3NF） 一个已经是第一和第二范式的表，并且所有的非主键列的值都只能从主键列得到，而不能从其他的列得到。 严谨定义：如果关系模式R属于2NF，且它的每一个非主属性（非候选码的属性）都不传递依赖于任何候选码，则R是3NF。 推论1：如果关系模式属于1NF，且它的每一个非主属性既不部分依赖，也不传递依赖于任何候选码，则R是3NF。 推论2：不存在非主属性的关系模式一定是3NF。 StaffBranch 表不是 3NF 第三范式的形式化判别 例如，考虑一个含有列A、B、C的表。如果B功能依赖于A（A-B），并且C功能依赖于B（B-C），那么C就通过B（即使A不功能依赖于B或C）传递依赖于A。 如果传递依赖存在于主键中，这个表就不属于3NF。 转换 StaffBranch 表为 3NF 3NF例二 职工信息（职工号,姓名,职称,系名,系办公地址）不属于3NF，可把它分解如下，使其符合3NF： 职工（职工号 ,姓名,职称,系名） 系（系名 ,系办公地址） 小结 规范化是指创建的一些具有预期实用性的表的一项技术。 含有冗余数据的表可能会导致的问题叫做更新异常，可分为插入异常、删除异常和更改异常。 1NF：一个表中的每一个列和记录有且仅有一个值。 2NF：一个属于1NF的表，它的每一个非主键列必须完全由全部的主键列决定。 3NF：一个属于2NF的表