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

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

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

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

YAGNI You Aren't Going to Need It. 「それは必要にならない」

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

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

　この連載の第1回から第3回までは、ある種の議論の前提を示すために存在する。これは、いくつかの常識を壊し、別の常識を提示するという役割を持っていた。そして、前回（第4回）以降は、その前提の上に立って、実践的なXMLデータベースの使い方に関する話題を扱う。前回は、実践的なノウハウの1つとして「XMLデータモデルによる設計の基礎」について、さまざまなトピックについて説明した。例えば、「XMLデータベース設計における20-80ルール」として、「多種類のデータを一貫して扱う設計の80％は、20％の労力によって得られる」という解釈を説明した。このような観点から、すべてのデータを一貫して扱う唯一のスキーマを記述する試みがうまく機能しない理由を説明した。そして、たった1つのスキーマによって全データを扱おうとせず、例外的なスキーマを受け入れるべきと説明すると同時に、それを受け入れるべきときと、受け入れるべきではないときについて述べた。そのほか、「分かりやすい要素名、属性名」「一貫した名前」「関連する情報をグループ化する」「重複の除去」「分割と階層化を行う」といった項目についての説明を行った。

　しかし、これらは筆者として述べたい項目のすべてというわけではない。今回は、前回語り切れなかった、そのほかの多くのXMLデータモデルによる設計の基礎ノウハウについて語っていきたい。

　なお、XMLデータベースは利用実績も少なく、確定した設計指針なども存在しないと思う。ここで述べられている内容は、あくまで、現時点で筆者が考える「よりよい結果を引き出すであろう（容易に想定される悪い結果を回避できるであろう）」設計指針であることに注意を払っていただきたい。つまり、完全であることも、誤りがないことも保証はできない。しかし、少なくともXMLやXMLデータベースを初めて使うという利用者の立場からすれば、いくつもの重大なトラブルを回避できるだけの有益な内容は含んでいるはずである。

■IDの付与

　XMLにはID型という属性の型がある。これは、XML文書全体に対してユニークな名前を与える型であり、特定の要素を識別するために便利である。特に、XMLでは同じ名前の要素が複数存在することも珍しくなく、それらの要素の中から特定の1つを指定するために、ID型の属性の存在は大変便利である。

　しかし、いくつかの理由から、これの活用には注意が必要である。現在、実用性が高いと評価されるXMLデータベースにはスキーマレスという特徴を持つものが多いが、ある属性がID型であるということを指定する手段はDTDをはじめとするスキーマ言語ということになる。つまり、XMLデータベースはある属性がID型であることを知らず、属性値がユニークでなくてもエラーにしない。では、登録時にスキーマによる検査を実施しようと考えたとしても、これは一筋縄ではいかない。全体でユニークであることが要求されるID型の妥当性を調べるには、XMLデータベース全体を調べる必要が発生する。これから登録しようとするXML断片だけを検査しても、妥当性は判定できないのである。もし、データベースのサイズが極めて巨大であれば、データを登録するごとに全体の妥当性検証を行うのは、非現実的な負荷ということになるだろう。

　それ故に、ユニークなIDを与える場合には、ユニークさを常に保証するような名前付けルールを用意するなどの工夫を行うことが必要とされるかもしれない。

　もう1つ注意が必要とされるのは、現在のXMLデータベースの用法には、データの統合という使い方が含まれることである。これには、個別の単体のXML文書を1つのXMLデータベースに格納することや、複数のXMLデータベースの内容を1つのXMLデータベースに統合する作業が含まれる。これらの作業を行うと、当然ID型属性値の重複という現象が起こり得る。この問題を回避するためには、ID型属性値の値を置き換える作業が必要とされる。このような作業が発生する可能性を踏まえ、ID型の属性値を使う場合には、その値は単に識別のために使う便宜上の名前としておき、名前に特別な意味を込めないようにするとよいだろう。

　例えば、ID型の属性値を社員ID番号と一致させ、社員ID番号employee01231の社員の情報には「id="employee01231"」という属性を付けるという用法は、問題を引き起こす可能性がある。この2つの情報は例えば以下のように別個の属性として記述する方がよいだろう。

id="uniq0123" employeeId="employee01231"

■順序のあるデータ、ないデータ

　XMLはデータの順番を保持するが、もちろん保持された順番に意味がないと見なして、順番のないデータを扱ってもよい。

　順番のないデータを扱う場合には、データの一部分だけを自由に抜き出したり、好きな順序に入れ替える操作が問題ないものとして適用される。このような操作を安全に行うためには、前回の「関連する情報をグループ化する」の作業を適用しておく必要がある。関連する情報が並べ替えによってバラバラに分離されてしまう事態は、できるだけ回避しておくとよい。

　一方、順序のあるデータも、順序に関係なく一部だけを抜き出したり、好きな順序に入れ替える作業が適用されることがある。このような処理は、データが本来持っている「順序」という情報を破壊する作業であるが、別の有益な価値を得るために行われることがある。

　さて、このような処理が行われた場合でも、本来の順番を意識したい場合がある。このような場合には、主に抜き出しや並べ替えの対象となる要素にユニークな識別情報が付加されていると便利である。これに使用できる情報としては、絶対にユニークであることが保証された社員番号のような値や、XMLのID型の属性などがある。

　例えば、ID型の属性idを付加した例を以下に示す。

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

　例えば、このXML断片より「フジヤマミドリ」に関する個人要素だけを抜き出したとしよう。この時点で、この要素に関する順序の情報が失われる。つまり、手前が「ツワブキサンシロー」の情報であり、次が「ピート・リチャードソン」の情報であったという情報は失われる。しかし、個人要素に付加されたid属性の値「midori」（全体を通してユニークな値であることが保証される）を使って再度XML断片を検索することにより、その前後の要素が何であるかを確認する手段を得ることができる。

■数値の活用

　XMLは基本的にすべてのデータを文字として記述する。数値とて例外ではなく、文字を用いて記述し、常に文字として取得することができる。しかし、数値は文字であるという理解はXMLデータベースにおいては必ずしも正しくない。数値に関する処理は多発するよくある処理であり、これを高速化するために内部的に数値に変換される。またパス言語であるXPathやクエリ言語であるXQueryも、数値を扱う能力を持っていて、これを活用できる。

　これらを踏まえて考えれば、数値として処理され得るデータは、それ単体が要素や属性の値になるようにすべきである。例えば、平成15〜17年度までの情報を抜き出す、といった数値処理が期待されているときに、以下のようなXML断片を記述することは好ましくない。

<年度>平成十七年</年度>

　この情報は、年号と数値を分離したうえで、数値はXPathやXQueryで扱えるアラビア数字に置き換えるとよいだろう。例えば、以下のようにする。

<年度>   <元号>平成</元号>   <年>17</年> </年度>

（次ページへ続く）

1/4

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

XMLデータベース開発論

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