|
設計一個靈活、通用、方便的權限管理系統。
在這個系統中，我們需要對系統的所有資源進行權限控制，那么系統中的資源包括哪些呢？我們可以把這些資源簡單概括為靜態資源（功能操作、數據列）和動態資源（數據），也分別稱為對象資源和數據資源，后者是我們在系統設計與實現中的叫法。 系統的目標就是對應用系統的所有對象資源和數據資源進行權限控制，比如應用系統的功能菜單、各個界面的按鈕、數據顯示的列以及各種行級數據進行權限的操控。 三．相關對象及其關系 大概理清了一下權限系統的相關概念，如下所示： 1. 權限 系統的所有權限信息。權限具有上下級關系，是一個樹狀的結構。下面來看一個例子 系統管理 用戶管理 查看用戶 新增用戶 修改用戶 刪除用戶 對于上面的每個權限，又存在兩種情況，一個是只是可訪問，另一種是可授權，例如對于“查看用戶”這個權限，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個權限分配給其他人。 2. 用戶 應用系統的具體操作者，用戶可以自己擁有權限信息，可以歸屬于0～n個角色，可屬于0～n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關系都是n對n的關系。 3. 角色 為了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念，例如系統管理員、管理員、用戶、訪客等角色。角色具有上下級關系，可以形成樹狀視圖，父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的用戶、父級角色的組同理可推。 4. 組 為了更好地管理用戶，對用戶進行分組歸類，簡稱為用戶分組。組也具有上下級關系，可以形成樹狀視圖。在實際情況中，我們知道，組也可以具有自己的角色信息、權限信息。這讓我想到我們的QQ用戶群，一個群可以有多個用戶，一個用戶也可以加入多個群。每個群具有自己的權限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高級群等。 針對上面提出的四種類型的對象，讓我們通過圖來看看他們之間的關系。
有上圖中可以看出，這四者的關系很復雜，而實際的情況比這個圖還要復雜，權限、角色、組都具有上下級關系，權限管理是應用系統中比較棘手的問題，要設計一個通用的權限管理系統，工作量也著實不小。 當然對于有些項目，權限問題并不是那么復雜。有的只需要牽涉到權限和用戶兩種類型的對象，只需要給用戶分配權限即可。 在另一些情況中，引入了角色對象，例如基于角色的權限系統，只需要給角色分配權限，用戶都隸屬于角色，不需要單獨為用戶分配角色信息。 通用權限管理設計篇（二）——數據庫設計 國慶前整的通用權限設計的數據庫初步設計部分，現在貼上來。 理清了對象關系之后，讓我們接著來進行數據庫的設計。在數據庫建模時，對于N對N的 關系，一般需要加入一個關聯表來表示關聯的兩者的關系。初步估計一下，本系統至少需要十張表，分別為：權限表、用戶表、角色表、組表、用戶權限關聯表、用 戶角色關聯表、角色權限關聯表、組權限關聯表、組角色關聯表、用戶屬組關聯表。當然還可能引出一些相關的表。下面讓我們在PowerDesigner中畫出各表吧。 各表及其關系如下：
1. 用戶表
2. 角色表
3. 權限表
4. 組表
5. 角色權限表
6. 組權限表
7. 組角色表
8. 用戶權限表
9. 用戶角色表
10. 用戶組表
11. 組織表
12. 操作日志表
1. 權限資源 系統的所有權限信息。權限具有上下級關系，是一個樹狀的結構。下面來看一個例子 系統管理 用戶管理 查看用戶 新增用戶 修改用戶 刪除用戶 對于上面的每個權限，又存在兩種情況，一個是只是可訪問，另一種是可授權，例如對于“查看用戶”這個權限，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個權限分配給其他人。 2. 用戶 應用系統的具體操作者，用戶可以自己擁有權限信息，可以歸屬于0～n個角色，可屬于0～n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關系都是n對n的關系。 3. 角色 為了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念，例如系統管理員、管理員、用戶、訪客等角色。角色具有上下級關系，可以形成樹狀視圖，父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的用戶、父級角色的組同理可推。 4. 組 為 了更好地管理用戶，對用戶進行分組歸類，簡稱為用戶分組。組也具有上下級關系，可以形成樹狀視圖。在實際情況中，我們知道，組也可以具有自己的角色信息、 權限信息。這讓我想到我們的QQ用戶群，一個群可以有多個用戶，一個用戶也可以加入多個群。每個群具有自己的權限信息。例如查看群共享。QQ群也可以具有 自己的角色信息，例如普通群、高級群等。 針對如上提出的四種對象，我們可以整理得出它們之間的關系圖，如下所示： 總體設計思路是將系統分為組權限管理、角色權限管理、用戶權限管理、組織管理和操作日志管理五部分。 其中組權限管理包括包含用戶、所屬角色、組權限資源和組總權限資源四部分，某個組的權限信息可用公式表示：組權限 = 所屬角色的權限合集 + 組自身的權限。 角色權限管理包括包含用戶、包含組和角色權限三部分，某個角色的權限的計算公式為：角色權限 = 角色自身權限。 用戶權限管理包括所屬角色、所屬組、用戶權限、用戶總權限資源和組織管理五部分。某個用戶總的權限信息存在如下計算公式：用戶權限 = 所屬角色權限合集 + 所屬組權限合集 + 用戶自身權限。 組織管理即對用戶所屬的組織進行管理，組織以樹形結構展示，組織管理具有組織的增、刪、改、查功能。 操作日志管理用于管理本系統的操作日志。 注意：因為組和角色都具有上下級關系，所以下級的組或角色的權限只能在自己的直屬上級的權限中選擇，下級的組或者角色的總的權限都不能大于直屬上級的總權限。 2.5 模塊結構設計 本系統的具有的功能模塊結構如下圖所示： 2.6 尚未解決的問題 無。 3. 接口設計（暫略） 3.1 用戶接口（暫略） 3.2 外部接口（暫略） 3.3 內部接口（暫略） 4. 界面總體設計 本節將闡述用戶界面的實現，在此之前對頁面元素做如下約定：
4.1 組權限管理 4.1.1包含用戶
當用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該組所包含的用戶。 4.1.2所屬角色
當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以通過勾選或取消勾選來修改該組所屬的角色。 4.1.3組權限
4.1.4總權限
通過對已具有的權限取消勾選，或為某權限添加勾選，來修改組的權限信息，點擊“保存”按鈕保存修改信息。 4.1.5組管理 在下圖中，選中組1的時候，右鍵點擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。
4.2 角色權限管理 4.2.1包含用戶
當用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的用戶。 4.2.2包含組
當用戶選擇“修改”按鈕時，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的組。 4.2.3角色權限
通過對已具有的權限取消勾選，或為某權限添加勾選，來修改角色的權限信息，點擊“保存”按鈕保存修改信息。 4.2.4管理角色 在下圖中，選中組1的時候，右鍵點擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。
4.3 用戶權限管理 4.3.1所屬角色
當用戶選擇“修改”按鈕時，彈出角色樹形結構，操作人可以通過勾選或取消勾選來修改該用戶所屬的角色。 4.3.2所屬組
當用戶選擇“修改”按鈕時，彈出組的樹形結構，操作人可以通過勾選或取消勾選來修改該用戶所屬的組。 4.3.3用戶權限
通過對已具有的權限取消勾選，或為某權限添加勾選，來修改用戶的權限信息，點擊“保存”按鈕保存修改信息。 4.3.4總權限
通過對已具有的權限取消勾選，或為某權限添加勾選，來修改用戶的權限信息，點擊“保存”按鈕保存修改信息。 4.3.5用戶管理 當選擇了某用戶時，點擊右鍵，彈出菜單列表：修改、刪除、取消，點擊修改和刪除按鈕可以實現用戶的刪除和修改功能。 選擇某個組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點擊添加用戶按鈕可以實現用戶的添加功能。
4.3.6組織管理 選擇某個組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點擊添加子組織、刪除組織、修改組織按鈕可以實現組織的添加、刪除和修改功能。
4.4 操作日志管理 4.4.1查詢操作日志
輸入上圖表單中的查詢信息后，點擊“查詢”按鈕，可查詢出符合條件的信息。 4.4.2刪除操作日志
輸入上圖表單中的查詢信息后，點擊“查詢”按鈕，可查詢出符合條件的信息。而后點擊“刪除”按鈕，可刪除符合查詢條件的操作日志。 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 出錯信息
6.2 補救措施 為了當某些故障發生時，對系統進行及時的補救，提供如下補救措施： a．后備技術 定期對數據庫信息進行備份（每天一次），當數據庫因某種原因被破壞時，以最新的數據庫腳本進行恢復；。 7. 系統安全設計 7.1 數據傳輸安全性設計 SSH可以通過將聯機的封包加密的技術進行資料的傳遞; 使用SSH可以把傳輸的所有數據進行加密，即使有人截獲到數據也無法得到有用的信息。同時數據經過壓縮，大大地加快了傳輸的速度。通過SSH的使用，可以確保資料傳輸比較安全并且傳輸效率較高。 7.2 應用系統安全性設計 操作人的操作信息需要提供操作記錄。對系統的異常信息需進行記錄，已備以后查看。只有授權用戶才能登錄系統，對于某個操作，需要具有相應權限才能進行操作。 7.3 數據存儲安全性設計 對于用戶的密碼等敏感信息采用MD5進行加密。
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
