 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| XMLDBという選択肢
|
ここまでの内容から、RDBMS上でデータを管理することが大きな課題やリスクを抱えることを伝えられたと思う。では、いったいどのようにデータを管理すればいいのであろうか。初期段階に戻って検討することになった。
本システムを開発した当時（約3年前）は現在ほどはXMLが企業システムで広く利用されている状況ではなかった。しかし、データを表現する形式として大きな期待を持たれて浸透しつつあった。XMLは、1つのXML文書内にデータとデータを定義づけるためのデータ「メタデータ」を持つデータ形式である。
そのため、どういうデータ項目を持っているのかは、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を使っている以上は、当初の課題をクリアできない恐れがあると判断した。
|
前のページ 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の日本国内への普及をメインテーマとしている。
|
|
|
|
|
|
