小型項目的用戶角色權限的設計

實現業務系統中的用戶權限管理

　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表記錄着全部管理員的信息，每添加一個管理員，該表就會增長一條記錄。