O／Rマッピングで失敗しない分析・設計のポイント：JavaのDBアクセスを極める（2）（1/3 ページ）

Webシステムが主流となり、データベース・アプリケーションはJavaやC#といったオブジェクト指向言語で開発することが多くなった。しかし、データベース設計はオブジェクト指向モデルとうまくかみ合わず、データモデル設計に苦労するエンジニアは少なくない。本連載は、オブジェクト指向モデルとデータベースモデルのインピーダンスミスマッチに対応するテクニックを紹介する。（編集局）

[諏訪勇紀 著, 安間裕 監修，アクセンチュア・テクノロジー・ソリューションズ]

はじめに

　前回（第1回）の「JavaとDBのデータモデルはナゼすれ違う？」では、概要としてJavaでのデータベース・アクセスにおける代表的な問題や疑問およびJavaとデータベースとのアプローチの違いによるインピーダンスミスマッチ発生の背景を解説しました。第2回以降では、第1回で紹介したJavaでのデータベース・アクセスに関する問題／疑問に焦点を当て、Javaでデータベース・アクセスに関する設計および実装をされる開発者に、その解決への糸口を示していくことができればと考えています。

　今回は以下に示したような、データベース・アクセス分析・設計を行ううえで遭遇し得るO／Rマッピングに関連した問題の解決方法を説明します。

　問題（1）「テーブル構成変更に伴う思わぬ修正範囲の拡大」

データベースのテーブル構成を変更したら、SQL文を広範囲にわたって修正するだけでなく、ビジネスロジック側も広範囲に修正する必要が生じてしまった。このようなことが起きないようにするには、どうしたらよいのだろうか。

　問題（2）「インピーダンスミスマッチのあるデータモデルのマッピング」

ビジネス・アプリケーションの世界としてのデータモデルとデータベースの世界としてのデータモデルをどうやってうまくマッピングさせればよいのだろうか。

今回解説する範囲およびその概要

　O／Rマッピングに関連する問題（1）および問題（2）における解決法を解説するうえで、対象となる範囲を「設計フェイズ」および「実装フェイズ」での作業項目に当てはめると、図1のようになります。なお、一見するとO／Rマッピングと関連性がないように思われる「レイヤ間インターフェイス設計」は、実は非常に密接に関連がある設計項目であるため、解説範囲に含めます。

　図1　今回の解説範囲

　さらに、今回取り上げる2つの問題に関しての解説概要を表1に示します。

問題（1）における解決へのアプローチ	問題（1）の解決法に関連する設計項目として「レイヤ間インターフェイス設計」を取り上げ、解決策となり得るデータベース・アクセスにおけるビジネスロジック・レイヤとデータベースレイヤ間の最適なインターフェイス設計を行うためのポイントを解説します
問題（2）における解決へのアプローチ	問題（2）の解決法に関連する設計・実装項目として「O／Rマッピング設計」と「O／Rマッピング実装」を取り上げ、解決策となり得るO／Rマッピング・フレームワークを使用したソリューションの概要および各種O／Rマッピング・フレームワークの比較を解説します
表1　問題ごとの解説概要

問題（1）における解決へのアプローチ

　それでは、まず問題（1）「テーブル構成変更に伴う思わぬ修正範囲の拡大」について説明しましょう。

1. 問題（1）の発生要因

　問題（1）で最大の問題点は、「ビジネスロジック側にも広範囲に修正する必要が発生したこと」です。これが発生した要因を考えてみましょう。設計方針がバラバラで、かつその設計に従って実装した結果、煩雑なアプリケーションになってしまった可能性があります。筆者の経験を基に分析すると、発生要因として以下のような項目が考えられます。

• システム分析時にレイヤ分割して役割・責任の範囲をある一定レベルまで定義したが、厳密な部分まで定義しきれなかった。
• 上記の各レイヤの役割・責任範囲のあいまいさから、ビジネスロジック・レイヤ内のクラスの処理で、データベース接続などのトランザクション処理のみデータベース・レイヤのクラスを使用し、本来データベース・レイヤのクラスが役割を担うべきSQLの生成処理を実装している個所がある（図2）。
• ビジネスロジック・レイヤが扱うデータモデルと、データベース・レイヤが扱う物理データベース上のデータモデルとが完全に一致してしまっているケースがある。そのため、テーブル構成の変更に伴い、ビジネスロジックが扱うエンティティ・クラスまで変更を行う必要が生じてしまう（図3）。
• ビジネスロジック・レイヤとデータベース・レイヤ間のデータ問い合わせ用のインターフェイスが汎用的な設計になっていない（授受するクラスの型が固定である／すべてのビジネスロジックの機能単位に1対1でDAOのインターフェイスが実装されている、など）ものがある。そのため、レイヤ間で渡されるエンティティに修正が発生した場合、双方のインターフェイス処理部分にも修正が発生してしまう。

図2　ビジネスロジック・レイヤでSQL生成してしまっているケース

図3　物理データモデルとビジネスデータモデルが完全に同一のケース

（次ページへ続く）