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