XMLデータベーストップシェアカンパニー

アプリケーション設計段階：100％厳密にデータ項目を決める必要なし

RDBには、まず厳密なスキーマを決定してからデータを格納するという大前提があります。設計段階において、テーブルやフィールド構成が最終的に確定するまでは、以降の開発に取り掛かることも出来ず、様々な開発プロジェクトにおいて納期遅延やコストオーバー、最悪の場合はデスマーチに突入しかねません。

それにXMLは、データ側に「タグ」と呼ばれるデータの「意味」を表す「見出し」が必ずつけられており、データを見るだけで値の意味を理解することができるため、データの構造変更があってもDBMSは影響を受けずそのまま格納することができます。

同様にXMLデータベース（XML DB）も、データ構造をいつでも自由かつ容易に更新することが可能です。とりあえずデータベースを作成してアプリケーションの開発（あるいは運用）に取り掛かり、必要に応じてダイナミックにデータモデルを変更するといった柔軟な使い方が出来ます。つまり、ビジネスサイドや現場からの要求によって必要とされるデータ項目（スキーマ）を柔軟に再設計・再構成することができるのです。

リリース後のアプリケーション改修コストの削減・納期短縮

XMLデータベースの特長は、システム稼動後の運用・保守・2次開発コストの削減が可能なことです。一旦システムが運用段階に入った後でも、システムを利用する現場部門からの要望や、取引先の製品仕様の追加変更をシステムに反映しなければいけない場面は多いはずです。

例としてあるメーカーで管理している製品情報DBの場合で、現場や取引先からの要望などにより、今管理している内容に対して「面積」や「重量」を追加したい、「環境基準」や「CO2排出量」を管理したい、などの要求が後から出てきたとします。 そのようなシステム運用フェーズでのデータ項目の追加変更のインパクトは、RDBを使った場合非常に大きくなります。

これはアプリケーションの変更だけでなく、データベースのマスタテーブルの追加から始まり、外部キーの追加、インデックスキーの追加が必要になるからです。

これを何回も繰り返す事で、テーブルの数が増加し、それらをつなぎ合わせる事で検索のパフォーマンスが劣化し、アプリケーションのメンテナンス性が悪化し、結果としてコストに跳ね返る、という悪循環にはまってしまう事例が多く見られます。ただ、全てのRDBシステムでこのような事が起こっている訳ではありません。運用後のデータ変更が殆ど必要がないシステム（＝定期データのみを扱う業務システム）であれば、このような問題は起こりません。

このように、XMLデータベース（XML DB）とRDBを使い分け、併用することにより、仕様変更や運用にかかるコストを大幅に削減することが可能となります。データモデルの追加や変更が日常的なeビジネス、あるいは構造の未確定な情報をとりあえず電子化する場合など、スピードと柔軟性の求められるシーンにおいてXMLデータベースは、大きな威力を発揮するのです。