公文轉(zhuǎn)發(fā)流程自定義的數(shù)據(jù)建模

1、公文轉(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ā)的流程。盡管筆者沒有機(jī)會(huì)在已參與開發(fā)了的 MIS中實(shí)現(xiàn)出文件轉(zhuǎn)發(fā)流程自定義的功能，但是, 早在2002年初就曾深入思考過這方面的設(shè)計(jì)。當(dāng)時(shí)由于某些原因不能公開自己的設(shè)計(jì)思 路，現(xiàn)在市面上已經(jīng)有不少 MIS產(chǎn)品提供這樣的功能，筆者又已離職，所以是時(shí)候把我的設(shè) 計(jì)思路整理出來，和大家分享。首先，讓我們分

2、析需求，制定目標(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)該能讓用戶自己定義

3、。這樣一旦日后增加了新的處理動(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ā)送部門和接受部門，處理模式，最長(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è)由于

4、特殊原因，在某個(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)需求。如果不需要這么高的靈活性，可

5、以按實(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ù)表來保存企業(yè)結(jié)構(gòu)，然 后，采用權(quán)限表和用戶組相結(jié)合的方式來保存每個(gè)部門每個(gè)職位的職能。這塊的設(shè)計(jì)思路見 我之前發(fā)布的 淺談數(shù)據(jù)庫設(shè)計(jì)技巧（上）、（下）”，我在下面直接給出大致的數(shù)據(jù)表結(jié)構(gòu)：部門表(Departme nt_table)名稱類型約束條件說明Dp idint無重復(fù)類別標(biāo)識(shí)，主鍵

6、Dp n amevarchar(50)不允許為空類型名稱，不允許重復(fù)Dp fatherint不允許為空該類別的父類別標(biāo)識(shí)，如果是 頂節(jié)點(diǎn)的話設(shè)定為某個(gè)唯一值Dp layervarchar(6)限定3層，初始值為000000類別的先序遍歷，主要為減少 檢索數(shù)據(jù)庫的次數(shù)功能表(Fu nction_table)名稱類型|約束條件說明f idint無重復(fù)功能標(biāo)識(shí)，主鍵f namevarchar(20)不允許為空功能名稱，不允許重復(fù)f_descvarchar(50)允許為空功能描述用戶組表(User_group)名稱類型約束條件說明group idint無重復(fù)用戶組標(biāo)識(shí)，主鍵group namevarc

7、har(20)?不允許為空用戶組名稱group powervarchar(100)不允許為空用戶組權(quán)限表，內(nèi)容為功能 表f id的集合用戶表(User_table)名稱類型約束條件說明user idint無重復(fù)用戶標(biāo)識(shí)，主鍵user n amevarchar(20)無重復(fù)用戶名user pwdvarchar(20)不允許為空用戶密碼說明：其中，按部門的不同職位設(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種格式的公文

8、的共有屬性提取出來建立一張公文表。公文表(Docume nt_table)名稱類型約束條件說明doc idint無重復(fù)公文標(biāo)識(shí)，主鍵doc namevarchar(50)不允許為空公文名稱doc_typechar(1)?不允許為空公文類型doc_type字段用來辨別公文格式，目前只有 2種格式，可設(shè)“ 1表示文件格式，“ 2表示 表單格式。估計(jì)未來新增公文格式不會(huì)太多，所以該字段只需一位字符。文件格式的公文一 般是在文件內(nèi)固定好格式，我們可用一個(gè)二進(jìn)制的字段直接保存整個(gè)文件的內(nèi)容。文件格式 的公文需要建一個(gè)表來保存相關(guān)信息，其大致數(shù)據(jù)表如下：文件表(File_table)名稱類型約束條件說明f

9、ile idint無重復(fù)文件標(biāo)識(shí)，主鍵file namevarchar(50)不允許為空文件名稱file valuebin ary?不允許為空文件內(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)名稱類型約束條件

10、說明sheet idint無重復(fù)表單標(biāo)識(shí)，主鍵sheet namevarchar(50)不允許為空表單名稱table n amevarchar(20)不允許為空表單子表名，如Sub table1/Sub table2表單子表 1(Sub_table1)名稱類型約束條件說明sub idint無重復(fù)表單子表標(biāo)識(shí)，主鍵opti on1varchar不允許為空表單表項(xiàng)1opti on2varchar不允許為空表單表項(xiàng)2opti on3varchar不允許為空表單表項(xiàng)3表單子表 2(Sub_table2)名稱類型約束條件說明sub idint無重復(fù)表單子表標(biāo)識(shí)，主鍵opti on1varchar不允許為

11、空表單表項(xiàng)1opti on2varchar不允許為空表單表項(xiàng)2opti on3varchar不允許為空表單表項(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ù)庫結(jié)構(gòu)清晰，沒有數(shù)據(jù)冗余。缺點(diǎn)是開發(fā)比較復(fù)雜，工作量和上面相比高 出不少，而且表單查詢速度較慢。下面是這種方式的數(shù)據(jù)建模：表單總表(Sheet_table)名稱類型約束條件說明sheet idint無重復(fù)表單標(biāo)識(shí)，主鍵sheet namevarchar(50)不允許為空表單名稱表單表項(xiàng)表(Option_table

12、)名稱類型約束條件說明op idint無重復(fù)表單表項(xiàng)標(biāo)識(shí)，主鍵op namevarchar(50)不允許為空表單表項(xiàng)名稱op lengthint不允許為空表單表項(xiàng)長(zhǎng)度op_unitvarchar(10)允許為空表單表項(xiàng)單位表單信息表(Sheetinfo_table)名稱類型約束條件說明info idint無重復(fù)表單信息標(biāo)識(shí)，主鍵sheet idint不允許為空？所屬表單標(biāo)識(shí)，和Sheet table.sheet i(關(guān)聯(lián)op idint不允許為空？表單表項(xiàng)標(biāo)識(shí)，和Optio n table.op id 關(guān)聯(lián)in fo_valuevarchar()?不允許為空表單信息值3) 我們可以把公文轉(zhuǎn)發(fā)的

13、流程抽象化，看作一個(gè)實(shí)體超類。建表如下:流程表(Flow table)名稱類型約束條件說明flow idint無重復(fù)流程標(biāo)識(shí)，主鍵flow n amevarchar(50)不允許為空流程名稱flow step numint不允許為空流程步數(shù)I flow desc| varchar(200) | 允許為空| 流程描述流程中的每一步都可以抽象化成從發(fā)送方至接受方的用例，其數(shù)據(jù)建模大致如下：處理動(dòng)作表(Action_table)名稱類型約束條件說明a idint無重復(fù)動(dòng)作標(biāo)識(shí)，主鍵a_n amevarchar(20)不允許為空動(dòng)作名稱a callvarchar(50)不允許為空動(dòng)作所調(diào)用的模塊a d

14、escvarchar(200)允許為空動(dòng)作描述說明：如果米用面向過程的開發(fā)方式，如純腳本語言，可以把每一個(gè)處理動(dòng)作寫成一個(gè) 函數(shù)，調(diào)用a_call字段記錄的函數(shù)，即可完成相應(yīng)處理動(dòng)作。如果采用面向?qū)ο蟮拈_發(fā)方 式，可以用COM組件來封裝處理動(dòng)作，則a_call用來記錄相應(yīng)的COM組件的接口方法。如 果是在.NET Framework環(huán)境下，可以米用 Web服務(wù)的方式。當(dāng)然，發(fā)送方、接受方以及公 文標(biāo)識(shí)是作為輸入?yún)?shù)的。流程環(huán)節(jié)表(Step_table)名稱類型約束條件說明step idint無重復(fù)環(huán)節(jié)標(biāo)識(shí)，主鍵bel ongint不允許為空所屬流程標(biāo)識(shí)，和Flow table.flow id

15、關(guān)聯(lián)setp orderint不允許為空所屬流程的步驟次序senderint不允許為空發(fā)送方標(biāo)識(shí)，和User group.group id關(guān)聯(lián)receiverint?不允許為空接受方標(biāo)識(shí)，和User group.group id 關(guān)聯(lián)a idint不允許為空？?？處理動(dòng)作標(biāo)識(shí)，和 Action_table.a_id關(guān)聯(lián) a typeint不允許為空接受方所需的處理人數(shù)max waitint不允許為空最長(zhǎng)等待時(shí)間wait unitvarchar(5)不允許為空等待時(shí)間的單位說明：a_type用來確定接受方所需的處理人數(shù)，“0表示需同職位的所有人一起處理，1表示只需該職位的任意一名員工處理，“ 2

16、表示需該職位的任意兩名員工一起處理，依次遞推一起處理的方式和處理動(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)過一環(huán)節(jié),我們除了要保存這方面的信息，還必須保存該環(huán)節(jié)所轉(zhuǎn)發(fā)的公文，以及處理狀況等信息。而且，該環(huán)節(jié)所轉(zhuǎn)發(fā)公文數(shù)量大于等于一，所以可以參考我之前發(fā)布的淺談數(shù)據(jù)庫設(shè)計(jì)技巧（下）”中的 簡(jiǎn)潔的批量m:n設(shè)計(jì)”建表大致如下：流程環(huán)節(jié)記錄表（Ste

17、p_log）名稱類型約束條件說明logdint無重復(fù)環(huán)節(jié)記錄標(biāo)識(shí)，主鍵step idint不允許為空環(huán)節(jié)標(biāo)識(shí)，和 Step table.step id關(guān)聯(lián) sendervarchar(1OO)不允許為空發(fā)送用戶標(biāo)識(shí)，相關(guān)用戶組的User table.user id 的集合receivervarchar(1OO)不允許為空接受用戶標(biāo)識(shí)，相關(guān)用戶組的User table.user id 的集合doc idint不允許為空轉(zhuǎn)發(fā)公文標(biāo)識(shí)，和Document table.doc id關(guān)聯(lián)batch noint不允許為空批量轉(zhuǎn)發(fā)公文編號(hào)，同一流程環(huán)節(jié)轉(zhuǎn)發(fā)的batch no相同statechar(1)?不允

18、許為空處理狀態(tài)sub datedatetime不允許為空提交時(shí)間res datedatetime允許為空處理回復(fù)時(shí)間comme ntvarchar(255)允許為空處理回復(fù)注釋說明: 同一流程環(huán)節(jié)轉(zhuǎn)發(fā)的batch_no和該批第一條入庫的logd相同。舉例：假設(shè)當(dāng)前最大 log_id是64,接著某用戶一次轉(zhuǎn)發(fā)了 3件公文，則批量插入的3條流程環(huán)節(jié)記錄的batch_no 都是65。之后另外一個(gè)用戶通過某個(gè)流程環(huán)節(jié)轉(zhuǎn)發(fā)了一件公文，再插入流程環(huán)節(jié)記錄的batchd 是 68。 state字段用來描述其流程環(huán)節(jié)所處的狀態(tài)，是正待處理，已被處理通過，已被處理駁 回，還是超出最長(zhǎng)等待時(shí)間被系統(tǒng)自動(dòng)收回等等。通過這個(gè)字段我們對(duì)接受用戶發(fā)出處理通 知，還可以可以很容易的查詢出所有超出最長(zhǎng)等待時(shí)間被系統(tǒng)自動(dòng)收回的流程，以便企業(yè)管 理層在日后業(yè)務(wù)流程重組（BPR）時(shí)參考。 如果某份公文在某個(gè)流程中的某個(gè)環(huán)節(jié)被處理駁回，可以看作該公文在此次流程中被 駁