議論 ～ オブジェクト指向DBは、O/Rマッピングのより良い代替手段となり得るか？

最近、ODBMS.orgに公開された記事によると、Ted Neward氏は、オブジェクト/リレーショナルマッピング(ORM)が、コンピュータサイエンスにおけるベトナムのようであるという彼の見解について、詳しく説明している。彼が示している考えの中心となるところは、オブジェクト指向データベース管理システム(OODBMS)が、ある特定のアプリケーションにおいては、リレーショナルデータベースよりも良いという点にある。以下のとおり、例をあげる。

単一ユーザーインターフェースで単一データベースにアクセスするもの(巨大なデータベースの上にある、伝統的な小さなWebアプリケーション)であったり、より最先端の「サービス」実装といった、「サイロ」(他システムと関連の無い閉じたもの)アプリケーションのような場合は、全てのインタラクションが、ユーザーインターフェースやサービスインターフェースを通じて行われたとしても、データベース自身には対しては決して行われないでしょう。その結果、永続化をすることは、本当に実装にだけ関心が向きます。そういった状況下においては、リッチドメインモデルを定義し維持していく中で、間を取り持つための2つの言語(Java/C#とSQL DDL)で、エンティティをを定義する必要が無いOODBMSがバックエンドにあるということは、とても有益になり得ます。

...(中略) 伝統的なオブジェクト/リレーショナルの世界においては、Entity定義の2つのセットが動作しています。1つは、プログラム言語そのもので定義されたもので、もう1つは、SQLのDDLで使用している関係モデルによるものです。この設定は、もともと違っていますが、システムが成長し、発展していく時に、定義の2つのセットの同期をとり続けなければなりません。それは、一方の「スレーブ」(奴隷、即ち変更に従う方)が、もう一方(スキーマからクラスへの変換、あるいはその逆といった、コード生成の手法の利用がよく見られます)に対して同期をとるか、若しくは、2つを別々に編集/調整したり、必要に応じてそれらの間のマッピングを手作業で調整することで、同期をとります。これは、両者に常に気をつけていなければならないということであり、しばしば開発者は、お互いの同期をとり続けなければならないが故に、両方のモデルの純度を犠牲にせざるを得ません。

再度OODBMSに関して言うと、クラス定義がスキーマ定義を表しているという事実があるので、それは即ち、「デュアルスキーマ」といった問題が存在しないということを意味しています。ドメインモデルが、ストレージの定義に依存する必要は無く、ストレージの定義もまた、リッチドメインモデルのストレージをサポートしているので、おかしなフォーマットになる必要もありません。

Andrew McVeigh氏のように、この見解に同意する人がいる。

OO --> 複雑なグラフ構造、オブジェクト間の高速なナビゲーションや横断、少ないインピーダンスミスマッチ

RDBMS --> データの独立性、複雑な帳票処理に適合、スキーマ管理(DDL)が優れている

asking for trouble."RDBMSをCADシステムのダイアグラムのストレージとして使用する、あるいは、OODBを帳票処理用のデータベースとして利用するということは、単にトラブルを招くだけです。

しかしながら、これらの見解に異議を唱える人たちもいて、RDBMSの役割を主張した記事を書いたGavin King氏は、特にそうである。彼は、いくつかのポイントをあげている。それらの概要は、次のとおりである。

• ORMは、レガシーなデータに必須です - ORMは、既存のスキーマを操作したり、レガシーなデータをサポートする唯一の方法であり、他に選択できるものはありません。
• ORMは、あなたに代わってDBを操作します - 後方互換性の必要が無くとも、ORMのソリューションによって、マッピングとデータベーススキーマを生成することができます。
• データは、アプリケーションよりも長く保持されます - ほとんどの場合、データは、アプリケーションで作られた後も残っているので、マッピングは必要になります。
• OODBMSは、互換性が良くありません - 強く型づけされたオブジェクトをデータベースに格納しなければならないので、OODBMSでは、複数の開発言語を使用するのが困難です。一方で、RDBMSでは単純な文字列や数値なので、それぞれの言語に対応付けることができます。
• OODBMSは、十分に成熟していません - OODBMSが主要なデータ管理システムに見られないのは、大抵のRDBMSと比較したときにとても未成熟であるからだと言えます。
• ベンチマークでは、OODBMSは良い結果を示していません - OODBMSシステムは、通常、アプリケーションと同一プロセスで動作するか、若しくは、スケーラブルでない方法で実装されています。結果として、小規模場合は良く機能しますが、大規模な場合は良くないです。さらに、ORMは、より堅牢であるが故にパフォーマンスが比較的悪いのですが、OODBMSで堅牢さを組み込もうとすると、成熟した機能セットを利用してパフォーマンスが同等になります。

明らかなことは、ORMの技術は、新しくなく、「マッピング」や「デュアルスキーマ」の問題も無いものに適用でき、問題がある場合を除いて、レガシーなデータにアクセスする必要性のために適用できるということです。もし、あるオブジェクトをデータベースに単純に入れたいときには、単一マッピングのアノテーションを書く必要はありません。従って、そういった観点から見ると、少なくともORMは、全てのユースケースやオブジェクトデータベースのアプローチではないその他のユースケース(実際は、一般的なケース)にとってのオブジェクトデータベースと同等と言えます。

もし、リレーショナルの技術がアプリケーションの状態を永続化するためにあると考えているのならば、それは誤りです。リレーショナルモデルの価値は、それが一般的であることにあります。プログラム言語が好きな人であれば誰でも、プリミティブな値のセット一組の価値が理解できるでしょう。リレーショナルデータベースは、統合技術であり、永続化の技術だけではありません。そして、統合ということは、重要なことです。それが、私たちがリレーショナルデータベースを手放さない理由です。

Ted Neward氏による、長いフォローアップの記事の結果は、次のとおりである。

いつになったら、ツールで全ての問題を解決してくれるのか？それぞれに存在理由がある中で、単純に言えることは、OODBMS若しくはHODBMSが、「私たちは、RDBMSを常に使っています。」という理由だけで無視してしまうということは、良くないことです。

Gavin氏には申し訳ないのですが、事実として、あなたと私の間、そして、あなたと数年以上にわたりカンファレンス、コンサルティング業務、レクチャーなどで話をしたことのある、かなり多くの開発者たちの間では、相違点があり、今後もそうなるでしょう。単純なテーブルとクラスのマッピングに対するあなたの意見に関しては正しいと思いますし、それはとても単純なことです。しかしながら、「デュアルスキーマ」の問題においては、「真実のソース」に対する2つの競合があるという点において、データベーススキーマとオブジェクトモデルの両方の調整をしなければなりません。おそらく、あなたが携わったプロジェクト全てが、開発者がその両方を定義するプロジェクトであるならば、問題はおきないでしょう。しかし、もしあなたが、データベーススキーマがDBAチームによって管理されている「エンタープライズ」の世界にいるのであれば、あなたのオブジェクトモデルの形に、スキーマ定義を「リファクタ」するような柔軟性は持ち合わせていないでしょう。