【轉載】使用者·角色·許可權·表的設計
轉自：https://www.cnblogs.com/oo_o/p/8213448.html
設計一個靈活、通用、方便的許可權管理系統。
在這個系統中，我們需要對系統的所有資源進行許可權控制，那麼系統中的資源包括哪些呢？我們可以把這些資源簡單概括為靜態資源（功能操作、資料列）和動態資源（資料），也分別稱為物件資源和資料資源，後者是我們在系統設計與實現中的叫法。
系統的目標就是對應用系統的所有物件資源和資料資源進行許可權控制，比如應用系統的功能選單、各個介面的按鈕、資料顯示的列以及各種行級資料進行許可權的操控。
三．相關物件及其關係
大概理清了一下許可權系統的相關概念，如下所示：
1. 許可權
系統的所有許可權資訊。許可權具有上下級關係，是一個樹狀的結構。下面來看一個例子
系統管理
使用者管理
檢視使用者
新增使用者
修改使用者
刪除使用者
對於上面的每個許可權，又存在兩種情況，一個是隻是可訪問，另一種是可授權，例如對於“檢視使用者”這個許可權，如果使用者只被授予“可訪問”，那麼他就不能將他所具有的這個許可權分配給其他人。
2. 使用者
應用系統的具體操作者，使用者可以自己擁有許可權資訊，可以歸屬於0～n個角色，可屬於0～n個組。他的許可權集是自身具有的許可權、所屬的各角色具有的許可權、所屬的各組具有的許可權的合集。它與許可權、角色、組之間的關係都是n對n的關係。
3. 角色
為了對許多擁有相似許可權的使用者進行分類管理，定義了角色的概念，例如系統管理員、管理員、使用者、訪客等角色。角色具有上下級關係，可以形成樹狀檢視，父級角色的許可權是自身及它的所有子角色的許可權的綜合。父級角色的使用者、父級角色的組同理可推。
4. 組
為了更好地管理使用者，對使用者進行分組歸類，簡稱為使用者分組。組也具有上下級關係，可以形成樹狀檢視。在實際情況中，我們知道，組也可以具有自己的角色資訊、許可權資訊。這讓我想到我們的QQ使用者群，一個群可以有多個使用者，一個使用者也可以加入多個群。每個群具有自己的許可權資訊。例如檢視群共享。QQ群也可以具有自己的角色資訊，例如普通群、高階群等。
針對上面提出的四種類型的物件，讓我們通過圖來看看他們之間的關係。
有上圖中可以看出，這四者的關係很複雜，而實際的情況比這個圖還要複雜，許可權、角色、組都具有上下級關係，許可權管理是應用系統中比較棘手的問題，要設計一個通用的許可權管理系統，工作量也著實不小。
當然對於有些專案，許可權問題並不是那麼複雜。有的只需要牽涉到許可權和使用者兩種型別的物件，只需要給使用者分配許可權即可。
在另一些情況中，引入了角色物件，例如基於角色的許可權系統，只需要給角色分配許可權，使用者都隸屬於角色，不需要單獨為使用者分配角色資訊。
通用許可權管理設計篇（二）——資料庫設計
國慶前整的通用許可權設計的資料庫初步設計部分，現在貼上來。
理清了物件關係之後，讓我們接著來進行資料庫的設計。在資料庫建模時，對於N對N的
關係，一般需要加入一個關聯表來表示關聯的兩者的關係。初步估計一下，本系統至少需要十張表，分別為：許可權表、使用者表、角色表、組表、使用者許可權關聯表、用
戶角色關聯表、角色許可權關聯表、組許可權關聯表、組角色關聯表、使用者屬組關聯表。當然還可能引出一些相關的表。下面讓我們在PowerDesigner中畫出各表吧。
各表及其關係如下：
1. 使用者表
| 使用者表（TUser） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
tu_id |
bigint |
pk, not null |
| 所屬組織 |
to_id |
bigint |
fk, not null |
| 登入帳號 |
login_name |
varchar(64) |
not null |
| 使用者密碼 |
password |
varchar(64) |
not null |
| 使用者姓名 |
vsername |
varchar(64) |
not null |
| 手機號 |
mobile |
varchar(20) |
|
| 電子郵箱 |
|
varchar(64) |
|
| 建立時間 |
gen_time |
datetime |
not null |
| 登入時間 |
login_time |
datetime |
|
| 上次登入時間 |
last_login_time |
datetime |
|
| 登入次數 |
count |
bigint |
not null |
2. 角色表
| 角色表（TRole） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 角色ID |
tr_id |
bigint |
pk, not null |
| 父級角色ID |
parent_tr_id |
bigint |
not null |
| 角色名稱 |
role_name |
varchar(64) |
not null |
| 建立時間 |
gen_time |
datetime |
not null |
| 角色描述 |
description |
varchar(200) |
|
3. 許可權表
| 許可權表（TRight） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 許可權ID |
tr_id |
bigint |
pk, not null |
| 父許可權 |
parent_tr_id |
bigint |
not null |
| 許可權名稱 |
right_name |
varchar(64) |
not null |
| 許可權描述 |
description |
varchar(200) |
|
4. 組表
| 組表（TGroup） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 組ID |
tg_id |
bigint |
pk, not null |
| 組名稱 |
group_name |
varchar(64) |
not null |
| 父組 |
parent_tg_id |
bigint |
not null |
| 建立時間 |
gen_time |
datetime |
not null |
| 組描述 |
description |
varchar(200) |
|
5. 角色許可權表
| 角色許可權表（TRoleRightRelation） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
trr_id |
bigint |
pk, not null |
| 角色 |
Role_id |
bigint |
fk, not null |
| 許可權 |
right_id |
bigint |
fk, not null |
| 許可權型別 |
right_type |
int |
not null（0:可訪問，1:可授權） |
6. 組許可權表
| 組許可權表（TGroupRightRelation） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
tgr_id |
bigint |
pk, not null |
| 組 |
tg_id |
bigint |
fk, not null |
| 許可權 |
tr_id |
bigint |
fk, not null |
| 許可權型別 |
right_type |
int |
not null（0:可訪問，1:可授權） |
7. 組角色表
| 組角色表（TGroupRoleRelation） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
tgr_id |
bigint |
pk, not null |
| 組 |
tg_id |
bigint |
fk, not null |
| 角色 |
tr_id |
bigint |
pk, not null |
8. 使用者許可權表
| 使用者許可權表（TUserRightRelation） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
tur_id |
bigint |
pk, not null |
| 使用者 |
tu_id |
bigint |
fk, not null |
| 許可權 |
tr_id |
bigint |
fk, not null |
| 許可權型別 |
right_type |
int |
not null（0:可訪問，1:可授權） |
9. 使用者角色表
| 使用者角色表（TUserRoleRelation） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
tur_id |
bigint |
pk, not null |
| 使用者 |
tu_id |
bigint |
fk, not null |
| 角色 |
tr_id |
bigint |
fk, not null |
10. 使用者組表
| 使用者組表（TUserGroupRelation） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 記錄標識 |
tug_id |
bigint |
pk, not null |
| 使用者 |
tu_id |
bigint |
fk, not null |
| 組 |
tg_id |
bigint |
fk, not null |
11. 組織表
| 組織表（TOrganization） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 組織id |
to_id |
bigint |
pk, not null |
| 父組 |
parent_to_id |
bigint |
not null |
| 組織名稱 |
org_name |
varchar(64) |
not null |
| 建立時間 |
gen_time |
datetime |
not null |
| 組織描述 |
description |
varchar(200) |
|
12. 操作日誌表
| 操作日誌表（TLog） |
|||
| 欄位名稱 |
欄位 |
型別 |
備註 |
| 日誌ID |
log_id |
bigint |
pk, not null |
| 操作型別 |
op_type |
int |
not null |
| 操作內容 |
content |
varchar(200) |
not null |
| 操作人 |
tu_id |
bigint |
fk, not null |
| 操作時間 |
gen_time |
datetime |
not null |
1. 許可權資源
系統的所有許可權資訊。許可權具有上下級關係，是一個樹狀的結構。下面來看一個例子
系統管理
使用者管理
檢視使用者
新增使用者
修改使用者
刪除使用者
對於上面的每個許可權，又存在兩種情況，一個是隻是可訪問，另一種是可授權，例如對於“檢視使用者”這個許可權，如果使用者只被授予“可訪問”，那麼他就不能將他所具有的這個許可權分配給其他人。
2. 使用者
應用系統的具體操作者，使用者可以自己擁有許可權資訊，可以歸屬於0～n個角色，可屬於0～n個組。他的許可權集是自身具有的許可權、所屬的各角色具有的許可權、所屬的各組具有的許可權的合集。它與許可權、角色、組之間的關係都是n對n的關係。
3. 角色
為了對許多擁有相似許可權的使用者進行分類管理，定義了角色的概念，例如系統管理員、管理員、使用者、訪客等角色。角色具有上下級關係，可以形成樹狀檢視，父級角色的許可權是自身及它的所有子角色的許可權的綜合。父級角色的使用者、父級角色的組同理可推。
4. 組
為了更好地管理使用者，對使用者進行分組歸類，簡稱為使用者分組。組也具有上下級關係，可以形成樹狀檢視。在實際情況中，我們知道，組也可以具有自己的角色資訊、許可權資訊。這讓我想到我們的QQ使用者群，一個群可以有多個使用者，一個使用者也可以加入多個群。每個群具有自己的許可權資訊。例如檢視群共享。QQ群也可以具有自己的角色資訊，例如普通群、高階群等。
針對如上提出的四種物件，我們可以整理得出它們之間的關係圖，如下所示：
總體設計思路是將系統分為組許可權管理、角色許可權管理、使用者許可權管理、組織管理和操作日誌管理五部分。
其中組許可權管理包括包含使用者、所屬角色、組許可權資源和組總許可權資源四部分，某個組的許可權資訊可用公式表示：組許可權 = 所屬角色的許可權合集 + 組自身的許可權。
角色許可權管理包括包含使用者、包含組和角色許可權三部分，某個角色的許可權的計算公式為：角色許可權 = 角色自身許可權。
使用者許可權管理包括所屬角色、所屬組、使用者許可權、使用者總許可權資源和組織管理五部分。某個使用者總的許可權資訊存在如下計算公式：使用者許可權 = 所屬角色許可權合集 + 所屬組許可權合集 + 使用者自身許可權。
組織管理即對使用者所屬的組織進行管理，組織以樹形結構展示，組織管理具有組織的增、刪、改、查功能。
操作日誌管理用於管理本系統的操作日誌。
注意：因為組和角色都具有上下級關係，所以下級的組或角色的許可權只能在自己的直屬上級的許可權中選擇，下級的組或者角色的總的許可權都不能大於直屬上級的總許可權。
2.5 模組結構設計
本系統的具有的功能模組結構如下圖所示：
2.6 尚未解決的問題
無。
3. 介面設計（暫略）
3.1 使用者介面（暫略）
3.2 外部介面（暫略）
3.3 內部介面（暫略）
4. 介面總體設計
本節將闡述使用者介面的實現，在此之前對頁面元素做如下約定：
| 序號 |
頁面元素 |
約定 |
| 1 |
按鈕 |
未選中時：[按鈕名稱] 選中時：[按鈕名稱] |
| 2 |
單選框 |
○ 選項 |
| 3 |
複選框 |
□ 選項 |
| 4 |
下拉框 |
[選項,…,] ▽ |
| 5 |
文字框 |
|________| |
| 6 |
TextArea |
|…………| |
| 7 |
頁籤 |
未選中時：選項名稱 選中時：選項名稱 |
| 8 |
未選中連結 |
連結文字 |
| 9 |
選中連結 |
連結文字 |
| 10 |
說明資訊 |
說明資訊 |
4.1 組許可權管理
4.1.1包含使用者
| 組資訊 組1 組11 組12 組… 組2 組21 組22 組…
|
所選擇組：組1 [包含使用者] [所屬角色] [組許可權] [總許可權] [修改] 使用者名稱 姓名 手機號 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
當用戶選擇“修改”按鈕時，彈出使用者列表，操作人可以通過勾選或取消勾選來修改該組所包含的使用者。
4.1.2所屬角色
| 組資訊 組1 組11 組12 組… 組2 組21 組22 組…
|
所選擇組：組1 [包含使用者] [所屬角色] [組許可權] [總許可權] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 --
|
當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以通過勾選或取消勾選來修改該組所屬的角色。
4.1.3組許可權
| 組資訊 組1 組11 組12 組… 組2 組21 組22 組…
|
所選擇組：組1 [包含使用者] [所屬角色] [組許可權] [總許可權] [儲存] [取消] |
4.1.4總許可權
| 組資訊 組1 組11 組12 組… 組2 組21 組22 組…
|
所選擇組：組1 [包含使用者] [所屬角色] [組許可權] [總許可權] [儲存] [取消] |
通過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改組的許可權資訊，點選“儲存”按鈕儲存修改資訊。
4.1.5組管理
在下圖中，選中組1的時候，右鍵點選可彈出組的操作列表，包括新增、刪除和修改按鈕，從而完成在該組下新增子組，刪除該組以及修改該組的功能。
| 組資訊 組1 組11 組12 組… 組2 組21 組22 組…
|
所選擇組：組1 [包含使用者] [所屬角色] [組許可權] [總許可權] [修改] 使用者名稱 姓名 手機號 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
4.2 角色許可權管理
4.2.1包含使用者
| 角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色…
|
所選擇角色：角色1 [包含使用者] [包含組] [角色許可權] [修改] 使用者名稱 姓名 手機號 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
當用戶選擇“修改”按鈕時，彈出使用者列表，操作人可以通過勾選或取消勾選來修改該角色所包含的使用者。
4.2.2包含組
| 角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色…
|
所選擇角色：角色1 [包含使用者] [包含組] [角色許可權] [修改] 組ID 組名稱 組描述 1 xxx1 -- 2 xxx2 -- …… |
當用戶選擇“修改”按鈕時，彈出使用者列表，操作人可以通過勾選或取消勾選來修改該角色所包含的組。
4.2.3角色許可權
| 角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色…
|
所選擇角色：角色1 [包含使用者] [包含組] [角色許可權]
[儲存] [取消] |
通過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改角色的許可權資訊，點選“儲存”按鈕儲存修改資訊。
4.2.4管理角色
在下圖中，選中組1的時候，右鍵點選可彈出組的操作列表，包括新增、刪除和修改按鈕，從而完成在該組下新增子組，刪除該組以及修改該組的功能。
| 角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色…
|
所選擇角色：角色1 [包含使用者] [包含組] [角色許可權] [修改] 使用者名稱 姓名 手機號 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
4.3 使用者許可權管理
4.3.1所屬角色
| 使用者許可權資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3…
|
所選擇使用者：阿蜜果 [所屬角色] [所屬組] [使用者許可權] [總許可權] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- … |
當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以通過勾選或取消勾選來修改該使用者所屬的角色。
4.3.2所屬組
| 使用者資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3…
|
所選擇使用者：阿蜜果 [所屬角色] [所屬組] [使用者許可權] [總許可權] [修改] 組ID 組名稱 組描述 1 組1 -- 2 組2 -- … |
當用戶選擇“修改”按鈕時，彈出組的樹形結構，操作人可以通過勾選或取消勾選來修改該使用者所屬的組。
4.3.3使用者許可權
| 使用者資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3…
|
所選擇使用者：阿蜜果 [所屬角色] [所屬組] [使用者許可權] [總許可權]
[儲存] [取消] |
通過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改使用者的許可權資訊，點選“儲存”按鈕儲存修改資訊。
4.3.4總許可權
| 使用者資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3…
|
所選擇使用者：阿蜜果 [所屬角色] [所屬組] [使用者許可權] [總許可權]
[儲存] [取消] |
通過對已具有的許可權取消勾選，或為某許可權新增勾選，來修改使用者的許可權資訊，點選“儲存”按鈕儲存修改資訊。
4.3.5使用者管理
當選擇了某使用者時，點選右鍵，彈出選單列表：修改、刪除、取消，點選修改和刪除按鈕可以實現使用者的刪除和修改功能。
選擇某個組織，例如下表中的“廣州分公司”，彈出選單列表：新增子組織、刪除組織、修改組織、新增使用者、取消，點選新增使用者按鈕可以實現使用者的新增功能。
| 使用者許可權資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3…
|
所選擇使用者：阿蜜果 [所屬角色] [所屬組] [使用者許可權] [總許可權] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- … |
4.3.6組織管理
選擇某個組織，例如下表中的“廣州分公司”，彈出選單列表：新增子組織、刪除組織、修改組織、新增使用者、取消，點選新增子組織、刪除組織、修改組織按鈕可以實現組織的新增、刪除和修改功能。
| 使用者許可權資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3…
|
所選擇使用者：阿蜜果 [所屬角色] [所屬組] [使用者許可權] [總許可權] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- … |
4.4 操作日誌管理
4.4.1查詢操作日誌
| 操作名稱：|________| 操作人：|________| 操作時間從 |________| 到 |________| [查詢] [重置] [刪除] 編號 操作名稱 操作內容 操作人 操作時間 1 xx1 -- Amigo 2007-10-8 2 xx2 -- xxyy 2007-10-8 … |
輸入上圖表單中的查詢資訊後，點選“查詢”按鈕，可查詢出符合條件的資訊。
4.4.2刪除操作日誌
| 操作名稱：|________| 操作人：|________| 操作時間從 |________| 到 |________| [查詢] [重置] [刪除] 編號 操作名稱 操作內容 操作人 操作時間 1 xx1 -- Amigo 2007-10-8 2 xx2 -- xxyy 2007-10-8 … |
輸入上圖表單中的查詢資訊後，點選“查詢”按鈕，可查詢出符合條件的資訊。而後點選“刪除”按鈕，可刪除符合查詢條件的操作日誌。
5. 資料結構設計
資料庫設計的模型請參見《通用許可權管理系統_資料庫模型.pdm》。表的說明請參見《通用許可權管理系統資料庫設計說明書》。
5.1 設計原則
5.1.1命名的規範
資料庫中表、主鍵、外來鍵、索引的命名都以統一的規則，採用大小寫敏感的形式，各種物件命名長度不要超過30個字元，這樣便於應用系統適應不同的資料庫平臺。
5.1.2資料的一致性和完整性
為了保證資料庫的一致性和完整性，往往通過表間關聯的方式來儘可能的降低資料的冗餘。表間關聯是一種強制性措施，建立後，對父表（Parent Table）和子表(Child Table)的插入、更新、刪除操作均要佔用系統的開銷。如果資料冗餘低，資料的完整性容易得到保證，但增加了表間連線查詢的操作，為了提高系統的響應時間，合理的資料冗餘也是必要的。使用規則（Rule）和約束（Check）來防止系統操作人員誤輸入造成資料的錯誤是設計人員的另一種常用手段，但是，不必要的規則和約束也會佔用系統的不必要開銷，需要注意的是，約束對資料的有效性驗證要比規則快。所有這些，需要在設計階段應根據系統操作的型別、頻度加以均衡考慮。
5.2 資料庫環境說明
資料庫：MySql5.0
設計庫建模工具：PowerDesigner12.0
5.3 資料庫命名規則
表名以T開頭，外來鍵以FK開頭，索引以INDEX開頭。
5.4 邏輯結構
pdm檔案的名稱為：《通用許可權管理系統_資料庫模型》。
5.5 物理儲存
通過資料庫建模工具PowerDesigner12可以將pdm匯出為文字檔案，將資料庫指令碼放入文字檔案中儲存。
5.6 資料備份和恢復
資料庫需定期備份（每天備份一次），備份檔案格式為backup_yyyyMMdd，資料庫被破壞時，利用最新的備份檔案進行恢復。
6. 系統出錯處理設計
6.1 出錯資訊
| 錯誤分類 |
子項及其編碼 |
錯誤名稱 |
錯誤程式碼 |
備註 |
| 資料庫錯誤 |
連線 |
連線超時 |
100001001 |
|
| 連線斷開 |
100001002 |
|||
| 資料庫本身錯誤程式碼 |
資料庫本身錯誤程式碼 |
100002+資料庫錯誤程式碼 |
||
| TCP連線錯誤 |
連線 |
連線超時 |
101001001 |
|
| 連線斷開 |
101001002 |
|||
| 其它TCP連線錯誤(socket自身錯誤程式碼) |
101002+ socket錯誤程式碼 |
|||
| 配置資訊錯誤 |
未配置輸入引數 |
102001 |
||
| 未配置輸出引數 |
102002 |
|||
| 組管理部分自定義錯誤 |
103001——103999 |
|||
| 角色管理部分自定義錯誤 |
104001——104999 |
|||
| 使用者管理部分自定義錯誤 |
105001——105999 |
|||
| 操作日誌管理 |
106001——106999 |
6.2 補救措施
為了當某些故障發生時，對系統進行及時的補救，提供如下補救措施：
a．後備技術 定期對資料庫資訊進行備份（每天一次），當資料庫因某種原因被破壞時，以最新的資料庫指令碼進行恢復；。
7. 系統安全設計
7.1 資料傳輸安全性設計
SSH可以通過將聯機的封包加密的技術進行資料的傳遞; 使用SSH可以把傳輸的所有資料進行加密，即使有人截獲到資料也無法得到有用的資訊。同時資料經過壓縮，大大地加快了傳輸的速度。通過SSH的使用，可以確保資料傳輸比較安全並且傳輸效率較高。
7.2 應用系統安全性設計
操作人的操作資訊需要提供操作記錄。對系統的異常資訊需進行記錄，已備以後檢視。只有授權使用者才能登入系統，對於某個操作，需要具有相應許可權才能進行操作。
7.3 資料儲存安全性設計
對於使用者的密碼等敏感資訊採用MD5進行加密。