我這個系統可以不同的人可操作範圍是不壹樣的，那麽這句話包含了哪些信息呢？
1，要有人
2，要有操作
3，要有不同的操作集合（操作組<=>權限組）
4，人和操作組的關聯
所以，現在條理就清晰了，現在就來按照這個思路來設計數據關系映射
人，權限組 ，這個肯定是多對多的關系，所以設計壹張關系表 人-權限組表
操作，權限組，這個也是多對多的關系，壹個權限組有多個操作，壹個操作也可以屬於多個權限組，也需要壹個中間表，操作-權限組
至於每個實體有多少屬性，得按照妳的實際系統需求，但總的來說基本上是下面的結構
人：user{ `id` `name` `password` `disabled` }等，如果這個用戶有別的信息，建議另放在別的表裏
權限組：role{ `id` `name` } 很簡單，就只有這個組的描述，至於這個組裏到底有什麽內容，繼續往下
人-權限組 u-r{`user_id` `role_id` }這裏用 user 和 role 的主鍵關聯的壹對關系，至於建表時外鍵主鍵也很明了了
操作：option{`id` `name` `value` } 這個操作可以具體到妳某個頁面的某個按鈕或者鏈接，當然，其屬性要根據妳的實際應用有所變動
權限組-操作 {`role_id` `option_id` } 道理跟 “人-權限組” 差不多
現在有了這樣的數據關系支持了，控制層做權限判定也就很容易了，比如：
截獲現在得到的請求，根據請求包含的操作，還有發起這個請求的人，查壹下是不是這個操作屬於這個人，然後放行或者攔截，如果用到struts2，可以在攔截器（interceptor）裏面做這個權限過濾。當然，過濾器（filter）也可以.