第11章-数据库设计应用.ppt

* 保险业务管理 业务员（业务员工号，业务员姓名，电话号码） 主键：业务员工号。 函数依赖集F： 业务员工号?{业务员姓名，电话号码}。 关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以业务员关系满足第3范式。 * 保险业务管理 保险（保险号，保险名称，保险金额，保险期限，交费期限，交费方式，标准保险费） 主键：保险号 函数依赖集F： 保险号?{保险名称，保险金额，保险期限，交费期限，交费方式，标准保险费}。 关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以保险关系满足第3范式。 * 保险业务管理 合同（保险合同号，投保人号，被保险人号，业务员工号，保险号，日期，收款收据号） 主键：保险合同号。 外键：投保人号，引用了投保人关系中的投保人号； 被保险人号，引用了被保险人关系中的被保险人号； 业务员号，引用了业务员关系中的业务员号； 保险号，引用了保险关系中的保险号。 函数依赖集F： 保险合同号?{投保人号，被保险人号，业务员工号，保险号，日期，收款收据号}。 关系中不存在非主属性与候选键之间的部分与传递函数依赖，所以合同关系满足第3范式。 * 保险业务管理 验证查询需求的满足情况： （1）要查询所有已签的个人保险投保合同情况，只需对合同关系进行查询； （2）要查询能够保险的所有项目，只需对保险关系进行查询； （3）要查询所有投保人情况，只需对投保人关系进行查询； （4）要查询所有被保险人情况，只需对被保险人关系进行查询； * 由E-R图映射来的关系模式经过优化以后，基本上可以反映一个单位数据的内在联系，但不一定都适合应用的需要和系统的要求。根据需求分析对关系模式进一步作些调整是必要的。 ? 逻辑模式的调整 11.3.2 逻辑模式的规范化、调整和实现 * ? 减少连接运算 ? 减小关系大小及数据 ? 使用快照 ? 改善数据库性能 11.3.2 逻辑模式的规范化、调整和实现 * ?节省存储空间的一些考虑 ?尽可能缩小每个属性所占空间 ?采用假属性减少重复数据所占存储空间 6.3 关系模式的调整 11.3.2 逻辑模式的规范化、调整和实现 * 6.3 关系模式的调整 11.3.2 逻辑模式的规范化、调整和实现 学号 ... 经济状况类型 ... A A C B ... ... ... ... 学号 ... 经济状况 ... 经济状况类型 经济状况 A ... B ... C ... D ... ... ... * ? 外模式的设计 外模式也称子模式或用户模式，是与应用程序对应的数据库视图，是数据库的一个子集，也是局部逻辑数据模式。 11.3.2 逻辑模式的规范化、调整和实现 * 【例】设有一产品关系模式： 产品（产品号,产品名,规格,单价,生产车间,生产负责人,产品成本,产品合格率,质量等级） 在产品关系模式上为不同的用户建立两个视图。 为一般客户建立视图： 产品1（产品号,产品名,规格,单价） 为产品销售部门建立视图： 产品2（产品号,产品名,规格,单价,车间,生产负责人） 11.3.2 逻辑模式的规范化、调整和实现 * 典型应用分析 * 典型应用分析 该例中, 把一个地址的详细内容作为一个单独的值. 问题:查询某个电话号码是哪个部门的, 不方便. branch表 【例1】分解下列关系, 使其满足1NF. * 典型应用分析 * 典型应用分析 staffNo, branchNo是主键, 所以 {staffNo, branchNo}?branchAddress 而 branchNo?branchAddress 又: staffNo ?{name,position} 存在部分函数依赖,所以tempStaffAllocation不是2NF. 主键为复合主键时, 易遇到不属于2NF的情况. 【例2】分解下列关系,使其满足2NF. * 典型应用分析 对关系进行分解,以消除部分函数依赖: 2NF比1NF减少了许多冗余, 但仍可能存在更新异常 * 典型应用分析 部门经理表(不属于3NF) 主键:branchNo branchNo ? branchAddress branchNo ? telNo branchNo ? mgrStaffNo branchNo ? name (非主属性传递依赖于主键) mgrStaff