開發(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ā)的流程。 
　　盡管筆者沒有機(jī)會(huì)在已參與開發(fā)了的MIS中實(shí)現(xiàn)出文件轉(zhuǎn)發(fā)流程自定義的功能，但是，早在2002年初就曾深入思考過這方面的設(shè)計(jì)。當(dāng)時(shí)由于某些原因不能公開自己的設(shè)計(jì)思路，現(xiàn)在市面上已經(jīng)有不少M(fèi)IS產(chǎn)品提供這樣的功能，筆者又已離職，所以是時(shí)候把我的設(shè)計(jì)思路整理出來，和大家分享。
　　首先，讓我們分析需求，制定目標(biāo)。
　　1)一般情況下，企業(yè)內(nèi)的公文轉(zhuǎn)發(fā)、審批是按部門或職位來轉(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)的代碼，不過和修改底層數(shù)據(jù)建模比起來，工作量要少得多。
　　4)每個(gè)流程的環(huán)節(jié)數(shù)不一定相同，應(yīng)該能讓用戶設(shè)定環(huán)節(jié)數(shù)，指定公文流轉(zhuǎn)中每個(gè)環(huán)節(jié)的發(fā)送部門和接受部門，處理模式，最長等待時(shí)間。
　　5)當(dāng)待處理的公文發(fā)出后，系統(tǒng)應(yīng)該在等待時(shí)間中定期向該流程中下個(gè)環(huán)節(jié)的用戶(們)發(fā)出通知，提醒該用戶(們)及時(shí)處理，直至公文已被處理。如果超出最長等待時(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í)要求處理后可以跳過中間三個(gè)環(huán)節(jié)，直接轉(zhuǎn)到最后一個(gè)環(huán)節(jié)等候處理。其實(shí)，這種情況下，并不一定要在技術(shù)層面上實(shí)現(xiàn)其靈活性，這種特例畢竟是少數(shù)。用戶只需定義一個(gè)新流程，把上面流程的第1，2，6步復(fù)制加入進(jìn)來，2個(gè)流程之間用流程名來區(qū)分即可。一個(gè)優(yōu)秀的系統(tǒng)架構(gòu)設(shè)計(jì)師應(yīng)該充分利用現(xiàn)有的工具，不要什么都自行架設(shè)開發(fā)。
　　上面的需求對(duì)靈活性要求較高，抽象化程度較深，所以在表現(xiàn)層和業(yè)務(wù)邏輯層的開發(fā)量較大，初期投資較多，不過開發(fā)完畢后估計(jì)不需對(duì)底層數(shù)據(jù)庫修改，即可滿足日后不斷變化的公文流轉(zhuǎn)需求。如果不需要這么高的靈活性，可以按實(shí)際項(xiàng)目簡化某些假設(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ù)表來保存企業(yè)結(jié)構(gòu)，然后，采用權(quán)限表和用戶組相結(jié)合的方式來保存每個(gè)部門每個(gè)職位的職能。這塊的設(shè)計(jì)思路見我之前發(fā)布的“淺談數(shù)據(jù)庫設(shè)計(jì)技巧(上)、(下)”，我在下面直接給出大致的數(shù)據(jù)表結(jié)構(gòu)：
部門表(Department_table)
名稱　　　　類型　　　　約束條件　　　                    說明
Dp_id   　  int     　  無重復(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ù)庫的次數(shù)
功能表(Function_table)
名稱　　　　類型　　　　約束條件　　　說明
f_id        int    　   無重復(fù)　　   功能標(biāo)識(shí)，主鍵
f_name      varchar(20) 不允許為空   功能名稱，不允許重復(fù)
f_desc      varchar(50) 允許為空     功能描述
用戶組表(User_group)
名稱　　　　類型　　　　 約束條件　　　說明
group_id    int          無重復(fù)        用戶組標(biāo)識(shí)，主鍵
group_name  varchar(20)  不允許為空    用戶組名稱
group_power varchar(100) 不允許為空    用戶組權(quán)限表，內(nèi)容為功能表f_id的集合
用戶表(User_table)
名稱　　　　類型　　　　約束條件　　　說明
user_id     int         無重復(fù)        用戶標(biāo)識(shí)，主鍵
user_name   varchar(20) 無重復(fù)        用戶名
user_pwd    varchar(20) 不允許為空    用戶密碼
user_type   int         不允許為空    所屬用戶組標(biāo)識(shí)，和User_group.group_id關(guān)聯(lián)
　　說明：其中，按部門的不同職位設(shè)置不同權(quán)限的用戶組，如某個(gè)用戶組為“市場部業(yè)務(wù)員”，該用戶組的用戶可在流程“報(bào)銷申請(qǐng)”中發(fā)送報(bào)銷申請(qǐng)。
　　2)盡管流程中的公文分為文件和表單2種格式，但是每個(gè)文件/表單都應(yīng)該有其唯一標(biāo)識(shí)，名稱等屬性。所以，我們把公文抽象化，把這2種格式的公文的共有屬性提取出來建立一張公文表。
公文表(Document_table)
名稱　　　　類型　　　　約束條件　　　說明
doc_id      int         無重復(fù)        公文標(biāo)識(shí)，主鍵
doc_name    varchar(50) 不允許為空    公文名稱
doc_type    char(1)     不允許為空    公文類型
　　doc_type字段用來辨別公文格式，目前只有2種格式，可設(shè)“1”表示文件格式，“2”表示表單格式。估計(jì)未來新增公文格式不會(huì)太多，所以該字段只需一位字符。文件格式的公文一般是在文件內(nèi)固定好格式，我們可用一個(gè)二進(jìn)制的字段直接保存整個(gè)文件的內(nèi)容。文件格式的公文需要建一個(gè)表來保存相關(guān)信息，其大致數(shù)據(jù)表如下：
文件表(File_table)
名稱　　　 類型　　　　約束條件　　　說明
file_id    int         無重復(fù)       文件標(biāo)識(shí)，主鍵
file_name  varchar(50) 不允許為空   文件名稱
file_value binary      不允許為空   文件內(nèi)容
……
　　表單格式的公文要讓用戶自己定義表單格式，確定表單中的表項(xiàng)。有兩種方法來實(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ù)庫的結(jié)構(gòu)顯得比較混亂，而且大部分表單中都有相同的字段，這樣也增加了數(shù)據(jù)冗余。這種方式的數(shù)據(jù)建模如下：
表單總表(Sheet_table)
名稱　　　　類型　　　　約束條件　　　說明
sheet_id    int         無重復(fù)        表單標(biāo)識(shí)，主鍵
sheet_name  varchar(50) 不允許為空    表單名稱
table_name  varchar(20) 不允許為空    表單子表名，如Sub_table1/Sub_table2
表單子表1(Sub_table1)
名稱　　　類型　　　約束條件　　　說明
sub_id    int       無重復(fù)        表單子表標(biāo)識(shí)，主鍵
option1   varchar   不允許為空    表單表項(xiàng)1
option2   varchar   不允許為空    表單表項(xiàng)2
option3   varchar   不允許為空    表單表項(xiàng)3
……

[1] [2]  下一頁