2017-04-20 18 views
-1

私は次の場合があります: エンティティ 'Master_Entity'があります。このエンティティには、名前、タイプ、期間などのプロパティがあります。他の2つのタイプのエンティティ 'Entity'と 'Sub-Entity'があります。 「Master_Entity」と同じものがあります(これらは全く同じプロパティを持っています)。データベース設計ソリューション

最後に 'Master_Entity'は 'Entity'のコレクションを保持し、 'Entity'は 'Sub-Entity'のコレクションを保持する必要があります。 「Entity」タイプのレコードは、異なる「Master_Entity」(「Sub-Entity」と同じ)の一部である可能性がありますが、たとえば持続時間の値が異なる場合があります。どのようにそのようなモジュール性を達成できますか?

ここで私は思いつきましたが、それはかなり仕事をしていません。あなたは私にこれを手伝ってもらえますか?

enter image description here

編集:作業トラッカーのいくつかの並べ替えとしてこれを想像してみてください。たとえば、「PHPアプリケーションを作成する」(マスターエンティティ)があります。このエンティティは、このジョブを終了するのにかかる時間の長さを含みます。さらに、エンティティ 'Writing Code'(エンティティ)を含み、このジョブに固有のdurationプロパティを持つ 'Writing Http Client'(サブエンティティ)に分割することができます。

他の側では、アプリケーションのコンテキストのために同じ 'Writing Code'エンティティを含むが、持続時間が異なる 'Java Appを作成する'(マスターエンティティ)がある可能性がありますあなたは建っています。

「書き込みコード」という単一のレコードが必要ですが、割り当てられているすべてのジョブごとに異なる持続時間値を設定する必要があります。タイプ 'Entity'のレコードを最小限に複製することで、それをどのように達成できますか?

+2

"*でもそれはあまり仕事をしていない*"とはどういう意味ですか?あなたの質問は何ですか? –

+0

サンプルデータと期待される結果は、おそらくあなたの問題の理解に役立ちます。そして、その恐ろしいIDを識別子の名前として使うのを止めて、あなたのダイアグラムからpk/FKの関係を使って何を使っているのか分かりません。名前としてのIDは、非常に悪いSQLの反パターンです。 – HLGEM

+1

@HLGEM IDは、すべてのFKがTargetTableNameIDである限り、PKの優れた列名です。 –

答えて

0

これは、これらの3つのテーブルのようなものがあなたのために働くように聞こえる:

Entity 
* Id 
* Name 
* Type 

EntityGroup 
* Id 
* Name 
* ParentEntityGroupId 
* ParentEntityId  

EntityRelationship 
* Id 
* EntityId 
* ParentEntityId 
* EntityGroupId 

この構造により、あなたはエンティティグループのメンバー、または他のエンティティのソロ子も持つことができます。また、グループをエンティティの子、または他のグループの子にすることもできます。あなたのデータの詳細を知らなくても、あなたが必要とするものを知るのは難しいですが、これはあなたを始めるはずです。

+0

お読みになることをお勧めします。このアプローチを試してみる –

0

あなたが言ったことから、あなたはEAVがまったく必要ないと思われます。なぜなら、あなたは異なる値の各項目に対して異なるプロパティを持っていないからです。そして、あなたはそれを使用すべきではありません。

必要なものは、ルックアップテーブルの組み合わせと、次に作品の実際の追跡履歴に対応するテーブルです。 これは時間が重要なデータであるためです。プロジェクトが作成された時点でのタスクは、2年後にそのタスクグループに関連付けられたタスクとは大きく異なる場合がありますが、作成時にタスクを記録する必要があります)。これは非正規化ではなく、時間内にデータの画像を作成していることに注意してください。本当の持続時間は、常にタスクにこれまでにないプロジェクトに行く。タスクでは、出発点として使用する推奨期間を設定することができます。私はテクニカルハードウェア関連のプロジェクトの販売提案を作成するためのデータベースを設計するために、同様の設計を使用しました。実際のキーは、ポイントデータとして保存する必要があるデータと、最終プロジェクトデータを作成するために使用される参照データを認識することです。誰かが「Java Appの作成」グループに新しいタスクを追加した場合、既に完了したプロジェクトや作業中のプロジェクト、新しいプロジェクトの詳細は変更したくありません。

だから、必要があります。もちろん

Task group 
    Task Group ID 
    Task Group Name 

Task 
    TaskID 
    Task Name 
    SuggestedDuration (can be null if you have tasks that are always different 
        but filled in for tasks that usually have a similar duration) 

Task_Taskgroup 
    TaskID 
    TaskGroupID 

Project 
    ProjectID 
    ProjectName 
    TaskGroupID 

ProjectTask (should be filled in automatically when the task group is 
      chosen for the project) 
    ProjectID 
    Task ID 
    EstimatedDuration (fills in the default value, but can be changed 
         by the person creating the work project) 
    ActualDuration (Field in after the task is done, can be used by an 
        analyst to create more reflective task default duration values) 

をこれらのテーブルのそれぞれは、必要に応じて他のフィールドを有することができます。