XMLDB解説

2006年11月6日 更新

今回はXMLデータベース「NeoCore XMS」を使ったシステム構築事例として、ある損害保険会社で構築した保険契約者向けのインターネットサービスサイトについて紹介する。
本システムは、WebベースのCRM（Customer Relationship Management）システムであり、保険契約者の様々な情報をXML DBで管理し、この情報をベースにして保険契約者への様々なサービスを提供している。

このシステムの概要を紹介するとともに、このシステムを構築するにあたってなぜXML DBを利用することにしたのか、また数あるXML DBの中でなぜNeoCore XMSを選択したのかについて言及していく。

損害保険業界では代理店を通した保険商品の販売やサポートを行うことが多かった。いわゆる「間接的」な商流がメインの業態だが、インターネットの普及に伴い、より「直接的」かつスピーディに顧客への商品情報の発信や顧客サービスの提供などを行うようになってきた。さらに、OneToOneマーケティングをより強力にする手段としてもインターネットが利用されてきている。

今回の事例で紹介する損害保険会社においても、保険契約者へのサービス向上とマーケティング強化の一環として、保険契約者に次のような様々なサービスを提供するためのインターネットサイトを構築し、サービスを開始している。

• 契約内容の照会
• 事故の解決状況の参照
• 自動車免許の更新時期の通知

▲表1：保険契約者に対して提供したいサービス

そして図1は今回事例として紹介するシステムの概要図である。

▲図1：保険契約者に対してのサービス提供サイト概要図（画像をクリックすると別ウィンドウに拡大図を表示します）

フロントエンドは2種類ある。1つはインターネット上で公開されている保険契約者向けのポータルサイトであり、もう1つは社内向けにサポートや情報提供の業務を行うものである。ユーザインタフェースはすべてWebブラウザを利用する形態となっており、社外／社内用ともに日立製のJ2EEアプリケーションサーバ「Cosminexus」上に構築している。

また、このシステムのバックエンドには2種類のシステムがつながっている。1つはNeoCore XMSであり、CRMとして利用するアンケートなどの様々な保険契約者の情報を管理している。もう1つはメインフレームとUNIXサーバ上に構築されている基幹業務システムであり、これらのシステムでは保険の試算や契約などの保険会社としてのコアな業務を行っている。
そして、フロントエンドとバックエンドをつなぐプラットフォームとして、ESB（Enterprise Service Bus）製品「PolarLake」を利用している。

例えば、保険契約者がインターネット上に公開されているWebサイトを使って自分の契約内容を閲覧したり、事故発生時の解決状況を照会することができるが、その場合には基幹業務を行ってるメインフレームやUNIXサーバ上のシステムにリアルタイムで問い合わせて最新の情報を参照できるようになっている。

また、保険契約者が登録したアンケートなどの情報はNeoCore XMSに登録され、これを社内から自動車免許の更新時期が近づいていることを通知するサービスやキャンペーン情報やダイレクトメールを配信する保険契約者を抽出するために利用している。
このシステムを構築した当時はそれほど意識していなかったが、すでに存在する業務システムや新しいシステムを「サービス」として利用できるようにしており、本事例はSOAのアプローチとしてのシステム構築事例にもなっている。

NeoCore XMS・PolarLakeというXMLにたけた2つのパッケージと、CosminexusというJ2EEアプリケーションサーバとの組み合せ、さらにメインフレームやUNIX上のCOBOLプログラムなどのレガシーシステムも連携させるということで、当時としては多少挑戦的な試みでもあった。このシステム開発においてはそれぞれのシステムによって様々な課題があったが、最優先課題は表2の2点であった。

• 将来的に発生するシステム変更を、いかにスピーディかつ柔軟に対応できるようにするか
• システムの構築・運用コストをいかに抑えられるか

▲表2：今回のシステム開発においての最優先課題

以降、この2点に触れながらXML DB「NeoCore XMS」を採用するにいたった経緯を説明する。

本システムは当初RDBMS上に構築する計画であり、実際に基本設計まではRDBMSベースで行っていた。しかし、要件定義を終えて基本設計の段階になっても、データ項目はなかなか決まらなかった。

▲図2：RDBMSでのシステム構築 （画像をクリックすると別ウィンドウに拡大図を表示します）DBMS 上のアプリケーション開発では、初期段階で、決められたデータ項目をもとにデータベースのスキーマを確定させる。そのデータ項目が決まらないとなると、本当にRDBMS上に構築することが最善の方法なのかということの再検討を余儀なくされた。その理由は次の2点である。

• アンケートやキャンペーンで集める保険契約者の情報としては、毎回ある程度同じ内容であり、その分はデータ項目として確定している。しかし、より効果的な OneToOneマーケティングを行っていくためには、有効なアンケート項目を追加したり、逆に不要な項目を削除したりする必要がある。そのため、毎回集める情報（データ項目）の見直しを行う必要性がでてきた
• 初期のシステム開発時点において、将来的に発生するだろうデータ項目の変更をすべて考えることは不可能であり、データ項目が不確定となるのは必然となる。RDBMS上でシステムを構築する場合はスキーマを確定することが必須となるが、不確定なデータ項目が必然である状況をいかに吸収できるかという課題があった。

▲表3：RDBMSでシステム構築する場合の懸念点
プロジェクトでは解決方法について議論したが、毎回異なるデータ項目をRDBMS上で管理するためには次のことが必要である。

• アンケート項目をメタ情報として扱えるような仕組みを作りこむ
• 毎回RDBMS上のスキーマを変更する

▲表4：毎回異なるデータ項目をRDBMS上で管理するために必要なこと、1の方法ではシステム構築の難易度が高くなり、その分開発コストが増える可能性が高くなる。また、2の方法ではスキーマ変更のための開発コストと運用コストがかさむ上、スキーマ変更時にサービスを止めなければならなくなる可能性もでてくる。
この他の方法として、アンケートを行う度に専用のテーブルを作成する方法もあるが、アンケートデータから保険契約者の絞込みを行う場合、複数のテーブルから検索することになり、アプリケーションプログラムの複雑化による開発コスト増や性能上の問題で業務に支障を与える可能性もでてくる。

つまり、RDBMS上で構築すると初期開発および将来的なシステム維持・運用どちらにおいてもコストが増加してしまい、柔軟かつスピーディという今回のシステム構築における課題がクリアできないことが予想された。

ここまでの内容から、RDBMS上でデータを管理することが大きな課題やリスクを抱えることを伝えられたと思う。では、いったいどのようにデータを管理すればいいのであろうか。初期段階に戻って検討することになった。
本システムを開発した当時（約3年前）は現在ほどはXMLが企業システムで広く利用されている状況ではなかった。しかし、データを表現する形式として大きな期待を持たれて浸透しつつあった。XMLは、1つのXML文書内にデータとデータを定義づけるためのデータ「メタデータ」を持つデータ形式である。
そのため、どういうデータ項目を持っているのかは、XML文書自身に書かれている内容を解釈すればどんなデータを持つのかが理解できる。複数の文書が存在した場合にそれぞれのXML文書のメタデータが異なっていたとしても、XML文書を扱う上で問題が発生することはない。

例えば、今回のシステムで扱うアンケート情報のように毎回異なる形式のデータであっても、XMLでは問題なくデータを扱うことができる。
このXMLの特徴に着目し、毎回項目が異なるデータを扱う形式としてはXMLが最適であると考えた。

では、どのようにしてXML文書をデータベース化できるのか。プロジェクトにおいてさらにXML文書を管理する方法を検討した。

XML 文書の1つ1つはファイルとして扱うことができるため、ファイルシステム上に直接保存することができる。しかし、ファイルとして保存してしまうとデータの検索をファイルの名前や更新日付だけでしか行えなくなる。ファイルの中身をいちいち参照するとI/Oが発生するために効率が悪い。こういった理由から、 XML文書をファイルとして保存しておく方法は選択できないことは明らかである。

RDBMSでもXML文書を格納することはできる。その方法の1つとして、CLOBのように大きな文字列データを格納できるカラムを使って、XML文書をそのまま格納してしまう方法がある。

しかし、この方法ではCLOBカラムにXML文書全体で格納・取り出しを行うことになり、XML文書内の情報であるデータ項目（エレメント）に対して条件検索ができなくなる。CLOBカラムに格納されたXMLデータ全体をいったんメモリ上に展開して、メモリ上に展開されたXML文書を解釈しながら条件に合致するエレメントを抽出するようなロジックを実装したとしても、性能要件を満たさない。

RDBMSにXML文書を格納するための別の方法として、XML文書をエレメントごとに分割し、それぞれのエレメントをRDBテーブルのカラムにマッピングさせて格納する方法が考えられる。

▲図3：柔軟性と拡張性の消滅

しかし、この方法ではRDBテーブルのスキーマが固定となるため、データ項目に柔軟性を持たせられなくなる。そのため、結局は当初の課題を解決できないことになる。また、データの格納時にはXML文書をエレメント単位に分割してRDBテーブルのカラムにマッピングするための処理が必要になる。
逆に、取り出すときもRDBテーブルのカラムのデータをマージしてXML文書として構成し直す処理が必要になる。さらに、XML文書の階層構造を表現するためには複数テーブルを用いる必要がある。プロジェクトにおいて、これらの処理を実装するためのコストや実行時の処理性能面のレスポンス低下は見逃せないレベルにあると判断された。

上記のように、RDBMSを使っている以上は、当初の課題をクリアできない恐れがあると判断した。

次に、XML文書をそのまま格納できるXML DBの導入を検討することにした。 ▲図4：柔軟性と拡張性の最大活用（画像をクリックすると別ウィンドウに拡大図を表示します）

導入検討時にはXMLの柔軟性をそのままに格納・検索ができるXML DBが存在すると考えていた。しかし、実際に製品を調査していくと様々な問題があることがわかってきた。

当時、すでにいくつかのXML DBはリリース済みであった。今回事例で紹介するNeoCore XMSは三井物産が日本国内で販売を開始した直後であり、日本国内では後発組であったため、導入実績は多いとはいえない状況だった。
しかし、その中でNeoCore XMSが選択された理由は、次の2点である。

• スキーマ定義が不要である
• 格納するデータ量が増えても検索スピードが一定であり、しかも高速である

▲表5：NeoCoreXMSを選択した理由

NeoCoreXMS以外のXML DB製品では、XML文書を格納する前に、どのようなXML文書を格納するのか、あらかじめスキーマを定義しておく必要があった。運用上、スキーマを定義する手間がかかるのはRDBMSでも同じである。

そのため、運用・維持コストはRDBMSを採用した場合と変わらないと考えられた。しかし、スキーマ定義が必要だということは、結局は固定的なデータしか登録できないことを意味するため、柔軟性を必要とされる今回のシステム要件をクリアできないことになる。
スキーマ定義をしなくてもXML文書を格納できる製品も存在してはいたが、格納しているデータ量が増えていくと検索スピードが遅くなってしまうことがわかった。これでは性能要件を満たさないのは明らかであった。

一方、NeoCore XMSは、スキーマ定義が不要であるため、データ項目が変更になったとしても定義のやり直しを行う必要がなく、運用・維持コストの低減が可能になる。また、データ項目の増減など格納するデータのスキーマが変更されたとしても、問題なくすべてのデータを格納していくことができる柔軟性を持っていることがわかった。
さらに毎回のアンケート情報をすべて蓄積していくことになるが、NeoCore XMSでは格納するデータ量が増えたとしても一定の検索スピードが実現できることがわかった。

このようなアドバンテージにより、NeoCore XMSが採用されることになった。

なお、XML文書をそのまま格納できるRDBMSも世の中に存在していたが、まだ世の中に登場してきた直後であり、今回の要件を満たすような製品は見当たらなかった。

システムを構築する際、不慣れなXML DBでの開発であることや柔軟性の高い方式に変更するために3回ほどプログラム変更を要したが、プロジェクト当初に設定したリリース時期を延ばすことはなかった。

▲図5：プロジェクトのスケジュール

今回のプロジェクトにおいて、プロジェクト当初の課題であるコスト低減と柔軟性の高いシステムを構築することができた。初期開発での開発コストはRDBMS の場合と変わらないが、改修・運用に関するコストは当初計画したRDBMSベースのものに比べて30～50%削減することが可能となった。

今回紹介した事例のシステムは、今後は他のシステムとの連携も視野に入っており、NeoCore XMSを核とした本格的なCRMシステムへの拡張も将来的には検討しているという。より効果的なアンケートやキャンペーンを行うため、データ項目を自由に改廃しながらトライ＆エラーを繰り返すことが簡単にできるようにする必要があるためだ。

RDBMSはデータベースの代名詞であり、これからも企業の業務システムに最も多く利用されるデータベースであることは間違いない。

しかし今回の事例のように、表5のことを実現させようとする場合、NeoCore XMSはもっとも最適なソリューションを提供できる製品の1つであると考えられるのではないか。

• システムの変更に柔軟に対応できること
• システム運用開始後の運用・改修コストを低減できること
• データ量が増えても高い検索性能の確保すること

▲表5：NeoCore XMSを選択した理由

▲このページのTOPへ