(57)【特許請求の範囲】
【請求項１】
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段と、
前記情報源側から前記情報源側の前記物理モデルでの処理対象データを抽出する抽出手段と、
前記抽出手段によって抽出された前記物理モデルでの処理対象データを、前記マッピング定義を参照することにより対象反映データを生成し、対応する前記マッピング定義の項目を解決済みとするとともに、前記対象反映データを前記論理モデルでの情報に統合する第１の統合手段と、
前記第１の統合手段によって統合された結果、前記マッピング定義において未解決の項目がある場合、前記第１の統合手段によって統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの処理対象データを検索する検索式を生成する生成手段と、
前記生成手段によって生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集手段と、
前記収集手段によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合手段と、
前記第１および第２の統合手段によって統合された統合結果を前記利用側に出力する出力手段と、
を備えることを特徴とする情報統合装置。
【請求項２】
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段と、
前記情報源側から前記情報源側の前記物理モデルでの処理対象データを抽出し、抽出された前記物理モデルでの処理対象データを、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合処理を実行する第１の統合手段と、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理を実行する第２の統合手段と、
統合指示を検出する検出手段と、
前記検出手段によって検出された統合指示が、前記情報源側からの抽出により前記利用側に統合結果を出力する第１の統合指示である場合、前記第１の統合処理を実行し、前記利用側からの問い合わせにより当該問い合わせの結果を前記利用側に返す第２の統合指示である場合、前記第２の統合処理を実行するように制御する制御手段と、
前記制御手段によって実行された第１または第２の統合処理による統合結果を前記利用側に出力する出力手段と、
を備えることを特徴とする情報統合装置。
【請求項３】
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータが、
前記情報源側から前記情報源側の前記物理モデルでの処理対象データを抽出する抽出工程と、
前記抽出工程によって抽出された前記物理モデルでの処理対象データを、前記マッピング定義を参照することにより対象反映データを生成し、対応する前記マッピング定義の項目を解決済みとするとともに、前記対象反映データを前記論理モデルでの情報に統合する第１の統合工程と、
前記第１の統合工程によって統合された結果、前記マッピング定義において未解決の項目がある場合、前記第１の統合工程によって統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの処理対象データを検索する検索式を生成する生成工程と、
前記生成工程によって生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集工程と、
前記収集工程によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合工程と、
前記第１および第２の統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行することを特徴とする情報統合方法。
【請求項４】
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータに、
前記情報源側から前記情報源側の前記物理モデルでの処理対象データを抽出する抽出工程と、
前記抽出工程によって抽出された前記物理モデルでの処理対象データを、前記マッピング定義を参照することにより対象反映データを生成し、対応する前記マッピング定義の項目を解決済みとするとともに、前記対象反映データを前記論理モデルでの情報に統合する第１の統合工程と、
前記第１の統合工程によって統合された結果、前記マッピング定義において未解決の項目がある場合、前記第１の統合工程によって統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの処理対象データを検索する検索式を生成する生成工程と、
前記生成工程によって生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集工程と、
前記収集工程によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合工程と、
前記第１および第２の統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行させることを特徴とする情報統合プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報を統合する情報統合装置、情報統合方法および情報統合プログラムに関する。
【背景技術】
【０００２】
抽出したデータをまとめて統合する処理は、物理統合（ＥＴＬ：Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄｉｎｇ）と呼ばれる。物理統合では、抽出機能（Ｅｘｔｒａｃｔ）により情報源から抽出したデータについて、物理的な統合（Ｔｒａｎｓｆｏｒｍ）をおこなう。そして、統合結果を登録機能（Ｌｏａｄｉｎｇ）によって利用側に登録する。物理統合は、バッチ処理としてまとまった処理を行うのに適している。物理統合では、情報の鮮度は抽出した時点の情報となり、情報源と統合結果の重複管理が発生しやすい。
【０００３】
また、統合機能の部品化を行い、予め統合ロジックをＴＤＬ（Ｔｒａｎｓｆｏｒｍａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）と呼ばれる統合処理ロジック記述言語により記述してリポジトリに登録しておく。そして、実行時にＴＤＬに沿って統合部品を順次処理することにより、物理統合を実現する方法もある（たとえば、下記特許文献１，２を参照。）。
【０００４】
また、異なるシステムにおいて管理されている複数の情報源に存在するデータを利用側の要求によりリアルタイムに収集して統合する処理は、仮想統合（ＥＩＩ：Ｅｎｔｅｒｐｒｉｓｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ）と呼ばれる。仮想統合では、利用側からの検索要求に応じて、必要な情報を情報源から検索して収集を行い、収集したデータを統合して利用側に返すことにより、仮想的な情報統合を実現する。仮想統合は、利用側が必要とする時点のリアルタイムな情報を情報源から取得するため、鮮度が良い情報を利用できる。また、利用後は情報を廃棄することにより情報の重複管理が不要である。
【０００５】
たとえば、統合対象となる情報源のデータ構造を示すデータモデルを物理モデル、利用側が必要なデータ構造を示すデータモデルを論理モデルとし、物理モデルと論理モデル間の関連をマッピング定義としてメタ定義を行うだけで効率の良い仮想統合を実現することができる（たとえば、下記特許文献３を参照。）。このような仮想統合では、処理ロジックが不要なので、情報源や利用側の変化に対して、該当するメタ定義だけを変更することで、変化に対応できる柔軟性を持ち、利用側のデータモデルが多様な場合でも、対応する論理モデルを追記するだけで対応できる。
【０００６】
また、ストリームデータとして流れているデータを取得して統合を行う処理は、ストリーム統合と呼ばれる。ストリーム統合は、ネットワークなどのデータストリームを流れているデータ（ストリームデータ）を必要に応じて取得し、情報統合を行い、その結果をデータストリームに送出する。ストリーム統合には時間軸があり、情報源から能動的に送出されるデータなので、物理統合や仮想統合など、通常の情報統合とは全く異なる方法で統合処理されている。
【０００７】
ストリーム統合には、情報源からストリームラッパで取得されたストリームデータについて、一旦キャッシュに蓄積し、順次統合して利用側からの問合わせに応じて送出する方式がある（たとえば、下記非特許文献１を参照。）。このように、従来のストリームデータ統合では、情報源のデータおよびその構造を意識して、その統合手順を記述することによって、利用目的とする統合結果情報を得ていた。
【０００８】
また、物理統合、仮想統合およびストリーム統合といった３つの情報統合は、それぞれ機能が異なるため、異なる処理系により情報統合が実行されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許第６，０１４，６７０号明細書
【特許文献２】米国特許第６，３３９，７７５号明細書
【特許文献３】国際公開第２００８／０２８１８４９号パンフレット
【００１０】
【非特許文献１】Ｈｉｒｏｙｕｋｉ  Ｋｉｔａｇａｗａ  ａｎｄ  Ｙｏｕｓｕｋｅ  Ｗａｔａｎａｂｅ，  “Ｓｔｒｅａｍ  Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ  Ｂａｓｅｄ  ｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ  ｏｆ  ａ  Ｓｔｒｅａｍ  Ｐｒｏｃｅｓｓｉｎｇ  Ｅｎｇｉｎｅ  ａｎｄ  Ｄａｔａｂａｓｅｓ”，Ｐｒｏｃ．  ＩＦＩＰ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｎｅｔｗｏｒｋ  ａｎｄ  Ｐａｒａｌｌｅｌ  Ｃｏｍｐｕｔｉｎｇ  Ｗｏｒｋｓｈｏｐｓ，  ｐｐ．１８−２２，Ｄａｌｉａｎ，  Ｃｈｉｎａ，  Ｓｅｐｔ．２００７．
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、上述した物理統合では、完全な統合ロジックを運用者（または開発者）が記述して登録する必要があった。したがって、運用者（または開発者）の作業負担が大きいという問題があった。また、情報源や利用側の変化に対しては、関連する処理ロジックをすべて書き換える必要があった。したがって、柔軟性が低いという問題があった。さらに、利用側の求めるデータモデル毎に、ＴＤＬで完全なロジックを記述する必要があった。したがって、利用側が多様な（多くの種類の）データモデルを必要とする場合には、処理ロジックの作成負担が増大するという問題があった。
【００１２】
また、上述したストリーム統合では、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）をストリーミング処理向けに拡張した「要求記述言語  ＨａｍＱＬ（Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）」によって情報源を含んだ関係演算や拡張した関数を使用した統合ロジックを運用者（または開発者）が記述して登録する必要があった。
【００１３】
また、物理統合、仮想統合およびストリーム統合は、それぞれ異なる処理系で実行されている。したがって、統合方式毎に開発や運用が必要になり、開発負担や費用増大、複雑性の増加といった問題があった。また、情報源や利用側を各統合方式に混在させたい状況が発生しても、処理系が異なるため混在させることはできなかった。
【００１４】
たとえば、３つの情報源があり、１つは物理統合された情報、１つはＤＢＭＳ（Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）で運用されているデータ、１つはストリームデータである場合、これらの情報源に対して物理統合、仮想統合およびストリーム統合を混在させて実行することは困難であった。同様に、情報源が物理統合された情報で利用側がデータストリームである場合も、物理統合およびストリーム統合を混在させることは困難であった。このような場合は、統合方式ごとに個別に統合システムを開発する必要があった。
【００１５】
本開示技術は、上述した従来技術による問題点を解消するため、開発／運用負担の軽減、費用の低廉化、情報統合の効率化により、情報統合の柔軟性および利便性の向上を図ることができる情報統合装置、情報統合方法および情報統合プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
上述した課題を解決し、目的を達成するため、情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶しておき、前記情報源側から前記情報源側の前記物理モデルでの情報を抽出し、抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合し、統合された結果、前記マッピング定義において未解決の項目がある場合、統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの情報を検索する検索式を生成し、生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合し、統合された統合結果を前記利用側に出力する情報統合装置、情報統合方法および情報統合プログラムが、一例として提供される。
また、情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶しておき、前記情報源側から前記情報源側の前記物理モデルでの情報を抽出し、抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合し、統合された統合結果を前記利用側に出力する情報統合装置、情報統合方法および情報統合プログラムが、一例として提供される。
さらに、情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶しておき、前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合し、統合された統合結果を前記利用側に出力する情報統合装置、情報統合方法および情報統合プログラムが、一例として提供される。
また、情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶しておき、前記情報源側から前記情報源側の前記物理モデルでの情報を抽出し、抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合処理を実行し、前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理を実行し、統合指示を検出し、検出された統合指示が、前記情報源側からの抽出により前記利用側に統合結果を出力する第１の統合指示である場合、前記第１の統合処理を実行し、前記利用側からの問い合わせにより当該問い合わせの結果を前記利用側に返す第２の統合指示である場合、前記第２の統合処理を実行するように制御し、実行された第１または第２の統合処理による統合結果を前記利用側に出力する情報統合装置、情報統合方法および情報統合プログラムが、一例として提供される。
【発明の効果】
【００１７】
本開示技術にかかる情報統合装置、情報統合方法および情報統合プログラムによれば、開発／運用負担の軽減、費用の低廉化、情報統合の効率化、情報統合の用途拡大により、情報統合の利便性の向上を図ることができるという効果を奏する。
【図面の簡単な説明】
【００１８】
【図１】実施の形態にかかる情報統合システムのシステム構成図である。
【図２】ＰＵＬＬ型情報統合を示す説明図である。
【図３】ＰＵＳＨ型情報統合を示す説明図である。
【図４】混合型情報統合を示す説明図である。
【図５】実施の形態にかかる情報統合装置のハードウェア構成を示すブロック図である。
【図６】情報源側システム１１１に記憶されている情報Ａの具体例を示す説明図である。
【図７】情報源側システム１１２に記憶されている情報Ｂ，Ｄ，Ｔの具体例を示す説明図である。
【図８】情報源側システム１１３のデータストリームＳに流れるストリームデータｓｄの具体例を示す説明図である。
【図９】物理モデルＰと論理モデルＬとの対応関係を示す説明図である。
【図１０】図９に示した物理モデルＰと論理モデルＬとの対応関係の部分拡大図（その１）である。
【図１１】図９に示した物理モデルＰと論理モデルＬとの対応関係の部分拡大図（その２）である。
【図１２】図９に示した物理モデルＰと論理モデルＬとの対応関係の部分拡大図（その３）である。
【図１３】メタ情報１０３の記述内容の一例を示す説明図である。
【図１４】物理モデルＰＡの記述内容を示す説明図である。
【図１５】物理モデルＰＢの記述内容を示す説明図である。
【図１６】物理モデルＰＤの記述内容を示す説明図である。
【図１７】物理モデルＰＴの記述内容を示す説明図である。
【図１８】物理モデルＰＳの記述内容を示す説明図である。
【図１９】論理モデルＬＣおよびマッピング定義ＭＤ（Ｃ）の記述内容を示す説明図である。
【図２０】論理モデルＬＥおよびマッピング定義ＭＤ（Ｅ）の記述内容を示す説明図である。
【図２１】論理モデルＬＮおよびマッピング定義ＭＤ（Ｎ）の記述内容を示す説明図である。
【図２２】評価ポイントテーブルの記憶内容を示す説明図である。
【図２３】マッピング定義ＭＤのソート処理前後を示す説明図（その１）である。
【図２４】マッピング定義ＭＤのソート処理前後を示す説明図（その２）である。
【図２５】マッピング定義ＭＤのソート処理前後を示す説明図（その３）である。
【図２６】事前設定情報の一例を示す説明図である。
【図２７】事前設定情報の他の例を示す説明図である。
【図２８】論理モデルＬＥに登録機能１４１を割り付ける事前設定の一例を示す説明図である。
【図２９】論理モデルＬＥに登録機能１４１を割り付ける事前設定の他の例を示す説明図である。
【図３０】物理モデルＰＡに抽出機能１３１を割り付ける事前設定の一例を示す説明図である。
【図３１】物理モデルＰＡに抽出機能１３１を割り付ける事前設定の他の例を示す説明図（その１）である。
【図３２】物理モデルＰＡに抽出機能１３１を割り付ける事前設定の他の例を示す説明図（その２）である。
【図３３】物理モデルＰＳにデータストリームの取得機能１３３を割り付ける事前設定の一例を示す説明図である。
【図３４】物理モデルＰＳにデータストリームの取得機能１３３を割り付ける事前設定の他の例を示す説明図である。
【図３５】論理モデルＬＮにデータストリームの送出機能１４３を割り付ける事前設定の一例を示す説明図である。
【図３６】論理モデルＬＮにデータストリームの送出機能１４３を割り付ける事前設定の他の例を示す説明図である。
【図３７】物理統合指示情報３７００の一例を示す説明図である。
【図３８】仮想統合指示情報３８００の一例を示す説明図である。
【図３９】ストリーム統合指示情報３９００の一例を示す説明図である。
【図４０】統合エンジン１０１による統合処理手順を示すフローチャートである。
【図４１】図４０に示した物理統合処理（ステップＳ４００５）の詳細な処理手順を示すフローチャートである。
【図４２】図４０に示した仮想統合処理（ステップＳ４００６）の詳細な処理手順を示すフローチャートである。
【図４３】データストリームの監視処理手順を示すフローチャートである。
【図４４】図４０に示したストリーム統合処理（ステップＳ４００７）の詳細な処理手順を示すフローチャートである。
【図４５】図４１および図４４に示したＰＵＳＨ型情報統合処理（ステップＳ４１０５）の詳細な処理手順を示すフローチャートである。
【図４６】図４２および図４５に示したＰＵＬＬ型情報統合処理（ステップＳ４２０１）の詳細な処理手順を示すフローチャートである。
【図４７】図４６に示した問合わせ分解処理（ステップＳ４６０１）の詳細な処理手順を示すフローチャートである。
【図４８】ステップＳ４７０２での統合結果Ｅを示す説明図である。
【図４９】ステップＳ４７０２でのマッピング定義ＭＤ（Ｅ）を示す説明図である。
【図５０】ステップＳ４７０３でのマッピング定義ＭＤ（Ｅ）を示す説明図である。
【図５１】ステップＳ４７０８で作成された検索式の一例を示す説明図である。
【図５２】図４５および図４６に示した対象データ反映処理（ステップＳ４５０４）の詳細な処理手順を示すフローチャートである。
【図５３】図５２に示したデータ変換処理（ステップＳ５２０２）の詳細な処理手順を示すフローチャートである。
【図５４】図４７および図５３に示した検索条件のクレンジング処理（ステップＳ４７０５）の詳細な処理手順を示すフローチャートである。
【図５５】型属性の違いによるクレンジングの一例を示す図である。
【図５６】データ型が異なるときに実行されるクレンジング機能の一例を示す図である。
【図５７】図５２および図５４に示したクレンジング処理（ステップＳ５２０３）の詳細な処理手順を示すフローチャートである。
【図５８】図５２に示した結果反映処理（ステップＳ５２０４）の詳細な処理手順を示すフローチャートである。
【図５９】図４１のステップＳ４１０１による対象データの抽出例を示す説明図である。
【図６０】論理モデルＬのマッピング定義ＭＤの初期化（ステップＳ４５０１）を示す説明図である。
【図６１】対象データ反映処理（ステップＳ４５０４）の具体例を示す説明図である。
【図６２】図４７に示した検索条件のクレンジング処理（ステップＳ４７０５）の具体例を示す説明図である。
【図６３】解決フラグの更新例を示す説明図である。
【図６４】指定された検索式の実行内容（ステップＳ４６０４）を示す説明図である。
【図６５】ＰＵＬＬ型情報統合処理の完了時の統合結果Ｅを示す説明図である。
【図６６】図４２に示した検索条件抽出処理（ステップＳ４２００）の例を示す説明図である。
【図６７】検索条件６６００から得られたマッピング定義ＭＤ（Ｅ）の初期化を示す説明図である。
【図６８】検索条件のクレンジング処理例を示す説明図である。
【図６９】図４７のステップＳ４７０８での検索式の生成例（１回目）を示す説明図である。
【図７０】図４７のステップＳ４７０８での検索式の生成例（２回目）を示す説明図である。
【図７１】検索式６９００の検索内容を示す説明図である。
【図７２】対象データ反映処理（ステップＳ４５０４）の具体例（１回目）を示す説明図である。
【図７３】対象データ反映処理（ステップＳ４５０４）の具体例（２回目）を示す説明図である。
【図７４】検索式７０００による検索内容を示す説明図である。
【図７５】統合結果Ｅの処理対象レコードの移動状態を示す説明図である。
【図７６】対象データ反映処理（ステップＳ４５０４）の表Ｂの検索結果における具体例を示す説明図である。
【図７７】中間テーブルとして検索された表Ｄの検索結果７７００を示す説明図である。
【図７８】対象データ反映処理（ステップＳ４５０４）の表Ｄの検索結果における具体例を示す説明図である。
【図７９】仮想統合結果として出力される統合結果Ｅを示す説明図である。
【図８０】ストリーム統合による対象データの取得例を示す説明図である。
【図８１】初期化済みのマッピング定義ＭＤ（Ｎ）を示す説明図である。
【図８２】抽出結果Ｓの先頭の対象データにおける対象データ反映処理例を示す説明図である。
【図８３】抽出結果Ｓのつぎの対象データの指定例を示す説明図である。
【図８４】ストリーム統合における中間テーブル検索処理例（その１）を示す説明図である。
【図８５】ストリーム統合における中間テーブル検索処理例（その２）を示す説明図である。
【図８６】対象データ反映処理（ステップＳ４５０４）の表Ｄの検索結果８５０２における具体例を示す説明図である。
【図８７】対象データ反映処理（ステップＳ４５０４）の表Ｓの抽出結果Ｓにおける具体例（その１）を示す説明図である。
【図８８】対象データ反映処理（ステップＳ４５０４）の表Ｓの抽出結果Ｓにおける具体例（その２）を示す説明図である。
【図８９】ストリーム統合結果として出力される統合結果Ｎを示す説明図である。
【図９０】実施例２の物理統合指示情報９０００の一例を示す説明図である。
【図９１】実施例２のマッピング定義の初期化（ステップＳ４５０１）を示す説明図である。
【図９２】実施例２の対象データ反映処理（ステップＳ４５０４）の１回目（表Ａの反映処理）を示す説明図である。
【図９３】実施例２の対象データ反映処理（ステップＳ４５０４）の２回目（表Ｂの反映処理）を示す説明図である。
【図９４】情報源または利用側にアプリケーションプログラムを使用する例（ＰＵＬＬ型）を示す説明図である。
【図９５】情報源または利用側にアプリケーションプログラムを使用する例（ＰＵＳＨ型／混合型）を示す説明図である。
【図９６】問合わせ分解処理（ステップＳ４６０１）の動作例１における初期化時（ステップＳ４７０３処理後）のマッピング定義を示す説明図である。
【図９７】問合わせ分解処理（ステップＳ４６０１）の動作例１における１回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。
【図９８】問合わせ分解処理（ステップＳ４６０１）の動作例１における２回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。
【図９９】問合わせ分解処理（ステップＳ４６０１）の動作例２における初期化時（ステップＳ４７０２処理後）のマッピング定義を示す説明図である。
【図１００】問合わせ分解処理（ステップＳ４６０１）の動作例２における１回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。
【図１０１】問合わせ分解処理（ステップＳ４６０１）の動作例３における初期化時（ステップＳ４７０３処理後）のマッピング定義を示す説明図である。
【図１０２】問合わせ分解処理（ステップＳ４６０１）の動作例３における１回目の検索式実行（ステップＳ４７０７処理後）のマッピング定義を示す説明図である。
【図１０３】問合わせ分解処理（ステップＳ４６０１）の動作例３における２回目の検索式実行（ステップＳ４７０７処理後）のマッピング定義を示す説明図である。
【図１０４】問合わせ分解処理（ステップＳ４６０１）の動作例３における３回目の検索式作成（ステップＳ４７０７処理後）のマッピング定義を示す説明図である。
【図１０５】問合わせ分解処理（ステップＳ４６０１）の動作例３における４回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。
【図１０６】ツリー構造の論理モデルＭに対応するＸＭＬ  Ｓｃｈｅｍａおよびデータ構造の例を示す説明図である。
【図１０７】ツリー構造の論理モデルＭに対応するメタ情報の一部について例を示す説明図である。
【図１０８】図１０７の例について、関連するメタ情報の全体像を示す説明図である。
【図１０９】ツリー構造の論理モデルＭに対するストリーム統合指示情報を示す説明図である。
【図１１０】図１０９の論理モデルＭに対するストリーム統合指示による情報統合結果の例を示す説明図である。
【発明を実施するための形態】
【００１９】
以下に添付図面を参照して、本開示技術にかかる情報統合装置、情報統合方法および情報統合プログラムの好適な実施の形態を詳細に説明する。以下に示す実施の形態では、物理統合、仮想統合およびストリーム統合を共通の統合エンジンにより統合処理を実現する情報統合システムについて説明する。
【００２０】
＜システム構成＞
図１は、実施の形態にかかる情報統合システムのシステム構成図である。情報統合システム１００は、統合エンジン１０１と情報源１１０と利用側１２０とを含む構成である。統合エンジン１０１は、情報源１１０と利用側１２０とに接続され、物理統合、仮想統合、およびストリーム統合を実現する。
【００２１】
ここで、物理統合は、大量の情報を効率よく処理でき、バッチ処理を中心に使用される。たとえば、銀行の決済情報では、夜間バッチで物理統合処理を実行し、翌日の営業開始時に決済を完了させている。
【００２２】
仮想統合は、利用側１２０からの要求時に、リアルタイムで情報源の情報を収集して統合するので、統合結果の鮮度が高い。たとえば、ＳＯＡ（Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ：サービス指向アーキテクチャ）のような業務システム間連携において、必要なときに相手システムのマスタデータを参照する際に使用される。
【００２３】
ストリーム統合は、情報の受信、送出、中継時にリアルタイムで情報統合を実行し、高いリアルタイム性が求められる。ＳＯＡのサービスメッセージや、デジタル電話、センサー情報の転送、データ放送など、使用される機会が増大している。
【００２４】
情報源１１０は、情報源側システム１１１〜１１３を有する。情報源側システム１１１〜１１３は、各種情報を記憶するコンピュータシステムである。本実施の形態では、たとえば、情報源側システム１１１を従業員管理システム、情報源側システム１１２を組織管理システム、情報源側システム１１３を社内電話システムとする。
【００２５】
したがって、情報源側システム１１１が記憶する情報Ａは、従業員番号、氏名、電話番号といった従業員に関する情報である。また、情報源側システム１１２が記憶する情報Ｂ，Ｄ，Ｔは、従業員番号や（従業員の）所属といった組織に関する情報である。また、情報源側システム１１３のデータストリームＳは、発信元、発信先、発信日時といった通話に関する情報である。
【００２６】
利用側１２０は、利用側システム１２１〜１２３を有する。利用側システム１２１〜１２３は、各種情報の提供を受けるコンピュータシステムである。本実施の形態では、たとえば、利用側システム１２１をデータベースサーバやアプリケーションサーバ、クライアント装置を管理するサーバとしてもよく、クライアント装置群としてもよい。
【００２７】
本実施の形態では、利用側システム１２１は、統合エンジン１０１からの統合結果ＣをデータベースＤＢに登録する。また、利用側システム１２２は、利用側システム１２２からの問合わせに応じた統合結果Ｅを仮想ビューとしてアプリケーションに提供する。そして、ディスプレイに表示する。利用側システム１２３は、統合エンジン１０１からの統合結果ＮをデータストリームＺに送出する。
【００２８】
統合エンジン１０１は、情報入力機能１３０と情報出力機能１４０とメタ情報１０３と制御機能１０２とを有する情報統合装置である。情報入力機能１３０は、情報源１１０からの情報を入力する。具体的には、抽出機能１３１は、抽出指示１０４を受けると、条件に合致した結果（情報Ａ）を、情報源側システム１１１から抽出する。また、収集機能１３２は、制御機能１０２からの問合わせに応じた結果（情報Ｂ，Ｄ，Ｔ）を、情報源側システム１１２から収集する。
【００２９】
また、取得機能１３３は、取得指示１０５を受けると、情報源側システム１１３において流れているデータストリームＳから該当するストリームデータを取得して統合エンジン１０１にキューイングする。具体的には、外部から取得指示を与えて後述するＰＵＳＨ型情報統合処理でデータストリームＳからデータを取得する。また、取得機能１３３は、統合エンジン１０１の指示により後述するＰＵＬＬ型情報統合処理でデータストリームＳから該当するストリームデータを取得する。
【００３０】
情報出力機能１４０は、制御機能１０２からの情報を出力する。具体的には、登録機能１４１は、制御機能１０２からの統合結果Ｃを利用側システム１２１のデータベースＤＢに登録する。また、提供機能１４２は、利用側システム１２２からの仮想ビューＥに対する問合わせ文（検索式）を統合エンジン１０１に伝え、統合エンジン１０１により得られた統合結果Ｅを利用側システム１２２に提供する。その後、利用側システム１２２では、統合結果Ｅをディスプレイに表示する。送出機能１４３は、データストリームＳの統合結果Ｎを必要によりキューイングして、利用側システム１２３のデータストリームＺに送出する。
【００３１】
メタ情報１０３は、物理モデルＰと論理モデルＬとマッピング定義ＭＤを有する。物理モデルＰとは、情報源１１０において管理されているデータのモデル（スキーマ）を定義したものである。たとえば、情報源側システム１１１のデータに関するデータモデルが物理モデルＰＡである。物理モデルＰＡは、たとえば、従業員番号と氏名と電話番号といった従業員に関する属性を有する。
【００３２】
また、情報源側システム１１２のデータについて定義されたデータモデルが物理モデルＰＢ，ＰＤ，ＰＴである。物理モデルＰＢは、たとえば、従業員番号と所属といった組織に関する属性を有する。物理モデルＰＤは、たとえば、所属と（所属の）名称といった組織に関する属性を有する。物理モデルＰＴは、たとえば、内線（番号）とその所属といった組織に関する属性を有する。
【００３３】
また、情報源側システム１１３においてデータストリームを流れるストリームデータの形式を定義したデータモデルが物理モデルＰＳである。物理モデルＰＳは、たとえば、発信元、発信先、発信日時といった通話に関する属性を有する。
【００３４】
また、論理モデルＬとは、情報源１１０からの情報について利用側アプリケーションごとにあらかじめ定義されたデータモデルである。たとえば、利用側システム１２１におけるデータベースＤＢの登録に必要なデータモデルが論理モデルＬＣである。たとえば、論理モデルＬＣは、物理モデルＰＡで定義された従業員に関する属性（たとえば、従業員番号と氏名）と、物理モデルＰＢで定義された組織に関する属性（たとえば、所属）とを統合した属性を有する。
【００３５】
また、利用側システム１２２においてアプリケーションが必要なデータ形式として定義されたデータモデルが論理モデルＬＥである。たとえば、論理モデルＬＥは、物理モデルＰＡで定義された従業員に関する属性（たとえば、従業員番号と氏名）と、物理モデルＰＢ，ＰＤで定義された組織に関する属性（たとえば、所属）とを統合した属性を有する。
【００３６】
また、利用側システム１２３において、データストリームＺのデータ形式として定義されたデータモデルが論理モデルＬＮである。たとえば、論理モデルＬＮは、物理モデルＰＤで定義された組織に関する属性（たとえば、所属の名称）と、物理モデルＰＳで定義された通話に関する属性（たとえば、発信元、発信先、発信日時）を統合した属性を有する。
【００３７】
マッピング定義ＭＤとは、物理モデルＰと論理モデルＬとの対応関係を定義したテーブルである。これにより、物理モデルＰのどの属性がどの論理モデルＬの属性に統合されるかがわかることとなる。
【００３８】
制御機能１０２は、マッピング定義ＭＤを参照して、情報源１１０からの情報を物理モデルＰから論理モデルＬに統合したり、利用側１２０からの問合わせを論理モデルＬから物理モデルＰに分解したりする。その際、必要に応じて値の各種変換処理（クレンジング処理）を実行する。
【００３９】
このように、情報統合システム１００では、利用側システム１２１から見れば物理統合が実現され、利用側システム１２２から見れば仮想統合が実現され、利用側システム１２３から見ればストリーム統合が実現される。したがって、統合エンジン１０１を利用することで、共通のメタ情報１０３により、物理統合、仮想統合およびストリーム統合が実現できる。
【００４０】
これにより、メタ情報１０３の定義付けが１回で済み、開発負担の軽減を図ることができる。また、二重定義や定義のコンバートが不要となり、矛盾が発生しないため、信頼性の向上を図ることができる。さらに、物理統合、仮想統合およびストリーム統合といった３種類の処理系を単一化することができ、開発コストの低減化と運用の柔軟性向上を図ることができる。
【００４１】
＜情報統合の方式種＞
つぎに、情報統合の方式種について説明する。上述した統合エンジン１０１では、ＰＵＬＬ型情報統合とＰＵＳＨ型情報統合と混合型情報統合といった３種類の方式種を利用することができる。
【００４２】
図２は、ＰＵＬＬ型情報統合を示す説明図である。ＰＵＬＬ型情報統合とは、利用側１２０からの問合わせによって、統合結果を利用側１２０に返す方式である。ＰＵＬＬ型情報統合は、制御機能１０２が有する問合わせ分解機能２０１と結果統合機能２０２により統合をおこなう。問合わせ分解機能２０１とは、利用側１２０からの論理モデルＬＸに対する問合わせ文Ｑを、対応する物理モデルＰＡ，ＰＢへの問合わせ文に分解して情報源Ａ，Ｂを検索する。結果統合機能２０２とは、各物理モデルＰＡ，ＰＢとして得られた検索結果情報ＰＡ，ＰＢを論理モデルＬＸに統合して、統合結果Ｒを返す。ＰＵＬＬ型情報統合により仮想統合が実現される。
【００４３】
図３は、ＰＵＳＨ型情報統合を示す説明図である。ＰＵＳＨ型情報統合とは、情報源１１０から情報を入力することにより、利用側１２０に統合結果Ｒを出力する方式である。ＰＵＳＨ型情報統合では、結果統合機能２０２により統合をおこなう。情報源１１０から物理モデルＰＡ，ＰＢとして入力された情報は結果統合機能によって論理モデルＬＸに統合されて利用側１２０に統合結果Ｒを出力する。具体的には、問合わせ分解機能２０１を使わない（ＯＦＦにする）ことによりＰＵＳＨ型情報統合を実現することができる。したがって、共通の統合エンジン１０１により、ＰＵＬＬ型情報統合とＰＵＳＨ型情報統合とを実現することができる。
【００４４】
図４は、混合型情報統合を示す説明図である。混合型情報統合とは、ＰＵＬＬ型情報統合とＰＵＳＨ型情報統合とを混合した方式である。基本は物理モデルＰＡに入力された情報Ａについて論理モデルＬＸへの統合を行い、利用側１２０に統合結果Ｒを出力するＰＵＳＨ型である。ただし、統合に必要な情報が他の情報源１１０に存在する場合に、問合わせ分解機能２０１により物理モデルＰＢに対する必要な問合わせ文Ｑを生成して、ＰＵＬＬ型情報統合により情報Ｂを取得して統合する。図４では、情報ＡはＰＵＳＨ型、情報ＢはＰＵＬＬ型で統合しているので混合型である。
【００４５】
＜情報統合装置のハードウェア構成＞
図５は、実施の形態にかかる情報統合装置のハードウェア構成を示すブロック図である。図５において、情報統合装置は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）５０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ  Ｍｅｍｏｒｙ）５０２と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）５０３と、磁気ディスクドライブ５０４と、磁気ディスク５０５と、光ディスクドライブ５０６と、光ディスク５０７と、ディスプレイ５０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）５０９と、キーボード５１０と、マウス５１１と、スキャナ５１２と、プリンタ５１３と、を備えている。また、各構成部はバス５００によってそれぞれ接続されている。
【００４６】
ここで、ＣＰＵ５０１は、情報統合装置の全体の制御を司る。ＲＯＭ５０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。磁気ディスクドライブ５０４は、ＣＰＵ５０１の制御にしたがって磁気ディスク５０５に対するデータのリード／ライトを制御する。磁気ディスク５０５は、磁気ディスクドライブ５０４の制御で書き込まれたデータを記憶する。
【００４７】
光ディスクドライブ５０６は、ＣＰＵ５０１の制御にしたがって光ディスク５０７に対するデータのリード／ライトを制御する。光ディスク５０７は、光ディスクドライブ５０６の制御で書き込まれたデータを記憶したり、光ディスク５０７に記憶されたデータをコンピュータに読み取らせたりする。
【００４８】
ディスプレイ５０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ５０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００４９】
Ｉ／Ｆ５０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク５１４に接続され、このネットワーク５１４を介して他の装置に接続される。そして、Ｉ／Ｆ５０９は、ネットワーク５１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ５０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。
【００５０】
キーボード５１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス５１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。
【００５１】
スキャナ５１２は、画像を光学的に読み取り、情報統合装置内に画像データを取り込む。なお、スキャナ５１２は、ＯＣＲ（Ｏｐｔｉｃａｌ  Ｃｈａｒａｃｔｅｒ  Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ５１３は、画像データや文書データを印刷する。プリンタ５１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。
【００５２】
なお、図１〜図４に示した各機能は、図５に示したＲＯＭ５０２，ＲＡＭ５０３，磁気ディスク５０５などの記憶装置に記憶されたプログラムを、ＣＰＵ５０１に実行させることにより実現される。また、情報源１１０および利用側１２０の各種情報、メタ情報１０３は、図５に示したＲＯＭ５０２，ＲＡＭ５０３，磁気ディスク５０５などの記憶装置に記憶されている情報である。
【００５３】
情報源１１０はネットワーク５１４で接続された他の情報システムで記憶している情報でもよく、利用側１２０は情報統合装置と同じ環境で動作する別のアプリケーションプログラム、データベース、データストリームまたは、ネットワーク５１４で接続された他の情報システムで動作しているアプリケーションプログラム、データベース、データストリームであってもよい。また、ＣＰＵ５０１とＲＡＭ５０３を除くハードウェアは、情報統合装置の動作に必要な構成の範囲内で必要に応じて採用するものであり、情報統合装置の必須要件では無い。
【００５４】
＜情報源１１０の具体例＞
つぎに、情報源１１０の具体例について説明する。上述したように、本実施の形態では、たとえば、情報源側システム１１１を従業員管理システム、情報源側システム１１２を組織管理システム、情報源側システム１１３を社内電話システムとする。
【００５５】
図６は、情報源側システム１１１に記憶されている情報Ａの具体例を示す説明図である。物理モデルＰＡは情報統合エンジン１０１から見たときの情報Ａを規定し、属性ごとに属性名、データ型、制約を有する。属性名とは従業員番号、氏名、電話番号といった属性の名称であり、データ型とは、整数型（Ｉｎｔｅｇｅｒ）や文字列型（Ｓｔｒｉｎｇ）といった属性の型を示す。制約とは、その属性が主キー（ＭＫｅｙ）であるか従属キー（ＳＫｅｙ）であるかを識別する。たとえば、従業員番号は、整数型で主キー制約がある。また、氏名および電話番号は文字列型である。
【００５６】
情報Ａは、物理モデルＰＡに基づいて従業員番号項目、氏名項目および電話番号項目を構成し、レコードごとに従業員情報を管理する。図６では、従業員番号７００１〜７００３の３名の従業員が登録されている。なお、情報源側システム１１１はパーソナル・コンピュータで稼働していることを想定しているので、情報Ａの文字コード系は、Ｓ−ＪＩＳ（Ｓｈｉｆｔ  ＪＩＳ  ｃｏｄｅ）とする。
【００５７】
図７は、情報源側システム１１２に記憶されている情報Ｂ，Ｄ，Ｔの具体例を示す説明図である。物理モデルＰＢ，ＰＤ，ＰＴは情報統合エンジン１０１から見たときの情報Ｂ，Ｄ，Ｔを規定し、物理モデルＰＡと同様、属性ごとに属性名、データ型、制約を有する。属性名とは従業員番号、所属、名称、内線といった属性の名称であり、データ型とは、整数型（Ｉｎｔｅｇｅｒ）や文字列型（Ｓｔｒｉｎｇ）といった属性の型を示す。制約とは、その属性が主キー（ＭＫｅｙ）であるか従属キー（ＳＫｅｙ）であるかを識別する。
【００５８】
情報Ｂは、物理モデルＰＢに基づいて従業員番号項目および所属項目を構成し、レコードごとに従業員の所属情報を管理する。図７では、従業員番号７００１〜７００３の３名の従業員の所属が登録されている。情報Ｄは、物理モデルＰＤに基づいて所属項目および名称項目を構成し、レコードごとに所属情報を管理する。図７では、１０１：営業部と１０２：製造部といった２つの所属が登録されている。
【００５９】
情報Ｔは、物理モデルＰＴに基づいて内線項目および所属項目を構成し、レコードごとに内線の所属情報を管理する。図７では、内線：１４１００の所属：１０１と、内線２４２００の所属：２０２が登録されている。なお、情報源側システム１１２はメインフレーム上で稼働していることを想定しているので、情報Ｂ，Ｄ，Ｔの文字コード系は、ＪＥＦ（Ｊａｐａｎｅｓｅ  ｐｒｏｃｅｓｓｉｎｇ  Ｅｘｔｅｎｄｅｄ  Ｆｅａｔｕｒｅ）とする。
【００６０】
図８は、情報源側システム１１３のデータストリームＳに流れるストリームデータｓｄの具体例を示す説明図である。情報源側システム１１３では、内線：１４１００の電話機８０１から内線：２４２００の電話機８０２への通話がおこなわれ、データストリームＳが流れている。データストリームＳの実体は一連のストリームデータｓｄである。ストリームデータｓｄは、発信日時（ＤＴ）と、発信元（ＦＲＯＭ）と、発信先（ＴＯ）が規定されている。
【００６１】
また、物理モデルＰＳは情報統合エンジン１０１から見たときのデータストリームＳを規定し、物理モデルＰＡと同様、属性ごとに属性名、データ型、制約を有する。属性名とは属性の名称（図８では、ＤＴ，ＦＲＯＭ，ＴＯ）であり、データ型とは、整数型（Ｉｎｔｅｇｅｒ）や文字列型（Ｓｔｒｉｎｇ）といった属性の型を示す。制約とは、その属性が主キー（ＭＫｅｙ）であるか従属キー（ＳＫｅｙ）であるかを識別する。
【００６２】
データストリームＳは、物理モデルＰＳに基づいてＤＴ項目，ＦＲＯＭ項目およびＴＯ項目を構成し、レコードごとに通話情報を示す。図８では、２００９年２月２８日２０時２０分００秒、同２１分００秒、同２２分００秒の３回、内線：１４１００から内線２４２００に通話があったことを示している。
【００６３】
＜物理モデルＰと論理モデルＬとの対応関係＞
つぎに、物理モデルＰと論理モデルＬとの対応関係について説明する。物理モデルＰと論理モデルＬとは、マッピング定義ＭＤにより対応付けられる。
【００６４】
図９は、物理モデルＰと論理モデルＬとの対応関係を示す説明図である。図９では、情報源側システム１１１〜１１３で管理する前述の物理モデルＰＡ，ＰＢ，ＰＤ，ＰＴ，ＰＳに対して、表Ａ，表Ｂ，表Ｄ，表Ｔ，表Ｓというモデル名をつけている。また、利用側システム１２１〜１２３ごとに論理モデルＬを有する。図９に示す各論理モデルＬＣ，ＬＥ，ＬＮも、物理モデルＰと同様、属性名、データ型、制約により構成されている。
【００６５】
ここで、論理モデルＬＣは、項目として従業員番号、氏名、電話番号、所属とを有する従業員一覧（表Ｃ）のデータモデルである。また、論理モデルＬＥは、項目として従業員番号、氏名、所属とを有する従業員一覧（表Ｅ）のデータモデルである。論理モデルＬＮは項目としてＤＴ（発信日時）、ＦＲＯＭ（発信元コード）、ＦＲＯＭ名称、ＴＯ（発信先コード）とを有する通話記録表（表Ｎ）のデータモデルである。
【００６６】
また、利用側システム１２１〜１２３ごとにマッピング定義ＭＤが用意されている。マッピング定義ＭＤは、それぞれＦｒｏｍ列項目とＴｏ列項目とを有する。Ｆｒｏｍ列項目には、物理モデルＰのモデル名＋属性名が登録されており、Ｔｏ列項目には、論理モデルＬまたは物理モデルＰのモデル名＋属性名が登録されている。
【００６７】
マッピング定義ＭＤ（Ｃ）は、物理モデルＰと論理モデルＬＣとを対応付けるテーブルである。マッピング定義ＭＤ（Ｅ）は、物理モデルＰと論理モデルＬＥとを対応付けるテーブルである。マッピング定義ＭＤ（Ｎ）は、物理モデルＰと論理モデルＬＮとを対応付けるテーブルである。マッピング定義ＭＤに示した各マッピング定義のＦｒｏｍ列の示す項目は、図９の矢印の始端、すなわち結果データの複製元を示しており、Ｔｏ列の示す項目は、図９の矢印の終端、すなわち結果データの複製先を示している。このことを、Ｆｒｏｍ列の項目からＴｏ列の項目に「マッピングする」と呼ぶ。
【００６８】
図１０は、図９に示した物理モデルＰと論理モデルＬとの対応関係の部分拡大図（その１）であり、論理モデルＬＣに必要な定義だけを拡大したものである。図１０では、物理モデルＰＡ，ＰＢと論理モデルＬＣとの対応関係をマッピング定義ＭＤ（Ｃ）により定義している。図１０において、物理モデルＰＡ，ＰＢと論理モデルＬＣとの間の矢印のカッコ番号とマッピング定義ＭＤ（Ｃ）の各行に付されているカッコ番号とが対応している。
【００６９】
たとえば、マッピング定義ＭＤ（Ｃ）の１行目（１）を参照すると、Ｆｒｏｍ列の項目が「表Ａ．従業員番号」であり、Ｔｏ列の項目が「表Ｃ．従業員番号」である。したがって、物理モデルＰＡ（表Ａ）の従業員番号の項目が論理モデルＬＣ（表Ｃ）の従業員番号の項目にマッピングされる。
【００７０】
同様に、マッピング定義ＭＤ（Ｃ）の２行目（２）を参照すると、Ｆｒｏｍ列の項目が「表Ｂ．従業員番号」であり、Ｔｏ列の項目が「表Ｃ．従業員番号」である。したがって、物理モデルＰＢ（表Ｂ）の従業員番号の項目が論理モデルＬＣ（表Ｃ）の従業員番号の項目にマッピングされる。
【００７１】
ここで、マッピング定義（１）はＦｒｏｍ列とＴｏ列に主キー制約（ＭＫｅｙ）を持つ項目（以下ではＭＫｅｙ項目と呼ぶ）を指定している。このように、物理モデルのＭＫｅｙ項目を論理モデルのＭＫｅｙ項目にマッピングすることによって、物理モデルのレコードを論理モデルのレコードにＭＫｅｙ項目で対応付けることができる。すなわち、マッピング定義（１）は物理モデルＰＡのレコードを論理モデルＬＣのレコードとして従業員番号の項目で対応付けしていることになる。
【００７２】
また、マッピング定義（２）も同様にＦｒｏｍ列とＴｏ列にＭＫｅｙ項目を指定しており、そのＴｏ列は、マッピング定義（１）と同じ論理モデルＬＣの従業員番号にマッピングしている。このように、複数の物理モデルのＭＫｅｙ項目を１つの論理モデルのＭＫｅｙ項目にマッピングすることによって、複数の物理モデルのレコードを論理モデルに対応付けることができる。
【００７３】
このことは、複数の物理モデルのレコードをマッピング定義で指定した項目をＪＯＩＮキーとして関係演算のＪＯＩＮ演算を実行した結果を論理モデルに対応付けていることになる。すなわち、物理モデルＰＡのレコードと物理モデルＰＢのレコードを、従業員番号をキーにして関係演算のＪＯＩＮ演算を実行した結果を論理モデルＬＣのレコードとして対応付けしていることになる。
【００７４】
図１１は、図９に示した物理モデルＰと論理モデルＬとの対応関係の部分拡大図（その２）であり、論理モデルＬＥに必要な定義だけを拡大したものである。図１１では、物理モデルＰＡ，ＰＢ，ＰＤと論理モデルＬＥとの対応関係をマッピング定義ＭＤ（Ｅ）により定義している。図１１において、物理モデルＰＡ，ＰＢ，ＰＤと論理モデルＬＥとの間の矢印のカッコ番号とマッピング定義ＭＤ（Ｅ）の各行に付されているカッコ番号とが対応している。
【００７５】
マッピング定義ＭＤ（Ｅ）では、従属キー制約（ＳＫｅｙ）のある属性について、当該属性をＦｒｏｍ列項目、従属先の属性をＴｏ列項目に記述しておくことができる。たとえば、マッピング定義ＭＤ（Ｅ）の３行目（３）は、Ｆｒｏｍ列項目が「表Ｂ．所属」、Ｔｏ列項目が「表Ｄ．所属」である。また、マッピング定義ＭＤ（Ｅ）の５行目（５）は、Ｆｒｏｍ列項目が「表Ｄ．名称」、Ｔｏ列項目が「表Ｅ．所属」である。
【００７６】
したがって、物理モデルＰＢの所属（整数型）が物理モデルＰＤの所属（整数型）にマッピングし、マッピングされた所属（整数型）の名称（文字列型）が論理モデルＬＥの所属（文字列型）にマッピングすることにより、論理モデルＬＥの所属（文字列型）に格納される。これにより、所属（整数型）を所属（文字列型）に変換して利用側システム１２２に提供することができる。
【００７７】
また、各項目はデータ型だけでなく、データ型の詳細な性質を指定するための型属性を複数持つことができる。具体的には、格納元である物理モデルＰＤの名称のＣｈａｒＣｏｄｅ型属性はＪＥＦであり、格納先である論理モデルＬＥの所属のＣｈａｒＣｏｄｅ型属性はＳ＿ＪＩＳである。この場合、対応するクレンジング処理が動作して、格納元のＣｈａｒＣｏｄｅ型属性（ＪＥＦ）は格納先のＣｈａｒＣｏｄｅ型属性（Ｓ＿ＪＩＳ）に変換して格納される。このクレンジング処理は、統合エンジン１０１の制御機能１０２の機能として実装され、データ型や型属性またはその型属性値の組み合わせにより動作する機能が一意に決定できるように構成される。
【００７８】
図１２は、図９に示した物理モデルＰと論理モデルＬとの対応関係の部分拡大図（その３）であり、論理モデルＬＮに必要な定義だけを拡大したものである。図１２では、物理モデルＰＳ，ＰＤ，ＰＴと論理モデルＬＮとの対応関係をマッピング定義ＭＤ（Ｎ）により定義している。図１２において、物理モデルＰＳ，ＰＤ，ＰＴと論理モデルＬＮとの間の矢印のカッコ番号とマッピング定義ＭＤ（Ｎ）の各行に付されているカッコ番号とが対応している。
【００７９】
マッピング定義ＭＤ（Ｎ）においても、従属キー制約（ＳＫｅｙ）のある属性について、当該属性をＦｒｏｍ列項目、従属先の属性をＴｏ列項目に記述しておくことができる。たとえば、マッピング定義ＭＤ（Ｎ）の４行目（４）は、Ｆｒｏｍ列項目が「表Ｓ．ＦＲＯＭ」、Ｔｏ列項目が「表Ｔ．内線」である。また、マッピング定義ＭＤ（Ｎ）の５行目（５）は、Ｆｒｏｍ列項目が「表Ｔ．所属」、Ｔｏ列項目が「表Ｄ．所属」である。さらに、マッピング定義ＭＤ（Ｎ）の６行目（６）は、Ｆｒｏｍ列項目が「表Ｄ．名称」、Ｔｏ列項目が「表Ｎ．ＦＲＯＭ名称」である。
【００８０】
したがって、物理モデルＰＳのＦＲＯＭ（整数型）は物理モデルＰＴの内線（整数型）にマッピングを行い、マッピングされた内線（整数型）の所属（整数型）が、物理モデルＰＤの所属（整数型）をマッピングする。そして、マッピングされた所属（整数型）の名称（文字列型）が、論理モデルＬＮのＦＲＯＭ名称（文字列型）をマッピングする。
【００８１】
すなわち、データストリームＳのＦＲＯＭは内線番号を示しているため、物理モデルＰＴからその所属（整数型）を特定し、特定された所属（整数型）が、物理モデルＰＤの所属（整数型）をマッピングすることで、データストリームＳのＦＲＯＭの内線が属する所属の名称をＦＲＯＭ名称として特定して論理モデルＬに格納することができる。これにより、物理モデルＰには単独では存在しない属性（ＦＲＯＭ名称）を、論理モデルＬで定義することができる。
【００８２】
＜メタ情報１０３の記述内容＞
図１３は、メタ情報１０３の記述内容の一例を示す説明図である。メタ情報１０３は、メタ開始タグ＜ＭＥＴＡ−ＤＡＴＡ＞から始まり、メタ終了タグ＜／ＭＥＴＡ−ＤＡＴＡ＞で終わる。メタ開始タグとメタ終了タグとの間には、物理モデルＰＡ，ＰＢ，ＰＤ，ＰＴ，ＰＳ、論理モデルＬＣおよびマッピング定義ＭＤ（Ｃ）、論理モデルＬＥおよびマッピング定義ＭＤ（Ｅ）、論理モデルＬＮおよびマッピング定義ＭＤ（Ｎ）（符号１３０１〜１３０８）が記述される。
【００８３】
図１４は、物理モデルＰＡの記述内容を示す説明図である。物理モデルＰＡの名称は表Ａとする。図１５は、物理モデルＰＢの記述内容を示す説明図である。物理モデルＰＢの名称は表Ｂとする。図１６は、物理モデルＰＤの記述内容を示す説明図である。物理モデルＰＤの名称は表Ｄとする。図１７は、物理モデルＰＴの記述内容を示す説明図である。物理モデルＰＴの名称は表Ｔとする。図１８は、物理モデルＰＳの記述内容を示す説明図である。物理モデルＰＳの名称は表Ｓとする。
【００８４】
図１９は、論理モデルＬＣおよびマッピング定義ＭＤ（Ｃ）の記述内容を示す説明図である。論理モデルＬＣの名称は表Ｃとする。図２０は、論理モデルＬＥおよびマッピング定義ＭＤ（Ｅ）の記述内容を示す説明図である。論理モデルＬＥの名称は表Ｅとする。図２１は、論理モデルＬＮおよびマッピング定義ＭＤ（Ｎ）の記述内容を示す説明図である。論理モデルＬＮの名称は表Ｎとする。
【００８５】
＜メタ情報１０３の初期化＞
つぎに、メタ情報１０３の初期化について説明する。初期化では、メタ情報１０３を統合エンジン１０１に入力する。なお、統合は、メタ情報１０３に含まれているマッピング定義の上位の行からおこなわれる。したがって、統合がただしくおこなわれるようにするため、マッピング定義ＭＤの行を必要に応じて並び替える。ここでは、評価ポイントを利用する。
【００８６】
図２２は、評価ポイントテーブルの記憶内容を示す説明図である。評価ポイントテーブルは、マッピング定義ＭＤの各行のＦｒｏｍ列およびＴｏ列を評価する評価ポイントを記憶する。マッピング定義ＭＤは、評価ポイント合計の高い順にソートされる。マッピング定義ＭＤのソート処理により統合の順番が決定される。
【００８７】
図２３〜図２５は、マッピング定義ＭＤのソート処理前後を示す説明図である。図２３〜図２５では、評価ポイントテーブルに従って、マッピング定義のＦｒｏｍ列およびＴｏ列の評価を行い、行ごとにポイントを集計する。そして、ポイントの降順にソートして行を並び替える。
【００８８】
＜事前設定＞
つぎに、事前設定について説明する。事前設定とは、情報源１１０にある実データを物理モデルＰに割り付け、また必要により利用側１２０にある格納場所の実体および実体のアクセス手段を論理モデルに割り付ける処理である。事前設定は、物理モデルＰまたは論理モデルＬごとに用意された事前設定情報にしたがって実行する。事前設定として実行時にメタ定義と実体およびアクセス手段とを割り付けることによってメタ定義と具体的な実体とを分けることができるので、メタ定義の汎用性（再利用性）が高まる効果が有る。たとえば、同じメタ定義であっても、事前設定情報を入れ替えることによって、ＲＤＢ，ＣＳＶファイル、ＸＭＬファイルなど、いろいろな性質を持つ実体を使うことが可能になる。
【００８９】
図２６は、事前設定情報の一例を示す説明図である。事前設定情報２６００は、物理モデルＰＡ，ＰＢ，ＰＤを情報源１１０の実データに割り付けている。具体的には、事前設定情報２６００では、物理モデルＰＡを情報源側システム１１１で管理されているＲＤＢ（リレーショナルデータベース）１の表１として割り付ける。同様に、物理モデルＰＢを情報源側システム１１２で管理されているＲＤＢ２の表２として割り付ける。同様に、物理モデルＰＤを情報源側システム１１２で管理されているＲＤＢ３の表３として割り付ける。
【００９０】
図２７は、事前設定情報の他の例を示す説明図である。図２７の事前設定情報２７００は、図２６の事前設定情報２６００の表Ａの割り付けについて記述を追記した例である。事前設定情報２７００では、同一属性について物理モデルＰと実データとで属性名が異なっている（氏名とＮａｍｅ）。したがって、下線部のように、「氏名＝Ｎａｍｅ」を追記しておく。なお、物理統合を行う場合は、以下の図２８または図２９に示す論理モデルの事前設定も必要となる。
【００９１】
図２８は、論理モデルＬＥに登録機能１４１を割り付ける事前設定の一例を示す説明図である。図２８の事前設定情報２８００は、論理モデルＬＥを登録機能１４１に割り付けている。図２８では、論理モデルＬＥのデータ出力先として、ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）情報２８０１である「ｃ：￥Ｔａｂｌｅ−Ｅ．ｃｓｖ」を割り当てる。
【００９２】
事前設定情報２８００の＜ＣＳＶＦＩＬＥ＞タグは、登録機能１４１の種別を示し、個別に属性を指定することができる。たとえば、＜ＣＳＶＦＩＬＥ＞タグのヘッダ属性（ｈｅａｄｅｒ）は、ＣＳＶ情報２８０１の先頭行にスキーマヘッダを付与する（１）／しない（０）ことを示す。
【００９３】
図２９は、論理モデルＬＥに登録機能１４１を割り付ける事前設定の他の例を示す説明図である。図２９の事前設定情報２９００では、利用側システム１２１のＲＤＢ２で管理されている表２に論理モデルＬＥを割り付けている。同一属性について論理モデルＬと実データとで属性名が異なっている場合（従業員番号とＩｄ）、下線部のように、「従業員番号＝ｉｄ」を追記しておく。
【００９４】
図３０は、物理モデルＰＡに抽出機能１３１を割り付ける事前設定の一例を示す説明図である。図３０の事前設定情報３０００では、物理モデルＰＡを、情報源側システム１１１のＲＤＢ１で管理されている表１に割り付けている。なお、物理統合用の抽出機能１３１では、＜ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）＞タグにより抽出条件を指定することができる。この時、全件を処理対象として抽出する場合はｗｈｅｒｅ句を省略する。
【００９５】
図３１および図３２は、物理モデルＰＡに抽出機能１３１を割り付ける事前設定の他の例を示す説明図である。図３１の事前設定情報３１００では、物理モデルＰＡをＣＳＶ情報３１０１に割り付けており、図３２の事前設定情報３２００では、物理モデルＰＡをＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）情報３２０１に割り付けている。
【００９６】
図３３は、物理モデルＰＳにデータストリームの取得機能１３３を割り付ける事前設定の一例を示す説明図である。図３３の事前設定情報３３００では、データストリームＳ１であるＣＳＶストリーム（ＳＴＲＥＡＭ１）からのストリームデータの取得機能１３３を、物理モデルＰＳに割り付けている。
【００９７】
図３４は、物理モデルＰＳにデータストリームの取得機能１３３を割り付ける事前設定の他の例を示す説明図である。図３４の事前設定情報３４００では、データストリームＳ２であるＸＭＬストリーム（ＳＴＲＥＡＭ２）からのストリームデータの取得機能１３３を、物理モデルＰＳに割り付けている。
【００９８】
図３５は、論理モデルＬＮにデータストリームの送出機能１４３を割り付ける事前設定の一例を示す説明図である。図３５の事前設定情報３５００では、論理モデルＬＮのデータ出力先として、データストリームＳ３であるＣＳＶストリーム（ＳＴＲＥＡＭ３）を割り付けている。
【００９９】
図３６は、論理モデルＬＮにデータストリームの送出機能１４３を割り付ける事前設定の他の例を示す説明図である。図３６の事前設定情報３６００では、論理モデルＬＮのデータ出力先として、データストリームＳ４であるＸＭＬストリーム（ＳＴＲＥＡＭ４）を割り付けている。
【０１００】
＜統合指示＞
つぎに、統合指示について説明する。統合指示とは、統合エンジン１０１に、物理統合、仮想統合、およびストリーム統合のうちいずれの統合をおこなうかを指示する処理である。以下、図３７〜図３９を用いて説明する。
【０１０１】
図３７は、物理統合指示情報３７００の一例を示す説明図である。物理統合指示情報３７００は、物理モデルＰＡに存在するすべての情報を抽出して、論理モデルＬＥのデータとして統合結果を返す指示を記述している。すなわち、論理モデルＬＥに割り当てられたファイルやデータベースに統合結果を登録する。もしくは論理モデルＬＥに割り当てられたデータストリームに送出する。なお、Ｗｈｅｒｅ句で抽出条件を指定することもできる。
【０１０２】
図３８は、仮想統合指示情報３８００の一例を示す説明図である。仮想統合指示情報３８００は、論理モデルＬＥを従業員番号＝７００２の条件で検索した結果を返す指示を記述している。
【０１０３】
図３９は、ストリーム統合指示情報３９００の一例を示す説明図である。ストリーム統合指示情報３９００は、物理モデルＰＳに割り当てられたデータストリームＳから、Ｔｏ＝２４２００に該当するデータの２０：２０〜２０：２２までの時間の統合結果を、論理モデルＬＮのデータとして返す指示を記述している。すなわち、論理モデルＬＮに割り当てられたデータストリームに送出する。もしくは、論理モデルＬＮに割り当てられたファイルやデータベースに統合結果を登録する。
【０１０４】
＜統合処理手順＞
図４０は、統合エンジン１０１による統合処理手順を示すフローチャートである。まず、統合エンジン１０１は、メタ情報１０３の読込と初期化をおこなう（ステップＳ４００１）。つぎに、統合エンジン１０１は、事前設定情報の読込をおこなう（ステップＳ４００２）。また、統合エンジン１０１は、統合指示情報を取得する（ステップＳ４００３）。
【０１０５】
そして、統合指示情報の種別を判断する（ステップＳ４００４）。種別の判断は、図３７〜図３９に示した統合指示情報３７００〜３９００の開始タグで判断することができる。統合指示情報３７００〜３９００の種別が物理統合である場合（ステップＳ４００４：ＥＴＬ）、物理統合処理を実行する（ステップＳ４００５）。また、統合指示情報３７００〜３９００の種別が仮想統合である場合（ステップＳ４００４：ＥＩＩ）、仮想統合処理を実行する（ステップＳ４００６）。
【０１０６】
また、統合指示情報３７００〜３９００の種別がストリーム統合である場合（ステップＳ４００４：ＳＴＲＥＡＭ）、ストリーム統合処理を実行する（ステップＳ４００７）。これにより一連の処理を終了する。
【０１０７】
（物理統合処理）
図４１は、図４０に示した物理統合処理（ステップＳ４００５）の詳細な処理手順を示すフローチャートである。まず、物理統合指示情報３７００内の抽出条件により対象データを情報源１１０から抽出する（ステップＳ４１０１）。
【０１０８】
そして、対象データの抽出が成功したか否かを判断する（ステップＳ４１０２）。失敗した場合（ステップＳ４１０２：Ｎｏ）、ステップＳ４１０８に移行してエラー出力をおこなう（ステップＳ４１０８）。一方、成功した場合（ステップＳ４１０２：Ｙｅｓ）、抽出結果があるか否かを判断する（ステップＳ４１０３）。抽出結果がない場合（ステップＳ４１０３：Ｎｏ）、処理を終了する。一方、抽出結果がある場合（ステップＳ４１０３：Ｙｅｓ）、抽出結果の先頭データを指定する（ステップＳ４１０４）。ここで、図５９に示すＲＤＢ１の表Ａの抽出結果である情報Ａでは、１レコード目の先頭項目である「従業員番号＝７００１」を指定する。
【０１０９】
このあと、ＰＵＳＨ型情報統合処理を実行する（ステップＳ４１０５）。ＰＵＳＨ型情報統合処理とは、情報源１１０から統合対象のデータが物理モデルＰで入力され、必要な統合処理が実行されて、利用側１２０に論理モデルＬの統合結果を出力する処理である。ＰＵＳＨ型情報統合処理（ステップＳ４１０５）の詳細については図４５で後述する。そして、ＰＵＳＨ型情報統合処理が成功したか否かを判断する（ステップＳ４１０６）。
【０１１０】
失敗である場合（ステップＳ４１０６：Ｎｏ）、ステップＳ４１０８に移行してエラー出力をおこなう。一方、成功である場合（ステップＳ４１０６：Ｙｅｓ）、物理統合指示情報３７００内の格納条件により統合結果を格納する（ステップＳ４１０７）。ここで統合結果の格納処理（ステップＳ４１０７）は、事前設定情報によって論理モデルＬに割り付けられている出力先がファイルやデータベースの場合には、登録機能１４１によって統合結果が該当するファイルやデータベースに登録されるが、データストリームに割り付けられている場合には、送出機能１４３によって該当するデータストリームに送出される。これにより、物理統合処理（ステップＳ４００５）を終了する。
【０１１１】
（仮想統合処理）
図４２は、図４０に示した仮想統合処理（ステップＳ４００６）の詳細な処理手順を示すフローチャートである。仮想統合処理（ステップＳ４００６）では、まず、統合指示情報３８００から検索条件を抽出する（ステップＳ４２００）。具体的には、たとえば、統合指示情報３７００〜３９００の開始タグ＜ＥＩＩ＞で指定された検索式を検索条件として抽出する。つぎに、ＰＵＬＬ型情報統合処理を実行する（ステップＳ４２０１）。そして、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）が成功したか否かを判断する（ステップＳ４２０２）。
【０１１２】
成功した場合（ステップＳ４２０２：Ｙｅｓ）、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）で得られたデータを統合結果として出力する（ステップＳ４２０３）。一方、失敗した場合（ステップＳ４２０２：Ｎｏ）、エラー出力をおこなう（ステップＳ４２０４）。これにより、仮想統合処理（ステップＳ４００６）を終了する。
【０１１３】
（データストリームの監視処理）
図４３は、データストリームの監視処理手順を示すフローチャートである。まず、所定の開始条件（たとえば、時刻）に該当するまで待ち受ける（ステップＳ４３０１：Ｎｏ）。該当した場合（ステップＳ４３０１：Ｙｅｓ）、終了条件（たとえば、時刻）に該当するか否かを判断する（ステップＳ４３０２）。
【０１１４】
該当しない場合（ステップＳ４３０２：Ｎｏ）、データストリームＳ（通話システム）内に取得条件に合致するデータ（ストリームデータｓｄ）があるか否かを判断する（ステップＳ４３０３）。取得条件は、任意に設定することができる。たとえば、すべてのストリームデータｓｄを取得対象としてもよく、発信元／発信先が特定の内線であるストリームデータｓｄとしてもよい。
【０１１５】
合致するデータがない場合（ステップＳ４３０３：Ｎｏ）、ステップＳ４３０２に戻る。一方、合致するデータがある場合（ステップＳ４３０３：Ｙｅｓ）、合致するデータを取得キューに格納して（ステップＳ４３０４）、ステップＳ４３０２に戻る。ステップＳ４３０２において、終了条件に該当する場合（ステップＳ４３０２：Ｙｅｓ）、ステップＳ４３０１に戻り、開始条件を待ち受ける。
【０１１６】
（ストリーム統合処理）
図４４は、図４０に示したストリーム統合処理（ステップＳ４００７）の詳細な処理手順を示すフローチャートである。まず、取得キューにデータがあるか否かを判断する（ステップＳ４４０１）。データがある場合（ステップＳ４４０１：Ｙｅｓ）、取得キューから先頭データを取得する（ステップＳ４４０２）。取得が失敗した場合（ステップＳ４４０３：Ｎｏ）、エラー出力をおこなって（ステップＳ４４０４）、ステップＳ４４０１に戻る。一方、取得が成功した場合（ステップＳ４４０３：Ｙｅｓ）、ＰＵＳＨ型情報統合処理を実行する（ステップＳ４１０５）。
【０１１７】
そして、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）が失敗した場合（ステップＳ４４０５：Ｎｏ）、エラー出力をおこなって（ステップＳ４４０４）、ステップＳ４４０１に戻る。
【０１１８】
一方、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）が成功した場合（ステップＳ４４０５：Ｙｅｓ）、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）で得られたデータを統合結果として出力し（ステップＳ４４０６）、ステップＳ４４０１に戻る。ここで統合結果の出力処理（ステップＳ４４０６）は、事前設定情報によって論理モデルＬに割り付けられている出力先がデータストリームに割り付けられている場合には、送出機能１４３によって該当するデータストリームに送出される。一方、ファイルやデータベースの場合には、登録機能１４１によって統合結果が該当するファイルやデータベースに登録される。ステップＳ４４０１において、取得キューにデータがない場合（ステップＳ４４０１：Ｎｏ）、ストリーム統合処理（ステップＳ４００７）を終了する。
【０１１９】
このように、物理統合処理とストリーム統合処理では、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）が共通して実行される。したがって、物理統合とストリーム統合を同一の処理系（統合エンジン１０１）で実現することができる。
【０１２０】
（ＰＵＳＨ型情報統合処理）
図４５は、図４１および図４４に示したＰＵＳＨ型情報統合処理（ステップＳ４１０５）の詳細な処理手順を示すフローチャートである。まず、取得された統合指示情報の＜ＯＵＴ＞タグで指定された論理モデルＬのマッピング定義ＭＤを初期化する（ステップＳ４５０１）。具体的には、＜ＯＵＴ＞タグで指定された論理モデルＬのマッピング定義ＭＤを取得し、解決フラグをクリアする。そして、統合指示情報内の＜ＩＮ＞タグで指定されたすべての物理モデルＰで解決される項目について解決フラグを“１”にする。
【０１２１】
つぎに、ＰＵＳＨコールフラグＦｐｃをＦｐｃ＝１とする（ステップＳ４５０２）。ＰＵＳＨコールフラグＦｐｃは、マッピング定義ＭＤがステップＳ４５０１において初期化済みであることをＰＵＬＬ型情報統合処理（ステップＳ４２０１）に通知するためのフラグである。Ｆｐｃ＝１の場合、初期化済みである。
【０１２２】
このあと、未処理の入力データをポイントして（ステップＳ４５０３）、対象データ反映処理を実行する（ステップＳ４５０４）。たとえば、入力データとして表Ｂをポイントすると、ポイントされた表Ｂについて、対象データ反映処理を実行する。対象データ反映処理（ステップＳ４５０４）は、ＰＵＳＨ型情報統合処理に入力された１つの物理モデルに該当するデータに応じて、論理モデルに統合結果を反映できる項目、すなわち、入力された対象データが持つ項目のうち解決フラグが“１”であるデータの項目を論理モデルＬにコピーする処理である。
【０１２３】
そして、対象データ反映処理（ステップＳ４５０４）が成功したか否かを判断する（ステップＳ４５０５）。失敗した場合（ステップＳ４５０５：Ｎｏ）、ＰＵＬＬ型情報統合処理を実行しないで処理失敗としてＰＵＳＨ型情報統合処理（ステップＳ４１０５）を終了する。成功した場合（ステップＳ４５０５：Ｙｅｓ）、未処理の物理モデルに対応する入力データが存在するか確認する（ステップＳ４５０６）。未処理の入力データが存在する場合（ステップＳ４５０６：Ｙｅｓ）、ステップＳ４５０３に戻って、未処理の入力データに対する処理を実行する。
【０１２４】
未処理の入力データが存在しない場合（ステップＳ４５０６：Ｎｏ）、つぎに、未解決のマッピング定義（厳密には後述する末端列をＦＲＯＭ列に持つマッピング定義）が有るか確認する（ステップＳ４５０７）。未解決のマッピング定義がある場合（ステップＳ４５０７：Ｙｅｓ）だけ、ＰＵＬＬ型情報統合処理を実行する（ステップＳ４２０１）。これにより、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）を終了する。一方、未解決のマッピング定義がない場合（ステップＳ４５０７：Ｎｏ）、終了する。
【０１２５】
このように、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）には、入力されたデータだけでは情報が不足する場合には、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）を呼ぶことができる。したがって、物理統合処理、仮想統合処理およびストリーム統合処理では、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）が共通して実行できる。これにより、物理統合、仮想統合およびストリーム統合を同一の処理系（統合エンジン１０１）で実現することができる。
【０１２６】
（ＰＵＬＬ型情報統合処理）
図４６は、図４２および図４５に示したＰＵＬＬ型情報統合処理（ステップＳ４２０１）の詳細な処理手順を示すフローチャートである。まず、図４２の検索条件抽出処理（ステップＳ４２００）で抽出した検索条件や、図４５の対象データ反映処理（ステップＳ４５０４）の処理結果を引き継いで、問合わせ分解処理を実行する（ステップＳ４６０１）。
【０１２７】
この問合わせ分解処理（ステップＳ４６０１）では、問合わせが指定されていない場合は、処理中の論理モデルから論理モデルＬの問合わせを生成し、論理モデルＬで表現された問合わせ（検索式）を物理モデルＰに対する問合わせ（検索式）に分解する。具体的には、論理モデルＬに対する問合わせ文（検索式）、すなわち、問合わせ文の検索条件と問合わせ対象に関するマッピング定義ＭＤにより、論理モデルＬに対する問合わせ文（検索式）を分解して、物理モデルＰに対する問合わせ文（検索式）を作成する。これにより、物理モデルＰ毎に情報源１１０にアクセスすることができる。
【０１２８】
問合わせ分解処理（ステップＳ４６０１）では物理モデルＰの検索式が０個以上作成されるため、作成された先頭の物理モデルＰの検索式を指定する（ステップＳ４６０２）。検索式が０個のケースもあるため、最初に処理すべき物理モデルＰの検索式があるか否かを判断する（ステップＳ４６０３）。物理モデルＰの検索式がない場合（ステップＳ４６０３：Ｎｏ）、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）を終了する。一方、物理モデルＰの検索式がある場合（ステップＳ４６０３：Ｙｅｓ）、指定された検索式を実行して物理モデルから対象データを検索する（ステップＳ４６０４）。検索が失敗した場合（ステップＳ４６０５：Ｎｏ）、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）を終了する。一方、検索が成功した場合（ステップＳ４６０５：Ｙｅｓ）、対象データ反映処理を実行する（ステップＳ４５０４）。
【０１２９】
対象データ反映処理（ステップＳ４５０４）は、上述したように、処理中の検索式の結果データについて、解決フラグが“１”であるデータを論理モデルＬにコピーする処理である。そして、対象データ反映処理（ステップＳ４５０４）が成功したか否かを判断する（ステップＳ４６０６）。失敗した場合（ステップＳ４６０６：Ｎｏ）、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）を終了する。
【０１３０】
一方、成功した場合（ステップＳ４６０６：Ｙｅｓ）、つぎの検索式を指定する（ステップＳ４６０７）。そして、ステップＳ４６０３に戻り、検索式の存在チェックを実行する。
【０１３１】
（問合わせ分解処理その１）
図４７は、図４６に示した問合わせ分解処理（ステップＳ４６０１）の詳細な処理手順を示すフローチャートである。問合わせ分解処理とは、上述したように、論理モデルに対する問合わせを物理モデルに対する問合わせに分解する処理である。また、問合わせが指定されていない場合は、処理中の論理モデルから論理モデルＬに対する問合わせを生成し、論理モデルＬに対する問合わせを物理モデルＰに対する問合わせに分解する処理である。別の説明としては、たとえば図１１に示す論理モデルＬＥの従業員番号に対する問合わせを、マッピング定義ＭＤ（Ｅ）に基づいて矢印を逆にたどることで、末端の物理モデルＰＡ，ＰＢに対する問合わせに分解する処理である。
【０１３２】
ここでは、例として、図４２に示した仮想統合処理（ステップＳ４００６）から呼び出されたＰＵＬＬ型情報統合処理（ステップＳ４２０１）において、問合わせ分解処理（ステップＳ４６０１）に与えられた問合わせとなる検索条件、すなわち、ＰＵＳＨコールフラグＦｐｃの値が“０”であるときの問合わせを、つぎの検索式として説明する。
【０１３３】
Ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  表Ｅ  Ｗｈｅｒｅ  従業員番号＝７００２
【０１３４】
この場合、検索対象は論理モデルＬＥの従業員番号「表Ｅ．従業員番号」であり、検索条件は「７００２」である。図５０、図９６〜図９８に、この例における問合わせ分解処理の経緯を示す。
【０１３５】
まず、ＰＵＳＨコールフラグＦｐｃの値が“１”であるか“０”であるかを判断する（ステップＳ４７０１）。
【０１３６】
この例では、ＰＵＳＨコールフラグＦｐｃは“０”なので、（ステップＳ４７０１：０）、検索条件に指定された論理モデルＬ（表Ｅ）は初期化されていないこととなる。したがって、検索条件に指定された論理モデルＬのマッピング定義ＭＤを取得し、解決フラグをクリアする（ステップＳ４７０３）。上述した検索式の場合、表Ｅ（論理モデルＬＥ）が指定されているため、マッピング定義ＭＤ（Ｅ）を取得することとなる。
【０１３７】
図５０は、ステップＳ４７０３でのマッピング定義ＭＤ（Ｅ）を示す説明図である。ステップＳ４７０３では解決フラグをクリアする(“０”を設定する)ことによって初期化を行い、つぎに入力された検索式からつぎの検索条件を抽出する。
【０１３８】
表Ｅ．従業員番号＝７００２
【０１３９】
また、ステップＳ４７１１では、抽出した検索条件を、マッピング定義の列に関連付ける（ステップＳ４７１１）。図９６では、マッピング定義ＭＤ（Ｅ）について、Ｔｏ列が「表Ｅ．従業員番号」の行（１），（２）に検索条件「＝７００２」を関連付けている。
【０１４０】
つぎに、マッピング定義ＭＤのＴｏ列を最上位の行から検索して、検索条件で指定されている列に対する最初のＦｒｏｍ列を求める（ステップＳ４７０４）を実行する。この際、解決フラグが“１”である行はスキップする。
【０１４１】
図９６は、問合わせ分解処理（ステップＳ４６０１）の動作例１における初期化時（ステップＳ４７０３処理後）のマッピング定義を示す説明図である。図９６に示したマッピング定義ＭＤ（Ｅ）では、１行目（１）のＴｏ列は「表Ｅ．従業員番号」であるため、検索条件で指定されている列となる。したがって、マッピング定義（１）のＦｒｏｍ列の「表Ａ．従業員番号」を求めることとなる。
【０１４２】
Ｆｒｏｍ列が求まった後、検索条件のクレンジング処理を実行する（ステップＳ４７０５）。検索条件のクレンジング処理（ステップＳ４７０５）では、検索条件に指定されている値（たとえば「表Ｅ．従業員番号＝７００２」）について、そのデータ型および型属性をクレンジング処理のＦｒｏｍ型に設定する。
【０１４３】
また、ステップＳ４７０４で求めたＦｒｏｍ列である「表Ａ．従業員番号」のデータ型および型属性をクレンジング処理のＴｏ型に設定して、クレンジング処理（ステップＳ４７０５）が実行される。結果として、「表Ｅ．従業員番号」の検索条件として与えられた検索条件の値をクレンジング（変換）して「表Ａ．従業員番号」の検索条件値が設定される。なお、検索条件のクレンジング処理（ステップＳ４７０５）の詳細については後述する。
【０１４４】
検索条件のクレンジング処理（ステップＳ４７０５）のあと、該当するＦｒｏｍ列（たとえば、「表Ａ．従業員番号」）を検索対象として、クレンジング結果を検索条件とする検索式を作成する（ステップＳ４７０８）。
【０１４５】
つぎに、クレンジングの結果を設定したＦｒｏｍ列（このケースでは「表Ａ．従業員番号」）が末端列であり、ＭＫｅｙ項目であるか否かを判断する（ステップＳ４７０６）。ここで、マッピング定義ＭＤにおける末端列とは、Ｔｏ列に同じ表の列が存在しない列（オリジナルのＦｒｏｍ列）を意味する。
【０１４６】
たとえば、図１１および図４９、図５０に示すマッピング定義ＭＤ（Ｅ）において、１行目（１）のＦｒｏｍ列である「表Ａ．従業員番号」について末端列であるか判定すると、Ｔｏ列には「表Ａ」の列は存在しないので末端列であると判定される。一方、５行目（５）のＦｒｏｍ列である「表Ｄ．名称」について末端列であるか判定すると、「表Ｄ」は３行目（３）のＴｏ列に「表Ｄ．所属」が存在するので、末端列ではないと判定される。
【０１４７】
この場合、再度「表Ｄ．所属」（３行目のＴｏ列）の検索式を導出して最終的には末端列である「表Ｂ．所属」（３行目のＦｒｏｍ列）の検索式を導出する必要がある。ちなみに、図１１のマッピング定義ＭＤ（Ｅ）において、末端列でないのは５行目（５）の「表Ｄ．名称」だけであり、他の行である（１）〜（４）のＦｒｏｍ列はすべて末端列である。
【０１４８】
このステップＳ４７０６において、該当するＦｒｏｍ列（たとえば、「表Ａ．従業員番号」）が末端列であり、かつＭＫｅｙ項目である場合（ステップＳ４７０６：Ｙｅｓ）、つぎに、作成された検索式で解決できるマッピング定義ＭＤの行に解決フラグを立てる（ステップＳ４７０９）。
【０１４９】
図９７は、問合わせ分解処理（ステップＳ４６０１）の動作例１における１回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。たとえば、図９７の第１回目の処理で生成された検索式９７００では、結果として表Ａのレコードを取得できるので、図１１に示したマッピング定義において、表Ａのレコードが持つ項目をＦｒｏｍ列に持つ（１）および（４）に対応するマッピングがこの検索により解決されるマッピング定義となる。したがって、図９７のマッピング定義は、１行目（１）と４行目（４）の解決フラグを“１”に設定できる。
【０１５０】
ステップＳ４７０９のあと、Ｆｒｏｍ列が末端列であるマッピング定義ＭＤに未解決（解決フラグが“０”）があるか否かを判断する（ステップＳ４７１０）。ここで、末端列に未解決がある場合（ステップＳ４７１０：Ｙｅｓ）、ステップＳ４７１１に戻る。
【０１５１】
図９８は、問合わせ分解処理（ステップＳ４６０１）の動作例１における２回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。図９８に示すように、ステップＳ４７０４〜Ｓ４７１０を繰り返し実行して残りの検索式９８００を生成する。ステップＳ４７１０において、末端列に未解決がない場合（ステップＳ４７１０：Ｎｏ）、問合わせ分解処理を終了する。この時点では、図９８に示すように、末端列を持つマッピング定義の解決フラグはすべて“１”、すなわち、解決済になっており、図５１に示すように作成された問合わせ文（検索式）は、その情報統合に必要な物理モデルに対する検索式に分解されて、導出されている。
【０１５２】
（問合わせ分解処理その２）
図４７の問合わせ分解処理について、ＰＵＳＨコールフラグＦｐｃの値が"１"であるときの処理、すなわち、図４５のＰＵＳＨ型情報統合処理から図４６のＰＵＬＬ型情報統合処理が呼ばれた場合の、問合わせ分解処理（ステップＳ４６０１）を、図４８に示す統合結果情報Ｅ、図４９に示すマッピング定義ＭＤ（Ｅ）の状態からの処理を例にして説明する。
【０１５３】
図４７において、まず、ＰＵＳＨコールフラグＦｐｃの値が“１”なので（ステップＳ４７０１：１）、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）において、論理モデルＬのマッピング定義ＭＤは初期化されており（ステップＳ４５０１）、かつ、対象データ反映処理（ステップＳ４５０４）が実行されて、統合結果情報に値が設定されている。
【０１５４】
したがって、このＰＵＳＨ型情報統合処理での対象データ反映処理（ステップＳ４５０４）で得られた統合結果情報から結果集合の値を、次段のステップで物理モデルＰの検索式を作成するための検索条件として抽出する（ステップＳ４７０２）。
【０１５５】
ここで、図４８は、ステップＳ４７０２での統合結果集合Ｅを示す説明図であり、図４９は、ステップＳ４７０２でのマッピング定義ＭＤ（Ｅ）を示す説明図である。すなわち、ステップＳ４７０２の開始時点で、統合結果集合Ｅには、表Ｅ．従業員番号の値として、「７００１」，「７００２」，「７００３」を持ち、表Ｅ．氏名の値として「田中一郎」，「鈴木次郎」，「佐藤三郎」が存在している。このときのマッピング定義は、これらの値の列（表Ｅ．従業員番号、表Ｅ．氏名）に対応する解決フラグは“１”となっている。なお、これらの値を検索条件として抽出するとつぎのようになる。
【０１５６】
表Ｅ．従業員番号＝７００１
表Ｅ．従業員番号＝７００２
表Ｅ．従業員番号＝７００３
表Ｅ．氏名＝田中一郎
表Ｅ．氏名＝鈴木次郎
表Ｅ．氏名＝佐藤三郎
【０１５７】
図９９は、問合わせ分解処理（ステップＳ４６０１）の動作例２における初期化時（ステップＳ４７０２処理後）のマッピング定義を示す説明図である。図９９は、つぎのステップＳ４７１１で、抽出した検索条件をマッピング定義に関連付けた例を示している。マッピング定義のＴｏ列が検索対象の項目「表Ｅ．従業員番号」と一致する１行目（１）と２行目（２）について検索条件値「＝７００１、＝７００２、＝７００３」が関連付けられている。また、検索対象項目「表Ｅ．氏名」と一致する４行目（４）検索条件値「＝田中一郎、＝鈴木次郎、＝佐藤三郎」が関連付けられている。
【０１５８】
つぎに、ステップＳ４７０４では、マッピング定義ＭＤのＴｏ列を最上位の行から検索して、検索条件と関連付けられている最初のＦｒｏｍ列を求める処理を実行する。この際、解決フラグが“１”である行はスキップする。
【０１５９】
たとえば、図９９に示したマッピング定義ＭＤ（Ｅ）では、１行目（１）は解決フラグが“１”であるため、スキップされる。そして、２行目（２）のＴｏ列は「表Ｅ．従業員番号」であり、検索条件も関連付けられているので、マッピング定義（２）のＦｒｏｍ列の「表Ｂ．従業員番号」を求めることとなる。ここで、関連付けられている検索条件はつぎの３件である。
【０１６０】
表Ｅ．従業員番号＝７００１
表Ｅ．従業員番号＝７００２
表Ｅ．従業員番号＝７００３
【０１６１】
つぎに、検索条件のクレンジング処理を実行する（ステップＳ４７０５）。検索条件のクレンジング処理（ステップＳ４７０５）では、検索条件に指定されている値（たとえば、「表Ｅ．従業員番号」）について、そのデータ型および型属性をクレンジング処理のＦｒｏｍ型に設定する。
【０１６２】
また、ステップＳ４７０４で求めたＦｒｏｍ列である「表Ｂ．従業員番号」のデータ型および型属性をクレンジング処理のＴｏ型に設定して、クレンジング処理（ステップＳ４７０５）が実行される。結果として、「表Ｅ．従業員番号」の検索条件として与えられた検索条件の値をクレンジング（変換）して「表Ｂ．従業員番号」の検索条件値が設定される。なお、検索条件のクレンジング処理（ステップＳ４７０５）の詳細については後述する。
【０１６３】
つぎに、該当するＦｒｏｍ列（たとえば、「表Ｂ．従業員番号」）を検索対象として、クレンジング結果を検索条件とするつぎの検索式を作成する（ステップＳ４７０８）。
【０１６４】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００１
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００２
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００３
【０１６５】
つぎに、クレンジングの結果を設定したＦｒｏｍ列（このケースでは「表Ｂ．従業員番号」）が末端列であり、ＭＫｅｙ項目であるか否かを判断する（ステップＳ４７０６）。
【０１６６】
この例では、「表Ｂ．従業員番号」は末端列であり、ＭＫｅｙ項目なので（ステップＳ４７０６：Ｙｅｓ）、作成された検索式で解決できるマッピング定義ＭＤの行に解決フラグを立てる（ステップＳ４７０９）。
【０１６７】
図１００は、問合わせ分解処理（ステップＳ４６０１）の動作例２における１回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。図１００において、符号１００００は作成された検索式である。ここでは、図１００に示すように、２行目（２）と３行目（３）がこの検索式により解決されるマッピング定義となり、解決フラグを“１”に設定する。
【０１６８】
つぎに、Ｆｒｏｍ列が末端列であるマッピング定義ＭＤに未解決（解決フラグが“０”）があるか否かを判断する（ステップＳ４７１０）。ここでは、図１００は末端列でない（５）を除いてすべての末端列が解決済になっている（ステップＳ４７１０：Ｎｏ）ので、問合わせ分解処理が完了する。
【０１６９】
（問合わせ分解処理その３）
ここで、問合わせ分解処理（ステップＳ４６０１）への入力がつぎの検索式である例を用いて、図４７のステップＳ４７０７以降の動作を中心に図１０１〜図１０５により説明する。
【０１７０】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｅ  Ｗｈｅｒｅ  所属＝営業部
【０１７１】
図１０１は、問合わせ分解処理（ステップＳ４６０１）の動作例３における初期化時（ステップＳ４７０３処理後）のマッピング定義を示す説明図である。図１０１では、図４７のステップＳ４７１１により最初の検索条件が設定された状態を示している。マッピング定義の５行目（５）に検索条件「＝製造部」が設定されている。このとき、ステップＳ４７０４では、Ｆｒｏｍ列として「表Ｄ．名称」が求められ、ステップＳ４７０５で値のクレンジングが行われて、ステップＳ４７０８でつぎの検索式が作成される。
【０１７２】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｄ  Ｗｈｅｒｅ  名称＝営業部
【０１７３】
つぎに、ステップＳ４７０６で、そのＦｒｏｍ列「表Ｄ．名称」が末端列で、ＭＫｅｙ項目であるか、判定する。この例では、「表Ｄ．名称」は末端列でないので（ステップＳ４７０６：Ｎｏ）、作成した検索式を実行する（ステップＳ４７０７）。ここでは、たとえば物理モデルＰＤに割り当てられているＲＤＢ３の表３の検索を行い、その結果を図１０２のように求める。つぎに、実行結果から検索条件を抽出する（ステップＳ４７１２）。
【０１７４】
図１０２は、問合わせ分解処理（ステップＳ４６０１）の動作例３における１回目の検索式実行（ステップＳ４７０７処理後）のマッピング定義を示す説明図である。ここでは、図１０２に示すように、「表Ｄ．所属＝１０１」を抽出して、ステップＳ４７１１に戻り、抽出した検索条件をマッピング定義に関連付ける。具体的には、図１０２に示すように、Ｔｏ列に検索対象の項目「表Ｄ．所属」が含まれる３行目（３）に「＝１０１」を関連付ける。
【０１７５】
図１０３は、問合わせ分解処理（ステップＳ４６０１）の動作例３における２回目の検索式実行（ステップＳ４７０７処理後）のマッピング定義を示す説明図である。同様に２回目のステップＳ４７０６では、図１０３に示すように、つぎの検索式が生成され、Ｆｒｏｍ項目「表Ｂ．所属」が判定される。
【０１７６】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  所属＝１０１
【０１７７】
「表Ｂ．所属」は末端列であるが、ＭＫｅｙ項目で無いので、ステップＳ４７０７に進み、図１０３に示すように検索式が実行されてその結果から検索条件を抽出し、マッピング定義の１行目（１）、２行目（２）に関連付けられる。
【０１７８】
図１０４は、問合わせ分解処理（ステップＳ４６０１）の動作例３における３回目の検索式作成（ステップＳ４７０７処理後）のマッピング定義を示す説明図である。つぎの３回目のステップＳ４７０６では、図１０４に示すように、つぎの検索式１０４００が生成され、Ｆｒｏｍ項目「表Ａ．従業員番号」が判定される。
【０１７９】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ａ  Ｗｈｅｒｅ  従業員番号＝７００１
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ａ  Ｗｈｅｒｅ  従業員番号＝７００３
【０１８０】
「表Ａ．従業員番号」は末端列であり、ＭＫｅｙ項目なので、ステップＳ４７０９に進み、マッピング定義の１行目（１）、４行目（４）の解決フラグに”１“が設定される。
【０１８１】
図１０５は、問合わせ分解処理（ステップＳ４６０１）の動作例３における４回目の検索式作成（ステップＳ４７０９処理後）のマッピング定義を示す説明図である。つぎの４回目のステップＳ４７０６では、図１０５に示すように、つぎの検索式１０５００が生成され、Ｆｒｏｍ項目「表Ｂ．従業員番号」が判定される。
【０１８２】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００１
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００３
【０１８３】
「表Ｂ．従業員番号」は末端列であり、ＭＫｅｙ項目なので、ステップＳ４７０９に進み、マッピング定義の２行目（２）、３行目（３）の解決フラグに”１“が設定される。
【０１８４】
ここで、つぎのステップＳ４７１０では、すべての末端列の解決フラグに”１“が設定できたので、問合わせ分割処理は完了し、つぎの検索式が分割結果となる。
【０１８５】
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ａ  Ｗｈｅｒｅ  従業員番号＝７００１
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ａ  Ｗｈｅｒｅ  従業員番号＝７００３
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００１
Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００３
【０１８６】
（対象データ反映処理）
図５２は、図４５および図４６に示した対象データ反映処理（ステップＳ４５０４）の詳細な処理手順を示すフローチャートである。まず、現在指定されている抽出結果から選ばれた対象データが論理モデルＬに直接反映可能か否かを判断する（ステップＳ５２０１）。すなわち、テーブル変換処理（ステップＳ５２０２）が必要か否かを判断する。たとえば、図１０に示したように、物理モデルＰＡの項目と論理モデルＬＣの項目がそれぞれ直接対応していれば、直接反映可能となる。
【０１８７】
一方、図１１に示した物理モデルＰＢの所属項目のように、論理モデルＬＥとの間で物理モデルＰＤを介して対応付けている場合、物理モデルＰＢの所属項目と論理モデルＬＥとは直接対応していないこととなる。このような場合は、直接反映不可となる。
【０１８８】
図５２において、直接反映不可である場合（ステップＳ５２０１：Ｎｏ）、テーブル変換処理を実行して（ステップＳ５２０２）、ステップＳ５２０１に戻る。すなわち、論理モデルＬに直接反映可能となるまでテーブル変換処理（ステップＳ５２０２）を実行することとなる。テーブル変換処理（ステップＳ５２０２）の詳細は後述する。
【０１８９】
論理モデルＬに直接反映可能となった場合（ステップＳ５２０１：Ｙｅｓ）、クレンジング処理（ステップＳ５２０３）と結果反映処理（ステップＳ５２０４）を実行する。クレンジング処理（ステップＳ５２０３）ではコピー元のデータ型または型属性とコピー先のデータ型または型属性が異なる場合にコピー元をコピー先に一致するように変換処理をおこなう。また、結果反映処理（ステップＳ５２０４）では、データを論理モデルＬにコピーする。
【０１９０】
クレンジング処理（ステップＳ５２０３）と結果反映処理（ステップＳ５２０４）の詳細は後述する。そして、成功したか否かを判断する（ステップＳ５２０５）。失敗した場合（ステップＳ５２０５：Ｎｏ）、処理失敗として、対象データ反映処理（ステップＳ４５０４）を終了する。
【０１９１】
一方、成功した場合（ステップＳ５２０５：Ｙｅｓ）、抽出結果に未処理のデータがあるか否かを判断する（ステップＳ５２０６）。未処理のデータがある場合（ステップＳ５２０６：Ｙｅｓ）、つぎのデータを指定して（ステップＳ５２０７）、ステップＳ５２０１に戻る。一方、未処理のデータがない場合（ステップＳ５２０６：Ｎｏ）、処理成功として、対象データ反映処理（ステップＳ４５０４）を終了する。
【０１９２】
（テーブル変換処理）
図５３は、図５２に示したテーブル変換処理（ステップＳ５２０２）の詳細な処理手順を示すフローチャートである。まず、検索条件のクレンジング処理を実行する（ステップＳ４７０５）。検索条件のクレンジング処理（ステップＳ４７０５）の詳細は後述する。つぎに、検索条件のクレンジング処理（ステップＳ４７０５）が成功したか否かを判断する（ステップＳ５３０１）。
【０１９３】
失敗した場合（ステップＳ５３０１：Ｎｏ）、ステップＳ５２０１に移行できないので、処理失敗として対象データ反映処理（ステップＳ４５０４）を終了する。一方、成功した場合（ステップＳ５３０１：Ｙｅｓ）、中間テーブルを検索する（ステップＳ５３０２）。中間テーブルとは、物理モデルＰと論理モデルＬとの間に存在する物理モデルＰである。たとえば、図１１に示した物理モデルＰＤ、図１２に示した物理モデルＰＤ，ＰＴである。
【０１９４】
検索が失敗した場合（ステップＳ５３０３：Ｎｏ）、ステップＳ５２０１に移行できないので、処理失敗として対象データ反映処理（ステップＳ４５０４）を終了する。一方、検索が成功した場合（ステップＳ５３０３：Ｙｅｓ）、ポイントしている値を検索結果で置き換え（ステップＳ５３０４）、ステップＳ５２０１に移行する。具体的には、図１１を例に挙げると、物理モデルＰＢの属性「所属」をポイントしている場合、その従属先である物理モデルＰＤが中間テーブルとして検索される。
【０１９５】
物理モデルＰＤは、物理モデルＰＢの属性「所属」の従属先となる属性「所属」と「所属」に対応する属性「名称」がある。したがって、物理モデルＰＢの「所属」を、物理モデルＰＤの「名称」に置き換える。置き換え後の属性「名称」は、論理モデルＬＥの属性「所属」に直接マッピングしているため、直接反映可能となる。
【０１９６】
（検索条件のクレンジング処理）
図５４は、図４７および図５３に示した検索条件のクレンジング処理（ステップＳ４７０５）の詳細な処理手順を示すフローチャートである。まず、与えられた検索条件について、そのデータ型および型属性をクレンジング元の性質を示すＦｒｏｍ型に設定し、検索対象の列についても、そのデータ型および型属性をクレンジング先の性質を示すＴｏ型に設定する（ステップＳ５４０１）。つぎに、クレンジング処理を実行する（ステップＳ５２０３）。クレンジング処理（ステップＳ５２０３）の詳細は後述する。そして、クレンジング処理が成功したか否かを判断する（ステップＳ５４０２）。ここで、クレンジング処理が失敗した場合（ステップＳ５４０２：Ｎｏ）、処理失敗として検索条件のクレンジング処理（ステップＳ４７０５）を終了する。
【０１９７】
一方、クレンジング処理が成功した場合（ステップＳ５４０２：Ｙｅｓ）、クレンジング結果の値（Ｔｏ値）をＴｏ型のデータ型および型属性とともに、クレンジング結果としての検索条件に設定して（ステップＳ５４０３）、検索条件のクレンジング処理（ステップＳ４７０５）を正常終了する。これにより、異なるデータモデル間における検索条件のクレンジング（変換）を実現することができるので、図４７に示した問合わせ（検索式）の分解や、図５３に示した中間テーブルの検索に必要な検索式の生成で使用される。
【０１９８】
（クレンジング処理）
クレンジング処理とは、複写元（Ｆｒｏｍ型にデータ型および型属性を規定）から複写先（Ｔｏ型にデータ型および型属性を規定）への値の複写が発生するときにおいて、双方のデータ型および型属性のチェックを実行し、複写元（Ｆｒｏｍ型）と複写先（Ｔｏ型）の間でデータ型または型属性が異なっている場合に、複写元（Ｆｒｏｍ型）の形式を複写先（Ｔｏ型）の形式にあわせるために必要なデータ型変換や型属性の変換を実行する処理である。この処理により、データ型や型属性が異なる項目の間でも値の複写が可能になる。
【０１９９】
図５５は、型属性の違いによるクレンジングの一例を示す図である。図５５において、双方のデータ型はＳｔｒｉｎｇ（文字列型）で一致しているが、型属性が異なるため、Ｆｒｏｍ型の型属性（ＣｈａｒＣｏｄｅ＝ＪＥＦ）からＴｏ型の型属性（ＣｈａｒＣｏｄｅ＝Ｓ＿ＪＩＳ）に変換するために、ＪＥＦからシフトＪＩＳへ文字コード系を変換するクレンジング処理を実行し、その結果を複写先にコピーする。
【０２００】
文字列型の型属性が異なるときに実行されるクレンジングとしては、上述した文字コード系変換以外にも、たとえば、文字列変換がある。具体的には、全空白除去、前後の空白除去、連続空白を１個に集約、タブ／空白変換、改行コード除去、改行コード変換、全角／半角変換、英大文字／英小文字変換、文字の置き換え（置き換えテーブルを使用）などがある。
【０２０１】
また、他のクレンジング機能としては、単位の変換（３千円から３，０００円へ、あるいはその逆）（文字列型／数値型）、年号表記（平成１６年から２００４年へ、あるいはその逆）（文字列型／数値型）、漢数字表記（十六から１６へ、あるいはその逆）（文字列型／数値型）、有効桁変換（数値型、有効桁数の増加あるいは減少）、有効文字数変換（文字列型、有効文字数の増加あるいは減少）などがある。
【０２０２】
図５６は、データ型が異なるときに実行されるクレンジング機能の一例を示す図である。図５６において、Ｓｔｒｉｎｇ（文字列型）であって、ＪＥＦコード文字列「“２０００”」（すべて全角で４文字）のデータを、文字列から整数（Ｉｎｔｅｇｅｒ）に変換するとともに、１０桁以内の整数に変換するクレンジング処理を実行する。それによって、「２０００」（４桁の整数）のデータに変換する。
【０２０３】
このように、実施の形態にかかる情報統合装置は、データ値の変換として、文字コード系の違いを変換する文字コード系変換処理、空白除去、全角半角変換を含む文字列の正規化をおこなう文字列変換処理、文字や数字の単位の違いを変換する単位変換処理、年号の西暦・和暦の違いを変換する年号表記変換処理、数字表現として漢数字／アラビア数字／ローマ数字と数値の違いを変換する漢数字表記変換処理、数字の有効桁を揃える有効桁変換処理、データ型間の変換処理の少なくともいずれか一つを必要によりおこなうことができる。
【０２０４】
図５７は、図５２および図５４に示したクレンジング処理（ステップＳ５２０３）の詳細な処理手順を示すフローチャートである。まず、クレンジング元の性質を示すＦｒｏｍ型とクレンジング先の性質を示すＴｏ型について、データ型が同じであるか否かを判断する（ステップＳ５７０１）。ここで、両者が同じデータ型である場合（ステップＳ５７０１：Ｙｅｓ）、Ｆｒｏｍ型とＴｏ型に共通する先頭の型属性を指定する（ステップＳ５７０２）。
【０２０５】
つぎに、型属性の値が同じか否かを判断する（ステップＳ５７０３）。ここで、型属性の値が同じ場合（ステップＳ５７０３：Ｙｅｓ）、Ｆｒｏｍ型とＴｏ型に共通するつぎの型属性を指定する（ステップＳ５７０４）。そして、未処理の型属性が未だあるか否かを判断する（ステップＳ５７０５）。未処理の型属性がある場合（ステップＳ５７０５：Ｙｅｓ）、ステップＳ５７０３へ戻って、以後ステップＳ５７０３〜Ｓ５７０５を繰り返し実行する。そして、未処理の型属性がなくなった場合（ステップＳ５７０５：Ｎｏ）、一連のクレンジング処理（ステップＳ５２０３）を正常に終了する。
【０２０６】
また、ステップＳ５７０１において、Ｆｒｏｍ型とＴｏ型のデータ型が異なる場合（ステップＳ５７０１：Ｎｏ）、該当するデータ型変換機能があるか否かを判断する（ステップＳ５７０６）。該当するデータ型変換機能がない場合（ステップＳ５７０６：Ｎｏ）、クレンジング失敗処理をして、クレンジング処理（ステップＳ５２０３）を終了する。
【０２０７】
一方、該当するデータ型変換機能がある場合（ステップＳ５７０６：Ｙｅｓ）、該当するデータ型変換処理を実行する（ステップＳ５７０７）。そして、データ型変換処理が成功したか否かを判断する（ステップＳ５７０８）。ここで、データ型変換処理が成功した場合（ステップＳ５７０８：Ｙｅｓ）、ステップＳ５７０２へ移行する。一方、データ型変換処理が失敗した場合（ステップＳ５７０８：Ｎｏ）、クレンジング失敗処理をして、クレンジング処理（ステップＳ５２０３）を終了する。
【０２０８】
また、ステップＳ５７０３において、型属性の値が異なる場合（ステップＳ５７０３：Ｎｏ）、該当する型属性変換機能があるか否かを判断する（ステップＳ５７０９）。ここで、該当する型属性変換機能がない場合（ステップＳ５７０９：Ｎｏ）、クレンジング失敗処理をして、クレンジング処理（ステップＳ５２０３）を終了する。一方、該当する型属性変換機能がある場合（ステップＳ５７０９：Ｙｅｓ）、該当する型属性変換処理を実行する（ステップＳ５７１０）。
【０２０９】
そして、実行された型属性変換処理が成功したか否かを判断する（ステップＳ５７１１）。型属性変換処理が成功した場合（ステップＳ５７１１：Ｙｅｓ）、ステップＳ５７０４へ移行する。一方、型属性変換処理が失敗した場合（ステップＳ５７１１：Ｎｏ）、クレンジング失敗処理をして、クレンジング処理（ステップＳ５２０３）を終了する。
【０２１０】
（結果反映処理）
図５８は、図５２に示した結果反映処理（ステップＳ５２０４）の詳細な処理手順を示すフローチャートである。まず、反映元の項目（Ｆｒｏｍ側）からマッピングされている反映先の項目（Ｔｏ側）がＭＫｅｙ項目であるか否かを判断する（ステップＳ５８０１）。ＭＫｅｙ項目である場合（ステップＳ５８０１：Ｙｅｓ）、そのＭＫｅｙ項目について統合結果情報を検索してＦｒｏｍ側の値と一致するレコードがあるか否かを判断する（ステップＳ５８０２）。一致するレコードがあった場合（ステップＳ５８０２：Ｙｅｓ）、該当レコードを反映の対象レコード（反映先のレコード）とし（ステップＳ５８０３）、ステップＳ５２０５に移行する。
【０２１１】
すなわち、反映先の項目がＭＫｅｙ項目である場合において、既に統合結果情報に反映元と同じ値（ＭＫｅｙ）を持つレコードがあったときは、そのレコードを反映対象レコードとして設定するだけでつぎの反映処理に移る。
【０２１２】
一方、ステップＳ５８０２において、一致するレコードがない場合（ステップＳ５８０２：Ｎｏ）、統合結果情報に新規にレコードを生成して反映の対象レコードとする（ステップＳ５８０４）。そして、その対象レコードについてＴｏ側の項目に反映元の値を複製し（ステップＳ５８０５）、ステップＳ５２０５に移行する。
【０２１３】
また、ステップＳ５８０１において、Ｔｏ側がＭＫｅｙ項目でない場合（ステップＳ５８０１：Ｎｏ）、Ｆｒｏｍ側がＭＫｅｙ項目であるか否かを判断する（ステップＳ５８０６）。Ｆｒｏｍ側がＭＫｅｙ項目である場合（ステップＳ５８０６：Ｙｅｓ）、統合結果情報のＴｏ側項目をＦｒｏｍ側の値（主キー制約（ＭＫｅｙ））で検索して、一致するレコードがあるか否かを判断する（ステップＳ５８０７）。一致するレコードがあった場合（ステップＳ５８０７：Ｙｅｓ）、一致するレコードをすべて対象レコードとし（ステップＳ５８０８）、ステップＳ５２０５に移行する。
【０２１４】
一方、ステップＳ５８０６において、Ｆｒｏｍ側がＭＫｅｙ項目でない場合（ステップＳ５８０６：Ｎｏ）、統合結果情報に対象レコードが存在するか否かを判断する（ステップＳ５８０９）。ステップＳ５８０７において、一致するレコードがない場合（ステップＳ５８０７：Ｎｏ）も、統合結果情報に対象レコードが存在するか否かを判断する（ステップＳ５８０９）。
【０２１５】
対象レコードが存在しない場合（ステップＳ５８０９：Ｎｏ）、新規にレコードを生成して対象レコードとして（ステップＳ５８１０）、ステップＳ５８１１に移行する。一方、対象レコードが存在する場合（ステップＳ５８０９：Ｙｅｓ）、ステップＳ５８１１に移行する。ステップＳ５８１１では、統合結果情報の対象レコードについてＴｏ側の項目に値を複製し（ステップＳ５８１１）、ステップＳ５２０５に移行する。
【０２１６】
ここでステップＳ５８１０の「新規にレコードを生成して対象レコードとする」処理は、ＭＫｅｙ項目の反映よりも早い段階で、ＭＫｅｙ項目以外の項目を設定するケースで実行される処理であるが、図２２〜図２５で詳細に説明したように、マッピング定義はＭＫｅｙ項目を優先して処理するようにソートされているので、表構造を持つ論理モデルについては、ステップＳ５８１０が実行されるケースは無いと考えてよい。
【０２１７】
なお、前記の物理モデルや論理モデルは表構造で考えるのが判りやすいので、表構造を例にして説明しているが、必ずしも表構造である必要は無く、情報源や利用側も含めて、ＸＭＬに代表されるツリー構造や、その他のデータ構造または、その一部であってもよい。メタ情報（物理モデル、論理モデル、マッピング定義）に関する厳密な要件はつぎの４点である。
【０２１８】
・数値や文字、文字列などの値を項目として持ち、各項目の性質（データ型や型属性）を定めることができる。
・項目の集合（ここではレコードと呼んでいる）はＭＫｅｙ項目の値で一意に特定できるものであり、項目の配置（関連や位置）を定めることができる。
・同じ性質を持つレコードの集合を有し、名前などで一意に特定することができる。
・マッピング定義によって項目間の関連を定義できる。
【０２１９】
論理モデルＭがツリー構造である例について、図１０６〜図１１０によって説明する。この例で使用するツリー構造は、ＸＭＬ  Ｓｃｈｅｍａで示す構造とする。この「ＸＭＬ  Ｓｃｈｅｍａ」は、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）で標準化されている。
【０２２０】
図１０６は、ツリー構造の論理モデルＭに対応するＸＭＬ  Ｓｃｈｅｍａおよびデータ構造の例を示す説明図である。図１０６において、先頭ノード「Ｍ」の子ノードとして、通話記録を示す１つ以上の「ＤＴ」を持ち、「ＤＴ」ノードは、「ｉｄ」属性でユニークに特定される。また、「ＤＴ」ノードの子ノードとして、通話元を示す「ＦＲＯＭ」ノードと、通話先を示す「ＴＯ」ノードを持ち、「ＦＲＯＭ」ノードと「ＴＯ」ノードは、子ノードとして、「ＩＤ」ノードと「ＮＡＭＥ」ノードを持つ。ここで、「ＮＡＭＥ」ノードは省略可能である。
【０２２１】
図１０７は、ツリー構造の論理モデルＭに対応するメタ情報の一部について例を示す説明図である。図１０７では、このツリー構造を論理モデルＭとして使用する場合のメタ定義の一部を示している。ここで、物理モデルは図１８に示す「表Ｓ」、図１７に示す「表Ｔ」、図１６に示す「表Ｄ」を使用しているので省略してあるので、図１０７の論理モデルを、図１３〜図２１に示すメタ情報に、＜ＭＥＴＡ−ＤＡＴＡ＞の子要素として追加することによってメタ定義が完全になる。このときの論理モデルＭに関連するメタ情報の全体を以下に示す。
【０２２２】
図１０８は、図１０７の例について、関連するメタ情報の全体像を示す説明図である。図１０８では、図１０８におけるマッピング定義の（１）〜（６）は図１０７の＜ＭＡＰ＿ＲＵＬＥ＞の同じ番号と対応している。
【０２２３】
図１０７は、図２１とほぼ同じであるが、図２１の論理モデルＭは表構造であり、＜ＣＯＬＵＭＮ＞タグで指定されている項目は、指定順に一列に並んでおり、すべての項目をまとめて、レコードを構成している。一方、図１０７の論理モデルＭはツリー構造であるので、＜ＣＯＬＵＭＮ＞タグの「ｒｅｆ」属性によって、項目の位置を規定している。この「ｒｅｆ」属性は、ＸＭＬ  Ｓｃｈｅｍａにおける項目の位置を指定すればよいので、その仕様は、Ｗ３Ｃで標準化されているＸＭＬ Ｐａｔｈ  Ｌａｎｇｕａｇｅ（ＸＰａｔｈ）を用いることができる。
【０２２４】
すなわち、図１０７における「ＤＴ．ＩＤ」項目は、ＭＫｅｙ項目であり、その値は＜ＤＴ＞ノードの、「ｉｄ」属性に設定する。また、「ＦＲＯＭ．ＩＤ」項目は、ＭＫｅｙ項目である＜ＤＴ＞ノードの子ノードである「ＦＲＯＭ」ノードの更に子ノードである「ＩＤ」ノードである。
【０２２５】
同様に、「ＦＲＯＭ．ＮＡＭＥ」項目は、ＭＫｅｙ項目である＜ＤＴ＞ノードの子ノードである「ＦＲＯＭ」ノードの更に子ノードである「ＮＡＭＥ」ノードある。また、「ＴＯ．ＩＤ」項目は、ＭＫｅｙ項目である＜ＤＴ＞ノードの子ノードである「ＴＯ」ノードの更に子ノードである「ＩＤ」ノードであることを示している。
【０２２６】
この「ｒｅｆ」属性によって、各項目の位置関係が一意に定まるので、前記の情報統合装置で、表構造のデータモデルと同様に統合処理を行うことができる。
【０２２７】
図１０９は、ツリー構造の論理モデルＭに対するストリーム統合指示情報を示す説明図である。図１０９では、図１０６のメタ情報に対するストリーム統合指示の例を示している。ここでは、＜ＯＵＴ＞タグで指定されている論理モデル側（出力側）の出力条件がＳＱＬではなく、ツリー構造である論理モデルに合わせた形式になっている。
【０２２８】
この部分は、論理モデルに対する問合わせ文でよいので、ツリー構造である論理モデルに対しては、Ｗ３Ｃで標準化されている「ＸＱｕｅｒｙ」を使うことができる。このように、前記の問合わせ文は必ずしもＳＱＬである必要は無く、物理モデルまたは、論理モデルのデータモデルの性質によって親和性の良い問合わせ文を使うことができる。
【０２２９】
図１１０は、図１０９の論理モデルＭに対するストリーム統合指示による情報統合結果の例を示す説明図である。図１１０では、図１０６のメタ定義を使用する情報統合装置に対して、図１０９の統合指示を与えたときの論理モデルＭの統合結果例を示している。図１０９の＜ＩＮ＞タグで指定された情報源である表Ｓに対応するデータストリームから、ＴＯ＝２４２００に該当するストリームデータを、２０：２０〜２０：２２までの時間について取得を行い、情報統合装置の入力にする。
【０２３０】
情報統合装置では、後述の実施例３とほぼ同じ統合処理が行われ、図１０９の＜ＯＵＴ＞タグで指定された論理モデルＭのデータとして統合され、／／Ｍ／ＤＴ／ＦＲＯＭ／ＮＡＭＥ＝“営業部”に該当するデータだけが論理モデルＭに対応する出力先に出力される。そのとき図１１０に示すように、メタ定義のｒｅｆ属性によって一意に決まるツリー構造を持つ、図１０６に示すＸＭＬ  ＳｃｈｅｍａのＸＭＬとして出力される。
【実施例１】
【０２３１】
つぎに、実施例１について説明する。実施例１は、図３７に示した物理統合指示情報３７００が与えられた場合の物理統合処理（ステップＳ４００５）の実行例である。実施例１が前提とするメタ情報は図１１に示すモデルの範囲であり、図１４に示す物理モデルＰＡ、図１５に示す物理モデルＰＢ、図２０に示す論理モデルＬＥを組み合わせて使用する。以下、図５９〜図６５を用いて、上述したフローチャートと対応付けて説明する。
【０２３２】
図５９は、図４１のステップＳ４１０１による対象データの抽出例を示す説明図である。統合エンジン１０１は、物理統合指示情報３７００から＜ＩＮ＞タグで指定された検索式「Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ａ」を抽出条件５９００として抽出する。そして、抽出条件５９００により、表Ａに割り付けられているＲＤＢ１の表１から物理モデルＰＡに従って対象データ群（７００１〜７００３、田中一郎〜佐藤三郎、…）を抽出する。以下、抽出された対象データ群を抽出結果Ａとする。
【０２３３】
このあと、ステップＳ４１０４では、抽出結果Ａの先頭データとして、従業員番号：７００１である１レコード目のレコードを指定して、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）を実行することとなる。ＰＵＳＨ型情報統合処理（ステップＳ４１０５）では、統合エンジン１０１は、物理統合指示情報３７００の＜ＯＵＴ＞タグで指定された論理モデルＬのマッピング定義ＭＤを初期化する（ステップＳ４５０１）。
【０２３４】
図６０は、論理モデルＬのマッピング定義ＭＤの初期化（ステップＳ４５０１）を示す説明図である。図５９に示した物理統合指示情報３７００では、＜ＯＵＴ＞タグで指定された検索式で検索対象として指定されている論理モデルＬは論理モデルＬＥ（表Ｅ）である。したがって、論理モデルＬＥのマッピング定義ＭＤ（Ｅ）を初期化する。
【０２３５】
具体的には、メタ定義の初期化処理（ステップＳ４００１）で評価順にソートされたマッピング定義ＭＤ（Ｅ）を取得して、その解決フラグをクリアする（“０”で埋める）。そして、Ｆｒｏｍ列に、物理統合指示情報３７００の＜ＩＮ＞で指定された表Ａ（物理モデルＰＡ）が持つ項目が設定されているマッピング定義（１），（４）の解決フラグを“１”にする。表Ａの他には入力される物理モデルは無いので、解決フラグの設定はこれで完了する。解決フラグを立てることによりマッピング定義ＭＤ（Ｅ）は、抽出処理（ステップＳ４１０１）が完了した状態として初期化される。
【０２３６】
物理統合では、マッピング定義ＭＤ（Ｅ）の初期化（ステップＳ４５０１）のあと、統合対象のすべての入力データである抽出結果Ａを、図４５の対象データ反映処理（ステップＳ４５０４）により、論理モデルの統合結果情報にコピーする。
【０２３７】
図６１は、対象データ反映処理（ステップＳ４５０４）の具体例を示す説明図である。図６１において、抽出結果に存在する項目について、解決フラグの値が“１”であるマッピング定義ＭＤ（Ｅ）の行を選択する。そして、選択したマッピング定義（１），（４）のＦｒｏｍ列の項目（表Ａ．従業員番号、表Ａ．氏名）を対象データとして、選択したマッピング定義（１），（４）のＴｏ列で指定された論理モデルＬＥにそれぞれコピーする。これにより、従業員番号の値と氏名の値が抽出結果Ａからコピーされ、統合結果Ｅが生成される。
【０２３８】
表Ａのほかには入力されたデータは無いので（ステップＳ４５０６：Ｎｏ）、つぎに未解決の末端列をＦＲＯＭ列に持つマッピング定義があるか判定する（ステップＳ４５０７）。ここでは未解決の末端列をＦＲＯＭ列に持つマッピング定義（２），（３）が存在するので（ステップＳ４５０７：Ｙｅｓ）、ＰＵＳＨ型情報統合処理の最終段階として図４６のＰＵＬＬ型情報統合処理を実行する（ステップＳ４２０１）。このとき、ＰＵＳＨ型情報統合処理から継続して呼ばれていることを示すＰＵＳＨコールフラグ（Ｆｐｃ）に“１”が設定されている。ＰＵＬＬ型情報統合処理（ステップＳ４２０１）では、図４６に示したように、問合わせ分解処理（ステップＳ４６０１）を実行する。問合わせ分解処理（ステップＳ４６０１）では、検索条件としてつぎに示す統合結果Ｅに設定済みの値を抽出する（ステップＳ４７０２）。
【０２３９】
表Ｅ．従業員番号＝７００１，７００２，７００３
表Ｅ．氏名＝田中一郎、鈴木次郎、佐藤三郎
【０２４０】
つぎに、図６０に示した初期化済みのマッピング定義ＭＤ（Ｅ）の２行目（２）が指定される（図４７のステップＳ４７０４）。このとき、着目する検索条件はマッピング定義（２）のＴｏ列に指定されている「表Ｅ．従業員番号＝７００１，７００２，７００３」となる。そして、この検索条件のクレンジング処理を実行する（ステップＳ４７０５）。ここで、検索条件のクレンジング処理（ステップＳ４７０５）について具体的に説明する。
【０２４１】
図６２は、図４７に示した検索条件のクレンジング処理（ステップＳ４７０５）の具体例を示す説明図である。図６２における検索条件のクレンジング処理（ステップＳ４７０５）では、初期化済みのマッピング定義ＭＤ（Ｅ）の２行目（２）のＴｏ列「表Ｅ．従業員番号」の値を、Ｆｒｏｍ列である「表Ｂ．従業員番号」の検索条件６２００としてクレンジングする。このクレンジングでは、データ型（Ｉｎｔｅｇｅｒ）が一致し、型属性がないため、Ｔｏ列「表Ｅ．従業員番号」の検索条件値をそのまま複写することとなる。これにより、ステップＳ４７０８において、表Ｂの検索式６２０１が生成されることとなる。
【０２４２】
図６３は、解決フラグの更新例を示す説明図である。図６２において、表Ｂの検索式６２０１が生成されたため、表Ｂの検索式６２０１によって検索することで解決できるマッピング定義ＭＤ（Ｅ）の行に対し、解決フラグを立てる（ステップＳ４７０９）。具体的には、マッピング定義ＭＤ（Ｅ）のＦｒｏｍ列において、「表Ｂ」の項目がある行（２），（３）について解決フラグを“１”にする。
【０２４３】
つぎにステップＳ４７１０で解決すべき未解決のマッピング定義があるか確認する。ここで、解決フラグが"０"である未解決のマッピング定義（５）は、そのＦｒｏｍ列「表Ｄ．名称」に対し、マッピング定義（３）のＴｏ列「表Ｄ．所属」が存在するため、マッピング定義（５）のＦｒｏｍ列「表Ｄ．名称」は、末端列ではないので、問合わせ分解処理（ステップＳ４６０１）は終了する。
【０２４４】
また、図４６において、問合わせ分解処理（ステップＳ４６０１）が終了すると、ステップＳ４６０３において、作成された物理モデルＰの検索式から先頭の物理モデルＰの検索式を指定する。たとえば、図６２で生成された表Ｂの検索式６２０１では、先頭の検索式「Ｓｅｌｅｃｔ  ＊  Ｆｒｏｍ  表Ｂ  Ｗｈｅｒｅ  従業員番号＝７００１」を指定することとなる。そして、ステップＳ４６０４で、指定された検索式を実行する。
【０２４５】
図６４は、指定された検索式の実行内容（ステップＳ４６０４）を示す説明図である。図６４では、指定された検索式６４００を実行することで、表Ｂに割り付けられているＲＤＢ２の表２から検索結果６４０１を検索する。つぎに対象データ反映処理（ステップＳ４５０４）を実行する。ここで、検索結果６４０１の表Ｂ．所属は、直接、統合結果Ｅに反映できない（図５２のステップＳ５２０１：Ｎｏ）。
【０２４６】
したがって、テーブル変換処理（ステップＳ５２０２）を実行することで、中間テーブル表Ｄの検索結果６４０２を得る。検索結果６４０２により、所属：１０１の名称：営業部が得られるため、統合結果Ｅの所属項目に反映することができる。この一連の処理を繰り返すことで、統合結果Ｅの所属項目には、各従業員番号に対応する所属の名称が埋まることとなる。
【０２４７】
図６５は、ＰＵＬＬ型情報統合処理の完了時の統合結果集合Ｅを示す説明図である。図６５の統合結果集合Ｅを得ることで、物理統合指示情報３７００の＜ＯＵＴ＞で割り付けた出力先に統合結果集合Ｅが出力されることとなる。具体的には、図２８に示すように、表ＥにＣＳＶファイルへの登録機能１４１が割り付けられている場合は、統合結果集合Ｅは登録機能１４１によりＣＳＶ形式に変換されてＣＳＶファイル「Ｃ：￥Ｔａｂｌｅ−Ｅ．ｃｓｖ」に登録される。
【０２４８】
また、図２９に示すように、表Ｅにデータベースへの登録機能１４１が割り付けられている場合は、統合結果集合Ｅは登録機能１４１により該当するデータベースの登録情報に変換されてデータベース「ＲＤＢ２」の「表２」に登録される。この際、論理モデルＥの「従業員番号」項目は、表２の「Ｉｄ」項目に変換されて登録されることになる。
【実施例２】
【０２４９】
つぎに、実施例２について説明する。実施例２は、以下に示す物理統合指示情報が与えられた場合の物理統合処理（ステップＳ４００５）の実行例である。実施例２が前提とするメタ情報は実施例１と同様に図１１に示すモデルの範囲（図１４に示す物理モデルＰＡ、図１５に示す物理モデルＰＢ、図２０に示す論理モデルＬＥ、およびマッピング定義ＭＤ（Ｅ）の組み合わせ）である。以下、図９０〜図９３を用いて、上述したフローチャートと対応付けて説明する。尚、実施例２は、実施例１とほぼ同じであるので、異なる処理について説明する。
【０２５０】
図９０は、実施例２の物理統合指示情報９０００の一例を示す説明図である。物理統合指示情報９０００において、＜ＩＮ＞タグで入力データとして表Ａ，表Ｂの２つが指定されているので、対象データ抽出処理（ステップＳ４１０１）では、表Ａ、表Ｂそれぞれについて＜ＩＮ＞タグで指定されたデータ抽出が行われる。物理統合指示情報９０００では、物理モデル表Ａに存在するすべての情報を抽出し、物理モデル表Ｂに存在するすべての情報を抽出し、それらを統合した結果として論理モデル表Ｅのデータを返す。また、Ｗｈｅｒｅ句で抽出条件を指定することもできる。
【０２５１】
図９１は、実施例２のマッピング定義の初期化（ステップＳ４５０１）を示す説明図である。ＰＵＳＨ型情報統合処理（ステップＳ４１０５）の、マッピング定義ＭＤ（Ｅ）の初期化処理（ステップＳ４５０１）においては、図９１に示すように、表Ａについて解決できるマッピング定義（１），（４）の解決フラグを“１”にした後で、表Ｂについて解決できるマッピング定義（２），（３）の解決フラグを“１”にする。
【０２５２】
具体的には、図９１の左側のマッピング定義ＭＤ（Ｅ）において、図９０の最初の＜ＩＮ＞で指定された表Ａで解決されるマッピングの解決フラグを“１”にする。すなわち、ＦＲＯＭ側に表Ａを持つマッピング定義（１）（４）を“１”にする。
【０２５３】
つぎに、図９１の右側のマッピング定義ＭＤ（Ｅ）において、図９０の２番目の＜ＩＮ＞で指定された表Ｂで解決されるマッピングの解決フラグを“１”にする。すなわち、ＦＲＯＭ側に表Ｂを持つマッピング定義（２）（３）を“１”にする。
【０２５４】
図９２は、実施例２の対象データ反映処理（ステップＳ４５０４）の１回目（表Ａの反映処理）を示す説明図である。図９２において、表Ａについての対象データ反映処理（ステップＳ４５０４）が完了した状態を示している。この処理は、実施例１における同処理（段落［０１７７］〜段落［０１７８］）と全く同じである。
【０２５５】
つぎに、未処理の入力データがあるかを確認する（ステップＳ４５０６）。入力データ「表Ｂ」の反映処理が未処理なので（ステップＳ４５０６：Ｙｅｓ）、ステップＳ４５０５へ戻る。ステップＳ４５０５では、未処理の入力データである「表Ｂの抽出結果」をポイントして、対象データ反映処理（ステップＳ４５０４）を実行する。
【０２５６】
図９３は、実施例２の対象データ反映処理（ステップＳ４５０４）の２回目（表Ｂの反映処理）を示す説明図である。図９３では、表Ｂについての対象データ反映処理（ステップＳ４５０４）が完了した状態を示している。この処理は、実施例１で示したＰＵＬＬ型情報統合処理（図４６）における検索式（ステップＳ４６０４)の実行結果を反映する「対象データ反映処理（ステップＳ４５０４）」と同じ処理であるので、テーブル変換処理（ステップＳ５２０２）にて中間テーブル表Ｄで表Ｂの所属番号を表Ｅに必要な所属名称に読み替えた結果が統合結果情報Ｅの所属項目に反映される。
【０２５７】
これで、すべての入力データについて対象データ反映処理（ステップＳ４５０４）が完了したので（ステップＳ４５０６：Ｎｏ）、ステップＳ４５０７に進む。ここで、図９１に示すマッピング定義ＭＤ（Ｅ）は、末端列でない（５）を除いてすべて解決フラグが“１”になっているので（ステップＳ４５０７：Ｎｏ）、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）を実行することなく、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）は完了する。このように、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）は、指定された論理モデルの統合に必要なデータがすべて予め入力される場合には、ＰＵＬＬ型情報統合処理を必要としない。
【０２５８】
最後に、物理統合指示情報９０００で＜ＯＵＴ＞タグに指定されている格納条件により、表Ｅに割り付けられている出力先に実施例１と同様に出力されて、物理統合処理（ステップＳ４００５が完了し、すべての統合処理が完了する。
【０２５９】
実施例２と同様に、図１０に示す範囲のメタ情報（図１４に示す物理モデルＰＡ、図１５に示す物理モデルＰＢ、図１９に示す論理モデルＬＣおよびマッピング定義ＭＤ（Ｃ）の組み合わせ）を前提として、物理統合指示情報９０００の＜ＯＵＴ＞タグで「表Ｅ」に替えて「表Ｃ」を指定した場合でも、情報統合処理が正しく動作することは明らかである。この場合は、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）の対象データ反映処理（ステップＳ４５０４）では、表Ｂの所属項目を直接表Ｃの所属項目に反映できるので、テーブル変換処理（ステップＳ５２０２）は実行されない。
【実施例３】
【０２６０】
つぎに、実施例３について説明する。実施例３は、図３８に示した仮想統合指示情報３８００が与えられた場合の仮想統合処理（ステップＳ４００６）の実行例である。実施例３で使用するメタ情報は実施例１および実施例２と同様に図１１に示すモデルの範囲である。以下、図６６〜図７９を用いて、上述したフローチャートと対応付けて説明する。
【０２６１】
仮想統合処理（ステップＳ４００６）では、まず、仮想統合指示情報３８００から検索条件となる検索式を抽出する。
【０２６２】
図６６は、図４２に示した検索条件抽出処理（ステップＳ４２００）の例を示す説明図である。図６６において、仮想統合指示情報３８００の＜ＥＩＩ＞タグで指定された検索式を検索条件６６００として抽出する。抽出された検索条件６６００を入力して、ＰＵＬＬ型情報統合処理が開始され（ステップＳ４２０１）、問合わせ分解処理（ステップＳ４６０１）を実行することとなる。
【０２６３】
問合わせ分解処理（ステップＳ４６０１）では、検索条件６６００で指定されている論理モデルＬＥ（表Ｅ）のマッピング定義ＭＤ（Ｅ）を取得して、解決フラグをクリアする（図４７のステップＳ４７０３）。
【０２６４】
図６７は、検索条件６６００から得られたマッピング定義ＭＤ（Ｅ）の初期化を示す説明図である。図６７のマッピング定義ＭＤ（Ｅ）は、ステップＳ４７０３により、解決列の解決フラグがクリアされている。そして、ステップＳ４７０４により、解決フラグが“０”である１行目のマッピング定義（１）が指定され、そのＦｒｏｍ列「表Ａ．従業員番号」が求まる。そして、求められたＦｒｏｍ列「表Ａ．従業員番号」について、検索条件のクレンジング処理（ステップＳ４７０５）を実行する。
【０２６５】
図６８は、検索条件のクレンジング処理例を示す説明図である。ここでは、マッピング定義のＦｒｏｍ列「表Ａ．従業員番号」をクレンジング先、検索条件６８０１であるマッピング定義のＴｏ列「表Ｅ．従業員番号」をクレンジング元に設定してクレンジングする。検索条件６８０１であるＴｏ列「表Ｅ．従業員番号」と検索対象であるＦｒｏｍ列「表Ａ．従業員番号」とは、データ型および型属性が同じである。
【０２６６】
したがって、検索条件６８０１であるＴｏ列「表Ｅ．従業員番号」の値「７００２」をそのまま、検索対象であるＦｒｏｍ列「表Ａ．従業員番号」の検索値としてコピーする。クレンジング結果６８０２であるＦｒｏｍ列「表Ａ．従業員番号」は末端列である。したがって、クレンジング結果６８０２から検索式６９００を生成する（図４７のステップＳ４７０８）。
【０２６７】
図６９は、図４７のステップＳ４７０８での検索式の生成例（１回目）を示す説明図である。生成された検索式６９００は、表Ａを検索対象としているため、マッピング定義ＭＤ（Ｅ）のＦｒｏｍ列に「表Ａ」の項目がある行（１），（４）の解決フラグを“１”にする。この場合、未解決のマッピング定義（２），（３），（５）があるため、同様の処理を実行することで、再度クレンジング結果から検索式を生成することとなる（図４７のステップＳ４７０８）。
【０２６８】
図７０は、図４７のステップＳ４７０８での検索式の生成例（２回目）を示す説明図である。図７０では、あらたに、検索式７０００が生成されている。生成された検索式７０００は、表Ｂを検索対象としているため、マッピング定義ＭＤ（Ｅ）のＦｒｏｍ列に「表Ｂ」がある行（２），（３）の解決フラグを“１”にする。なお、未解決のマッピング定義（５）は、末端列には該当しないため、解決すべきマッピング定義はないものとして問合わせ分解処理（ステップＳ４６０１）を終了する。
【０２６９】
このあと、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）では、問合わせ分解処理で生成された物理モデルＰの検索式６９００，７０００を先頭から指定し、指定された検索式６９００を実行する（図４６のステップＳ４６０３，Ｓ４６０４）。
【０２７０】
図７１は、検索式６９００の検索内容を示す説明図である。図７１では、検索式６９００により表Ａから従業員番号：７００２の従業員情報を物理モデルＰＡに従って検索することとなる。したがって、表Ａの検索結果７１００を得ることができる。このあと、対象データ反映処理（ステップＳ４５０４）を実行することとなる。
【０２７１】
図７２は、対象データ反映処理（ステップＳ４５０４）の具体例（１回目）を示す説明図である。図７２では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｅ）の該当する行である１行目（１）を参照する。そのＦｒｏｍ列「表Ａ．従業員番号」は、Ｔｏ列「表Ｅ．従業員番号」に直接反映可能である（図５２のステップＳ５２０１:Ｙｅｓ）。したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。
【０２７２】
すなわち、表Ａの検索結果７１００に含まれている値「７００２」，「鈴木次郎」，「０９６−２２２−２２２２」のうち先頭の値「７００２」を対象データとして反映を試みる。表Ａの従業員番号と表Ｅの従業員番号は、データ型および型属性が一致するため、表Ａの検索結果の「７００２」を、そのまま表Ｅの従業員番号にコピーすることとなる。
【０２７３】
図７３は、対象データ反映処理（ステップＳ４５０４）の具体例（２回目）を示す説明図である。図７３では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｅ）の１行目（４）を参照する。そのＦｒｏｍ列「表Ａ．氏名」は、Ｔｏ列「表Ｅ．氏名」に直接反映可能である（図５２のステップＳ５２０１：Ｙｅｓ）。したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。
【０２７４】
すなわち、表Ａの検索結果７１００に含まれている値「７００２」，「鈴木次郎」，「０９６−２２２−２２２２」のうち値「鈴木次郎」を対象データとして反映を試みる。表Ａの氏名と表Ｅの氏名は、データ型および型属性が一致するため、表Ａの検索結果の「鈴木次郎」を、そのまま表Ｅの氏名にコピーすることとなる。なお、検索結果７１００のうち電話番号は表Ｅには反映しない（クレンジング定義ＭＤ（Ｅ）のＦｒｏｍ列に存在しない）ため、これ以上反映すべきつぎのデータは無い（ステップＳ５２０６）。したがって、対象データ反映処理（ステップＳ４５０４）は完了する。このあと、つぎの検索式を指定する（ステップＳ４６０８）。
【０２７５】
図７４は、検索式７０００による検索内容を示す説明図である。図７４では、つぎの検索式として検索式７０００が指定されているため、検索式７０００を実行することで、表Ｂの検索結果７４００を得ることができる（ステップＳ４６０５）。この表Ｂの検索結果７４００を入力として対象データ反映処理（ステップＳ４５０４）を実行する。
【０２７６】
対象データ反映処理（ステップＳ４５０４）では、表Ｂの検索結果７４００の値「従業員番号＝７００２」，「所属＝２０２」のうち、まず先頭の「従業員番号＝７００２」から指定する。ここでは、マッピング定義ＭＤ（Ｅ）の２行目（２）を参照する。マッピング定義（２）のＦｒｏｍ列「表Ｂ．従業員番号」は、Ｔｏ列「表Ｅ．従業員番号」に直接反映可能である（図５２のステップＳ５２０１：Ｙｅｓ）。したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。
【０２７７】
なお、「表Ｂ．従業員番号」のＴｏ列「表Ｅ．従業員番号」はＭＫｅｙ項目であり、すでに統合結果Ｅには、従業員番号項目に同一の値「７００２」を持つレコードが存在するため、統合結果Ｅの処理対象レコードを「従業員番号＝７００２」に移す（このケースでは、他にレコードがないため、移動はない。）。
【０２７８】
図７５は、統合結果集合Ｅの処理対象レコードの移動状態を示す説明図である。つぎに、対象データ反映処理（ステップＳ４５０４）では、表Ｂの検索結果７４００の値「従業員番号＝７００２」，「所属＝２０２」のうち、「所属＝２０２」を指定する。
【０２７９】
図７６は、対象データ反映処理（ステップＳ４５０４）の表Ｂの検索結果における具体例を示す説明図である。図７６では、表Ｂの検索結果７４００の値「所属＝２０２」が指定されている。図７６では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｅ）の３行目（３）を参照する。マッピング定義（３）のＦｒｏｍ列「表Ｂ．所属」は、直接論理モデルＬに反映できない（図１１の（３）を参照。）。
【０２８０】
したがって、図５２のテーブル変換処理（ステップＳ５２０２）が実行され、その中で図５４の検索条件のクレンジング処理（ステップＳ４７０５）を実行することとなる。図７６では、表Ｂの所属は、表Ｄの所属とデータ型（Ｉｎｔｅｇｅｒ）が一致し、型属性がないため、所属の値「２０２」をそのままコピーして、クレンジング結果７６０１を得る。このクレンジング結果７６０１により、表Ｄ（物理モデルＰＤ）の検索式７６０２を生成する（図５４のステップＳ５４０３）。このあと、生成された検索式７６０２を実行して中間テーブルを検索する（ステップＳ５３０２）。
【０２８１】
図７７は、中間テーブルとして検索された表Ｄの検索結果７７００を示す説明図である。物理モデルＰＤは、所属（Ｉｎｔｅｇｅｒ）と名称（Ｓｔｒｉｎｇ）を構造化しているため、所属「２０２」で、その名称「製造部」を引くことができる。これにより、表Ｂでポイントしている値（所属「２０２」）が、表Ｄの所属「２０２」に対応する名称「製造部」に置き換わることとなる。このあと、表Ｄの検索結果７７００を用いて対象データ反映処理（ステップＳ４５０４）を実行する。
【０２８２】
図７８は、対象データ反映処理（ステップＳ４５０４）の表Ｄの検索結果７７００における具体例を示す説明図である。図７８では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｅ）の５行目（５）を参照する。マッピング定義（５）のＦｒｏｍ列「表Ｄ．名称」は、Ｔｏ列「表Ｅ．所属」に直接反映可能である（図５２のステップＳ５２０１：Ｙｅｓ）。したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。
【０２８３】
なお、クレンジング処理（ステップＳ５２０３）において、Ｆｒｏｍ列「表Ｄ．名称」のデータ型とＴｏ列「表Ｅ．所属」のデータ型はともにＳｔｒｉｎｇ（文字列型）で一致するが、ＣｈａｒＣｏｄｅ型属性が異なるため、型属性を変換する。すなわち、表Ｄの名称“ＣｈａｒＣｏｄｅ”＝ＪＥＦを、表Ｅの所属“ＣｈａｒＣｏｄｅ”＝Ｓ＿ＪＩＳに型属性を変換するクレンジング処理が実行される。そして、型属性変換の結果（シフトＪＩＳの「製造部」）を、Ｔｏ列「表Ｅ．所属」に複写する。そして、両側共にＭＫｅｙ項目ではないので、その時点で処理対象になっている統合結果Ｅのレコードの所属項目に属性変換結果（シフトＪＩＳの「製造部」）を複写する。
【０２８４】
これにより、反映すべき残りのデータがないため（ステップＳ５２０６：Ｎｏ）、表Ｄに対する対象データ反映処理（ステップＳ４５０４）は完了する。なお、問合わせ分解処理で生成された検索式６９００，７０００はすべて処理され、未処理の検索式がないため（ステップＳ４６０７：Ｎｏ）、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）は成功したこととなる。これにより、最終結果として統合結果Ｅを得ることができる。
【０２８５】
図７９は、仮想統合結果として出力される統合結果集合Ｅを示す説明図である。図７９の統合結果Ｅが、論理モデルＬＥに問合わせを行った利用側システムに提供されることとなる。
【実施例４】
【０２８６】
つぎに、実施例４について説明する。実施例４は、図３９に示したストリーム統合指示情報３９００が与えられた場合のストリーム統合処理（ステップＳ４００７）の実行例である。実施例４で使用するメタ情報は図１２に示すモデルの範囲である。実施例４が前提とするメタ情報は図１２に示すモデルの範囲であり、図１８に示す物理モデルＰＳ、図１６に示す物理モデルＰＤ、図１７に示す物理モデルＰＴ、図２１に示す論理モデルＬＮおよびマッピング定義ＭＤ（Ｎ）を組み合わせて使用する。以下、図８０〜図８９を用いて、上述したフローチャートと対応付けて説明する。
【０２８７】
図８０は、ストリーム統合による対象データの取得例を示す説明図である。図８０では、ストリーム統合指示情報３９００の＜ＩＮ＞タグで指定された取得条件８０００により、情報源１１０のデータストリームＳ２から対象データを表Ｓ（抽出結果Ｓ）として取得する。この取得処理は図４３に示すデータストリームの監視処理手順により実行される。すなわち、取得条件８０００の＜ＴＩＭＩＮＧ＞タグで指定された「２０：２０」を開始条件とし、「２０：２２」を終了条件として、表Ｓに割り付けられたデータストリームＳ２の監視を行い、＜ＳＱＬ＞タグで指定された条件「Ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  表Ｓ  Ｗｈｅｒｅ  ＴＯ＝２４２００」に合致する通話情報（図８）を取得して取得キューに格納する。
【０２８８】
ストリーム統合では、取得したデータ（抽出結果Ｓ）を入力としてＰＵＳＨ型情報統合処理（ステップＳ４１０５）を実行し、得られた統合結果を＜ＯＵＴ＞タグで指定された統合結果情報（表Ｎ）に割り付けられた出力先に出力する。ＰＵＳＨ型情報統合処理では、最初に、ストリーム統合指示情報３９００の＜ＯＵＴ＞タグで指定された表Ｎのマッピング定義ＭＤ（Ｎ）を初期化する（図４５のステップＳ４５０１）。
【０２８９】
図８１は、初期化済みのマッピング定義ＭＤ（Ｎ）を示す説明図である。ここでは、すべての解決フラグに“０”を設定してクリアした後で、Ｆｒｏｍ列にすべての入力データである「表Ｓ」の項目を持つマッピング定義（１），（４），（２），（３）の解決フラグを“１”にする（ステップＳ４５０１）。初期化済みなので、ＰＵＳＨコールフラグＦｐｃ＝１にする（ステップＳ４５０２）。つぎに、表Ｓの抽出結果Ｓを論理モデルＬの統合結果Ｎへの反映を試みる（ステップＳ４５０３）。
【０２９０】
図８２は、抽出結果Ｓの先頭の対象データにおける対象データ反映処理例を示す説明図である。図８２では、対象データとして先頭の「ＤＴ＝２００９．２．２８．２０：２０：００」を指定する。図８２では、対象データ反映処理（ステップＳ４５０４）において、図８１のマッピング定義ＭＤ（Ｎ）の１行目（１）を参照する。マッピング定義（１）のＦｒｏｍ列「表Ｓ．ＤＴ」は、Ｔｏ列「表Ｎ．ＤＴ」に直接反映可能である（図５２のステップＳ５２０１：Ｙｅｓ）。「表Ｎ．ＤＴ」は、ＭＫｅｙ項目であり、統合結果Ｎにレコードが存在しないため、新規レコードを作成して（ステップＳ５８０４）、ＤＴ項目に「２００９．２．２８．２０：２０：００」をコピーする（ステップＳ５８０５）。
【０２９１】
図８３は、抽出結果Ｓのつぎの対象データの指定例を示す説明図である。図８３では、先頭の対象データ「ＤＴ＝２００９．２．２８．２０：２０：００」のつぎのデータ「ＦＲＯＭ＝１４１００」を対象データとして指定する（ステップＳ５２０７）。マッピング定義ＭＤ（Ｎ）において「表Ｓ．ＦＲＯＭ」がＦｒｏｍ列にある行は、（４），（２）である。マッピング定義（４）は、Ｔｏ列が統合結果Ｎに直接反映できない（図５２のステップＳ５２０１：Ｎｏ）。したがって、テーブル変換処理（ステップＳ５２０２）を実行する。
【０２９２】
図８４は、ストリーム統合における中間テーブル検索処理例（その１）を示す説明図である。図８３で指定された対象データは、表Ｓの「ＦＲＯＭ＝１４１００」である。マッピング定義ＭＤ（Ｎ）の２行目（４）では、そのＴｏ列が「表Ｔ．内線」であるため、「表Ｔ．内線＝１４１００」という検索条件８４００を作成する。そして、この作成された検索条件８４００で中間テーブル（表Ｔ）を検索する検索式８４０１を生成する。検索式８４０１を実行することで、表Ｔの検索結果８４０２を得ることができる（ステップＳ５３０２）。
【０２９３】
図８５は、ストリーム統合における中間テーブル検索処理例（その２）を示す説明図である。図８４の表Ｔの検索結果８４０２では、内線＝１４１００の所属＝１０１が得られたが、Ｆｒｏｍ列「表Ｔ．所属」であるマッピング定義ＭＤ（Ｎ）の３行目（５）のＴｏ列は「表Ｄ．所属」であるため、論理モデルＬではない。したがって、統合結果Ｎに直接反映することができない（図５２のステップＳ５２０１：Ｎｏ）。したがって、テーブル変換処理（ステップＳ５２０２）を実行する。
【０２９４】
マッピング定義ＭＤ（Ｎ）の３行目（５）のＴｏ列が「表Ｄ．所属」であるため、「表Ｄ．所属＝１０１」という検索条件８５００を作成する。そして、この作成された検索条件８５００で中間テーブル（表Ｄ）を検索する検索式８５０１を生成する。検索式８５０１を実行することで、表Ｄの検索結果８５０２を得ることができる（ステップＳ５３０２）。
【０２９５】
図８６は、対象データ反映処理（ステップＳ４５０４）の表Ｄの検索結果８５０２における具体例を示す説明図である。図８６では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｎ）の６行目（６）を参照する。マッピング定義（６）のＦｒｏｍ列「表Ｄ．名称」は、統合結果情報ＮであるＴｏ列「表Ｎ．ＦＲＯＭ名称」に直接反映可能である（図５２のステップＳ５２０１:Ｙｅｓ）。したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。
【０２９６】
なお、クレンジング処理（ステップＳ５２０３）において、Ｔｏ列「表Ｎ．ＦＲＯＭ名称」のデータ型とＦｒｏｍ列「表Ｄ．名称」のデータ型はともにＳｔｒｉｎｇ（文字列型）で一致するが、ＣｈａｒＣｏｄｅ型属性が異なるため、ＣｈａｒＣｏｄｅ型属性をＴｏ列側に変換するクレンジングを実行する。すなわち、表Ｄの名称“ＣｈａｒＣｏｄｅ”＝ＪＥＦを、表Ｅの所属“ＣｈａｒＣｏｄｅ”＝Ｓ＿ＪＩＳに型属性変換する。
【０２９７】
つぎの結果反映処理（ステップＳ５２０４）では、双方ともにＭＫｅｙ項目ではないため、Ｔｏ列である「表Ｎ．ＦＲＯＭ名称」に型属性変換結果（シフトＪＩＳの「営業部」）を複写する（ステップＳ５８１１）。このあと、抽出結果Ｓ（図８３）に戻り、対象データ「ＦＲＯＭ＝１４１００」に対するつぎのマッピング定義（２）を指定する（ステップＳ５２０７）。
【０２９８】
図８７は、対象データ反映処理（ステップＳ４５０４）の表Ｓの抽出結果Ｓにおける具体例（その１）を示す説明図である。図８７では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｎ）の４行目（２）を参照する。マッピング定義（２）のＦｒｏｍ列「表Ｓ．ＦＲＯＭ」は、Ｔｏ列「表Ｎ．ＦＲＯＭ」に直接反映可能である（図５２のステップＳ５２０１：Ｙｅｓ）。したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。これにより、「表Ｓ．ＦＲＯＭ」の値「１４１００」が「表Ｎ．ＦＲＯＭ」にそのままコピーされる（ステップＳ５８１１）。
【０２９９】
図８８は、対象データ反映処理（ステップＳ４５０４）の表Ｓの抽出結果Ｓにおける具体例（その２）を示す説明図である。図８８では、対象データ反映処理（ステップＳ４５０４）において、マッピング定義ＭＤ（Ｎ）の５行目（３）を参照する。マッピング定義（３）のＦｒｏｍ列「表Ｓ．ＴＯ」は、Ｔｏ列「表Ｎ．ＴＯ」に直接反映可能である（図５２のステップＳ５２０１：Ｙｅｓ）。
【０３００】
したがって、ステップＳ５２０３によりクレンジング処理をして、ステップＳ５２０４により結果反映処理を実行する。これにより、「表Ｓ．ＴＯ」の値「２４２００」が「表Ｎ．ＴＯ」にそのままコピーされる（ステップＳ５８１１）。ここまでで、抽出結果Ｓの１レコード目の処理が終了するが、同じように、２レコード目、３レコード目について処理する。
【０３０１】
これで、すべての抽出結果Ｓについて対象データ反映処理（ステップＳ４５０４）が完了し、未処理の入力データは無く（ステップＳ４５０６：Ｎｏ）、未解決の末端列をＦＲＯＭ列に持つマッピング定義も無い（ステップＳ４５０７：Ｎｏ）ので、ＰＵＬＬ型情報統合処理（ステップＳ４２０１）は実行しないで、ＰＵＳＨ型情報統合処理（ステップＳ４１０５）は完了する。
【０３０２】
図８９は、ストリーム統合結果として出力される統合結果集合Ｎを示す説明図である。図８９の統合結果集合Ｎは、論理モデルＬＮがデータストリームに割り付けられているケースでは、割り当てられたデータストリームＮに送出されることとなる。また、論理モデルＬＮがファイルやＤＢなどの物理データに割り付けられているケースでは、割り付けられたファイルまたはＤＢに登録される。ストリーム統合では、ＰＵＳＨ型情報統合を実行しているが、統合に必要な中間テーブル（表Ｄ、表Ｔ）はＰＵＬＬ型で動的に取得する仮想統合を使用しているため、混合型情報統合といえる（図４を参照。）。
【０３０３】
図９４は、情報源または利用側にアプリケーションプログラムを使用する例（ＰＵＬＬ型）を示す説明図である。図９４では、情報源または利用側にアプリケーションプログラムを使用するＰＵＬＬ型情報統合方式（図２）の例を示している。
【０３０４】
図９４の物理モデルＡに対応する情報源は、アプリケーションプログラム（アプリ１）であり、更にアプリ１は別のアプリケーション（アプリ１０）と接続している。ここで、アプリ１０は、問合わせを入力することによって処理を実行し、その結果として、入力された問合わせに該当するデータを出力するＰＵＬＬ型の情報源側アプリケーションプログラムである。また、アプリ１は、収集手段とアプリ１０とを仲介するプログラムである。
【０３０５】
物理モデルＡに対する問合わせを収集手段が受け取ると、収集手段はアプリ１に送る。アプリ１は受け取った問合わせを必要によりアプリ１０に対する問合わせに変換してアプリ１０に送る。
【０３０６】
アプリ１０は受け取った問合わせに対する処理を行い、その結果をアプリ１に返す。アプリ１はアプリ１０から受け取った処理結果を必要に応じて変換して収集機能に送り、収集機能は物理モデルＡの問合わせ結果として情報統合エンジンに回答する。物理モデルＢに対応するアプリ２、アプリ２０も同様である。
【０３０７】
これらアプリ１の動作は、実施例３で説明した図１１の物理モデルＰＡ（表Ａ）に対して、図２６でＲＤＢ１の表１を割り付けていることに対応しており、情報統合エンジンから見た時の情報源の動きは実施例３と等価であるから、実施例３と同様に情報統合処理が実行されることは明らかである。
【０３０８】
また、図９４の論理モデルＸに対応する利用側は、アプリケーションプログラム（アプリ３）であり、更にアプリ３は別のアプリケーション（アプリ３０）と接続している。ここで、アプリ３０は、問合わせを発行して、その処理結果を受け取ることにより処理を行うＰＵＬＬ型の利用側アプリケーションプログラムである。また、アプリ３は、提供手段とアプリ３０とを仲介するプログラムである。
【０３０９】
アプリ３０によって発行された問合わせをアプリ３が受け取ると、必要に応じて論理モデルＸに対する問合わせに変換して提供手段に送り、収集手段は情報統合エンジンに入力する。情報統合エンジンは、入力された論理モデルＸに対する問合わせによってＰＵＬＬ型の情報統合処理を行い、その統合結果を提供手段に送る。提供手段は、受け取った統合結果をアプリ３に送り、アプリ３は必要に応じて変換してアプリ３０に送る。アプリ３０は受け取った統合結果を使用して処理を継続する。
【０３１０】
これらアプリ３の動作は、実施例３で説明した図１１の論理モデルＬＥ（表Ｅ）に対して、図３８に示す仮想統合指示情報を渡し、仮想統合処理の結果を受け取るアプリケーションプログラムに対応しており、情報統合エンジンから見た時の利用側の動きは実施例３と等価であるから、実施例３と同様に情報統合処理が実行されることは明らかである。
【０３１１】
図９５は、情報源または利用側にアプリケーションプログラムを使用する例（ＰＵＳＨ型／混合型）を示す説明図である。図９５では、情報源または利用側にアプリケーションプログラムを使用するＰＵＳＨ型および混合型情報統合方式（図３、図４）の例を示している。図９５の物理モデルＡに対応する情報源は、アプリケーションプログラム（アプリ４）であり、更にアプリ４は別のアプリケーション（アプリ４０）と接続している。ここで、アプリ４０は、予め設定しておいた出力先に対して、実行結果をＰＵＳＨ型で送信する情報源側アプリケーションプログラムである。また、アプリ４は、抽出手段とアプリ４０とを仲介するプログラムである。
【０３１２】
アプリ４０は、アプリ４に送信すべき処理結果が生じたときに、アプリ４に対して処理結果を送信する。アプリ４はアプリ４０から受け取った処理結果を、必要に応じて変換して抽出機能に送り、抽出機能は物理モデルＡのデータとして情報統合エンジンに入力する。物理モデルＢに対応するアプリ５、アプリ５０は、前述したアプリ２、アプリ２０と同様である。
【０３１３】
このアプリ４の動作は、実施例１で説明した図１１の物理モデルＰＡ（表Ａ）に対して、図３１でＣＳＶファイルである「Ｃ：￥Ｔａｂｌｅ−Ａ．ｃｓｖ」を割り付けていることに対応しており、アプリ５の動作は、図１１の物理モデルＰＢ（表Ｂ）に対して、図２６でＲＤＢ２の表２を割り付けていることに対応している。従って、情報統合エンジンから見た時の情報源の動きは実施例１と等価であるから、実施例１と同様に情報統合処理が実行されることは明らかである。
【０３１４】
また、図９５の論理モデルＸに対応する利用側は、アプリケーションプログラム（アプリ６）であり、更にアプリ６は別のアプリケーション（アプリ６０）と接続している。ここで、アプリ６０は、アプリ３の結果をＰＵＳＨ型で受け取ることによって処理を行うＰＵＳＨ型の利用側アプリケーションプログラムである。また、アプリ６は、登録手段とアプリ６０とを仲介するプログラムである。
【０３１５】
ＰＵＳＨ型または混合型の情報統合エンジンが、論理モデルＸとしての統合結果を登録機能に送ると、登録手段は、受け取った統合結果をアプリ６に送り、アプリ６は必要に応じて変換してアプリ６０に送る。アプリ６０は受け取った統合結果を使用して処理を行う。
【０３１６】
これらアプリ６の動作は、実施例１で説明した図１１の論理モデルＬＥ（表Ｅ）に対して、図２８に示すようにＣＳＶファイルである「Ｃ：￥Ｔａｂｅｌ−Ｅ．ｃｓｖ」を割り付けることに対応しており、情報統合エンジンから見た時の利用側の動きは実施例１と等価であるから、実施例１と同様に情報統合処理が実行されることは明らかである。
【０３１７】
図９４および図９５に示したアプリ１〜６は、アプリ１０〜６０に対応するクライアントアプリケーションでも良い。また、ＸＭＬによる通信によりサービス連携を行うＳＯＡ（サービス指向アーキテクチャ）における応用では、アプリ１０、アプリ２０、アプリ３は、問合わせに応じた検索結果を返す検索サービスを実行する「サービスプロバイダ」であり、アプリ１、アプリ２、アプリ３０は、サービスプロバイダに対して検索サービスを依頼してその結果を受け取る「サービスリクエスタ」となる。また、アプリ４０、アプリ４、アプリ６、アプリ６０は必要な処理を行った結果をつぎの処理に渡すＰＵＳＨ型のサービスとなる。
【０３１８】
このように、情報源や利用側をアプリケーションプログラムとすることによって、本特許の情報統合装置は、アプリケーション連携の手段や、情報や情報システムを他のアプリケーションと接続するためのアダプタとしても応用することができる。
【０３１９】
以上説明したように、この情報統合装置、情報統合方法、および情報統合プログラムによれば、処理ロジックを記載しない定義ベースの共通のメタ情報を用いて、１つの統合エンジン１０１で、物理統合、仮想統合、ストリーム統合の３種類の統合処理を実現させることができる。したがって、情報源の性質や、利用側の統合目的に最適な情報統合方式または、その組み合わせを柔軟に実現することが可能になる。更に、事前設定情報を用いてメタ情報を実体に割り付けることによって、メタ情報の独立性が高まり、いろいろな実体やアプリケーションを対象にした情報統合が容易になる。
【０３２０】
また、物理統合、仮想統合およびストリーム統合の混合パターンの統合処理も実現することができる。たとえば、ストリーム統合で仮想統合を使用するケースでは、たとえば、電話線を流れている発信元（ＦＲＯＭ）、発信先（ＴＯ）、日時（ＤＴ）について、ストリーム統合を行い、発信元の名称（ＦＲＯＭ名称)を仮想統合によって追加することで、発信元の名称を電話機に表示することができる。
【０３２１】
また、ストリーム統合に使用している電話番号と名称を対応付ける情報を、運用されているシステムのマスタ情報を直接使用して仮想統合することにより、システムで組織変更が発生した場合でも、ストリーミングデータに自動的に反映される。また、ストリーム統合の出力として、ＸＭＬファイルやＤＢなどの実データを割り付けることにより、送受信の記録を残すことができる。
【０３２２】
また、物理統合で仮想統合を使用するケースでは、従業員情報の物理統合でも、組織表など随時変更されている情報が必要になる場合が多い。従来技術は必要な情報を先に収集して入力することにより物理統合を実施していたが、本実施の形態では、処理対象となるデータ以外は仮想統合により最新の情報を使用した統合処理を実現できる。したがって、情報の鮮度が保障され、誤り防止も図ることができる。たとえば、従業員名簿の作成時に、最新の所属情報を利用することができる。このように、二重管理が不要であるという仮想統合の利点を物理統合にも活かすことが可能になる。
【０３２３】
なお、本実施の形態で説明した情報統合方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。
（付記１）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段と、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出する抽出手段と、
前記抽出手段によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合手段と、
前記第１の統合手段によって統合された結果、前記マッピング定義において未解決の項目がある場合、前記第１の統合手段によって統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの情報を検索する検索式を生成する生成手段と、
前記生成手段によって生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集手段と、
前記収集手段によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合手段と、
前記第１および第２の統合手段によって統合された統合結果を前記利用側に出力する出力手段と、
を備えることを特徴とする情報統合装置。
（付記２）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段と、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出する抽出手段と、
前記抽出手段によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する統合手段と、
前記統合手段によって統合された統合結果を前記利用側に出力する出力手段と、
を備えることを特徴とする情報統合装置。
（付記３）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段と、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解する分解手段と、
前記分解手段によって分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集手段と、
前記収集手段によって収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する統合手段と、
前記統合手段によって統合された統合結果を前記利用側に出力する出力手段と、
を備えることを特徴とする情報統合装置。
（付記４）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段と、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出し、抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合処理を実行する第１の統合手段と、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理を実行する第２の統合手段と、
統合指示を検出する検出手段と、
前記検出手段によって検出された統合指示が、前記情報源側からの抽出により前記利用側に統合結果を出力する第１の統合指示である場合、前記第１の統合処理を実行し、前記利用側からの問い合わせにより当該問い合わせの結果を前記利用側に返す第２の統合指示である場合、前記第２の統合処理を実行するように制御する制御手段と、
前記制御手段によって実行された第１または第２の統合処理による統合結果を前記利用側に出力する出力手段と、
を備えることを特徴とする情報統合装置。
（付記５）
前記出力手段は、
前記統合結果を前記利用側に存在する所定のデータベースに登録することを特徴とする付記１〜４のいずれか一つに記載の情報統合装置。
（付記６）
前記出力手段は、
前記統合結果を前記利用側に存在する所定のファイルに登録することを特徴とする付記１〜４のいずれか一つに記載の情報統合装置。
（付記７）
前記情報源側に存在するデータストリームから統合対象となる前記物理モデルでの情報を取得する取得手段を備え、
前記第１の統合手段は、
前記取得手段によって取得された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合し、
前記出力手段は、
前記統合結果を前記利用側に存在するデータストリームに送出することを特徴とする付記１に記載の情報統合装置。
（付記８）
前記情報源側に存在するデータストリームから統合対象となる前記物理モデルでの情報を取得する取得手段を備え、
前記統合手段は、
前記取得手段によって取得された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合し、
前記出力手段は、
前記統合結果を前記利用側に存在するデータストリームに送出することを特徴とする付記２に記載の情報統合装置。
（付記９）
前記情報源側に存在するデータストリームから統合対象となる前記物理モデルでの情報を取得し、取得された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第３の統合処理を実行する第３の統合手段を備え、
前記制御手段は、
前記検出手段によって検出された統合指示が、前記情報源側からの抽出により前記利用側に統合結果を出力する第１の統合指示である場合、前記第１の統合処理を実行し、前記利用側からの問い合わせにより当該問い合わせの結果を前記利用側に返す第２の統合指示である場合、前記第２の統合処理を実行し、前記情報源側に存在するデータストリームからの取得により前記利用側に統合結果を出力する第３の統合指示である場合、前記第３の統合処理を実行するように制御し、
前記出力手段は、
前記制御手段によって実行された第１〜第３の統合処理による統合結果を前記利用側に出力することを特徴とする付記４に記載の情報統合装置。
（付記１０）
前記記憶手段は、
前記物理モデルを前記情報源側の情報に割り付ける事前設定情報を記憶しており、
前記抽出手段は、
前記事前設定情報によって前記物理モデルに割り付けされた情報を前記物理モデルでの情報として抽出することを特徴とする付記１、２、４または９に記載の情報統合装置。
（付記１１）
前記事前設定情報には、同一属性（情報の項目）について前記物理モデルと前記情報源側の情報とで属性名が異なる場合、前記属性名どうしが同一であることを示す付加情報が含まれており、
前記抽出手段は、
前記付加情報に基づいて、前記事前設定情報によって前記物理モデルに割り付けされた情報を前記物理モデルでの情報として抽出することを特徴とする付記１０に記載の情報統合装置。
（付記１２）
前記記憶手段は、
前記論理モデルを前記所定のデータベースに割り付ける事前設定情報を記憶しており、
前記出力手段は、
前記事前設定情報によって前記論理モデルに割り付けされた前記所定のデータベースに前記統合結果を登録することを特徴とする付記５に記載の情報統合装置。
（付記１３）
前記事前設定情報には、
同一属性（情報の項目）について前記論理モデルと前記所定のデータベースとで属性名が異なる場合、前記属性名どうしが同一であることを示す付加情報が含まれており、
前記出力手段は、
前記付加情報に基づいて、前記論理モデルに割り付けされた前記所定のデータベースの前記付加情報に対応する属性に対応する前記統合結果を登録することを特徴とする付記１２に記載の情報統合装置。
（付記１４）
前記記憶手段は、
前記物理モデルを前記情報源側の情報に割り付けるとともに、前記抽出手段による抽出条件を割り付ける事前設定情報を記憶しており、
前記抽出手段は、
前記事前設定情報の前記抽出条件に従って、前記情報源側の前記物理モデルでの情報を抽出することを特徴とする付記１、２、４または９に記載の情報統合装置。
（付記１５）
前記記憶手段は、
前記物理モデルを前記情報源側に存在するデータストリームに割り付ける事前設定情報を記憶しており、
前記取得手段は、
前記事前設定情報に基づいて、前記情報源側に存在するデータストリームから統合対象となる前記物理モデルでの情報を取得することを特徴とする付記７または８に記載の情報統合装置。
（付記１６）
前記記憶手段は、
前記物理モデルを前記情報源側に存在するデータストリームに割り付ける事前設定情報を記憶しており、
前記第３の統合手段は、
前記事前設定情報に基づいて、前記情報源側に存在するデータストリームから統合対象となる前記物理モデルでの情報を取得し、取得された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第３の統合処理を実行することを特徴とする付記９に記載の情報統合装置。
（付記１７）
前記記憶手段は、
前記論理モデルを前記利用側に存在するデータストリームに割り付ける事前設定情報を記憶しており、
前記出力手段は、
前記事前設定情報に基づいて、前記統合結果を前記利用側に存在するデータストリームに送出することを特徴とする付記７，８または１５に記載の情報統合装置。
（付記１８）
前記記憶手段は、
前記論理モデルを前記利用側に存在するデータストリームに割り付ける事前設定情報を記憶しており、
前記出力手段は、
前記制御手段によって前記第１の統合処理または、前記第３の統合処理が実行された場合、前記事前設定情報に基づいて、前記統合結果を前記利用側に存在するデータストリームに送出することを特徴とする付記９または１６に記載の情報統合装置。
（付記１９）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記第１の統合手段は、
前記物理モデルでの情報を前記マッピング定義を参照することにより前記論理モデルでの情報に統合する処理において、前記物理モデルでの情報を入力側として前記クレンジングを順次行い、最終的に前記論理モデルでの情報を出力側として前記クレンジングを行うことを特徴とする付記１に記載の情報統合装置。
（付記２０）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記第２の統合手段は、
前記収集手段によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する処理において、前記物理モデルでの検索結果を入力側として前記クレンジングを順次行い、最終的に前記論理モデルでの検索結果を出力側として前記クレンジングを行うことを特徴とする付記１に記載の情報統合装置。
（付記２１）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記統合手段は、
前記抽出手段によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する処理において、前記物理モデルでの情報を入力側として前記クレンジングを順次行い、最終的に前記論理モデルでの情報を出力側として前記クレンジングを行うことを特徴とする付記２に記載の情報統合装置。
（付記２２）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記分解手段は、
前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解する処理において、前記論理モデルでの検索式を入力側として前記クレンジングを順次行い、最終的に前記物理モデルでの検索式を出力側として前記クレンジングを行うことを特徴とする付記３に記載の情報統合装置。
（付記２３）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記統合手段は、
前記収集手段によって収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する処理において、前記物理モデルでの検索結果を入力側として前記クレンジングを順次行い、最終的に前記論理モデルでの検索結果を出力側として前記クレンジングを行うことを特徴とする付記３に記載の情報統合装置。
（付記２４）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記第１の統合手段は、
前記情報源側の前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合処理において、前記物理モデルでの情報を入力側として前記クレンジングを順次行い、最終的に前記論理モデルでの情報を出力側として前記クレンジングを実行することを特徴とする付記４に記載の情報統合装置。
（付記２５）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記第２の統合手段は、
前記利用側の前記論理モデルでの検索式を前記物理モデルでの検索式に分解する処理において、前記論理モデルでの検索式を入力側として前記クレンジングを順次行い、最終的に前記物理モデルでの検索式を出力側として前記クレンジングを行い、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理を実行することを特徴とする付記４に記載の情報統合装置。
（付記２６）
前記物理モデルおよび前記論理モデルは、項目のデータ型と、値の性質を示す型属性についてその値である型属性値をメタ定義として有し、入力側と出力側とで前記メタ定義の前記データ型または対応する前記型属性値が異なる場合に、前記入力側の前記データ型として入力された値を前記出力側の前記データ型に変換して出力し、または、前記入力側の前記型属性値として入力された値を前記出力側の前記型属性値の性質を有する値に変換して出力するクレンジング手段を備え、
前記第２の統合手段は、
前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理において、前記物理モデルでの検索結果を入力側として前記クレンジングを順次行い、最終的に前記論理モデルでの検索結果を出力側として前記クレンジングを実行することを特徴とする付記４に記載の情報統合装置。
（付記２７）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータが、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出する抽出工程と、
前記抽出工程によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合工程と、
前記第１の統合工程によって統合された結果、前記マッピング定義において未解決の項目がある場合、前記第１の統合工程によって統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの情報を検索する検索式を生成する生成工程と、
前記生成工程によって生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集工程と、
前記収集工程によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合工程と、
前記第１および第２の統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行することを特徴とする情報統合方法。
（付記２８）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータが、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出する抽出工程と、
前記抽出工程によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する統合工程と、
前記統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行することを特徴とする情報統合方法。
（付記２９）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータが、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解する分解工程と、
前記分解工程によって分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集工程と、
前記収集工程によって収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する統合工程と、
前記統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行することを特徴とする情報統合方法。
（付記３０）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータが、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出し、抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合処理を実行する第１の統合工程と、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理を実行する第２の統合工程と、
統合指示を検出する検出工程と、
前記検出工程によって検出された統合指示が、前記情報源側からの抽出により前記利用側に統合結果を出力する第１の統合指示である場合、前記第１の統合処理を実行し、前記利用側からの問い合わせにより当該問い合わせの結果を前記利用側に返す第２の統合指示である場合、前記第２の統合処理を実行するように制御する制御工程と、
前記制御工程によって実行された第１または第２の統合処理による統合結果を前記利用側に出力する出力工程と、
を実行することを特徴とする情報統合方法。
（付記３１）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータに、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出する抽出工程と、
前記抽出工程によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合工程と、
前記第１の統合工程によって統合された結果、前記マッピング定義において未解決の項目がある場合、前記第１の統合工程によって統合された第１の統合結果を検索条件として、前記情報源側の情報のうち前記未解決の項目での前記論理モデルに対応する前記物理モデルでの情報を検索する検索式を生成する生成工程と、
前記生成工程によって生成された検索式で前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集工程と、
前記収集工程によって収集された前記物理モデルでの検索結果を、前記未解決の項目に関連するマッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合工程と、
前記第１および第２の統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行させることを特徴とする情報統合プログラム。
（付記３２）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータに、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出する抽出工程と、
前記抽出工程によって抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する統合工程と、
前記統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行させることを特徴とする情報統合プログラム。
（付記３３）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータに、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解する分解工程と、
前記分解工程によって分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集する収集工程と、
前記収集工程によって収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する統合工程と、
前記統合工程によって統合された統合結果を前記利用側に出力する出力工程と、
を実行させることを特徴とする情報統合プログラム。
（付記３４）
情報源側のデータモデルである物理モデルと、統合された情報を利用する利用側のデータモデルである論理モデルと、前記物理モデルおよび前記論理モデル間の対応関係を示す項目群からなるマッピング定義と、を記憶する記憶手段にアクセス可能なコンピュータに、
前記情報源側から前記情報源側の前記物理モデルでの情報を抽出し、抽出された前記物理モデルでの情報を、前記マッピング定義を参照することにより前記論理モデルでの情報に統合する第１の統合処理を実行する第１の統合工程と、
前記マッピング定義を参照することにより、前記利用側の前記論理モデルでの検索式を、前記物理モデルでの検索式に分解し、分解された前記物理モデルでの検索式に基づいて前記情報源側を検索することにより、前記物理モデルでの検索結果を収集し、収集された前記物理モデルでの検索結果を、前記マッピング定義を参照することにより前記論理モデルでの検索結果に統合する第２の統合処理を実行する第２の統合工程と、
統合指示を検出する検出工程と、
前記検出工程によって検出された統合指示が、前記情報源側からの抽出により前記利用側に統合結果を出力する第１の統合指示である場合、前記第１の統合処理を実行し、前記利用側からの問い合わせにより当該問い合わせの結果を前記利用側に返す第２の統合指示である場合、前記第２の統合処理を実行するように制御する制御工程と、
前記制御工程によって実行された第１または第２の統合処理による統合結果を前記利用側に出力する出力工程と、
を実行させることを特徴とする情報統合プログラム。
【符号の説明】
【０３２４】
１００  情報統合システム
１０１  統合エンジン（情報統合装置）
１０２  制御機能（制御手段）
１０３  メタ情報
１１０  情報源
１２０  利用側
１３１  抽出機能（抽出手段）
１３２  収集機能（収集手段）
１３３  取得機能（取得手段）
１４０  情報出力機能（出力手段）
１４１  登録機能（登録手段）
１４２  提供機能（提供手段）
１４３  送出機能（送出手段）
２０１  問合わせ分解機能（問合わせ分解手段）
２０２  結果統合機能（結果統合手段）
【図１】
0005471086.tif 000002
【図２】
0005471086.tif 000003
【図３】
0005471086.tif 000004
【図４】
0005471086.tif 000005
【図５】
0005471086.tif 000006
【図６】
0005471086.tif 000007
【図７】
0005471086.tif 000008
【図８】
0005471086.tif 000009
【図９】
0005471086.tif 000010
【図１０】
0005471086.tif 000011
【図１１】
0005471086.tif 000012
【図１２】
0005471086.tif 000013
【図１３】
0005471086.tif 000014
【図１４】
0005471086.tif 000015
【図１５】
0005471086.tif 000016
【図１６】
0005471086.tif 000017
【図１７】
0005471086.tif 000018
【図１８】
0005471086.tif 000019
【図１９】
0005471086.tif 000020
【図２０】
0005471086.tif 000021
【図２１】
0005471086.tif 000022
【図２２】
0005471086.tif 000023
【図２３】
0005471086.tif 000024
【図２４】
0005471086.tif 000025
【図２５】
0005471086.tif 000026
【図２６】
0005471086.tif 000027
【図２７】
0005471086.tif 000028
【図２８】
0005471086.tif 000029
【図２９】
0005471086.tif 000030
【図３０】
0005471086.tif 000031
【図３１】
0005471086.tif 000032
【図３２】
0005471086.tif 000033
【図３３】
0005471086.tif 000034
【図３４】
0005471086.tif 000035
【図３５】
0005471086.tif 000036
【図３６】
0005471086.tif 000037
【図３７】
0005471086.tif 000038
【図３８】
0005471086.tif 000039
【図３９】
0005471086.tif 000040
【図４０】
0005471086.tif 000041
【図４１】
0005471086.tif 000042
【図４２】
0005471086.tif 000043
【図４３】
0005471086.tif 000044
【図４４】
0005471086.tif 000045
【図４５】
0005471086.tif 000046
【図４６】
0005471086.tif 000047
【図４７】
0005471086.tif 000048
【図４８】
0005471086.tif 000049
【図４９】
0005471086.tif 000050
【図５０】
0005471086.tif 000051
【図５１】
0005471086.tif 000052
【図５２】
0005471086.tif 000053
【図５３】
0005471086.tif 000054
【図５４】
0005471086.tif 000055
【図５５】
0005471086.tif 000056
【図５６】
0005471086.tif 000057
【図５７】
0005471086.tif 000058
【図５８】
0005471086.tif 000059
【図５９】
0005471086.tif 000060
【図６０】
0005471086.tif 000061
【図６１】
0005471086.tif 000062
【図６２】
0005471086.tif 000063
【図６３】
0005471086.tif 000064
【図６４】
0005471086.tif 000065
【図６５】
0005471086.tif 000066
【図６６】
0005471086.tif 000067
【図６７】
0005471086.tif 000068
【図６８】
0005471086.tif 000069
【図６９】
0005471086.tif 000070
【図７０】
0005471086.tif 000071
【図７１】
0005471086.tif 000072
【図７２】
0005471086.tif 000073
【図７３】
0005471086.tif 000074
【図７４】
0005471086.tif 000075
【図７５】
0005471086.tif 000076
【図７６】
0005471086.tif 000077
【図７７】
0005471086.tif 000078
【図７８】
0005471086.tif 000079
【図７９】
0005471086.tif 000080
【図８０】
0005471086.tif 000081
【図８１】
0005471086.tif 000082
【図８２】
0005471086.tif 000083
【図８３】
0005471086.tif 000084
【図８４】
0005471086.tif 000085
【図８５】
0005471086.tif 000086
【図８６】
0005471086.tif 000087
【図８７】
0005471086.tif 000088
【図８８】
0005471086.tif 000089
【図８９】
0005471086.tif 000090
【図９０】
0005471086.tif 000091
【図９１】
0005471086.tif 000092
【図９２】
0005471086.tif 000093
【図９３】
0005471086.tif 000094
【図９４】
0005471086.tif 000095
【図９５】
0005471086.tif 000096
【図９６】
0005471086.tif 000097
【図９７】
0005471086.tif 000098
【図９８】
0005471086.tif 000099
【図９９】
0005471086.tif 000100
【図１００】
0005471086.tif 000101
【図１０１】
0005471086.tif 000102
【図１０２】
0005471086.tif 000103
【図１０３】
0005471086.tif 000104
【図１０４】
0005471086.tif 000105
【図１０５】
0005471086.tif 000106
【図１０６】
0005471086.tif 000107
【図１０７】
0005471086.tif 000108
【図１０８】
0005471086.tif 000109
【図１０９】
0005471086.tif 000110
【図１１０】
0005471086.tif 000111