基于Web的團場通用業務管理系統設計

劉小波（兵團第一師十六團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］最終實現對物理表數據的訪問。

隨著時間的推移，業務量的增多，視圖數量會不斷增長，受限于操作系統單文件夾下文件數量以及文件系統的索引效率的影響，當視圖數量達到一定級別時，文件系統索引性能下降，影響數據庫服務器的操作效率，通過分庫、表空間映射或轉移備份不常用的業務，可以得到解決。

6　結論與討論

此系統雖基于連隊業務形式創建，但對于其他有相關性業務邏輯的組織形式也適用，對于特定的需求可有針對性地進行開發，在此系統基礎上，可進一步實現連隊、團場之間的互聯互通，打破空間距離限制，加強彼此信息溝通和數據共享。

［1］The Java API for Microsoft Documents Apache POI［EB/OL］. http://poi.apache.org/.

［2］The JSON Data Type MySQL Documentation［EB/OL］.http:// dev.mysql.com/doc/refman/5.7/en/json.html.

［3］A grid plugin for the JQuery Javascript library jqGrid［EB/OL］. http://www.jqgrid.com/.

［4］View Processing Algorithms MySQL Documentation［EB/OL］. http://dev.mysql.com/doc/refman/5.7/en/view-algorithms.html.

2016—06—15