0

現在、2つの弱いエンティティが関連付けられたエンティティを形成する状況があります(多対多の関係のため)。

「プロジェクト」の強力なエンティティは、

projectID (PK), projectName, projectStartDate, projectEndDate

「タスク」の弱いエンティティは、

composite primary key projectID (FK,PK) and taskID (PK), taskName,etc

「リソース」の弱いエンティティは、

composite primary key projectID (FK,PK) and resourceID (PK), resourceName, maxUnits, standardRate, costPerUse, etc

（資源実体とは、人力・設備・機械のようなものです。ただし、プロジェクトごとに資源は異なりますので、単独の実体ではなく、「プロジェクト」の実体に関連付けられた弱い実体でなければならないと感じています。）

ただし、1 つのリソースがプロジェクト内の複数のタスクを持つことができ、1 つのタスクが複数のリソースを持つことができます。したがって、多対多の関係が形成されました。(リソースとタスクの弱いエンティティ間)

したがって、「割り当て」エンティティと呼ばれる関連エンティティがあります。

「Assignment」テーブルをマッピングすると、次の属性が含まれます。

projectID, taskID, resourceID, workCompleted, work, units

その後、「Assignment」テーブルの SQL 構造を作成するときに、 ProjectID をTask Weak Entityから参照するのか、Resource Weak Entityから参照するのか、混乱しています。

それとも、すべてを間違ってマッピングしていますか?

4

1 に答える 1

0

まあ、これは実際のデータやデータモデルなどに大きく依存するため、実際に完全に答えるのは難しいでしょう.

あなたが言及したことから、プロジェクトに関連付けられていないリソーステーブルが必要だと思います。なぜなら、それがスタッフ/マンパワーである場合、1人のスタッフメンバーが複数のプロジェクトに関連付けることができるはずだからです(私は思うでしょう)。・「スタッフ」と「プロジェクト」の関連が多い。

まず、次のようなテーブル構造が必要になると思います。

Staff/Resource --> ResourceOnProject     <-- Project
Id (PK)        --> ProjectID, ResourceId <-- Id (PK)

既存の Resource テーブルの代わりに。

これが可能であれば、それはあなたを今後助けるはずだと思います。タスクの情報によっては、同じことができる場合があります。

しかし今、現在のセットアップで直面している「二重」の ProjectId 問題を必要とせずに、Assignment を変更して Staff/Resource から ResourceId を保持する可能性があるはずです。

だから基本的に：

Staff/Resource (Id PK)
Project (Id PK)
ResourceOnProject (ProjectId FK, ResourceId FK)
Task (Id PK, ProjectId FK) 
Assignment (TaskId FK, ProjectId FK, ResourceId FK)
于 2015-01-09T07:14:52.697 に答える