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

変化は抱擁せざるを得ない、しかも禁欲的に

川俣 晶
株式会社ピーデー
2005/8/19

本連載は、XMLデータベースの開発方法論を展開する内容である。全6回の連載の前半3回では、なぜXMLデータベースを採用すべきなのかという根元的な認識を読者と共有し、後半3回においてXMLデータベース構築に特化した開発方法論を展開する。（編集局）

「そう卑下するこたァねェ。そうよなあ。俺は、まあさっき云ったように、そりゃあ昔から家がガタピシ云う度に担ぎ出されて来た訳だ。家が鳴るからヤナリだ。そのまんまの捻りのねえ命名だな。しかしこの姿を戴いたのは、そう古いことじゃねえのよ。俺が形を持ったなァお前が生れたのとそう変わりねえ頃だ」 「そうなんで？」 「そうだよ。お前が絵草紙に描かれてこの世に生れたほんの少しばかり前のことだよ。俺がこんな鬼の姿になったのは。考えてもみろ。俺は音ォ出すだけだ。別に鬼の格好なんかしてなくたっていいんだよ。実際今でも俺のことを鬼だと思ってる連中はそう多くはないぜ。場合によっちゃ、もっとつるりとした化け物だったり、子供だったり獣だったり、色々だよ」 京極夏彦 作『豆腐小僧双六道中ふりだし』p47より

■前回のおさらいと今回のテーマ

主な内容 --Page 1-- 前回のおさらいと今回のテーマ 変化に弱いRDB 対象を厳密に定義できない問題 対象の定義を厳密に表現できない問題 --Page 2-- 観測が観測対象に影響を及ぼす問題 人や社会が変化し続ける問題 実用十分圏に追従する 仕様変更ができるだけ発生しないような設計とは何か 変化を肯定することによる使い勝手の向上 --Page 3-- リファクタリングになじむDB、なじまないDB 変化への要求は、禁欲的に受けよ --Page 4-- XMLデータベースを使うべき条件 まとめ

　前回の「スケーラビリティの重大な誤解、“大は小を兼ねない”」では「規模が違えば性質も変わる」という、一種の常識について説明した。これは、より多くのデータを扱える技術が最も優れている、スケーラビリティこそがデータ処理技術で最も重要である、といった一種の常識に異を唱えるものであった。このような主張を、その是非を意識的に検証しないまま、盲目的に信じ込んで疑うこともない人は多いと思う。しかし、世の中の多くのモノや情報は、規模が違えば性質も変わるという特徴を示す。実はデータベースもその例外ではなく、規模が異なれば性質が変わることがあり、1つの技術をすべての規模で使うことは最善ではない可能性がある。それは、データベースもRDBだけあればよいという硬直した常識を脱し、適材適所で意識的に選び取って使おう、という提案でもある。

　とはいえ、これはXMLデータベースを使うべき強い理由を示したことにはならない。RDBだけあればよい、という常識を打破し、XMLデータベースが登場する可能性をつくっただけである。つまり、どうしてもXMLデータベースを使う必要があるという強いニーズを示してはいない。そこで、今回は、ぜひともXMLデータベースでなければうまくいかないというテーマについて語りたいと思う。そのテーマとは「変化」である。XMLデータベースはRDBと比較して変化に強いのだが、実は変化に対する要求は避けては通れないほど大きいものであると考える。例えば、開発中の仕様変更要求や、運用中の機能変更などは、構造的にどうしても避けられない必然性があるのではないか。今回は、そのような「変化の必然性」について主に述べる。そして、変化に弱いRDBから変化に強いXMLデータベースへと入れ替えることにより、よりきめ細かく変化し、よりよい使い勝手を提供するシステムの可能性についても述べてみたい。

　そして、今回の締めくくりとして、この連載の前半（第3回まで）のまとめとして、XMLデータベースを適用すべき領域について述べて終わりたい。これは、これまでの内容の中で最も重要なポイントである。いかなる技術であろうとも、何にでも効能を持つ「万能解」などはない（これを「銀の弾丸はない」と称する）。どのような技術であろうと、使いどころを間違えれば、益よりも害をもたらす。それにもかかわらず、特にIT業界にあっては、技術の性質を斟酌することなく、何にでも有効な万能解であるかのように技術（製品）を喧伝し、売り込もうとする人たちがいる。このような行為は、彼らの利益にはなっても、技術の未来を殺す行為であり、利用者の利益を損なう行為である。XMLデータベースという技術の未来を花開かせるためには、それが適する領域を正しく把握し、そこで活用する必要がある。もちろん、利用実績が少ないXMLデータベースについて確実に何かを断言するにはまだ早い。しかし、大ざっぱな指針は示すことができる。そして、たとえ大ざっぱであろうとも指針があることは、XMLデータベースという未知の世界に乗り出すには、大きな助けになるだろう。

■変化に弱いRDB

　ごく最近（ここ2〜3年）に限っていえば、私がXMLデータベースを欲する理由は、XMLデータベースが優れているからではなく、RDBの持つ変化への適応性が期待する水準を大幅に下回るという点にある。つまり、RDBがニーズに応えてくれないために、ほかの技術を求めざるを得ず、そこに有力な候補としてXMLデータベースしか存在しなかったということである。

　さて、RDBは構造の変更に弱いとは、どういうことだろうか？

　それは、RDBのデータベースの構造を変更する場合の作業手順を考えると見えてくるだろう。

　RDBをうまく運用するためには、データベースを正規化するという手順が必要とされる。情報の重複をなくして複数のテーブルに分類することで、RDBはその真価を発揮すると思う。もし、データベースに格納するデータの内容に変更があった場合は、強引にデータを入れるか、あるいは正規化をやり直す必要が出てくる。正規化をやり直すと、テーブルの数や構成が変わることもある。もしテーブルの数や構成が変わると、その影響は甚大となる。つまり、本来変更個所と関係のないデータにアクセスするためのクエリも、書き直しを要求されてしまう可能性が出てくるのである。しかも、運用しながら旧データベースから新データベースに徐々に切り替えることもできない。テーブルの構成がまったく違うということは、一度システムを止め、データベースの構成を変換してからシステムを再開しなければならないのである。

　これに対して、XMLデータベースは変化に強い。正規化という手順は要求されておらず、不定型であることを許容するので、追加されたデータは単に要素や属性を追加するだけでよい。そして、従来のデータにはその情報が含まれていないが、そのような欠落した情報の存在も柔軟に許容する。つまり、旧データベースから新データベースへ、シームレスに運用することもでき、システムを止めないままデータベースを拡張することもできる。

　もちろん、正規化不要ということは、いいかげんに行き当たりばったりにデータベースを構築してよいということではない。同じ情報を重複させない、といった配慮は当然要求される。しかし、部分の一貫性は要求されても全体が一貫している必要はなく、テーブルを分割するという手順も存在しないことが、XMLデータベースの特徴となる。

　しかし、今回のテーマは、RDBとXMLデータベースのどちらが変化に強いか、ということではない。現実のシステムが、いかに変化に対する強い要求にさらされているのかについて語るのが主テーマである。

　そう、実は今回の主題は、XMLデータベースではなく、変化への要求にある。そして、変化への強い要求にさらされたシステムにRDBを使うことは、実はミスマッチな選択でしかなく、積極的にXMLデータベースに乗り換えていく価値がある、というアイデアを示したい（図1）。

図1　変化への要求を持つシステムにマッチしないRDB

■対象を厳密に定義できない問題

　プログラムやシステムを開発する場合には、それが何を実現すべきかを明確にしなければならない。例えば、業務システムであれば、業務を分析し、システムが必要とする要件を抽出し、それを基にプログラムの仕様を決定するのが一般的な流れといえるだろう。

　さて、その場合に問題となるのは、そのような要件を厳密に定義することが本当に可能であるのか、ということである。おそらく、長年対象となる業務に携わってきた当事者であれば、仕事のやり方はすべて分かっているし、明確なルールをすべて示すことができると思うことが多いのではないかと思う。しかし、過去の経験上、それは当てにならないことが多い。実は、厳密で無矛盾なルールというものは、意識的かつ慎重に組み上げねば作り得ないものである。ただ単に、うまく運営されている組織のルールというだけなら、その水準に達していないことが多いのではないだろうか。

図2　厳密に定義された業務と定義されていない業務

　しかし、なぜ厳密で無矛盾なルールがないのに、円滑に業務が遂行できるのだろうか。その理由は、人間の適応性の高さにあると思う。多少のルールの不整合は、人間がうまく扱うことで回避できる。それが無意識的に行われるようになれば、不整合があるということも意識されなくなる。これはこれでよいのだが、コンピュータを使ったシステムに置き換える場合には問題になる。コンピュータには、人間ほど高い適応性はないからである。

　おそらく、大半の業務は、このような境界のあいまいさを持っていて、かつ、当事者はそのことにあまり自覚的ではないのではないかと考える。それにもかかわらず、システムを開発するために業務を明確に定義しようとするのは、システム開発の都合という側面が大きいだろう。開発する側の立場からすれば、最初から最終形を描ける方が作りやすいし、大規模システムであれば定義を示さなければそもそも開発が不可能になる可能性もあるだろう。それ故に、業務を定義するという試みを否定するわけではない。しかし、本来は明確に定義できないものを明確に定義しようとする行為は、さまざまなトラブルを引き起こす可能性があることに留意すべきだろう。例えば、設計の不整合の発覚や、仕様変更要求は、常にあり得るものと考え、それに対する対処をあらかじめ考慮しておく必要があるのではないかと思う。

　つまり、対象を厳密に定義できないことが、変化への潜在的な原因となる。そして、大抵の場合、対象を厳密に定義できないのが当たり前である。

■対象の定義を厳密に表現できない問題

　仮に、「対象を厳密に定義できない問題」が間違いであり、厳密な定義は可能だと仮定してみよう。しかし、そうだとしても事態はまったく楽観できない。なぜなら、厳密な定義を表現する手段が存在しないという問題があるからだ。

　何かを記述するための言語にはさまざまな種類がある。まず考えられるのが、日本語や英語のような自然言語である。しかし、自然言語はあいまいさを多く含み、厳密な定義を行うには向いていない。いや、慎重に厳密に書けばあいまいさを排除できる……と思う方もいると思うがそうでもないらしい。厳密に書くということは何かを熟知した規格文書のプロが書いた文書であっても、後からあいまいな部分が見つかり、正誤表が出ることが珍しくないからだ。

　そこで、より厳密な人工言語を使うということが行われている。例えば、プログラムを記述するプログラム言語、構文ルールを記述するBNF（EBNF）のような言語がある。また図で表現するとはいえ、オブジェクト指向のクラスの構造などを記述するUMLも、一種の人工言語といえる。厳密にいえば、これらの言語が本当にあいまいさを排除して記述する能力を持っているといえるのかは議論の余地があるが、ここでは記述できるという前提で話を進めよう。

　さて、人工言語が開発されたことで、あいまいさがない仕様書を記述できるようになったのかといえば、そうではない。依然として、技術関連の規格文書も、システムの仕様書も、大量の自然言語で満ちあふれている。人工言語は、厳密ではあるが、それは仕様書が必要とするすべての表現力や語いを備えているわけではないのである。例えばBNF（EBNF）は構文を示すことはできても、意味を示すことができない。必然的に、何かを定義しようとすれば、自然言語に頼らざるを得ず、そこにあいまいさが発生する。

　あいまいさを含む仕様書を基にシステムを開発した場合、実際に運用してみると実際の業務と不整合が生じる可能性がある。できるだけ、あいまいさが生じないように仕様書を記述することで、そのような問題は減らすことができる。しかし、自然言語が持つあいまいさそのものが、そのような問題の根絶を妨げる。つまり、システム開発の最終段階で、実際の業務とシステムのすり合わせの工程は必要とされ、その段階でシステムの修正が必要とされる可能性は常にあり得ると考えられる。

　つまり、対象の定義を厳密に表現できないことが、変化への潜在的な原因となる。そして自然言語を使う限り、厳密な表現はできないと思って間違いないと思う。（次ページへ続く）

1/4

Index
XMLデータベース開発方法論（3） 変化は抱擁せざるを得ない、しかも禁欲的に
	Page 1 ・前回のおさらいと今回のテーマ ・変化に弱いRDB ・対象を厳密に定義できない問題 ・対象の定義を厳密に表現できない問題
	Page 2 ・観測が観測対象に影響を及ぼす問題 ・人や社会が変化し続ける問題 ・実用十分圏に追従する ・仕様変更ができるだけ発生しないような設計とは何か ・変化を肯定することによる使い勝手の向上
	Page 3 ・リファクタリングになじむDB、なじまないDB ・変化への要求は、禁欲的に受けよ
	Page 4 ・XMLデータベースを使うべき条件 ・終わりに

XMLデータベース開発論

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