数据库应用系统3_6.pptVIP

数据库应用系统需求分析与规划 第三章数据库应用系统的总体设计 §1 总体设计目标和任务 §2总体设计的过程 §3模块化 §4从数据流程图导出结构图 §5数据库概念结构设计 §6数据库逻辑结构设计 §7数据库设计的其它因素 §8总体设计阶段文档 §6数据库逻辑结构设计 6.1不同数据模型中的逻辑模式 6.2 E-R图向数据模型的转换 6.3规范化理论 6.4规范化理论的应用 6.1不同数据模型中的逻辑模式 概念设计是独立于DBMS的，而逻辑设计与DBMS有关，受到DBMS所支持的数据模型的约束。因此，逻辑设计的过程可以理解为：根据数据库的概念结构和数据库管理系统特征导出数据库的逻辑结构。简单地说，就是把概念结构转换为某个DBMS所支持的数据模型上的结构表示，我们把它称为逻辑模式。DBMS所支持的数据模型，最流行的是三种：层次数据模型，网状数据模型和关系数据模型。本书只考虑关系数据模型。 关系数据库的逻辑结构 关系数据库的逻辑结构由一组关系模式构成。每个关系模式可表示为RU，F形式，其中R是关系名，U是属性的集合，F是数据依赖的集合。有时也可以只列出关系名和该关系包含的所有的属性名。 关系数据模型 6.2 E-R图向数据模型的转换 逻辑设计过程就是把概念结构转换为逻辑结构的过程。现在，我们是用E－R图来表示概念结构的；而逻辑结构在不同的DBMS中表示形式不同，因此，所谓转换工作，就是把表示概念结构的E－R图转换为层次模型的逻辑结构或网状模型的逻辑结构或关系模型的逻辑结构。这三种转换工作可以按一定规则进行得到相应的逻辑结构，然后再针对具体的DBMS作适当的修改。本书只讨论将概念结构转换为关系模式的转换规则。 从E－R图转换为关系模式 关系模型的逻辑结构即为一组关系模式。因而从概念结构到关系模型逻辑结构的转换，就是从E－R图转换为关系模式。实体和属性的转换比较容易，一个实体对应一个关系模式。实体的属性就是关系的属性。下面着重讨论联系的转换。 1、两个实体型之间联系的转换 2、一个实体型内联系的转换 3、多元联系和多重联系的转换 1、两个实体型之间联系的转换 l：n联系的情况 1：1联系的情况 n： m联系的情况 l：n联系的情况 对于l：n联系的情况。例如：旅客与帐单之间存在着l：n联系。在转换时，只要在“帐单”关系中，增加一个(组)属性项就能反映这1：n联系，该属性项是“旅客”关系的码属性，例如，身份证号。这样，“帐单”关系模式可表示成如下形式：帐单(帐单号，身份证号，日期，品名，单价，数量，金额)。 1：1联系的情况 对于1：1联系的情况．例如“部门经理”与“部门”存在着1：1联系，转换时，只要在“部门经理”的关系中增加“部门”关系的码作为属性项；而在“部门”的关系中增加“部门经理”关系的码作为属性项。这样，这两个关系模式可以有如下形式： 部门经理(部门经理号，部门号，部门经理名，…) 部门(部门号，部门经理号，部门名，…) 第二种的转换方案 可以有另外的转换方案：只在一个关系中增加另一关系的码作为属性，这样，这两个关系模式可以有如下形式： 部门经理(部门经理号，部门号，部门经理名，…) 部门(部门号，部门名，…) 或 部门经理(部门经理号，部门经理名，…) 部门(部门号，部门经理号，部门名，…) 第三种的转换方案 还可以有别的转换方案：引进一个新的关系模式，例如称为GT，它只包含两个属性项：“部门经理号”和“部门号”。这样，有关系模式如下： 部门经理(部门经理，部门经理名，…) 部门(部门号，部门名，…) GT(部门经理号，部门号) 可以看出，转换方案不同，性能会有所区别。 n： m联系的情况 对n： m联系的情况。例如，“旅客”与“小吧商品”之间存在着n： m联系，转换时，引入新的关系“消费”。这样，转换后所得到的关系模式如下： 旅客(身份证号，旅客姓名，…) 小吧商品(商品号，商品名，…) 消费(身份证号，商品号，时间，数量，…) 2、一个实体型内联系的转换 1：n联系的情况 n：m联系的情况 1：1联系的情况 1：n联系的情况 对于1：n联系的情况。例如，在“职工”内部存在着1：n的领导与被领导的联系，职工中的部门经理领导部门内的职工。这样，在转换时，只要在“职工”关系中增加一个属性项“上级职工