どんな時に使うのか
ODBMS入門 ― どんな時に使うのか
リック・グリーハン (Rick Grehan) 著
(PDF版はこちら＝英・）
【解題】 RDBMSが市場で圧倒的な力を持っているのに、なぜ、どんな時にODBMSを使うべきなのか。いわゆるORミスマッチ問題を超えて、意外にもORDBMSを必要とする状況はますます増えている。開発者として幅広い経験を持ち、またByteやInfoWorld、Embedded Systems Programming などの専門誌で編集者、寄稿者として活躍してきたリック・グリーハン（現在コンピュウェア社研究所に所属）が、明快に8点にわたって解説する。
最初に、現実を認めなくてはならない。まずRDBMSが非常にうまくいっているという現状がある。リレーショナル データベースの上で動く優秀なアプリケーションは、何年にもわたって山ほど蓄積されてきた。同様に、非常によいRDBMSパッケージも入手できる。実際、MySQLとPostgreSQLという2つのオープンソースRDBMS製品は、誰が見ても素晴らしい。
それでもなお、ODBMSのほうがアプリケーションに適していることは少なくない。以下に、ODBMSのほうがRDBMSよりもよいソリューションとなることが多いアプリケーションの種類を示す（これがすべてではない）。
組込みDBMSアプリケーション
組込みDBMSアプリケーションには、一部モバイルデバイスに関連するデータベース、超高速の応答性を要求するアプリケーションにおけるOOデータキャッシュ、などが含まれる。 Java や .NETを使っている場合には、クライアント側やミドルウェアに、自己管理型、非侵入型で、実装が容易な永続化ソリューションが必要となる。
理由：永続化ソリューションを実装するには、Javaや .NETオブジェクトを「メモリ上にあるとおり」に格納するのが、つねに最も容量が少なく、侵入性も低い方法だからだ。RDBMSを使えば、オブジェクト－リレーショナル・マッピングのオーバーヘッドが加わるので、要求リソースも増大する。さらに、RDBMSアプローチでは管理の負担も重くなる。とくにインストールした データベースに対してクラススキームの更新をしなければならない場合にはそうだ。
複雑なデータの関係
正確には複雑なオブジェクトの関係というべきだが、そうしたアプリケーションでは、クラス間での多重的な相互参照が定義されている。ネットワーク型のデータ構造を含むアプリケーションがこのカテゴリーに入る。
理由：オブジェクトの間での複雑な相互参照は、リレーショナル データベースシステムでモデル化するには困難でミスも生まれやすい。（RDBMSでは）オブジェクト間の関係は外部キー (foreign keys)を使って扱われることが多いが、そうするとオブジェクトをフェッチする場合 ― 次に参照するオブジェクトをフェッチして、さらにそれらが参照するオブジェクトをフェッチするので ― 複雑になり、コードの保守もたいへんになる。
他方、ほとんどのODBMSは、到達可能な永続性 (reachability persistence) を実装している。そのため、永続化オブジェクトが参照するオブジェクトは、すべて永続化される（Object A がObject B を参照する時に、Object A が永続性を持つならば、Object B は自動的に永続化される。）通常、オブジェクトのツリーに伸びる到達可能な永続性の深さは、プログラマーが指定できる。その結果、オブジェクトの「塊り」は、すべて1回の呼び出しで格納されあるいはフェッチされる。：オブジェクトが格納されるとODBMSエンジンが参照の保守の詳細を管理し、オブジェクトがフェッチされた時にはそれらを満たす。
深いオブジェクト構造
これは前述したことと関係がある。データのすべてが、RDBMSが扱うように簡単に表形式の行と列に整理できるわけではない。「奇妙な」グラフ構造にしか整理できないものもあるし、多種多様なツリー構造なものもある。例えば、非常に「深い」ツリー構造では、プログラマーには長々しい親子－孫－曾孫といったように、参照の紐がRDBMSで扱うにはあまりに扱いにくくなっている。
理由：上述したように、非常に結合関係の複雑なオブジェクト構造は、リレーショナル データベースに「フィット」するよう変換するのは困難だ。変換コードは混乱を起こし易いし、保守が困難となる（元の構造が変換中に失われてしまうこともある）。また完全性の毀損 例えばツリーの「断片」だけが格納されるといった）の危険にさらされ、データの関係を保護するために長いコードの区画をラップする必要も出てくる。その結果、マルチユーザー・アプリケーションではとくにパフォーマンスが犠牲になる。
ODBMSは元の構造を データベースのために変換してやる必要がない。もしODBMSがプログラマーに対し、深く到達可能な永続性のコントロールを可能にするならば、開発者はツリー全体をフェッチし、格納するかどうか、それとも枝や小枝だけをフェッチし、格納するかどうかを制御できる。ここでも、構造は データベースエンジン自体によって完全に保持される。
データ（オブジェクト）構造の変換
あなたが、時々に応じてアプリケーションのクラス構造を変えたいと考えたとしよう。おそらくあなたは、新しいデータメンバが加わったり、新しいオブジェクトの関係を追加する必要が生ずる可能性が高いことを知っている。（ほとんどのアプリケーションは、使われていくほど進化するし、サポートするデータ構造も進化する。）
理由：ODBMSは、一般にRDBMSよりもデータ構造の変更を容易に行うことができる。もしRDBMSを使えば、（新しいオブジェクト構造にフィットするよう）スキーマを変更しなければならないだろう。そして変更すればクエリコードも改訂しなければならない。さらにテーブルを新しいフォーマットに対応させるために一括変換アプリケーション（時間を節約するため、必要に迫られて作成する、一種の使い捨てアプリケーション）を書く破目になるかもしれない。
ODBMSの中には、オブジェクトの構造を「稼働中に」変更できるようにしたものもある。「新」「旧」のオブジェクトを同じ データベースで混合して使うこともできる。新しいオブジェクト構造が追加的なフィールドを持っていた場合、旧いオブジェクトを新しいアプリケーションに読み込むには、単純に既定値（例えばナル、ゼロ…）を持った追加フィールドをロードする。逆に新しいオブジェクト構造のフィールドが少ない場合、旧いオブジェクトを新しいアプリケーションに読み込むには、存在しなくなったフィールドをスキップする。（ODBMSの db4o を例にとれば、（ データベースからアクセスした時に）「旧」オブジェクトを新しいオブジェクトに自動的に「アップグレード」してくれるメカニズムさえ提供している。
開発チームがアジャイル技法を使っている
アジャイルプログラミング技法は、開発上のエラーを減らす効果が認められて人気が高まっている。ODBMSは、RDBMSよりもアジャイル開発にスムーズに適合する。
理由：その答を、われらが導師であるスコット・アンブラーほど巧みに言った人はいない（本ポータルに提供されたペーパーで読める）。
現代のソフトウェア開発プロセスは、本質的に進化的ではあるが、それ以上にアジャイルでもある。アジャイル技法には、リファクタリング、アジャイルモデリング、継続的で回帰的なテスティング、すべての開発資産の構成管理、開発者のサンドボックスの隔離などが含まれる。リレーショナル データベース（RDBMS）技術を使うと、こうした技法の採用が複雑になる。それは技術的なインピーダンスミスマッチのためであり、文化的なインピーダンスミスマッチのためであり、また現在ツールのサポートがないためでもある。オブジェクトデータベース（ODBMS）ならもっと簡単にアジャイルできる。
OOプログラミング言語を使っている
当然すぎて、わざわざ持ち出すほどのことはと思われるかもしれないが、これを軽視してはいけない。
理由：考えてみよう。RDBMSではなくODBMSを使うということは、データベースからフェッチした行のオブジェクトと、アプリケーションの中の実際のオブジェクトとの間でデータをやり取りするための変換コードを書く必要がない、ということを意味する。また、（ORDBMSを使っている場合には）オブジェクト／スキーマのマッピングコードを書く必要もない。これは、以下のような場合には重要なことがらとなる。例えば、同じ データベースに、少しづつ違ったやり方でアクセスする複数のアプリケーションを保守しなければならない場合などである。こんな時には、全部のアプリケーションのすべての変換コードが同期しているかどうかを確認しなくてはならない。そして、 データベースの構造に何か変更があったら、全部のアプリケーションを点検して、変更がすべて適切に処理されるかどうかも確認しなくてはならない。
ODBMSを使えば、全部のアプリケーションからのアクセスは同じだ。…というのは、フェッチされ、格納されたオブジェクトは、同じように操作されるからである。アプリケーションさえ十分に確認しておけば、クラス構造の変更は1個のライブラリの変更にとどまる。アプリケーションを全部点検して変換コードを直すことなど不要になる。
オブジェクトが集合を含む場合
アプリケーションが、メンバを集合として定義する1個またはそれ以上のクラスを含む場合（List、Set など）。
理由：オブジェクトの中の集合は、しばしば1対多の関係を表現する。こうした関係をRDBMSでモデル化する場合、「親」オブジェクト（1個のテーブルに保持される）と集合（別のテーブルに保持される）の中のオブジェクトリンクとして機能する中間テーブルを必要とする。集合が様々なクラスを含むオブジェクトを格納できるようになっている場合には、さらに複雑になる。
他方で、ほとんどのODBMSは、こうした整理を行っても何の問題も生じない。集合はたんに別のオブジェクト（「深い」オブジェクトではあるかもしれないが）として扱われるだけで、ほとんどのODBMSは ― メンバの集合とすべてのコンテンツとともに ― 親オブジェクトのフェッチと格納が1個の呼び出しでできる。
データがクエリよりもナビゲーションからアクセスされる場合
これは現実に上記の2つの項目と関係している。それはこうしたオブジェクト構造の必然的な結果でもある。
理由：もしデータが高度なネットワーク構造において格納されている場合、またデータアクセスがデータの値へのクエリよりも、一義的にはオブジェクトの構造を通したナビゲーションにより行われる場合、ODBMSはほとんど確実に優れている。RDBMSを使ってツリーを通したナビゲーションを行う場合には、一連のクエリ－フェッチ操作として解決される（通常はSQLの select ステートメント）。ODBMSでは、これはネイティブな言語コンストラクツで表現される。そこで得られるコードは、分かりやすく保守も容易だ。
結論
冒頭に述べたように、RDBMSを使うことが実際的である例はいくらもある。ここではODBMSがより自然な選択となる様々な条件について述べた。
著者紹介
リック・グリーハンは、コンピュウェア社NumegaラボのQAエンジニアで、Javaと .NETの開発プロジェクトに従事している。同時にInfoWorld Magazineの客員編集委員を務め、同時に Embedded Systems Programming、EDN、The Microprocessor Report、Computer Designなどの常連寄稿者でもある。コンピュウェア社の前には、Metrowerks, Inc.で Discover DSP Project に参加、さらにBYTE Magazineの Senior Editor としてラボを担当したほか、 JavaTalk コラムも執筆した。