開發比較復雜的企業多用戶管理信息系統(MIS)，不可能不涉及到系統內多個用戶之間的數據文件的流轉、審批等功能的開發。由于企業的需求總是隨著時間推移不斷發生變化，加之各個企業內部所設置的辦公流程不盡相同，一套通用性比較好的管理信息系統應該能讓系統管理員自己定義公文轉發的流程。 
　　盡管筆者沒有機會在已參與開發了的MIS中實現出文件轉發流程自定義的功能，但是，早在2002年初就曾深入思考過這方面的設計。當時由于某些原因不能公開自己的設計思路，現在市面上已經有不少MIS產品提供這樣的功能，筆者又已離職，所以是時候把我的設計思路整理出來，和大家分享。
　　首先，讓我們分析需求，制定目標。
　　1)一般情況下，企業內的公文轉發、審批是按部門或職位來轉送，即對崗不對人。例如：某個流程的某個環節需要財務總監審批，日后財務總監換人，該流程應該不受影響。而且，流程中某個環節可能出現某個部門中的任何一人都能審批，或者需要該部門的所有人員共同審批。
　　2)流程中轉送，審批的公文一般分為文件和表單2種格式。文件格式的公文應該支持批處理，即一次可以轉發多個文件，審批時可以只退回其中某一個不合格的文件，其他的文件可以轉送到下一個環節繼續處理。表單格式的公文應該能讓用戶自己定義表單格式，確定表單中的表項。同理，表單也應該支持批處理。
　　3)流程中處理公文的動作應該能讓用戶自己定義。這樣一旦日后增加了新的處理動作，也不用修改MIS系統的底層數據建模。當然，要實現新的處理動作，還是需要在業務邏輯層編寫相應的代碼，不過和修改底層數據建模比起來，工作量要少得多。
　　4)每個流程的環節數不一定相同，應該能讓用戶設定環節數，指定公文流轉中每個環節的發送部門和接受部門，處理模式，最長等待時間。
　　5)當待處理的公文發出后，系統應該在等待時間中定期向該流程中下個環節的用戶(們)發出通知，提醒該用戶(們)及時處理，直至公文已被處理。如果超出最長等待時間，公文還未被用戶(們)處理，此次流程處理失敗。企業管理層可能會要求記錄相關信息，以便在日后業務流程重組(BPR)時參考。
　　6)某些企業由于特殊原因，在某個流程中要求實現跨環節處理。例如，該流程有6步，執行到第二個環節時要求處理后可以跳過中間三個環節，直接轉到最后一個環節等候處理。其實，這種情況下，并不一定要在技術層面上實現其靈活性，這種特例畢竟是少數。用戶只需定義一個新流程，把上面流程的第1，2，6步復制加入進來，2個流程之間用流程名來區分即可。一個優秀的系統架構設計師應該充分利用現有的工具，不要什么都自行架設開發。
　　上面的需求對靈活性要求較高，抽象化程度較深，所以在表現層和業務邏輯層的開發量較大，初期投資較多，不過開發完畢后估計不需對底層數據庫修改，即可滿足日后不斷變化的公文流轉需求。如果不需要這么高的靈活性，可以按實際項目簡化某些假設條件。下面按照上面的需求進行用例(use case)分析和數據建模。
　　1)由于流程環節的發送方和接受方是對崗不對人，我們應該先描畫出整個企業的機構設置，確定每個部門的權利職責。其中大的部門內可能有若干子部門，每個子部門內又有不同職位，負責處理相應的事務。所以，可先建立一個樹形關系的數據表來保存企業結構，然后，采用權限表和用戶組相結合的方式來保存每個部門每個職位的職能。這塊的設計思路見我之前發布的“淺談數據庫設計技巧(上)、(下)”，我在下面直接給出大致的數據表結構：
部門表(Department_table)
名稱　　　　類型　　　　約束條件　　　                    說明
Dp_id   　  int     　  無重復　　                   類別標識，主鍵
Dp_name　　 varchar(50) 不允許為空                   類型名稱，不允許重復
Dp_father   int         不允許為空                   該類別的父類別標識，如果是頂節點的話設定為某個唯一值
Dp_layer    varchar(6)  限定3層,初始值為000000       類別的先序遍歷，主要為減少檢索數據庫的次數
功能表(Function_table)
名稱　　　　類型　　　　約束條件　　　說明
f_id        int    　   無重復　　   功能標識，主鍵
f_name      varchar(20) 不允許為空   功能名稱，不允許重復
f_desc      varchar(50) 允許為空     功能描述
用戶組表(User_group)
名稱　　　　類型　　　　 約束條件　　　說明
group_id    int          無重復        用戶組標識，主鍵
group_name  varchar(20)  不允許為空    用戶組名稱
group_power varchar(100) 不允許為空    用戶組權限表，內容為功能表f_id的集合
用戶表(User_table)
名稱　　　　類型　　　　約束條件　　　說明
user_id     int         無重復        用戶標識，主鍵
user_name   varchar(20) 無重復        用戶名
user_pwd    varchar(20) 不允許為空    用戶密碼
user_type   int         不允許為空    所屬用戶組標識，和User_group.group_id關聯
　　說明：其中，按部門的不同職位設置不同權限的用戶組，如某個用戶組為“市場部業務員”，該用戶組的用戶可在流程“報銷申請”中發送報銷申請。
　　2)盡管流程中的公文分為文件和表單2種格式，但是每個文件/表單都應該有其唯一標識，名稱等屬性。所以，我們把公文抽象化，把這2種格式的公文的共有屬性提取出來建立一張公文表。
公文表(Document_table)
名稱　　　　類型　　　　約束條件　　　說明
doc_id      int         無重復        公文標識，主鍵
doc_name    varchar(50) 不允許為空    公文名稱
doc_type    char(1)     不允許為空    公文類型
　　doc_type字段用來辨別公文格式，目前只有2種格式，可設“1”表示文件格式，“2”表示表單格式。估計未來新增公文格式不會太多，所以該字段只需一位字符。文件格式的公文一般是在文件內固定好格式，我們可用一個二進制的字段直接保存整個文件的內容。文件格式的公文需要建一個表來保存相關信息，其大致數據表如下：
文件表(File_table)
名稱　　　 類型　　　　約束條件　　　說明
file_id    int         無重復       文件標識，主鍵
file_name  varchar(50) 不允許為空   文件名稱
file_value binary      不允許為空   文件內容
……
　　表單格式的公文要讓用戶自己定義表單格式，確定表單中的表項。有兩種方法來實現：
　　①每當用戶建立一個新格式的表單時，就新建立一個表，把用戶輸入的表單表項當作該表的字段。這種方式的優點是表單查詢速度較快方便，業務邏輯層的開發量較小。缺點是不太靈活，如果企業所使用的不同格式的表單較多(>20種)，整個數據庫的結構顯得比較混亂，而且大部分表單中都有相同的字段，這樣也增加了數據冗余。這種方式的數據建模如下：
表單總表(Sheet_table)
名稱　　　　類型　　　　約束條件　　　說明
sheet_id    int         無重復        表單標識，主鍵
sheet_name  varchar(50) 不允許為空    表單名稱
table_name  varchar(20) 不允許為空    表單子表名，如Sub_table1/Sub_table2
表單子表1(Sub_table1)
名稱　　　類型　　　約束條件　　　說明
sub_id    int       無重復        表單子表標識，主鍵
option1   varchar   不允許為空    表單表項1
option2   varchar   不允許為空    表單表項2
option3   varchar   不允許為空    表單表項3
……

[1] [2]  下一頁