#第2章 数据库设计和ER模型 #目录 #2.1 数据库系统生存期
2.1.1 规划阶段
2.1.2 需求分析阶段
2.1.3 概念设计阶段
2.1.4 逻辑设计阶段
2.1.5 物理设计阶段
2.1.6 数据库的实现
2.1.7 数据库的运行与维护
#2.2 ER模型的基本概念
2.2.1 ER模型的元素
2.2.2 属性的分类
2.2.3 联系的设计
2.2.4 ER模型的操作
2.2.5 采用ER模型的数据库概念设计步骤
#2.3 关系模型的基本概念
2.3.1 关系模型的基本术语
2.3.2 关系的定义和性质
2.3.3 三类完整性规则
#2.4 ER模型到关系模型的转换
2.4.1 ER图转换成关系模式集的算法
2.4.2 采用ER模型的逻辑设计步骤
#2.5 ER模型实例分析
2.5.1 库存管理信息系统的ER模型及转换
2.5.2 人事管理信息系统的ER模型
2.5.1 住院管理信息系统的ER模型
2.5.1 公司车队信息系统的ER模型
#2.6 增强的ER模型
2.6.1 弱实体与强实体
2.6.2 子类实体与超类实体
#小结
- 本章介绍数据库设计的全过程,重点介绍数据库结构的概念设计和逻辑设计。
- 概念设计是设计能反映用户需求的数据库概念结构,即概念模型。概念设计使用的方法主要是ER方法。依据ER方法设计ER模型,画ER图。ER模型要得到用户的认可才能最终确定下来。
- ER模型是人们客观认识世界的一种方法、工具。ER模型具有客观性和主观性两重含义。ER模型是在客观事物或系统的基础上形成的,在某种程序上反映了客观现实,反映了用户需求,因此ER模型具有客观性。但ER模型以不等同于客观事物本身,它往往反映事物的某一方面,至于选取哪个方面或哪些属性,如何表达则取决于观察者本身的目的与状态,从这个意义上来说,ER模型以具有主观性。
- 具体设计时,有时”实体“、”联系“、”属性“三者之间的界线是模糊的。数据库设计者的任务就是把现实世界中的数据以及数据间的联系抽象出来,分别用”实体“、”联系“、”属性“三者来表示。
- 逻辑设计的主要任务是把ER模型转换成关系模型。这个转换具有固定的转换规则。
- 本章举了四个大的ER模型实例,供读者参考、拓宽思路,以利于今后的数据库设计工作。
- 本章最后介绍了EER模型,涉及到弱实体、子类实体、超类实体等内容。这些内容有助于深化ER模型。
#习题 2.1 名词解释
- 数据库工程
以数据库为基础的信息系统通常称为数据库应用系统,它一般具有信息采集、组织、加工、抽取、综合和传播等功能。数据库应用系统的开发是一项软件工程,但又有自己特有的特点,所以特称为“数据库工程”。 - 数据库系统生存期
仿照软件生存期,可以得到数据库系统生存期概念。
我们把数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个时间,称为数据库系统生存期。 - 实体
(Entity)是一个数据对象,指应用中可以区别的客观存在的事物。 - 实体集
(Entity Set)是指同一类实体构成的集合。 - 实体类型
(Entity Type)是对实体集中实体的定义。 - 实体标识符
在一个实体中,能够惟一标识实体的属性或属性集称为“实体标识符”。
一个实体只有一标识符,没有候选标识符的概念。实体标识符有时也称为实体的主键。 - 联系
(Relationship)表示一个或多个实体之间的关联关系。 - 联系集
(Relationship Set)是指同一类联系构成的集合。 - 联系类型
(Relationship Type)是对联系集中联系的定义。 - 属性
实体的某一特性称为属性(Attribute)。 - 简单属性
简单属性是不可分割的属性。 - 复合属性
复合属性是可再分解为其他属性的属性(即属性可嵌套)。复合属性形成了一个属性的层次结构。 - 单值属性
指的是同一实体的属性只能取一个值。(同一个学生只能具有一个年龄) - 多值属性
指同一实体的属性可能取多个值。(一个人的学位(学士、硕士、硕士)) - 存储属性
需要存储值的属性称为存储属性(Stored Attribute)。 - 派生属性
有时候,两个(或两个以上)属性值是相关的。此时可从其他属性值推导出值的属性,称为派生属性(Derived Attribute)。派生属性的值不必存储在数据库内。(如职工实体中,实发工资可从基本工资、奖金、房租等属性推导出来。) - 联系
(Relationship)表示一个或多个实体之间的关联关系。 - 联系元数
一个联系涉及到的实体集个数,称为该联系的元数或度数(Degree)。 - 映射基数
实体集E1和E2之间有二元联系,则参与一个联系中的实体数目称为映射基数。
对于二元联系类型,可能的映射基数有1:1、1:N、M:N、M:1。 - 完全参与
如果实体集E中每个实体都参与联系集R的至少一个联系中,我们称实体集E“完全参与”联系集R。 - 部分参与
如果实体集E中只有部分实体参与联系集R的联系中,我们称实体集E“部分参与”联系集R。 - 关系模型
用二维表格表示实体集,用关键码表示实体之间联系的数据模型称为关系模型(Relational Model)。 - 关系模式
在关系模型中,记录类型称为关系模式。 - 关系实例
元组的集合称为关系(Relation)或实例(Instance)。 - 属性
在关系模型中,字段称为属性,字段值称为属性值。 - 域
关系中的每个属性都有一个取值范围,称为属性的值域(Domain)。每一个属性对应一个值域,不同的属性可以对应于同一值域。 - 元组
在关系模型中,记录称为元组(Tuple)。 - 超键 (Super Key),在关系中惟一标识元组的属性集称为关系模式的超键。
- 候选键 (Candidate Key),不含有多余属性的超键称为候选键。也就是在候选键中,若再删除属性,就不是键了。
- 主键
(Primary Key),用户选做元组标识的候选键称为主键。 - 外键
(Foreign Key),如果模式R中属性K是其他模式的主键,那么K在模式R中称为外键。 - 实体完整性规则
(Entity Integrity Rule),这条规则要求关系中元组在组成主键的属性上不能有空值。如果有空值,那么主键值就起不了惟一标识元组的作用。 - 参照完整性规则
(Reference Integrity Rule),如果属性集K是关系模式R1的主键,K也是关系模式R2的外键,那么在R2的关系中,K的取值只允许两种可能,或者为空值,或者等于R1关系中的某个主键值。 - 弱实体
一个实体对于另一个实体(称为强实体)具有很强的依赖关系,而且该实体主键的一部分或全部从其强实体中获得,则称该实体为弱实体。 - 子类实体
当较低层上实体类型表达了与之联系的较高层上的实体类型的特殊情况时,就称较高层上实体类型为超类型(Supertype),较低层上实体类型为子类型(Subtype)。 - 超类实体
当较低层上实体类型表达了与之联系的较高层上的实体类型的特殊情况时,就称较高层上实体类型为超类型(Supertype),较低层上实体类型为子类型(Subtype)。
2.2 数据库设计的规划阶段应做哪些事情?
- (1)系统调查。对应用单位作全面的调查。发现其存在的主要问题,并画出组织层次图,以了解企业的组织结构。
- (2)可行性分析。从技术、经济、效益、法律等诸方面对建立数据库的可行性进行分析;然后写出可行性分析报告;组织专家进行讨论其可行性。
- (3)确定数据库系统的总目标,并对应用单位的工作流程进行优化和制订项目开发计划。在得到决策部门的批准后,就正式进入数据库系统的开发工作。
2.3 数据库设计的需求分析阶段主要由哪四步组成?
- (1)分析用户活动,产生业务流程图
- (2)确定系统范围,产生系统关联图
- (3)分析用户活动涉及的数据,产生数据流图
- (4)分析系统数据,产生数据字典
2.4 在数据库中,为什么要有概念设计这一阶段?
在早期的数据库设计中,概念设计并不是一个独立的设计阶段,当时的设计方式是需求分析之后,直接把用户信息需求得到的数据存储格式转换成DBMS能处理的逻辑模型。这样,注意力往往被牵扯更多的细节限制方面,而不能集中在最重要的信息组织结构和处理模型上。因此在设计依赖于具体DBMS的逻辑模型后,当外界环境发生变化时,设计结果就难以适应这个变化。
为了改善这种状况,在需求分析和逻辑设计之间增加了概念设计阶段。此时,设计人员仅从用户角度看待数据及处理需求和约束,尔后产生一个反映用户观点的概念模型(也称为“组织模型”)。将概念设计从设计过程中独立开来,可以使数据库设计各阶段的任务相对单一化,得以有效控制设计的复杂程度,便于组织管理。概念模型能充分反映现实世界中实体间的联系,又是各种基本数据模型的共同基础,同时也容易向现在普遍使用的关系模型转换。
详见P31
2.5 试述概念设计的主要步骤。
概念设计的任务一般可分为三步来完成:
- (1)进行数据抽象,设计局部概念模型
- (2)将局部概念模型综合成全局概念模型
- (3)评审 详见P31
2.6 逻辑设计的目的是什么?试述逻辑设计阶段的主要步骤及内容。
逻辑设计的目的是把概念设计阶段设计好的概念模型转换成与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构(包括数据库逻辑模型和外模型)。这些模型在功能上、完整性和一致性约束及数据库的可扩充性等方面均就满足 用户的各种要求。
逻辑设计主要是把概念模型转换成DBMS能处理的逻辑模型。转换过程中要对模型进行评价和性能测试,以便获得较好的模式设计。逻辑设计的主要步骤有五步。
- (1)把概念模型转换成逻辑模型
- (2)设计外模型
- (3)设计应用程序与数据库的接口
- (4)评价模型
- (5)修正模型
2.7 什么是数据库的物理设计?试述其具体步骤。
对于给定的基本数据模型选取一个最适合应用环境的物理结构的过程,称为物理设计。 物理设计可分五步完成,前三步涉及到物理结构设计,后两步涉及到约束和具体的程序设计。
- (1)存储记录结构设计:包括记录的组成、数据项的类型、长度,以及逻辑记录到存储记录的映射
- (2)确定数据存放位置:可以把经常同时被访问的数据组合在一起
- (3)存取方法的设计:存取路径分为主存取路径与辅存取路径,前者用于主键检索,后者用于辅助键检索。
- (4)完整性和安全性考虑:设计者应在完整性、安全性、有效性和效率方面进行分析,做出权衡。
- (5)程序设计:在逻辑数据库结构确定后,应用程序设计就应当随之开始。
2.8 数据库实现阶段主要做哪几件事情?
- (1)定义数据结构
- (2)数据装载
- (3)编制与调试应用程序
- (4)数据库试运行
2.9 数据库系统投入运行后,有哪些维护工作?
- (1)数据库的转储和恢复
- (2)数据库安全性、完整性控制
- (3)数据库性能的监督、分析和改进
- (4)数据库的重组织和重构造
2.10 在概念设计中,如何把多值属性变换成系统容易实现的形式?
对多值属性进行变换,通常有下列两种变换方法。
- (1)将原来的多值属性用几个新的单值属性来表示。
- (2)将原来的多值属性用一个新的实体类型表示。这个新实体类型和原来的实体类型之间1:N联系。这个新实体依赖于原实体而存在,我们称之为弱实体。
2.11 对联系类型有哪两种约束?试详细解释之。
有两类联系约束:基数约束和参与约束。
- (1)基数约束:实体集E1和E2之间有二元联系,则参与一个联系中的实体数目称为映射基数。 对于二元联系类型,可能的映射基数有1:1、1:N、M:N、M:1。
- (2)参与约束:如果实体集E中的每个实体与联系集R的至少一个联系中,我们称实体集E“完全参与”联系集R。如果实体集E中只有部分实体参与联系集R的联系中,我们称实体集E“部分参与”联系集R。
2.12 采用ER模型的数据库概念设计有哪些主要的步骤?
- (1)设计局部ER模型:1.1 确定局部结构范围 1.2 定义实体 1.3 定义联系 1.4 分配属性
- (2)设计全局ER模型:2.1 确定公共实体类型 2.2 合并局部ER模型 2.3 消除冲突
- (3)全局ER模型的优化:3.1 合并实体类型 3.2 消除冗余属性 3.3 消除冗余联系
2.13 在关系模型中,关系具有哪些性质?
关系是一种规范化了的二维表格。在关系模型中,对关系作了下列规范性限制:
- (1)关系中每一个属性值都是不可分解的
- (2)关系中不允许出现重复元组(即不允许出现相同的元组)
- (3)由于关系是一个集合,因此不考虑元组间的顺序,即没有行序
- (4)元组中的属性在理论上也是无序的,但使用时按习惯考虑列的顺序
2.14 为什么关系中的元组没有先后顺序?且不允许有重复元组?
由于关系是一个集合,因此不考虑元组间的顺序,即没有行序,同时不允许有重复元组。
2.15 参照完整性规则使用时,有哪些变通?试举例说明。
这条规则的实质是“不允许引用不存在的实体”。这条规则在具体实体时,有三点变通:
- (1)外键和相应的主键可以不同名,只要定义在相同的值域上即可
- (2)R1和R2也可以是同一个关系模式,此时表示了同一个关系中不同元组之间的联系
- (3)外键值是否允许为空,就视具体问题而定。