通常最简单的权限管理只需要一张用户表User，一张资源表Resource，一张用户与资源的关联表ResourceInUser即可。表示同一个用户可以拥有多个资源，同一个资源可以被多个用户拥有，可能的结构如下：
有时候我们需要同一个资源对不同的用户有着不一样的表现，比如用户A是临时拥有某资源，而用户B是永久拥有某资源，这时候我们需要引入“许可”的概念，追加一张许可表Permission，该表表示用户拥有资源的不同方式。可能的结构如下：
有时候我们需要对许可进行分类，比如按业务来分，我们想把可以协同完成一种业务的许可归为一类，以更方便的将这些许可授予某一个用户来完成相应的业务。这时候我们需要引入“角色”的概念，角色是许可的集合，通常情况下，这些许可可以协同完成某一项或多项业务。可能的结构如下：
由此，指定的用户便拥有了可以完成某项业务的许可。问题又来了，有时候我们希望多名用户都可以完成同样的业务，但又苦于这类用户较多，不适合一一授予角色，这时候我们需要引入“用户组”的概念，它是一系列相似用户的集合。可能的结构如下：
这样以来，该用户组下的所有用户都可以完成同样的业务。用户在具备了单独授予许可能力的同时也具备了被批量授予许可的能力。
有时候我们希望把许可分的更加详细，拥有许可的角色也显得更加精细化，这时候如果我们需要给某用户或用户组授予角色时不得不同时选择好几类角色授予，这样会显得太麻烦。此时我们引入“角色组”的概念，角色组其实是一系列相似或需要协同处理业务的角色集合。有了角色组，我们可以很轻松的把多个角色才有的许可授予给用户或用户组。可能的结构如下：
在组织架构较大的企业中，单独靠用户组和角色组已经不能较好的满足许可的授予，于是有了“组织”授权。可能的结构如下：
当组织变得非常庞大之时，可能会出现需要同时管理多个组织的情况，这时候就需要引入“架构”的概念。架构是组织的上一层，可以包含多个组织，同时也是租户的下一层。可能的结构如下：
以上是一个典型的基于角色的访问控制（Role-Base Access Control，RBAC）案例。但有时RBAC并不一定能满足我们的全部需求，我们可能还需要角色的继承，约束，甚至是优先等级，这些是对RBAC更深一层的使用。对于更加复杂的权限管理系统来说，可能需要同时基于角色和资源许可。