以下に添付図面を参照して、この発明にかかるデータ統合装置、データ統合方法およびデータ統合プログラムを記録したコンピュータ読み取り可能な記録媒体の最適な実施の形態を詳細に説明する。図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を有する甲データベース(DB)210を備えており、乙サブシステム202は、テーブルC221を有する乙データベース(DB)220を備えており、丙サブシステム203は、テーブルD231を有する丙データベース(DB)230を備えている。
各サブシステムの情報、すなわち甲DB210、乙DB220、丙DB230の情報をマスターとする。これによって、サブシステムごとに独立したデータ管理をおこなう。また、マスターDB(甲DB210、乙DB220、丙DB230)の中で共有したい情報をEII101に公開する。これによって、各サブシステムは自分の全情報を管理することができる。図2−1、図2−2にあっては、テーブルA211は「A1」〜「A5」のデータ列からなるが、物理モデル111のテーブルA'241は、「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のテーブルA'241、テーブルB'242に反映することにより、情報源としての甲DB210とEII101上のレプリカ240の同期を実現する。
乙サブシステム202も、図2−1と同様にEII101の論理モデル112にアクセスしてテーブルMCの「B4」を取得して「C4」を更新する。このとき、EII101はレプリカ240のテーブルB'242に保持されている「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(物理モデル1)403およびシステム2(物理モデル2)404であり、利用側はシステム3(601)が必要とする論理モデル3(501),システム4(602)が必要とする論理モデル4(502)である。また、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桁以内の整数に変換するクレンジング処理を実行する。それによって、「2000」(4桁の整数)のデータに変換する。
このように、この発明の実施の形態にかかるデータ統合装置は、データ値の変換として、文字コード系の違いを変換する文字コード系変換処理、空白除去、全角半角変換を含む文字列の正規化をおこなう文字列変換処理、文字や数字の単位の違いを変換する単位変換処理、年号の西暦・和暦の違いを変換する年号表記変換処理、数字表現として漢数字/アラビア数字/ローマ数字と数値の違いを変換する漢数字表記変換処理、数字の有効桁を揃える有効桁変換処理、データ型間の変換処理の少なくともいずれか一つをおこなうことができる。
図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の従業員番号列に対応付ける(複写する)ことを示している。
ここで、図13(6)のように、中間テーブルによる変換にも対応するマッピング定義が作成される。このマッピング定義は論理モデルの表単位で作成され、その内容は評価ポイント順にソートされている。評価ポイントの導出根拠の一例を図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の(1)(4)に対応するマッピングが解決されるので、図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(サービス指向アーキテクチャ)などにより各情報源のアプリケーションが提供している情報更新機能に依頼しておこなう方式を採用する。
これによって、マスターデータ管理(MDM)の導入に際して各情報源システムの改修を不要とし、利用システムのアプリケーションを簡素化し、物理的な共通マスターデータベースを不要とし、トランザクションなどの更新制御を各システム内に限定することによりマスター更新を簡素化することができる。さらに、各マスターデータ(情報源)の形式変更などが発生してもデータ統合装置に対する物理モデルの定義変更だけで、他のシステムへの波及を防止して、効率的なマスターデータ管理(MDM)を実現することができる。
また、この発明によれば、結果として、既存システムへの容易な導入、システムの変更や入れ替えに対する高い柔軟性、さらに、各サブシステムの高い独立性により、各サブシステムを担当する業務に最適化する部分最適の追求と、情報システム全体としての全体最適の追求を両立させることが可能となる。