第三章 数据库系统设计
数据库系统设计概述
需求分析
概念数据库设计
逻辑数据库数据库设计
物理数据库设计
什么是数据库设计
– 数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求
（信息要求和处理要求）
– 在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。
数据库是信息系统的核心和基础
– 把信息系统中大量的数据按一定的模型组织起来
– 提供存储、维护、检索数据的功能
– 使信息系统可以方便、及时、准确地从数据库中获得所需的信息
数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在
数据库设计是信息系统开发和建设的重要组成部分数据库设计人员应该具备的技术和知识
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识数据库设计的特点
数据库建设是硬件、软件和干件的结合
– 三分技术，七分管理，十二分基础数据
– 技术与管理的界面称之为“干件”
数据库设计应该与应用系统设计相结合
– 结构（数据）设计：设计数据库框架或数据库结构
– 行为（处理）设计：设计应用程序、事务处理等数据库设计方法简述
手工试凑法
– 设计质量与设计人员的经验和水平有直接关系
– 缺乏科学理论和工程方法的支持，工程的质量难以保证
– 数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
规范设计法典型方法
新奥尔良（ New Orleans）方法
– 将数据库设计分为四个阶段
S.B.Yao方法
– 将数据库设计分为五个步骤
I.R.Palmer方法
– 把数据库设计当成一步接一步的过程
计算机辅助设计
– ORACLE Designer 2000
– SYBASE PowerDesigner
参加设计的人员
1,数据库分析设计人员
– 数据库设计的核心人员
– 自始至终参与数据库设计
– 其水平决定了数据库系统的质量
2,用户
– 在数据库设计中也是举足轻重的
– 主要参加需求分析和数据库的运行维护
– 用户积极参与带来的好处
加速数据库设计
提高数据库设计的质量数据库设计步骤：
⒈ 需求分析,全面、准确了解用户的实际要求。
⒉ 概念结构设计,即设计数据库的概念结构。
概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体 DBMS的概念模型。
⒊ 逻辑结构设计,逻辑结构设计是将抽象的概念结构转换为所选用的 DBMS支持的数据模型，并对其进行优化。
⒋ 数据库物理设计,数据库物理设计是对为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
⒌ 数据库实施 在数据库实施阶段，设计人员运用 DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，
编制与调试应用程序，组织数据入库，并进行试运行。
⒍ 数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
3.1 数据库系统设计过程
需求分析 Requirements Analysis;
概念数据库设计 Conceptual Schema Design;
逻辑数据库设计 Logical schema design;
物理数据库设计 Physical Schema Design;
实现 Implementation;
系统测试 System Testing;
维护 Delivery & Maintenance
数据库规划系统定义需求的收集和分析逻辑设计物理设计实现数据转换与加载测试操作性维护构建原型应用程序设计选择 DBMS
数据库设计数据库应用程序生命周期的主要步骤概念数据库设计
IPO表 ……
输入：
输出：
处理：
Creat……
Load……
Main( )
……
if……
then
……
end
分区 1
分区 2
……
概念结构设计逻辑结构设计物理设计设计阶 段设 计 描 述数 据 处 理需求分 析数据字典,全系统中数据项,
数据流,数据存储的描述数据流图和判定表 （ 判定树 ）,数据字典中处理过程的描述概念模型 （ E-R图 ）
数据字典系统说明书包括：
① 新系统要求,
方案和概图
② 反映新系统信息流的数据流图某种数据模型关系 非关系系统结构图
（ 模块结构 ）
存储安排方法选择存取路径建立模块设计
IPO表实施阶段编写模式装入数据数据库试运行程序编码,
编译联结,
测试运行,
维护 性能监测,转储 /恢复数据库重组和重构新旧系统转换,运行,维护 （ 修正性,适应性,改善性维护 ）
3.2 需求分析 Requirements Analysis
⑴ functional requirements
⑵ data/information requirements
⑶ operational/process requirements
(4) security and integrity requirements
⑷ possible evolution
需求分析阶段的工作步骤：
– 分析用户活动，产生业务流程图
– 确定系统范围，产生系统范围图
– 分析用户活动所涉及的数据，产生数据流图
– 分析系统数据，产生数据字典
– 功能分析
– 分析用户活动，产生业务流程图了解用户当前的业务活动和职能，理清其处理流程。
把用户业务分成若干个子处理过程，使每个处理功能明确、界面清楚，画出业务流程图。
– 确定系统范围，产生系统范围图在和用户经过充分讨论的基础上，确定计算机所能进行数据处理的范围，确定 哪些工作由人工完成，哪些工作由计算机系统完成,即确定人机界面。
– 分析用户活动所涉及的数据，产生数据流图深入分析用户的业务处理，以数据流图 (Data Flow
Diagram,DFD)形式表示出数据的流向和对数据所进行的加工。 DFD有四个基本成分：数据流、加工或处理、文件、外部实体 。 DFD可以形象地表示数据流与各业务活动的关系，它是需求分析的工具和分析结果的描述手段。
– 分析系统数据，产生数据字典仅仅有 DFD并不能构成需求说明书,DFD只表示出系统有哪几部分组成和各个部分之间的关系，并没有说明各个成分的含义。数据字典提供对数据库时间描述的集中管理，它的功能是存储和检索各种数据描述
(元数据 Metadata)，数据字典是数据收集和数据分析的主要成果，在数据库设计中占有很重要地位。
数据字典编写的基本要求是：
a.对数据流程图上各种成分的定义必须明确，易理解，唯一。
b.命名、编号与数据流程图一致。
c.符合一致性与完整性的要求，对数据流程图上的成分定义与说明无漏项，无同名异义或异名同义。
d.格式规范，文字精炼，符号正确。
d.数据存储：名称、输入、输出、数据量、存取频率和存取方式 (批处理或联机处理；查询或更新；
顺序或随机 )。
e.处理过程：名称、输入、输出、频率、数据量、处理逻辑说明和响应时间等。
– 功能分析数据库的设计是与应用系统的设计紧密结合的过程，离开一定的功能，数据库就失去其存在价值。数据库设计的一个重要特点是结构 (数据 )
和行为 (功能 )的结合。用户希望系统能提供的功能必须有一个清晰的描述。
功能分析可以采用软件结构图或模块图来表示系统的层次分解关系、模块调用关系。
需求规范
数据流图 Data Flow Diagrams
IPO
数据字典 Data Dictionary
Data Flow Diagrams
Data FlowData Flowinput Process output
Data Storage
input Data storage
Process Data flow
output
Book title;
user name
Book
Shelves
List of Authors
List of titles
Get a
book
Find book
position
Book
reception
List of books borrowed
Author
Title
Book
<shelf#,book#>
Title and author
of requested book;
name of the user
Book requested
by the user
财务费用变动订单细节未付差额调整调整发票包装通知单结算数据批准订单准备发货细节生产通知单应收帐款报表核对订单数据批准 /不批准批准 /不批准订单数据顾客主管部门
1.0
送 进 定单
2.0
处理定单
4,0
支 付 过帐
3.0
开发票
5,0
提 供 应收帐款产品描述应收帐款 定单记录应收帐款生产部门图：销售管理子系统顶层数据流图已批准的订单核对订单数据批准 /不批准帐目状况已核对的订单已核对价格的订单订单数据批准 /不批准
1,1
核对价格
1,2
核对帐目状况
1,3
批准订单顾客主 管 部门产品描述 应收帐款图：接受订单待完成订单报表准备发货细节生产通知单编好号的订单已登记的订单已批准的订单 2,1
登记订单
2,2
分配工种号
2,3
准备订货卡
2,4
准备待完成订单报表生产部门待完成定单订单记录图：处理订单发票包装通知单
3,1
开发票
3,2
分配发票号发票主清单发票记录本生产部门顾客应收帐款准备发货细节发票编过号的发票图：开发票调整 调整已批准的信贷支付信贷结算数据 4,1
送进结算
4,3
批准信贷
4,2
记入货方余额
4,4
记入借方余额应收帐款顾客图：支付过帐
在多层数据流图中，顶层流图可以仅包含一个加工，
它代表被开发系统。它的输入流是该系统的输入数据，
输出流是系统所输出数据
底层流图是指其加工不需再做分解的数据流图，它处在最底层
中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。
画数据流图的基本步骤,一般是自外向内,自顶向下,
逐层细化,完善求精 。 具体步骤如下：
先找系统的数据源点和汇点 。
找出外部实体的输出数据流和输入数据流 。
在图的边上画出系统的外部实体 。
从外部实体的输出数据流 （ 即系统的源点 ） 出发,按照系统的逻辑需要,逐步画出一系列逻辑加工,直到找到外部实体所需的输入数据流 （ 即系统的汇点 ）,形成数据流的封闭 。
按照下面所给的原则进行检查和修改
数据流图上所有图形符号只限于前述四种基本图形元素。数据流图的主图必须包括前述四种基本元素，缺一不可。数据流图的主图上的数据流必须封闭在外部实体之间，外部实体可以不止一个。
每个加工至少有一个输入数据流和一个输出数据流
在数据流流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。
任何一个数据流子图必须与它上一层的一个加工对应，
两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。它表明了在细化过程中输入与输出不能有丢失和添加
图上每个元素都必须有名字。表明数据流和数据文件是什么数据，加工做什么事情,
数据流图中不可夹带控制流，不是程序流程图
初画时可以忽略琐碎的细节，以集中精力于主要数据流
按照上述步骤，再从各加工出发，画出所需的子图
Data Dictionary
描述数据流图的数据存储、数据加工（最底层加工）和数据流
主要内容：
–基本信息：名字、别名、描述；
–定义：数据长度、数据类型、数据结构；
–使用特点：取值范围、使用频率、使用方式等；
–控制信息：来源、用户、引用程序、读写权限等；
–其他说明。
数据元素的定义可以是基本元素及其组合，数据进行自顶向下地分解，直到不需要进一步解释且参与人员都清楚其含义为止。
数据项 描述 （ 名,含义,类型,长度,取值,与其它项逻辑关系等 ） ；
数据结构 描述 （ 名,含义,组成 ） ；
数据流 （ 名,含义,组成,流出过程,流入过程 ） ；
数据存储 （名，含义，组成，数据量，存取方式）；
运算符 含义
= 由 …… 组成
+ 和 （顺序关系）
{ } 重复
[ | ] 或 （必选一个）
（ ） 可选
* * 注释符 号 含 义 举 例
＝ 被定义为
＋ 与 x = a＋ b
[...,...] 或 [...|...] 或 x = [a,b],x = [a|b]
{,.,}或 m{...}n 重复 x = {a},x = 3{a}8
(...) 可选 x = (a)
“...” 基本数据元素 x =,a”
.,连结符 x = 1..9
数据结构的描述存折＝户名＋所号＋帐号＋开户日＋性质＋（印密）＋ 1{存取行 }50
户名＝ 2{字母 }24
所号＝,001”..“999”
帐号＝,00000001”..“99999999”
开户日＝年＋月＋日性质＝,1”..“6” 注：,1”表示普通户,,5”表示工资户等印密＝,0” 注：印密在存折上不显示存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核数据结构（数据项组）名特征 数据项名 数据项名 数据项名 数据项名编号,编号,编号,编号：
数据类型数据宽度小数位数单位值约束允许空值否值个数
对数据流图的每一个基本加工，必须有一个基本加工逻辑说明
基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则
加工逻辑说明必须描述实现加工的策略而不是实现加工的细节
加工逻辑说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息基本加工 /处理
3.3 概念数据库设计
基于 DFD,DD ;
产生数据库概念模式，信息结构 ;
数据库概念模型 /信息模型 /语义模型数据库概念模型：
（ 1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。是对现实世界的一个真实模型。
（ 2）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。
（ 3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
（ 4）易于向关系、网状、层次等各种数据模型转换。
E_R模型实体关系模型
实体集
联系集
设计问题
映射约束
键
E-R 图
扩展 E-R
E-R 模式设计
E-R 模式到表的转换实体集
数据库可被建模为,
– 实体集合,
– 实体间联系,
实体 是客观存在的对象并且与其他对象可区分,
例如,特定的人,公司,事件,植物
实体具有 属性例如,人具有姓名和地址
实体集 是相同类型的实体的集合，他们具有相同的性质,
例如,所有人的集合,所有公司的集合属性
实体用一个属性集合来表示,即实体集中所有成员都具有的描述性特性,
例如,
customer = (customer-id,customer-name,
customer-street,customer-city)
loan = (loan-number,amount)
域 – 属性允许取值的集合
属性种类,
– 简单属性与复合属性,
– 单值属性与多值属性
E.g,多值属性,phone-numbers
– 导出属性
可由其他属性计算得到
E.g,给定出生日期可计算出年龄复合属性联系集
联系 是实体之间的关联例如,
Hayes depositor A-102
customer 实体 联系集 account 实体
联系集 是 n? 2 个实体之间的数学关系,每个实体取自一实体集
{(e1,e2,… en) | e1? E1,e2? E2,…,en? En}
其中 (e1,e2,…,en) 是一个联系
– 例如,
(Hayes,A-102)? depositor
联系集 borrower
联系集也可具有属性,
例如,实体集 customer 和 account 之间的 depositor 联系集可具有属性 access-date
联系集的度
参加联系的实体集的个数,
涉及两个实体集的联系集称为二元的,
联系集可以涉及多于两个的实体集,
– E.g,假设银行职员可以在多个分行承担工作,
且在不同分行有不同工作,则在实体集
employee,job 和 branch 之间有一个三元联系集
多于两个实体集之间的联系较少见,数据库系统中的联系集一般多为二元的,
映射基数
表达可与一个实体通过联系集进行关联的其他实体的个数,
描述二元联系集最有用,
二元联系集的映射基数只能是以下情况,
– 一对一
– 一对多
– 多对一
– 多对多映射基数一对一 一对多注意,A 和 B 中的某些元素可能未被映射到另一集合中的任何元素多对一 多对多注意,A 和 B 中的某些元素可能未被映射到另一集合中的任何元素映射基数影响 ER 设计
如果每个账户只能有一个客户，可将 access-date 作为 account 的属性而不是联系的属性
即,从 account 到 customer 的联系是多对一的,或等价地,
customer 到 account 是一对多的
E-R 图
矩形 表示实体集
菱形 表示联系集
直线 连接实体集及其属性，实体集与联系集
椭圆 表示属性
双椭圆 表示多值属性
虚线椭圆 表示导出属性
下划线 表示主键属性 (见后 )
带有复合属性，多值属性和导出属性的 E-R 图带有属性的联系集角色
参加联系的实体集不必是互不相同的
标记,manager‖ 和,worker‖ 称为 角色 ; 他们指明了
employee 实体是如何通过 works-for 联系集相关的,
角色在 E-R 图中通过对连接菱形与矩形的直线做标记来表示,
角色标记是可选的,用于明确联系的语义基数约束
在联系集与实体集之间用有向直线 (?)表示“一”，无向直线 (—)表示“多”,
例如,从 customer到 loan的一对一联系,
– 通过联系 borrower 一个客户最多只能与一笔贷款相关联
– 通过联系 borrower 一笔贷款最多只能与一个客户相关联一对多联系
通过从 customer到 loan的一对多联系 borrower,一笔贷款最多只能与一个客户相关联,但一个客户可与多笔
(包括 0)贷款相关联多对多联系
一个客户可与多笔 (包括 0)贷款相关联
一笔贷款可与多个客户 (包括 0)相关联实体集参加联系集的方式
完全参加 (用双线表示 ),实体集中的每个实体都至少参加联系集中的一个联系
E.g,loan 参加 borrower 是完全的通过 borrower，每笔 loan 至少与一个 customer 关联
部分参加,某些实体可能未参加联系集中的任何联系
E.g,customer 参加 borrower 是部分的基数限制表示法基数限制也能表达参加约束键
实体集的 超键 是指其值能唯一确定实体的一个或多个属性的集合,
实体集的 候选键 是指具有极小性的超键
– Customer-id 是 customer 的候选键
– account-number 是 account 的候选键
可能存在多个候选键,选择其中之一作为 主键,
具有三元联系的 E-R 图三元联系的基数约束
三元以上的联系最多只允许出现一个箭头
E.g,从 works-on 到 job 的箭头表示每个雇员在每个分行最多只承担一项工作,
若有多个箭头,其意义有两种定义方式
– A,B 和 C 之间的三元联系 R 带有指向 B 和 C 的箭头可以意味着
1,每个 A 实体与唯一的 B 和 C 实体相关联，或
2,每个实体对 (A,B) 与唯一的 C 实体相关联,并且每个实体对
(A,C) 与唯一的 B 实体相关联
– 上面这两种定义方式在不同的系统中都被使用
– 为避免混淆我们禁止多于一个箭头的情况二元 Vs,非二元联系
某些看起来似乎是非二元的联系可用二元联系更好地表示
– E.g,三元联系 parents 将孩子与其父亲和母亲相关联,
可以更好地用两个二元联系 father 和 mother 代替
使用二元联系可以表达部分信息 (e.g,只知道母亲 )
– 但有些联系用非二元更自然
E.g,works-on
弱实体集
不具有主键的实体集称为 弱实体集,
弱实体集的存在依赖于它的 标识实体集 的存在
– 弱实体集通过一个从标识实体集到弱实体集的完全的、一对多的联系集来与它的标识实体集相关联
– 标识联系 用双菱形表示
弱实体集的 辨别属性 （或称 部分键 ）是指在一个弱实体集内区分所有实体的属性集合,
弱实体集的主键由它所依赖的强实体集的主键加上它的辨别属性组成,
弱实体集用双矩形表示,
用下划虚线表示弱实体集的辨别属性,
payment-number – payment 实体集的辨别属性
payment 的主键 – (loan-number,payment-number)
注意,强实体集的主键并不显式地存于弱实体集中,而是隐含地通过标识联系起作用,
如果 loan-number 显式存在,payment 就成了强实体,则
payment 与 loan 之间的联系变得冗余。因为 payment 与
loan共有的属性 loan-number 定义了一个隐含的联系。
特化 /演绎
自顶向下设计过程中,确定实体集中的一个具有特殊性质的子集,
这些子集成为低层实体集,它们具有特殊的属性或者参加特殊的联系,
用带有 ISA 标记的三角形表示 (E.g,customer ―is a‖
person).
属性继承 – 低层实体集继承它连接的高层实体集的所有属性及参加的联系,
特化例子泛化 /归纳
自底向上设计过程 – 将若干共享相同特性的实体集组合成一个高层实体集,
特化与泛化简单互逆 ; 他们在 E-R 图中以相同方式表示,
特化与泛化
一个实体集根据不同特性可以有多个特化实体集,
E.g,除了 officer vs,secretary vs,teller 之外,还有
permanent-employee vs,temporary-employee
每个雇员是
– permanent-employee 或 temporary-employee 之一的成员
– 也是 officer,secretary 或 teller 之一的成员
ISA 联系也称为 超类 - 子类联系对特化 /泛化的设计约束
关于哪些实体可以是给定低层实体集的成员的约束,
– 通过条件定义
E.g,超过 65岁的客户是 senior-citizen 实体集的成员 ; senior-citizen ISA person.
– 用户定义
关于实体在单个泛化中是否可以属于多于一个低层实体集的约束,
– 不相交
一个实体只能属于一个低层实体集
在 E-R 图中 ISA三角形旁边加注 disjoint
– 重叠
一个实体可以属于多个低层实体集对特化 /泛化的设计约束 (续 )
完备性约束 – 说 明高层实体集中的实体是否必须至少属于一个低层实体集,
– 完全的,是
– partial,否
相交完全
相交部分
正交完全
正交部分设计问题
实体集 vs,属性主要根据被建模的企业信息结构以及语义来做选择,
实体集 vs,联系集一个可能的指导原则是用联系集来描述发生在实体之间的动作
二元 vs,n-元联系集尽管可以将任意非二元 (n-ary,n > 2) 联系集用若干不同的二元联系集来代替,n-ary 联系集可以更清楚地显示若干个实体参加单个联系,
联系属性的放置
E-R 设计决策
用属性还是实体集来表示对象
一个现实世界概念最好表示为实体集还是联系集
用三元联系还是一对二元联系
用强实体集还是弱实体集
特化 /泛化的使用 – 有助于设计的模块性
聚集的使用 – 将聚集实体集视为单个单元,从而不必关心其内部结构的细节
branch (branch-name,branch-city,assets)
customer (customer-name,customer-street,customer-only)
account (account-number,branch-name,balance)
loan (loan-number,branch-name,amount)
depositor (customer-name,account-number)
borrower (customer-name,loan-number)
Banking Example
1
顾 客订 单应收帐产 品支付定货
1
n
n
n
n
n n
1
11
1
1
顾 客 应收帐支付
n
定货订 单订单细节 产品描述折扣规则组成参照 2
参照 1
构建概念模型 E_R模型：
标识实体；
标识联系；
标识实体和联系的有关属性；
确定属性域；
确定候选键和主键属性；
特化和泛化实体；
删除和关系模型不相容的属性；
检查模型是否支持用户事务。
视图综合概念数据库设计
1 设计局部 E_R模式确定局部结构范围；
定义实体,产生局部实体；
联系定义,确定局部实体间的联系及其结构约束；
深入分析,确定子类,超类等联系；
2 合成,设计全局 E_R模式
（ 1） 确定局部 E_R模式间公共实体类型；
（ 2） 局部 E_R模式合并,合并对应部分,保留特殊部分,删除冗余部分：
两两合并；
先合并有联系的；
从公共实体类型出发,最后再加入独立的局部结构；
3 消除冲突
（ 1） 属性冲突：类型,取值范围,单位等的冲突；
（ 2） 约束 /结构冲突：属性,实体抽象不同,
实体键,联系关系等冲突；
（ 3） 命名冲突：有异名同意义,同名异意等；
4 优化准确,全面反映用户功能需求；
实体类型个数尽可能少；
属性尽可能少；
实体类型间联系无冗余；
（ 1） 实体类型合并,例如 1,1联系的两个实体可以考虑合并；
（ 2） 冗余属性消除 。 综合成全局模式后,可能产生全局范围内的冗余属性,比如有些数据可以由其他数据推出；
（ 3） 冗余联系消除 。
3.4 逻辑数据库设计目标：将数据库概念结构转化为 特定 DBMS可处理的数据库的逻辑结构。
基本步骤：
（ 1） 初始逻辑数据库模式转换,根据若干规则进行；
（ 2） 规范化处理,减少 /消除关系模式中存在的各种异常,
改善完善性,一致性和存储效率：
确定规范级别；
实施规范化处理；
（ 3） 模式评价功能评价：规范化后的关系模式集合是否支持所有用户的所有的应用要求,及用户需要访问的所有属性；
性能评价：逻辑记录等为基础；
（ 4） 模式修正根据现实世界的应用环境和用户的要求进行相关修正,
例如增加,分解,合并关系模式 。
从 ER模式导出初始数据库模式处理需求ER模式 DBMS特征关系模式规范化模式评价用 DBMS语法描述是否修正进入物理设计阶段初始逻辑数据库模式转换：
符合 E-R 图的数据库可以表示成若干表的集合,
对每一个实体集及联系集都有一个唯一的表，该表的名字就是对应实体集或联系集的名字,
每个表有若干列 (一般对应于属性 ),列有唯一的名字,
E-R 图转换成表格式是从 E-R 图导出关系数据库设计的基础,
强实体集转换到具有相同属性的表,包含所有简单属性和其复合属性的简单子属性，略去复合属性本身。
实体集表示为表
– E.g,给定带有复合属性 name ( 组成属性为 first-name 和 last-name )
的实体集 customer,对应的表具有两个属性
name.first-name 和 name.last-name
实体集 E 的多值属性 M 用一个单独的表 EM 表示
– --表 EM 具有对应于 E 的主键的属性以及对应于 M 的属性
– E.g,employee的多值属性 dependent-names表示为表
employee-dependent-names(employee-id,dname)
– 多值属性的每个值映射到表 EM 中的单独行
E.g.,主键为 John 的雇员实体及其受赡养者 Johnson 和 Johndotir
映射到两行,
(John,Johnson)
(John,Johndotir)
实体间联系的变换：
（ 1） 一个 m:n联系转换为一个关系模式 。 与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性 。
而关系的键为各实体键的组合 。
Employee ProjectsWorks_on
timeEmployee-id Project-id
Table,works_on( employee-id,project-id,time)
（ 2） 一个 1:n联系可以转换为一个独立的关系模式,也可以与 n端对应的关系模式合并 。 如果转换为一个独立的关系模式,则与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性,而关系的键为 n端实体的键 。
branch loanLoan-branch
Branch-name Loan-numberamount
Table,loan( loan-number,amount,branch-name)
（ 3）一个 1:1联系可以转换为一个独立的关系模式（部分参与），也可以与任意一端对应的关系模式合并（全参与）。
manager departmentmanage
manager-name Dept-idDept-name
Table:
Manager(Manager-name,Dept-id)
department( Dept-id,Dept-name,manager-name)
（ 4） 三个或三个以上实体间的一个多元联系转换为一个关系模式 。 与该多元联系相连的各实体的键以及联系本身的属性均转换为关系的属性 。 而关系的键为各实体键的组合 。
course teacherS_C_T
CNO TeaNO
student NO
S_C_T(NO,CNO,TeaNO,…)
弱实体集转换：
弱实体集转换成的表还包含对应于其标识强实体集的主键的列。
Table,payment(loan-number,payment-number,payment-
date,payment-amount)
演绎 /归纳表示成表
方法 1,
– 为高层实体集构造表
– 为每个低层实体集构造表,包括高层实体集的主键和局部属性表 表属性
person name,street,city
customer name,credit-rating
employee name,salary
– 缺点,获得 employee 之类的实体的信息需要访问两个表演绎 /归纳表示成表 (续 )
方法 2,
– 为每个实体集构造表,其属性包括所有局部属性和继承来的属性表 表属性
person name,street,city
customer name,street,city,credit-rating
employee name,street,city,salary
如果是完备的,则没有必要为一般实体 (person)创建表
– 缺点,对于既是客户又是雇员的人,其 street 和 city 被冗余存储转换总结：
转换规则 1,ER图中的每一个实体映射到关系数据库中的一个表，并用实体名来命名这个表。表的列代表了连接到实体的所有简单单值属性 (可能是通过复合属性连接到实体的，但复合属性本身并不变成表的列 )。
实体的标识符映射为该表的候选键，实体的主标识符映射为主键。实体实例映射为该表的行。
转换规则 2：给定一个实体 E，主标识是 p,a是 E的一个多值属性，那么 a映射成自身的一个表，该表的列包含
p和 a，这个表的主键是 p和 a的组合。 E当然地映射成一个表。
转换规则 3：当两个实体 E和 F参与一个二元的多对多的联系 R时，联系 R映射成一个表 T。这个表包括从实体 E
和 F转化而来的两个表的主键，这些列构成了表 T的主键，
也可能还得再加入联系的属性才能构成表 T的主键。
转换规则 4：当两个实体 E和 F参与一个多对一的二元联系 R时，这个联系在关系数据库设计中不能被映射自身的一个表。假设 F表示多方，具有 maxcard(F,R)=1，那么从 F转化成的表 T中应当包括从 E转化的表的主键，这被称为 T的外键。因为 maxcard(F,R)=1,T的每一行都通过一个外键值联系到实体 E的一个实例。
转换规则 4(续 )：如果 F在 R中是全部参与的，那么意味着
T的上述外键不能取空值。如果 F在 R中是选择参与的，
那么 T中不与 E的实例相联系的行的外键可以取空值。
转换规则 5：如果给定实体 E和 F，它们的联系是一对一，
二者的参与都是部分的，那么 E和 F分别转换为表 S和 T，
并且在表 S中加入 T表的主键作为 S的外键，在表 T中加入
S表的主键作为 T的外键，有此表示 E和 F的可选参与一对一联系。
转换规则 6：如果给定实体 E和 F，它们的联系是一对一，
二者的参与都是全部的，那么最好将 E和 F对应的两个表合并成一个表，由此而避免使用外键。
转换规则 7：如果参与联系的实体数目多于两个，一般称为多元联系。对于多元联系，通常用多个不同的二元联系替代，再针对二元联系进行转换 (Oracle的数据库设计工具 Designer只处理二元联系的转换 )。
对于不能用多个不同的二元联系替代的情形，一般采用如下规则进行转换：除参与联系的实体转换为相应的表之外，联系也转换为独立的表，表中包含了参与联系的实体的主键。注：转换的表能够真实表达语义是最终目的。
转换规则 8：对于一元联系，一般不特别将联系转换成独立的表，而在参与联系的这个实体相应的表中加入联系的附加属性。例如职工实体的领导联系是一个一元联系，职工实体转换成相应的表，在此表中加入领导工号属性。联系转换为表中的一列。
– 更新异常 (Update Anomaly)：例如如果更改表所对应的某个实体实例或者关系实例的单个属性时，需要将多行更新，那么就说这个表存在更新异常。
– 删除异常 (Delete Anomaly),例如如果删除表的某一行来反应某个实体实例或者关系实例消失时，
会导致丢失另一个不同实体实例或者关系实例的信息，而这是我们不希望丢失的。
– 插入异常 (Insert Anomaly),例如如果某个实体或者实例信息随着另一个实体或实例信息的存在而存在，在缺少另一个实体或实例信息时，无法表示这个实体或者实例信息。
– 例：客户 _电话（姓名，性别，身份证号，地址，
电话号码。。。）
关系模式存在的问题：
设计目标
关系数据库设计的目标是,
– BCNF.
– 无损连接,
– 依赖保持,
如果不能达到这些,也可接受
– 缺少依赖保持
– 因 3NF引起的冗余
除了超键之外,SQL 并没有提供直接声明函数依赖的方法,
可以通过断言声明 FD,但检测代价大,
因此即使我们有一个保持依赖的分解,用 SQL我们也不能有效地检测左部不是键的函数依赖,
数据库逻辑设计全过程
假设给定了模式 R
– R 可能是经转换 E-R图到表而生成的,
– R 可能是单个包含 所有 属性的关系 (称为全关系 ).
– 规范化将 R 分解成较小的关系,
– R 可能是某种特定设计的结果,然后再测试 /转换成范式,
数据模型的优化方法为：
1.确定数据依赖 。
2.对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
3.按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
4.按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
5.对关系模式进行必要的分解。
6.对经过规范化的关系数据库模式进行优化处理，根据需求和应用的特点，进行逻辑数据库的性能估计，并进行必要的水平和垂直分解。
规范化的优缺点优点：
消除更新异常减少数据冗余
-解决了数据完整性问题
-节省存储空间缺点：
涉及多表的子查询和表之间的联接需要更复杂的 SQL语句
DBMS的额外工作使应用程序变慢
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。
为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。
充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数
充分了解所用 RDBMS的内部特征，特别是系统提供的存取方法和存储结构
3.5 数据库的物理设计数据库物理设计确定数据库的物理结构评价数据库的物理结构逻辑结构设计数据库实施物理模型逻辑模型
关系数据库物理设计的内容
– 为关系模式选择存取方法 (建立存取路径 )
– 设计关系、索引等数据库文件的物理存储结构
物理数据库设计所需参数
－数据库查询事务（查询的关系,查询条件所涉及的属性,连接条件所涉及的属性,查询的投影属性）
－数据更新事务（被更新的关系，每个关系上的更新操作条件所涉及的属性,修改操作要改变的属性值）
－每个事务在各关系上运行的频率和性能要求物理设计步骤：
设计物理表示；
分析事务；
选择文件组织方式；
选择索引；
估计所需的磁盘空间；
设计用户视图；
设计安全机制；
考虑引入可控冗余；
监控和调整运行的系统。
设计物理表示法分析事务；
选择文件组织方式；
选择索引。
受控冗余的考虑考虑派生的数据；
同时考虑重复列或连接表。
设计安全机制设计用户视图；
设计访问规则。
监控并调整操作系统设计物理表示方法：
分析事务：理解运行在数据库上的事务的功能并分析重要的事务。
事务应用图；
事务 /表交叉引用矩阵；
将所有事务路径映射到表中；
确定哪些表最常被事务访问；
分析选出的包含了这些表的事务。
选择文件组织方式：
确定每个基本表的有效文件组织方式。（如果目标 DBMS允许）
堆
HASH
索引顺序存取方法（ ISAM）
B+树堆（无序的）：（下面情况较适合）
1）当数据批量加载到表时；
2）表只有几页长；
3）每当访问表时都要检索表中的每条记录；
4）当表有其他的访问结构时，例如索引键，则堆存储可用来保存空间。
当仅访问表中的选定记录时，堆文件不合适。
HASH：（在下面情况下并不适合）
1）当记录是基于 Hash字段值的模式匹配进行检索时。
（例如检索成员号以‘ M2’开始的所有成员）
2）当记录是基于 HASH字段值的范围进行检索时。
3）当记录是基于一个其他列而不是基于 HSAH列检索时。
4）当记录是基于 HSAH字段的一部分进行检索时。
5）当 HSAH列被经常更新时。
ISAM（索引顺序存取方法）：
支持基于准确键匹配、模式匹配、值的范围和制定的部分码。
B+树：
支持基于准确键匹配、模式匹配、值的范围和指定的部分键。其的索引是动态的，随着表内容的增加而增加。
确定数据库的存储结构
确定数据库物理结构的内容
– 1,确定数据的存放位置和存储结构
关系
索引
聚簇
日志
备份
– 2,确定系统配置确定数据的存放位置
影响数据存放位置和存储结构的因素
– 硬件环境
– 应用需求
存取时间
存储空间利用率
维护代价这三个方面常常是相互矛盾的
基本原则
– 根据应用情况将
易变部分与稳定部分
存取频率较高部分与存取频率较低部分分开存放，以提高系统性能例：
数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。
如果计算机有多个磁盘，可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。
可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
确定系统配置
DBMS产品一般都提供了一些存储分配参数
– 同时使用数据库的用户数
– 同时打开的数据库对象数
– 使用的缓冲区长度、个数
– 时间片大小
– 数据库的大小
– 装填因子
– 锁的数目
– 等等
系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要根据应用环境确定这些参数值，以使系统性能最优。
在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
选择索引：
目标是确定添加索引是否会改善系统性能。
应该选择如下列来排序或群集索引记录：
经常用于连接操作的列；
在表中经常按某列的顺序访问记录的列。
受控冗余的考虑：
目标是确定如何处理派生数据并确定是否放松规范化规则引入受控冗余数据来改善系统性能。
通常如果性能达不到要求，并且表的更新率较低，查询率较高，则降低规范化就是可行的。
但需要考虑下述因素：
降低规范化使实现更复杂；
降低规范化经常会牺牲灵活性；
降低规范化可能加快检索速度，但会降低更新速度。
考虑派生数据：
确定怎样处理派生数据。（总量、总和等）
计算：
存储派生数据以及与派生它的数据操作保持一致的额外费用；
每次在需要时进行计算的费用。
当系统的查询语言不能简单地运用运算法则来计算派生列时，存储派生列就更加合适。
同时考虑重复列或连接表：
目标是确定是否通过放松规范化规则，以受控的方式引入冗余来改善系统的性能。
降低规范化的一些通常情况：
合并一对一关系；
复制一对多关系中的非键列来减少连接；
复制一对多关系中的外键列来减少连接；
复制多对多关系中的列来减少连接；
引入重复组；
合并查找表和基本表；
创建提取表。
为每个视图构建逻辑数据模型为局部逻辑数据模型创建并检查表只有一个视图？
构建并检查全局逻辑数据模型将全局逻辑数据模型转换成目标 DBMS
对性能有要求？
设计物理表示法受控冗余的考虑对安全性有要求？
设计安全机制监控并调整操作系统是是是否否否数据库实施
– 用 DDL定义数据库结构
– 组织数据入库
– 编制与调试应用程序
– 数据库试运行
应用程序开发的主要工作：
–应用程序设计：应用程序设计主要包括事务设计和用户界面设计。
事务代表了现实世界的事件，事务设计包括事务使用什么数据，事务要做什么，事务的输出，
事务的使用频度。事务有检索事务、更新事务、
混合事务之分。
用户界面设计要易于掌握、操作直观。
应用程序开发
应用程序开发的主要工作：
–应用程序编写
–组织数据入库
–应用程序的调试与试运行
维护阶段的任务包括：
–维护数据库的安全性和完整性：检查系统安全性是否受到侵犯，及时调整授权和密码，实施系统转储与后备，发生故障及时恢复。
–监测并改善数据库性能：对数据库的存储空间状况及响应时间进行分析评价，结合用户反应确定改进措施。
–必要时对数据库进行重新组织和重新构造。
–根据用户要求对数据库现有功能进行扩充。
主要由 DBA协助完成。
思考题：
１设公司的工程项目管理子系统需要对以下信息进行管理：
工程项目：有项目编号,项目名称和项目地址等属性；零件：有零件编号,零件名称,颜色,重量等属性；供应商：供应商编号,供应商名称,地址等属性 。 供应商供给工程项目一定数量的零件 。 完成以下设计：
（ １ ） 画出此子系统的 E_R图；
（ ２ ） 将 E_R图转换成相应的关系模式,使得每个关系模式至少是 3NF；
指出每个关系模式的主键。
数据库系统设计概述
需求分析
概念数据库设计
逻辑数据库数据库设计
物理数据库设计
什么是数据库设计
– 数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求
（信息要求和处理要求）
– 在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。
数据库是信息系统的核心和基础
– 把信息系统中大量的数据按一定的模型组织起来
– 提供存储、维护、检索数据的功能
– 使信息系统可以方便、及时、准确地从数据库中获得所需的信息
数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在
数据库设计是信息系统开发和建设的重要组成部分数据库设计人员应该具备的技术和知识
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识数据库设计的特点
数据库建设是硬件、软件和干件的结合
– 三分技术，七分管理，十二分基础数据
– 技术与管理的界面称之为“干件”
数据库设计应该与应用系统设计相结合
– 结构（数据）设计：设计数据库框架或数据库结构
– 行为（处理）设计：设计应用程序、事务处理等数据库设计方法简述
手工试凑法
– 设计质量与设计人员的经验和水平有直接关系
– 缺乏科学理论和工程方法的支持，工程的质量难以保证
– 数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
规范设计法典型方法
新奥尔良（ New Orleans）方法
– 将数据库设计分为四个阶段
S.B.Yao方法
– 将数据库设计分为五个步骤
I.R.Palmer方法
– 把数据库设计当成一步接一步的过程
计算机辅助设计
– ORACLE Designer 2000
– SYBASE PowerDesigner
参加设计的人员
1,数据库分析设计人员
– 数据库设计的核心人员
– 自始至终参与数据库设计
– 其水平决定了数据库系统的质量
2,用户
– 在数据库设计中也是举足轻重的
– 主要参加需求分析和数据库的运行维护
– 用户积极参与带来的好处
加速数据库设计
提高数据库设计的质量数据库设计步骤：
⒈ 需求分析,全面、准确了解用户的实际要求。
⒉ 概念结构设计,即设计数据库的概念结构。
概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体 DBMS的概念模型。
⒊ 逻辑结构设计,逻辑结构设计是将抽象的概念结构转换为所选用的 DBMS支持的数据模型，并对其进行优化。
⒋ 数据库物理设计,数据库物理设计是对为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
⒌ 数据库实施 在数据库实施阶段，设计人员运用 DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，
编制与调试应用程序，组织数据入库，并进行试运行。
⒍ 数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
3.1 数据库系统设计过程
需求分析 Requirements Analysis;
概念数据库设计 Conceptual Schema Design;
逻辑数据库设计 Logical schema design;
物理数据库设计 Physical Schema Design;
实现 Implementation;
系统测试 System Testing;
维护 Delivery & Maintenance
数据库规划系统定义需求的收集和分析逻辑设计物理设计实现数据转换与加载测试操作性维护构建原型应用程序设计选择 DBMS
数据库设计数据库应用程序生命周期的主要步骤概念数据库设计
IPO表 ……
输入：
输出：
处理：
Creat……
Load……
Main( )
……
if……
then
……
end
分区 1
分区 2
……
概念结构设计逻辑结构设计物理设计设计阶 段设 计 描 述数 据 处 理需求分 析数据字典,全系统中数据项,
数据流,数据存储的描述数据流图和判定表 （ 判定树 ）,数据字典中处理过程的描述概念模型 （ E-R图 ）
数据字典系统说明书包括：
① 新系统要求,
方案和概图
② 反映新系统信息流的数据流图某种数据模型关系 非关系系统结构图
（ 模块结构 ）
存储安排方法选择存取路径建立模块设计
IPO表实施阶段编写模式装入数据数据库试运行程序编码,
编译联结,
测试运行,
维护 性能监测,转储 /恢复数据库重组和重构新旧系统转换,运行,维护 （ 修正性,适应性,改善性维护 ）
3.2 需求分析 Requirements Analysis
⑴ functional requirements
⑵ data/information requirements
⑶ operational/process requirements
(4) security and integrity requirements
⑷ possible evolution
需求分析阶段的工作步骤：
– 分析用户活动，产生业务流程图
– 确定系统范围，产生系统范围图
– 分析用户活动所涉及的数据，产生数据流图
– 分析系统数据，产生数据字典
– 功能分析
– 分析用户活动，产生业务流程图了解用户当前的业务活动和职能，理清其处理流程。
把用户业务分成若干个子处理过程，使每个处理功能明确、界面清楚，画出业务流程图。
– 确定系统范围，产生系统范围图在和用户经过充分讨论的基础上，确定计算机所能进行数据处理的范围，确定 哪些工作由人工完成，哪些工作由计算机系统完成,即确定人机界面。
– 分析用户活动所涉及的数据，产生数据流图深入分析用户的业务处理，以数据流图 (Data Flow
Diagram,DFD)形式表示出数据的流向和对数据所进行的加工。 DFD有四个基本成分：数据流、加工或处理、文件、外部实体 。 DFD可以形象地表示数据流与各业务活动的关系，它是需求分析的工具和分析结果的描述手段。
– 分析系统数据，产生数据字典仅仅有 DFD并不能构成需求说明书,DFD只表示出系统有哪几部分组成和各个部分之间的关系，并没有说明各个成分的含义。数据字典提供对数据库时间描述的集中管理，它的功能是存储和检索各种数据描述
(元数据 Metadata)，数据字典是数据收集和数据分析的主要成果，在数据库设计中占有很重要地位。
数据字典编写的基本要求是：
a.对数据流程图上各种成分的定义必须明确，易理解，唯一。
b.命名、编号与数据流程图一致。
c.符合一致性与完整性的要求，对数据流程图上的成分定义与说明无漏项，无同名异义或异名同义。
d.格式规范，文字精炼，符号正确。
d.数据存储：名称、输入、输出、数据量、存取频率和存取方式 (批处理或联机处理；查询或更新；
顺序或随机 )。
e.处理过程：名称、输入、输出、频率、数据量、处理逻辑说明和响应时间等。
– 功能分析数据库的设计是与应用系统的设计紧密结合的过程，离开一定的功能，数据库就失去其存在价值。数据库设计的一个重要特点是结构 (数据 )
和行为 (功能 )的结合。用户希望系统能提供的功能必须有一个清晰的描述。
功能分析可以采用软件结构图或模块图来表示系统的层次分解关系、模块调用关系。
需求规范
数据流图 Data Flow Diagrams
IPO
数据字典 Data Dictionary
Data Flow Diagrams
Data FlowData Flowinput Process output
Data Storage
input Data storage
Process Data flow
output
Book title;
user name
Book
Shelves
List of Authors
List of titles
Get a
book
Find book
position
Book
reception
List of books borrowed
Author
Title
Book
<shelf#,book#>
Title and author
of requested book;
name of the user
Book requested
by the user
财务费用变动订单细节未付差额调整调整发票包装通知单结算数据批准订单准备发货细节生产通知单应收帐款报表核对订单数据批准 /不批准批准 /不批准订单数据顾客主管部门
1.0
送 进 定单
2.0
处理定单
4,0
支 付 过帐
3.0
开发票
5,0
提 供 应收帐款产品描述应收帐款 定单记录应收帐款生产部门图：销售管理子系统顶层数据流图已批准的订单核对订单数据批准 /不批准帐目状况已核对的订单已核对价格的订单订单数据批准 /不批准
1,1
核对价格
1,2
核对帐目状况
1,3
批准订单顾客主 管 部门产品描述 应收帐款图：接受订单待完成订单报表准备发货细节生产通知单编好号的订单已登记的订单已批准的订单 2,1
登记订单
2,2
分配工种号
2,3
准备订货卡
2,4
准备待完成订单报表生产部门待完成定单订单记录图：处理订单发票包装通知单
3,1
开发票
3,2
分配发票号发票主清单发票记录本生产部门顾客应收帐款准备发货细节发票编过号的发票图：开发票调整 调整已批准的信贷支付信贷结算数据 4,1
送进结算
4,3
批准信贷
4,2
记入货方余额
4,4
记入借方余额应收帐款顾客图：支付过帐
在多层数据流图中，顶层流图可以仅包含一个加工，
它代表被开发系统。它的输入流是该系统的输入数据，
输出流是系统所输出数据
底层流图是指其加工不需再做分解的数据流图，它处在最底层
中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。
画数据流图的基本步骤,一般是自外向内,自顶向下,
逐层细化,完善求精 。 具体步骤如下：
先找系统的数据源点和汇点 。
找出外部实体的输出数据流和输入数据流 。
在图的边上画出系统的外部实体 。
从外部实体的输出数据流 （ 即系统的源点 ） 出发,按照系统的逻辑需要,逐步画出一系列逻辑加工,直到找到外部实体所需的输入数据流 （ 即系统的汇点 ）,形成数据流的封闭 。
按照下面所给的原则进行检查和修改
数据流图上所有图形符号只限于前述四种基本图形元素。数据流图的主图必须包括前述四种基本元素，缺一不可。数据流图的主图上的数据流必须封闭在外部实体之间，外部实体可以不止一个。
每个加工至少有一个输入数据流和一个输出数据流
在数据流流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。
任何一个数据流子图必须与它上一层的一个加工对应，
两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。它表明了在细化过程中输入与输出不能有丢失和添加
图上每个元素都必须有名字。表明数据流和数据文件是什么数据，加工做什么事情,
数据流图中不可夹带控制流，不是程序流程图
初画时可以忽略琐碎的细节，以集中精力于主要数据流
按照上述步骤，再从各加工出发，画出所需的子图
Data Dictionary
描述数据流图的数据存储、数据加工（最底层加工）和数据流
主要内容：
–基本信息：名字、别名、描述；
–定义：数据长度、数据类型、数据结构；
–使用特点：取值范围、使用频率、使用方式等；
–控制信息：来源、用户、引用程序、读写权限等；
–其他说明。
数据元素的定义可以是基本元素及其组合，数据进行自顶向下地分解，直到不需要进一步解释且参与人员都清楚其含义为止。
数据项 描述 （ 名,含义,类型,长度,取值,与其它项逻辑关系等 ） ；
数据结构 描述 （ 名,含义,组成 ） ；
数据流 （ 名,含义,组成,流出过程,流入过程 ） ；
数据存储 （名，含义，组成，数据量，存取方式）；
运算符 含义
= 由 …… 组成
+ 和 （顺序关系）
{ } 重复
[ | ] 或 （必选一个）
（ ） 可选
* * 注释符 号 含 义 举 例
＝ 被定义为
＋ 与 x = a＋ b
[...,...] 或 [...|...] 或 x = [a,b],x = [a|b]
{,.,}或 m{...}n 重复 x = {a},x = 3{a}8
(...) 可选 x = (a)
“...” 基本数据元素 x =,a”
.,连结符 x = 1..9
数据结构的描述存折＝户名＋所号＋帐号＋开户日＋性质＋（印密）＋ 1{存取行 }50
户名＝ 2{字母 }24
所号＝,001”..“999”
帐号＝,00000001”..“99999999”
开户日＝年＋月＋日性质＝,1”..“6” 注：,1”表示普通户,,5”表示工资户等印密＝,0” 注：印密在存折上不显示存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核数据结构（数据项组）名特征 数据项名 数据项名 数据项名 数据项名编号,编号,编号,编号：
数据类型数据宽度小数位数单位值约束允许空值否值个数
对数据流图的每一个基本加工，必须有一个基本加工逻辑说明
基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则
加工逻辑说明必须描述实现加工的策略而不是实现加工的细节
加工逻辑说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息基本加工 /处理
3.3 概念数据库设计
基于 DFD,DD ;
产生数据库概念模式，信息结构 ;
数据库概念模型 /信息模型 /语义模型数据库概念模型：
（ 1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。是对现实世界的一个真实模型。
（ 2）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。
（ 3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
（ 4）易于向关系、网状、层次等各种数据模型转换。
E_R模型实体关系模型
实体集
联系集
设计问题
映射约束
键
E-R 图
扩展 E-R
E-R 模式设计
E-R 模式到表的转换实体集
数据库可被建模为,
– 实体集合,
– 实体间联系,
实体 是客观存在的对象并且与其他对象可区分,
例如,特定的人,公司,事件,植物
实体具有 属性例如,人具有姓名和地址
实体集 是相同类型的实体的集合，他们具有相同的性质,
例如,所有人的集合,所有公司的集合属性
实体用一个属性集合来表示,即实体集中所有成员都具有的描述性特性,
例如,
customer = (customer-id,customer-name,
customer-street,customer-city)
loan = (loan-number,amount)
域 – 属性允许取值的集合
属性种类,
– 简单属性与复合属性,
– 单值属性与多值属性
E.g,多值属性,phone-numbers
– 导出属性
可由其他属性计算得到
E.g,给定出生日期可计算出年龄复合属性联系集
联系 是实体之间的关联例如,
Hayes depositor A-102
customer 实体 联系集 account 实体
联系集 是 n? 2 个实体之间的数学关系,每个实体取自一实体集
{(e1,e2,… en) | e1? E1,e2? E2,…,en? En}
其中 (e1,e2,…,en) 是一个联系
– 例如,
(Hayes,A-102)? depositor
联系集 borrower
联系集也可具有属性,
例如,实体集 customer 和 account 之间的 depositor 联系集可具有属性 access-date
联系集的度
参加联系的实体集的个数,
涉及两个实体集的联系集称为二元的,
联系集可以涉及多于两个的实体集,
– E.g,假设银行职员可以在多个分行承担工作,
且在不同分行有不同工作,则在实体集
employee,job 和 branch 之间有一个三元联系集
多于两个实体集之间的联系较少见,数据库系统中的联系集一般多为二元的,
映射基数
表达可与一个实体通过联系集进行关联的其他实体的个数,
描述二元联系集最有用,
二元联系集的映射基数只能是以下情况,
– 一对一
– 一对多
– 多对一
– 多对多映射基数一对一 一对多注意,A 和 B 中的某些元素可能未被映射到另一集合中的任何元素多对一 多对多注意,A 和 B 中的某些元素可能未被映射到另一集合中的任何元素映射基数影响 ER 设计
如果每个账户只能有一个客户，可将 access-date 作为 account 的属性而不是联系的属性
即,从 account 到 customer 的联系是多对一的,或等价地,
customer 到 account 是一对多的
E-R 图
矩形 表示实体集
菱形 表示联系集
直线 连接实体集及其属性，实体集与联系集
椭圆 表示属性
双椭圆 表示多值属性
虚线椭圆 表示导出属性
下划线 表示主键属性 (见后 )
带有复合属性，多值属性和导出属性的 E-R 图带有属性的联系集角色
参加联系的实体集不必是互不相同的
标记,manager‖ 和,worker‖ 称为 角色 ; 他们指明了
employee 实体是如何通过 works-for 联系集相关的,
角色在 E-R 图中通过对连接菱形与矩形的直线做标记来表示,
角色标记是可选的,用于明确联系的语义基数约束
在联系集与实体集之间用有向直线 (?)表示“一”，无向直线 (—)表示“多”,
例如,从 customer到 loan的一对一联系,
– 通过联系 borrower 一个客户最多只能与一笔贷款相关联
– 通过联系 borrower 一笔贷款最多只能与一个客户相关联一对多联系
通过从 customer到 loan的一对多联系 borrower,一笔贷款最多只能与一个客户相关联,但一个客户可与多笔
(包括 0)贷款相关联多对多联系
一个客户可与多笔 (包括 0)贷款相关联
一笔贷款可与多个客户 (包括 0)相关联实体集参加联系集的方式
完全参加 (用双线表示 ),实体集中的每个实体都至少参加联系集中的一个联系
E.g,loan 参加 borrower 是完全的通过 borrower，每笔 loan 至少与一个 customer 关联
部分参加,某些实体可能未参加联系集中的任何联系
E.g,customer 参加 borrower 是部分的基数限制表示法基数限制也能表达参加约束键
实体集的 超键 是指其值能唯一确定实体的一个或多个属性的集合,
实体集的 候选键 是指具有极小性的超键
– Customer-id 是 customer 的候选键
– account-number 是 account 的候选键
可能存在多个候选键,选择其中之一作为 主键,
具有三元联系的 E-R 图三元联系的基数约束
三元以上的联系最多只允许出现一个箭头
E.g,从 works-on 到 job 的箭头表示每个雇员在每个分行最多只承担一项工作,
若有多个箭头,其意义有两种定义方式
– A,B 和 C 之间的三元联系 R 带有指向 B 和 C 的箭头可以意味着
1,每个 A 实体与唯一的 B 和 C 实体相关联，或
2,每个实体对 (A,B) 与唯一的 C 实体相关联,并且每个实体对
(A,C) 与唯一的 B 实体相关联
– 上面这两种定义方式在不同的系统中都被使用
– 为避免混淆我们禁止多于一个箭头的情况二元 Vs,非二元联系
某些看起来似乎是非二元的联系可用二元联系更好地表示
– E.g,三元联系 parents 将孩子与其父亲和母亲相关联,
可以更好地用两个二元联系 father 和 mother 代替
使用二元联系可以表达部分信息 (e.g,只知道母亲 )
– 但有些联系用非二元更自然
E.g,works-on
弱实体集
不具有主键的实体集称为 弱实体集,
弱实体集的存在依赖于它的 标识实体集 的存在
– 弱实体集通过一个从标识实体集到弱实体集的完全的、一对多的联系集来与它的标识实体集相关联
– 标识联系 用双菱形表示
弱实体集的 辨别属性 （或称 部分键 ）是指在一个弱实体集内区分所有实体的属性集合,
弱实体集的主键由它所依赖的强实体集的主键加上它的辨别属性组成,
弱实体集用双矩形表示,
用下划虚线表示弱实体集的辨别属性,
payment-number – payment 实体集的辨别属性
payment 的主键 – (loan-number,payment-number)
注意,强实体集的主键并不显式地存于弱实体集中,而是隐含地通过标识联系起作用,
如果 loan-number 显式存在,payment 就成了强实体,则
payment 与 loan 之间的联系变得冗余。因为 payment 与
loan共有的属性 loan-number 定义了一个隐含的联系。
特化 /演绎
自顶向下设计过程中,确定实体集中的一个具有特殊性质的子集,
这些子集成为低层实体集,它们具有特殊的属性或者参加特殊的联系,
用带有 ISA 标记的三角形表示 (E.g,customer ―is a‖
person).
属性继承 – 低层实体集继承它连接的高层实体集的所有属性及参加的联系,
特化例子泛化 /归纳
自底向上设计过程 – 将若干共享相同特性的实体集组合成一个高层实体集,
特化与泛化简单互逆 ; 他们在 E-R 图中以相同方式表示,
特化与泛化
一个实体集根据不同特性可以有多个特化实体集,
E.g,除了 officer vs,secretary vs,teller 之外,还有
permanent-employee vs,temporary-employee
每个雇员是
– permanent-employee 或 temporary-employee 之一的成员
– 也是 officer,secretary 或 teller 之一的成员
ISA 联系也称为 超类 - 子类联系对特化 /泛化的设计约束
关于哪些实体可以是给定低层实体集的成员的约束,
– 通过条件定义
E.g,超过 65岁的客户是 senior-citizen 实体集的成员 ; senior-citizen ISA person.
– 用户定义
关于实体在单个泛化中是否可以属于多于一个低层实体集的约束,
– 不相交
一个实体只能属于一个低层实体集
在 E-R 图中 ISA三角形旁边加注 disjoint
– 重叠
一个实体可以属于多个低层实体集对特化 /泛化的设计约束 (续 )
完备性约束 – 说 明高层实体集中的实体是否必须至少属于一个低层实体集,
– 完全的,是
– partial,否
相交完全
相交部分
正交完全
正交部分设计问题
实体集 vs,属性主要根据被建模的企业信息结构以及语义来做选择,
实体集 vs,联系集一个可能的指导原则是用联系集来描述发生在实体之间的动作
二元 vs,n-元联系集尽管可以将任意非二元 (n-ary,n > 2) 联系集用若干不同的二元联系集来代替,n-ary 联系集可以更清楚地显示若干个实体参加单个联系,
联系属性的放置
E-R 设计决策
用属性还是实体集来表示对象
一个现实世界概念最好表示为实体集还是联系集
用三元联系还是一对二元联系
用强实体集还是弱实体集
特化 /泛化的使用 – 有助于设计的模块性
聚集的使用 – 将聚集实体集视为单个单元,从而不必关心其内部结构的细节
branch (branch-name,branch-city,assets)
customer (customer-name,customer-street,customer-only)
account (account-number,branch-name,balance)
loan (loan-number,branch-name,amount)
depositor (customer-name,account-number)
borrower (customer-name,loan-number)
Banking Example
1
顾 客订 单应收帐产 品支付定货
1
n
n
n
n
n n
1
11
1
1
顾 客 应收帐支付
n
定货订 单订单细节 产品描述折扣规则组成参照 2
参照 1
构建概念模型 E_R模型：
标识实体；
标识联系；
标识实体和联系的有关属性；
确定属性域；
确定候选键和主键属性；
特化和泛化实体；
删除和关系模型不相容的属性；
检查模型是否支持用户事务。
视图综合概念数据库设计
1 设计局部 E_R模式确定局部结构范围；
定义实体,产生局部实体；
联系定义,确定局部实体间的联系及其结构约束；
深入分析,确定子类,超类等联系；
2 合成,设计全局 E_R模式
（ 1） 确定局部 E_R模式间公共实体类型；
（ 2） 局部 E_R模式合并,合并对应部分,保留特殊部分,删除冗余部分：
两两合并；
先合并有联系的；
从公共实体类型出发,最后再加入独立的局部结构；
3 消除冲突
（ 1） 属性冲突：类型,取值范围,单位等的冲突；
（ 2） 约束 /结构冲突：属性,实体抽象不同,
实体键,联系关系等冲突；
（ 3） 命名冲突：有异名同意义,同名异意等；
4 优化准确,全面反映用户功能需求；
实体类型个数尽可能少；
属性尽可能少；
实体类型间联系无冗余；
（ 1） 实体类型合并,例如 1,1联系的两个实体可以考虑合并；
（ 2） 冗余属性消除 。 综合成全局模式后,可能产生全局范围内的冗余属性,比如有些数据可以由其他数据推出；
（ 3） 冗余联系消除 。
3.4 逻辑数据库设计目标：将数据库概念结构转化为 特定 DBMS可处理的数据库的逻辑结构。
基本步骤：
（ 1） 初始逻辑数据库模式转换,根据若干规则进行；
（ 2） 规范化处理,减少 /消除关系模式中存在的各种异常,
改善完善性,一致性和存储效率：
确定规范级别；
实施规范化处理；
（ 3） 模式评价功能评价：规范化后的关系模式集合是否支持所有用户的所有的应用要求,及用户需要访问的所有属性；
性能评价：逻辑记录等为基础；
（ 4） 模式修正根据现实世界的应用环境和用户的要求进行相关修正,
例如增加,分解,合并关系模式 。
从 ER模式导出初始数据库模式处理需求ER模式 DBMS特征关系模式规范化模式评价用 DBMS语法描述是否修正进入物理设计阶段初始逻辑数据库模式转换：
符合 E-R 图的数据库可以表示成若干表的集合,
对每一个实体集及联系集都有一个唯一的表，该表的名字就是对应实体集或联系集的名字,
每个表有若干列 (一般对应于属性 ),列有唯一的名字,
E-R 图转换成表格式是从 E-R 图导出关系数据库设计的基础,
强实体集转换到具有相同属性的表,包含所有简单属性和其复合属性的简单子属性，略去复合属性本身。
实体集表示为表
– E.g,给定带有复合属性 name ( 组成属性为 first-name 和 last-name )
的实体集 customer,对应的表具有两个属性
name.first-name 和 name.last-name
实体集 E 的多值属性 M 用一个单独的表 EM 表示
– --表 EM 具有对应于 E 的主键的属性以及对应于 M 的属性
– E.g,employee的多值属性 dependent-names表示为表
employee-dependent-names(employee-id,dname)
– 多值属性的每个值映射到表 EM 中的单独行
E.g.,主键为 John 的雇员实体及其受赡养者 Johnson 和 Johndotir
映射到两行,
(John,Johnson)
(John,Johndotir)
实体间联系的变换：
（ 1） 一个 m:n联系转换为一个关系模式 。 与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性 。
而关系的键为各实体键的组合 。
Employee ProjectsWorks_on
timeEmployee-id Project-id
Table,works_on( employee-id,project-id,time)
（ 2） 一个 1:n联系可以转换为一个独立的关系模式,也可以与 n端对应的关系模式合并 。 如果转换为一个独立的关系模式,则与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性,而关系的键为 n端实体的键 。
branch loanLoan-branch
Branch-name Loan-numberamount
Table,loan( loan-number,amount,branch-name)
（ 3）一个 1:1联系可以转换为一个独立的关系模式（部分参与），也可以与任意一端对应的关系模式合并（全参与）。
manager departmentmanage
manager-name Dept-idDept-name
Table:
Manager(Manager-name,Dept-id)
department( Dept-id,Dept-name,manager-name)
（ 4） 三个或三个以上实体间的一个多元联系转换为一个关系模式 。 与该多元联系相连的各实体的键以及联系本身的属性均转换为关系的属性 。 而关系的键为各实体键的组合 。
course teacherS_C_T
CNO TeaNO
student NO
S_C_T(NO,CNO,TeaNO,…)
弱实体集转换：
弱实体集转换成的表还包含对应于其标识强实体集的主键的列。
Table,payment(loan-number,payment-number,payment-
date,payment-amount)
演绎 /归纳表示成表
方法 1,
– 为高层实体集构造表
– 为每个低层实体集构造表,包括高层实体集的主键和局部属性表 表属性
person name,street,city
customer name,credit-rating
employee name,salary
– 缺点,获得 employee 之类的实体的信息需要访问两个表演绎 /归纳表示成表 (续 )
方法 2,
– 为每个实体集构造表,其属性包括所有局部属性和继承来的属性表 表属性
person name,street,city
customer name,street,city,credit-rating
employee name,street,city,salary
如果是完备的,则没有必要为一般实体 (person)创建表
– 缺点,对于既是客户又是雇员的人,其 street 和 city 被冗余存储转换总结：
转换规则 1,ER图中的每一个实体映射到关系数据库中的一个表，并用实体名来命名这个表。表的列代表了连接到实体的所有简单单值属性 (可能是通过复合属性连接到实体的，但复合属性本身并不变成表的列 )。
实体的标识符映射为该表的候选键，实体的主标识符映射为主键。实体实例映射为该表的行。
转换规则 2：给定一个实体 E，主标识是 p,a是 E的一个多值属性，那么 a映射成自身的一个表，该表的列包含
p和 a，这个表的主键是 p和 a的组合。 E当然地映射成一个表。
转换规则 3：当两个实体 E和 F参与一个二元的多对多的联系 R时，联系 R映射成一个表 T。这个表包括从实体 E
和 F转化而来的两个表的主键，这些列构成了表 T的主键，
也可能还得再加入联系的属性才能构成表 T的主键。
转换规则 4：当两个实体 E和 F参与一个多对一的二元联系 R时，这个联系在关系数据库设计中不能被映射自身的一个表。假设 F表示多方，具有 maxcard(F,R)=1，那么从 F转化成的表 T中应当包括从 E转化的表的主键，这被称为 T的外键。因为 maxcard(F,R)=1,T的每一行都通过一个外键值联系到实体 E的一个实例。
转换规则 4(续 )：如果 F在 R中是全部参与的，那么意味着
T的上述外键不能取空值。如果 F在 R中是选择参与的，
那么 T中不与 E的实例相联系的行的外键可以取空值。
转换规则 5：如果给定实体 E和 F，它们的联系是一对一，
二者的参与都是部分的，那么 E和 F分别转换为表 S和 T，
并且在表 S中加入 T表的主键作为 S的外键，在表 T中加入
S表的主键作为 T的外键，有此表示 E和 F的可选参与一对一联系。
转换规则 6：如果给定实体 E和 F，它们的联系是一对一，
二者的参与都是全部的，那么最好将 E和 F对应的两个表合并成一个表，由此而避免使用外键。
转换规则 7：如果参与联系的实体数目多于两个，一般称为多元联系。对于多元联系，通常用多个不同的二元联系替代，再针对二元联系进行转换 (Oracle的数据库设计工具 Designer只处理二元联系的转换 )。
对于不能用多个不同的二元联系替代的情形，一般采用如下规则进行转换：除参与联系的实体转换为相应的表之外，联系也转换为独立的表，表中包含了参与联系的实体的主键。注：转换的表能够真实表达语义是最终目的。
转换规则 8：对于一元联系，一般不特别将联系转换成独立的表，而在参与联系的这个实体相应的表中加入联系的附加属性。例如职工实体的领导联系是一个一元联系，职工实体转换成相应的表，在此表中加入领导工号属性。联系转换为表中的一列。
– 更新异常 (Update Anomaly)：例如如果更改表所对应的某个实体实例或者关系实例的单个属性时，需要将多行更新，那么就说这个表存在更新异常。
– 删除异常 (Delete Anomaly),例如如果删除表的某一行来反应某个实体实例或者关系实例消失时，
会导致丢失另一个不同实体实例或者关系实例的信息，而这是我们不希望丢失的。
– 插入异常 (Insert Anomaly),例如如果某个实体或者实例信息随着另一个实体或实例信息的存在而存在，在缺少另一个实体或实例信息时，无法表示这个实体或者实例信息。
– 例：客户 _电话（姓名，性别，身份证号，地址，
电话号码。。。）
关系模式存在的问题：
设计目标
关系数据库设计的目标是,
– BCNF.
– 无损连接,
– 依赖保持,
如果不能达到这些,也可接受
– 缺少依赖保持
– 因 3NF引起的冗余
除了超键之外,SQL 并没有提供直接声明函数依赖的方法,
可以通过断言声明 FD,但检测代价大,
因此即使我们有一个保持依赖的分解,用 SQL我们也不能有效地检测左部不是键的函数依赖,
数据库逻辑设计全过程
假设给定了模式 R
– R 可能是经转换 E-R图到表而生成的,
– R 可能是单个包含 所有 属性的关系 (称为全关系 ).
– 规范化将 R 分解成较小的关系,
– R 可能是某种特定设计的结果,然后再测试 /转换成范式,
数据模型的优化方法为：
1.确定数据依赖 。
2.对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
3.按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
4.按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
5.对关系模式进行必要的分解。
6.对经过规范化的关系数据库模式进行优化处理，根据需求和应用的特点，进行逻辑数据库的性能估计，并进行必要的水平和垂直分解。
规范化的优缺点优点：
消除更新异常减少数据冗余
-解决了数据完整性问题
-节省存储空间缺点：
涉及多表的子查询和表之间的联接需要更复杂的 SQL语句
DBMS的额外工作使应用程序变慢
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。
为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。
充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数
充分了解所用 RDBMS的内部特征，特别是系统提供的存取方法和存储结构
3.5 数据库的物理设计数据库物理设计确定数据库的物理结构评价数据库的物理结构逻辑结构设计数据库实施物理模型逻辑模型
关系数据库物理设计的内容
– 为关系模式选择存取方法 (建立存取路径 )
– 设计关系、索引等数据库文件的物理存储结构
物理数据库设计所需参数
－数据库查询事务（查询的关系,查询条件所涉及的属性,连接条件所涉及的属性,查询的投影属性）
－数据更新事务（被更新的关系，每个关系上的更新操作条件所涉及的属性,修改操作要改变的属性值）
－每个事务在各关系上运行的频率和性能要求物理设计步骤：
设计物理表示；
分析事务；
选择文件组织方式；
选择索引；
估计所需的磁盘空间；
设计用户视图；
设计安全机制；
考虑引入可控冗余；
监控和调整运行的系统。
设计物理表示法分析事务；
选择文件组织方式；
选择索引。
受控冗余的考虑考虑派生的数据；
同时考虑重复列或连接表。
设计安全机制设计用户视图；
设计访问规则。
监控并调整操作系统设计物理表示方法：
分析事务：理解运行在数据库上的事务的功能并分析重要的事务。
事务应用图；
事务 /表交叉引用矩阵；
将所有事务路径映射到表中；
确定哪些表最常被事务访问；
分析选出的包含了这些表的事务。
选择文件组织方式：
确定每个基本表的有效文件组织方式。（如果目标 DBMS允许）
堆
HASH
索引顺序存取方法（ ISAM）
B+树堆（无序的）：（下面情况较适合）
1）当数据批量加载到表时；
2）表只有几页长；
3）每当访问表时都要检索表中的每条记录；
4）当表有其他的访问结构时，例如索引键，则堆存储可用来保存空间。
当仅访问表中的选定记录时，堆文件不合适。
HASH：（在下面情况下并不适合）
1）当记录是基于 Hash字段值的模式匹配进行检索时。
（例如检索成员号以‘ M2’开始的所有成员）
2）当记录是基于 HASH字段值的范围进行检索时。
3）当记录是基于一个其他列而不是基于 HSAH列检索时。
4）当记录是基于 HSAH字段的一部分进行检索时。
5）当 HSAH列被经常更新时。
ISAM（索引顺序存取方法）：
支持基于准确键匹配、模式匹配、值的范围和制定的部分码。
B+树：
支持基于准确键匹配、模式匹配、值的范围和指定的部分键。其的索引是动态的，随着表内容的增加而增加。
确定数据库的存储结构
确定数据库物理结构的内容
– 1,确定数据的存放位置和存储结构
关系
索引
聚簇
日志
备份
– 2,确定系统配置确定数据的存放位置
影响数据存放位置和存储结构的因素
– 硬件环境
– 应用需求
存取时间
存储空间利用率
维护代价这三个方面常常是相互矛盾的
基本原则
– 根据应用情况将
易变部分与稳定部分
存取频率较高部分与存取频率较低部分分开存放，以提高系统性能例：
数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。
如果计算机有多个磁盘，可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。
可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
确定系统配置
DBMS产品一般都提供了一些存储分配参数
– 同时使用数据库的用户数
– 同时打开的数据库对象数
– 使用的缓冲区长度、个数
– 时间片大小
– 数据库的大小
– 装填因子
– 锁的数目
– 等等
系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要根据应用环境确定这些参数值，以使系统性能最优。
在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
选择索引：
目标是确定添加索引是否会改善系统性能。
应该选择如下列来排序或群集索引记录：
经常用于连接操作的列；
在表中经常按某列的顺序访问记录的列。
受控冗余的考虑：
目标是确定如何处理派生数据并确定是否放松规范化规则引入受控冗余数据来改善系统性能。
通常如果性能达不到要求，并且表的更新率较低，查询率较高，则降低规范化就是可行的。
但需要考虑下述因素：
降低规范化使实现更复杂；
降低规范化经常会牺牲灵活性；
降低规范化可能加快检索速度，但会降低更新速度。
考虑派生数据：
确定怎样处理派生数据。（总量、总和等）
计算：
存储派生数据以及与派生它的数据操作保持一致的额外费用；
每次在需要时进行计算的费用。
当系统的查询语言不能简单地运用运算法则来计算派生列时，存储派生列就更加合适。
同时考虑重复列或连接表：
目标是确定是否通过放松规范化规则，以受控的方式引入冗余来改善系统的性能。
降低规范化的一些通常情况：
合并一对一关系；
复制一对多关系中的非键列来减少连接；
复制一对多关系中的外键列来减少连接；
复制多对多关系中的列来减少连接；
引入重复组；
合并查找表和基本表；
创建提取表。
为每个视图构建逻辑数据模型为局部逻辑数据模型创建并检查表只有一个视图？
构建并检查全局逻辑数据模型将全局逻辑数据模型转换成目标 DBMS
对性能有要求？
设计物理表示法受控冗余的考虑对安全性有要求？
设计安全机制监控并调整操作系统是是是否否否数据库实施
– 用 DDL定义数据库结构
– 组织数据入库
– 编制与调试应用程序
– 数据库试运行
应用程序开发的主要工作：
–应用程序设计：应用程序设计主要包括事务设计和用户界面设计。
事务代表了现实世界的事件，事务设计包括事务使用什么数据，事务要做什么，事务的输出，
事务的使用频度。事务有检索事务、更新事务、
混合事务之分。
用户界面设计要易于掌握、操作直观。
应用程序开发
应用程序开发的主要工作：
–应用程序编写
–组织数据入库
–应用程序的调试与试运行
维护阶段的任务包括：
–维护数据库的安全性和完整性：检查系统安全性是否受到侵犯，及时调整授权和密码，实施系统转储与后备，发生故障及时恢复。
–监测并改善数据库性能：对数据库的存储空间状况及响应时间进行分析评价，结合用户反应确定改进措施。
–必要时对数据库进行重新组织和重新构造。
–根据用户要求对数据库现有功能进行扩充。
主要由 DBA协助完成。
思考题：
１设公司的工程项目管理子系统需要对以下信息进行管理：
工程项目：有项目编号,项目名称和项目地址等属性；零件：有零件编号,零件名称,颜色,重量等属性；供应商：供应商编号,供应商名称,地址等属性 。 供应商供给工程项目一定数量的零件 。 完成以下设计：
（ １ ） 画出此子系统的 E_R图；
（ ２ ） 将 E_R图转换成相应的关系模式,使得每个关系模式至少是 3NF；
指出每个关系模式的主键。
