业务流程图组织结构图数据流程图ER图指导资Word文件下载.docx
《业务流程图组织结构图数据流程图ER图指导资Word文件下载.docx》由会员分享，可在线阅读，更多相关《业务流程图组织结构图数据流程图ER图指导资Word文件下载.docx（14页珍藏版）》请在冰豆网上搜索。
〔1〕外部项
外部项又称外部实体，是指不受系统控制的，在系统之外的事物或人。
它表达了该系统的数据的外部来源或去处。
它也可以是另外一个数据处理系统，它向该系统提供数据或接收来自该系统向它发出的数据。
〔2〕数据流
数据流用箭头表示数据流动的方向，并给予命名。
一般采用单箭头，偶尔使用双箭头。
数据流可以由某一个外部项产生，也可以由某一个处理逻辑产生，还可以来自某一个数据存储。
一般来说，对每一个数据流可以在数据流箭头的上方加以简单的描绘；
对一些含义比较明显的数据流，就不一定作描绘。
也可以在数据流上写记号，然后另外描绘记号的意义。
〔3〕处理逻辑〔加工〕
处理逻辑对数据的变换方式有两种：
A、变换数据的构造
B、在原有数据内容根底上产生新的数据内容
可以用一个长方形框表示处理逻辑。
由三部分组成：
标识部分、功能描绘部分和功能执行部分。
标识部分用于惟一地标识一个处理逻辑，以区别于其它逻辑。
一般用数字编号表示主处理逻辑，编号下再接子编号，表示某个处理逻辑被进一步分解后某个处理逻辑下的某个子处理逻辑等。
功能描绘部分是处理逻辑必不可少的部分。
它用一句非常简单的话，直接表示这个处理逻辑要做的事，即它的逻辑功能。
在逻辑的功能描绘部分中没有主语，只有动词和宾语组成。
执行这项功能的主体可能是某一个部门，也可以是某一个人或计算机程序，它们被看作处理逻辑的执行者，书写在长方框的底部。
功能执行部分同标识部分一样，不是必须的，只是作参考用，通常是不写出的。
〔4〕数据元素
数据元素是数据的最小组成单位，也就是不可分的数据单位。
数据元素是数据流或数据存储中的根本成分。
〔5〕数据存储〔文件〕
数据存储用长方条表记，在长方条内部写上该数据存储的名称。
用作标识的编号一般用英文字母D和数字组成。
同外部项一样，允许在一张数据流程式图上重复出现一样的数据存储，以防止数据流线的穿插，这时应在重复的数据存储符号的左侧再加一条竖线。
一个处理逻辑可能要从数据存储中读出某些数据，或者可能把一些数据存入到某个数据存储中，甚至修改数据存储中的某些数据，那么就得用数据流将处理逻辑和数据存储联结起来。
3.数据流程图的分解
编制复杂的数据流程图，最好的方法是采用自顶向下扩展逐层分解。
首先是系统关联图，给出外部实体与即将开发的计算机管理信息系统之间的数据流。
哪些数据流从外部实体进入系统，又有哪些数据流从系统输出给外部实体。
关联图答复系统从外部世界得到什么，系统将给外部世界又是什么。
从关联图分解得到顶层图，又从顶层图分解得到一层数据流程图，再分解出二层数据流程图。
在分解过程中，随着更详细和更详细，新的数据流和数据存储被引入，但外部世界输入到系统，系统输出到外部世界，在关联图中提及的那些数据流是不能再增加，也不允许被减少的。
在上述分解过程中，上层的一个处理逻辑可能被分解成多个更详细的处理逻辑，新的数据存储和数据流被被引入。
如此逐一分解扩展，直至不需要再分解为止。
4、数据词典
构造化系统分析中的数据词典，既用于描绘数据流和数据存储的详细逻辑内容，也可用于描绘外部项和处理逻辑的某些数据特性。
数据词典把数据的最小组成单位看作数据元素，假设干个数据元素可以组成一个数据构造。
它通过对数据元素和数据构造的定义，来描绘数据流和数据存储的逻辑内容。
数据元素
在数据词典中，对数据元素的定义包括以下五项内容：
〔1〕数据元素的名称
〔2〕在其他场合下的别名
〔3〕取值的范围和取值的含义
〔4〕数据元素的长度
〔5〕在何处出现
数据构造
在数据词典中，数据构造是用来对数据之间的组合关系进展定义的，它完全是一种逻辑的描绘。
一个数据构造可以由假设干个数据元素组成，也可以由假设干个数据构造组成，还可以由假设干个数据元素和数据构造混合组成。
在数据构造中，对数据构造的定义包括以下几项内容：
〔1〕数据构造的名称
〔2〕数据构造的组成
数据流
数据流是数据构造在系统内传输的途径。
在数据词典中对数据流的定义要包括以下五项内容：
a〕数据流的来源
b〕数据流的去外
c〕数据流的组成
d〕数据流的流通量
e〕顶峰时期的流通量
数据存储
数据存储也是数据流的来源或去外之一。
在数据词典中，对数据存储定义的内容简单地给予以下描绘：
〔1〕数据存储的名称及其编号
〔2〕流入/流出的数据流
〔3〕数据存储的组成：
处理逻辑
处理逻辑的表达工具有判断树、断定表、构造化语言等。
在数据词典中，对处理逻辑的定义有以下的内容：
〔1〕处理逻辑在数据流程图内的名称和编号。
处理逻辑的名称应该反映它的逻辑功能
〔2〕对处理逻辑简单的描绘
〔3〕处理逻辑的输入和输出
〔4〕对处理逻辑的主要功能描绘，可用构造化语言简单地概括其逻辑功能
处理逻辑在数据词典中的表达应该按"
输入-处理-输出"
的顺序排列。
外部项
外部项的数量反映了系统的独立性程度，以及人机界面设计的合理性。
外部项的个数应尽可能少。
外部项在数据词典中的定义包括以下两项内容：
〔1〕外部项的名称
〔2〕有关的数据流
5、关系数据库建模
逻辑数据库的设计过程分成两个阶段。
概念形式设计
这是对给定的现实世界状态的第一层抽象〔与计算机无关〕。
逻辑数据构造设计
这是概念形式的表示，可以把它映照成一种实际的处理〔与计算机、数据模型都有关〕
第一阶段同应用领域的信息需求分析有关，用来提供非形式的需求规格说明，由此构造一个高级的数据模型。
数据库设计应先进展概念模型的设计，然后是对关系数据库的建模。
采用称之为实体联络模型的非形式模型。
它提供一种表示实体及其互相联络的自然方法。
先在第一阶段的设计策略上使用实体联络模型，然后讨论从实体-联络模型向关系模型的转换。
实体-联络的建模
实体-联络模型中的信息由以下三种根本概念级成：
实体正要被建模的对象
联络实体之间的联络
属性实体和联络的特征
形式化的实体-联络模型
形式化的实体-联络模型用图表方法表示数据的自然构造。
在图表中，用长方框表示实体集，菱形框表示联络。
联络由弧边把参加的实体连接起来，联络的对应元个数可在弧边上标出。
在完好的E-R模型中，还对每个实体和联络的属性另外列出。
键
关系R的健K是有如下性质的属性的一个子集：
〔1〕惟一的标识性，在R上，K的值惟一地标识一个元组
〔2〕无冗余性，在不破坏性质1的情况下，K中没有属性可以被删除
在同一个关系中每一个元组都是不一样的，故键总是存在的。
一个关系可以有多个候选键。
在这种情况下，必须从中选出一个作为根本的键。
组成根本键的属性称为主属性。
在任何元组中，主属性的值不可以是空的。
在关系形式中，用下划线标出主属性。
联络
在现实世界中，实体集或"
型"
之间会出现1：
1，1：
N，N：
M等复杂的联络。
例如在同类型的实体集之间或者两个以上实体集之间可以有联络。
同一实体集的实体间联络，同一实体联络指在一样实体集中不同实体之间的联络。
1：
1的同一实体联络
实体集个人实体可以与另一个成员建立婚姻关系，在一夫一妻制下是1：
1的同一实体联络。
在这个联络中，个人之间的这个联络常用婚姻状况的属性来简单表示。
N的同一实体联络
实体集雇员可以指导其他雇员，假设一个雇员指导多个雇员，指导联络是一个1：
N联络。
N：
M的同一实体联络
实体集部件可以由其他一些部件组合而成，这种情况可以由一个N：
M的同一实体联络表示。
子类型
假如实体集E1的每一个实例也是实体集E2的实例，那么E1是E2的子类型。
假如实体集E的每一个出现也是实体集E1、E2、。
、En中的仅有一次出现，那么E是E1、E2、。
、En的一个超类型。
子类型的例子是，在学院数据库中也许规定系主任是一位教授更适宜。
教授是老师的特别范畴。
同样，实体集老师和学生具有一些共同的性质，其实都可以把他们看作实体集人的不同范畴。
实体集老师和学生都是实体集人的子类型，而实体集教授是老师实体集的子类型。
另一方面，假如在数据库内实体集人的每一个实例是实体学生的一个实例或者是实体集老师的一个实例。
那么，人是学生和老师的超类型。
子类型同其超类之间的联络由一种特别的1：
1联络IS-A表示。
子类型不要求全部的，只需要部分共享超类型属性和联络。
另一方面，子类型可以有附加的，只有它才有的属性和联络。
例如，只有教授才能担任系主任等。
由此，这个联络应该在实体集教授、系之间定义。
教授共享老师的全部属性，但是可以有仅同教授相关的附加属性。
例如系主任职务。
对于需要不同用记视图的应用中，特别要用到子类型。
这在一般性和类型的层次性中是一项关键技术。
三个实体集的实体间联络
联络可以由两个或两个以上的实体集组成。
例如对关于公司、产品和销售国家等的信息，它们之间是三个实体间存存一个销售关系，且是多对多对多的。
对于给定的一对〔公司，产品〕可销售多个国家；
对于给定的一对〔公司，国家〕，会销售多种产品，由该公司出口到该国。
通常是在不可以对有关的多个实体集使用多个二元联络时才引入三元关系。
例如，假如某公司制造多个产品，而且把全部产品出口到许多不同的国家，那么可以用公司与产品之间的制造联络，以及公司与国家的出口关系代替。
一个E-R图的实例
一个小型学院有根本实体集：
系、老师、学生和课程。
它们各有属性：
系：
系名，位置
课程：
课程号，课程名称，开课学期
学生：
学生学号，学生姓名、性别、地址
老师：
老师姓名，办公室
实体间有联络：
每个系有一位系主任，有多位老师；
一个老师仅在一个系任职；
每个系开设多门不同课程；
每门课程各由一位老师授课；
一个学生可以在不同的系选修多门课程。
存在联络有：
1对1：
系与系主任〔系主任是老师〕
1对多：
系与老师、系与课程，老师与课程
多对多：
学生与课程
E-R模型转换成关系形式的根本规那么
实体集的转换
每个实体集用一个关系表示，实体集的属性被转换成关系的属性。
实体集的主键在满足惟一标识和无冗余等性质的条件下，将作为对应关系的主键。
在实体关系中，由于它与其它实体集存在联络，可能还要增加一些属性。
二元联络的转换
对联络的转换技术主要同联络的性质以及参加联络的实体集成员类有关。
相应的法那么如下：
A.强迫类型类
倘假设实体集E2与实体集E1的联络N：
1，E2的关系形式应包含E1的主属性。
例如，倘假设规定每门课程由本系授课，实体集课程是联络提供的强迫成员。
因此课程的关系形式中应包含实体集系的主属性：
课程〔课程号，系编号#，老师编号#，课程名称，开课学期〕
其中"
系编号"
是由其它关系引入的键，称为外键〔用#表示〕，表示系与课程之间的联络提供。
B.可选成员类
倘假设实体集E2是它同实体集E1的N：
1联络中的一个可选成员，那么，这个联络往往由包括E1和E2主属性以及该联络中每个属性的各个关系形式表示。
例如，图书馆的书，也许被借出或者未被借出〔假定仅将当前借出的记录在数据库内〕。
读者和书之间的联络借阅联络是1：
N的。
用以下关系形式表示这个E-R模型
BORROWER〔BNO，NAME，ADDRESS〕
BOOK〔ISBN，BNO#，TITLE〕
在关系BOOK中引入外键BNO，记下当前借出详细一本书的读者的身份号。
然而，在关系BOOK中许多元组的属性BNO的值是空的，表示对应的书处于未出借状态。
不仅仅联络的可选型会引起空值，由于实体集的某个实例的详细属性未定义，也会引起空值。
在这个例子中，可以引入另一个表示联络出借的关系，来防止空值：
BOOK〔ISBN，TITLE〕
ON-LOAN〔ISBN#，BNO#，DATE-OF-LOAN，DATE-DUS〕
这样，只有当前被借出的书才出如今关系ON-LOAN中。
假如一个联络有属性，那么，将可选联络用另一个关系是有意义的。
例如，在上例增加了出借的日期和应归还的日期。
在联络中，实体集的联络型也许是"
几乎强迫"
的，这就是说，绝大多数的元组都参加联络。
在这种情况下，容许少量空值比引入另一个关系更好。
C、N：
M二元联络
M联络一般由另一个关系形式表示。
这个关系形式由每个参加的实体集的主属性以及这个联络的全部属性一起组成。
这种变换应用于参加实体集的各种成员类。
例如实体集学生和课程之间的联络选课可以由以下形式表示：
选课〔学号#，课程号#，选课日期，理论成绩，考试成绩〕
学院数据库的关系形式
应用上述根本转换规那么，假设实体集E2与实体集E1的联络1：
1，应根据需要把E2的主属性放入关系形式E1中，或反之。
假设实体集E2与实体集E1的联络N：
M联络一般由另一个关系形式表示，这个关系形式由每个参加的实体集的主属性以及这个联络的所有属性一起组成。
得到以下学院落数据库关系形式：
系〔系编号，系名，老师编号#，位置〕
学生〔学号，姓名，姓别，地址〕
老师〔老师编号，老师姓名，系编号#，办公室号〕
在以上形式中，关系系的外键老师编号表示联络指导，以说明这个联络的成员是对系强迫的。
关系课程中的外键老师编号和系编号分别表示联络课授和提供。
课程实体集是每一个这些联络的强迫成员。
关系老师内的外键系编号表示系与老师之间的联络属于。
老师是它们的强迫成员。
最后，由M：
N联络引出关系选课。
E-R模型转换成关系形式方法的进一步讨论。
同一实体集联络的转换
同一实体集联络的转换在很大程度上根据二元联络的类型。
A.1：
1同一实体集联络
1同一实体集联络的常用例子是在实体集人的实例之间的婚姻联络。
显然，这是一种可选的联络，因为会有一些人不参加这个联络。
因此可用另一个关系形式表示这个联络：
人〔身份号，名，地址〕
婚姻〔丈夫身份号#，妻子身份号#，结婚日期〕。
必须在婚姻关系上用区分丈夫和妻子的身份号码来解决属性名冲突问题。
假定每个人只允许有一个配偶，于是丈夫身份号或者妻子身份号都可用作关系婚姻的主键。
倘假设希望存储婚姻的资料，联络便是N：
M的，而且丈夫身份号和妻子身份号一起组成键属性。
B.1：
N同一实体集联络
N同一实体集联想系的例子是雇员和上司的实体联络。
倘假设每一个雇员都有一个上司，那么就要有一个强迫联络。
它可以通过上司的键置于雇员的关系形式上来表示。
如：
雇员〔身份号，上司身份号#，雇员名〕
倘假设仅有一些雇员被指导，那么要用另一个关系表示这个联络，见如下的关系形式：
雇员〔身份号，雇员名〕
雇员上司〔身份号，上司身份号#〕
C.N：
M同一实体集联络
M同一实体集联络的例子是，一个部件是其它部件的组成零件，这个联络可以翻译成如下的关系形式：
部件〔部件号，部件名，规格说明〕
组成〔主部件号#，分部件号#，数量〕
部件关系形式对于组成联络有另一个关系。
按这个方法，它要有参加实体的键属隆。
然而，对于同一实体集的联络来说，这些键属性取自同一实体集，而且必须区分它们，以上说明组成一个大部件的每一种小部件有一定的个数。
子类型转换
子类型的关系只包含超类型的键同该子类型指定的增加属性。
例如，假设把实体集老师的子类型教授引入学院形式。
然后，这个关系形式将对教授有另一个关系，它的形式是
教授〔老师编号#，系主任头衔〕
在这个关系中，键属性老师编号是外键，它取自关系老师。
这个外键表示子类型和其超类之间的是其中之一联络。
通过这个外键，可以访问教授同其他老师共有的附加属性。
层次类型的转换得到一个代表根实体集和每个子类型的另外关系，每个关系的键是根实体关系的键，它还可以包括对所有子类型所拥有的属性。
每个子类型的关系，包含同这个键一起的隶属该子类型的属性。
于是，层次类型涉及实体集人同子类型学生和老师，以及老师的子类型的实体集教授，可由以下形式的关系形式表示：
人〔身份号，所有个人公共属性〕
学生〔身份号#，所有学生公共属性〕
老师〔身份号#，所有老师公共属性〕
教授〔身份号#，所有老师公共属性〕
身份号惟一地标识实体集伯一个实例。
关系人将对每个学生、老师和教授都有一个元组。
关系老师对每一个教授有一个元组。
三个实体集联络的转换
每一个三个实体集联络被转换成另一个关系形式，其中包括有三个参加联络的实体集的键，以及这个联络的属性。
例如公司、产品、国家三者之间存在销售联络。
在联络销售中，可能要附加每年由公司销售到有关国家的产品数量。
联络销售的键由这个联络的对应性确定。
倘假设是N：
M：
P的，那么全部三个外键作成销售的键。
然面，倘假设每个公司把它的每个产品仅出口一个国家，那么，显然仅需把公司和产品两个外键作成销售的键。
考虑这样一种情况，一些学员在导师指导下做不同的课题。
设没有一个导师可以指导任何一个做多项课题的学员；
又没有一个学员可以在多个导师指导下做一个工程。
可以用一个包括学员、导师和课题三个实体集联络指导来表示。
该联络是1：
N的，用四个关系形式表示。
作为1：
1三个实体集联络的一个例子，实体集老师、教科书和题目之间的联络。
老师给一门课程选用一本教科书，对同一门课程不同的老师选用不同的教科书，没有一个老师对不同的课程选用同一本教科书。
但是，对不同的理解，不同的老师可以选用一样的教科书。
联络使用是1：
1的，使用关系形式有三个候选键，从三中任意选出二个都可作为使用关系的键。
关系形式的标准化
使用前述方法设计的关系形式仍然会产生异常或者不协调性。
必须在实现之前解决这个问题。
这个求精过程称为标准化。
标准化理论建立在范式概念上。
按前述方法设计的关系形式，最低限度是第一范式INF。
第一范式的每个属性是一个原子，是不可分解的数据项。
这个性质是在原来的关系定义中规定的。
从原始的需求分析出发推出适宜的实体，属性和关系将会对所得关系形式上的标准程度有根本的影响。
关系形式中的任何异常或者不协调性很大程度是由于实体-联络模型的不适宜或者不正确引起的。
函数依赖
对于给定的关系R，R的属性B函数依赖R的属性A〔记作A-B〕，当且仅当对于R的两个元组，假如它们的A值相等，那么它们的B值相等。
在任何实例上，每个A的值仅惟一地有一个B的值与之对应。
实际上，属性A和B是可以组合的。
考虑以下设计欠佳的关系形式：
REPORT〔Sno,Cno,TITLE,LNAME,ROOMno,MARKS〕
元组S,C,T,L,R,M表示学生S获得C号课程的分数M，课程名称是T，该课程由老师L在R号教室上课。
假定每门课程只有一个老师，每个老师有一个教室。
这个关系存在的一些函数依赖如下：
Sno,Cno-MARKS
即一对〔Sno,Cno〕值，正好存在的一个值MARKS。
Cno-TITLECno-LNAMECno-ROOMno
对于Cno的一个给定值，正好存在TITLE、LNAME、ROOMno的一个值。
LNAME-ROOMno
每个老师正好有一个对应的ROOMno。
属性MARKS被称为完全函数八月赖于键，这是由于它依赖于组合对的键属性Sno和Cno，但不依赖于其中的任何一个。
假如关系R的属性B函数依赖于A，而不函数依赖于A的任何一个真子集，那么，属性B完全函数依赖于属性B。
属性TITLE、LNAME、ROOMno被称为部分函数依赖于健，这是由于它们仅依赖于Cno，而不依赖于Sno。
属性ROOMno被称为传递依赖于Cno，这是由于它依赖于LNAME，而LNAME又依赖于Cno。
关系形式中的这种函数依赖的部分性和传递性在处理数据库时会引起一系列的问题。
因此，在实现之前，必须把它们去除捍。
第二范式
一个数据库被称为第二范式〔2NF〕，假如它是第一范式〔1NF〕，而且每一个非主属性完全函数依赖于键。
前述定义的REPORT不是2NF，在数据处理时会引起一系列问题，这是因为：
1〕倘假设希望在数据库中插入新课程的细节，在至少有一个学生注册之前才可以执行〔不可以在主属性Sno上有空值〕。
类似地，假如希望插入一个新老师的细节及其教室号码，在他被按排上课而且至少有一个学生在这个课程注了册后，才能执行。
2〕倘假设想把课程361的名称由?
数据库技术?
改成?
数据库系统?
，那么，必须查找有Cno的这个值的每一个元组，而且全部更新它们，其实，有多少学生选修这门课程，就会有多少个元组。
3〕倘假设选修课程361的每个学生放弃该课程，除了删除相应的元组外，还要在数据库上删除这门课程的全部细节。
为了转换成第二范式，以抑制这些弊病，把这个关系分解所两部分，而且将那些部分依赖于键的属性合并成另外一个关系形式：
REPORT〔Sno,Cno,MARKS〕
COURSE〔Cno,TITLE,LNAME,ROOMno〕
这些关系属于2NF，因为在它们的每一个中，非主属性都完全依赖于键。
然而，关系COURSE由于存在如下传递依赖，所以还要进展标准化：
Cno-LNAME-ROOMno
第三范式
关系R被称为第三范式〔3NF〕，旭果它是2NF，而且不存在非主属性传递依赖于R的候选键。
更准确地说，关系是3NF，假如对每个X-A在R上成立而且A不属于X，那么X含有R的键或者A是主属性。
上述定义的关系COURSE不属于3NF，因为有依赖LNAME-ROOMno，以及LNAME不是键和ROOMno不是主属性。
这个传递依赖会引起一些异常：
a〕在安排一个新老师上一门课后，才能插入他的细节和他的ROOM
升级会员 