第11章数据库设计剖析.ppt

第11章 数据库设计 ?数据库设计也和其他工程设计一样，具有三个特征: ?反复性。数据库设计不可能“一气呵成”，需要反复推敲和修改才能完成。 ?试探性。设计过程往往是一个试探的过程。在设计过程中，有各式各样的要求和制约因素，它们之间往往是矛盾的。 ?分步进行。数据库设计常常由不同的人员分阶段进行。这样做，一是由于技术上分工的需要；二是为了分段把关，逐级审查，保证设计的质量和进度。 ?设计方法 ?集中式模式设计法 首先将需求说明综合成一个一致的、统一的需求说明，然后，在此基础上设计一个单位的全局数据模式，再根据全局数据模式为各个用户组或应用定义外模式。 这种方法强调统一，对各用户组和应用可能照顾不够，一般用于小的、不太复杂的单位。 ?视图集成法 视图集成法以各部分的需求说明为基础，按照统一的要求和规范，分别设计各自的局部模式。这些局部模式实际上相当于各部分的视图，然后再以这些视图为基础，集成为一个全局模式。 视图集成法比较适合于大型数据库的设计，可以多组并行进行，可以免除综合需求说明的麻烦。目前，视图集成法用得较多。 某保险公司雇佣多名业务员开展保险业务。一名业务员可以为多名客户服务；一个客户也可以通过多个业务员购买多种保险；每个客户在每次购买保险时通过一个业务员与保险公司签订合同。图中显示一张经过简化的该保险公司的个人保险投保合同书，请根据这张合同书所提供的信息设计数据库，对保险业务合同数据进行管理。 ?保险业务管理的处理需求有： ?查询所有已签的个人保险投保合同情况 ?查询能够保险的所有项目 ?查询所有投保人情况 ?查询所有被保险人情况 ?查询业务员情况 … 各方案比较： 如：要得到一个实体的全部属性。 方案一须作一次连接操作，即R?Ri; 方案二虽不需做连接操作，但只适用于不相交和全特殊化情况。 如果子实体集相交，则一个实体可能属于多个子实体集，而它从C继承的属性在多个关系中存储，这种冗余导致修改异常； 如果不是全特殊化，则有些实体将因不属于任何子实体集而丢失。 方案三和方案四只有一个关系，但可能存在很多NULL。如果Si的特殊属性不多，方案可取。 ?范畴的转换 转换后的关系： R1（单位名，负责人，地址，车主标识） R2（身份证号码，住址，姓名，车主标识） R3（车主标识，牌照号码，购买日期） 数据库逻辑设计的结果不是惟一的。利用映射规则初步得到一组关系模式集后，还应该适当地修改、调整关系模式的结构，以进一步提高数据库应用系统的性能。 ?节省存储空间的一些考虑 ?尽可能缩小每个属性所占空间 ?采用假属性减少重复数据所占存储空间 ? 外模式的设计 外模式也称子模式或用户模式，是与应用程序对应的数据库视图，是数据库的一个子集，也是局部逻辑数据模式。 【例】 不同类型实体 11.3.1 E-R图到关系模式的转换 替身键 范畴 11.3.2 逻辑模式的规范化、调整 ?逻辑模式的规范化（优化）： （1）确定函数依赖 根据需求分析阶段所得到的数据的语义，分别写出每个关系模式内部各属性之间的函数依赖。 11.3.2 逻辑模式的规范化、调整 6.2 关系模式的优化 （2）对于各个关系模式之间的函数依赖进行最小化处理，消除冗余的联系。 11.3.2 逻辑模式的规范化、调整 6.2 关系模式的优化 （3）根据规范化理论对关系模式逐一进行分析，分析是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。 11.3.2 逻辑模式的规范化、调整 6.2 关系模式的优化 （4）根据需求分析阶段得到的各种应用对数据处理的要求，分析所在的应用环境中这些关系模式是否合适，确定是否要对它们进行合并或分解。 11.3.2 逻辑模式的规范化、调整 6.2 关系模式的优化 （5）对关系模式进行必要的分解，以提高数据操作的效率和存储空间的利用率。 11.3.2 逻辑模式的规范化、调整 6.2 关系模式的优化 【例】 假设有一个产品关系模式，其中包含有出口产品和内销产品两类数据。由于不同的应用关心不同的产品。因此，可将产品关系模式进行水平分解，分解为两个关系模式，一个存放出口产品数据，另一个存放内销产品数据，如图所示。这样可以减少应用存取的元组数。 11.3.2 逻辑模式的规范化、调整 6.2 关系模式的优化 【例】 假设有一个职工关系模式，其中含有职工号、职工名、性别、职务、职称、年龄、地址、邮编、电话、所在部门等描述属性。如