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

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相關功能，設計並實現了一個電子公文管理系統，探討了其總體結構及設計實現相關的關鍵內容，並通過大量實驗驗證了上述工作的有效性。該系統目前已經投入使用，執行穩定，效能良好，也在一定程度上驗證了本文工作的可行性。