JP2014096177A - データ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

【課題】別々に管理されている複数の情報源に存在するデータを収集して統合する。
【解決手段】情報源からのデータ収集は、各情報源側のデータモデル（物理モデル）でお
こない、統合処理は利用側アプリケーションごとにあらかじめ定義されたデータモデル（
論理モデル）に向けてデータ構造を変換する処理（マッピング）および各値を揃えるよう
に変換する処理（クレンジング）をおこない、結果を各アプリケーションごとのビュー（
論理モデル）として利用側アプリケーションに提供する。
【選択図】図１

Description

この発明は、データ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体に関し、特に異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体に関する。

従来から、複数の異なるシステムにおいて管理されているデータを統合することによりシステム間の連携をおこなう装置は実現されている。たとえばＥＴＬ（Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄ）は、情報源となるデータベースからデータを抽出(ｅｘ
ｔｒａｃｔ)し、利用側システムで利用しやすい形に加工(ｔｒａｎｓｆｏｒｍ)し、利用
システムのデータベースに書き出す(ｌｏａｄ)ことにより実現しており、目的ごとに開発され、バッチ処理により運用されるのが通常である。ＥＴＬはデータウエアハウスの構築が代表的な応用例である。

また、ＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）では、連携するシステム間であらかじめ取り決めた基準にしたがってデータとプロセスを連携させることにより、複数のコンピュータシステムの有機的な連携を実現するものである。

ＥＡＩの具体例としては、異なるデータ形式を用いるように設計されている複数の業務システム間の連携を実現するために、ある所定の標準データ形式を規定しておき、各業務システム間でデータの連携をする際には、転送元の業務システムのデータを一旦、標準データ形式に変換し、さらに転送先の業務システムのデータ形式に変換することにより複数システム間のデータ連携を実現する技術がある（たとえば、特許文献１参照。）。

その際、業務システムがデータ処理において使用するデータ形式と標準データ形式との対応情報を記憶した複数の辞書データベースを用いて、ある業務システムからのデータのデータ形式を標準データ形式へ変換する。もしくはその逆をおこなうことでデータ連携をおこなう技術が示されている。この方法では、標準データ形式の定義をおこない、各情報システムごとに専用の変換用辞書データベースを構築する必要があり、また、標準データ形式に変更が発生すると、すべての辞書データベースの変更が必要になる。また、実際の連携時には、最低２段階のデータ形式の変換処理がおこなわれ、ＣＰＵ処理が発生する。

そこで、ＥＩＩ（Ｅｎｔｅｒｐｒｉｓｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）というデータ統合の方式が求められている。ＥＩＩは、物理的に散在しているデータを統合してシングル・ビューで利用する仕組みである。

一方、複数のシステム間に分散しているマスターデータを統合して管理する仕組みとして、ＭＤＭ（Ｍａｓｔｅｒ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）がある。従来技術にかかるＭＤＭの原理を図２２、図２３により示す。ここで、図２２は、本出願に共通の例題として、ＭＤＭ導入前の各サブシステムの状態を示す説明図であり、図２３は従来技術によるＭＤＭの実現例を示す説明図である。

図２２において、２２０１，２２０２，２２０３はそれぞれ、統合対象のサブシステム甲、乙、丙である。甲サブシステム２２０１は、テーブルＡ２２１１およびテーブルＢ２２１２を有する甲データベース（ＤＢ）２２１０を備えており、乙サブシステム２２０２は、テーブルＣ２２２１を有する乙データベース（ＤＢ）２２２０を備えており、丙サブシステム２２０３は、テーブルＤ２２３１を有する丙データベース（ＤＢ）２２３０を備えている。また、各テーブルには列としてカラムを持つ。たとえば表Ａ２２１１は、Ａ１，Ａ２，Ａ３，Ａ４，Ａ５のカラムを持つ。

ここで、２２４１，２２４２，２２４３，２２４４は、それぞれ各サブシステムで管理されているＤＢの表におけるデータの中で、統合対象とするデータ列を示す。たとえばテーブルＡ２２１１の場合には、列「Ａ１」、「Ａ３」、「Ａ４」が統合対象である。また、甲サブシステム２２０１は、データ統合対象システムがデータ統合の適用前から持つ機能の代表例として、機能‐Ｘを持ち、乙サブシステム２２０２はデータ統合を利用するアプリケーション機能の代表例として機能‐Ｙを持つ。

図２３では、図２２における甲サブシステム２２０１と丙サブシステム２２０２を従来技術で統合したＭＤＭの実現例を示す。まず、マスター（統合）ＤＢ２２５０を作成し、各サブシステムで管理されているＤＢの表（元表）の中から、統合対象である列データ２２４１，２２４２，２２４３を集めて、マスターテーブルＭ２２５１を持つように構成する。ここでは、マスターテーブルＭ２２５１に集めた列データがマスターデータとなるので、重複した管理を避けるために、元表からマスターテーブルＭ２２５１に集めた列データを可能な限り削除するが、すべての統合対象列データを元表から削除できない場合がある。

たとえば、元表の主キーとなる列データは削除することができないため、各元表とマスターテーブルＭ２２５１の両方で管理されるデータも存在する。また、各サブシステムの機能を実現しているアプリケーションは、各元表だけでなく、マスターテーブルＭ２２５１も扱うように変更する。各テーブルは、たとえばテーブルＡ２２１１の場合には列として「Ａ１」、「Ａ２」、「Ａ５」を持つことを示している。

具体的には、共有する情報（「Ａ１」、「Ａ３」、「Ａ４」、「Ｂ２」、「Ｂ３」、「Ｂ４」、「Ｃ２」、「Ｃ３」）はテーブルＭ２２５１としてマスターＤＢ２２５０で集中管理する。また、各システム固有の情報（「Ａ２」、「Ａ５」、「Ｂ１」、「Ｂ５」、「Ｃ１」、「Ｃ４」、「Ｃ５」）は各システムで管理する。また、各システムのＤＢにはマスターＤＢ２２５０と重複する情報（たとえば「Ａ１」、「Ｂ４」など）も存在することになる。

ここで、機能−Ｘおよび機能−Ｙの動作について検証する。まず、甲サブシステム２２０１における機能−Ｘである「テーブルＡのカラムＡ１，Ａ２，Ａ３，Ａ４を更新する（１）」を実行する。そこで、甲サブシステム２２０１は、マスターＤＢ２２５０のテーブルＭ２２５１の「Ａ１」、「Ａ３」、「Ａ４」について更新するとともに、甲ＤＢ２２１０で管理されているテーブルＡ２２１１の「Ａ１」、「Ａ２」を更新する。

つぎに、機能−Ｘである「Ａ２、Ａ３の合計をテーブルＢのＢ４に書込む（２）」を実行する。そこで、甲サブシステム２２０１は、マスターＤＢ２２５０のテーブルＭ２２５１にある「Ａ３」を取得し、テーブルＡ２２１１にある「Ａ２」と取得した「Ａ３」の合計をテーブルＢ２２１２の「Ｂ４」に書き込む。そして、マスターＤＢ２２５０に対して更新データである「Ｂ４」の反映をおこなう（３）。

さらに、乙サブシステム２２０２における機能−Ｙである「テーブルＭのＢ４を参照してＣ４を更新（４）」を実行する。そこで、乙サブシステム２２０２は、上記（３）において更新データが反映された、マスターＤＢ２２５０の「Ｂ４」を参照して、テーブルＣ２２２１の「Ｃ４」を更新する。このように、マスターＤＢ２２５０を用いたデータ統合をおこなっていた。

特開２００５−２９３０４７号公報

しかしながら、従来のシステムにあっては、以下のような問題点があった。すなわち、統合されたマスターＤＢ２２５０を設けるため、利用側システムのアプリケーションは自システムが管理している表だけでなく、マスターＤＢ２２５０についても、情報の所在と情報の参照および更新を意識して取り扱う必要がある。そのため、アプリケーションの改修が必要であったり、アプリケーションの内容が複雑化する要因の一つともなっているという問題点があった。

また、情報の更新をおこなう際には、自システムの情報とマスターＤＢ２２５０の情報を同期して矛盾なく更新する制御が必要となるという問題点があった。この制御は、自システムとマスターＤＢ２２５０についてトランザクションの制御をおこない、処理が失敗したときにはロールバックするなどの処理をアプリケーションによって実現する必要があるという問題点があった。これによって、アプリケーションへの負担が増加することになる。

また、利用側システムの更新時に参照したデータや、更新対象のデータは、中途半端な状態（他のアプリケーションが操作中で値が確定していない状態）にある場合があり、それを防止するためには更新に関わるデータに対する何らかのロック制御が必要となる。また、サブシステム間に跨るロック制御をおこなうことによって、システム全体の性能を低下させしまうという問題点があった。たとえば、甲サブシステムがマスターテーブルＭ２２５１（統合ＤＢ）をロックしている間は、他のシステムから統合ＤＢを利用することができないため、他のシステムは甲サブシステムの処理（トランザクション）が完了するのを待たされることになる。

また、各サブシステムの変更によって、統合ＤＢで管理しているデータに追加や変更が発生する場合もあり、この際には変更が発生した統合ＤＢのテーブルを使用しているすべてのサブシステムについて、アプリケーションの変更が必要になるケースも多い。さらに、個々のサブシステムの都合で統合ＤＢで管理しているデータの追加が発生するために、結果として統合ＤＢが肥大化する傾向がある。

このように、統合ＤＢへの集中と統合ＤＢの肥大化が生じ、また、統合ＤＢへのアクセスが増加するために、統合ＤＢの参照・更新性能が劣化するとともに、各アプリケーションが複雑化し、統合ＤＢの影響が各サブシステムに伝搬してしまうという問題があった。

この発明は、上述した従来技術による問題点を解消するため、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合する際に、各システムの負荷を軽減することが可能なデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体を提供し、理想的なＥＩＩおよびその応用としてのＭＤＭを実現することを目的とする。

上述した課題を解決し、目的を達成するため、この発明にかかるデータ統合装置は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、前記情報源から、各情報源側のデータモデル（以下「物理モデル」という）のままでデータの収集をおこなうデータ収集手段と、前記データ収集手段によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル（以下「論理モデル」という）になるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換手段と、前記データ変換手段によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供手段と、を備えたことを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記データ収集手段が、前記利用側アプリケーションからの要求に基づいて、リアルタイムに前記情報源からのデータの収集をおこなうこと特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記情報源のシステム側に設けられた前記データのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータのメタ情報に基づく仮想統合データベースを作成する仮想統合データベース作成手段を備え、前記データ変換手段が、前記仮想統合データベース作成手段によって作成された仮想統合データベースに含まれるメタ情報に基づいて、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうことを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記情報源のシステム側に設けられた前記データのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータからなる複製データベースを作成する複製データベース作成手段と、前記複製データベース作成手段によって作成された複製データベースを、前記マスターデータの更新に対応して更新する複製データベース更新手段と、を備え、前記データ収集手段が、前記複製データベースからデータの収集をおこなうことを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記物理モデルまたは前記論理モデルを表すメタ情報として、少なくとも表の名前、データ列の名前、データ値の型を定義することを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記メタ情報として、前記データ値の型に関する詳細を属性として示す型属性を定義し、前記変換手段が、前記データ値を変換する際に前記型属性が相違する場合に、当該型属性を合わせる処理をおこなうことを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記物理モデルまたは前記論理モデルを表すメタ情報として、データ列の制約を定義することを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記変換手段が、前記物理モデルと前記論理モデルとの間に、データの変換をおこなう中間テーブルを定義し、物理モデルとして収集したデータを中間テーブルで変換した結果を論理モデルに統合することを特徴とする。

また、この発明にかかるデータ統合装置は、上記の発明において、前記変換手段が、前記データ値の変換として、文字コード系の違いを変換する文字コード系変換処理、空白除去、全角半角変換を含む文字列の正規化をおこなう文字列変換処理、文字や数字の単位の違いを変換する単位変換処理、年号の西暦・和暦の違いを変換する年号表記変換処理、数字表現として漢数字／アラビア数字／ローマ数字と数値の違いを変換する漢数字表記変換処理、数字の有効桁を揃える有効桁変換処理、データ型間の変換処理の少なくともいずれか一つをおこなうことを特徴とする。

また、この発明にかかるデータ統合方法は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置を含むシステムにおけるデータ統合方法であって、前記情報源から、各情報源側のデータモデル（以下「物理モデル」という）のままでデータの収集をおこなうデータ収集工程と、前記データ収集工程によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル（以下「論理モデル」という）になるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換工程と、前記データ変換工程によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供工程と、を含んだことを特徴とする。

また、この発明にかかるデータ統合方法は、上記の発明において、前記情報源に存在するデータをそれぞれマスターデータとし、前記マスターデータのうち、他のシステムに公開するデータを前記データ統合装置に登録し、前記利用側アプリケーションは、前記データ統合装置に登録されたデータのうち、あらかじめ利用するデータを論理モデルとして前記データ統合装置に定義し、必要なときに前記論理モデルを検索することによって、前記データ統合装置に登録されたデータを論理モデルとして参照し、他のシステムのデータを更新する場合には、該当データをマスターデータとして管理しているシステムに対して、当該データに対する更新依頼を実施することを特徴とする。

また、この発明にかかるコンピュータ読み取り可能に記録する記録媒体は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置において実行されるデータ統合プログラムであって、前記情報源から、各情報源側のデータモデル（以下「物理モデル」という）のままでデータの収集をおこなうデータ収集工程と、前記データ収集工程によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル（以下「論理モデル」という）になるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換工程と、前記データ変換工程によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供工程と、をコンピュータに実行させるデータ統合プログラムを記録することを特徴とする。

この発明によれば、情報源の改造を不要とし、利用側アプリケーションの負荷を軽減することができるデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体が得られるという効果を奏する。

図１は、この発明にかかるＥＩＩの全体構成を示す説明図である。 図２−１は、この発明にかかるＥＩＩの原理を示す説明図（その１）である。 図２−２は、この発明にかかるＥＩＩの原理を示す説明図（その２）である。 図３は、表の構造（スキーマ）の一例を示す説明図である。 図４は、統合エンジンのアーキテクチャ（物理モデルの定義付け）を示す説明図である。 図５は、統合エンジンのアーキテクチャ（マッピング）を示す説明図である。 図６は、統合エンジンのアーキテクチャ（問い合わせ）を示す説明図である。 図７は、統合エンジンのアーキテクチャ（実際の動作）を示す説明図である。 図８は、統合エンジンのアーキテクチャ（クレンジング）を示す説明図（その１）である。 図９は、統合エンジンのアーキテクチャ（クレンジング）を示す説明図（その２）である。 図１０は、クレンジングの処理内容を示すフローチャートである。 図１１は、図１０に示したフローチャートの処理を実行する機能構成を示す説明図である。 図１２は、マッピングの処理内容を示すフローチャートである。 図１３は、マッピングの定義の一例を示す説明図である。 図１４は、評価ポイントの一例を示す説明図である。 図１５は、図１３のマッピングの定義に基づくマッピング制御を示す説明図である。 図１６は、検索条件の定義の一例を示す説明図である。 図１７は、マッピングの処理内容を示すフローチャートである。 図１８は、マッピングの定義の一例を示す説明図である。 図１９は、作成された検索式の一例を示す説明図である。 図２０は、マッピングの処理内容を示すフローチャートである。 図２１は、マッピングの処理内容を示すフローチャートである。 図２２は、ＭＤＭ導入前の各サブシステムの状態を示す説明図である。 図２３は、従来技術によるＭＤＭの実現例を示す説明図である。

以下に添付図面を参照して、この発明にかかるデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体の最適な実施の形態を詳細に説明する。図１は、この発明にかかるＥＩＩの全体構成を示す説明図である。図１において、１０１はデータ統合装置（以下「ＥＩＩ」という）であり、統合エンジン１１０を備え、物理モデル１１１と、論理モデル１１２からなるデータ記憶機能を備える。また、ＥＩＩ１０１は、サービスバス１０２を介してあるいは直接に、Ｂａｃｋ系システム（情報源）１０３およびＦｒｏｎｔ系システム（利用アプリケーション）１０４と接続されている。

ＥＩＩ１０１は、物理モデル１１１から論理モデル１１２へのデータ構造の変換処理（マッピング）およびデータ値の変換処理（クレンジング）を実行する統合エンジン１１０を備えている。また、表の名前、データ列の名前、データの型を定義し、データの型には型の詳細を定義する型属性を定義でき、さらに、主キー制約、従属キー制約などのデータ列の制約を定義できるメタ情報（リポジトリ）１１６を備え、メタ情報整備機能１１７によりメタ情報の整備を実行する。このメタ情報の整備によって、上記マッピング、クレンジングの確実性、効率性の向上を図っている。

なお、上記各機能は、ＥＩＩ１０１を構成するコンピュータシステムにおいて、図示を省略するＲＡＭ、ＲＯＭなどのメモリに記録されたプログラムをＣＰＵが実行することによって実現することができる。また、本実施の形態において記載されているデータベース（ＤＢ）はそれぞれ、各コンピュータシステムにおける図示を省略するハードディスクなどのデータ記録媒体に記録されるデータと、データベース管理ソフトウエア（ＤＢＭＳ）によってその機能を実現することができる。

図２−１および図２−２は、この発明にかかるＥＩＩの原理を示す説明図である。図２−１において、２０１は甲サブシステムであり、２０２は乙サブシステムであり、２０３は丙サブシステムである。甲サブシステム２０１は、テーブルＡ２１１およびテーブルＢ２１２を有する甲データベース（ＤＢ）２１０を備えており、乙サブシステム２０２は、テーブルＣ２２１を有する乙データベース（ＤＢ）２２０を備えており、丙サブシステム２０３は、テーブルＤ２３１を有する丙データベース（ＤＢ）２３０を備えている。

各サブシステムの情報、すなわち甲ＤＢ２１０、乙ＤＢ２２０、丙ＤＢ２３０の情報をマスターとする。これによって、サブシステムごとに独立したデータ管理をおこなう。また、マスターＤＢ（甲ＤＢ２１０、乙ＤＢ２２０、丙ＤＢ２３０）の中で共有したい情報をＥＩＩ１０１に公開する。これによって、各サブシステムは自分の全情報を管理することができる。図２−１、図２−２にあっては、テーブルＡ２１１は「Ａ１」〜「Ａ５」のデータ列からなるが、物理モデル１１１のテーブルＡ'２４１は、「Ａ１」、「Ａ３」、「Ａ４」のみの情報が仮想的に存在する。このことから、テーブルＡ２１１に関しては、「Ａ１」、「Ａ３」、「Ａ４」のみを共有し、「Ａ２」、「Ａ５」は共有しないことを示していることがわかる。

ここで、仮想統合では必要になった時点でマスターＤＢ２１０，２２０，２３０から情報を収集して統合する。また、物理統合ではＥＩＩ１０１上にあらかじめマスターＤＢのレプリカ２４０を置く、すなわち情報のレプリケーションをおこなう。

また、ＥＩＩ１０１は統合結果を利用アプリケーションに提供する機能を提供する。図２−１、図２−２では、論理モデル１１２として、乙システム専用のテーブルＭＣ２５１として統合結果を参照することができるようになっている。物理モデル１１１から論理モデル１１２への変換（統合処理）に関する詳細は後述する。

また、図２−１において、実線は表の実体を示し、破線は仮想的な表を示す。したがって、甲ＤＢ２１０のテーブルＡ２１１、テーブルＢ２１２、乙ＤＢ２２０のテーブルＣ２２１、丙ＤＢ２３０のテーブルＤ２３１およびレプリカテーブルＤ’２４５は実線で示してあり、物理モデル１１１の各テーブル２４１〜２４３、論理モデル１１２のテーブルＭＣ２５１は波線で示している。図２−２においても同様であり、２４１〜２４４は、レプリカであるので、実線で示している。

ここで、機能−Ｘおよび機能−Ｙの動作について検証する。この機能−Ｘおよび機能−Ｙの動作およびこれらの動作の対象となるテーブルＡ２１１、テーブルＢ２１２、テーブルＣ２２１は、図２２、図２３において示した従来技術における機能−Ｘおよび機能−Ｙの動作およびこれらの動作の対象となったテーブルＡ２２１１、テーブルＢ２２１２、テーブルＣ２２２１と同じにしてある。

図２−１は、この発明にかかるＥＩＩの原理として、仮想統合の一例を示す説明図である。まず、甲サブシステム２０１における機能−Ｘである「テーブルＡのカラムＡ１，Ａ２，Ａ３，Ａ４を更新する（１）」を実行する。そこで、甲サブシステム２０１は、甲ＤＢ２１０の「Ａ１」、「Ａ２」、「Ａ３」、「Ａ４」について更新する。

つぎに、「Ａ２、Ａ３の合計をテーブルＢのＢ４に書込む（２）」を実行する。そこで、甲サブシステム２０１は、テーブルＡ２１１にある「Ａ２」と「Ａ３」の合計をテーブルＢ２１２の「Ｂ４」に書き込む。このように、データ統合の実施前に実現されていたサブシステム内の処理は、更新処理を含めて、サブシステムに閉じたトランザクションとして独立して完結している。これらの処理は、データ統合の実施前から甲サブシステムの機能として実現していたものであり、データ統合の実施によるサブシステムの改良は不要であることを示している。

特にデータ更新に関わる処理がサブシステム内に閉じているので、ロールバック、すなわちトランザクションの処理中に何か異常が起こり、正常に処理を完了できない場合、関連する処理を中止し、関連する情報を処理前の状態に戻さなければならない場合にも、簡単かつ確実にロールバックを実行することができるという効果を奏する。したがって、アプリケーションの負担が軽く、アプリケーションの変更による影響がサブシステム外部に及ばないという効果も奏する。

つぎに、乙サブシステム２０２における機能−Ｙである「テーブルＭＣのＢ４を参照してＣ４を更新（３）」を実行する。そこで、乙サブシステム２０２はＥＩＩ１０１の論理モデル１１２として管理されているテーブルＭＣに対して「Ｂ４」を要求する。ＥＩＩ１０１は甲ＤＢ２１０の「Ｂ４」を参照して、その結果をテーブルＭＣの「Ｂ４」として乙サブシステム２０２に回答する。乙サブシステム２０２は回答の結果に基づいて「Ｃ４」を更新する。したがって、仮想統合では利用システムから要求された時点で、情報源からのデータ収集を実施するために、その時点における最新の情報であることを保証することができる。また、データ収集に際して情報源である甲サブシステム２０１の参照負荷が生じるが、図２３に示した従来技術の更新時のトランザクション負荷と比較すると大幅に軽減される。

このように、この発明の実施の形態にかかるデータ統合装置（ＥＩＩ１０１）は、異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するに際し、情報源（たとえば甲ＤＢ２１０）から、各情報源側のデータモデル（物理モデル１１１）のままでデータの収集をおこない、収集されたデータを、当該データの利用側アプリケーション（たとえば乙サブシステム２０２）ごとにあらかじめ定義されたデータモデル（論理モデル１１２）になるように、データ構造およびデータ値の少なくともいずれか一方の必要な変換をおこない、変換されたデータを利用側アプリケーションへ提供するものである。

また、利用側アプリケーションからの要求に基づいて、リアルタイムに情報源からのデータの収集をおこなう。また、サブシステム側に設けられたデータのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータのメタ情報を含む仮想統合データベース（テーブル２４１〜２４３）を作成し、作成された仮想統合データベースに含まれるメタ情報に基づいて、データ構造およびデータ値の少なくともいずれか一方の変換（マッピング、クレンジング）をおこなうものである。

図２−２は、この発明にかかるＥＩＩの原理として、物理統合の一例を示す説明図である。図２−２では、図２−１における情報源側サブシステムの参照負荷を軽減するために、各情報源側サブシステムのＤＢに、ＤＢの更新をトランザクション単位で記録するジャーナルを設け、このジャーナルを用いて、統合ＤＢのレプリカに対して情報源の更新を反映するように構成する。

図２−２において、機能−Ｘの「テーブルＡのカラムＡ１，Ａ２，Ａ３，Ａ４を更新する（１）」、「Ａ２、Ａ３の合計をテーブルＢのＢ４に書込む（２）」を図２−１と同様にそれぞれ実行すると、トランザクション単位で、甲ＤＢの更新記録がジャーナル２６１として生成される。このジャーナル２６１を用いてＥＩＩ１０１に甲ＤＢの更新を通知するとともに、ＥＩＩ１０１上のレプリカ２４０のテーブルＡ'２４１、テーブルＢ'２４２に反映することにより、情報源としての甲ＤＢ２１０とＥＩＩ１０１上のレプリカ２４０の同期を実現する。

乙サブシステム２０２も、図２−１と同様にＥＩＩ１０１の論理モデル１１２にアクセスしてテーブルＭＣの「Ｂ４」を取得して「Ｃ４」を更新する。このとき、ＥＩＩ１０１はレプリカ２４０のテーブルＢ'２４２に保持されている「Ｂ４」を参照して、乙システ
ムに回答するだけでよい。このように物理統合では、利用システム（図２−２では乙サブシステム２０２）からのアクセス性能が高く、情報源（図２−２では甲サブシステム２０１）への負荷が最小で済むという効果を奏する。また、情報源の停止時であってもレプリカで保有している停止直前の情報を利用することができるという効果を奏する。

このように、この発明の実施の形態にかかるデータ統合装置（ＥＩＩ１０１）の物理統合は、各サブシステム側に設けられたマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータからなる複製データベース（レプリカ２４０）を作成し、作成された複製データベースを、マスターデータベースの更新と同期して更新するとともに、複製データベースからデータの収集をおこなうものである。

つぎに、ＥＩＩ１０１におけるデータ統合の具体例について説明する。図３は、表の構造（スキーマ）の一例を示す説明図である。図３において、３０１は表のスキーマであり、表名＝表Ａと各列の列名、型、制約を示しており、３０２は、上記３０１のスキーマに基づく実際の表Ａを示している。

すなわち、表Ａの列名は「従業員番号」、「氏名」、「電話番号」からなる。各列が持つデータ値の型は、Ｉｎｔｅｇｅｒ（整数型）と、Ｓｔｒｉｎｇ（文字列型）とからなる。また、各データ値には型の詳細を定義するための情報として型属性を持つことができる。たとえば、Ｉｎｔｅｇｅｒ（整数型）において、型属性「ＭａｘＬｅｎｇｔｈ＝１０」とすることで、最大１０桁の整数型であることを示すことができる。同様に、Ｓｔｒｉｎｇ（文字列型）において、型属性「ＣｈａｒＣｏｄｅ＝Ｓ＿ＪＩＳ」とすることで、当該文字列の文字コードはシフトＪＩＳであることを示すことができる。また、各列の制約は、Ｍｋｅｙ（主キー制約）とＳｋｅｙ（従属キー制約）とからなる。

図３においては、従業員番号がＩｎｔｅｇｅｒ（整数型）であり、氏名および電話番号がＳｔｒｉｎｇ（文字列型）である。また、従業員番号はＭｋｅｙ（主キー制約）の制約があることを示している。

図４は、統合エンジンのアーキテクチャ（物理モデルの定義付け）を示す説明図である。物理モデルの定義付けは、たとえば図１に示したメタ情報整備機能１１７のオペーレーションとして実行される。図４において、４０１はテーブル（表Ａ４１１）を有する情報源システム１であり、４０２はテーブル（表Ｂ４１２、表Ｄ４１３）を有する情報源システム２であり、４０３はテーブル（表Ａ４２１）からなる４０１に対応する物理モデル１であり、４０４はテーブル（表Ｂ４２２および表Ｄ４２３）からなる４０２に対応する物理モデル２である。

ここで、ＥＩＩ１０１は各情報源システムのテーブルから、共有の対象となる表のスキーマを取得して、取得した情報に基づいて物理モデルを作成する。その際、登録された物理モデルに対して、不要列の削除、列名、型および型属性、制約などの修正をおこなう。図４において、表Ａ４１１の「住所」列についての情報は、システム１が共有しないとしたものであるため、物理モデルから削除されている。表Ｂ４１２の「内線番号」列、表Ｄ４１３の「内線」列も同様である。

図５は、統合エンジンのアーキテクチャ（マッピングの定義）を示す説明図である。マッピングの定義は、たとえば図１に示したメタ情報整備機能１１７のオペーレーションとして実行される。マッピングの定義は、定義済みの物理モデルに基づいて、論理モデルを定義するものである。なお、図５におけるマッピング定義の前提条件としては、情報源は図４に示したシステム１（物理モデル１）４０３およびシステム２（物理モデル２）４０４であり、利用側はシステム３（６０１）が必要とする論理モデル３（５０１），システム４（６０２）が必要とする論理モデル４（５０２）である。また、４つのシステムで従業員番号コード（キー）が同じものを使用しているものとする。

図５においてまず、物理モデルの必要な項目を論理モデルにセットする。具体的には、物理モデル１の表Ａ４２１から、「従業員番号」、「氏名」、「電話番号」を、物理モデル２の表Ｂ４２２から「従業員番号」、「所属」をそれぞれ、論理モデル３の表Ｃ５１１にセットする。ここで、複数の表（たとえば表Ａと表Ｂ）を結合する（ＪＯＩＮ）ときには、対象表のＭｋｅｙ制約列を論理モデルのＭｋｅｙ制約列につなぐことにより定義する。論理モデルには物理モデルから引き継いだ列名、型、型属性、制約が設定され、マッピング定義も自動に作成される。

また、論理モデル４の表Ｅにセットする際に、特定の列を別の表により変換する場合は、間に中間テーブル（表Ｄ４２３）をつなぐことにより定義する。すなわち、表Ｂ４２２の「所属」は、所属コードを表す「Ｉｎｔｅｇｅｒ」であるが、それを中間テーブルＤ４２３を用いて所属名称を表す「Ｓｔｒｉｎｇ」に変換する。そして、論理モデル４の表Ｅ５１２では、「所属」列として変換結果である「Ｓｔｒｉｎｇ」をセットする。これは、対象表のＳｋｅｙを中間テーブルのＭｋｅｙにつなぎ、変換先の列を論理モデルにつなぐことにより定義される。

つぎに、論理モデルに対して必要な修正をおこなう。たとえば、不要な列の削除（ただし、Ｍｋｅｙ制約を持つ列は削除できない）、列名の変更、型の変更と型属性変更などである。たとえば、表Ｄ４２３の「名称」列はＳｔｒｉｎｇ（文字列型）で型属性として「ＣｈａｒＣｏｄｅ＝ＪＥＦ」は設定されているので、当初の論理モデル表Ｅ５１２の所属列は、列名＝「名称」、データ型＝文字列、型属性＝「ＣｈａｒＣｏｄｅ＝ＪＥＦ」となっている。ここで、論理モデルとして必要な列に変更するために列名を「所属」に変更し、型属性を「ＣｈａｒＣｏｄｅ＝Ｓ＿ＪＩＳ」に変更している。これらの変更は、マッピング定義、クレンジング定義に反映される。統合処理に必要なこれらのメタ情報は、リポジトリ１１６に格納され、必要なときに統合エンジン１１０から利用される。

図６は、統合エンジンのアーキテクチャ（問い合わせ）を示す説明図である。利用側のシステム（システム３（たとえば内部の情報形式として表６１１を有する）、システム４（たとえば内部の情報形式として表６１２を有する））は、あらかじめ準備されている論理モデル（論理モデル３、論理モデル４）に対して検索（ＳＱＬ）文を発行して必要な情報を得ることができる。得た情報は各システムの内部表現と一致しているので、そのまま使用することがきる。ここで、システム４が表Ｅ５１２に対して、従業員番号７５００の情報がほしい旨の要求を出した場合の実際の動作について、図７を用いて説明する。

図７は、統合エンジンのアーキテクチャ（実際の動作）を示す説明図である。実際の統合処理は、たとえば図１に示した統合エンジン１１０において実行される。図７において、まず、論理モデル４の表Ｅ５１２について「従業員番号＝７５００」が検索条件になる。ＥＩＩは、求められた論理モデルに対する検索条件を、物理モデルに対する検索条件に変換する。これが、検索条件の導出（逆変換）処理である。論理モデル４の表Ｅ５１２の「従業員番号」列は物理モデル１の表Ａ４２１の従業員番号、物理モデル２の表Ｂ４２２の従業員番号から求めることになっているので、「表Ａの従業員番号＝７５００」、「表Ｂの従業員番号＝７５００」の検索条件を生成する。そして、表Ａ４２１に検索文を実行して結果（Ａ）を得る。表Ａ４２１の検索結果（Ａ）から、従業員番号列と氏名列を表Ｅ５１２にコピーする。これが結果の統合処理である。

つぎに、物理モデル２の表Ｂ４２２に検索文を実行して検索結果（Ｂ）を得る。表Ｂ４２２の検索結果（Ｂ）から、所属列を持ってくるが、検索結果（Ｂ）の所属列は所属コードになっているので、表Ｄ４２３を使って、名称に変換した結果を表Ｅ５１２の所属列の値にする。これは値の変換処理である。このとき、表Ｄ４２３の名称列がＪＥＦコード文字列であるのに対して、表Ｅ５１２の所属列はシフトＪＩＳ文字列を要求しているので「ＪＥＦ→シフトＪＩＳ変換」のクレンジング機能（詳細は後述する）が動作して、その結果を表Ｅ５１２の所属列にコピーする。

図８および図９は、統合エンジンのアーキテクチャ（クレンジング）を示す説明図である。クレンジングは、値の複写が発生するときには型チェックがおこなわれ、複写元（Ｆｒｏｍ型）と複写先（Ｔｏ型）の間で型または型属性が異なっていれば、型または型属性に対応して必要な処理が実行される。図８は、型属性の違いによるクレンジングの一例である。図８において、双方のデータ型はＳｔｒｉｎｇ（文字列型）で一致しているが、型属性が異なるため、Ｆｒｏｍ型の型属性（ＣｈａｒＣｏｄｅ＝ＪＥＦ）からＴｏ型の型属性（ＣｈａｒＣｏｄｅ＝Ｓ＿ＪＩＳ）に変換するために、ＪＥＦからシフトＪＩＳへ変換するクレンジング処理を実行し、その結果を複写先にコピーする。

文字コード系変換（文字列型）以外に、型属性が異なるときに実行されるクレンジング機能としては、たとえば、文字列変換（文字列型）がある。具体的には、全空白除去、前後の空白除去、連続空白を１個に集約、タブ／空白変換、改行コード除去、改行コード変換、全角／半角変換、英大文字／英小文字変換、文字の置き換え（置き換えテーブルを使用）などがある。

また、他のクレンジング機能としては、単位の変換（３千円から３，０００円へ、あるいはその逆）（文字列型／数値型）、年号表記（平成１６年から２００４年へ、あるいはその逆）（文字列型／数値型）、漢数字表記（十六から１６へ、あるいはその逆）（文字列型／数値型）、有効桁変換（数値型、有効桁数の増加あるいは減少）、有効文字数変換（文字列型、有効文字数の増加あるいは減少）などがある。

図９は、型が異なるときに実行されるクレンジング機能の一例である。図９において、Ｓｔｒｉｎｇ（文字列型）であって、ＪＥＦコード文字列「"２０００"」（すべて全角で４文字）のデータを、文字列から整数に変換するとともに、１０桁以内の整数に変換するクレンジング処理を実行する。それによって、「2000」（４桁の整数）のデータに変換する。

このように、この発明の実施の形態にかかるデータ統合装置は、データ値の変換として、文字コード系の違いを変換する文字コード系変換処理、空白除去、全角半角変換を含む文字列の正規化をおこなう文字列変換処理、文字や数字の単位の違いを変換する単位変換処理、年号の西暦・和暦の違いを変換する年号表記変換処理、数字表現として漢数字／アラビア数字／ローマ数字と数値の違いを変換する漢数字表記変換処理、数字の有効桁を揃える有効桁変換処理、データ型間の変換処理の少なくともいずれか一つをおこなうことができる。

図１０は、クレンジングの処理内容を示すフローチャートであり、図１１は、図１０に示したフローチャートの処理を実行する機能構成を示す説明図である。図１０のフローチャートにおいて、まず、図１１に示すＦｒｏｍ値１１０１のＦｒｏｍ型とＴｏ値１１０２のＴｏ型が同じか否かをクレンジング制御部１１０３によって判断する（ステップＳ１００１）。ここで、両者が同じ場合（ステップＳ１００１：Ｙｅｓ）は、Ｆｒｏｍ型とＴｏ型に共通する先頭の型属性をポイントする（ステップＳ１００２）。

つぎに、型属性の値が同じか否かを判断する（ステップＳ１００３）。ここで、型属性の値が同じ場合（ステップＳ１００３：Ｙｅｓ）は、Ｆｒｏｍ型とＴｏ型に共通するつぎの型属性をポイントする（ステップＳ１００４）。そして、確認すべき型属性が未だあるか否かを判断し（ステップＳ１００５）、ある場合（ステップＳ１００５：Ｙｅｓ）は、ステップＳ１００３へ戻って、以後ステップＳ１００３〜Ｓ１００５を繰り返し実行する。そして、確認すべき型属性がなくなった場合（ステップＳ１００５：Ｎｏ）は、一連のクレンジング処理を終了する。

ステップＳ１００１において、Ｆｒｏｍ型とＴｏ型とが異なる場合（ステップＳ１００１：Ｎｏ）は、つぎに、データ型の変換が可能か否かを判断する（ステップＳ１００６）。ここで、データ型の変換が可能でない場合（ステップＳ１００６：Ｎｏ）は、クレンジング処理の失敗処理をおこなう。一方、データ型の変換が可能な場合（ステップＳ１００６：Ｙｅｓ）は、つぎに、図１１に示す型変換呼出し部１１０４によって型変換の呼出しがおこなわれ、図１１に示す型変換処理部１１０５によって、該当する型変換処理を実行する（ステップＳ１００７）。

そして、型変換処理は成功したか否かを判断する（ステップＳ１００８）。ここで、型変換処理が成功した場合（ステップＳ１００８：Ｙｅｓ）は、ステップＳ１００２へ移行する。一方、型変換処理が失敗した場合（ステップＳ１００８：Ｎｏ）は、クレンジング処理の失敗処理をおこなう。

ステップＳ１００３において、型属性の値が異なる場合（ステップＳ１００３：Ｎｏ）は、図１１に示すクレンジング呼出し部１１０６によって型属性変換の呼出しがおこなわれ、該当するクレンジング機能があるか否かを判断する（ステップＳ１００９）。ここで、該当するクレンジング機能がない場合（ステップＳ１００９：Ｎｏ）は、クレンジング処理の失敗処理をおこなう。一方、該当するクレンジング機能がある場合（ステップＳ１００９：Ｙｅｓ）は、図１１に示すクレンジング処理部１１０７によって、該当するクレンジング処理を実行する（ステップＳ１０１０）。

そして、実行されたクレンジング処理は成功したか否かを判断する（ステップＳ１０１１）。ここで、クレンジング処理が成功した場合（ステップＳ１０１１：Ｙｅｓ）は、ステップＳ１００４へ移行する。一方、クレンジング処理が失敗した場合（ステップＳ１０１１：Ｎｏ）は、クレンジング処理の失敗処理をおこなう。

図１２は、マッピングの処理内容を示すフローチャートである。図１２のフローチャートにおいて、まず、論理モデルに対する検索式とマッピング定義によって、物理モデルの検索式を作成する（ステップＳ１２０１）。この詳細な内容については後述（図１７のフロー１を参照）する。つぎに、先頭の物理モデルの検索式をポイントし（ステップＳ１２０２）、ポイントされた物理モデルに検索式を実行して該当するデータを取得する（ステップＳ１２０３）。

そして、検索が成功したか否かを判断し、検索が失敗した場合（ステップＳ１２０４：Ｎｏ）は、マッピング失敗処理を実行する。一方、検索が成功した場合（ステップＳ１２０４：Ｙｅｓ）は、つぎに、検索結果の該当データを論理モデルにコピーする（ステップＳ１２０５）。この詳細な内容についても後述（図２０のフロー２を参照）する。そして、コピーが成功したか否かを判断し（ステップＳ１２０６）、コピーが失敗した場合（ステップＳ１２０６：Ｎｏ）は、マッピング失敗処理を実行する。

一方、ステップＳ１２０６において、コピーが成功した場合（ステップＳ１２０６：Ｙｅｓ）は、つぎの検索式をポイントする（ステップＳ１２０７）。そして、残りがあるか否かを判断し（ステップＳ１２０８）、残りがある場合（ステップＳ１２０８：Ｙｅｓ）は、ステップＳ１２０３へ戻り、以後ステップＳ１２０３〜Ｓ１２０８まで繰り返し実行する。ステップＳ１２０８において、残りがない場合（ステップＳ１２０８：Ｎｏ）は、一連のマッピング処理を終了する。

図１３は、マッピング定義の一例を示す説明図であり、図１４は、評価ポイントの一例を示す説明図であり、図１５は、図１３のマッピングの定義に基づくマッピング制御を示す説明図である。図１３において、「表Ｅ．氏名」は表Ｅの氏名列を示しており、図１３の括弧付数字（１）〜（６）は、図１５の（１）〜（６）にそれそれ対応している。たとえば、図１３の（１）に示すマッピング定義は、図１５の表Ａの該当データについて、その従業員番号列を表Ｅの従業員番号列に対応付ける（複写する）ことを示している。

ここで、図１３（６）のように、中間テーブルによる変換にも対応するマッピング定義が作成される。このマッピング定義は論理モデルの表単位で作成され、その内容は評価ポイント順にソートされている。評価ポイントの導出根拠の一例を図１４に示す。また、図１６は、利用側アプリケーションから発行される検索条件の一例を示す説明図である。

図１７は、マッピングの処理内容（Ｓ１２０１の詳細）を示すフローチャート（フロー１）であり、図１８は、図１７で利用するマッピングの定義の一例を示す説明図である。図１７のフローチャートにおいて、まず、図１６に示す検索式で指定されている論理モデル表（表Ｅ）のマッピング定義を取得して、解決済フラグをクリアする（ステップＳ１７０１）。すなわち、図１８の「解決」をすべて「０」にする。

つぎに、マッピング定義のＴｏ列を上から検索して、検索条件で指定されている列に対する最初のＦｒｏｍ列を求める（ステップＳ１７０２）。その際、解決フラグがあるマッピング定義はスキップする。たとえば図１６に示す検索条件として指定されている「表Ｅ.従業員番号」をＴｏ列から検索して、Ｆｒｏｍ列として「表Ａ.従業員番号」を求める。そして、該当するＦｒｏｍ列を検索対象として、検索条件のクレンジングを実行する（ステップＳ１７０３）。ステップＳ１７０３の詳細な内容については後述（図２１のフロー３を参照）する。

そして、Ｆｒｏｍ列は末端列か否かを判断する（ステップＳ１７０４）。ここで、末端列とは、マッピング定義において、Ｔｏ列に存在しない列（オリジナルのＦｒｏｍ列）を意味する。ここで、Ｆｒｏｍ列が末端列ではない場合（ステップＳ１７０４：Ｎｏ）は、つぎに、該当するＦｒｏｍ列を検索対象として、クレンジング結果を検索条件に設定して検索条件クレンジングの再処理をおこなう（ステップＳ１７０５）。その後、ステップＳ１７０２へ戻る。たとえば、図１８でＦｒｏｍ列の「表Ｄ．名称」に対する検索条件を導出した場合には、「表Ｄ．名称」がＴｏ列（６行目の要素）に存在するため、再度「表Ｄ．所属」の検索式を導出する必要がある。この場合、再度「表Ｂ．所属」（３行目のＦｒｏｍ要素）の検索式に変換され、これが末端列となる。このステップＳ１７０２〜Ｓ１７０５のループによって、中間テーブルによる変換など、多段階のマッピングに対応している。

ステップＳ１７０４において、Ｆｒｏｍ列が末端列である場合（ステップＳ１７０４：Ｙｅｓ）は、該当するＦｒｏｍ列を検索対象として、クレンジング結果を検索条件とする検索式を作成する（ステップＳ１７０６）。図１９が、作成された検索式の一例である。そして、この検索で解決できるマッピング定義に解決フラグを立てる（ステップＳ１７０７）。すなわち、図１８の「解決」を「１」にする。ここで「解決」とは、検索結果のデータ列の複写により、該当するマッピングが実現できることを意味している。たとえば、図１９の１行目の検索により、図１５の（１）（４）に対応するマッピングが解決されるので、図１８の１行目と４行目の解決列を「１」に設定できる。

つぎに、Ｆｒｏｍ列が末端列であるマッピング定義に未解決があるか（すなわち、「解決」が「０」のものがあるか）否かを判断する（ステップＳ１７０８）。ここで、未だ、未解決がある場合（ステップＳ１７０８：Ｙｅｓ）は、ステップＳ１７０２に戻る。そして、ステップＳ１７０２〜Ｓ１７０８を繰り返し実行する。ステップＳ１７０８において、未解決がない場合（ステップＳ１７０８：Ｎｏ）は、フロー１の一連の処理を終了し、図１２に示したステップＳ１２０２へ移行する。ここで、図１８はこの状態（ステップＳ１７０８において、未解決がない場合）を示している。すなわち、Ｆｒｏｍ列が末端列であるマッピング定義（１）〜（４）が全て解決済になっている。

図２０は、マッピングの処理内容（Ｓ１２０５の詳細）を示すフローチャート（フロー２）であり、論理モデルへの反映処理の内容を示す。図２０のフローチャートにおいて、まず、該当データの先頭をポイントする（ステップＳ２００１）。つぎに、ポイントされたデータが直接論理モデルに反映することが可能か否かを判断する（ステップＳ２００２）。ここで、データが直接論理モデルに反映することが可能な場合（ステップＳ２００２：Ｙｅｓ）は、クレンジングをおこなってから、結果を論理モデルにコピーする（ステップＳ２００３）。

つぎに、コピーは成功したか否かを判断し（ステップＳ２００４）、コピーが失敗した場合（ステップＳ２００４：Ｎｏ）は、フロー２の処理が失敗であるとして、図１２に示したフローチャートのステップＳ１２０６へ移行する。一方、コピーが成功した場合（ステップＳ２００４：Ｙｅｓ）は、つぎの値をポイントする（ステップＳ２００５）。そして、残りはあるか否かを判断する（ステップＳ２００６）。ここで、残りがある場合（ステップＳ２００６：Ｙｅｓ）は、ステップＳ２００２へ戻る。一方、残りがない場合（ステップＳ２００６：Ｎｏ）は、フロー２の一連の処理を終了し、図１２に示したフローチャートのステップＳ１２０６へ移行する。

ステップＳ２００２において、データを直接論理モデルに反映することが可能ではない場合（ステップＳ２００２：Ｎｏ）は、対象のデータ値を検索条件とし、該当する中間テーブルの列を検索対象として、検索条件のクレンジングを実行する（ステップＳ２００７）。この処理の詳細な内容については後述（図２１を参照）する。そして、クレンジングが成功したか否かを判断し（ステップＳ２００８）、失敗した場合（ステップＳ２００８：Ｎｏ）は、フロー２の処理が失敗であるとして、図１２に示したフローチャートのステップＳ１２０６へ移行する。

つぎに、中間テーブルを検索し（ステップＳ２００９）、検索は成功したか否かを判断する（ステップＳ２０１０）。ここで、失敗した場合（ステップＳ２０１０：Ｎｏ）は、フロー２の処理が失敗であるとして、図１２に示したフローチャートのステップＳ１２０６へ移行する。一方、成功した場合（ステップＳ２０１０：Ｙｅｓ）は、ポイントしている値を検索結果で置き換え（ステップＳ２０１１）、その後、ステップＳ２００２へ戻る。このＳ２００７〜Ｓ２０１１で中間テーブルによるデータ値の変換処理を実現している。

図２１は、マッピングの処理内容（Ｓ２００７，Ｓ１７０３の詳細）を示すフローチャートであり、検索条件のクレンジング処理の内容を示す。図２１のフローチャートにおいて、まず、検索条件を型および型属性とともにＦｒｏｍ値に設定し、検索対象表の列をＴｏ値に設定する（ステップＳ２１０１）。つぎに、クレンジングを実行する（ステップＳ２１０２）。そして、クレンジングが成功したか否かを判断する（ステップＳ２１０３）。ここで、クレンジングが失敗した場合（ステップＳ２１０３：Ｎｏ）は、フロー３の処理が失敗であるとして、図２０に示したフローチャートのステップＳ２００８または、図１７に示したフローチャートのステップＳ１７０４へ移行する。

一方、クレンジングが成功した場合（ステップＳ２１０３：Ｙｅｓ）は、クレンジング結果（Ｔｏ値）を型および型属性とともに、検索条件に設定する（ステップＳ２１０４）。それによって、一連の処理を終了し、図２０に示したフローチャートのステップＳ２００８または、図１７に示したフローチャートのステップＳ１７０４へ移行する。これらのフローチャート中で実行されている値のクレンジング処理（Ｓ２００３，Ｓ２１０２）は、図１０で説明済みのクレンジング処理により実現するものである。

以上説明したように、この発明によれば、別々に管理されている複数の情報源１０３に存在するデータを収集して統合するに際して、情報源１０３からのデータ収集は、各情報源側のデータモデル（物理モデル１１１）でおこない、統合処理は各利用側アプリケーション１０４ごとにあらかじめ定義されたデータモデル（論理モデル１１２）に向けてデータ構造を変換する処理（マッピング）および各値を揃えるように変換する処理（クレンジング）をおこない、結果を各アプリケーションごとのビュー（論理モデル１１２）として利用側アプリケーションに提供することによって、情報源１０３側の改造を不要とし、利用側アプリケーション１０４の負担を軽減することができる。

また、この発明によれば、利用側アプリケーション１０４から要求された時点でリアルタイムに情報源１０３からの情報収集をおこない、データ統合処理を実行して結果を利用側アプリケーション１０４に提供することにより、リアルタイムな統合結果を提供する、いわゆる仮想統合を実現することができる。

また、この発明によれば、あらかじめ情報源１０３の公開する情報に限定した複製であるレプリカ２４０（複製データベース）をＥＩＩ１０１側に作成しておき、情報源１０３の更新に同期して、トランザクション単位の差分をレプリカ２４０（複製データベース）に適用しておき、利用側アプリケーション１０４からの要求に対してはレプリカ２４０からデータを収集して統合して、結果を利用側アプリケーション１０４に提供する、いわゆる物理統合を実現することによって、情報源１０３へのアクセス負荷を軽減し、情報源１０４の停止時間でも停止直前のデータを利用したデータ統合を実現することができる。

また、この発明によれば、情報源１０３で管理されているデータの性質および運用形態に合わせて、情報源１０３または表ごとに、上記仮想統合または上記物理統合を選択可能とすることによって、最適なデータ統合を実現することができる。

また、この発明によれば、各情報源１０３側の形式（物理モデル１１１）および各利用側アプリケーション１０４の形式（論理モデル１１２）を表すメタ情報として、少なくとも表の名前、データ列の名前、データの型を定義し、データの型には型の詳細を定義する型属性を定義できるように構成する。そして、各データの値を物理モデル１１１から論理モデル１１２に変換するクレンジング処理では、データ型が異なるときには複写元をＦｒｏｍ型、複写先をＴｏ型として、Ｆｒｏｍ型のデータ値をＴｏ型のデータ値に変換する型変換機能を実行し、型属性に差があるときには型属性を合わせるクレンジング処理を実行することによって、きめ細かいクレンジングを効率よく実行することができる。

また、この発明によれば、上記メタ情報として主キー制約、従属キー制約などのデータ列の制約を併せて定義し、物理モデル１１１の表および列から論理モデル１１２の表および列への対応関係を示すマッピング定義を定義するように構成し、利用側アプリケーション１０４から要求された論理モデル１１２の表に対する検索条件式からマッピング定義に基づいて、対応する物理モデル１１１の検索条件式を作成する。

この検索条件式の作成は、マッピング定義の評価関数で評価された順に実行し、その検索条件は論理モデル１１２側をＦｒｏｍ型、物理モデル１１１側をＴｏ型として統合と逆方向のクレンジング処理をおこない、これらにより生成された検索条件式により各情報源１０３（物理モデル１１１）からデータの収集をおこない、収集したデータはマッピング定義とデータ値の型および型属性定義に基づいて、マッピングおよびクレンジングをおこない、論理モデル１１２のデータに統合し、利用側アプリケーション１０４に提供することができる。

また、この発明によれば、マッピング定義として、利用側アプリケーション１０４のシステムが要求する論理モデル１１２と、情報源１０３側の形式としての物理モデル１１１の間に、データの変換をおこなう中間テーブル（たとえば図５などに示した表Ｄ４２３）を定義できるように構成し、物理モデル１１１として収集したデータを中間テーブルで変換した結果を論理モデル１１２に統合することによって、より差の大きいデータモデル間の統合を可能とする。

また、この発明によれば、クレンジングは、文字コード系の違いを変換する文字コード系変換処理、空白除去や全角半角変換などの文字列の正規化をおこなう文字列変換機能、文字や数字の単位の違いを変換する単位変換機能、年号の西暦・和暦などの違いを変換する年号表記変換、数字表現として漢数字／アラビア数字／ローマ数字と数値の違いを変換する漢数字表記変換、数字の有効桁を揃える有効桁変換、データ型間の変換機能のいずれかが可能となる。

また、この発明によれば、複数のシステムに独立して管理されているマスターデータを管理するに際し、マスターデータはあくまでも各システムで各アプリケーションが独立して管理をおこない、各マスターデータの中で、他のシステムに有用なデータをマスターデータの形式である物理モデル１１１として、ＥＩＩ１０１に対してデータ公開の定義をおこない、利用側アプリケーション１０４の各システムはそれそれのアプリケーションにとって使いやすいデータ形式を論理モデルとしてＥＩＩ１０１に定義をおこない、各利用システムは独自の形式である論理モデルを通じて、公開されているデータを統合して利用（参照）し、データの更新はＳＯＡ（サービス指向アーキテクチャ）などにより各情報源のアプリケーションが提供している情報更新機能に依頼しておこなう方式を採用する。

これによって、マスターデータ管理(ＭＤＭ)の導入に際して各情報源システムの改修を不要とし、利用システムのアプリケーションを簡素化し、物理的な共通マスターデータベースを不要とし、トランザクションなどの更新制御を各システム内に限定することによりマスター更新を簡素化することができる。さらに、各マスターデータ(情報源)の形式変更などが発生してもデータ統合装置に対する物理モデルの定義変更だけで、他のシステムへの波及を防止して、効率的なマスターデータ管理(ＭＤＭ)を実現することができる。

また、この発明によれば、結果として、既存システムへの容易な導入、システムの変更や入れ替えに対する高い柔軟性、さらに、各サブシステムの高い独立性により、各サブシステムを担当する業務に最適化する部分最適の追求と、情報システム全体としての全体最適の追求を両立させることが可能となる。

以上のように、この発明にかかるデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体は、複数の異なるシステムの情報を統合し活用するのに有用であり、特に、ＥＩＩやＭＤＭなどにおいて用いられるのに適している。

１０１ データ統合装置（ＥＩＩ）
１０２ サービスバス
１０３ 情報源
１０４ 利用アプリケーション
１１１ 物理モデル
１１２ 論理モデル
２０１，２０２，２０３ サブシステム
２１０，２２０，２３０ マスターデータベース
２４０ レプリカ

Claims (5)

1. 異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置であって、
   前記情報源から、各情報源側のデータモデル（以下「物理モデル」という）のままでデータの収集をおこなうデータ収集手段と、
   前記データ収集手段によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル（以下「論理モデル」という）になるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換手段と、
   前記データ変換手段によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供手段と、
   を備えたことを特徴とするデータ統合装置。
2. 前記情報源のシステム側に設けられた前記データのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータのメタ情報に基づく仮想統合データベースを作成する仮想統合データベース作成手段を備え、
   前記データ変換手段は、前記仮想統合データベース作成手段によって作成された仮想統合データベースに含まれるメタ情報に基づいて、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうことを特徴とする請求項１に記載のデータ統合装置。
3. 前記情報源のシステム側に設けられた前記データのマスターデータベースに格納されたデータのうち、公開の対象となっているデータに限定したデータからなる複製データベースを作成する複製データベース作成手段と、
   前記複製データベース作成手段によって作成された複製データベースを、前記マスターデータの更新に対応して更新する複製データベース更新手段と、を備え、
   前記データ収集手段は、前記複製データベースからデータの収集をおこなうことを特徴とする請求項１に記載のデータ統合装置。
4. 異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置を含むシステムにおけるデータ統合方法であって、
   前記情報源から、各情報源側のデータモデル（以下「物理モデル」という）のままでデータの収集をおこなうデータ収集工程と、
   前記データ収集工程によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル（以下「論理モデル」という）になるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換工程と、
   前記データ変換工程によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供工程と、
   を含んだことを特徴とするデータ統合方法。
5. 異なるシステムにおいて管理されている複数の情報源に存在するデータを収集して統合するデータ統合装置において実行されるデータ統合プログラムであって、
   前記情報源から、各情報源側のデータモデル（以下「物理モデル」という）のままでデータの収集をおこなうデータ収集工程と、
   前記データ収集工程によって収集されたデータを、当該データの利用側アプリケーションごとにあらかじめ定義されたデータモデル（以下「論理モデル」という）になるように、データ構造およびデータ値の少なくともいずれか一方の変換をおこなうデータ変換工程と、
   前記データ変換工程によって変換されたデータを前記利用側アプリケーションへ提供するデータ提供工程と、
   をコンピュータに実行させることを特徴とするデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images