レベル: 初級 Elliotte Rusty Harold (elharo@metalab.unc.edu), Adjunct Professor, Polytechnic University
2005年 6月 06日 金づちしか道具がないときには、あらゆるものが釘に見えます。唯一のツールがリレーショナル・データベースのときには、あらゆるものがテーブルに見えます。ただし、現実はもう少し複雑です。データは表形式になっていない場合も多く、その本来の構造により適したツールを使った方がよい場合があります。データがXMLのときには、それを管理する適切なツールはネイティブXMLデータベースかもしれません。重要なXML処理ニーズを持つアプリケーションの多数のクラスにとって、ネイティブXMLデータベースは非常に強力なツールです。ネイティブXMLデータベースの性質を探り、開発者のツールボックスに加えられたこの新しいツールに何が期待できるのか、その概念について把握しておきましょう。
リレーショナル・データベース全般、特にSQLデータベースは非常な成功を収め、実際のインストール台数で常に、とは言えないにしても、ほとんどライバルがいなくなったかのように感じてしまうほどです。（実際には、多くのデータがいまだにIMS(TM)のように階層的な大型コンピューター専用データベースに閉じ込められていて、さらに多くのデータがFileMakerのようなローエンドの非SQLデータベースに格納されています。）しかし、リレーショナル・データベースが多くの問題に適しているとしても、XMLドキュメントには適していません。少なくとも、XMLドキュメントの汎用性を活かしきることはできません。XMLドキュメントを細分化してリレーショナル・テーブルに格納したり、あるいは1つの大きなブロブとして扱うことはできますが、どちらの方法でも、インデックス付けや高速クエリーには適していません。実際、ドキュメントを細切れにすると、要素の順序、処理命令、コメント、空白類など、多くのアプリケーションで重要な要素の詳細が失われることになりがちです。そもそもXMLドキュメントは、直列化テーブルとは構造が違います。フィールドとレコードの境界は、XMLドキュメントの境界とは一致しません。このような部分が重要になってくるパブリッシング・システムなどのアプリケーションでは、その情報格納ニーズから、リレーショナル・データベースよりもさらに進んだ機能が必要になってきます。
従来、テーブルに適さない情報はファイル・システムに格納されてきました。しかし、この方法はいささか時代遅れであり、おそらく何年も前に見捨てられているべき方法でした。いまや莫大な量のデータがXMLでコード化され、その量は日々増え続けています。しかし、多くの人は、これらのXMLドキュメントをファイル・システムに投げ入れるだけで、（個別のドキュメントの内部構造とは別の）ドキュメントの集合によって形成されるスーパー構造を管理することに、あまり考慮を払っていません。そろそろ、もっとましな方法を考えるべき時に来ています。
その結果、さまざまなベンダーがネイティブXMLデータベースをリリースしました。ネイティブXMLデータベースは、テーブル、レコード、フィールドではなく、XMLドキュメントと要素を基本構造として扱うデータベースです。このようなデータベースでは、開発者は、作業対象のドキュメントの構造に適したツールと言語を使用することができ、生産性を向上させることができます。新聞の発行、Webサイトの管理、Webサービスなど、大量の文書処理が必要なタスクでは、ネイティブXMLデータベースは従来のリレーショナル・データベースのパフォーマンスを大幅に上回るとも考えられています（実証されたわけではありませんが）。
データベース・モデル
リレーショナル・データベースの基礎となっている汎用的な数学理論は、30年前にE. F. Coddによって打ち立てられ、その後の数十年間でC. J. Dateなどによって拡張され、説明されてきました。この理論の実装は、常に理論のとおりにいくわけではありません（むしろ、常に理論のとおりにいかない、と言うべきでしょう）。しかし、この理論は、「リレーショナル・データベース」という用語が意味するものについて、世間一般に共通の理解をもたらしました。「SQLデータベース」と言えば、さらに明確な理解が得られます。ISO標準によって、そういったデータベースに必要なものが正確に規定されているからです。
ネイティブXMLデータベースの世界では、状況ははるかに不透明です。まだ発展段階にあるというのが、その一因です。標準は策定中であり、このようなデータベースとのインターフェースに必要なもののごく一部をカバーしているに過ぎません。事実、私がここでネイティブXMLデータベースについて述べることの大部分は、「ネイティブXMLデータベース」と呼ばれている製品のすべてに当てはまるわけではありません。しかし、谷間の霧は晴れつつあります。いくつかの例外はあるでしょうが、少なくともほとんどのXMLデータベースに当てはまる概略的な説明を、ここで述べても差し支えはないでしょう。
まず、XMLモデルとリレーショナル・モデルを比較してみましょう（表1）。これはリレーショナル・モデルに対するXMLモデルの比較だと言うべきでしょう。リレーショナル・モデルはかなり詳細に定義されていますが（常に忠実に実装されているとは言えないにしても）、XMLモデルには、デファクト・スタンダードにしろ法律上の標準にしろ、そのような標準がないからです。それでも、表1によって、ある程度の概念は把握することができます。
表1. リレーショナル・データベースとXMLデータベースの比較
|
リレーショナル・データベース
|
XMLデータベース
| | リレーショナル・データベースはテーブルを含む。 | XMLデータベースはコレクションを含む。 | | リレーショナル・テーブルは、同じスキーマのレコードを含む。 | コレクションは、同じスキーマのXMLドキュメントを含む。 | | リレーショナル・レコードは、名前付きの値の順序なしリストである。 | XMLドキュメントはノードのツリーである。 | | SQLクエリーは、順序なしレコード・セットを返す。 | XQueryは、順序付きノード・シーケンスを返す。 |
 |
採用曲線の谷？
今はXMLデータベースの世界を探検するのに悪い時期ではありません。ネイティブXMLデータベースは、2つの隆起を持つ古典的な採用曲線に従っているようです。初期のXMLの派手な宣伝とドットコム熱により、XMLデータベース・テクノロジーに多くの関心が集まりました。その結果としてのデータベースは市場を揺るがし、その淘汰の中で、多くのベンダーが地位を失い（Zvon、Stanford）、買収され（XYZFind、Coherity、Excelon、B-Bop）、業績が低迷し（Apache）、開発を中止し（MindSuite）、事業撤退しました（Tendara）。それにもかかわらず、このデータベースに対する真のニーズは存在しています。初期の製品は、機能を盛り込みすぎであり、価格が高すぎために売れませんでしたが、現在のところ、状況はかなり好転しました。 |
|
実装によって、それぞれの事情は異なります。ネイティブXMLデータベースの中には、実際にはコレクションという概念を持たないものもあります。1つのコレクションで複数のスキーマをサポートできるデータベースもあります。いくつかのローエンドのデーベースは、スキーマをまったくサポートしていません。（このようなデータベースは、予想以上に便利です。結局、重要なのはスキーマではなくインスタンス・ドキュメントだからです。）最初期の製品の中には、DTDしかサポートしていないものもありました。現在、ネイティブXMLデータベースの中で最も広くサポートされている言語は、W3C XML Schemaです。実際、データベースのニーズが、従来のリレーショナルにしてもネイティブXMLにしても、W3C XML Schema言語の設計の主要な推進力でした。しかし、この言語に対する落胆が広がるにつれて、いくつかのベンダーはRELAX NGに目を向け始めましたが、実際の製品に実装されたのはまだ見たことがありません。
ほとんどのXMLデータベースでは、基本単位はXMLドキュメントであり、従来のデータベースのレコードにほぼ相当します。ネイティブXMLデータベースの大きな利点の1つは、複数のXMLドキュメントに含まれる情報を組み合わせる（SQL用語で言うと「結合する」）クエリーを実行できることです。複数のドキュメントをクエリーする必要性から、XQuery、すなわち、ネイティブXMLドキュメント向けのクエリー言語が設計開発されました。これは、XPath 2に基づいています。事実、複数のドキュメントをクエリーできるかどうかが、おそらくXPath 1とXPath 2/XQueryの最も基本的な違いです。SQLとリレーショナル・データベースの関係に相当するのが、XQueryとネイティブXMLデータベースの関係です。
ただし、XQueryはSQLほど多くのことができるわけではありません。SQLには、SELECT、INSERT、UPDATE、DELETEという4つの基本的操作があり、テーブルおよびユーザーの作成と削除のためのコマンドもありますが、XQueryはSELECTで始まり、SELECTで終わります。XQueryでは、XMLデータベースから情報を取り出すことができますが、それだけです。データベースにドキュメントを追加したり、データベースからドキュメントを削除したり、既存のドキュメントを修正したりといったことはできず、機能面にかなり大きな穴が開いていると言えます。
さしあたり、ほとんどのネイティブXMLデータベースは、さまざまな独自の方法でこの穴を埋めています。こういった方法の多くがXQuery拡張として実装されています。ここで最も標準に近い方法は（月は木星よりもブルックリンに近いという程度のことですが）、XUpdateです。XUpdateは、dbXML、eXist、X-Hive/DBなどの製品によって実装されています。たとえば、Surname子要素の値が"Harold"であるすべてのAuthor要素にRusty要素を追加する簡単なXUpdateを以下に示します。
ただし、XUpdateは１つの可能性に過ぎず、これを実装していないネイティブXMLデータベースの方が実装しているデータベースよりも多いのです。Xupdateが充分なシェアを獲得するためにはまだまだ課題が山積みで、しかもこの4年間、課題はほとんど解決されていません。より長期的に見てみると、W3C XQueryワーキング・グループは、XQueryにアップデート機能を追加すると見られています。しかし、この作業は始まったばかりで、現在はまだ要件が公開されただけです。グループは、この言語の実際の構文についての提案すら公表していません。このグループがXML版のSELECTを実装するだけでも5年かかったことを考えると、あまり期待しない方がよさそうです。
ネイティブXMLデータベースの利点
ネイティブXMLデータベースの現状が不安定なのに、なぜデータベースの使用を検討するのでしょうか。おそらくその理由は、1980年代前半にリレーショナル・データベースの使用が検討された理由と同じでしょう。25年前、リレーショナル・データベースは、処理速度が遅く、バグも多く、非標準でメモリばかりを浪費するものでした。それにもかかわらず、従来のシステムと比べて多くの利点があり、時間とともに改善されてきました。
今日のネイティブXMLデータベースは、たしかに非標準です。中には、と言うよりも、おそらくほとんどが低速なメモリ食いです。しかし、ムーアの法則の25年間によって、この問題はそれほど大きな問題ではなくなりました。どのくらいバグが含まれているかは、製品によってさまざまです。今すぐにでも実用になるものもあれば、食料品リストの管理にも使えないと思うものもあります。しかし、管理すべきXMLデータが大量にある場合、このテクノロジーには現在の製品群を評価するに値する利点が確かにあります。
すべて一箇所で
ネイティブXMLデータベースの最も重要な（そして最も見過ごされがちな）利点は、すべてのコンテンツを検索と管理が容易な一箇所にまとめておけるということです。ファイル名規則やディレクトリー構造を気にする必要はありません。すべてがデータベースの中にあるのです。情報を得るためにするべきことは、クエリーを作成することだけです。ファイル・システムはもはや時代遅れとなった単一ユーザー・システムに適したものですが、そのようなシステムでも、従来のファイル・システムはいささか時代遅れになっています。AppleやMicrosoft(R)などの企業は、各社のオペレーティング・システムの基礎をデータベースに似た構造へと徐々に移行しつつあります。異種システムにまたがって、さまざまなレベルのアクセス権を持つさまざまなユーザーがアクセスし編集するデータの場合、データが何らかのデータベース構造になっていなければ対応できません。今日、あまりにも多くの重要なデータが最高経営責任者のノート・パソコンや主任プログラマーの個人用CVSリポジトリーのMicrosoft WordファイルやExcelスプレッドシートに格納されています。この情報の全部ではないにしても一部は、データベースによってバックアップされた集中リポジトリーに格納するのが妥当でしょう。こうすれば、必要なときに情報を見つけられるだけでなく、専門家によって集中管理される冗長システムとバックアップが可能になります。コンテンツをデータベースに格納することによって、上司がバックアップされていないノート・パソコンをタクシーに置き忘れても、7桁の金額の見積書とそのサポート・ドキュメントのすべてをなくさずに済みます。
同じデータの複数のビュー
データをデータベースに格納することに関連した利点は、格納することにより、同じコンテンツの複数のビューが可能になることです。たとえば、社内向けの見積書には、入札しようとしている会社には見せたくない、予想されるコスト構造とマージンに関するコンテンツを含めることができます。もちろん、この利点はネイティブXMLデータベースだけのものではなく、リレーショナル・データベースでも同じことができます。しかし、ここで改めて述べておくべき利点です。おそらく、この場合におけるネイティブXMLデータベース固有の利点は、最終報告書そのものがもう1つのデータベース・クエリーになることでしょう。この報告書は、クエリーの出力をCrystal Reportsなどの非標準ツールで操作して作成されたものではないのです。
リレーショナル、ネイティブXML、またはその他のデータベース・システムに固有の利点のほかに、XMLの処理にデータベースを使用することには、いくつかの利点があります。
パフォーマンス
最初の利点はパフォーマンスです。入念に設計され、実装されたネイティブXMLデータベースでのクエリーは、ファイル・システムに格納されたドキュメントに対するクエリーよりも確実に高速であり、それにはいくつかの理由があります。まず、データベースでは、処理速度を上げるためのさまざまなインデックス付けテクニックを使うことができます。たとえば、ドキュメント内のすべてのID値テーブルを保持すれば、Jaxen XPathエンジンなどの非データベース・ツールのようにツリーを探し回らなくても、特定のIDで要素に直接ジャンプできます。データベースでは、各ノードにシーケンス番号を割り当てることができるので、各ノードの位置がわかり、2つのノードのドキュメント順序を迅速に比較することができます。
次の理由は、データベースでは、ドキュメントが格納されるときに、各ドキュメントが事前に解析されていることです。したがって、クエリーがアクセスした各ドキュメントの形式が整っているかをチェックしたり、そのドキュメントを表すオブジェクト・モデルを構築したりする必要がありません。これらの詳細はすべて、クエリー・エンジンが使用できる形でデータベース内にすでに存在しています。
XMLデータベースでは、パフォーマンスを最適化するために、ほかにもさまざまなテクニックが使用されています。そのいくつか（たとえば、スマートなクエリーの再作成）は、データベースによってバックアップされていないツールからも使用できます。ただし、最大のパフォーマンス向上をもたらしているのは、挿入および更新の速度を犠牲にしたクエリー速度の向上にあります。データベースが真価を発揮するのは、ドキュメントを追加または修正し、その作業結果を格納し、その後、その結果を使用して電光石火のクエリーを実行するときです。多くのアプリケーションがそうであるように、クエリーの頻度が挿入や更新の頻度よりはるかに高い場合、ドキュメントをデータベースに入れるために余分なコストを支払っても、データを取り出すときに十分元が取れます。
非常に大きなドキュメント
データベース以外のシステムと比較した場合のネイティブXMLデータベースの2つ目の利点は、ドキュメントのサイズです。データベースはディスクでバックアップできるので、基本的に任意の大きさのドキュメントを処理できます。SAXやSystem.Xml.XmlReaderなどのストリーミング・ツールでも同じことができますが、XSLT、XPath、DOMなどのツリー・ベースのツールでは、ドキュメントが約100メガバイトを超えると限界に達します。ネイティブXMLデータベースを使用すると、XSLT、XQuery、DOMなども任意の大きさのドキュメントを処理することができます。
1ビットも失われない
全部ではありませんが、一部のネイティブXMLデータベースの最後の利点は、注目に値します。それは、解析されていないオリジナルのドキュメントを1文字ずつ、または1バイトずつ取り出せることです。この機能は、オリジナルのドキュメントを最後の1バイトに至るまで正確に再現する必要がある法律関係の作業に不可欠のものです。この機能は、ソフトウェア開発、特にバグ追跡やパフォーマンス最適化においても重要です。これらの作業では、一見すると重要には思えない些細な部分が、実は重要な意味を持ってくることがあります。実際にバグを引き起こしているのが、10メガバイトの中の2バイトだとしたら、データベースがその2バイトを変更しないという保証が重要になってきます。XMLドキュメントを細切れにしてからリレーショナル・データベースに格納するシステムも含めて、パーサー・ベースのソリューションでは、タグ内の空白、数字による参照など、通常はあまり重要ではない部分が失われる場合があります。１00回のうち99回はこのような場合を気にしなくても、残りの1回は、この細部こそが重要であり、この細部が保存されているデータベースを探す必要があるという場面に遭遇するでしょう。
先を見る
データが増えるほど、何らかの種類のデータベースを使用してデータを管理することが重要になってきます。データがXMLの場合は、安定したネイティブXMLデータベースを使用すべきです。その際に問題になるのは、そのようなシステムをどこで見つけたらよいかということです。XQueryのような基礎技術が完成までに少なくともまだ1年はかかり、その他の技術はまだ着手されたばかりという現状を踏まえると、現時点で安定したシステムを本当に見つけられるのだろうかと疑問に思うかもしれません。それでも、将来、時間的にも資金面でもアップグレード・コストを支払うということを十分に理解したうえで採用する限り、ネイティブXMLデータベースには、移行を考慮するに十分な利点があります。
参考文献
著者について
記事の評価
| 
