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

20-80ルールでざっくりXMLデータベース設計

川俣 晶
株式会社ピーデー
2005/9/22

■XMLデータモデルとは何か

　XMLデータベースとは、XMLデータモデルを保存することができるデータベースである（実際には、XMLデータモデルをRDBなどの別のモデルに変換したうえで保存するものと、XMLデータモデルのまま保存するものが存在するが、この連載では主に後者を扱う）。

　では、XMLデータモデルとは何だろうか？ XMLを物理構造と論理構造に分けたとき、論理構造に当たるものがXMLデータモデルだと考えると分かりやすいだろう。

　では物理構造と論理構造とは何だろうか？ 通常、XML文書といえば、以下のようなテキストファイルを思い浮かべるだろう。

<?xml version="1.0" ?> <城址> <名称>世田谷城</名称> <所在地>東京都世田谷区豪徳寺</所在地> </城址>

　ここで、<城址>は開始タグ、</城址>は終了タグと呼ばれる。タグは、「<」で書き始め、「>」で書き終わる。そして、開始タグと終了タグのペアにより、1つの要素が完結する。これがXMLの物理構造である。

　しかし、物理構造を把握するだけでXML文書を書くことはできない。上記のルールをすべて守って、以下のようなXML文書を書いたとしても、これは正しいXML文書にならないからだ。

<?xml version="1.0" ?> <城址> <名称>世田谷城<所在地></名称>東京都世田谷区豪徳寺</所在地> </城址>

　この文書は、確かに開始タグと終了タグが1対1に対応しており、すべての開始タグに対応する終了タグが存在している。それにもかかわらず、このXML文書が正しくないのは、これがXMLの論理構造に反しているためである。

　上記の正しいXML文書は、論理構造という意味では以下のように表現される。

図2　XML文書の論理構造

　XML文書の論理構造は、常にツリー構造として表現され、ツリー構造として表現できないタグの組み合わせはすべて正しくない。上記の誤ったXML文書は、ツリー構造に置き換えることができない（名称要素と所在地要素のどちらがどちらの子であるか確定しない）ために、誤っているのである。

　このようなXMLの論理構造をここでは、“XMLデータモデル”と呼ぶことにする。そして、この論理構造こそがXMLの本質であり、タグを使ったテキスト表記は、XMLデータを表現するための1つの手段にすぎない……と割り切ってみよう。とすれば、XMLデータベースは、論理表現としてのXMLを使うストレージということになり、これも有効ということになる。

　ちなみに、XMLの標準APIの1つであるDOM（Document Object Model）も、XMLデータモデルを異なる表現方法で扱う手段の1つである。これは、物理表現のXML文書を、オブジェクトのツリーという別個の表現に置き換えて扱うが、XMLデータモデルは常に維持されている。もちろん、DOMも公式に支持された仕様であり、XML文書を別の表現に置き換えることは、否定されていない。

　しかし、なぜXMLデータモデルに固執する価値があるのだろうか。その結論は、次回、設計に関する話題のまとめで述べることにする。

■XMLデータモデルの特徴

　XMLデータモデルにはいくつもの特徴がある。その中で、特に大きな特徴を以下にまとめた。これらの特徴は、XMLデータベースの設計と深くかかわるので、目を通しておくと分かりやすくなるだろう。

• ツリー構造である
• 要素と属性という2つの記述方法がある
• 要素や属性の値に数値型などはなく、すべてテキストとなる
• データの順番は常に維持され、順番は意味を持つ（属性を除く）
• データの重複や欠落などを許容する
• 通常、RDBのテーブルのように分割されず、全体が1つの塊として使われる

■XMLデータベース設計における20-80ルール

　「20-80ルール」には、似たような名前を持ちながら、異なる意味を示すものが多くある。「売り上げの8割は全顧客の2割が生み出している」であるとか「処理にかかる時間の80％はコード全体の20％の部分が占める」といった意味で使われることがある。冒頭に引用した文章は、「80％の恩恵は20％の仕事から得られる」という解釈を取っている。

　XMLデータベース設計においては、この法則を以下のように解釈してみることにしよう。

多種類のデータを一貫して扱う設計の80％は、20％の労力によって得られる

　これは、以下のような状況を意味する。例えば、似て非なる100種類の文書を格納するXMLデータベースを設計する際、80種類の文書を一貫性のある形できれいに扱うスキーマを記述するだけなら、全体の20％の労力で到達できるということである。そして、残された20種類の文書も一貫性のある形で扱うために、残り80％の労力が消費されることになる。

　さて、話はここでは終わらない。実は、残り80％の労力を注ぎ込んで完成されたスキーマは、もしかしたらすべての文書に対する一貫性を持っているかもしれないが、それが扱いやすく分かりやすいスキーマであるとは限らない。むしろ、きれいに収まらないものを無理やり統合したスキーマは扱いにくいモンスターになっている可能性すら考えられる。それを運用することが、本当に好ましい結果を出すかは分からない。

　であるならば、スキーマのモンスター化を防ぐために、20％の労力で完成したカバー率80％のスキーマを採用し、それに該当しない文書はすべて例外的なデータとしてそれぞれ専用スキーマを適用して扱うというのも選択肢としてあり得るだろう。そして、この連載では、思い切って、このような選択を推奨してみることにする。XMLデータベースは柔軟であり、どのようなデータでも受け入れることができるので、統一された1つのスキーマに固執する必要はない。むしろ、きれいに1つに統一できないデータを扱う場合には、無理に1つのスキーマにまとめることの方が有害であるとすらいえる。つまり、一貫した設計は20％の労力で実現される80％の水準で止めておき、それ以上の設計のカバー率を上げることは誤りと見なす。

　さて、1つのスキーマに統一できれば、美しいし、システムもシンプルになり、楽ができると考えることを、ここでは「秩序に堕落する誘惑」と呼びたい。そして、カバー率100％のスキーマを目指すことはこの誘惑に敗北することを意味する。この誘惑に敗北した場合、スキーマそのものが過剰に複雑化し、おそらくシステムはシンプルにならないし、楽もできないだろう。場合によっては、長い時間を費やした揚げ句、そもそもスキーマを記述できないかもしれない。さらに、変化を前提にするなら、100％のスキーマは永遠に作ることができないかもしれない。未知の未来の要求を先取りして設計することはできないからである。

　一方で、カバー率100％のスキーマを目指すことが徒労であるなら、そもそも一貫性のある設計など行わない方がよい、と考えることも誤りである。これは、「秩序に堕落する誘惑」とは正反対の方向性を持つ「混沌に堕落する誘惑」への敗北である。もしも、すべてのデータを別個に行き当たりばったりに処理すればよいと考えるならば、システムの複雑さは爆発的に増大し、下手をすれば手に負えなくなる。手に負える水準に収まっていたとしても、無駄な手間と時間を多く要求されるだろう。わずか20％の労力で達成できるカバー率80％の一貫性は、これらを回避するために重要な価値を持つ。

　つまり、XMLデータベース設計における20-80ルールとは、20％の労力で達成できるカバー率80％の一貫性の達成を目指すべき目標とし、これ以下は「混沌に堕落する誘惑」への敗北と見なし、これ以上は「秩序に堕落する誘惑」への敗北と見なすということである。

　いうまでもなく、このようなやり方は、柔軟性の高いXMLデータベースでのみ実践可能であり、正規化のために100％の一貫性を要求するRDBなどでは極めて実践しにくいものである。

　ちなみに、ここで使われる20％や80％という数字は、象徴的な意味合いにおいて使われているもので、実際の現場においてはこれが増減することがあり得るだろう。また、対象によっては、そもそも割合を厳密に数値で示すことができないかもしれない。大体の傾向として、おおむねこれぐらいの比率に落ち着くことが多い、という程度に理解しておくとよいだろう。（次ページへ続く）

2/4

Index
XMLデータベース開発方法論（4） 20-80ルールでざっくりXMLデータベース設計
	Page 1 ・前回のおさらいと今回のテーマ ・XMLとは何を示すか
	Page 2 ・XMLデータモデルとは何か ・XMLデータモデルの特徴 ・XMLデータベース設計における20-80ルール
	Page 3 ・分かりやすい要素名、属性名 ・一貫した名前 ・関連する情報をグループ化する
	Page 4 ・重複の除去 ・分割と階層化を行う

XMLデータベース開発論

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