我如何建模(GitHub)相关的权限？

Question

tl; dr:我如何实现像(例如)github的权限模型

更新以尝试解决@ philipxy的一些评论:

我打算实现一个类似于github的权限模型:

1. 用户
2. 用户可以成组
3. 用户可以在组织中
4. 团体可以在组织中
5. 用户将被允许在资产,组或组织中执行任何C,R,U和D操作,如下所示:
   1. 允许那些(C,R,U,D)操作的个人用户
   2. 已被授予这些权限的组的成员
   3. 已被授予这些权限的组织的成员
      1. 或者作为该组属于具有权限的组织的组的成员
6. 用户被授予读取权,因为资产/组/组织对匿名用户("公共")是可见的(可读)
7. 用户还应具有一组权限,以表明他们是否可以对权限执行任何C,R,U或D(用户可以为其他用户,组创建权限[C,R,U,D]或组织)
   1. 用户可以为他们创建的任何资产,组或组织设置权限,或者为其授予权限的任何资产,组或组织设置权限.

这些权限将控制谁可以对站点中的资产,组和组织执行创建,读取,更新和删除(CRUD)操作.

大致如何对此进行建模？

显然我有这些模型:

1. 财富
2. 用户
3. 组
4. 组织

接下来是什么？

1. 允许？
2. PermissionType(捕获C/R/U/D)？

我正在使用节点中的mysql(通过sequelize),但我可以自己弄清楚具体的语法,我还没有想出如何在概念上做到这一点.

更多@ philipxy的观点:

你提议我做的更多的事情确实是我认为我正在寻求帮助的事情.也就是说,那些信息设计方法(NIAM,FCO-IM,ORM2,IDEF1X)正是我正在寻找的.我知道有关关系数据库实现(学习规范化和正常形式以及诸如此类的日子)的相当数量,但实际上指定业务需求并将其转换为可操作规范的过程是一项挑战.

• ORM2 很难找到,因为名称冲突与模块的NodeJS的.:我已经下载了从NIAM维基百科页面链接的书籍
• 现在使用NIAM似乎不太常见？
• FCO-IM:我从他们的网站上下载了这本书
• IDEF1X:看起来也很有趣

我想我要去拿一本数据库教科书.

更多关于谓词的工作:

1. U 识别出一个 User
2. A 识别出一个 Asset
3. G 识别出一个 Group
4. a User U可以是0或更多Groups G
5. O 识别出一个 Organization
6. a User U可以是0或更多Organizations O
7. a Group G可以是0或更多Organizations O
8. 资产A可以由a创建User U
9. CRUD Assets:
   1. 一个Entity E可以被允许(通过Permission P？)来执行动作Ac上Assets
   2. 那些Actions是:
      1. Create
      2. Read
      3. Update
      4. Delete
   3. 的Entity可以是类型:
      1. User
      2. Group
      3. Organization
      4. Anonymous User/"公众"
   4. 详细信息(仅适用于显示Read,而且相关的Create,Update和Delete):
      1. 一个User U0可以允许另一User U1对Read的Asset A
      2. 一个User U0可以允许Users U谁是成员Group G到Read一个Asset A
      3. 一个User U0可以允许Users U谁是成员Organization O到Read一个Asset A
      4. Users U在Group G1其中G1是一个Group是在Organization O已被允许Read Asset A,因此被允许Read Asset A
10. Permission P引用a的a Asset A只能由某些用户创建:
    1. 默认情况下,User U是谁的创建者Entity可以创建Permissions为Entity,
    2. 但他们可能只参考Assets他们所拥有的Permission(在基本情况下:那些Assets创造者U)
    3. 一个User被Grant(?)授予特权的人也可以参考Entity E一个Permission
    4. Gr 识别出一个 Grant
       1. a Grant赋予Entity创建,读取,更新或删除Permissions该引用的权限Entity
       2. 比如Permissions,Grants具有传递性:
          1. 如果Organization O一直Granted特权(例如)修改Permissions了Entity E,那么
          2. 不仅是Users谁是O修改Permissions引用的成员E,
             1. 而且Users谁是任何的成员Group G,其中G在O有权限修改Permissions引用E

Answer 1

谓词和表格

一个命题是真或假的公司情况发了言.一个谓语是给定一个行给出一个命题一列参数化的语句.表(基础或查询结果)保存从其谓词中生成真命题的行.

user (with id) U has name N
R is a grantor (may grant permissions)

user U has permission to update asset A
grantor R gave permission to grantor E to use an operator of type 'CRUD'
grantor E is of type 'user' AND grantor E has permission to update assets

商业规则

业务规则是始终为真的语句,用于定义术语或描述策略或过程.

A user is uniquely identified by an id assigned when their cheque clears.  
A crudable is an asset, group or organization.  
A grantor is a user, group, organization.
"Grantee" refers to a grantor receiving or holding a permission.    
Users can be in organizations.  

您可以创建无参数谓词的真实语句.这些可以使用由FOR ALL&FOR SOME(THERE EXISTS)绑定的参数名称.根据这种命题谓词和/或表名称表达的业务规则是数据库约束.考虑到User(U,N)与Grantor(R)作为速记前两个谓词上面谓词表User及Grantor,下面几行都说着同样的事情:

A user is a grantor.
FOR ALL U, if U is a user then U is a grantor.

FOR ALL U, (FOR SOME N, User(U, N)) IMPLIES Grantor(U).
(SELECT U FROM User) ? (SELECT R AS U FROM Grantor).

FOR ALL U & N, User(U, N) IMPLIES Grantor(U).
FOR ALL U & N, (U, N) IN User IMPLIES (U) IN Grantor.

FOREIGN KEY User (U) REFERENCES Grantor (R); 说明上面做了什么(注意它与中间两个的相似性)加上在Grantor中R是UNIQUE NOT NULL.

不要将规则与谓词混淆.它们有不同的用途,通常有不同的形式.(无参数句子模板可以用作其中之一.)规则是一个真实的陈述; 谓词是参数化语句.看看我的答案是如何区分它们的.基表和查询结果表具有谓词.但是规则可能会建议您需要基本谓词/表来记录某些内容.当我们从规则中看到我们必须记录关于当前情况的一些陈述时,我们有基本谓词/表.请注意,一些规则不会激发基本谓词.

您可能想要统一类型和权限.

A user is a grantor of type 'user'.
Permission named 'C' is permission for a grantee to create a crudable.

Grantor E is of type 'user'.
Permission P is of type 'CRUD'.
Grantor R gave permission P of type 'CRUD' on crudable C to grantee E.

设计正在寻找必要且充分的规则和基础谓词

以下是相关谓词,用于记录您的博览会建议出现的情况.

1. 用户

U identifies a user

2. 用户可以成组

G identifies a group
user U is in group G

3. 用户可以在组织中

O identifies an organization
user U is in organization O

4. 团体可以在组织中

group G is in organization O

5. 允许用户对资产,组或组织进行CRUD操作

A identifies a crudable of type 'asset'
user U is permitted CRUD operations on crudable C

5.1作为单个用户,或作为组的成员,或作为组织的成员(或作为该组属于具有权限的组织的组的成员),

P identifies a permission
organization O is permitted CRUD operations on crudable C

或者因为资产/组/组织对匿名用户("公共")是可见的(可读的)

crudable C is public

6. 用户还应具有一组权限,以表明他们是否可以设置上述权限

grantor R has permission to set CRUD permission for users on crudable C --?  

什么是"上述权限"？也许你的意思是用户CRUD权限和组织CRUD权限？也许你的意思是有创建,阅读等操作的个人权限？你需要更清楚.

"一组权限"中的权限是什么？通过"许可",你真的意味着"对特定受助人的特殊许可"吗？你需要更清楚.

更清楚的方法是给出尽可能简单的规则和谓词,但也不要太简单,以至于他们没有提到相关的实体/值.之后您可能希望将多个规则和谓词概括为单个规则和谓词.例如,不是与用户,团体,组织和资产打交道,而是拥有授予者和crudables:Grantors may grant permissions.&grantor R gives permission P to grantee E.如果某些此类权限也与特定被授予者相关联,则可能还需要谓词grantor R gives permission P to grantee E re permission Q and grantee F.

6.1.用户可以为他们创建的任何资产,组或组织设置权限,

user U created crudable C

或者已获得设置权限的任何资产,组或组织.

user U has permission to set permission P for crudable C --?  

你会想要记录那样的事情user U has name N and ....

了解数据库设计

搜索重新数据库/ SQL子类型/继承/多态性习语.例如,用户,组织和组织是许可拥有者和持有者的类型; 我把它们作为一种类型的设保人的子类型.也许你想要某种权限目标类型,即crudable和grantor的联合.也许你想要各种类型的权限.也许某些权限权限与关联的受赠者有关.也许'C','R','U'和'D'是权限,'CRUD'是一种权限.您可能想要记录授权人给予受让人哪些权限.

稍后,如果连接在共享PK/UNIQUE上,并且两者中具有相同的值集,我们可以通过它们的连接替换表.当我们可以加入一个PK/UNIQUE&FK时,我们可以将一个表替换为一个像它们的连接一样但是FK可以为空.还有一些时候我们可以毫无问题地替换多个表.但首先确定基本谓词.

了解关系数据库设计.遵循一些信息设计方法.Best是NIAM/FCO-IM/ORM2系列的成员.窥视IDEF1X.不要依赖产品.

了解约束.它们遵循谓词和业务规则.它们是关于谓词的可能业务情况的真相.同样,它们是关于表格中可能的数据库状态的真相.还要了解SQL中的约束,包括声明性(PK,UNIQUE,FK)和触发.