實現業務系統中的用戶權限管理設計篇
B/S系統中的權限比C/S中的更顯的重要C/S系統因為具有特殊的客戶端所以訪問用戶的權限檢測可以通過客戶端實現或通過客戶端+服務器檢測實現而B/S中浏覽器是每一台計算機都已具備的如果不建立一個完整的權限檢測那麼一個非法用戶很可能就能通過浏覽器輕易訪問到B/S系統中的所有功能因此B/S業務系統都需要有一個或多個權限系統來實現訪問權限檢測讓經過授權的用戶可以正常合法的使用已授權功能而對那些未經授權的非法用戶將會將他們徹底的拒之門外下面就讓我們一起了解一下如何設計可以滿足大部分B/S系統中對用戶功能權限控制的權限系統
需求陳述不同職責的人員對於系統操作的權限應該是不同的優秀的業務系統這是最基本的功能
可以對
組
進行權限分配
對於一個大企業的業務系統來說
如果要求管理員為其下員工逐一分配系統操作權限的話
是件耗時且不夠方便的事情
所以
系統中就提出了對
組
進行操作的概念
將權限一致的人員編入同一組
然後對該組進行權限分配
權限管理系統應該是可擴展的
它應該可以加入到任何帶有權限管理功能的系統中
就像是組件一樣的可以被不斷的重用
而不是每開發一套管理系統
就要針對權限管理部分進行重新開發
滿足業務系統中的功能權限
傳統業務系統中
存在著兩種權限管理
其一是功能權限的管理
而另外一種則是資源權限的管理
在不同系統之間
功能權限是可以重用的
而資源權限則不能
關於設計
借助NoahWeb的動作編程理念在設計階段系統設計人員無須考慮程序結構的設計而是從程序流程以及數據庫結構開始入手為了實現需求數據庫的設計可謂及其重要無論是組操作的概念還是整套權限管理系統的重用性都在於數據庫的設計
我們先來分析一下數據庫結構
首先action表（以下簡稱為權限表）gorupmanager表（以下簡稱為管理組表）以及master表（以下簡稱為人員表）是三張實體表它們依次記錄著權限的信息管理組的信息和人員的信息如下圖
這三個表之間的關系是多對多的一個權限可能同時屬於多個管理組一個管理組中也可能同時包含多個權限同樣的道理一個人員可能同時屬於多個管理組而一個管理組中也可能同時包含多個人員如下圖
由於這三張表之間存在著多對多的關系那麼它們之間的交互最好使用另外兩張表來完成而這兩張表起著映射的作用分別是actiongroup表（以下簡稱權限映射表）和mastergroup表（以下簡稱人員映射表）前者映射了權限表與管理組表之間的交互後者映射了人員表與管理組表之間的交互如下圖
另外還需要一張表來控制系統運行時左側菜單中的權限分欄
也就是權限分欄表如下圖
根據上面的分析我們進行數據庫結構設計如下圖
點擊這裡查看權限管理系統數據表字段設計
為了能夠進行良好的分析我們將數據庫結構圖拆分開來三張實體表的作用已經很清晰現在我們來看一下兩張映射表的作用
一 權限映射表 如下圖
首先我們來了解一下權限映射表與管理組表以及權限表之間的字段關聯
看圖中的紅圈先看gorupid字段相關聯這種關聯方式在實際數據庫中的表現如下圖
如圖中所示管理組表中超級管理員的groupid為那麼權限映射表中groupid為的權限也就是超級管理員所擁有的權限
使用groupid字段關聯是為了查到一個管理組能夠執行的權限有哪些但這些權限的詳細信息卻是action字段關聯所查詢到的
action字段相關聯在數據庫中的表現如下圖
通過這種關聯才查詢到權限映射表之中那些權限的詳細信息綜合起來我們就知道了一個管理組可以執行的權限有哪些以及這些權限的詳細信息是什麼
或許你會問為什麼不使用actionid字段相關聯呢因為
權限表中的id字段在經過多次的數據庫操作之後可能會發生更改
權限映射表中僅僅記錄著一個管理組可以執行的權限
一旦權限表中的id更改
那麼權限映射表中的記錄也就更改了
一個管理組可以執行的權限勢必將出錯
這是非常不希望的
考慮到上面的情況所以應該使用action字段相關聯因為
在權限表中id可能發生變化而action字段卻是在任何情況下也不可能發生變化的
權限映射表中記錄的action字段也就不會變一個管理組可以執行的權限就不會出錯了
二 人員映射表 如下圖
我們來了解一下人員映射表與管理組表以及人員表之間的字段關聯如下圖
From:http://tw.wingwit.com/Article/program/net/201311/13938.html
