第7章数据库设计详解.ppt

数据库的安全性和完整性控制 随着数据库应用环境的变化，对数据库的安全性和完整性要求也会发生变化。 比如，要收回某些用户的权限，或增加、修改某些用户的权限，增加、删除用户，或者某些数据的取值范围发生变化等， 这都需要系统管理员对数据库进行适当的调整，以反映这些新的变化。 监视、分析、调整数据库性能 监视数据库的运行情况，并对检测数据进行分析，找出能够提高性能的可行性，并适当地对数据库进行调整。 目前有些DBMS产品提供了性能检测工具，数据库系统管理员可以利用这些工具很方便地监视数据库。 数据库的重组 数据库经过一段时间的运行后，随着数据的不断添加、删除和修改，会使数据库的存取效率降低， 这时数据库管理员可以改变数据库数据的组织方式，通过增加、删除或调整部分索引等方法，改善系统的性能。 注意数据库的重组并不改变数据库的逻辑结构。 小结 数据库的结构和应用程序设计的好坏只是相对的，它并不能保证数据库应用系统始终处于良好性能。 数据库中的数据随着数据库的使用而发生变化，随着这些变化的不断增加，系统的性能就有可能日趋下降，即使在不出现故障的情况下，也要对数据库进行维护，以便数据库始终能够获得较好的性能。 数据库的维护工作与一台机器的维护工作类似，花的功夫越多，它服务得就越好。 数据库的设计工作并非一劳永逸，一个好的数据库应用系统同样需要精心的维护使其保持良好的性能。 * * 1. E-R模型向关系模型的转换 一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的标识符就是关系的码。 实体间的联系分情况考虑。 联系的转换方法 1:1联系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并 1:n联系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。 m:n联系转换为一个关系模式。 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。 具有相同码的关系模式可以合并。 1:1转换示例 部门（部门号，部门名，经理号） 经理（经理号，经理名，电话） 或者： 部门（部门号，部门名） 经理（经理号，部门号，经理名，电话） 1:n转换示例 部门（部门号，部门名） 职工（职工号，部门号，职工名，工资） m:n转换示例 教师表（教师号，教师名，职称） 课程表（课程号，课程名，学分） 授课表（教师号，课程号，授课时数） * * 营业员（职工号，姓名，出生日期 商品（商品编号，商品名称，单价） 顾客（身份证号，姓名，性别） 销售（职工号，商品编号，身份证号，销售数量，销售时间） 2. 数据模型的优化 关系数据模型的优化通常以规范化理论为指导，并考虑系统的性能。具体方法为： 确定各属性间的数据依赖。 消除冗余的联系。 确定最合适的范式。 确定是否要对某些模式进行分解或合并 。 对关系模式进行必要的分解，以提高数据的操作效率和存储空间的利用率。 水平分解 以时间、空间、类型等范畴属性取值为条件，满足相同条件的数据行为一个子表。 分解的依据一般以范畴属性取值范围划分数据行。这样在操作同表数据时，时空范围相对集中，便于管理。 K# A1 … Am K# A1 … Am K# A1 … Am 垂直分解 以非主属性所描述的应用对象生命历程的先后为条件，对应相同历程的属性为一个子表。 分解的依据是将非主属性按其数据生成的时间段划分，描述相同时间段的属性划分在一个组中。 使操作同表数据时时空范围相对集中，便于管理。 K# A11 …A1m A21 … A2n K# A11 …A1m K# A21 … A2n 3.设计外模式 将概念模型转换为逻辑数据模型之后，还应该根据局部应用需求，并结合具体的数据库管理系统的特点，设计用户的外模式。 外模式概念对应关系数据库的视图概念，设计外模式是为了更好地满足局部用户的需求。 定义数据库的模式主要是从系统的时间效率、空间效率、易维护等角度出发。 定义外模式考虑事项 使用更符合用户习惯的别名。 对不同级别的用户定义不同的视图，以保证数据的安全。 简化用户对系统的使用。 7.3.3 物理结构设计 对已确定的逻辑数据结构，利用DBMS提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置以及存储分配，设计出一个高效的、可实现的物理数据库结构。 数据库的物理设计通常分为两步： 确定数据库的物理结构； 对物理结构进行时间和空间效率的评价。 1.物理结构设计的内容和方法 对于数据查询，需要得到如下信息： 查询所涉及的关系； 查询条件所涉及的属性； 连接条件所涉及的属性； 查询列表中涉及的属性。 对于更新数据的事务，需要得到如下信息: 更新所涉及的关系； 每个关系上的更新条件所涉及的属性； 更新操作所涉