0

例に基づいて尋ねるのが最善だと思います。人、顧客、プロジェクトがあります。

人から顧客への関係は an:m の関係です。人々は複数の顧客のために働くことができます。

プロジェクトと顧客は 1 対 n の関係です。1 つのプロジェクトは常に特定の顧客に属しますが、顧客はもちろん複数のアクティブなプロジェクトを持つことができます。

人から顧客への関係は :m の関係ですが、プロジェクトから顧客へ、および人から顧客への割り当てによって制限されます。

詳細: 一部の従業員は複数の顧客のために働いていますが、それらの顧客のいくつかのプロジェクトのみを担当しています。

顧客 A にプロジェクト 1、2、3 があり、顧客 B にプロジェクト 4、5、6 があるとします。

現在、フレッドは顧客 A のプロジェクト 1 と顧客 B のプロジェクト 5 と 6 に取り組んでいます。代わりに、ティムは顧客 A のプロジェクト 2、3 と顧客 B のプロジェクト 6 に取り組んでいます。しかし、現在どのプロジェクトにも割り当てられていません。顧客は後で彼をプロジェクトに割り当てることができます。

さて、適切なリレーショナル データベース設計を使用して、プロジェクトなしで顧客 (Nick など) に人を割り当てることができ、さらに、後でそれらを任意の顧客のプロジェクトに割り当てることができるようにするにはどうすればよいでしょうか。に。

では、最初に Nick を顧客 A に割り当てずに Nick をプロジェクト 1、2、または 3 に割り当てることができないようにデータベース モデルが保証されるように、テーブルを設計する必要がありますか?

アイデアをありがとう:)

4

2 に答える 2

1

SQL での例を次に示します。

CREATE TABLE Project
 (ProjectID INT NOT NULL PRIMARY KEY, CustomerID INT NOT NULL,
 UNIQUE (ProjectID, CustomerID));

CREATE TABLE EmployeeProject
 (EmployeeID INT NOT NULL, ProjectID INT NOT NULL, CustomerID INT NOT NULL,
  FOREIGN KEY (EmployeeID, CustomerID) REFERENCES EmployeeCustomer (EmployeeID, CustomerID),
  FOREIGN KEY (ProjectID, CustomerID) REFERENCES Project (ProjectID, CustomerID),
  PRIMARY KEY (EmployeeID, ProjectID));
于 2010-12-15T09:01:31.387 に答える
0

このモデルでは、Projectは のサブタイプですAssignment。たとえば、代入のタイプはP = projectまたはO = Openです。

  • 各割り当て (オープンまたはプロジェクト) は、1 人の顧客のみに属します。
  • 複数の従業員が異なる時間帯に 1 つの割り当てに取り組んでいる場合があります。

再割り当ての制約は、ビジネス ロジック (アプリケーション層) で処理する必要があります。オープンな割り当てからプロジェクトへの切り替えは、その従業員の割り当て ( ) の期間を閉じ、その従業員と顧客の組み合わせに対してEndDateの新しい割り当てを定義することで実行できます。type = project

代替テキスト

于 2010-12-15T12:47:45.213 に答える