ビジネスシステムにユーザー許可管理を実装します
b/sシステムの権限は、c/sの権限よりも重要です。 C/Sシステムには特別なクライアントがあるため、アクセスユーザーの許可検出は、クライアントまたはクライアント +サーバーの検出を通じて実装できます。 B/Sでは、ブラウザはすでにすべてのコンピューターで利用可能です。完全な許可検出が確立されていない場合、「違法ユーザー」は、ブラウザを介してB/Sシステムのすべての機能に簡単にアクセスする可能性があります。したがって、B/Sビジネスシステムには、アクセス許可検出を実装するための1つまたは複数の許可システムが必要であるため、認定ユーザーは正常におよび合法的に使用できるようになり、不正な「違法ユーザー」が完全に「拒否」されます。ほとんどのB/Sシステムでのユーザー機能許可の制御を満たすことができる許可システムを設計する方法を見てみましょう。
要件ステートメント
•責任が異なる人員は、システム操作に異なる権限を持つ必要があります。優れたビジネスシステム、これは最も基本的な機能です。
•グループに権限を割り当てることができます。大企業のビジネスシステムの場合、管理者に従業員に1つずつシステム操作許可を割り当てるように依頼するのは時間がかかり、不便です。したがって、システムは「グループ」で動作するという概念を提案し、一貫した許可を持つ人々を同じグループに組織し、グループに許可を割り当てます。
•許可管理システムは拡張可能である必要があります。許可管理機能を備えたシステムに参加できるはずです。コンポーネントと同様に、開発されたすべての管理システムの許可管理部品を再開発する代わりに、コンポーネントを常に再利用できます。
•ビジネスシステムの機能権を満たします。従来のビジネスシステムでは、許可管理には2つのタイプがあります。 1つは機能的権限の管理であり、もう1つはリソース許可の管理です。異なるシステム間では、機能的な権限を再利用できますが、リソースの権限は再利用できません。
デザインについて
Noahwebのアクションプログラミングコンセプトの助けを借りて、設計段階では、システム設計者はプログラム構造の設計を考慮する必要はありませんが、プログラムフローとデータベース構造から始めます。要件を実現するために、データベースの設計は非常に重要です。それが「グループ」操作の概念であるか、許可管理システムのセット全体の再利用可能性であるかは、データベースの設計にあります。
最初にデータベース構造を分析しましょう。
まず、アクションテーブル（以下「許可テーブル」と呼ばれる）、GorupManager Table（以下では「管理グループテーブル」と呼ばれる）、およびマスターテーブル（以下「人事テーブル」と呼ばれる）は、「許容」の情報、「管理グループ」の情報、および「人員情報」を記録する3つのエンティティテーブルです。下の図に示すように：
これらの3つのテーブルの関係は、多くのものです。 1つの許可は、複数の管理グループに同時に属する場合があり、1つの管理グループに複数の許可を同時に含めることもできます。同様に、人は同時に複数の管理グループに属し、管理グループに複数の担当者を同時に含めることもできます。下の図に示すように：
これら3つのテーブルの間には多くの関係があるため、他の2つのテーブルを使用して相互作用を完了することをお勧めします。これらの2つのテーブルは、マッピングの役割、つまり「アクショングループ」テーブル（以下では「許可マッピングテーブル」と呼ばれる）と「MasterGroup」テーブル（以下「人事マッピングテーブル」と呼ばれる）と呼ばれます。前者は、許可表と管理グループテーブルの間の相互作用をマッピングします。後者は、人事テーブルと管理グループテーブルの間の相互作用をマッピングします。下の図に示すように：
さらに、下の図に示すように、システムの実行時間の左メニュー、つまり「許可列テーブル」の許可列を制御するには、テーブルも必要です。
上記の分析に基づいて、以下の図に示すように、データベース構造設計を実施します。
ここをクリックして、許可管理システムデータテーブルフィールド設計を表示します
適切な分析を実行するために、データベース構造チャートを分割します。 3つのエンティティテーブルの役割はすでに非常に明確です。次に、2つのマッピングテーブルの役割を見てみましょう。
許可マッピングテーブルを以下に示します。
まず、許可マッピングテーブルと管理グループテーブルと許可表とのフィールドアソシエーションを見てみましょう。
写真の赤い円を見ると、まずゴルピドフィールドの関連性を見てください。実際のデータベースでのこの関連メソッドのパフォーマンスは次のとおりです。
図に示すように、管理グループテーブルの「スーパー管理者」のGroupIDは1であるため、許可マッピングテーブルのGroupIDが1の許可は「スーパー管理者」が所有する許可です。
GroupID Field Associationを使用して、管理グループが実行できる許可を見つけます。ただし、これらの許可の詳細情報は、アクションフィールドアソシエーションにあります。
データベース内のアクションフィールドの動作は次のとおりです。
この協会を通じてのみ、許可マッピングテーブルのこれらの許可の詳細情報を見つけることができます。要約すると、管理グループが実行できる権限と、これらのアクセス許可の詳細がどのようなものかを知っています。
たぶん、あなたは尋ねるでしょう、なぜアクションIDフィールドを使用して関連付けてみませんか？なぜなら：
•許可表のIDフィールドは、複数のデータベース操作後に変更される場合があります。
•Permissions Map Tableは、1つの管理グループが実行できる権限のみを記録します。
•許可表のIDが変更されると、許可マップテーブルのレコードも変更されます。
•管理グループが実行できる許可にエラーが発生しますが、これは非常に望ましくありません。
上記の状況を考慮すると、次のためにアクションフィールドを関連付ける必要があります。
•許可表では、IDが変更される可能性がありますが、アクションフィールドはいかなる状況でも変更できません。
•許可マップテーブルに記録されたアクションフィールドは変更されません。
•管理グループが実行できる許可にエラーはありません。
2人用マッピングテーブルは次のとおりです。
下の図に示すように、人事マッピングテーブル、管理グループテーブル、および人事テーブルとのフィールドアソシエーションについて学びましょう。
写真の赤い円の部分を見ると、まずGroupIDフィールドアソシエーションを見てください。この関連付け方法は、以下の図に示すように、データベースで実行されます。
図に示すように、「スーパー管理者」グループのGroupIDは1です。人事マッピングテーブルを見てみましょう。管理者はスーパー管理者グループに属し、管理者はスーパー管理者グループに属し、管理者グループにも属します。
この関連付け方法は、管理グループに誰がいるのかを調べるために使用されます。上記のように、人の詳細情報は、IDフィールド（人事マッピングテーブルのMasterIDフィールド）との関連によって照会されます。
下の図に示すように、IDフィールド（人事マッピングテーブルのMasterIDフィールド）は、データベースに関連しています。
人は、複数の「管理グループ」に同時に属する場合があります。図に示すように、管理者は同時に2つの「管理グループ」に属します。したがって、人事マッピングテーブルには、管理者に関する2つの記録があります。
この方法でのみ、管理グループの担当者の詳細情報を照会できます。それを組み合わせることによってのみ、管理グループとこの担当者の詳細情報を知ることができます。
上記の許可表と許可マッピングテーブルを組み合わせて、以下の図に示すように、要件の「グループ」操作が実現されます。
実際、管理グループのテーブルは、グループの人々の詳細と同様に、グループの詳細と同様に、グループが実行できる許可の詳細など、グループの基本情報のみを記録します。 2つのマッピングテーブルのみが、実際にグループ内の人々がどのようなものであり、どのような権限を実行できるかを記録します。 2つのマッピングテーブルの接続を介してのみ、3つのエンティティテーブル間の相互作用を実現できるため、要件に記載されている「グループ」操作が完了します。
許可列のテーブルと許可表の間の相互作用を見てみましょう。これら2つのテーブルの間のフィールドは次のとおりです。
2つのテーブルは、ActionColumnidフィールドを使用して関連付けます。データベースの関係方法を以下の図に示します。
図に示すように、この関連付け方法を通じて、許可表の許可を属する列が明確に確認できます。
現在、データベース構造は非常に明確であり、許可と「グループ」操作を割り当てる機能が実装されています。要件に記載されている許可管理システムの再利用性の問題を分析しましょう。
このデータベース設計方法を使用して構築されたシステムを再利用できるのはなぜですか？
システム内の3つの決定的な要素が、3つのエンティティテーブルに記録されています。 「許可」、「グループ」、「人」。これらの3つの要素は、互いに影響を受けることなく自由に追加できます。どのタイプのビジネスシステムであっても、これら3つの決定的な要素は変化しません。つまり、構造は変わらないが、データのみが変更されることを意味します。
3つの要素間の関係は、2つのマッピングテーブルに記録されます。しかし、これらの関係は人間によって完全に作成されます。変更が必要な場合、構造を変更せずにデータベース内のレコードでのみ動作します。
許可列のテーブルは、システムの使用時に表示される列を記録します。列を追加するか、列を変更するか、列を削減するかにかかわらず、それは単なる操作レコードです。
要約すると、この方法でデータベースを設計することでシステムを完全に再利用でき、「変更」のテストに耐えることができます。
要約：
このシステムの鍵は、3つの物理テーブルがシステムのコアコンポーネントをしっかりと把握し、2つのマッピングテーブルが3つの物理テーブル間の相互作用を完全にマッピングすることです。難易度は、関係を記録し、「グループ」操作の概念を実装するマッピングテーブルの作業を理解することにあります。システムの全体的な設計は、さまざまなMISシステムで「再利用」することにより、異なるシステムの機能的許可設定を満たすことです。
付録：
許可管理システムデータテーブルのフィールド設計
下の図に示すように、許可管理システムのデータベーステーブル設計を6つのテーブルに分割します。
アクションテーブル：
アクションテーブルは、システム内のすべてのアクションとアクション関連の説明を記録します。
ActionColumnテーブル：
ActionColumnテーブルは、アクション列を記録します。システムが実行されているとき、左メニューバーはいくつかの異なる機能を提供します。各ブロックは列です。各列が追加され、テーブルの1つのレコードが追加されます。それに対応して、左メニューバーに新しい列が追加されます。
ActionGroupテーブル：
ActionGroupテーブルは、アクションが配置されているグループを記録します。
グループマネージャーテーブル：
グループマネージャーテーブルは、管理グループに関する関連情報を記録します。追加された各管理グループについて、ここに1つのレコードが追加されます。
マスターグループテーブル：
マスターグループテーブルは、管理者が配置されている管理グループを記録します。管理者は同時に複数のグループに属する可能性があるため、テーブル内の管理者に関する複数のレコードがある場合があります。
マスターテーブル：
マスターテーブルは、すべての管理者の情報を記録します。追加された各管理者について、テーブルにレコードが追加されます。
Javaの上記の一般的な許可管理デザイン（推奨）は、私があなたと共有するすべてのコンテンツです。参照を提供できることを願っています。wulin.comをもっとサポートできることを願っています。