XMLデータベーストップシェアカンパニー

XMLデータベース　エンジニア特別対談【エンジニアが本音で語る! XMLデータベース、その真の実力とは】（1）

HOME > コンテンツ > XML/XML DB関連コンテンツ > XMLデータベース　エンジニア特別対談【エンジニアが本音で語る! XMLデータベース、その真の実力とは】（1）

XMLデータベース（XML DB）　エンジニア特別対談【エンジニアが本音で語る! XMLデータベース、その真の実力とは】タイトル

エンジニアの視点で語られることが少なかった、XMLデータベース（XML DB）。
今回は、XMLデータベースシステムインテグレーションの第一人者であるキヤノンＩＴソリューションズ株式会社の木村氏に、XMLデータベースを使ったシステム提案・構築・実装の経験を踏まえ、その使いどころと構築のツボ、今後について伺った。　　（聞き手：株式会社サイバーテック　白井）

キヤノンＩＴソリューションズ株式会社製造事業本部　開発センター木村　亮　氏	株式会社サイバーテック取締役　アプリケーション開発部長白井　千晶

（1）プロローグ

白井：木村さんにXMLデータベースのお話を頂く前に、XMLデータベース製品について、その分類方法や呼称が統一されていないので、ここから整理したいと思います。

私達サイバーテックでは、XMLデータベースを、「XMLのハンドリングに特化したデータベース製品」と定義しています。
リレーショナルデータベース（RDB）にもXML型が扱えるように機能拡張した製品があり、「ハイブリッド型XML DB」と分類される事もありますが、テーブル型アーキテクチャがベースであるため、「リレーショナルデータベース（RDB）」と分類する事にしています。

XML DBとRDB。XMLをそのまま格納できるXML DBとXMLをRDBの拡張機能として扱うRDB

図1：XMLを格納する際のXML DBとRDBの違い
※画像をクリックすると拡大されます。

（2）SI案件における、XML DBとRDBの選択

白井：木村さんは、キヤノンＩＴソリューションズ株式会社で長年、XMLデータベースの開発に携わっておられますが、XMLデータベース（以下、XML DB）との出会いはいつ頃だったのですか？

木村：NeoCoreXMS(以下、NeoCore)が、日本市場で発売された当時、XML DBの技術調査という目的も兼ねて、当社向けのベンダ説明会に参加しました。

白井：案件の中でXML DBを使った業務システムの開発に携わったのはいつ頃ですか？

木村：2004年に、NeoCoreを使った製品情報管理システムの開発が最初です。

白井：その当時、RDBでXMLが扱える製品はありましたか？

木村：はい、RDBでもXMLデータを扱う事ができる製品はありました。

白井：XML DBを扱える、と言ってもXML系のツールを使い、XMLタグをRDBテーブルのカラムにマッピングする使い方や、XML-EDIに代表されるようなXMLデータを単に変換して業務システムに流すような使い方が中心でしたね。

木村：はい。お客様への提案時に、XMLを扱えるデータベースをいくつか比較・検証しました。

白井：そのお客様は、最終的にXML DBのNeoCoreを選択されたわけですが、XML DBを選定された決め手となった理由はは何だったのですか？

木村：最も大きな理由が、「専門のシステム管理者・データベース管理者が不要な、社内で管理運用できるシステムにして欲しい」という要件があった事です。
導入後にデータ項目の追加変更が発生する事が最初から想定されていて、顧客からは「データの構造変更が頻繁に発生するので、そのために都度データベースの再設定やアプリケーション改修によるコストや時間をかける事は許されない」、と強く言われていました。
当社もRDBを使ったSIを行っていますから、社内からは、その当時「データマッピングをして、インデックスを張ればRDBでも実現できるのではないか」という声があがったのは事実です。
ただ、業務要件として、データ（製品情報）の構造変更が頻繁に発生する、という事は明確でしたから、従来のRDBアプローチでは、要件は満たせないと考えていました。

白井：パフォーマンス面での検証についてはいかがでしたか？

木村：やりました。RDBも含めて一生懸命やりました（笑）。

まずは各テーブルに対してXMLタグをマッピングして格納する方法。
これは、現実的な方法ではありませんでした。
なぜなら、データ構造が変わったら結局テーブルを設計し直す必要があります。
つまり、XMLを使う意味がなくなってしまいます。
2つ目は、CLOBフィールドにXMLをそのまま入れる方法があります。
これはXMLの形式にとらわれず格納する事ができますが、検証の結果、業務で耐えうる十分な検索パフォーマンスがでませんでした。
3つ目は、CLOBに格納されているXMLの中で、検索対象となる特定タグについて通常のテキストフィールドに入れて、そこにインデックスを張る方法があります。
この方法ですと、高速にターゲットとなるXMLタイプを特定する事が可能にはなりました。
ただ、検索項目が増えた場合に必ずテーブルの改修が発生してしまうので、今までと異なる形式のXMLが飛んできた時点で、結局エンジニアによるチューニング作業が発生しまいます。

図2：RDBのCLOBにXMLをマッピングする
※画像をクリックすると拡大されます。

木村：XMLを活用する場合であっても、システム内には、RDBデータとXMLデータが混在するのが一般的でしょう。そうしたとき、直感的には、XMLを扱えるRDBで構築することが最適解であるように見えます。確かに、XMLデータが付加的な情報として扱われている場合は、XMLを扱えるRDBが有効な場合があります。
しかし、もう少し具体的に、即ち、安全性や、システムリソース、それに伴うパフォーマンスを考えたとき、扱う情報毎にサーバを分けて構築するケースも考えられるのではないでしょうか。その場合、XMLを格納するサーバには、XMLのハンドリングに適したXML DBを使い、表形式データを格納するサーバには、RDBを配置する、即ち、システムとしてのハイブリッドが現実的であることも多いと思います。
例えば、変化が激しい「製品スペック情報」は、現場の方が運用できる柔軟なアプリケーションを介してXML DBに格納され、情報システムの運用者がいなくても業務が回るシステムにします。一方、「製品スペック情報」と連動してWebカタログに表示するための「顧客データ」や「受注データ」は、RDBに格納する。私が担当したお客様もこのように、RDBとXML DBをシステムとしてハイブリッドにして使われています。顧客からの要件を具体的に検討すると、データベースだけの議論ではなく、システムとしてXML DBとRDBをどのように配置すれば良いか、という議論になるのです。

白井：なるほど、データベースだけではなく、システムとしてのハイブリッドですね。弊社のXML DBの事例でもシステム構成上、RDBとXML DBに格納するデータを分離したパターンは多数あります。