(57)【要約】【課題】複数の取り出し元データ間の整合性を確保した状態のデータを参照可能にするデータ処理システムのデータ処理方法を提供する。【解決手段】データ処理システムは、アプリケーションにとって整合性が確保される条件を示した整合性条件１２５と、アプリケーションから参照可能となるデータを示した整合性対象１２６と、整合性条件を満たした際に参照可能とするデータを断定するために必要となるグループキー１２７からなる整合性定義１２４を備え、任意のデータベースからリアルタイムに得られた更新情報全てをバッファに一時格納し、得られた更新情報がそれを参照するアプリケーションにとって整合性を確保する必要があるとき、更新情報が整合性条件を満たすか否かを判定し、整合性条件を満たした時点でそれまでにバッファに格納した更新情報からグループキーと整合性対象で絞り込んだ全ての更新情報を参照可能な状態にする。【選択図】図１
2010231323.tif 000002
【特許請求の範囲】
【請求項１】
複数存在する第１のデータ蓄積領域が更新されたときに送信される更新データを受信し、第２のデータ蓄積領域に反映するデータ処理システムのデータ処理方法であって、
前記データ処理システムは、
前記第１のデータ蓄積領域から前記第２のデータ蓄積領域に反映する複数の対象を定義した対象情報と、前記更新データを前記第２のデータ蓄積領域に反映するための条件を定義した反映条件と、複数の前記更新データを関連付けるグループ化情報を含んでなる定義情報を有しており、
前記更新データを受信すると一時蓄積し、さらに前記更新データを受信したときに、前記グループ化情報に基づき、前記受信した更新データと、前記一時蓄積されている更新データとの間のデータの関連付けを行い、
前記関連付けを行ったデータに対して、前記第２のデータ蓄積領域に反映する対象に対応する、前記反映条件が成立するか否かを確認し、
前記反映条件が成立する場合に、前記対象情報から導き出される対象データを前記一時蓄積されているデータから抽出し、抽出したデータを前記第２のデータ蓄積領域に反映する
ことを特徴とするデータ処理方法。
【請求項２】
複数存在する第１のデータ蓄積領域が更新されたときに送信される更新データを受信し、第２のデータ蓄積領域に反映するデータ処理システムのデータ処理方法であって、
前記データ処理システムは、
前記第１のデータ蓄積領域から前記第２のデータ蓄積領域に反映する複数の対象を定義した対象情報と、前記更新データを前記第２のデータ蓄積領域に反映するための条件を定義した反映条件と、複数の前記更新データを関連付けるグループ化情報を含んでなる定義情報をそれぞれ複数有しており、
さらに、前記複数の定義情報の中で、異なる二つ以上の定義情報で前記対象情報の一部が重複した場合、それぞれの前記対象情報の一部が重複した定義情報を合わせた、新たな定義情報を生成する定義情報適正化部を有しており、
前記更新データを受信すると一時蓄積し、さらに前記更新データを受信したときに、前記新たな定義情報の生成対象とならなかった定義情報の前記グループ化情報と、前記新たな定義情報の前記グループ化情報とに基づき、前記受信した更新データと、一時蓄積されている更新データとの間のデータの関連付けを行い、
前記関連付けを行ったデータに対して、前記第２のデータ蓄積領域に反映する対象に対応する、前記反映条件が成立するか否かを確認し、
前記反映条件が成立する場合に、前記対象情報から導き出される対象データを前記一時蓄積されているデータから抽出することを繰り返し、抽出したデータを第２のデータ蓄積領域に反映する
ことを特徴とするデータ処理方法。
【請求項３】
前記更新データは、
特定の対象データ、前記対象データの一意性を保障するためのユニークなデータ、前記対象データの更新前の状態を表す更新前状態情報を少なくとも含む更新前のデータ情報と、
前記対象データ、前記ユニークなデータ、前記対象データの更新後の状態を表す更新後状態情報を少なくとも含む更新後のデータ情報とを、含んでなる
ことを特徴とする請求項１または請求項２に記載のデータ処理方法。
【請求項４】
前記反映条件は、特定のデータが特定の形式となることが条件である
ことを特徴とする請求項１または請求項２に記載のデータ処理方法。
【請求項５】
前記反映条件は、少なくとも一つ以上の特定のデータの有無が条件である
ことを特徴とする請求項１または請求項２に記載のデータ処理方法。
【請求項６】
前記反映条件は、少なくとも一つ以上の特定のデータあるいはその計算結果が特定の値となったことを条件とする
ことを特徴とする請求項１または請求項２に記載のデータ処理方法。
【請求項７】
複数存在する第１のデータ蓄積領域が更新されたときに送信される更新データを受信し、第２のデータ蓄積領域に反映するデータ処理システムであって、
前記第１のデータ蓄積領域から前記第２のデータ蓄積領域に反映する複数の対象を定義した対象情報と、前記更新データを前記第２のデータ蓄積領域に反映するための条件を定義した反映条件と、複数の前記更新データを関連付けるグループ化情報を含んでなる定義情報を有し、
前記更新データを受信すると一時蓄積し、さらに前記更新データを受信したときに、前記グループ化情報に基づき、前記受信した更新データと、前記一時蓄積されている更新データとの間のデータの関連付けを行い、
前記関連付けを行ったデータに対して、前記第２のデータ蓄積領域に反映する対象に対応する、前記反映条件が成立するか否かを確認し、
前記反映条件が成立する場合に、前記対象情報から導き出される対象データを前記一時蓄積されているデータから抽出し、抽出したデータを前記第２のデータ蓄積領域に反映する
ことを特徴とするデータ処理システム。
【請求項８】
前記更新データは、
特定の対象データ、前記対象データの一意性を保障するためのユニークなデータ、前記対象データの更新前の状態を表す更新前状態情報を少なくとも含む更新前のデータ情報と、
前記対象データ、前記ユニークなデータ、前記対象データの更新後の状態を表す更新後状態情報を少なくとも含む更新後のデータ情報とを、含んでなり、
前記反映条件は、
特定のデータが特定の形式となるという条件、少なくとも一つ以上の前記特定のデータの有無という条件、少なくとも一つ以上の前記特定のデータあるいはその計算結果が特定の値となるという条件、のうち少なくとも一つ以上の条件である
ことを特徴とする請求項７に記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、企業内における実業務のデータを蓄積する業務システムと業務データを分析する分析システムが存在する企業内情報システムにおいて、業務システムから分析システムへ業務データを反映する方法に関する。
【背景技術】
【０００２】
近年、企業の中に蓄積された業務データを集約、分析、整理することで、生産性を向上させたり、経営に活かしたりする分析系の業務が重要となってきている。分析系の業務では、実業務を行なう業務システムが作成したデータを収集して、実業務データの複製を作成したものを参照する。従来、分析業務のためのデータの収集は、週次や日次の定期間（もしくは一定量）データを集め、まとめて一括処理を行なうバッチ処理により行なわれていた。
【０００３】
分析結果が幅広く活用されるようになり、分析業務を実施するユーザとって正に今の情報であるリアルタイムなデータを含めた業務分析を実施したいといった要望が高まってきている。しかし、週次や日次のバッチ処理にて収集されたデータを分析システムで参照する場合、情報を参照するタイミングによっては古い情報しか参照できない。このような要望にこたえるための技術として、特許文献１に開示されている技術などがある。
【０００４】
これとは別に、既存の企業内情報システムにおいて、業務システムや分析システムに変更を加えずに、バッチ処理システムで実行していた部分をリアルタイムにデータを収集するシステムに置き換えることを考える。このような考えに基づき、データを収集する技術として、特許文献２に開示されているレプリケーションが挙げられる。レプリケーションでは、業務システムにおいてデータを更新すると、業務システム側のデータベースと全ての分析システム側のデータベースに自動的に更新内容が伝播する。この技術を用いることで、業務システムから分析システムへ、リアルタイムに業務データを反映させることが可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−７８４６４号公報
【特許文献２】特開平１１−００７４０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
実際の分析業務では、１つの業務システム内に格納される業務データだけでなく、データの管理元が異なる複数の業務システムから集めた複数の業務データを横断的に組み合わせたものが扱われる。図１８に示すように、企業内情報システムは、大きく業務サーバと分析サーバで構成される。業務サーバは、業務サーバ１（１８０２）から業務サーバ３（１８０４）の様に、企業内で行なう業務毎に存在し、それぞれの業務担当者１８１８，１８１９，１８２０が作業情報１８１４，１８１５，１８１６を業務アプリ（業務アプリケーション）１８１０，１８１１，１８１２を使用して業務サーバに格納する。
【０００７】
分析者１８１７は、分析サーバ１８０１で分析アプリ（分析アプリケーション）１８０９を使用して分析を実施し、分析結果１８１３を取得する。分析アプリは、各業務サーバの業務データ（ＴＡＢＬＥ１（１８２５）、ＴＡＢＬＥ２（１８２６）、ＴＡＢＬＥ３（１８２７）、ＴＡＢＬＥ４（１８２８））の複製の業務データ（ＴＡＢＬＥ１ａ（１８２１）、ＴＡＢＬＥ２ａ（１８２２）、ＴＡＢＬＥ３ａ（１８２３）、ＴＡＢＬＥ４ａ（１８２４））を参照し分析を行なう。ここで、各業務サーバの業務データの複製の業務データを作成することを考える。
【０００８】
バッチ処理で行なう場合、所定期間業務サーバ側の作業を停止し、各業務データの複製を一括して作成する。本方式の場合、前述したように情報を参照するタイミングによっては古い情報しか参照できない。また、業務サーバ側の作業を停止しなければならないと言う問題がある。
【０００９】
従来のリアルタイムに業務データを反映させる手法であるレプリケーションで行なう場合、業務サーバ１（１８０２）に新たな業務データが入力された場合、入力されたデータがＴＡＢＬＥ１（１８２５）から複製のＴＡＢＬＥ１ａ（１８２１）に反映される。同様に、業務サーバ２（１８０３）や業務サーバ３（１８０４）の情報の反映が、それぞれ独立して行なわれる。各業務サーバ単独では整合性が確保できているが、業務サーバ間の整合性は考慮されていない。そのため、業務横断の分析実行時に不整合な情報を参照し、間違った判断をすることで分析業務に影響を与える可能性がある。問題が発生する具体例を、図１８を参照して、さらに説明する。
【００１０】
図１８の企業内システムを、製造業の歩留まり監視システムを例として説明する。製造作業者が、工程管理情報、原材料投入情報、製造実績情報、不良実績情報を管理する。製造作業者１（１８１８）が製造工程管理を行い、製品の製造工程情報をＴＡＢＬＥ１（１８２５）に登録する。製造作業者２（１８１９）が原材料投入実績の管理を行い、製品製造時に投入した原材料の情報を、ＴＡＢＬＥ２（１８２６）に登録する。製造作業者３（１８２０）が製造された製品の管理を行い、製品実績と検査により見つかった不良の実績情報をそれぞれＴＡＢＬＥ３（１８２７）、ＴＡＢＬＥ４（１８２８）に登録する。製造作業管理者（１８１７）がこれら情報から導出した歩留率の変動を参照することで、不良品の状況やラインの問題を発見し対応する。
【００１１】
例えば、ＴＡＢＬＥ１ａ（１８２１）が製造工程情報、ＴＡＢＬＥ２ａ（１８２２）が原材料投入実績、ＴＡＢＬＥ３ａ（１８２３）が製品実績、ＴＡＢＬＥ４ａ（１８２４）が不良の実績情報を製品毎に管理しているものとする。このとき製品毎に歩留率を算出する。歩留率は、製造実績／材料投入実績で算出されるものとする。各情報は、工程情報毎に製造工程情報が更新され、製造開始時に製造に使用する原材料の情報が更新され、製品検査時に不良の実績、製品完成時に製品実績が更新される。業務データの反映をレプリケーションで行なうと、前記各情報の更新時に値の反映が行なわれる。
【００１２】
工程の進行に伴い各情報に値が入力され、製造ロット番号が０００１番の材料投入実績に５０、同じく製造ロット番号が０００１番の製造実績に４０、不良の実績に１０が入力された場合、歩留率は８０％となる。続いて製造が行なわれ、前記と同製品で製造ロット番号が０００２番の製造を開始した状態では、材料投入実績が入力され、その値がレプリケーションにより分析サーバにも反映される。この時、対象製品の材料投入実績量だけが増加し、その結果、対象製品の歩留率の値が悪くなってしまう。この後、検査が行なわれ、製品が完成すると、不良の実績、製品実績が入力され、正しい歩留率が算出される。
【００１３】
以上の様に、レプリケーションによりリアルタイムに業務データを反映させただけでは、業務間（業務サーバ間）の整合性を取ることができず、正しくない分析が行なわれてしまう恐れがある。
【００１４】
そこで、１つのデータベース管理システムに閉じた業務データ単体の整合性が保障されるだけでなく、分析システムで扱う全ての業務データ間で整合性を保障する必要がある。
【００１５】
本発明は、上記の課題を解決するための発明であって、複数の取出し元のデータを、ビジネスイベントなどのタイミングで一括反映させることにより、複数の取り出し元データ間の整合性を確保した状態のデータを参照可能にするデータ処理方法およびデータ処理システムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成するため、本発明では、複数存在する第１のデータ蓄積領域が更新されたときに送信される更新データを継続的に受信し、第２のデータ蓄積領域に反映するデータ処理システムのデータ処理方法であって、データ処理システムは、第１のデータ蓄積領域から第２のデータ蓄積領域に反映する複数の対象を定義した対象情報と、更新データを第２のデータ蓄積領域に反映するための条件を定義した反映条件と、複数の更新データを関連付けるグループ化条件情報を含んでなる定義情報を有しており、第１のデータ蓄積領域から送信された更新データを一時的に記憶領域に蓄積し、さらに、更新データの受信したとき、グループ化情報に基づき、受信した更新データと、一時蓄積されている更新データと間のデータの関連付けを行い、関連付けを行ったデータに対して、対象情報から導き出される第２のデータ蓄積領域に反映する対象に対応する、反映条件が成立するか否かを確認し、条件が成立する場合に、対象情報から導き出される対象データを一時蓄積領域から抽出し、第２のデータ蓄積領域に反映する一連の処理を含むことにより達成される。
【００１７】
本発明では、分析アプリケーションから見て整合性が確保された状態のデータのみを参照可能とするために、複数の取り出し元データから反映先データへのデータの反映処理を一つの処理単位としてまとめたものを業務トランザクションと定義する。
【発明の効果】
【００１８】
本発明によれば、分析業務において複数の業務システムから収集した業務データを横断的に組み合わせて参照する場合でも、業務データ間の整合性が確保された、分析業務を実施するユーザにとって正しい情報が見ることができる。
【００１９】
また、既存の企業内情報システムにおいて、バッチ処理システムによって行なわれていた業務システムから分析システムへの業務データの反映を本発明に置き換えることで、リアルタイムなデータを含めた業務データを分析業務に利用することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本発明の第一の実施形態の全体構成を示す図である。
【図２】システム実行処理部の処理内容を示すフローチャートである。
【図３】更新情報蓄積処理部の処理内容を示すフローチャートである。
【図４】更新データのデータ構造の例を示した図である。
【図５】データ対応表の構成の例を示した図である。
【図６】更新情報蓄積処理部以降で扱う再構成された更新データのデータ構造の例を示した図である。
【図７】第一の実施形態における実行判定処理部の処理内容を示すフローチャートである。
【図８】第一の実施形態における整合性判定処理部の処理内容を示すフローチャートである。
【図９】整合性定義の構成の例を示した図である。
【図１０】更新反映処理部の処理内容を示すフローチャートである。
【図１１】整合性定義の設定方法を説明するための一時記憶領域内のデータ構造の例を示した図である。
【図１２】第一の実施形態における本発明の概略の処理内容を示す図である。
【図１３】本発明の第二の実施形態の全体構成を示す図である。
【図１４】最適整合性定義の構成および構成方法の例を示した図である。
【図１５】第二の実施形態における整合性定義最適化処理部の処理内容を示すフローチャートである。
【図１６】第二の実施形態における実行判定処理部の処理内容を示すフローチャートである。
【図１７】第二の実施形態における整合性判定処理部の処理内容を示すフローチャートである。
【図１８】従来の企業内情報システムの構成の例を示した図である。
【発明を実施するための形態】
【００２１】
以下、本発明の実施形態について図面を参照して詳細に説明する。
［第一の実施形態］
図１は、本発明の第一の実施形態の全体構成を示す図である。本実施形態の整合性確保システム（データ処理システム）は、分析サーバ１０１の中に構築される。分析サーバ１０１は、後記する各処理を実行するＣＰＵ（Central Processing Unit）１０４や、インターネットなどのネットワーク１００に接続されるネットワークインタフェース（ＮＩ：Network Interface）１０５、処理の結果を表示する出力装置１０６、キーボード、マウスなどの入力装置１０７、ＲＡＭ（Random Access Memory）などの主記憶装置１０８、ハードディスクドライブなどの２次記憶装置１０９（第２のデータ蓄積領域）とをバス１０３を介して接続した構成で実現される。また、ネットワーク１００を介して、業務サーバ２０２が複数接続されている。
【００２２】
分析サーバ１０１内の２次記憶装置１０９には、分析処理で扱うデータが分析テーブル１３０として格納されており、主記憶装置１０８には、分析アプリケーション１１０が格納される。分析アプリケーション１１０は、分析テーブル１３０を参照することで分析処理が可能となるプログラムである。
【００２３】
また、主記憶装置１０８には、業務サーバ２０２のデータ送信部２３４から、ネットワーク１００などを介して送信されてきた業務テーブル２３５の更新データを受信するデータ受信部１１１が格納される。データ受信部１１１は、システム実行処理部１１４により更新データを要求されるまで、受信した更新データを一時的に蓄積する。
【００２４】
本実施形態における整合性確保システム（データ処理システム）とは、分析サーバ１０１がデータ受信部１１１にて更新データを受信し、分析サーバ１０１で２次記憶装置１０９内の対象となる分析テーブル１３０にデータを反映する間に実装するシステムである。主記憶装置１０８には、システム設定処理部１１３、システム実行処理部１１４（図２参照）、分析アプリケーション１１０のプログラム、整合性定義１２４（図９参照）、データ対応表１２８（図５参照）、主記憶装置１０８に確保された一時記憶領域１２９から構成される。
【００２５】
以上の処理部、定義、表は２次記憶装置１０９や、ＵＳＢ（Universal Serial Bus）メモリといった外部記憶装置（本図未表記）などのコンピュータで読み書きできる記憶媒体に格納することもできる。また、一時記憶領域１２９は、２次記憶装置１０９や、ＵＳＢメモリといった外部記憶装置（本図未表記）などのコンピュータで読み書きできる記憶媒体上に確保してもよい。
【００２６】
システム設定処理部１１３は、データ構造設定処理部１１５および整合性定義設定処理部１１６で構成される。また、システム実行処理部１１４（図４参照）は、更新情報蓄積処理部１１７（図３参照）、実行判定処理部１１８（図７参照）、整合性判定処理部１１９（図８参照）および更新反映処理部１２０（図１０参照）で構成される。さらに、整合性定義１２４（定義情報）は、整合性条件１２５（反映条件）、整合性対象１２６（対象情報）およびグループキー１２７（グループ化情報）で構成された定義情報であり、図９を参照して説明する。
【００２７】
図９は、整合性定義の構成の例を示した図である。整合性定義１２４（定義情報）のうち整合性条件１２５（反映条件）とは、グループキー１２７で整合性を確保するとした一連のデータにおいて、データ間の整合性が確保される条件を示したものである。整合性条件の条件判定方式として、データの値によって条件判定を行なう場合と、データの有無によって条件判定を行なう場合と、データの集計値によって条件判定を行なう場合がある。具体的には、図９に示す例は、データの値によって条件判定を行なう場合であり、定義されている整合性条件１２５は、テーブル「ＴＡＢＬＥ１」のカラム「ＳＴＡＴＵＳ」が“ＣＯＭＰＬＥＴＥ”であるときを示す。なお、“ＣＯＭＰＬＥＴＥ”とは、対象とした製品・半製品のある工程あるいは全工程が完成したことを意味する。
【００２８】
整合性定義１２４のうち整合性対象１２６（対象情報）とは、整合性条件１２５が成立したときに、一時記憶領域１２９内に蓄積された更新データの中から分析サーバ１０１内の２次記憶領域内の分析テーブル１３０に反映される対象を、業務テーブル２３５のカラム名で表したものである。
【００２９】
整合性定義１２４のうちグループキー１２７（グループ化情報）とは、整合性を確保する必要のある、業務トランザクションのデータを結びつけるための情報で、結びつける複数のテーブルのカラムを設定する。ここに設定されたカラムの値が同一となるテーブルの行データが一つの業務トランザクションとなる。
【００３０】
例えば、図９に示すグループキー１２７は、テーブル「ＴＡＢＬＥ１」、テーブル「ＴＡＢＬＥ２」、テーブル「ＴＡＢＬＥ３」並びにテーブル「ＴＡＢＬＥ４」がひとつの業務トランザクションで使用するテーブルあり、それぞれのテーブルのＬＯＴＮＵＭというカラムの値で業務トランザクションが識別できることを示す。つまり、
ＴＡＢＬＥ１．ＬＯＴＮＵＭ
ＴＡＢＬＥ２．ＬＯＴＮＵＭ
ＴＡＢＬＥ３．ＬＯＴＮＵＭ
ＴＡＢＬＥ４．ＬＯＴＮＵＭ
が等しくなるそれぞれのテーブルの行データが整合性を確保する必要がある一つの業務トランザクションとなる。
【００３１】
業務サーバ２０２は、分析サーバ１０１と同様一般的なコンピュータを用いて実現されており、業務サーバ２０２内の２次記憶装置２３２（第１のデータ蓄積領域）には業務上入力されたデータが業務テーブル２３５として格納されており、主記憶装置２３１には、業務アプリケーション２３３と、業務テーブル２３５が更新されたときに更新データの送信処理を実行するデータ送信部２３４が格納される。
【００３２】
図２は、第一の実施形態におけるシステム実行処理部の処理内容を示すフローチャートの例である。システム実行処理部１１４による整合性確保システムの実行処理について図２を参照して説明する。
【００３３】
システム実行処理部１１４は、データ受信部１１１がデータを受信することによって起動される。本処理部は、まずステップＳ２００でデータ受信部１１１が受信したデータを取得し、取得したデータがトランザクション単位で纏められた更新データ群であった場合は、対象データを取得した上で、更新データの単位（図４参照）に分割する。取得・分割した全ての更新データはシステム実行処理部１１４で一時的に所持する。
【００３４】
次に、ステップＳ２０１で、システム実行処理部１１４が所持する、前記分割された更新データの数だけ以下のステップＳ１１７からステップＳ１１９を繰り返す。この繰り返し処理では、まず、ステップＳ１１７で更新情報蓄積処理部１１７を起動し、更新データ（図４参照）に含まれる情報を一時記憶領域１２９に反映する。更新情報蓄積処理部１１７の詳細については後記する（図３参照）。
【００３５】
次に、ステップＳ１１８で実行判定処理部１１８を起動し、処理対象の更新データを分析テーブル１３０に反映するにあたり、整合性判定処理部１１９において、整合性判定処理を行なう必要があるかどうかを確認する。実行判定処理部１１８の詳細については後記する（図７参照）。
【００３６】
次に、ステップＳ１１９で整合性判定処理部１１９を起動し、整合性判定処理を実施する。整合性判定処理部１１９では、実行判定処理部１１８において整合性判定処理を行なう必要があると判定されたときに限り整合性判定処理を実行する。整合性判定処理部１１９の詳細については後記する（図８参照）。
【００３７】
最後に、ステップＳ２０２で全ての更新データの処理を終了すると、ステップＳ１２０で更新反映処理部１２０を起動する。更新反映処理部１２０では、システム実行処理部１１４が一つ以上の反映データを所持していた場合に限り、分析テーブル１３０に対し反映データを反映する処理である。反映データおよび、更新反映処理部１２０の詳細については後記する（図１０参照）。
【００３８】
図３は、更新情報蓄積処理部の処理内容を示すフローチャートである。更新情報蓄積処理部１１７の処理内容について、図３のフローチャートおよび、図４、図５、図６を参照して説明する。
【００３９】
更新情報蓄積処理部１１７では、まずステップＳ３００で更新データの解析を実施する。更新データの解析とは、業務サーバ２０２から送信された更新データが、「追加」、「更新」、「削除」のデータの操作形式のいずれであるのかを判定することを指す。
【００４０】
図４は、更新データのデータ構造の例を示した図である。業務サーバ２０２から送信される更新データのデータ構造を図４により説明する。図４に示す更新データは、更新前のデータ４００と更新後のデータ４０１を行データの単位の組み合わせで表現され、業務サーバ２０２から送信されてくる。
【００４１】
図４に示す更新データは、更新前のデータ４００における全てのカラムの値が指定されていないことから、テーブル「ＴＡＢＬＥ１」（４０２）への「追加」を表した更新データである。また、更新後のデータ４０１における全てのカラムの値が指定されていない場合、更新データは対象テーブルへの「削除」を表した更新データを意味する。また、更新前のデータ４００と更新後のデータ４０１共に値が指定されている場合、更新データは対象テーブルへの「更新」を表した更新データを意味する。
【００４２】
図３に戻り、ステップＳ３０１において、図５に示すデータ対応表１２８に従って、更新データから必要なデータを抽出し、再構成した更新データの例を図６に示す。
【００４３】
図５は、データ対応表の構成の例を示した図である。データ対応表１２８について、図５を参照して説明する。データ対応表１２８は、反映元テーブル名５０１、反映元カラム名５０２、反映先テーブル名５０３、反映先カラム名５０４から構成される。
【００４４】
反映元テーブル名５０１は、業務テーブル２３５のテーブル名を表しており、反映元カラム名５０２は、前記業務テーブル２３５が持つカラムのカラム名を表す。また、反映先テーブル名５０３は、分析テーブル１３０のテーブル名を表しており、反映先カラム名５０４は、前記分析テーブルが持つカラムのカラム名を表す。つまり、データ対応表１２８の各行の行データは、カラム単位での業務テーブル２３５と分析テーブル１３０の対応関係を表現する。なお、データ対応表１２８は、業務テーブル２３５と分析テーブル１３０の間において対応関係のないカラムについては設定しなくてもよい。
【００４５】
図３に戻り、ステップ３０１を具体的に説明する。図４に示す更新データの中から、図５に示すデータ対応表１２８の反映元テーブル名５０１および反映元カラム名５０２で示された対象のみを抽出し、更新データの再構成を行なう。例えば、図５のデータ対応表１２８に従い、図４の更新データから抽出処理を実行すると、テーブル「ＴＡＢＬＥ１」（４０２）においては「製品名」（４０４）、「ＬＯＴＮＵＭ」（４０５）、「ＳＴＡＴＵＳ」（４０６）の更新データが抽出され、以降のシステム実行処理部１１４で扱われる更新データは図６となる。
【００４６】
図６は、更新情報蓄積処理部以降で扱う再構成された更新データのデータ構造の例を示した図である。図６に示す例は、カラム「製品名」（６０４）、カラム「ＬＯＴＮＵＭ」（６０５）、カラム「ＳＴＡＴＵＳ」（６０６）から構成されるテーブル「ＴＡＢＬＥ１」（６０２）の「追加」操作である。「削除」、「更新」に対しても同様の処理が適用される。
【００４７】
図３に戻り、最後に、ステップＳ３０２で再構成した更新データの操作形式に従い、一時記憶領域１２９に適宜蓄積されているデータ群に対し更新処理を行なう。
【００４８】
図４の例ではデータの操作形式が「追加」であることから、一時記憶領域１２９に新しく記憶領域を確保し、そこにステップＳ３０２で抽出した「製品名」、「ＬＯＴＮＵＭ」、「ＳＴＡＴＵＳ」の値をテーブル名「ＴＡＢＬＥ１」と共に格納する。
【００４９】
また、前記データの操作形式が「更新」である場合、図４に示すデータ構造をとる更新データにおける更新前のデータと一致する一時記憶領域１２９に既に存在するデータを、更新後のデータに置き換える。
【００５０】
また、前記データの操作形式が「削除」である場合、図４に示すデータ構造をとる更新データにおける更新前のデータと一致する一時記憶領域１２９に既に存在するデータを削除する。
【００５１】
本実施形態では、一時記憶領域１２９のデータ構造は、テーブル構造を想定しているが、ＳＱＬのリストで管理するなど、テーブル構造以外のデータ構造であってもよい。また、更新データが図４のようなデータ構造をとっているが、更新データはＳＱＬやＣＳＶ（Comma-Separated Values）などのデータ構造をとってもよい。なお、ＳＱＬは、リレーショナルデータベース管理システムにおいて、データの操作や定義を行なうためのデータベース言語である。以上、本実施形態における更新情報蓄積処理部１１７における一時記憶領域への更新データ反映処理の内容である。
【００５２】
図７は、第一の実施形態における実行判定処理部の処理内容を示すフローチャートである。実行判定処理部１１８の処理内容について図７を参照して説明する。実行判定処理部１１８では、まずステップＳ７００で処理対象の更新データ（図６参照）を分析テーブル１３０に反映するにあたって、整合性判定処理を行なう必要があるか否かを、整合性定義１２４の整合性対象１２６から判断し、ステップＳ７０１で整合性判定処理が必要であるか否かを判定する。
【００５３】
具体的には、ステップＳ７００で一時記憶領域１２９の更新データ（図６参照）の中からテーブル名、並びに全てのカラム名を取り出し、取り出したテーブル名と、カラム名の組み合わせをカラム名の数だけ生成する。前記組み合わせと、整合性定義１２４（図９参照）で定義されている整合性対象１２６に示されたテーブル名およびカラム名において、ひとつでも一致するものがあるか否かを、全ての前記組み合わせに対し確認する。
【００５４】
ステップＳ７０１で整合性判定処理の必要性判定で、一つ以上の組み合わせにおいて一致が確認された場合（ステップＳ７０１，Ｙｅｓ）、ステップＳ７０２で整合性判定処理を行なう必要があることを、システム実行処理部１１４に通知し、実行判定処理部（１１８）での整合性判定処理の必要性判定処理を終了する。また、前記整合性判定処理の必要性判定によって、すべての組み合わせにおいて一致が確認されなかった場合は（ステップＳ７０１，Ｎｏ）、ステップＳ７０４で、更新データと整合性条件１２５から整合性判定の実行が必要か否かを判断する。
【００５５】
ステップＳ７００では、整合性対象１２６で定義されているテーブル名およびカラム名を対象に確認処理を行なったのに対し、ステップＳ７０４では、整合性条件１２５で定義されているテーブル名およびカラム名を対象に整合性判定処理の必要性判定処理を行なう。ステップＳ７００で生成されたテーブル名とカラム名の組み合わせと、整合性定義１２４において整合性条件１２６で定義されているテーブル名およびカラム名において、一致するか否かを、全ての前記組み合わせに対し確認する。
【００５６】
ステップＳ７０５において、整合性判定処理が必要な場合（一致が確認された場合）（ステップＳ７０５，Ｙｅｓ）に、ステップＳ７０６で整合性判定処理を行なう必要があることを、システム実行処理部（１１４）に通知する。整合性判定処理が必要でない場合（ステップＳ７０５，Ｎｏ）、処理を終了する。以上が実行判定処理部１１８の処理内容である。
【００５７】
図８は、第一の実施形態における整合性判定処理部の処理内容を示すフローチャートである。整合性判定処理部１１９の処理内容について図８および図９を参照して説明する。
【００５８】
整合性判定処理部１１９では、まずステップＳ８００で以下の処理ステップを行なうか否かを判定する。前記判定は、実行判定処理部１１８における、整合性判定を行なう必要があるか否かの判定を指しており、システム実行処理部１１４が整合性判定を行なう必要があることを通知されていた場合は（ステップＳ８００，Ｙｅｓ），以下のステップを実行する。通知されていない場合（ステップＳ８００，Ｎｏ）、処理を終了する。
【００５９】
整合性判定処理部１１９は、まず、ステップＳ８０１で更新データから、整合性定義１２４で定義されているグループキー１２７を取得する。取得されたグループキーについては、本処理を実行している間、整合性判定処理部１１９の中に一時的に格納する。
【００６０】
次に、整合性判定処理部１１９は、ステップＳ１２１で条件判定処理部１２１を起動し、整合性定義１２４で定義されている整合性条件１２５が成立するか否かを判定する。本条件判定処理は、整合性判定処理部１１９に格納されているグループキーで関連付けられた業務トランザクションに対して行われる。
【００６１】
具体的には、整合性判定処理部１１９は、整合性定義１２４が図９の場合、テーブル「ＴＡＢＬＥ１」のカラム「ＬＯＴＮＵＭ」、「ＴＡＢＬＥ２」のカラム「ＬＯＴＮＵＭ」、「ＴＡＢＬＥ３」のカラム「ＬＯＴＮＵＭ」および、「ＴＡＢＬＥ４」のカラム「ＬＯＴＮＵＭ」の値を等しくする更新データを対象に、図９の整合性定義１２４で定義されている整合性条件１２５が成立するかどうかの判定を実施する。
【００６２】
ステップＳ８０２でステップＳ１２１の条件判定処理において、整合性条件の成立が確認された場合には（ステップＳ８０２，Ｙｅｓ）、対象データ抽出処理部１２２を起動し、整合性判定処理部１１９に格納されているグループキー１２７の値と整合性定義１２４で定義されている整合性対象１２６に基づき、テーブル単位で一時記憶領域１２９から値を抽出する（ステップＳ１２２）。
【００６３】
抽出された値は、抽出元のテーブル名とカラム名と結びつけられ、反映対象への追加データとして、整合性判定処理が終了するまで、整合性判定処理部１１９において一時的に所持する。前記追加データは、整合性対象１２６で定義されているテーブルの数だけ作成されていることから、一つ以上存在する。ステップＳ８０３では、整合性判定処理部（１１９）が保持する追加データの数だけ以下のステップを繰り返す。
【００６４】
この繰り返し処理では、まず、反映目標対応処理部１２３を起動する。反映目標対応処理部１２３では、処理中の追加データと、データ対応表１２８から、反映データを構築する。反映データは、処理中の追加データと、追加データの反映対象となるテーブル名と、カラム名から構成されており、分析テーブル１３０への更新操作を実施するためのデータである。
【００６５】
例えば、分析テーブル１３０がＲＤＢＭＳ（Relational Database Management System）で管理されていた場合、追加データとデータ対応表１２８から分析テーブル１３０への行の追加命令であるＳＱＬ文が作成される。
【００６６】
本処理部では、処理中の追加データのテーブル名およびカラム名と、データ対応表１２８の反映元テーブル名５０１と反映元カラム名５０２の値を比較することで、追加データの値を反映する、分析テーブル１３０のテーブル名とカラム名を判定する。
【００６７】
次にステップＳ８０４では、反映目標対応処理部１２３において構築した反映データをシステム実行処理部１１４に格納する。そして、ステップＳ８０５において抽出したデータ全てを処理した際に一連の処理を終了する。なお、ステップＳ８０２において、整合性条件をみたさない場合（ステップＳ８０２，Ｎｏ）、処理を終了する。以上、整合性判定処理部１１９の処理内容である。
【００６８】
図１０は、更新反映処理部の処理内容を示すフローチャートである。更新反映処理部１２０の処理内容について図１０を参照して説明する。更新反映処理部１２０では、まずステップＳ１０００でシステム実行処理部１１４が反映データを一つ以上保持しているかどうかを確認する。
【００６９】
反映データを一つ以上保持していた場合（ステップＳ１０００，Ｙｅｓ）、ステップ１００１に進む。ステップＳ１００１では、システム実行処理部１１４が保持していた全ての反映データを分析テーブル１３０に反映するまで、以下のステップを繰り返す。
【００７０】
まず、ステップＳ１００２で、システム実行処理部１１４が保持している反映データの中からひとつを取得する。次に、ステップＳ１００３で、取得した反映データを分析テーブル１３０に対し反映する。反映処理の終了した反映データをシステム実行処理部１１４から取り除く。この反映処理は、反映対象となる分析テーブル１３０がテーブル構造であることから、反映データで示されている対象となるテーブル並びにカラムに対して、反映データに示されている値を格納することによって完了する。ステップＳ１００４において、全ての反映データを反映した際に一連の処理を終了する。なお、ステップＳ１０００において、反映データを保持していない場合（ステップＳ１０００，Ｎｏ）、処理を終了する。以上、更新反映処理部１２０の処理内容である。
【００７１】
また、更新反映処理部１２０の処理が終了することで、システム実行処理部１１４の処理も終了する。システム実行処理部１１４の処理が終了した場合、システム実行処理部１１４が一時的に保持していた情報は全て破棄する。
【００７２】
次に、システム実行処理部１１４で利用される整合性定義１２４とデータ対応表１２８の設定処理を実装するシステム設定処理部１１３について説明する。
【００７３】
システム設定処理部１１３は、整合性確保システムの管理者による入力装置１０７からの指示を受け起動するものであり、整合性確保システムおよび分析アプリケーションが正常に動作する上で必要とするデータの設定処理が実行される。
【００７４】
システム設定処理部１１３では、データ構造設定処理部１１５において、データ対応表１２８の設定処理が行なわれる。また、整合性定義設定処理部１１６において、整合性定義（１２４）の設定処理が行なわれる。以下、処理内容について説明する。
【００７５】
データ構造設定処理部１１５は、まず、データ対応表１２８の設定要求があるかどうかを調べる。ここで、データ対応表１２８の設定要求があった場合には、業務テーブル２３５と分析テーブル１３０のテーブル、および各テーブルのカラムの対応関係をデータ対応表１２８に設定し、データ構造設定処理部１１５におけるデータ対応表の設定処理を終了する。
【００７６】
整合性定義設定処理部１１６は、まず、整合性定義１２４の設定要求があるかどうかを調べる。ここで、整合性定義１２４の設定要求があった場合には、グループキー１２７を設定する。次に、整合性条件１２５を設定する。最後に、整合性対象１２６を設定し、整合性定義設定処理部１１６における整合性定義の設定処理を終了する。
【００７７】
図１１は、整合性定義の設定方法を説明するための一時記憶領域内のデータ構造の例を示した図である。システム設定処理部１１３が設定する整合性定義１２４の設定方法を、図１１および図９を参照して説明する。具体的に説明すると、図９に示す例では、グループキー１２７により複数のテーブルがＬＯＴＮＵＭ（ロットナンバー）で関係付けられている。
【００７８】
図１１（ａ）はＬＯＴＮＵＭ（ロットナンバー）毎の製品の状態を示す情報であるＴＡＢＬＥ１（１１０１）を示し、図１１（ｂ）はＬＯＴＮＵＭ毎の材料投入量を示す情報であるＴＡＢＬＥ２（１１０２）を示し、図１１（ｃ）はＬＯＴＮＵＭ毎の製造量を示す情報であるＴＡＢＬＥ３（１１０３）を示し、図１１（ｄ）はＬＯＴＮＵＭ毎の不良量を示す情報であるＴＡＢＬＥ４（１１０４）を示している。
【００７９】
例えば、図１１においてグループキー１２７のＬＯＴＮＵＭが“０００１”であるとき、ＴＡＢＬＥ１（１１０１）のＬＯＴＮＵＭ＝“０００１”の行データ１１１４とＴＡＢＬＥ２（１１０２）のＬＯＴＮＵＭ＝“０００１”の行データ１１１５と、ＴＡＢＬＥ３（１１０３）のＬＯＴＮＵＭ＝“０００１”の行データ１１１６と、ＴＡＢＬＥ４（１１０４）のＬＯＴＮＵＭ＝“０００１”の行データ１１１７が、整合性を確保する必要がある同一の業務トランザクションの更新データであることを意味する。
【００８０】
このとき、図１１に示す例では、各テーブルは、図９に示すグループキー１２７によって関係づけられ、ＬＯＴＮＵＭ＝“０００１”で結びつけられた業務トランザクション（１１１４、１１１５、１１１６、１１１７）とＬＯＴＮＵＭ＝“０００２”で結びつけられた業務トランザクション（１１１８、１１１９、１１２０、１１２１）が整合性条件１２５を満たしており、一方、ＬＯＴＮＵＭ＝“０００３”で結びつけられた業務トランザクション（１１２２、１１２３、１１２４、１１２５）とＬＯＴＮＵＭ＝“０００４”で結びつけられた業務トランザクション（１１２６、１１２７、１１２８、１１２９）は整合性条件１２５を満たしていないと判定される。なぜなら、ＬＯＴＮＵＭ＝“０００３”およびＬＯＴＮＵＭ＝“０００４”の場合、ＴＡＢＬＥ１．ＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”ではないからである。
【００８１】
次に、図１１を参照して、データの有無によって条件判定を行なう場合について説明する。図１１において整合性条件１２５を、ＴＡＢＬＥ１（１１０１）のカラム「製品名」（１１０５）とカラム「ＳＴＡＴＵＳ」（１１０７）、ＴＡＢＬＥ２（１１０２）のカラム「材料投入量」（１１０９）、並びにＴＡＢＬＥ３（１１０３）のカラム「製造量」（１１１１）とＴＡＢＬＥ４（１１０４）のカラム「不良」（１１１３）にデータが存在するとき、と設定する。
【００８２】
この場合の整合性条件１２５は、
ＴＡＢＬＥ１．製品名！＝ＮＵＬＬ  ＡＮＤ  
ＴＡＢＬＥ１．ＳＴＡＴＵＳ  ！＝ＮＵＬＬ  ＡＮＤ  
ＴＡＢＬＥ２．材料投入量  ！＝ＮＵＬＬ  ＡＮＤ  
ＴＡＢＬＥ３．製造量  ！＝ＮＵＬＬ  ＡＮＤ  
ＴＡＢＬＥ４．不良  ！＝ＮＵＬＬ                    ・・・  条件（１）
と表される。なお、「！＝ＮＵＬＬ」はＮＵＬＬ（何のデータも含まれない状態、あるいは長さ０の空文字列）でないことを意味する。
【００８３】
このとき、図１１の例ではグループキー１２７よって関係づけられたＬＯＴＮＵＭ＝“０００１”で結びつけられた業務トランザクション（１１１４、１１１５、１１１６、１１１７）、ＬＯＴＮＵＭ＝“０００２”で結びつけられた業務トランザクション（１１１８、１１１９、１１２０、１１２１）、ＬＯＴＮＵＭ＝“０００３”で結びつけられた業務トランザクション（１１２２、１１２３、１１２４、１１２５）は整合性条件［条件（１）］を満たしており、ＬＯＴＮＵＭ＝“０００４”で結びつけられた業務トランザクション（１１２６、１１２７、１１２８、１１２９）は整合性条件［条件（１）］を満たしていないと判定される。
【００８４】
最後に、データの計算値によって条件判定を行なう場合について説明する。図１１においてデータの整合性条件１２５を、ＴＡＢＬＥ３（１１０３）のカラム「製造量」（１１１１）とＴＡＢＬＥ４（１１０４）のカラム「不良」（不良量）（１１１３）の和が、ＴＡＢＬＥ２（１１０２）のカラム「材料投入量」（１１０９）以上であるとき、と設定する。
【００８５】
この場合の整合性条件は、
ＴＡＢＬＥ３．製造量＋ＴＡＢＬＥ４．不良＝＞ＴＡＢＬＥ２．材料投入量
・・・  条件（２）
と表される。なお、「＝＞」は、≧（大なりまたは等しい）を意味する。
【００８６】
このとき、図１１の例ではグループキー１２７よって関係づけられたＬＯＴＮＵＭ＝“０００１”で結びつけられた業務トランザクション（１１１４、１１１５、１１１６、１１１７）とＬＯＴＮＵＭ＝“０００２”で結びつけられた業務トランザクション（１１１８、１１１９、１１２０、１１２１）が整合性条件［条件（２）］を満たしており、ＬＯＴＮＵＭ＝“０００３”で結びつけられた業務トランザクション（１１２２、１１２３、１１２４、１１２５）が整合性条件［条件（２）］を満たしていないと判定される。また、ＬＯＴＮＵＭ＝“０００４”で結びつけられた業務トランザクション（１１２６、１１２７、１１２８、１１２９）についてもカラム「製造量」（１１１１）とカラム「不良」（１１１３）の値が入力されていないことから、整合性条件［条件（２）］を満たしていないと判定される。なお、整合性条件１２５には、特定の時刻や一定の時間周期などの時間を設定する方式を用いてもよい。この場合、現在の時刻が条件として設定した時刻と一致したときに条件が成立したと判定される。
【００８７】
図９を参照すると、図１１において、業務システム側から分析システム側に反映される反映対象は、テーブル「ＴＡＢＬＥ２」（１１０２）のカラム「ＬＯＴＮＵＭ」（１１０８）とカラム「材料投入量」（１１０９）、テーブル「ＴＡＢＬＥ３」（１１０３）のカラム「ＬＯＴＮＵＭ」（１１１０）とカラム「製造量」（１１１１）およびテーブル「ＴＡＢＬＥ４」（１１０４）のカラム「ＬＯＴＮＵＭ」（１１１２）とカラム「不良」（１１１３）、と設定されている。
【００８８】
この場合、図１１の例において、ＬＯＴＮＵＭ＝“０００１”で結びつけられた業務トランザクション（１１１４、１１１５、１１１６、１１１７）の整合性条件が成立したとき、分析テーブル（１３０）に反映される対象データは、テーブル「ＴＡＢＬＥ２」（１１０２）では、カラム「ＬＯＴＮＵＭ」（１１０８）の値である“０００１”とカラム「材料投入量」（１１０９）の値５０、同様に、テーブル「ＴＡＢＬＥ３」（１１０３）では、カラム「ＬＯＴＮＵＭ」（１１１０）の値である“０００１”とカラム「製造量」（１１１１）の値４０、テーブル「ＴＡＢＬＥ４」（１１０４）では、カラム「ＬＯＴＮＵＭ」（１１１２）の値である“０００１”とカラム「不良」（１１１３）の値１０である。
【００８９】
図１２は、本発明の概略の処理内容を示す図である。以下、本実施形態における整合性確保システムを用いたデータ処理ついて、図１２を参照して具体的に説明する。以下の説明で使用されるデータ対応表は図５のデータ対応表１２８、整合性定義は図９の整合性定義１２４が設定されているものとして説明する。
【００９０】
また、本例で扱う更新データのデータ構造は、更新前の行データと更新後の行データの組み合わせで表現された、図４のような構造をする。また、以下の説明における一時記憶領域内のデータ構造は、図１１に示すようなテーブル構造をとる。
【００９１】
まず、業務テーブルにおいて、整合性対象で定義されていないデータが更新された時のデータ処理の流れについて具体的に説明する。本データ処理では、１０：００の時点で、業務サーバ１（２０２ａ）において、ＴＡＢＬＥ１（業務テーブル１）（１２０１）に対する行の追加操作が実行される。ＴＡＢＬＥ１（１２０１）はＲＤＢＭＳで管理されており、１０：００の時点で「ＩＮＳＥＲＴ」という文字列から始まる下記のＳＱＬが発行されＴＡＢＬＥ１（１２０１）に対する行データの追加が実行される。
【００９２】
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ１  製品名  ＬＯＴＮＵＭ  ＳＴＡＴＵＳ  ＴＩＭＥ  ＶＡＬＵＥＳ（“製品ＡＸ”，“０００２”，“ＳＴＡＲＴ”，“１０：００”）
【００９３】
次に、業務サーバ１（２０２ａ）では、「ＴＡＢＬＥ１に、製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＳＴＡＲＴ”、ＴＩＭＥが“１０：００”の行を追加する」ことを表す更新データ（１２０９ａ）が作成される。
【００９４】
作成された更新データ１２０９ａは、データ送信部２３４ａ（２３４）から送信され、ネットワーク１００を介して、分析サーバ１０１のデータ受信部１１１で受信される。受信した更新データ１２０９ａは、データ受信部１１１に蓄積される。
【００９５】
次に、整合性確保システム１２００（データ処理システム）においてデータ処理を開始する。なお、本具体例を説明するにあたり、あらかじめ、システム設定処理部１１３において、前記のとおりデータ対応表１２８ならびに整合性定義１２４が設定されているものとする。整合性確保システム１２００では、まずシステム実行処理部１１４が起動され、システム実行処理部１１４はデータ受信部１１１が蓄積する更新データ１２０９ａを取得する。
【００９６】
次に、システム実行処理部１１４は、更新情報蓄積処理部１１７を起動する。更新情報蓄積処理部１１７では、データ対応表１２８に従い、更新データ１２０９ａの再構成を実施する。再構成前の更新データ１２０９ａはカラム「製品名」カラム「ＬＯＴＮＵＭ」カラム「ＳＴＡＴＵＳ」カラム「ＴＩＭＥ」から構成される。
【００９７】
本再構成処理では、データ対応表１２８に従い、更新データ１２０９ａからカラム「製品名」、カラム「ＬＯＴＮＵＭ」、カラム「ＳＴＡＴＵＳ」の要素のみを取り出し、「ＴＡＢＬＥ１に、製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＳＴＡＲＴ”の行データを追加する」ことを表す図６の再構成更新データ１２１０ａを作成する。この時、システム実行処理部が持つ更新データ１２０９ａは破棄される。また、更新情報蓄積処理部１１７は、再構成更新データ１２１０ａの操作形式を判定し、一時記憶領域（１２９）への再構成更新データ（１２１０ａ）の反映処理を実施する。
【００９８】
更新情報蓄積処理部１１７は、再構成更新データ１２１０ａにより、一時記憶領域１２９内のテーブル「ＴＡＢＬＥ１」に「製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＳＴＡＲＴ”」といった行を追加する。
【００９９】
次に、実行判定処理部１１８において、再構成更新データ１２１０ａを分析テーブルに反映するにあたり、整合性判定処理部１１９で整合性判定処理を行なう必要があるかどうかを確認する。
【０１００】
まず、再構成更新データ１２１０ａを構成するカラムと整合性定義１２４の整合性対象１２６を比較する。再構成更新データ１２１０ａはテーブル「ＴＡＢＬＥ１」へ「追加」操作を行なったものであり、再構成更新データ１２１０ａを構成するカラムは「製品名」「ＬＯＴＮＵＭ」「ＳＴＡＴＵＳ」である。
【０１０１】
一方、整合性対象１２６に定義されているテーブル名に「ＴＡＢＬＥ１」は存在しない。これにより、整合性対象１２６と再構成更新データ１２１０ａの間に一致が確認されず、本比較処理では、整合性判定処理が必要であるとは判断されない。次に、再構成更新データ１２１０ａを構成するカラムと整合性定義１２４の整合性条件１２５を比較する。
【０１０２】
図９に示す整合性条件１２５は、条件判定の対象として、テーブル「ＴＡＢＬＥ１」のカラム「ＳＴＡＴＵＳ」が設定されている。これにより、整合性条件１２５と再構成更新データ１２１０ａの間に一致が確認され、本比較処理において、整合性判定処理が必要であると判定される。この結果、実行判定処理部１１８は、システム実行処理部１１４に対し整合性判定処理を行なう必要があることを通知する。以上、実行判定処理部１１８の処理を終了する。
【０１０３】
次に、整合性判定処理部１１９において、整合性判定処理を実行する。実行判定処理部１１８において、整合性判定処理を行なう必要があることをシステム実行処理部１１４に通知していることから、整合性判定処理部１１９は以降の整合性判定処理を実行する。
【０１０４】
まず、図９に示す整合性定義１２４に基づき、再構成更新データ１２１０ａからグループキーを取り出す。整合性定義１２４のグループキー１２７において「ＴＡＢＬＥ１」のグループキーは「ＬＯＴＮＵＭ」の値であることが示されている。これにより、再構成更新データ１２１０ａから「ＬＯＴＮＵＭ」の値（例えば、“０００２”）が抽出され、整合性判定処理終了時まで整合性判定処理部１１９がこのグループキーを所持する。
【０１０５】
次に、整合性判定処理部１１９は、一時記憶領域１２９においてグループキー“０００２”で関連付けられた業務トランザクションが整合性条件を満たすか否かを確認する。図９の整合性条件１２５には、「ＴＡＢＬＥ１のＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”である時」と定義されている。この時点で、一時記憶領域１２９内のテーブル「ＴＡＢＬＥ１」における「ＬＯＴＮＵＭ」が“０００２”の行データのカラム「ＳＴＡＴＵＳ」の値は“ＳＴＡＲＴ”であるため、整合性条件を満たさない。この結果、整合性判定処理部（１１９）は以降の処理は行なわず、処理を終了する。
【０１０６】
次に、更新反映処理部１２０において、システム実行処理部１１４が持つ反映データの分析テーブルへの反映処理を実行する。しかし、この時点においてシステム実行処理部１１４が持つ反映データは存在しない。これにより、更新反映処理部１２０は以下の処理を実行せず、その処理を終える。最後に、システム実行処理部１１４が一時的に保持する再構成更新データ１２１０ａおよび反映データ１２１１を全て破棄し、システム実行処理部１１４の処理が終了する。以上が、本データ処理の実行例である。
【０１０７】
次に、分析テーブルで、整合性対象で定義されているデータが更新されるが、整合性条件不成立時のデータ処理の流れについて具体的に説明する。本データ処理は、前記整合性対象で定義されていないデータが更新された時のデータ処理（以下、前記データ処理）の後に行なわれるものであり、一時記憶領域１２９に蓄積されているデータ、およびＴＡＢＬＥ１（業務テーブル１）（１２０１）からＴＡＢＬＥ４（業務テーブル４）（１２０４）、分析テーブル１（１２０５）から分析テーブル４（１２０８）は前記データ処理が終了したときの状態を継続する。
【０１０８】
本データ処理では、１０：０２の時点で、ＴＡＢＬＥ２（業務サーバ２）（２０２ｂ）において、ＴＡＢＬＥ２（１２０２）に対する行の追加操作が実行される。ＴＡＢＬＥ２（１２０２）はＲＤＢＭＳで管理されており、１０：０２の時点で「ＩＮＳＥＲＴ」という文字列から始まる下記のＳＱＬが発行されＴＡＢＬＥ２に対する行データの追加が実行される。
【０１０９】
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ２  ＬＯＴＮＵＭ  材料投入量  ＶＡＬＵＥＳ（“０００２”，“５０”）
【０１１０】
次に、業務サーバ２（２０２ｂ）では、「ＴＡＢＬＥ２に、ＬＯＴＮＵＭが“０００２”、材料投入量が５０の行を追加する」ことを表す更新データ（１２０９ｂ）が作成される。
【０１１１】
作成された更新データ（１２０９ｂ）は、前記データ処理時と同様の処理を経てシステム実行処理部１１４により取得される。システム実行処理部１１４は、更新情報蓄積処理部１１７を起動し、データ対応表１２８に従い、更新データ１２０９ｂの再構成を実施する。再構成前の更新データ１２０９ｂは「ＬＯＴＮＵＭ」「材料投入量」といったカラムから構成される。
【０１１２】
本再構成処理では、データ対応表１２８に従い、再構成前の更新データ１２０９ｂからカラム「ＬＯＴＮＵＭ」、カラム「材料投入量」が取り出され、「ＴＡＢＬＥ２に、ＬＯＴＮＵＭが“０００２”、材料投入量が５０の行データを追加する」ことを表す再構成更新データ１２１０ｂを作成する。この時、システム実行処理部１１４が持つ更新データ１２０９ｂは破棄される。また、更新情報蓄積処理部１１７は、再構成更新データ１２１０ｂの操作形式を判定し、一時記憶領域１２９への再構成更新データ１２１０ｂの反映処理を実施する。
【０１１３】
更新情報蓄積処理部１１７は、再構成更新データ１２１０ｂにより、一時記憶領域１２９内のテーブル「ＴＡＢＬＥ２」に「ＬＯＴＮＵＭが“０００２”、材料投入量が５０」といった行を追加する。
【０１１４】
次に、実行判定処理部１１８において、整合性判定処理が必要かどうかを確認する。再構成更新データ１２１０ｂを構成するカラムと整合性定義１２４の整合性対象１２６を比較する。再構成更新データ１２１０ｂは、テーブル「ＴＡＢＬＥ２」へ「追加」操作を行なったものであり、再構成更新データ１２１０ｂを構成するカラムは「ＬＯＴＮＵＭ」「材料投入量」である。
【０１１５】
一方、整合性対象１２６においてテーブル「ＴＡＢＬＥ２」のカラム「ＬＯＴＮＵＭ」が定義されていることから、整合性対象１２６と再構成更新データ１２１０ｂの間に一致が確認され、本比較処理では、整合性判定処理が必要であると判定される。この結果、実行判定処理部１１８は、システム実行処理部１１４に対し、整合性判定処理を行なう必要があることを通知する。本データ処理では、以上で実行判定処理部１１８の処理を終了する。
【０１１６】
次に、整合性判定処理部１１９において、整合性判定処理を実行する。実行判定処理部１１８において、整合性判定処理を行なう必要があることをシステム実行処理部１１４に通知していることから、整合性判定処理部１１９は以降の整合性判定処理を実行する。
【０１１７】
まず、図９に示す整合性定義１２４に基づき、再構成更新データ１２１０ｂからグループキーを取り出す。整合性定義１２４のグループキー１２７において「ＴＡＢＬＥ２」のグループキーは「ＬＯＴＮＵＭ」の値であることが示されている。これにより、再構成更新データ１２１０ｂから「ＬＯＴＮＵＭ」の値“０００２”が抽出され、整合性判定処理終了時まで整合性判定処理部１１９がこのグループキーを所持する。
【０１１８】
次に、整合性判定処理部１１９は、一時記憶領域１２９においてグループキー１２７のＬＯＴＮＵＭ“０００２”で関連付けられた業務トランザクションが整合性条件を満たすか否かを確認する。図９の整合性条件１２５は、「ＴＡＢＬＥ１のＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”である時」と定義されている。この時点で、一時記憶領域１２９内のテーブル「ＴＡＢＬＥ１」における「ＬＯＴＮＵＭ」が“０００２”の行データのカラム「ＳＴＡＴＵＳ」は“ＳＴＡＲＴ”であるため、整合性条件を満たさない。この結果、整合性判定処理部は以降の処理は行なわず、処理を終了する。
【０１１９】
次に、更新反映処理部１２０において、システム実行処理部１１４が持つ反映データの分析テーブルへの反映処理を実行する。この時点においてシステム実行処理部１１４が持つ反映データは存在しない。これにより、更新反映処理部１２０は以下の処理を実行せず、その処理を終える。最後に、システム実行処理部１１４が一時的に保持する再構成更新データ（１２１０ｂ）を破棄し、システム実行処理部１１４の処理が終了する。以上が本データ処理におけるデータ処理の実行例である。
【０１２０】
次に、１０：０５の時点で、ＴＡＢＬＥ３（業務サーバ３）（２０２ｃ）において、ＴＡＢＬＥ３（１２０３）に対する行の追加操作が実行される。ＴＡＢＬＥ３（１２０３）はＲＤＢＭＳで管理されており、１０：０５の時点で「ＩＮＳＥＲＴ」という文字列から始まる下記のＳＱＬが発行されＴＡＢＬＥ３（１２０３）に対する行データの追加が実行される。
【０１２１】
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ３  ＬＯＴＮＵＭ  製造量  ＶＡＬＵＥＳ（“０００２”，“４０”）
【０１２２】
次に、業務サーバ３（２０２ｃ）において更新データが作成され、分析サーバ１０１において前記更新データに対するデータ処理が実行される。処理の流れについては前記整合性条件不成立時のデータ処理の流れと同様であるため省略する。
【０１２３】
同様に、１０：０６の時点で、業務サーバ３（２０２ｃ）において、ＴＡＢＬＥ４（業務テーブル４）（１２０４）に対する行の追加操作が実行される。ＴＡＢＬＥ４（１２０４）はＲＤＢＭＳで管理されており、１０：０６の時点で「ＩＮＳＥＲＴ」という文字列から始まる下記のＳＱＬが発行されＴＡＢＬＥ４（１２０４）に対する行データの追加が実行される。
【０１２４】
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ４  ＬＯＴＮＵＭ  不良  ＶＡＬＵＥＳ（“０００２”，“１０”）
【０１２５】
次に、業務サーバ３（２０２ｃ）において更新データが作成され、分析サーバ１０１において前記更新データに対するデータ処理が実行される。処理の流れについては前記整合性条件不成立時のデータ処理の流れと同様であるため省略する。最後に、分析テーブルで、データが更新されることで、整合性条件が成立する時のデータ処理の流れについて具体的に説明する。
【０１２６】
本データ処理では、１０：０７の時点で、業務サーバ１（２０２ａ）において、「ＵＰＤＡＴＥ」という文字列から始まる下記のＳＱＬが発行されＴＡＢＬＥ１（１２０１）に対する行の更新操作が実行される。
【０１２７】
ＵＰＤＡＴＥ  ＴＡＢＬＥ１  ＳＥＴ  ＳＴＡＴＵＳ＝“ＣＯＭＰＬＥＴＥ”，ＴＩＭＥ＝“１０：０７”  ＷＨＥＲＥ  ＬＯＴＵＮＵＭ＝“０００２”
【０１２８】
次に、業務サーバ１（２０２ａ）では、「ＴＡＢＬＥ１で、製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＳＴＡＲＴ”、ＴＩＭＥが“１０：００”の行を、製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”、ＴＩＭＥが“１０：０７”の行に変更する」ことを表す更新データ（１２０９ｃ）が作成される。
【０１２９】
作成された更新データ（１２０９ｃ）は前記データ処理時と同様にシステム実行処理部（１１４）により取得される。システム実行処理部１１４は、更新情報蓄積処理部１１７を起動し、データ対応表１２８に従い、更新データ１２０９ｃの再構成を実施する。再構成前の更新データ１２０９ｃは、カラム「製品名」、カラム「ＬＯＴＮＵＭ」、カラム「ＳＴＡＴＵＳ」、カラム「ＴＩＭＥ」から構成される。
【０１３０】
本再構成処理では、データ対応表１２８に従い、更新データ１２０９ｃから「製品名」「ＬＯＴＮＵＭ」「ＳＴＡＴＵＳ」の要素のみを取り出し、「ＴＡＢＬＥ１で、製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＳＴＡＲＴ”の行を、製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”の行に変更する」ことを表す再構成更新データ１２１０ｃを作成する。また、更新情報蓄積処理部１１７は、再構成更新データ１２１０ｃの操作形式を判定し、一時記憶領域１２９への再構成更新データ１２１０ｃの反映処理を実施する。
【０１３１】
更新情報蓄積処理部１１７は、再構成更新データ１２１０ｃの操作形式を判定し、一時記憶領域１２９内のテーブル「ＴＡＢＬＥ１」の「製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＳＴＡＲＴ”」の行を「製品名が“製品ＡＸ”、ＬＯＴＮＵＭが“０００２”、ＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”」に更新する。
【０１３２】
次に、実行判定処理部１１８において、整合性判定処理が必要かどうかを確認する。再構成更新データ１２１０ｃを構成するカラムと整合性定義１２４の整合性対象１２６を比較する。このとき再構成更新データ１２１０ｃは、前記データ処理時と同様に整合性判定処理が必要であるとは判断されない。
【０１３３】
実行判定処理部１１８は、前記比較の結果を受け、再構成更新データ１２１０ｃを構成するカラムと整合性定義１２４の整合性条件１２５を比較し、前記データ処理時と同様に、整合性判定処理が必要であると判定される。この結果、実行判定処理部１１８は、システム実行処理部１１４に対し、整合性判定処理を行なう必要があることを通知する。以上で実行判定処理部１１８の処理を終了する。
【０１３４】
次に、整合性判定処理部１１９において、整合性判定処理を実行する。実行判定処理部１１８において、整合性判定処理を行なう必要があることをシステム実行処理部１１４に通知していることから以降の整合性判定処理を実行する。
【０１３５】
まず、図９に示す整合性定義１２４を参照して、再構成更新データ１２１０ｃからグループキー“０００２”が抽出され、整合性判定処理終了時まで整合性判定処理部１１９がこのグループキーを所持する。
【０１３６】
次に、整合性判定処理部１１９は、一時記憶領域１２９においてグループキー“０００２”で関連付けられた業務トランザクションが整合性条件を満たすか否かを確認する。図９に示す整合性条件１２５は、テーブル「ＴＡＢＬＥ１のＳＴＡＴＵＳが“ＣＯＭＰＬＥＴＥ”である時」と定義されている。この時点で、一時記憶領域１２９内のテーブル「ＴＡＢＬＥ１」における「ＬＯＴＮＵＭ」が“０００２”の行データのカラム「ＳＴＡＴＵＳ」は”ＣＯＭＰＬＥＴＥ”であるため、整合性条件を満たす。この結果、以降の処理を継続する。
【０１３７】
整合性判定処理部１１９では、次に、整合性対象１２６と整合性判定処理部１１９が保持するグループキー“０００２”に基づき、一時記憶領域１２９からテーブル単位で行データを抽出する。さらに、抽出元のテーブル名とカラム名と抽出した値を対応付け、以下の追加データを作成し、整合性判定処理部１１９内に一時的に蓄積する。
【０１３８】
「ＴＡＢＬＥ２」の「ＬＯＴＮＵＭが“０００２”、材料投入量が“５０”」
・・・追加データ（１）
「ＴＡＢＬＥ３」の「ＬＯＴＮＵＭが“０００２”、製造量が“４０”」
・・・追加データ（２）
「ＴＡＢＬＥ４」の「ＬＯＴＮＵＭが“０００２”、不良が“１０”」
・・・追加データ（３）
【０１３９】
次に、前記追加データ（１）および、追加データ（２）、追加データ（３）とデータ対応表１２８から反映データ１２１１を作成する。反映データ１２１１は、対象となる分析テーブルへの追加操作を実施するためのデータである。本例における分析テーブルはＲＤＢＭＳで管理されている。これにより、本例の反映データはＳＱＬとする。
【０１４０】
追加データは、対象分析テーブルへの「追加」操作を表しており、データ対応表（１２８）において、テーブル「ＴＡＢＬＥ２」のカラム「ＬＯＴＮＵＭ」「材料投入量」に対応するのは、テーブル「ＴＡＢＬＥ２ａ」のカラム「ＬＯＴＮＵＭ」「材料投入実績」である。
【０１４１】
同様に、テーブル「ＴＡＢＬＥ３」のカラム「ＬＯＴＮＵＭ」「製造量」に対応するのは、テーブル「ＴＡＢＬＥ３ａ」のカラム「ＬＯＴＮＵＭ」「製造実績」であり、テーブル「ＴＡＢＬＥ４」のカラム「ＬＯＴＮＵＭ」「不良」に対応するのは、テーブル「ＴＡＢＬＥ４ａ」のカラム「ＬＯＴＮＵＭ」「不良実績」である。
【０１４２】
これにより構成される反映データは、
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ２ａ  ＬＯＴＮＵＭ  材料投入実績  ＶＡＬＵＥＳ（“０００２”，“５０”）                          ・・・反映データ（１）
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ３ａ  ＬＯＴＮＵＭ  製造実績  ＶＡＬＵＥＳ（“０００２”，“４０”）                              ・・・反映データ（２）
ＩＮＳＥＲＴ  ＩＮＴＯ  ＴＡＢＬＥ４ａ  ＬＯＴＮＵＭ  不良実績  ＶＡＬＵＥＳ（“０００２”，“１０”）                              ・・・反映データ（３）
となる。
【０１４３】
作成された反映データ１２１１は、システム実行処理部１１４に一時的に蓄積される。最後に、整合性判定処理部１１９は、整合性判定処理部１１９が持つ追加データを全て破棄し、全ての処理を終了する。
【０１４４】
次に、更新反映処理部１２０において、システム実行処理部１１４が持つ反映データ１２１１の分析テーブルへの反映処理を実行する。システム実行処理部１１４が持つ反映データは［反映データ（１）］、［反映データ（２）］、［反映データ（３）］（１２１１）である。更新反映処理部１２０は、［反映データ（１）］を分析テーブル２（１２０６）、［反映データ（２）］を分析テーブル３（１２０７）、［反映データ（３）］を分析テーブル４（１２０８）に対して、それぞれ反映する。以上で更新反映処理部１２０における、分析テーブルに対する反映データの更新反映処理を終了する。
【０１４５】
最後に、システム実行処理部１１４が持つ一時的に保持する再構成更新データ１２１０ｃおよび反映データ１２１１を全て破棄し、システム実行処理部１１４の処理が終了する。以上が本データ処理の実行例である。
【０１４６】
整合性確保システムにおいて前記したデータ処理を実行し、その結果、分析テーブル１（１２０５）、分析テーブル２（１２０６）、分析テーブル３（１２０７）、分析テーブル４（１２０８）に反映されたデータを参照することで、分析アプリケーション１１０からデータ間の整合性が確保されたデータのみ参照が可能となる。
【０１４７】
以上説明したように、本発明によれば、複数の業務サーバから横断的に更新データを取得したときに、分析サーバにおいて以上説明したようなデータ処理を実行することで、分析時に用いるデータの整合性が確保され、製造業務管理者が分析を行なう上で正しい情報のみを参照することが可能となる。
【０１４８】
また、従来の企業内情報システムにおいてバッチ処理で行なわれていた業務サーバから分析サーバへの更新データの反映処理を本発明に置き換えることで、一定の間隔に縛られることなく、データ間の整合性が確保されたデータを即座に分析処理に利用することが可能となる。
【０１４９】
［第二の実施形態］
次に、本発明の第二の実施形態について、図１３を参照して説明する。
図１３は、本発明の第二の実施形態の全体構成を示す図である。第二の実施形態で示す整合性確保システムでは、整合性定義１２４を複数設定することで、分析サーバ１０１で扱う業務トランザクションが単一でなかったとしても、分析アプリケーション１１０にとって整合性のとれた正しいデータを参照することが可能となる。
【０１５０】
第二の実施形態は、第一の実施形態（図１参照）と基本的に同様の構成をとるが、その中の主記憶装置１０８ａ内の構成が異なる。第二の実施形態における主記憶装置１０８ａ内の構成は図１３に示すように、主記憶装置１０８ａに整合性定義が一つ以上存在し、システム設定処理部１１３ａの制御下に、整合性定義最適化処理部１３００（定義情報適正化部）を設ける。また、二つ以上の整合性定義を統合、最適化した最適整合性定義１３０１が一つ以上存在する。以上の処理部、定義は２次記憶装置１０９や、ＵＳＢメモリといった外部記憶装置（本図未表記）などのコンピュータで読み書きできる記憶媒体に格納することもできる。
【０１５１】
以下、本実施形態における整合性確保システムの処理内容について説明する。
整合性確保システム（データ処理システム）では、第一の実施形態のときと同様の処理を実行する。整合性確保システムのシステム設定処理部１１３ａは、整合性定義１２４の設定要求を受け、整合性定義設定処理部１１６にて整合性定義１２４を設定した直後に、整合性定義最適化処理部１３００を起動し、必要に応じて一つ以上の整合性定義から最適整合性定義１３０１を作成する。ここで、図１４を参照して最適整合性定義１３０１について説明する。
【０１５２】
図１４は、最適整合性定義の構成および構成方法の例を示した図である。最適整合性定義１３０１は、整合性定義と同様の構造をとっており、必要に応じて新たに設定された整合性定義１２４と、前記整合性定義が設定された時点で既に存在する最適整合性定義を統合することで作成される。
【０１５３】
最適整合性定義１３０１の整合性条件１３０２、整合性対象１３０３、グループキー１３０４は統合された整合性定義（１２４ａ、１２４ｂ）の整合性条件（１２５ａ、１２５ｂ）、整合性対象（１２６ａ、１２６ｂ）、グループキー（１２７ａ、１２７ｂ）の集合で表現されており、整合性定義（１２４ａ、１２４ｂ）としての関係性は、統合される前の状態が分かるように設定（１４０４、１４０８）される。最適整合性定義１３０１の整合性対象１３０３において重複したもの（１４１２）に関しては、いずれか一方の整合性対象から削除し統合することで、整合性判定処理時に同様の反映処理を重複して行なわない。一つ以上の整合性定義１２４を統合することによる、整合性定義の最適化処理の詳細については後記する。
【０１５４】
以下、第一の実施形態から追加された整合性定義最適化処理部１３００、および第一の実施形態と処理が異なる実行判定処理部１１８ａと整合性判定処理部１１９ａの処理内容について説明する。
【０１５５】
図１５は、第二の実施形態における整合性定義最適化処理部の処理内容を示すフローチャートである。整合性定義最適化処理部１３００による整合性定義の最適化処理について図１５を参照して説明する。
【０１５６】
整合性定義最適化処理部１３００では、まず、ステップＳ１５００で、既に設定されている最適整合性定義１３０１がひとつ以上存在するか否かを確認する。ここで、既に設定されている最適整合性定義１３０１がひとつ以上存在する場合は（ステップＳ１５００，Ｙｅｓ）、ステップＳ１５０１で、全ての最適整合性定義の数だけ以下のステップを繰り返す。繰り返し処理では、まず、ステップＳ１５０２で直前に設定された整合性定義１２４と、比較対照である最適整合性定義１３０１に対し、比較対象同士の最適化を実行する必要があるか否かを確認（判定）する。
【０１５７】
整合性定義の最適化が必要となる状況について説明する。整合性定義１２４が複数設定されるということは、業務トランザクションが複数存在することを意味する。業務トランザクションが複数存在するとき、整合性を確保すべき対象が、複数の業務トランザクションで重複することがある。このような場合、全ての業務トランザクションにおいて整合性を確保するためには、全ての業務トランザクションにおいて整合性が確保される条件が成立した時点でデータの反映処理を行なう必要がある。
【０１５８】
ステップＳ１５０３で行われる、最適化を実行する必要があるか否かの確認は、比較対象としている整合性定義の整合性対象１２６と最適整合性定義の整合性対象１３０３を比較することで実行する。ここで、整合性定義１２４の最適化が必要である場合（ステップＳ１５０３，Ｙｅｓ）、すなわち、整合性定義と最適整合性定義で、ひとつでも整合性対象が重複した場合には、ステップＳ１５０５で整合性定義１２４と、最適整合性定義１３０１を統合する形で、新たな最適整合性定義１３０１を作成する。このとき重複した整合性対象については、直前に設定された整合性定義から削除された上で統合を実施する。
【０１５９】
また、整合性定義の最適化処理実施し、新たな最適整合性定義を作成したときには、作成時に使用した最適整合性定義は削除し、整合性定義の最適化処理を終了する。
【０１６０】
また、ステップＳ１５０３において、整合性定義１２４の最適化が必要でない場合（ステップＳ１５０３，Ｎｏ）、ステップＳ１５０４において、ステップＳ１５０１の繰り返し処理を全て終えた場合、ステップＳ１５０６で直前に設定された整合性定義を最適整合性定義として設定し、整合性定義の最適化処理を終了する。なお、ステップＳ１５００において、既に最適整合性定義１３０１が設定されていない場合（ステップＳ１５００，Ｎｏ）、ステップＳ１５０６に進む。以上で、整合性定義最適化処理部１３００の説明を終了する。
【０１６１】
図１６は、第二の実施形態における実行判定処理部の処理内容を示すフローチャートである。実行判定処理部１１８ａによる整合性判定処理が必要であるか否かの判定処理について図１６を参照して説明する。
【０１６２】
実行判定処理部１１８ａは、システム実行処理部１１４ａにより起動される。実行判定処理部１１８ａは、ステップＳ１６００で、既に設定されている最適整合性定義１３０１の数だけ以下のステップを繰り返す。この繰り返し処理では、まずステップＳ７００ａで処理対象の更新データを分析テーブル１３０に反映するにあたって、整合性判定処理を行なう必要があるか否かを判定する。
【０１６３】
整合性判定処理の必要性判定処理について第一の実施形態との変更点について述べる。ステップＳ７００ａにおける判定対象が、整合性定義１２４で定義されている整合性対象１２６から最適整合性定義１３０１で定義される全ての整合性対象１３０３に変更する。
【０１６４】
前記整合性判定処理が必要であるか否かの判定処理の結果から整合性判定処理を行なう必要があると判定された場合（ステップＳ７０１，Ｙｅｓ）、ステップＳ７０２ａで処理中の最適整合性定義１３０１を参照して整合性判定処理をする必要があることをシステム実行処理部１１４aに通知する。整合性判定処理を行なう必要がないと判定された場合（ステップＳ７０１，Ｎｏ）、ステップＳ７０４ａで更新データと整合性条件１３０２から整合性判定の実行が必要か否かを判断する。本ステップでは最適整合性定義１３０１で定義されている全ての整合性条件１３０２を対象に整合性判定処理の必要性判定処理を行なう。
【０１６５】
前記整合性判定処理の必要性判定処理で、整合性判定処理を行なう必要があると判定された場合（ステップＳ７０５，Ｙｅｓ）、ステップＳ７０６ａで処理中の最適整合性定義１３０１に対して整合性判定処理をする必要があることをシステム実行処理部１１４ａに通知する。なお、ステップＳ７０５で整合性判定処理が必要でない場合（ステップＳ７０５ａ，Ｎｏ）、処理を終了する。以上が第二の実施形態における実行判定処理部１１８ａの処理内容である。
【０１６６】
図１７は、第二の実施形態における整合性判定処理部の処理内容を示すフローチャートである。整合性判定処理部１１９ａにおける整合性判定処理について図１７を参照して説明する。整合性判定処理部１１９ａは、システム実行処理部１１４ａにより起動される。
【０１６７】
図１７に示す処理内容のうち、ステップＳ８０５，Ｓ８０６，Ｓ８０７，Ｓ８０８における反映データの作成処理の処理内容については第一の実施形態で述べた通りである。整合性判定処理部１１９ａでは、実行判定処理部１１８ａからシステム実行処理部１１４ａに通知された全ての最適整合性定義１３０１を対象に以下のステップ整合性判定処理を実行する。
【０１６８】
整合性判定処理では、まずステップＳ１７００で、実行判定処理部１１８ａにおいて整合性判定処理が必要であると判定された最適整合性定義の数だけ以下のステップを繰り返す。この繰り返し処理では、まずステップＳ８０１ａで対象の整合性定義のグループキー１３０４を取得する。最適整合性定義１３０１が複数の整合性定義１２４から最適化されたものであり、グループキー１３０４が複数定義されている場合には、定義されているグループキー１３０４の値を全て取得し、一時的に格納する。
【０１６９】
次に、ステップＳ８０２ａで、条件判定処理部１２１ａを起動し、最適整合性定義１３０１で定義されている複数の整合性条件１３０２が成立するか否かを判定する。本条件判定処理は、それぞれの整合性条件と対応関係にあるグループキーで関連付けられた業務トランザクションに対して行われる。前記条件判定処理において、全ての整合性条件の成立が確認された場合にのみ（ステップＳ８０３ａ，Ｙｅｓ）、ステップＳ８０４ａで対象データ抽出処理部１２２ａを起動し、最適整合性定義１３０１で定義されている複数の整合性対象１３０３と、それらの整合性対象１３０３と対応関係にある、整合性判定処理部１１９ａに格納されているグループキー１３０４の値に基づき、一時記憶領域からテーブル単位で値を抽出する。
【０１７０】
ここまでの処理ステップ（Ｓ８０１ａ、Ｓ８０２ａ、Ｓ８０３ａ、Ｓ８０４ａ）について図１４を参照して説明する。まず、ステップＳ８０１ａにおいて、グループキー１４０７とグループキー１４１１の値が個々に取得される。
【０１７１】
次に、ステップＳ８０２ａでグループキー１４０７の値で関連付けられた業務トランザクションに対して、整合性条件１４０５が成立しているか否かを判定し、それと同様にグループキー１４１１で関連付けられた業務トランザクションに対して、整合性条件１４０９が成立しているか否かを判定する。
【０１７２】
前記判定処理において、両整合性条件（１４０５、１４０９）が成立した場合にのみ、ステップＳ８０４ａにおいて、グループキー１４０７の値で関連付けられた業務トランザクションから整合性対象１４０６を抽出し、グループキー１４１１の値で関連付けられた業務トランザクションから整合性対象１４１０を抽出する。
【０１７３】
なお、整合性対象１３０３において、対象が重複することはないため、最適整合性定義１３０１に最適化する前の整合性定義１２４の時に重複していた同対象に対して複数回の抽出処理が行われることはない。
【０１７４】
ステップＳ８０４ａで抽出された値は、抽出元のテーブル名とカラム名と結びつけられ、反映対象への追加データとして、整合性判定処理が終了するまで、整合性判定処理部１１９ａにおいて一時的に所持する。以上が第二の実施形態における整合性判定処理部１１９ａの処理内容である。
【０１７５】
以上説明したように、本発明によれば、整合性定義を複数設定した上で必要に応じて整合性定義の最適化を実施することによって、分析サーバで扱う業務トランザクションが単一でなかったとしても、分析アプリケーションにとって整合性のとれた正しいデータを参照することが可能となる。また、商業的なシステムとして用いる場合には、本発明を導入するにあたり、分析業務毎に別途分析サーバを準備する必要がなくなりコストの低減が可能となる。
【０１７６】
本実施形態では、先ずアプリケーションにとって整合性が確保される条件を示した整合性条件１２５と、整合性が確保された時にアプリケーションから参照可能となるデータを示した整合性対象１２６と、整合性条件の判定に必要となる要素の獲得や整合性条件を満たした際に参照可能とするデータを断定するために必要となるグループキー１２７からなる整合性定義１２４を用意する。
【０１７７】
次に、任意のデータベースからリアルタイムに得られた更新情報全てをバッファに一時格納し、得られた更新情報がそれを参照するアプリケーションにとって整合性を確保する必要がある情報か否かを判定し（例えば、ステップＳ１１８）、整合性を確保する必要があるのであれば更新情報が整合性条件を満たすか否かを判定し（例えば、ステップＳ８０２）、整合性条件を満たした時点でそれまでにバッファに格納した更新情報からグループキーと整合性対象（取得対象）で絞り込んだ全ての更新情報をアプリケーションにとって参照可能な状態にする（例えば、ステップＳ１２０）。リアルタイム処理に加え、整合性確保システムを用い、アプリケーションから参照可能となるデータを選定することで、アプリケーションがデータを横断的に組み合わせて参照する場合でも、正しく最新の情報が見ることができる。
【０１７８】
本実施形態の更新データは、特定の対象データ（例えば、製品（製品名））、対象データの一意性を保障するためのユニークなデータ（例えば、製品を製造する材料のロット番号）、対象データの更新前の状態を表す更新前状態情報（例えば、製品の製造過程の更新前の状態を表す更新前状態情報）を少なくとも含む更新前のデータ４００（データ情報）と、対象データ（例えば、製品）、ユニークなデータ（例えば、ロット番号）、対象データの更新後の状態を表す更新後状態情報（例えば、製品の製造過程の更新後の状態を表す更新後状態情報）を少なくとも含む更新後のデータ４０１（データ情報）とを、含んでなることを特徴とする。
【０１７９】
本実施形態の反映条件（整合性条件１２５）は、特定のデータが特定の形式となることが条件であることを特徴とする。「特定のデータが特定の形式となる」とは、整合性条件の条件判定式を満たすことを意味し、例えば、図９に示した例では、定義されている整合性条件１２５は、符号１１０７（図１１参照）に示す「ＳＴＡＴＵＳ」（特定のデータ）が、“ＣＯＭＰＬＥＴＥ”（特定の形式）である。
【０１８０】
本実施形態の反映条件（整合性条件１２５）は、特定のデータの有無が条件であることを特徴とする。特定のデータとは、例えば、図１１に示す製品の製品名のデータ（符号１１０５参照）、製品の製造過程の状態のデータ（符号１１０７参照）、製品の材料投入量のデータ（符号１１０９参照）、製品の製造量のデータ（符号１１１１参照）、製品の不良量のデータ（符号１１１３参照）である。
【０１８１】
本実施形態の反映条件（整合性条件１２５）は、少なくとも一つ以上の特定のデータあるいはその計算結果が特定の値となったことを条件とすることを特徴とする。少なくとも一つ以上の特定のデータの計算結果とは、例えば、図１１に示す製品の製造量（符号１１１１参照）と製品の不良量（符号１１１３）との和であり、製品の材料投入量（符号１１０９参照）（特定の値）以上である。
【０１８２】
本実施形態の反映条件（整合性条件１２５）は、特定のデータが特定の形式となるという条件、少なくとも一つ以上の前記特定のデータの有無という条件、少なくとも一つ以上の前記特定のデータあるいはその計算結果が特定の値となるという条件、のうち少なくとも一つ以上の条件であってもよい。
【符号の説明】
【０１８３】
１００    ネットワーク
１０１    分析サーバ
１０３    バス
１０４    ＣＰＵ
１０５    ネットワークインタフェース
１０６    出力装置
１０７    入力装置
１０８，２３１    主記憶装置
１０９    ２次記憶装置（第２のデータ蓄積領域）
１１０    分析アプリケーション
１１１    データ受信部
１１３    システム設定処理部
１１４    システム実行処理部
１１５    データ構造設定処理部
１１６    整合性定義設定処理部
１１７    更新情報蓄積処理部
１１８    実行判定処理部
１１９    整合性判定処理部
１２０    更新反映処理部
１２１    条件判定処理部
１２２    対象データ抽出処理部
１２３    反映目標対応処理部
１２４    整合性定義（定義情報）
１２５    整合性条件（反映条件）
１２６    整合性対象（対象情報）
１２７    グループキー（グループ化情報）
１２８    データ対応表
１２９    一時記憶領域
１３０    分析テーブル
２０２    業務サーバ
２３２    ２次記憶装置（第１のデータ蓄積領域）
２３３    業務アプリケーション
２３４    データ送信部
２３５    業務テーブル
１２００    整合性確保システム（データ処理システム）
１３００    整合性定義最適化処理部（定義情報適正化部）
１３０１    最適整合性定義
１３０２    整合性条件（最適整合性定義）
１３０３    整合性対象（最適整合性定義）
１３０４    グループキー（最適整合性定義）
【図１】
2010231323.tif 000003
【図２】
2010231323.tif 000004
【図３】
2010231323.tif 000005
【図４】
2010231323.tif 000006
【図５】
2010231323.tif 000007
【図６】
2010231323.tif 000008
【図７】
2010231323.tif 000009
【図８】
2010231323.tif 000010
【図９】
2010231323.tif 000011
【図１０】
2010231323.tif 000012
【図１１】
2010231323.tif 000013
【図１２】
2010231323.tif 000014
【図１３】
2010231323.tif 000015
【図１４】
2010231323.tif 000016
【図１５】
2010231323.tif 000017
【図１６】
2010231323.tif 000018
【図１７】
2010231323.tif 000019
【図１８】
2010231323.tif 000020