RDB／OODB／XMLDBで比較する永続化設計：JavaのDBアクセスを極める（4）（3/3 ページ）

» 2005年05月20日 00時00分公開

[下平浩由著, 安間裕監修，アクセンチュア・テクノロジー・ソリューションズ]

データ表現形式の違いがシステム開発に与える影響

開発フェイズでの影響

　開発フェイズで最も影響が大きいのは、インピーダンスミスマッチからくる開発工数の増加です。インピーダンスミスマッチを回避するために、RDBMSの場合はオブジェクトとリレーションを相互変換するO／Rマッピングを、XMLDBMSの場合はオブジェクトとXMLドキュメントを相互変換するデータバインディングを行いますが、この実装は永続層とデータベースの間にデータマッピング層とでもいうべき、新たなレイヤを生み出します。

　OODBMSの場合と比べて、RDBMS、XMLDBMSを利用した場合にはこのデータマッピング層の設計、実装、テストを実施するための追加工数が発生します。ここで特に注意しておきたいのはOODBMS以外のDBMSを利用した場合に、設計上2つの異なるデータモデルが作成されることです。RDBMSの場合はアプリケーション側でクラス図が、データベース側でER図が作成され、この2つは常に同期する必要があります。この同期をスムーズに行っていく方法については、第3回「OOAとDOAを併用した最適な分析／設計パターン」で解説しています。

　図5　インピーダンスミスマッチとデータマッピング層

運用保守フェイズでの影響

　運用保守フェイズではシステムの仕様変更が発生したとき、その影響が大きくなるほど多くの保守作業が必要になります。仕様変更の際にデータベースが影響を受けるのは、データベースに格納する永続化オブジェクトの構造が変化した場合です。永続化オブジェクトの構造の変更はスキーマ定義、スキーマ実装とデータベース上のデータに影響を与えますが、この中で最も時間のかかる作業は、データベース上にすでに格納されている旧スキーマ形式のデータを新スキーマ形式のデータに変換する作業で、データ量によってはかなりの時間を必要とします。ここでXMLDBMSがWell-Formed Documentを扱っている場合は、このデータ変換作業は発生しません。


	RDBMS	OODBMS	XMLDBMS
DBMS側	スキーマ定義の変更、スキーマの実装、データ変換	データ変換	なし
アプリケーション側	オブジェクト定義の変更、永続層の変更、データマッピング層の変更	オブジェクト定義の変更、永続層の変更	オブジェクト定義の変更、永続層の変更、データマッピング層の変更
表2　データ構造の変更時に発生する作業

　このときアプリケーション側でデータ構造を扱う永続層、データマッピング層の設計変更、プログラムの修正などが生じますが、DBMSの違いによる影響は少なく、上位レイヤへの影響は適切なレイヤ設計が行われていれば、ある程度コントロールできます。それはインピーダンスミスマッチを回避するために新たに設けたデータマッピング層についても同様で、設計いかんではこの層がファサード注3として機能し、上位レイヤに与える仕様変更の影響を制限できる場合があります。ただしアプリケーションを構成するレイヤが増えると保守性と拡張性が高まりますが、開発工数の増加とパフォーマンスの低下が考えられるため、慎重に設計する必要があります。

　このようなレイヤ設計手法については第2回「O／Rマッピングで失敗しない分析・設計のポイント」で解説しています。

注3：Facade（ファサード）パターン
複数のサブシステムのインターフェイスに、1つの統一されたインターフェイスを与えるデザインパターン。ファサードとは「窓口、建物の正面」の意味。

Point

開発フェイズでは、インピーダンスミスマッチを回避するために開発工数が増加する。
開発フェイズでインピーダンスミスマッチが発生するシステムは、異なるデータモデルを2重管理していかなくてはならない。
運用フェイズでXMLDBMSがWell-Formed Documentを扱っているとき、データ構造の変更によるデータの変換は不要である。
運用フェイズで仕様変更によりシステムが受ける影響は、適切なレイヤ設計によりコントロールできる。

DBMSを選択するポイント

　これら3つのDBMSが扱う、異なるデータ表現形式はどのような企業情報システムに向いているのでしょうか。ここでは企業情報システムを、企業の経営資源である「ヒト」「モノ」「カネ」の3つの要素に対応した情報系、業務系、勘定系の3つに分類しました。

情報系システム
　顧客管理、人事管理、経営支援などヒトを扱うシステムと、グループウェア、ドキュメント管理などの情報共有・分析を目的としたシステム　
業務系システム
　販売管理、物流管理、在庫管理、生産管理、品質管理などモノを取り扱う基幹業務システム　
勘定系システム
　財務経理、売り上げ管理、給与管理などカネの流れにかかわる基幹システム

　図6　企業情報システムとDBMSの関係

　データ表現形式に着目したときは図6のようになりますが、現実的にDBMSを選定する際には多くの機能要件（信頼性、可用性、保守性）や維持管理、資産運用、教育といった側面、または環境、ハードウェア、人的リソースなどを検討して行うことになり、単純に決まるものではありません。例えば、過去の導入実績が多いRDBMSの場合、TCOに占める割合が大きい運用・管理・資産運用について、以下の点が選定に有利に働きます。

サードパーティも含め、運用、保守ツールが充実している
運用マニュアル、教育マニュアルなどの過去の資産が流用できる
スキルを持ったエンジニアを確保しやすい

DBMSの今後

　これまでリレーション、オブジェクト、XMLの3つのデータ表現形式をそれぞれ見てきましたが、図6からも分かるように、それぞれのDBMSは競合関係にあるわけではなく、お互いに補完する関係にあります。実際に現在主流のRDBMSはOODBMS、XMLDBMSの特徴を取り込んだ複合DBMSになりつつあります。SQL99にはオブジェクト指向の要素が盛り込まれ、データ型が拡張されてオブジェクトが扱えるほか、継承やカプセル化も行えるようになり、オブジェクト・リレーショナル・データベース（ORDBMS）というカテゴリが生まれました。また、RDBMSのXMLサポート、XMLDB機能の統合が進んでおり、RDBMSはハイブリッドなDBMSとして適用範囲を広げています。

　またインピーダンスミスマッチを回避する手法として、さまざまなマッピング手法やマッピングツールが登場しており、インピーダンスミスマッチによる開発工数増加の問題は解決されつつあります。

　OODBMSはオブジェクト指向開発において大きなアドバンテージを持っているものの、現在までのところあまり普及していません。これにはいくつかの理由が考えられますが、業務に堪えられるOODBMS製品が市場に登場したとき、すでにRDBMSを使った企業情報システムが普及していたこと、業務分析があらゆる業務に対して行われその手法がRDBMS向けに確立されていたことなどが、その主な理由ではないかと思います。これは市場にRDBMSが組み込まれた多くの業務パッケージがあふれ、企業側がパッケージシステムを導入するケースが多くなっていることからもうかがえます。

　しかし、最近登場している開発手法、開発言語はオブジェクト指向によるものが多く、今後のシステム開発においてOODBMSがより重要になることは確実と思われます。例えば、次期業務パッケージシステムの組み込みDBMSとしてOODBMSが採用されるような展開になれば、一気に普及が加速することも考えられます。

　OODBMSではありませんが、「Cache」が多次元データベースと統一データ構造というアプローチを行って注目を集めています。多次元データベースへのアクセス方法は多次元アクセス、SQLアクセス、オブジェクトアクセスが提供されます。このときネイティブの多次元アクセス以外はインピーダンスミスマッチが発生しますが、Cacheの統一データ構造はマッピング情報の自動生成を行い、SQLアクセスとオブジェクトアクセスを同時に可能にします。このようにDBMSにO／Rマッピングツールが統合されているため、アプリケーションの開発工数を削減できます。

　XMLDBMSはこれまで情報システムで扱うことが難しかった非定型データを得意とします。これにより情報システムの扱えるデータ構造の幅を広げ、企業情報の電子化を促進していくと思われます。またXMLはすでに企業間取引などデータ授受の分野で普及しているため、XMLを扱えるXMLDBMSの用途は今後より増えていくでしょう。

まとめ

　今回はデータ表現形式に着目してRDBMS、OODBMS、XMLDBMSを比較しました。今後はオブジェクト指向言語とOODBMSの組み合わせによる業務パッケージや、XMLDBMSによる情報系システムなど新しい形のシステムが登場することを期待します。次回はまたRDBMSに戻り、「実装時における永続化のパターン」というテーマで、実装時に発生する問題に対して、永続化をどのように適用し解決させていくか、実装例を基に検証、解説します。（次回に続く）