(57)【特許請求の範囲】
【請求項１】
プログラムされたコンピュータ処理により、記憶装置に記憶した同一データファイル（共用データファイル）を複数のユーザそれぞれに専用の複数のデータファイルとして利用させるファイル管理制御システムであって、
プログラムされたコンピュータ処理を実行する手段として、
上記共用データファイルに実データを登録する際、該実データを登録するユーザが入力した、自ユーザの識別情報（ユーザＩＤ）を少なくとも含む、当該実データを当該ユーザ専用のデータファイルの実データとして利用する対象として選択するための条件情報（選択条件情報）を当該実データに付与する第１の手段と、
上記複数のユーザが、上記共用データファイルの各実データにアクセスする際、当該ユーザからの上記選択条件情報の上記ユーザＩＤを含むいずれかを指定する入力情報に従って、指定された選択条件情報が付与された各実データを上記共用データファイルから読み出し、読み出した各実データのみを登録した当該ユーザ専用のデータファイル（仮想データファイル）を作成する第２の手段と、
上記仮想データファイルの実データおよび上記共用データファイルの実データに対するアクセスを、上記選択条件情報に従って実行する第３の手段と
を有することを特徴とするファイル管理制御システム。
【請求項２】
請求項１に記載のファイル管理制御システムであって、
上記第３の手段は、
上記ユーザにより上記仮想データファイルのデータに対する更新がなされると、当該データの更新内容を上記共用データファイルの当該データに反映させる
ことを特徴とするファイル管理制御システム。
【請求項３】
請求項１もしくは請求項２のいずれかに記載のファイル管理制御システムであって、
上記選択条件情報は、データ照会操作の際に、上記共用データファイルと上記仮想データファイルのいずれをもしくは両方を利用するかを示す照会情報を含み、
上記第３の手段は、
上記ユーザが上記仮想データファイルのデータを参照する際に指定した上記参照情報に従って、上記仮想データファイルと上記共用データファイルのいずれかを、もしくは両方を、照会の対象として選択する
ことを特徴とするファイル管理制御システム。
【請求項４】
請求項１から請求項３のいずれかに記載のファイル管理制御システムであって、
上記選択条件情報は、ダンプ処理とリロード処理の対象データであるか否かを示す再編成情報を含み、
上記第３の手段は、
上記ユーザからのリクエストもしくは予め定められた周期で上記ダンプ処理とリロード処理のいずれかもしくは両方を実行する際に、上記選択条件情報に含まれる再編成情報に従って、実行対象のデータを選択する
ことを特徴とするファイル管理制御システム。
【請求項５】
請求項１から請求項４のいずれかに記載のファイル管理制御システムであって、
上記選択条件情報は、
当該データのユーザ間での流用可否を表す流用フラグ情報と、
アクセス可能な日時を表す更新日時情報と、
上記共用データファイルへのアクセス制御に用いるテストフラグ情報と、
ケース番号に基づくアクセス対象のデータ群の特定に用いるケースＮＯ情報と
を含み、
上記第２の手段は、
上記ケースＮＯ情報に従って、自ユーザＩＤのデータから特定のデータのみを選択して上記仮想データファイルを作成し、
上記流用フラグ情報に従って、上記共用データファイルにおける他ユーザのデータの上記仮想データファイルへの流用を実行し、
上記第３の手段は、
上記更新日時情報に従って、上記共用データファイルおよび上記仮想データファイルへのアクセス可否を判別し、
上記テストフラグ情報に従って、上記共用データファイルのデータおよび上記仮想データファイルのデータのアクセス制御を実行する
ことを特徴とするファイル管理制御システム。
【請求項６】
プログラムされたコンピュータ処理により、記憶装置に記憶した同一データファイル（共用データファイル）を複数のユーザそれぞれに専用の複数のデータファイルとして利用させるコンピュータシステムによるファイル管理制御方法であって、
プログラムされたコンピュータ処理を実行する手段として、請求項１から請求項５のいずれかに記載のファイル管理制御システムにおける各手段が実行する手順を含み、
該各手段のプログラムされたコンピュータ処理により、上記仮想データファイルの生成と該仮想データファイルのデータおよび上記共用データファイルのデータへの処理を行うことを特徴とするファイル管理制御方法。
【請求項７】
コンピュータを、請求項１から請求項５のいずれかに記載のファイル管理制御システムにおける各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ化されたシステムにおけるデータファイルの更新・照会方法およびそれを管理するシステム、ならびにそのプログラムに関し、特に、様々なデータ様式を持つ共用データファイルの更新・照会・管理を、複数のユーザが、自分専用にも共用にも両面で効率よく実施するのに好適なデータファイルのバーチャル更新・照会方法、およびシステム、ならびにそのプログラムに関する。
【背景技術】
【０００２】
従来のファイル管理システムや、共用ファイルのデータ更新方法や、仮想ファイルの入出力制御方法等は、ネットワーク上の複数のファイル更新情報を相互に転送してファイル間の同一性を保持するシステムであった。また、例えば、特開平６−５９９５３号公報（仮想ファイル入出力制御方法）（特許文献１参照）に示すように、複数媒体にまたがる大型ファイルを分類・分割して複数の独立したファイルを作成し、仮想ファイル概念を用いて、１つの大きなファイルとして扱ったり、個別の小さなファイルとして扱うことを可能にする方法もあった。
【０００３】
さらに、例えば特開平６−１９７７０号公報（共有ファイルのデータ更新処理方法）（特許文献２参照）に示すように、データの更新順序に保障が必要な共用ファイルの更新処理を、複数のアクセス元が共同して実行する際に、他のアクセス元の処理進捗状況を意識することなく、効率的に実行するために、共有ファイル内の更新アクセス対象データが未処理のとき以外は更新データを読み飛ばし、処理が可能な更新データのみを実行させるようにする読み飛ばし管理機構を設けて、更新データの処理ごとにデータ管理機構に処理状況を問い合わせ、共有ファイル内の更新アクセス対象データが更新処理中、あるいは更新処理済のときには、処理しようとしていた更新データを読み飛ばし、次の更新データの処理に移るようにする方法がある。
【０００４】
しかし、これらの方法は、１つの共用データファイルを利用して、共用データとユーザ独自データと併せることで、他のユーザに影響を与えることなく、ユーザ独自の業務が効率よく行える技術ではなかった。
【０００５】
【特許文献１】特開平６−５９９５３号公報
【特許文献２】特開平６−１９７７０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来においては、共用データとユーザ独自データを併せて多方面の検証を実施したり、あるいは、独自予算を立てたり、あるいは、独自シミュレーションを行ったりしたいというニーズはあったが、共用データファイルは、通常使用権限を保持する人全員がデータの更新・照会が可能であり、ユーザ独自のデータを更新・追加することはできなかった。
共用データファイルを使用して、ユーザ独自データを共用データファイルに更新するためには、共用データファイルを自分専用の別リソースへコピー作成してから、独自データを更新する必要があり、そのため、リソース確保の面からも、処理時間（更新・検証前のコピー作成と、更新後のファイル削除等）の面からも、実現が困難であった。
【０００７】
（目的）
本発明の目的は、上記課題を解決し、共用データファイルを利用して、共用データとユーザ独自データを併せて、ユーザ独自業務処理を他のユーザに影響を与えることなく、効率よく実現することができるデータファイルのバーチャル更新・照会方法、およびシステム、ならびにそのプログラムを提供することである。
【課題を解決するための手段】
【０００８】
本発明のデータファイルのバーチャル更新・照会方法では、通常データ項目の他に、ユーザ識別ＮＯ．テストフラグ・ケースＮＯ．流用フラグ等の選択条件情報（選択条件情報が、データをグループ分けするキーとなる）を併せて保持し、更新時は全ユーザの全データ（ユーザ独自データ・共用データ）で共用データファイルを更新する。データファイル照会時に選択条件情報（グループ分けキー）の指定要領により、共用データファイルから自分専用のデータのみを照会することも、共用全データを照会することもできる。また、共用データファイルを、全ユーザの全データで更新することで、データベースにおけるデータの不整合を避けることが可能となるため、共用データファイルの形式にはとらわれない運用が可能になる。
【０００９】
すなわち、本発明の更新・照会方法では、共用データファイル様式は、必要なデータ項目と、データ選択条件項目を併せて保持し、登録・更新時は共用データだけでなく、常に全ユーザの全データ（ユーザ独自データを含む）で、共用データファイルが登録・更新される。
また、共用データファイルを常にタイムリーに、全ユーザの全データで更新することにより、データベースにおける登録・更新時に実施される整合性チェックをタイムリーに実施できるので、データの不整合を避けることが可能となる。
【発明の効果】
【００１０】
本発明によれば、データファイル様式にはとらわれない、膨大な共用データを利用して、自分専用業務を効率よく、他のユーザに影響を及ぼすことなく、実施することが可能となる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施例を、図面により説明する。
図１は、本発明の一実施例に係るデータファイルのバーチャル更新・照会システムの全体構成図である。
データファイルのバーチャル更新・照会システム１１５は、ネットワーク１０４で接続されたホストシステム１０１，１０２およびサーバシステム１０３からなるＰＣグループからのデータ登録・更新・照会のリクエストにより、共用データファイル（実データファイル１１１）に共用・ユーザ独自のデータ登録・更新・照会を行う。
【００１２】
ホストシステム１０１のオンラインログイン時、サーバシステム１０３のログイン時、ホストシステム１０２よりのログイン時に、ユーザ情報と併せて選択条件を入力してもらい、ログインにより選択条件の確定処理部１０５で選択条件を確定する。また、ログインにより選択条件の確定処理部１０５のバッチ処理のファイルオープン時、サーバシステム１０３のファイルオープン時のリクエストで、選択条件を入力してもらい、ＯＰＥＮ／ＣＬＯＳＥのリクエストによる選択条件の確定処理部１０６で選択条件を確定する。
【００１３】
選択条件確定後は、ホストシステム１０１，１０２またはサーバシステム１０３の各ＰＣからのデータファイルの更新／照会を、リクエスト受付部１０７で受けて、リクエストの内容によりデータ更新／照会処理部１０９またはデータ再編成処理部１１０にて実際のデータファイル処理を実施する。
また、実データファイル１１１は、データの保存場所が対象範囲のシステム１１２に示す通り、サーバ１０３でもホスト１０１，１０２でもネットワーク１０４で接続され、使用可能な状態であれば、何処でも問題なく行える。
なお、仮想データファイル（１〜ｎ）１０８のデータ様式と、実データファイル１１１の様式の詳細については、後述する（図６を参照されたい）。
【００１４】
図２は、入力された選択条件により選択条件テーブルの作成要領を決定する方法の動作フローチャートである。
ログインにより選択条件の確定処理部１０５、および、ＯＰＥＮ／ＣＬＯＳＥのリクエストリクエストによる選択条件の確定処理部１０６は、処理が開始された後、データファイルの再編成処理であるか否かを判定し（ステップ２０１）、そうであれば、再編成処理時のデータ照会／更新条件の確定を行い（ステップ２０３）、また、そうでなければ、通常処理時のデータ照会／更新処理の確定を行う（ステップ２０２）。なお、通常処理時のデータ照会／更新条件の確定の詳細については、図３により説明するとともに、再編成処理時のデータ照会／更新条件の確定の詳細については、図７により説明する。
【００１５】
図３は、図２における通常処理時のデータ照会／更新条件の確定（条件テーブルの作成）を行う動作フローチャートである。
ステップ３００では、ログイン時に、ユーザ識別情報／使用権限を表すパスワードと、共用データファイルからデータを選択するための選択条件を指示する。選択条件には、本番用／テスト用区分を表すテストフラグと、同一ユーザでもデータを別管理したいケースに使用するケースＮＯ．と、ユーザ間でデータの流用可否を表す流用フラグと、データの更新日・更新時間と、同一キーの存在を制御するファイル区分がある（図３の右欄参照）。
【００１６】
データの選択条件は、全て入力任意項目であり、入力された選択条件が組み合わされて、最終的な選択条件が確定される。入力後は、ステップ３０１で、入力されたユーザ識別情報／パスワードの妥当性（マスタ登録状況・有効期限）がチェックされ、ＮＧの時は再度ログインを実施することになる。ＯＫのときは、ステップ３０２で、処理区分のチェックを行い、区分未設定ならばＯＫ、それ以外ならばＮＧとなる。ＮＧのときは、再度ログインを実施することになる。ＯＫのときは、ステップ３０３〜３０９で選択条件の妥当性がチェックされる。ステップ３０３のテストフラグは、未設定（入力なし）または設定（＋または＊）ならばＯＫ、それ以外ならばＮＧである。ステップ３０４のケースＮＯ．は、未設定（入力なし）または設定（入力任意３桁×××）ならばＯＫ、それ以外ならばＮＧである。
【００１７】
ステップ３０６の流用フラグは、未設定（入力なし）または設定（＊）ならばＯＫ、それ以外ならばＮＧである。ステップ３０７の更新日は、未設定（入力なし）または設定（年月の範囲（ＹＹＹＹＭＭ〜ＹＹＹＹＭＭ）または年月または年月日範囲（ＹＹＹＹＭＭＤＤ〜ＹＹＹＹＭＭＤＤ）または年月日）ならばＯＫ、それ以外ならばＮＧである。
ステップ３０８の更新時間は、未設定（入力なし）または設定（時間の範囲（ＨＨＭＭ〜ＨＨＭＭ）または時間（ＨＨＭＭ）ならばＯＫ、それ以外ならばＮＧである。ステップ３０９のファイル区分は、０または１ならばＯＫ、それ以外ならばＮＧである。
【００１８】
ステップ３０３〜３０９の選択条件チェック後に、ステップ３１０のエラー有無チェックを行い、１項目でもエラーがあれば、ステップ３００のログインを再度行い、正しい選択条件を入力する。テストフラグ以外の選択条件は、テストフラグ未設定時（本番データ選択）に指示された時は、無視される。選択条件にエラーがない時は、ステップ３１１で本番モードか否かの判定処理を行い、テストフラグ未設定の時は、通常処理の本番用データ選択／更新条件の確定処理（選択条件テーブルの作成−図４）を行い、テストフラグ設定済みの時は、通常処理のテスト用データ選択／更新条件の確定処理（選択条件テーブルの作成−図５）を行う。
【００１９】
図４は、テストフラグ未設定時の通常処理の本番用選択条件の確定要領を示す図である。
選択条件の確定処理は、ログイン時に指定された選択条件より、データの選択条件テーブルを作成することにより確定する。図４の左半分が、ログイン時にリクエストユーザにより設定された選択条件オプションの内容を表す。右半分は、指示された選択条件オプションにより、作成される選択条件テーブルの内容を表す。
【００２０】
選択条件オプションの設定内容により作成される選択条件は、複数作成されるケースがあるが、本番モードで作成される選択条件は、常に本番全データ対象を選択する選択条件１個のみが作成される。テストフラグ未設定時は、本番モードのため、本番全データのみの選択となり、選択条件テーブルのテストフラグを始めとする各選択項目には全てスペースがセットされた選択条件１個のみが作成される。すなわち、テストフラグ未設定でログインすると本番モードとなり、流用フラグ／ケースＮＯ．／更新日／更新時間等のテストモードでのみ有効な選択オプションは、全て無視されることになる。この場合、たとえ指定しても、無視することになる。
【００２１】
図５は、テストフラグ設定時の通常処理のテスト用選択条件の確定要領を示す図である。
ログイン時に指定された選択オプションにより、作成される選択条件の個数は変わる。
選択条件の見方は、選択条件の縦行（例えば、５）−１）と５）−２））がＯＲ条件、確定された選択条件テーブルの横列（例えば、テストフラグ、ユーザＩＤ〜更新時間）がＡＮＤ条件となる。従って、ログイン時の選択オプションのテストフラグ＝＊、流用フラグ＝＊、ケースＮＯ．・更新日・更新時間＝未定の条件を指定した場合の選択条件は、５）−１）または５）−２）を満足するデータのみが選択されることになる。
【００２２】
ログイン時の選択オプションによる選択条件の組合わせは、図５の１６通りとなる。
テストフラグ設定時のテストモード時は、選択オプションのテストフラグの設定如何で、本番データとテストデータの選択条件が確定する。選択オプションの『テストフラグ＝＊』設定時は、テストデータ（テストフラグ設定されたデータ）だけが選択され、選択オプションの『テストフラグ＝＋』設定時は、テストデータと本番データ（テストフラグ未設定のデータ）を併せて選択することができる。
ただし、本番データは、常に全データが選択され、更新日等で本番データの選択はできない。本番データの部分選択を不可とした理由は、本番データ選択条件設定不備が原因であり、本番データに漏れが発生して、漏れによる二次的な事故を防ぐために、本番データは全選択とした。
【００２３】
選択オプションの流用フラグ（テストデータについてのみ有効）については、流用フラグ未設定時は同じユーザＩＤのテストデータのみが選択され、流用フラグ設定時（フラグ＝＊）は、同じユーザＩＤのテストデータと流用フラグの設定された他のユーザＩＤのテストデータも併せて選択される。ただし、このケースは同じユーザＩＤのデータは、流用フラグの設定に関係なく選択されるが、他のユーザＩＤのデータは流用フラグ設定のデータのみが選択対象となる。選択オプションのケースＮＯ．（同じユーザＩＤを持つ、テストデータについてのみ有効）設定時は、同じユーザＩＤのテストデータの中から、同じケースＮＯ．を持つテストデータのみが選択される。ケースＮＯ．は、他のユーザＩＤを持つテストデータには無効である。従って、ケースＮＯ．の採番方法はユーザ独自で設定する。選択オプションの更新日（テストデータについてのみ有効）は、単独の設定だけでなく、範囲での設定も可能である。
【００２４】
また、更新日の様式は、年月日（ＹＹＹＹＭＭＤＤ）・年月（ＹＹＹＹＭＭ）から選択できる。選択オプションの更新日は、テストデータの全ユーザＩＤのデータに対して有効であるが、自分のユーザＩＤだけ、または、他のユーザＩＤだけに、適用することはできない。
選択オプションの更新時間（テストデータについてのみ有効）は、単独の設定だけでなく、範囲での設定も可能である。時間の様式は、時分（ＨＨＭＭ）となる。選択オプションの更新時間は、テストデータの全ユーザＩＤのデータに対して有効であるが、自分のユーザＩＤだけ、または、他のユーザＩＤだけに適用することはできない。
選択オプションの指定は、テストフラグは必須（設定：＊または、＋、未設定）であるが、テストフラグ以外の選択オプションは、任意の指定となる。
【００２５】
図６は、実データファイルの様式と、仮想データファイルの様式の関係を示す図である。
実データファイル１１１には、仮想データファイル１０８にはないデータ選択条件項目が付加される。仮想データファイル１０８の様式が、システム上のプログラムやパラメータや、他で扱う論理データファイルのデータ様式と同じになる。実データファイル１１１上のデータ選択条件は、図３で説明したステップ３１２の本番用データ選択／更新条件の確定、および、ステップ３１３のテスト用データ選択／更新条件の確定（確定処理の詳細説明は、図４、図５を参照されたい）で作成されたものであり、ログイン時やファイルのＯＰＥＮ／ＣＬＯＳＥ時に指定された選択オプションより作成された本選択条件と、実データファイル１１１上のデータ選択条件の比較を行い、合致するデータ選択条件を持つ実データのみを、実データファイル１１１より選択して、本情報リクエストユーザにデータ選択条件を除いた仮想データファイル１０８の様式で渡すことになる。
【００２６】
これにより、リクエストユーザは、欲しい情報のみを選択することが可能となる。
対象ファイルがデータベースの形式の場合には、実データファイル１１１の中の『データ選択条件』の各項目よりインデックスを作成することにより、データの読込み／書出しのレスポンスの向上を図ることが可能となる。対象ファイルがデータベース以外の場合には、『データ選択条件』は、単純な項目として保持することになる。『データ選択条件』の各項目の簡単な説明を行うと、下記８項目となる。
【００２７】
１）テストフラグ：本番用データ（フラグ設定なし）か、テスト用データ（フラグ＝＊）かを表示。
２）流用フラグ：他ユーザが作成したテストデータを流用可能（フラグ＝＊）か、否（フラグ設定なし）かを表示。
３）ケースＮＯ．：同じユーザでも、テストケースを種々作成して検証する必要性が発生する。ケースＮＯ．を指定することで、必要なテストデータのみを選択し検証する。テストデータのみに設定可能。
４）ユーザＩＤ：テストデータを作成したユーザのＩＤ（データ所有者を表す）を表示。
従って、本番用データには、所有者がいないので、選択条件中のユーザＩＤは設定されない。
【００２８】
５）更新日：データの作成・更新を行った日（・ＹＹＹＹＭＭＤＤ、・ＹＹＹＹＭＭ、・未設定の選択可能）。
６）更新時間：データの作成・更新を行った時間（・ＨＨＭＭ、・未設定の選択が可能）。
７）ファイル区分：データファイル中に、同一キーの存在を許す（区分＝１）か、否（区分＝０）を表示。
８）削除区分：データの削除リクエストがあった時に、データ自身を削除（区分＝０）するか、削除フラグを設定（区分＝１）するかを表示。
【００２９】
図７は、共用データファイルを再編成するためのログイン時の処理フローチャートである。
図１のデータ再編成処理部１１０が実施する再編成とは、ダンプ処理（別ファイルへ全点、出力）と、フォーマッティング処理（データファイルエリア内のデータ消去）と、リロード処理（別ファイルへ出力したファイルより、必要なデータのみを選択して、データファイルへ書込み）の処理からなる。データファイルがデータベースの時は、本処理によりデータの最適化がなされ、入出力レスポンスの工場が図られる。
ステップ７０１のログイン時には、ユーザ識別情報／使用権限を表すパスワードと、共用データファイルを再編成するための選択条件を指示する。選択条件には、データファイルを再編成するための処理区分（ダンプのみ、リロードのみ、ダンプとリロード）と、本番用／テスト用区分を表すテストフラグと、同一ユーザでもデータを別管理したいケースに使用するケースＮＯ．と、データの更新日とがある。
【００３０】
データの選択条件は全て入力任意項目であり、入力された選択条件が組み合わされて、最終的な選択条件が確定される。
入力後は、ステップ７０２で入力されたユーザ識別情報／パスワードの妥当性（マスタ登録状況・有効期限）がチェックされ、ＮＧの時は再度ログインを実施することになる。
ＯＫの時は、選択条件の妥当性がチェックされる。選択条件の妥当性の最初のチェックは、ステップ７０３の処理区分チェックである。この区分により、再編成するためのどの処理を実施するのかを指示する。処理の区分は、データファイルのダンプ処理（Ｄ）のみと、リロード処理（Ｒ）のみと、ダンプ処理とリロード処理（Ｄ＆Ｒ）を併せて実施することができる。従って、処理区分は設定（ＤまたはＲまたはＤ＆Ｒ）ならばＯＫ、それ以外ならばＮＧである。
ステップ７０５のテストフラグチェックは、未設定（入力なし）または設定（＋または＊）ならばＯＫ、それ以外ならばＮＧである。
【００３１】
ステップ７０７の更新日は、未設定（入力なし）または設定（年月の範囲（ＹＹＹＹＭＭ〜ＹＹＹＹＭＭ）または年月または年月日範囲（ＹＹＹＹＭＭＤＤ〜ＹＹＹＹＭＭＤＤ）または年月日）ならばＯＫ、それ以外ならばＮＧである。
ステップ７０８のファイル区分チェックは、０または１ならばＯＫ、それ以外ならばＮＧである。ステップ７０９の保存日数は、日数＝数字ならばＯＫ、それ以外ならばＮＧである。ステップ７０５〜７０９の選択条件チェック後に、ステップ７１０のエラー有無チェックを行い、１項目でもエラーがあれば、ステップ７１４のログイン選択条件エラーを表示した後、ステップ７０１のログインを再度行い、正しい選択条件を入力する。
テストフラグ以外の選択条件は、テストフラグ未設定時（本番データ選択）に指示された時は無視される。ステップ７１０の選択条件にエラーがない時は、ステップ７１１の本番モードかの判定処理を行い、テストフラグ未設定の時は、ステップ７１２の再編成処理の本番用データ選択／更新条件の確定処理（選択条件テーブルの作成ー図８参照）を行い、テストフラグ設定済みの時は、ステップ７１３の再編成処理のテスト用データ選択／更新条件の確定処理（選択条件テーブルの作成ー図９参照）を行う。
【００３２】
選択条件の確定処理は、ログイン時に指定された選択条件より、データの選択条件テーブルを作成するで確定する。
図８は、テストフラグ未設定時の再編成処理の本番用選択条件の確定要領を示す図である。
テストフラグ未設定時は、本番モードのため本番全データのみの選択となり、選択条件テーブルのテストフラグを始めとする各選択項目には全てスペースがセットされた選択条件１個のみが作成される。なお、テストフラグ以外の項目は、指定しても無視される。
【００３３】
図９は、テストフラグ設定時の再編成処理のテスト用選択条件の確定要領を示す図である。
指定された選択条件により、作成される選択条件テーブルの個数は変わる。また、テストフラグの値により、選択条件が変わる。テストフラグ＝＊の時は、テストデータのみが選択され、テストフラグ＝＋の時は、テストデータと併せて本番データも選択される。従って、ログイン時に入力された選択条件内容により、選択条件が複数作成される可能性がある。なお、図８、図９の見方や作成要領の詳細については、図４、図５の説明を参照されたい。
【００３４】
図１０は、ＯＰＥＮ／ＣＬＯＳＥのリクエスト時のデータ照会／更新条件の確定（条件テーブルの作成）を行う手順を示すフローチャートである。
ステップ１００１のリクエストは、ファイルのＯＰＥＮか、またはＣＬＯＳＥかを判定する。ＣＬＯＳＥ時は、ステップ１０１５でデータファイルのクローズ処理を行う。ＯＰＥＮ時は、指示された選択条件より、データファイルの更新／照会時に使用する選択条件テーブルを作成する。作成要領は、ユーザのログイン時に作成する選択条件テーブルの作成要領と同じである。
【００３５】
選択条件には、本番用／テスト用区分を表すテストフラグと、同一ユーザでもデータを別管理したいケースに使用するケースＮＯ．と、ユーザ間でデータの流用可否を表す流用フラグと、データの更新日・更新時間と、同一キーの存在を制御するファイル区分がある。
データの選択条件は全て入力任意項目であり、入力された選択条件が組み合わされて、最終的な選択条件が確定される。
ステップ１００２のテストフラグ・チェックは、未設定（入力なし）または設定（＋または＊）ならばＯＫ、それ以外ならばＮＧである。ステップ１００４のケースＮＯ．チェックは、未設定（入力なし）または設定（入力任意３桁）ならばＯＫ、それ以外ならばＮＧである。ステップ１００５の流用フラグ・チェックは、未設定（入力なし）または設定（＊）ならばＯＫ、それ以外ならばＮＧである。ステップ１００６の更新日チェックは、未設定（入力なし）または設定（年月の範囲（ＹＹＹＹＭＭ〜ＹＹＹＹＭＭ）または、年月日または年月日範囲（ＹＹＹＹＭＭＤＤ〜ＹＹＹＹＭＭＤＤ）または年月日）ならばＯＫ、それ以外ならばＮＧである。
【００３６】
ステップ１００７の更新時間チェックは、未設定（入力なし）または設定（時間の範囲（ＨＨＭＭ〜ＨＨＭＭ）または時間（ＨＨＭＭ）ならばＯＫ、それ以外ならばＮＧである。
ステップ１００８のファイル区分チェックは、０または１ならばＯＫ、それ以外ならばＮＧである。ステップ１００２〜１００８の選択条件チェック後に、ステップ１００９のエラー有無チェックを行い、１項目でもエラーがあれば、ステップ１０１３でＯＰＥＮ選択条件指定エラーを表示して終了する。エラーが１件もなかった時には、ステップ１０１０の本番モードか否かの判定処理を行い、テストフラグ未設定の時には、ステップ１０１１の通常処理の本番分データ選択／更新条件の確定処理（選択条件テーブルの作成−図４）を行い、テストフラグ設定済みの時には、ステップ１０１２の通常処理のテスト用データ選択／更新条件の確定処理（選択条件テーブルの作成−図５）を行う。
テストフラグ以外の選択条件は、テストフラグ未設定時（本番データ選択）に指示された時は、無視される。
ステップ１０１１の本番用選択条件確定またはステップ１０１２のテスト用選択条件確定処理を行った後に、ステップ１０１４のデータファイルのＯＰＥＮ処理を行う。選択条件チェックエラーがあった時には、データファイルのＯＰＥＮ処理は実施しない。
【００３７】
図１１は、図１におけるデータファイルの更新／照会のリクエスト受付部、および、データ更新／照会処理部の関係を示す図である。
データファイルの更新／照会のリクエスト受付部１０７は、ユーザからのデータファイルの更新／照会リクエストを受付けて、実行処理を選択する。また、データ更新／照会処理部１０９は、選択されたデータ入出力処理を実際に実行する。ユーザからデータファイルの更新／照会リクエストがあると、リクエストに応じてデータファイルの照会や登録や、更新等の各種入出力処理を実行する。機能的には、実データファイルの照会と、実データファイルの更新と、実データファイルの登録と、実データファイルの削除とがある。
ステップ１１００でユーザからのＩ／Ｏリクエストがあると、リクエストはまずステップ１１０１でユーザからのデータファイルリクエスト受付部１０７で、ユーザの入出力リクエストを受付けた後、リクエストの応じた業務が選択される。リクエストがデータの照会依頼の時には、ステップ１１０２の照会処理へ、データの更新依頼の時には、ステップ１１０３の更新処理へ、データの登録依頼の時には、ステップ１１０４の登録処理へ、データの削除依頼の時には、ステップ１１０５の削除処理へ、それぞれ制御を渡す。
【００３８】
リクエスト受付部１０７よりデータ更新／照会処理部１０９へ制御が渡されると、リクエストに応じた実際の入出力処理が、実データファイルに対して実行され、その結果を仮想データファイル様式に変換して、リクエスト元のユーザを送付されることになる。
リクエストがデータ照会依頼の時には、ステップ１１０６のデータファイルの照会を、データ更新依頼の時には、ステップ１１０８のデータファイルの更新を、データの登録依頼の時には、ステップ１１０７のデータファイルの登録を、データの削除依頼の時には、ステップ１１０９のデータファイルの削除を、それぞれ実際に実行する。
【００３９】
図１２は、図１１におけるデータファイルの照会の詳細動作フローチャートである。
データファイルの照会機能は、ユーザからのデータファイル照会のリクエストにより実施されるもので、ステップ１２０１の実データファイルを実際に読込み、ステップ１２０２でデータファイルが終了（ＡＴＥＮＤ状態）か否かを判定し、データファイルが終了でない場合には、ステップ１２０３で読込み結果とログイン時、またはデータファイルのオープンリクエスト時に作成したデータ選択条件テーブルの選択条件とを比較して、選択条件に合ったデータのみを検索する。選択条件とアンマッチの時は、次のデータの読込み（ステップ１２０１の実データ読込み）へ移る。
【００４０】
選択条件テーブルは、１件とは限らないため、データファイルとの比較は、選択条件テーブルの１件ずつと比較し、１件目の選択条件と不一致の時は、続けて２件目の選択条件と比較する。２件目と不一致の時には続けて３件目と比較・・・のように、選択条件テーブルの全選択条件とＯＲ条件で比較を行いながら、データを検索する。選択条件に合致するデータがあった時には、ステップ１２０４で、データの選択条件中の削除区分を確認し、削除区分＝１（削除フラグのセット）の時には、該当データファイルには死んでいるデータ（削除済みデータ）も残っているので、ステップ１２０５でデータ中の削除フラグで、削除データでないことを確認する。削除データの時には、データファイルの次のデータを読込み（ステップ１２０１）、再度選択条件テーブルの１件目から比較して、データの検索を続行する。削除データでない時には、ステップ１２０６で、実データファイル様式より、データ選択条件項目を除いた仮想データファイル様式に変換した後に、ステップ１２０７で、ユーザにデータを渡して、データファイル照会を終了する。
【００４１】
選択条件テーブルの全選択条件に合致するデータがなかった時には、データファイルの次のデータを読込み、再度選択条件テーブルの１件目から比較して、データの検索を続行する。データファイルが終了（ＡＴ  ＥＮＤ状況）するか、または同一キーデータがなくなっても、選択条件に合致するデータがなかった時には、ステップ１２０８で、対象データなしエラーとして、仮想データファイル様式の全項目に、ＮＵＬＬ値をセットして、データファイル照会を終了する。
【００４２】
図１３は、図１１におけるデータファイルの登録の詳細動作フローチャートである。
データファイルの登録機能は、ユーザからのデータファイル登録のリクエストにより実施される。まず、ステップ１３０１で、前述（図１２）のデータファイル照会を実施して、ステップ１３０２で、登録データと同一キーを持つデータの有無を確認する。登録データと同一キーを持つデータが存在する時には、ステップ１３０３で、同一キーの存在を許すファイルか否かをファイル区分により確認し、同一キーの存在を許さない場合には、ステップ１３０５で、同一キーデータ登録済みエラーとして、データの登録は実施せずにエラーとしてデータファイルの登録処理を終了する。
【００４３】
同一キーの存在を許す場合には、ステップ１３０４で、仮想データ様式にデータ選択条件を付加した実データファイル様式に変換した後、該当データファイルがデータベースの時には、登録データにデータ選択条件インデックスを付加するが、データベース以外の時には、インデックスの作成は不要である。
実データファイル様式に変換後に、ステップ１３０８で、実データファイルに登録処理を行い、データファイルの登録処理を終了する。同一キーを持つデータが存在しない時には、ステップ１３０４の仮想データ様式にデータ選択条件を付加した実データファイル様式に変換した後、ステップ１３０８で、実データファイルに登録処理を行い、データファイルの登録処理を終了する。
【００４４】
データ登録時の仮想データファイル様式に付加するデータ選択条件の編集は、項目毎に以下の要領により編集する。
１）テストフラグ
ログイン時、またはＯＰＥＮリクエスト時に指定されたテストフラグより作成する。未設定の時には、付加するテストフラグは未設定とし、「＋」または「＊」の時には、付加するテストフラグは「＊」の時には、付加するテストフラグは「＊」とする。
２）流用フラグ
ログイン時、またはＯＰＥＮリクエスト時に指定された流用フラグより作成する。未設定の時には、付加する流用フラグは未設定とし、「＊」の時には、付加する流用フラグは「＊」とする。
３）ケースＮＯ．
ログイン時、またはＯＰＥＮリクエスト時に指定されたケースＮＯ．より作成する。未設定の時には、付加するケースＮＯ．は未設定とし、設定された時には、設定されたケースＮＯとする。
【００４５】
４）ユーザＮＯ．
ログイン時のユーザＩＤをセットする。ＯＰＥＮリクエストには未設定とする。
５）更新日
データが登録、または更新されたシステム日付（ＹＹＹＹＭＭＤＤ）を設定する。
６）更新時間
データが登録、または更新された時間（ＨＨＭＭ）を設定する。
７）ファイル区分
ログイン時、またはＯＰＥＮリクエスト時に指定されたファイル区分をそのまま設定する。
【００４６】
図１４は、図１１におけるデータファイルの更新の詳細動作フローチャートである。
データファイルの更新機能は、ユーザからのデータファイル更新（訂正）のリクエストにより実施される。まず、ステップ１４０１で、前述（図１２）のデータファイル照会を実施して、ステップ１４０２で、更新データと同一キーを持つデータの有無を確認する。更新データと同一キーを持つデータが存在する時には、更新対象データがあったケースであり、ステップ１４０３で、更新可能か否かの判断を実施する。更新可能か否かは、対象データのデータ選択条件のテストフラグ項目と、ログイン時、またはＯＰＥＮリクエスト時のテストフラグにより判断する。選択条件のテストフラグが未設定データは、本番データであるため、ログイン時、またはＯＰＥＮリクエスト時のテストフラグが未設定の場合のみ、更新を実施するが、それ以外の場合には更新対象外のデータであるため、次のデータファイル照会を実施して同様の処理を続行する（ステップ１４０１）。本番データの更新は、ステップ１４０６で、仮想データファイルの全項目を更新データと入替え、併せてデータ選択条件の各項目の更新を実施した後、実データファイルの更新処理を終了する。
【００４７】
同様の処理を続行した結果、または、最初から同一キーを持つデータが存在しない場合には、更新対象データがないケースであり、ステップ１４０８で、更新対象データなしエラーとして、データの更新は実施せずに、エラーとしてデータファイルの更新処理を終了する。
ステップ１４０４の選択条件のテストフラグが「＊」データは、テストデータであるため、ログイン時、またはＯＰＥＮリクエスト時のテストフラグが「＊」の場合のみ、ステップ１４０５で、ユーザの更新権限の確認を行う。それ以外の場合には、次のデータファイル照会を実施して（ステップ１４０１）、同様の処理を続行する。テストデータは、ユーザに帰属するデータであるため、ユーザの更新権限の確認が必要となる。ステップ１４０５のユーザの更新権限の確認は、データのユーザＩＤとログイン情報のユーザＩＤを比較して、等しい場合にのみ、ステップ１４０６で実データの更新処理を実施する。
比較結果、不一致の場合には、ステップ１４０１で、次のデータファイル照会を実施して、同様の処理を続行する。テストデータにおけるステップ１４０６の実データの更新要領も、本番データと同様に仮想データファイルの全項目を更新データと入替え、併せてデータ選択条件の各項目を更新して、データファイルの更新処理を終了する。同様の処理を続行した結果、または、最初から同一キーを持つデータが存在しない場合の処理は、本番データと同じである。
【００４８】
データ更新時の仮想データファイル様式に付加するデータ選択条件の編集は、項目毎に以下の要領により編集する。
１）テストフラグ
更新せず。
２）流用フラグ
更新せず。
３）ケースＮＯ．
更新せず。
４）ユーザＩＤ
更新せず。
５）更新日
データが登録、または更新されたシステム日付（ＹＹＹＹＭＭＤＤ）を設定する。
６）更新時間
データが登録、または更新された時間（ＨＨＭＭ）を設定する。
７）ファイル区分
更新せず。
【００４９】
図１５は、図１１におけるデータファイルの削除の詳細動作フローチャートである。
データファイルの削除機能は、ユーザからのデータファイル削除のリクエストにより実施される。まず、ステップ１５０１で、前述（図１２）のデータファイル照会を実施して、ステップ１５０２で削除データと同一キーを持つデータの有無を確認する。同一キーを持つデータが存在する時には、削除対象データがあったケースであり、ステップ１５０３で存在する対象データが、削除可能か否かの判断を実施する。削除可能か否かは、対象データのデータ選択条件のテストフラグ項目と、ログイン時またはＯＰＥＮリクエスト時のテストフラグにより判断する。
【００５０】
選択条件のテストフラグが未設定データは、本番データであるため、ログイン時、またはＯＰＥＮリクエスト時のテストフラグが未設定の場合のみ、削除を実施するが、それ以外の場合には次のデータファイル照会を実施して（ステップ１５０１）、同様の処理を続行する。データの削除は、ファイルの削除区分により処理方法が異なる。ステップ１５０６で、ファイルの削除区分を判定し、削除区分＝０（データを削除）の場合には、ステップ１５１０で、対象データを実データファイルより削除して、削除処理を終了する。
削除区分＝１（削除フラグのセット）の場合には、ステップ１５０７で、選択された対象データの削除フラグのセット状況を確認し、対象データの削除フラグがセット済みであれば、選択された対象データは既に削除済みのため、ステップ１５０９で削除済みデータエラーで削除処理を終了する。
【００５１】
対象データの削除フラグが未設定の場合には、選択された対象データの削除は可能なので、ステップ１５０８で削除フラグをセットし、併せてステップ１５１１で、データ選択条件の各項目の更新を実施した後、実データファイルの削除処理を終了する。同様の処理を続行した結果、または、最初から同一キーを持つデータが存在しない場合は、削除対象データがないケースであり、ステップ１５１２で、削除対象データなしエラーとして、データの削除は実施せずに、エラーとしてデータファイルの削除処理を終了する。
ステップ１５０４で、選択条件のテストフラグが「＊」データは、テストデータであるため、ログイン時、またはＯＰＥＮリクエスト時のテストフラグが「＊」の場合のみ、ステップ１５０５でユーザの削除権限の確認を行う。それ以外の場合には、次のデータファイル照会を実施して（ステップ１５０１）、同様の処理を続行する。
【００５２】
テストデータは、ユーザに帰属するデータであるため、ユーザの削除権限の確認が必要である。ステップ１５０５でのユーザの削除権限の確認は、データのユーザＩＤとログイン情報のユーザＩＤを比較して、等しい場合にのみ実データの削除処理を実施する（ステップ１５０８）。比較の結果、不一致の場合には、次のデータファイル照会を実施して（ステップ１５０１）、同様の処理を続行する。同様の処理を続行した結果、または最初から同一キーを持つデータが存在しない場合には、削除対象データがないケースであり、ステップ１５１２で、データの削除権限なしエラーとして、データの削除処理は実施せず、エラーとしてデータファイルの削除処理を終了する。
テストデータの実データの削除要領は、本番データと同様に削除区分を確認して、データの削除、または更新を実施した後、データファイルの更新処理を終了する。
【００５３】
データ削除時の仮想データファイル様式に付加するデータ選択条件の編集は、項目毎に以下の要領により編集する。ただし、削除区分＝１のケースのみであり、削除区分＝０のケースはデータそのものを削除するので、下記の選択条件の更新は不要となる。
１）テストフラグ
更新せず。
２）流用フラグ
更新せず。
３）ケースＮＯ．
更新せず。
４）ユーザＩＤ
更新せず。
５）更新日
データが登録、または更新されたシステム日付（ＹＹＹＹＭＭＤＤ）を設定する。
６）更新時間
データが登録、または更新された時間（ＨＨＭＭ）を設定する。
７）ファイル区分
更新せず。
【００５４】
図１６は、図１におけるデータの再編成処理部の動作フローチャートである。
データ再編成処理部１１１は、データファイルの再編成処理のリクエストがあると、処理区分により再編成（ダンプとリロード）処理、ダンプ処理のみ、またはリロード処理のみ、のいずれかの処理を実施する。図１６は再編成（ダンプとリロード）処理の場合である。ステップ１６０１で、処理区分＝Ｄ（ダンプ）の時は、ステップ１６０２でデータのダンプ処理（データファイルを全点、別ファイルへ書き出す）を実施する。ステップ１６０３で、処理区分＝Ｒ（リロード）の時には、ステップ１６０４でリロード処理（ダンプ処理で書き出した別ファイルを読込みデータを選択しながら、データファイルへデータを書き出す）を実施する。処理区分≠Ｄ，Ｒの時には、ステップ１６０５でデータのダンプ処理を実施した後、ステップ１６０６でデータファイルのフォーマッティング（ただし、本処理はデータファイルがデータベースの時のみ実施し、それ以外のときは実施しない）を行う。その後、ステップ１６０７で、データのリロード処理を実施する。
【００５５】
図１７は、図１におけるデータの再編成処理部によるデータファイルのダンプ処理のフローチャートである。
ダンプ処理は、ダンプ処理のみのリクエスト、または再編成処理のリクエスト時にのみ行われる。実データファイルを全点読込み、指定されたダンプ用ファイルへ実データファイル様式のまま出力する。ステップ１７０１で実データファイルを読込み、ステップ１７０２でデータファイルが終了か否かを判断する。終了でない時には、ステップ１７０３でデータをそのままの形式（実データファイル様式のまま）指定されたダンプ用の別ファイルへ書き出した後、次のデータファイルの読込みへ移る（ステップ１７０１）。ステップ１７０２のデータファイル終了判断により、データファイルが終了とみなして本ダンプ処理を終了する。
【００５６】
図１８は、図１におけるデータ再編成処理部によるデータファイルのリロード処理のフローチャートである。
リロード処理は、リロード処理のみのリクエスト、または再編成処理のリクエスト時のみに行われる。まず、ダンプ処理で作成されたダンプ用データファイルを全点読込み、読込み結果とログイン時に作成したデータ選択条件テーブルの選択条件と比較して、選択条件にあったデータのみをリロードする。
選択条件テーブルは、１件とは限らないため、データファイルとの比較は選択条件テーブルの１件ずつと比較し、１件目の選択条件と不一致の時には、続けて２件目の選択条件と比較する。２件目と不一致の時には、続けて３件目と比較・・・のようにして、選択条件テーブルの全選択条件とＯＲ条件で比較を行いながら、データを検索する。
【００５７】
まず、ステップ１８０１で、ダンプ用データファイルを読込む。ステップ１８０２で、データファイルの終了か否かを判定し、ファイルが終了時点でデータリロード処理を終了する。ファイルが終了でない時には、ステップ１８０３で、読込みデータがデータ選択条件にマッチしているか否かを、選択条件テーブルを読込んだデータの選択条件を比較して判定する。データ選択条件テーブルにマッチしていない場合には、次のデータの読込みへ移る（ステップ１８０１）。
データ条件にマッチした時には、ステップ１８０４で、データの選択条件中の削除区分を確認し、削除区分＝１（削除フラグのセット）の時には、ステップ１８０５でデータ中の削除フラグで、削除データでないことを確認する。削除データでない時には、データをロードするため、ステップ１８０７で同一データありか否かの判定へ移る。
【００５８】
削除データの時には、ステップ１８０６で、保存期間内か否かを判断して、保存期間を超過した削除データは登録対象外として、登録対象から外すため、次のデータの読込みへ移る（ステップ１８０１）。保存期間内の削除データは、他の登録データと同様に実データファイル様式のまま、データファイルへ出力するが、登録処理前のステップ１８０７で、同一キーの存在有無を確認する。同一キーデータが存在しない場合には、ステップ１８０９でダンプ用データを実データファイルに書き出し、登録する。同一キーデータが存在する場合には、ステップ１８０８で、同一キーデータを複数登録可能か否かを判断する。この判断において、データのファイル区分＝１の場合には、同一キーの存在ありのため、同一データのロード可能となるが、ファイル区分＝０の時には、同一キーの存在なしのため、同一キーデータのロードは不可能となる。登録不可能の場合には、登録対象外なので、登録はせず、次のデータの読込みへ移る。登録可能の場合には、他のデータと同様にステップ１８０９で、ダンプ用データを実データファイルへ登録する。
【００５９】
削除区分＝０（データを削除する）の時には、削除データはないため、削除フラグや、保存期間確認処理は不要である。
同様に処理を行って、ダンプ用データファイルが終了（ＡＴ  ＥＮＤ状況）するまで処理を続行する。
ダンプ用データファイルが終了になった時点で、この処理を終了する。
ステップ１８０６の保存期間内か否かの判定は、以下の通りである。
・データの更新日＋保存日数＜システム日付：リロード対象外
・データの更新日＋保存日数≧システム日付：リロード対象
なお、保存日数は、再編成のログイン時の選択条件で指定した保存日数である。
【００６０】
本発明の実施例について、作用効果を以下に述べる。
１）別リソースに共用データと独自データを登録することなく、共用データファイルに独自データも登録できるので、登録・更新リクエストのある都度、ファイルをコピーする必要がないため、処理時間やリソースの有効活用の面でも、非常に効率がよい。
２）テストフラグを持つことで、本番用（テストフラグ設定なし）データのみを選択することも、またテスト用（テストフラグ設定あり）データのみを選択することも、本番用データとテスト用データとを併せて選択することも、いずれも可能となる。
３）ユーザ情報の他に、ケースＮＯ．を持つことで、同一ユーザの特定のケースの情報のみを選択することも、同一ユーザの全ケースの情報を選択することも、可能となる。
４）ユーザ情報の他に、流用フラグを持つことで、テスト（テストフラグ設定あり）データについては、同一ユーザ独自の情報だけでなく、別ユーザのデータも併せて選択（ユーザ間データの流用）することが可能となる。ただし、別ユーザのテストデータの更新はできない。本番（テストフラグ設定なし）データは、常に全ユーザのデータの更新・照会が可能である。
【００６１】
５）ユーザ情報の他に、更新日・更新時間を持つことで、同一ユーザの特定の更新日・更新時間のデータのみを選択することも、同一ユーザの全更新日・更新時間のデータを選択することも、可能となる。
６）ユーザ独自データは、ユーザ数の大小や、テストケースの大小により、データ量は大きく増減するため、そのままでは処理時間の増加を招くおそれがある。そこで、本実施例では、定期・不定期のサイクルでファイルの再編成（ダンプとリロード）を実施する。再編成のデータリロード時に、リロードデータの選択条件を指示して、不要データを排除することで、データ量の増大を防ぎ、かつデータファイルの入出力にかかわる時間増大を防ぐ。ただし、リロードの選択条件で、テストフラグを設定しない場合（本番データ）のリロード時は、テストフラグ以外の選択条件は無視されて、無条件にテストフラグなしの全データをリロードする。
７）テストフラグのあるデータ（テストデータ）は、基本的にはユーザ情報に帰属するデータであり、テストフラグのないデータ（本番データ）は、ユーザ情報に帰属しないデータである。従って、テストフラグの有無を意識するだけで、ユーザは使用したいデータのみを容易に選択することができる。
【００６２】
図３、図７、図１０〜図１８のフロー動作をプログラム化して、これをＣＤ−ＲＯＭ等の記録媒体に格納しておけば、データファイルのバーチャル更新・照会システムのプロセッサに記録媒体を装着することで、該プロセッサにプログラムをインストールしてこれを実行させることにより、本発明を容易に実現することができる。また、ネットワークを経由して他の端末にこのプログラムをダウンロードすることにより、このプログラムの汎用化も可能である。
【図面の簡単な説明】
【００６３】
【図１】本発明の一実施例に係るデータファイルのバーチャル更新・照会システムの構成図である。
【図２】入力された選択条件により選択条件テーブルの作成要領を決定する方法の動作フローチャートである。
【図３】図２における通常処理時のデータ照会／更新条件の確定処理のフローチャートである。
【図４】テストフラグ設定時の通常処理の本番用選択条件の確定要領を示す図である。
【図５】テストフラグ設定時の通常処理のテスト用データ選択条件の確定要領を示す図である。
【図６】実データファイルと仮想データファイルのデータ様式関係図である。
【図７】図２における再編成処理時のデータ照会／更新条件の確定処理のフローチャートである。
【図８】図１のデータ再編成処理部における本番用データ選択／更新条件の確定（再編成）のテーブル様式図である。
【図９】図１のデータ再編成処理部におけるテスト用データ選択／更新条件の確定（再編成）のテーブル様式図である。
【図１０】図１のデータ照会／更新選択条件の確定部におけるＯＰＥＮ／ＣＬＯＳＥのリクエストによる選択条件の確定処理のフローチャートである。
【図１１】図１におけるデータファイルの更新／照会のリクエスト受付部とデータ更新／照会処理部の概略フローチャートである。
【図１２】図１１におけるデータファイルの照会の詳細動作フローチャートである。
【図１３】図１１におけるデータファイルの登録の詳細動作フローチャートである。
【図１４】図１１におけるデータファイルの更新の詳細動作フローチャートである。
【図１５】図１１におけるデータファイルの削除の詳細動作フローチャートである。
【図１６】図１におけるデータの再編成処理部の動作フローチャートである。
【図１７】図１６におけるデータのダンプのみを実施した時の動作フローチャートである。
【図１８】図１６におけるデータのリロードのみを実施した時の動作フローチャートである。
【符号の説明】
【００６４】
１０１：ホストシステム
１０２：ＰＣ（パーソナルコンピュータ）
１０３：サーバシステム
１０４：ネットワーク
１０５：ログインによる選択条件の確定部
１０６：ＯＰＥＮ／ＣＬＯＳＥのリクエストによる選択条件の確定部
１０７：データファイルの更新／照会のリクエスト受付部
１０８：仮想データファイル（１）〜（ｎ）
１０９：データ更新／照会処理部
１１０：データ再編成処理部
１１１：実データファイル
１１２：対象範囲のシステム
１１５：データファイルのバーチャル更新・照会システム
【図１】
0004467505.tif 000002
【図２】
0004467505.tif 000003
【図３】
0004467505.tif 000004
【図４】
0004467505.tif 000005
【図５】
0004467505.tif 000006
【図６】
0004467505.tif 000007
【図７】
0004467505.tif 000008
【図８】
0004467505.tif 000009
【図９】
0004467505.tif 000010
【図１０】
0004467505.tif 000011
【図１１】
0004467505.tif 000012
【図１２】
0004467505.tif 000013
【図１３】
0004467505.tif 000014
【図１４】
0004467505.tif 000015
【図１５】
0004467505.tif 000016
【図１６】
0004467505.tif 000017
【図１７】
0004467505.tif 000018
【図１８】
0004467505.tif 000019