2008年12月23日火曜日

XML DBや半構造データについて思うこと

先日のTwitterタイムラインの記事については、当事者の一人の斉藤太郎君がすでに記事を書いていたり、それに対して山本陽平君(もちろん「RESTful Webサービス」の訳者の山本君である)がはてなブックマークTwitterで応答を返していたりする。斉藤君がはてなブックマークのコメントで書いている通り、結構過激な発言が多いので、補足をせねばならないだろう。


まず、自分のスタンスから述べねばなるまい。今はデータベース研究者のコミュニティに出入りしているが、修士までは論理設計の講座にいた。そこでデータモデリングに興味を持って、データベースのほうに研究の軸足を移して、現在に至っている。データベースへの興味の持ち方はその頃からあまり変わっておらず、内部の実装(索引など)よりも外部の機能(問合せ言語やデータモデル)のほうに興味がある。ついでに言えば、修士までの研究室でのテーマ、ブール代数やオートマトン、正規表現などが研究者としての根っこにある。

もう一つ、XMLとの関わりについて述べる。XMLに関心を持ってかれこれ10年になるが、その原動力は極めて文書寄りかつ学術的なところにある。すなわち、Relaxによって木言語理論との関係を知ったこと、XDuceによって(学生時代から憧れの言語だった)Standard MLや型理論とのつながりを知ったこと、この2つの感動が原動力となっている。元から興味のあった文書処理と情報科学の理論、それも学生時代から慣れ親しんできたオートマトンや正規表現、型理論が偶然つながったわけで、ある種運命的なものを感じたのを今でも覚えている。原体験がこういう感じなので、私のXMLへの接し方は極めて文書寄りであり、貴族よりもボヘミアンに属する。

そんな背景に立っているので、XMLデータベースはあくまで「XML文書を大量に格納し検索するシステム」として興味を持っている。格納対象は構造化文書であり、したがって木である。ただし、データベース研究の論文でよく例に出されるデータ指向のXMLの格納・検索には、何となく引っかかるものを感じていた。ただ、何が引っかかているのか、あまり明確に考えたことはなかった。単に自分がXMLボヘミアンだから、くらいに考えていた。

先のTwitterでの発言は、こういう背景を踏まえたものである。加えて、先日行ったSIG WI2でのXMLチュートリアルでの2つの体験が伏線となっている。

一つは、下準備として、Abiteboulが1997年に発表した論文 "Querying semi-structured data" を読んでの印象である。半構造データという用語がデータベースコミュニティで広く知られるようになったのは、この論文がきっかけであろう。ただ、すでに彼の著書 "Data on the Web" を読んでいた(というか自ら翻訳して出版した)ので、この論文はまだ読んでいなかったように思う。

一読して、これは「半構造データというものを扱っていくべきだ」という、研究の方向性を提案した論文なのだな、と思った。その一例が、半構造データの例としてHTMLとASN.1を挙げている点である。ASN.1は構造を持ったデータの記述フォーマットだから、例としてよく分かる。しかしHTMLは?木を表現しているとはいえ、データベース的な意味でのスキーマはないに等しい。実際、"Data on the Web" では、HTMLは半構造データの例としては明記されていない。HTMLというインスタンスを例に出して、半構造データという概念に説得力を持たせたのだな。そう読み取った。文書をコンピュータで処理させる上で構造化が不可欠だったのに比べ、半構造データはAbiteboulの掲げたアドバルーンだった(もちろんよくできたアドバルーンだったから研究者も大勢集まったし、その後研究が盛んに行われたわけだが)。その差が、漠然と感じていた「引っかかり」だったのだろう、と気がついたのである。それが「飯の種」発言につながっている。

もう一つの体験は、チュートリアルで聞いたSQL/XMLの機能の話である。たぶん、このチュートリアルで私が一番驚いた話である。なんと、SQL/XML中からXQuery文が呼び出せてしまうらしい。サポートページで天笠先生の資料を公開しているので、詳しくはそちらを参照してほしい。ここまで丸呑みしてしまうとは。SQL恐るべし。この話を聞いたとき、ネイティブXMLデータベースはRDBに丸呑みされてしまうな、と直感した。

過去に同じような話を経験しているが故の直感である。10数年前、私がまだ学生だった頃、オブジェクト指向データベース(OODB)というものが流行した。第1正規形ではない構造を持ったデータ(複合オブジェクト)を格納するデータベースが必要だ、RDBで複合オブジェクトを格納したらjoinがたくさん発生して効率が悪い、親言語とSQLとのセマンティックギャップを解消すべきだ、などのキャッチフレーズの下、オブジェクトをそのまま格納できるデータベースとして提案されたものである。当時は「OODBとRDB、どちらが生き残るか」という議論がまじめに交わされた。

結果はどうなったか。RDBがオブジェクトを格納・検索する機能を提供するようになり、RDBのみが生き残った。OODBはシステム組み込みの永続オブジェクト管理機構など、限定された用途でかろうじて命脈を保っている、という状態である。ちなみに、初期のネイティブXML DBの一つであるeXcelonは、OODBのObject Designの発展形(生きながらえるために形を変えた、ともいう)である。

研究対象としてのXML DBに価値がないとは思わない。範囲ラベリングなどの索引技法、XPathやXQueryなどの問合せ処理技法など、今後に生かされるだろう技術はいろいろある。しかし、DBMSとしてはRDBのみが生き残るのだろう、と思う。XML DBが生き残るとするなら、大量の文書を蓄えるためのレポジトリ用途くらいではないか。これが「ネットワークモデル、階層モデル、OODB、演繹DB、XML DB、みんな失敗した」という発言の意図である。「失敗した」という言葉は的確ではなかったかもしれない。

なんというか、XMLや半構造データという土俵の上で相撲を取っていたら、実はその土俵はAbiteboulの仕組んだものだった、しかもそこはCoddというお釈迦様の手のひらの上だった。そういう心境である。

2 comments:

村田 さんのコメント...

うむむ、私の知らんところで、こんな
話が ... ここ二年ぐらいは血で血を
洗うような戦場をさまよっているばか
りだったからなあ。

大したことを言えるほど最近は頭を
使ってませんし、データベースには
詳しくない(爆)んですが、個人的
にはまったく文書よりのデータベース
(TeraTextみたいなやつ)と、ただの
関係データベースがけっこう好き
だったりする。

Takeo Kunishima さんのコメント...

ODF/OOXML戦線ですか…あれ、いつか終結するんですかねえ。仕様がでかいだけに戦線の収束にえらく時間がかかりそうな。

それはさておき、実に村田さんらしい意見ですね。

文書DBとしてどんなものがいいのか、実はあまり意見が固まっていません。たぶんニーズがよく見えていないのだと思います。文書の検索と言われて連想するのがGoogle Desktop、程度の認識なので…