第七章数据库设计.docx
《第七章数据库设计.docx》由会员分享，可在线阅读，更多相关《第七章数据库设计.docx（31页珍藏版）》请在冰豆网上搜索。
第七章数据库设计
第七章数据库设计
7.1数据库设计概述1
7.1.1数据库和信息系统1
7.1.2数据库设计的特点2
7.1.3数据库设计方法简述2
7.1.4数据库设计的基本步骤2
7.2需求分析4
7.2.1需求分析任务4
7.2.2需求分析的方法4
7.2.3数据字典6
7.3概念结构设计7
7.3.1概念结构7
7.3.2概念结构设计的方法和步骤7
7.3.3数据抽象与局部视图设计10
7.3.4视图的集成17
7.4逻辑结构设计22
7.4.1E-R图向关系模型的转换23
7.4.2数据模型的优化24
7.4.3设计用户子模式24
7.5数据库的物理设计25
7.5.1数据库的物理设计的内容和方法25
7.5.2关系模式存取方法选择25
7.5.3确定数据库的存储结构27
7.5.4评价物理结构27
7.6数据库的实施和维护27
7.6.1数据的载入和应用程序的调试27
7.6.2数据库的试运行27
7.6.3数据库的运行和维护28
7.1数据库设计概述
数据库设计:
是指对于一个给定的应用环境，构造最数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。
数据库应用系统:
常常把使用数据库的各类系统统称为数据库应用系统。
7.1.1数据库和信息系统
信息系统:
是提供信息、辅助人们对环境进行控制和进行决策的系统。
数据库:
是信息系统的核心和基础。
它把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
数据库设计人员要求:
数据库的基本知识和数据库设计技术；
计算机科学的基础知识和程序设计的方法和技巧；
软件工程的原理和方法；
应用领域的知识。
其中应用领域的知识随着应用系统所属的领域不同而不同。
数据库设计人员必须深入实际与用户密切结合，对应用环境、专业业务有具体深入的了解才能设计出符合具体领域要求的数据库应用系统。
7.1.2数据库设计的特点
1数据库建设是硬件、软件和技术.管理的结合。
这是数据库设计的特点之一
2数据库设计应该和应用系统设计相结合，也就是说，整个设计过程中要把结构（数据）设计和行为（处理）设计密切结合起来。
这是数据库设计的特点之二。
7.1.3数据库设计方法简述
数据库设计分为四个阶段：
需求分析（分析用户要求）
概念设计（信息分析和定义）
逻辑设计（设计实现）
物理设计（物理数据库设计）
7.1.4数据库设计的基本步骤
按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下六个阶段（如图7.2所示）：
•需求分析；
•概念结构设计；
•逻辑结构设计；
•物理结构设计；
•数据库实施；
•数据库运行和维护。
应用需求
（数据、处理）需求收集和分析需求分析阶段
转换规则设计概念结构概念设
DBMS功能、计阶段
优化方法
设计逻辑结构
逻辑设
计阶段
数据模型优化
应用要求，
DBMS详细
特征
设计物理结构
物理设
计阶段
评价设计，性能预测
不满意
物理实现
数据库
实施阶段
试验性运行
不满意
数据库运行、维护
使用、维护数据库阶段
图7.2数据库设计步骤
1、需求分析阶段
进行数据库设计首先必须准确了解与分析用户需求（包括数据与处理）。
需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。
作为地基的需求分析是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量。
需求分析做得不好，甚至会导致整个数据库设计返工重做。
2、概念结构设计阶段
概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
3、逻辑结构设计阶段
逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。
4、数据库物理设计阶段
数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
5、数据库实施阶段
在数据库实施阶段，设计人员运用DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
6、数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
7.2需求分析
需求分析简单地说就是分析用户的要求。
需求分析是设计数据库的起点，需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
7.2.1需求分析任务
调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下要求：
（1）信息要求。
指用户需要从数据库中获得信息的内容与性质。
由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。
（2）处理要求。
指用户要完成什么处理功能，对处理的响应有什么要求，处理方式是批处理还是联机处理。
（3）安全性与完整性要求。
7.2.2需求分析的方法
1调查用户需求的具体步骤是：
（1）调查组织机构情况。
包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。
（2）调查各部门的业务活动情况。
包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么，这是调查的重点。
（3）在熟悉了业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求，这是调查的又一个重点。
（4）确定新系统的边界。
对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。
由计算机完成的功能就是新系统应该实现的功能。
2调查方法:
（1）跟班作业。
通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准备地理解用户的需求，但比较耗费时间。
（2）开调查会。
通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
（3）请专人介绍。
（1）询问。
对某些调查中的问题，可以找专人询问。
（2）设计调查表请用户填写。
如果调查表设计得合理，这种方法是很有效，也易
于为用户接受。
（6）查阅记录。
查阅与原系统有关的数据记录。
做需求调查时，往往需要同时采用上述多种方法。
但无论使用何种调查方法，都必须有用户的积极参与和配合。
3调查了解了用户的需求以后，还需要进一步分析和表达用户的需求。
在众多的分析方法中结构化分析方法是一种简单实用的方法。
SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方法分析系统。
SA方法把任何一个系统都抽象为如下形式。
给出的只是最高层次抽象的系统概貌，要反映更详细的内容，可将处理功能分解为若干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。
在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图。
数据流图表达了数据和处理过程的关系。
在SA方法中，处理过程的处理逻辑常常借肋判定表或判定树来描述。
系统中的数据则借助数据字典来描述。
7.2.3数据字典
数据字典:
是系统中各类数据描述的集合
数据字典通常包括:
数据项、数据结构、数据流、数据存储和处理过程五个部分。
1数据项
数据项是不可再分的数据单位。
对数据项的描述通常包括以下内容：
数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
其中“取值范围”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件，是设计数据检验功能的依据。
2、数据结构
数据结构反映了数据之间的组合关系。
一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
对数据结构的描述通常包括以下内容：
数据结构描述={数据结构名，含义说明，组成：
{数据项或数据结构}}
3、数据流
数据流是数据结构在系统内传输的路径。
对数据流的描述通常包括以下内容：
数据流描述={数据流名，说明，数据流来源，数据流去向，
组成：
{数据结构}，平均流量，高峰其流量}
其中“数据流来源”是说明该数据流来自哪个过程。
“数据流去向”是说明该数据流将到哪个过程去。
“平均流量”是指在单位时间（每天、每周、每月等）里的传输次数。
“高峰期流量”则是指在高峰时期的数据流量。
4、数据存储
数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。
它可以是手工文档或手工凭单，也可以是计算机文档。
对数据存储的描述通常包括以下内容：
数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，
组成：
{数据结构}，数据量，存取频度，存取方式}
其中“存取频度”指每小时或每天或每周存取几次、每次存取多少数据等信息。
“存取方式”包括是批处理还是联机处理；是检索还是更新；是顺序检索还是随机检索等。
另外，“输入的数据流”要指出其来源，“输出的数据流”要指出其去向。
5、处理过程
处理过程的具体处理逻辑一般用判定表或判定树来描述。
包括以下内容：
处理过程描述={处理过程名，说明，输入：
{数据流}，输出：
{数据流}，
处理：
{简要说明}}
其中“简要说明”中主要说明该处理过程的功能及处理要求。
功能是指该处理过程用来做什么（而不是怎么做），处理要求包括处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。
这些处理要求是后面物理设计的输入及性能评价的标准。
可见，数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。
7.3概念结构设计
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。
它是整个数据库设计的关键。
7.3.1概念结构
概念结构的主要特点是：
（1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。
是对现实世界的一个真实模型。
（2）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。
（3）易于更改，当应用环境和应用要求改变时，容易对要领模型修改和扩充。
（4）易于向关系、网状、层次等各种数据模型转换。
概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。
描述概念模型的有力工具是E-R模型。
7.3.2概念结构设计的方法和步骤
1设计概念结构通常有四类方法：
•自顶向下。
即首先定义全局概念结构的框架，然后逐步细化，如图7.7（a）所示。
需求
全局概念模型
概念模式…概念模式
………
…
概念模式…概念模式 …概念模式概念模式
（a）自顶向下策略
•自底向上。
即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局结构，如图7.7（b）所示。
子需求子需求子需求子需求
概念模式概念模式概念模式概念模式
概念模式…概念模式
…
全局概念模式
（b）自底向上策略
•逐步扩张。
首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐成其他概念结构，直至总体概念结构，如图7.7（c）所示。
核心需求需求
核心概…全局
念结构概念结构
（C）逐步扩张策略
•混合策略。
即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
其中最经常采用的策略是自底向上方法。
即自顶向下地进行需求分析，然后再自底向上地设计概念结构。
如图7.8所示。
需求
需求分析
（自顶向上）需求1……需求n
需求1.1需求1.2需求n.1需求n.2
概念模式概念模式概念模式n.1概念模式n.2
1.11.2
概念结构设计
（自底向上）概念模式1……概念模式n
（应用1）（应用n）
全局概念模式
图7.8自顶向下分析需求与自底向上设计概念结构
这里只介绍自底向上设计概念结构的方法。
它通常分为两步：
第1步是抽象数据并设计局部视图，第2步是集成局部视图，得到全局的概念结构，如图7.9所示。
需求分析DFD
DD
数据抽象、局部
视图的设计分E-R图
返回用户
征求意见
直到满意
为止
视图集成总E-R图
逻辑结构设计
图7.9概念结构设计步骤
7.3.3数据抽象与局部视图设计
1三种抽象
1分类定义某一类概念作为现实世界中一组对象的类型。
2聚集定义某一类型的组成成分
实体型学生
属性学号姓名专业班级
聚集
仓库名
面积
主任
仓库
姓名
年龄
性别
工资
更复杂的聚集
3概括定义类型之间的一种子集联系。
超类学生
“issubsetof”
本科生
本科生
子类
2设计分E-R图具体做法
①选择局部应用
在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点。
让这组图中每一部分对应一个局部应用。
由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据（如图7.14所示）。
某工厂管理信息系统
……
设计分E-R图的出发点
物资管理子系统销售管理子系统人事管理子系统
┇
……
图7.14设计分E-R图的出发点
②逐一设计分E-R图
选择好局部应用之后，就要对每个局部应用逐一设计分E-R图，亦称局部E-R图。
③实体与属性之间并没有形式上可以截然划分的界限，但可以给出两条准则：
（1）作为“属性”，不能再具有需要描述的性质。
“属性”必须是不可分的数据项，不能包含其他属性。
（2）“属性”不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
凡满足上述两条准则的事物，一般均可作为属性对待。
④例子
例如1：
职工是一个实体，职工号、姓名、年龄是职工的属性，职称如果没有与工资、福利挂钩，换句话说，没有需要进一步描述的特性，则根据准则
（1）可以作为职工实体的属性。
但如果不同的职称有不同的工资、住房标准和不同的附加福利，则职称作为一个实体看待就更恰当，如图7.15所示。
职工
职工号姓名年龄职称
职工聘任职称
职工号姓名年龄职工代码工资住房标准附加福利
图7.15职称作为一个实体
例如2在医院中，一个病人只能住在一个病房，病房号可以作为病人实体的一个属性。
但如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则病房根据准则
（2）应作为一个实体，如图7.16所示。
病人病人n住在1病房
m
住院号姓名病房号住院号姓名医疗
1
医生
图7.16病房作为属性或一个实体
例如3如果一种货物只存放在一个仓库，那么就可以把存放货物的仓库号作为描述货物存放地点的属性。
但如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者与职工发生管理上的联系，那么就应把仓库作为一个实体，如图7.17所示。
货物m存放n仓库
货物存量货号单价存量仓库号面积
货号单价存放仓库号货物n存放1仓库
1
货号单价存量仓库号面积管理
n
职工
图7.17仓库作为一个实体
实例销售管理子系统分E-R图的设计。
子系统的主要功能是：
处理顾客和销售员送来的订单（接订单）
根据订货安排生产的（处理订单）
交出货物同时开出发票（开发票）
收到顾客付款后,根据发票存根和信贷情况进行应收款处理
得到了该子系统二层数据流图（共5张）和数据字典，其中包括14个数据结构和29个数据流。
图7.18是第一层数据流图。
虚线部分划出了系统边界。
图中把系统功能又分为四个子系统。
图7.19至图7.22是第二层数据流图。
4.0支付过账
顾客
结算数据
包装通知单
产品描述
当前价格调整
应收账款订单记录本发票应收账款
顾客账目情况订单细节未付差额调整
1.0送进订单
3.0开发票
2.0外理订单
订单数据已批准订单
5.0提供应收账款
批准/不批准
主管部门批准生产通知单
生产部门
主管部门
/不批准核对订单数据
准能准备发货细节账务费用变动
图7.18销售管理子系统第一层数据流图
顾客账
目情况应收账款
当前价格产品描述
1.2核对账目状况
1.1核对价格
已核对
顾客
顾客订单数据价格的订单
1.3批准订单
账目状况已核对的订单
已批准的订单
批准/不批准
主管部门批准/不批准核对订单数据
主管部门
图7.19接收订单
订单记录本
订单的细节工种号
2.2分配工种号
2.1登记订单
已批准
的订单
已登记
编好号
的订单
2.3准备订货卡
准备
订货卡
订货卡
待完成订货清单
待完成订单
准备待完成
订单报表待完成订单报表
生产通知单生产准备发货细节
部门
图7.20处理订单
包装通知单发票
顾客应收账款
3.1开发票
发票发票主清单
准备发
货细节
3.2分配发票号
生产部门
发票记录本
图7.21开发票
4.3批准信货
结算数据信贷
顾客4.1送进结算
4.2记入贷方余额
支付已批准的信货
4.4记入借方余额
调整调整
应收账款
发票
图7.22支付过账
设计该分E-R图的草图（如图7.23所示）。
顾客1支付n应收账款
1
支付
n
订单产品
?
?
图7.23分E-R图的框架
然后参照第二层数据流图和数据字典中的详尽描述，遵循前面给出的两个准则，进行了如下调整：
（1）每张订单由订单号、若干头信息和订单细节组成。
订单细节又有订货的零件号、数量等来描述。
按照准则
（2），订单细节就不能作订单的属性处理而应该上升为实体。
一张订单可以订若干产品，所以订单与订单细节两个实体之间是1：
n的联系。
（2）原订单和产品的联系实际上是订单细节和产品的联系。
每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重要等信息。
（3）图7.21中“发票清单”是一个数据存储，是否应作为实体加入分E-R图呢？
答案是不必。
这里的数据存储对应手工凭证，发票上的信息在开具发票的同时已及时存入应收账款中了。
（4）工厂对大宗订货给予优惠。
每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们放在产品描述实体中。
最后得到分E-R图如图7.24所示。
顾客1支付n应收账款
1
订货
n
订单
组成
n
折扣规则1参照1n订单细节n参照11产品描述
图7.24销售管理子系统的分E-R图
对每个实体定义的属性如下：
顾客：
{顾客号，顾客名，地址，电话，信贷状况，账目余额}
订单：
{订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点}
订单细则：
{订单号，细则号，零件号，订货数，金额}
应收账款：
{顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额}
产品描述：
{产品号，产品名，单价，重量}
折扣规则：
{产品号，订货量，折扣}
7.3.4视图的集成
各子系统的分E-R图设计好以后，下一步就是要将所有的分E-R图综合成一个系统的总E-R图。
1有两种方式：
·多个分E-R图一次集成，如图所示。
·逐步集成，用累加的方式一次集成两个分E-R图，如图所示。
第一种方式比较复杂，做起来难度较大。
第二种方式每次只集成两个分E-R图，可以降低复杂度。
2每次集成局部E-R图时都需要分两步走。
（1）合并。
解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图。
（2）修改和重构。
消除不必要的冗余，生成基本E-R图。
一、合并分E-R图，生成初步E-R图
合理消除各分E-R图的冲突是合并分E-R图的主要工作与关键所在。
各分E-R图之间的冲突主要有三类：
属性冲突、命名冲突和结构冲突。
1、属性冲突
（1）属性域冲突，即属性值的类型、取值范围或取值集合不同。
（2）属性取值单位冲突。
例如零件的重量，有的以公斤为单位，有的以斤为单位，有的以克为单位。
属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。
2、命名冲突
（1）同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。
（2）异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。
如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。
3、结构冲突
（1）同一对象在不同应用中具有不同的抽象。
解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。
（2）同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同。
（3）实体间的联系在不同的分E-R图中为不同的类型，如实体E1与E2在一个分E-R图中是多对多联系，在另一个分E-R图中是一对多联系；又如在一个分E-R图中E1与E2发生联系，而在另一个分E-R图中E1，E2，E3三者之间有联系。
解决方法是根据应用的语义对实体联系的类型进行综合或调整。
例如，图7.27中零件与产品之间存在多对多的联系——“构成”。
产品、零件与供应商三者之间还存在多对多的联系——“供应”，这两个联系互相不能包含，在合并两个分E-R图时就应把它们综合起来。
产品产品n
n
构成数量数量供应p供应商
mm
零件零件
（E-R）1（E-R）2
产品
nn
数量1构成供应p供应商
mm
零件数量2
（E-R）12
图7.27合并两个分E-R图时的综合
二、消除不必要的冗余，设计基本E-R图
在初步E-R图中，可能存在一些冗余的数据和实体间冗余的联系。
冗余的数据是指可由基本数据导出的数据
冗余的联系是指可由其他联系导出的联系。
冗余数据和冗余联系容易破坏数据库的完整性，给数据库的维护增加困难，应当予以消除。
消除了冗余后的初步E-R图称为基本E-R图。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
如图中，Q3=Q1×Q2，Q4=ΣQ5。
所以Q3和Q4是冗余数据，可以消去。
并且由于Q3消去，产品与材料间m:
n的冗余联系也应消去。
但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。
因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允
升级会员 