基于Web的团场通用业务管理系统设计

2016-10-13刘小波兵团第一师十六团2连新疆阿拉尔843018

新疆农垦科技 2016年8期

刘小波（兵团第一师十六团2连，新疆　阿拉尔　843018）

基于Web的团场通用业务管理系统设计

刘小波
（兵团第一师十六团2连，新疆阿拉尔843018）

随着互联网发展战略向农业挺进，互联网+农业这种方式必定会对电商、农户、农企团场等产生深远影响，在大数据时代，数据为王，团场业务繁多且无定式，数据分散不便于管理，传统的管理系统无法应付多变的业务需求，该文讨论了基于Web的团场业务管理系统设计的必要性，通过数据库的视图机制打通数据之间的交互障碍，寻求一种更通用、更高效、更快捷获取数据的方法，其实现原理不是最优的，旨在通过讨论，达到抛砖引玉的目的。

团场；通用业务；管理系统；视图

1　团场各基层单位管理人员构成

团场基层单位一般是连队（其他类型的单位分析类似），配备连长1人，指导员1人，副连长1人或多人，技术员1人或多人，报账员1人，治安员1人，政工员1人等，管理人员数量从几个到十几个不等，管控土地面积不等，总人口（含职工）500人以内。数据流描述，不同连队管理人员分工有所不同，但业务逻辑大同小异，不关注岗位设置，只抽取出数据流，大致描述如图1所示。

图1　连队业务数据流程

矩形框内的是作物信息、农资、水电结算价格等基础数据，所有连队共用，由团级部门确定；人员信息一般由连队治安员进行维护，包括本单位常住、暂住、流动人口身份等信息，职工是它的子集，连队职工信息、土地承包信息、各类账目、物料领用处理等一般由报账员进行维护，而作物种植技术措施、管理日志及各类技术报表一般由技术人员进行维护，连级数据还要通过某种形式传输到上层管理部门如综治办、财务科、农业科等进行汇总处理形成决策依据或传输到更上层。

2　业务

一般数据处理都是通过电子表格来完成，这里把一张电子表格定义为一项业务，完成某种特定功能或任务，如单位报账员制作春播农资领用表，技术员制作棉花测产记录表，政工员制作党员花名册等等，各业务与时间相关，一项业务完成，便作为档案留存，很难再被用到，随着时间的推移，业务数量会逐年增加，但处于活动状态的一般是当年的业务。历年的业务可通过归并整理，为将来的大数据分析提供素材。

3　传统业务处理逻辑弊端

3.1在本单位内部业务处理、数据共享方面的弊端

管理人员在工作中会产生各自的业务数据，分散在不同的电脑上，查找、拷贝、编辑起来都比较麻烦，也不便于单位领导了解、查看本单位的数据信息；有些业务是在非上班时间完成的，往返上班地点进行业务处理比较麻烦，随着各团场各连队互联网的普及，这种业务处理方式效率显得有些低下；不便于数据共享，如技术员制作技术报表要用到各条田承包户的农资使用信息，需引用报账员农资领用业务中的相关数据，在讨要数据过程中可能会产生业务摩擦，不便于及时获取；数据版本不一致，如因后期减面积，报账员维护的承包信息中的承包面积有变动，而技术员不知情或没来得及或懒得修改，先前拷贝的承包面积没能同步更正，影响数据准确性；不便于数据的管理和再利用，分散在不同文件里的数据查找起来比较麻烦，要引用其中的一列或某些行列数据不方便，通过拷贝复制的方式引用数据在将来可能会出现数据版本不一致的问题。

3.2在任务分发、数据上报汇总等方面的弊端

基层单位一般通过QQ群或电子邮件实现数据上报、信息沟通等。如由团农业科发起，各连队技术员加入组建的技术员群，科室人员通过群共享文件方式把任务通过Excel表格的形式派发给各连队技术员，技术员通过实地调查收集、填写数据，最后通过电子邮件或群文件共享，上交各类数据，科室人员再把各单位上报来的数据进行汇总、整理等。比较重要的数据还需要打印出纸质版，由本单位主要领导签名确认上交。上述处理方式中，也有些弊端，如：数据格式不统一，不同操作人员因技术水平或喜好不同，上交的数据格式不统一，有时候比较混乱；汇总麻烦，因数据分散在不同的文件里，科室人员要实现把各单位上交的数据汇总，比较繁琐，负担重，出错概率大。隐私风险，如通过QQ群共享文件，一些个人信息如身份证号、联系方式等有被人偷窥或利用的风险。

4　业务管理系统基础功能设计

在功能设计上，业务管理系统要避免上述弊端，充分利用发达的互联网资源，实现随时随地协同办公的需求。

4.1关联关系分析

基层单位管理人员组成一个团队，团队各成员产生的数据自然共享，这些数据只有一个版本，由数据生产者保证其正确性，并只能被数据生产者（或由其授权团队中的某个人）进行编辑，数据源端修改，数据引用端自动修改，简化描述如下：

由a成员产生的A业务，会被a或b成员的X业务所引用，也就是说，X要依赖于A，X是A的子集，有简单关系：X∪A=A，X∩A=X，对应于SQL语言Left/Right Join、Inner Join，用关系型数据库很容易描述上面的关系。

这种依赖关系无处不在，构成了此系统的基础。如职工信息业务依赖于人员信息业务，承包信息业务依赖于人员信息业务和地块信息业务，作物种植业务又依赖于承包信息业务和作物信息业务等等，各业务之间通过主键进行自由链接（交集或并集），从而在不同业务中获取想要的关联数据，为方便主键链接，可定义根主键，其他继承自根主业务的业务自动继承根主键属性。

4.2业务中各列类型界定

引用列，即此列数据引用自其他业务，有2种形式：（1）前关系引用列：在创建新业务时，引用1个或多个既定业务，这些既定业务之间通过主键链接起来，然后把所需列数据加入到新业务中，此类型的引用列是不可编辑列。（2）后关系引用列：在创建新业务时，引用1个或多个既定业务，新业务与既定业务，或既定业务之间事先不存在关联关系，而是在数据录入时建立起关系，此类型的引用列是可编辑列。比如要建立承包信息业务，需要引用人员信息业务和地块信息业务，此两者间不存在关系，在数据选择录入时才建立起某个人和某个地块的承包关系。计算列，由公式计算得来，不可编辑列，可参与计算，需避免循环计算的问题。数字列，可编辑的原始数据列，存放数字，可参与计算。文本列，可编辑的原始数据列，存放文本或日期，日期类型可参与计算。上述4种列类型构成了业务数据基础，根据需要，还可以界定其他一些列类型。

4.3业务中数据、格式、表头实现分离

为便于对数据进行各种操作，业务中实现数据、格式、表头的分离，用户只需关注数据，格式在输出时实行统一控制。

4.4业务的创建

基层单位管理人员在本单位Web平台上创建自己的业务，设计表头、列类型或引用本单位其他管理人员既有的数据，科室人员登录管理平台创建分发业务，分发给具体单位，接受到分发任务的基层单位在规定时间内填写、提交。

4.5业务数据的编辑、汇总、导入和输出

数据一次性加载完毕，数据编辑缓存在客户端浏览器本地数据库中，可撤销或提交，数据提交到服务器端后不可再撤销。数据汇总在客户端完成，可根据任一列进行汇总。通过POI［1］组件实现业务数据和常用的xls或xlsx类型电子表格文件相互导入和输出，导入时实现全盘导入或匹配更新导入等方式，输出后可利用电子表格软件的灵活性作更为复杂个性化的数据操作。

4.6权限控制

系统设置系统管理员和单位管理员，系统管理员负责各单位权限分发，系统参数和公共基础数据的维护，单位管理员负责本单位用户信息、基础数据等维护。各单位成员登录后进入本单位系统界面，单位内部各成员产生的业务数据由本人维护，自然共享，可授权其他成员进行修改。

5　系统实现原理

5.1系统概述

本系统Web服务采用Apache Tomcat，数据库服务采用MySQL Community Edition（GPL），MySQL5.7实现了对JSON的原生支持［2］，为可伸缩、多级的表头设计提供了极大便利，前端业务数 JQuery JavaScript JQuery JavaScript Library开源的jqGrid插件［3］并进行改写，前、后台之间通过AJAX方式进行通信。

5.2实现原理及性能分析

系统充分利用MySQL的视图机制，一切业务皆视图，视图之间通过主键进行链接，任务分发通过分发视图来完成，后端的计算任务通过MySQL视图来处理，前端的计算任务通过JS计算引擎来处理，MySQL视图机制通过merge算法［4］最终实现对物理表数据的访问。

随着时间的推移，业务量的增多，视图数量会不断增长，受限于操作系统单文件夹下文件数量以及文件系统的索引效率的影响，当视图数量达到一定级别时，文件系统索引性能下降，影响数据库服务器的操作效率，通过分库、表空间映射或转移备份不常用的业务，可以得到解决。