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

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

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

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

20-80ルール 80％の恩恵は20％の仕事から得られる 『XPエクストリーム・プログラミング入門』ケント・ベック著　ピアソン・エデュケーション刊

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

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

　この連載の第1〜3回までは、ある種の議論の前提を示すために存在する。これは、いくつかの常識を壊し、別の常識を提示するという役割を持っていた。そして、今回（第4回）以降は、その前提の上に立って、実践的なXMLデータベースの使い方に関する話題に入っていく。期待していた読者にはお待たせした。実は、前半と後半では、想定読者が違うので、今回からはより多くの読者に興味を持っていただけると思う。

　さて、前回までの内容を要約しておこう。XMLデータベースの活用領域は2つの尺度によって決められると筆者は考えた。1つは、規模である。規模が変わると性質が変わることがある、という前提を取るなら、規模に関係なく利用できる技術よりも、規模の違いに対応して、その規模に最適な技術を採用することがよりよい結果を生むことになる。もう1つは、変化である。無秩序に変化し続ける「混沌」、一切の変化がない「秩序」、そして、その中間領域では要求される具体的な資質が異なり、技術を使い分けることが必要とされる。そして、変化への要求は不可避であるという前提を取るならば、一切の変化がない「秩序」という領域でデータベースを扱っていくことはミスマッチであり、どうしても中間領域に適した技術が必要とされる。

　この、「規模」と「秩序」という2つの条件を用いて表を描くことで、XMLデータベースが適する領域が明りょうに見えてくる……、というのがこの連載の第1〜3回の内容であった。

図1　XMLデータベースが適する領域 第3回「変化は抱擁せざるを得ない、しかも禁欲的に」の図8を再掲。

　さて、今回の内容は、XMLデータモデルによるデータベース設計の基礎である。このテーマには、実はXMLデータベース専用とはいいがたいノウハウが含まれる。つまり、XMLデータベースではなく、一般のXML文書を設計する（スキーマを記述する）ために有用なノウハウが含まれる。それらのノウハウは、XML技術者であれば、いまさら読むまでもないと思うかもしれない。しかし、今回はそれも含めてあえて記述する。その理由は2つある。

　第1の理由は、第4回以降の主たる想定読者は、XML技術者というよりも、RDBとSQLに慣れ親しんできたデータベース技術者と考えているためである。一応、要素や属性はどのように書くかというXMLの基礎知識は持っていることを前提とするが、XMLを深く突っ込んで使ったことはない、という水準を想定している。彼らに、一度XML界を通過してからXMLデータベースの世界に来てくれと求めることは、無駄であるだけでなく、さまざまな有害な問題を引き起こす可能性がある（この件の詳細は残念ながら誌面の都合で割愛する）。そのため、XML界を経由しないRDB→XMLデータベースという直接移行経路を設定するという意味で、基本的な事柄もここで解説する。

　（さらに、もう1つ補足すれば、自分はXMLを完ぺきに理解していると考える人たちの中には、少なからず本人の自負する水準と実際がかけ離れているケースがあり、基礎の確認は有益であるという配慮がないともいえない……）

　第2の理由は、通常のXML文書の設計とXMLデータベースの設計は、似て非なる部分が存在するためである。今回の内容にも、そのような相違がいくつか出現するが、詳細は本連載の第6回に解説できると思う。つまり、通常のXML文書の設計と一致しない部分が存在するため、単に通常のXML文書の設計手法を学ぶだけではXMLデータベースを扱うのに不十分だということである。それ故に、この連載の今回以降では、似て非なるXMLデータベース向けの解説を行い、単なるXMLの設計方法の反復にはならない。

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

■XMLとは何を示すか

　本来は書く必要がないことなのだが、XMLに親しみのない読者、あるいはXMLを誤解している読者のために説明しておこう。

　この連載で扱うXMLとは、Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004（XML 1.0勧告）を示す。これ以外のXML関連の技術、標準、仕様、概念、神話、都市伝説、宗教的盲信などは、XMLの内には含めない。これにより、あたかもXMLとイコールであるかのように語られることがある電子商取引（BtoB）、Webサービス、サービス指向アーキテクチャ（SOA）などは、XMLの中に含まれない。また、XMLの一部であるかのように語られるExtensible Stylesheet Language (XSL)、XSL Transformations (XSLT)、XML Path Language (XPath)、XML Schemaなども、XMLの内に含めて考えない。

　ただし、例外的にNamespaces in XML, World Wide Web Consortium 14-January-1999だけはXMLの内に含める。これについては、後で詳しく述べる。また、あくまでクエリの手段に限定し、XPathやXQueryを使用することも想定するが、それはクエリの手段であって格納されるデータの本質とはかかわらない。クエリの結果をさらに読みやすい書式に整形するためにXSLTなどの技術を使う可能性があるが、それはXMLデータベースの外の世界の話であり、ここでは直接扱わない。

　一般にXMLの「一部」と考えられている多くのものを、なぜ排除してしまうのだろうか？ 筆者がそれらを嫌いだから切り捨てたいのだろうか？ それともXMLの純血主義のような過激な思想が、純粋なXMLなるものに向かって猪突猛進させるのだろうか？ いや、そうではない。これらの周辺技術を冷静に一度切り落として見せることは、特にXMLデータベースを使っていくうえで重要なステップといえるからである。

　XMLデータベースとは、いうまでもなく情報を記憶する一種の「ストレージ」である。大量のデータを、長期にわたり保管するために使用される。一方で、XMLという技術は、これまで暗黙的に「通信」のための技術であると扱われてきた。電子商取引とはつまり企業間の商取引のための通信技術である。Webサービスもやはり通信技術である。サービス指向アーキテクチャも、やはり通信を前提としたアーキテクチャである。それらに奉仕するために生まれてきた技術群も、やはり通信と深く関係する使い方を暗黙的に想定されていたといえる。

　しかし、ストレージと通信では、要求される資質がまったく異なっている。通信で必要とされるのは、主に標準化され、小さく、寿命の短いデータである。特に、通信では標準化が必要とされることに注意を払おう。通信においては、受信者が理解できないデータを送信することは無意味であり、送信者と受信者が共有する標準化されたプロトコルやデータフォーマットが不可欠なのである。しかし、ストレージに求められる資質とは、それとは正反対である。既存のデータを保管する際に、それが標準に適合しないから保存できないとはいえないし、当然データの総量は大きくなり、寿命も長くなる。

　つまり、要求される資質が正反対といってもよいほど異なるので、通信のための技術体系を、通信の常識を引きずったままストレージに適用してもうまく機能しないリスクを持つのである。

　ここで1つの疑問が生まれると思う。通信のための技術体系をストレージに使うことがハイリスクなら、そもそもストレージにXMLを使うこともハイリスクではないのだろうか。

　これには明快にノーと答えられる。なぜなら、XMLは本来ストレージのための技術だからである。XMLの祖先ともいえるSGMLは、ごく大ざっぱに要約すれば、膨大な文書を長期保存するために生まれたストレージのための技術である。それが、1990年代のCALS（Commerce At Light Speedなどの略語）ブームで通信手段として認知され、後継となるXMLがWWW（World Wide Web）という通信の標準化団体であるW3Cによって勧告されたことから、あたかも通信のための技術であるように受け取られてしまっただけである。確かに、XMLには通信のための技術という側面があることは否定できない。しかし、元をただせばそれはストレージのための技術であり、XML 1.0勧告に関してはその事実を正しく理解している人たちによって、そのための特質を正しく残したまま成立している。

　それ故に、データを保存するストレージとしてのデータベースを指向する読者は、安心してXML 1.0勧告を受け入れてよい。しかし、周辺のさまざまなものについては、受け入れる前にじっくり吟味してみるべきである。そして、仮に受け入れるとしても、使い方については検討を加える必要があるだろう。（次ページへ続く）

1/4

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

XMLデータベース開発論

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