【RDBとの違いが明快に分かる】 これだけは押さえておきたい XML-DBの基本操作とその仕組み   翔泳社『DBマガジン』2007年4月号 「XML&XML-DB徹底解剖」に掲載   伊奈正剛/西澤晶

XML-DBの特徴

XML-DBとは何か

データベースとは、そもそもデータを格納し操作する仕組みのことを言う。「大量のデータから効率良く目的のデータを検索したい」。そんな目的から生まれたものだ。そのため、XMLデータベース（以下、XML-DB）を簡単に説明すれば、「大量のXMLデータを格納し、効率良く操作できる仕組み」ということになる。

XML-DBもリレーショナルデータベース（以下、RDB）もデータを格納し操作する点では同じだが、異なるのは扱うデータの構造だ。

RDBに格納するデータは「リレーショナルデータ」と呼ばれる表形式のデータになる。これに対して、XMLデータのデータ構造は「階層型」である。

XMLデータは、データの要素を「タグ」という記法で記述し、その要素を入れ子にすることで階層構造を表現できる。タグを見るとHTMLと同じように見えるが、HTMLは使用できるタグが決まっているのに対し、XMLは自由にタグを設定し使うことができるという違いがある。

階層構造で表現できるものには、WordやPowerPointのアウトラインで示されるドキュメントの構造や、会社の組織図、オブジェクト指向言語のクラス階層など、さまざまなものがある。自由にタグを設定し、階層構造を表現できるXMLは、これらのデータを表現するのに向いている。リレーショナルデータでは、このような階層構造を表現するのは難しい。XML-DBは、このXMLデータの階層構造を活かした形で格納できるデータベースなのである。

XML-DBの2つのタイプ

XML-DBには大きく分けて「ネイティブ型」と「ハイブリッド型」の2つのタイプがある。ネイティブ型はXMLデータを扱うことに特化したもので、ハイブリッド型はRDBにXMLデータを扱う機能を追加し、2つの機能を統合したものだ。

しかし、この2つのタイプの違いはこれだけではない。ネイティブ型は、特に大量のXMLデータを格納し、高速に検索したいという要件に向いた構造を持っている。今日ではテラバイト級のデータを扱えるネイティブ型の製品も登場している。また、インデックスを自動で設定するなど、エンジニアを悩ませずに気軽に扱えるという利点もある。

一方のハイブリッド型は、主にRDBのデータを使うが、XMLデータも併せて使いたい場面にその威力を発揮する。RDBと同様に検索と更新のバランスを考えながらインデックスを設定する必要があるが、その分トランザクション処理が多いシステムにも向いていると言えるだろう。

この2つのタイプは使用する目的に応じて利用するため、どちらが優れているのかは一概に言えるものではない。

XML-DBで管理するデータ

XML-DBを説明するにあたり、取り扱うデータが必要だ。今回は、XMLデータとして企業の各部門の「週報」を取り上げることにする。このデータを用いて活動報告を管理することを想定して解説を進める。

まずはそのデータを見ていただきたい。図1-A、図1-Bに示したのは、週報の構造をXMLで表現したものだ。図1-A は営業部門、図1-BはSE部門の週報になる。

図1-A：営業の週報データ

図1-B：SEの週報データ

週報は言うまでもなく、その週に行なった活動について報告するものだ。多くの場合、顧客やプロジェクトなどの項目に活動を分類して書くので、階層構造になることが多い。各自が提出する週報はそれぞれ小さな情報に過ぎないが、横断的に企業内すべての部門の週報を集めれば、会社全体の現状を把握するのに役立つ。

例えば、複数の営業所での活動を取り出して集計することにより、全社的な営業活動の状況をリアルタイムで知ることが可能になる。また、同じ顧客を担当する営業とSEなどほかの部門からのレポートをいっしょに参照できれば、会社全体にどのような問題点があるのかを早い段階で関係者と共有することが可能になる。これらを実現するには、週報データをデータベースで一元管理する必要がある。

一般的に週報のフォーマットは、各部門において局所最適になるように決められているため、部門ごとに異なる報告項目を持つことが多い。図1-A、図1-Bの週報データを見比べてほしい。同じ週報データだが、営業とSEの週報は異なった構造になっている。

図1-Aの営業の週報は基本的には顧客単位で記述しているのに対し、図1-BのSEの週報にはプロジェクト単位で活動を記述している。また、図1-Bではプロジェクトをさらに部門固有の要素であるフェーズごとに分けて進捗状況が記述されている。さらにそれぞれの階層で問題点も記述されている。

このような構造のバリエーションを持ったデータをどのように一元化するかが、全社の週報を活かすためのカギになる。

半定型文書とRDBの限界

部門ごとに異なる報告項目を一元管理する場合によく行なわれるのが、自由なテキストで記述できる「その他」のような項目を設けて、部門ごとに使い方を決めるやり方だ。これにより、同じ部門内であれば必要なメッセージがどこにどのように書かれているかを理解できる。

しかし、このやり方では部門外から「その他」に何が入っているか分からないために情報を取り出すことができず、部門間をまたがる自動処理は非常に難しい。かといって「その他」ではなく自動処理で情報を取り出せるような項目を設けても、RDBのスキーマ設計が問題となる。

単純に考えれば、社内のすべての部門でどんな報告書のニーズがあるかを把握し、それをすべて表現できるスキーマを作れば良いのだが、それは現実的に不可能に近い。「その他」であればテキスト型のカラムを1つ用意すれば良いが、膨大な量の項目を洗い出して、それぞれについてデータ型やサイズなどを決めなくてはならないからだ。

週報データのようにおおよその構造は同じだが、細かくいろいろ変わるデータのことを「半定型文書」と言う。RDBでは、半定型文書の処理は難しいのだ。実は、この難問をクリアするための仕組みがXML-DBなのである。その理由は以降で解説する。