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

XMLデータベース設計におけるYAGNI問題

川俣 晶
株式会社ピーデー
2005/10/14

■無限詳細化とYAGNI

　未来の未知の変化を積極的に受け入れよう、というのがこの連載の趣旨の1つなのだが、これを実践するうえではまりやすい落とし穴がある。それが、無限詳細化である。

　詳細化とは情報をより詳細に分割し、記述するように設計することである。そして、無限詳細化とは、情報を詳細に扱うために分割する作業が永遠に終わらないことを意味する。

　例えば人名を記述する事例を考えてみよう。最初に考えたのは、以下のように名前要素を使ってシンプルに表現する方法である。

<名前>石ノ森章太郎</名前>

　このような表記は現在のニーズではこれで十分であるが、将来の変化を想定すると不安が残る……と思ったとしよう。例えば、姓と名を分けて処理したいというニーズが発生したとき、1つの文字列で記述された名前を、確実に姓と名に分離するアルゴリズムは存在しないためである。例えば、泉野明は「泉野・明」と区切ることも「泉・野明」と区切ることもでき、どちらもあり得る人名である。姓と名を分けて処理する必要が発生したときに備え、これを分けて保存するように変更してみた。

<名前>   <姓>石ノ森</姓>   <名>章太郎</名> </名前>

　これで姓と名は分離された……。しかし、ふとさらに不安が過ぎるのである。この名前はもちろん著名人のペンネームであって、本名ではない。本名で発行しなければ意味のない文書を想定するなら、それが本名であるか否かを示す情報を付け加えた方がよいのではないか……。そこで、名前の種別を示す属性を追加してみた。

<名前 種別="ペンネーム">   <姓>石ノ森</姓>   <名>章太郎</名> </名前>

　だが、まだ不安は消え去らない。なぜなら、この名前はペンネームとしてすら一貫していないのである。かつては「ノ」を含まない名前で呼ばれていたこともある。（具体的にそれがいつになるか分からないが）その当時の資料を電子化し、それを付き合わせて情報を加工するクエリを記述することを考えれば、古い名前も併記できるようにした方がよいだろう。

<名前>   <現在名 種別="ペンネーム">     <姓>石ノ森</姓>     <名>章太郎</名>   </現在名>   <旧名 種別="ペンネーム">     <姓>石森</姓>     <名>章太郎</名>   </旧名> </名前>

　さて、ここまでやれば大丈夫、あるいはやりすぎだと思う読者も多いと思うが、不安がこれで解消されたわけではない。名前が切り替わった日付も入れた方がよいのではないか、という次なる不安も出てくる可能性がある。ある名前が有効かどうかを判定するプログラムを、もしも将来記述する必要が生じた場合は、日付によって判定を変えねばならないのである。また、それとは別に、ペンネームや芸名には、姓と名に分離できない名前もあり、姓と名を固定的に指定すると収まらない名前が出るかもしれない。例えば、「モンキー・パンチ」というペンネームを、姓がパンチ、名はモンキーと解釈することは、おそらく適切ではないだろう。また、外国人の名前を扱う場合には、貴族の「サー」をどう扱うのか、ミドルネームを記述するための要素も追加する必要があるのではないか、といった不安が発生する。

　このような不安は、多くの場合、永遠に終わることはない。どれほど詳細に記述するようにしても、いや、詳細にすればするほど、ほころびが見えるようになり、不安は消えない。

　このような無限詳細化に対処する原則がYAGNIである。YAGNIとは「You Aren't Going to Need It」の略であり、「それは必要にならない」ということを意味する。未知の未来の変化に備えるために準備された機能の大半は、実は使用されずに終わるか、あるいは、必要とされても機能がニーズに対して十分ではなく、作り直しを要求される。つまり、現在のニーズが以下のようなシンプルな表現ですべて満たせるのであれば、これを採用するのが正解ということである。未来の変化に備えてより詳細な表現力を与えることは、ほとんどの場合無駄になるので、行うべきではない。

<名前>石ノ森章太郎</名前>

　ちなみに、無限詳細化に該当しない場合でも、未知の未来に備えた機能を付け加えることは、すべてYAGNIの原則により行うべきではない。柔軟に変化を受け入れることができるシステムは、具体的な変化の要求が発生してから変化させるのが最も無駄がなく効率のよい結果を出す。つまり、変化に弱いRDBで未知の未来の備えることがよい選択であったとしても、変化に強いXMLデータベースで同じ選択を取ることがよいとは限らないということである。

　YAGNIの件はまだまだ奥が深いが、それは次回に詳しく取り上げる。

■なぜXMLデータモデルに固執するのか

　この連載では、変化は必然であり、それに対応するためには変化に強いデータベースを使う必要がある（使わざるを得ない）という前提を取っている。だからこそ、XMLデータベースを使う意義があるということである。しかし、変化に強いデータベースは必ずしもXMLデータベースだけとはいえない。XMLのデータモデルとは一致しないが、やはり変化に強いデータベースというものは、いくらでも考えることができる。それにもかかわらず、ここでは強くXMLデータベースこそが本命であるといい切っているのはなぜだろうか。

　この問い掛けは、もっとシンプルに要約することができる。つまり、XMLデータモデルに固執する価値と何だろうか、という問い掛けである。

　その答えは簡単である。XMLデータモデルに準拠したデータは、いつでもテキスト形式に変換することができる。もちろん、巨大な（例えばテラバイト級の）データベースを丸ごとテキスト形式に変換することは現実的ではないかもしれないが、一部をテキスト形式に置き換えることは、日常的に発生する作業の1つということになるだろう。そして、テキスト形式に置き換えられたデータは、XML文書を扱うあらゆる汎用の技術、ツールによる処理の対象になるわけである。

　データは、もちろん保存して終わりということはない。クエリを発行して結果を得て終わりということもない。保存し、クエリを発行し、クエリの結果を得た後、それをさらに有益な形で活用することが求められる。そして、それを行うために、既存のXML関係の技術やツールがすべて使えることは、大きな強みとなる。例えば、クエリの結果を汎用のXMLエディタに読み込んで再加工することもできるし、PDF形式に変換するツールなどを経由して、読みやすい文書を生成することもできるだろう。

　逆に、XMLデータベースに登録すべきデータを準備する作業で、汎用のXMLツールや技術を活用していくことも可能である。例えば、XMLの入力フォームを定義するXFormsのような技術と連動して入力データを用意することも可能であろう。

　つまり、なぜXMLデータモデルに固執するのかといえば、常にXML文書に変換可能な状態でデータを扱うことにより、データベースの周辺をXML関連の技術やツールによって満たすことが可能になるためである。例えば、XMLデータベースは周辺ツールなどの整備が遅れているという話があるが、実は汎用XMLの世界の資産をいくらでも転用できるので、それにニーズがあると分かれば整備は急速に進むのではないかと考えている。

　そして、XMLデータベースのためのツール整備は、多くの場合、一般のXML利用者の役にも立つだろう。つまり、XMLデータベースの普及が、一般のXML世界にもよい刺激を与えることも考えられる。このような相乗効果を発揮することで、XMLデータベースは、単にデータベースの世界だけで閉じた技術よりも、ずっと大きな価値を発揮する可能性を秘めているといえるのではないか、と筆者は思うのである。そして、そのような相乗効果は、XMLデータモデルを多くの人たちが共有することによって「のみ」発生し得る。

■次回予告

　次回は、「変化に追従する柔軟なデータ構造」について書いていきたいと考えている。変化は不可避であり受け入れざるを得ない、という主張はすでに書いてきたし、XMLデータベースが変化を柔軟に受け入れる資質を持っていることも述べた。しかし、ただ単に「何でもそのまま受け入れる」という態度を取るだけでは十分ではない。そのような態度は、「混沌に堕落する誘惑」への敗北である。変化の受容にも、やはり何らかのルールを設定する必要がある。やはり、変化に対応しやすいデータ構造もあれば、そうではないデータ構造もあり得る。また、変化を積極的に受け入れるか、消極的に受け入れるかによっても、対応が変わることがある。それらについて、次回は述べていきたい。（次回へ続く）

4/4

Index
XMLデータベース開発方法論（5） XMLデータベース設計におけるYAGNI問題
	Page 1 ・前回のおさらいと今回のテーマ ・IDの付与 ・順序のあるデータ、ないデータ ・数値の活用
	Page 2 ・列挙型の活用 ・名前空間を使う ・既存ボキャブラリ（語い）の活用
	Page 3 ・要素と属性の使い分け ・データ分割の単位 ・混合内容の使い方
	Page 4 ・無限詳細化とYAGNI ・なぜXMLデータモデルに固執するのか ・次回予告

XMLデータベース開発論

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