通用數據權限管理系統設計

通用數據權限管理系統設計(一)
 

 
前言:
 本文提供一種集成功能權限和數據權限的解決方法,以滿足多層次組織中權限管理方面的集中控制。本方法是RBAC(基於角色的訪問控制方法)的進一步擴展和延伸,即在功能權限的基礎上增加數據權限的管理,實現數據權限和功能權限的集中處理。
 
解釋:
 功能權限:能做什麼的問題,如增加銷售訂單;
 數據權限:能在哪裏幹什麼的問題,如察看北京分公司海淀銷售部張三的銷售訂單;
 
術語:
 資源:系統中的資源,主要是各種業務對象,如銷售單、付款單等;
 操作類型:對資源可能的訪問方法,如增加、刪除、修改等;
 功能:對資源的操作,是資源與操作類型的二元組,如增加銷售單、修改銷售單等;
 數據類型:業務系統中常用的數據權限類型,如公司、部門、項目、個人等;
 數據對象:具體的業務對象,如甲公司、乙部門等等,包括所有涉及到數據權限的對象值;
 權限:角色可使用的功能,分角色的功能權限和角色的數據權限;
 角色:特定權限的集合;
 用戶:參與系統活動的主體,如人,系統等。
 
 
通用數據權限管理系統設計(二)
 
方法說明:
 在實際應用中,數據權限的控制點一般相對固定,如針對公司、部門、個人、客戶、供應商等,也就是說數據權限一般針對指定數據類型下的一些數據對象。
 
 本方法中,數據權限的依賴於功能權限,是對功能權限的進一步描述,說明角色在指定的功能點上的數據控制權限。
本方法中採用“沒有明確規定即視爲有效”的原則,如果沒有定義功能的數據權限,則說明該角色具有該功能的全部的權限。如果定義了功能的某種類型的數據權限,則該用戶只具有該類型下指定數據的數據權限。
 
 這段話比較繞口,下面舉個例子實際例子。
 
 某公司有北京銷售部、上海銷售部和廣州銷售部三個銷售部,現在需要定義幾種角色:
    銷售總監      -- 能察看所有銷售部的銷售訂單;
    北京銷售經理 -- 只能察看北京銷售部的所有銷售訂單;
    上海銷售經理 -- 只能察看上海銷售部的所有銷售訂單;  
    廣州銷售經理 -- 只能察看廣州銷售部的所有銷售訂單;  
 
 上述角色的定義如下:
 
     -------------------------------------------------------------------
     角色名稱             功能             數據類型     數據對象  
     -------------------------------------------------------------------
     銷售總監           察看銷售訂單                                 
     北京銷售經理       察看銷售訂單         部門         北京  
     上海銷售經理       察看銷售訂單         部門         上海     
     廣州銷售經理       察看銷售訂單         部門         廣州     
     -------------------------------------------------------------------
 
    上述定義中,銷售總監只定義了功能權限,而沒有定義數據權限,所以銷售總監能夠察看所有的銷售訂單;而其他幾位銷售經理分別定義了這一功能的數據權限,所以只能察看指定部門的銷售訂單。
 
     在實際應用中,往往會出現部門分組,組長能夠察看本組所有人員處理的銷售訂單的情況,以及某些情況下,某些人只能察看本人的銷售訂單的情況,這些特殊情況在上述的說明中無法解決,需要在設計和實現中進行處理。
 
 
    北京銷售代表 -- 只能察看北京銷售部的本人的所有銷售訂單;  
     北京銷售代表         察看銷售訂單           部門            北京     
                                                 個人                  
 
 
通用數據權限管理系統設計(三)--數據庫設計
 
我們先來看看傳統的基於角色的權限管理系統,如下圖所示,最簡單的基於角色的權限管理由系統功能、系統角色、系統用戶、角色功能和用戶角色五部分組成。
    圖一:基於角色的數據庫結構
爲實現數據權限控制,在設計上對基於角色的權限管理進行擴充,如下圖所示:
 
圖二:通用數據權限管理系統數據庫設計
對比兩張圖,我們可以看到,他們之間的主要變化爲:
1、 增加系統資源信息和操作類型信息,系統資源爲樹形結構、如銷售模塊、銷售訂單等;操作類型記錄可能的操作,如增加、刪除、修改、查看、查詢等,系統功能是資源與操作類型的組合,對資源的操作就是系統功能。
2、 增加數據對象類型和數據對象兩張表,數據對象類型記錄系統中需要控制的對象類型,如部門、庫房、員工、客戶、供應商等;數據對象記錄各對象類型的對象實例,如北京銷售部、上海銷售部、張三、李四等等。(獨立保存的好處後面會說到)
3、 增加系統資源與數據對象類型的關聯表(多對多),本表爲配置表,說明某種資源可能需要的控制點,如銷售訂單與部門類型的關聯可能涉及到分部門分配權限;銷售訂單與客戶的關聯可能涉及到按客戶分配權限等等。
4、 增加數據對象與角色權限的關聯,這張表是真正最終實現數據權限管理的所在地。
 
通過這種設計,能夠最小化地減少對原有權限系統的更改,並且可以很靈活地增加數據的控制點。在產品化軟件的設計中使用,能夠靈活滿足客戶的需要。
 
下一篇文章將討論這種結構如何滿足第二部分功能需求的問題,如果時間允許,將對程序的設計做進一步闡述。
 
本設計方法已應用於自行開發的通用供應鏈管理系統中,歡迎指正。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章