3

そのような状況をどのようにモデル化しますか? データベースはどのように設計する必要がありますか? どのクラスが必要ですか?

問題の説明:各従業員は少な​​くとも 1 つのプロジェクトに属し、各プロジェクトには多くのタスクがあり、各タスクは少なくとも 1 人の従業員に割り当てられています。

私はかき回すことができるはずです

  • プロジェクトに取り組んでいる従業員。
  • プロジェクトに属するタスク
  • 特定の従業員が取り組んでいるタスク。

等...

循環/循環関係は悪い設計であり、排除できますか?

データベースでエンティティをどのように表現する必要がありますか? クラスを使用してエンティティをどのように表現する必要がありますか?

前もって感謝します、

4

4 に答える 4

1

パフォーマンスや使用要件については何も言及されていなかったので、一般的な方法で回答します。より具体的な情報が必要な場合は、回答を更新します。DBテーブルについては、これらの線に沿った一般的な正規化されたアプローチを提案します。

tblProject
    ProjectID
    ProjectDescription etc.

tblTask
    TaskID
    TaskDescription etc.

tblEmployee
    EmployeeID
    Name etc.

tblProjectTasks
    ProjectTasksID
    ProjectID
    TaskID

tblTaskAssignments
    TaskAssignmentsID
    TaskID
    EmployeeID

別の有効なアプローチは、プロジェクトを定義するテーブルと、プロジェクトのリストを定義する別のテーブルを作成することです。同じことがタスクと従業員にも当てはまります。実際のアプリケーションでは、他の明確に定義されたオブジェクトを含むクラスを設計するのと同じように、これらのエンティティがより一般的なテーブルで明確に定義されるのが一般的です。たとえば、従業員以外のプロジェクトリソースについては言及していません。これらのリソースは、リソースのタイプ、リソースプロパティなどを定義し、リソースをプロジェクトやタスクに結合するスキーマで表すことができます。

プロジェクトの従業員を表すテーブルを作成することもできますが、他のテーブルを結合することでプロジェクトに割り当てられた従業員を見つけることができるため、その中のデータは冗長になります。私見ですが、この種の重複は、テーブルが巨大で、この特定のタイプのクエリが非常に頻繁に使用される場合にのみ保証されます。しかし、私はまだ他のアプローチを最初に検討したいと思います。

クラスについても質問されました。あなたの目標をよりよく理解することなしに、あまりにも具体的にするのは難しいです。典型的なオブジェクト指向デザインでは、クラスはプロジェクト、タスク、および従業員を明確に表す必要があります。ただし、特定のニーズに合わせて調整する必要があります。

于 2009-06-02T19:42:26.250 に答える
1

質問にはできる限り一般的な方法で回答し、前の回答のように特定のテーブル構造を繰り返さないようにします。一般的に言えば、エンティティ間の循環関係は悪いことではありません...逆に、それらは非常に一般的です:

There are many Projects
Projects have Employees
Projects have Tasks
Employees are assigned some Tasks

プロジェクトには従業員がいます...そして従業員にもプロジェクトがあります（または、従業員が一度に複数のプロジェクトに取り組むことができる場合は、おそらく多くのプロジェクトがあります）。データベースの観点からは、外部キーを作成すると、必要かどうかに関係なく、その「循環」関係が存在します。

より重要な問題は、概念的な観点から、従業員が自分がどのプロジェクトの一部であるかを知っているかどうかは重要ですか? プロジェクトがどの従業員が取り組んでいるかを知ることはおそらく非常に重要ですが... 従業員がそのプロジェクトで働いていることを知ることは重要ではないかもしれません.これは「ナビゲーション可能性」と呼ばれるものであり、データベース構造とは異なり、クラスでこれを制御できます。Project オブジェクトには Employee オブジェクトのコレクションがありますが、Employee オブジェクトは必ずしも Project プロパティ (または Project のコレクション) を持つ必要はありません。

操作性に関して、私があなたに提供できる定型の答えはありません。これは通常、主観的なものであり、ビジネスのニーズによって異なります。モデリングするビジネスに、従業員がどのプロジェクトに取り組んでいるかを知っているという概念があり、その知識がビジネス ロジックが実行するプロセスを完了するために重要である場合、その循環関係が必要です。従業員とタスク、プロジェクトとタスクなどの間のナビゲーションについても同様です。

于 2009-06-02T20:29:20.243 に答える
0

私はデータベース設計のためにこのようなことをします：

    Create Table Projects
(
    ProjectID int Identity(1,1),
    ProjectName varchar(50) Primary Key NonClustered,
    OtherStuff varchar(255)
)
CREATE CLUSTERED INDEX IX_PROJECTS_ID ON dbo.Projects(ProjectID)

Create Table Employees
(
    EmployeeID int Identity(1,1),
    EmployeeName varchar(50) Primary Key NonClustered,
)
CREATE CLUSTERED INDEX IX_EMPLOYEES_ID ON dbo.Employees(EmployeeID)

Create Table ProjectEmployees
(
    ProjectID int,
    EmployeeID int,
    Constraint pk_ProjectEmpoyees Primary Key (ProjectID, EmployeeID)
)

Create Table Tasks
(
    TaskID int Identity(1,1),
    TaskName varchar(50) Primary Key NonClustered,
    AssignedEmployeeID int, --NOTE: assumes only 1 employee per task
    OtherStuff varchar(255)
)
CREATE CLUSTERED INDEX IX_TASKS_ID ON dbo.Tasks(TaskID)

Create Table TaskPrecedents
(
    TaskID int,
    PrecedentTaskID int,
    PrecedentType Char(2)   --Codes, you'll have to work these out
    Constraint pk_TaskPrecedents Primary Key (TaskID, PrecedentTaskID)
)
于 2009-06-02T20:09:34.853 に答える
0

データベースから始めて、そこから作業します。クラス構造を推奨するには、さらに情報が必要です。従業員用のオブジェクトが必要ですか？またはそれらはプロジェクトのプロパティになりますか？等..

DB 設計:

Projects
    ProjectID
    ProjectName...
    EmployeeID

Tasks
    TaskID
    ProjectID
    TaskName...
    EmployeeID

Employees
    EmployeeID
    EmployeeName...
于 2009-06-02T19:08:35.540 に答える