資料庫篇（資料庫設計） ---許可權系統設計
目錄
概述
許可權管理，一般指根據系統設定的安全規則或者安全策略，使用者可以訪問而且只能訪問自己被授權的資源，不多不少。
許可權管理幾乎出現在任何系統裡面，只要有使用者和密碼的系統。 很多人常將“使用者身份認證”、“密碼加密”、“系統管理”等
概念與許可權管理概念混淆。一個（ERP）系統中沒有許可權進行管理，就像軀體沒有了靈魂，沒有任何控制，行屍走肉一
般，無論功能設計的多麼完美，白搭。
依據我現有的淺薄認知，我認為許可權從控制作用上來劃分成兩類：
- 選單功能許可權控制
- 資料許可權控制
選單功能許可權控制
宣告一下：選單功能許可權控制不單單是對選單的展示和控制，還包括選單頁面上的功能控制，細分到每一個按鈕連結操作，
有些人只有檢視許可權，有些人可以修改，具體不同的人員可以檢視到不同的資料，就交由資料許可權控制。
說起選單許可權，RBAC是目前最-最-最為廣泛接受的許可權模型。我們從簡單的開始說起。
使用者-許可權
每個使用者和每個許可權進行多對多的關聯
資料庫：人員表-人員許可權關聯表-許可權表 這種設計比較簡單，一般不用。
使用者-角色-許可權
當我們需要管理很多許可權的時候，有些許可權可以分成組以功能模組進行賦許可權。這個時候角色就是一些許可權的集合。
比如機構管理的增刪改可以放到一個角色中，只需要將改角色和某個人關聯就能把增刪改都賦予這個人。
在這個模型中，我們把許可權賦予角色，再把角色賦予使用者。使用者和角色，角色和許可權都是多對多的關係。
使用者擁有的許可權等於他所有的角色持有許可權之和。
資料庫表設計：
使用者-使用者組-角色-許可權
當用戶的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，
每個使用者組內有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有許可權，就是使用者
個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。（下圖為使用者組、使用者與角色三者的關聯關係）
資料庫設計：
這個時候發現，我使用者沒有和許可權進行關聯，為什麼不關聯呢？不是不可以，是根據業務場景來，基本上一個
使用者所擁有的許可權來源於他的職責範圍，而職責範圍是一個許可權的集合，而且，業務系統中這種場景不多，並且
可以通過再次新建一個角色進行關聯單獨解決。如果有業務需要，增加一個使用者-許可權表就可以了。
資料許可權控制
當我們查詢敏感資料時候，每個人對某個表都有查詢許可權，但是部門人員只能查詢本部門的資料，但是總部可以
查詢所有的，這個時候就要涉及到資料許可權隔離。
首先，人員或者組我們可以使用以上功能許可權的表格資料，對不同的功能資料型別進行不同的控制，這個時候需要
一張功能表，一張組/使用者-資料表（通過標識區分使用者或者租），用來記錄資料許可權。
其中資料型別可以存放到字典中，主要是功能的一個唯一標識。大體上我們可以分為4個主要物件：
使用者，關聯表，系統資料，功能。
資料來源是系統中各個表格的待查詢型別資料。例如我們查詢個人工資資料，每個人只能查詢自己的，這個可以
做名稱條件限制，但是各個部門人力資源需要知道部門內人員的薪資資料，總公司可以查詢到全部的資料。我們
可以將薪資資料查詢作為一個功能型別-01（薪資查詢）存放到字典中，然後將部門作為另一個型別從系統中部門
表讀取，並根據不同的部門分配不同的部門資料（如果還需要根據其他其他型別做區分，只需要增加組/使用者-資料
表字段就可以了,例如只能看到某一職級人員，不能看到老總那個職級的資料，就可以把職級也新增成一個條件）。
建議組/使用者-資料表的設計.(id,使用者或者組id,使用者或者組標識,資料型別（例如:部門）,功能型別(01-薪資查詢),擴充套件1(職級資料)，….)