mb_language("uni"); mb_internal_encoding("utf-8"); mb_http_input("auto"); mb_http_output("utf-8"); ?>
XMLデータベース(以下、「XML DB」)の特長を一言でいうと、「刻々と変化する環境に合わせて、システムで管理するデータを柔軟に変更する事が出来るデータベース」です。社会情勢、マーケット、ビジネスモデル、そして顧客や顧客のし好や好みなどは、刻々と変化しています。特に企業活動の「現場で扱う情報」は生もので、日々形を変えていきます。ある時はこの情報が欲しい、ある人はこのデータが知りたいなど、その時その人その状況で 必要な情報は異なり、定形的に決めておくことは不可能に近いと言えます。
一方で、情報処理システムは、日々変化する情報の中の、ある時点でのスナップショットを下地にモデル化をします。さらに、その情報をデータベース化しようとした場合、不変のあるいは変化の少ない部分に絞ってテーブル(箱)を用意し、その中に情報を格納していく形をとります。この時、レアな部分や不確定な部分、変化の多い部分の情報は無視せざるを得ません。
このように、常に変化し続けるものをシステム化することは非常に困難なので、現場部門がシステム部門に掛け合って現場の要望に合わせたシステム化を実現しようとすると、現在のシステムの償却が完了する3年~5年と月日を待たないという気の遠いお話になってしまいます。特に、企画、営業、コミュニケーション、ドキュメントといった知的生産活動を支援するようなデータを扱うシステムでは、使いながらマーケットやビジネスのニーズに合わせて、形の見直しや拡張をしていくことが必須と言え、これは固定化こそシステムの前提である、という従来の常識と相反するものなのです。
この点で、現在多く存在している情報システムの課題であり、矛盾が存在すると、私は考えます。こういった従来の情報システムの既成概念や常識に風穴を空ける可能性を秘めた、「XML」という技術と「XML DB」という製品について、少しでもご理解を頂ければ幸いです。
では、全てのシステムはXMLやXML DBを適用した方が良いのでしょうか?
受注データのように数百万件の数値データをソートする、銀行の勘定系システムのように1秒間に大量のトランザクション(更新)処理が発生するようなシステムのデータの管理は、従来のシステムで多く使われているRDBの方が得意です。このような管理するデータ項目が変化しないような用途や、変化する情報を扱う事よりもシステムとしての堅牢性を重視するような用途では、RDBをXML DBに置き換えても逆効果です。
XML DBを適用できるか否かを判断するポイントは、「使いながらデータの見直しや拡張が必要なアプリケーションかどうか」です。もし、上記のようなニーズがあれば、XML DB単独で、もしくはRDBとXML DBを組み合わせて最適なシステムを構築する事が出来るとお考えください。
では、もっと具体的にXML DBの適用分野を整理して解説します。
一つ目は「メタデータの管理」。ここでは「図面データ」を想定してご説明します。通常目的の図面データを探す場合にはファイル名や図面番号を使って検索します。しかし、営業現場や代理店は、もっと自分たちに合ったキーワードや分類方法で効率良く目的の図面を入手したいはずです。
例えば、「カーナビ及びカーオーディオという完成品カテゴリで使われている組み込みソフトウエアの設計図面で、2000年~2005年に生産された型番に該当する図面の一覧を入手したい」「2008年にある顧客に納品した特注品に使われている部品一覧と関連する図面の全てを入手したい」。こんな現場のニーズをシステムで実現できるのがXML DBです。
二つ目は「ユニークデータの管理」。種類は同じでも、管理する項目がバラバラなどといったものです。カーナビという製品は、年々製品のライフサイクルが短くなり、また次々に新しい機能が追加されていきます。ある製品ではHDDの容量、種類、ナビゲーション・モードといったものだけ管理していればよかったものが、新製品で追加された「音楽再生機能」や「USB接続機能」など製品固有の項目が増えていきます。これらを予想して予め入れ物を用意するのは困難ですが、XML DBではその柔軟さゆえ簡単に項目を追加することが可能となります。
さらにXML DBは、「ツリー構造データの管理」、「XMLありきのデータ管理」、「構造化文書のデータ管理」、「ワンソースマルチユース」といった適用分野があります。XML DBは、このように適用用途こそ選びますが、業種は選びません。現実に様々な業種のお客様で利用されています。
データモデルの観点で分類すると、格納するデータの構造について、RDBが「定型的な表データ」のみを管理する事が出来るのに対して、XML DBは、定型部分と非定形が混在した「半定型なツリーデータ(XML)のみ」を格納する事が出来る、と理解してください。
今までは、適用分野と用途という観点から、XML DBの特長をご説明しましたが、アプリケーションの設計という観点からみた場合の違いについてご説明します。
RDBは元となるデータを把握したうえで、その格納先を予め定義して用意しておく必要があります。データ型やデータ項目に変更があった場合はDB側も予め格納先を定義し直して準備しておく必要があります。
対してXMLは、データに「タグ」と呼ばれるデータの「意味」を表す「見出し」が必ずつけられており、データを見るだけで値の意味を理解することができるため、データの構造変更があってもDBMSは影響を受けずそのまま格納することができます。
システム開発の初期段階・設計段階における仕様変更(データ項目が決まらない)に対して、RDBの場合、100%厳密にデータ項目を決めなければいけませんが、XML DBでは、ビジネスサイドや現場からの要求によって必要とされるデータ項目(スキーマ)を柔軟に再設計・再構成することができます。「XMLデータベースはスキーマレス」「XMLデータベ-スはやわらかい」といわれる理由はここにあるのです。システムが運用段階に入った後でも、システムを利用する現場部門からの要望や、取引先の製品仕様の追加変更をシステムに反映しなければいけない場面は多いはずです。
例としてあるメーカーで管理している製品情報DBの場合で、現場や取引先からの要望などにより、今管理している内容に対して「面積」や「重量」を追加したい、「環境基準」や「CO2排出量」を管理したい、などの要求が後から出てきたとします。そのようなシステム運用フェーズでのデータ項目の追加変更のインパクトは、RDBを使った場合に非常に大きくなります。アプリケーションの変更だけでなく、データベースのマスタテーブルの追加から始まり、外部キーの追加、 インデックスキーの追加が必要になります。
一方で、XML DBを利用したアプリケーションでは、データを検索するためのアプリケーションに対するプログラムの設計変更を加える必要はありますが、あらかじめ「使いながらデータの見直しや拡張が必要なアプリケーションなので、変化する製品スペック情報についてはXML DBで管理しよう」というポリシーでアプリケーションを設計していれば、システム運用フェーズでのデータ項目の追加変更のインパクト(=コスト・工数) は、非常に小さく済むはずです。
一言で「帳票」と言ってもその用途は年々広がりを見せています。従来の「納品伝票」「請求書」などの他に、「作業指示書」「検査仕様書」「提案資料」「カタログやチラシ」などシステムから出力される様々なものを帳票と位置付ける事があります。「現場の業務に合わせて様々なフォーマットの帳票を作成したい」「大量に蓄積された電子帳票を素早く探したい」「複数のデータベースで管理されたデータを集めて様々な形の帳票に出力したい」こんなニーズがあれば、XML技術を適用したシステム提案が可能とお考えください。
最後に、XMLは標準化から10年が経過し、マークアップ言語として、プログラミングの現場や異機種間のデータ交換フォーマットとして広く認知されてきました。しかしXMLは、既に次の時代に突入しています。それは「XML活用の時代」です。情報やデータの流通量が爆発的に増加する中で、本当に「RDBだけ」がデータ管理の答えなのでしょうか?本コンテンツを読んで頂き、XMLとこれからの情報システムのあるべき姿について、顧客の課題に直面しているエンジニアの皆様に少しでも「気づき」をご提供できたら、幸いです。
▲このページのTOPへ