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

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

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

■列挙型の活用

　有限の選択肢を示すために、数値の特定の値に特定の意味を与えることがある。例えば、性別属性の値は男性なら「0」、女性なら「1」とする、と決めることがある。例えば、自由な文字列の記入を許すと収拾がつかなくなるなどの理由で、情報を単純化して保存する場合に使うことがある。

　以下はそれを使用したXML断片の例である。

<名前 性別="0">ツワブキサンシロー</名前> <名前 性別="1">フジヤマミドリ</名前> <名前 性別="0">ピート・リチャードソン</名前>

　しかし、このような一見して意味の分かりにくい番号（マジックナンバー）の利用は、直感的な分かりやすさという観点からは好ましいものではない。これは、DTDなどのXMLのスキーマ言語が備える列挙型の機能を用いて記述すべきだろう。列挙型はあらかじめ列挙した名前トークンのみを許す型である。名前トークンとは、制限された文字（といっても漢字の多くは使用できる）の組み合わせで表現される名前である。例えば、「性別」属性が値「男性」と「女性」のみを許す列挙型であるとすれば、上記のXML断片は以下のように書き換えることができる。

<名前 性別="男性">ツワブキサンシロー</名前> <名前 性別="女性">フジヤマミドリ</名前> <名前 性別="男性">ピート・リチャードソン</名前>

　この場合、以下のような意図しない属性値を含むXML断片はスキーマによる検査によって妥当ではないと判定され、排除することができる。

<名前 性別="女装者">大空ひばり</名前>

　しかし、例外的にこのような非標準的な入力を受理しなければならない状況が発生する可能性は完全に排除することはできない。明示的にスキーマを必要としないXMLデータベース（この連載で想定するXMLデータベース）は、例外的なXML断片も常に受け入れることができる。もちろん、例外を何もかも受け入れることは「混沌に堕落する誘惑」への敗北であり、厳に避けるべきである。しかし、諸般の事情から受け入れざるを得ない（万策を検討しても回避できない）場合は、その現実から逃避することなく、受け入れる必要がある。

■名前空間を使う

　すでに、この連載で扱うXMLとは、Extensible Markup Language (XML) 1.0を示し、そのほかの周辺のもろもろは含めないと述べた。しかし、例外的にNamespaces in XML（XML名前空間）だけはXMLの内に含めるとした。

　なぜ、このXML名前空間だけを別格として扱っているかといえば、ほかの技術が基本的にXML勧告の上に構築されたものであるのに対して、XML名前空間はXML勧告そのものの機能を向上させる効能を持っているためである。そして、現在のXMLはこのXML名前空間を含めて実用上十分という水準に達すると考えられる。つまり、事実上、XML 1.0勧告の一部がたまたま別文書になっているだけと考えてもよいぐらい重要なものである。

　さて、名前空間という概念は、決してXMLだけのものではない。プログラム言語などにも名前空間の概念を持つものは増えている。その主な効能は名前の衝突の回避である。例えば、複数のXMLデータベースの内容を1つのXMLデータベースに統合した統合データベースを考えてみよう。データベースAで、「名前」要素は文書の著者の名前を示すために使われているが、データベースBでは文書の名前を示すために使われていたとしよう。この2つのデータベースを統合して1つの大きなデータベースにした場合、「名前」要素を検索しても、著者名と文書名のどちらもがまとめて出てきて、あまり実用的ではない。

　このような状況を回避するために、要素や属性は「名前空間」というものに属するとし、名前空間として全世界的にユニークな名前を付与ために、URIを使用している。多くの場合、これにはhttp://で始まる名前が使用されるが、これはWWWの世界でWebサイトを識別する名前の構文の拝借であり、全世界的に一意の名前を容易に得ることができる。つまり、たとえ個人であっても、全世界的にユニークな名前を容易に得ることができる。例えば契約したISPが「http://example.com/~username/」というURLを割り当ててくれた場合「http://example.com/~username/xmlns/mynamespace」というような名前が他人によって使われる気遣いはない（契約を解除して他人が同じ名前で契約した場合は別であるが）。この場合は「http://example.com/~username/xmlns/mynamespace」を名前空間を識別する名前（名前空間URI）として安心して使用できる。

　個々のデータベース、あるいはデータに対して、それぞれ固有の名前空間URIを指定しておけば、データベースの統合が発生しても、名前が区別できないという問題はなくなる。たとえ同じ名前の要素が別の意味で使われていても、名前空間URIが異なっていれば、それぞれを異なる要素であると容易に区別することができるためである。

　仮に、データベースの統合がないとしても、名前空間URIを付加しておくことは有益である。データの一部だけがほかのデータベースに取り込まれて使われることもあるだろうし、通信回線を経由して送信されることもあるだろう。通信回線経由でデータを受け取った側は、それが何を示すデータであるかを、ユニークな名前空間URIによって判定して適切な応用システムに転送することができる。

　いろいろ理屈を書いたが、取りあえず名前空間URIは付けられるなら付けておくべきだといえる。それはわずかな手間で済む作業であるが、不確定な未来に対する大きな保険となる。

　もう1つ、名前空間は、次に述べる既存ボキャブラリ（語彙：ごい）の活用においても重要な意味を持つ。

■既存ボキャブラリ（語彙：ごい）の活用

　世の中には、多くのデータにおいて繰り返し使われる機能が存在する。例えば、文書における「段落」や「見出し」はその一例である。しかし、「段落」を示すための要素は、世の中に多く存在する。XHTMLのp要素が有名であるが、para、paragraph、段落といった名前で記述されることもある。名前空間URIも一定していない。しかし、同じ段落であるのに、それを何回も繰り返し定義するのはまったくの無駄であるばかりか、データの互換性すらなくすことになり有害であるという考えがある。車輪の再発明はすべきではない、とも表現される。

　この問題は、既存ボキャブラリの活用という手法により回避できる。ボキャブラリとは、名前を付けられ、定義された要素や属性などの集まりを意味する。例えば、XMLデータベースに格納するデータの構造に「段落」があるなら、XHTMLのp要素（名前空間URIは「http://www.w3.org/1999/xhtml」）をそのまま使うことで、このような問題を回避できる。

　このようなやり方は、実利的なメリットも生む。例えば、段落を示す要素ぐらい、簡単に仕様書に書けると思うかもしれないが、これを厳密かつ明確に定義するのは結構手間がかかる。そして、大抵の場合段落の要素だけでは終わらず、いくつもの要素や属性を定義しなければならない。その手間と労力は実はばかにならない。しかし、XHTMLなどの実績ある既存仕様の要素や属性を借用してくるなら、それらの文書を参照するように1行書くだけで終わってしまう。これが、既存ボキャブラリの活用の実利的メリットである。

　しかし、既存ボキャブラリの活用にはデメリットも存在する。まったく別個の言語で定義された要素や属性は、分かりやすいとは限らず、また自前で定義した名前との間で一貫性を持たないかもしれない。つまり、前回に説明した「分かりやすい要素名、属性名」や「一貫した名前」といったルールと相反する可能性がある。このような矛盾が大きな問題となった場合は、メリットとデメリットをてんびんに掛けたうえで、どちらのルールを優先するかを決断する必要がある。

　なお、既存ボキャブラリの活用にも20-80ルールを適用すべきであることに注意が必要である。既存ボキャブラリの活用は、20％の労力で80％の達成度を目指すべきであり、100％の達成度を目指すべきではない。例えば、これから使いたい要素が海外の難解な学術用言語にすでに含まれているからといって、何カ月もかけてそれを勉強してまでその要素を活用するというのは、労力に比して得るものが少な過ぎるといえる。一方、XHTMLなど、だれもが知っていて日本語の解説も容易に手に入る言語の要素を活用しないことは、あまりに無駄の多い選択であるといえる。（次ページへ続く）

2/4

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

XMLデータベース開発論

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