| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
TopLinkでは、オブジェクトの表現とデータ・ソースに固有の表現との間でデータを変換できます。この変換はマッピングと呼ばれ、TopLinkプロジェクトの中核をなすものです。
1つのマッピングは、ドメイン・オブジェクトの単一のデータ・メンバーに対応します。マッピングにより、オブジェクトのデータ・メンバーがそのデータ・ソースの表現と関連付けられ、オブジェクトとデータ・ソースの間で双方向での変換を実行する手段が定義されます。
この章の内容は次のとおりです。
表17-1では、TopLinkがサポートするマッピングのタイプについて説明します。
表17-1 TopLinkのマッピングのタイプ
| タイプ | 説明 | Oracle JDeveloper |
TopLink Workbench | Java |
|---|---|---|---|---|
|
リレーショナル（17.4項「リレーショナル・マッピング」を参照） |
オブジェクトのデータ・メンバー・タイプを、サポートされているリレーショナル・データベースの対応するリレーショナル・データベース（SQL）のデータ・ソース表現に変換するマッピング。リレーショナル・マッピングを使用すると、オブジェクト・モデルをリレーショナル・データ・モデルにマップできます。 |
 |
|
|
|
オブジェクト・リレーショナル・データ・タイプ（17.5項「オブジェクト・リレーショナル・データ・タイプ・マッピング」を参照） |
特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データ・タイプ・データベースでの格納用に最適化された構造化データ・ソース表現に変換するマッピング。オブジェクト・リレーショナル・データ・タイプ・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・データ・タイプ・データ・モデルにマップできます。 |
|
|
|
|
EIS（17.7項「EISマッピング」を参照） |
オブジェクトのデータ・メンバーを、オブジェクトのディスクリプタで定義されたEISレコード形式に変換するマッピング。 |
|
|
|
|
XML（17.6項「XMLマッピング」を参照） |
オブジェクトのデータ・メンバーを、構造がXMLスキーマ・ドキュメント（XSD）により定義されているXML文書のXML要素に変換するマッピング。 |
|
|
|
詳細は、次を参照してください。
この項では、次の内容を含む、TopLinkマッピングに固有の概念について説明します。
マッピング・アーキテクチャ（リレーショナルおよび非リレーショナル・マッピングに適用）
マッピングの例（リレーショナルおよび非リレーショナル・マッピングに適用）
JPA自動マッピング（リレーショナル・マッピングに適用）
開発時にTopLink Workbenchを使用した自動マッピング（リレーショナルおよび非リレーショナル・マッピングに適用）
実行時にOC4Jを使用するEJB 2.n CMPプロジェクトでのデフォルト・マッピング（リレーショナル・マッピングに適用）
開発時のJAXBプロジェクト生成（XMLマッピングに適用）
インダイレクション（遅延ロード）（リレーショナル・マッピングに適用）
メソッド・アクセッサおよび属性アクセッサ（リレーショナルおよび非リレーショナル・マッピングに適用）
シリアライズ・オブジェクト・コンバータ（リレーショナルおよび非リレーショナル・マッピングに適用）
タイプ変換コンバータ（リレーショナルおよび非リレーショナル・マッピングに適用）
オブジェクト・タイプ・コンバータ（XMLマッピングに適用）
シンプル・タイプ・トランスレータ（XMLマッピングに適用）
トランスフォーメーション・マッピング（リレーショナルおよび非リレーショナル・マッピングに適用）
マッピングおよびXPath（XMLマッピングに適用）
マッピングとxsd:listおよびxsd:unionタイプ（XMLマッピングに適用）
マッピングおよびjaxb:classカスタマイズ（XMLマッピングに適用）
マッピングおよびJAXB型保証列挙（XMLマッピングに適用）
マッピングを定義するには、次のコンポーネントを利用します。
オブジェクトのデータを格納するデータ・ソース（リレーショナル・データベース表またはスキーマ定義のXML要素など）に固有のデータ表現
特定オブジェクト・クラスのディスクリプタ
マップするオブジェクト・クラス
|
注意: マッピングは、プロジェクトの永続性の有無にかかわりなく同じです。 |
標準的なTopLinkマッピングの例については、17.2.2項「マッピングの例」を参照してください。
TopLinkプロジェクトで定義するデータ・ソースのタイプにより、使用できるマッピングのタイプおよびその構成方法が決まります。永続プロジェクトでは、マッピングを使用してデータ・ソースを永続させます。永続ではないプロジェクトでは、オブジェクト形式とその他の一部のデータ表現（XMLなど）の間で単に変換を行うためにマッピングを使用します。データ・ソースおよびプロジェクト・タイプの詳細は、15.1項「TopLinkプロジェクト・タイプ」を参照してください。
ディスクリプタは、特定のドメイン・オブジェクトを表します。つまり、オブジェクトのクラスを示します。ディスクリプタはマッピングを所有します。つまり、メモリーで永続させるまたは変換するクラスのデータ・メンバーのそれぞれに1つのマッピングがあります。
|
注意: 永続性はディスクリプタ・レベルで適用できます。 |
ディスクリプタの詳細は、第16章「ディスクリプタの概要」を参照してください。
TopLinkはマッピングを提供して、多種多様なデータ・タイプおよびデータ表現を処理します。詳細は、17.1項「マッピングのタイプ」を参照してください。
すべてのマッピングは、oracle.toplink.mappings.DatabaseMappingクラスのサブクラスです。マッピングAPIの詳細は、17.3項「マッピングAPI」を参照してください。
TopLinkでは、より複雑なマッピングをサポートしますが、ほとんどのTopLinkのクラスは、クラスで使用可能な情報のタイプを定義する1つのデータベース表またはXML要素にマップされます。特定のクラスからインスタンス化された各オブジェクトは、一意にオブジェクトを識別する識別子（主キー）を付加して、オブジェクトの属性を構成する1つの行にマップされます。
図17-1は、最も単純なデータベース・マッピングの例を示します。
データベースのTable_Xは、Class_Xを表します。
Object_X1およびObject_X2は、Class_Xのインスタンスです。
Table_Xの各行は、Object_X1およびObject_X2に加えて、Class_Xのその他のインスタンスも表します。
TopLinkには、図17-1に示した単純なマッピングから複雑なマッピングまで、これらのマッピングを作成するためのツールが用意されています。
その他のリレーショナル・マッピングの例については、図27-1「フィールドへ直接マッピング」を参照してください。
その他のリレーショナルではないマッピングの例については、図53-34「XMLトランスフォーメーション・マッピング」を参照してください。
通常は、手動でOracle JDeveloper TopLinkエディタまたはTopLink Workbenchを使用して、クラス対クラスおよびデータ・メンバー対データ・メンバー単位でマッピングを定義します（120.2項「開発時におけるマッピングの手動作成」を参照）。
また、次を利用することも可能です。
JPAプロジェクトで自動マッピングを構成する際に必要となるのは、永続性クラスに@Entityという注釈を付けること、および@Idを使用してそれらの主キーを定義すること（またはorm.xmlでエンティティのリストおよびそれらの主キー・フィールドを定義すること）のみです。これにより、マップされていないプロパティはすべてEclipseLink JPA永続性プロバイダによって自動的にマップされます。また、目的のデータベース表が自動的に作成または置換されるように、persistence.xmlのプロパティを構成することも可能です。詳細は、『EclipseLink Developer's Guide』の「Introduction to EclipseLink JPA」（http://wiki.eclipse.org/Introduction_to_EclipseLink_JPA_%28ELUG%29）を参照してください。
Oracle JDeveloper TopLinkエディタの「自動マップ」機能を使用して、プロジェクトのすべてのクラスおよびデータ・メンバーにデフォルトのマッピングを自動的に定義できます（120.3項「開発時におけるマッピングの自動作成」を参照）。
TopLink Workbenchの「自動マップ」機能を使用して、プロジェクトのすべてのクラスおよびデータ・メンバーにデフォルトのマッピングを自動的に定義できます（120.3項「開発時におけるマッピングの自動作成」を参照）。
TopLink Workbenchの自動マッピングは、すべてのプロジェクト・タイプに使用できますが、プロジェクト・モデルおよびデータベース・スキーマの両方が定義済であることが前提です。
デフォルト・マッピングとは、リレーショナルの永続フレームワークの用語で、フレームワークにオブジェクトのディスクリプタ・メタデータ（マッピング、ログイン・データ、データベース・プラットフォーム、ロックおよび外部キーなどが含まれます）を自動生成させることを指します。
|
注意: デフォルト・マッピングは、リレーショナル・プロジェクトのみに適用できます。 |
TopLinkでは、必要に応じてエンティティに関連付けられた表の作成、または削除および作成をデプロイ時に実行できます。このことは、TopLinkが最小の要件、つまり準拠した1つのEARファイルおよび1つの有効なデータ・ソースで、デプロイ・プロセス全体を処理できること意味します。これにより、アプリケーションをデプロイする前に、表を作成しマッピングを指定する必要がなくなります。
TopLinkのデフォルト・マッピングは、次の機能をサポートします。
標準CMP（つまり、依存オブジェクトではない）フィールドのための、フィールドへ直接マッピングのサポート
依存オブジェクトのためのシリアライズ・オブジェクト・マッピングのサポート
CMRフィールドのための1対1、1対多および多対多マッピングのサポート
自己参照型の単方向リレーションシップ・マッピングおよび双方向リレーションシップ・マッピング（27.2.1項「方向性」を参照）
エンティティごとのオプティミスティック・バージョン・ロック
表の自動削除および作成、プラットフォーム固有のサポート・タイプ、デフォルトのサイズとサブサイズおよびデータベース予約キー
finderおよびejbSelectなどのEJB QL（EJB問合せ言語）問合せ
不明の主キー・クラスの大/小文字（主キー・クラス・タイプjava.lang.Object.class）
デフォルト・マッピングは、永続性マネージャとしてTopLinkを使用するために構成されたOC4Jにデプロイされる、CMPリレーショナル・プロジェクトに使用できます。この構成では、EJBコンテナは、永続性マネージャが必要とするエンティティBeanディスクリプタのデータを（ejb-jar.xmlから）提供し、永続性ディスクリプタ・ファイルを生成します。
toplink-ejb-jar.xmlディスクリプタ・ファイルが存在しない場合、OC4Jの永続性マネージャとして機能するTopLinkにより、デプロイ時にすべてのCMPプロジェクトに対してデフォルトの永続性ディスクリプタ・ファイルが生成されます。この場合、TopLinkではデフォルト・マッピングおよびオプションとして、自動表生成が適用されます。生成されたディスクリプタ・ファイルの内容は次のとおりです。
エンティティCMPおよびCMRフィールドごとのマッピング
オプティミスティック・ロック、外部キー、ターゲット外部キーおよびリレーション表
リレーションシップ用透過インダイレクション（遅延ロード）
データベース・ログインおよびプラットフォーム・メタデータ
toplink-ejb-jar.xmlディスクリプタ・ファイルが存在し、orion-ejb-jar.xmlファイルで指定されている場合、TopLinkでは、デフォルト・マッピングは適用されません。つまり、TopLinkでは、toplink-ejb-jar.xmlファイルで指定されたマッピングを順守します。この場合、自動表生成を構成できます。
詳細は、9.9.1.3項「default-mappingのプロパティの構成」を参照してください。
JAXBでは、XML文書とJavaオブジェクトの間で双方向の自動マッピングを許可するAPIとツールが提供されます。JAXBコンパイラでは、提供されるDocument Type Definition（DTD）とスキーマ定義に基づいてすべてのJavaクラスおよびマッピングが生成されます。
JAXBに関する詳細は、http://java.sun.com/developer/technicalArticles/xml/jaxb/index.htmlの「Architecture for XML Binding (JAXB): A Primer」を参照してください。
XMLプロジェクトの詳細は、第47章「XMLプロジェクトの概要」を参照してください。
XMLマッピングの詳細は、第53章「XMLマッピングの概要」を参照してください。
デフォルトでは、TopLinkで永続オブジェクトを取得すると、それによって参照先の依存オブジェクトがすべて取得されます。インダイレクション（遅延読取り、遅延ロードおよびJust-In-Time読取りとしても知られている）をリレーションシップ・マッピングでマップされた属性に構成すると、TopLinkでは、参照されたオブジェクトのプレースホルダとしてインダイレクション・オブジェクトが使用されます。つまり、TopLinkでは、当該の指定属性にアクセスするまで、依存オブジェクトの読取りは遅延されます。これにより、特にアプリケーションが取得したオブジェクトのコンテンツのみを必要とし、そのオブジェクトに関連するオブジェクトのコンテンツは必要としない場合に、パフォーマンスの大幅な向上が見られます。
すべてのリレーションシップ・マッピングに対してインダイレクションを使用することをお薦めします。これにより、データ・ソースへのアクセスを最適化できるだけでなく、作業ユニット処理、キャッシュ・アクセスおよび同時実行性のTopLinkによる最適化が可能になります。
|
注意: インダイレクションの使用は、双方向リレーションシップを適切に維持する場合に特に重要です（2.14.3.4項「双方向リレーションシップの維持」を参照）。この場合、インダイレクションを使用する必要があります。コレクションを操作する場合は、透過インダイレクションを使用する必要があります（17.2.4.2項「透過インダイレクト・コンテナ・インダイレクション」を参照）。 |
図17-2は、インダイレクションの例を示します。インダイレクションを使用しない場合、Orderオブジェクトの読取りにより、LineItemオブジェクトの依存コレクションも読み取ります。インダイレクションを使用すると、Orderオブジェクトの読取りでは、LineItemオブジェクトの依存コレクションは読み取られません。つまり、lineItems属性はインダイレクション・オブジェクトを参照します。他の属性（customerIdなど）にアクセスできますが、lineItems属性にアクセスした場合は、TopLinkでは依存LineItemオブジェクトのみが読み取られます。
TopLinkでは、次のインダイレクション・タイプをサポートします。
CMPでインダイレクションを使用する場合、使用するEJBのバージョンおよびアプリケーション・サーバーが、インダイレクションの構成方法および適用するインダイレクションのタイプの決定に影響します（17.2.4.6項「インダイレクションおよびEJB 2.n CMP」を参照）。
アプリケーションのシリアライズ対象となるオブジェクトにインダイレクションを使用する場合、デシリアライズ時にトリガーされないインダイレクション・オブジェクトの影響を検討する必要があります（17.2.4.7項「インダイレクション、シリアライズおよびデタッチ」を参照）。
インダイレクションの構成の詳細は、121.3項「インダイレクションの構成（遅延ロード）」を参照してください。
インダイレクションを使用する永続クラスでは、リレーションシップ属性をValueHolder属性に置き換える必要があります。ValueHolderは、ValueHolderなど、ValueHolderInterfaceインタフェースを実装するクラスのインスタンスです。このオブジェクトには、置き換えられるオブジェクトをデータベースから取得するために必要な情報が格納されます。アプリケーションがValueHolderにアクセスしないと、置き換えられたオブジェクトはデータベースから読み取られません。
ValueHolderが置き換えるオブジェクトを取得するには、ValueHolderInterfaceのgetValueおよびsetValueメソッドを使用します。これらのメソッドを使用する便利な方法としては、次の例で示すように、ValueHolderInterfaceのgetValueおよびsetValueメソッドを、getおよびsetメソッド内で非表示にする方法があります。
図17-3に、データベースから読み取られるEmployeeオブジェクトを示します。Addressオブジェクトは読み取られず、アクセスするまで作成されません。
図17-4に示すとおり、最初のアドレスへのアクセス時に、ValueHolderはAddressオブジェクトを読み取り、それを返します。
図17-5で示すように、アドレスに対する後続のリクエストではデータベースにアクセスしません。
メソッド・アクセス（121.6項「マッピング・レベルでのメソッドまたは直接フィールド・アクセスの構成」を参照）を使用している場合、マッピングで指定されたgetメソッドおよびsetメソッドは、ValueHolderが参照しているオブジェクトではなく、ValueHolderInterfaceのインスタンスにアクセスする必要があります。アプリケーションがこれらのgetterおよびsetterを使用することはありませんが、ValueHolderの使用を隠すgetterおよびsetterを使用します。詳細は、121.3.2.2項「ValueHolderインダイレクションとメソッド・アクセスの同時構成」を参照してください。
ウィービング用に構成したJPAエンティティまたはPOJOクラスの場合、TopLinkでは、1対1マッピングのValueHolderインダイレクションのウィービングが実行されます。アプリケーションにコレクション・マッピング（1対多または多対多）が含まれている場合にTopLinkで変更追跡に対するウィービングが実行されるようにするには、すべてのコレクション・マッピングに対し、透過インダイレクト・コンテナ・インダイレクションのみが使用されるように構成する必要があります（コレクション・マッピングは、即時ロードやValueHolderインダイレクションが使用されるようには構成できません）。
透過インダイレクト・コンテナ（121.14項「コンテナ・ポリシーの構成」を参照）・インダイレクションを使用すると、次のいずれかの関連オブジェクトのコレクションを保持する永続クラスの任意のリレーションシップ属性を宣言できます。
java.util.Collection
java.util.Hastable
java.util.List
java.util.Map
java.util.Set
java.util.Vector
TopLinkでは、適切なインタフェースを実装し、関連オブジェクトのJust-in-Time方式による読取りも実行するインダイレクション・オブジェクトが使用されます。透過インダイレクションを使用する場合、属性をValueHolderInterfaceとして宣言する必要はありません。
新しく作成されたコレクション・マッピングでは、属性がValueHolderInterfaceでない場合、デフォルトで透過インダイレクションを使用します。
ウィービング用に構成したJPAエンティティまたはPOJOクラスの場合、TopLinkでは、1対1マッピングのValueHolderインダイレクションのウィービングが実行されます。アプリケーションにコレクション・マッピング（1対多または多対多）が含まれている場合にTopLinkで変更追跡に対するウィービングが実行されるようにするには、すべてのコレクション・マッピングに対し、透過インダイレクト・コンテナ・インダイレクションのみが使用されるように構成する必要があります（コレクション・マッピングは、即時ロードやValueHolderインダイレクションが使用されるようには構成できません）。
JPAエンティティおよびPlain Old Java Object（POJO）クラスに対しては、透過インダイレクト・コンテナ・インダイレクションのウィービングが自動的に実行されるようTopLinkを構成できます。詳細は、次を参照してください。
『EclipseLink Developer's Guide』の「Using EclipseLink JPA Weaving」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Using_EclipseLink_JPA_Weaving）
JDK 1.3で導入されたJavaクラスProxyを使用すると、定義済インタフェースのためのプレースホルダとして、動的プロキシ・オブジェクトを使用できます。一部のTopLinkマッピング（表121-4「マッピングによるインダイレクションのサポート」を参照）を構成してプロキシ・インダイレクションを使用できます。プロキシ・インダイレクションでは、ドメイン・モデルにTopLinkクラスを含めなくても、TopLinkインダイレクションの利点を活用できます。インダイレクト・コンテナはコレクション・マッピングに対するものですが、プロキシ・インダイレクションは、1対1リレーションシップ・マッピングに対するものです。
プロキシ・インダイレクションを使用するには、ドメイン・モデルが次の条件をすべて満たしている必要があります。
1対1リレーションシップのターゲット・クラスがパブリック・インタフェースを実装していること
ソース・クラスの1対1属性が、インタフェース・タイプであること
メソッド・アクセス（121.6項「マッピング・レベルでのメソッドまたは直接フィールド・アクセスの構成」を参照）を採用する場合、getterメソッドおよびsetterメソッドでそのインタフェースが使用されること
プロキシ・インダイレクションを使用する前に、作業ユニットの使用方法で設定されている制限に注意してください（17.2.4.3.1項「プロキシ・インダイレクションの制限」を参照）。
プロキシ・インダイレクションを構成するには、Oracle JDeveloper TopLinkエディタ、TopLink Workbench（121.3.1項「TopLink Workbenchを使用したインダイレクションの構成方法」を参照）またはJavaの修正メソッド（121.3.2.5項「プロキシ・インダイレクションの構成」を参照）を使用できます。
Javaのプロキシ・オブジェクトは、送信されるメッセージの遮断にのみ使用できます。==、instanceofまたはgetClassなどのプリミティブ操作がプロキシで使用されている場合は、メッセージは遮断されません。プロキシ・オブジェクトの使用に関しては、アプリケーションでこの制限に多少注意することが必要です。
プロキシ・インダイレクションの実装のターゲットは作業ユニットに登録できません。かわりに、先にソース・オブジェクトを作業ユニットに登録します。これにより、ソース・オブジェクト・クローンでgetterコールを使用し、ターゲット・オブジェクト・クローンを取得できます。
次に例を示します。
UnitOfWork uow = session.acquireUnitOfWork(); Employee emp = (Employee)session.readObject(Employee.class); // Register the source object Employee empClone = (Employee)uow.registerObject(emp); // All of source object's relationships are cloned when source object is cloned Address addressClone = empClone.getAddress(); addressClone.setCity("Toronto");
クローンおよび作業ユニットの詳細は、第113章「TopLinkトランザクションの概要」を参照してください。
ウィービング用に構成したJPAエンティティまたはPOJOクラスの場合、TopLinkでは、1対1マッピングのValueHolderインダイレクションのウィービングが実行されます。アプリケーションにコレクション・マッピング（1対多または多対多）が含まれている場合にTopLinkで変更追跡に対するウィービングが実行されるようにするには、すべてのコレクション・マッピングに対し、透過インダイレクト・コンテナ・インダイレクションのみが使用されるように構成する必要があります（コレクション・マッピングは、即時ロードやValueHolderインダイレクションが使用されるようには構成できません）。
詳細は、2.10項「ウィービングの使用」を参照してください。
マッピングの注釈属性fetchをlazyに設定すると、EclipseLink JPA永続性プロバイダでインダイレクションが使用されます。
デフォルトでは、1対多リレーションシップおよび多対多リレーションシップはLAZYで、透過インダイレクションが使用されます。一方、1対1リレーションシップおよび多対1リレーションシップはLAZYではありません。
1対1リレーションシップおよび多対1リレーションシップをLAZYに設定してウィービングを有効にすると、EclipseLink JPA永続性プロバイダでは、ウィービングを介して、これらのリレーションシップに対するValueHolderインダイレクションが有効になります。
詳細は、次を参照してください。
EJB 2.nでインダイレクション（遅延ロード）を使用する場合、TopLinkによるインダイレクションの処理方法は、使用しているEJBのバージョンおよびアプリケーション・サーバーに依存します。
さらに、EJBはそのリモートまたはローカルのインタフェースを直接実装しないため、プロキシ・インダイレクション（17.2.4.3項「プロキシ・インダイレクション」を参照）は、Enterprise Beanへのリレーションシップに使用できません。
アプリケーションのシリアライズ対象となるEnterprise Beanにインダイレクションを使用する場合、デシリアライズ時にトリガーされないインダイレクション・オブジェクトの影響を検討する必要があります（17.2.4.7項「インダイレクション、シリアライズおよびデタッチ」を参照）。
TopLinkがCMP統合（8.1項「アプリケーション・サーバーのサポートの概要」を参照）を提供する任意のアプリケーション・サーバーでCMPを使用している場合、TopLinkでは、コード生成を使用して、すべてのCMRに対してValueHolderインダイレクション（17.2.4.1項「ValueHolderインダイレクション」を参照）の使用が自動的に構成されます。
インダイレクション（遅延ロード）を使用している場合、永続オブジェクトのグラフにトリガーされていないインダイレクション・オブジェクトが含まれる可能性があります。インダイレクション・オブジェクトは一時オブジェクトで、1つのJVMと別のJVMの間でシリアライズが存続することはないため、トリガーされていないインダイレクション・オブジェクトでは、デシリアライズ後にリレーションシップへのアクセスが行われるとエラーがトリガーされます。
アプリケーションでは、デシリアライズ後に必要となるインダイレクト・リレーションシップが必ず、シリアライズ前にインスタンス化されるようにすることが必要です。そのためには、ValueHolderまたはウィービング済インダイレクションを使用してリレーションシップのgetメソッドにアクセスし、透過インダイレクションを使用してリレーションシップにsize()メソッドを送信します。アプリケーションにおいて、リレーションシップが常にシリアライズと同時にインスタンス化される必要がある場合は、目的のリレーションシップを初めてインスタンス化する際、永続クラスでシリアライズのwriteObjectメソッドが上書きされます。多数のリレーションシップを持つオブジェクトや階層の深いリレーションシップを持つオブジェクトに対しては、大きなオブジェクト・グラフをシリアライズしないよう注意してください。できれば、クライアントが必要とするリレーションシップのみをインスタンス化してください。
JPAエンティティをシリアライズする場合、それより前にインスタンス化されていないLAZYリレーションシップにアクセスしようとすると、エラーがトリガーされます。サーバー上でウィービングを使用しており、クライアントに対してエンティティがシリアライズされる場合は、同じウィービング済クラスがクライアント上に存在する必要があります。それには、jarの静的ウィービングを実行するか、またはTopLinkエージェントを使用してクライアントJVMを起動します。
詳細は、次を参照してください。
デフォルトでは、TopLinkは直接アクセスを使用して一般的な属性にアクセスします。TopLinkを使用して、プロジェクト・レベル（117.4項「プロジェクト・レベルでのメソッドまたは直接フィールド・アクセスの構成」を参照）およびマッピング・レベル（121.6項「マッピング・レベルでのメソッドまたは直接フィールド・アクセスの構成」を参照）でフィールド・アクセスを構成できます。
既存のTopLinkマッピングがニーズを満たしていない場合、マッピングの拡張機能を使用してカスタムのマッピングを作成できます。これらの拡張機能は、次のとおりです。
|
注意: データ・ソースがリレーショナルかリレーショナルでないかにかかわらず、マッピング・コンバータおよびトランスフォーマを使用できます。 |
シリアライズ・オブジェクト・コンバータは、Javaオブジェクト・シリアライズを介して複雑なオブジェクトをバイナリ・フィールドにマップできるダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能です。シリアライズされたオブジェクトは、通常、データベースのRAWまたはバイナリ・ラージ・オブジェクト（BLOB）フィールド、またはXML文書のHEXまたはBASE64要素に格納されます。
図17-6は、シリアライズ・オブジェクト・コンバータを使用したフィールドへの直接マッピングの例を示します。属性jobDescriptionには、データベースのJOB_DESCフィールドに格納される、書式設定されたテキスト文書が含まれています。
図17-7に、シリアライズ・オブジェクト・コンバータを使用したリレーショナルではないマッピングの例を示します。属性jobDescriptionには、TopLinkによってXMLスキーマのJOB DESCRIPTION要素に格納される、書式設定されたテキスト文書が含まれています。
シリアライズ・オブジェクト・コンバータは、Javaシリアライザを利用します。ドメイン・オブジェクトをシリアライズ・オブジェクト・コンバータでマップする前に、ドメイン・オブジェクトにjava.io.Serializableインタフェースが実装され（または実装が継承され）、シリアライズされていないすべてのフィールドにtransientがマークされていることを確認してください。
詳細は、121.9項「シリアライズ・オブジェクト・コンバータの構成」を参照してください。
タイプ変換コンバータは、データ・ソースのタイプをJavaのタイプに明示的にマップできるダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能です。たとえば、データ・ソースのNumberは、JavaのStringにマップできます。または、Javaのjava.util.Dateは、データ・ソースのjava.sql.Dateにマップできます。
図17-8に、タイプ変換マッピング（リレーショナル）の例を示します。java.util.Dateクラスは、デフォルトではTimestampとしてデータベースに格納されるため、そのクラスは、まず、java.sql.Dateのような明示的なデータベース・タイプに変換する必要があります（これはDB2に対してのみ必須であり、その他の大部分のデータベースには、任意の日付または時間を格納できる単一日付のデータ・タイプがあります）。
図17-9は、タイプ変換マッピング（非リレーショナル）を示しています。java.util.DateオブジェクトがXMLスキーマのStringにマップされています。
データベース用に特別にタイプ処理が必要な場合、タイプ変換コンバータを使用してその特定のデータベースを指定できます。コンバータには、5Kを超えるBLOBおよびCLOBフィールドの処理に必要なOracle Thin JDBCの特別な挿入および更新と同様に、NCHAR、NVARCHAR2およびNCLOBフィールドに必要な特別なOracle JDBCの特別なバインド・オプションのためのサポートが含まれています。
TopLinkは、oracle.toplink.platform.database.oracleパッケージのNCharacter、NClobおよびNStringタイプをコンバータのデータ・タイプとして使用し、NCHAR、NCLOBおよびNVARCHAR2タイプをサポートしています。TopLinkは、java.sql.BlobおよびClobタイプをコンバータのデータ・タイプとして使用して、5Kを超えるBLOBおよびCLOBの値をサポートしています。
データ・ソースの時間タイプ（TIMESTAMPなど）をjava.lang.Stringにマップするためにタイプ変換コンバータを構成できます。ただし、String値が次の書式に一致していることが条件です。
YYYY/MM/DD HH:MM:SS
YY/MM/DD HH:MM:SS
YYYY-MM-DD HH:MM:SS
YY-MM-DD HH:MM:SS
より複雑なStringをTIMESTAMPタイプに変換する場合は、トランスフォーメーション・マッピングを検討してください（17.2.6.5項「トランスフォーメーション・マッピング」を参照）。
詳細は、121.10項「タイプ変換コンバータの構成」を参照してください。
オブジェクト・タイプ・コンバータは、一定数のXML値をJavaオブジェクトに対応させることができるダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能です。このコンバータは、スキーマにある値がJavaにある値と異なる場合に使用します。
図17-10は、Employee属性のgenderとXML要素のgenderとの間のオブジェクト・タイプの変換を示しています。Javaのオブジェクト属性の値がFemaleの場合、TopLinkではその値がFとしてXML要素に格納されます。
詳細は、121.11項「オブジェクト・タイプ・コンバータの構成」を参照してください。
シンプル・タイプ・トランスレータは、ダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能であり、XMLスキーマで定義したとおり、要素の<type>属性に基づいて、XML要素の値を適切なJavaタイプに自動的に変換できます。
シンプル・タイプ・トランスレータは、マッピングのXPathがテキスト・ノードを指定している場合にのみ使用できます。シンプル・タイプ・トランスレータは、マッピングのXPathが属性を指定している場合は使用できません。
シンプル・タイプ・トランスレータを使用すると、XML文書の保持タイプ情報を作成できます。これは、java.lang.Integerまたはjava.util.Calendarなど、特定オブジェクト属性の場合とは異なり、java.lang.Objectおよびjava.io.Serializableなどの汎用オブジェクト属性がTopLinkで特定のタイプ変換をトリガーしないため、オブジェクト・モデルで汎用オブジェクト属性を指定する際に役立ちます。
図17-11に、PhoneNumberクラスのnumber属性のタイプ変換XMLマッピングを示します。Java属性は、タイプの保持に必要な具体的な情報が不足している点に注意してください。シンプル・タイプ・トランスレータでは、タイプを保持するためにタイプ情報を結果の文書に追加します。
デフォルトでは、TopLinkでは組込みの読取りおよび書込み変換ペアが使用されます（17.2.6.4.1項「デフォルトの読取り変換」および17.2.6.4.2項「デフォルトの書込み変換」を参照）。
独自のシンプル・タイプ・トランスレータの指定および構成によってこの動作をオーバーライドして、たとえば、XMLバイナリ・データをBase64として書き込むことができます。
詳細は、121.12項「シンプル・タイプ・トランスレータの構成」を参照してください。
表17-2は、XML要素を読み取るための、組込みの変換ペアのリストを示しています。スキーマ<type>属性が指定され、シンプル・タイプ・トランスレータが有効な場合、読み取られた値は対応するJavaタイプに変換されます。
表17-2 シンプル・タイプ・トランスレータの読取り変換
| スキーマ・タイプ | Javaタイプ |
|---|---|
|
base64Binary |
Byte[] |
|
boolean |
Boolean |
|
byte |
Byte |
|
date |
Calendar |
|
dateTime |
Calendar |
|
double |
Double |
|
float |
Float |
|
hexBinary |
Byte[] |
|
int |
int |
|
integer |
BigInteger |
|
long |
Long |
|
short |
Short |
|
string |
String |
|
time |
Calendar |
|
unsignedByte |
Short |
|
unsignedInt |
Long |
|
unsignedShort |
Integer |
ある種の特殊な状況においては、データ・ソースの処理に関して、既存のマッピング・タイプおよびそのデフォルトのJavaでは、不十分な場合が考えられます。このような特殊なケースでは、Javaでの値の表現とデータ・ソースでの値の表現の間で、特殊な変換を実行するためのトランスフォーメーション・マッピングの使用を検討できます。
トランスフォーメーション・マッピングは、次の2つのコンポーネントで構成されています。
属性トランスフォーマ（121.15項「属性トランスフォーマの構成」を参照）: 読取り（アンマーシャリング）時にオブジェクトの属性トランスフォーメーションを実行
フィールド・トランスフォーマ（121.16項「フィールド・トランスフォーマ・アソシエーションの構成」を参照）: 書込み（マーシャリング）時にオブジェクト属性とフィールド間のトランスフォーメーションを実行
トランスフォーマは、別個のクラスまたはドメイン・オブジェクトでのメソッドのいずれかとして実装できます。
属性およびフィールド・トランスフォーマの実装時には、アプリケーション・データをデータ・ソースに、またはその逆に適合させるための変換に必要な、どのような処置も講じることができます。
詳細は、次を参照してください。
TopLinkでは、Xpath文を使用して、XMLレコードへのEISマッピングおよびXML文書へのXMLマッピングで、Javaオブジェクトの属性を効率的にマップします。このようなマッピングを作成する場合、次を指定できます。
リレーショナル・データベース表では、列は名前により一意に識別されます。XML文書では、要素は名前および位置により一意に識別されます。図17-12は、street要素の最初のインスタンスが建物の情報を格納し、street要素の2番目のインスタンスが番地の情報を格納しているXML文書へのマッピングの例を示しています。図17-12は、マッピングが永続され、street[2]/text()のようなXpathを使用しJavaオブジェクト属性をXML要素に位置によってマップできる順序をTopLink XMLマッピングが保持していることを示しています。
他のXMLテクノロジでは、XML要素の位置ではなく、名前を認識するのみのため、コレクションにある同じ名前の要素から単純な値を格納する必要があります。
XML文書では、属性および要素は名前とパスの組合せにより一意に識別されます。図17-13では、TopLink XMLマッピングではitem/name/text()のようなXPathにより、名前とパスでXML要素を一意に識別できる例を示しています。TopLinkでは、XML要素linesとitemとの間の正規のオブジェクト・リレーションシップは必要ありません。
その他のXMLテクノロジでは、すべてのネスト・レベルにオブジェクト・リレーションシップを指定する必要があり、その結果、この制限を満たすため、単なるデータの編成に多くのXML要素とクラスが必要になります。これにより、ドメイン領域を適切に反映していない、不要で大きなオブジェクト・モデルを生成することになります。
単純なXML文書については、TopLink XMLマッピングでは、属性または要素の名前のみのXPathの指定によってデータをXML文書に正確に配置できます。
図17-14は、名前による単純なXML文書へのマッピングの例を示しています。@NAMEのみのXPathの指定によって、Javaオブジェクト属性nameをXML属性nameにマップできます。同様に、AGEのみのXPathの指定によって、Javaオブジェクト属性ageをXMLテキスト・ノードAGEにマップできます。
名前でXPathを指定すると、XPathマッピング・オプションのパフォーマンスが最も低下します。そのため、位置によるXPath（17.2.7.1項「位置によるXPath」を参照）またはパスと名前によるXPath（17.2.7.2項「パスと名前によるXPath」を参照）の使用をお薦めします。
コンポジット・リレーションシップでは、TopLink XMLマッピングは、自己XPath（"."）の指定のある親にネストした要素ではなく、親の要素にデータを配置できます。
図17-15は、自己XPathを使用したXML文書へのマッピングを示しています。
図17-15で示される前述の例の場合、Employeeクラスのname属性は、注釈@nameを使用してマップされます。
自己XPathを使用することにより、親にネストした要素ではなく、親の要素でのすべての読取りおよび書込みをTopLinkで実行できるようにします（17.2.9項「マッピングおよびjaxb:classカスタマイズ」を参照）。
TopLinkでは、次の表17-4で示されているように、XMLレコードへのEISマッピングおよびXML文書へのXMLマッピングで、xsd:listおよびxsd:unionタイプへのマッピングをサポートしています。
表17-4 xsd:listおよびxsd:unionタイプに対するTopLinkのサポート
| XSD | EISダイレクト・マッピングXMLダイレクト・マッピング |
EISコンポジット・ダイレクト・コレクション・マッピングXMLコンポジット・ダイレクト・コレクション・マッピング |
|---|---|---|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EISDirectMapping（XMLレコードで使用）、XMLDirectMappingまたはそのサブクラスを使用して、次のようにJava属性をxsd:unionタイプにマップします。
<xsd:simpleType name="size-type">
<xsd:union memberTypes="xsd:decimal xsd:string"/>
</xsd:simpleType>
TopLinkでオブジェクトをXMLにマーシャリング（書込み）する場合、そのデフォルトの変換ペアが使用され、Javaタイプが適切なxsdタイプに変換されます。
memberTypesが同じJavaタイプをマップする場合、TopLinkでは、正常な変換を可能にするUNIONにある最初のmemberTypeを使用してマーシャリングします。たとえば、byte[]のJavaタイプをhexBinaryおよびbase64BinaryのmemberTypesを持つxsd:unionにマップする場合、TopLinkでは、最初のmemberType: hexBinaryを使用してマーシャリングします。
変換ペアのデフォルト変換をカスタマイズすると、XMLFieldメソッドaddConversionを使用して、またEISDirectMappingまたはXMLDirectMappingのメソッドsetFieldによるXMLFieldとのマッピングを構成して、Javaタイプからxsdへの変換を制御できます。たとえば、memberTypesがxsd:dateおよびxsd:timeで、Java属性がJAXB 1.0標準java.util.Calendarではなく、タイプjava.util.Dateであった場合、xsd:dateをjava.util.Dateにするために変換ペアを変更できます。
TopLinkでXMLをオブジェクトにアンマーシャリング（読取り）する場合、最初に正常な変換が行われるまで、XSDで指定された順序で各memberTypeが試行されます。
XML文書でxsi:type属性が要素に指定されている場合、TopLinkではmemberTypesの変換を試行せず、xsi:typeに従って変換します。
詳細は、53.3.5項「XMLダイレクト・マッピングによるunionフィールドへのマッピング」を参照してください。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（77.3項「EISダイレクト・マッピング」を参照）。
java属性は次のようにxsd:listタイプにマップできます。
<xsd:simpleType name="sizes">
<xsd:list itemType="xsd:int"/>
</xsd:simpleType>
xsd:listをJava Listタイプとしてオブジェクト・モデルで表す場合、EISCompositeDirectCollectionMapping（XMLレコードで使用）、XMLCompositeDirectCollectionMappingまたはそのサブクラスを使用し、Java属性のListタイプを指定するにはマッピング・メソッドuseCollectionClassを使用します。
listを空白デリミタ付きトークンのStringとして表す場合（たとえば、aaa bbb ccc）、EISDirectMapping（XMLレコードで使用）、XMLDirectMappingまたはそのサブクラスを使用して、このJava属性をxsd:listにマップします（たとえば、<item>aaa bbb ccc</item>）。
いずれの場合でも、マッピングでlistを<item>aaa bbb ccc</item>のように、1つのノードに、または、次のように複数のノードにマーシャリング（書込み）するかどうかを構成できます。
<item>aaa</item> <item>bbb</item> <item>ccc</item>
XMLCompositeDirectCollectionMappingまたはそのサブクラスを使用したxsd:listタイプへのマッピングに関する詳細は、次を参照してください。
同じことがEISCompositeDirectCollectionMapping（XMLレコードで使用）にも適用されます。
XMLDirectMappingまたはそのサブクラスを使用したxsd:listタイプへのマッピングの詳細は、53.3.4項「XMLダイレクト・マッピングによるlistフィールドへのマッピング」を参照してください。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（77.3項「EISダイレクト・マッピング」を参照）。
EISCompositeDirectCollectionMapping（XMLレコードで使用）、XMLCompositeDirectCollectionMappingまたはそのサブクラスを使用して、次のように、Java属性をxsd:unionタイプを含むxsd:listにマップします。
<xsd:element name="listOfUnions" type="listOfUnions"/>
<xsd:simpleType name="listOfUnions">
<xsd:list>
<xsd:simpleType>
<xsd:union memberTypes="xsd:date xsd:integer"/>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
TopLinkによりオブジェクトがXMLにマーシャリング（書込み）される場合、1つのxsd:list itemTypeに依存しません。そのかわり、TopLinkでは最初に正常な変換が行われるまで、Listの項目ごとに各memberTypeを試行します。
詳細は、53.4.5項「XMLコンポジット・ダイレクト・コレクション・マッピングによるlistOfUnionsマッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeDirectCollectionMappingにも適用されます（77.4項「EISコンポジット・ダイレクト・コレクション・マッピング」を参照）。
次のように、memberTypesがxsd:listタイプであり、各xsd:listに単一タイプの項目が含まれているxsd:unionタイプに、Java属性をマップできます。
<xsd:element name="listOfUnions" type="UnionOfLists"/>
<xsd:simpleType name="UnionOfLists">
<xsd:union memberTypes="xsd:double">
<xsd:simpleType>
<xsd:list itemType="xsd:date"/>
</xsd:simpleType>
<xsd:simpleType>
<xsd:list itemType="xsd:integer"/>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
この例では、有効なXML文書にすべてのxsd:double、すべてのxsd:dateまたはすべてのxsd:integerのいずれかの値が含まれていることに注意してください。
listを空白デリミタ付きトークンのStringとして表す場合（たとえば、aaa bbb ccc）、EISDirectMapping（XMLレコードで使用）またはXMLDirectMappngを使用して、このJava属性をxsd:listにマップします（たとえば、<item>aaa bbb ccc</item>）。
listをJava Listタイプとしてオブジェクト・モデルで表す場合、EISCompositeDirectCollectionMapping（XMLレコードで使用）、XMLCompositeDirectCollectionMappingまたはそのサブクラスを使用します。
詳細は、次を参照してください。
53.3.6項「XMLダイレクト・マッピングによるunionOfListsマッピング」。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（77.3項「EISダイレクト・マッピング」を参照）。
53.4.6項「XMLコンポジット・ダイレクト・コレクション・マッピングによるunionOfListsマッピング」。同じことがXMLレコードを使用するEISCompositeDirectCollectionMappingにも適用されます（77.4項「EISコンポジット・ダイレクト・コレクション・マッピング」を参照）。
EISDirectMapping（XMLレコードで使用）、XMLDirectMappingまたはそのサブクラスを使用して、次のように、Java属性をxsd:unionタイプを含むxsd:unionにマップします。
<xsd:simpleType name="UnionOfUnions">
<xsd:union>
<xsd:simpleType>
<xsd:union>
<xsd:simpleType>
<xsd:list itemType="xsd:date"/>
</xsd:simpleType>
<xsd:simpleType>
<xsd:list itemType="xsd:integer"/>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
<xsd:simpleType>
<xsd:union>
<xsd:simpleType>
<xsd:list itemType="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType>
<xsd:list itemType="xsd:float"/>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
この例では、有効なXML文書にxsd:date、xsd:integer、xsd:stringまたはxsd:floatのいずれかが含まれている可能性があることに注意してください。
詳細は、53.3.7項「XMLダイレクト・マッピングによるunionOfUnionsマッピング」を参照してください。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（77.3項「EISダイレクト・マッピング」を参照）。
jaxb:classカスタマイズを使用すると、スキーマから生成された実装クラスのアプリケーション固有のサブクラスを宣言で指定できます。これにより、JAXBの生成済実装クラスを拡張する独自のクラスを書き込むことができます（47.1.1.2.1項「実装クラス」を参照）。その結果、JAXBランタイム・バインディング・フレームワークのサブクラスへのアクセスが可能になります。
XMLレコードへのEISコンポジット・オブジェクト・マッピングまたはXML文書へのXMLコンポジット・オブジェクト・マッピングを作成すると、次のXSD構造を使用してjaxb:classカスタマイズに対応するため、マッピングのXPath（121.4項「XPathの構成」を参照）を構成できます。
jaxb:classカスタマイズ構造へのマッピング時には、このカスタマイズに対するTopLinkサポートの制限を考慮してください（17.2.9.6項「jaxb:classカスタマイズ・サポートの制限」を参照）。
jaxb:classカスタマイズは、all、choiceまたはsequence構造で使用できます。例17-1は、all構造のjaxb:classカスタマイズを示しています。
例17-1 all構造のjaxb:classカスタマイズ
<xsd:element name="employee">
<xsd:complexType>
<xsd:all>
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="period"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="startDate" type="xsd:date"/>
<xsd:element name="endDate" type="xsd:date"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
これは、all構造に対して、所有側の要素にPeriodという名前のインナー・クラスを作成することをJAXBコンパイラに指示します。EISCompositeObjectMapping（XMLレコードで使用）またはXMLCompositeObjectMappingを使用して、Java属性をこのインナー・クラスにマップします。
詳細は、53.5項「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（77.5項「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、例17-2で示されているように、group構造で使用できます。
例17-2 group構造のjaxb:classカスタマイズ
<xsd:group name="G1">
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="period"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="startDate" type="xsd:date"/>
<xsd:element name="endDate" type="xsd:date"/>
</xsd:sequence>
</xsd:group>
<xsd:element name="employee">
<xsd:complexType>
<xsd:group ref="G1"/>
</xsd:complexType>
</xsd:element>
これは、group構造に対して、Periodという名前の外部ラッパー・クラスを作成することをJAXBコンパイラに指示します。EISCompositeObjectMapping（XMLレコードで使用）またはXMLCompositeObjectMappingを使用して、Java属性をこの外部ラッパー・クラスにマップします。
詳細は、53.5項「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（77.5項「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、groupを含むsequenceまたはchoice構造で使用できます。例17-3は、group構造を含む、sequence構造のjaxb:classカスタマイズを示しています。
例17-3 groupを含むsequence構造のjaxb:classカスタマイズ
<xsd:element name="employee">
<xsd:complexType>
<xsd:sequence>
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="EmploymentInfo"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="id" type="xsd:int"/>
<xsd:group ref="G1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:group name="G1">
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="Period"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="startDate" type="xsd:date"/>
<xsd:element name="endDate" type="xsd:date"/>
</xsd:sequence>
</xsd:group>
これは、sequence構造に対して所有側の要素にEmploymentInfoという名前のインナー・クラスを、またgroup構造に対してPeriodという名前の外部ラッパー・クラスを作成することをJAXBコンパイラに指示します。インナー・クラスは、外部ラッパー・クラスを参照します。EISCompositeObjectMapping（XMLレコードで使用）またはXMLCompositeObjectMappingを使用して、Java属性をこのインナー・クラスにマップします。
詳細は、53.5項「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（77.5項「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、sequenceまたはchoiceを含むgroup構造で使用できます。例17-4は、sequence構造を含む、group構造のjaxb:classカスタマイズを示しています。
例17-4 sequenceを含むgroup構造のjaxb:classカスタマイズ
<xsd:group name="G1">
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="EmploymentInfo"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="Period"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="startDate" type="xsd:date"/>
<xsd:element name="endDate" type="xsd:date"/>
</xsd:sequence>
</xsd:group>
<xsd:element name="employee">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="id" type="xsd:int"/>
<xsd:group ref="G1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
これは、group構造に対してEmploymentInfoという名前の外部ラッパー・クラスを、またsequence構造に対して外部ラッパー・クラスにPeriodという名前のインナー・クラスを作成することをJAXBコンパイラに指示します。所有側の要素は、外部ラッパー・クラスを参照します。EISCompositeObjectMapping（XMLレコードで使用）またはXMLCompositeObjectMappingを使用して、Java属性をこの外部ラッパー・クラスにマップします。
詳細は、53.5項「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（77.5項「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、例17-5に示すように、別のgroup構造を含むgroup構造で使用できます。
例17-5 groupを含むgroup構造のjaxb:classカスタマイズ
<xsd:group name="G1">
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="EmploymentInfo"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="id" type="xsd:int"/>
<xsd:group ref="G2"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="G2">
<xsd:annotation>
<xsd:appinfo>
<jaxb:class name="Period"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="startDate" type="xsd:date"/>
<xsd:element name="endDate" type="xsd:date"/>
</xsd:sequence>
</xsd:group>
<xsd:element name="employee">
<xsd:complexType>
<xsd:group ref="G1"/>
</xsd:complexType>
</xsd:element>
これは、所有側の要素クラスが参照するgroup構造に対してEmploymentInfoという名前のラッパー・クラスを、またEmploymentInfoクラスが参照するgroup構造に対してPeriodという名前の別のラッパー・クラスを作成することをJAXBコンパイラに指示します。EISCompositeObjectMapping（XMLレコードで使用）またはXMLCompositeObjectMappingを使用して、Java属性をこれらのラッパー・クラスにマップします。
詳細は、53.5項「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（77.5項「EISコンポジット・オブジェクト・マッピング」を参照）。
カスタマイズ構造へのマッピングの場合、次の制限を考慮してください。
バインドされていない構造はサポートされていません。
部分検証はサポートされていません。
sequence要素をコンポジット・オブジェクトにマッピングする場合、XMLスキーマでは、コンポジット・オブジェクトへマップする要素が一緒に維持されるように要素を順序付ける必要があります。
sequence構造では、XMLスキーマで指定された順序でそのすべての要素が発生するよう強制されます。例17-6に示すXMLスキーマについて考えてみます。有効なXMLインスタンスには、sequence要素を指定した順序で含める必要があります。
street、customerName、city
この例では、ダイレクト・マッピングを使用してcustomerName属性をマップし、streetおよびcity属性をコンポジットAddressオブジェクトにマップしようとしています。マッピングを定義する順序に応じて、TopLinkでは、無効なXML文書インスタンスを次の順序でマーシャリングします。
customerName、street、city
または
street、city、customerName
例17-6 サポートされていないsequence要素順序を使用するXMLスキーマ
<xs:element name="customer">
<xs:complexType>
<xs:sequence>
<xs:element name="street" type="xs:string"/>
<xs:element name="customerName" type="xs:string" />
<xs:element name="city" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
この問題を修正するには、コンポジット・オブジェクトにマップする要素を一緒に維持するようにXMLスキーマを変更して（例17-7を参照）、XMLスキーマで指定した順序でマッピングを定義します。
JAXBは、xsd:NCNameから導出され、enumerationファセットを持つbasetypeを使用して、型保証列挙クラスを名前付きの単純なタイプ定義にバインドします（例17-8を参照）。
例17-8 型保証列挙宣言を使用したスキーマ・フラグメント
<simpleType name="NISTSchema-NCName-enumeration-1-Type">
<restriction base="NCName">
<enumeration value="qbandwidth-and.software-use.too"/>
<enumeration value="_effort-disseminate_and-devices.com"/>
</restriction>
</simpleType>
EISDirectMappingにJAXBTypesafeEnumConverterを使用、XMLレコードあるいはXMLDirectMappingにEISCompositeDirectCollectionMappingを使用、またはXML文書にXMLCompositeDirectCollectionMappingやそのサブクラスを使用して、Java属性をこのような列挙にマップできます。
Oracle JDeveloper TopLinkエディタおよびTopLink Workbenchでは、JAXBTypesafeEnumConverterを使用するマッピングの構成で、このコンバータを直接サポートしていないため、ディスクリプタ修正メソッドを使用する必要があります（121.13項「JAXB型保証列挙コンバータの構成」を参照）。
プロジェクトおよびオブジェクト・モデルをTopLink JAXBコンパイラを使用して作成する場合（48.2項「XMLスキーマからのXMLプロジェクトの作成」を参照）、コンパイラでは型保証列挙クラスおよびディスクリプタ修正メソッドのあるクラスが作成され、必須修正メソッドが自動的に登録されます。
リレーショナル・マッピングは、オブジェクトのデータ・メンバー・タイプを、サポートされているリレーショナル・データベースの対応するリレーショナル・データベース（SQL）のデータ・ソース表現に変換します。リレーショナル・マッピングを使用すると、オブジェクト・モデルをリレーショナル・データ・モデルにマップできます。
また、リレーショナル・マッピングは、データベースの別の表に格納され、外部キーを介して関連付けられている他のドメイン・オブジェクトを参照するオブジェクト・データ・メンバーも変換できます。
リレーショナル・マッピングは、リレーショナル・プロジェクトで使用します。詳細は、18.1項「リレーショナル・プロジェクトの作成」を参照してください。
リレーショナル・マッピングの詳細は、第XII部「リレーショナル・マッピング」を参照してください。
オブジェクト・リレーショナル・データ・タイプ・マッピングは、特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データ・タイプ・データベースでの格納に最適化された構造化データ・ソース表現に変換します。オブジェクト・リレーショナル・データ・タイプ・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・データ・タイプ・データ・モデルにマップできます。
オブジェクト・リレーショナル・データ・タイプ・マッピングは、リレーショナル・プロジェクトで使用します。詳細は、18.1項「リレーショナル・プロジェクトの作成」を参照してください。
オブジェクト・リレーショナル・データ・タイプ・マッピングの詳細は、第XIII部「オブジェクト・リレーショナル・データ・タイプ・マッピング」を参照してください。
XMLマッピングは、オブジェクトのデータ・メンバーを、構造がXMLスキーマ・ドキュメント（XSD）により定義されているXMLファイルのXML要素に変換します。
XMLマッピングは、XMLプロジェクトで使用します。詳細は、47.1項「XMLプロジェクトの概念」を参照してください。
XMLマッピングの詳細は、第XVI部「XMLマッピング」を参照してください。
EISマッピングでは、オブジェクトのデータ・メンバーをオブジェクトのディスクリプタで定義されたEISレコード形式に変換します。
EISマッピングは、EISプロジェクトで使用します。詳細は、71.1項「EISプロジェクトの概念」を参照してください。
EISマッピングの詳細は、第XIX部「EISマッピング」を参照してください。
