電子公文管理系統(tǒng)設計與實現(xiàn)模板

1、電子公文管理系統(tǒng)設計與實現(xiàn)1引言公文是政府軍隊等各類部門請示匯報、命令下達等工作中的重要部分。傳統(tǒng)的公文歸檔以紙質原件為主，存放在檔案局等部門，當歸檔公文數(shù) 目逐漸增多時，公文的查找就存在效率較低等缺點。 尤其是當用戶記不清楚公文 的具體年份、標題等內容時，在紙質歸檔公文中進行基于內容的模糊查詢幾乎無 法實現(xiàn)。另外，紙質公文的管理、維護、防腐等，也需要大量的人力物力支持。 隨著計算機硬件、局域設施的普及以及用戶計算機水平的不斷提高，當前公文 的撰寫基本都是先完成電子版本， 然后再打印傳達。因此，將公文的電子版進行 歸檔成為可能1-2。實施電子公文的歸檔管理3-4,與傳統(tǒng)方法相結合，可以 在幾乎

2、不增加額外勞動量的前提下， 對公文的管理、查找、維護工作起到大大的 改善效果。2系統(tǒng)設計電子公文管理系統(tǒng)就是在這樣的背景下產生的。具 目的是在不改變用戶公文撰寫流程的前提下，完成電子公文的歸檔、查詢等功能。 此外，對歷史公文的充分借鑒，還可以提高用戶公文撰寫格式的規(guī)范以及公文內 容風格的一致性等。系統(tǒng)采用標準的客戶端-服務器模式（c-s模式），由oracle數(shù)據(jù)庫服務器5對電子公文的存儲、查詢提供支持?？蛻舳塑浖?delphi實現(xiàn)，包括公文模板管理、公文歸檔、公文撰寫、臨時公文管理、公文 查詢和系統(tǒng)設置六大模塊，如圖1所示?！肮哪０骞芾怼笨梢詫⒊Ｓ玫目瞻坠哪０宕鎯Φ綌?shù)據(jù)庫中，用戶可以據(jù)此

3、撰寫新的公文?！肮淖珜憽蹦K 可以依據(jù)公文模板或已經(jīng)歸檔的歷史公文，撰寫新的公文。用戶只需修改其中的 內容即可，而不用再過多關心其格式等內容，提高公文撰寫的效率?！芭R時公文 管理”對新撰寫的公文以及尚未定稿的公文進行管理，支持同一公文的多個不同 版本，并可以將臨時公文及時上傳備份到服務器以防丟失，同時能夠方便地從其 它機器閱讀修改公文?！肮臍w檔”對于已經(jīng)完成的公文，可以歸檔錄入數(shù)據(jù)庫， 以方便將來查閱。系統(tǒng)提供單個公文歸檔、批量歸檔等多種歸檔方式，并能夠通 過“公文自動分析”功能解析出公文中的項目，如標題、關鍵字等，減少公文歸檔的工作量，提高系統(tǒng)可用性和效率；同時還可以將領導簽字照片等附件

4、一同錄 入，以提高公文歸檔的完整性可用性?！肮牟樵儭蹦K能夠對所有已歸檔的公 文進行高效查詢。除了支持靈活的按照各種項目自定義條件查詢外，還支持基于內容的查詢，即可以查找內容中包含指定文字的所有公文。最后，“系統(tǒng)設置”模塊包括不同部門、不同級別用戶的用戶管理及權限控制功能， 靈活的數(shù)據(jù)庫連 接參數(shù)配置功能等。3關鍵技術系統(tǒng)實現(xiàn)的主要難點和創(chuàng)新包括以下幾個方面： 1）公文在oracle數(shù)據(jù)庫中的存取控制；2）公文內容的自動解析和批量歸檔；3） 基于公文內容的全文檢索查詢；4）本地文檔與數(shù)據(jù)庫備份文檔的比較及版本控制。公文在數(shù)據(jù)庫中的存取一個公文由很多元素組成，如標題、發(fā)文機關、公文種類、年份、

5、主題詞、引發(fā)說明、承辦說明、正文等等2 o在數(shù)據(jù)庫中的存取有兩個方案：一是將各種元素分開存儲，用戶預覽全文時再按照公 文格式要求合并成一個文檔。該方案的好處是分開存儲便于用戶的查詢；不足是當合成新文檔是需要考慮公文的格式要求。因為公文類型繁多，因此恢復新文檔 的操作復雜，而且往往難以完全恢復原樣。第二個方案是將整個文檔采用二進制 方式存儲在數(shù)據(jù)庫中。這樣的好處是文檔的恢復比較簡單， 但是由于各個元素沒 有分離，因此在公文的查詢方面存在不足，需要解析文檔內容并逐個分離出元素 信息，效率較低，難以滿足快速、靈活的查詢需求。通過分析比較，系統(tǒng)采用了一個折中方案：對于除正文以外的其它元素， 如標題、發(fā)

6、文機關、年份等，在數(shù)據(jù)庫中分別在不同字段中分離存儲，以方便用 戶的查詢；同時又將文檔本身進行存儲，以便于公文的恢復。該方案以一定的存 儲開銷為代價，較好地照顧了查詢操作和公文恢復操作。因為除正文以外的其它元素內容很少，通過數(shù)據(jù)庫中的日期型字段、varchar字段等即可滿足要求，因此引入的額外開銷非常小。實驗部分證明了該方法的有效性。公文文檔存放在oracle中的blob字段中，具體是通過 delphi中tblobfield 類的 loadfromfile()和saveto巾le() 方法實現(xiàn)了數(shù)據(jù)庫的存入和讀出。公文內容的自動解析和批量歸檔為了解決在公文歸檔過程中手工輸入各種元素信息的效率問題

7、，系統(tǒng)實現(xiàn)了公文內容的自動解析。 根據(jù)公文格式規(guī)定，通過程 序對指定的公文進行自動分析，解析出各種元素的內容，然后自動填入數(shù)據(jù)庫。 delphi 提供了兩個類：twordapplication 和 tworddocument3。前者可以連接 到ms word應用程序中，后者可以連接到一個 word文檔。公文中的每一段、每 一行以及每一個表格，都可以通過 tworddocument對應的如paragraph、line 以及table對象等獲得。根據(jù)公文承辦規(guī)定中對相關元素位置、格式的定義，配合識別元素的關鍵詞信息，通過逐段逐行分析，就可以解析得到元素內容。 實現(xiàn)了對一個公文的解析功能，再配合 f

8、indfirst 、findnext 以及巾ndclose 等windows的api函數(shù)的遞歸調用，就可以查找指定路徑下(包括子目錄)的所 有word文檔，然后逐一對之進行解析并將分析結果入庫，就可以實現(xiàn)公文批量 歸檔的功能。公文內容自動解析及批量歸檔功能的實現(xiàn)，簡化了公文歸檔的工作量，用戶只需指定文件或者路徑，系統(tǒng)即可自動完成剩余工作，大大提高 了公文歸檔的效率?；趦热莸娜臋z索查詢指定通過公文標題、發(fā)文機關等元素內容，查找滿足條件的公文，是基本的數(shù)據(jù)庫查詢操作，比較容 易實現(xiàn)。但是在公文的查找中存在一類需求，即用戶只記得公文的大致內容，如公文內容中包含的幾個關鍵詞，但是關于公文更詳細的內

9、容如發(fā)文時間、發(fā)文機關名稱等并不清除。在這種情況下需要對公文進行基于內容的全文檢索查詢。 該功能的實現(xiàn)流程如圖2所示。對數(shù)據(jù)庫中的每條記錄，均先將對應的word文檔保存到本地，然后用 delphi的tworddocument類打開。tworddocument類的 content屬性為range對象，調用其()方法可以在該范圍內進行文本查找，功能 與word應用程序中調用“編輯-查找”功能菜單一樣，不僅可以進行基本的查找， 還可以通過參數(shù)控制在查找過程中是否區(qū)別大小寫、是否使用通配符等。如果匹配成功，則該方法返回true ,系統(tǒng)為該條記錄做好標記，作為查詢結果中的一 條進行顯示。當數(shù)據(jù)庫中所有的

10、記錄都處理完后，查詢處理結束，所有被標記的 記錄均為滿足條件的結果，即內容中包含指定關鍵詞的公文。文檔版本控制“臨時公文管理”模塊主要是將正在撰寫尚未正式定稿的公文存放到數(shù)據(jù)庫中進行備份，同時支持同一稿件在撰寫修改過程中產生的多個不同版本維護 功能。文檔修改前后的比較、版本控制是這一模塊的主要技術點。版本控制主要是通過獲取文件最近修改時間來實現(xiàn)的。具體來說包括以下 步驟：1)系統(tǒng)啟動時，通過oracle中的sysdate函數(shù)取得數(shù)據(jù)庫服務器的當前 時間，并將客戶端時間與服務器時間進行自動同步；2)臨時公文上傳到服務器進行備份時，獲得文件的最近修改時間并保存在數(shù)據(jù)庫中的updatetime字段中

11、；3)檢查本地文件與數(shù)據(jù)庫備份文件是否一致時，再次獲得本地文件的最近修改 時間，通過與數(shù)據(jù)庫中保存的時間進行比較完成。獲取文件最近修改時間功能實現(xiàn)，主要是通過windows的api函數(shù)find巾rstfile()獲得文件屬性數(shù)據(jù)，該數(shù)據(jù)的ftlastwritetime屬性即為文件的最后修改時間。值得注意的是，該屬性獲得的是用32位表示的文件時間戳，為操作系統(tǒng)使用。要想轉換為用戶能看 懂的本地系統(tǒng)時間，需要通過 filetimetolocalfiletime() 、 filetimetosystemtime() 以及 systemtimetodatetime() 函數(shù)進行轉換。 4測試驗證為了驗

12、證依據(jù)上述分析設計的有效性，對已實現(xiàn)的公文管理系統(tǒng)進行了測試驗證。實驗設置試驗在2臺pc機組成的局域 內進行。數(shù)據(jù)庫服務器的基本配置為piv cpu , 1g內存，120g硬盤，其上安裝了 oracle 9i ;客戶端pc機配置為piii 1g cpu , 512m內存，80g硬盤，安裝了 oracle客 戶端和office XX軟件。實驗數(shù)據(jù)集為某單位產生的500個實際公文文件，大小從50k到500k不等，平均大小約為200k。在其上進行了存儲開銷比較、查 詢性能、自動歸檔性能以及全文檢索性能的實驗。實驗結果采用三種存儲方案對公文進行存儲，考查隨公文數(shù)增加不同方案存儲開銷之間的差異， 如圖3

13、所示。其中方案一為所有元素均分離存儲；方案二為僅存儲完整的公文文 件；方案三為本文采取的折中方案?？梢钥闯?，方案一所需空間最小，方案二其次，方案三所需空間最大。這是因為，方案一僅保存了必須的文本內容，而且不同元素之間相互無重疊冗余；而方案二存儲的完整文件除了包含字符格式、 字體等信息外，還包含doc文件必須的文件格式頭等內容，因此所需空間較大。 方案三在方案二的基礎上還冗余存儲了一些元素內容，因此所需空間最大。但總體看來，方案三與方案二相比，額外所需的存儲空間并不是很大，約占文件大小 的1%左右。三種存儲方案下普通查詢的效率和原文檔恢復所需時間分比較別如圖4、圖5所示?？梢钥闯?，方案三普通查詢

14、的效率與方案一幾乎沒有差別， 受益于oracle數(shù)據(jù)庫管理系統(tǒng)的查詢性能，在實驗數(shù)據(jù)規(guī)模上返回結果的時間 為毫秒級；而方案二由于需要還原文件后再進行全文檢索，所需時間較長，尤其隨著數(shù)據(jù)庫中記錄數(shù)增加所需時間也線性增加，當數(shù)據(jù)規(guī)模較大時難以滿足用戶 需求。而在文檔恢復方面，方案一需要將所有內容進行重組， 并按照公文承辦規(guī) 定設置相關元素的格式等，所需時間為秒級，而且恢復效果較差；而方案二和方 案三直接從數(shù)據(jù)庫中讀取完整文檔并恢復，所需時間僅為毫秒級。在采用第三種存儲方案實現(xiàn)的系統(tǒng)中，隨歸檔文檔數(shù)的增加，系統(tǒng)自動歸檔所需時間情 況如圖6所示?？梢钥闯?，系統(tǒng)具有較高的自動分析和批量歸檔功能， 平均每個 文檔所需的分析歸檔時間不足1秒。因此能夠較好滿足歸檔需求。系統(tǒng)全文檢索效率如圖7所示。可以看出，全文檢索所需時間與隨公文數(shù)