"異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、前記情報源に存在するデータのデータ構造を定義したデータモデル以下物理モデルというと、前記複数の情報源に存在するデータを収集して統合されたデータのデータ構造を定義したデータモデル以下論理モデルというと、前記論理モデルと前記物理モデルまたは前記論理モデルとのデータ構造の対応関係を定義したマッピング定義情報を記憶した記憶部と、利用側アプリケーションから前記論理モデルに対する検索条件を受信し、該受信した検索条件を前記物理モデル、前記論理モデル、および前記マッピング定義情報から物理モデルに対する検索条件に変換する第一変換部と、前記第一変換部によって変換された前記物理モデルへの検索条件に一致するデータを前記情報源から収集する収集部と、前記収集した物理モデルのデータを前記物理モデル、前記論理モデル、及び前記マッピング定義情報に基づいて論理モデルのデータに変換する第二変換部と、前記第二変換部によって変換された論理モデルのデータを出力する出力部と、を備えたことを特徴とするデータ統合装置。前記物理モデルは、前記情報源のデータ構造に基づいて定義される表の名前以下表名というごとに、項目を示すデータ列の名前以下列名というと当該項目のデータ値の型以下データ型というから構成されるデータモデルであり、前記論理モデルは、利用側アプリケーションごとに定義した統合された表の構造として、表名ごとに列名とデータ型から構成されるデータモデルであり、前記第一変換部は、前記論理モデルに対する検索条件を前記物理モデルへの検索条件に変換する際に、対応するデータ列間で前記データ型が相違する場合には、当該データ型を合わせるデータ型変換処理を実行し、前記第二変換部は、前記収集部によって収集された前記物理モデルのデータを前記マッピング定義情報に基づいて前記論理モデルのデータに変換する際に、対応するデータ列間で前記データ型が相違する場合には、当該データ型を合わせるデータ型変換処理を実行することを特徴とする請求項1に記載のデータ統合装置。前記第一変換部は、前記論理モデルに対する検索条件を前記物理モデルへの検索条件に変換する際に、対応するデータ列間で前記データ型の属性が相違する場合には、当該データ型の属性を合わせるクレンジング処理を実行し、前記第二変換部は、前記収集部によって収集された前記物理モデルのデータを前記マッピング定義情報に基づいて前記論理モデルのデータに変換する際に、対応するデータ列間で前記データ型の属性が相違する場合には、当該データ型の属性を合わせるクレンジング処理を実行することを特徴とする請求項2に記載のデータ統合装置。しかしながら、従来のシステムにあっては、以下のような問題点があった。すなわち、統合されたマスターDB2250を設けるため、利用側システムのアプリケーションは自システムが管理している表だけでなく、マスターDB2250についても、情報の所在と情報の参照および更新を意識して取り扱う必要がある。そのため、アプリケーションの改修が必要であったり、アプリケーションの内容が複雑化する要因の一つともなっているという問題点があった。また、情報の更新をおこなう際には、自システムの情報とマスターDB2250の情報を同期して矛盾なく更新する制御が必要となるという問題点があった。この制御は、自システムとマスターDB2250についてトランザクションの制御をおこない、処理が失敗したときにはロールバックするなどの処理をアプリケーションによって実現する必要があるという問題点があった。これによって、アプリケーションへの負担が増加することになる。また、利用側システムの更新時に参照したデータや、更新対象のデータは、中途半端な状態他のアプリケーションが操作中で値が確定していない状態にある場合があり、それを防止するためには更新に関わるデータに対する何らかのロック制御が必要となる。また、サブシステム間に跨るロック制御をおこなうことによって、システム全体の性能を低下させしまうという問題点があった。たとえば、甲サブシステムがマスターテーブルM2251統合DBをロックしている間は、他のシステムから統合DBを利用することができないため、他のシステムは甲サブシステムの処理トランザクションが完了するのを待たされることになる。また、各サブシステムの変更によって、統合DBで管理しているデータに追加や変更が発生する場合もあり、この際には変更が発生した統合DBのテーブルを使用しているすべてのサブシステムについて、アプリケーションの変更が必要になるケースも多い。さらに、個々のサブシステムの都合で統合DBで管理しているデータの追加が発生するために、結果として統合DBが肥大化する傾向がある。このように、統合DBへの集中と統合DBの肥大化が生じ、また、統合DBへのアクセスが増加するために、統合DBの参照更新性能が劣化するとともに、各アプリケーションが複雑化し、統合DBの影響が各サブシステムに伝搬してしまうという問題があった。この発明は、上述した従来技術による問題点を解消するため、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合する際に、各システムの負荷を軽減することが可能なデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体を提供し、理想的なEIIおよびその応用としてのMDMを実現することを目的とする。上述した課題を解決し、目的を達成するため、この発明にかかるデータ統合装置は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、前記情報源から、各情報源側のデータモデル以下物理モデルというのままでデータの収集をおこなうデータ収集手段と、前記データ収集手段によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル以下論理モデルというになるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換手段と、前記データ変換手段によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供手段と、を備えたことを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記データ収集手段が、前記利用側アプリケーションからの要求に基づいて、リアルタイムに前記情報源からのデータの収集をおこなうこと特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記情報源のシステム側に設けられた前記データのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータのメタ情報に基づく仮想統合データベースを作成する仮想統合データベース作成手段を備え、前記データ変換手段が、前記仮想統合データベース作成手段によって作成された仮想統合データベースに含まれるメタ情報に基づいて、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうことを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記情報源のシステム側に設けられた前記データのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータからなる複製データベースを作成する複製データベース作成手段と、前記複製データベース作成手段によって作成された複製データベースを、前記マスターデータの更新に対応して更新する複製データベース更新手段と、を備え、前記データ収集手段が、前記複製データベースからデータの収集をおこなうことを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記物理モデルまたは前記論理モデルを表すメタ情報として、少なくとも表の名前、データ列の名前、データ値の型を定義することを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記メタ情報として、前記データ値の型に関する詳細を属性として示す型属性を定義し、前記変換手段が、前記データ値を変換する際に前記型属性が相違する場合に、当該型属性を合わせる処理をおこなうことを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記物理モデルまたは前記論理モデルを表すメタ情報として、データ列の制約を定義することを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記変換手段が、前記物理モデルと前記論理モデルとの間に、データの変換をおこなう中間テーブルを定義し、物理モデルとして収集したデータを中間テーブルで変換した結果を論理モデルに統合することを特徴とする。また、この発明にかかるデータ統合装置は、上記の発明において、前記変換手段が、前記データ値の変換として、文字コード系の違いを変換する文字コード系変換処理、空白除去、全角半角変換を含む文字列の正規化をおこなう文字列変換処理、文字や数字の単位の違いを変換する単位変換処理、年号の西暦和暦の違いを変換する年号表記変換処理、数字表現として漢数字/アラビア数字/ローマ数字と数値の違いを変換する漢数字表記変換処理、数字の有効桁を揃える有効桁変換処理、データ型間の変換処理の少なくともいずれか一つをおこなうことを特徴とする。また、この発明にかかるデータ統合方法は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置を含むシステムにおけるデータ統合方法であって、前記情報源から、各情報源側のデータモデル以下物理モデルというのままでデータの収集をおこなうデータ収集工程と、前記データ収集工程によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル以下論理モデルというになるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換工程と、前記データ変換工程によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供工程と、を含んだことを特徴とする。また、この発明にかかるデータ統合方法は、上記の発明において、前記情報源に存在するデータをそれぞれマスターデータとし、前記マスターデータのうち、他のシステムに公開するデータを前記データ統合装置に登録し、前記利用側アプリケーションは、前記データ統合装置に登録されたデータのうち、あらかじめ利用するデータを論理モデルとして前記データ統合装置に定義し、必要なときに前記論理モデルを検索することによって、前記データ統合装置に登録されたデータを論理モデルとして参照し、他のシステムのデータを更新する場合には、該当データをマスターデータとして管理しているシステムに対して、当該データに対する更新依頼を実施することを特徴とする。また、この発明にかかるコンピュータ読み取り可能に記録する記録媒体は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置において実行されるデータ統合プログラムであって、前記情報源から、各情報源側のデータモデル以下物理モデルというのままでデータの収集をおこなうデータ収集工程と、前記データ収集工程によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル以下論理モデルというになるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換工程と、前記データ変換工程によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供工程と、をコンピュータに実行させるデータ統合プログラムを記録することを特徴とする。この発明によれば、情報源の改造を不要とし、利用側アプリケーションの負荷を軽減することができるデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体が得られるという効果を奏する。以下に添付図面を参照して、この発明にかかるデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体の最適な実施の形態を詳細に説明する。図1は、この発明にかかるEIIの全体構成を示す説明図である。図1において、101はデータ統合装置以下EIIというであり、統合エンジン110を備え、物理モデル111と、論理モデル112からなるデータ記憶機能を備える。また、EII101は、サービスバス102を介してあるいは直接に、Back系システム情報源103およびFront系システム利用アプリケーション104と接続されている。EII101は、物理モデル111から論理モデル112へのデータ構造の変換処理マッピングおよびデータ値の変換処理クレンジングを実行する統合エンジン110を備えている。また、表の名前、データ列の名前、データの型を定義し、データの型には型の詳細を定義する型属性を定義でき、さらに、主キー制約、従属キー制約などのデータ列の制約を定義できるメタ情報リポジトリ116を備え、メタ情報整備機能117によりメタ情報の整備を実行する。このメタ情報の整備によって、上記マッピング、クレンジングの確実性、効率性の向上を図っている。なお、上記各機能は、EII101を構成するコンピュータシステムにおいて、図示を省略するRAM、ROMなどのメモリに記録されたプログラムをCPUが実行することによって実現することができる。また、本実施の形態において記載されているデータベースDBはそれぞれ、各コンピュータシステムにおける図示を省略するハードディスクなどのデータ記録媒体に記録されるデータと、データベース管理ソフトウエアDBMSによってその機能を実現することができる。図2-1および図2-2は、この発明にかかるEIIの原理を示す説明図である。図2-1において、201は甲サブシステムであり、202は乙サブシステムであり、203は丙サブシステムである。甲サブシステム201は、テーブルA211およびテーブルB212を有する甲データベースDB210を備えており、乙サブシステム202は、テーブルC221を有する乙データベースDB220を備えており、丙サブシステム203は、テーブルD231を有する丙データベースDB230を備えている。各サブシステムの情報、すなわち甲DB210、乙DB220、丙DB230の情報をマスターとする。これによって、サブシステムごとに独立したデータ管理をおこなう。また、マスターDB甲DB210、乙DB220、丙DB230の中で共有したい情報をEII101に公開する。これによって、各サブシステムは自分の全情報を管理することができる。図2-1、図2-2にあっては、テーブルA211はA1~A5のデータ列からなるが、物理モデル111のテーブルA241は、A1、A3、A4のみの情報が仮想的に存在する。このことから、テーブルA211に関しては、A1、A3、A4のみを共有し、A2、A5は共有しないことを示していることがわかる。ここで、仮想統合では必要になった時点でマスターDB210,220,230から情報を収集して統合する。また、物理統合ではEII101上にあらかじめマスターDBのレプリカ240を置く、すなわち情報のレプリケーションをおこなう。また、EII101は統合結果を利用アプリケーションに提供する機能を提供する。図2-1、図2-2では、論理モデル112として、乙システム専用のテーブルMC251として統合結果を参照することができるようになっている。物理モデル111から論理モデル112への変換統合処理に関する詳細は後述する。また、図2-1において、実線は表の実体を示し、破線は仮想的な表を示す。したがって、甲DB210のテーブルA211、テーブルB212、乙DB220のテーブルC221、丙DB230のテーブルD231およびレプリカテーブルD’245は実線で示してあり、物理モデル111の各テーブル241~243、論理モデル112のテーブルMC251は波線で示している。図2-2においても同様であり、241~244は、レプリカであるので、実線で示している。ここで、機能-Xおよび機能-Yの動作について検証する。この機能-Xおよび機能-Yの動作およびこれらの動作の対象となるテーブルA211、テーブルB212、テーブルC221は、図22、図23において示した従来技術における機能-Xおよび機能-Yの動作およびこれらの動作の対象となったテーブルA2211、テーブルB2212、テーブルC2221と同じにしてある。図2-1は、この発明にかかるEIIの原理として、仮想統合の一例を示す説明図である。まず、甲サブシステム201における機能-XであるテーブルAのカラムA1,A2,A3,A4を更新する1を実行する。そこで、甲サブシステム201は、甲DB210のA1、A2、A3、A4について更新する。つぎに、A2、A3の合計をテーブルBのB4に書込む2を実行する。そこで、甲サブシステム201は、テーブルA211にあるA2とA3の合計をテーブルB212のB4に書き込む。このように、データ統合の実施前に実現されていたサブシステム内の処理は、更新処理を含めて、サブシステムに閉じたトランザクションとして独立して完結している。これらの処理は、データ統合の実施前から甲サブシステムの機能として実現していたものであり、データ統合の実施によるサブシステムの改良は不要であることを示している。特にデータ更新に関わる処理がサブシステム内に閉じているので、ロールバック、すなわちトランザクションの処理中に何か異常が起こり、正常に処理を完了できない場合、関連する処理を中止し、関連する情報を処理前の状態に戻さなければならない場合にも、簡単かつ確実にロールバックを実行することができるという効果を奏する。したがって、アプリケーションの負担が軽く、アプリケーションの変更による影響がサブシステム外部に及ばないという効果も奏する。つぎに、乙サブシステム202における機能-YであるテーブルMCのB4を参照してC4を更新3を実行する。そこで、乙サブシステム202はEII101の論理モデル112として管理されているテーブルMCに対してB4を要求する。EII101は甲DB210のB4を参照して、その結果をテーブルMCのB4として乙サブシステム202に回答する。乙サブシステム202は回答の結果に基づいてC4を更新する。したがって、仮想統合では利用システムから要求された時点で、情報源からのデータ収集を実施するために、その時点における最新の情報であることを保証することができる。また、データ収集に際して情報源である甲サブシステム201の参照負荷が生じるが、図23に示した従来技術の更新時のトランザクション負荷と比較すると大幅に軽減される。このように、この発明の実施の形態にかかるデータ統合装置EII101は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するに際し、情報源たとえば甲DB210から、各情報源側のデータモデル物理モデル111のままでデータの収集をおこない、収集されたデータを、当該データの利用側アプリケーションたとえば乙サブシステム202ごとにあらかじめ定義されたデータモデル論理モデル112になるように、データ構造およびデータ値の少なくともいずれか一方の必要な変換をおこない、変換されたデータを利用側アプリケーションへ提供するものである。また、利用側アプリケーションからの要求に基づいて、リアルタイムに情報源からのデータの収集をおこなう。また、サブシステム側に設けられたデータのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータのメタ情報を含む仮想統合データベーステーブル241~243を作成し、作成された仮想統合データベースに含まれるメタ情報に基づいて、データ構造およびデータ値の少なくともいずれか一方の変換マッピング、クレンジングをおこなうものである。図2-2は、この発明にかかるEIIの原理として、物理統合の一例を示す説明図である。図2-2では、図2-1における情報源側サブシステムの参照負荷を軽減するために、各情報源側サブシステムのDBに、DBの更新をトランザクション単位で記録するジャーナルを設け、このジャーナルを用いて、統合DBのレプリカに対して情報源の更新を反映するように構成する。図2-2において、機能-XのテーブルAのカラムA1,A2,A3,A4を更新する1、A2、A3の合計をテーブルBのB4に書込む2を図2-1と同様にそれぞれ実行すると、トランザクション単位で、甲DBの更新記録がジャーナル261として生成される。このジャーナル261を用いてEII101に甲DBの更新を通知するとともに、EII101上のレプリカ240のテーブルA241、テーブルB242に反映することにより、情報源としての甲DB210とEII101上のレプリカ240の同期を実現する。乙サブシステム202も、図2-1と同様にEII101の論理モデル112にアクセスしてテーブルMCのB4を取得してC4を更新する。このとき、EII101はレプリカ240のテーブルB242に保持されているB4を参照して、乙システムに回答するだけでよい。このように物理統合では、利用システム図2-2では乙サブシステム202からのアクセス性能が高く、情報源図2-2では甲サブシステム201への負荷が最小で済むという効果を奏する。また、情報源の停止時であってもレプリカで保有している停止直前の情報を利用することができるという効果を奏する。このように、この発明の実施の形態にかかるデータ統合装置EII101の物理統合は、各サブシステム側に設けられたマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータからなる複製データベースレプリカ240を作成し、作成された複製データベースを、マスターデータベースの更新と同期して更新するとともに、複製データベースからデータの収集をおこなうものである。つぎに、EII101におけるデータ統合の具体例について説明する。図3は、表の構造スキーマの一例を示す説明図である。図3において、301は表のスキーマであり、表名=表Aと各列の列名、型、制約を示しており、302は、上記301のスキーマに基づく実際の表Aを示している。すなわち、表Aの列名は従業員番号、氏名、電話番号からなる。各列が持つデータ値の型は、Integer整数型と、String文字列型とからなる。また、各データ値には型の詳細を定義するための情報として型属性を持つことができる。たとえば、Integer整数型において、型属性MaxLength=10とすることで、最大10桁の整数型であることを示すことができる。同様に、String文字列型において、型属性CharCode=S_JISとすることで、当該文字列の文字コードはシフトJISであることを示すことができる。また、各列の制約は、Mkey主キー制約とSkey従属キー制約とからなる。図3においては、従業員番号がInteger整数型であり、氏名および電話番号がString文字列型である。また、従業員番号はMkey主キー制約の制約があることを示している。図4は、統合エンジンのアーキテクチャ物理モデルの定義付けを示す説明図である。物理モデルの定義付けは、たとえば図1に示したメタ情報整備機能117のオペーレーションとして実行される。図4において、401はテーブル表A411を有する情報源システム1であり、402はテーブル表B412、表D413を有する情報源システム2であり、403はテーブル表A421からなる401に対応する物理モデル1であり、404はテーブル表B422および表D423からなる402に対応する物理モデル2である。ここで、EII101は各情報源システムのテーブルから、共有の対象となる表のスキーマを取得して、取得した情報に基づいて物理モデルを作成する。その際、登録された物理モデルに対して、不要列の削除、列名、型および型属性、制約などの修正をおこなう。図4において、表A411の住所列についての情報は、システム1が共有しないとしたものであるため、物理モデルから削除されている。表B412の内線番号列、表D413の内線列も同様である。図5は、統合エンジンのアーキテクチャマッピングの定義を示す説明図である。マッピングの定義は、たとえば図1に示したメタ情報整備機能117のオペーレーションとして実行される。マッピングの定義は、定義済みの物理モデルに基づいて、論理モデルを定義するものである。なお、図5におけるマッピング定義の前提条件としては、情報源は図4に示したシステム1物理モデル1403およびシステム2物理モデル2404であり、利用側はシステム3601が必要とする論理モデル3501,システム4602が必要とする論理モデル4502である。また、4つのシステムで従業員番号コードキーが同じものを使用しているものとする。図5においてまず、物理モデルの必要な項目を論理モデルにセットする。具体的には、物理モデル1の表A421から、従業員番号、氏名、電話番号を、物理モデル2の表B422から従業員番号、所属をそれぞれ、論理モデル3の表C511にセットする。ここで、複数の表たとえば表Aと表Bを結合するJOINときには、対象表のMkey制約列を論理モデルのMkey制約列につなぐことにより定義する。論理モデルには物理モデルから引き継いだ列名、型、型属性、制約が設定され、マッピング定義も自動に作成される。また、論理モデル4の表Eにセットする際に、特定の列を別の表により変換する場合は、間に中間テーブル表D423をつなぐことにより定義する。すなわち、表B422の所属は、所属コードを表すIntegerであるが、それを中間テーブルD423を用いて所属名称を表すStringに変換する。そして、論理モデル4の表E512では、所属列として変換結果であるStringをセットする。これは、対象表のSkeyを中間テーブルのMkeyにつなぎ、変換先の列を論理モデルにつなぐことにより定義される。つぎに、論理モデルに対して必要な修正をおこなう。たとえば、不要な列の削除ただし、Mkey制約を持つ列は削除できない、列名の変更、型の変更と型属性変更などである。たとえば、表D423の名称列はString文字列型で型属性としてCharCode=JEFは設定されているので、当初の論理モデル表E512の所属列は、列名=名称、データ型=文字列、型属性=CharCode=JEFとなっている。ここで、論理モデルとして必要な列に変更するために列名を所属に変更し、型属性をCharCode=S_JISに変更している。これらの変更は、マッピング定義、クレンジング定義に反映される。統合処理に必要なこれらのメタ情報は、リポジトリ116に格納され、必要なときに統合エンジン110から利用される。図6は、統合エンジンのアーキテクチャ問い合わせを示す説明図である。利用側のシステムシステム3たとえば内部の情報形式として表611を有する、システム4たとえば内部の情報形式として表612を有するは、あらかじめ準備されている論理モデル論理モデル3、論理モデル4に対して検索SQL文を発行して必要な情報を得ることができる。得た情報は各システムの内部表現と一致しているので、そのまま使用することがきる。ここで、システム4が表E512に対して、従業員番号7500の情報がほしい旨の要求を出した場合の実際の動作について、図7を用いて説明する。図7は、統合エンジンのアーキテクチャ実際の動作を示す説明図である。実際の統合処理は、たとえば図1に示した統合エンジン110において実行される。図7において、まず、論理モデル4の表E512について従業員番号=7500が検索条件になる。EIIは、求められた論理モデルに対する検索条件を、物理モデルに対する検索条件に変換する。これが、検索条件の導出逆変換処理である。論理モデル4の表E512の従業員番号列は物理モデル1の表A421の従業員番号、物理モデル2の表B422の従業員番号から求めることになっているので、表Aの従業員番号=7500、表Bの従業員番号=7500の検索条件を生成する。そして、表A421に検索文を実行して結果Aを得る。表A421の検索結果Aから、従業員番号列と氏名列を表E512にコピーする。これが結果の統合処理である。つぎに、物理モデル2の表B422に検索文を実行して検索結果Bを得る。表B422の検索結果Bから、所属列を持ってくるが、検索結果Bの所属列は所属コードになっているので、表D423を使って、名称に変換した結果を表E512の所属列の値にする。これは値の変換処理である。このとき、表D423の名称列がJEFコード文字列であるのに対して、表E512の所属列はシフトJIS文字列を要求しているのでJEF→シフトJIS変換のクレンジング機能詳細は後述するが動作して、その結果を表E512の所属列にコピーする。図8および図9は、統合エンジンのアーキテクチャクレンジングを示す説明図である。クレンジングは、値の複写が発生するときには型チェックがおこなわれ、複写元From型と複写先To型の間で型または型属性が異なっていれば、型または型属性に対応して必要な処理が実行される。図8は、型属性の違いによるクレンジングの一例である。図8において、双方のデータ型はString文字列型で一致しているが、型属性が異なるため、From型の型属性CharCode=JEFからTo型の型属性CharCode=S_JISに変換するために、JEFからシフトJISへ変換するクレンジング処理を実行し、その結果を複写先にコピーする。文字コード系変換文字列型以外に、型属性が異なるときに実行されるクレンジング機能としては、たとえば、文字列変換文字列型がある。具体的には、全空白除去、前後の空白除去、連続空白を1個に集約、タブ/空白変換、改行コード除去、改行コード変換、全角/半角変換、英大文字/英小文字変換、文字の置き換え置き換えテーブルを使用などがある。また、他のクレンジング機能としては、単位の変換3千円から3,000円へ、あるいはその逆文字列型/数値型、年号表記平成16年から2004年へ、あるいはその逆文字列型/数値型、漢数字表記十六から16へ、あるいはその逆文字列型/数値型、有効桁変換数値型、有効桁数の増加あるいは減少、有効文字数変換文字列型、有効文字数の増加あるいは減少などがある。図9は、型が異なるときに実行されるクレンジング機能の一例である。図9において、String文字列型であって、JEFコード文字列2000すべて全角で4文字のデータを、文字列から整数に変換するとともに、10桁以内の整数に変換するクレンジング処理を実行する。それによって、20004桁の整数のデータに変換する。このように、この発明の実施の形態にかかるデータ統合装置は、データ値の変換として、文字コード系の違いを変換する文字コード系変換処理、空白除去、全角半角変換を含む文字列の正規化をおこなう文字列変換処理、文字や数字の単位の違いを変換する単位変換処理、年号の西暦和暦の違いを変換する年号表記変換処理、数字表現として漢数字/アラビア数字/ローマ数字と数値の違いを変換する漢数字表記変換処理、数字の有効桁を揃える有効桁変換処理、データ型間の変換処理の少なくともいずれか一つをおこなうことができる。図10は、クレンジングの処理内容を示すフローチャートであり、図11は、図10に示したフローチャートの処理を実行する機能構成を示す説明図である。図10のフローチャートにおいて、まず、図11に示すFrom値1101のFrom型とTo値1102のTo型が同じか否かをクレンジング制御部1103によって判断するステップS1001。ここで、両者が同じ場合ステップS1001:Yesは、From型とTo型に共通する先頭の型属性をポイントするステップS1002。つぎに、型属性の値が同じか否かを判断するステップS1003。ここで、型属性の値が同じ場合ステップS1003:Yesは、From型とTo型に共通するつぎの型属性をポイントするステップS1004。そして、確認すべき型属性が未だあるか否かを判断しステップS1005、ある場合ステップS1005:Yesは、ステップS1003へ戻って、以後ステップS1003~S1005を繰り返し実行する。そして、確認すべき型属性がなくなった場合ステップS1005:Noは、一連のクレンジング処理を終了する。ステップS1001において、From型とTo型とが異なる場合ステップS1001:Noは、つぎに、データ型の変換が可能か否かを判断するステップS1006。ここで、データ型の変換が可能でない場合ステップS1006:Noは、クレンジング処理の失敗処理をおこなう。一方、データ型の変換が可能な場合ステップS1006:Yesは、つぎに、図11に示す型変換呼出し部1104によって型変換の呼出しがおこなわれ、図11に示す型変換処理部1105によって、該当する型変換処理を実行するステップS1007。そして、型変換処理は成功したか否かを判断するステップS1008。ここで、型変換処理が成功した場合ステップS1008:Yesは、ステップS1002へ移行する。一方、型変換処理が失敗した場合ステップS1008:Noは、クレンジング処理の失敗処理をおこなう。ステップS1003において、型属性の値が異なる場合ステップS1003:Noは、図11に示すクレンジング呼出し部1106によって型属性変換の呼出しがおこなわれ、該当するクレンジング機能があるか否かを判断するステップS1009。ここで、該当するクレンジング機能がない場合ステップS1009:Noは、クレンジング処理の失敗処理をおこなう。一方、該当するクレンジング機能がある場合ステップS1009:Yesは、図11に示すクレンジング処理部1107によって、該当するクレンジング処理を実行するステップS1010。そして、実行されたクレンジング処理は成功したか否かを判断するステップS1011。ここで、クレンジング処理が成功した場合ステップS1011:Yesは、ステップS1004へ移行する。一方、クレンジング処理が失敗した場合ステップS1011:Noは、クレンジング処理の失敗処理をおこなう。図12は、マッピングの処理内容を示すフローチャートである。図12のフローチャートにおいて、まず、論理モデルに対する検索式とマッピング定義によって、物理モデルの検索式を作成するステップS1201。この詳細な内容については後述図17のフロー1を参照する。つぎに、先頭の物理モデルの検索式をポイントしステップS1202、ポイントされた物理モデルに検索式を実行して該当するデータを取得するステップS1203。そして、検索が成功したか否かを判断し、検索が失敗した場合ステップS1204:Noは、マッピング失敗処理を実行する。一方、検索が成功した場合ステップS1204:Yesは、つぎに、検索結果の該当データを論理モデルにコピーするステップS1205。この詳細な内容についても後述図20のフロー2を参照する。そして、コピーが成功したか否かを判断しステップS1206、コピーが失敗した場合ステップS1206:Noは、マッピング失敗処理を実行する。一方、ステップS1206において、コピーが成功した場合ステップS1206:Yesは、つぎの検索式をポイントするステップS1207。そして、残りがあるか否かを判断しステップS1208、残りがある場合ステップS1208:Yesは、ステップS1203へ戻り、以後ステップS1203~S1208まで繰り返し実行する。ステップS1208において、残りがない場合ステップS1208:Noは、一連のマッピング処理を終了する。図13は、マッピング定義の一例を示す説明図であり、図14は、評価ポイントの一例を示す説明図であり、図15は、図13のマッピングの定義に基づくマッピング制御を示す説明図である。図13において、表E.氏名は表Eの氏名列を示しており、図13の括弧付数字1~6は、図15の1~6にそれそれ対応している。たとえば、図13の1に示すマッピング定義は、図15の表Aの該当データについて、その従業員番号列を表Eの従業員番号列に対応付ける複写することを示している。ここで、図136のように、中間テーブルによる変換にも対応するマッピング定義が作成される。このマッピング定義は論理モデルの表単位で作成され、その内容は評価ポイント順にソートされている。評価ポイントの導出根拠の一例を図14に示す。また、図16は、利用側アプリケーションから発行される検索条件の一例を示す説明図である。図17は、マッピングの処理内容S1201の詳細を示すフローチャートフロー1であり、図18は、図17で利用するマッピングの定義の一例を示す説明図である。図17のフローチャートにおいて、まず、図16に示す検索式で指定されている論理モデル表表Eのマッピング定義を取得して、解決済フラグをクリアするステップS1701。すなわち、図18の解決をすべて0にする。つぎに、マッピング定義のTo列を上から検索して、検索条件で指定されている列に対する最初のFrom列を求めるステップS1702。その際、解決フラグがあるマッピング定義はスキップする。たとえば図16に示す検索条件として指定されている表E従業員番号をTo列から検索して、From列として表A従業員番号を求める。そして、該当するFrom列を検索対象として、検索条件のクレンジングを実行するステップS1703。ステップS1703の詳細な内容については後述図21のフロー3を参照する。そして、From列は末端列か否かを判断するステップS1704。ここで、末端列とは、マッピング定義において、To列に存在しない列オリジナルのFrom列を意味する。ここで、From列が末端列ではない場合ステップS1704:Noは、つぎに、該当するFrom列を検索対象として、クレンジング結果を検索条件に設定して検索条件クレンジングの再処理をおこなうステップS1705。その後、ステップS1702へ戻る。たとえば、図18でFrom列の表D.名称に対する検索条件を導出した場合には、表D.名称がTo列6行目の要素に存在するため、再度表D.所属の検索式を導出する必要がある。この場合、再度表B.所属3行目のFrom要素の検索式に変換され、これが末端列となる。このステップS1702~S1705のループによって、中間テーブルによる変換など、多段階のマッピングに対応している。ステップS1704において、From列が末端列である場合ステップS1704:Yesは、該当するFrom列を検索対象として、クレンジング結果を検索条件とする検索式を作成するステップS1706。図19が、作成された検索式の一例である。そして、この検索で解決できるマッピング定義に解決フラグを立てるステップS1707。すなわち、図18の解決を1にする。ここで解決とは、検索結果のデータ列の複写により、該当するマッピングが実現できることを意味している。たとえば、図19の1行目の検索により、図15の14に対応するマッピングが解決されるので、図18の1行目と4行目の解決列を1に設定できる。つぎに、From列が末端列であるマッピング定義に未解決があるかすなわち、解決が0のものがあるか否かを判断するステップS1708。ここで、未だ、未解決がある場合ステップS1708:Yesは、ステップS1702に戻る。そして、ステップS1702~S1708を繰り返し実行する。ステップS1708において、未解決がない場合ステップS1708:Noは、フロー1の一連の処理を終了し、図12に示したステップS1202へ移行する。ここで、図18はこの状態ステップS1708において、未解決がない場合を示している。すなわち、From列が末端列であるマッピング定義1~4が全て解決済になっている。図20は、マッピングの処理内容S1205の詳細を示すフローチャートフロー2であり、論理モデルへの反映処理の内容を示す。図20のフローチャートにおいて、まず、該当データの先頭をポイントするステップS2001。つぎに、ポイントされたデータが直接論理モデルに反映することが可能か否かを判断するステップS2002。ここで、データが直接論理モデルに反映することが可能な場合ステップS2002:Yesは、クレンジングをおこなってから、結果を論理モデルにコピーするステップS2003。つぎに、コピーは成功したか否かを判断しステップS2004、コピーが失敗した場合ステップS2004:Noは、フロー2の処理が失敗であるとして、図12に示したフローチャートのステップS1206へ移行する。一方、コピーが成功した場合ステップS2004:Yesは、つぎの値をポイントするステップS2005。そして、残りはあるか否かを判断するステップS2006。ここで、残りがある場合ステップS2006:Yesは、ステップS2002へ戻る。一方、残りがない場合ステップS2006:Noは、フロー2の一連の処理を終了し、図12に示したフローチャートのステップS1206へ移行する。ステップS2002において、データを直接論理モデルに反映することが可能ではない場合ステップS2002:Noは、対象のデータ値を検索条件とし、該当する中間テーブルの列を検索対象として、検索条件のクレンジングを実行するステップS2007。この処理の詳細な内容については後述図21を参照する。そして、クレンジングが成功したか否かを判断しステップS2008、失敗した場合ステップS2008:Noは、フロー2の処理が失敗であるとして、図12に示したフローチャートのステップS1206へ移行する。つぎに、中間テーブルを検索しステップS2009、検索は成功したか否かを判断するステップS2010。ここで、失敗した場合ステップS2010:Noは、フロー2の処理が失敗であるとして、図12に示したフローチャートのステップS1206へ移行する。一方、成功した場合ステップS2010:Yesは、ポイントしている値を検索結果で置き換えステップS2011、その後、ステップS2002へ戻る。このS2007~S2011で中間テーブルによるデータ値の変換処理を実現している。図21は、マッピングの処理内容S2007,S1703の詳細を示すフローチャートであり、検索条件のクレンジング処理の内容を示す。図21のフローチャートにおいて、まず、検索条件を型および型属性とともにFrom値に設定し、検索対象表の列をTo値に設定するステップS2101。つぎに、クレンジングを実行するステップS2102。そして、クレンジングが成功したか否かを判断するステップS2103。ここで、クレンジングが失敗した場合ステップS2103:Noは、フロー3の処理が失敗であるとして、図20に示したフローチャートのステップS2008または、図17に示したフローチャートのステップS1704へ移行する。一方、クレンジングが成功した場合ステップS2103:Yesは、クレンジング結果To値を型および型属性とともに、検索条件に設定するステップS2104。それによって、一連の処理を終了し、図20に示したフローチャートのステップS2008または、図17に示したフローチャートのステップS1704へ移行する。これらのフローチャート中で実行されている値のクレンジング処理S2003,S2102は、図10で説明済みのクレンジング処理により実現するものである。以上説明したように、この発明によれば、別々に管理されている複数の情報源103に存在するデータを収集して統合するに際して、情報源103からのデータ収集は、各情報源側のデータモデル物理モデル111でおこない、統合処理は各利用側アプリケーション104ごとにあらかじめ定義されたデータモデル論理モデル112に向けてデータ構造を変換する処理マッピングおよび各値を揃えるように変換する処理クレンジングをおこない、結果を各アプリケーションごとのビュー論理モデル112として利用側アプリケーションに提供することによって、情報源103側の改造を不要とし、利用側アプリケーション104の負担を軽減することができる。また、この発明によれば、利用側アプリケーション104から要求された時点でリアルタイムに情報源103からの情報収集をおこない、データ統合処理を実行して結果を利用側アプリケーション104に提供することにより、リアルタイムな統合結果を提供する、いわゆる仮想統合を実現することができる。また、この発明によれば、あらかじめ情報源103の公開する情報に限定した複製であるレプリカ240複製データベースをEII101側に作成しておき、情報源103の更新に同期して、トランザクション単位の差分をレプリカ240複製データベースに適用しておき、利用側アプリケーション104からの要求に対してはレプリカ240からデータを収集して統合して、結果を利用側アプリケーション104に提供する、いわゆる物理統合を実現することによって、情報源103へのアクセス負荷を軽減し、情報源104の停止時間でも停止直前のデータを利用したデータ統合を実現することができる。また、この発明によれば、情報源103で管理されているデータの性質および運用形態に合わせて、情報源103または表ごとに、上記仮想統合または上記物理統合を選択可能とすることによって、最適なデータ統合を実現することができる。また、この発明によれば、各情報源103側の形式物理モデル111および各利用側アプリケーション104の形式論理モデル112を表すメタ情報として、少なくとも表の名前、データ列の名前、データの型を定義し、データの型には型の詳細を定義する型属性を定義できるように構成する。そして、各データの値を物理モデル111から論理モデル112に変換するクレンジング処理では、データ型が異なるときには複写元をFrom型、複写先をTo型として、From型のデータ値をTo型のデータ値に変換する型変換機能を実行し、型属性に差があるときには型属性を合わせるクレンジング処理を実行することによって、きめ細かいクレンジングを効率よく実行することができる。また、この発明によれば、上記メタ情報として主キー制約、従属キー制約などのデータ列の制約を併せて定義し、物理モデル111の表および列から論理モデル112の表および列への対応関係を示すマッピング定義を定義するように構成し、利用側アプリケーション104から要求された論理モデル112の表に対する検索条件式からマッピング定義に基づいて、対応する物理モデル111の検索条件式を作成する。この検索条件式の作成は、マッピング定義の評価関数で評価された順に実行し、その検索条件は論理モデル112側をFrom型、物理モデル111側をTo型として統合と逆方向のクレンジング処理をおこない、これらにより生成された検索条件式により各情報源103物理モデル111からデータの収集をおこない、収集したデータはマッピング定義とデータ値の型および型属性定義に基づいて、マッピングおよびクレンジングをおこない、論理モデル112のデータに統合し、利用側アプリケーション104に提供することができる。また、この発明によれば、マッピング定義として、利用側アプリケーション104のシステムが要求する論理モデル112と、情報源103側の形式としての物理モデル111の間に、データの変換をおこなう中間テーブルたとえば図5などに示した表D423を定義できるように構成し、物理モデル111として収集したデータを中間テーブルで変換した結果を論理モデル112に統合することによって、より差の大きいデータモデル間の統合を可能とする。また、この発明によれば、クレンジングは、文字コード系の違いを変換する文字コード系変換処理、空白除去や全角半角変換などの文字列の正規化をおこなう文字列変換機能、文字や数字の単位の違いを変換する単位変換機能、年号の西暦和暦などの違いを変換する年号表記変換、数字表現として漢数字/アラビア数字/ローマ数字と数値の違いを変換する漢数字表記変換、数字の有効桁を揃える有効桁変換、データ型間の変換機能のいずれかが可能となる。また、この発明によれば、複数のシステムに独立して管理されているマスターデータを管理するに際し、マスターデータはあくまでも各システムで各アプリケーションが独立して管理をおこない、各マスターデータの中で、他のシステムに有用なデータをマスターデータの形式である物理モデル111として、EII101に対してデータ公開の定義をおこない、利用側アプリケーション104の各システムはそれそれのアプリケーションにとって使いやすいデータ形式を論理モデルとしてEII101に定義をおこない、各利用システムは独自の形式である論理モデルを通じて、公開されているデータを統合して利用参照し、データの更新はSOAサービス指向アーキテクチャなどにより各情報源のアプリケーションが提供している情報更新機能に依頼しておこなう方式を採用する。これによって、マスターデータ管理の導入に際して各情報源システムの改修を不要とし、利用システムのアプリケーションを簡素化し、物理的な共通マスターデータベースを不要とし、トランザクションなどの更新制御を各システム内に限定することによりマスター更新を簡素化することができる。さらに、各マスターデータの形式変更などが発生してもデータ統合装置に対する物理モデルの定義変更だけで、他のシステムへの波及を防止して、効率的なマスターデータ管理を実現することができる。また、この発明によれば、結果として、既存システムへの容易な導入、システムの変更や入れ替えに対する高い柔軟性、さらに、各サブシステムの高い独立性により、各サブシステムを担当する業務に最適化する部分最適の追求と、情報システム全体としての全体最適の追求を両立させることが可能となる。"