第11章数据库设计剖析

《第11章数据库设计剖析》由会员分享，可在线阅读，更多相关《第11章数据库设计剖析（133页珍藏版）》请在金锄头文库上搜索。

1、1,第11章 数据库设计,2,数据库设计过程：,需求分析概念设计逻辑设计物理设计,11.1 数据库的设计引论,3,数据库设计的基本任务： 根据一个单位的信息需求、处理需求和数据库的支撑环境（包括DBMS、操作系统、网络和硬件），设计出数据模式（包括外模式、逻辑（概念）模式和内模式）以及典型的应用程序。,11.1 数据库的设计引论,4,数据库设计方法： 以信息需求为主，兼顾处理需求，这种方法称为面向数据的设计方法； 以处理需求为主，兼顾信息需求，这种方法称为面向过程的设计方法。,11.1 数据库的设计引论,5,数据库设计也和其他工程设计一样，具有三个特征: 反复性。数据库设计不可能“一气呵成”，

2、需要反复推敲和修改才能完成。 试探性。设计过程往往是一个试探的过程。在设计过程中，有各式各样的要求和制约因素，它们之间往往是矛盾的。 分步进行。数据库设计常常由不同的人员分阶段进行。这样做，一是由于技术上分工的需要；二是为了分段把关，逐级审查，保证设计的质量和进度。,11.1 数据库的设计引论,6,11.2 数据库概念设计,E-R模型能够描述现实世界，表达一定的语义信息且与技术实现无关。 因此， E-R是设计人员、编程人员以及最终用户之间进行交流的数据模型。,11.2.1 数据库概念设计的基本方法,选择适当的数据模型,基本任务：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概

3、念数据模型。,7,设计方法 集中式模式设计法 首先将需求说明综合成一个一致的、统一的需求说明，然后，在此基础上设计一个单位的全局数据模式，再根据全局数据模式为各个用户组或应用定义外模式。 这种方法强调统一，对各用户组和应用可能照顾不够，一般用于小的、不太复杂的单位。,11.2.1 数据库概念设计的基本方法,8,视图集成法 视图集成法以各部分的需求说明为基础，按照统一的要求和规范，分别设计各自的局部模式。这些局部模式实际上相当于各部分的视图，然后再以这些视图为基础，集成为一个全局模式。 视图集成法比较适合于大型数据库的设计，可以多组并行进行，可以免除综合需求说明的麻烦。目前，视图集成法用得较多。

4、,11.2.1 数据库概念设计的基本方法,9,数据库概念设计的步骤： 局部视图设计、视图集成 。,11.2.1 数据库概念设计的基本方法,10,11.2.2 视图设计,步骤：1.确定范围； 2.确定实体及实体的主键； 3.定义实体间的联系； 4.给实体及联系加上描述属性。,局部视图的设计从划分用户组开始，然后对每一个用户组建立一个局部视图。该视图是由实体、实体间联系、实体的属性以及实体的主键组成。,11,某保险公司雇佣多名业务员开展保险业务。一名业务员可以为多名客户服务；一个客户也可以通过多个业务员购买多种保险；每个客户在每次购买保险时通过一个业务员与保险公司签订合同。图中显示一张经过简化的该

5、保险公司的个人保险投保合同书，请根据这张合同书所提供的信息设计数据库，对保险业务合同数据进行管理。,【实例】保险业务管理,11.2.2 视图设计,12,【实例】保险业务管理,13, 需求分析,【实例】保险业务管理,保险合同业务数据流图,14,保险业务管理涉及到的数据有： 合同数据 保险数据 投保人数据 被保险人数据 业务员数据,【实例】保险业务管理,15,保险业务管理的处理需求有： 查询所有已签的个人保险投保合同情况 查询能够保险的所有项目 查询所有投保人情况 查询所有被保险人情况 查询业务员情况 ,【实例】保险业务管理,16,一、局部视图设计 1.确定局部视图的设计范围 略。 2.确定实体及

6、实体的主键 该保险业务涉及到的实体有： 个人保险投保合同书，存放保险公司与投保人签订的所有个人保险投保合同。主键：保险合同号 投保人，存放所有投保人的信息。主键：投保人号 被保险人，存放所有被保险人的信息。主键：被保险人号 业务员，存放所有业务员的基本信息。主键：业务员工号 保险，存放所有能够提供的保险内容。主键：保险号, 概念设计,【实例】保险业务管理,17,定义联系 识别联系的元数（单元、二元、多元）。 识别联系的类型（一对一、一对多、多对多） 确定实体在联系中的参与度（用m : n 表示),3 .定义实体间的联系,11.2.2 视图设计,18, 二元联系 1）1:1,a.两个实体都是强制

7、性的。,11.2.2 视图设计,假定： 每一教师教一门课；每一课程由一个教师讲; 每一教师必须讲课；每一课程必须有教师讲。 那么， 上述联系是1 对 1 即11，且都是强制性的。,19,11.2.2 视图设计,两个实体都是强制性参与的11联系,1,1,20,11.2.2 视图设计,21,b.其中只有一个实体是强制的,假定： 每一教师教一门课；每一课程由一个教师讲； 每一教师必须讲课； 但，每一课程并不都必须有教师讲。,11.2.2 视图设计,22,11.2.2 视图设计,一个实体是强制性参与的11联系,1,1,见后页例子,23,11.2.2 视图设计,此时，如果将二实体组成一张表，则必将造 成

8、表中许多教师栏为空，因此，可建二张表：,24,11.2.2 视图设计,25,所有被教的课程,所有开设的课程,11.2.2 视图设计,26,2）1:N 联系,假定：一个教师可指导多名研究生； 而每一名研究生只能由一位教师指导。 这种联系便是一对多联系（1:N）。 这里，我们只关心多端情况。,11.2.2 视图设计,27, 多端的实例是强制性的,假定：每个研究生必须归在某个教师名下。,11.2.2 视图设计,28,11.2.2 视图设计,多端实体是强制参与的1N联系,1,N,29,11.2.2 视图设计,30, 多端的实例是非强制性的,11.2.2 视图设计,多端实体是非强制参与的1N联系,1,N

9、,研究生可以没有导师。,31,11.2.2 视图设计,研究生,教师,32,有导师的研究生,11.2.2 视图设计,由于空值的存在，另建一个关系较好。,所有研究生,33,3) M:N 联系,假定：一位教师可指导多名研究生，且一名研究生可由多个教师指导。,11.2.2 视图设计,教师实体和研究生实体间的M N联系,M,N,34,教师信息,研究生信息,教师指导研究生的信息,11.2.2 视图设计,35,4) 自联系(一元联系、递归联系),自联系也是一种二元联系，不过，这种 联系发生在同一实体类的不同实体之间。,11.2.2 视图设计,36,11.2.2 视图设计,职工信息,37,4. 给实体及联系加

10、属性（非标识属性）,11.2.2 视图设计,成绩作为选课联系的属性,M,N,38,【实例】保险业务管理(续） 如果一份合同只能购买一种保险，而每种保险可以被不同的合同购买。则保险实体和合同实体之间是一对多联系。,1,N,39,每个客户只和一名业务员签订保险合同，而一名业务员可以为多名客户服务，也就是可以签订多份保险合同；则业务员实体和合同实体之间是一对多联系。,1,N,【实例】保险业务管理,40,每份合同只有一个投保人，而每个投保人可以购买多种保险，即可签订多份保险合同。则投保人实体和合同实体之间是一对多联系。,1,N,1,【实例】保险业务管理,41,被投保人是依赖于投保人的，因此，被保险人是

11、一个弱实体。如果投保人只能为一个被保险人购买保险，而每个被保险人只能有一个投保人。则投保人实体和被投保人之间是一对一联系。,1,N,1,1,【实例】保险业务管理,42,（4）给实体及联系加上描述属性 根据个人保险投保合同书的内容，我们可以确定每个实体的描述属性。如果需要，可以在实体中增加一定的描述属性。 合同实体的描述属性有：（合同基本内容） 保险合同号，投保人号，被保险人号，业务员工号，保险号，日期，收款收据号。 保险实体的描述属性有：（要约内容） 保险号，保险名称，保险金额，保险期限，交费期限，交费方式，标准保险费。,【实例】保险业务管理,43,业务员的描述属性有： 业务员工号，业务员姓名

12、，电话号码，负责险种。 投保人实体的描述属性有： 投保人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email。 被投保人实体的描述属性有： 投保人号，被保险人号，姓名，性别，出生日期，证件名称，证件号码，通信地址，联系电话，地址，邮编，Email。,【实例】保险业务管理,44, 扩充E-R模型（EER模型）,11.2.2 视图设计,识别完所有的实体和实体的主键，有时还需再对实体进行归类，把具有共性的实体归为一类。,实体的分类表示,例：,45,超类:是一个实体，包含所有在实体中出现的公共属性和关系。,子类:是一个实体，有一个区分的角色，并且包含在(超类)实体中

13、出现的部分具体属性和关系。,11.2.2 视图设计,46,利用超类和子类可以避免在一个实体中用不同的属性来描述实体。 假设, 本科生的特殊属性:选修/必修 硕士生的特殊属性:学位，导师 如果把学生的所有属性放在一个实体中, 则在特殊属性上就会产生空值。这是我们不希望的。,11.2.2 视图设计,47,子类继承超类的所有属性.,优点: 避免多次描述相同的属性.可读性更强.,11.2.2 视图设计,学生的超类/子类关系,48,子类可以有多个超类，这种子类称为共享子类。继承属于多重继承。 例如，在职研究生，既是教师的子类，又是研究生的子类。,11.2.2 视图设计,共享子类的表示,49,11.2.2

14、 视图集成,视图集成的意义,50,11.2.2 视图集成,本科生选课视图,视图集成举例:,51,11.2.2 视图集成,研究生选课视图,52,上例存在命名冲突问题：在两个视图中，学生课程的含义不同。,上图指大学生和本科生课程， 下图指研究生和研究生课程。,所以，这属于同名异义。 另外，在本科生选课视图中，学生实体有“何时 入学”属性，而研究生选课视图中有“入学时间”属性，这属于同义异名。,11.2.2 视图集成,53,11.2.2 视图集成,集成后的视图：,54,值域冲突、约束冲突,集成的策略：,11.2.2 视图集成,阶梯式,平衡式,55,平衡式：通常，先选一个初始集成序列，即选两个关系最密

15、切的视图作为初始集成序列，合并后，希望对象数越少越好。,优点：分析比较次数可望最少。,11.2.2 视图集成,56, 阶梯式：不考虑视图的初始序列。所以不能保证X值最大。,适合与已存在的局部集成模式进行综合。,11.2.2 视图集成,57, 一次 n 元集成： 一次集成 n 元视图。,11.2.2 视图集成,58,多次 n 元集成：,11.2.2 视图集成,59,既具有平衡式二元集成效率高的优点， 又具有较少的总的集成次数。, 缺点：,集成的复杂度最大。,多次 n 元集成优点：,11.2.2 视图集成,60, 集成的步骤 ：,2.集成,形成全局视图，因此应满足以下要求：,语义上完整、结构上正确

16、、简明、易理解。,1.揭示同义异名及同名异义问题 2.定义数据对象类的值域 3.说明等价对象类之间的映射,1.预集成,11.2.2 视图集成,61,保险业务管理集成E-R图,1,N,1,N,1,1,N,1,【实例】保险业务管理,62,任务： 由E-R图通过映射得到一组初始关系模式 利用规范化方法检查关系模式的合理性 验证数据库的结构是否满足用户的信息需求 根据应用的需要和系统的要求再对关系模式作适当调整。,11.3 数据库的逻辑设计,63,映射的基本思想: 将E-R图中 每一个实体映射为一个关系； 联系也可以单独映射为一个关系； 每一个属性映射为关系的属性或联系的属性。,11.3.1 E-R图到关系模式的转换,64,映射中可能出现的问题: 命名问题(映射后关系的命名可以与原名相同,也可以不同)