XMLデータベース開発方法論（1）　Page 2/4

序章、データ処理技法の地政学

川俣 晶
株式会社ピーデー
2005/6/28

■ここがスタートライン、データ処理技法の個人史

　ここまで読んだ読者の皆さんは、XMLデータベースの話を早く読みたいと思っていると思う。残念ながら具体的なXMLデータベースの話題は、実は全6回の連載中の第4回以降となる予定である。では、それ以前の第1〜3回は何を行うのかといえば、XMLデータベースが効果を発揮する条件について取り上げる。どのような技術も万能ではないが、XMLデータベースもまた万能ではない。すべては適材適所で使うことで、最も大きな成果を引き出すことができる。実は、この適材適所が達成できれば、それだけで「90％勝ったも同然」ではないかと思う。つまり、勝負の9割は、XMLデータベースの採用を決断する段階でついているということであり、大変重要な話を行いたいと思う。

　さて、適材適所について語るためには、XMLデータベースだけ知っているだけでは不十分である。世の中に存在するさまざまなデータ処理技法について幅広く知っていて、その中でXMLデータベースがどのような位置付けにあるかを知らねばならない。それ故に、今回は、XMLデータベースと比較され選択される（かもしれない）、ほかのデータ処理技法について、筆者の個人的な経験を基に見ていきたいと思う。

■対照的な2つのデータ表現方法

　筆者が初めてデータ処理を意識したのは、おそらく日本初のパソコンと位置付けられるであろうPC-8001のDisk BASIC（注：後年の同シリーズの機種と異なり「N80-」のような接頭辞が名前に付かない）である。

　このDisk BASICは、単なるプログラム言語処理系ではなく、事実上OSとデータベースの機能を内部に含んだ統合的な開発システムであった。ファイルにアクセスする方法として、非常に大ざっぱにいえば、現在のテキストファイルに相当するシーケンシャルファイルと、レコードやフィールドを持つ現在のRDB（のテーブル）に近いランダムファイルの2種類が提供されていた。そして、『Disk BASIC入門』は、その2つがどのように異なるかを克明に説明してくれていた。この本を原点にできたことは、筆者にとって、非常に幸運だったのかもしれない。なぜなら、本連載で展開される議論の大前提を最初の最初からしっかりと頭に植え付けられたからである。

　では、その議論の大前提とは何だろうか。それは、データを処理するまったく対照的な2つの方法があるということである。1つは、文字だけで記述され厳密な定義をせずとも手軽に使用でき柔軟性もあるが、例えば100番目（100行目）のデータをよこせといっても素早く取り出せない（ファイルのどの位置にそれがあるかの情報がないので、先頭から100個のデータを順に調べるしかない）方法である。もう1つは、バイナリとして表現され、厳密な定義を要求し使うのは面倒だが、膨大なデータの中から目的のデータを素早く取り出せる（100番目といえば、99番目までのデータを調べることなく、100番目のデータを即座に取り出せる）方法である。この2つの方法は、どちらも一長一短であり、どちらを使うか悩まされる。

　つまり、たった1つの万能の正解など存在しない、という大前提をこの本から学んだ。そして、その大前提は、いまに至っても何ら変わっておらず、むしろ深刻な問題として顕在化しているのではないかとすら思うのである。

　さて、たった1つの正解の不在は、とある経験によって強く印象付けられた。次は、その体験談を述べたい。

■例外的処理こそが重要である

　1980年代、筆者は「ドラクエ」で有名なエニックス（現スクウェア・エニックス）でプログラミングの仕事をしていた。そのころ、エニックスには、マニア上がりのすご腕のプログラマが何人もいて、技術を競っていた。また、パソコンのスペックが貧弱であるために、職人芸的なすご腕がなければ成立しないソフトも多かった時代である。このような時代、彼らと話していて必ず同意する話題があった。それは「例外的処理が重要」という考えであった。ここでいう「例外的処理」とは、最近のプログラム言語が備える「（try構文などで使用される）例外」のことではなく、基本的なルールから外れた特殊な処理のことをいう。

　例えばゲームの例でいえば、シナリオの都合上、通常の処理とは異なる例外的な処理がしばしば要求される。弾が当たればダメージを受けるというのが通常の処理だとすれば、シナリオ上勝てないとされた強敵と遭遇した場合だけは弾が当たってもダメージを受けないようにするのが例外的な処理に当たる。通常の処理を短くエレガントに記述するのは容易なのだが、例外的な処理はまさに例外的であるために、短くエレガントにまとめられないことが多い。しかし、だからといって長々と泥臭いコードを書いていては、貧弱なスペックの当時のマシンでは実行できなくなってしまう。つまり、「例外的処理が重要」ということになるわけである。

　さて、この時代に筆者は、とある業務システムを開発した。最初のバージョンは、BASIC言語で記述され、8bitパソコン上で動作するものであったが、より強力な16bitパソコンに移行するということになった。その時点で、いまさらBASICでもないだろうと、RDBを使うことを提案した。そこで、もはや正確には覚えていないのだが、東海クリエイトの「SWING」というソフトを使用した。試しに使ってみると、驚くほど少ない手間で、驚くほど多くの機能を実現できることが分かった。もはや、BASICで低レベルの処理を長々と書く時代ではないと思った。

　しかし、RDBを使うという当時としては画期的な先見の明はあっさりと挫折した。業務に含まれる例外的な処理が極めて多く、容量オーバーになってしまったためである。この出来事で、筆者は例外的な処理が重要であるのは、決してゲームだけではないと学んだのである。そして、もはやすべての機能を満たす見込みのなくなった作りかけのシステムを泣く泣く放棄し、8bit用のBASIC言語のソースコードから、16bit用のBASICのソースコードを作成した。

　もちろん、いまどきのRDBは、当時とは比較にならないぐらいパワフルになっている。容量の問題など、もはや過去のものだろう。そういう意味では、この出来事は、過渡期の悲劇にすぎないと見ることができる。しかし、この出来事には別の教訓が含まれている。それは、RDBは「例外的な処理」との相性が悪いということである。きれいに正規化されたデータを扱っている限り、RDBは実に快適で、わずかな手間で素晴らしい成果をもたらしてくれる。しかし、そこから逸脱する例外的なデータや、例外的な処理が発生すると急に扱いにくくなる。そして、例外的なデータや例外的な処理は、多かれ少なかれ、どこかで要求に入り込んでくる。それに対処するためには、職人芸的なテクニックや、複雑な定義や処理などが必要とされると思う。そして、それは手間、コスト、時間などのリソースを余計に消費することを意味する。RDBとは、それだけのリソースを消費するに値するデータを扱う場合にのみ、有効な選択肢と考えるべきだろう。また、あまりに不定形でありすぎるデータ（例えば単なる日本語の文章）は、現実的に有用な形でRDBに格納できない場合もある（単なる日本語の文章であれば現在のRDBには格納でき、全文検索の対象にできる）。

　つまり、RDBによって満たせず、こぼれ落ちたニーズが存在するのである。少量のデータを扱う場合、RDBはリーズナブルではない場合があり、不定形のデータはそもそも扱えないケースがあり得るということである。

　実は、上記の業務システムを除けば、筆者の抱えるデータ処理にはこのような条件を持つものが多かった。つまり、RDBから落ちこぼれたニーズばかり抱え込んでいたのである。その結果、この経験の後、RDBのパワーを当てにすることはめったになかった。

　しかし、RDBが当てにできないとしたら、ほかに何が使えるのだろうか。実は、RDBの対極として、UNIX系OSの世界で進化してきたフィルタと呼ばれるプログラムを駆使するテキストによるデータ処理が存在するのである。それを象徴する「AWK」という言語について、次は語ってみよう。（次ページへ続く）

2/4

Index
XMLデータベース開発方法論（1） 序章、データ処理技法の地政学
	Page 1 ・本連載の目的 ・本連載の価値観「すべきである」対「せざるを得ない」 ・本連載のお約束 ・筆者の立場と議論の進め方 ・XMLデータベースの定義
	Page 2 ・ここがスタートライン、データ処理技法の個人史 ・対照的な2つのデータ表現方法 ・例外的処理こそが重要である
	Page 3 ・AWK、使い捨てデータ処理の切り札 ・問題を認識する領域
	Page 4 ・RDBとAWKの中間ポイントに位置するXML ・さまざまな技術たち ・挫折、XMLはAWKの不満を解消し得なかった ・結末、そしてXMLデータベースへ ・次回予告

XMLデータベース開発論

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）