私は現在、ここでローカルアソシエーションのメンバー管理を開発しており、現在データベーススキーマを開発しています。それを改善し、他の役割ベースのアクセスモデル（RBAC）の例を示すために、それをあなたと共有したいと思います。特にテーブル間の関係について建設的な批判をいただければ幸いです。
高解像度へのリンク：http：//i.stack.imgur.com/WG3Vz.png
スキーマは次のとおりです。
使い方：
既存のクライアント（実際にはアソシエーションのメンバー）を外部アプリケーションから管理アプリケーションにマッピングしています。（クライアントテーブル）
関連付けは、Division、Subdivisionsなどで構成されます（intern_structuresテーブル）。すべてのクライアントは、複数のディビジョン、サブディビジョン、セクションなどのメンバーになることができます。
すべてのクライアントは、社長、アクチュアリー、会計などのようなメンバーシップ（部門など）で1つまたは複数の役割を持つことができ、各役割には、役割の所有者が自分の部門、下位部門、セクションなどで他の人に適用できる特定の特権があります。 。
クレデンシャルは、アプリケーションの特定のアクションに関連付けられています。クレデンシャルの所有者は、自分のスコープ内の他のメンバーに対してこのアクションを実行できます。複数の「スタンドアロン」アプリケーションが存在する可能性がありますが、それらはすべて同じ認証/承認システムを共有します。
アプリケーションは、モジュール/サブモジュール/アクションなどで構成されています。例として、「個人情報」モジュールがあります。このモジュールには「画像」というサブモジュールが含まれており、この画像に「表示、削除、編集」アクションを適用できます。ただし、削除しようとしている写真の人物が、適切な役割を持っている部門/セクションにいない限り、写真を削除することはできません。
内部構造とアプリケーション構造はどちらもツリーであり、隣接リストとネストされたセットとして実装されます。隣接リストは整合性を保証し、ネストされたセットにより、ツリーをすばやくトラバースできます。
例外は、特定の資格情報（client_credentials）を誰かに直接与えることができることです。これは、自分の部門/セクションにいない誰かに対して特定のアクションを実行する必要がある場合に必要です。
したがって、誰かが複数の部門/セクションのメンバーになり、メンバーであるすべての部門/セクションで複数の役割を取得することができます。誰かが複数の役割を通じて持っているすべての資格情報をマージします。また、クレデンシャルは常に正であり、制限的なクレデンシャルは使用できません。