PR
図8●オブジェクト指向データベースの概念
プログラム中で利用するオブジェクトをそのままの形で保存し,後から再利用できる。
図9●オブジェクトの構造を安易に表にする
大量のテーブルが必要となり,結合処理に時間がかかる。

 RDBの「次」と期待されて伸び悩んでいるものに,オブジェクト指向データベースとXMLデータベースがある。これらはどちらも,リレーショナル・モデルとはデータの構造があわないと言われていたものだ。しかしOracleを初めとするRDBは,どれもオブジェクトをそのまま格納する機能を備え,XMLにも同じように対応してきた。その意味では,RDBはここ数年間,別の形態のライバルとの競争を排除してきたといえるだろう。

 オブジェクト指向データベースは,オブジェクト指向に基づき開発されたシステムにおけるデータ格納に向いているというのが最大の売りである。例えばプログラムで作成したオブジェクトがそのまま格納できる(図8[拡大表示])。このとき,プログラム中で一時的に使うオブジェクトか,永続化するオブジェクトかは,オブジェクトの生成時に意識するだけだ。後は通常のオブジェクトと同じように操作できる。こうすることで,データベースの存在をプログラマから隠蔽してくれる。

 同じことをRDBで実現しようとすると,二つの問題がある。まずオブジェクトの構造に対応するテーブル群を作成しなければならない。だが,オブジェクトが持つ構造は複数のテーブルに分割するだけで対処できるとは限らない。オブジェクトがオブジェクトの集合を参照するような場合,RDBで表現するのは難しい。これはデータの表現力の問題だ。

 次に性能が課題となる。オブジェクトの場合,オブジェクト間の関連をたどる処理が当然多くなる。だがRDBだと関連をたどるたびに結合処理をしなければならず,効率が悪い(図9[拡大表示])。こうした欠点がRDBにあることから,オブジェクト指向開発の普及とあいまって,オブジェクト指向データベースはやがて本命になるだろうといわれていた。

RDBもオブジェクト拡張

 だが同じクラス定義をそのまま別のアプリケーションで使うということは,実はあまりない。つまり,個々のシステムに依存した形のデータベースにしかならない。また言語的にもC++で作ったクラス定義をJavaなど別の言語に流用する姿も想像しがたい。「性能が高いと言ってもメモリー依存度が高く,キャッシュ・メモリー的に使われているだけだった。しかもスキーマが独立していない。これでは用途が限られる」(豆蔵代表取締役副社長の山岸耕二氏)。

 またもう一つの課題が検索である。RDBはその構造から分かるように,ある一つのテーブルの中で条件に合致するレコード集合を取り出すといった処理が得意だ。逆にOODBはオブジェクトをたどる処理(traverse)が得意。業務システムにおいては,オブジェクトをたどる処理よりも検索処理の方が頻繁に発生する。つまり業務システムにオブジェクト指向データベースは向かない可能性がある。多くのオブジェクト指向データベース・ベンダーは,「OQL」などというクエリー用の言語を搭載してきたが,「OQLはSQLに似ているが違うもの。理論が先行しすぎていた」(インターシステムズジャパン 上級コンサルタントの佐藤比呂志氏)。

 とどめを刺した形になったのが,ほとんどのRDBが「オブジェクト・リレーショナル」を標榜し,オブジェクトの格納に対応してきたことだ。「データを格納するストレージは文化みたいなもの。そう簡単に移行しない」(インフォテリア製品企画部部長の江島健太郎氏)。Oracleなど力があるベンダーに比べ,オブジェクト指向データベースを提供するベンダーは知名度の低いベンチャー企業が多かった。「ベンダーの力の差は大きい」(豆蔵の山岸氏)。

 同じことがXMLデータベースにも言える。XMLの場合,あくまでも企業の外部やシステムの外部という,外とのインタフェースのためにXMLを使うのであって,システムの内部データにXMLを使うことはあまりない。構造上無駄が多いからだ。特にトランザクションが多発するシステムにおいては,XMLという重いデータ形状が脚を引っ張ることになる。

 そこで専門のデータベースを作るという発想があるのだが,敢えてXMLそのものを管理するという必然性が少ない。データベースにする以上,ある程度の規模でXMLのデータそのものを保持しておきたいという必然性が存在しなければならない。

新しい利用形態を生む可能性もある

 XMLデータベースは半面,可能性を秘めている。整形式であれば,とりあえず明確なスキーマ定義が存在しなくてもなんとか格納できる点だ。これは,デスクトップなど個人が使うデータベースに適している。また,完成までにあまり時間をかけられないシステムの開発にも向くだろう。例えば三井情報開発の「NeoCore XMS」は,スキーマ定義がなくても利用できる点が売りだ。「企業に蓄えられているデータの90%は,明確なスキーマ定義ができない“半構造データ”だ。これを取り扱えるのは柔軟なデータ構造のXMLならでは」(三井物産Marketing Managerの寺田親弘氏)。

 また小規模なチーム程度の作業であれば,トランザクションがそれほど多く飛び交うわけではない。XML自体が持つ構造を頼りにできる。「XMLデータをファイルとして保存しておいて,それを全文検索すれば十分使える用途がある」(インフォテリアの江島氏)。

WinFSが新たな可能性を開くか

 アプリケーション・ソフトに組み込む用途を考えると,データベースの選択基準として開発ツールとの親和性が重要だ。例えば米Microsoft社の「ADO .NET」や,米Borland Software社の「dbExpress」などで扱えるデータベースであれば,極論すれば大差ない。あとは大量にクライアントに配布して,そのデータを吸い上げるといった処理が必要な場合に,データベース・サーバーと同期をとる仕組みがあるかどうかが問題になる。

 クライアント用のデータベースという点では,次世代Windowsのファイル・システム「WinFS」がユニークな位置にいる。そもそもファイルはデータそのものである。データを管理するのにデータベースを使うというのは自然な発想だ。OSが標準でファイル・システムとしてデータベースを使うというのは当然の方向性なのかもしれない。

企業システムはRDBの覇権が続く

 ただ企業システムの観点からすると,これまで通りRDBが主役を演じることは間違いない。おそらくここは2極に分化する。エントリ向けで大容量になることが想定されておらず,Time to Marketを意識したプロジェクトではコスト-メリットに優れるオープンソースで開発されたデータベースが有力になる。比較的手がけたことのある技術者が多く,スキルの応用も利くので技術者を募集しやすいというメリットもある。

 大規模への進化という点や,保守性などに関してはまだまだOracleなどの商用製品に一日の長がある。特に大規模化などを意識した場合には,まだオープンソースでは難しい。

(北郷 達郎)