JavaにおけるO/Rマッピング：Hibernateで理解するO/Rマッピング（2）
O/Rマッピングは、従来の煩雑なデータベースに関する処理の記述をスマートにし、柔軟なアプリケーションの構築を可能にします。本連載ではオープンソースのO/Rマッピングフレームワーク「Hibernate」を用いてO/Rマッピングの基礎を解説します。そしてさらに、J2EEアプリケーションへの実践的な適用方法とそのメリットも紹介していきます。（編集局）
JavaでのO/Rマッピングの仕組み
前回「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」には以下のような問題点があります。
【問題1】シンプルなO/Rマッピングソリューションではない
EJBは本来「分散コンポーネント」を作成するための仕様として策定されたため、処理コストの高い分散ネットワーキングの機能を持っています。
また、O/Rマッピングではデータベースの1レコードにつき、1つのインスタンスを生成することになりますが、重厚なEntity Beanオブジェクトのインスタンスを多数生成することによってサーバリソースの著しい消費が懸念されます。
さらにEJBの仕様として、デプロイのためのいくつかの決まり事が存在します。例えば1つのEntity Beanを作成するために最低でも2つのインターフェイスと1つのデプロイメントディスクリプタを用意しなければなりません。
確かに、EJBが持つ分散ネットワーキングやトランザクション管理などの機能とO/Rマッピングとを組み合わせることで、強力なビジネスコンポーネントを作り出すことが可能です。しかし単純にO/Rマッピングの処理を行いたいだけのために、この重厚なアーキテクチャを適用するまでもないでしょう。そういった意味でO/RマッピングはEJBと切り離された方が、シンプルで扱いやすいソリューションとなるのではないかという議論も行われています。
【問題2】デプロイとテストにかかわる煩雑さ
Entity Beanを作成して実行するためにはEJBコンテナへのデプロイが必要となります。このデプロイ方法は各ベンダの提供するサーバ製品によって異なり、単純にJavaのクラスを作成して実行するのに比べると、手間の掛かる作業でもあります。また大規模なシステムでEntity Beanを利用するとなると、生成されるBeanの数はかなりのものになり、デプロイにかかる時間も長くなってしまいます。
デプロイが煩雑であることとEJBコンテナ外で使用できないことによって影響を受けるのがプログラムテストの容易性です。Entity Beanを使用するアプリケーションではローカルでのプログラムテストが困難になります。JakartaにCactusというWebアプリケーションのためのテスティングフレームワークが存在しており、これを利用することでローカルでの単体テストが可能です。しかし、通常の単体テストに比べてテストが複雑になることに変わりはありません。単体テストの容易性は「インピーダンスミスマッチ」の問題以上に開発効率に影響する可能性があります。
【問題3】SQLの確認が困難
Entity Beanではコンテナによって自動的にSQLが発行されます。しかし、コンテナが自動的に発行するSQLがどのようなものかを調べ、それを調整するのは容易ではありません。不適切なSQL文の発行は、致命的なパフォーマンスダウンを引き起こすこともあります。簡単な問い合わせならともかく、複雑なモデル間のマッピングを処理するO/Rマッピングにとって「どのようなSQL文が発行されているか」を確認することは非常に重要な作業です。
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を定義しています。
- リレーショナルデータベース
- オブジェクトデータベース
- ERP システム（SAP/R3など）
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の永続化クラス」を参照してください）。
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のメリットを押さえていることが重要になります。まずは次のような要件を考慮してみましょう。
- O/Rマッピングの基本的な要件を満たしていること （オブジェクトの透過的な永続化）
- トランザクションの管理が、Entity Beanと同等の信頼性を持ち、Entity Beanと同等の容易性を持っていること（J2EEのトランザクションAPIであるJTAにトランザクション処理を委譲できることが好ましい）
次にEntity Beanの問題点がカバーできていることが求められます。
- 通常のJavaオブジェクトが使用できること
- SQLの調整が容易であること
- SQLに標準で備わっている結合や集計といった機能に対して制限が少ないこと
- デプロイが容易であること
- EJBコンテナ外でも実行可能であること
また、今後重要なテクノロジとして注目されているJDOの仕様に準拠している、あるいは準拠する予定があるということが選択の基準として重要になります。
O/Rマッピングに関するテクノロジは従来のデータベースアプリケーションの開発に効率アップをもたらす仕組みであり、非常に注目を集めています。J2EEが提供するEntity Beanは、シンプルなO/Rマッピングのみのソリューションには少し重たいのではないでしょうか。そのためサードパーティ製のO/Rマッピングフレームワークが数多く提供されており、またデータアクセスの標準的なAPIとなるJDOという仕様がサンから提供されています。
次回からはオープンソースのO/Rマッピングフレームワークを利用して簡単なサンプルプログラムを作成し、O/Rマッピングを使ったデータベースアクセスを実際に体験していきましょう。
筆者紹介
山本 大（やまもと だい）
株式会社クロノスに勤務するITアーキテクト。甲南大学 経営学部 卒業。J2EE、.NETにこだわらずベストソリューションを提供できるマルチプラットフォームアーキテクトを目指す。『XMLマスター教科書 プロフェッショナル』（翔泳社）や雑誌などで執筆活動も行っている。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。