RDBとXML DBで管理できるデータを比較しよう

ビジネスの変化や進化のスピードに対応できるのは、XML DB

今なぜ、XML DBが求められるのか？それは、XML DBが日々変化するビジネス環境やめまぐるしく進化するIT技術に対して柔軟に対応できる唯一の解だからです。

今求められる情報システムのあるべき姿　～ ビジネスの変化や進化のスピードへの対応 ～

XMLデータベース（以下、「XML DB」）の特長を一言でいうと、「刻々と変化する環境に合わせて、システムで管理するデータを柔軟に変更する事が出来るデータベース」です。社会情勢、マーケット、ビジネスモデル、そして顧客や顧客のし好や好みなどは、刻々と変化しています。特に企業活動の「現場で扱う情報」は生もので、日々形を変えていきます。ある時はこの情報が欲しい、ある人はこのデータが知りたいなど、その時その人その状況で 必要な情報は異なり、定形的に決めておくことは不可能に近いと言えます。

一方で、情報処理システムは、日々変化する情報の中の、ある時点でのスナップショットを下地にモデル化をします。さらに、その情報をデータベース化しようとした場合、不変のあるいは変化の少ない部分に絞ってテーブル（箱）を用意し、その中に情報を格納していく形をとります。この時、レアな部分や不確定な部分、変化の多い部分の情報は無視せざるを得ません。

このように、常に変化し続けるものをシステム化することは非常に困難です。現場部門がシステム部門に掛け合い、現場の要望をシステムに反映してもらうためには、現行システムの償却が完了する3年～5年といった月日を待たなければいけません。特に、企画、営業、コミュニケーション、ドキュメントといった知的生産活動を支援するようなデータを扱うシステムでは、使いながらマーケットやビジネスのニーズに合わせて、形の見直しや拡張をしていくことが必須と言え、これは固定化こそシステムの前提である、という従来の常識と相反するものなのです。この点で、現在多く存在している情報システムは多くの課題を抱えています。

データベースで管理されない大量の「半定型データ」

ビジネスの現場で利用されるデータの種類は、大きく分けて3種類あります。

ひとつめは「定型データ」と呼ばれるもので、「店舗毎の売上データ」「従業員の1か月の勤怠実績」「ある製品の出荷本数と出荷先一覧」といったようなデータを指します。企業の情報システムの中で、定型データは「基幹系システム」で扱われており、大量のトランザクション処理や集計処理に適した、ホストコンピュータやリレーショナルデータベースにより管理されています。

次に「非定型データ」と呼ばれるデータがあります。「非定型データ」は、「メールの本文データ」「文書作成ソフトで書かれた文書データ」「デスクトップに書き留めたメモデータ」に代表されるデータで、データ自体に構造を持つことなく、作成者毎に自由なフォーマットで作成されるという特長があります。これら「非定型データ」は、個人PCの中に公開されないまま保管されたり、紙の形で電子化されない状態でキャビネットに保管されている事が多く、電子化した非定型データは、検索エンジンを使ってキーワードで探し出す方法が一般的になっています。

3つ目のデータは、「半定型データ」と呼ばれるデータで、「顧客情報に紐付いた要望クレーム情報」「ある製品に関連する技術文書情報」「blogやtwitterに書き込まれたコンテンツとそのコメント」など、定型化されたデータの中に非定型データが混在したり、定型化されたデータが様々なバリエーションを持つ様なデータを指します。「非定型データ」や「半定型データ」は、文書管理システム、コンテンツ管理システム、CRMシステムやカタログ制作システムなどの「情報系システム」で管理されていますが、その一方でこれら情報系システムを活用する現場や経営層からは、「データベース化が困難である」「データベース化したが現場で使われていない」「データベース化を断念した」と言った声が多く聞かれるのも事実です。

▼企業内ビジネスデータの分類

非定型データや半定型データはRDBだけでデータベース化できるのか？

RDBには、まず厳密なスキーマを決定してからデータを格納するという大前提があります。テーブルやフィールドをどのように構成するかという設計を確定するまでは、それ以降の開発に取り掛かることも出来ないのです。これは、多品種を扱うメーカーのカタログ製作現場や、組織ナレッジや顧客クレームをデータベース化して共有化したい企業など多くの現場で課題となっています。めまぐるしく変化するビジネス環境において、もはやRDBだけで柔軟性の高いデータや情報を管理することは、現実的とは言えません。

XMLデータベースは、データ構造をいつでも自由かつ容易に更新するこ とが可能です。とりあえずデータベースを作成してアプリケーションの開発（あるいは運用）に取り掛かり、必要に応じてダイナミックにデータモデルを変更するといった柔軟な使い方が出来ます。また、運用しようとするデータのうち、スキーマがしっかりと決まっている部分はRDBに入るが、今後どうなるかわからない部分・あるいは当初想定していなかった部分はどうしてもRDBからこぼれ落ちる場合が多々あるかと思います。そういった場合、「XML DBはスキーマを気にしなくても良い」という特徴を最大限生かし、XML DBにてこぼれ出た部分をキャッチアップすることができます。そのようにして、XML DBとRDBの用途を使い分け、併用して用いることにより、余計な仕様変更コストや運用コストなどを削減することができます。

近年のRDBはXML対応を謳っていますが、基本的な設計思想はXMLが適しているツリー型データ構造ではなく、テーブル型のアーキテクチャを持っています。したがって、「複雑なXMLデータを格納する」「一度格納したデータを更新する」「項目を追加する」といった処理が、どうしてもXML専用のデータベースに比べ、パフォーマンス面で劣ります。

このようにデータモデルの追加や変更が日常的なeビジネス、あるいは構造の未確定な情報をとりあえず電子化する場合など、スピードと柔軟性の求められるシーンにおいてXMLデータベースは、大きな威力を発揮するのです。