このデータに最適なリレーショナルデータベース構造

次のシナリオのデータベーススキームを作成しています。

• ユーザーがいます
• ユーザーには役割があります（「開発者」や「CEO」など）
• ロールにはアプリケーションがあります（「Topdesk」など）
• アプリケーションには権限があります（「ナレッジベースの更新」など）
• ロールがアプリケーションへのアクセス権をすでに持っている場合、ロールは権限を持つことができます

高性能環境がない（速度を最適化する必要がない）と仮定すると、このスキーマを実装する最良の方法は何でしょうか？データベース環境には、MySQL、MSSQLを使用できます。リレーショナルデータベースの設計が重要です。

私自身は次のことを考え出しました：

もちろん、最も不確かな部分は、Applications_Permissions_Rolesテーブルです。これは、リンクテーブルですの上に別のリンクテーブル。これまで使用したことも、見たこともありません。それを行う別の方法は、それを役割と権限の間のリンクテーブルで置き換え、次にコードまたは制約を使用して必要な関係を確認することです...しかし、それは私にとって良い解決策のようではありません。これらのことは、コードレベルではなく、可能な限り（可能であると思われる場合）データベースレベルで実施する必要があります。

次に、Permissions.ApplicationとApplications.Idの間のリンクが必要ですか？Roles_Applicationsに行がない可能性があるため（新しいアプリケーションを追加した直後など）、どの権限がどのアプリケーションに属しているかを判別することができないため、これを使用します。また、権限が属するアプリケーションを検索するための単一の参照ポイントでもあります。これは正しいと思いますが、それはまた、データベース設計において円を描くものです。ON_DELETEまたはON_UPDATEをカスケードに設定しようとすると、MSSQLエラーが発生します。

何か提案、またはこれはどのように行われることになっていますか？命名規則などに関するその他の提案も（おそらくコメントとして）歓迎されます。

ありがとう、
Luc

編集：タイトルを変更しました。以前のものはより包括的でしたが、おそらく複雑すぎます。

モデル化した方法は問題ありません。モデルにより、ビジネスルールがデータベースによって確実に適用されます。

代わりにできることがいくつかあります。1つは、の代理キーを削除することRoles_Applicationsです。交差テーブルとして、2つの外部キーを一緒に複合主キーとして使用できます。あなたはこれをしなかった場合は、それが伝播するだろうRoleし、ApplicationあなたにダウンApplications_Permissions_Rolesテーブル。これには、正規化を損なうことなく、アプリケーションの許可データの「ワンストップショップ」を増やす（結合の数を減らす）ことができるという利点があります。

もう1つの方法は、少し単純化して、各アプリケーションのデフォルトの権限を定義することです。「デフォルトアクセス」、「基本アクセス」、「ユーザー」など、わかりやすい名前を付けることができます。これにより、モデルをフラット化し、基本的にRoles_Applicationsテーブルを削除してにApplications_Permissions_Roles直接結合できますRoles。これにより、「どのロールがどのアプリケーションにアクセスできるか」を尋ねるために使用するクエリの性質が変わります。ただし、ビジネスルールはスキーマによって適用されます。

Roles_Applicationここでは実物を表すようには見えません。そのレベルが何であるかを確認するためにチェックアウトする必要がある場合でも、特定のロールがアプリケーションに対するあるレベルの権限を持っていることを示す以外に、それApplications_Permissions_Rolesは何ですか？例として、現在のモデルでアプリケーションカレンダーへの書き込みアクセス権を取得するCEOを次に示します。

役割

ID    Name
--    ----
1     CEO

用途

ID    Name
--    ----
C     Calendar

許可

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Roles_Applications

ID    Role_ID    Application_ID
--    -------    --------------
50    1          C

Applications_Permissions_Roles

Role_Application_ID    Permission_ID
-------------------    -------------
50                     10

この一連の関係は、なしでモデル化できると思いますRoles_Applications。それを削除した場合（Joel Brownの提案どおりですが、「デフォルトのアクセス権」があると仮定する変更はありません）：

役割

ID    Name
--    ----
1     CEO

用途

ID    Name
--    ----
C     Calendar

Applications_Permissions（nee Permissions）

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Applications_Permissions_Roles

Role_ID    Application_Permission_ID
-------    -------------
1          10

古いPermissionsテーブルには、「読み取り」や「書き込み」などの単純な権限はなく、「Topdesk」や「カレンダー」などのアプリケーションに適用できます。「Topdeskに書き込み」や「」などのアプリケーション固有の権限が含まれています「カレンダーに書き込む」と「Windowsでシステムクロックを変更する」わかりやすくするために、表に名前を付けましたApplications_Permissionsが、もちろんこれは必要な手順ではありません。

このアプローチには、Joelの2番目の提案と同様に、モデルをフラット化する効果がありますが、アプリケーションロジックやデフォルトのアクセス許可の概念は追加されません。 Roles_Applicationsロールがアプリケーションにある程度のアクセス権を持っていることを示す以外に、パーティーに何ももたらしていませんでした。その情報はApplications_Permissions_Roles、Role_IDの適切な値を持つレコードの存在によって、より簡潔に伝えられます。