TOP＞プロジェクト管理＞ 業務システムの現状
データ指向アプローチ
DOAとは何か！〜開発現場から見るDOA〜

第２回：正規化されたRDBとJavaによるデータアクセス
著者：システムズ・デザイン  DOA推進ワークショップ   2007/3/1
1   2  3  次のページ
業務システムの現状

   近年、基幹系業務システムの形態として、Webアプリケーションが定着してきました。システム構造の変化としては、ホストによる中央集中からクライアントサーバ（以下、C/S）での分散化が進み、そして現在ではデータ／ビジネス／ユーザの各サービスを分担するアプリケーションを使用した「3階層アーキテクチャ」が主流となっています。

   またプログラミング言語は、環境に依存せず拡張性の高いJavaが定着し、良くも悪くも「第2のCOBOL」といわれるほど目覚ましい普及を遂げています。しかし、データベースだけはC/Sの時代から大きな変化はなく、依然としてリレーショナルデータベース（以下、RDB）が不動の地位を保持しています。
WebアプリケーションとRDBの課題から見えてくるもの

   これだけ普及しているJavaを活用したWebアプリケーションですが、データアクセスに関してはいまだベストな手法が確立されておらず、依然として高度な知識や煩雑なプログラミングが必要な状況です。これは技術者へ大きな負荷をかける原因となっています。

   では、なぜこのような状況になっているのでしょうか。
データ指向アプローチとオブジェクト指向の相性

   RDBによるデータベース設計の方法論として、データ指向アプローチ（以下、DOA）が広く普及しています。その一方、Webアプリケーションの開発ではオブジェクト指向プログラミングによる開発を行うJavaが主流となっています。

   DOAは、関数従属性によって正規形状態にあるデータ構造を導き出します。これに対して、データ／操作をカプセル化した「クラス構造」と重複がなく再利用性の高い「ポリモーフィズム」、継承に基づくプログラミングといった構成概念を持つオブジェクト指向との相性は本当に良いのでしょうか。それともDOAとオブジェクト指向は対立する概念なのでしょうか。

   筆者は、DOAとオブジェクト指向という個々の分野においてベストなもの同士の組み合わせこそが、逆に反発の要因になっていると考えています。そのどちらにも備わっている「変化に対して強い」という共通性が、様々な議論を生む争点になっているのではないでしょうか。

   歴史的な背景としてDOAは、プロセス中心アプローチのプログラム変更がデータ構造まで波及するという問題点に対峙にした際、変化の多いプログラムからデータ構造を独立させることを目的として生まれた方法論です。

   DOAが持つデータ独立という概念によって、関連するプログラムの特定が困難になったという新たな問題点が生じ、これに対してオブジェクト指向はプログラムとデータ構造を一体化させているというわけです。

   さらに、DOAは業務システム向け、オブジェクト指向は組み込みシステム向けというように、異なった領域で発展してきたという経緯も関係していると考えられます。
DOAとオブジェクト指向のデータアクセスでの問題点

   では実際にDOAとオブジェクト指向の組み合わせにおいて、データアクセス時の問題点にはどのようなものがあるか見てみましょう。
インピーダンスミスマッチ

   ここ最近よく目にする用語ですが、簡単にいうと「単純なデータ構造をもつRDBにオブジェクト指向言語の複雑なクラス構造を実装するとき、その構造の違いからすっきり収まらず、無理な部分が発生する」という問題です。

   RDBのデータ構造は行と列の2次元形式（表形式）で、テーブル同士の関係も外部キーで表現されます。一方オブジェクト指向のクラス構造は、オブジェクトが関連・集約という横の関係で他のオブジェクトへの参照を持つと同時に継承という縦の関係も有する、といった複雑な構造をあつかうことが可能です。

   そこで発生するのがインピーダンスミスマッチです。これを解決する方法の1つがO/Rマッピングです。詳細については以下の連載を参考にしてください。

徹底比較!!O/Rマッピングツール
http://www.thinkit.co.jp/free/article/0606/13/1/


人材の不足

   分析・設計・実装いずれの場面でも、現状のWebアプリケーション開発の現場では、DOAとオブジェクト指向の両方に精通している人材が必要となります。しかし、そのような人材はまだまだ不足しているといわざるを得ません。

   具体的には、分析・設計ではUMLによるオブジェクトモデリングとER図によるデータモデリング両方のスキルが必要です。また、データアクセスの実装では、テーブル定義に加えてクラス構造を正確に知っている必要があります。言語としては、JavaとSQL両方のエキスパートである必要があります。
本質的な問題

   筆者は実際の開発現場の中で「問題の本質は前述のスキルの問題ではなく、DOA技術者とオブジェクト指向技術者の対立にある」と感じています。それぞれの技術者の立ち位置の違いは表1のようにまとめられると考えています。

  DOA技術者 オブジェクト指向技術者
視座 データ オブジェクト、サービス
ドキュメント ER図、DFD UML
実装先 DBMS プログラムコード
言語 SQL Java（オブジェクト指向言語）
世代 年配 若者

表1：DOA技術者とオブジェクト指向技術者

   お互いが「変化に強いシステムを構築する」という共通の目標を持っているにも関わらず、それが実現できていない点は非常に残念に思います。
1   2  3  次のページ

システムズ・デザイン株式会社 DOA推進ワークショップ
 著者プロフィール
システムズ・デザイン株式会社  DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。
INDEX
第2回：正規化されたRDBとJavaによるデータアクセス
業務システムの現状
  一般的な解決策
  DOA活用事例〜B社の例（永続化されたドメインモデル）