04数据流图和数据库分析与设计下打印版本.docx

04数据流图和数据库分析与设计下打印版本.docx

《04数据流图和数据库分析与设计下打印版本.docx》由会员分享，可在线阅读，更多相关《04数据流图和数据库分析与设计下打印版本.docx（18页珍藏版）》请在冰豆网上搜索。

04数据流图和数据库分析与设计下打印版本

软件工程之数据流图（DFD）

数据库分析与设计

主讲：

邓少勋

比特培训

2015年上

第1节软件工程之数据流图和数据字典

1.1数据流图的基本成分

数据流图主要由4种成分（加工、数据流，数据存储文件、数据源点或汇点）组成，如表1.1所示：

表1.1数据流图基本成分

符号

名称

说明

加工

在圆中注明加工的名字与编号

数据流

在箭头边给出数据流的名称与编号，注意不是控制流

数据存储文件

文件名称为名词或名词性短语

数据源点或汇点

在方框中注明数据源或汇点的名称

1.2分层数据流图

设计数据流图时，先画顶层数据流图（上下文数据流图），再细化为0层数据流图，然后将0层细化为1层数据流图，将1层细化为2层数据流图，……。

一个招聘信息管理系统的分层数据流图案例如下：

1.顶层数据流图（上下文数据流图）

在顶层数据流图中，整个系统就用一个加工表示，从该图只能看出系统和外部实体之间的数据流交互关系。

招聘信息管理系统的顶层数据流图如图1.1所示。

图1.1顶层数据流图

2.0层数据流图

0层数据流图是对顶层数据流图中加工进行细化，将顶层数据流图中的加工细化为数据存储文件、1号加工、2号加工等。

招聘信息管理系统的顶层数据流图细化后对应的0层数据流图如图1.2所示。

可看出图1.1中的加工“招聘系统”被细化为图1.2中的加工1、加工2和“评估结果表”、“未录用的应聘者表”两个存储文件及相应的数据流图，即图1.2中虚线框住的部分。

图1.2是对图1.1的细化，图1.1称为父图，图1.2称为子图。

容易看出，流入和流出图1.2中虚线框住的部分的数据流与流进和流出图1.1中加工“招聘系统”的数据流是一致的，这称为子图和父图的平衡。

图1.20层数据流图

3.1层数据流图

1层数据流图是对0层数据流图的细化。

招聘信息管理系统的0层数据流图细化后对应的1层数据流图如图1.3所示。

在图1.3中，加工1.1和加工1.2是对父图1.2中加工1的细化，加工2.1、2.2和2.3是对父图1.2中加工2的细化。

图1.2中数据流“决策”由图1.3中“谢绝决策”和“录用决策”两条数据流组成。

虽然子图的数据流和父图的数据流在数量上不平衡，但是含义上却是平衡的，数据平衡指的是含义上的平衡。

图1.31层数据流图

1.3数据流图的基本原则

在单张DFD中，必须满足以下原则

⏹一个加工的输出数据流不能与输入数据流同名，即使它们的组成成分相同（流进和流出存储文件的数据流除外）

⏹数据流必然有一头是加工,数据流不能存在于外部实体与外部实体之间，也不能存在于外部实体和数据存储文件或数据存储文件之间；

⏹保持数据守恒。

一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据；

⏹每个加工必须既有输入数据流，又有输出数据流；

⏹流向/流出数据存储文件的数据流名可以省略不写。

1.加工需要避免的几个现象

⏹“黑洞”：

一个加工只有输入数据流，没有输出数据流；

⏹“奇迹”：

只有输出流没有输入数据流

⏹“灰洞”：

无法从输入数据流经过加工得到输出数据流。

在父图与子图之间，必须满足以下原则

⏹保持父图与子图的平衡。

父图中某加工的输入（输出）数据流中的数据必须与它的子图的输入（输出）数据流中的数据在数量和名字上相同;

⏹加工细节隐藏。

根据抽象原则，在画父图时，只需画出加工和加工之间的关系，而不必画出各个加工内部的细节;

⏹均匀分解。

应该使一个数据流图中的各个加工分解层次大致相同。

其它应该注意的原则

⏹简化加工间关系。

加工间的数据流越少，各加工就越相对独立目；

⏹适当地为数据流、加工、文件、源/宿命名，名字应反映该成分的实际意义，避免空洞的名字;

⏹忽略枝节。

集中精力于主要的数据流，而暂不考虑一些例外情况、出错处理等枝节性问题;

⏹表现的是数据流而不是控制流;

⏹在整套数据流图中，每个文件必须既有读文件的数据流又有写文件的数据流，但在某一张子图中可能只有读没有写或者只有写没有读。

例：

根据数据流图的设计原则（子图），阅读如图1.4所示的数据流图，找出其中的错误之处。

图1.4带错误的部分数据流图

错误如下：

⏹外部实体A和B之间不能存在数据流；

⏹外部实体A和数据存储H之间不能存在数据流；

⏹加工2的输入/输出数据流名字相同；

⏹加工4只有输入，没有输出；

加工5只有输出，没有输入。

1.4DD（DataDictionary）数据字典

数据字典（DataDictionary,简称DD）就是用来定义数据流图中的各个成分的具体含义的，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。

它和数据流图共同构成了系统的逻辑模型，是需求规格说明书的主要组成部分。

1.4.1数据字典的内容以及格式

在定义数据流或数据存储组成时，使用的符号如表1.2：

表1.2数据字典中的符号

举例：

定义数据流组成和数据项。

机票=姓名+日期+航班号+起点+终点+费用

姓名={字母}

航班号=“Y7100”..“Y8100”

终点=[上海|北京|西安]

1.4.2数据字典条目

数据字典有以下四类条目：

数据流、数据项、数据存储、基本加工。

1.数据流条目：

数据流的定义，通常列出该数据流的各组成数据项。

⏹数据流名称：

订单

⏹别名：

无

⏹简述：

顾客订货时填写的项目

⏹来源：

顾客

⏹去向：

加工1“检验订单”

⏹数据流量：

1000份/每周

⏹组成：

编号+订货日期+顾客编号+地址+电话+银行账号+货物名称+规格+数量

2.数据存储条目：

数据存储条目是对数据存储的定义，其定义格式如下：

⏹数据存储名称：

库存记录

⏹别名：

无

⏹简述：

存放库存所有可供货物的信息

⏹组成：

货物名称+编号+生产厂家+单价+库存量

⏹组织方式：

索引文件，以货物编号为关键字

⏹查询方式：

要求能立即查询

3.数据项条目：

数据项条目是不可再分解的数据单位，其定义格式如下：

⏹数据项名称：

货物编号

⏹别名：

G-No，G-num，Goods-No

⏹简述：

本公司的所有货物的编号

⏹类型：

字符串

⏹长度：

10

⏹取值范围及含义：

第1位：

进口/国产

第2～4位：

类别

第5～7位：

规格

第8～10位：

品名编号

4.加工条目：

用来说明DFD中基本加工的处理逻辑的，其定义格式如下：

⏹加工名称：

查阅库存

⏹编号：

1.2

⏹激发条件：

接收到合格订单时

⏹优先级：

普通

⏹输入：

合格订单

⏹输出：

可供货订单、缺货订单

⏹加工逻辑：

根据库存记录

IF订单项目的数据<该项目库存量的临界值

THEN可供货处理

ELSE此订单缺货，登录，待进货后再处理

ENDIF

第2节数据库分析与设计

在数据库分析与设计中，主要涉及到的数据模型有：

概念数据模型、逻辑数据模型和物理数据模型。

1.概念数据模型

也称信息模型，是从数据语义的角度来抽象，面向用户、面向现实世界的观点来对数据和信息建模。

概念数据模型主要用来描述现实世界的概念化结构，与具体的数据库管理系统无关，主要用于数据库设计阶段。

2.逻辑数据模型

从数据的组织结构角度来抽象，并按计算机系统的观点对数据建模，逻辑数据模型与采用的数据库管理系统有关，主要用于DBMS的实现。

用概念数据模型表示的数据必须转化为逻辑数据模型表示的数据才能在DBMS中实现。

因此，逻辑数据模型既要面向用户，也要面向实现。

常见的逻辑数据模型有：

层次模型、网状模型、关系模型、面向对象模型和对象关系模型等。

3.物理数据模型

描述由数据库管理系统支持的、面向计算机系统的、数据在系统内部的表示方式和存取方法，是对数据最低层的抽象。

物理数据模型的具体实现是DBMS的任务，是数据库设计人员的职责，一般用户可不考虑物理级的细节。

物理数据模型不仅与DBMS有关，而且与操作系统和硬件有关。

概念模型在考题中主要集中体现为对实体联系图（E-R图）的考查，而逻辑模型则主要考查关系型数据库，物理模型是数据库在计算机中的实际物理存储形式，本课程主要讲解概念模型和逻辑模型。

2.2某公司销售信息管理系统需求描述

甲公司的经营销售业务目前是手工处理的，随着业务量的增长，准备采用关系数据库对销售信息进行管理。

经销业务的手工处理主要涉及三种表：

订单、客户表和产品表。

在日常工作中，三表样式如图2.1所示：

图2.1实际工作中的工作表

为了用计算机管理销售信息，甲公司提出应达到以下要求：

产品的单价发生变化时，应及时修改产品表中的单价。

客户购货计价采用订货时的单价。

订货后，即使单价发生变化，计算用的单价也不变。

2.3系统数据库概念模型设计

2.3.1提炼需求描述得到实体型

分析图2.1中客户表，很容易得出其对应的实体型为：

客户（客户代码，客户名，地址，电话），其中“客户代码”为主码。

分析图2.1中产品表，很容易得出其对应的实体型为：

产品（产品代码，产品名称，单价），其中“产品代码”为主码。

分析图2.1订单表发现，此表比客户表和产品表都复杂得多，而初学者往往拿到这种表束手无策！

图2.2订单表可分为两部分

在图2.2中，把A部分（数量为1部分）单独提取出来，成为订单实体型：

订单（订单号，订货日期，总金额）

其中“订单号”为主码。

注意，其中A部分中的“客户代码”和“客户名”属于“客户”实体型的属性，而非“订单”实体型中的属性。

三张表分别对应的三个实体型图为：

图2.3订单实体型

图2.4客户实体型

图2.5产品实体型

2.3.2三个实体型之间的实体联系图（E-R图）

从2.2节中订单表可以看出“订单”和“产品”两实体型之间的关系是多对多的关系，而“客户”和“订单”两实体型之间是1对多的关系。

图2.6三实体型E-R图

⏹思考：

在图2.2中，“产品代码”、“产品名称”等是属于订单明细的，但为什么在如图2.6所示中，“订单明细”没有“产品代码”、“产品名称”等属性？

2.4系统数据库逻辑模型设计

2.4.1E-R图向关系数据库转换思想

1.一个实体型转换为一个关系模型，实体的属性就是关系的属性，实体的键就是关系的键。

图2.7实体型A

对应的关系模式为：

实体A（属性1，属性2，属性3）

2.一个联系是否要转换为一个关系模式，这取决于与该联系相关的实体之间的对应关系，不同的对应关系，遵循不同的转换原则：

（1）两个实体型之间的关系为1：

1关系

图2.81对1联系图

对应的关系模式为（假设此E-R图中属性1为主属性）：

实体A（属性1，属性2，属性3，属性4，属性5）

一对1:

1的E-R图转换成关系模式时至少需要1张表，联系不需要转换成关系模式。

（2）两个实体型之间的关系为1：

m关系

如图2.9所示，实体型A与实体型B的关系为1：

m的关系，假设“属性1”为实体型A的码，“属性4”为实体型B的码。

图2.91对多联系图

如图2.9对应的关系模式为：

实体A（属性1，属性2，属性3）

实体B（属性4，属性5，属性6，属性1）

在以上的关系模式“实体型B”中，“属性4”是主键，“属性1”是外键（参照到主键表“实体型A”表的主键“属性1”）。

一对1:

M的E-R图转换成关系模式时至少需要2张表，联系不需要转换成关系模式。

（3）两个实体型之间的关系为m：

n关系

图2.10多对多联系图

这里首先把图2.10个多对多的关系转换为两个一对多的关系，如图2.11示：

图2.11一个多对多对应的两个一对多联系图

转换以后的关系模式如下：

实体A（属性1，属性2，属性3）

实体B（属性4，属性5，属性6）

联系名（属性1，属性4，属性7）

一对多比多的联系，需要转换成两对1对多的联系，至少需要三张表，中间的联系需要转换为一个关系模式。

一个“多对多”的E-R图转换为对应的关系模式，至少需要3个二维关系表，E-R图中的联系要转换为相应的关系模式。

（4）实体型之间的关系为m：

n：

p关系

图2.12m:

n:

p实体联系图

图2.13两个“多对多”E-R图的简化方式图

最终的概念模型为：

实体A（属性1，属性2，属性3）

实体B（属性4，属性5，属性6）

实体C（属性7，属性8，属性9）

联系名（属性1，属性4，属性7）

1对m:

n:

p的E-R图转换成关系模式时至少需要4张表，中间的联系需要转换成关系模式。

提醒：

图2.11和图2.13所示的图并非标准的概念模型图，而是咱们为了把图2.10和图2.12所示的E-R图转换为逻辑模型而使用的一个转换图而已！

所以在实际的数据库分析与设计中，这种图是没有的，考试时千万不要画这种图，但是可以借用来作为概念模型转换为逻辑模型的一种工具，一种手段！

2.4.2销售信息管理系统逻辑模型设计

根据“2.4.1”小节讲解，针对图2.6可进行如下转换理解：

图2.14销售信息管理系统转换图

图2.14对应的逻辑模型（使用关系数据库模型）为：

客户（客户代码，客户名，地址，电话）

产品（产品代码，产品名称，单价）

订单（订单号，订货日期，总金额，客户代码）

订单明细（订单号，产品代码，数量，小计，订货序号）

去掉“订货序号”和“总金额”属性得最终的关系模型为（“订货序号”可由程序生成，因为“订单明细”表中有“小计”字段，故只能留一个）：

客户（客户代码，客户名，地址，电话）

产品（产品代码，产品名称，单价）

订单（订单号，订货日期，总金额、客户代码）

订单明细（订单号，产品代码，数量）

2.5实体型和关系模式

在概念模型中，实体型表示如下：

实体型名（属性1，属性2，…，属性n），在关系模型中，关系二维表表示如下：

关系名（属性1，属性2，…，属性n）。

两者的表示非常相似，但它们有本质的区别：

实体型不考虑实体之间的参照关系，而关系模式要实现表之间的参照关系，故关系二维表中除了包含主键字段外，还可能包含外键字段。

2.6子实体和属性类型

1.子实体

在概念模型中，一个实体可能包含1个或多个子实体，如学生实体包含班长实体、学习委员实体、支部书记实体等。

实体和子实体之间绘图方式如图2.5所示。

图2.15实体和子实体

2.属性类型

假设有学生实体Students（学号，姓名，性别，年龄，家庭住址，家庭成员，关系，成员联系电话），其中“家庭住址”记录了邮编、省、市、街道信息；“家庭成员，关系，联系电话”分别记录了学生亲属的姓名、与学生的关系以及联系电话。

现针对以上案例对属性的类别作如下分析：

⏹简单属性：

原子的、不可再分的属性。

如学生的学号、姓名、性别、年龄等属性是不可再细分的，故为简单属性。

⏹复合属性：

可以细分为更小的部分（即划分为别的属性）。

如学生家庭住址可细分为邮编、省、市、街道信息等，故家庭住址为复合属性。

⏹多值属性：

在大多数情况下，属性对应一个特定的实体都只有单独的一个值。

例如，对于一个特定的学生，其只有一个学号和姓名，这种的属性叫单值属性，但是，在某些特定情况下，一个属性可能对应一组值。

例如，案例中学生可能有0个、1个或多个亲属，那么学生的亲属的姓名可能有多个，那么案例中一个学生对应的“家庭成员、关系、成员联系电话”可能有多个，则家庭成员、关系、成员联系电话为多值属性。

为了减少数据的冗余，将数据库设计得更合理，多值属性应该单独对应一个关系模式，如案例中的家庭成员、关系、成员联系电话，再加上学生学号单独构成一个独立的关系模式为“家庭成员（成员名、关系、电话）”。

⏹派生属性：

派生属性是指通过其他属性可以计算获得结果的属性。

如给学生加上一个属性“出生日期”的话，那么学生的属性年龄可通过出生日期属性计算得到，故年龄即为简单属性，同时也为派生属性。