[工学]实体联系模型E-R模型--补充.pptVIP

2.5 关系模型 2.5 关系的规范化--前三个范式的实例(图1) 前三个范式的实例--1 1)项目号—希望是主键,或者是主键的一部分,但是包含Null值. 2)该表有数据冗余,这些冗余产生了如下异常. ●更新异常:当重复信息的一个拷贝被修改,所有的拷贝都必须进行同样的修改,否则就会造成不一致性. 例如:修改员工号为102的员工”工作类型”将潜在的要求许多的修改,对每个”员工号”=102的记录都需要修改. ●插入异常:只有当一些信息事先已经存储在数据库中时,另外一些信息才能存入到数据库中. 例如:为了满足行的定义,新员工必须被分配到某个项目.如果员工没有被分配到某一个项目中,就必须创建一个虚拟的项目,以完成员工数据录入. ●删除异常:在删除某些信息时可能会丢失其他信息. 例如:如果员工104辞职了,必须删除所有”员工号”=104的记录,而一旦这些记录被删除,将会丢失许多别的重要数据. 注意:每次把员工分配到某个项目时,没有必要重复记录某些数据如(项目名,员工名等) 前三个范式的实例(图2) 前三个范式的实例—第一范式1 因为关系模型将数据看作表的一部分或者表的集合的一部分,这些表中所有的码值必须确定,所以图1中的数据不能够按照所显示的格式存储. 由上所述,可将图1改成图2即可. 图3所示的依赖图来标识依赖. 前三个范式的实例—第一范式2 分析图3的时候,注意下面几点. 1)主码属性是下划线表示 2)实体上方的箭头指出了所有必须的依赖,也就是说,基于主码的所有依赖.—这里是联合主键. 3)实体下方的箭头指出了相对不重要的一些依赖.存在两种 ●部分依赖;若确定项目名称,只要知道项目号就可以了.也就是说项目名称只依赖于主码的一部分. ●传递依赖;每小时报酬是依赖于工作类型的.每小时报酬和工作类型都不是码组成的部分,故而我们把这种情况称为传递依赖. 根据图3所示的依赖时,注意这些依赖也可以写成下面的形式: 项目号,员工号?项目名称,员工名称,工作类型,每小时报酬 项目号?项目名称 员工号?员工名称,工作类型,每小时报酬 工作类型?每小时报酬 前三个范式的实例—第一范式2 注意:虽然有时为了提高性能需要使用部分依赖,但是对它们的使用要谨慎.是因为包含部分依赖的表仍然有数据冗余,因此将导致各种异常. 前三个范式的实例—第二范式1 由于上述关系,我们可以将数据库转换为第二范式(2FN)来改进关系数据库设计. 具体转换如下: 1)将每个码的组成写在单独的行中,然后将原来的(复合)码写在最后一行: 项目号 员工号 项目号 员工号 每个组成部分都成为表中的码,换句话说,将初始表分为三个表.描述如下: 项目表(项目号,项目名称) 员工表(员工号,员工名称,工作类型,每小时报酬) 工资表(项目号,员工号,小时数) 操作过程如图4所示: 前三个范式的实例—第二范式2(图4) 前三个范式的实例—第二范式3 注意:一个表属于第二范式应该具有: 1)它属于1FN. 2)它不包含部分依赖,也就是说,没有属性只依赖于主码的一部分. 3)可以存在传递依赖. 前三个范式的实例—第三范式1 我们可以将图4中的传递依赖进行分离,则可以转换为下面4个表: 项目表(项目号,项目名称) 员工表(员工号,员工名称,工作类型) 工资表(项目号,员工号,小时数) 工作类型表(工作类型,每小时报酬)------此处进行Sql Server数据库建库的演示 这样就可以将原来的依赖传递进行消除,就可以形成第三范式. 1)它属于2FN 2)它不包含传递依赖. 一旦消除了表中的部分依赖和传递依赖,我们就可以将注意力集中在改善数据库提供信息和增强关系特性的能力了. 因此我们需要作如下修改: 1)随着职工人数的增加,必须每次往员工表中添加一个新的职工记录,并且都需要输入工作类型的值.不幸的是,这样太容易出现录入错误的情况. –可以增加一个”工作类型code”属性,也就产生了下面的依赖 前三个范式的实例—第三范式2 工作类型Code?工作类型,每小时报酬 2)在”项目表”中增加”员工号”为外码,保证了每一个项目的项目经理的详细信息的能力,这样我们不用生成额外的数据冗余就可以访问每个项目的项目经理的详细信息. 3)虽然”员工号”和”项目号”组合作为主码看起来可以接受,但是使用一个”交易代码code”可能会更加准确,并且具有灵活性. 例如:某一个职工在同一个项目里,”工资表”中有两个工作时间,就会破坏了实体完整性要求. 根据上述的问题,我们对数据表进行修改后如下所示: 项目表(项目号,项目名称,员工号) 工作类型表(工作类型Code,工作类型,每小时报酬) 员工表(员工号,员工名称,工作类型Code) 工资表(交易代码Code,项目号,员工号,小时数) 2806 23 122 项目经理