JP5601066B2 - 情報統合プログラム、装置及び方法 - Google Patents

Description

本技術は、情報統合技術に関する。

ＥＴＬ（Extract Transform Load）と呼ばれる技術では、情報源システムに蓄積されたデータを抽出（extract）し、抽出されたデータを所定の形式に変換（transform）し、変換されたデータを格納先システム（例えばデータウェアハウス）に登録（load）する。このような一連の処理は、情報統合と呼ばれることもある。

従来、情報統合に関する以下のような従来技術が存在する。具体的には、ソースデータに対し、複数の変換オブジェクトにより順次変換処理を行い、最終的にターゲットシステムにデータをマッピングする。各変換オブジェクトは、予め用意されたメタデータに従い変換処理を行う。

また、既存システムのデータをデータウェアハウスに移行する際に、既存システム側の項目名をキーとして（１）その項目がデータウェアハウスのデータベースのテーブルではどのような項目名・データ形式になるのか、（２）その項目を移行するためにどのような変換ロジックが必要か、を取得するマッピングテーブルを用意することで、移行時のデータウェアハウス構築コストを下げる技術が存在する。

また、データベースのスキーマ情報に関して、データベースのスキーマ情報を採取、保持しておき、利用者の指示によって再度取得したスキーマ情報と比較して差分データを作成することで、スキーマ情報へのアクセスの高速化を行う技術が存在する。

しかし、上で述べたような技術では、情報統合を行うシステムにおいて、情報源のスキーマが変更された場合については考慮されていない。このような場合にはデータの変換を適切に行うことができなくなるため、従来では、管理者等がデータ変換のためのロジックを再度作成し直すことにより対処していた。しかし、これは運用コストの増大につながるという問題がある。

米国特許第６０１４６７０号 米国特許第６３３９７７５号 特開２００４−３０１７９号公報 特開平１１−２５１２６号公報

従って、本技術の目的は、情報統合を行うシステムの運用コストを削減するための技術を提供することである。

本情報統合方法は、情報源から抽出したデータを変換して格納先に記憶する情報統合方法であって、情報源から取得した、第１のスキーマ情報に含まれるデータ項目と、当該第１のスキーマ情報の変更前のスキーマ情報である第２のスキーマ情報に含まれるデータ項目とに基づいて、第２のスキーマ情報に含まれるデータ項目について属性値と第２のスキーマ情報に対応する変更前データモデルにおけるデータ項目情報とを対応付けて記憶する第１記憶部に記憶された、第１のスキーマ情報に含まれる属性値を探索し、探索の結果、第１のスキーマ情報に含まれる属性値が検出された場合、検出された該属性値に対応付けて第１記憶部に記憶されたデータ項目情報に基づいて、第１のスキーマ情報に対応する変更後データモデルを生成する処理を含む。

情報統合を行うシステムの運用コストを削減することができるようになる。

図１は、本技術の実施の形態に係るシステムの構成図である。 図２は、情報統合装置の機能ブロック図である。 図３は、対応表格納部に格納されるデータの一例を示す図である。 図４は、変換経路表格納部に格納されるデータの一例を示す図である。 図５は、変換経路表格納部に格納されるデータの一例を示す図である。 図６は、変換経路表格納部に格納されるデータの一例を示す図である。 図７は、変換経路表格納部に格納されるデータの一例を示す図である。 図８は、変換経路表格納部に格納されるデータの一例を示す図である。 図９は、メタ情報格納部に格納されるデータについて説明するための図である。 図１０は、メタ情報格納部に格納されるデータについて説明するための図である。 図１１は、統合ロジックの初回実行時における処理の処理フローを示す図である。 図１２は、スキーマ収集処理の処理フローを示す図である。 図１３は、スキーマ情報の収集方法について説明するための図である。 図１４は、スキーマ情報の収集方法について説明するための図である。 図１５は、統合ロジックの実行時における処理の処理フローを示す図である。 図１６は、データモデル・データ属性改修処理の処理フローを示す図である。 図１７は、項目情報追加処理の処理フローを示す図である。 図１８は、データモデル・データ属性改修処理について説明するための図である。 図１９は、項目情報追加処理について説明するための図である。 図２０は、統合ロジック改修処理の処理フローを示す図である。 図２１は、仮変換ロジック生成処理の処理フローを示す図である。 図２２は、削除フラグについて説明するための図である。 図２３は、仮変換ロジック生成処理について説明するための図である。 図２４は、変更後統合ロジック生成処理の処理フローを示す図である。 図２５は、統合ロジック最適化処理の処理フローを示す図である。 図２６は、統合ロジック最適化処理について説明するための図である。 図２７は、変更後統合ロジック生成処理の処理フローを示す図である。 図２８は、変更後の統合ロジックについて説明するための図である。 図２９は、統合ロジックの実行時における処理の処理フローを示す図である。 図３０は、コンピュータの機能ブロック図である。

図１に、本技術の実施の形態に係るシステムの構成図を示す。情報統合装置１には、情報源（データソースとも呼ばれる）であるＤＢ（データベース）３１及びＤＢ３３を含む情報源システム３と、ＤＢ５１及びＤＢ５３を含む格納先システム５とが接続されている。本システムは、情報統合を実現するシステムである。すなわち、情報統合装置１は、情報源システム３におけるＤＢ３１又はＤＢ３３から抽出したデータを所定の形式に変換し、格納先システム５におけるＤＢ５１又はＤＢ５３に登録する。ＤＢ５１又はＤＢ５３に登録されたデータは、図示しないユーザ端末等を操作するユーザ等により利用される。なお、図１の例では情報源システム３及び格納先システム５に含まれるＤＢは２つしか示していないが、数に限定は無い。

図２に、情報統合装置１の機能ブロック図を示す。情報統合装置１は、統合処理実行部１００と、スキーマ収集部１０４と、スキーマ格納部１０５と、収集スキーマ格納部１０６と、データモデル・データ属性改修部１０７と、対応表格納部１０８と、変更後データ格納部１０９と、統合ロジック改修部１１０と、変換経路表格納部１１４と、メタ情報格納部１１５と、実行データ格納部１１６と、出力部１１７とを含む。また、統合処理実行部１００は、抽出部１０１と、変換部１０２と、登録部１０３とを含み、統合ロジック改修部１１０は、仮変換ロジック生成部１１１と、仮変換ロジック格納部１１２と、統合ロジック生成部１１３とを含む。

なお、本実施の形態においては、例えばデータ型やデータ長などデータの構造を表現するデータを「データモデル」と呼び、例えば文字コードやエンディアンなどデータの構造以外の性質を表現するデータを「データ属性」と呼ぶ。データモデル及びデータ属性は、情報源となるデータベースの種別に依存しない、抽象的な形式で表現される。

抽出部１０１は、情報源システム３におけるＤＢ３１又はＤＢ３３からデータを抽出し、変換部１０２に出力する。変換部１０２は、メタ情報格納部１１５に格納されているデータに従い、データを変換する処理を行い、登録部１０３に出力する。登録部１０３は、変換部１０２から受け取ったデータを格納先システム５におけるＤＢ５１又はＤＢ５３に登録する。スキーマ収集部１０４は、収集したスキーマ情報を収集スキーマ格納部１０６に格納する処理や、スキーマ格納部１０５に格納されているスキーマ情報を更新する処理等を行う。データモデル・データ属性改修部１０７は、スキーマ格納部１０５、収集スキーマ格納部１０６、対応表格納部１０８及びメタ情報格納部１１５に格納されているデータに基づき、後で説明するデータモデル・データ属性改修処理を実施し、処理結果を変更後データ格納部１０９に格納する処理等を行う。仮変換ロジック生成部１１１は、変更後データ格納部１０９に格納されているデータ及びメタ情報格納部１１５に格納されているデータに基づき、後で説明する仮変換ロジック生成処理を実施し、処理結果を仮変換ロジック格納部１１２に格納する。統合ロジック生成部１１３は、変換経路表格納部１１４、メタ情報格納部１１５及び仮変換ロジック格納部１１２に格納されているデータに基づき、後で説明する変更後統合ロジック生成処理を実施し、処理結果を実行データ格納部１１６に格納する処理等を行う。また、各処理部は、処理結果を出力部１１７を介して表示装置に出力する処理を実施する。

図３に、対応表格納部１０８に格納されているデータ（メタ情報対応表）の一例を示す。図３の例は、データ型用のメタ情報対応表であり、「Schema」の列と、「Model」の列と、「Type」の列と、「Condition」の列とが含まれる。メタ情報対応表は、情報源であるＤＢ３１又はＤＢ３３の固有の形式で表現されている情報を、情報統合装置１のデータモデルやデータ属性にマッピングするためのマッピング・ルールを格納する。「Schema」の列には、ＤＢ３１又はＤＢ３３から収集したスキーマ情報に含まれる項目の属性値が格納され、「Model」の列には、情報統合装置１のデータモデル及びデータ属性における項目情報が格納される。例えば３行目のデータは、スキーマ情報において「DECIMAL」という属性値がデータモデルにおいて「Number」という項目情報に対応付けられることを表している。また、「Type」の列には、マッピング・ルールの種別を表すデータが格納される。例えば、「default」であれば予め用意されたものであることを表し、「user」であれば情報統合装置１の管理者等が追加したものであることを表し、「auto」であれば後で説明する項目情報追加処理において追加されたものであることを表す。「Condition」の列には、適用条件に関するデータが格納される。なお、メタ情報対応表は情報源であるデータベースの種別（例えば、Oracle、COBOL等）毎に用意され、さらにデータ型やデータ長、エンディアン等の種別毎に用意される。

図４に、変換経路表格納部１１４に格納されているデータの一例を示す。図４は、文字コードを変換するための変換経路表の一例である。図４の例では、変換前の値を表す「From」の列と、変換後の値を表す「To」の列と、変換の複雑さを表す「Cost」の列と、非等価フラグ（NonEQuivalence flag）を設定するための「NEQ」の列とが含まれる。NEQフラグは、その変換を行うとデータが等価でなくなる（情報の一部が失われてしまう）可能性があることを表す。例えば９行目のデータにはNEQフラグが設定されているが、これは「UTF-8」から「SJIS」に変換できない文字があることを表している。

また、図５乃至図８に、変換経路表格納部１１４に格納されているデータの一例を示す。図５はデータ型を変換するための変換経路表の一例を示し、図６は改行コードを変換するための変換経路表の一例を示し、図７は桁数を変換するための変換経路表の一例を示し、図８はエンディアンを変換するための変換経路表の一例を示している。図５乃至図８の変換経路表のデータのフォーマットは図４と同様である。

図９及び図１０に、メタ情報格納部１１５に格納されているデータの一例を示す。図９は、メタ情報格納部１１５に格納されているデータモデル及びデータ属性の一例である。図９の例では、ＤＢ３１に対応するデータモデル及びデータ属性９０１と、ＤＢ３３に対応するデータモデル及びデータ属性９０２と、ＤＢ５１に対応するデータモデル及びデータ属性９０３とが含まれる。

一方、図１０は、メタ情報格納部１１５に格納されている統合ロジックのデータの一例を示す。図１０の統合ロジックは、データモデル及びデータ属性９０１とデータモデル及びデータ属性９０２とを、データモデル及びデータ属性９０３に変換するための統合ロジックである。より具体的には、図１０の例の統合ロジックには、「従業員NO」という項目のデータ型を「Number」から「String」へ変換するためのロジックと、文字コードを「SJIS」から「UTF-16」へ変換するためのロジックと、「EMPNO」という項目のデータ型を「Number」から「String」へ変換するためのロジックと、同じ項目である「従業員NO」及び「EMPNO」を結合するためのロジックと、必要なものだけを取り出すための射影のロジックとが含まれる。

このように、メタ情報格納部１１５には、情報源であるデータベースの各々に対応するデータモデル及びデータ属性と、格納先データベースに対応するデータモデル及びデータ属性と、前者を後者へ変換するための統合ロジックのデータとが格納されている。なお、図示していないが、メタ情報格納部１１５には、情報源となるデータベース毎にデータベースに関する情報（例えば接続方法など）も格納されている。

次に、図１１乃至図２９を用いて、図２に示した情報統合装置１の処理内容について説明する。まず、図１１乃至図１４を用いて、統合ロジックを初めて実行する際に行われる処理について説明する。

まず、情報統合装置１における統合処理実行部１００は、メタ情報格納部１１５に格納されているデータに従い、ＤＢ３１及びＤＢ３３から抽出したデータに対して統合処理を実行する（図１１：ステップＳ１）。ステップＳ１の処理は、例えば米国特許第６０１４６７０号及び米国特許第６３３９７７５号に開示されているような従来の技術を用いて実現することができる。具体的には、まず抽出部１０１は、ＤＢ３１及びＤＢ３３からデータを抽出し、変換部１０２に出力する。変換部１０２は、メタ情報格納部１１５に格納されているデータに従い、抽出部１０１から受け取ったデータに対して変換処理を行う。例えば図９及び図１０に示したデータモデル、データ属性及び統合ロジックがメタ情報格納部１１５に格納されている場合には、「従業員NO」及び「EMPNO」という項目の項目値のデータ型を「Number」から「String」に変換し、ＤＢ３１から抽出したデータの文字コードを「SJIS」から「UTF-16」に変換する。また、同じ項目である「従業員NO」及び「EMPNO」を結合する。さらに、「従業員NO」、「氏名」及び「部署」についてのデータのみを取り出す。このような変換処理により、目的のデータモデル及びデータ属性９０３にマッピングする。そして、変換部１０２は、変換されたデータを登録部１０３に出力する。登録部１０３は、受け取ったデータをＤＢ５１に登録する。

そして、統合処理実行部１００は、統合処理が成功したか、すなわちデータの変換が問題なく行われたか判断する（ステップＳ３）。統合処理の実行が成功しなかった場合（ステップＳ３：Ｎｏルート）、統合処理実行部１００は、処理が失敗した旨を通知するためのデータを出力部１１７を介して表示装置等に表示させる（ステップＳ５）。

一方、統合処理の実行が成功した場合（ステップＳ３：Ｙｅｓルート）、統合処理実行部１００は、スキーマ収集部１０４にスキーマ情報の収集を指示する。そして、スキーマ収集部１０４は、スキーマ収集処理を実施する（ステップＳ７）。

スキーマ収集処理については、図１２を用いて説明する。まず、スキーマ収集部１０４は、スキーマを収集するために必要なデータ（例えばＤＢ３１及びＤＢ３３の種別や、ＤＢ３１及びＤＢ３３への接続方法についてのデータ）をメタ情報格納部１１５から読み出す（ステップＳ２１）。

そして、スキーマ収集部１０４は、ＤＢ３１及びＤＢ３３に接続し、スキーマ情報を生成するために必要な情報を抽出する（ステップＳ２３）。また、スキーマ収集部１０４は、抽出された情報に対応するスキーマ定義を生成し、抽出された情報と生成されたスキーマ定義とを含むスキーマ情報を収集スキーマ格納部１０６に格納する（ステップＳ２５）。そして元の処理に戻る。

ステップＳ２３及びＳ２５の処理について、図１３及び図１４を用いて説明する。まず、ステップＳ２３において行われる処理の一例を、図１３を用いて説明する。ステップＳ２３において、スキーマ収集部１０４は、例えばＰＬ（Procedural Language）／ＳＱＬのインタフェースを用いてＤＢ３１に接続する。データの抽出対象となるテーブルのＤＤＬ（Data Definition Language）文を取得するためのＳＱＬ１３０１を実行し、例えば実行結果１３０３を取得する。そして、実行結果から項目数、項目名、データ型等のデータ構造に関する情報を抽出する。また、スキーマ収集部１０４は、文字コードの情報を取得するためのＳＱＬ１３０５を実行し、例えば実行結果１３０７を取得する。さらに、スキーマ収集部１０４は、データの抽出対象となるテーブルからデータの先頭１００レコードを抽出するためのＳＱＬを実行し、例えば実行結果１３１１を取得する。そして、抽出したレコードを解析し、エンディアン等の情報を取得する。

そして、ステップＳ２５において、抽出した情報に対応するスキーマ定義を生成する。図１４は、スキーマ定義について説明するための図である。図１４において、ＤＢ３１から取得した情報１４０３に対し、スキーマ定義１４０１が設定されており、ＤＢ３３から取得した情報１４０７に対しスキーマ定義１４０５が設定されている。ここでは、ＤＢ３１から取得した情報１４０３は、ＤＢ３１における表現形式がそのまま保持され、スキーマ定義１４０１におけるデータ構造に関する記述１４０９においてスキーマ定義１４０１に関連付けられる。なお、スキーマ定義１４０５及びＤＢ３３から取得した情報１４０７についても同様である。

図１１の説明に戻り、スキーマ収集部１０４は、スキーマ収集処理が成功したか判断する（ステップＳ９）。スキーマ収集処理が失敗したと判断された場合（ステップＳ９：Ｎｏルート）、スキーマ収集部１０４は、処理が失敗した旨を通知するためのデータを出力部１１７を介して表示装置等に表示させる（ステップＳ５）。

一方、スキーマ収集処理が成功したと判断された場合には（ステップＳ１１：Ｙｅｓルート）、スキーマ収集部１０４は、収集スキーマ格納部１０６に格納されているスキーマ情報を、スキーマ格納部１０５に格納する（ステップＳ１１）。そして処理を終了する。

以上のように、動作実績のあるスキーマに関する情報（スキーマ情報）をスキーマ格納部に保持しておくことにより、後にスキーマが変更された際に利用することができるようになる。

次に、図１５乃至図２９を用いて、図１１の処理が行われた後に、再度統合処理を実行する際に行われる処理について説明する。

まず、統合処理実行部１００は、メタ情報格納部１１５に格納されている、データモデル、データ属性及び統合ロジックを読み出し、実行データ格納部１１６に格納しておく。そして、統合処理実行部１００は、スキーマ収集部１０４に対しスキーマ情報の収集を指示する。すると、スキーマ収集部１０４は、スキーマ収集処理を実施する（図１５：Ｓ３１）。スキーマ収集処理については、図１２乃至図１４を用いて説明したとおりである。また、スキーマ収集部１０４は、スキーマ収集処理が成功したか判断する（ステップＳ３３）。スキーマ収集処理が失敗したと判断された場合（ステップＳ３３：Ｎｏルート）、処理は端子Ａを介して図２９のステップＳ５９に移行する。そして、スキーマ収集部１０４は、処理が失敗した旨を通知するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ５９）。

一方、スキーマ収集処理が成功したと判断された場合（ステップＳ３３：Ｙｅｓルート）、スキーマ収集部１０４は、スキーマ格納部１０５に格納されているスキーマ情報と、収集スキーマ格納部１０６に格納されているスキーマ情報とを比較し、スキーマの変更があるか判断する（ステップＳ３５）。例えば差分を取ることにより、スキーマの変更があるかを判断する。スキーマの変更がないと判断された場合（ステップＳ３７：Ｎｏルート）、処理は端子Ｂを介して図２９のステップＳ４９に移行する。

一方、スキーマの変更があると判断された場合（ステップＳ３７：Ｙｅｓルート）、スキーマ収集部１０４は、メインメモリ等の記憶装置に変更フラグをセットし（ステップＳ３９）、データモデル・データ属性改修部１０７にスキーマの変更が発生した旨を通知する。そして、データモデル・データ属性改修部１０７は、変更が発生したスキーマ情報に対し、データモデル・データ属性改修処理を実施する（ステップＳ４１）。なお、以下では、収集スキーマ格納部１０６に格納されている、変更が発生したスキーマ情報を変更後スキーマと呼び、スキーマ格納部１０５に格納されている、変更が発生する前のスキーマ情報を変更前スキーマと呼ぶ。

データモデル・データ属性改修処理については、図１６乃至図１９を用いて説明する。ここでは、データ型に変更が発生した場合における処理（データモデルの改修処理）について説明するが、データ属性の改修処理についても同様の処理フローにて処理を実施すればよい。

まず、データモデル・データ属性改修部１０７は、収集スキーマ格納部１０６に格納されている、変更後スキーマのデータ構造情報から未処理の項目を１つ特定する（図１６：ステップＳ７１）。そして、データモデル・データ属性改修部１０７は、ステップＳ７１において特定された項目（以下、図１６及び図１７の説明において「処理に係る項目」と呼ぶ）で、スキーマ格納部１０５に格納されている、変更前スキーマのデータ構造情報を探索する（ステップＳ７３）。

そして、データモデル・データ属性改修部１０７は、変更前スキーマのデータ構造情報において処理に係る項目が検出されたか判断する（ステップＳ７５）。変更前スキーマのデータ構造情報において処理に係る項目が検出されたと判断された場合（ステップＳ７５：Ｙｅｓルート）、データモデル・データ属性改修部１０７は、変更後スキーマのデータ構造情報に含まれる処理に係る項目の属性値と、変更前スキーマのデータ構造情報に含まれる処理に係る項目の属性値とが同じであるか判断する（ステップＳ７７）。同じであると判断された場合（ステップＳ７７：Ｙｅｓルート）、データモデル・データ属性改修部１０７は、メタ情報格納部１１５に格納されているデータモデル（以下、変更前データモデルと呼ぶ）の項目情報を、変更後データ格納部１０９に格納されているデータモデル（データモデル・データ属性改修処理により生成されるデータモデル。以下、変更後データモデルと呼ぶ）に追加する（ステップＳ８１）。

ステップＳ７１乃至Ｓ８１の処理について、図１８を用いて説明する。例えばステップＳ７１において、変更後スキーマのデータ構造情報における「氏名」又は「電話番号」という項目が特定されたとする。一方、変更前スキーマのデータ構造情報には「氏名」及び「電話番号」という項目が含まれ、且つこれらの項目の属性値は変更後スキーマの属性値と同じであるから、変更後データモデルに、変更前データモデルの項目情報をそのまま追加する。ここでは、「氏名」という項目については「String(20)」という項目情報を追加し、「電話番号」という項目については「String(11)」という項目情報を追加する。

図１６の説明に戻り、変更前スキーマのデータ構造情報において処理に係る項目が検出されない場合（ステップＳ７５：Ｎｏルート）、又は変更後スキーマのデータ構造情報に含まれる処理に係る項目の属性値と変更前スキーマのデータ構造情報に含まれる処理に係る項目の属性値とが同じではないと判断された場合（ステップＳ７７：Ｎｏルート）、データモデル・データ属性改修部１０７は、項目情報追加処理を実施する（ステップＳ７９）。項目情報追加処理については、図１７乃至図１９を用いて説明する。

まず、データモデル・データ属性改修部１０７は、対応表格納部１０８に格納されているメタ情報対応表（図３）を、処理に係る項目の属性値で探索する（図１７：ステップＳ９１）。メタ情報対応表において処理に係る項目の属性値が検出された場合（ステップＳ９３：Ｙｅｓルート）、処理に係る項目に対応する項目情報をメタ情報対応表から抽出し、変更後データモデルに追加する（ステップＳ９５）。

図１８を用いて、ステップＳ９１乃至Ｓ９５において行われる処理について説明する。例えばステップＳ７１において、変更後スキーマのデータ構造情報における「従業員NO」という項目が特定されたとする。一方、変更前スキーマのデータ構造情報には「従業員NO」という項目が含まれ、且つこの項目の属性値は「NUMBER(6,0)」であり変更後スキーマの属性値「CHAR(6)」とは異なるから、項目情報追加処理（ステップＳ７９）が行われる。そして、ステップＳ９１においてデータ型「CHAR」でメタ情報対応表を探索すると、「Schema」の列において「CHAR」が検出されるので、「Model」の列における「String」を変更後データモデルに追加する。

図１７の説明に戻り、メタ情報対応表において処理に係る項目が検出されない場合（ステップＳ９３：Ｎｏルート）、データモデル・データ属性改修部１０７は、変更前スキーマのデータ構造情報を処理に係る項目の属性値で探索する（ステップＳ９７）。処理に係る項目の属性値が検出された場合（ステップＳ９９：Ｙｅｓルート）、データモデル・データ属性改修部１０７は、当該属性値に対応する項目の項目情報を変更前データモデルから抽出し、変更後データモデルに追加する（ステップＳ１０５）。そして、データモデル・データ属性改修部１０７は、メタ情報対応表に新規のマッピング・ルールを追加する（ステップＳ１０７）。

ステップＳ１０５及びＳ１０７において行われる処理について、図１９を用いて説明する。例えばステップＳ７１において、変更後スキーマのデータ構造情報における「商品ID」という項目が特定されたとする。一方、変更前スキーマのデータ構造情報には「商品ID」という項目が含まれ、且つこの項目の属性値は「NUMBER(12,0)」であり変更後スキーマの属性値「SMALLINT」とは異なるから、項目情報追加処理（ステップＳ７９）が行われる。そして、ステップＳ９１においてデータ型「SMALLINT」でメタ情報対応表を探索すると、「Schema」の列において「SMALLINT」は検出されないので、変更前スキーマのデータ構造情報を「SMALLINT」で探索する。ここで、「SMALLINT」が検出された場合には、「SMALLINT」の項目「個数」に対応する項目情報「Integer」を変更前データモデルから抽出し、変更後データモデルに追加する。また、メタ情報対応表には、新規のマッピング・ルールとして、「Schema」の列には「SMALLINT」を格納し、「Model」の列には「Integer」を格納し、「Type」の列には「auto」を格納する。このように、メタ情報対応表に存在しないマッピング・ルールを、変更前スキーマ及び変更前データモデルを利用して導き出す。

図１７の説明に戻り、処理に係る項目の属性値が検出されない場合（ステップＳ９９：Ｎｏルート）、データモデル・データ属性改修部１０７は、項目情報の入力を促すためのデータを出力部１１７を介して表示装置等に表示させる（ステップＳ１０１）。そして、項目情報が入力された場合には、入力された項目情報を変更後データモデルに追加する（ステップＳ１０３）。また、メタ情報対応表に新規のマッピング・ルールを追加する（ステップＳ１０７）。ここでは、「Schema」の列には処理に係る項目が格納され、「Model」の列には入力された項目情報が格納され、「Type」の列には「user」が格納される。そして元の処理に戻る。

以上のような処理を実施することにより、スキーマの変更に応じて、必要なデータモデル（及びデータ属性）の改修を自動的に行うことができるようになる。

図１５の説明に戻り、データモデル・データ属性改修部１０７は、データモデル・データ属性改修処理が成功したか判断する（ステップＳ４３）。データモデル・データ属性改修処理が成功しなかった場合（ステップＳ４３：Ｎｏルート）、処理は端子Ａを介して図２９のステップＳ５９に移行する。そして、データモデル・データ属性改修部１０７は、処理が失敗した旨を通知するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ５９）。

一方、データモデル・データ属性改修処理が成功した場合（ステップＳ４３：Ｙｅｓルート）、データモデル・データ属性改修部１０７は、統合ロジック改修部１１０に統合ロジック改修処理の実行を指示する。そして、統合ロジック改修部１１０は、統合ロジック改修処理を実施する（ステップＳ４５）。統合ロジック改修処理については、図２０乃至図２８を用いて説明する。

まず、統合ロジック改修部１１０の仮変換ロジック生成部１１１は、仮変換ロジック生成処理を実施する（図２０：ステップＳ１１１）。仮変換ロジック生成処理については、図２１を用いて説明する。ここでは、データモデルについての仮変換ロジック生成処理を例にして説明するが、データ属性についても同様の処理を行う。

まず、仮変換ロジック生成部１１１は、変更後データ格納部１０９に格納されている変更後データモデルから未処理の項目（以下、図２１の説明において「処理に係る項目」と呼ぶ）を１つ特定する（図２１：ステップＳ１２１）。

そして、仮変換ロジック生成部１１１は、処理に係る項目で、メタ情報格納部１１５に格納されている変更前データモデルを探索する（ステップＳ１２３）。そして、仮変換ロジック生成部１１１は、処理に係る項目が変更前データモデルにおいて検出されたか判断する（ステップＳ１２５）。検出されなかった場合（ステップＳ１２５：Ｎｏルート）、ステップＳ１３１の処理に移行する。

一方、処理に係る項目が変更前データモデルにおいて検出されたと判断された場合（ステップＳ１２５：Ｙｅｓルート）、仮変換ロジック生成部１１１は、変更前データモデルにおいて、検出された項目に対応付けて削除フラグをセットする（ステップＳ１２７）。

ステップＳ１２７において行われる処理について、図２２を用いて説明する。例えば処理に係る項目が「EMPNO」又は「DEPT」である場合、これらの項目は変更前データモデルにも含まれるので、変更前データモデルにおける「EMPNO」及び「DEPT」という項目に対応付けて削除フラグをセットする。一方、変更前データモデルにおける「EXT」という項目は、変更後データモデルに含まれる項目ではないため、削除フラグは設定されない。なお、削除フラグは、後で説明する図２７の処理フローにて使用される。

図２１の説明に戻り、仮変換ロジック生成部１１１は、変更後データモデルを変更前データモデルに変換するための仮変換ロジックを生成し、仮変換ロジック格納部１１２に格納する（ステップＳ１２９）。そして、仮変換ロジック生成部１１１は、全ての項目について処理したか判断する（ステップＳ１３１）。全ての項目について処理していないと判断された場合（ステップＳ１３１：Ｎｏルート）、次の項目について処理を実施するため、ステップＳ１２１の処理に戻る。一方、全ての項目について処理したと判断された場合（ステップＳ１３１：Ｙｅｓルート）、元の処理に戻る。

ここで、図２３を用いて、ステップＳ１２９において行われる処理について説明する。なお、図２３の例においては、データモデルだけでなくデータ属性についての仮変換ロジックの生成についても説明している。まず、ＤＢ３１についての変更後データモデルにおいては「従業員NO」という項目のデータ型が「String」であるが、変更前データモデルにおいては「Number」であるため、データ型の変換のための仮変換ロジック２３０１が生成される。また、ＤＢ３１についての変更後データ属性においては文字コードが「JEF」であるのに対し、変更前データ属性においては「SJIS」であるため、文字コード変換のための仮変換ロジック２３０２が生成される。さらに、ＤＢ３３についての変更後データモデルにおいては「DEPT」という項目の桁数が「50」であるのに対し、変更前のデータモデルにおいては「40」であるため、桁数変換のための仮変換ロジック２３０３が生成される。このようにして生成された仮変換ロジックが、仮変換ロジック格納部１１２に格納される。

以上のようにして仮変換ロジックを用意しておけば、変更前の統合ロジックを利用して変更後の統合ロジックを効率的に生成することができる。

図２０の説明に戻り、統合ロジック改修部１１０の統合ロジック生成部１１３は、変更後統合ロジック生成処理を実施する（ステップＳ１１３）。変更後統合ロジック生成処理については、図２４乃至図２８を用いて説明する。ここでは、データモデルについての統合ロジック生成処理を例にして説明するが、データ属性についても同様の処理を行う。

まず、統合ロジック生成部１１３は、変更後データ格納部１０９に格納されている変更後データモデルから、未処理の項目（以下、図２４及び図２５の説明において「処理に係る項目」と呼ぶ）を１つ特定する（図２４：ステップＳ１４１）。そして、統合ロジック生成部１１３は、処理に係る項目についての仮変換ロジックが仮変換ロジック格納部１１２に格納されているか判断する（ステップＳ１４３）。例えば、データ型や型属性（桁数、null制約、一意性制約など）についての仮変換ロジックが仮変換ロジック格納部１１２に格納されているか判断する。

処理に係る項目についての仮変換ロジックが仮変換ロジック格納部１１２に格納されていると判断された場合（ステップＳ１４３：Ｙｅｓルート）、統合ロジック生成部１１３は、統合ロジック最適化処理を実施する（ステップＳ１４５）。統合ロジック最適化処理については、図２５及び図２６を用いて説明する。ここでは、データ型についての統合ロジック最適化処理を例にして説明する。

まず、統合ロジック生成部１１３は、メタ情報格納部１１５に格納されている統合ロジック（以下、変更前統合ロジックと呼ぶ）に、処理に係る項目についてのデータ型の変換ロジックが含まれるか判断する（ステップＳ１７１）。

データ型の変換ロジックが含まれると判断された場合（ステップＳ１７３：Ｙｅｓルート）、統合ロジック生成部１１３は、データ型の仮変換ロジックにおける変換前のデータ型をＴ１、統合ロジックに含まれるデータ型の変換ロジックにおける変換後のデータ型をＴ２と設定する（ステップＳ１７５）。

一方、データ型の変換ロジックが含まれないと判断された場合（ステップＳ１７３：Ｎｏルート）、統合ロジック生成部１１３は、データ型の仮変換ロジックにおける変換前のデータ型をＴ１、変換後のデータ型をＴ２と設定する（ステップＳ１７７）。

図２６を用いて、ステップＳ１７５及びＳ１７７において行われる処理について説明する。なお、図２６の例においては、データ型だけでなく、データ属性等の処理についても説明している。図２６において、「従業員NO」という項目には、データ型の仮変換ロジックが存在し、且つ変更前の統合ロジックにおいてもデータ型の変換ロジックが存在するから、データ型の仮変換ロジックにおける変換前のデータ型「Str」をＴ１ａと設定し、統合ロジックに含まれるデータ型の変換ロジックにおける変換後のデータ型「Str」をＴ２ａと設定する。また、文字コードには、仮変換のロジックが存在し、且つ変更前の統合ロジックにおいても文字コードの変換ロジックが存在するから、文字コードの仮変換ロジックにおける変換前の文字コード「JEF」をＴ１ｂと設定し、統合ロジックに含まれる文字コードの変換ロジックにおける変換後の文字コード「UTF-16」をＴ２ｂと設定する。一方、「DEPT」という項目には、桁数の仮変換ロジックが存在しているが、統合ロジックには桁数についての変換ロジックが存在しないため、桁数の仮変換ロジックにおける変換前の桁数「50」をＴ１ｃと設定し、桁数の仮変換ロジックにおける変換後の桁数「40」をＴ２ｃと設定する。

図２５の説明に戻り、ステップＳ１７５又はＳ１７７の後、統合ロジック生成部１１３は、Ｔ１からＴ２に至るコストが最小となる最適な変換経路を、データ型変換の変換経路表を用いて探索する（ステップＳ１７９）。

ステップＳ１７９において行われる処理について、図２６を用いて説明する。図２６の例では、Ｔ１ａ（Str）からＴ２ａ（Str）への変換は、同じ値への変換となるため、変換を行わないことがコスト０で最適となる。また、Ｔ１ｂ（JEF）からＴ２ｂ（UTF-16）への変換については、変換経路表（図４）を参照すると、（１）JEF→SJIS→UTF-16（コストの合計：70）という経路、（２）JEF→SJIS→UTF-8→UTF-16（コストの合計：100）という経路、（３）JEF→U90→UTF-16（コストの合計：50）という経路、及び（４）JEF→U90→UTF-8→UTF-16（コストの合計：90）という経路が存在する。この中で、コストが最小となるのは（３）の経路であるから、（３）の経路が最適となる。また、Ｔ１ｃ（50）からＴ２ｃ（40）への変換については、変換経路表（図７）に従い、そのまま変換することが最適となる。なお、図２６に示した仮変換ロジック及び変更前の統合ロジックから、最適な変換経路を選択して変更後の統合ロジックを生成すると、図２８に示すような統合ロジックが完成する。

図２５の説明に戻り、Ｔ１からＴ２に至るコストが最小となる最適な変換経路が特定された場合（ステップＳ１８１：Ｙｅｓルート）、統合ロジック生成部１１３は、変換経路表格納部１１４において、特定された変換経路に対してNEQフラグがセットされているか判断する（ステップＳ１８５）。NEQフラグがセットされている場合（ステップＳ１８５：Ｙｅｓルート）、統合ロジック生成部１１３は、変換を行ってよいか確認するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ１８７）。図２６の例であれば、Ｔ１ｃ（50）からＴ２ｃ（40）への変換については変換経路表（図７）にNEQフラグがセットされているため、ステップＳ１８５の処理が行われる。そして、NEQフラグがセットされていない場合（ステップＳ１８５：Ｎｏルート）又はステップＳ１８７の処理の後管理者等から変換を指示された場合、統合ロジック生成部１１３は、新たに生成されたデータ型の変換ロジックで実行データ格納部１１６を更新する（ステップＳ１８９）。すなわち、変更前のデータ型の変換ロジックを新たに生成されたデータ型の変換ロジックで置換する。そして元の処理に戻る。

一方、Ｔ１からＴ２に至るコストが最小となる変換経路が特定されなかった（すなわち、変換経路が存在しない）場合（ステップＳ１８２：Ｎｏルート）、統合ロジック生成部１１３は、改修不能な変更があることを通知するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ１８３）。そして元の処理に戻る。

以上のような処理を実施することにより、情報統合のための処理に要するコストを抑えた形で変更後の統合ロジックを生成することができるようになる。

図２４の説明に戻り、統合ロジック生成部１１３は、全ての項目について処理したか判断する（ステップＳ１４７）。全ての項目について処理していない場合（ステップＳ１４７：Ｎｏルート）、次の項目について処理を実施するため、ステップＳ１４１の処理に戻る。一方、全ての項目について処理した場合（ステップＳ１４７：Ｙｅｓルート）、処理は端子Ｃを介して図２７のステップＳ１４９に移行する。

図２７の説明に移行して、統合ロジック生成部１１３は、メタ情報格納部１１５に格納されている変更前データモデルにおいて、削除フラグがセットされていない未処理の項目を探索する（ステップＳ１４９）。削除フラグがセットされていない未処理の項目が検出されなかった場合（ステップＳ１５１：Ｎｏルート）、統合ロジック生成部１１３は、新たに生成された変更後データモデルで実行データ格納部１１６を更新し（すなわち、変更前のデータモデルを変更後のデータモデルで置換し）、元の処理に戻る。そして、統合ロジック改修処理を終了し、図１５のステップＳ４７に戻る。

一方、削除フラグがセットされていない未処理の項目が検出された場合（ステップＳ１５１：Ｙｅｓルート）、統合ロジック生成部１１３は、メタ情報格納部１１５に格納されている統合ロジックに、検出された項目についての変換ロジックが含まれるか判断する（ステップＳ１５３）。検出された項目についての変換ロジックが含まれないと判断された場合（ステップＳ１５５：Ｎｏルート）、ステップＳ１４９の処理に戻る。一方、検出された項目についての変換ロジックが含まれると判断された場合（ステップＳ１５５：Ｙｅｓルート）、統合ロジック生成部１１３は、変更前の統合ロジックに関係する項目が変更後データモデルにおいて削除されている旨を通知するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ１５７）。そしてステップＳ１４９に戻る。

なお、削除フラグがセットされていない項目とは、変更前データモデルには存在するが変更後データモデルには存在しない項目、すなわち変更後データモデルからは削除された項目である。そのような項目についての変換ロジックが変更前の統合ロジックに存在する場合には、変更後の統合ロジックにも影響を及ぼす可能性がある。従って、管理者等に確認を促すため、ステップＳ１５７の処理を行っている。

以上のような処理を実施すれば、管理者等が統合ロジックを改修する手間を削減することができるようになる。

図１５の説明に戻り、統合ロジック改修部１１０は、統合ロジック改修処理が成功したか判断する（ステップＳ４７）。統合ロジック改修処理が失敗したと判断された場合（ステップＳ４７：Ｎｏルート）、処理は端子Ａを介して図２９のステップＳ５９に移行する。そして、統合ロジック改修部１１０は、処理が失敗した旨を通知するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ５９）。一方、統合ロジック改修処理が成功したと判断された場合（ステップＳ４７：Ｙｅｓルート）、処理は端子Ｂを介して図２９のステップＳ４９に移行する。

図２９の説明に移行して、統合処理実行部１００は、実行データ格納部１１６に格納されているデータモデル、データ属性及び統合ロジックに基づき、統合処理を実行する（ステップＳ４９）。そして、統合処理実行部１００は、統合処理が成功したか判断する（ステップＳ５１）。統合処理が失敗したと判断された場合（ステップＳ５１：Ｎｏルート）、統合処理実行部１００は、処理が失敗した旨を通知するためのデータを出力部１１７を介して表示装置に表示させる（ステップＳ５９）。

一方、統合処理が成功したと判断された場合（ステップＳ５１：Ｙｅｓルート）、統合処理実行部１００は、ステップＳ３９において変更フラグがセットされたか判断する（ステップＳ５３）。変更フラグがセットされていない場合（ステップＳ５３：Ｎｏルート）、処理を終了する。

一方、変更フラグがセットされている場合（ステップＳ５３：Ｙｅｓルート）、統合処理実行部１００は、収集スキーマ格納部１０６に格納されている変更後スキーマでスキーマ格納部１０５を更新する（ステップＳ５５）。また、統合処理実行部１００は、実行データ格納部１１６に格納されている変更後のデータモデル、データ属性及び統合ロジックでメタ情報格納部１１５を更新する（ステップＳ５７）。そして処理を終了する。

以上のように、情報源であるデータベースのスキーマの変更に伴い必要となるメタ情報（データモデル、データ属性及び統合ロジックなど）の改修を自動的に行えば、管理者等による改修作業は不要となり、システムの運用コストを削減できるようになる。

以上、本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上で説明した情報統合装置１の機能ブロック図は必ずしも実際のプログラムモジュール構成に対応するものではない。

また、上で説明した各テーブルの構成は一例であって、必ずしも上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、上で述べた情報統合装置１は、コンピュータ装置であって、図３０に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本技術の実施の形態をまとめると以下のようになる。

本情報統合方法は、情報源から抽出したデータを変換して格納先に登録するコンピュータにより実行される。そして、本情報統合方法は、（Ａ）情報源（例えばデータベースやファイル）から取得した第１のスキーマ情報と、当該第１のスキーマ情報の変更前に情報源から取得した第２のスキーマ情報とを比較し、情報源のスキーマの変更を検出するステップと、（Ｂ）スキーマの変更に関連する項目の属性値で、スキーマ情報に含まれる属性値とデータモデルにおける項目情報とを対応付けて格納する対応表格納部を探索するステップと、（Ｃ）対応表格納部においてスキーマの変更に関連する項目の属性値が検出された場合には、当該スキーマの変更に関連する項目の属性値に対応する項目情報を用いて、第２のスキーマ情報に対応するデータモデルである変更前データモデルを格納するメタ情報格納部に格納されている変更前データモデルを改修して変更後データモデルを生成し、記憶装置に格納するステップと、（Ｄ）記憶装置に格納された変更後データモデルを、格納先に対応するデータモデルに変換するための変更後統合ロジックを生成し、メタ情報格納部に格納するロジック改修ステップとを含む。

このような構成であれば、情報源のスキーマが変更されたとしても、変更に伴い必要となる改修作業を管理者等が行う必要は無いため、システムの運用コストを削減できる。なお、データモデル（例えばデータ型やデータ長などデータの構造を表現するデータ）だけではなく、データ属性（例えば文字コードやエンディアンなどデータの構造以外の性質を表すデータ）についても同様の処理にて対処することができる。

なお、情報源や格納先のシステムとしては一般にデータベースが使用されるが、ＣＳＶ（Comma Separated Values）やＸＭＬ（Extensible Markup Language）といったファイルが利用されることも多い。本実施の形態では情報源、格納先システムともにデータベースであることを前提として説明するが、ファイルであった場合にも、例えばデータプロファイリング（解析）などの手法を用いてデータベースのスキーマに相当する情報を構築することにより、本技術の適用が可能である。

また、対応表格納部においてスキーマの変更に関連する項目の属性値が検出されなかった場合には、当該スキーマの変更に関連する項目の属性値が第２のスキーマ情報に含まれるか判断するステップと、スキーマの変更に関連する項目の属性値が第２のスキーマ情報に含まれると判断された場合には、当該第２のスキーマ情報から、スキーマの変更に関連する項目の属性値に対応する項目を特定するステップと、特定された項目に対応する項目情報を変更前データモデルから抽出し、当該項目情報を用いて、変更前データモデルを改修して変更後データモデルを生成し、記憶装置に格納する抽出ステップとをさらに含むようにしてもよい。対応表格納部には格納されていない対応付けのルールを、第２のスキーマ情報及び変更前のデータモデルを利用して導き出すものである。

また、スキーマの変更に関連する項目の属性値と抽出ステップにおいて抽出された項目情報とを対応付けて対応表格納部に格納する新規ルール生成ステップをさらに含むようにしてもよい。これにより、新たに導き出された対応付けのルールを次回以降も利用できるようになる。

また、上で述べたメタ情報格納部には、変更前データモデルを格納先に対応するデータモデルに変換するための変更前統合ロジックがさらに格納されるようにしてもよい。そして、上で述べたロジック改修ステップが、記憶装置に格納されている変更後データモデルを、メタ情報格納部に格納されている変更前データモデルに変換するための仮変換ロジックを生成するステップと、生成された仮変換ロジックとメタ情報格納部に格納されている変更前統合ロジックとに基づき、変更後データモデルを格納先に対応するデータモデルに変換するための変更後統合ロジックを生成する生成ステップとを含むようにしてもよい。これにより、変更前統合ロジックを活用して効率的に変更後統合ロジックを生成することができるようになる。

また、上で述べた生成ステップが、変換経路のデータと変換に要するコストとを対応付けて格納する変換経路表に格納されているデータを用いて、変更後データモデルから格納先に対応するデータモデルへの変換に要するコストが最小となる変換経路を特定し、特定された当該変換経路で変換を行うように変更後統合ロジックを生成するステップを含むようにしてもよい。このようにすれば、統合ロジックの変更後において、情報統合のための処理に要するコストを抑制することができるようになる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
情報源から抽出したデータを変換して格納先に登録するための情報統合プログラムであって、
前記情報源から取得した第１のスキーマ情報と、当該第１のスキーマ情報の変更前に前記情報源から取得した第２のスキーマ情報とを比較し、前記情報源のスキーマの変更を検出するステップと、
前記スキーマの変更に関連する項目の属性値で、スキーマ情報に含まれる属性値とデータモデルにおける項目情報とを対応付けて格納する対応表格納部を探索するステップと、
前記対応表格納部において前記スキーマの変更に関連する項目の属性値が検出された場合には、当該スキーマの変更に関連する項目の属性値に対応する項目情報を用いて、前記第２のスキーマ情報に対応するデータモデルである変更前データモデルを格納するメタ情報格納部に格納されている前記変更前データモデルを改修して変更後データモデルを生成し、記憶装置に格納するステップと、
前記記憶装置に格納された前記変更後データモデルを、前記格納先に対応するデータモデルに変換するための変更後統合ロジックを生成し、前記メタ情報格納部に格納するロジック改修ステップと、
を、コンピュータに実行させるための情報統合プログラム。

（付記２）
前記対応表格納部において前記スキーマの変更に関連する項目の属性値が検出されなかった場合には、当該スキーマの変更に関連する項目の属性値が前記第２のスキーマ情報に含まれるか判断するステップと、
前記スキーマの変更に関連する項目の属性値が前記第２のスキーマ情報に含まれると判断された場合には、当該第２のスキーマ情報から、前記スキーマの変更に関連する項目の属性値に対応する項目を特定するステップと、
特定された前記項目に対応する項目情報を前記変更前データモデルから抽出し、当該項目情報を用いて、前記変更前データモデルを改修して変更後データモデルを生成し、前記記憶装置に格納する抽出ステップと、
を、さらに実行させるための付記１記載の情報統合プログラム。

（付記３）
前記スキーマの変更に関連する項目の属性値と前記抽出ステップにおいて抽出された項目情報とを対応付けて前記対応表格納部に格納する新規ルール生成ステップ
を、さらに実行させるための付記２記載の情報統合プログラム。

（付記４）
前記メタ情報格納部には、前記変更前データモデルを前記格納先に対応するデータモデルに変換するための変更前統合ロジックがさらに格納されており、
前記ロジック改修ステップが、
前記記憶装置に格納されている前記変更後データモデルを、前記メタ情報格納部に格納されている前記変更前データモデルに変換するための仮変換ロジックを生成するステップと、
生成された前記仮変換ロジックと前記メタ情報格納部に格納されている前記変更前統合ロジックとに基づき、前記変更後データモデルを前記格納先に対応するデータモデルに変換するための変更後統合ロジックを生成する生成ステップと、
を含む、付記１乃至３のいずれか１つ記載の情報統合プログラム。

（付記５）
前記生成ステップが、
変換経路のデータと変換に要するコストとを対応付けて格納する変換経路表に格納されているデータを用いて、前記変更後データモデルから前記格納先に対応するデータモデルへの変換に要するコストが最小となる変換経路を特定し、特定された当該変換経路で変換を行うように前記変更後統合ロジックを生成するステップ
を含む、付記４記載の情報統合プログラム。

（付記６）
情報源から抽出したデータを変換して格納先に登録する情報統合装置であって、
スキーマ情報に含まれる属性値とデータモデルにおける項目情報とを対応付けて格納する対応表格納部と、
前記情報源から取得した第１のスキーマ情報に対応するデータモデルである変更前データモデルを格納するメタ情報格納部と、
前記第１のスキーマ情報と、当該第１のスキーマ情報の変更後に前記情報源から取得した第２のスキーマ情報とを比較し、前記情報源のスキーマの変更を検出するスキーマ収集部と、
前記スキーマの変更に関連する項目の属性値で前記対応表格納部を探索し、前記スキーマの変更に関連する項目の属性値が検出された場合には、当該スキーマの変更に関連する項目の属性値に対応する項目情報を用いて、前記メタ情報格納部に格納されている前記変更前データモデルを改修して変更後データモデルを生成するデータモデル改修部と、
生成された前記変更後データモデルを、前記格納先に対応するデータモデルに変換するための変更後統合ロジックを生成し、前記メタ情報格納部に格納する統合ロジック改修部と、
を有する情報統合装置。

（付記７）
情報源から抽出したデータを変換して格納先に登録するコンピュータにより実行される情報統合方法であって、
前記情報源から取得した第１のスキーマ情報と、当該第１のスキーマ情報の変更前に前記情報源から取得した第２のスキーマ情報とを比較し、前記情報源のスキーマの変更を検出するステップと、
前記スキーマの変更に関連する項目の属性値で、スキーマ情報に含まれる属性値とデータモデルにおける項目情報とを対応付けて格納する対応表格納部を探索するステップと、
前記対応表格納部において前記スキーマの変更に関連する項目の属性値が検出された場合には、当該スキーマの変更に関連する項目の属性値に対応する項目情報を用いて、前記第２のスキーマ情報に対応するデータモデルである変更前データモデルを格納するメタ情報格納部に格納されている前記変更前データモデルを改修して変更後データモデルを生成し、記憶装置に格納するステップと、
前記記憶装置に格納された前記変更後データモデルを、前記格納先に対応するデータモデルに変換するための変更後統合ロジックを生成し、前記メタ情報格納部に格納するロジック改修ステップと、
を含む情報統合方法。

１ 情報統合装置
１００ 統合処理実行部 １０１ 抽出部
１０２ 変換部 １０３ 登録部
１０４ スキーマ収集部 １０５ スキーマ格納部
１０６ 収集スキーマ格納部 １０７ データモデル・データ属性改修部
１０８ 対応表格納部 １０９ 変更後データ格納部
１１０ 統合ロジック改修部 １１１ 仮変換ロジック生成部
１１２ 仮変換ロジック格納部 １１３ 統合ロジック生成部
１１４ 変換経路表格納部 １１５ メタ情報格納部
１１６ 実行データ格納部 １１７ 出力部
３ 情報源システム ３１，３３ ＤＢ
５ 格納先システム ５１，５３ ＤＢ

Claims (7)

1. 情報源から抽出したデータを変換して格納先に記憶する情報統合プログラムであって、
   前記情報源から取得した、第１のスキーマ情報に含まれるデータ項目と、当該第１のスキーマ情報の変更前のスキーマ情報である第２のスキーマ情報に含まれるデータ項目とに基づいて、前記第２のスキーマ情報に含まれるデータ項目について属性値と前記第２のスキーマ情報に対応する変更前データモデルにおけるデータ項目情報とを対応付けて記憶する第１記憶部に記憶された、前記第１のスキーマ情報に含まれる属性値を探索し、
   探索の結果、前記第１のスキーマ情報に含まれる属性値が検出された場合、検出された該属性値に対応付けて前記第１記憶部に記憶されたデータ項目情報に基づいて、前記第１のスキーマ情報に対応する変更後データモデルを生成する処理
   を、コンピュータに実行させる情報統合プログラム。
2. 請求項１記載の情報統合プログラムであって、前記コンピュータに、
   第２記憶部に記憶され且つ変換経路のデータと変換に要するコストとを対応付けた変換経路情報を参照して、前記変更後データモデルから前記格納先に対応するデータモデルへの変換に要するコストが最小となる変換経路を特定し、特定された当該変換経路で変換を行う統合ロジックを生成する、
   ことをさらに実行させる情報統合プログラム。
3. 前記探索の結果、前記第１のスキーマ情報に含まれる属性値が検出されなかった場合には、当該第１のスキーマ情報に含まれる属性値が前記第２のスキーマ情報に含まれるか判断し、
   前記第１のスキーマ情報に含まれる属性値が前記第２のスキーマ情報に含まれると判断された場合には、当該第２のスキーマ情報から、前記第１のスキーマ情報に含まれる属性値に対応する項目を特定し、
   特定された前記項目に対応するデータ項目情報を前記第２のスキーマ情報に対応するデータモデルである変更前データモデルから抽出し、当該データ項目情報を用いて、前記変更前データモデルを改修して変更後データモデルを生成する
   処理を、さらに実行させる請求項１又は２記載の情報統合プログラム。
4. 前記第１のスキーマ情報に含まれる属性値と前記変更前データモデルから抽出された前記データ項目情報とを対応付けて前記第１記憶部に格納する処理
   を、さらに実行させる請求項３記載の情報統合プログラム。
5. 前記統合ロジックを生成する処理が、
   前記変更後データモデルを、前記第２のスキーマ情報に対応するデータモデルである変更前データモデルに変換するための仮変換ロジックを生成し、
   生成された前記仮変換ロジックと前記変更前データモデルを前記格納先に対応するデータモデルに変換する変更前統合ロジックとに基づき、前記変更後データモデルを前記格納先に対応するデータモデルに変換する統合ロジックを生成する処理、
   を含む、請求項２記載の情報統合プログラム。
6. 情報源から抽出したデータを変換して格納先に記憶する情報統合装置であって、
   前記情報源から取得した、第１のスキーマ情報に含まれるデータ項目と、当該第１のスキーマ情報の変更前のスキーマ情報である第２のスキーマ情報に含まれるデータ項目とに基づいて、前記第２のスキーマ情報に含まれるデータ項目について属性値と前記第２のスキーマ情報に対応する変更前データモデルにおけるデータ項目情報とを対応付けて記憶する第１記憶部に記憶された、前記第１のスキーマ情報に含まれる属性値を探索する手段と、
   探索の結果、前記第１のスキーマ情報に含まれる属性値が検出された場合、検出された該属性値に対応付けて前記第１記憶部に記憶されたデータ項目情報に基づいて、前記第１のスキーマ情報に対応する変更後データモデルを生成する手段と
   を有する情報統合装置。
7. 情報源から抽出したデータを変換して格納先に記憶するコンピュータにより実行される情報統合方法であって、
   前記情報源から取得した、第１のスキーマ情報に含まれるデータ項目と、当該第１のスキーマ情報の変更前のスキーマ情報である第２のスキーマ情報に含まれるデータ項目とに基づいて、前記第２のスキーマ情報に含まれるデータ項目について属性値と前記第２のスキーマ情報に対応する変更前データモデルにおけるデータ項目情報とを対応付けて記憶する第１記憶部に記憶された、前記第１のスキーマ情報に含まれる属性値を探索し、
   探索の結果、前記第１のスキーマ情報に含まれる属性値が検出された場合、検出された該属性値に対応付けて前記第１記憶部に記憶されたデータ項目情報に基づいて、前記第１のスキーマ情報に対応する変更後データモデルを生成する処理
   を含む情報統合方法。

Images