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

変化に強いXMLデータベース設計とチューニング

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

■YAGNI再び

　「拡張のためのスタブ」をより多く設ければ、設計変更に伴うデータベースの変換をゼロ時間で完了できる可能性を高めることができる。しかし、だからといって、ありとあらゆる場所に、「拡張のためのスタブ」を埋め込むようなやり方は好ましいものとはいえない。それらの大多数は、永遠に利用されることがなく、単なる邪魔者にしかならないからである。前回紹介したYAGNI（You Aren't Going to Need It.の略であり、「それは必要にならない」）の典型的な事例ということである。

　通常、YAGNIの原則を用いて物事に対処する場合には、「拡張のためのスタブ」のような未知の未来に備える機能は排除されるべきものとされる。それにもかかわらず、筆者が「拡張のためのスタブ」をここで解説するのは、もちろん「ゼロ時間変換」という極めて有用なテクニックを活用するためである。

　しかし、いかに「ゼロ時間変換」が魅力あるテクニックだとしても、あらゆる変換をゼロ時間で完了させようと考えるのは誤りである。発生する設計の変更には、比較的よく発生することが具体的に予測されるものと、そうではないものがある。「拡張のためのスタブ」は、前者のためにのみ用意するとよい。後者のために用意することは、やはりYAGNIとなる。

　では、比較的よく発生することが予測される変更とはどのようなものだろうか。大ざっぱにいえば、以下のようなものが相当するのではないかと思う。

• 人間や一般社会など、厳密に定義されない対象
• 単純にデフォルメされた情報

　例えば、まさに人間は1番目の条件に合致するので、「拡張のためのスタブ」を用意しておく価値がある。その場合は、もちろん個人単位で人物についての情報を持つためのスタブを用意するのが基本である。

　会議の出席者についての情報を記述する際に、それを名前だけの情報に絞り込んで記述するのは、2番目の条件に合致する。人間には名前のほかにさまざまな属性がある。年齢、出身地、所属部署など、さまざまな情報が名前と並んで必要とされる可能性がある。また、名前は個人を識別する情報として十分ではない。同姓同名の人が存在する可能性があるからである。それにもかかわらず、「出席者名」要素を使い、人間を名前によってのみ記述するようなやり方は、情報を単純にデフォルメしすぎである。つまり、修正要求によって破たんする可能性が高い。しかし、「拡張のためのスタブ」を用意することで、破たんしない修正が可能になる可能性を得ることができる。

■要素と属性の問題再び

　すでに前回触れている問題ではあるが、要素と属性のどちらを使ってもよい場合、拡張性という観点から要素を選ぶことができる。「拡張のためのスタブ」として用意されたものではないとしても、将来追加される情報が子に追加される可能性はあり得る。そのような情報を記述する際に、属性を使うことはできない。属性は子を持つことができないからである。その場合は、どうしても要素を使わねばならない。

　一方、拡張させないために、あえて属性を選ぶという選択もあり得る。例えば、シンプルに一意性を示すために付加されるID番号のような情報は、それ以上構造を複雑化させるべきではないと考えられるかもしれない。その場合、あえて拡張性のない属性を用いて記述することで、他者がシステムをメンテナンスする場合であっても、それを拡張しない方向に誘導できるかもしれない。

■「ゼロ時間変換」を行うか否かの選択

　「ゼロ時間変換」は常によい選択ではない。いかにゼロ時間で変換できるとしても、それが分かりやすさやシンプルさを大きく損なうとすれば、それは好ましい選択とはいえない。

　では、どのような場合に「ゼロ時間変換」を断念すべきだろうか。残念ながら、それについての明快なヒントを示すことはできない。しかし、見た目が明らかに不自然な構造、解釈をこじつけねば説明できない構造、トリックのように入り組んだ構造ができあがるとすれば、たとえゼロ時間で変換できるとしても、それを選択するのは好ましくないだろう。その場合は、データベースの変換を含む設計変更を地道に行うことが望ましいだろう。

■データベースのリファクタリング

　「ゼロ時間変換」を断念する場合、データベースの設計変更が必要とされる。このような修正を行う場合には、将来的にリファクタリングというテクニックが有効ではないかと考えている。

　プログラム言語にはリファクタリングというテクニックが存在するが、RDBに対するリファクタリングも存在する。XMLデータベースに対するリファクタリングが存在するか否かは残念ながら筆者は分からないが、仮にリファクタリングを行うとすれば、RDBよりもXMLデータベースの方が相性がよいはずである。その理由は以下のとおりである。

　リファクタリングは、あらかじめカタログに用意された小さな修正を機械的に繰り返し適用し、徐々にあるべき姿に仕上げていく。ここでポイントになるのは、小さな修正の繰り返しという点である。自動化された単体テストと併用して、常に同じ動作を維持しながら、ソースコードを変容させていくのである。しかし、RDBは、正規化の都合でテーブル構成が大幅に変わるような修正を行う場合には、小さな修正の積み重ねでそれを行うことは困難となる。XMLデータベースはテーブルに分割する必要がないので、テーブル構成が大幅に変わるという事態は起こさずに済み、小さな修正の積み重ねで設計変更を完了することができる。

　具体的なXMLデータベースのリファクタリング・カタログ作成については、実際にXMLデータベースを使い込んでいるエキスパートの方々に任せるとしよう。実地で繰り返される修正に即して、それをカタログに仕上げていくことができれば、それが最強である。

　しかし、カタログを待つことなく、「重複を取り除く」といった基本的なポリシーを使ってXMLデータベースのリファクタリングを試みることはできるだろう。要は小さな修正を積み重ねて、シンプルなデータベース設計を得ることができればよいのである。（次ページへ続く）

3/5

Index
XMLデータベース開発方法論（6） 変化に強いXMLデータベース設計とチューニング
	Page 1 ・前回のおさらいと今回のテーマ ・ノイズまみれのシステム
	Page 2 ・変化に追従する柔軟なデータ構造 ・拡張のためのスタブ
	Page 3 ・YAGNI再び ・要素と属性の問題再び ・「ゼロ時間変換」を行うか否かの選択 ・データベースのリファクタリング
	Page 4 ・データ構造の最適化の必要性 ・準備段階 ・追加／削除の最適化
	Page 5 ・クエリの無駄を省く ・クエリの効率アップ ・「標準」に魂を奪われるな！ ・連載の終わりに

XMLデータベース開発論

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