EFコードで最初に不要な外部キー列を生成するのはなぜですか？

Question

私は自動的に私のデータベーススキーマを作成するには、エンティティフレームワークのコード最初を使用していて、私のエンティティの一つは次のようになります。EFの私のデータベースを自動生成するとき

public class AssessmentsCaseStudies { 
    #region Persisted fields 
    [Required] 
    [Key, Column(Order=0)] 
    [ForeignKey("Assessment")] 
    public int AssessmentId { get; set; } 

    [Required] 
    [Key, Column(Order=1)] 
    [ForeignKey("CaseStudy")] 
    public int CaseStudyId { get; set; } 

    [Required] 
    public int Score { get; set; } 

    [ForeignKey("Follows")] 
    public int? FollowsCaseStudyId { get; set; } 
    #endregion 

    #region Navigation properties 
    public virtual Assessment Assessment { get; set; } 
    public virtual CaseStudy CaseStudy { get; set; } 
    public virtual CaseStudy Follows { get; set; } 
    #endregion 
} 

、それは次の列を持つテーブルを作成します：

これはCaseStudy_CaseStudyIdの列以外はすべて問題ありません。なぜそれが生成されたのですか？それはなんのためですか？どうやってそれを止めることができますか？私の疑惑は、CaseStudyのとCaseStudyIdの列を自動的に一致させることができなくなるため、そのナビゲーションプロパティ用に2つの列をリンクする独自の列を作成するということです。

Answer 1

を

何らかの理由で、SlaumaのInverseProperty属性の提案が機能しませんでした。それが生成されています追加、移行コードです一度

modelBuilder.Entity<AssessmentsCaseStudies>() 
    .HasRequired(acs => acs.CaseStudy) 
    .WithMany(cs => cs.AssessmentsCaseStudies) 
    .HasForeignKey(acs => acs.CaseStudyId) 
    .WillCascadeOnDelete(false); 

modelBuilder.Entity<AssessmentsCaseStudies>() 
    .HasOptional(acs => acs.Follows) 
    .WithMany() // No reverse navigation property 
    .HasForeignKey(acs => acs.FollowsCaseStudy) 
    .WillCascadeOnDelete(false); 

：どのような仕事をしたことは私には私のデータベースコンテキストのOnModelCreating方法で流暢APIを介して、AssessmentsCaseStudiesで2つのCaseStudyナビゲーションプロパティ、およびCaseStudyエンティティ間の関係を規定してI Add-Migrationは、もはやCaseStudy_CaseStudyId列を追加しようとせず、適切な外部キーの関係で、FollowsCaseStudyId列が追加されました。

Answer 2

あなたCaseStudyエンティティであなたのAssessmentsCaseStudiesエンティティにおけるタイプCaseStudyのナビゲーションプロパティとAssessmentsCaseStudiesコレクションを持っているのでEFは、このコレクションが参照する2つのCaseStudyナビゲーションプロパティのかを決定することはできません。どちらも可能であり、どちらのオプションも有効ではあるが異なるエンティティモデルとデータベーススキーマになります。 EF規則は、実際に関係を作成することです、このようなあいまいな状況で

、CaseStudyであなたのコレクションが2つのCaseStudyナビゲーションプロパティのいずれかを指すが、（露出され、「目に見えない」ではなく）三分の一を持っていない、すなわち、エンドポイントはAssessmentsCaseStudiesです。この3番目の関係は、データベースで表示される3番目の外部キー（アンダースコア付きの外部キー）の理由です。

この問題を修正して規約を変更するには、[InverseProperty]属性を適用して、CaseStudyナビゲーションを指定することができます（アンダースコアは常にマッピング規則によって何か起こっていることを強く示しています）プロパティAssessmentsCaseStudiesコレクションが属する：

[InverseProperty("AssessmentsCaseStudies")] // the collection in CaseStudy entity 
public virtual CaseStudy CaseStudy { get; set; } 

あなたはまた（あるいは、あなたは両方を必要としない）、コレクション側の属性を置くことができます。

[InverseProperty("CaseStudy")] // the CaseStudy property in AssessmentsCaseStudies entity 
public virtual ICollection<AssessmentsCaseStudies> AssessmentsCaseStudies { get; set; } 

Answer 3

ここで解決策を探している人は、以前の回答を試してまだ余分な外部キー列がある場合は、意図していないPOCOクラスをさらに詳しく定義したプロパティを探してくださいDBフィールドにマップします。複雑なgetアクセサの場合のようにコードブロックが含まれていても、Entity Frameworkはそれらをデータベースにマッピングしようとします。これにより、プロパティがエンティティを返す場合に、余分な外部キー列が発生する可能性があります。安全のために、[NotMapped]属性でそのようなプロパティを装飾するか、またはメソッドに変換してください。