| Oracle TopLink開発者ガイド 10g（10.1.3.1.0） B31861-01 |
|
 戻る |
 次へ |
TopLinkの最大の強みの1つが、オブジェクトの表現とデータ・ソースに固有の表現との間でデータを変換するための機能があることです。この変換はマッピングと呼ばれ、TopLinkプロジェクトの中核をなすものです。
1つのマッピングは、ドメイン・オブジェクトの単一のデータ・メンバーに対応します。マッピングにより、オブジェクトのデータ・メンバーがそのデータ・ソースの表現と関連付けられ、オブジェクトとデータ・ソースの間で双方向での変換を実行する手段が定義されます。
この章の内容は次のとおりです。
表30-1では、TopLinkがサポートするマッピングのタイプについて説明します。
表30-1 TopLinkのマッピングのタイプ
| タイプ | 説明 | タイプ | TopLink Workbench | Java |
|---|---|---|---|---|
|
|
オブジェクトのデータ・メンバー・タイプを、サポートされているリレーショナル・データベースの対応するリレーショナル・データベース（SQL）のデータ・ソース表現に変換するマッピング。リレーショナル・マッピングを使用すると、オブジェクト・モデルをリレーショナル・データ・モデルにマップできます。 |
基本 |
 |
|
|
|
特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データベースでの格納に最適化された構造化データ・ソース表現に変換するマッピング。オブジェクト・リレーショナル・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・データ・モデルにマップできます。 |
詳細 |
 |
|
|
|
オブジェクトのデータ・メンバーを、オブジェクトのディスクリプタで定義されたEISレコード形式に変換するマッピング。 |
詳細 |
|
|
|
|
オブジェクトのデータ・メンバーを、構造がXMLスキーマ・ドキュメント（XSD）により定義されているXML文書のXML要素に変換するマッピング。 |
詳細 |
|
|
詳細は、次を参照してください。
この項では、次の内容を含む、TopLinkマッピングに固有の概念について説明します。
マッピング・アーキテクチャ（リレーショナルおよび非リレーショナル・マッピングに適用）
マッピングの例（リレーショナルおよび非リレーショナル・マッピングに適用）
開発時にTopLink Workbenchを使用した自動マッピング（リレーショナルおよび非リレーショナル・マッピングに適用）
実行時にOC4Jを使用するCMPプロジェクトでのデフォルト・マッピング（リレーショナル・マッピングに適用）
開発時のJAXBプロジェクト生成（XMLマッピングに適用）
インダイレクション（オブジェクト・リレーショナル・マッピングに適用）
メソッド・アクセッサおよび属性アクセッサ（リレーショナルおよび非リレーショナル・マッピングに適用）
シリアライズ・オブジェクト・コンバータ（リレーショナルおよび非リレーショナル・マッピングに適用）
タイプ変換コンバータ（リレーショナルおよび非リレーショナル・マッピングに適用）
オブジェクト・タイプ・コンバータ（XMLマッピングに適用）
シンプル・タイプ・トランスレータ（XMLマッピングに適用）
トランスフォーメーション・マッピング（リレーショナルおよび非リレーショナル・マッピングに適用）
マッピングおよびXPath（XMLマッピングに適用）
マッピングとxsd:listおよびxsd:unionタイプ（XMLマッピングに適用）
マッピングおよびjaxb:classカスタマイズ（XMLマッピングに適用）
マッピングおよびJAXB型保証列挙（XMLマッピングに適用）
マッピングを定義するには、次のコンポーネントを利用します。
オブジェクトのデータを格納するデータ・ソース（リレーショナル・データベース表またはスキーマ定義のXML要素など）に固有のデータ表現
特定オブジェクト・クラスのディスクリプタ
マップするオブジェクト・クラス
|
注意: マッピングは、プロジェクトの永続性の有無にかかわりなく同じです。 |
標準的なTopLinkマッピングの例については、「マッピングの例」を参照してください。
TopLinkプロジェクトで定義するデータ・ソースのタイプにより、使用できるマッピングのタイプおよびその構成方法が決まります。永続プロジェクトでは、マッピングを使用してデータ・ソースを永続させます。永続ではないプロジェクトでは、オブジェクト形式とその他の一部のデータ表現（XMLなど）の間で単に変換を行うためにマッピングを使用します。データ・ソースおよびプロジェクト・タイプに関する詳細は、「TopLinkプロジェクト・タイプ」を参照してください。
ディスクリプタは、特定のドメイン・オブジェクトを表します。つまり、オブジェクトのクラスを示します。ディスクリプタはマッピングを所有します。つまり、メモリーで永続させるまたは変換するクラスのデータ・メンバーのそれぞれに1つのマッピングがあります。
|
注意: 永続性はディスクリプタ・レベルで適用できます。 |
ディスクリプタの詳細に関しては、「ディスクリプタの概要」を参照してください。
TopLinkはマッピングを提供して、多種多様なデータ・タイプおよびデータ表現を処理します。詳細は、「マッピングのタイプ」を参照してください。
すべてのマッピングは、oracle.toplink.mappings.DatabaseMappingクラスのサブクラスです。マッピングAPIの詳細は、「マッピングAPIの概要」を参照してください。
TopLinkでは、より複雑なマッピングをサポートしますが、ほとんどのTopLinkのクラスは、クラスで使用可能な情報のタイプを定義する1つのデータベース表またはXML要素にマップされます。特定のクラスからインスタンス化された各オブジェクトは、一意にオブジェクトを識別する識別子（主キー）を付加して、オブジェクトの属性を構成する1つの行にマップされます。
図30-1に、最も単純なデータベース・マッピングの例を示します。
データベースのTable_Xは、Class_Xを表します。
Object_X1およびObject_X2は、Class_Xのインスタンスです。
Table_Xの各行は、Object_X1およびObject_X2に加えて、Class_Xのその他のインスタンスも表します。
TopLinkには、図30-1に示される単純なマッピングから複雑なマッピングまで、これらのマッピングを作成するためのツールが用意されています。
その他のリレーショナル・マッピングの例については、図33-1「フィールドへ直接マッピング」を参照してください。
その他のリレーショナルではないマッピングの例については、図62-34「XMLトランスフォーメーション・マッピング」を参照してください。
通常は、手動でTopLink Workbenchを使用して、クラス対クラスおよびメンバー対データ・メンバー単位でマッピングを定義します（「開発時におけるマッピングの手動作成」を参照）。
また、次を利用することも可能です。
TopLink Workbenchの「自動マップ」機能を使用して、プロジェクトのすべてのクラスおよびデータ・メンバーにデフォルトのマッピングを自動的に定義できます（「開発時におけるマッピングの自動作成」を参照）。
TopLink Workbenchの自動マッピングは、すべてのプロジェクト・タイプに使用できますが、プロジェクト・モデルおよびデータベース・スキーマの両方が定義済であることが前提です。
デフォルト・マッピングとは、リレーショナルの永続フレームワークの用語で、フレームワークにオブジェクトのディスクリプタ・メタデータ（マッピング、ログイン・データ、データベース・プラットフォーム、ロックおよび外部キーなどが含まれます）を自動生成させることを指します。
|
注意: デフォルト・マッピングは、リレーショナル・プロジェクトのみに適用できます。 |
TopLinkでは、必要に応じてエンティティに関連付けられた表の作成、または削除および作成をデプロイ時に実行できます。このことは、TopLinkが最小の要件、つまり準拠した1つのEARファイルおよび1つの有効なデータ・ソースで、デプロイ・プロセス全体を処理できること意味します。これにより、アプリケーションをデプロイする前に、表を作成しマッピングを指定する必要がなくなります。
TopLinkのデフォルト・マッピングは、次の機能をサポートします。
標準CMP（つまり、依存オブジェクトではない）フィールドのための、フィールドへ直接マッピングのサポート
依存オブジェクトのためのシリアライズ・オブジェクト・マッピングのサポート
CMRフィールドのための1対1、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ファイルで指定されたマッピングを順守します。この場合、自動表生成を構成できます。
詳細は、「default-mappingのプロパティの構成」を参照してください。
|
注意: 前述の内容は、EJB 3.0の永続リレーショナル・プロジェクトにも適用されます。通常、ディスクリプタ・ファイルは、EJB 3.0の注釈により置換されます。たとえば、TopLinkでは、 |
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マッピングの詳細は、第62章「XMLマッピングの概要」を参照してください。
デフォルトでは、TopLinkで永続オブジェクトを取得すると、それによって参照先の依存オブジェクトがすべて取得されます。インダイレクション（遅延読取り、遅延ロードおよびJust-In-Time読取りとしても知られている）をリレーションシップ・マッピングでマップされた属性に構成すると、TopLinkでは、参照されたオブジェクトのプレースホルダとしてインダイレクション・オブジェクトが使用されます。つまり、TopLinkでは、当該の指定属性にアクセスするまで、依存オブジェクトの読取りは遅延されます。これにより、特にアプリケーションが取得したオブジェクトのコンテンツのみを必要とし、そのオブジェクトに関連するオブジェクトのコンテンツは必要としない場合に、パフォーマンスの大幅な向上が見られます。
すべてのリレーションシップ・マッピングに対してインダイレクションを使用することをお薦めします。これにより、データ・ソースへのアクセスを最適化できるだけでなく、作業ユニット処理、キャッシュ・アクセスおよび同時実行性のTopLinkによる最適化が可能になります。
|
注意: インダイレクションの使用は、双方向リレーションシップを適切に維持する場合に特に重要です（「双方向リレーションシップの維持」を参照）。この場合、インダイレクションを使用する必要があります。コレクションを操作する場合は、透過インダイレクションを使用する必要があります（「透過インダイレクト・コンテナ・インダイレクション」を参照）。 |
図30-2は、インダイレクションの例を示しています。インダイレクションを使用しない場合、Orderオブジェクトの読取りにより、LineItemオブジェクトの依存コレクションも読み取ります。インダイレクションを使用すると、Orderオブジェクトの読取りでは、LineItemオブジェクトの依存コレクションは読み取られません。つまり、lineItems属性はインダイレクション・オブジェクトを参照します。他の属性（customerIdなど）にアクセスできますが、lineItems属性にアクセスした場合は、TopLinkでは依存LineItemオブジェクトのみが読み取られます。
TopLinkでは、次のインダイレクション・タイプをサポートします。
EJBでインダイレクションを使用する場合、使用するEJBのバージョンおよびアプリケーション・サーバーが、インダイレクションの構成方法および適用するインダイレクションのタイプの決定に影響します（「インダイレクションおよびEJB」を参照）。
アプリケーションのシリアライズ対象となるオブジェクトにインダイレクションを使用する場合、デシリアライズ時にトリガーされないインダイレクション・オブジェクトの影響を検討する必要があります（「インダイレクション、シリアライズおよびデタッチ」を参照）。
インダイレクションの構成に関する詳細は、「インダイレクションの構成」を参照してください。
インダイレクションを使用する永続クラスは、リレーションシップ属性をValueHolder属性に置き換える必要があります。ValueHolderは、ValueHolderなど、ValueHolderInterfaceインタフェースを実装するクラスのインスタンスです。このオブジェクトには、置き換えられるオブジェクトをデータベースから取得するために必要な情報が格納されます。アプリケーションがValueHolderにアクセスしないと、置き換えられたオブジェクトはデータベースから読み取られません。
ValueHolderが置き換えるオブジェクトを取得するには、ValueHolderInterfaceのgetValueおよびsetValueメソッドを使用します。これらのメソッドを使用する便利な方法としては、次の例で示すように、ValueHolderInterfaceのgetValueおよびsetValueメソッドを、getおよびsetメソッド内で非表示にする方法があります。
図30-3は、データベースから読み取られるEmployeeオブジェクトを示しています。Addressオブジェクトは読み取られず、アクセスするまで作成されません。
図30-4に示すとおり、最初のアドレスへのアクセス時に、ValueHolderはAddressオブジェクトを読み取り、それを返します。
図30-5で示すように、アドレスに対する後続のリクエストではデータベースにアクセスしません。
メソッド・アクセス（「メソッド・アクセスの構成」を参照）を使用している場合、マッピングで指定されたgetおよびsetメソッドは、ValueHolderが参照しているオブジェクトではなく、ValueHolderInterfaceのインスタンスにアクセスする必要があります。アプリケーションがこれらのgetterおよびsetterを使用することはありませんが、ValueHolderの使用を隠すgetterおよびsetterを使用します。詳細は、「ValueHolderインダイレクションとメソッド・アクセスの同時構成」を参照してください。
透過インダイレクト・コンテナ（「コンテナ・ポリシーの構成」を参照）・インダイレクションを使用すると、次のいずれかの関連オブジェクトのコレクションを保持する永続クラスの任意のリレーションシップ属性を宣言できます。
java.util.Collection
java.util.Hastable
java.util.List
java.util.Map
java.util.Set
java.util.Vector
TopLinkでは、適切なインタフェースを実装し、関連オブジェクトのJust-in-Time方式による読取りも実行するインダイレクション・オブジェクトが使用されます。透過インダイレクションを使用する場合、属性をValueHolderInterfaceとして宣言する必要はありません。
新しく作成されたコレクション・マッピングでは、属性がValueHolderInterfaceでない場合、デフォルトで透過インダイレクションを使用します。
JDK 1.3で導入されたJavaクラスProxyを使用すると、定義済インタフェースのためのプレースホルダとして、動的プロキシ・オブジェクトを使用できます。一部のTopLinkマッピング（表32-4を参照）を構成してプロキシ・インダイレクションを使用できます。プロキシ・インダイレクションでは、ドメイン・モデルにTopLinkクラスを含めなくても、TopLinkインダイレクションの利点を活用できます。インダイレクト・コンテナはコレクション・マッピングに対するものですが、プロキシ・インダイレクションは、1対1リレーションシップ・マッピングに対するものです。
プロキシ・インダイレクションを使用するには、ドメイン・モデルが次の条件をすべて満たしている必要があります。
1対1リレーションシップのターゲット・クラスがパブリック・インタフェースを実装していること
ソース・クラスの1対1属性が、インタフェース・タイプであること
メソッド・アクセス（「メソッド・アクセスの構成」を参照）を採用する場合、getterおよびsetterメソッドでそのインタフェースが使用されること
プロキシ・インダイレクションを使用する前に、作業ユニットの使用方法で設定される制限に注意してください（「プロキシ・インダイレクションの制限」を参照）。
プロキシ・インダイレクションを構成するには、TopLink Workbench（「TopLink Workbenchの使用」を参照）またはJavaの修正メソッドを使用できます（「プロキシ・インダイレクションの構成」を参照）。
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");
クローンおよび作業ユニットの詳細は、第97章「TopLinkトランザクションの概要」を参照してください。
EJBでインダイレクションを使用する場合、TopLinkによるインダイレクションの処理方法は、使用しているEJBのバージョンおよびアプリケーション・サーバーに依存します。
さらに、EJBはそのリモートまたはローカルのインタフェースを直接実装しないため、プロキシ・インダイレクション（「プロキシ・インダイレクション」を参照）は、Enterprise Beanへのリレーションシップに使用できません。
アプリケーションのシリアライズ対象となるEnterprise Beanにインダイレクションを使用する場合、デシリアライズ時にトリガーされないインダイレクション・オブジェクトの影響を検討する必要があります（「インダイレクション、シリアライズおよびデタッチ」を参照）。
TopLinkがCMP統合（「アプリケーション・サーバーのサポート」を参照）を提供する任意のアプリケーション・サーバーでCMPを使用している場合、TopLinkでは、コード生成を使用して、すべてのCMRに対してValueHolderインダイレクション（「ValueHolderインダイレクション」を参照）の使用が自動的に構成されます。
|
注意: OC4JでEJB 3.0の永続性を使用している場合、@Bean注釈属性fetch=lazyを指定すると、TopLinkは、バイトコードのウィービングを使用して、すべてのコンテナ管理リレーションシップに対してValueHolderインダイレクション（「ValueHolderインダイレクション」を参照）の使用を自動的に構成します。 |
インダイレクションを使用している場合、永続オブジェクトのグラフにトリガーされていないインダイレクション・オブジェクトが含まれる可能性があります。インダイレクション・オブジェクトは一時オブジェクトで、1つのJVMと別のJVMの間でシリアライズを存続することはないため、トリガーされていないインダイレクション・オブジェクトは、デシリアライズ時にnull値として表示される可能性があります。この項では、使用しているEJBのバージョンおよびアプリケーション・サーバーへのこの依存性の対処方法について説明します。
シリアライズおよびTopLinkに関する詳細は、「作業コピーのクローンでの変更内容のマージ」を参照してください。
TopLinkがCMP統合（「アプリケーション・サーバーのサポート」を参照）を提供する任意のアプリケーション・サーバーでCMPを使用している場合、インダイレクションは同じJVM内でのEnterprise Beanの非アクティブ化およびアクティブ化に影響を及ぼしません。
ただし、1つのJVMから別のJVM（たとえば、サーバーからクライアント）にインダイレクション対応Enterprise Beanをシリアライズすると、トリガーされていないインダイレクション・オブジェクトがデシリアライズ時にnull値として表示されます。この使用例を処理するためにクライアントをコーディングして、データ・ソースでnullであったためにnullとなっている属性と、トリガーされていないインダイレクション・オブジェクトのためにnullとなっている属性を区別する必要があります。
|
注意: OC4JでEJB 3.0の永続性を使用している場合、インダイレクションは、Enterprise Beanの非アクティブ化およびアクティブ化に影響を及ぼさず、同じJVM内の永続性マネージャ間でのデタッチおよびアタッチにも影響を及ぼしません。ただし、1つのJVMから別のJVM（たとえば、サーバーからクライアント）にインダイレクション対応EJB 3.0 Beanをシリアライズすると、トリガーされていないインダイレクション・オブジェクトがデシリアライズ時にnull値として表示されます。これを回避するため、OC4Jで使用されるJavaエージェントと同じエージェントを使用するようクライアントを構成します（「OC4JでのEJB 3.0使用時のValueHolderインダイレクションの構成」を参照）。 |
デフォルトでは、TopLinkは直接アクセスを使用して一般的な属性にアクセスします。TopLinkを使用して、プロジェクト・レベル（「プロジェクト・レベルでのマッピングされたフィールド・アクセスの構成」を参照）とメソッド・レベル（「メソッド・アクセスの構成」を参照）でフィールド・アクセスを構成できます。
既存のTopLinkマッピングがニーズを満たしていない場合、マッピングの拡張機能を使用してカスタムのマッピングを作成できます。これらの拡張機能は、次のとおりです。
|
注意: データ・ソースがリレーショナルかリレーショナルでないかにかかわらず、マッピング・コンバータおよびトランスフォーマを使用できます。 |
シリアライズ・オブジェクト・コンバータは、Javaオブジェクト・シリアライズを介して複雑なオブジェクトをバイナリ・フィールドにマップできるダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能です。シリアライズされたオブジェクトは、通常、データベースのRAWまたはバイナリ・ラージ・オブジェクト（BLOB）フィールド、またはXML文書のHEXまたはBASE64要素に格納されます。
図30-6は、シリアライズ・オブジェクト・コンバータを使用したフィールドへ直接マッピングの例を示しています。属性jobDescriptionには、データベースのJOB_DESCフィールドに格納される、書式設定されたテキスト文書が含まれています。
図30-7は、シリアライズ・オブジェクト・コンバータを使用したリレーショナルではないマッピングの例を示しています。属性jobDescriptionには、TopLinkによってXMLスキーマのJOB DESCRIPTION要素に格納される、書式設定されたテキスト文書が含まれています。
シリアライズ・オブジェクト・コンバータは、Javaシリアライザを利用します。ドメイン・オブジェクトをシリアライズ・オブジェクト・コンバータでマップする前に、ドメイン・オブジェクトにjava.io.Serializableインタフェースが実装され（または実装が継承され）、シリアライズされていないすべてのフィールドにtransientがマークされていることを確認してください。
詳細は、「シリアライズ・オブジェクト・コンバータの構成」を参照してください。
タイプ変換コンバータは、データ・ソースのタイプをJavaのタイプに明示的にマップできるダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能です。たとえば、データ・ソースのNumberは、JavaのStringにマップできます。または、Javaのjava.util.Dateは、データ・ソースのjava.sql.Dateにマップできます。
図30-8に、タイプ変換マッピング（リレーショナル）の例を示します。java.util.Dateクラスは、デフォルトではTimestampとしてデータベースに格納されるため、そのクラスは、まず、java.sql.Dateのような明示的なデータベース・タイプに変換する必要があります（これはDB2に対してのみ必須であり、その他の大部分のデータベースには、任意の日付または時間を格納できる単一日付のデータ・タイプがあります）。
図30-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タイプに変換するには、トランスフォーメーション・マッピングを検討してください（「トランスフォーメーション・マッピング」を参照）。
詳細は、「タイプ変換コンバータの構成」を参照してください。
オブジェクト・タイプ・コンバータは、一定数のXML値をJavaオブジェクトに対応させることができるダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能です。このコンバータは、スキーマにある値がJavaにある値と異なる場合に使用します。
図30-10は、Employee属性のgenderとXML要素のgenderとの間のオブジェクト・タイプの変換を示しています。Javaのオブジェクト属性の値がFemaleの場合、TopLinkではその値がFとしてXML要素に格納されます。
詳細は、「オブジェクト・タイプ・コンバータの構成」を参照してください。
シンプル・タイプ・トランスレータは、ダイレクト・マッピングおよびダイレクト・コレクション・マッピングの拡張機能であり、XMLスキーマで定義したとおり、要素の<type>属性に基づいて、XML要素の値を適切なJavaタイプに自動的に変換できます。
シンプル・タイプ・トランスレータは、マッピングのXPathがテキスト・ノードを指定している場合にのみ使用できます。シンプル・タイプ・トランスレータは、マッピングのXPathが属性を指定している場合は使用できません。
シンプル・タイプ・トランスレータを使用すると、XML文書の保持タイプ情報を作成できます。これは、java.lang.Integerまたはjava.util.Calendarなど、特定オブジェクト属性の場合とは異なり、java.lang.Objectおよびjava.io.Serializableなどの汎用オブジェクト属性がTopLinkで特定のタイプ変換をトリガーしないため、オブジェクト・モデルで汎用オブジェクト属性を指定する際に役立ちます。
図30-11は、PhoneNumberクラスのnumber属性のタイプ変換XMLマッピングを示しています。Java属性は、タイプの保持に必要な具体的な情報が不足している点に注意してください。シンプル・タイプ・トランスレータでは、タイプを保持するためにタイプ情報を結果の文書に追加します。
デフォルトでは、TopLinkでは組込みの読取りおよび書込み変換ペアが使用されます（「デフォルトの読取り変換」および「デフォルトの書込み変換」を参照）。
独自のシンプル・タイプ・トランスレータの指定および構成によってこの動作をオーバーライドして、たとえば、XMLバイナリ・データをBase64として書き込むことができます。
詳細は、「シンプル・タイプ・トランスレータの構成」を参照してください。
表30-2は、XML要素を読み取るための、組込みの変換ペアのリストを示しています。スキーマ<type>属性が指定され、シンプル・タイプ・トランスレータが有効な場合、読み取られた値は対応するJavaタイプに変換されます。
表30-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つのコンポーネントで構成されています。
属性トランスフォーマ（「属性トランスフォーマの構成」を参照）: 読取り時（アンマーシャリング時）にオブジェクトの属性トランスフォーメーションを実行
フィールド・トランスフォーマ（「フィールドとトランスフォーマ関連付けの構成」を参照）: 書込み（マーシャリング）時にオブジェクト属性とフィールド間のトランスフォーメーションを実行
トランスフォーマは、別個のクラスまたはドメイン・オブジェクトでのメソッドのいずれかとして実装できます。
属性およびフィールド・トランスフォーマの実装時には、アプリケーション・データをデータ・ソースに、またはその逆に適合させるための変換に必要な、どのような処置も講じることができます。
詳細は、次を参照してください。
TopLinkでは、Xpath文を使用して、XMLレコードへのEISマッピングおよびXML文書へのXMLマッピングで、Javaオブジェクトの属性を効率的にマップします。このようなマッピングを作成する場合、次を指定できます。
リレーショナル・データベース表では、列は名前により一意に識別されます。XML文書では、要素は名前および位置により一意に識別されます。図30-12は、street要素の最初のインスタンスが建物の情報を格納し、street要素の2番目のインスタンスが番地の情報を格納しているXML文書へのマッピングの例を示しています。図30-12は、マッピングが永続され、ならびにstreet[2]/text()のようなXpathを使用しJavaオブジェクト属性をXML要素に位置によってマップできる順序をTopLink XMLマッピングが保持していることを示しています。
他のXMLテクノロジでは、XML要素の位置ではなく、名前を認識するのみのため、コレクションにある同じ名前の要素から単純な値を格納する必要があります。
XML文書では、属性および要素は名前とパスの組合せにより一意に識別されます。図30-13では、TopLink XMLマッピングではitem/name/text()のようなXPathにより、名前とパスでXML要素を一意に識別できる例を示しています。TopLinkでは、XML要素linesとitemとの間の正規のオブジェクト・リレーションシップは必要ありません。
その他のXMLテクノロジでは、すべてのネスト・レベルにオブジェクト・リレーションシップを指定する必要があり、その結果、この制限を満たすため、単なるデータの編成に多くのXML要素とクラスが必要になります。これにより、ドメイン領域を適切に反映していない、不要で大きなオブジェクト・モデルを生成することになります。
単純なXML文書については、TopLink XMLマッピングでは、属性または要素の名前のみのXPathの指定によってデータをXML文書に正確に配置できます。
図30-14は、名前による単純なXML文書へのマッピングの例を示しています。@NAMEのみのXPathの指定によって、Javaオブジェクト属性nameをXML属性nameにマップできます。同様に、AGEのみのXPathの指定によって、Javaオブジェクト属性ageをXMLテキスト・ノードAGEにマップできます。
名前でXPathを指定すると、XPathマッピング・オプションのパフォーマンスが最も低下します。そのかわりに、位置によるXPath（「位置によるXPath」を参照）またはパスと名前によるXPath（「パスと名前によるXPath」を参照）の使用をお薦めします。
コンポジット・リレーションシップでは、TopLink XMLマッピングは、自己XPath（"."）の指定のある親にネストした要素ではなく、親の要素にデータを配置できます。
図30-15は、自己XPathを使用したXML文書へのマッピングの例を示しています。
図30-15で示される前述の例の場合、Employeeクラスのname属性は、注釈@nameを使用してマップされます。
自己XPathを使用することにより、親にネストした要素ではなく、親の要素でのすべての読取りおよび書込みをTopLinkで実行できるようにします（「マッピングおよびjaxb:classカスタマイズ」を参照）。
TopLinkでは、次の表30-4で示されているように、XMLレコードへのEISマッピングおよびXML文書へのXMLマッピングで、xsd:listおよびxsd:unionタイプへのマッピングをサポートしています。
表30-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に従って変換します。
詳細は、「XMLダイレクト・マッピングによるunionフィールドへのマッピング」を参照してください。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（「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レコードで使用）またはXMLDirectMappngを使用して、この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タイプへのマッピングに関する詳細は、「XMLダイレクト・マッピングによるlistフィールドへのマッピング」を参照してください。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（「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を試行します。
詳細は、「XMLコンポジット・ダイレクト・コレクション・マッピングによるlistOfUnionsマッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeDirectCollectionMappingにも適用されます（「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を使用します。
詳細は、次を参照してください。
「XMLダイレクト・マッピングによるunionOfListsマッピング」。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（「EISダイレクト・マッピング」を参照）。
「XMLコンポジット・ダイレクト・コレクション・マッピングによるunionOfListsマッピング」。同じことがXMLレコードを使用するEISCompositeDirectCollectionMappingにも適用されます（「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のいずれかが含まれている可能性があることに注意してください。
詳細は、「XMLダイレクト・マッピングによるunionOfUnionsマッピング」を参照してください。同じことがXMLレコードを使用するEISDirectMappingにも適用されます（「EISダイレクト・マッピング」を参照）。
jaxb:classカスタマイズを使用すると、スキーマから生成された実装クラスのアプリケーション固有のサブクラスを宣言で指定できます。これにより、JAXBの生成済実装クラスを拡張する独自のクラスを書き込むことができます。その結果、JAXBランタイム・バインディング・フレームワークのサブクラスへのアクセスが可能になります。
XMLレコードへのEISコンポジット・オブジェクト・マッピングまたはXML文書へのXMLコンポジット・オブジェクト・マッピングを作成すると、次のXSD構造を使用してjaxb:classカスタマイズに対応するため、マッピングのXPath（「XPathの構成」を参照）を構成できます。
jaxb:classカスタマイズ構造へのマッピング時には、このカスタマイズに対するTopLinkサポートの制限を考慮してください（「jaxb:classカスタマイズ・サポートの制限」を参照）。
jaxb:classカスタマイズは、all、choiceまたはsequence構造で使用できます。例30-1は、all構造のjaxb:classカスタマイズを示しています。
例30-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属性をこのインナー・クラスにマップします。
詳細は、「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、例30-2で示されているように、group構造で使用できます。
例30-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属性をこの外部ラッパー・クラスにマップします。
詳細は、「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、groupを含むsequenceまたはchoice構造で使用できます。例30-3は、group構造を含む、sequence構造のjaxb:classカスタマイズを示しています。
例30-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属性をこのインナー・クラスにマップします。
詳細は、「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、sequenceまたはchoiceを含むgroup構造で使用できます。例30-4は、sequence構造を含む、group構造のjaxb:classカスタマイズを示しています。
例30-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属性をこの外部ラッパー・クラスにマップします。
詳細は、「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（「EISコンポジット・オブジェクト・マッピング」を参照）。
jaxb:classカスタマイズは、例30-5に示すように、別のgroup構造を含むgroup構造で使用できます。
例30-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属性をこれらのラッパー・クラスにマップします。
詳細は、「XMLコンポジット・オブジェクト・マッピング」を参照してください。同じことがXMLレコードを使用するEISCompositeObjectMappingにも適用されます（「EISコンポジット・オブジェクト・マッピング」を参照）。
カスタマイズ構造へのマッピングの場合、次の制限を考慮してください。
バインドされていない構造はサポートされていません。
部分検証はサポートされていません。
sequence要素をコンポジット・オブジェクトにマッピングする場合、XMLスキーマでは、コンポジット・オブジェクトへマップする要素が一緒に維持されるように要素を順序付ける必要があります。
sequence構造では、XMLスキーマで指定された順序でそのすべての要素が発生するよう強制されます。例30-6で示すXMLスキーマを検討してください。有効なXMLインスタンスには、sequence要素を指定した順序で含める必要があります。
street、customerName、city
この例では、ダイレクト・マッピングを使用してcustomerName属性をマップし、streetおよびcity属性をコンポジットAddressオブジェクトにマップしようとしています。マッピングを定義する順序に応じて、TopLinkでは、無効なXML文書インスタンスを次の順序でマーシャリングします。
customerName、street、city
または
street、city、customerName
例30-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スキーマを変更して（例30-7を参照）、XMLスキーマで指定した順序でマッピングを定義します。
JAXBは、xsd:NCNameから導出され、enumerationファセットを持つbasetypeを使用して、型保証列挙クラスを名前付きの単純なタイプ定義にバインドします（例30-8を参照）。
例30-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属性をこのような列挙にマップできます。
TopLink Workbenchでは、JAXBTypesafeEnumConverterを使用するマッピングの構成で、このコンバータを直接サポートしていないため、ディスクリプタ修正メソッドを使用する必要があります（「JAXB型保証列挙コンバータの構成」を参照）。
プロジェクトおよびオブジェクト・モデルをTopLink JAXBコンパイラを使用して作成する場合（「XMLスキーマからのXMLプロジェクトの作成」を参照）、コンパイラでは型保証列挙クラスおよびディスクリプタ修正メソッドのあるクラスが作成され、必須修正メソッドが自動的に登録されます（「DescriptorAfterLoadsクラスに対する型保証列挙コンバータの修正メソッド」を参照）。
すべてのマッピング・クラスは、DatabaseMappingクラスから導出されます。
表30-5 プラットフォームとマッピング・パッケージの互換性
| プラットフォーム | マッピング・パッケージ |
|---|---|
|
リレーショナル・プロジェクト用 |
|
|
EISプロジェクト用 |
|
|
XMLプロジェクト用 |
|
リレーショナル・マッピングは、オブジェクトのデータ・メンバー・タイプを、サポートされているリレーショナル・データベースの対応するリレーショナル・データベース（SQL）のデータ・ソース表現に変換します。リレーショナル・マッピングを使用すると、オブジェクト・モデルをリレーショナル・データ・モデルにマップできます。
また、リレーショナル・マッピングは、データベースの別の表に格納され、外部キーを介して関連付けられている他のドメイン・オブジェクトを参照するオブジェクト・データ・メンバーも変換できます。
リレーショナル・マッピングは、リレーショナル・プロジェクトで使用します。詳細は、「リレーショナル・プロジェクト」を参照してください。
リレーショナル・マッピングの詳細は、第33章「リレーショナル・マッピングの概要」および第34章「リレーショナル・マッピングの構成」を参照してください。
|
注意: リレーショナル・マッピングとオブジェクト・リレーショナル・マッピングは混同しないでください（「オブジェクト・リレーショナル・マッピング」を参照）。オブジェクト・リレーショナル・マッピングは、特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データベースでの格納に最適化された構造化データ・ソース表現に変換します。オブジェクト・リレーショナル・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・データ・モデルにマップできます。通常、リレーショナル・マッピングは、サポートされているすべてのリレーショナル・データベースで使用できます。オブジェクト・リレーショナル・マッピングは、オブジェクト・データ・ソース表現をサポートするために最適化された特別のオブジェクト・リレーショナル・データベースにのみ使用できます。 |
TopLinkでは、次のリレーショナル・マッピングを提供します。
オブジェクト・リレーショナル・マッピングは、特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データベースでの格納に最適化された構造化データ・ソース表現に変換します。オブジェクト・リレーショナル・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・データ・モデルにマップできます。
オブジェクト・リレーショナル・マッピングは、リレーショナル・プロジェクトで使用します。詳細は、「リレーショナル・プロジェクト」を参照してください。
オブジェクト・リレーショナル・マッピングの詳細は、第46章「オブジェクト・リレーショナル・マッピングの概要」および第47章「オブジェクト・リレーショナル・マッピングの構成」を参照してください。
|
注意: オブジェクト・リレーショナル・マッピングとリレーショナル・マッピングは混同しないでください（「リレーショナル・マッピング」を参照）。リレーショナル・マッピングは、オブジェクトのデータ・メンバー・タイプを、サポートされているリレーショナル・データベースの対応するリレーショナル・データベース（SQL）のデータ・ソース表現に変換します。リレーショナル・マッピングを使用すると、オブジェクト・モデルをリレーショナル・データ・モデルにマップできます。通常、リレーショナル・マッピングは、サポートされているすべてのリレーショナル・データベースで使用できます。オブジェクト・リレーショナル・マッピングは、オブジェクト・データ・ソース表現をサポートするために最適化された特別のオブジェクト・リレーショナル・データベースにのみ使用できます。 |
TopLinkでは、次のオブジェクト・リレーショナル・マッピングを提供します。
XMLマッピングは、オブジェクトのデータ・メンバーを、構造がXMLスキーマ・ドキュメント（XSD）により定義されているXMLファイルのXML要素に変換します。
XMLマッピングは、XMLプロジェクトで使用します。詳細は、「XMLプロジェクト」を参照してください。
XMLマッピングの詳細は、第62章「XMLマッピングの概要」および第63章「XMLマッピングの構成」を参照してください。
TopLinkでは、次のXMLマッピングを提供します。
EISマッピングでは、オブジェクトのデータ・メンバーをオブジェクトのディスクリプタで定義されたEISレコード形式に変換します。
EISマッピングは、EISプロジェクトで使用します。詳細は、「EISプロジェクト」を参照してください。
EISマッピングの詳細は、第53章「EISマッピングの概要」および第54章「EISマッピングの構成」を参照してください。
TopLinkでは、次のEISマッピングを提供します。
