幾篇不錯的權限管理系統講述
1.講的很詳細
http://www.cnblogs.com/Gavinzhao/archive/2009/11/10/1599691.html
實現業務系統中的用戶權限管理--設計篇
B/S系統中的權限比C/S中的更顯的重要，C/S系統因為具有特殊的客戶端，所以訪問用戶的權限檢測可以通過客戶端實現或通過客戶端+服務器檢測實現，而B/S中，瀏覽器是每一臺計算機都已具備的，如果不建立一個完整的權限檢測，那么一個“非法用戶”很可能就能通過瀏覽器輕易訪問到B/S系統中的所有功能。因此B/S業務系統都需要有一個或多個權限系統來實現訪問權限檢測，讓經過授權的用戶可以正常合法的使用已授權功能，而對那些未經授權的“非法用戶”將會將他們徹底的“拒之門外”。下面就讓我們一起了解一下如何設計可以滿足大部分B/S系統中對用戶功能權限控制的權限系統。
需求陳述不同職責的人員，對于系統操作的權限應該是不同的。優秀的業務系統，這是最基本的功能。
-
- 可以對“組”進行權限分配。對于一個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作權限的話，是件耗時且不夠方便的事情。所以，系統中就提出了對“組”進行操作的概念，將權限一致的人員編入同一組，然后對該組進行權限分配。
- 權限管理系統應該是可擴展的。它應該可以加入到任何帶有權限管理功能的系統中。就像是組件一樣的可以被不斷的重用，而不是每開發一套管理系統，就要針對權限管理部分進行重新開發。
- 滿足業務系統中的功能權限。傳統業務系統中，存在著兩種權限管理，其一是功能權限的管理，而另外一種則是資源權限的管理，在不同系統之間，功能權限是可以重用的，而資源權限則不能。
關于設計
借助NoahWeb的動作編程理念，在設計階段，系統設計人員無須考慮程序結構的設計，而是從程序流程以及數據庫結構開始入手。為了實現需求，數據庫的設計可謂及其重要，無論是“組”操作的概念，還是整套權限管理系統的重用性，都在于數據庫的設計。
我們先來分析一下數據庫結構：
首先，action表（以下簡稱為“權限表”），gorupmanager表（以下簡稱為“管理組表”），以及master表（以下簡稱為“人員表”），是三張實體表，它們依次記錄著“權限”的信息，“管理組”的信息和“人員”的信息。如下圖：
這三個表之間的關系是多對多的，一個權限可能同時屬于多個管理組，一個管理組中也可能同時包含多個權限。同樣的道理，一個人員可能同時屬于多個管理組，而一個管理組中也可能同時包含多個人員。如下圖：
由于這三張表之間存在著多對多的關系，那么它們之間的交互，最好使用另外兩張表來完成。而這兩張表起著映射的作用，分別是“actiongroup”表（以下簡稱“權限映射表”）和“mastergroup”表（以下簡稱“人員映射表”），前者映射了權限表與管理組表之間的交互。后者映射了人員表與管理組表之間的交互。如下圖：
另外，還需要一張表來控制系統運行時左側菜單中的權限分欄，也就是“權限分欄表”，如下圖：
根據上面的分析，我們進行數據庫結構設計，如下圖：
為了能夠進行良好的分析，我們將數據庫結構圖拆分開來，三張實體表的作用已經很清晰，現在我們來看一下兩張映射表的作用。
一權限映射表如下圖：
首先，我們來了解一下權限映射表與管理組表以及權限表之間的字段關聯。
看圖中的紅圈，先看gorupid字段相關聯，這種關聯方式在實際數據庫中的表現如下圖：
如圖中所示，管理組表中“超級管理員”的groupid為1，那么權限映射表中groupid為1的權限也就是“超級管理員”所擁有的權限。
使用groupid字段關聯，是為了查到一個管理組能夠執行的權限有哪些。但這些權限的詳細信息卻是action字段關聯所查詢到的。
action字段相關聯在數據庫中的表現如下圖：
通過這種關聯，才查詢到權限映射表之中那些權限的詳細信息。綜合起來，我們就知道了一個管理組可以執行的權限有哪些，以及這些權限的詳細信息是什么。
或許你會問，為什么不使用actionid字段相關聯呢？因為：
- 權限表中的id字段在經過多次的數據庫操作之后可能會發生更改。
- 權限映射表中僅僅記錄著一個管理組可以執行的權限。
- 一旦權限表中的id更改，那么權限映射表中的記錄也就更改了。
- 一個管理組可以執行的權限勢必將出錯，這是非常不希望的。
考慮到上面的情況，所以應該使用action字段相關聯，因為：
- 在權限表中，id可能發生變化，而action字段卻是在任何情況下也不可能發生變化的。
- 權限映射表中記錄的action字段也就不會變。
- 一個管理組可以執行的權限就不會出錯了。
二人員映射表如下圖：
我們來了解一下人員映射表與管理組表以及人員表之間的字段關聯，如下圖：
看圖中的紅圈部分，先看groupid字段關聯，這種關聯方式在數據庫中的表現如下圖：
如圖，“超級管理員”組的groupid為1，我們再看人員映射表，admin屬于超級管理員組，而administrator屬于超級管理員組，同時也屬于管理員組。
使用這種關聯方式，是為了查到一個管理組中的人員有誰。和上面一樣，人員的詳細信息是靠id字段（人員映射表中是masterid字段）關聯查詢到的。
id字段（人員映射表中是masterid字段）關聯表現在數據庫中的形式如下圖：
一個人員可能同時屬于多個“管理組”，如圖中，administrator就同時屬于兩個“管理組”。所以，在人員映射表中關于administrator的記錄就會是兩條。
這種關聯方式才查詢到管理組中人員的詳細信息有哪些。綜合起來，才可以知道一個管理組中的人員有誰，以及這個人員的詳細信息。
再結合上面談到的權限表和權限映射表，就實現了需求中的“組”操作，如下圖：
其實，管理組表中僅僅記錄著組的基本信息，如名稱，組id等等。至于一個組中人員的詳細信息，以及該組能夠執行的權限的詳細信息，都記錄在人員表和權限表中。兩張映射表才真正記錄著一個組有哪些人員，能夠執行哪些權限。通過兩張映射表的銜接，三張實體表之間的交互才得以實現，從而完成了需求中提到的“組”操作。
我們再來看一下權限分欄表與權限表之間的交互。這兩張表之間的字段關聯如下圖：
兩張表使用了actioncolumnid字段相關聯，這種關聯方式在數據庫中的表現如下圖：
如圖所示，通過這種關聯方式，我們可以非常清晰的看到權限表中的權限屬于哪個分欄。
現在，數據庫結構已經很清晰了，分配權限的功能以及“組”操作都已經實現。下面我們再來分析一下需求中提到的關于權限管理系統的重用性問題。
為什么使用這種數據庫設計方式搭建起來的系統可以重用呢？
- 三張實體表中記錄著系統中的三個決定性元素。“權限”，“組”和“人”。而這三種元素可以任意添加，彼此之間不受影響。無論是那種類型的業務系統，這三個決定性元素是不會變的，也就意味著結構上不會變，而變的僅僅是數據。
- 兩張映射表中記錄著三個元素之間的關系。但這些關系完全是人為創建的，需要變化的時候，只是對數據庫中的記錄進行操作，無需改動結構。
- 權限分欄表中記錄著系統使用時顯示的分欄。無論是要添加分欄，修改分欄還是減少分欄，也只不過是操作記錄而已。
綜上所述，這樣設計數據庫，系統是完全可以重用的，并且經受得住“變更”考驗的。
總結：
此套系統的重點在于，三張實體表牢牢地抓住了系統的核心成分，而兩張映射表完美地映射出三張實體表之間的交互。其難點在于，理解映射表的工作，它記錄著關系，并且實現了“組”操作的概念。而系統總體的設計是本著可以在不同的MIS系統中“重用”來滿足不同系統的功能權限設置。
附錄：
權限管理系統數據表的字段設計
下面我們來看看權限管理系統的數據庫表設計，共分為六張表，如下圖：
action表：
action表中記錄著系統中所有的動作，以及動作相關描述。
actioncolumn表：
actioncolumn表中記錄著動作的分欄，系統運行時，左側菜單欄提供了幾塊不同的功能，每一塊就是一個分欄，每添加一個分欄，該表中的記錄就會增加一條,相對應的，左側菜單欄中也會新增機一個欄。
actiongroup表：
actiongroup表記錄著動作所在的組。
groupmanager表：
groupmanager表記錄著管理組的相關信息，每添加一個管理組，這里的記錄就會增加一條。
mastergroup表：
mastergroup表記錄著管理員所在的管理組，由于一名管理員可能同同時屬于多個組，所以該表中關于某一名管理員的記錄可能有多條。
master表：
master表記錄著所有管理員的信息，每添加一個管理員，該表就會增加一條記錄。
2.觀點很好
http://www.cnblogs.com/leoxie2011/archive/2011/05/19/2050626.html
一，前言
權限管理系統的應用者應該有三種不同性質上的使用，
A,使用權限
B,分配權限
C,授權權限
本文只從《使用權限》和《分配權限》這兩種應用層面分析，暫時不考慮《授權權限》這種。
二，初步分析
用戶和角色
說到權限管理，首先應該想到，當然要設計一個用戶表，一個權限表。這樣就決定了一個人有什么樣的權限。
做著做著就會發現這樣設計太過繁瑣，如果公司里面所有員工都有這樣的權限呢，每一個人都要配置？那是一件很痛苦的事情。因此再添加一個角色表，把某些人歸為一類，然后再把權限分配給角色。角色屬下的用戶也就擁有了權限。
用戶、角色之間的關系是一個用戶可以對應多個角色，一個角色可以對應多個用戶。多對多關系。
所以需要一個中間表，相信大家都很熟悉，自然不會有疑問。
應用場景
有了用戶和角色以后，就需要設計應用場景，比如一個應用程序有幾大模塊（系統模塊、項目管理模塊、銷售模塊），
類似這樣的模塊就是一種應用場景，常見的還有 菜單 、 操作 等等。
假設現在我們設計好了，應用場景包括 模塊、菜單、和操作，那么應該有以下六種關系
- 一個用戶可以對應多個模塊，一個模塊可以對應多個用戶。多對多關系。
- 一個用戶可以對應多個菜單，一個菜單可以對應多個用戶。多對多關系。
- 一個用戶可以對應多個操作，一個操作可以對應多個用戶。多對多關系。
- 一個角色可以對應多個模塊，一個模塊可以對應多個角色。多對多關系。
- 一個角色可以對應多個菜單，一個菜單可以對應多個角色。多對多關系。
- 一個角色可以對應多個操作，一個操作可以對應多個角色。多對多關系。
于是建立六張表來維護這六種關系。
這樣設計看起來沒什么問題。是的，如果沒有加入新的關系的話，這樣是已經可以滿足大部分的需求了。可是如果就是如果，新的關系（需求）往往會加入到系統進來。這個時候就需要再建立一個新的表。系統的復雜度也隨著增加。
可以看出，這樣的設計有幾個問題：
- 數據表設計太復雜
- 應對系統方案過于固定
三，把問題簡單化
不同的應用場合，你可能會想出不同的需求，提了一個新的需求以后，可能會發現原來的設計沒方法實現了，于是還要添加一個新的表。這也是上面所提到的問題。
其實不必想得那么復雜，權限可以簡單描述為：
某某主體 在 某某領域 有 某某權限
1，主體可以是用戶，可以是角色，也可以是一個部門
2， 領域可以是一個模塊，可以是一個頁面，也可以是頁面上的按鈕
3， 權限可以是“可見”，可以是“只讀”，也可以是“可用”(如按鈕可以點擊)
其實就是Who、What、How的問題
因此上面所提到的六張表其實可以設計一張表：
四，實例說明
下面用一個例子做設計說明。“用戶、角色在頁面上的是使用權限”
詳細設計：
1，把菜單的配置放在數據庫上，每一個菜單對于一個唯一的編碼MenuNo，每一個“葉節點”的菜單項對于一個頁面(url)。
2，把按鈕的配置放在數據庫上，并歸屬于一個菜單項上（其實就是掛在某一個頁面上）。應該一個頁面可能會有幾個按鈕組，比如說有兩個列表，這兩個列表都需要有“增加、修改、刪除”。所以需要增加一個按鈕分組的字段來區分。
3,把菜單權限分配給用戶/角色，PrivilegeMaster為"User"或"Role",PrivilegeMasterValue為UserID或RoleID,PrivilegeAccess為“Menu",PrivilegeAccessValue為MenuNo,PrivilegeOperation為"enabled"
4,把按鈕權限分配給用戶/角色，PrivilegeMaster為"User"或"Role",PrivilegeMasterValue為UserID或RoleID,PrivilegeAccess為“Button",PrivilegeAccessValue為BtnID,PrivilegeOperation為"enabled"
5,如果需要禁止單個用戶的權限，PrivilegeOperation 設置為"disabled"。
如果不清楚的可以看下圖：
數據庫設計：
四，結語
說了這么多，其實我推薦的只是Privilege的表設計。這個表是who、what、how問題原型的設計。不僅擴展性、靈活性都很好，而且將復雜的權限管理系統濃縮成一句話。
而PrivilegeOperation不僅僅只是使用和禁止兩種，包括分配權限、授權權限，都可以用這個字段定義。只是這無疑加大了應用程序的設計難度，但是對于表設計可以不做出任何的修改就可以完成，可以看出其靈活性。