エンジニアの視点から活用するXMLデータベース 「第1回：事例から見るXMLデータベース適用範囲の広がり」

XML DBの背景の説明

本連載ではXMLデータベース（以下、XML DB）の適用領域や技術の特徴を解説していきます。著者は1998年から現在まで、XMLおよびXML DBに様々な形で関わってきました。

そこで、第1回目はこれから連載するXML DBの概要として、テーマを選ぶ背景を説明します。内容は著者がXMLとどのように関わってきて、どのような方針で取り組んできたかを紹介します。

概要といっても、内容は技術半分・活用半分です。XML技術ありきで解説すると方法が先行してしまい、本来の適用の必然性が失われてしまいます。また適用ありきで話すと、なぜXMLなのかに対する回答ができないことが懸念されます。本連載ではそのようにならないように留意して進めていきます。

パブリッシングビジネスモデルを変える出版のデータベースとして注目

1998年もしく1999年に、「これからはデータベース機能を持ったXMLが注目だ」とある印刷関係の研究会で発表がありました。研究会の話題は大量印刷の時代から個々（ワンツーワン）の時代へ進んでいました。その技術にはデータベースが必要であるということだったので、当時よりXML DB技術者であった筆者が呼ばれました。ただ、その研究会は大きな壁にぶつかっていました。

▲図1：パブリックビジネスがXML DBに期待したこと

データベースと印刷との融合をテーマにしたとき、その両者の違いは技術／ビジネス的に大きなものでした。印刷／出版は普遍（不変）のコンテンツが前提であり、だからこそオフセット印刷などの大量印刷技術が成り立っているわけです。そういった理由から、関係者のその頃の関心は印刷の質と1原版あたりのプリント枚数です。

例えば、読者1人ずつからすると週刊誌のすべてが読む対象ではないはずであり、読みたくない記事もあわせて購入するわけです。雑誌が1つの原稿をもとに数千枚印刷することで読者は安いコンテンツを手に入ることができ、提供側は印刷数で利益を得るのが印刷／出版業界のビジネスモデルです。

話は戻りますが、そういったビジネスモデルを変えるテーマの研究会にデータベースの話題を持ち込む狙いは、読者個々が求める様々なコンテンツに対する要求に応じるためでした。

データベース機能を持ったXMLの採用で、パブリッシングのビジネスモデルを根底から変える可能性があると当時の筆者は夢をみました。しかし、その頃には出版の仕組みを変える条件はそろっていなかったようでした。パブリッシングがXMLに注目するのは多くの時間が必要だったようです。

今ではXML DBはインターネットの急激な普及により、従来のパブリッシングビジネスモデル自身の変更を可能にしますし、パブリッシング自身も変えなければならない状況にいたっています。

印刷／出版関係ではXMLと同様な言語としてSGMLが存在していました。SGMLは記述ルールの複雑さから敬遠されることが多かったので、XMLはその救世主としても注目しました。

SOAに最適なDBに注目

XML DBと従来のデータベースとの違いは、従来のデータベースがアプリケーションで使う情報システム処理に最適な格納を目指しているのに対して、XML DBが顧客／他のシステムとの接点部分で、より現場の業務サービスに近い利用を想定していることです。

また、XMLはさらに進化した機能を持っています。それは情報処理のデータ処理（データベース処理）としての活用であり、XMLのデータベース文書処理とデータ処理の融和を担います。

▲図2：XMLのデータベース文書処理とデータ処理の融和

厳密な意味でのXML DBとは

様々なメディアや雑誌などで「XML DB」という言葉が盛んに用いられますが、厳密に考えると筆者は違和感を持ちます。XML形式のドキュメントを格納する仕組みと捉えられなくはないのですが、XMLのドキュメントやデータ自身がスキーマを持っていますので、わざわざデータベース格納用スキーマを作らなくてはならないという原則はありません。従って、なにをどうマネジメントすればXML DBといえるのでしょうか。

また、スタイルシートやクエリーが国際標準となっていますので、それを使うことで標準操作でXMLのドキュメントやデータを扱えます。こういったことから、DBMSがなくてもXMLはそれ自体がデータ操作機能を保有しているものといえるでしょう。それなのになぜXML DBと名乗る意義は何なのでしょうか。これが、このシリーズの1つのテーマです。

B2Bの電子カタログとしてXMLに着目

筆者が直接XML DBを活用するようになった時期は1999年頃です。ヨーロッパのあるPC販社がXMLを使ったカタログをWebで公開し、B2B・B2Cを行っていることを聞いたのが著者がXML DBを活用しようと思ったきっかけです。

▲図3：XMLを使ったカタログをWebで公開した例

その頃は日本でB2Bが騒がれはじめた時期であり、筆者が所属していた会社も新しいEDIを企画していました。筆者がB2BおよびEDIで得意としたところは、XML電子カタログのドキュメントを受発注という情報処理に結び付けることでした。カタログなどのドキュメントの中には情報処理で扱うデータが含まれており、そのデータを自動的に抽出して業務処理に活用できれば、きっとすばらしいことができると考えていました。

また情報処理のデータを容易にドキュメントに組み入れられれば、機械の冷たいデータ処理と人の温もりのある仕事が連動できるのではないかという夢を描いていました。

技術者にとってのXMLの魅力

技術者にとってXMLの魅力はメタデータです。メタデータのないXMLはあり得ませんし、そのメタデータを自由に定義できるのがXMLです。技術進化の流れはXMLの整備、つまりモデリングへと必然的に進んで行きます。

その頃、ebXMLやロゼッタネットなどの話題の中で、データ構造も含んだメタデータの標準化に急激な注目が集まりだしました。

流通データの標準は蓄積データ（データベースデータの蓄積）に繋げると、両者の関係は「シースルー」の関係となります。このような入り口と内部（データベース）の連携の技術がXMLが得意とする適用分野と捉えられます。

マネジメントシステムとしてのXML

2000年前後はXMLの優位性の議論が盛んに行われていました。その頃のXMLに対する企業の姿勢は推進派と拒否派と二分していました（その傾向は現在でもその空気を継続しています）。

XMLの適用領域は段々と広がってきて、先に述べたB2Bのほかに注目する適用領域としてコンテンツマネジメントシステム、ナレッジマネジメントシステム、ドキュメント･マネジメントシステムの実用化へと進んできました。

▲図4：XML DBの適用範囲の広がり

これら以外にも、ラーニングマネジメントやビジネスプロセスマネジメントなどのマネジメントシステムは沢山あります。

これらのマネジメントシステムのXML採用には、対象とするサービスのデータにXMLを使うものとマネジメントデータ自身をXMLで保有するものとの2種類あります。

特に後者は管理データのXML化技術として急激に進化していきました。このような様々なマネジメントシステムは、適用するサービスを特化したXML DBといえます。

さらに、これらのマネジメントシステムはサービス対象データやマネジメントシステム自身で扱うデータを他のソフトで活用したり、他のソフトウェアのデータを活用したりするために、インポート／エクスポート機能を持たせて、そのデータにXML形式を採用するケースが多いようです。

XMLのマネジメント適用の特長は次のようにまとめられます。

▲表1:XMLのマネジメント適用の特長

表1の特長により、これらのマネジメントシステムは頭にエンタープライズの冠を付けたエンタープライズマネジメントシステムへと発展することになります。

以前、筆者は米国にコンテンツマネジメントの技術調査を何度か実施しました。調査当初のコンテンツマネジメントシステムは個性的なものが沢山存在しており、その違いに目を見張りました。

そのころXMLの採用はまだ初期段階だったので、XMLをブランド定着の手段としている商品（ソフトウェア）も見られましたが、多くの商品はよりよい機能を保有するためにXMLの採用を積極的に進めていました。

初期段階のコンテンツマネジメントシステムで著者が注目したのは、ドキュメントやコンテンツ自身をXML化の特徴と既存の非XMLのドキュメント、コンテンツを扱うためにマネジメントデータのXML化の特徴とその有効性でした。

エンタープライズがXMLにもたらしたもの

コンテンツマネジメントシステムなどのシステムが頭にエンタープライズという冠を付けた途端に、米国の市場の状況が変わってきました。急激な商品の生存競争が起こったのです。特長のないものは消え、強い企業は弱い企業を買収しながら、エンタープライズコンテンツマネジメントシステムなどは恐竜のごとく、巨大化する進化をたどりました。

それまで多数存在していたカンファレンスの開催は延期や中止が続出ししていたことを記憶しています。このような製品およびそれを担いでいた企業の統合化の流れを起こした起爆剤がXMLであったのではないでしょうか。

XMLが起爆剤である理由は異なるマネジメントを統合する強力接着力（統合力）があるからです。その変化（統合）のスピードは瞬間接着（統合）といかないまでも、相当なスピードをもたらしたからです。

多くの製品がはじめに多くの種類を生み、その中で淘汰がはじまると、残ったものは巨大化していきます。しかし、その状況下でも氷河期の哺乳類のごとく寸敏なマネジメントシステムは生き残り、もしくは次の時代を夢みる新たなコンテンツマネジメントシステムも存在しています。

エンタープライズシステムとXML

筆者は数年前にXMLを採用した観測システムの基本設計に参画しました。そのシステムは5つ程度の大きなサブシステムから構成され、全国規模のものでした。そのシステムのXMLの適用の特徴は以下の通りです。

▲表2:観測システムのXML適用の特徴

▲図5：観測システムにおいてのデータ交換

このシステムのサブシステム内の処理について、XMLを使わなくてならないという制約がありませんでした。しかし、他のシステムとのインタフェース部に関してはXMLのデータで制約を設けてデータの統一化・標準化をはかりました。物理的なシステムの中は別々でも、外の流通データがXMLとその形式を統一したのです。

筆者が担当したことは、システム全体のデータの論理構造を明確にし、その上でデータ項目の名称／型／長さなどの統一をはかることでした。つまり、統一した論理構造からサブシステム間で流れるXML形式のメッセージを切り出したのです。その標準化作業は設計初期段階で実施し、それを元に各サブシステムは具体的な設計を実施しました。

この事例のように、統一したXMLのメッセージにより動作するサブシステムをもつエンタープライズシステムは、広範囲な標準データのXML DBを保有しているといえます。

メタデータとXML

観測システム構築の翌年にEAのリファレンスモデル作成に参加し、筆者はDRM（データリファレンスモデル）を担当しました。その時に注目されたのは、横断的なデータ交換におけるXMLの有効性でした。

リファレンスとした時の整理方法としてXMLが有効である点は、既述のアメリカにおいてXMLがエンタープライズに与えた影響力の例からでも明らかです。そして、適用規模が大きくなると、そのリファレンスを格納して共有・再利用する仕組みが必要なり、様々なリポジトリを生みます。

リポジトリもXML DBの応用系の1つといえます。XMLを語るとき、リポジトリ技術および活用は基礎知識といってもよいでしょう。

ナレッジと新たな技術の創造へ

XMLはその適用で様々な色に染まります。当初、ドキュメントとデータの融合アプローチはそれらを管理するデータを取り込み、さらにそのマネジメントデータはプロセスの管理をするまでにその役割を広げています。

それはドキュメント構造／データ構造／マネジメント構造など異なるモデル概念の融合のはじまりです。また、XMLはメタデータとデータを一体で扱っていますので、データベース以上にデータベースらしい応用ができる可能性があります。

トピックマップ

その1つの応用技術として実現しているものにトピックマップがあります。筆者はこのトピックマップの概念を使ったシステムを構築中です。コンテンツと利用の間に、マッピングするメタデータ層を置き、そのメタデータ層の中で、知識の連鎖を作ろうといく仕組みです。

▲図6：トピックマップ

トピックマップ情報検索は定められた道筋のほかに、道草をする楽しみを設けています。雑談は道筋なしの会話です。会話の流れの中で会話のネタが生まれ、人の話からその人の趣味の話になり、趣味から想定していない人の話に飛び、今度は住んでいた町の話になり、お国自慢の話の主題が移り...等々、このような話題の複雑な連鎖をメタデータの整理で合理的な仕組みとして実現できます。

トピックマップの概念はXML DBの1つの方向性を示しています。利用目的により従来のデータベースのような使い方ができることに加えて、構造が不確定なものを容易に取り組む使い方です。

簡単な例を説明します。受発注のような定型業務のデータベースは仕事のルールがデータの対象などが確定しているので、RDBなどの固定したスキーマ構造の中で定められたデータについて、決められた制約を確定して格納します。

XMLはあらかじめスキーマを確定しなくても、XMLの規則にあえば扱える仕様となります。扱うデータの構造は利用する側の問題となります。トピックマップは自身の構造や属性を決めています。その構造や属性は一種のメタデータですが、通常のデータベースのメタデータと異なります。

情報処理におけるドキュメント系／ナレッジ系のメタデータの考え方の違いがこの点にあります。XML DBの理解には、XMLで表現するメタデータの特徴に注目する必要があります。

• 1
• 2
• 3
• 4