我們比較常見的就是基於角色的訪問控制，用戶通過角色與權限進行關聯。簡單地說，一個用戶擁有多個角色，一個角色擁有多個權限。這樣，就構造成“用戶-角色-權限”的授權模型。在這種模型中，用戶與角色之間、角色與權限之間，通常都是多對多的關係。如下圖：
基於這個，得先了解角色到底是什麼？我們可以理解它為一定數量的權限的集合，是一個權限的載體。例如：一個論壇的“管理員”、“版主”，它們都是角色。但是所能做的事情是不完全一樣的，版主只能管理版內的貼子，用戶等，而這些都是屬於權限，如果想要給某個用戶授予這些權限，不用直接將權限授予用戶，只需將“版主”這個角色賦予該用戶即可。
但是通過上面我們也發現問題了，如果用戶的數量非常大的時候，就需要給系統的每一個用戶逐一授權(分配角色)，這是件非常繁瑣的事情，這時就可以增加一個用戶組，每個用戶組內有多個用戶，除了給單個用戶授權外，還可以給用戶組授權，這樣一來，通過一次授權，就可以同時給多個用戶授予相同的權限，而這時用戶的所有權限就是用戶個人擁有的權限與該用戶所在組所擁有的權限之和。用戶組、用戶與角色三者的關聯關係如下圖：
通常在應用系統裡面的權限我們把它表現為菜單的訪問(頁面級)、功能模塊的操作(功能級)、文件上傳的刪改，甚至頁面上某個按鈕、圖片是否可見等等都屬於權限的範疇。有些權限設計，會把功能操作作為一類，而把文件、菜單、頁面元素等作為另一類，這樣構成“用戶-角色-權限-資源”的授權模型。而在做數據表建模時，可把功能操作和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。如下圖：
這裡特別需要注意以下權限表中有一列“PowerType(權限類型)”，我們根據它的取值來區分是哪一類權限，可以把它理解為一個枚舉，如“MENU”表示菜單的訪問權限、“OPERATION”表示功能模塊的操作權限、“FILE”表示文件的修改權限、“ELEMENT”表示頁面元素的可見性控制等。
這樣設計的好處有兩個。一、不需要區分哪些是權限操作，哪些是資源，（實際上，有時候也不好區分，如菜單，把它理解為資源呢還是功能模塊權限呢？）；二、方便擴展，當系統要對新的東西進行權限控制時，我只需要建立一個新的關聯表“權限XX關聯表”，並確定這類權限的權限類型字符串即可。
需要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關係。（文件、頁面權限點、功能操作等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表通過“權限類型”和這個ID來區分是種類型下的哪條記錄。最後擴展出來的模型完整設計如下圖：
注意上面我額外增加了一個操作日誌表；
隨著系統的日益龐大，為了方便管理，如果有需要可引入角色組對角色進行分類管理，跟用戶組不同，角色組不參與授權。例如：當遇到有多個子公司，每個子公司下有多個部門，這是我們就可以把部門理解為角色，子公司理解為角色組，角色組不參於權限分配。另外，為方便上面各主表自身的管理與查找，可採用樹型結構，如菜單樹、功能樹等，當然這些可不需要參於權限分配。
數據字典
1. 用戶表：
2. 角色表：
3. 用戶與角色關聯表
4. 用戶組表
5. 用戶組與用戶信息關聯表
6. 用戶組與角色關聯表
7．菜單表
8. 頁面元素表
9. 文件表
10. 權限表
11. 權限與菜單關聯表
12. 權限與頁面元素關聯表
13. 權限與文件關聯表
14. 功能操作表
15. 權限與功能操作關聯表
16. 角色與權限關聯表
17. 操作日誌表
閱讀更多 Java雙料架構師 的文章
