分析：
1）由於流程每個節點環節的傳送方和接受方是對崗不對人，應該考慮到整個企業的機構設定，確定每個部門的權利職責。每個大部門內可能有若干子部門，每個子部門內又有不同的職位，負責處理相應的事務。 *
部門的設定是根據每個部門相關人員的崗位來劃分設定的。
* 使用者組設定具體的崗位許可權。
* 乙個具體部門可能會擁有幾個使用者組所在崗位許可權。
資料模型如下：
幾點說明：
圖中，也許有人會提出使用者組部門表與使用者組功能表應該合併成一張表。我的考慮是設定使用者組部門表時不需要去考慮具體的明細功能，同樣設定使用者組功能表時也不需要去考慮屬於哪個部門。因為乙個使用者組功能可以只屬於乙個部門也有可能屬於幾個部門，換句話說乙個部門可以擁有乙個使用者組中的許可權，也可以擁有多個使用者組中的許可權。 2
）審批的公文一般分為檔案和表單
2種格式，應該把公文抽象化。把２種格式的公文的共有屬性提取出來建立一張公文表。
a.檔案格式的
公文表(document_table)
名稱 型別 約束條件 說明
doc_id int
無重複公文標識，主鍵
doc_name varchar(50)
不允許為空
公文名稱
doc_type char(1)
不允許為空
公文型別
doc_type
字段用來辨別公文格式，目前只有
2種格式，可設
「1」表示檔案格式，
「2」表示表單格式。估計未來新增公文格式不會太多，所以該字段只需一位字元。檔案格式的公文一般是在檔案內固定好格式，我們可用乙個二進位制的字段直接儲存整個檔案的內容。檔案格式的公文需要建乙個表來儲存相關資訊，其大致資料表如下：
檔案表(file_table)
名稱
型別 約束條件 說明
file_id int
無重複檔案標識，主鍵
file_name varchar(50)
不允許為空
檔名稱
file_value binary
不允許為空
檔案內容
……
b.表單格式的公文要讓使用者自己定義表單格式，確定表單中的表項。有兩種方法來實現：①
每當使用者建立乙個新格式的表單時，就新建立乙個表，把使用者輸入的表單表項當作該錶的字段。這種方式的優點是表單查詢速度較快方便，業務邏輯層的開發量較小。缺點是不太靈活，如果企業所使用的不同格式的表單較多
(>20種)
，整個資料庫的結構顯得比較混亂，而且大部分表單中都有相同的字段，這樣也增加了資料冗餘。
這種方式的資料建模如下：
表單總表
(sheet_table)
名稱 型別 約束條件 說明
sheet_id int
無重複表單標識，主鍵
sheet_name varchar(50)
不允許為空
表單名稱
table_name varchar(20)
不允許為空
表單子表名，如
sub_table1/sub_table2
表單子表
1(sub_table1)
名稱 型別 約束條件 說明
sub_id int
無重複表單子表標識，主鍵
option1 varchar
不允許為空
表單表項
1option2 varchar
不允許為空
表單表項
2option3 varchar
不允許為空
表單表項
3……
表單子表
2(sub_table2)
名稱 型別 約束條件 說明
sub_id int
無重複表單子表標識，主鍵
option1 varchar
不允許為空
表單表項
1option2 varchar
不允許為空
表單表項
2option3 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()
不允許為空
表單資訊值
對於以上的這兩種情況，我個人認為應該採用第二種較為合適。
繼續中....
資料庫建模
定義 正規化可以理解為設計一張資料庫表結構符合某種標準級別的規範和要求。優點 在關係型資料庫建表時遵循一定的規範要求，目的降低資料的冗餘性。缺點 在獲取資料時通過jion拼接出完整資料。分類 目前業界正規化有 第一正規化 第二份正規化 第三正規化 巴斯 科德正規化 第四正規化 第五正規化 1.完全函...
Power Designer資料庫建模
power designer 資料庫建模 1.power designer支援從e r模型轉換成資料庫的物理模型。這裡我使用的是power designer的看家本領，physical data model pdm 的建立。2.pdm建立資料庫 選擇new physical data model，因...
Database 資料庫建模
待整理1.開發軟體的生命週期 1.可行性研究 做不做 2.需求分析 做什麼 3.概要設計 怎麼做 4.詳細設計 5.系統實現 開發 6.測試 7.執行維護 2.e r圖 1.定義 2.三要素 1.e entity 實體 2.attributes，properties 屬性 3.r 關係 實體間的三種...