Foreign Key Mapping

Maps an association between objects to a foreign key reference between tables.

• オブジェクトの関連は親->子の参照で表される

• RDB上では子->親の外部キーで表される

  • さもないと、親が複数の子を集約する場合、第一正規形違反になる
• Foreign Key Mappingパターンは、オブジェクトの参照とRDBの外部キーとをマッピングする

How It Works

• 事態が複雑になるのは、コレクションを集約しており、更新がかかる場合

  • 例: アルバムとトラック

• 選択肢は3つ

  • delete/insert
  • back pointer
  • 差分

delete/insert

• メリット

  • 実装が簡単

• デメリット

  • Dependent Mappingである場合にしか適用できない

    • トラックがアルバム以外に所有されていないこと

• オブジェクトのリンクをimmutableにした場合はこれ以外の選択肢はない

  • 参照をすげ替えることができないため
  • シンプル

back pointer

• 子->親の参照を追加

  • 【補】RDBの外部キーには、親のIdentity Fieldを使用する

• メリット

  • 単純

• デメリット

  • オブジェクトモデルを変えてしまう

    • 本来不要な相互参照が追加される

差分

• 上記いずれも響かなければこれ

• 何との差分？

  • RDBの最新レコード

  • 最初に読み込んだデータ

    • RDBの再読込が不要な点が良い

• Optimistic Offline Lock利用時はRDBを再読み込みしなければならない

  • 【補】バージョンの照合が必要なため

• 新しいオブジェクトの取り回し

  • 2つの方法

    • キー(Identity Field)の有無で判別する

      • キーがないものは新しいオブジェクト

    • Unit Of Workで、オブジェクトの新規作成を一元管理する

      • クライアントにはRDBに挿入済のオブジェクトが返る
  • いずれの場合も、親のIDをFKに設定し、RDBに書き戻す必要がある点は同じ

• トラックがアルバムから取り除かれる場合、トラックのレコードに対する操作にはいくつかのケースがある

  • 他のアルバムに移動する

    • UPDATE FK更新

  • いずれのアルバムにも所属しない

    • UPDATE FKにnullを設定

  • 完全に削除される

    • DELETE

循環参照について

• Customer->Payments->Order->Customer->...みたいなやつ

• 対処

  • Lazy Load
  • Empty Object

When to Use It

• クラス間に関連がある場合ほぼ必ず使用する
• 多対多の場合は代わりにAssociation Table Mappingを使用する

英語

• a bevy of

  • 大量の