轉《公文轉發流程自定義的數據建模 》
開發比較復雜的企業多用戶管理信息系統(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
……
表單子表2(Sub_table2)
名稱 類型 約束條件 說明
sub_id int 無重復 表單子表標識，主鍵
option1 varchar 不允許為空 表單表項1
option2 varchar 不允許為空 表單表項2
option3 varchar 不允許為空 表單表項3
……
……
②對表單再進行一個抽象，把表單看成由若干個表單表項所組合成的一個集合。這種方式的優點是相當靈活，用戶建立新格式的表單時只用從已有表單表項中勾選出需要的表項即可，而且整個數據庫結構清晰，沒有數據冗余。缺點是開發比較復雜，工作量和上面相比高出不少，而且表單查詢速度較慢。下面是這種方式的數據建模：
表單總表(Sheet_table)
名稱 類型 約束條件 說明
sheet_id int 無重復 表單標識，主鍵
sheet_name varchar(50) 不允許為空 表單名稱
表單表項表(Option_table)
名稱 類型 約束條件 說明
op_id int 無重復 表單表項標識，主鍵
op_name varchar(50) 不允許為空 表單表項名稱
op_length int 不允許為空 表單表項長度
op_unit varchar(10) 允許為空 表單表項單位
表單信息表(Sheetinfo_table)
名稱 類型 約束條件 說明
info_id int 無重復 表單信息標識，主鍵
sheet_id int 不允許為空 所屬表單標識，和Sheet_table.sheet_id關聯
op_id int 不允許為空 表單表項標識，和Option_table.op_id關聯
info_value varchar() 不允許為空 表單信息值
3)我們可以把公文轉發的流程抽象化，看作一個實體超類。建表如下：
流程表(Flow_table)
名稱 類型 約束條件 說明
flow_id int 無重復 流程標識，主鍵
flow_name varchar(50) 不允許為空 流程名稱
flow_stepnum int 不允許為空 流程步數
flow_desc varchar(200) 允許為空 流程描述
流程中的每一步都可以抽象化成從發送方至接受方的用例，其數據建模大致如下：
處理動作表(Action_table)
名稱 類型 約束條件 說明
a_id int 無重復 動作標識， 主鍵
a_name varchar(20) 不允許為空 動作名稱
a_call varchar(50) 不允許為空 動作所調用的模塊
a_desc varchar(200) 允許為空 動作描述
說明：如果采用面向過程的開發方式，如純腳本語言，可以把每一個處理動作寫成一個函數，調用a_call字段記錄的函數，即可完成相應處理動作。如果采用面向對象的開發方式，可以用COM組件來封裝處理動作，則a_call用來記錄相應的COM組件的接口方法。如果是在.NET Framework環境下，可以采用Web服務的方式。當然，發送方、接受方以及公文標識是作為輸入參數的。
流程環節表(Step_table)
名稱 類型 約束條件 說明
step_id int 無重復 環節標識，主鍵
belong int 不允許為空 所屬流程標識，和Flow_table.flow_id關聯
setp_order int 不允許為空 所屬流程的步驟次序
sender int 不允許為空 發送方標識，和User_group.group_id關聯
receiver int 不允許為空 接受方標識，和User_group.group_id關聯
a_id int 不允許為空 處理動作標識，和Action_table.a_id關聯
a_type int 不允許為空 接受方所需的處理人數
max_wait int 不允許為空 最長等待時間
wait_unit varchar(5) 不允許為空 等待時間的單位
說明：a_type用來確定接受方所需的處理人數，“0”表示需同職位的所有人一起處理，“1”表示只需該職位的任意一名員工處理，“2”表示需該職位的任意兩名員工一起處理，依次遞推……一起處理的方式和處理動作有關，例如是投票方式，少數服從多數，還是某人有一票否決權等等。可能針對某些處理動作還得細化，進行相關的數據建模，這里我就不細分下去了。
4)下面分析公文轉發的流程環節記錄。此時相當于實例化一個流程環節的對象，發送方和接受方應具體聯系到管理信息系統的某個(些)用戶，而不是某個用戶組。每經過一環節，我們除了要保存這方面的信息，還必須保存該環節所轉發的公文，以及處理狀況等信息。而且，該環節所轉發公文數量大于等于一，所以可以參考我之前發布的“淺談數據庫設計技巧(下)”中的“簡潔的批量m:n設計”，建表大致如下：
流程環節記錄表(Step_log)
名稱 類型 約束條件 說明
log_id int 無重復 環節記錄標識，主鍵
step_id int 不允許為空 環節標識，和Step_table.step_id關聯
sender varchar(100) 不允許為空 發送用戶標識，相關用戶組的User_table.user_id的集合
receiver varchar(100) 不允許為空 接受用戶標識，相關用戶組的User_table.user_id的集合
doc_id int 不允許為空 轉發公文標識，和Document_table.doc_id關聯
batch_no int 不允許為空 批量轉發公文編號，同一流程環節轉發的batch_no相同
state char(1) 不允許為空 處理狀態
sub_date datetime 不允許為空 提交時間
res_date datetime 允許為空 處理回復時間
comment varchar(255) 允許為空 處理回復注釋
說明：
①同一流程環節轉發的batch_no和該批第一條入庫的log_id相同。舉例：假設當前最大log_id是64，接著某用戶一次轉發了3件公文，則批量插入的3條流程環節記錄的batch_no都是65。之后另外一個用戶通過某個流程環節轉發了一件公文，再插入流程環節記錄的batch_id是68。
②state字段用來描述其流程環節所處的狀態，是正待處理，已被處理通過，已被處理駁回，還是超出最長等待時間被系統自動收回等等。通過這個字段我們對接受用戶發出處理通知，還可以可以很容易的查詢出所有超出最長等待時間被系統自動收回的流程，以便企業管理層在日后業務流程重組(BPR)時參考。
③如果某份公文在某個流程中的某個環節被處理駁回，可以看作該公文在此次流程中被駁回至起始點，最初發送用戶可根據處理回復注釋修改公文后重新發送。
總結：
企業公文流程自定義應該是把企業內已經固定了的公文轉發、審批流程電子化，實現高效的無紙化辦公，對于非正式的口頭討論、商議、集會等商務活動并不適合。當企業累積了一定數量的電子化公文轉發的記錄后，可以在商業咨詢專家和技術開發人員的協助下對其進行數據挖掘，分析出其中的低效、無用環節，進行優化重組，最終提高整個企業的競爭力。作為技術開發人員，我們應該根據企業實際運作情況、資金投入規模，選擇當前時期最適合的技術解決方案，切不可為了展示自己的技術實力，而把開發復雜化，企業開發并不是追求技術最先進，而是最適合。