本來打算用嘗試用MindManager畫個思維導向圖的，不過down了N久都沒down下來，也就做罷了。
1，基礎部分資料庫設計。
下面說一下"頁面(功能項)表"的設計，因為其他的比較簡單。通過關系圖已經可以完整表達我的設計意圖：
我這樣設計是希望系統具有一定的自定義組裝能力，是以把設計的權限控制粒度細到頁面級的添，删，改，查的和局部的使用者級，抽出頁面(功能項)表解釋下，
1)，啟用審批流程：頁面(基本等同于一個具體功能項，或者代表某項業務需求，下同)，這個功能項是否需要進入審批流程；如果設定“是”則需要自定義相應的工作流程(下面會講到)；
2)，啟用填加控制：這個設定決定在配置使用者權限的時候的細化程度。如果為“啟用”，則在配置使用者權限的時候，可以控制改功能項那些使用者可以填加，那些不 可以。反之。則所有使用者均可以。當然該使用者必須具有功能項級的權限。其他的。啟用修改，版本控制，浏覽，删除等類似；
3)，僅自己：這個選項對啟用填加，修改，浏覽，删除控制均有影響。如果為“是”，則在配置使用者權限的時候，可以附加選項“僅自己”，如果配置使用者權限的時候“僅自己”為“是”，那麼該使用者隻能修改，編輯，删除，浏覽自己填加的資料，反之。則無限制。
頁面(功能項)表為使用者權限配置的時候提供可選參數，為系統配置提供服務。而權限表是具體的使用者權限設定。為控制使用者權限服務；
2,工作流資料庫設計：
也就是說，系統自身實作簡單實用的工作流引擎而非采用比如wwf等的workflow enginee：
工 作流部分基于功能項和節點的組合。如果功能項(頁面)被配置為啟用審批流程。那麼需要設定相應的自定義流程。多個“節點”構成一個完整的流程。節點的前後 順序結構在資料庫設計中以“樹結構”來展現。每個“節點”可配置多個相關人員。通過“是否需全體通過”來控制該流程節點等待所有人員都審批通過才進入下一 節點。還是隻需要其中審批通過就進入下一節點。
考慮到系統的定位。沒有采用基于“崗位流轉”的工作流設計，而采用了基于“人員流轉”的工作流設計。