Entity間のリレーション
概要
Entityには、スキーマ上のテーブル間のリレーションが、関連テーブルへのプロパティ(メソッド)として反映されます。 そのプロパティを利用して、ConditionBeanなどで検索された関連テーブルのデータを取得することができます。
リレーションを持つのは、DomainEntity のみです。CustomizeEntity は、SQLのフラットな構造に対応する Entity のため、リレーションを持ちません。
リレーションのタイプ
リレーションのタイプ(種類)と、それぞれの特徴です。これらは、Entity だけでなく、ConditionBean や Behavior など他のクラスにも通じる話です。また、ExampleDB の構造を把握しておくと一層理解がしやすくなるでしょう。
many-to-one (親テーブル)
- 例えば、会員を基点とした場合は？
- 会員ステータスが該当
- many-to-one であることの判定基準
- FK制約(or AdditionalForeignKey)で参照していること
- プロパティ名の特徴
- テーブル名がそのままキャメルケースとなったもの(例えば、memberStatus)。 但し、同じ関連テーブルへのリレーションが複数存在する場合は、プロパティ名の最後に "By[FKカラム名]" が付与される。
- 逆方向のリレーション
- 同時に、関連テーブル側には、基点テーブルへの one-to-many のリレーションが存在する
one-to-one
- 例えば、会員を基点とした場合は？
- 会員セキュリティ情報、会員退会情報が該当
- one-to-one であることの判定基準
- 基点テーブルを参照しているFKカラムに、PK制約(or AdditionalPrimaryKey)、もしくは、UQ制約(or AdditionalUniqueKey)が定義されていること
- プロパティ名の特徴
- many-to-one のプロパティ名の法則に加えて、プロパティ名の最後に "AsOne" が付与される(例えば、memberSecurityAsOne)。但し、逆方向のone-to-oneのリレーションのプロパティには付与されない。
- 逆方向のリレーション
- 関連テーブル側には、many-to-one と同じ仕様の基点テーブルへのリレーションが存在する。
- その他特徴
- FKの方向的には、one-to-many と同じ構造だが、実装上では many-to-one と(ほぼ)同じように扱うことができるため、DBFlute ではあまり子テーブルとは言わず、どちらかというと親テーブルという言葉にこのone-to-oneが含まれることが多い。
業務的one-to-one
- 例えば、会員を基点とした場合は？
- 会員住所情報が該当
- 業務的one-to-one であることの判定基準
- AdditionalForeignKeyで fixedCondition が利用されていること
- プロパティ名の特徴
- many-to-one のプロパティ名の法則に加えて、AdditionalForeignKeyの fixedSuffix がプロパティ名の最後にが付与される(例えば、memberAddressAsValid)。
- 逆方向のリレーション
- そもそも、one-to-manyとしてのリレーションが存在しているため(そちらで代替できるため)、 この業務的one-to-oneに対応する逆方向のリレーションは存在しない。
one-to-many (子テーブル)
- 例えば、会員を基点とした場合は？
- 購入、会員ログイン情報が該当
- one-to-many であることの判定基準
- 基点テーブルをFK制約(or AdditionalForeignKey)で参照していること。
- プロパティ名の特徴
- many-to-one のプロパティ名の法則に加えて、プロパティ名の最後に "List" が付与される(例えば、purchaseList)。
- 逆方向のリレーション
- 同時に、関連テーブル側には、基点テーブルへの many-to-one のリレーションが存在する
ユニーク制約を参照するFK制約
DBFluteでは、リレーションのDB上の実装は "主キー制約を参照するFK制約" が推奨されています。ユニーク制約を参照するFK制約のリレーションは、DBFluteでは基本的にサポートされません。
そのリレーションに関するJDBCのメタデータは取得されません(但し、DBMSによっては取得できる場合もあり得る：JDBCドライバの実装次第)。 additionalForeignKeyMap.dfprop にて手動で設定することで、Entity上のリレーションとして扱うことができますが、 完全なサポートは保証されません。SetupSelect, ExistsReferrer, LoadReferrer などの基本機能は利用できますが(@since 0.9.7.6)、より複雑な機能においてはその限りではありません。
それでも、"影響の少ない修正で対応できる範囲でサポートする" というスタンスになっていますので、もし、これに関する制限で困った場合は、フィードバックして相談されると良いでしょう。
