轉(zhuǎn)《公文轉(zhuǎn)發(fā)流程自定義的數(shù)據(jù)建模 》
開發(fā)比較復(fù)雜的企業(yè)多用戶管理信息系統(tǒng)(MIS)，不可能不涉及到系統(tǒng)內(nèi)多個(gè)用戶之間的數(shù)據(jù)文件的流轉(zhuǎn)、審批等功能的開發(fā)。由于企業(yè)的需求總是隨著時(shí)間推移不斷發(fā)生變化，加之各個(gè)企業(yè)內(nèi)部所設(shè)置的辦公流程不盡相同，一套通用性比較好的管理信息系統(tǒng)應(yīng)該能讓系統(tǒng)管理員自己定義公文轉(zhuǎn)發(fā)的流程。
盡管筆者沒(méi)有機(jī)會(huì)在已參與開發(fā)了的MIS中實(shí)現(xiàn)出文件轉(zhuǎn)發(fā)流程自定義的功能，但是，早在2002年初就曾深入思考過(guò)這方面的設(shè)計(jì)。當(dāng)時(shí)由于某些原因不能公開自己的設(shè)計(jì)思路，現(xiàn)在市面上已經(jīng)有不少M(fèi)IS產(chǎn)品提供這樣的功能，筆者又已離職，所以是時(shí)候把我的設(shè)計(jì)思路整理出來(lái)，和大家分享。
首先，讓我們分析需求，制定目標(biāo)。
1)一般情況下，企業(yè)內(nèi)的公文轉(zhuǎn)發(fā)、審批是按部門或職位來(lái)轉(zhuǎn)送，即對(duì)崗不對(duì)人。例如：某個(gè)流程的某個(gè)環(huán)節(jié)需要財(cái)務(wù)總監(jiān)審批，日后財(cái)務(wù)總監(jiān)換人，該流程應(yīng)該不受影響。而且，流程中某個(gè)環(huán)節(jié)可能出現(xiàn)某個(gè)部門中的任何一人都能審批，或者需要該部門的所有人員共同審批。
2)流程中轉(zhuǎn)送，審批的公文一般分為文件和表單2種格式。文件格式的公文應(yīng)該支持批處理，即一次可以轉(zhuǎn)發(fā)多個(gè)文件，審批時(shí)可以只退回其中某一個(gè)不合格的文件，其他的文件可以轉(zhuǎn)送到下一個(gè)環(huán)節(jié)繼續(xù)處理。表單格式的公文應(yīng)該能讓用戶自己定義表單格式，確定表單中的表項(xiàng)。同理，表單也應(yīng)該支持批處理。
3)流程中處理公文的動(dòng)作應(yīng)該能讓用戶自己定義。這樣一旦日后增加了新的處理動(dòng)作，也不用修改MIS系統(tǒng)的底層數(shù)據(jù)建模。當(dāng)然，要實(shí)現(xiàn)新的處理動(dòng)作，還是需要在業(yè)務(wù)邏輯層編寫相應(yīng)的代碼，不過(guò)和修改底層數(shù)據(jù)建模比起來(lái)，工作量要少得多。
4)每個(gè)流程的環(huán)節(jié)數(shù)不一定相同，應(yīng)該能讓用戶設(shè)定環(huán)節(jié)數(shù)，指定公文流轉(zhuǎn)中每個(gè)環(huán)節(jié)的發(fā)送部門和接受部門，處理模式，最長(zhǎng)等待時(shí)間。
5)當(dāng)待處理的公文發(fā)出后，系統(tǒng)應(yīng)該在等待時(shí)間中定期向該流程中下個(gè)環(huán)節(jié)的用戶(們)發(fā)出通知，提醒該用戶(們)及時(shí)處理，直至公文已被處理。如果超出最長(zhǎng)等待時(shí)間，公文還未被用戶(們)處理，此次流程處理失敗。企業(yè)管理層可能會(huì)要求記錄相關(guān)信息，以便在日后業(yè)務(wù)流程重組(BPR)時(shí)參考。
6)某些企業(yè)由于特殊原因，在某個(gè)流程中要求實(shí)現(xiàn)跨環(huán)節(jié)處理。例如，該流程有6步，執(zhí)行到第二個(gè)環(huán)節(jié)時(shí)要求處理后可以跳過(guò)中間三個(gè)環(huán)節(jié)，直接轉(zhuǎn)到最后一個(gè)環(huán)節(jié)等候處理。其實(shí)，這種情況下，并不一定要在技術(shù)層面上實(shí)現(xiàn)其靈活性，這種特例畢竟是少數(shù)。用戶只需定義一個(gè)新流程，把上面流程的第1，2，6步復(fù)制加入進(jìn)來(lái)，2個(gè)流程之間用流程名來(lái)區(qū)分即可。一個(gè)優(yōu)秀的系統(tǒng)架構(gòu)設(shè)計(jì)師應(yīng)該充分利用現(xiàn)有的工具，不要什么都自行架設(shè)開發(fā)。
上面的需求對(duì)靈活性要求較高，抽象化程度較深，所以在表現(xiàn)層和業(yè)務(wù)邏輯層的開發(fā)量較大，初期投資較多，不過(guò)開發(fā)完畢后估計(jì)不需對(duì)底層數(shù)據(jù)庫(kù)修改，即可滿足日后不斷變化的公文流轉(zhuǎn)需求。如果不需要這么高的靈活性，可以按實(shí)際項(xiàng)目簡(jiǎn)化某些假設(shè)條件。下面按照上面的需求進(jìn)行用例(use case)分析和數(shù)據(jù)建模。
1)由于流程環(huán)節(jié)的發(fā)送方和接受方是對(duì)崗不對(duì)人，我們應(yīng)該先描畫出整個(gè)企業(yè)的機(jī)構(gòu)設(shè)置，確定每個(gè)部門的權(quán)利職責(zé)。其中大的部門內(nèi)可能有若干子部門，每個(gè)子部門內(nèi)又有不同職位，負(fù)責(zé)處理相應(yīng)的事務(wù)。所以，可先建立一個(gè)樹形關(guān)系的數(shù)據(jù)表來(lái)保存企業(yè)結(jié)構(gòu)，然后，采用權(quán)限表和用戶組相結(jié)合的方式來(lái)保存每個(gè)部門每個(gè)職位的職能。這塊的設(shè)計(jì)思路見(jiàn)我之前發(fā)布的“淺談數(shù)據(jù)庫(kù)設(shè)計(jì)技巧(上)、(下)”，我在下面直接給出大致的數(shù)據(jù)表結(jié)構(gòu)：
部門表(Department_table)
名稱 類型 約束條件 說(shuō)明
Dp_id int 無(wú)重復(fù) 類別標(biāo)識(shí)，主鍵
Dp_name varchar(50) 不允許為空 類型名稱，不允許重復(fù)
Dp_father int 不允許為空 該類別的父類別標(biāo)識(shí)，如果是頂節(jié)點(diǎn)的話設(shè)定為某個(gè)唯一值
Dp_layer varchar(6) 限定3層,初始值為000000 類別的先序遍歷，主要為減少檢索數(shù)據(jù)庫(kù)的次數(shù)
功能表(Function_table)
名稱 類型 約束條件 說(shuō)明
f_id int 無(wú)重復(fù) 功能標(biāo)識(shí)， 主鍵
f_name varchar(20) 不允許為空 功能名稱，不允許重復(fù)
f_desc varchar(50) 允許為空 功能描述
用戶組表(User_group)
名稱 類型 約束條件 說(shuō)明
group_id int 無(wú)重復(fù) 用戶組標(biāo)識(shí)，主鍵
group_name varchar(20) 不允許為空 用戶組名稱
group_power varchar(100) 不允許為空 用戶組權(quán)限表，內(nèi)容為功能表f_id的集合
用戶表(User_table)
名稱 類型 約束條件 說(shuō)明
user_id int 無(wú)重復(fù) 用戶標(biāo)識(shí)，主鍵
user_name varchar(20) 無(wú)重復(fù) 用戶名
user_pwd varchar(20) 不允許為空 用戶密碼
user_type int 不允許為空 所屬用戶組標(biāo)識(shí)，和User_group.group_id關(guān)聯(lián)
說(shuō)明：其中，按部門的不同職位設(shè)置不同權(quán)限的用戶組，如某個(gè)用戶組為“市場(chǎng)部業(yè)務(wù)員”，該用戶組的用戶可在流程“報(bào)銷申請(qǐng)”中發(fā)送報(bào)銷申請(qǐng)。
2)盡管流程中的公文分為文件和表單2種格式，但是每個(gè)文件/表單都應(yīng)該有其唯一標(biāo)識(shí)，名稱等屬性。所以，我們把公文抽象化，把這2種格式的公文的共有屬性提取出來(lái)建立一張公文表。
公文表(Document_table)
名稱 類型 約束條件 說(shuō)明
doc_id int 無(wú)重復(fù) 公文標(biāo)識(shí)， 主鍵
doc_name varchar(50) 不允許為空 公文名稱
doc_type char(1) 不允許為空 公文類型
doc_type字段用來(lái)辨別公文格式，目前只有2種格式，可設(shè)“1”表示文件格式，“2”表示表單格式。估計(jì)未來(lái)新增公文格式不會(huì)太多，所以該字段只需一位字符。文件格式的公文一般是在文件內(nèi)固定好格式，我們可用一個(gè)二進(jìn)制的字段直接保存整個(gè)文件的內(nèi)容。文件格式的公文需要建一個(gè)表來(lái)保存相關(guān)信息，其大致數(shù)據(jù)表如下：
文件表(File_table)
名稱 類型 約束條件 說(shuō)明
file_id int 無(wú)重復(fù) 文件標(biāo)識(shí)，主鍵
file_name varchar(50) 不允許為空 文件名稱
file_value binary 不允許為空 文件內(nèi)容
……
表單格式的公文要讓用戶自己定義表單格式，確定表單中的表項(xiàng)。有兩種方法來(lái)實(shí)現(xiàn)：
①每當(dāng)用戶建立一個(gè)新格式的表單時(shí)，就新建立一個(gè)表，把用戶輸入的表單表項(xiàng)當(dāng)作該表的字段。這種方式的優(yōu)點(diǎn)是表單查詢速度較快方便，業(yè)務(wù)邏輯層的開發(fā)量較小。缺點(diǎn)是不太靈活，如果企業(yè)所使用的不同格式的表單較多(>20種)，整個(gè)數(shù)據(jù)庫(kù)的結(jié)構(gòu)顯得比較混亂，而且大部分表單中都有相同的字段，這樣也增加了數(shù)據(jù)冗余。這種方式的數(shù)據(jù)建模如下：
表單總表(Sheet_table)
名稱 類型 約束條件 說(shuō)明
sheet_id int 無(wú)重復(fù) 表單標(biāo)識(shí)， 主鍵
sheet_name varchar(50) 不允許為空 表單名稱
table_name varchar(20) 不允許為空 表單子表名，如Sub_table1/Sub_table2
表單子表1(Sub_table1)
名稱 類型 約束條件 說(shuō)明
sub_id int 無(wú)重復(fù) 表單子表標(biāo)識(shí)，主鍵
option1 varchar 不允許為空 表單表項(xiàng)1
option2 varchar 不允許為空 表單表項(xiàng)2
option3 varchar 不允許為空 表單表項(xiàng)3
……
表單子表2(Sub_table2)
名稱 類型 約束條件 說(shuō)明
sub_id int 無(wú)重復(fù) 表單子表標(biāo)識(shí)，主鍵
option1 varchar 不允許為空 表單表項(xiàng)1
option2 varchar 不允許為空 表單表項(xiàng)2
option3 varchar 不允許為空 表單表項(xiàng)3
……
……
②對(duì)表單再進(jìn)行一個(gè)抽象，把表單看成由若干個(gè)表單表項(xiàng)所組合成的一個(gè)集合。這種方式的優(yōu)點(diǎn)是相當(dāng)靈活，用戶建立新格式的表單時(shí)只用從已有表單表項(xiàng)中勾選出需要的表項(xiàng)即可，而且整個(gè)數(shù)據(jù)庫(kù)結(jié)構(gòu)清晰，沒(méi)有數(shù)據(jù)冗余。缺點(diǎn)是開發(fā)比較復(fù)雜，工作量和上面相比高出不少，而且表單查詢速度較慢。下面是這種方式的數(shù)據(jù)建模：
表單總表(Sheet_table)
名稱 類型 約束條件 說(shuō)明
sheet_id int 無(wú)重復(fù) 表單標(biāo)識(shí)，主鍵
sheet_name varchar(50) 不允許為空 表單名稱
表單表項(xiàng)表(Option_table)
名稱 類型 約束條件 說(shuō)明
op_id int 無(wú)重復(fù) 表單表項(xiàng)標(biāo)識(shí)，主鍵
op_name varchar(50) 不允許為空 表單表項(xiàng)名稱
op_length int 不允許為空 表單表項(xiàng)長(zhǎng)度
op_unit varchar(10) 允許為空 表單表項(xiàng)單位
表單信息表(Sheetinfo_table)
名稱 類型 約束條件 說(shuō)明
info_id int 無(wú)重復(fù) 表單信息標(biāo)識(shí)，主鍵
sheet_id int 不允許為空 所屬表單標(biāo)識(shí)，和Sheet_table.sheet_id關(guān)聯(lián)
op_id int 不允許為空 表單表項(xiàng)標(biāo)識(shí)，和Option_table.op_id關(guān)聯(lián)
info_value varchar() 不允許為空 表單信息值
3)我們可以把公文轉(zhuǎn)發(fā)的流程抽象化，看作一個(gè)實(shí)體超類。建表如下：
流程表(Flow_table)
名稱 類型 約束條件 說(shuō)明
flow_id int 無(wú)重復(fù) 流程標(biāo)識(shí)，主鍵
flow_name varchar(50) 不允許為空 流程名稱
flow_stepnum int 不允許為空 流程步數(shù)
flow_desc varchar(200) 允許為空 流程描述
流程中的每一步都可以抽象化成從發(fā)送方至接受方的用例，其數(shù)據(jù)建模大致如下：
處理動(dòng)作表(Action_table)
名稱 類型 約束條件 說(shuō)明
a_id int 無(wú)重復(fù) 動(dòng)作標(biāo)識(shí)， 主鍵
a_name varchar(20) 不允許為空 動(dòng)作名稱
a_call varchar(50) 不允許為空 動(dòng)作所調(diào)用的模塊
a_desc varchar(200) 允許為空 動(dòng)作描述
說(shuō)明：如果采用面向過(guò)程的開發(fā)方式，如純腳本語(yǔ)言，可以把每一個(gè)處理動(dòng)作寫成一個(gè)函數(shù)，調(diào)用a_call字段記錄的函數(shù)，即可完成相應(yīng)處理動(dòng)作。如果采用面向?qū)ο蟮拈_發(fā)方式，可以用COM組件來(lái)封裝處理動(dòng)作，則a_call用來(lái)記錄相應(yīng)的COM組件的接口方法。如果是在.NET Framework環(huán)境下，可以采用Web服務(wù)的方式。當(dāng)然，發(fā)送方、接受方以及公文標(biāo)識(shí)是作為輸入?yún)?shù)的。
流程環(huán)節(jié)表(Step_table)
名稱 類型 約束條件 說(shuō)明
step_id int 無(wú)重復(fù) 環(huán)節(jié)標(biāo)識(shí)，主鍵
belong int 不允許為空 所屬流程標(biāo)識(shí)，和Flow_table.flow_id關(guān)聯(lián)
setp_order int 不允許為空 所屬流程的步驟次序
sender int 不允許為空 發(fā)送方標(biāo)識(shí)，和User_group.group_id關(guān)聯(lián)
receiver int 不允許為空 接受方標(biāo)識(shí)，和User_group.group_id關(guān)聯(lián)
a_id int 不允許為空 處理動(dòng)作標(biāo)識(shí)，和Action_table.a_id關(guān)聯(lián)
a_type int 不允許為空 接受方所需的處理人數(shù)
max_wait int 不允許為空 最長(zhǎng)等待時(shí)間
wait_unit varchar(5) 不允許為空 等待時(shí)間的單位
說(shuō)明：a_type用來(lái)確定接受方所需的處理人數(shù)，“0”表示需同職位的所有人一起處理，“1”表示只需該職位的任意一名員工處理，“2”表示需該職位的任意兩名員工一起處理，依次遞推……一起處理的方式和處理動(dòng)作有關(guān)，例如是投票方式，少數(shù)服從多數(shù)，還是某人有一票否決權(quán)等等。可能針對(duì)某些處理動(dòng)作還得細(xì)化，進(jìn)行相關(guān)的數(shù)據(jù)建模，這里我就不細(xì)分下去了。
4)下面分析公文轉(zhuǎn)發(fā)的流程環(huán)節(jié)記錄。此時(shí)相當(dāng)于實(shí)例化一個(gè)流程環(huán)節(jié)的對(duì)象，發(fā)送方和接受方應(yīng)具體聯(lián)系到管理信息系統(tǒng)的某個(gè)(些)用戶，而不是某個(gè)用戶組。每經(jīng)過(guò)一環(huán)節(jié)，我們除了要保存這方面的信息，還必須保存該環(huán)節(jié)所轉(zhuǎn)發(fā)的公文，以及處理狀況等信息。而且，該環(huán)節(jié)所轉(zhuǎn)發(fā)公文數(shù)量大于等于一，所以可以參考我之前發(fā)布的“淺談數(shù)據(jù)庫(kù)設(shè)計(jì)技巧(下)”中的“簡(jiǎn)潔的批量m:n設(shè)計(jì)”，建表大致如下：
流程環(huán)節(jié)記錄表(Step_log)
名稱 類型 約束條件 說(shuō)明
log_id int 無(wú)重復(fù) 環(huán)節(jié)記錄標(biāo)識(shí)，主鍵
step_id int 不允許為空 環(huán)節(jié)標(biāo)識(shí)，和Step_table.step_id關(guān)聯(lián)
sender varchar(100) 不允許為空 發(fā)送用戶標(biāo)識(shí)，相關(guān)用戶組的User_table.user_id的集合
receiver varchar(100) 不允許為空 接受用戶標(biāo)識(shí)，相關(guān)用戶組的User_table.user_id的集合
doc_id int 不允許為空 轉(zhuǎn)發(fā)公文標(biāo)識(shí)，和Document_table.doc_id關(guān)聯(lián)
batch_no int 不允許為空 批量轉(zhuǎn)發(fā)公文編號(hào)，同一流程環(huán)節(jié)轉(zhuǎn)發(fā)的batch_no相同
state char(1) 不允許為空 處理狀態(tài)
sub_date datetime 不允許為空 提交時(shí)間
res_date datetime 允許為空 處理回復(fù)時(shí)間
comment varchar(255) 允許為空 處理回復(fù)注釋
說(shuō)明：
①同一流程環(huán)節(jié)轉(zhuǎn)發(fā)的batch_no和該批第一條入庫(kù)的log_id相同。舉例：假設(shè)當(dāng)前最大log_id是64，接著某用戶一次轉(zhuǎn)發(fā)了3件公文，則批量插入的3條流程環(huán)節(jié)記錄的batch_no都是65。之后另外一個(gè)用戶通過(guò)某個(gè)流程環(huán)節(jié)轉(zhuǎn)發(fā)了一件公文，再插入流程環(huán)節(jié)記錄的batch_id是68。
②state字段用來(lái)描述其流程環(huán)節(jié)所處的狀態(tài)，是正待處理，已被處理通過(guò)，已被處理駁回，還是超出最長(zhǎng)等待時(shí)間被系統(tǒng)自動(dòng)收回等等。通過(guò)這個(gè)字段我們對(duì)接受用戶發(fā)出處理通知，還可以可以很容易的查詢出所有超出最長(zhǎng)等待時(shí)間被系統(tǒng)自動(dòng)收回的流程，以便企業(yè)管理層在日后業(yè)務(wù)流程重組(BPR)時(shí)參考。
③如果某份公文在某個(gè)流程中的某個(gè)環(huán)節(jié)被處理駁回，可以看作該公文在此次流程中被駁回至起始點(diǎn)，最初發(fā)送用戶可根據(jù)處理回復(fù)注釋修改公文后重新發(fā)送。
總結(jié)：
企業(yè)公文流程自定義應(yīng)該是把企業(yè)內(nèi)已經(jīng)固定了的公文轉(zhuǎn)發(fā)、審批流程電子化，實(shí)現(xiàn)高效的無(wú)紙化辦公，對(duì)于非正式的口頭討論、商議、集會(huì)等商務(wù)活動(dòng)并不適合。當(dāng)企業(yè)累積了一定數(shù)量的電子化公文轉(zhuǎn)發(fā)的記錄后，可以在商業(yè)咨詢專家和技術(shù)開發(fā)人員的協(xié)助下對(duì)其進(jìn)行數(shù)據(jù)挖掘，分析出其中的低效、無(wú)用環(huán)節(jié)，進(jìn)行優(yōu)化重組，最終提高整個(gè)企業(yè)的競(jìng)爭(zhēng)力。作為技術(shù)開發(fā)人員，我們應(yīng)該根據(jù)企業(yè)實(shí)際運(yùn)作情況、資金投入規(guī)模，選擇當(dāng)前時(shí)期最適合的技術(shù)解決方案，切不可為了展示自己的技術(shù)實(shí)力，而把開發(fā)復(fù)雜化，企業(yè)開發(fā)并不是追求技術(shù)最先進(jìn)，而是最適合。