資料庫許可權表設計

『壹』 一個角色對應多個用戶，一個用戶又有多個許可權怎麼設計資料庫

前端的登陸界面，除了用戶名、密碼之外，添加一個下拉框選擇公司名稱
使用兩個表的聯合查詢
sql
=
"select
a.position
from
user
a,corp
b
where
a.corpid
=
b.corpid
and
a.username
=
and
a.password
=
and
b.corpname
=
";
把輸入的用戶名、密碼、公司名稱這三個數據代入到三個號中。

『貳』 java許可權系統資料庫的設計，三張表的那種

資料庫和程序都很重要。 資料庫方面設計許可權這一塊設計三張表，（用戶表、角色表、許可權表）， 許可權表關聯用戶表和角色表的外鍵，這個就兩個一對多的關系代替了，多對多的關系。 在hibernate中配置的時候要配置用戶表和角色表的多對多關系。

『叄』 java 許可權管理系統中數據許可權的設計與使用

建立一個角色資源表，表中各種資源設置不同的類型，比如菜單類型為0，數據許可權類型為1等等，表中也可以規定能訪問的數據規則，取得表中數據規則放到sql語句。

『肆』 2、用戶許可權管理，資料庫表設計

網上資料說許可權設計 = 功能許可權 + 數據許可權，我認為還是很有道理的。之前項目中只涉及到功能許可權，沒有數據許可權，原因是最開始設計時，數據已經綁定在特定的用戶下了，而且涉及到的表數量很少，不需要單獨考慮數據許可權的問題。

許可權管理，最細致的許可權管理有 用戶，用戶組，角色，許可權，功能。根據不同的需求適當選擇，如 用戶量過大，每個人都授權和麻煩，就引入用戶組，對用戶組賦予許可權。功能上也根據業務不同做適當的擴展。由於如用戶許可權之前存在多對多關系，需要引入中間表。
本系統設計如下：

數據量很小，功能也不復雜，所以只有用戶，角色，許可權（功能）及產生的中間表。
表中的數據都是提前填的，用戶登陸，查ermroleuser表，獲取角色，查ermrolefunction表，獲取功能，再查ermfunction表，返回該用戶的功能的中文，在頁面上展示。

功能許可權詳細設計請參考，本項目也是受此啟發：
http://blog.csdn.net/painsonline/article/details/7183613/

需求：給一個原來沒有許可權的數據配置系統加上登錄，許可權功能，不同角色查同一張表返回結果不同。
思路：所謂數據許可權，關注點在於實體屬性值、條件、允許值，用戶登錄後，查詢該用戶的查詢條件，根據條件獲取數據即可。詳細表結構設計可以參考： https://zhuanlan.hu.com/p/31339794

具體介紹一下每個欄位含義：
（1）主鍵 id；
（2）acl_id 映射許可權點表主鍵，代表每行記錄是針對哪個許可權點的；
（3）status 代表當前這條配置是否有效，方便臨時激活與禁用；
（4）param 代表需要校驗的參數名，允許一個請求有多個參數參與數據校驗；如果參數復雜，比如包含對象，定義的參數可能為a.b.c 這種多級的形式，建議不要太復雜
（5）operation 代表數據攔截的規則，使用數字代表是等於、大於、小於、大於等於、小於等於、包含、介於之間等，可以根據自己需要增加或減少支持的攔截規則
（6）value1 和 value2 用來和param、operation組成一個關系表達式，比如：1<=a<2
next_param_op 欄位根據需要使用，如果一個許可權點支持多條數據規則時，連接兩個規則之間的操作，|| 還是 &&
（7）seq 欄位用於某個許可權點包含多條數據許可權規則時的順序

假設有這么一條數據，那麼他的含義是：id為1（acl_id）的許可權點，配置了一條有效（status=1）的數據規則，規則是：傳入參數id（param）的值要大於（operation）10（value1）

這種設計很細致了，當然我的項目沒有那麼復雜，所以最終沒有採用這個。
http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.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表記錄著所有管理員的信息，每添加一個管理員，該表就會增加一條記錄。

『陸』 怎麼設計用戶許可權管理系統資料庫要用到哪幾張表每張表有哪些欄位

什麼樣的許可權？菜單許可權？
一般用戶表，角色表，模塊表（或者菜單啊反正是你要許可權的東西），然後角色和模塊的表
這是最簡單的結構，用戶關聯角色，角色關聯模塊，用角色去控制許可權，增刪改查什麼的模塊表呢，就是你要控制的東西，比菜單，根據登錄人的角色，看有哪些模塊，然後顯示這些模塊其他的模塊隱藏。
如果需要復雜的東西，中間可以加別的東西，具體看你需求了
至於欄位，用戶和角色就沒什麼可說的，無法就是名字啊什麼的
模塊表也簡單，比如模塊名稱，ID，父子模塊id（如果有父子模塊的話），具體欄位還是要看需求。

『柒』 怎麼設計用戶許可權管理系統資料庫

一般用戶表，角色表，模塊表（或者菜單啊反正是你要許可權的東西），然後角色和模塊的表
這是最簡單的結構，用戶關聯角色，角色關聯模塊，用角色去控制許可權，增刪改查什麼的模塊表呢，就是你要控制的東西，比菜單，根據登錄人的角色，看有哪些模塊，然後顯示這些模塊其他的模塊隱藏。
如果需要復雜的東西，中間可以加別的東西，具體看你需求了。