ネットワークが普及した今日、 企業やコミュニティ内であちこちに分散して蓄積されてきた情報を共通利用しようというニーズは結構多い。 ニーズは高いが、一朝一夕にはいかないこの分野、 その難しさと解決方法にはどんなものがあるのだろうか？

異種データ統合のニーズ

データベーステーブル、CSV、HTMLファイルなど様々な形で、 様々な場所に蓄積されてきたデータを共通利用しようというニーズがある。 企業内で共有したいノウハウ、年次により調査項目が異なる統計データ、 合併した企業のそれぞれのデータ、 世界中の研究機関が蓄えた遺伝子情報 などがこれにあたる。 つまり、管理組織の違いによる異種データ、時系列的に異質なデータの統合ニーズである。

データ統合の難しさ

異種データ統合の難しさはどこにあるのだろう？ 一口に異種といっても、カラム名が違う、型が違う、同じ名前でも意味が違う、 表現方法が違う、コード体系が違う、データ構造が違う、 データモデル(リレーショナル、オブジェクト、ネットワークモデルなど)が違う、 DBMS が違う（SQLに方言がある）、など様々な違いがある。 データが分散していれば、分散結合処理の最適化といった問題もある。 利用者側のビュー（これは標準規格であることが多い）が策定されていなければ、 まず、これを策定しなければならない。

データ統合の方法

異種データを共通利用する仕組みには、以下のような方法がある。

(1)データをオブジェクトでラッピングして利用する方法
(2)ゲートウェイ・ミドルウェアを使う方法
(3)XMLとXML変換ツールを使う方法

プログラムとデータを一まとめにした単位をオブジェクトという。 (1)は、データの出入り口にオブジェクトを設け、 オブジェクト間で共通のインターフェースで相互にサービスやデータをやりとりをする方法である。 オブジェクトがデータをラッピングして異種性を吸収する。 オブジェクトに自律性を持たせたエージェントとしてデータを集めさせる方法などもある。 数年前からのCORBAオブジェクトによりデータ統合を図ろうという流れはこの方式による。 柔軟だが、各所にORBクライアントを用意し、 サーバをIIOPというプロトコルを通すよう設定する必要がある。

(2)は、各データベースに個別に問合せ、利用したいビューで表示する方式だ。 この際、Oracle, Sybase, SQLServer あるいは CSV ファイルといった様々なデータソースに透過にアクセスし、 ビューまたはテーブルを作るゲートウェイ・ミドルウェアを利用する。 ターゲットとなるデータ構造までの変換をGUIでできるものもある。 DBMS 自体に複数 DBMS を扱える機能を付加したものもある。 この複数 DBMS を統合する技術は、 Federated Database という分野で研究されてきた。 (2)は、対象がR DBMS の場合(1)より高機能で有効な手段だが、それなりに導入コストもかかる。

(3)は、今色々なところで話題となっている XMLを使う方法である。 XML は、HTML と SGML から派生した記述言語で、ユーザが自由にタグを定義することができる。 オブジェクトモデルに近い入れ子構造のデータと、 その表現方法を別々に記述できるので拡張性が高く、データ変換も行いやすい。 XSLT というトランスレータを使えば、ある XML から別の XML への文書変換も可能であり、 流通用中間表現としての用途も多い。 電子書籍や、 地理情報、デジタル放送のコンテンツ記述に応用されている。 導入コストは、比較的安価だが、 XML はネストを深くすると検索に時間がかかるという問題もあり、注意が必要である。

標準化と柔軟性が重要

共通利用となると、最終的には、利用者の共通意識に基づく標準化が重要になってくる。 OASIS を始め各所で様々な業界の標準データ構造を策定している。 標準が決まれば、先の方法でこれと独自データとのマッピングを図ればよい。

しかし、データ構造というのは、絶えず変化するものである。 標準化と同時に、柔軟にデータ構造を拡張できる仕組みも確保する必要がある。 これには、リレーショナルモデルよりオブジェクトモデルの方が適している。 オブジェクトモデルに近く、テキストデータであり特別なサーバ側設定がいらず、 Eメールでもブラウザでも扱えるXMLが取り沙汰される理由はこのあたりにある。