介绍自定义安全管理框架的 数据结构
目的：1. 对安全管理提供更强大的扩展性和伸缩性。2.提高权限验证算法效率。
以下对传统的安全管理数据结构和安全管理框架的数据结构进行大致比较
传统的数据结构中，
1. 左数第一列为各样安全管理主体， 分别是USER, USERGROUP, ROLE, FUNCTIONGROUP
这些安全管理主体类型的数量以及定义 因不同项目定义各异， 有可能衍生其它主体或只需要其中某些而已，存在伸缩性。
2. 左数第二列为第一列安全管理主体之间的关系类型。 例如 用户组中组合用户（UserGroup_User）, 因为第一列存在的不确定性， 引致此列上的类型数量以及定义也存在不确定性。
3. 左数第三列为任务， 和第二列一样，因为安全管理主体的不确定性，也是有可能改变的数据类型。
4. 只有第四列task的定义相对稳定。
（图一）
以下是自定义安全管理数据结构对以上1，2，3项的不确定性做出的重新设计
数据结构：
1. 把图一第一列的各样安全管理主体类型（USER, USERGROUP, ROLE, FUNCTIONGROUP）抽象为主体类Party, 他们之间的区别用Party中的PartyTypeId 表示， PartyTypeId 外关联到 PartyType 表中的PartyTypeId， 这样，无论主体数量如何更改和定义，也无需变动数据结构。User 表关联到Party, 是因为User是一个特别的主体(Party), 有必要存储其更多的属性。
2. 对图一第二列提出的不确定性用PartyToParty数据结构解决，各种安全管理主体之间的组合关系抽象为PartyToParty, 同样也适应了主体类型的变化引起的组合关系变化。
3．对图一第三列提出的不确定性用PartyTask数据结构解决，各种安全管理主体和任务之间的组合关系抽象为PartyTask, 同样也适应了安全管理主体类型的变化引起的主体和任务之间的变化。
4．最后是PartyTypeConstraint，它的意义在与约束属于某类型（PartyType）的主体（Party）组合其他类型主体，例如 PartyType（类型）为用户组的主体只能组合PartyType（类型）为户的主体。
实现形式
1. 在菜单上选择新建安全类型：
2. 填写相关数据，指定该类型能包含（聚合）的其他类型，例如用户组包含用户，选择用户类型
|
|
|
3. 保存后， 菜单上自动增加了一个允许新增用户组的菜单项
4. 进入新建用户组后，看到左图的下拉框能看到第2步选择的包含类型及其实例。选择用户组的用户（这里选择的是Matt）作为此用户组的成员，并授权此用户组能实现的功能(这里选择的是UpdateItem)。最后进行保存。
|
|
|
5. 以下是按照1-4步骤再建立的功能组
6. 菜单中新增了“新建功能组“
7. “所有安全类型主体”中能选择用户及用户组的成员
|
|
|
