公文轉發(fā)流程自定義的數(shù)據(jù)建模-文庫吧在線文庫
【正文】 程，把上面流程的第1，2，6步復制加入進來，2個流程之間用流程名來區(qū)分即可。當然，要實現(xiàn)新的處理動作，還是需要在業(yè)務邏輯層編寫相應的代碼，不過和修改底層數(shù)據(jù)建模比起來，工作量要少得多。例如：某個流程的某個環(huán)節(jié)需要財務總監(jiān)審批，日后財務總監(jiān)換人，該流程應該不受影響。由于企業(yè)的需求總是隨著時間推移不斷發(fā)生變化，加之各個企業(yè)內(nèi)部所設置的辦公流程不盡相同，一套通用性比較好的管理信息系統(tǒng)應該能讓系統(tǒng)管理員自己定義公文轉發(fā)的流程。文件格式的公文應該支持批處理，即一次可以轉發(fā)多個文件，審批時可以只退回其中某一個不合格的文件，其他的文件可以轉送到下一個環(huán)節(jié)繼續(xù)處理。如果超出最長等待時間，公文還未被用戶(們)處理，此次流程處理失敗。如果不需要這么高的靈活性，可以按實際項目簡化某些假設條件。所以，我們把公文抽象化，把這2種格式的公文的共有屬性提取出來建立一張公文表。這種方式的優(yōu)點是表單查詢速度較快方便，業(yè)務邏輯層的開發(fā)量較小。不允許為空接受方標識，a_idint不允許為空而且，該環(huán)節(jié)所轉發(fā)公文數(shù)量大于等于一，所以可以參考我之前發(fā)布的“淺談數(shù)據(jù)庫設計技巧(下)”中的“簡潔的批量m:n設計”，建表大致如下：流程環(huán)節(jié)記錄表(Step_log)名稱類型約束條件說明log_idint無重復環(huán)節(jié)記錄標識，主鍵step_idint不允許為空環(huán)節(jié)標識，sendervarchar(100)不允許為空發(fā)送用戶標識，receivervarchar(100)不允許為空接受用戶標識，doc_idint不允許為空轉發(fā)公文標識，batch_noint不允許為空批量轉發(fā)公文編號，同一流程環(huán)節(jié)轉發(fā)的batch_no相同statechar(1)當企業(yè)累積了一定數(shù)量的電子化公文轉發(fā)的記錄后，可以在商業(yè)咨詢專家和技術開發(fā)人員的協(xié)助下對其進行數(shù)據(jù)挖掘，分析出其中的低效、無用環(huán)節(jié)，進行優(yōu)化重組，最終提高整個企業(yè)的競爭力?！ 、趕tate字段用來描述其流程環(huán)節(jié)所處的狀態(tài)，是正待處理，已被處理通過，已被處理駁回，還是超出最長等待時間被系統(tǒng)自動收回等等。可能針對某些處理動作還得細化，進行相關的數(shù)據(jù)建模，這里我就不細分下去了。如果采用面向對象的開發(fā)方式，可以用COM組件來封裝處理動作，則a_call用來記錄相應的COM組件的接口方法。缺點是開發(fā)比較復雜，工作量和上面相比高出不少，而且表單查詢速度較慢。文件格式的公文一般是在文件內(nèi)固定好格式，我們可用一個二進制的字段直接保存整個文件的內(nèi)容。所以，可先建立一個樹形關系的數(shù)據(jù)表來保存企業(yè)結構，然后，采用權限表和用戶組相結合的方式來保存每個部門每個職位的職能。其實，這種情況下，并不一定要在技術層面上實現(xiàn)其靈活性，這種特例畢竟是少數(shù)。這樣一旦日后增加了新的處理動作，也不用修改MIS系統(tǒng)的底層數(shù)據(jù)建模。 1)一般情況下，企業(yè)內(nèi)的公文轉發(fā)、審批是按部門或職位來轉送，即對
公司管理相關推薦
鄂ICP備17016276號-1