3

既存の SQL Server インフラストラクチャに EDM をセットアップしようとしていますが、問題が発生しました。

EDM は、PK-FK 関係を複合外部キーに解決しません。

私のDBテーブル構造は次のようになります（無実を保護するために名前が変更されています）：

  • PerID (PK) という INT 列を含む PERSONS テーブルがあります。
  • OffID (PK) という INT 列を含む OFFICE テーブルがあります。
  • OFFICEPERSONS というテーブルを使用してこれらのテーブルを結合し、PERSONS と OFFICE の間に多対多の関係を作成します。このテーブルには、PerID と OffID の 2 つの INT 列があり、これらが一緒になって複合主キーを形成します。
  • LocID と OffID の 2 つの INT 列を含む OFFICELOCATION というテーブルがあります。これら 2 つの列は複合主キーを構成します。さらに、OffID は OFFICE テーブルの FK でもあります。
  • 最後に、OFFICEPERSONSLOCATION というテーブルがあります。このテーブルには、PerID、OffID、および LocID の 3 つの INT 列があります。3 つの列はすべて複合主キーを構成します。LocID と OffID は OFFICELOCATION に FK 関係を提供し、OffID と PerID は OFFICEPERSONS に FK 関係を提供します。

ここまで私と？うまくいけば、私はまだあなたを失っていません。すべてが完了したら、私の構造は次のようになります。 データベース構造図

この構造は、SQL Server でうまく機能します。EDMで？それほどでもない。OFFICEPERSONSLOCATION と OFFICEPERSONS の間の関係を構築することはできません。次のエラーが表示されます。

エラー 6037: 外部キー制約 'FK_OFFICEPERSONSLOCATION_OFFICEPERSONS' がストレージ モデルから省略されています。テーブル 'Model.Store.OFFICEPERSONSLOCATION' の列 'OffID' は、複数のリレーションシップに参加している外部キーです。データの不整合が発生する可能性があるため、1 対 1 のエンティティ モデルは検証されません。

は？データ不整合?!? どのように？

エンティティ フレームワークにこれを認識させるにはどうすればよいですか?

4

1 に答える 1

2

これはエンティティ フレームワークの問題であり、愚かな問題であることに同意します。UPDATE CASCADE を「アクションなし」にしたとしても、不整合を作成できるわけではありませんが、何とかできると主張しています。

いずれにせよ、この状況で、複合キーの代わりに代理キーを使用する場合は、ID 参照を変更する唯一の場所がメイン テーブルにあるため、これを回避できます。

この場合、OffID は「一貫性がない」可能性がありますが、OFFICEPERSONS テーブルと OFFICELOCATIONS テーブルで ID を使用する (したがって、OFFICEPERSONSLOCATION で参照する) ことにより、OffId をプライマリ テーブルで管理する必要があります。

于 2014-02-13T21:23:30.943 に答える