b/s系統中的許可權比c/s中的更顯的重要，c/s系統因為具有特殊的客戶端，所以訪問使用者的許可權檢測可以通過客戶端實現或通過客戶端+伺服器檢測實現， 而b/s中，瀏覽器是每一台計算機都已具備的，如果不建立乙個完整的許可權檢測，那麼乙個「非法使用者」很可能就能通過瀏覽器輕易訪問到b/s系統中的所有功 能。因此b/s業務系統都需要有乙個或多個許可權系統來實現訪問許可權檢測，讓經過授權的使用者可以正常合法的使用已授權功能，而對那些未經授權的「非法使用者」 將會將他們徹底的「拒之門外」。下面就讓我們一起了解一下如何設計可以滿足大部分b/s系統中對使用者功能許可權控制的許可權系統。
需求陳述
不同職責的人員，對於系統操作的許可權應該是不同的。優秀的業務系統，這是最基本 的功能。
可以對「組」進行許可權分配。對於乙個大企業的業務系統來說，如果要求管理員為其 下員工逐一分配系統操作許可權的話，是件耗時且不夠方便的事情。所以，系統中就提出了對「組」進行操作的概念，將許可權一致的人員編入同一組，然後對該組進行 許可權分配。
許可權管理系統應該是可擴充套件的。它應該可以加入到任何帶有許可權管理功能的系統中。 就像是元件一樣的可以被不斷的重用，而不是每開發一套管理系統，就要針對許可權管理部分進行重新開發。
滿足業務系統中的功能許可權。傳統業務系統中，存在著兩種許可權管理，其一是功能權 限的管理，而另外一種則是資源許可權的管理，在不同系統之間，功能許可權是可以重用的，而資源許可權則不能。
關於設計
借助noahweb的動 作程式設計理念，在設計階段，系統設計人員無須考慮程式結構的設計，而是從程式流程以及資料庫結構開始入手。為了實現需求，資料庫的設計可謂及其重要，無論是 「組」操作的概念，還是整套許可權管理系統的重用性，都在於資料庫的設計。
我們先來分析一下資料庫結構：
首先，action表（以 下簡稱為「許可權表」），gorupmanager表（以下簡稱為「管理組表」），以及master 表（以下簡稱為「人員表」），是三張實體表，它們依次記錄著「許可權」的資訊，「管理組」的資訊和「人員」的資訊。如下 圖：
[img]
這三個表之間的關係是多 對多的，乙個許可權可能同時屬於多個管理組，乙個管理組中也可能同時包含多個許可權。同樣的道理，乙個人員可能同時屬於多個管理組，而乙個管理組中也可能同時 包含多個人員。如下圖：
[img]
由於這三張表之間存在著 多對多的關係，那麼它們之間的互動，最好使用另外兩張表來完成。而這兩張表起著對映的作用，分別是「actiongroup」表（以下簡 稱「許可權對映表」）和「mastergroup」表（以下簡稱「人員對映表」），前者映**許可權表 與管理組表之間的互動。後者映**人員表與管理組表之間的互動。如下圖：
[img]
另外，還需要一張表來控 制系統執行時左側選單中的許可權分欄，也就是「許可權分欄表」，如下圖：
[img]
根據上面的分析，我們進 行資料庫結構設計，如下圖：
[img]
為了能夠進行良好的分 析，我們將資料庫結構圖拆分開來，三張實體表的作用已經很清晰，現在我們來看一下兩張對映表的作用。
一 許可權對映表 如下圖：
首先，我們來了解一下權 限對映表與管理組表以及許可權表之間的字段關聯。
[img]
[img]
如圖中所示，管 理組表中「超級管理員」的groupid為1，那麼許可權對映表中groupid為1的許可權也就是 「超級管理員」所擁有的許可權。
使用groupid欄位 關聯，是為了查到乙個管理組能夠執行的許可權有哪些。但這些許可權的詳細資訊卻是action欄位關聯所查詢到的。
[img]
通過這種關聯，才查詢到權 限對映表之中那些許可權的詳細資訊。綜合起來，我們就知道了乙個管理組可以執行的許可權有哪些，以及這些許可權的詳細資訊是什麼。
許可權表中的id欄位在經過多次的資料庫操作之後可能會發生更改。
許可權對映表中僅僅記錄著乙個管理組可以執行的許可權。
一旦許可權表中的id更改，那麼許可權對映表中 的記錄也就更改了。
乙個管理組可以執行的許可權勢必將出錯，這是非常不希望的。
在許可權表中，id可能發生變化，而action欄位卻是在任何情況下也不可能發 生變化的。
許可權對映表中記錄的action欄位也就不會變。
乙個管理組可以執行的許可權就不會出錯了。
二 人員對映表 如下圖：
我們來 了解一下人員對映表與管理組表以及人員表之間 的字段關聯，如下圖：
[img]
看圖中 的紅圈部分，先看groupid欄位關聯，這種關聯方式在資料庫中的表現如下圖：
[img]
如圖， 「超級管理員」組的groupid為1，我們再看人員對映表，admin屬於超級管理員組，而 administrator屬於超級管理員組，同時也屬於管理員組。
使用這 種關聯方式，是為了查到乙個管理組中的人員有誰。和上面一樣，人員的詳細資訊是靠id欄位（人員對映表中是 masterid欄位）關聯查詢到的。
id字 段（人員對映表中是masterid欄位）關聯表現在資料庫中的形式如下圖：
[img]
乙個人 員可能同時屬於多個「管理組」，如圖中，administrator就同時屬於兩個「管理組」。所以，在人員對映表中 關於administrator的記錄就會是兩條。
這種關 聯方式才查詢到管理組中人員的詳細資訊有哪些。綜合起來，才可以知道乙個管理組中的人員有誰，以及這個人員的詳細資訊。
再結合 上面談到的許可權表和許可權對映表，就實現了需求中的「組」操作，如下圖：
[img]
其實，管 理組表中僅僅記錄著組的基本資訊，如名稱，組id等等。至於乙個組中人員的詳細資訊，以及該組能夠執行的許可權的詳細資訊，都記錄在人 員表和許可權表中。兩張對映表才真正記錄著乙個組有哪些人員，能 夠執行哪些許可權。通過兩張對映表的銜接，三張實體表之間的互動才得以實現，從而完成了需求中提到的「組」操作。
我們再 來看一下許可權分欄表與許可權表之間的互動。這兩張表之間的字段關聯如下圖：
[img]
[img]
如圖所 示，通過這種關聯方式，我們可以非常清晰的看到許可權表中的許可權屬於哪個分欄。
現在， 資料庫結構已經很清晰了，分配許可權的功能以及「組」操作都已經實現。下面我們再來分析一下需求中提到的關於許可權管理系統的重用性問題。
為什麼 使用這種資料庫設計方式搭建起來的系統可以重用呢？
三張實體表中記錄著系統中的三個決定性元素。「許可權」，「組」和「人」。而這三 種元素可以任意新增，彼此之間不受影響。無論是那種型別的業務系統，這三個決定性元素是不會變的，也就意味著結構上不會變，而變的僅僅是資料。
兩張對映表中記錄著三個元素之間的關係。但這些關係完全是人為建立的，需要變化 的時候，只是對資料庫中的記錄進行操作，無需改動結構。
許可權分欄表中記錄著系統使用時顯示的分欄。無論是要新增分欄，修改分欄還是減少 分欄，也只不過是操作記錄而已。
綜 上所述，這樣設計資料庫，系統是完全可以重用的，並且經受得住「變更」考驗的。
總結：此 套系統的重點在於，三張實體表牢牢地抓住了系統的核心成分，而兩張對映表完美地對映出三張實體表之間的互動。其難點在 於，理解對映表的工作，它記錄著關係，並且實現了「組」操作的概念。而系統總體的設計是本著可以在不同的mis系統中「重用」來滿足不同系統的功能許可權設 置。
附錄：許可權管理系統資料表的字 段設計
下 面我們來看看許可權管理系統的資料庫表設計，共分為六張表，如下圖：
action表：
[img]
action 表中記錄著系統中所有的動作，以及動作相關描述。
actioncolumn表：
[img]
actioncolumn 表中記錄著動作的分欄，系統執行時，左側選單欄提供了幾塊不同的功能，每一塊就是乙個分欄，每新增乙個分欄，該表中的記錄就會增加一條,相對應的，左側菜 單欄中也會新增機乙個欄。
actiongroup表：
[img]
actiongroup 表記錄著動作所在的組。
groupmanager表：
[img]
groupmanager 表記錄著管理組的相關資訊，每新增乙個管理組，這裡的記錄就會增加一條。
mastergroup表：
[img]
mastergroup 表記錄著管理員所在的管理組，由於一名管理員可能同同時屬於多個組，所以該表中關於某一名管理員的記錄可能有多條。
master表：
[img]
master 表記錄著所有管理員的資訊，每新增乙個管理員，該錶就會增加一條記錄。
實現業務系統中的使用者許可權管理
最近學那個使用者許可權管理系統，鬱悶的很啊，總是理解地雲裡雲霧 最後還是從網上搜尋一兩篇有關於使用者許可權的系統，很詳細，有時間慢慢看一下，理解還是有好處滴 還希望那位有心大蝦教教 歷時三周的通訊錄系統，讓我對許可權管理有更深的理解了 這是做這個專案，對於許可權管理的總結 第一步 通過登入的使用者名...
許可權系統使用者管理功能剖析
使用者管理功能是許可權系統中的核心功能，管理著企業應用系統中所有的相關使用者資料，通過此功能可以實現新建或刪除使用者 使用者狀態的改變 查詢使用者相關資訊，為使用者增加角色以及許可權等。許可權管理系統操作介面的友好程度以及效能的優劣性，帶給終端使用者的體驗效果也是截然不同的。由慧都科技開發的upms...
Pb中多使用者許可權管理實現方案
pb 中多使用者許可權管理實現方案 南京審計學院教育技術中心 210029 丁國勇 在pb實現一般管理系統的時候，我們會遇到這樣一種情況，作為乙個系統，可以分為若干個子系統，有多個操作員對它進行操作，每個操作員對各個子系統的許可權不同，甚至在同一子系統中，操作員對各個選單項的 操作許可權也不一樣，更...