内部管理系统详细设计方案
二○○二年七月二十七日
设计方案简介
本设计方案是为内部管理程序开发而编写的，它包括了系统可行性研究，系统模块设计，
模块的具体流程设计，一些需要进一步讨论或者研究的问题，需要的资料与硬件，数据表的
定义等。但它没有包含关于编码的更多主题。例如编码的约定，注解的格式等。尽管这些问
题对于实现这个系统都是非常重要的，但因为是设计方案它没有被包括在其中。
整个设计方案的大致目录如下：
一．内部管理系统项目方案（第 2 页－第 20 页）
1． 项目开发背景 （第 2 页）
2． 项目可行性研究 （第 2 页－第 6 页）
3． 系统的大致模块划分 （第 6 页－第 18 页）
3．1 市场部 （第 6 页－第 17 页）
3．1．1 系统登陆模块 （第 8 页）
3．1．2 系统设置模块 （第 8 页）
3．1．3 事件添加模块 （第 8 页－第 9 页）
3．1．4 事件查找编辑 （第 9 页－第 11 页）
3．1．5 事件参数设置 （第 11 页）
3．1．6 事件跟踪模块 （第 11 页－第 13 页）
3．1．7 人事基本管理 （第 13 页）
3．1．8 部门参数设置 （第 14 页）
3．1．9 资料票据管理 （第 14 页－第 15 页）
3．1．10 业务收入统计 （第 15 页）
3．1．11 工资参数设置 （第 15 页）
3．1．12 员工工资管理 （第 15 页－第 16 页）
3．1．13 数据加密备份模块 （第 16 页）
3．1．14 数据库管理模块 （第 16 页－第 17 页）
3．2 网管部 （第 17 页）
3．3 制作部 （第 17 页－第 18 页）
4． 数据流图 （第 19 页－第 20 页）
4．1 市场部业务数据流图 （第 19 页）
4．2 市场部工资数据流图 （第 20 页）
二．内部管理系统所需资料 （第 21 页）
三．内部管理系统所需硬件 （第 22 页）
四．数据库设计 （第 23 页－第 25 页）
1． 上层数据库设计 （第 23 页）
2． 市场部数据库设计 （第 24 页－第 25 页）
五．项目工作量估算 （第 26 页）
内部管理系统项目方案
一． 项目开发背景
为了提高公司内部管理的效率，所以需要编制一套完整的用于公司内部管理的系统。
这样一个系统可以在整个公司范围内使用，做到了公司资源的整合与共享。
二． 项目的可行性研究
1． 技术方面：
整个系统属于一个规模比较大的 MIS 系统。尽管其在组织关系上存在着很大的
复杂性，繁琐性，不确定性，但是就整个系统的技术构成上来看，它还是属于一个
数据库应用类的系统。其基本操作还是对存在数据库进行添加、删除、查找、编辑
等。所以就单纯的数据库应用来看，暂不存在太大的技术问题。
2． 经济方面：
由于系统对公司的正常运行的影响是相当大的，所以必须要设置单独的服务器
来运行这个系统。又考虑到所有计算机硬件软件都是存在出错可能的（具体到这个
系统，由于其需要不间断的运行，所以其出错的可能就会变得更大），因此整个系
统应该考虑使用双机热备份技术。使用两台服务器同时运行，一个为主一个作备份，
这样可以避免服务器故障对整个系统的影响。又考虑到这个系统是为公司内部服务
的，而且数据库设置和调试时候都必须要直接使用服务器，所以应该将服务器设置
在公司内部。纵观整个系统需要的硬件，我们认为整个项目的投资将可能是比较巨
大的。这方面，提请公司再作详细讨论。
3． 法律方面：
整个系统由于是自行开发，自行使用，所以系统本身不存在法律上的版权争议。
在服务器软件方面，应该使用正版软件，因为整个系统尽管是开发给内部使用，但
它毕竟很多部分还是要依靠 Internet 的，一旦服务器连接到 Internet 上，它的操作系
统可能会被 Microsoft 跟踪，如果不是正版软件，将不得不面临民事诉讼的风险。
4． 目前存在的问题：
目前我们觉得最大的问题仍然是数据库访问方式上的问题。和一般的 MIS 系统
不同，我们面临着更广泛范围内的数据库访问。这个范围已经不可能用局域网解决
了，但一旦使用 Internet 网，数据传输的有效性和安全性就会成为严重的问题。现
在将三种可能数据访问的方式列举如下，并逐一作分析：
a． 使用纯单机版的数据库系统
这是最简单的数据库访问方式。采用这种方式不涉及网络传输，所以无论
在哪个部门，也不管其上网设施是如何的，总能采用这种方法的。采用这种系
统后，如果要实现数据同步，必须定期将数据库全部上传（注意：这里应该是
上传整个数据库，因为采用这种方式操作的系统，它上传的时间间隔一般是比
较大的，如果记录哪些记录是更新的，在实际同步时候，将花费很多时间作整
个更新记录的比对，在记录量增大时候，这个检测的时间也会急剧增加，反而
增加了处理时间），服务器在收到整个数据库后，在服务器端运行一个特殊的
软件，用于数据的同步。然后将处理后的数据库放在一个特定的区域，客户端
可以将处理后的数据库收下来，以实现数据库同步。
整个系统采用的传输示意图如下（仅以市场部为例）：
b． 采用纯网络数据库的结构：
采用这个结构从理想的角度来看，是最适合这个系统的。因为它具有最好
的实时性，可以将当前获得的数据立即传输出去，这样其他部门也就立即可以
得知目前的业务情况。而且采用这个结构，从数据库应用角度来看，对网络底
层的传输情况不需要有太多的了解（这部分由 SQLServer 提供的网络传输协议
保证）。但是就公司目前各市场部上网情况来看，由于很多市场部采用的仍然
是 Modem 和 ISDN，不能 24 小时在线，因此再不对目前各市场部上网设备改
造的情况下，很难使用这种结构。这种结构还有一个问题是它很大程度上依赖
于中心数据库，对中心数据库可靠性和稳定性的要求相当高。
这种结构的示意图如下（以市场部为例）：
市场部
DB
总部服务器
DB
市场部
这段传输可以采用任何传
输方式，包括 FTP，Email
总部服务器上应该运行特定软
件用于数据同步，此过程可能
需要人工干预。
DB
市场部
市场部
市场部
市场部
总部服务器
DB
C．采用本地数据库和网络数据库同时使用的结构
1
：
这是这个系统最有可能采用的数据库结构。它的特点是平时数据存储在本
地数据库，以天为单位，让本地数据库和总部的一个共享数据库进行交互，以
实现数据的同步。这种方式的优点是数据因为在本地和网络数据库上共存，所
以可靠性是比较高的。而且就 Modem，ISDN 和宽带共存的情况下使用这种结
构也是比较现实的。它的缺点是：在每日用于同步的数据量大的情况下是无法
使用的，另外，即使每天用于同步的数据量并不是很大，但是本地数据库或者
网络共享数据库的存储量已经很大，这样再搜索用于需要同步的数据的时间也
将成倍增加。系统在刚投入使用时候可能速度比较快，但是存储量达到一定程
序后，系统运行速度将会急剧减慢。（根据实验，当数据记录条数达到 5 万条
以上时，完整的数据库搜索花费的时间会很长很长），而在这种系统结构下，
为了保持两者数据库的完全同步，可能要反复搜索数据库。此段时间的开销是
相当大的。
除此之外，这个结构最大的问题是：如何保证数据的完整同步。因为诸如
Modem 等上网设备，其传输过程极易由于外界干扰或者线路传输速率的突变造
成传输中断。重传这些数据可能会造成数据的重复。（比如经过检测，这次需
要上传 10 条记录，现在客户端开始上传，上传一半 Modem 断线了，所以实际
只传了五条。客户端检测到这一错误，开始重传，但实际上尽管断线仍然有五
条记录是成功传送的，重传全部必定造成重复，但是要很准确的定位具体是在
那条中断是相当困难的。这和网络传输协议里错误检测是类似的）
采用这个结构的示意图如下：
1
这里的结构和示意图 a）中的结构看上去有些相似。但其原理是完全不同的。图 a）中，需要上传的是完
整的数据库，它依靠运行在服务器端的程序对数据进行整理以达到同步的目的。而这个结构中，实际上并
不存在一个文件上传的过程，它是依靠数据库访问接口来直接实现数据交互的。数据库访问接口屏蔽了很
多网络的细节。在这个结构中，在服务器上不需要再单独运行管理程序来实现数据同步。
市场部
DB
DB
市场部
总部服务器
DB
直接数据库交互
