實作業務系統中的使用者權限管理
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系統中“重用”來滿足不同系統的功能權限設定。