電子公文管理系統設計與實現

1 引言

公文是政府軍隊等各類部門請示彙報、命令下達等工作中的重要部分。傳統的公文歸檔以紙質原件為主，存放在檔案局等部門，當歸檔公文數目逐漸增多時，公文的查找就存在效率較低等缺點。尤其是當用户記不清楚公文的具體年份、標題等內容時，在紙質歸檔公文中進行基於內容的模糊查詢幾乎無法實現。另外，紙質公文的管理、維護、防腐等，也需要大量的人力物力支持。

隨着計算機硬件、局域網設施的普及以及用户計算機水平的不斷提高，當前公文的撰寫基本都是先完成電子版本，然後再打印傳達。因此，將公文的電子版進行歸檔成為可能[1-2]。實施電子公文的歸檔管理[3-4]，與傳統方法相結合，可以在幾乎不增加額外勞動量的前提下，對公文的管理、查找、維護工作起到大大的改善效果。

2 系統設計

《電子公文管理系統》就是在這樣的背景下產生的。其目的是在不改變用户公文撰寫流程的前提下，完成電子公文的歸檔、查詢等功能。此外，對歷史公文的充分借鑑，還可以提高用户公文撰寫格式的規範以及公文內容風格的一致性等。

系統採用標準的客户端-服務器模式（c-s模式），由oracle數據庫服務器[5]對電子公文的存儲、查詢提供支持。客户端軟件由delphi實現，包括公文模板管理、公文歸檔、公文撰寫、臨時公文管理、公文查詢和系統設置六大模塊，如圖1所示。

“公文模板管理”可以將常用的空白公文模板存儲到數據庫中，用户可以據此撰寫新的公文。“公文撰寫”模塊可以依據公文模板或已經歸檔的歷史公文，撰寫新的公文。用户只需修改其中的內容即可，而不用再過多關心其格式等內容，提高公文撰寫的效率。“臨時公文管理”對新撰寫的公文以及尚未定稿的公文進行管理，支持同一公文的多個不同版本，並可以將臨時公文及時上傳備份到服務器以防丟失，同時能夠方便地從其它機器閲讀修改公文。“公文歸檔”對於已經完成的公文，可以歸檔錄入數據庫，以方便將來查閲。系統提供單個公文歸檔、批量歸檔等多種歸檔方式，並能夠通過“公文自動分析”功能解析出公文中的項目，如標題、關鍵字等，減少公文歸檔的工作量，提高系統可用性和效率；同時還可以將領導簽字照片等附件一同錄入，以提高公文歸檔的完整性可用性。“公文查詢”模塊能夠對所有已歸檔的公文進行高效查詢。除了支持靈活的按照各種項目自定義條件查詢外，還支持基於內容的查詢，即可以查找內容中包含指定文字的所有公文。最後，“系統設置”模塊包括不同部門、不同級別用户的用户管理及權限控制功能，靈活的數據庫連接參數配置功能等。 3 關鍵技術 系統實現的主要難點和創新包括以下幾個方面：1）公文在oracle數據庫中的存取控制；2）公文內容的自動解析和批量歸檔；3）基於公文內容的全文檢索查詢；4）本地文檔與數據庫備份文檔的比較及版本控制。

3.1 公文在數據庫中的存取

一個公文由很多元素組成，如標題、發文機關、公文種類、年份、主題詞、引發説明、承辦説明、正文等等[2]。在數據庫中的存取有兩個方案：一是將各種元素分開存儲，用户預覽全文時再按照公文格式要求合併成一個文檔。該方案的好處是分開存儲便於用户的查詢；不足是當合成新文檔是需要考慮公文的格式要求。因為公文類型繁多，因此恢復新文檔的操作複雜，而且往往難以完全恢復原樣。第二個方案是將整個文檔採用二進制方式存儲在數據庫中。這樣的好處是文檔的恢復比較簡單，但是由於各個元素沒有分離，因此在公文的查詢方面存在不足，需要解析文檔內容並逐個分離出元素信息，效率較低，難以滿足快速、靈活的查詢需求。

通過分析比較，系統採用了一個折中方案：對於除正文以外的其它元素，如標題、發文機關、年份等，在數據庫中分別在不同字段中分離存儲，以方便用户的查詢；同時又將文檔本身進行存儲，以便於公文的恢復。該方案以一定的存儲開銷為代價，較好地照顧了查詢操作和公文恢復操作。因為除正文以外的其它元素內容很少，通過數據庫中的日期型字段、 varchar字段等即可滿足要求，因此引入的額外開銷非常小。實驗部分證明了該方法的有效性。

公文文檔存放在oracle中的blob字段中，具體是通過delphi中tblobfield類的loadfromfile()和savetofile()方法實現了數據庫的存入和讀出。

3.2 公文內容的自動解析和批量歸檔

為了解決在公文歸檔過程中手工輸入各種元素信息的效率問題，系統實現了公文內容的自動解析。根據公文格式規定，通過程序對指定的公文進行自動分析，解析出各種元素的內容，然後自動填入數據庫。

delphi提供了兩個類：twordapplication和tworddocument[3]。前者可以連接到ms word應用程序中，後者可以連接到一個word文檔。公文中的每一段、每一行以及每一個表格，都可以通過tworddocument對應的如paragraph、line

以及table對象等獲得。根據公文承辦規定中對相關元素位置、格式的定義，配合識別元素的關鍵詞信息，通過逐段逐行分析，就可以解析得到元素內容。

實現了對一個公文的解析功能，再配合findfirst、findnext以及findclose等windows的api函數的遞歸調用，就可以查找指定路徑下（包括子目錄）的所有word文檔，然後逐一對之進行解析並將分析結果入庫，就可以實現公文批量歸檔的功能。

公文內容自動解析及批量歸檔功能的實現，簡化了公文歸檔的工作量，用户只需指定文件或者路徑，系統即可自動完成剩餘工作，大大提高了公文歸檔的效率。

3.3 基於內容的全文檢索查詢

指定通過公文標題、發文機關等元素內容，查找滿足條件的公文，是基本的數據庫查詢操作，比較容易實現。但是在公文的查找中存在一類需求，即用户只記得公文的大致內容，如公文內容中包含的幾個關鍵詞，但是關於公文更詳細的內容如發文時間、發文機關名稱等並不清除。在這種情況下需要對公文進行基於內容的全文檢索查詢。

該功能的實現流程如圖2所示。對數據庫中的每條記錄，均先將對應的word文檔保存到本地，然後用delphi的tworddocument類打開。tworddocument類的content屬性為range對象，調用其ute()方法可以在該範圍內進行文本查找，功能與word應用程序中調用“編輯-查找”功能菜單一樣，不僅可以進行基本的查找，還可以通過參數控制在查找過程中是否區別大小寫、是否使用通配符等。如果匹配成功，則該方法返回true，系統為該條記錄做好標記，作為查詢結果中的一條進行顯示。當數據庫中所有的記錄都處理完後，查詢處理結束，所有被標記的記錄均為滿足條件的結果，即內容中包含指定關鍵詞的公文。

3.4 文檔版本控制

“臨時公文管理”模塊主要是將正在撰寫尚未正式定稿的公文存放到數據庫中進行備份，同時支持同一稿件在撰寫修改過程中產生的多個不同版本維護功能。文檔修改前後的比較、版本控制是這一模塊的主要技術點。

版本控制主要是通過獲取文件最近修改時間來實現的。具體來説包括以下步驟：1）系統啟動時，通過oracle中的sysdate函數取得數據庫服務器的當前時間，並將客户端時間與服務器時間進行自動同步；2）臨時公文上傳到服務器進行備份時，獲得文件的最近修改時間並保存在數據庫中的updatetime字段中；3）檢查本地文件與數據庫備份文件是否一致時，再次獲得本地文件的最近修改時間，通過與數據庫中保存的時間進行比

較完成。

獲取文件最近修改時間功能實現，主要是通過windows的api函數findfirstfile()獲得文件屬性數據，該數據的ftlastwritetime屬性即為文件的最後修改時間。值得注意的是，該屬性獲得的是用32位表示的文件時間戳，為操作系統使用。要想轉換為用户能看懂的本地系統時間，需要通過filetimetolocalfiletime()、filetimetosystemtime()以及systemtimetodatetime()函數進行轉換。

4 測試驗證

為了驗證依據上述分析設計的有效性，對已實現的公文管理系統進行了測試驗證。

4.1 實驗設置

試驗在2台pc機組成的局域網內進行。數據庫服務器的基本配置為piv 2.0g cpu，1g內存，120g硬盤，其上安裝了oracle 9i；客户端pc機配置為piii 1g cpu，512m內存，80g硬盤，安裝了oracle客户端和office XX軟件。

實驗數據集為某單位XX-XX.6產生的500個實際公文文件，大小從50k到500k不等，平均大小約為200k。在其上進行了存儲開銷比較、查詢性能、自動歸檔性能以及全文檢索性能的實驗。

4.2 實驗結果

採用三種存儲方案對公文進行存儲，考查隨公文數增加不同方案存儲開銷之間的差異，如圖3所示。其中方案一為所有元素均分離存儲；方案二為僅存儲完整的公文文件；方案三為本文采取的折中方案。

可以看出，方案一所需空間最小，方案二其次，方案三所需空間最大。這是因為，方案一僅保存了必須的文本內容，而且不同元素之間相互無重疊宂餘；而方案二存儲的完整文件除了包含字符格式、字體等信息外，還包含doc文件必須的文件格式頭等內容，因此所需空間較大。方案三在方案二的基礎上還宂餘存儲了一些元素內容，因此所需空間最大。但總體看來，方案三與方案二相比，額外所需的存儲空間並不是很大，約佔文件大小的0.5~1%左右。

三種存儲方案下普通查詢的效率和原文檔恢復所需時間分

比較別如圖4、圖5所示。可以看出，方案三普通查詢的效率與方案一幾乎沒有差別，受益於oracle數據庫管理系統的查詢性能，在實驗數據規模上返回結果的時間為毫秒級；而方案二由於需要還原文件後再進行全文檢索，所需時間較長，尤其隨着數據庫中記錄數增加所需時間也線性增加，當數據規模較大時難以滿足用户需求。而在文檔恢復方面，方案一需要將所有內容進行重組，並按照公文承辦規定設置相關元素的格式等，所需時間為秒級，而且恢復效果較差；而方案二和方案三直接從數據庫中讀取完整文檔並恢復，所需時間僅為毫秒級。

在採用第三種存儲方案實現的系統中，隨歸檔文檔數的增加，系統自動歸檔所需時間情況如圖6所示。可以看出，系統具有較高的自動分析和批量歸檔功能，平均每個文檔所需的分析歸檔時間不足1秒。因此能夠較好滿足歸檔需求。

系統全文檢索效率如圖7所示。可以看出，全文檢索所需時間與隨公文數目增加呈線性增加，平均處理每個公文所需的時間約為200毫秒。因此，當公文數目較多時，建議先通過普通查詢縮小全文檢索範圍，可以有效降低全文檢索的響應時間。

5 結束語

基於delphi和oracle數據庫，結合ms word的vba相關功能，設計並實現了一個電子公文管理系統，探討了其總體結構及設計實現相關的關鍵內容，並通過大量實驗驗證了上述工作的有效性。該系統目前已經投入使用，運行穩定，性能良好，也在一定程度上驗證了本文工作的可行性。