 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| システム構築における問題点
|
NeoCore XMS・PolarLakeというXMLにたけた2つのパッケージと、CosminexusというJ2EEアプリケーションサーバとの組み合せ、さらにメインフレームやUNIX上のCOBOLプログラムなどのレガシーシステムも連携させるということで、当時としては多少挑戦的な試みでもあった。
このシステム開発においてはそれぞれのシステムによって様々な課題があったが、最優先課題は表2の2点であった。
- 将来的に発生するシステム変更を、いかにスピーディかつ柔軟に対応できるようにするか
- システムの構築・運用コストをいかに抑えられるか
表2：今回のシステム開発においての最優先課題
以降、この2点に触れながらXMLDB「NeoCore XMS」を採用するにいたった経緯を説明する。
|
| 当初はRDBMSで計画
|
本システムは当初RDBMS上に構築する計画であり、実際に基本設計まではRDBMSベースで行っていた。しかし、要件定義を終えて基本設計の段階になっても、データ項目はなかなか決まらなかった。
図2：RDBMSでのシステム構築 （画像をクリックすると別ウィンドウに拡大図を表示します）
RDBMS上のアプリケーション開発では、初期段階で、決められたデータ項目をもとにデータベースのスキーマを確定させる。そのデータ項目が決まらないとなると、本当にRDBMS上に構築することが最善の方法なのかということの再検討を余儀なくされた。その理由は次の2点である。
- アンケートやキャンペーンで集める保険契約者の情報としては、毎回ある程度同じ内容であり、その分はデータ項目として確定している。しかし、より効果的なOneToOneマーケティングを行っていくためには、有効なアンケート項目を追加したり、逆に不要な項目を削除したりする必要がある。そのため、毎回集める情報（データ項目）の見直しを行う必要性がでてきた
- 初期のシステム開発時点において、将来的に発生するだろうデータ項目の変更をすべて考えることは不可能であり、データ項目が不確定となるのは必然となる。RDBMS上でシステムを構築する場合はスキーマを確定することが必須となるが、不確定なデータ項目が必然である状況をいかに吸収できるかという課題があった。
表3：RDBMSでシステム構築する場合の懸念点
プロジェクトでは解決方法について議論したが、毎回異なるデータ項目をRDBMS上で管理するためには次のことが必要である。
- アンケート項目をメタ情報として扱えるような仕組みを作りこむ
- 毎回RDBMS上のスキーマを変更する
表4：毎回異なるデータ項目をRDBMS上で管理するために必要なこと
1の方法ではシステム構築の難易度が高くなり、その分開発コストが増える可能性が高くなる。また、2の方法ではスキーマ変更のための開発コストと運用コストがかさむ上、スキーマ変更時にサービスを止めなければならなくなる可能性もでてくる。
この他の方法として、アンケートを行う度に専用のテーブルを作成する方法もあるが、アンケートデータから保険契約者の絞込みを行う場合、複数のテーブルから検索することになり、アプリケーションプログラムの複雑化による開発コスト増や性能上の問題で業務に支障を与える可能性もでてくる。
つまり、RDBMS上で構築すると初期開発および将来的なシステム維持・運用どちらにおいてもコストが増加してしまい、柔軟かつスピーディという今回のシステム構築における課題がクリアできないことが予想された。
|
前のページ 1 2 3 4 次のページ
|
株式会社日立システムアンドサービス
コンサルティングからシステムの企画・設計、開発、保守・運用にいたるトータルソリューションをワンストップでお客様に提供
NeoCore XML Management System
http://www.hitachi-system.co.jp/neocore/
|
|
|
|
著者プロフィール
株式会社日立システムアンドサービス
PolarLakeソリューション推進センタ 主任技師
山本 貴禎
この数年、Java EEや.NETのWebアプリケーション開発、技術コンサルテーションに従事している。現在では、NeoCore XMSなどのXML関連製品のサポートにも携わっており、特にSOA／ESB対応製品PolarLakeの日本国内への普及をメインテーマとしている。
|
|
|
|
|
|
