[php] ユニバーサル著作権管理データベースの設計

B/S システムの権限は C/S システムの権限よりも重要です。C/S システムには特別なクライアントがあるため、アクセス ユーザー権限の検出は、クライアントを通じて、またはクライアント + サーバーの検出を通じて実装できます。 B/S では、すべてのコンピュータにブラウザがあり、完全な許可の検出が確立されていない場合、「不正なユーザー」はブラウザのすべての機能を介して B/S システムに簡単にアクセスできる可能性があります。したがって、B/S業務システムでは、許可されたユーザーが許可された機能を正常かつ合法的に利用できるようにするために、アクセス許可の検出を実装するための許可システムを1つ以上備えている必要があり、許可されていない「不正なユーザー」は完全に「シャットアウト」されます。ほとんどの B/S システムでユーザー機能の権限制御を満たすことができる権限システムを設計する方法を見てみましょう。

要件ステートメント

• 異なる責任を持つ担当者は、システム操作に対して異なる権限を持つ必要があります。 優れたビジネスシステム、これは最も基本的な機能です。
• 「グループ」に権限を割り当てることができます。大企業の業務システムでは、管理者が従業員にいちいちシステムの操作権限を割り当てるのは手間がかかり不便です。したがって、システムは「グループ」を操作し、同じ権限を持つユーザーを同じグループにまとめて、そのグループに権限を割り当てるという概念を提案しています。
• 権限管理システムは拡張可能である必要があります。権限管理機能を備えたあらゆるシステムに追加できる必要があります。コンポーネントと同様に、管理システムを開発するたびに権限管理部分を再開発する必要がなく、継続的に再利用できます。
• ビジネス システムの機能権限を満たします。 従来のビジネス システムでは、2 種類の権限管理があります。1 つは機能権限の管理で、もう 1 つは、機能権限は異なるシステム間で再利用できますが、リソース権限は再利用できません。

  設計について

  NoahWebのアクションプログラミングのコンセプトでは、システム設計者は設計段階でプログラム構造の設計を考慮する必要はなく、プログラムの流れから始めて、 データベース構造 始めましょう。要件を実現するには、「グループ」操作の概念にしろ、権限管理システム全体の再利用性にしろ、すべては データベース の設計にあります。 最初にデータベース構造を分析しましょう:

  まず、アクションテーブル(以下「権限テーブル」と呼びます)、gorupmanagerテーブル(以下「管理テーブル」と呼びます)グループテーブル)、マスターテーブル(以下「人事テーブル」)は、「権限」情報、「管理グループ」情報、「人事」情報を順に記録する3つのエンティティテーブルです。以下に示すように:

  

  これら 3 つのテーブル間の関係は、同時に複数の管理グループに属することができ、管理グループには次のものが含まれる場合もあります。複数の権限。同様に、1 人のユーザーが同時に複数の管理グループに所属することもでき、1 つの管理グループに同時に複数のユーザーが含まれることもあります。以下に示すように:

  

  これら 3 つのテーブル間には多対多の関係があるため、他の 2 つのテーブルを使用してそれらの間の対話を完了するのが最善です。これら 2 つのテーブルは、マッピングの役割を果たします。つまり、「actiongroup」テーブル (以下、「権限マッピング テーブル」と呼びます) と、「mastergroup」テーブル (以下、「personnel マッピング テーブル」と呼びます) です。権限テーブルと管理グループテーブルとの対話。後者は、人事テーブルと管理グループ テーブルの間の相互作用をマッピングします。以下に示すように:

  

  さらに、システムの実行中に左側のメニューの権限列を制御するためのテーブル、つまり「権限列テーブル」が必要です。以下に示します:

  

  上記の分析に基づいて、以下に示すようにデータベース構造を設計します: ここをクリックして権限管理システムのデータテーブルフィールドの設計を表示します

  

  3 つのエンティティ テーブルの役割がすでに明確になっているので、見てみましょう。 . 2 つのマッピング テーブルの役割。

  権限マッピング テーブル は以下のとおりです:

  まず、 権限マッピング テーブル と 管理グループ テーブル と の間のフィールドの関連付けを見てみましょう。許可テーブル。

  

  画像の赤い丸を見て、最初に実際のデータベースでのこの相関メソッドのパフォーマンスを見てください。

  

  図に示すように、管理グループテーブルの「スーパー管理者」のグループIDは1なので、権限マッピングテーブルのグループID 1の権限も、 「スーパー管理者」。

  groupid フィールドの関連付けを使用すると、管理グループが実行できるアクセス許可を確認できます。ただし、これらの権限の詳細情報は、アクション フィールドの関連付けによって照会されます。

  データベース内のアクションフィールド関連付けのパフォーマンスは次のとおりです:

  

  この関連付けを通じて、権限マッピングテーブル内の権限できる詳細を問い合わせた。まとめると、管理グループが実行できるアクセス許可と、それらのアクセス許可の詳細がわかります。

  おそらく、関連付けに actionid フィールドを使用しないのはなぜかと疑問に思われるかもしれません。理由:

  • 権限テーブルのIDフィールドは、複数のデータベース操作後に変更される可能性があります。
  • 権限マッピングテーブルは、管理グループが実行できる権限のみを記録します。
  • 権限テーブルのIDが変更されると、権限マッピングテーブルのレコードも変更されます。
  • 管理グループが実行できるアクセス許可は間違いが発生する可能性があり、これは非常に望ましくありません。

    上記の状況を考慮すると、関連付けにはアクションフィールドを使用する必要があります。理由は次のとおりです:

    • 権限テーブルでは、IDは変更される可能性がありますが、アクションフィールドはいかなる状況においてもそれを変えることはできません。
    • 権限マッピングテーブルに記録されるアクションフィールドは変更されません。
    • 管理グループが実行できる権限は間違っていません。

      2人のマッピングテーブルは以下の通りです:

      人事マッピングテーブルと管理グループテーブルとを見てみましょう。

      人事テーブル間のフィールドの関連付けは以下に示すとおりです。

      

      の赤丸部分を見てください。画像では、まずグループ ID フィールドの関連付けを確認します。データベース内でのこの関連付けメソッドのパフォーマンスは次のとおりです。

      「管理者」グループは 1 です。

      人事マッピング テーブル を見てみましょう。管理者はスーパー管理者グループに属し、管理者はスーパー管理者グループに属し、管理者グループにも属しています。

      この相関方法を使用して、管理グループのメンバーを確認します。上記のように、id フィールド (person マッピング テーブル の masterid フィールド) に関連付けられて、担当者の詳細情報が照会されます。

      idフィールド(人事マッピングテーブルではmasteridフィールド)、関連テーブルは以下に示すようなデータベースの形式になっています:

      

      図に示すように、管理者は同時に複数の「管理グループ」に所属することができます。したがって、人事マッピングテーブルには管理者に関するレコードが 2 つ存在します。

      この相関メソッドは、管理グループ内の人々の詳細情報をクエリできます。これらを総合すると、管理グループに誰がいるのか、その人の詳しい情報がわかります。

      上記の権限テーブルと権限マッピングテーブルを組み合わせると、要件内の「グループ」操作は次のように実現されます

      

      : 実際、管理グループ テーブルには、名前、グループ ID などのグループの基本情報のみが記録されます。グループ内の人の詳細情報や、そのグループが実行できる権限の詳細情報は、人事テーブルと権限テーブルに記録されます。 2 つの マッピング テーブル は、グループに誰が参加しているか、およびそのグループがどのような権限を実行できるかを実際に記録します。 2 つのマッピング テーブルの接続を通じて、3 つのエンティティ テーブル間の相互作用が実現され、 要件で言及されている「グループ」操作が完了します 。

      権限列テーブルと権限テーブルの間の相互作用を見てみましょう。これら 2 つのテーブル間のフィールドの関連付けは次のとおりです。

      

      データベース内のこの関連付けのパフォーマンスは次のとおりです。

      

      図に示すように、この相関方法により、権限テーブルの権限がどの列に属しているかを非常に明確に確認できます。

      これで、データベース構造が非常に明確になり、権限を割り当てる機能と「グループ」操作が実装されました。次に、権限管理システムの要件で挙げられている再利用性の問題を分析してみましょう。

      なぜこのデータベース設計手法で構築されたシステムが再利用できるのでしょうか?

      • 3 つのエンティティ テーブルは、システム内の 3 つの決定的な要素を記録します。 「権限」、「グループ」、「人」。これら 3 つの要素は、相互に影響を与えることなく、自由に追加できます。どのような業務システムであっても、この3つの決め手は変わらない、つまり構造は変わらず、データだけが変わるということです。
      • 2 つのマッピング テーブルは、3 つの要素間の関係を記録します。 しかし、これらの関係は完全に人為的に作成され、変更が必要な場合は、構造を変更せずにデータベース内のレコードのみが操作されます。
      • 権限列テーブルは、システム使用時に表示される列を記録します。列を追加したり、列を変更したり、列を削減したりする場合でも、それは単なる操作記録です。

        要約すると、このようにデータベースを設計することにより、システムは完全に再利用可能であり、「変更」のテストに耐えることができます。

        概要:

        このシステムの重要な点は、3 つの エンティティ テーブル がシステムのコア コンポーネントをしっかりとキャプチャし、2 つのマッピング テーブルが 3 つの相互作用を完全にマップしていることです。エンティティテーブル。難しいのは、関係を記録し、「グループ」操作の概念を実装するマッピング テーブルの動作を理解することにあります。システムの全体的な設計は、さまざまなシステムの機能許可設定を満たすために、さまざまな MIS システムで「再利用」できるという考えに基づいています。

        付録:

        権限管理システムのデータテーブルのフィールド設計

        権限管理システムのデータベーステーブル設計を見てみましょう。以下に示すように、6 つのテーブルがあります:

        アクション テーブル:

        

        アクション テーブルは、システム内のすべてのアクションとアクション関連の説明を記録します。

        actioncolumnテーブル:

        

        actioncolumnテーブルは、システムの実行中、左側のメニューバーにいくつかの異なる機能が提供され、それぞれが1つの列です。 、列が追加されるたびに、テーブルに 1 つのレコードが追加され、それに応じて左側のメニュー バーに新しい列が追加されます。 actiongroup テーブルにはアクション グループが記録されます。

        groupmanager テーブル:

        

        groupmanager テーブルは、管理グループが追加されるたびに、ここに 1 つのレコードが追加されます。

        マスターグループテーブル:

        

        マスターグループテーブルは、管理者が同時に複数のグループに属する可能性があるため、テーブルには次の内容が記録されます。管理者に対して複数のレコードが存在する場合があります。

        マスターテーブル:

        

        マスターテーブルは、管理者が追加されるたびに、テーブルにレコードが追加されます。

        上記は、内容の側面も含めて [php] ユニバーサル著作権管理データベースの設計を紹介しました。PHP チュートリアルに興味のある友人に役立つことを願っています。