JP5883937B2 - 計算機システム、データ管理方法及びプログラムを格納する記録媒体 - Google Patents

Description

本発明は、計算機システム、データ管理方法及びプログラムを格納する記録媒体に係り、特に、処理を行う複数の処理部によって生成されたデータを管理する計算機システム、データ管理方法及びプログラムを格納する非一時的な記録媒体に関する。

多種多様な膨大なデータ群を利用する際、計算機システム内には、そのデータ群を用いた種々のサービスを提供することを目的として、多くのテータ処理プログラムが稼動する。これらデータ処理プログラムは、独自のサービスを提供するために、各々データ群にアクセスしてこれを加工又は変換し、付加価値が付けられた種々のデータ（処理後データ）が生成される。計算機システムでは、このように複数のデータ処理プログラムから生成された処理後データの全部又は一部を利用して、特定のサービスを提供することがある。

このような場合、複数のデータ処理プログラムが生成した処理後データの関係性を管理する必要がある。より具体的には、各データ処理プログラムが生成した処理後データの元となる処理前データの整合性を管理する必要がある。例えば、処理前データ群が更新された場合、更新前の処理前データにアクセスしたデータ処理プログラムと、更新後の処理前データにアクセスしたデータ処理プログラムとから生成される処理後データは、処理のベースが異なることになる。この結果、計算機システムが提供する特定のサービスに矛盾等が生ずる虞もある。

特許文献１は、管理サーバが電子データに対するアクセスを監視し、アクセスがあった場合にその利用履歴や処理内容を示すメタデータを付与し管理する方法を開示する。この方法は、管理サーバが一元管理するメタデータを条件としてオリジナルデータを抽出するシステムを実現する。

特許文献２は、単一の画像データに対して処理前データ、処理後データ、処理内容や処理日時といった処理履歴情報を履歴管理サーバが保持することで、画像データの処理履歴の追跡を可能とする方法を開示する。この方法は、複数の処理結果データの処理履歴を追跡することで、処理前データと処理後データの関係性を管理することができる。

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

特許文献１の技術は、処理後データと処理前データの対応が管理されていないため、加工又は変更された処理後データを取得した場合に、その処理履歴を知ることができないという問題がある。

特許文献２の技術は、処理の度に処理前データと処理後データとの両方の検知、処理前データと処理後データを関連付ける処理履歴データの生成及び処理履歴データの保存、といった処理を適宜実行するため、処理履歴を管理するための負荷が発生する。

これら処理履歴を管理する負荷は、データ処理プログラムにおける処理の実行に伴って発生するため、データ処理プログラムの実行自体に影響が及ぶことになる。例えば、データ処理プログラムにその実行途中で処理履歴に関する処理を加えた場合には、処理履歴を管理する負荷により処理プログラムの実行を遅延させることになる。また、扱うデータ量、処理プログラムの種類又は実行頻度が増加する場合には、処理履歴の管理に関わる処理量の増大により負荷がより増大し、データ処理プログラムに与える影響も大きくなる。

上記課題を解決するために、例えば、特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、
処理前データを取得して所定の処理を実行し、その処理の結果として処理後データを生成する複数の処理部と、
前記複数の処理部の各々によって前記処理前データが取得される契機に、その取得の順序性を示し且つ前記複数の処理部の所定の処理の前後で更新されない処理ＩＤを、取得される処理前データに付与し、前記処理部の所定の処理によって生成された処理後データを記憶装置に格納させるデータ処理部と
所定のデータ検索条件を受信し、前記記憶装置に格納された処理後データを抽出する際、前記データ検索条件を満たす処理後データのうち、処理部毎の処理後データ間で最新であって、各処理部間で最古となる処理ＩＤ以前の処理ＩＤを有する処理後データを抽出し、検索要求元に出力するデータ管理部と、
を有する計算機システムである。

本発明によれば、特定のデータ処理イベントとそのデータ処理イベントにより処理された処理後データとの対応関係を処理履歴として管理するデータ管理システムを提供することができる。上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

図１は、本発明を適用した第1実施例における計算機システムの概要を示す模式図である。 図２は、第１実施例における計算機システムの構成例を示す。 図３は、第１実施例における計算機システムの処理ＩＤ管理表を示す模式図である。 図４は、第1実施例における計算機システムの処理後データグループ管理表を示す模式図である。 図５は、第1実施例における計算機システムの処理ＩＤの具体的付与例を示す。 図６は、第1実施例における計算機システムの処理ＩＤの具体的付与例を示す。 図７は、第1実施例における計算機システムの処理前データの収集処理の流れを示すフロー図である 図８は、第1実施例における計算機システムの処理後データの管理処理の流れを示すフロー図である 図９は、第1実施例の変形例における処理依存グループ管理表を示す模式図である。 図１０は、第２実施例における計算機システムの構成例を示す。 図１１は、第２実施例における処理前データの収集処理の流れを示すフロー図である。 図１２は、第３実施例における計算機システムの構成例を示す。 図１３は、第３実施例における多段処理がなされた修理後データの生成・格納例を示した模式図である。 図１４は、第３実施例における処理ＩＤ管理表の例を示す模式図である。 図１５Ａは、第３実施例における計算機システムの処理ＩＤの具体的な付与例を示す。 図１５Ｂは、第３実施例における計算機システムの処理ＩＤの具体的な他の付与例を示す。 図１６は、第３実施例における多段処理を含む処理前データの収集処理の流れを示すフロー図である。 図１７は、第３実施例における処理後データの管理処理の流れを示すフロー図である。 図１８は、第４実施例における計算機システムの構成例を示す。 図１９は、第４実施例における計算機システムの変換規則管理表を示す模式図である。 図２０は、第４実施例における計算機システムの処理前データの収集処理の流れを示すフロー図である。 図２１は、第５実施例における計算機システムの構成例を示す。 図２２は、第５実施例における計算機システムのデータ収集スケジュール管理表を示す模式図である。 図２３は、第５実施例における計算機システムの外部システムからの処理前データ抽出処理の流れを示す模式図である。 図２４は、第５実施例における計算機システムの処理前データ収集スケジュールの管理処理の流れを示すフロー図である。 図２５は、第６実施例における計算機システムの構成例を示す。 図２６は、第６実施例における計算機システムの処理コスト管理表を示す模式図である。 図２７は、第６実施例における計算機システムの処理によって、検索要求元に表示される画面例を示す模式図である。 図２８は、第６実施例における計算機システムのデータ管理装置におけるデータ価格に関する管理処理の流れを示すフロー図である。

〔第１実施例〕
同じデータソースに対してアクセスする複数の処理プログラムが存在し、夫々の処理プログラムが独立してデータ処理イベントを発行する場合を考える。各処理プログラムは独立していることから、イベントはランダムに発生するともいえる。
ここで、データソースが更新されたとすると、各イベントが発生したタイミングによっては、同一のデータソースに対して発生したものであるか否かは不明である。

例えば、データソースに格納された画像Ａ及びキーワードＢの両方のデータを利用する所定の処理プログラムが２つ存在し、これらが独立して動作するとする。夫々が更新前の同じデータソースに対してイベント（例えば、データ取得イベント／データクロール）を発行したか否かは、双方のプログラムの処理自体が完了しているか否かを管理することによって判別することができる。一方の処理プログラムの処理のみが完了している場合、他方の処理プログラムが同一のデータソースに対してイベントを発生したか否かは真偽不明である（画像Ａと、キーワードＢとが同一データソースに含まれていないともいえる。）。

逆に、両方の処理プログラムの処理が完了している場合、画像Ａと、キーワードＢとは、同一のデータソースに含まれていると判断することができる。即ち各処理プログラムがデータソースからクロールした収集結果が整合していることを保証するには、各プログラムにおいてイベント処理後のデータを取得できるように管理する必要がある。これを実現する場合、イベントによって処理された処理後データと、各処理プログラムのデータ処理イベントの処理履歴とを対応付けて管理する必要がある。

しかしながら、処理履歴を管理する処理を処理プログラムの実行途中に加えるのは高負荷であり、処理遅延を招来する要因となる。更に、各処理プログラムに処理履歴を管理する改変を施す必要があり、柔軟性の問題も残る。

第1実施例では、データソースに対するデータ処理イベント（例えば、データ取得／データクロール）が発生した場合、データ処理イベントを一意に識別可能であり且つ処理プログラムの処理の前後で変更されることのない処理ＩＤを生成し、これを処理対象となったデータに対してイベントに利用される前に付与し、処理されたデータを処理ＩＤで管理することで、データソースから取得したデータが処理プログラム間で整合するものであるか否かを管理できる方法について説明する。

〔概要〕
図１に、本発明を適用した第1実施例である計算機システムの概要構成を示す。
データ処理部１０は、複数の独立した処理を実行するプログラムＡ１２ａ〜Ｃ１２ｃを有する。各プログラムは、任意のタイミングで、データソース４にイベントを発行する。なお、発行するイベントは、データ取得（データクローリング）であるものとして説明する。データソース４には、プログラムＡ１２a等によって取得される前のデータ（以後、「処理前データ」と称する。）である処理前データ領域３０が確保されるとともに、各プログラムのデータ取得イベントによって取得された後の取得済みデータ（以後、「処理後データ」と称する。）である処理後データ格納領域４０が確保されるようになっている。 先ず、プログラムＡ１２ａが、データソース４に対してデータ取得を要求し、処理前データＸ３１ａを取得する。データ処理部１０は、処理ＩＤ４５ａ（図では、「１」）を生成し、それと同時に、処理ＩＤ管理表１７に、処理ＩＤ４５ａと、イベント要求元である「プログラムＡ」とを対応付けて管理する。処理前データＸ３１ａは、処理ＩＤ４５ａが付加された状態でプログラムＡ１２ａに送信され、プログラムＡ１２ａの所定の処理で利用されるようになっている。

処理ＩＤ４５ａが付加された処理前データＸ３１ａを受取ったプログラムＡ１２ａは、所定の処理を実行した後の処理後データＸ４１ａを生成する。このとき処理ＩＤ４５ａは所定の処理によって影響を受けることなく普遍のＩＤとして処理後データＸ４１ａに付加され続けるようになっている。その後、処理後データＸ４１ａは、処理後データ格納領域４０に格納されるようになっている。

次いで、プログラムＢ１２ｂが、データソース４にデータ取得を要求する。データ処理部１０は、先のプログラムＡ１２ａのイベントとは異なるユニークな処理ＩＤ４５ｂ（図では、「２」）を生成し、処理ＩＤ管理表１７において、処理ＩＤ４５ｂと、イベント発行元である「プログラムＢ」とを対応付けて管理する。なお、処理ＩＤ４５は、処理ＩＤ管理表１７において、最新（最大値）の処理ＩＤを１インクリメントして新規に生成されるようになっている。

プログラムＢ１２ｂの所定の処理で利用された処理後データＹ４１ｂは、処理ＩＤ４５ｂを保持した状態で、処理後データ格納領域４０に格納されるようになっている。
データ処理部１０は、各プログラムＡ１２ａ〜Ｃ１２ｃによるデータ取得の度に同様の処理を繰り返す。

さて、データ管理部２０は、検索要求元から所定の検索条件を含む検索要求を受けると、処理ＩＤ４５が付加された処理後データ４１群の検索を行い、検索条件を満たす処理後データ４１を抽出する。

この時、データ管理部２０は、抽出した処理後データ４１に付加されている処理ＩＤ４５を抽出し、プログラム種別毎にグループ分けする処理を実行する。この結果が、処理後データグループ管理表２５である。

処理後データグループ管理表２５では、プログラムＡ１２ａ〜Ｃ１２ｃ毎に処理ＩＤがグルーピングされる。このため、各プログラムが処理に利用したデータを、処理ＩＤから判別することができる。例えば、プログラムＡ１２ａのイベントによって利用されたデータは、処理ＩＤが「１」及び「５」のデータであることが分かる。

処理ＩＤ４５ａ〜４５ｃは、データ処理部１０によって、イベントの発行順に付与・管理されることから、データ管理部２０は、各グループの処理ＩＤ４５の中で最新（最大値）の処理ＩＤ４５を夫々抽出し、抽出した最新の処理ＩＤのうち、グループ間で最古（最小値）の処理ＩＤ（以下、「全処理完了ＩＤ５５」という。）を求める（図では、「５」）。そして、全処理完了ＩＤ５５よりも新しい（値の大きい）処理ＩＤ４５を除外した処理ＩＤ４５群を求める。

このようにして求められた処理後ＩＤ４５群に対応する処理後データ４１は、処理プログラムＡ１２ａ〜Ｃ１２ｃが発行したデータ取得イベントにおいて整合性が保証された処理前データに対して処理がなされたものであることが分かる。データ管理部１０は、整合性のとれた処理前データから生成された処理後データ４１のみを、検索要求元に提供（送信）するようになっている。

また、全処理完了ＩＤ５５や、中間状態除去後ＩＤ一覧を、検索要求元やシステム管理者（不図示）のリクエストに応じて出力できるようになっている。

第１実施例の計算機システム１では、処理前データ３１ａ等に対するデータ取得イベントの発生の直前に付与し、その後のプログラムＡ１２ａ等の処理においても影響を受けない普遍の処理ＩＤ４５を処理後データに引継ぐようにすることで、全てのプログラムＡ１２ａ〜Ｃ１２ｃの処理自体を管理することなく、処理後データ４１の元となった処理前データの整合性を管理可能とする。

更に、データ処理部１０が、処理ＩＤ４５の生成・付与等に関する処理を実行するため、プログラムＡ１２ａ等の所定の処理に負荷をかけないという効果があり、更に、プログラムＡ１２ａ等に処理ＩＤの生成・付加を実行させるためのコードを逐次記述する必要がなく、処理プログラムの開発工数を削減するという効果も期待できる。
以上が概要である。

図２に、第１実施例の計算機システム１のより詳細な構成を示す。
計算機システム１は、ＣＰＵ２、主記憶としてのメモリ３、補助記憶としての記憶装置４、キーボードやポインティングデバイス、表示モニタやプリンタ等の種々の入出力を行う入出力装置５及びＬＡＮやインターネット等を介して外部機器との有線又は無線の通信を行うＩ／Ｆ６等を有するサーバ装置である。なお、入出力装置５は、計算機システム１の外部に設けて、Ｉ／Ｆ６を介してモバイル端末等から操作可能にする構成でもよい。

メモリ３には、例えば、ＣＰＵ２とプログラムとの協働により実現される機能部であるデータ処理部１０と、データ管理部２０とを有する。
データ処理部１０は、種々の独立したプログラムＡ１２ａ〜Ｃ１２ｃが動作する処理プログラム実行部１２と、これらプログラムからの要求により記憶装置４からデータを取得する処理前データ収集部１５と、収集したデータに対して一意の処理ＩＤ４５を生成する処理ＩＤ付与部１４と、処理ＩＤとデータ収集要求元であるプログラムＡ１２ａ等とを対応付けて管理する処理ＩＤ管理表１７を保持する処理ＩＤ保持部１３と、プログラムＡ１２ａ等の所定の処理に利用された後のデータである処理後データ４１を処理ＩＤ４５が付与された状態で記憶装置４に格納させる処理後データ保存部１６と、を有する。

プログラムＡ１２ａ〜Ｃ１２ｃは、夫々独立した処理を行う機能部である。各プログラムは、夫々の処理において必要となる種々のデータ（例えば、医療分野における患者の属性、病歴、ＣＴやレントゲン画像といった電子カルテに必要なデータや、工場・プラント管理における種々のセンサデータや、ＳＮＳ（Social Network System）分野におけるメッセージや動画像データ、金融分野における顧客データや取引履歴並びに流通分野における顧客属性や購買履歴等、種々の分野の様々な実データやメタデータが考えられる。）を、記憶部４から取得し、夫々の処理を行うようになっている。

図３に、処理ＩＤ管理表１７を模式的に示す。処理ＩＤ管理表１７は、処理ＩＤ項目１８と要求元項目１９を有し、各プログラムのデータ取得要求によって取得した処理前データに対して処理ＩＤ付与部１４が生成する一意の処理ＩＤ４５をデータ取得要求元と対応づけた上で、昇順に管理する情報である。なお、本実施例はテーブルを用いた例を説明するが、本発明はこれに限るものではなくリスト構造等で保持してもよい。また、処理ＩＤ４５を昇順で管理せずとも、順序性を判断可能であれば、種々の方式を適用することができる。

また、処理ＩＤ４５は、データ取得イベントが発生した時刻を用いてもよい。更に、処理ＩＤを処理ＩＤ付与部１４で新たに生成する以外に、処理前データ３１が有する既存の識別子を利用してもよい。この場合、処理ＩＤ付与部１４や処理ＩＤ保持部１３が、そのような識別子を処理前データ３１から抽出し、順序性を管理できるようにすればよい。具体的には、データのメタデータとして含まれるアクセス時刻や更新時刻を処理ＩＤとして利用してもよいし、データの記憶場所を示すパス情報を処理ＩＤとして利用しそのパス情報をデータ取得イベントの処理対象となった順番に管理してもよい。

データ管理部２０は、ＣＰＵ２と、プログラムとの協働により実現される機能部である、検索条件受信部２１、処理後データ収集部２２、処理履歴管理部２３、処理後データグループ管理表２４及び検索結果送信部２５を有する。データ処理部１０によって管理される処理ＩＤ管理表１７を用いて、各種の検索結果を演算するようになっている。

検索条件受信部２１は、入出力装置５を介して入力された検索要求を受け付けるようになっている。検索要求には、所定の検索条件が含まれ、処理プログラムＡ１２ａ〜１２ｃのデータ取得イベントによって取得された処理後データをプログラム毎に抽出する要求や、全ての処理プログラムＡ１２ａ〜Ｃ１２ｃのデータ取得イベントにおいて取得された処理後データ４１の検索要求等である。
処理後データ収集部２２は、検索条件受信部２１の検索要求受付に応じて、検索条件を満たす処理後データ４１を、それに付加された処理ＩＤ４５とともに収集するようになっている。

処理履歴管理部２３は、処理後データ収集部２２が取得した処理後ＩＤ４５について、処理ＩＤ管理表１７を参照して、プログラムＡ１２ａ〜Ｃ１２ｃ毎にグループ分けを行い、処理後データグループ管理表２４を作成する。

図４に、処理後データグループ管理表２４を模式的に示す。処理後データグループ管理表２４は、プログラムＡ１２ａ〜Ｃ１２ｃ毎のグループ項目２６〜２８と、最新処理ＩＤ項目５０、処理ＩＤ一覧項目５１及び中間状態除去後ＩＤ一覧項目５２の項目とを有する。処理ＩＤ一覧項目５１には、検索条件に基づいて処理後データ収集部２２が検索した処理後データ４１の処理ＩＤ４５が格納される。最新処理ＩＤ項目５０には、処理ＩＤ一覧項目５１のグループ単位で、最新（最大値）の処理ＩＤ４５が格納される。

中間状態除去後ＩＤ一覧項目５２には、全グループの最新処理ＩＤ５０の中で、最古（最小値）の最新処理ＩＤである全処理完了ＩＤ５５よりも新しい（値がより大きい）処理ＩＤを、処理ＩＤ一覧項目５１に登録された処理ＩＤから除いたものが格納される。例えば、最新処理ＩＤ項目５０の処理ＩＤの内、全処理完了ＩＤ５５が、「５」である場合、それ以下の処理ＩＤ４５（「１」、「２」、「３」、「４」、「５」）が格納されるようになっている。

検索結果送信部２５は、中間状態除去後ＩＤ一覧項目５２に格納された処理ＩＤ４５に対応する処理後データを検索結果として出力するようになっている。

記憶装置４は、例えば、ＨＤＤやＳＳＤ等から構成され、プログラムＡ１２ａ〜Ｃ１２ｃで利用する種々のデータを保持する。記憶装置４は、処理前データＸ３１ａ、Ｙ３１ｂ…を保持する処理前データ格納領域３０と、処理後データＸ４１ａ、Ｙ４１ｂ…を記憶する処理後データ格納領域４０との２つの記憶領域を有する。処理前データ格納領域３０の処理前データ３１は、適宜更新（追加・削除・上書）されるようになっている。

処理前データ３１ａ、３１ｂ…には、上述の処理ＩＤ４５ａ〜４５ｃ等は付与されていない。処理後データ４１ａ〜４１ｃには、処理ＩＤ４５ａ〜４５ｃ等が付与された状態で保持されるようになっている。処理ＩＤ４５ａ〜４５ｃは、一度付与されるとその後のプログラムＡ１２ａ〜Ｃ１２ｃの処理において削除されることなく保持し続けられるようになっている。

図５及び図６に、処理ＩＤ４５を付した処理後データ４１の例を模式的に示す。
図５に示すように、データ構造が、制御情報等を格納するＨｅａｄｅｒ部と、実データを格納するｂｏｄｙ部とからなる場合は、Ｈｅａｄｅｒ部に処理ＩＤ４５として”ProcessID=1“を記入すればよい（数値は処理順に応じて適当に変更される。）。

また、図６に示すように、データの存在場所を示す＜Source＞~＜/ Source＞の記述に続けて、メタデータとして、＜Metadata＞~＜/ Metadata＞の間に“＜ProcessID＞１＜/ ProcessID>”と記述して、処理ＩＤ４５を付与するようにしてもよい（数値は処理順に応じて適宜変更される。）。
なお、処理前データが取得された時刻等を処理ＩＤに利用してもよいことは前述の通りである。

以上の構成を有する計算機システム１の処理の流れについて詳細に説明する。
図７に、データ処理部１０の処理フローを示す。
Ｓ１０１で、処理前データ収集部１５は、プログラムＡ１２ａ~Ｃ１２ｃの何れか一つから発行された処理前データ取得要求を受ける（プログラムＡ１２ａから取得要求を受けたものとする。）。
Ｓ１０３で、処理ＩＤ付与部１４は、処理ＩＤ保持部１３の処理ＩＤ管理表１７を参照し、最新（最大値）の処理ＩＤ４５を取得し、これを１つインクリメントした新規の処理ＩＤ４５ａを生成する（処理ＩＤ管理表１７に最新の処理ＩＤが無い場合は、「１」を生成する。ここでは「１」とする。）。

Ｓ１０５で、処理ＩＤ保持部１３は、新規処理ＩＤと、データ取得要求元であるプログラムＡ１２ａの識別情報（プログラム名）とを対応づけて、処理ＩＤ管理表１７の最後尾に追加登録する。
Ｓ１０７で、処理前データ収集部１５は、要求された処理前データＸ３１ａを収集し、新規の処理ＩＤ４５ａを付加して、処理プログラム実行部１１に送付する。プログラムＡ１２ａは、取得した処理前データＸ３１ａに対して所定の処理を実行する。

Ｓ１０９で、処理後データ保存部１６は、所定の処理の結果生成した処理後データＸ４１ａを、記憶装置４の処理後データ格納領域４０に保存させる。このとき、処理後データＸ４１ａは、処理を行ったプログラムを識別できる状態で格納される。具体的には、処理後データ格納領域４０を処理プログラム毎に確保しても良いし、処理後データＸ４１ａのメタデータとしてプログラムＡ１２ａの情報を付与しても良い。
以上がデータ処理部１０の処理の流れである。

図８に、データ管理部２０の処理の流れを示す。
まず、Ｓ１５１で、処理後データ収集部２２は、入出力装置５等を介して検索条件受信部２１に入力された検索要求に対し、処理後データ格納領域４０から、条件に一致する処理後データ４１を、付随する処理ＩＤとともに収集する。

Ｓ１５３で、処理履歴管理部２３は、処理ＩＤ管理表１７を参照し、処理を実行したプログラムＡ１２ａ〜Ｃ１２ｃ毎に、処理後データ４１をグループ化して管理し、そのグループ毎に最新（最大）の処理ＩＤ４５を抽出する。例えば、図４の処理後データグループ管理表２５に示すように、プログラムＡによって実施された処理後データ４１ａはプログラムＡグループ２６に所属し、その最新処理ＩＤは「５」、プログラムＡグループ２６にグルーピングされた各処理後データ４１に付随する処理ＩＤ４５を、処理ＩＤ一覧項目５１に「１」、「５」と記録する。他のグループも同様の処理を行う。

Ｓ１５５で、処理履歴管理部２３は、各グループで抽出された最新処理ＩＤ４５のうち、各グループ間で最も古い（最小値）処理ＩＤを全処理完了ＩＤ５５として取得する。例えば、処理後データグループ管理表２５において、全処理完了ＩＤ５５は最新処理ＩＤのうち最も値の小さい「５」となる。

Ｓ１５７で、処理履歴管理部２３は、全処理完了ＩＤ５５よりも新しい（大きい）処理ＩＤ４５を収集データから除去し、その結果を中間状態除去後ＩＤ一覧項目５２に記録し、検索結果送信部２２に送信する。例えば、処理後データグループ管理表２５において、全処理完了ＩＤ５５である「５」以下の処理ＩＤ４５を持つ処理後データ４１が処理される前の処理前データ３１は、他の全ての処理の対象ともなっていると判定できる。他方、処理ＩＤ４５が「５」より大きい処理ＩＤ４５を保持する処理後データ４１が処理される前の処理前データ３１は、プログラムＡ１２ａによる処理の対象になっていない可能性がある。このような状態の処理後データ４１は、除去される。

Ｓ１５９で、検索結果送信部２５は、Ｓ１５１で処理後データ収集部２２が検索した処理後データ４１の中で、中間状態除去後ＩＤ一覧項目５２に格納された処理ＩＤ４５に対応する処理後データ４１を検索要求元に送付する。検索要求元では、例えば画面上に送付された検索結果が表示される。
以上が、データ管理部２０の処理の流れである。

このように、第１実施例の計算機システム１では、プログラム１２ａ〜Ｃ１２ｃのデータ取得時に、それらプログラムの処理においても改変されることのない一意且つ普遍の処理ＩＤ４５を生成・付与し、全処理完了ＩＤ５５に基づいて、各処理プログラムＡ１２ａ〜Ｃ１２ｃ間で取得した処理前データが整合するものであるか否かを管理することができる。このことは、処理前データに対して全てのプログラムＡ１２ａ〜Ｃ１２ｃによるデータ取得が実行された結果得ることのできる処理後データ４１のみを抽出・管理することができるとも言える。

また、計算機システム１では、プログラムＡ１２ａ等ではなく、処理ＩＤ付与部１４が処理前データ３１に処理ＩＤ４５を生成・付与し、処理履歴管理部２３によって処理後データ４１の処理ＩＤ４５が利用されるため、プログラムＡ１２ａ等自体の処理に影響を与えることがない。同時に、プログラムＡ１２ａ〜Ｃ１２ｃ自体に処理ＩＤ４５を管理する機能（プログラムの記述）を加える必要が無く、プログラムの開発工数を削減するという効果もある。

また、計算機システム１では、処理ＩＤ４５が、処理プログラム実行部１１等での各種処理を起因として改変されることなく処理後データ４１に保持されるようになっているため、計算機システム１内において統一された識別情報として処理ＩＤ４５を利用することが可能となる。

〔第１実施例の変形例〕
本発明は、第１実施例等に限定されるものではなく、その趣旨を逸脱することなく、種々の構成を適用可能である。例えば、計算機システム１では、全てのプログラムＡ１２ａ〜Ｃ１２ｃについて、処理後データ４１と、データ取得イベントとの処理履歴を管理するようになっているが、特定のプログラム同士の間のみで、処理履歴を管理するようにすることもできる。

図９に、特定のプログラム間の依存関係を定義する依存グループ管理表５６を模式的に示す。本表では、依存関係にあるプログラム同士がグループ化され、それに対し依存グループＩＤと、依存関係にある処理プログラムの識別情報（ここではプログラム名）との対応が定義される。

この依存グループ管理表５６を、データ管理部２０に持たせる。そして、図８に示す処理後データの検索処理において、先ず、依存グループ管理表５６で依存関係にある処理プログラム同士に、依存関係ＩＤ項目５７の値を付与し、依存グループＩＤが同一の処理プログラムについて、Ｓ１５３（図８）からの処理を実行するようにするようにすればよい。
これにより、特定のプログラム間における処理前データの整合性が保証された検索結果を提供することができる。

〔第２実施例〕
第２実施例の計算機システム６０について説明する。第１実施例の計算機システム１は、単一の物理計算機を例として説明した。ここで、計算機システム１のプログラムＡ１２ａ〜Ｃ１２ｃは、他の計算機資源として提供されることもある。例えば、業務プログラム（アプリケーションやそれらの基盤となるミドルウェア等を含む。）が実行する何らかの処理には、検索等の機能を伴うことも多くある。データソースは共有し、業務プログラム単位でサーバ計算機を任意に追加・削除できるような構成をとることも多い。第１実施例のような単一の物理計算機では、プログラムの追加・削除はメモリ資源やＣＰＵ資源等の拡張のために、他のプログラムの実行停止や計算機の再起動等を伴うこともあり、計算機システム全体としての処理の弊害となる虞もあるからである。

第２実施例では、各プログラムを物理的に独立した計算機で提供し、それらがデータ取得イベントを同一のデータソースに対して発行する構成を有する計算機システムに本発明を適用した例を説明する。

また、第２実施例の計算機システムでは、プログラムＡ１２ａ〜Ｃ１２ｃからのデータ取得要求は、処理前データ３１だけでなく、処理後データ４１を対象とすることもできるようになっている。何れのデータを取得の対象とするかは、プログラムＡ１２ａ〜Ｃ１２ｃによって任意に設定できるようになっている。
なお、以下の説明において、第１実施例で説明した要素と同等の要素は同一符号を用いるものとし、詳細な説明は省略するものとする。

図１０に、第２実施例の計算機システム６０の構成を示す。計算機システム６０の特徴の一つは、プログラムＡ１２ａ〜Ｃ１２ｃを夫々物理的に独立した実行計算機７０ａ〜７０ｃで実行するようになっている。また、第１実施例におけるデータ処理部１０の機能部をデータ記憶装置９０に有し、データ管理部２０の各機能部をデータ管理装置８０に有する構成をとるようになっている点である。各実行計算機７０ａ〜７０ｃは、自プログラムを稼動させる計算機資源を確保しているため、計算機システム６０に対する追加・削除にともなうシステム全体の（一時）停止等に影響を与えないという利点がある。

データ管理装置８０は、ＣＰＵ８１、メモリ２２、記憶装置８３及び外部通信の為のＩ／Ｆ８４を含む計算機装置である。メモリ２２に、検索条件受信部２１、処理後データ収集部２２、処理後データグループ管理表２４及び検索結果送信部２５を有する。

実行計算機７０ａ〜７０ｃは、ＣＰＵ７１、メモリ７２、記憶装置７３及び外部との通信を行うＩ／Ｆ７４を含む計算機装置である。本例は、３つの実行計算機を設けた構成を用いるが、計算機システム６０のシステム要件に応じて、適宜その数は増減可能である。メモリ７２には、プログラムＡ１２ａ〜Ｃ１２ｃが、夫々稼動可能なようになっている。実行計算機７０ａ〜７０ｃは、データ記憶装置９０の記憶部９３に格納されたデータを共有のデータソースとする。実行計算機７０ａ〜７０ｃは、記憶部９３の処理前データ３１や処理後データ４１を任意のタイミングで取得（クローリング）し、取得したデータを夫々のプログラムＡ１２ａ〜Ｃ１２ｃで利用するようになっている。

データ記録装置９０は、ＣＰＵ９１、メモリ９２、記憶部９３及び外部との通信を行うＩ／Ｆ９４を含む計算機装置であり、例えば、サーバ装置やストレージ装置を適用することができる。メモリ９２には、処理前データ収集部１５、処理ＩＤ付与部１４、処理後データ保存部１６、処理ＩＤ保持部１３及び処理ＩＤ管理表１７を有するが、新たに処理データ制御部９５を有する点が第１実施例と異なる。

処理データ制御部９５は、実行計算機７０ａ〜７０ｃからのデータ取得要求を受け、処理前データ記憶領域３０、処理後データ格納領域４０或いはその両方に格納されたデータ群から、要求に応じたデータを検索し、実行計算機Ａ１２ａ等に送信するようになっている。より具体的には、処理データ制御部９５は、実行計算機７０等からの要求が処理前データ格納領域３０に格納された処理前データ（データ取得がされる前のデータ）である場合は、処理を処理前データ収集部１５に渡し、処理後データ領域４０に格納されたデータ（データ取得後のデータ）である場合は、処理後データ格納領域４０から、要求された処理後データを取得し、要求元の実行計算機に出力するようになっている。
以上が計算機システム６０の構成である。

なお、第２実施例では、データ管理装置８０と、データ記憶装置９０とを別の計算機装置とする例を用いて説明するが、本発明はこれに限定されるものではなく、両者を同一計算機内で構成することも可能である。

更に、実行計算機７０等は、１つのプログラムに対して１台の計算機装置とする構成以外にも、仮想計算機として単一の物理計算機に複数の仮想計算機が設けられる構成とすることも可能である。この場合、物理計算機には、仮想計算機の増減に際して自律的にＣＰＵやメモリ等の計算機資源を制御可能とする機能を設けるとよい。

図１１に、計算機システム６０のデータ記録装置９０の処理フローを示す。
Ｓ２０１で、データ制御部９５は、実行計算機７０ａ〜７０ｃのプログラムＡ１２ａ〜Ｃ１２ｃのいずれかからデータ取得要求を受けると（プログラムＡ１２ａからのデータ取得要求とする）、その要求が処理前データ３１の取得要求であるのか、処理後データ４１の取得要求であるのかを判定する。処理前データ３１の取得要求の場合（Ｓ２０１：Ｙｅｓ）、Ｓ２０３に進み、処理後データ４１の取得要求の場合（Ｓ２０１：ＮＯ）、Ｓ２１３に進む。

Ｓ２０３で、処理前データ収集部１５は、データ制御部９５からの処理前データ３１の収集指示を受信する。
Ｓ２０５で、処理ＩＤ付与部１４は、処理ＩＤ保持部１３の処理ＩＤ管理表１７を参照し、最新（最大値）の処理ＩＤを取得し、これをインクリメントした新規の処理ＩＤ４５ａを生成し（処理ＩＤ管理表１７に最新の処理ＩＤがない場合は、「１」を生成する。ここでは「１」とする。）、データ取得要求元であるプログラムＡ１２ａの識別情報（プログラム名）と対応づけて、処理ＩＤ管理表１７の最後尾に追加登録する。
Ｓ２０７で、処理前データ収集部１５は、要求された処理前データＸ３１ａを収集し、新規処理ＩＤ４５ａを付加して、要求元の実行計算機Ａ１２ａに送信する。プログラムＡ１２ａは、取得した処理前データＸ３１ａに対して所定の処理を実行する。

Ｓ２０９で、処理後データ保存部１６は、所定の処理により生成された処理後データ４１ａを実行計算機７０ａから受信し、新規処理ＩＤ４５ａが付加された状態で処理後データ格納領域４０に保存させる。このとき、記録部９３は、処理後データ４１ａに処理を行ったプログラムを識別できる形式で格納する。

他方、Ｓ２０１の判断で、データ収集要求の対象が処理前データで無いと判断すると、Ｓ２１３で、処理データ制御部９５は、処理後データ格納領域４０にアクセスし、要求の検索条件に一致する処理後データを収集し、要求元である実行計算機７０ａに送信する。 以上がデータ記録装置９０の処理の流れである。

なお、このようにして管理される処理ＩＤ管理表１７が、データ管理装置８０において、各実行計算機７０ａ〜７０ｃで利用するデータの整合性を確認することができる処理履歴管理を行うことは、第１実施例と同様である。

以上、第２実施例における計算機システム６０によれば、実行計算機７０と処理前後のデータの記憶を夫々異なる計算機で実現できるため、処理前後データの記憶を実現する装置を停止することなく処理の実行を実現する計算機をシステムに追加することができる。 また、複数の実行計算機７０に対し、データの保持及び処理ＩＤ４５の管理をデータ記憶装置９０で一元的に管理するため、実行計算機７０の構成がより複雑になっても、計算機システム６０で統一された処理ＩＤを用いて管理することが可能となる。

更に、計算機システム６０でも、第１実施例と同様に処理ＩＤ４５を用いることでプログラムＡ１２ａ〜Ｃ１２ｃ間の処理前データの整合性を管理することができる。

〔第３実施例〕
第１及び第２実施例において、プログラムＡ１２ａ〜Ｃ１２ｃの所定の処理によって生成された処理後データ４１が、再び自身又は他のプログラムのデータ取得要求の対象になる場合も考えられる。以下、このような一度処理対象として取得され、取得元のプログラムによるデータ処理（加工含む。）で生成された処理後データに対して、再度データ取得が行われ、再取得元のプログラムによるデータ処理（加工含む。）で生成された処理後データを生成する処理を「多段処理」と称する。多段処理では、前回取得・生成された処理後データと、今回取得・生成された処理後データとでは、取得対象とするデータ群が異なることになる。

第３実施例では、多段処理が発生する場合に、前回までと、今回までとの処理後データ４１の整合性を管理する計算機システム１００について説明する。
なお、計算機システム１００は、第２実施例の計算機システム６０の構成を基調とするが、多段処理に対する処理履歴の管理は第１実施例の計算機システム１にも適用可能である。以下、特に構成が異なる部分について説明し、機能・要素を共通にするものは同一符号を用いて詳細な説明を省略する。

図１２に、計算機システム１００の構成を示す。計算機システム１００は、検索要求元から検索キーと検索条件が含まれた検索要求を、データ管理装置８０が受けるようになっている。データ管理装置８０では、検索キーに該当する処理後データ４１群が抽出され、その中で検索条件を満たす処理後データについて、多段処理によるデータの整合性が考慮された処理後データを検索結果として求める処理を行うよう点が他の実施例と異なる。

更に、計算機システム１００は、データ記憶装置９０において、プログラムＡ１２ａ〜Ｃ１２ｃからの処理後データに対するデータ取得要求を処理可能とし、処理後データに対してデータ取得要求がされた場合に、その処理後データに新たな処理ＩＤ４５が生成・付与される点が他の実施例と異なる。

先ずデータ記憶装置９０における相違点について、詳細に説明する。

処理データ制御部１２０では、実行計算機７０ａ〜７０ｃの何れかから発行されたデータ取得要求に対するデータが、処理前データ或いは処理後データの何れであるかを判定するようになっている。この判定は、データ記憶装置９０でのデータの格納先が、処理前データ格納領域３０であるか或いは処理後データ格納領域４０であるかによって判定するようになっている。なお、処理後データ４１に付与されている処理ID４５の有無により判定してもよい。

処理データ制御部１２０によって取得要求の対象が処理前データ３１であると判定された場合には、他の実施例と同様に、処理前データ収集部１５によって、所定の処理前データ３１が取得され、処理ＩＤ管理表１７の最新の処理ＩＤを１インクリメントした処理ＩＤ４５が生成され、これが処理前データに付与された状態で、データ取得要求元の実行計算機７０に送信される。同時に、処理ＩＤ管理表１７には、処理ＩＤと取得要求元が記録される。

実行計算機に送信されたデータは、プログラムＡ１２ａ等によって所定の処理（加工）が行われて、処理ＩＤ４５が付与された状態の処理後データ４５が生成される。その後、処理後データ保存部１６によって処理後データ格納領域に格納される。

他方、実行計算機７０からのデータ取得対象が処理後データであると判定された場合、処理データ制御部１２０によって、処理ＩＤ管理表１７の最新の処理ＩＤ４５を１インクリメントした処理ＩＤ４５が生成され、その処理ＩＤ４５が付与された状態で取得要求先の実行計算機７０に処理後データ４１が送信される。同時に、処理ＩＤ管理表１７の最後尾には、生成した処理ＩＤと取得要求元が記録される。

図１３に、処理後データが再取得され、多段処理が行われた処理後データの生成・格納例を模式的に示す。
まず、実行計算機７０ａのプログラムＡ１２ａからの処理前データの取得要求を受け、処理前データＸ３１ａが処理前データ格納領域３０から取得され、処理ＩＤ４５ａが付与される。その後、プログラムＡ１２ａの処理によって、処理後データＸ４０ａが生成され、処理後データＸ４１ａが処理後データ格納領域４０に格納される。以下、処理前データＹ３１ｂ及び処理前データＺ３１ｃについても、同様に処理後データＹ４１ｂ、処理後データＺ４１ｃとして処理後データ格納領域４０に格納される。
ついで、処理前データ制御部１２０は、プログラムＢ１２ｂから、処理後データＸ４１ａの取得要求を受けるものとする。処理データ制御部１２０では、処理ＩＤ管理表１７において、この時点での最新の処理ＩＤである処理ＩＤ４５ｃ（「３」）を取得し、これを１インクリメントした「４」の処理ＩＤ４５ｄが生成される。生成された処理ＩＤ４５ｄ（「４」）は、処理後データＸ４０ａに追加付与され、プログラムＢ１２ｂに送信される。プログラムＢ１２ｂによって処理された処理後データＸＸ４１ｄが、処理後データ格納領域４０に格納されることとなる。以下、処理後データＹ４１ｂ及び処理後データＺ４１ｃも同様に処理後データＹＹ４１ｅ、処理後データＺＺ４１ｆとして処理後データ格納領域４０に格納されるようになっている。なお、図１４に、図１３の例における処理ＩＤ管理表１７の例を示す。

図１５Ａ及び図１５Ｂに、処理後データ４１に処理ＩＤ４５が追加付与される実装例を示す。図１５Ａは、ヘッダ部に処理ＩＤ４５が昇順に追加されている例である。”ProcessID=3”が追加で付与された処理ＩＤである。図１５Ｂは、メタデータとして処理ＩＤが追加された例を示す。”＜IDList＞”〜”＜／IDList＞”で囲まれた領域の「３」が追加付与された処理ＩＤである。

データ管理装置８０の変更点について詳細に説明する。
データ管理装置８０では、処理後データ収集部２２及び処理履歴管理部２３の処理内容が、特に他の実施例と異なる。
処理後データ収集部２２では、検索要求元からの所定の検索キーを含む検索要求に対する検索処理が、処理後データ格納領域４０に格納された処理後データ４１全体に対して行われる。
処理履歴管理部２３では、処理後データ収集部４０による検索結果として抽出された処理後データ４１群のうち、実行計算機７０ａ〜ｃからのデータ取得要求対象とされた処理後データのみが、検索結果として検索要求元に返信されるようになっている。即ち多段処理によって生成された処理後データ４１のみが検索要求の結果として返信されるようになっている。

処理履歴管理部２３では、検索要求に応じて処理後データ格納領域４０から、検索内容を満たす処理後データが、夫々に付与された付与ＩＤ４５と共に取得される。その後、取得された処理後データ４１群のうち最新の処理ＩＤが抽出される。処理履歴管理部２３では、処理ＩＤ管理表１７に基づいて、抽出された最新の処理ＩＤ４５の要求元（プログラム名）が抽出され、処理ＩＤ管理表１７において、その要求元（プログラム名）と同じ要求元名を有し且つ最新の処理ＩＤ４１移行に発行された処理ＩＤ４５を有する処理後データ４１が、検索要求元に検索結果として送信されるようになっている。

例えば、図１３を例に説明すると、検索キーに該当した処理後データ４１が、処理後データＸ４１ａと、処理後データＸＸ４１ｄとであったとする（処理ＩＤは「1」と「4」）。最新の処理ＩＤは「4」であるから、処理ＩＤ管理表１７を参照し、処理ＩＤ「4」の取得要求元名が取得される。本例では、「プログラムＢ」である。処理ＩＤ管理表１７において、取得要求元を同様にプログラムＢとする処理後データ４１は、処理後データＹＹ４１ｅ及び処理後データＺＺ４１ｆである。これらは取得要求元であるプログラムＢを同一とし且つ最新の処理ＩＤである「4」以降の処理ＩＤ「5」「6」を有する。処理履歴管理部２３では、「4」、「5」、「6」の処理ＩＤ４５を有する処理後データ４１を、検索結果送信部２５によって検索要求元に送信させることとなる。

処理後データＸＸ４１ｄは、処理後データＸ４１ａを基に多段処理が行われたデータである。このため、検索要求に含まれる検索キーに該当するデータが、処理後データＸ４１ａ及び処理後データＸＸ４１ｄに含まれていることになる。よって、検索キーに該当するデータを包含する処理後データ群のうち、最新の処理ＩＤ４５を有する処理後データは、多段処理によって生成された処理後データとなる。

以上の構成において、計算機システム１００の処理の流れを図１６及び図１７のフロー図を用いて説明する。
図１６に、データ記憶装置９０の処理フローを示す。
Ｓ３０１で、処理データ制御部１２０は、実行計算機７０ａ〜７０ｃの何れかからデータ取得イベントの発行を受ける。

Ｓ３０３で、処理データ制御部１２０は、処理ＩＤ付与部１４に、処理ＩＤ管理表１７を参照させ、最新（最大値）の処理ＩＤが、１インクリメントされた新規処理ＩＤを生成させる。そして、処理ＩＤ管理表１７に新規エントリを追加させ、新規処理ＩＤと、要求元プログラム名とを対応付けて記録させる。

Ｓ３０５で、処理データ制御部１２０は、データの取得先の記録領域に基づいて、取得先が処理前データ格納領域３０であるか、処理後データ記録領域４０であるかを判断する。処理後データ格納領域４０である場合、Ｓ３０７に進み、処理前データ格納領域３０である場合、Ｓ３１３に進む。

Ｓ３０７で、処理データ制御部１２０は、処理後データ記録領域４０から、所定の処理後データ４１を取得する。
Ｓ３０９で、処理ＩＤ付与部１４は、取得した処理後データ４１に、Ｓ３０３で生成した新規処理ＩＤを追加付与して、要求元の実行計算機７０に送信する。

Ｓ３１１で、処理後データ保存部１６は、実行計算機７０ａ等のプログラムＡ１２ａ等のよる所定の処理によって生成された処理後データ４１を受信し、付与された或いは追加付与された処理ＩＤ４５とともに処理後データ記録領域４０に格納させる。

他方、Ｓ３１３に進んだ場合、処理前データ収集部１５は、処理前データ記録領域３０から処理前データを収集し、Ｓ３０９の処理に進む。
以上が、データ記憶装置９０の動作の流れである。

次いで、図１７に、データ管理装置８０の処理フローを示す。
Ｓ３５１で、検索条件受信部２１が、検索要求元から所定の検索キーを含む検索要求を受信する。
Ｓ３５３で、処理後データ収集部２２は、検索キーに基づいて処理後データ格納領域４０の処理後データ４１群を検索し、検索キーに該当する処理後データを、付随する処理ＩＤ４５とともに抽出する。

Ｓ３５５で、処理履歴管理部２３は、抽出された処理後データ４１群の処理ＩＤ４５の中から最新の処理ＩＤ４５を抽出する。
Ｓ３５７で、処理履歴管理部２３は、処理ＩＤ管理表１７を取得し、Ｓ３５５で抽出した最新処理ＩＤに対応する取得要求元（プログラム名）を抽出する。

Ｓ３５９で、処理履歴管理部２３は、処理ＩＤ管理表１７において、取得要求元（プログラム名）が同一で且つＳ３５５で抽出した最新処理ＩＤよりも値の大きい処理ＩＤを抽出する。
Ｓ３６１で、処理履歴管理部２３は、Ｓ３５９で抽出した、最新処理ＩＤよりも値の大きい処理ＩＤを有する処理後データ４５を処理後データ格納領域４０から抽出する。

Ｓ３６３で、処理履歴管理部２３は、最新処理ＩＤを有する処理後データ４５と、最新処理ＩＤよりも値の大きい処理ＩＤを有する処理後データ４５とを、検索結果送信部２５を介して検索要求元に返信する。
以上がデータ管理装置８０の動作の流れである。

このように、第３実施例の計算機システム１００によれば、多段処理が行われる処理後データ４１について、所定の検索キーに対応する処理後データのうち、多段処理が行われた処理後データ及びそれ以降に多段処理が行われた処理後データを管理することができる。

〔第４実施例〕
第４実施例では、データ形式の異なるデータを格納する複数のデータソースを利用することができる構成の計算機システム１５０について説明する。計算機システムにおいて、データの種別や量を増加させる為に、外部の計算機システムで管理するデータを自計算機システムで利用できるようにすることが好ましい場合もある。

しかしながら、外部システムで管理されるデータの形式が、自計算機システムのデータ形式と異なる場合、同一の処理プログラムにより処理することができないこともある。
更には、外部システムで管理されるデータを利用することはデータ量が膨大となり、データに対するデータ取得イベント等の処理履歴を管理する負荷も増加するといえる。

そこで、第４実施例の計算機システム１５０は、データ記憶装置９０において、異なるデータ形式であっても、各処理プログラムで利用することができるデータ形式に変換する変換機能を有することを特徴の一つとする。変換機能としては、ソフトウェアとＣＰＵとの協働によりＥＴＬ（Ｅｘｔｒｕｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄ）を実現する機能部（外部システムデータ収集部１５１、データ変換部１５２、変換規則保持部１５３、変換プログラム群１５５）を有するものとする。

図１８に、計算機システム１５０の構成を示す。計算機システム１５０のデータ管理装置８０及び実行計算機７０ａ〜７０ｃは第１〜第３実施例の計算機システムと同等の機能構成を有する。データ記録装置９０に、外部システム１７０ａ、１７０ｂ等のデータを計算システム１５０で利用できるようにするデータ変換機能と、それら外部システムのデータを含めたデータの処理ＩＤを管理する機能を有する点が他の実施例と特に異なる点である。

外部システム１７０ａ及び１７０ｂは、データを格納する記憶装置を有する計算機システムであり、通信線を介してデータ記憶装置９０と通信可能になっている。夫々データ形式の異なるデータ（文字列データや画像データ等）が格納される。また、外部システム１７０ａ及び１７０ｂに格納されたデータは、処理前データ格納領域３０の処理前データ３１ａ〜３１ｃと同様に、プログラムＡ１２ａ〜Ｃ１２ｃからのデータ取得要求がなされていない処理前データである。後述するデータ記憶装置９０のデータ送受信部１５１からの要求に応じて、適当な処理前データＬ３３ａ〜Ｒ３５ｂ等をデータ記憶装置９０に送信するようになっている。

また、外部システム１７０ａ及び１７０ｃも、外部システム単位で接続先（不図示）から適宜、外部システム内に保持されるデータが更新されるようになっている。
なお、本例では、外部システムが２つの例であるが、システムの仕様に応じ、その数は任意である。

データ記憶装置９０は、外部データ収集部１５１、データ変換部１５２、変換規則保存部１５３、変換規則表１５４及び変換プログラム群１５５を新たに有する。

外部データ収集部１５１は、プログラムＡ１２ａ等から処理データ制御部１２１を介して受信したデータ取得要求に応じて、外部システム１７０ａ及び１７０ｂから要求に沿ったデータを取得するようになっている。外部システム１７０ａ及び１７０ｂは、外部データ収集部１５１からの要求に応じて自装置の記憶領域を検索し、検索結果を返信するようになっている。

データ変換部１５２は、外部システム１７０ａ及び１７０ｂから取得した処理前データＬ３３ａ等について、夫々のデータ形式に対応する変換プログラムをもって、データ形式の変換を行うようになっている。より具体的には、変換規則保持部１５３は、予めデータ形式とその変換プログラムの対応関係を示す変換規則表１５４を有し、これに応じて樹種のデータ形式に対応した変換プログラム群１５５から適当な変換プログラムを呼び出し、所定のデータ形式に変換した処理前データを生成するようになっている。データ形式の変換された処理前データＬ３３ａ等は、その後、処理ＩＤ付与部１６に保持されるようになっている。

図１９に、変換規則管理表１５４を模式的に示す。変換規則管理表１５４は、データ形式項目１６０と、変換プログラム項目１６１を有する。例えば、データ形式が「文字列」であれば、変換プログラムは「Ａ変換プログラム」であるという対応を示す。

図１８に戻り、計算機システム１５０でも、処理前データ格納領域３０から取得された処理前データＸ３１ａ等及び外部システム１７０ａ並びに１７０ｂから取得され、データ形式が変換された処理前データＬ３３ａ等は、処理ＩＤ付与部１４によって処理ＩＤ４５が付与され、処理データ制御部１２１を介して要求元のプログラムＡ１２ａ等に送信される。

また同様に、プログラムＡ１２ａ〜Ｃ１２ｃの所定の処理によって生成された処理後データ４１ａ等が、処理ＩＤ４５が付与された状態で、処理後データ格納領域４０に格納されるようになっている。図１８において、処理ＩＤ４５ｌが「１２」の処理後データ４１ｌ等は、外部システム１７０ａから取得された処理前データＬ３３a等が、処理後データとして格納されている様を示す。

以上の構成を有する計算機システム１５０の処理の流れを説明する。
図２０に、データ記憶装置９０の処理フローを示す。
Ｓ４０１で、処理データ制御部１２１は、プログラムＡ１２ａ等からデータ取得要求を受信し、処理前データ収集部１５及び外部データ収集部１５１に、要求に沿ったデータの取得要求を送信する。

Ｓ４０３で、処理前データ収集部１５は、処理前データ記録領域３０から、外部データ収集部１５１は、外部システム１７０ａ及び１７０ｂから、取得要求に沿った処理前データ（処理前データＸ３１ａ、処理前データＬ３３ａ、処理前データＱ３５ａ等）を取得する。
Ｓ４０５で、データ変換部１５２は、外部システム１７０ａ等から取得した処理前データＬ３３ａ等について、変換規則管理表１５４を参照し、夫々のデータ形式に対応する変換プログラムを変換プログラム群１５５から呼び出し、プログラムＡ１２ａ等で利用可能なデータ形式に変換する。

Ｓ４０７で、処理前データ収集部１５は、処理前データ格納領域３０から取得した処理前データ（処理前データ３１ａ等）を、データ変換部１５２は、データ形式変換後の処理前データ（処理前データＬ３３ａ等）を、夫々処理ＩＤ付与部１４に送信する。
Ｓ４０９で、処理ＩＤ付与部１６は、処理ＩＤ管理表１７を参照し、最大値（最新）の処理ＩＤを抽出して、これを１つインクリメントし（処理ＩＤが記録されて無い場合は「１」）、新規処理ＩＤを生成する。

Ｓ４１１で、処理ＩＤ保持部１３は、新規処理ＩＤと、データ取得要求元のプログラム名とを対応付けて、処理ＩＤ管理表１７の最後に新規エントリとして追加記録する。
Ｓ４１３で、処理ＩＤ付与部１６は、新規処理ＩＤを処理前データに付与して、処理データ制御部１２１を通じて要求元に送信する。
Ｓ４１５で、処理ＩＤ付与部１６は、後続する取得データが有るかをチェックし、ある場合には（Ｓ４１５：Ｙｅｓ）Ｓ４０９の処理に戻り、無い場合には（Ｓ４１５：Ｎｏ）処理を終了する。

Ｓ４１７で、処理データ制御部１２１は、プログラムＡ１２ａ等の所定の処理によって生成された処理後ＩＤ４５ａが付加された処理後データ４１ａ等を受信し、処理後データ格納領域４０に可能する。
以上が、計算機システム１５０におけるデータ記録装置９０の処理の流れである。

この後、他の実施例と同様にデータ管理装置８０よって、全てのプログラムＡ１２ａ等において整合性のある処理前データ３１から生成された処理後データ４１を、検索要求元に提供することとなる。

以上、第４実施例の計算機システム１５０によれば、自計算機システム上で利用不可能なデータ形式のデータを有する外部システムのデータを利用する構成においても、データ取得履歴等の処理履歴管理を、処理ＩＤを用いて簡便に行うことができる。
特に、プログラムＡ１２ａ等のからの共有リソースとして機能するデータ記憶装置９０に、処理ＩＤ４５を一元管理させる機能を設けることで、プログラムＡ１２ａ等に処理履歴の管理を実現する改変をする必要がない事に加え、外部システム１７０ａ等の拡張性にも柔軟且つ簡便に対応することのできる処理履歴の管理を簡便に提供できるという効果がある。

〔第５実施例〕
第４実施例の計算機システム１５０では、データ記憶装置９０は、実行計算機７０ａ（プログラムＡ１２ａ含む）等がデータ取得イベント（データ取得要求）を開始する契機で、外部システム１７０ａ等から処理前データを収集するようになっている。

ここで、データ記憶装置９０が、実行計算機７０ａ等からのデータ取得イベントの発行前に、予め外部システム１７０ａ等からデータ取得をしておけば、実行計算機７０ａ等の要求するデータへのアクセス性能（例えば、アクセス速度）は向上する。特に、実行計算機７０ａ等のデータ取得が参照のみを目的とする場合には、利便性及びシステム負荷の低減効果が向上するとも言える。

しかしながら、実行計算機７０ａ等のデータ取得要求によって処理前データを実行計算機装置７０ａに送信した後に、データ記憶装置９０の処理前データを更新すると、実行計算機７０ａ等に取得されたデータと、データ記憶装置９０の更新データとの整合性が保証できないという問題がある。即ち実行計算機７０ａが処理を開始する契機と同期して収集する以上、任意の契機で参照できる処理前データを更新することができないこととなる。 そこで、第５実施例の計算機システム２００では、データ記憶装置９０での処理前データの更新を任意の契機で実行しつつ実行計算機７０ａ等のデータ取得要求によって取得されたデータとの差分も管理することができるようになっている。

図２１に、計算機システム２００の構成を示す。計算機システム２００では、新たにデータ抽出装置２１０を有することを特徴の一つとする。
データ抽出装置２１０は、実行計算機７０ａ等からのデータ取得要求には依存せずに、例えば、スケジュール化された任意の契機で、外部システム１７０ａ及び１７０ｂから処理前データを収集（クロール）するようになっている。

また、データ記憶装置９０は、実行計算機７０ａ等からのデータ取得要求の受信を契機に、データ抽出装置２１０から予め所定のスケジュールで取得した外部システム１７０ａ等からの処理前データを取得し、これに処理ＩＤ４５を付加して要求元である実行計算機７０ａ等に処理前データを送信するようになっている。処理ＩＤ４５とデータ取得要求元を処理ＩＤ管理表１７等で管理するのは、他の実施例と同様である。
また、データ記憶装置９０は、データ抽出装置２１０における外部システム１７０ａ等からのデータ収集スケジュールを管理するようになっており、所定時刻になるとデータ記憶装置にデータ収集処理を指示する。

データ抽出装置２１０の構成を詳細に説明する。データ抽出装置は、メモリ２１１に、データ送受信部２２０、外部データ収集部１５１、データ変換部１５２、変換規則保持部１５３、変換規則表１５４、及び変換プログラム群１５５を有する。また、記憶部２３０を有し、外部システム１７０ａ等から取得したデータを格納可能となっている。

データ送受信部２２０は、データ記憶装置９０から、データ収集指示を受信し、外部データ収集部１５１に、外部システム１７０ａ等から処理前データＬ３３ａ等を収集させ、これを所定のデータ形式に変換した後、データ記憶装置９０に出力するようになっている。

外部データ収集部１５１、データ変換部１５２、変換規則保持部１５３、変換規則表１５４及び変換プログラム群１５５は、第４実施例と同様の処理を行う。データ変換部１５２は、外部データ収集部１５１によって収集された処理前データに対し、変換規則保持部１５３が保持する変換規則表１５４を参照し、処理前データのデータ形式に応じて適当な変換プログラムを変換プログラム郡１５５から呼び出し、計算機システム２００で利用可能なデータ形式に変換する。形式が変換されたデータは、適宜、データ記憶装置９０に出力される。

データ記憶装置９０は、メモリ９２に、データ収集スケジューラ２０５を新たに有する。データ収集スケジューラ２０５は、収集スケジュール管理表２０６を保持する。
図２２に、収集スケジュール管理表２０６を模式的に示す。収集スケジュール管理表２０６は、処理前データの収集先である外部システムを識別する収集先２０７、単位時間当たりのデータ収集指示の送信回数を格納する収集スケジュール項目２０８（例えば、６０分に３回）及びデータ収集処理を最後に実行したときの時刻を格納する最新収集時刻２０９の各項目を有する。収集スケジュール管理表２０６は、静的に設定されるものであり、管理端末等を介して設定変更が可能であるものとする。データ収集スケジューラ２０５は、収集スケジュール管理表２０６を参照し、適宜、データ抽出装置２１０にデータ収集指示を送信するようになっている。
なお、データ収集指示に応じてデータ抽出装置２１０から送信された処理前データは、処理前データ格納領域３０に蓄積されるようになっている。

以上の構成を有する計算機システム２００の処理の流れを説明する。
図２３に、データ抽出装置２１０の処理フローを示す。
Ｓ５０１で、データ送受信部２２０は、データ管理装置９０のデータ収集スケジューラ２０５から処理前データ収集（クロール）の指示を受け、外部データ収集部１５１にデータ収集コマンドを送信する。
Ｓ５０３で、外部データ収集部１５１は、外部システム１７０ａ〜１７０ｂから処理前データを収集し、データ変換部１５２に送信する。

Ｓ５０５で、データ変換部１５２は、データ変換規則保持部１５３の変換規則表１５４を参照し、収集したデータのデータ形式に対応する変換プログラムを変換プログラム群１５５から呼び出し、計算機システム２００で処理可能なデータ形式に変換された処理前データを生成する。
Ｓ５０７で、データ送受信部２２０は、変換後の処理前データをデータ記憶装置９０に送信する。
Ｓ５０９で、処理データ制御部１２１は、プログラムＡ１２ａ等の所定の処理によって生成された処理ＩＤ付きの処理後データを受信し、処理後データ格納領域４０に格納する。
以上が、データ抽出装置２１０の処理の流れである。

図２４に、データ記憶装置９０の処理フローを示す。
Ｓ５５１で、データ収集スケジューラ２０５は、収集スケジュール管理表２０６を取得する。
Ｓ５５３で、データ収集スケジューラ２０５は、収集スケジュール管理表２０６の各外部システムの最新更新時刻と、現在時刻との差分を夫々算出する。

Ｓ５５５で、データ収集スケジューラ２０５は、算出した差分時間の夫々について、対応する収集スケジュールよりも大である外部システムが有るか否かを判断する。大のものが有る場合には、Ｓ５５７に進み（Ｓ５５５：ＹＥＳ）、無い場合（Ｓ５５５：ＮＯ）にはＳ５５３に戻り、差分時間の管理を継続する。

Ｓ５５７で、処理データ制御部１２１は、データ抽出装置２１０のデータ送受信部２２０に対し、差分時間が収集スケジュールよりも大である外部システムに関す、データ収集指示を送付する。
Ｓ５５９で、処理データ制御部１２１は、Ｓ５５７で指定した外部システムからの処理前データについて、データ抽出装置２１０からの受信が完了するまで待機する。例えば、データ抽出装置２１０からのデータ送信完了通知を受領するまで待機する。

Ｓ５６１で、データ収集スケジューラ２０５は、データ送受信部１２０からのデータ受信完了の通知を受け、現在の時刻を最新更新時刻として、収集スケジュール管理表２０６上で該当する外部システムの項目を更新する。

なお、Ｓ５６１の処理の後、先頭のＳ５５１に戻るようにしてもよいし、収集スケジュールが最短の間隔よりも短い間隔で本処理を実行するようにしてもよい。
以上が、データ記録装置９０の収集スケジュール処理の流れである。

このようにしてデータ記録装置９０の処理前データ格納領域３０に収集されたデータ形式変換後の処理前データＬ３３ａやＱ３５ａは、第１から第４実施例と同様に、プログラムＡ１２ａのデータ取得要求に応じて適宜利用され、更に、処理ＩＤ４５に基づいて処理履歴管理が行われるようになっている。

第５実施例の計算機システム２００によれば、実行計算機７０等（プログラムＡ１２ａ等）での処理と非同期的にデータを抽出することで、実施例１〜５で示した効果に加え、複数の外部システム１７０ａ〜１７０ｂから収集できる全ての処理前データを単一のデータ記憶装置９０に格納させ、参照を可能とする効果がある。

更に、データ記憶装置９０に記憶した処理前データを、実行計算機７０ａ等（プログラムＡ１２ａ等）が収集要求する契機に関わらず任意の契機で更新することができる。

〔第６実施例〕
第１〜第５実施例の計算機システムで仮想するプログラムＡ１２ａ等には様々な種類の処理を行うものを適用することができる。プログラムの中には、コンピューティングリソースを多く使うコストの高い処理や価値の高いデータと組み合わせることで、価値の高いデータを生成する処理を行うものもある。このように、処理後データ４１ａ等毎で、生成過程に必要となったコストやその価値が異なることもある。

第６実施例では、処理ＩＤ４５と、そのデータの価値を定義する情報（例えば、データ価格等）との関連を更に定義して、処理後データ４１毎にデータ価値を更に提供できる計算機システム２５０について説明する。

図２５に、計算機システム２５０の構成を示す。計算機システム２５０は、第１実施例の計算機システム１を基調とする。相違点は、処理コスト管理表２５１を有する点と、検索要求元からの検索要求に応答する検索結果について、処理コスト管理表２５１に基づいてデータ価格を算出する処理履歴管理部２６０と、検索結果を検索要求元に提供する前に算出されたデータ価格を検索要求元に出力する検索結果２７０とを有する点である。

図２６に、処理コスト管理表２５１を模式的に示す。処理コスト管理表２５１は、所定の処理によって処理後データ４１を生成したプログラムＡ１２ａ〜Ｃ１２ｃ毎に、データの価格が定義されている情報である。計算機システム２５０の管理者等によって、予め定義されているものである。なお、定義は適宜設定変更可能である。

処理コスト管理表２５１では、プログラム名項目２５２と、処理後データ価格項目２５３とが含まれる。プログラム名項目２５２には、処理後データ４１を生成したプログラム名が登録される。データ価格項目２５３には、プログラムＡ１２ａ〜Ｃ１２ｃ毎の単位量あたりのデータ価格が登録される。単位量には、データサイズやファイル数等が設定可能であり、定額又は無料も設定できるようになっている（図において「Ｆｒｅｅ」は無料であることを示す）。

処理履歴管理部２６０では、第１実施例と同様に、先ず処理後データ格納領域４０から収集された処理後データ４１について、処理後データグループ管理表２５１が作成され、整合性ある処理前データ３1ら生成された処理後データ４１が抽出される（図８参照）。その後、処理履歴管理部２６０では、抽出された処理後データ群に対し、処理コスト管理表２５１に基づいてプログラムの種別に応じたデータ価格が算出されるようになっている。算出されたデータ価格と、処理後データ４１とは、検索結果送信部２７０に送信される。

検索結果送信部２７０では、処理後データ４１に対して価格がチェックされる。具体的には、プログラムグループのデータをチェックし、無料の場合は、そのグループに属する処理ＩＤ４５に対応する処理後データ４１を検索要求元に送信する。有料の場合は、そのグループに属する処理ＩＤ４５に対応する処理後データ４１を送信せずに、変わりにデータ価格の情報を検索要求元に出力するようになっている。

図２７に、検索要求元の画面に表示される検索結果画面３００を模式的に示す。検索結果画面３００には、検索要求元が検索条件を入力する検索キーワード入力欄３０５（「株価」、「上昇」、「銘柄」のキーワードが入力されている様を示す。）、データ価格が無料（Ｆｒｅｅ）に設定されているプログラムＢ１２ｂの検索結果を表示する無料検索結果表示欄３１０、データ価格が有料に設定されているプログラムＡ１２ａ及びＣ１２ｃのヒット件数及び価格等を表示する有料検索結果表示欄３３０が含まれる。

有料検索については、検索者によって購入ボタン３３１ａや３３１ｂが操作されることを契機に、（所定の支払い機構等（不図示）を介して決裁が行われた後）、夫々のプログラムに対応する処理後データ４１が、検索結果送信２７０から送信され、表示されるようになっている。

以上の構成を有するデータ管理部２０の処理の流れを説明する。
図２８に、データ管理部２０の処理フローを示す。
Ｓ６０１で、処理後データ収集部２２は、入出力装置５等を介して検索条件受信部２１に入力された検索要求に対し、処理後データ格納領域４０から、条件に一致する処理後データ４１を、付随する処理ＩＤとともに収集する。

Ｓ６０３で、処理履歴管理部２６０は、処理ＩＤ管理表１７を参照し、処理を実行したプログラムＡ１２ａ〜Ｃ１２ｃ毎に、処理後データ４１をグループ化して管理し、そのグループ毎に最新（最大）の処理ＩＤ４５を抽出する。

Ｓ６０５で、処理履歴管理部２６０は、各グループで抽出された最新処理ＩＤ４５のうち、各グループ間で最も古い（最小値）処理ＩＤを全処理完了ＩＤ５５として取得する。 Ｓ６０７で、処理履歴管理部２６０は、全処理完了ＩＤ５５よりも新しい（大きい）処理ＩＤ４５を収集データから除去し、その結果を中間状態除去後ＩＤ一覧項目５２に記録し、検索結果送信部２２に送信する。

Ｓ６０９で、処理履歴管理部２６０は、処理コスト管理表２５１を参照し、グループ毎にデータ価格を算出する。具体的には、処理後データグループ管理表２４の中間状態除去後ＩＤ一覧項目５２に属する処理ＩＤ４５を有する処理後データ４１について、グループ毎にデータ価格を求める。

Ｓ６１１で、処理履歴管理部２６０は、各グループが有料であるのか無料であるのかをチェックし、無料である場合には、無料のグループを検索結果送信部２７０に通知する。検索結果送信部２７０は、通知を受けた無料のグループについて、中間状態除去後ＩＤ項目５２に記録された処理ＩＤに対応する処理後データ４１を検索要求元に送信する（Ｓ６１９）。

Ｓ６１３で、処理履歴管理部２６０は、有料のグループについて、データの価格を示す価格データを検索結果送信部２７０に送信させる。
Ｓ６１５で、検索結果送信部２７０は、検索要求元から有料プログラムの処理後データの購入要求の受信があるか否かを判断し、購入要求を受信した場合には、購入対象の有料プログラムのグループの中間状態除去後ＩＤ一覧項目５２に属する処理ＩＤ４５の処理後データ４１を検索要求元に送信する。
以上が、データ管理部２０の処理の流れである。

第６実施例の計算機システム２５０によれば、処理後データの価格管理により、処理後データをその処理履歴ごとの価格を設定することができる。

以上、本発明を適用した実施例を説明したが、本発明はこれらの実施例に限定されるものではなく、その趣旨を逸脱することなく、種々の変更が可能である。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。

また、上記の各構成、機能、処理部等は、それらの一部又は全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。

なお、各実施例を実現するプログラム、テーブル及びファイル等の情報は、磁気的・電子的な記録媒体に格納することができる。

１、６０、１００、１５０、２００、２５０ 計算機システム
１０ データ処理部
１３ 処理ＩＤ保持部
１４ 処理ＩＤ付与部
１７ 処理ＩＤ管理表
２０ データ管理部
３０ 処理前データ格納領域
３１ 処理前データ
４０ 処理後データ格納領域
４１ 処理後データ
４５ 処理ＩＤ
７０ 実行計算機
８０ データ管理装置
９０ データ記録装置
１１７ 多段処理ＩＤ管理表
１５１ 外部データ収集部
１５２ データ変換部
１５３ 変換規則保持部
１５４ 変換規則表
２５１ 処理コスト管理表

Claims (14)

1. 処理前データを取得して所定の処理を実行し、その処理の結果として処理後データを生成する複数の処理部と、
   前記複数の処理部の各々によって前記処理前データが取得される契機に、その取得の順序性を示し且つ前記複数の処理部の所定の処理の前後で更新されない処理ＩＤを、取得される処理前データに付与し、前記処理部の所定の処理によって生成された処理後データを記憶装置に格納させるデータ処理部と
   所定のデータ検索条件を受信し、前記記憶装置に格納された処理後データを抽出する際、前記データ検索条件を満たす処理後データのうち、処理部毎の処理後データ間で最新であって、各処理部間で最古となる処理ＩＤ以前の処理ＩＤを有する処理後データを抽出し、検索要求元に出力するデータ管理部と、
   を有する計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記データ処理部は、前記各処理部が処理前データを取得する度に、テーブル上で前記処理ＩＤを昇順若しくは降順に管理する計算機システム。
3. 請求項１に記載の計算機システムであって、
   前記処理ＩＤは、前記処理部が前記処理前データを取得した時刻を示す情報である計算機システム。
4. 請求項１の計算機システムであって、前記処理ＩＤは、処理前データを取得した前記複数の処理部の識別情報と対応付けて管理する計算機システム。
5. 請求項１の計算機システムであって、
   前記複数の処理部の依存関係を示す依存関係情報を更に有し、
   前記データ管理部は、前記検索条件を満たす処理後データのうち、前記依存関係情報に基づいて、依存関係にある処理部毎の処理後データ間で最新であって、各処理部間で最古となる処理ＩＤ以前の処理ＩＤを有する処理後データを抽出する計算機システム。
6. 請求項１の計算機システムであって、
   前記複数の処理部毎に、生成する処理後データの価値を示す情報を定義する価値管理情報を更に有し、
   前記データ管理部は、価値管理情報参照し、抽出した処理後データの価値情報を生成し、価値が一定値以下の処理後データを前記検索要求元に出力し、価値が一定値より大きい処理後データは前記生成した価値情報を前記検索要求元に出力する計算機システム。
7. 請求項６に記載の計算機システムであって、
   前記データ管理部は、前記価値情報を出力した処理後データに対する取得要求を前記検索要求元から受信し、価値情報に対応する処理後データを検索要求元に送信する計算機システム。
8. 請求項６又は７に記載の計算機システムであって、
   前記価値管理情報が定義するデータの価値を示す情報は、単位データ量あたりの価格である計算機システム。
9. 請求項１に記載の計算機システムであって、
   前記複数の処理部の夫々を稼動させる実行計算機と、
   前記データ処理部を稼動させる計算機と、
   前記データ管理部を稼動させる計算機と、
   が通信可能に接続されてなる計算機システム。
10. 請求項１に記載の計算機システムであって、
    前記複数の処理部が取得する処理前データを格納する記憶部を有するデータ記憶計算機を更に備え、
    前記データ記憶計算機は、
    前記複数の処理部が処理前データの取得をする場合、通信線で接続された外部計算機に格納された処理前データを取得し、前記記憶部に格納する外部データ取得部を有する計算機システム。
11. 請求項１０に記載の計算機システムであって、
    前記データ記憶計算機は、前記外部計算機から取得する処理前データを、前記計算機システムで利用可能なデータ形式に変換するデータ形式変換部を更に有する計算機システム。
12. 請求項１１に記載の計算機システムであって、
    前記複数の処理部が前記データ記憶計算機の記憶部に格納された処理前データを取得するタイミングが前記処理部毎に定義されたデータ取得スケジュール情報を更に有し、
    前記データ処理部は、前記データ取得スケジュール情報に基づいて、前記複数の処理部に前記処理前データを取得させる計算機システム。
13. 処理前データを取得して所定の処理を実行し、その処理の結果として処理後データを生成する複数の処理部を有し、前記処理後データに対する検索要求に対し検索結果を送信する計算機システムのデータ管理方法であって、
    前記計算機システムは、
    前記複数の処理部の各々によって前記処理前データが取得される契機に、その取得の順序性を示し且つ前記複数の処理部の所定の処理の前後で更新されない処理ＩＤを、取得される処理前データに付与し、前記処理部の所定の処理によって生成された処理後データを記憶装置に格納し、
    前記検索要求に含まれる検索条件に基づいて、前記記憶装置に格納された処理後データを抽出する際、前記検索条件を満たす処理後データのうち、処理部毎の処理後データ間で最新であって、各処理部間で最古となる処理ＩＤ以前の処理ＩＤを有する処理後データを抽出し、検索要求元に出力する
    データ管理方法。
14. 処理前データを取得して所定の処理を実行し、その処理の結果として処理後データを生成する複数の処理部をする計算機システムに実行させるプログラムを格納する非一時的な記録媒体であって、
    前記複数の処理部の各々によって前記処理前データが取得される契機に、その取得の順序性を示し且つ前記複数の処理部の所定の処理の前後で更新されない処理ＩＤを、取得される処理前データに付与させ、前記処理部の所定の処理によって生成された処理後データを記憶装置に格納させる手順と、
    所定の検索条件の受信時に、前記記憶装置に格納された処理後データを抽出する際、前記検索条件を満たす処理後データのうち、処理部毎の処理後データ間で最新であって、各処理部間で最古となる処理ＩＤ以前の処理ＩＤを有する処理後データを抽出させ、検索要求元に出力させる手順と、
    を実行させるプログラムを格納するコンピュータが読み取り可能である非一時的な記録媒体。

Images