JavaにおけるO/Rマッピング：Hibernateで理解するO/Rマッピング（2）

JavaでのO/Rマッピングの仕組み

本記事は、「ITアーキテクト」と＠ITの各フォーラムが展開する、分析／設計工程に焦点を絞った『ITアーキテクト連動企画』記事です。

　前回「O/Rマッピングの役割とメリット」では、データベースに関する処理を簡易にするO/Rマッピングの役割とメリットについて解説しました。今回は、JavaでO/Rマッピングを行う際の具体的な仕組みを解説します。さらに、Entity Beanとの比較、Javaにおける標準的なデータアクセス仕様としてサン・マイクロシステムズ（以下、サン）が提供しているJDOにも触れ、O/Rマッピングへの理解を深めることにします。

　 O/Rマッピングでは、データベースのレコードをデータマッピングクラスの1つのインスタンスとして扱います。そして、JavaのO/Rマッピングでは、具体的には、フィールドに対応するsetter/getterメソッドを持つクラスを介してデータベースのテーブルを扱います。O/Rマッピングを利用することによって、フィールドにデータを保持したオブジェクトをそのまま保存したり、データをJavaクラスのインスタンスとしてまとまった形で取り出したりすることができます。またsetter/getterメソッドを持つクラスの形式はJavaBeansの標準的な規約でもあり、JakartaプロジェクトのCommonsサブプロジェクトで開発されている「BeanUtils」など、サードパーティによって開発されたユーティリティやフレームワークを利用する際に便利です。

図1　O/Rマッピングのイメージ

Entity Beanの問題点は？

　ところで、Javaを使ってエンタープライズアプリケーションを開発する技術者にとって、最も聞き覚えのあるO/RマッピングソリューションはEntity Beanではないでしょうか。Entity BeanはEJB（Enterprise Java Beans）の仕様で定義されるEnterprise Beanの一種で、EJBオブジェクトによってデータエンティティを表現します。また、Entity BeanではEJB QLというクエリ言語を用いて、リレーショナルデータベースのレコードをEJBオブジェクトの形式で取得することができます。

　また、EJBには「コンテナによるトランザクション管理」の機能があります。Entity Beanの1つであるCMP（Container Managed Persistence）では、このEJBのトランザクション管理機能を使って自動的なトランザクション処理を実現しています。

　Entity Beanは、「インピーダンスミスマッチ」を軽減するO/Rマッピングの実装であり、かつ「トランザクション管理」や「セキュリティ管理」など多くの機能を実現します。またEJB 2.0以来パフォーマンスの問題点なども大きく改善されました。いまやEJBはJ2EEの中心的な仕様として普及しており、非常に強力で優れたテクノロジです。しかしEJBの仕様に含まれている「Entity Bean」はさまざまな議論を呼ぶ問題児とされることもあります。

　具体的に「Entity Bean」には以下のような問題点があります。

　Entity Beanのこうした問題点はJ2EE開発者の間ではよく知られており、これらの問題点を解決・回避するための議論が多くなされてきました。さらにEJB 2.0ではBeanへのローカルアクセスを可能にするなど大幅な改善がなされました。今後もEntity Beanは改善・発展を続けることでしょう。しかしEJBは根本的にO/Rマッピングとは別の問題領域に対するソリューションとして策定された仕様です。「EJBの仕様に付随したO/Rマッピング」ではなく、純粋なO/Rマッピングソリューションが求められているという事実もあります。こういった理由によりO/Rマッピングを処理するサードパーティ製のソリューションが注目されています。またサンの仕様としてもJDO（Java Data Objects）というO/Rマッピングを扱うことができるAPIが策定され、大きな関心を集めています。

サンのO/Rマッピング仕様「JDO」

　JDO（Java Data Objects）は、リレーショナルデータベースやオブジェクトデータベースを含むEIS（Enterprise Information System）全般に対するデータの永続化機能と、オブジェクトによる透過的なビューに関するAPIを提供しています。

　JDOではAPIのみを定義しているため、その実装はベンダに委ねられています。サンのサイトではJDO 1.0のReference Implementation（RI）が公開されており、またいくつかのO/RマッピングフレームワークはJDOのAPIを実装しています。JDOに準拠したO/Rマッピングフレームワークには以下のようなものがあります。

　JDOが提供するO/Rマッピングの仕組みはサーバには依存しないため、ローカルアプリケーションでのデータアクセスに使用できます。単体テストに際してもほかのJavaクラスと同じようにローカル環境で簡単にテストが行えます。

　またJDOでは永続化に使用するオブジェクトを通常のJavaオブジェクトに近いオブジェクトとして扱います。重厚なメソッドやフィールドを持ったインターフェイスやベースクラスを実装しません。これによりEntity Beanよりもインスタンス生成時のオーバーヘッドを軽減することができます。このことはたくさんのインスタンスを扱わなくてはならないO/Rマッピングでは重要な点となります。

　またJDOは、オブジェクトとリレーショナルデータベースとのマッピングのみではなく、以下のようなEIS全般に対してオブジェクトを永続化するためのAPIを定義しています。

　JDOのアーキテクチャを図2「JDOのアーキテクチャ」に表しました。JDOでは、図中の「PersistenceManagerFactory」「PersistenceManager」「PersistenceCapable」「Query」「Transaction」といったインターフェイスを定義しています。

図2　JDOのアーキテクチャ

　それぞれのインターフェイスは、以下の役割を担います。

PersistenceManager：
JDOアーキテクチャの中心でありPersistenceManagerの各種のメソッドによって、オブジェクトの永続化や取得を行います。QueryインターフェイスやTransactionインターフェイスのインスタンスを返すFactoryの役目もあります。

PersistenceManagerFactory：
PersistenceManagerのインスタンスを生成するためのFactoryの役目を果たします。

PersistenceCapable：
永続化オブジェクトに実装されるべきメソッドを定義します。JDOではこのインターフェイスを実装したオブジェクトを永続化オブジェクトとして扱います。ただしプログラマはPersistenceCapableインターフェイスを意識する必要はありません。PersistenceCapableインターフェイスで定義されたメソッドは、実行時にJDOベンダが提供する「Enhancer」によってコンパイル済みのクラスにバイトコードレベルで追加されます（図2「JDOのアーキテクチャ」図3「JDOの永続化クラス」を参照してください）。

図3　JDOの永続化クラス

Query：
JDOで使用するクエリであるJDOQLを処理するインターフェイスです。PersistenceManager インターフェイスに実装されたnewQuery()メソッドを使用してインスタンスを取得します。

Transaction：
トランザクションのbegin、commit、rollbackを扱うインターフェイスです。PersistenceManager インターフェイスに実装されたcurrentTransaction()メソッドを使用してインスタンスを取得します。

　リレーショナルデータベースなどのEISとJavaクラス間のマッピング定義は、ベンダに任されておりJDOでは定義していません。JDOはクラスの属性を永続化するかどうかを記述するマッピングファイルを用意しています。

　JDOはO/Rマッピングを解決するという部分でEntity Beanと重なる問題領域を扱っています。現在JDOはJ2EEの仕様に含まれていませんが、今後はJ2EEに取り込まれる可能性も否定できません。またJDOはEntity Bean以外のEJBの仕様とは補完関係にあります。しかしながら、現時点ではまだ大幅な改善が予想されるために仕様の準拠を見合わせるベンダも多いようです。そういう意味では未完成な仕様ですが、今後非常に重要なテクノロジとなっていくことは間違いないでしょう。

さまざまなO/Rマッピングフレームワーク

　Javaのサードパーティによって、O/Rマッピングフレームワークが数多く開発されています。以下に紹介するサイトでも多くのO/Rマッピングフレームワークが紹介されています。

　サードパーティ製のO/Rマッピングフレームワークは、Entity Beanの代替として十分に機能するソリューションであることが求められます。そうでなければ多少の問題点に目をつぶってでもJ2EEという強力な「標準」であるEntity Beanを使う方が、メリットがあるでしょう。このためサードパーティ製のO/Rマッピングを選択する際には、Entity Beanのメリットを押さえていることが重要になります。まずは次のような要件を考慮してみましょう。

　次にEntity Beanの問題点がカバーできていることが求められます。

　また、今後重要なテクノロジとして注目されているJDOの仕様に準拠している、あるいは準拠する予定があるということが選択の基準として重要になります。

　O/Rマッピングに関するテクノロジは従来のデータベースアプリケーションの開発に効率アップをもたらす仕組みであり、非常に注目を集めています。J2EEが提供するEntity Beanは、シンプルなO/Rマッピングのみのソリューションには少し重たいのではないでしょうか。そのためサードパーティ製のO/Rマッピングフレームワークが数多く提供されており、またデータアクセスの標準的なAPIとなるJDOという仕様がサンから提供されています。

　次回からはオープンソースのO/Rマッピングフレームワークを利用して簡単なサンプルプログラムを作成し、O/Rマッピングを使ったデータベースアクセスを実際に体験していきましょう。