信息管理系统设计论文指导 (计算机应用与软件工程)
前言
本篇文章主要给于计算机应用与软件工程的本科生毕业在写信息管理系统的毕业设计论文的一些建议与案例。该篇所有注意事项与内容均采用复旦大学计算机系老师（李大学、韩光、夏宽理）给出的如何写信息管理系统毕业设计论文的文档。我只是将老师的文档整理到一起方便需要写论文的同学来使用该文档。后续我也将会把个人的毕业论文发布到blog中（预计在2021年11月份发出），该文档包括了我的毕业论文以及我如何从软件层面实现毕业设计。该项目大部分功能没有完成，但是足以应对毕业论文中各个模块的截图以及需要在论文中展示的部分代码。论文可以说是对于大学所学的专业知识的一种总结吧，在论文中几乎用到了大部分的所学知识。可以说几乎没有一个知识是没有用的，但是写毕业论文也不用太害怕，所用到的知识也不会太深。
论文选题与前期注意事项
1. 论文的选题方面基本介绍
1、论文选题必须是论述一个具体信息管理系统的设计和实现。
2、论文论述内容必须完整，论文结构应该与论文样例基本一致。论文的格式、字体，字号和章节编号形式也与样例相同。为此，学生在撰写论文之前，必须认真阅读论文辅导资料，参考样例确定自己论文的结构。
3、指导老师一般只会审阅论文中的数据流程图或UML图、数据库设计中的实体描述、联系描述、E-R图、关系模式和数据库表。其它部分内容，指导老师一般不仔细审阅这些内容。
4、论文指导流程如下：
（1）、在看了论文指导课后，在要求的日期内，向指导老师报告自己的论文题目，让老师审核论文选题是否妥当并听取老师的建议。
（2）、组织结构图、业务流程图，数据流程图中的关联图、系统顶层图，系统一层图和二层图（或UML图）。
（3）、数据字典、HIPO图、IPO图。
（4）、数据库设计：确认系统要管理的实体，实体的基本属性，实体之间的联系、E-R图、关系模式和数据库表。
（5）、最后，提供完整的论文，让老师审阅，听取老师的修改意见。
2. 论文选题的三种项目样板
一、进销存的几种实现方案
1、最简单的方案-零售进销存，客户购买商品，付款后立即取商品走人。
库存管理依据销售信息修改库存。
2、稍难一些方案-付款给提货单，客户自己到仓库提货。
库存管理依据销售信息和提货确认单修改库存。
3、较难一些方案-付款给购买凭证，商店通过物流给客户送货。
库存管理依据销售信息和物流送货回执修改库存。
4、更难一些方案-为库存管理增加盘点功能。
考虑到库存数量因为种种原因而损耗，至某个特殊时间点，库存实际数量由仓管员指定。库存管理依据盘点信息更新库存。
二、图书流通的几种实现方案
1、最简单的方案-借阅和归还。
库存管理依据借阅和归还信息修改库存。
2、稍难一些方案--借阅、归还和预约。
库存管理依据借阅和归还信息修改库存。如果不能当时借阅，产生预约借书信息。有人归还，或有新书购入系统产生提示信息，由管理员通知预约人来借书。
3、较难一些方案-增加赔付功能。
丢失或损坏需要赔付。
三、单位器材流通的几种实现方案
1、最简单的方案-申领和归还。
库存管理依据申领和归还信息修改器件的状态。
2、稍难一些方案--申领、归还和申购。
库存管理依据申领和归还信息器件状态。如果不能当时申领，产生申购信息。。
3、较难一些方案-申领、归还和申购，申领和申购要有审核，并且丢失或损坏需要报损。
3. 办公自动化与信息管理系统比较（不要搞混淆）
办公自动化是利用计算机管理业务处理的流程，主要能对信息作录入、存储和查询等处理，大大提高信息处理业务的效率。在办公自动化系统中，通常不特别考虑信息之间的关联性。信息管理系统除能对信息作录入、存储和查询等处理功能外，更能对信息按业务要求能作自动加工处理。在信息管理系统中，各条信息之间会有一定的关联。
办公自动化系统可以不用数据库，用Excel表格就可以完成其功能；而信息管理系统如不用数据库，则很多功能就无法实现。论文要求设计一个信息管理系统，而不是一个办公自动化系统。
4. 论文选题的注意点
论文选题期间请先注意以下几点，以便节省为选题而多次与指导老师联系，还是无法确定，希望能参考老师的建议，能尽快准确完成选题。
1、多看几遍老师的论文指导视频课件，仔细领会老师讲解的内容和其中的提醒、建议、时间节点要求。
2、选择的题目要注意体现管理信息系统的管理功能，体现出管理信息系统所应该具有的业务处理功能（包括业务管理和数据加工）。这些管理功能会反映在数据流图中，包括处理模块的划分和向下层的逐级分解。
3、是一个信息管理系统，而不是办公自动化系统。选题时先想一下，你要做的系统是不是主要是建表和查表？是不是除了界面，用Excel就可以做到的？如果是 ，那就不是一个论文要求的管理信息系统，因为选题内容过于简单，以后就会发现在画数据流图时除顶层图外，已经无需做进一步步分解了。
4、不要选自己完全不了解的题目，如功能需求不知道，内部如何运作不熟悉的项目。
5、不要选项目内部运作非常繁杂，而基本逻辑又相对简单的项目。
6、不能搞财务系统，财务系统必须经国家财经部审核，财务系统中要避免信息之间有多对多联系。
7、如果是管理药品或食品的进销存系统中，物品的属性中要有批号和保质期，还必须要有对超过保质期的药品或食品的处理，不同批号和保质期的药品或食品的库存量不能简单累计。
这里列出一些论文题目供大家参考。
1、XXX###进销存信息管理系统
2、XXX办公设备信息管理系统
3、XXX图书馆信息管理系统
4、XXX学籍信息管理系统
5、XXX培训信息管理系统
6、XXX设备信息管理系统
7、XXX物品租赁信息管理系统
5. 各类信息管理系统包含的主要模块
1、进销存
各种商品进销存，确定一类（种），如一类（种）电子产品，一类（种）生活用品等。
建议不要选药品或食品。
主要模块包括销售管理、采购管理、库存管理和统计分析
2、办公设备管理
办公设备申领管理，采购管理，库存管理和统计分析。
3、图书管理
读者管理，图书借/还管理， 图书采编管理，图书库存管理和统计分析。
4、学籍管理
学生管理，学生选课管理，教学计划管理，教师管理，教学管理。
5、培训管理
学员管理，培训计划管理，教师管理，教学管理。
6、设备管理
设备申领管理，资产借用/归还管理，物品采购与编码管理、库存管理和统计分析。
7、XX物品租赁信息管理系统
客户管理，物品租赁/归还管理，物品采编管理，物品库存管理和统计分析。
论文中要到的各种图以及术语介绍
1. 数据流图部分
数据流图是结构化系统分析的工具。它既可以表达数据在系统内部的逻辑流向及存储，又可以表达系统的逻辑功能和数据的逻辑变换。数据流图既能表达现行人工系统的数据流程和逻辑处理功能，也能表达自动化系统的数据流程和逻辑处理功能。数据流程基本符号：外部项、数据流、处理逻辑（加工）、数据元素和数据存储。
数据流图包含：
关联图，顶层图，一层图，二层图……
系统关联图案例
1. 外部项
外部项又称外部实体，是指不受系统控制，在系统之外的事物或人。是系统数据的外部来源或去处；也可以是另外一个数据处理系统，向该系统提供数据或接收来自该系统向它发出的数据。
2. 数据流
数据流用单箭头表示数据流动的方向，并给予以字母F开头的编号命名，并给出编号代表的数据流的意义。数据流可以由某一个外部项产生，也可以由某一个处理逻辑产生，还可以来自某一个数据存储。一般来说，数据流可以在数据流箭头的上方加以简单的描述。一般不允许用双向箭头表示数据流。
3. 处理逻辑（加工）
处理逻辑对数据的变换方式有两种：
A、变换数据的结构
B、在原有数据内容基础上产生新的数据内容
可以用一个长方形框表示处理逻辑。用标识部分、功能描述部分表示。
标识部分用于惟一地标识一个处理逻辑，以区别于其它逻辑。一般用数字编号表示主处理逻辑，编号下再接子编号，表示某个处理逻辑被进一步分解后某个处理逻辑下的某个子处理逻辑等。
功能描述部分是处理逻辑必不可少的部分。用一句非常简单的话，直接表示这个处理逻辑要做的事，即它的逻辑功能。在逻辑的功能描述部分中没有主语，只有动词和宾语。
执行这项功能的主体可能是某一个部门，也可以是某一个人或计算机程序，它们被看作处理逻辑的执行者。
一个加工一定会有数据流进入加工,也有数据流从加工流出。不允许只有数据流出，或只有数据流进的加工。
4. 数据元素
数据元素是数据最小组成单位，是不可分的数据单位。数据元素是数据流或数据存储中的基本成分。
5. 数据存储（文件）
数据存储用长方条表记，在长方条内部写上该数据存储的名称。用作标识的编号一般用英文字母D和数字组成。同外部项一样，允许在一张数据流程式图上重复出现相同的数据存储，以避免数据流线的交叉，这时应在重复的数据存储符号的左侧再加一条竖线。
一个处理逻辑可能要从数据存储中读出某些数据，或者可能把一些数据存入到某个数据存储中，甚至修改数据存储中的某些数据，那么就得用数据流将处理逻辑和数据存储联结起来。
只出或只进的数据存储不必在数据流图中不画出。
2．数据流图的分解
编制数据流图，采用自顶向下扩展逐层分解。首先是系统关联图，给出外部实体与即将开发的管理信息系统之间的数据流（从外部实体流入系统、从系统流向外部实体）。回答系统从外部世界得到什么，系统将给外部世界是什么。从关联图分解得到顶层图，又从顶层图分解得到一层数据流程图，再分解出二层数据流程图。在分解过程中，随着更具体和更详细，新的数据流和数据存储被引入，但在关联图中提及的那些数据流是不能再增加，也不允许被减少。
在上述分解过程中，上层的一个处理逻辑可能被分解成多个更具体的处理逻辑，新的数据存储和数据流被引入。如此逐一分解扩展，直至不需要再分解为止。
模块分解案例图
特别提示
3. 数据词典
数据词典，既用于描述数据流和数据存储的详细逻辑内容，也可用于描述外部项和处理逻辑的某些数据特性。数据词典把数据的最小组成单位看作数据元素，若干个数据元素组成数据结构。它通过对数据元素和数据结构的定义，来描述数据流和数据存储的逻辑内容。
1. 数据元素
数据元素是数据的最小组成单位，也就是不可分的数据单位。在数据词典中，对数据元素的定义包括以下五项内容：
（1）数据元素的名称
（2）在其他场合下的别名
（3）取值的范围和取值的含义
（4）数据元素的长度
（5）在何处出现
2. 数据结构
在数据词典中，数据结构是用来对数据之间的组合关系进行定义的，完全是一种逻辑的描述。一个数据结构可以由若干个数据元素组成，也可以由若干个数据结构组成，还可以由若干个数据元素和数据结构混合组成。
在数据结构中，对数据结构的定义包括以下几项内容：
（1） 数据结构的名称
（2） 数据结构的组成
3. 数据流
数据流是系统内传输的信息。在数据词典中对数据流的定义要包括以下五项内容：
a)数据流的来源
b)数据流的去向
c)数据流的组成
d)数据流的流通量
e)高峰时期的流通量
4. 数据存储
数据存储也是数据流的来源或去向之一。在数据词典中，对数据存储定义的内容简单地给予以下描述：
（1） 数据存储的名称及其编号
（2） 流入/流出的数据流
（3） 数据存储的组成：数据结构
5. 处理逻辑
处理逻辑的表达工具有判断树、判定表、结构化语言等。在数据词典中，对处理逻辑的定义有以下的内容：
（1）处理逻辑在数据流程图内的名称和编号。处理逻辑的名称应该反映它的逻辑功能
（2）对处理逻辑简单的描述
（3）处理逻辑的输入和输出
（4）对处理逻辑的主要功能描述，可用结构化语言简单地概括其逻辑功能
处理逻辑在数据词典中的表达应该按“输入-处理-输出”的顺序排列。
6. 外部项
外部项的数量反映了系统的独立性程度，以及人机界面设计的合理性。外部项的个数应尽可能少。外部项在数据词典中的定义包括以下两项内容：
(1)外部项的名称
(2)有关的数据流
4. 其他的注意事项
1、关联图中提及的外部项、与外部项连接的数据流，在数据流程图的分解中不可以增加，也不可以减少。
2、数据存储与外部项之间不可以直接连接。
3、要保持各层成分的完整性和一致性。下层数据流图中，上层图中的数据流和数据存储必须继续出现；并可出现只限于下层专用的的数据存储，或数据流。
4、加工和数据存储，一定有数据流入，也有数据流出。不会只有流入，没有流出；也不会有只有出，没有入的加工。
5、数据存储环节作为两个加工的界面。一般来说，两个加工不能直接用数据流相连。数据存储之间不得出现未经加工的数据流。
6、同一流入数据流不可以重复向系统流入多次。流入和流出的数据流不可以同名。
7、关联图出，数据流必须有名称和意义说明，并且在下层数据流图中不能改名。
5. 编写论文时容易犯得错误
一、数据流图（DFD）的规范性问题：
1、关于外部项
● 外部项是系统的数据来源和归宿。系统由哪些外部项提供数据，和哪些数据流向外部项，在关联图上就表示系统有哪些外部项，有哪些数据从某外部项流入，和向哪些外部项流出数据。在数据流图进一步分解时，无论分解到哪层，都不允许再多出别的外部项或少了一些外部项；从外部项流入的数据流，和从系统流出的数据流都 不能增加和减少。
● 在数据流图分解时，无论分解到哪层，所涉及的外部项的名称要与关联图上外部项的名称一致。例如：关联图上的名字叫“仓储部”，下层图变成“仓管部”，虽然意思相同，但这是不允许的。
● 假设关联图上有某个外部项，但在后面的数据流图分解时没有用到该外部项，这也是不允许的，说明该外部项与系统无关。
● 在数据流图分解时，无论分解到哪层，如果某个处理模块可以被某个外部项访问，那么该模块的父模块（在上一层图中）必然要存在与该外部项连接的数据流。
● 在任何一层的数据流图中，外部项都不可以直接访问存储（即外部项不可以与数报春存储直连）。
2、关于数据流
● 在关联图上，明确确定了外部项向系统输入的、从系统读取的数据流，包括数据流的个数、名称、编号。在数据流图分解时，无论分解到哪层，都不允许再多出关联图上没有出现的数据流。
● 在数据流图分解时，无论分解到哪层，用到某数据流时，该数据流的名称、编号、方向要与关联图上取的名称、编号和流向保持一致。
● 处理模块与数据存储之间的数据流不要编写数据流名称和编号（因为存储本身已经可以反映该数据流的组成），但要标明方向（读、写、读和写）。数据流方向在上下层数据流图间要一致。例如，本层图是写某数据存储，下层图却没看到哪个模块向其写，或是变成了只读等等。
3、关于处理模块
● 切记每个加工（处理模块）需要的已知数据，或是外部项的输入数据流，或是别的加工产生的数据存储。一个加工不能没有输入而产生输出，也不能只有输入没有输出。
● 不可以出现处理模块到处理模块间的直连，中间要有数据存储 。
● 处理模块与外部项间的数据流是否与上层图的标示相符。
● 处理模块对某数据存储的访问，如果该存储在上层图出现过，则要检查本处对该存储的访问类型（读、写、读和写）是否与上层图的标示一致。
4、关于数据存储
● 数据存储不可以与外部项直连。
● 不可以出现存储到存储间的直连，中间要有处理模块。
● 在数据流图中，一个数据存储何时出现，掌握一个原则：
在某层数据流图中，如果一个数据存储要被该层多个（2个及以上）处理模块访问（读或写），则该数据存储要出现在该层图上。
如果要访问其上层图中出现的数据存储，则该存储要出现在该层图上。如果一个数据存储只被某一个模块内部访问，则该数据存储在该模块做进一步分解时按上述原则决定是否出现。
● 下层图访问上层图出现过的数据存储时，其编号、名称、访问类型（读、写、读和写）要与上层图相一致。
● 一个数据存储不该只有写者而没有读者（写了何用？）。
反之，一个数据存储不该只有读者而没有写者（数据何来？）
除非数据是直接来自或去往另外一个系统，这种情况我们先不考虑。
二、HIPO图的规范性问题：
HIOP图容易画，掌握如下规则：
最上面的方框内（只有一个方框）填系统的名称。
第二行各方框内分别对应数据流图（以下简称DFD）顶层图中各处理模块的名称。（注意：模块的数量和模块名字要与DFD顶层图中的模块数量与名字一致。）
第三行的方框是对第二行各方框的细化展示，对应各DFD一层图的处理模块。
第四行的方框是对第三行各方框的细化展示，对应各DFD二层图的处理模块。
三、实体描述、联系描述，ER图，关系模式的规范性问题：
1、数据库模式设计步骤：
（1）确定系统要管理的数据实体。
（2）确定每个实体的属性，注意，实体暂时不设主键属性。
（3）分析数据实体之间的各种联系。注意联系也可能有属性，例如采购联系，采购日期是采购联系的属性之一，能明确表示这个联系的发生时间。
（4）用一张E-R图表示步骤3的结果。
（5）利用转换规则，得到关系模式，为每个模式设定主键和外键。
（6）对关系模式作一些必要的优化。
例如：将采购部、销售部、仓库模式合并为部门模式（表）；
将不同部门的员工合并为员工模式（表）。
【注：在ER图上不要用优化后的模式来表示实体，因为ER图上要反映不同类实体所代表的不同角色。】
（7）为每个模式给出数据库表。在数据库中，必须为每个属性标出是否是主键属性、是否是外键属性，以及该属性可否为空等状态。并且必须要有一个主键属性。
2、需要注意的是：
● 每个实体一般是形成一张表的（即形成一个关系模式），但有部分实体可以进行优化合并（见上述三、1、（6）条中的说明），合并形成一张表。
● 按转换规则，每个多对多的联系是占一张表的。
● 核查最后形成的关系模式，是否都包含了上述表。
● 在ER图上，实体和联系都不需要标出属性。
● 检查一下数据库中的表，各属性的数据类型选择和取值范围是否合理。
四、处理逻辑的合理性问题：
1、数据流图的设计步骤：
管理信息系统的主要作用之一就是业务处理（代替原来的某些跑腿、电话、手工操作等工作方式。例如：网上申请，网上审批，自动排课等。）、数据处理（加工）、数据存储、统计分析。
管理信息系统的设计有不同的方法，其中结构化设计方法（SD）是一种自顶向下、逐步求精的方法。与普通程序设计中使用SD方法的不同之处是：有时根据下层处理模块的需要反过来会对上层提出部分调整需求。
对于管理信息系统，首先根据系统要实现的范围与目标，确定系统要实现哪几项功能。
根据要实现的几项功能，确定需要分哪几个大的功能模块来处理，从而产生DFD顶层图。
一个大的功能模块一般分解成若干个子功能模块，不同的子模块完成不同的功能，从而产生各模块的一层图。同样的方法，产生各子模块的二层图。
2、需要注意的是：
● DFD中，是否完全反映了系统想要实现的功能。
● 功能模块的划分是否合理，层次是否清晰，是否便于系统的维护和功能修改，是否会出现因修改一个功能模块的功能牵一发而动全身。
● 功能逻辑是否合理和清晰。可以把自己假想为系统的使用者（以不同的角色）进行体验、判断。
● 当发现某处理模块需要新增与某外部项的数据流时，逐级修改上层DFD的数据流，直到关联图。
● 一般来讲，统计分析模块是管理信息系统应该具有的功能。鉴于毕业设计时间紧张，该模块在DFD中不要求做进一步分解，分析功能也不做要求。但同学们要清楚：不只是总经理，有些角色也会使用该模块查询相关统计信息的，所以该模块会读一些存储的。同学们给出少部分就可以了。
论文简单版案例（以主要容易出错的部分为例）
1、组织结构图
要建立信息管理系统，就必需知道当前系统的组织机构设置情况和组织机构中各部门之间的隶属关系。通常用组织结构图来描述当前系统组织机构和各部门的隶属关系。所谓组织结构图就是一个行政单位分成部门，及各部门之间的关系。用矩形框表示组织机构中的一个部门，用上下连线表示隶属关系。以下是2个组织结构图的样例。
图1.1 组织结构图样例1
图1.2 组织结构图样例2
注：组织结构图的一个部门的称呼可以有中心、部、处、科、室、组等。部门之间只有上、下级关系，用无向的连线联结。注意上下级两部门不能用相同称呼，如不能都是处，在处之下可以是科、组等。
2、关联图
数据流图分析的第一步根据管理信息系统建设的总体要求，确定系统的外部项，即系统数据的数据来源和去处。通过分析，掌握本系统的外部项和输入输出数据流，绘制系统的关联图。以下是2个关联图的样例。
图2.1 一个进销存信息管理的关联图
外部项数据流统计：
采购部：流入1条，流出1条。客户：流入1条，流出1条。供应商：流入1条，流出1条。仓管部：流入1条，流出3条。
对系统的运行过程作以下约定：
1、 首先由采购部提出采购订单，系统以订货合同给供应商。
2、 采购部发出采购订单的依据之一是系统向采购部提示的缺补货汇总信息。
3、 供应商依据采购合同向单位发货，以到货通知形式向系统报告到货商品和数量。
4、 客户向系统给出销售订单，系统给客户提贷单。
5、 系统的库存管理，依据到货信息修改库存；依据销售信息修改库存，并可能产生缺货信息（销售数量小于库存量）或产生补货信息（库存量小于预先设定的最低库存量）。
图2.2 一个物业信息管理的关联图
注：画关联图时，首先是确定系统必须有的外部实体，再是各外部实体进出的数据流。必须保证进出数据对系统是平衡的，即进入的数据是系统中某些加工要用的；出来的数据是对进入系统的某些数据作某种处理得到的结果。例如，进入的是学生的单科成绩，出来的有学生成绩单。
有关关联图中数据流说明如下:
F1：报修申请信息； F9: 查询响应信息；
F2：维修安排信息； F10：收费一览信息 ；
F3：物业基本信息（业主、房屋、员工信息）； F11：综合统计信息；
F4： 仪表（水表、电表、煤气表）数据信息； F12：业主交款信息；
F5： 报修汇总信息； F13: 付款通知信息；
F6： 维修一览表信息； F14: 业主投诉信息；
F7: 物料领用信息； F15: 投诉汇总信息；
F8: 库存量信息； F16: 物料入库信息
F17：催款通知信息 F18: 施工情况信息
F19: 维修通知信息
从系统关联图可以看出：
业主向本系统提供报修申请信息（F1）,得出报修汇总信息（F5）给管理员,而后管理员输入维修安排信息（F2），并产生维修通知信息（F19）给维修员,而维修员向系统提供施工情况信息（F18），最后通过从本系统获得维修一览表信息（F6）。
系统管理员可由维修中所用的物料领用信息（F7）及物料入库信息（F16）提交本系统进行管理，从而通过本系统查询获得物料库存量信息（F8）。
对于每月每个业主（住户）的仪表（水表、电表、煤气表）信息（F4）及维修所产生的费用，按照收费标准信息，计算出精确费用，并产生收费一览信息（F10）、付款通知信息（F13），随后业主向系统提交业主交款信息(F12),如业主因各种不同原因未能在规定时间内交款，则系统输出催款通知信息(F17)，以告知业主。
系统还可以对物业基本信息（业主、房屋、员工信息）（F3）和业主投诉信息(F14)进行处理，而分别获得查询响应信息(F9)和投诉汇总信息(F15)。
另外，本系统支持总经理对有关数据的统计分析功能（F11）。
3、顶层图
在系统关联图的基础上，根据管理信息系统的实际运行情况，划分出若干基本信息管理功能模块，并明确各功能之间的联系，绘制出数据流程图的顶层图。
以下是2个顶层图的样例。
注：画顶层图时，首先是确定系统需要分解的功能模块，一般以3-4个为宜。顶层图中关联图中提及的处部实体、数据流都要出现，同时会出现许多数据存储。另约定：
1、 加工不能直接相连，必须中间经过数据存储。
2、 任一加工不能没有进入的数据流，也不能没有出来的数据流。
图3.1 图2.1的顶层图
加工数据流统计：
P1采购管理 流入4条，流出4条。
P2销售管理 流入3条，流出3条。
P3库存管理 流入3条，流出4条。
P4统计分析 流入4条，流出1条。
销售部门根据客户的订购要求产生了F5销售订单流入P2销售管理处理，查询D2库存文件，当库存不足时产生D5缺货信息，流入P1采购管理，经F2缺/补货汇总表到采购部进行采购；
当库存充足时产生D4出库单流入P3库存管理，同时对D2库存文件进行修改，经F8出库通知单给仓管部，同时产生F6提货单给客户。出库后若低于最低存则产生D6补货信息，流入P1采购管理，经F2缺/补货汇总表到采购部进行采购；
采购部的F1采购订单流入P1采购管理处理，产生F3订货合同给供应商。
供应商的F4到货通知流入P1采购管理，产生D1到货信息和入库单。D3入库单，流入P3库存管理，同时修改D2库存文件，流出F7入库通知单给仓管部。
仓管部输入F9统计要求信息，流入P4统计分析，查询D2库存文件，D4出库单，D3入库单，产生F10统计报表至仓管部。
从图上可以看出整个系统总体上划分为销售管理 ，采购管理，库存管理和统计分析四大部分。
销售管理根据客户的销售订单，及时进行销售操作事宜；采购管理根据销售管理产生的缺货信息，进行商品的采购事宜；库存管理根据销售管理发出的出库单和采购管理发出入库单更新库存文件和及时发出䃼货信息。统计分析根据输入的统计要求信息，对库存文件，入库单，出库单进行统计分析以能更好的了解公司的经营情况。
图3.2 图2.2的顶层图
顶层数据流图仅从总体上反映了物业管理系统的信息联系。从图上可以看出整个物业管理系统的项目信息管理功能从总体上可分为七个功能模块,其分别如下:
1)基本物业信息管理(P1)
2)报修维修管理(P2)
3)仪表数据管理(P3)
4)物料管理(P4)
5)收费管理(P5)
6)投诉管理(P6)
7)统计分析管理(P7)
以下对本系统被划分以上各功能模块进行简单扼要描述：
对一个小区物业管理系统而言，基本的物业信息（包括住户、房屋信息）模块(P1)是本系统管理的基础，因为小区的管理都是基于该小区的房产资源而产生的，而物业管理产生基础，是小区内业主的详细资料处理。有了上面的功能模块对基本的信息处理后，就能实现实质性的物业管理，即报修维修管理(P2)、仪表数据管理(P3)、物料管理(P4)、收费管理(P5)、投诉管理(P6)等，这些功能模块构成了小区物业管理的主体。最后，设置统计分析管理(P7)以便物业公司领导层对整个小区的管理信息有个全面了解。
4、一层图
顶层数据流图仅从总体上反映了公司的信息联系，还必须按照自顶向下，逐层分解的分析方法对顶层图进一步细化。以下是2个一层图的样例。
图4.1 图3.1的加工p1的一层图
加工项数据流统计
P1.1请购管理 流入3条 F1采购订单；补货信息，缺货信息
流出3条 F2缺/补货汇总表；请购单；F3订购合同
P1.2到货处理 流入2条 请购单；F4到货通知
流出2条 到货信息，入库单
出库后库存低于最低库存时产生D6补货信息，出货时库存不足时产生D5缺货信息，流入P1.1请购管理，经F2缺/补货汇总表到采购部采购。
采购部的F1采购订单流入P1.1请购管理，产生F3订购合同到供应商。
供应商由F4到货通知流入P1.2到货处理，产生D3入库单和D1到货信息
对销售管理进一步细化，得到销售管理一层数据流程图（图3.5），从图中可以看到，整个销售管理功能可分确定订货处理和发货管理两个子功能。
图4.2 图3.2的加工p1的一层图
5、E-R图和关系模式
1）一个进销存信息管理系统的E-R图和关系模式。
实体和属性
系统涉及以下8个实体，它们的属性分别如下：
1、客户（客户编号、客户名称、地址、联系电话）
2、供应商（供应商编号、供应商名称、地址、联系人、联系电话）
3、采购部（采购部编号、联系人、联系电话）
4、采购员（采购员号、姓名、性别、出生日期）
5、销售员（销售员号、姓名、性别、出生日期）
6、销售部（销售部编号、联系人、联系电话）
7、仓库（仓库名称、联系人、联系电话）
8、产品（产品号、产品名称、规格、单价、计量单位）
联系
1：1联系的有：
“管理”：业务员和业务部，采购员和采购部，其属性有：职务
1：N联系的有：
“存储”：仓库和商品，其属性有：数量、最低库存
“聘用”：业务部和业务员，采购部和采购员，其属性有：聘期
M：N联系的有：
“供应”：供应商和商品：其属性有：采购单号，日期，数量
M：N：P联系的有：
“采购”：采购员、供应商和商品，其属性有：采购单号、采购日期、数量、单价
“销售”：销售员、客户和商品，其属性有：销售单号、销售日期、数量、单价
E-R图
图5.1 一个进销存信息管理的E-R图
关系模式
每个关系的主码用下划线，外码用＃标出：
1、 客户（客户编号、客户名称、地址、联系电话）
2、 供应商（供应商编号、供应商名称、地址、联系人、联系电话）
3、 部门（部门编号、联系人、联系电话、员工编号＃）
4、 员工（员工编号、姓名、性别、部门编号＃、职务）
5、 产品（产品号、产品名称、规格、计量单位、单价）
6、 采购（采购单号、产品号＃、供应商编号＃、员工编号＃、采购日期、数量、单价）
7、 供应（供应号、采购单号＃、日期、数量）
8、 销售（销售单号、产品号＃、客户编号＃、员工编号＃、销售日期、数量、单价）
9、 存储（产品号＃，数量、最低库存量）
2）一个物业信息管理系统的E-R图和关系模式
实体及属性描述
主要涉及的实体及其属性如下：
- 实体集 <房产> 房产编号、物业地址、建筑面积、使用面积、房型、装修情况、售价、是否已出售、备注
- 实体集 <业主> 业主编号、业主姓名、性别、工作单位、身份证号、联系电话、银行帐号、入住时间、迁出时间
- 实体集 <员工> 员工工号、姓名、所属部门、性别、出身年月、职位、学历、入职年份、家庭地址、联系电话、电子邮件
（说明：将管理员、接待员、抄表员、维修员、发料员等实体行综合,用于存放公司所有员工信息。） - 实体集 <仪表> 仪表序号、仪表名称、型号、始用日期
- 实体集 <报修项目> 报修项目编号、报修项目名、摘要
- 实体集 <物料> 物料代码、物料名称、物料规格、单价、库存量
- 实体集 <物料室> 物料室号、物料室名、负责人、电话
实体间的联系描述
从需求分析抽取出合适的实体间联系，其描述如下：
- 拥有：实体集[业主]与[房产]之间的1:N联系，即每位小区业主可以拥有多套房产，而一套房产只属于一位业主。
- 位于：实体集[房产]与[仪表]之间的1:N联系，即一套房产中可被安装多台仪表，而一台仪表只能位于一套房产中。
- 抄录：实体集[抄表员]、[仪表]之间的N:M联系,即一个抄表员可以抄录多台仪表读数，而反之多台仪表的读数也可有不同的抄表员来记录。
- 报修：实体集[房产]、[报修项目]、[管理员]三者之间的N:M:P联系,即业主可对其所拥有的房产向不同管理人员提出多项报修项目，反之亦然。
- 安排：实体集[管理员]与[维修员]之间的M:N联系，即每个管理员可安排多名维修员上门实施维修工作，而一位维修员可被由不同管理员所安排。
- 领料：实体集[维修员]、[发料员]、[物料]三者之间的N:M: P联系,即维修员可向不同的发料员领取多种物料，反之亦然。
- 维修：实体集[维修员]与[房产]之间的M:N联系，即一位维修员向多套房产实施维修工作，而一套房产可由多个维修员来维修。
- 存放：实体集[物料]与[物料室]之间的M:N联系，即多种物料可存放于一间物料室中，而一种物料可存放在不同物料室。
- 进料：实体集[物料]、[物料室]、[物料员]三者之间的N:M:P联系,即一个物料员可以购进多种物料放入不同物料室中，反之亦然。
- 投诉：实体集[业主]、[接待员]之间的N:M联系,即一位业主可以向不同的接待员进行对各种服务的投诉，而反之一位接待员也可接受多为业主的投诉。
E-R图
图5.2 一个物业信息管理的E-R图
关系模式
上述小区物业信息系统E-R图可转换成如下关系模式：
房产 (房产编号，业主编号＃，物业地址，建筑面积，使用面积，房型，装修情况，售价，是否已出售，备注)
业主 (业主编号，业主姓名，性别，工作单位，身份证号，联系电话，银行帐号，入住时间，迁出时间)
员工 (员工工号，姓名，所属部门，性别，出身年月，职位，学历，身份证号，入职年份，家庭地址，联系电话，电子邮件)
投诉 （投诉表编号，业主编号＃，接待员工号＃，投诉日期，投诉内容，处理日期，处理结果，备注）
仪表 （仪表序号，仪表名称，型号，始用日期，房产编号＃）
抄录 (抄表记录单号，抄表员工号＃，仪表序号＃，抄表日期，上月抄见数，本月抄见数)
报修项目（报修项目编号，报修项目名，摘要）
报修 （报修单号，报修项目编号＃，房产编号＃，管理员工号＃，报修日期，摘要）
安排 （安排编号，管理员工号＃，维修员工号＃，报修申请号＃，维修地址，摘要）
维修 （维修员工号＃，房产编号＃，维修日期，报修单号＃，维修情况，完工日期）
物料 （物料代码，物料名称，物料规格，单价，库存量）
物料室 （物料室号，物料室名，负责人，电话）
领用 （领用单号，物料代码＃，维修员工号＃，物料员工号＃，数量，领用日期，摘要)
进料 （进料单号，物料代码＃，物料员工号＃，物料室号＃，数量，进料日期，摘要）
存放 (物料代码＃，物料室号＃，数量，存放位置)
★ 说明：1）其中属性中加下划线的是主键，加＃的是外键。
2）另外，经以上ER图及转换后的关系模式仔细分析，由业主、报修项目、管理员三者之间所产生的报修联系转换为关系模式（该关系模式又可称为“虚实体”）后,又可与维修关系模式产生联系，故可对维修这一关系模式做进一步修改。安排关系模式也类似地做修改。因此，修改后的维修和安排关系模式如下：
维修（维修员工号＃，房产编号＃，维修日期，报修单号＃，维修情况，完工日期）
安排（安排工号，管理员工号＃，维修员工号＃，报修单号＃，维修地址，摘要）