このトピックでは、EJB マッピングについて現在知られている制限の概要を説明します。
EJB マッピングの制限
- FLOAT データ型での SQL Server マッピングの問題: CMP Bean が SQL Server データベースにマップされている場合は、FLOAT 型のフィールドを REAL 型ではなく FLOAT 型の列にマップする必要があります。
- エンタープライズ Bean から外部キーおよび主キーへのマッピングのサポート: エンタープライズ Bean
をデータベース表にマップする場合は、外部キーおよび主キーに関連したいくつかの制限があります。
- 表に複数の列を含む複数の外部キーがある場合は、
両方の外部キーが 2 つの異なる EJB 関係へのマッピングに使用されていない限り、それらの外部キーを相互にオーバーラップすることはできません。
例えば、ForeignKey1 に ColumnA と ColumnB が含まれている場合、
ForeignKey2 は ColumnC と ColumnD を含むことができますが、ColumnB と ColumnC を含むことはできません。
ForeignKey2 に ColumnB と ColumnC が含まれていると、2 つの外部キーが相互にオーバーラップすることになります。
- 表に複数列の主キーが 1 つと、1 つ以上の外部キーがあって、外部キーが主キーの列を共用する場合、外部キーは、主キーと正確に同じ列を持つか、または完全に主キーの外部にある列を持っていなければなりません。
例えば、PrimaryKey1 に ColumnA と ColumnB が含まれている場合、ForeignKey1 は ColumnA と ColumnB または ColumnC と ColumnD を含むことができますが、ColumnB と ColumnC を含むことはできません。
複数の外部キーがある場合、外部キーはそれぞれこの要件を満たさなければなりません。
- 単一の外部キーが 2 つの異なる表を参照している場合、
EJB マッピング・ツールを使用して、ある Bean から別の Bean の単一の外部キーへ 1 対多対応 (1:M) 関係を複数マップすることはできません。外部キーはそれぞれの関係ごとに固有のものでなければなりません。
- 継承と 2 次表マッピング: マッピング継承へのルート・リーフ・アプローチを使用するか、複数の表との 2 次マップを使用する場合は、データベースから外部キー制約を除去して、参照保全性の順序付けの問題 (SQL ステートメントが不適切な順序で実行される) を回避してください。
- 1.1 CMP エンティティー Bean のオプティミスティック述部:
V5.0 より前のバージョンの
WebSphereR Studio Application Developer では、
オプティミスティック述部への EJB 1.1 CMP エンティティー Bean の属性の追加はサポートされていません。
しかし、V5.0 より前のバージョンを使用して開発した EJB アプリケーションのデプロイにワークベンチを使用し、オプティミスティック述部の属性のリストを組み込まない場合、使用可能な述部がすべて使用されます。
EJB 2.x CMP エンティティー Bean の処理はこれと異なります。述部として属性を 1 つも選択しないと、過剰修飾更新には何も追加されません。
- EJB を継承とマッピングする場合、階層内にあるすべての Bean のフィールドを 1 つのテーブルにすべてマッピングする、単一テーブル・マッピング戦略を使用することができます。各 Bean が固有のテーブルを持ち、該当する Bean に固有の属性を保管する、root-leaf 戦略も使用することができます。 また、一部の Bean は単一テーブルのように親テーブルに保管し、他の Bean は root-leaf のように独立したテーブルに保管する、混合戦略を使用することもできます。
混合戦略に沿って EJB 照会を使用する場合、次のルールに従ってください。
Bean が親テーブルにマッピングされている場合、その子孫はすべて (兄弟および兄弟の子孫) も同じ戦略に沿ってください。 例えば次の階層の場合、ChA1 を ChA と同じテーブルにマッピングすれば、ChA3、ChA2 および ChA4 も同じテーブルにマッピングしなくてはなりません。
