私は博士号を取得しています。 in cs-データベースの領域であるため、この答えはプログラマーの観点とは少し異なります。オリバー・ハナッピに関しては、代理キーでない場合、キーは変更される可能性があり、変更されることもあります。例えば。自然キーまたは複合キー。例えば。米国ではSSNを変更することができます。しかし、何年にもわたって多くのプログラマーは、これを変更不可能なキーと見なし、そのように使用していました。外部キーで構成される複合主キーを変更することは、はるかに一般的です。
三項関係のデータベースを扱っています。具体的には、3つのエンティティ（外部キーはそれぞれのテーブルの代理主キーです）。ただし、3番目のエンティティを変更するときに2つのエンティティ間の関係を維持するには、必須 交差テーブル（MSDNでは純粋な結合テーブルとも呼ばれます）の主キーの一部を変更します。これは有効な設計であり、三項関係の交差テーブルを削除し、それを2つの二項関係テーブル（独自の代理キーを持つ場合があります）に置き換えることによってのみ改善できます。 EFはこれをうまく処理します。この設計変更により、（多->多）->多またはParent1-Parent2->子-孫モデルが作成されます（明確でない場合は、以下の例をお読みください）。各リレーションシップは実際には1対多のリレーションシップであるため、エンティティフレームワークはこれで正常に機能します。しかし、DBの観点からはクレイジーなデザインです。理由の例を示しましょう。
コース、クラスルーム、インストラクターはクラス内で相互に関連付けられていると考えてください。クラスには、CourseID、ClassroomID、InstructorIDを外部キーとして含めることができ、3つすべてを含む複合主キーを含めることができます。明確で簡潔な3項モデル（3方向の関係）ですが、2項関係に分割することができます。これにより、2つの交差テーブルが得られます。代理キーを追加すると、次のようにEFが満たされます。
クラス（ SurrogateKeyClass 、 InstructorID 、 CourseID ）
ClassRoomUsed（ SurrogateKeyClassroomUsed 、 SurrogateKeyClass 、 ClassRoomID ）
この設計の問題は、同じコースとインストラクターを複数回関連付けることができることです。これは、以前のモデルでは回避できます。この問題を回避するために、2つのIDフィールドの一意性に関する制約をデータベースに追加できますが、最初に代理キーのみを処理しているのに、なぜこれを実行したいのでしょうか。しかし、この解決策は私が知る限り最もうまくいくでしょう。ただし、DBには不自然な一意の制約が必要なため、これは論理データベースの設計ではありません。
ただし、データベースを変更したくない場合、またはデータベースを変更できない場合は、2番目の解決策を参照してください。 ：交差点/関連付けテーブルはまさにそれであり、2つ以上のエンティティをリンクするリンクです。 1つが変更された場合は、関連付けを削除し、適切な外部キー（ナビゲーションプロパティ）を持つ新しい関連付けを再作成します。つまり、どの関係でも子エンティティを要求することは許可されませんが、それは非常に一般的です。
Entity Framework（将来）を使用すると、エレガントなDBモデルを設計できる人が、必要に応じて交差/関連付けテーブルのキーの一部を変更できるようになることをお勧めします。
無料の別の例：
学生、コース、学年協会を考えてみましょう。学生は、成績を介してコースに関連付けられます。通常、これは学生とコースの間の多対多の関連付けであり、関連付けテーブルにgradeと呼ばれる追加フィールドがあります（関連付けテーブルにはgradeなどのペイロードデータがあり、交差テーブルにはペイロードがなく、MSDNでは純粋な結合テーブルとして参照されます。 1か所でリース）：
Student（ StudentID 、....）
コース（ CourseID 、...）
取る（ StudentID 、 CourseID 、グレード）
誰かがドロップダウンからデータ入力エラーを起こし、生徒を間違ったクラスに入れた場合、後でドロップダウンを再度選択して別のコースを選択することにより、データ入力エラーを変更するようにします。バックグラウンドで、TakingテーブルからEFオブジェクトを削除し、グレードがある場合はそれを失うことなく再作成する必要があります。外部キーを変更するだけCourseID より良い選択肢のようです。これが不自然に思われる場合は、あなた自身の協会を考えてください。しかし、教授として、それは私にとって自然なことでした。
結論：一連の関係がある場合は、FKのカスケードや変更を許可しない方がよい場合がありますが、一般的なのベストプラクティスとして推奨されていない場合でも、必要な場合は合理的/論理的なシナリオが存在します。 / em> 。
この問題は、モデルのナビゲーションプロパティまたはキープロパティをそれぞれ変更するかどうかに応じて、次の例外で現れる可能性があります。
参照整合性制約違反が発生しました：参照整合性制約の一部である主キープロパティは、関連付けの主オブジェクトに設定されていない限り、依存オブジェクトが変更されていない場合は変更できません。主要なオブジェクトは追跡され、削除のマークが付けられていない必要があります。
プロパティ「X」はオブジェクトのキー情報の一部であり、変更できません。