表單子表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)時參考。
③如果某份公文在某個流程中的某個環節被處理駁回，可以看作該公文在此次流程中被駁回至起始點，最初發送用戶可根據處理回覆註釋修改公文後重新發送。
總結：
企業公文流程自定義應該是把企業內已經固定了的公文轉發、審批流程電子化，實現高效的無紙化辦公，對於非正式的口頭討論、商議、集會等商務活動並不適合。當企業累積了一定數量的電子化公文轉發的記錄後，可以在商業諮詢專家和技術開發人員的協助下對其進行數據挖掘，分析出其中的低效、無用環節，進行優化重組，最終提高整個企業的競爭力。作爲技術開發人員，我們應該根據企業實際運作情況、資金投入規模，選擇當前時期最適合的技術解決方案，切不可爲了展示自己的技術實力，而把開發複雜化，企業開發並不是追求技術最先進，而且最適合。
名稱 類型 約束條件 說明
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)時參考。
③如果某份公文在某個流程中的某個環節被處理駁回，可以看作該公文在此次流程中被駁回至起始點，最初發送用戶可根據處理回覆註釋修改公文後重新發送。
總結：
企業公文流程自定義應該是把企業內已經固定了的公文轉發、審批流程電子化，實現高效的無紙化辦公，對於非正式的口頭討論、商議、集會等商務活動並不適合。當企業累積了一定數量的電子化公文轉發的記錄後，可以在商業諮詢專家和技術開發人員的協助下對其進行數據挖掘，分析出其中的低效、無用環節，進行優化重組，最終提高整個企業的競爭力。作爲技術開發人員，我們應該根據企業實際運作情況、資金投入規模，選擇當前時期最適合的技術解決方案，切不可爲了展示自己的技術實力，而把開發複雜化，企業開發並不是追求技術最先進，而且最適合。
