关系数据库范式设计——常玉慧.ppt

1、1,关系数据库设计范式,?,如何评价酒店的星级,酒店,酒店的划分与评定标准,一星级酒店 二星级酒店 三星级酒店 四星级酒店 五星级酒店,评定为,依据,如何评价酒店的星级,如何评价酒店的星级,范式,1NF 2NF 3NF BCNF 4NF 5NF,依据,判定为,关系模式,9/1/2020,6,DataBase,工程号、工程名称、职工号、姓名、职务 ；,一项工程由多个职工参加，一个职工也可以参与多个工程；,公司按照工时和小时工资率支付工资，小时工资率由职工的职务决定,Table 1,Table 2,Table n,Table 1,Table 2,Table n,9/1/2020,7,公司的项目工时

2、表,非规范,关系数据库不支持 这种数据结构！,冗余数据,9/1/2020,8,如果一个关系模式R的所有属性都 是不可分的基本数据项，则R1NF。,9/1/2020,9,公司的项目工时表,每当一名职工分配一个工程时，都要重复输入大量的数据。这种重复的输入操作，既占据存储空间，又使得数据库的更新变得复杂，操作不当很可能导致数据的不一致性。,9/1/2020,10,若要增加一个新的职工时，首先必须给这名职工分配一个工程。或者为了添加一名新职工的数据，先给这名职工分配一个虚拟的工程。（因为主关键字不能为空）,9/1/2020,11,A4,虚拟的工程号,1005,王启明,技术员,60,异常：工程号不存在

3、或者该职工根本没有参与此项目！,如果1003号职工要辞职，则必须删除所有职工号1003的数据行。,9/1/2020,12,丢失了项目 A2的信息,异常：这样的删除操作，丢失了项目A2所有有用的数据！,9/1/2020,13,原因：一张表描述了多件事情,函数依赖图,工程信息,员工信息,项目工时信息,注意：存在非主属性对码的部分依赖 例如：（工程号，职工号） P 工程名称,若关系模式R1NF，并且每一个非主 属性都完全函数依赖于R的码，则R2NF。 上述的项目工时表1NF，但2NF。,9/1/2020,14,15,9/1/2020,思考：员工表中 小时工资率被重复 存储，修改技术员的 小时工资率怎

4、样操 作呢？,原因：存在非主属性“小时工资率”对码“职工号”的传递依赖,60,60,62,62,工程表,员工表,项目工时表,1NF,2NF,消除非主属性对码的部分依赖,如果关系模式R中的所有非主属性对 任何候选码都不存在传递依赖，则称关系 R 3NF。 员工表 2NF 员工表 3NF,9/1/2020,16,3NF的定义,17,9/1/2020,职工表,职务表,消除了非主属性对码的传递依赖,员工表,2NF,3NF,9/1/2020,18,工程表,职工表,职务表,项目工时表,任务完成，数据库包含如下四张表： 工程表（工程号，工程名称）3NF 职工表（职工号，姓名表，职务）3NF 职务表（职务，小时工资率）3NF 项目工时表（工程号，职工号，工时）3NF,规范化的本质是提高数据独立性，解决插入异常、删除异常、修改复杂、数据冗余等问题的方法。 1NF的目标：原子性 2NF的目标：非主属性列和主码完全相关 3NF的目标：非主属性列和主码直接相关,9/1/2020,19,总 结,下表给出的关系R为第几范式？是否存在操作异常？若存在，