Associationは、関連する属性に基づいて、2つのエンティティ・オブジェクト間の関係を定義するビジネス・コンポーネントです。この関係には、1対1、1対多または多対多があります。エンティティ・オブジェクトは、Associationを利用して永続的な参照を行い、他のエンティティ・オブジェクトのデータにアクセスできます。
ビジネス・コンポーネントのウィザードでは、データベースにすでに定義されているデータベース制約に基づいて、Associationが自動的に作成されます。定義したAssociationに基づいてデータベース制約を作成することもできます。
同じ関係を定義するためにAssociationとデータベース制約の両方を使用する必要はありません。エンティティ・オブジェクトが他のエンティティ・オブジェクトのデータにアクセスするために必要なのは、Associationのみです。対応する制約が、外部キー関係またはオブジェクトREFによってデータベースに指定されているかどうかは関係ありません。
たとえば、親の作成前に子を挿入できるようにする場合、Associationは必要ですがデータベース制約は不要です。
組織の部門と従業員との間に1対多の関係があるとします。Departmentエンティティ・オブジェクトは、Employeesエンティティ・オブジェクトにDepartmentId属性を使用して関連付けられます(Department.DepartmentId = Employees.
DepartmentId
)。次の図は、デフォルトの名前がEmpDeptFkAssocというAssociationが、JDeveloperの構造ペインにどのように表示されるかを表しています。
主キーを含む関連元はDepartmentsエンティティ・オブジェクトです。外部キーを含む関連先はEmployeesエンティティ・オブジェクトです。
Associationは、AssociationウィザードおよびAssociationエディタで定義および編集できます。
既存の表の外部キー制約に基づき、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ、ビジネス・コンポーネント・プロジェクト・ウィザードまたはビジネス・コンポーネント・パッケージ・ウィザードを使用して、デフォルトのAssociationを生成することもできます(逆方向生成)。
オプションとして、AssociationウィザードおよびAssociationエディタで定義したAssociationに基づいて表に外部キー制約を追加することもできます(順方向生成)。
ビジネス・コンポーネントを生成した後でデータベース制約を追加する場合は、次の方法で対応するAssociationを自動的に作成できます。
エンティティ・オブジェクト内のオプションのAssociationアクセッサにより、Associationの他方のデータにアクセスできます。コードでは、Associationをいずれの方向にも横断できます。たとえば、Departmentエンティティ・オブジェクト内でgetAttribute("Employees")
、または生成されたアクセッサ・メソッドがある場合はgetEmployees()
をコールし、現在の部門に所属している従業員を表すEmployeesエンティティ・オブジェクトの行セットを取得します。同様に、Employeesエンティティ・オブジェクトから、getDepartment()
をコールして従業員が所属する部門を取得します。このデータはキャッシュされるため、初めてメソッドをコールしたときはデータベース問合せが実行されますが、その後はキャッシュされたデータが返され、処理時間が短縮されます。
エンティティ・オブジェクトは、複数のアクセッサを連続してコールし、複数のAssociationを横断して必要なデータを取得できます。アクセッサから返されたイテレータは、使用後に閉じ、システム上に必要以上に多くの行セットが存在しないようにしてください。
コンポジット関係は、関連元エンティティ・オブジェクトが関連先エンティティ・オブジェクトを所有していることを意味します。つまり、所有側であるエンティティ・オブジェクトがまず存在していなければ、関連先エンティティ・オブジェクトを作成できません。
関連元エンティティ・オブジェクト(親)は、1つ以上の関連先オブジェクト(子)のコンテナとなります。関連先エンティティ・オブジェクトが変更されると、関連元エンティティ・オブジェクトには、検証が必要というマークが付けられます。
子エンティティ・オブジェクトは、親がないと作成できません。子エンティティ・オブジェクトを作成すると、フレームワークによって、親の主キー値と一致する外部キー値が割り当てられます。
挿入、更新および削除の場合、子エンティティ・オブジェクトは親エンティティ・オブジェクトの一部とみなされます。有効な子エンティティ・オブジェクトを持つ親エンティティ・オブジェクトは、これに含まれるエンティティ・オブジェクトがすべて削除されるまで、削除できません。子エンティティ・オブジェクトを変更しようとすると、ビジネス・ロジック層は親エンティティ・オブジェクトをロックします。最上位の親エンティティ・オブジェクトが正常にロックされないかぎり、子エンティティ・オブジェクトは変更できません。たとえば、明細品目が含まれる注文の場合、ユーザーが明細品目の変更を開始すると、他のユーザーが注文やその品目を変更できないように注文全体がロックされます。
コンポジットが定義されている場合には、親クラスのvalidateEntityメソッドに、複数の子に関連するビジネス・ルールを実行するコードを追加できます。子でデータが変更されると、子に関するすべての規則が実行されるように、親に再検証が必要というマークが付けられます。たとえば、Orderエンティティ・オブジェクトのvalidateEntityメソッドにコードを追加して、注文の品目の合計が顧客のクレジット・カード限度額を超えないようにできます。
2つのエンティティ・オブジェクトの間に所有関係があるかどうかを判断するには、次の2点について考えます。
関連先エンティティ・オブジェクトは関連元エンティティ・オブジェクトに依存せず存在できますか。
存在できる場合、関連元と関連先の関係はAssociationです。
存在できない場合、関連元と関連先の関係はコンポジットです。
たとえば、明細品目は注文に依存せずに存在できるでしょうか。存在できないため、この関係はコンポジットです。
関連元を削除するときに、関連付けられている関連先も削除しますか。
削除する場合、この関係はコンポジットです。
削除しない場合、この関係はAssociationです。
たとえば、注文を削除する場合、その明細品目もすべて削除する必要がありますか。削除する必要があるため、注文と明細品目の間の関係はコンポジットです。部門を削除する場合、その部門のすべての従業員も削除しますか。削除しないため、この関係はAssociationです。
逆方向生成で、データベースの参照整合性制約にON DELETE CASCADEオプションが定義されている場合、Business Components for Javaでは自動的にコンポジットを作成します。
プログラムで必要なAssociationを決定するには、UMLオブジェクト指向モデリングの技法を使用できます。ビジネス・コンポーネントのAssociationは、UMLのAssociationの概念を実装したものです。
関連項目
エンティティ・オブジェクトおよびAssociationの作成方法
Associationウィザード - 「サマリー」ページ