如何建立关系模型（类似 GitHub）权限？

tl;dr：我如何实现像（例如）github 的权限模型

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

我计划实现一个类似于 github 的权限模型：

1. users
2. 用户可以分组
3. 用户可以在组织中
4. 团体可以在组织中
5. a user will be permitted any of C, R, U, and D operations on an asset, group, or organization as:
   1. 已被允许进行这些（C、R、U、D 中的任何一项）操作的个人用户
   2. 已被授予这些权限的组的成员
   3. a member of an organization that has been granted those permissions
      1. 或作为组的成员，其中该组属于具有权限的组织
6. 用户被授予“读取”权限，因为资产/组/组织对匿名用户（“公共”）是可见的（可读）
7. a user should also have a set of permissions to say whether they can do any of C, R, U, or D on the permissions (a user can create a permission[C,R,U,D] for another user, a group, or an org)
   1. 用户可以为他们创建的任何资产、组或组织，或者他们被授予设置权限的任何资产、组或组织设置权限。

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

我大约如何建模？

显然我有这些模型：

1. Asset
2. User
3. Group
4. 组织

接下来是什么？

1. 允许？
2. PermissionType（捕获 C/R/U/D）？

我正在从节点使用mysql（通过sequelize），但我自己可以弄清楚具体的语法，我只是还没有弄清楚如何从概念上做到这一点。

更多 @philipxy 的观点：

您建议我做更多的事情确实是我认为我正在寻求帮助的事情。也就是说，那些信息设计方法（NIAM、FCO-IM、ORM2、IDEF1X）就是我正在寻找的。我对关系数据库了解相当多执行（学习规范化和规范形式等的时间），但实际上，指定业务需求并将其转换为可操作规范的过程是一个挑战。

• ORM2 is difficult to find because of name collisions with the nodejs module. : I have downloaded the book linked from the NIAM wikipedia page
• 现在 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可以由一个创建User U
9. CRUD on Assets:
   1. an Entity E可以被允许（通过Permission P?) 执行操作Ac on Assets
   2. those Actions are:
      1. Create
      2. Read
      3. Update
      4. Delete
   3. the Entity may be of types:
      1. User
      2. Group
      3. Organization
      4. Anonymous User/“公众”
   4. details (shown only for Read, but also relevant for Create, Update, and Delete):
      1. a User U0可以允许另一个User U1 to Read an Asset A
      2. a User U0可以允许Users U谁是成员Group G to Read an Asset A
      3. a User U0可以允许Users U谁是成员Organization O to Read an Asset A
      4. Users U in Group G1, where G1 is a Group那是在一个Organization O已被允许Read Asset A，因此允许Read Asset A
10. a Permission P that references an Asset A may only be created by certain users:
    1. 默认情况下，User U谁是一个的创造者Entity可以创造Permissions为了那个原因Entity,
    2. 但他们可能只参考Assets他们有Permission（在基本情况下：那些Assets创建者U)
    3. a User谁曾是Grant(?)ed特权也可以参考Entity E in a Permission
    4. Gr identifies a Grant
       1. a Grant给出一个Entity创建、读取、更新或删除的权限Permissions引用另一个Entity
       2. like Permissions, Grants have a transitive nature in that:
          1. if Organization O已经Granted（例如）修改的特权Permissions for Entity E, then
          2. not only may Users who are members of O modify Permissions referencing E,
             1. 但是也Users谁是任何成员Group G where G is in O有权限修改Permissions参考E

谓词和表

A 主张是对业务情况的真实或错误的陈述。 A谓词是一个列参数化语句，给定一行给出一个命题。表（基础或查询结果）保存根据其谓词得出真命题的行。

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.  

您可以创建无参数谓词的 true 语句。这些可以使用由以下方式绑定的参数名称FOR ALL & FOR SOME (THERE EXISTS）。以此类命题谓词和/或表名表述的业务规则是数据库限制. Given 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);说明上面的作用（注意它与中间两个的相似性）加上 R 在 Grantor 中是 UNIQUE NOT NULL。

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

你可能想要reify类型和权限。

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. users

U identifies a user

1. 用户可以分组

G identifies a group
user U is in group G

1. 用户可以在组织中

O identifies an organization
user U is in organization O

1. 团体可以在组织中

group G is in organization O

1. 用户将被允许对资产、组或组织进行 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

1. 用户还应该有一组权限来说明是否可以设置上述权限

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

什么是“上述权限”？也许你的意思是用户CRUD权限和组织CRUD权限？也许您的意思是创建、读取等操作有单独的权限？你需要更清楚。

“一组权限”中有哪些权限？这里的“许可”实际上是指“对特定受让人的特别许可”吗？你需要更清楚。

更清晰的方法是给出尽可能简单的规则和谓词，但也不要简单到没有提及相关实体/值。之后您可能希望将多个规则和谓词概括为单个规则和谓词。例如，不处理用户、团体、组织和资产，而是拥有授予者和可信任者：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 子类型/继承/多态性习语。例如，用户、组和组织是权限拥有者和持有者的类型；我将它们设为类型授予者的子类型。也许您想要某种权限目标类型，它是可授权者和授予者的联合。也许您想要权限类型。也许某些权限具有关联的被授予者。也许“C”、“R”、“U”和“D”是权限，“CRUD”是一种权限。您可能想要记录授予者向受让人授予了哪些权限。

稍后，如果连接位于共享 PK/UNIQUE 上且两者具有相同的值集，则我们可以通过连接来替换表。当我们可以连接 PK/UNIQUE 和 FK 时，我们可以将表替换为与它们的连接类似的表，但 FK 可为空。还有其他时候，我们可以毫无问题地替换多个表。但首先要确定基本谓词。

了解关系数据库设计。遵循一些信息设计方法。最好的是 NIAM/FCO-IM/ORM2 系列的成员。查看 IDEF1X。不要依赖产品。

了解约束。他们follow来自谓词和业务规则。它们是关于谓词可能的业务情况的事实。同样，它们是关于表中可能的数据库状态的事实。还可以了解 SQL 中的约束，包括声明式（PK、UNIQUE、FK）和触发式约束。