Ajaxやマッシュアップによる XMLデータ連携が当たり前の時代に   翔泳社『DBマガジン』2006年4月号 「特集「XML&XML-DB徹底解剖　Part1」に掲載   林浩一/高橋浩之

使いどころが見えてきたXML-DB

ここ数年、次々に新しいXML-DB 製品が登場し、機能も特性もバリエーションが増してきた。本節ではXML-DB とはそもそも何であるかを改めて確認した上で、今後の本格導入にあたって押さえておくべきポイントを見ていくことにする。

XML-DBとはそもそも何か

まず、XML-DB とはどのようなデータベースであり、何ができるのか、どのような課題を抱えているのかなどについて説明しよう。

階層構造を扱う

XML-DBとは、XMLの持つ構造を活かした形でデータを格納し、それに対する操作を可能にするデータベースのことである。XML の持つ構造とは、タグを用いて表現されたデータの階層構造のことだ。XML-DBは、これをそっくりそのままデータベース化してくれる。これまでよく行なわれてきたRDB への格納方法では、RDBのリレーショナル形式（表形式）にあてはまるように、XML データを要素レベルで 分解していた。

XMLドキュメントの検索が速い

XML-DBの最大のメリットは、XMLドキュメントの検索が速いことだ。基本的に表形式であるリレーショナルデータでは階層構造をうまく表現できないため、検索性能を上げることが難しい。XML-DB は、 階層構造のデータを効率良く扱うメカニズムを備えている。

大量のXMLデータを安全に管理できる

データベースである以上、大規模なデータを安全に管理するという役割が求められる。初期の製品が普及できなかったのは、ここが不十分だったためだ。1GB 以上のデータを格納できなかったり、できてもパフォーマンスが出ないものが多かった。また、トランザクション機能が不十分なため、更新時にデータの安全性を保てないような製品まであった。
これらの問題については、最近の製品では解決済みだ。数十～数百GB規模のデータを高速で扱うことができるのは当たり前になり、トランザクション機能をはじめとする安全性にも十分な配慮がなされている。

製品選定のミニマムチェックポイント

次に、XML-DB 製品を選定する際に最低限気を付けたいポイントをいくつか挙げよう。

XML-DBの格納タイプは何か

現状のXML-DBは、XMLデータを専門に扱うことに特化した「ネイティブ型」と、RDB にXML データを扱う機能を加えリレーショナルデータと統合して扱えるようにした「ハイブリッド型」の2 つに大別で きる（図9）。「NeoCore XMS（三井物産）」「Cyber Luxeon（サイバーテック）」「TX1（東芝ソリューション）」などはネイティブ型、「Oracle Database 10g（オラクル）」「DB2 9（IBM）」「SQL Server 2005（マイクロソフト）」などはハイブリッド型である。
膨大なXML データを主に参照するような場合は、ネイティブ型のほうが向くだろう。XML データも扱うが、リレーショナル型のデータが主となるような場合であればハイブリッド型は有力な選択肢だ。 また、ネイティブ型でもハイブリッド型でもない「Shunsaku（富士通）」のようなエンジンもある。この製品は全データをサーチするタイプで、検索の高速化に用いるインデックス自体がまったく不要であるという特徴がある。

図9 3種類のデータベース

XQuery に対応しているか

XQuery は、XML データを検索するための標準の問い合わせ言語で、RDBのSQLに相当する。XQueryは製品に依存しない言語なので、XQuery対応製品のほうがエンジニアにとって習熟のハードルが低くなるほか、技術者の獲得自体も容易になる。

スキーマは必須か

XML はスキーマを使って構造を定義できるが、必ずしもスキーマを必要としないという特徴がある。スキーマのおかげで、XMLのタグの意味をコンピュータに伝え、自動処理を効率的に行なうことができる一方、常にスキーマが必要になると、XMLが持つ構造の柔軟さや扱いの手軽さを活かせなくなってしまう。そこで「ウェルフォームド（整形式）XML」と呼ばれるスキーマを持たない形式での使い方も許されている。
XML-DB を使うときに、このスキーマ定義が必須かどうかは重要なポイントだ。RDB の場合、スキーマなしに使うことは考えられないが、XML データはそれ自体が構造を持つので、スキーマがなくても処 理することができる。手軽にXML データを格納して使いたい場合は、ウェルフォームドXML対応製品のほうが良いだろう。

インデックス設定は制御できるか

XML-DB は、高速検索を実現するためにインデックス機能を備えている。インデックスを使えば、検索条件として指定された要素に素早くアクセスできる。一方で、データが変更されるとインデックスを作り直す必要があるので、更新処理が遅くなるという欠点がある。うまくインデックスを設定すれば、検索性能と更新性能とのバランスをとることができるが、そのためには対象となる製品についての深い知識が必要になる。
ネイティブ型の製品の多くは、DB 管理者の頭を悩ませることなく常に高速で安定した検索を可能にするために、全自動でインデックスを設定する機能が実装されている。ハイブリッド型の製品では、DB 管理者がインデックスを設定するのが基本だ。どちらが良いかは一概には言えないので、更新と参照のバランスを考えて決める必要がある。

今後の動向を見定めるポイント

では、XML-DBはこれからの企業内システムをどのように変えていくのだろうか。

XMLの柔軟性を活かしたシステム開発

XML は定型なデータも非定型なデータも表現できるのだが、XML-DB はどんな形のXML データに対してもRDB より効率的に扱えるわけではない。発注書や申請書など構造が完全に定まった文書をXML化すると定型的なXML 文書となるが、これらのデータ構造はスキーマで固定的に表現できるので、RDB でも十分扱える。反対に、ワープロで自由に書いた報告書、プレゼン資料、WebページなどをXML化すると非定型なXML 文書になるが、これらを単にキーワード検索したいだけであれば、「Google アプライアンス」のような文書検索ソリューションで十分だろう。
何らかの構造を持ってはいるが、それが文書全体で完全に固定されているわけではない、半定型の文書を扱う処理こそ、XML-DBを最も効果的に使える場面である（図10）。半定型文書の具体例としては、カタログなどの商品情報、提案書などの営業資料、電子カルテなどの医療にかかわる情報、設計書など製品開発に伴う資料などがある。これらは文書構造に高い自由度が必要ではあるが、共通の構造を利用した処理も求められる。
例えば、「携帯電話など新しい機能が次々に増える製品をさまざまな角度で比較検討できる電子カタログ」や、「販売した顧客や製品構成について類似する提案を見つけることのできる営業支援システム」など、必要な部分を構造化したXML データとして扱うことによって可能になるシステムやサービスは多い。このようにデータを柔軟に扱うことのできるシステムのDB は、XML-DB以外では難しいだろう。

図10 半定型文書の処理に適したXML-DB

オフィス文書の標準化の本当の意味

ODFのようなオフィス文書の標準化も、XML-DB にかかわる大きな動きである。しかし、「それはマイクロソフトOfficeの互換ソフトが増える程度の話で、文書のフォーマットなんか、エンドユーザーには関係ない」と考えている人はいないだろうか。それは大きな間違いだ。オフィス文書の標準化は、業務支援をするシステムのあり方自体を抜本的に変えるほどのインパクトがある。
皆さんはオフィススイートを使っているときに、「今、この機能だけ使えたらいいのに」と思ったことはないだろうか。例えば、Word文書の表の中でExcel シートのように計算をしてほしいとか、Excelシートの変更を修正履歴で管理してもらえれば……といった具合だ。フォーマットがオープンなものになれば、外部プログラムが簡単に作れるので、本体を軽くしておき、普段使わない機能はプラグインとして使うようなシステムの構成をとることが可能になる。
さらに、XML-DBを使えば多数のドキュメントをまとめて扱うことが可能になる（図11）。複数のWordやExcelの文書を組み合わせた文書を自動生成し、それを編集したり、数値データを含む部分だけ取り出して分析したりするなど、さまざまな応用が考えられる。文書フォーマットのXML化だけでこれらのことがすぐに実現されるわけではないが、XML ベースの標準フォーマットの採用によって、これまでには考えられなかったような業務支援システムの可能性が広がるのだ。そのとき、XML-DBがそのシステムの中核を担っていることは間違いない。

図11 標準化で広がるオフィス文書処理の可能性

 

＊　　　　＊　　　　＊　　　　＊　　　　＊

本パートではXML という視点から、特にエンタープライズ領域でのシステムの変化を展望した。XML フォーマットは多様な目的のために、さまざまな領域での利用が広がっている。このことが、XML の持つ“つなぐ”能力をより効果的に発揮する機会を作っている。
2007 年にどこまで変化が進むかは分からないが、さらにその広がりが大きくなっていることだけは確かである。