【自然架構】之通用權限（四）：角色表組(轉)

 繼續，這是第四章了。這裡涉及到了資源方面的，不過有點繞，是以這裡先介紹一下表結構，在後面的章節裡面，再舉例子詳細介紹。

通用權限想要寫的文章目錄：（這是第四章）

1、 ​​簡介、資料庫的總體結構​​

2、 ​​介紹人員表組​​

3、 ​​介紹組織結構表組​​

4、 ​​介紹角色表組​​

5、 ​​介紹“項目自我描述表組”​​

6、 權限到節點

7、 權限到按鈕

8、 權限到清單（表單、查詢）

9、 權限的驗證

10、 資源方面的權限

11、 角色管理的程式（給客戶用的）

12、 權限下放

13、 個性化設定

角色表組

      目前有七個表：（有四個是這兩天才加上的）

      一、Role_Roles ，記錄角色資訊，比如角色名稱、角色描述、角色擁有的節點等。這個表我也打算可以做成n級分類的形式，因為如果角色多了（比如幾百個），不分類的話，看起來就比較亂，但是如何來分類我又沒有想好。當然對于一些簡單的情況，也是可以不分類的。

      這個角色表Role_Roles記錄的是操作方面的，并不包含資源方面。這個角色分為兩種：正向角色、拒絕角色。

      1、正向角色：

      記錄可以做的權限，就是記錄下來可以做哪些操作，正向角色不能繼承，不能關聯，但是可以組合。如果一個人擁有多個正向角色，那麼隻要有一個角色裡面允許，那麼他就可以做這個操作。

      2、拒絕角色：

      和正向角色相反，他記錄的是不可以做的操作。拒絕角色必須“繼承”（或者叫做關聯）一個或多個正向角色。拒絕角色不能繼承拒絕角色。如果一個人擁有了一個拒絕角色，那麼拒絕角色裡面不允許做的操作就絕對不可以做，不管他擁有的其他的正向角色是如何規定的。

      至于給人員配置設定角色的時候如何來具體的區分，還沒有太完善。

      3、“FunctionIDs”：角色擁有的節點的字段。這個字段的内容是“1,2,3,4”的形式。對于正向角色來說這裡記錄的就是可以操作的節點，而對于拒絕角色來說，這裡記錄的就是不可以操作的節點。

這個也是“權限到節點”的關鍵字段。

字段名	中文名	字段類型	大小	預設值	是否空	說明
RoleID	角色	int	4	1	主鍵
RoleName	角色名稱	nvarchar	50	_
RoleDescribe	角色描述
RoleKind	角色類型				1：正向角色；2：拒絕角色
LinkRoleIDs	關聯角色				拒絕角色有效。 拒絕角色可以關聯多個正向角色，但是不能關聯拒絕角色。 正向角色不能關聯。
ParentID	父節點ID				父節點ID。為n級分類做預留
ParentIDPath	父節點ID的路徑		30		父節點ID的路徑。為n級分類做預留
RoleLevel	角色層數				第幾級的角色
Sort	排序				序号
FunctionIDs	節點		500		角色擁有的功能節點。1,2,3的形式
AddedDate	添加日期	smalldatetime		GetDate()	記錄添加日期
AddedUserID	添加人				記錄哪個使用者添加的
UpdatedDate	最後修改日期				記錄最後修改日期
UpdatedUserID	最後修改人				記錄哪個使用者最後修改的

      二、Role_RoleButton ，這個表要記錄一個節點裡的按鈕的權限，就是說一個角色擁有的節點裡的按鈕的權限。如果他和正向角色關聯，則說明可以使用這個按鈕，如果和拒絕角色關聯則說明不能使用這個節點。

FunctionID					外鍵
ButtonIDs	人員ID		200

      三、Role_RoleColumn，同上，這個表要記錄一個角色擁有的節點裡的清單、表單或者查詢的字段的權限。如果粒度不需要做得這麼細的話，那麼這個表就可以省略了。

同樣如果他和正向角色關聯，則說明可以使用這些字段，如果和拒絕角色關聯則說明不能使用這寫字段。

					聯合主鍵
					聯合主鍵。外鍵
Kind	類型				1：清單；2：表單；3：查詢
ColumnIDs	字段ID

      四、Role_RoleUser，角色裡的使用者，角色和使用者是多對多的關系，即一個人可以有多個角色，一個角色可以有多個使用者，角色和UserID關聯，但是也要加上PersonID的資訊。

一個人可以擁有多個正向角色，也可以擁有多個拒絕角色。拒絕角色優先，隻要拒絕了那麼就不可以使用。

RoleUserID	編号
UserID	使用者				外鍵。角色裡面擁有的賬号ID
PersonID	人員				外鍵。角色裡面擁有的使用者ID

      五、Role_ResourceListCase，“記錄清單”的資源過濾方案，就是記錄過濾條件，即SQL語句裡面的Where後面的查詢條件。這個是給GridView級别的控件準備的，在自然架構裡面可以給QuickPager的查詢條件的屬性指派。這樣就可以實作過濾的效果。這個隻有“正向”沒有“拒絕”。角色和功能節點起到“聯合主鍵”的功能，一個節點可以有多個方案以供選擇。但是一個角色和節點的組合隻能選擇一個方法。

ListCaseID
	關聯節點				外鍵。0：不限制節點；其他：有效的節點
ResourceName	資源角色名稱
ResourceDescribe	資源角色描述
SQL	過濾條件				SQL語句裡的where後面的查詢條件
ResourceLevel	資源角色層數

      六、Role_ResourceControlCase ，控件的資源過濾方案，就是記錄過濾條件，即SQL語句裡面的Where後面的查詢條件。這個是給下拉清單框級别的控件準備的。通過這裡的條件可以達到過濾資料的效果。同樣，這個也有“正向”沒有“拒絕”。

 1、一個控件（比如下拉清單框）可以有多個方案，也可以不使用方案，即顯示全部資料。

 2、一個資源方案隻能給一個控件使用。

 3、一個功能節點裡面有查詢和表單，而一個表單（查詢）裡面有可能有多個下拉清單框。

ControlCaseID
ColumnID	關聯控件				外鍵。關聯的控件，即字段

      七、Role_RoleResource，角色、節點、資源方案的關系。

這是一個關聯表，把角色、和資源方案關聯起來，由于一個角色裡面會有多個功能節點，一個功能節點可能有多種方案（但是隻能選一個），有一個表單、有一個查詢，而表單和查詢裡面會有多個下拉清單框這一類的控件， 是以在關聯的時候是角色和功能節點做聯合主鍵的作用。好像沒說明白，暫時先這樣吧，以後我舉幾個例子就好辦了。

RoleResourceID
	清單過濾方案				外鍵，給分頁控件的查詢條件用
	控件過濾方案				1,2,3的形式，下拉清單框級别的控件用