PHP を使用してデータベースを管理する権限を設計する方法

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

要件ステートメント

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

NoahWeb のアクション プログラミング コンセプトの助けを借りて、システム設計者は設計段階でプログラム構造の設計を考慮する必要はなく、プログラム フローとデータベース構造から開始します。要件を実現するには、「グループ」操作の概念や権限管理システム全体の再利用性など、データベースの設計が非常に重要です。

最初にデータベース構造を分析してみましょう:

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

これら 3 つのテーブル間の関係は多対多であり、アクセス許可は同時に複数の管理グループに属することができ、また、1 つの管理グループに同時に複数のアクセス許可が含まれることもあります。同様に、1 人のユーザーが同時に複数の管理グループに所属することもでき、1 つの管理グループに同時に複数のユーザーが含まれることもあります。

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

さらに、システムの実行中に左側のメニューの権限列を制御するためのテーブルが必要です。これが「権限列テーブル」です

上記の分析に基づいて、データベース構造を設計します、以下に示すように：

権限管理システムのデータテーブルフィールドの設計を表示するには、ここをクリックしてください

適切な分析を行うために、データベース構造図を分割しました 3 つのエンティティテーブルの機能はすでに非常に優れています。それでは、マッピング テーブルの 2 つの役割を見てみましょう。

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

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

図の赤い丸を見て、まず gorupid フィールドの相関を見てください。実際のデータベースにおけるこの相関メソッドのパフォーマンスは次のとおりです。

図に示すように、「スーパー管理者」は管理グループ テーブル グループ ID が 1 の場合、権限マッピング テーブル内のグループ ID 1 の権限は、「スーパー管理者」が所有する権限になります。

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

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

この相関を通じて、権限マッピングテーブル内の権限の詳細情報を照会できます。これらを総合すると、管理グループが実行できる権限とその詳細がわかります。

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

複数のデータベース操作の後、権限テーブルの ID フィールドが変更される場合があります。
権限マッピング テーブルには、管理グループが実行できる権限のみが記録されます。
権限テーブルのIDが変更されると、権限マッピングテーブルのレコードも変更されます。
管理グループが実行できるアクセス許可は間違いが発生する可能性があり、これは非常に望ましくないことです。
上記の状況を考慮すると、関連付けにはアクション フィールドを使用する必要があります。理由は次のとおりです。

権限テーブルでは、ID は変更される可能性がありますが、アクション フィールドはいかなる状況でも変更できません。
権限マッピングテーブルに記録されるアクションフィールドは変更されません。
管理グループは権限を実行でき、エラーは発生しません。
2つの人事マッピングテーブルは以下のとおりです:

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

写真の赤丸部分を見て、まずgroupidフィールドの関連付け、パフォーマンスを見てください。データベース内のこの関連付けは次のとおりです。

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

この相関法を使うのは、誰が管理グループに属しているかを調べることです。上記と同様に、idフィールド（人事マッピングテーブルのmasteridフィールド）に関連付けて人事の詳細情報を問い合わせます。

id フィールド (人事マッピング テーブルの masterid フィールド) は、データベース内で次の図の形式で表されます。

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

この相関方法を使用すると、管理グループ内の人々の詳細情報を照会できます。これらを総合すると、管理グループに誰がいるのか、その人の詳しい情報がわかります。

上記の権限テーブルと権限マッピングテーブルと組み合わせることで、下図に示すように、必要な「グループ」操作が実現されます

実際、管理グループテーブルには、名前、グループIDなどグループ内のユーザーに関する詳細情報と、そのグループが実行できる権限に関する詳細は、担当者テーブルと権限テーブルに記録されます。 2 つのマッピング テーブルには、グループに誰が所属しているか、およびそのグループがどのような権限を実行できるかが実際に記録されています。 2 つのマッピング テーブルの接続を通じて、3 つのエンティティ テーブル間の相互作用が実現され、要件に記載されている「グループ」操作が完了します。

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

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

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

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

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

概要:

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

付録:

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

以下に示すように、6 つのテーブルに分割されている権限管理システムのデータベース テーブル設計を見てみましょう:

アクション テーブル:

actioncolumn テーブル システムの実行中に、左側のメニュー バーにいくつかの異なる機能が表示されます。列が追加されるたびに、対応する 1 つのレコードがテーブルに追加されます。新しい列が左側のメニュー バーにも追加されます。

actiongroup テーブル:

mastergroup テーブルは、管理者が所属する管理グループを記録します。管理者は同時に複数のグループに所属する可能性があるため、テーブル内に特定の管理者に関する複数のレコードが存在する可能性があります。

マスターテーブル:

マスターテーブルには、すべての管理者の情報が記録され、管理者が追加されるたびにレコードがテーブルに追加されます。

終了