連載
» 2005年03月10日 00時00分 公開

JavaのDBアクセスを極める(2):O/Rマッピングで失敗しない分析・設計のポイント (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 今回の解説範囲  図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生成してしまっているケース 図2 ビジネスロジック・レイヤでSQL生成してしまっているケース
図3 物理データモデルとビジネスデータモデルが完全に同一のケース 図3 物理データモデルとビジネスデータモデルが完全に同一のケース

次ページへ続く)

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。