時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得すると共に、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成してから、該ブロック単位生成ファイルを該ブロック単位で圧縮暗号化して、データ管理保存データベースに格納し、スナップショットしたテーブルの閲覧の際には、該ブロック単位で、該圧縮暗号化の伸張復号を行うようにしたことを特徴とするデータ管理保存方法。請求項1のスナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートした、レコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成し、該インデックスデータテーブルを前記データ管理保存データベースに格納するようにしたことを特徴とするデータ管理保存方法。請求項2のインデックスデータテーブルを用いて、前記データ管理保存データベースに格納の前記ブロック単位生成ファイルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測しつつ、予測されたブロックの前記圧縮暗号化の伸張復号を行ってから該ブロックにおいて検索を行うようにし、これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張復号及び検索を行いながら、検索結果を閲覧に供するようにしたことを特徴とするデータ管理保存方法。請求項2又は請求項3の前記インデックスデータテーブルが、複数のブロックに亘る連番のレコード番号の順列によって、前記レコード順列情報が保存されていることを特徴とするデータ管理保存方法。請求項1乃至請求項4のいずれか1つにおける前記ブロック単位生成ファイルの圧縮暗号化を、予め設定された定期的日時の単位で合成し、前記データ管理保存データベースに格納するようにしたことを特徴とするデータ管理保存方法。請求項1乃至請求項4のいずれか1つにおける前記スナップショット取得から少なくとも前記ブロック分け編成までの処理を、経理業務上、情報が確定する第1の定期的日時の単位で行うと共に、該第1の定期的日時より長期周期となる第2の定期的日時で、異なる該第1の定期的日時において前記ブロック分け編成されたブロック単位生成ファイルから、別のブロック単位生成ファイルを合成することを特徴とするデータ管理保存方法。時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得するスナップショット処理部と、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成するブロック化処理部と、該ブロック単位生成ファイルを該ブロック単位で圧縮暗号化するブロック別圧縮暗号化処理部と、スナップショット取得したテーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理部と、前記圧縮暗号化の情報、及び該インデックスデータテーブルを格納するデータ管理保存データベースと、スナップショットしたテーブルの閲覧の際に、該ブロック単位で、該圧縮暗号化の伸張復号を行うブロック別復号化処理部と、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測し、予測されたブロックの前記圧縮暗号化の伸張復号を行って該ブロックを検索し、これにより、検索対象のテーブルを逐次部分的に伸張復号を行いながら、検索結果を取得するブロック検索処理部と、該検索結果を利用者の閲覧に供する閲覧処理部と、を備えたことを特徴とするデータ管理保存装置。請求項1乃至請求項6のいずれか1つに記載のデータ管理保存方法、又は請求項7に記載のデータ管理保存装置を実施するためのコンピュータプログラム。しかしながら、特許文献1及び特許文献2については、前述のような会計情報の特性について配慮されておらず、重要な大量情報の長期保存と、その高速アクセスや高速検索を可能としながらも、同時に、暗号化によるデータ改ざん防止とセキュリティの確保を十分に図る点については開示されていない。データ圧縮については、過去1~2年分の情報しかオンラインでアクセスすることができない記憶装置や処理装置などのリソースにおいて、税法上7年間の会計情報を保存するには、データ圧縮を徹底する必要がある。又、高い圧縮倍率でも、検索などのアクセス性能は十分確保しなければならないことは言うまでもない。本発明は、前記従来の問題点を解決するべくなされたもので、データ管理保存システムに係り、特に、効率よくデータ圧縮することでリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とし、更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができるデータ管理保存システムを提供することを課題とする。本発明は、時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得すると共に、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成してから、該ブロック単位生成ファイルを該ブロック単位で圧縮暗号化して、データ管理保存データベースに格納し、スナップショットしたテーブルの閲覧の際には、該ブロック単位で、該圧縮暗号化の伸張復号を行うようにしたことにより、該ブロックは、効果的に圧縮倍率が上昇する単位で編成することができ、リソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とすることができる。更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができる。ここで、上述のようにスナップショット取得の対象になる、管理対象のデータベースに格納されているデータとしては、例えば、時系列的に発生するデータ情報で、テーブル形式で格納されているデータ情報がある。このようにテーブル形式のデータ情報であれば、一般に、レコード相互に類似するデータが多くなるため、本願発明におけるブロック単位での圧縮暗号化の圧縮倍率がより一層上昇する。又、スナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートした、レコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成し、該インデックスデータテーブルを前記データ管理保存データベースに格納するようにしたことにより、圧縮された情報のより一層の高速アクセスを可能とすることができる。更には、上記のインデックスデータテーブルを用いて、前記データ管理保存データベースに格納の前記ブロック単位生成ファイルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測しつつ、予測されたブロックの前記圧縮暗号化の伸張復号を行ってから該ブロックにおいて検索を行うようにし、これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張復号及び検索を行いながら、検索結果を閲覧に供するようにしたことにより、圧縮された情報のより一層の高速アクセスや高速検索を可能とすることができる。更に、上記のインデックスデータテーブルが、複数のブロックに亘る連番のレコード番号の順列によって、前記レコード順列情報が保存されていることにより、該インデックスデータテーブルにおいてレコード順列情報のデータ量を抑制することができる。又、上述のブロック単位生成ファイルの圧縮暗号化を、予め設定された定期的日時の単位で合成し、前記データ管理保存データベースに格納することができる。この定期的日時は、対象システムの運用閑散時期や、対象情報の圧縮効率が向上する時期に設定することができる。あるいは、前記スナップショット取得から少なくとも前記ブロック分け編成までの処理を、経理業務上、情報が確定する第1の定期的日時の単位で行うと共に、該第1の定期的日時より長期周期となる第2の定期的日時で、異なる該第1の定期的日時において前記ブロック分け編成されたブロック単位生成ファイルから、別のブロック単位生成ファイルを合成すると、対象情報の処理能率や圧縮効率を向上することができる。なお、上記の第1の定期的日時を、経理業務上、情報が確定する日次とし、上記の第2の定期的日時を、経理業務上、情報が確定する月次とすることもできる。あるいは、該第2の定期的日時を、上記の第1の定期的日時より長期周期となる、決算時期の四半期次や半期次や年次などとしてもよい。又、第1の定期的日時については、第2の定期的日時より短期周期となるものであればよく、日次に限定されるものではなく、場合によっては不定期であってもよい。次に、本発明は、時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得するスナップショット処理部と、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成するブロック化処理部と、該ブロック単位生成ファイルを該ブロック単位で圧縮暗号化するブロック別圧縮暗号化処理部と、スナップショット取得したテーブル単位で、該テーブルに含まれるレコードを特定データでソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理部と、前記圧縮暗号化の情報、及び該インデックスデータテーブルを格納するデータ管理保存データベースと、スナップショットしたテーブルの閲覧の際に、該ブロック単位で、該圧縮暗号化の伸張復号を行うブロック別復号化処理部と、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測し、予測されたブロックの前記圧縮暗号化の伸張復号を行って該ブロックを検索し、これにより、検索対象のテーブルを逐次部分的に伸張復号を行いながら、検索結果を取得するブロック検索処理部と、該検索結果を利用者の閲覧に供する閲覧処理部と、を備えたことにより、該ブロックを、効率よくデータ圧縮することができるように編成することで、リソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とすることができる。更には、該ブロックの圧縮暗号化によって、データ改ざん防止とセキュリティの確保を可能とすることができる。ここで、上述のようにスナップショット取得の対象になる、管理対象のデータベースに格納されているデータとしては、例えば、時系列的に発生するデータ情報で、テーブル形式で格納されているデータ情報がある。このようにテーブル形式のデータ情報であれば、前述のように、本願発明におけるブロック単位での圧縮暗号化の圧縮倍率がより一層上昇する。以上のデータ管理保存方法及びデータ管理保存装置は、コンピュータプログラムによって実現することができる。本発明によれば、対象になる情報を、効率よくデータ圧縮することができるブロックに分割して、ブロック単位生成ファイルに編成することができる。従ってデータ圧縮効率を高めてリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現することができる。このようなデータ圧縮効率の向上及びリソースの削減によって、従来オフライン保存とされていた大量の情報のオンライン保存化を図ることによって、高速アクセスや高速検索を可能とすることができる。更には、対象となる大量の情報は、ブロックに分割して編成した上で圧縮暗号化されるので、データ改ざん防止とセキュリティの確保を可能とすることができる。又、本発明のブロックは、スナップショット取得したテーブルデータを後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数により編成するようにしている。このようなブロック分けの編成は、後日閲覧する際の、アクセスや検索の便宜を図るためのインデックスデータテーブルを作成するのに好適である。例えば、このようにブロック分け編成されたレコードを、該レコード中の特定データ項目でソートした、レコード順列を示す情報が少なくとも保存されるインデックスデータテーブルを作成することも可能である。該インデックスデータテーブルを用いることで、ブロックの伸張復号をする以前に、必要なレコードがどのブロックに存在するか把握することができ、必要なレコードを含む該当のブロックのみ伸張復号することができ、情報の高速アクセスが可能になる。又、閲覧対象の情報本体が格納されるブロック単位生成ファイル自体が、MTなどに保存されオフラインであっても、インデックスデータテーブルにアクセスできれば、ブロック単位生成ファイル自体にアクセス以前に、必要なレコードが該ブロック単位生成ファイルにおいてどのブロックに存在するか把握することができる。従って、オフラインのブロック単位生成ファイルにおいて、最低限のブロックのみ読み出して伸張復号すればよいので、能率よくアクセスや検索を行うことが可能となる。なお、インデックスデータテーブルにおいて、複数のブロックに亘る連番のレコード番号の順列によって、レコード順列情報を保存するようにしてもよい。この場合、関係する全レコードをより少ないデータ長で識別することができる。従って、インデックスデータテーブルを格納するために必要な記憶手段の記憶容量を抑えることが可能となり、システムのリソースを抑えることができる。更に、経理情報や会計情報などは、業務上、情報が確定する日次又は月次が存在するので、このような日次又は月次に、本発明を適用した定期的なスナップショット取得を行うようにすると、このスナップショット取得を自動的に行えるだけでなく、ブロック単位の圧縮暗号化の圧縮率向上を図ることができる。更には、定期的なスナップショット取得によって、スナップショット取得された情報が時系列に保存され、本発明のブロックに分割されることになる。通常検索する場合は、日時を絞って行うため、このような検索に好適な取得情報の保存やインデックスの作成時間の短縮を図ることができると共に、該検索のレスポンスの向上を図ることができる。以下図面を参照して、本発明の実施形態を詳細に説明する。図1は、本発明が適用される実施形態のデータ管理保存システムが導入された企業基幹システムの全体的な構成を示すブロック図である。この図において、企業の購買部門、資材部門、販売管理部門、会計部門それぞれにおいて、購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56が設けられている。これら購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56は、いずれも分散系のDBDataBaseアプリケーションシステムにより構築され、又全体としてERPが適用されている。購買管理サーバ装置50、在庫管理サーバ装置51、及び販売管理サーバ装置52で発生する諸費用情報は、CSVCommaSeparatedValueやXMLextensiblemarkuplanguageなどの汎用形式、あるいは専用形式のファイル交換により、適宜会計管理サーバ装置56に集約され、統合されていわゆる仕訳帳や総勘定元帳などが作成され、これらは会計情報として活用されている。このような企業基幹システムにおいて、本実施形態のデータ管理保存装置10が導入されている。これら購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56は、本実施形態のデータ管理保存装置10が本発明を適用した管理の対象にする装置である。以下、これら装置を管理対象DB装置と呼ぶ。これら管理対象DB装置は、時系列的に発生するデータがテーブル形式のファイル以下元ファイルと呼ぶで格納されている管理対象のデータベースを備えている。又、データ管理保存装置10は、これら元ファイルの情報を、本発明を適用して、CSV形式やXML形式など所定ファイル形式の情報以下スナップショット取得情報と呼ぶにて定期的にスナップショット取得し、保存する。これにより、後日、スナップショットした時点におけるテーブルの情報を閲覧に供することができるようになっている。なお、この図1では、一点鎖線の矢印により、このようなナップショット取得情報を取得する処理が示される。ここで、上記のスナップショット取得情報は、元ファイルのそのままのファイル形式であってもよい。あるいは、元ファイルの情報をバイナリデータとして直接取得するものであってもよい。更には、元ファイルの情報の実体的内容を、CSV形式やXML形式その他の汎用形式、あるいは専用形式に一旦変換したものであってもよい。図2は、本実施形態の企業基幹システムの全体的なハードウェアの構成を示すブロック図である。前述の図1に示した本実施例が対象とする企業基幹システムは、この図2に示されるように、購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56、更にはデータ管理保存装置10が相互に、ネットワーク1により接続されている。加えて、これら装置に接続するクライアント装置5も、ネットワーク1により接続されている。該接続により、前述のような汎用形式や専用形式のファイル交換がなされる。なお、ネットワーク1は、特に限定されるものではない。公衆回線あるいは専用回線を用いるものでも、インターネットやWANWideAreaNetworkやLANLocalAreaNetworkを用いるものでも、あるいはこれらを複合的に接続し構成するものであってもよい。図3は、本実施形態の各装置に用いるコンピュータ装置のハードウェアの構成を示すブロック図である。この図3においては、購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56、更にはデータ管理保存装置10の各装置として利用可能な、ある種のコンピュータ装置のハードウェア構成が示される。しかしながら、各装置は、このようなものに限定されるものではない。図3の該コンピュータ装置は、OSOperatingSystemは一例として米国マイクロソフト社のWindows登録商標を搭載する、一般的なPCPersonalComputer装置であってもよく、特に限定されものではない。あるいは、PC装置以外のハードウェアを用いてもよく、例えばEWSEngineeringWorkStationなどの、いわゆるワークステーションなどのハードウェアを用いるようにしてもよい。なお、この図において、ハードウェア構成は、説明の関係上一部抽象化されている。この図において、コンピュータ装置は、CPUCentralProcessingUnit310と、RAMRandomAccessMemory311と、ROMReadOnlyMemory312と、LAN-I/FInterFace313と、MODEMmodulatordemodulator314と、種々のI/F320~322とを有している。これらは、バス301によって相互接続されている。なお、LAN-I/F313は、ネットワーク1に対して接続するために用いられる。又、バス301に対して、I/F320を介して、画面表示装置330が接続されている。又、バス303によって相互接続されている、キーボード331と、マウス332と、プリンタ装置333とは、バス301に対して、I/F321を介して接続されている。更に、バス301に対して、I/F322を介して、HDDHardDiscDrive装置340と、CDCompactDiscドライブ装置341と、FDDFloppy登録商標DiscDrive装置342とが接続されている。これらはバス302によって相互接続されている。以上のようなハードウェア構成において、記憶手段、又記憶装置は、RAM311、ROM312、HDD装置340、CDドライブ装置341、FDD装置342などである。このような記憶手段や記憶装置において、CPU310で実行される様々なプログラムや、本実施形態においてアクセスされるデータベースや諸ファイルやデータが保存され、電子的にアクセスができるようになっている。例えば、OSや、データベースやJAVA登録商標やJSPJava登録商標ServerPageなどのソフトウェア資源を利用する環境を提供するためのプログラム、本実施形態に係るアプリケーションプログラム、又ウェブブラウザプログラムは、HDD装置340に格納されていて、実行時には、RAM311に読み出されてCPU310によって実行される。なお、CPU310で実行されるアプリケーションプログラムには、ネットワーク1経由で取得される、JAVA登録商標のアプレットや、データ管理保存装置10におけるASPActiveServerPageの機能によって提供されるものも含まれる。又、OSやアプリケーションプログラムその他の実行に際して、オペレータは、画面表示装置330に表示出力される情報を参照しつつ、キーボード331によって文字入力や諸操作を行ったり、マウス332によって座標入力や諸操作の入力を行ったりする。例えば、マウス332によって、一覧表示される電子文書の選択をしたり、閲覧中の電子文書において、検索などの範囲指定を行ったり、その他、クリック操作や、いわゆるドラッグアンドドロップ操作により様々な操作を行ったりする。又、適宜、プリンタ装置333からは必要な情報を印字出力したりすることができる。言うまでもなく、これら諸出力や入力は、CPU310で実行されるプログラムによって、電子的な処理によって行われるものである。なお、CDドライブ装置341やFDD装置342は、本願発明を適用して実施する際の、アプリケーションプログラムのインストールや、その他のオフラインでの情報交換に用いられる。図4は、本実施形態における基幹業務を示すフローチャートである。このフローチャートにおいて、ステップS100は、購買部門、資材部門、販売管理部門、会計部門その他における、購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56の、業務別のシステム運用を示す。これら装置は、分散系のDBを構成しているが、必要に応じネットワーク1経由で相互に情報交換することができる。次に、ステップS102は、本実施形態の企業基幹システムにおいて、これら購買管理サーバ装置50、在庫管理サーバ装置51、販売管理サーバ装置52、及び会計管理サーバ装置56を連携させた、統合的なシステム運用を示す。特に、本企業基幹システムでは、購買管理サーバ装置50、在庫管理サーバ装置51、及び販売管理サーバ装置52で発生する諸費用情報を適宜会計管理サーバ装置56に集約し、該会計管理サーバ装置56において仕訳帳や総勘定元帳などを作成し、会計情報として活用している。更に、ステップS104では、本発明を適用してスナップショットによるデータ管理保存業務処理を行う。これにより、税務監査その他の長期保存情報の閲覧を行うことができる。ここで、これらステップS100、S102及びS104のそれぞれのシステム運用は、概念としてこの順に成立するものであるが、実務として常に並行運用されている。この図は、あくまでこのようなシステム運用の概念を示すものである。図5は、本実施形態に用いられるデータ管理保存装置の構成を示すブロック図である。この図では、前述の図1や図2に示されたデータ管理保存装置10の構成が示される。この図に示されるように、該データ管理保存装置10は、スナップショット処理部22と、ブロック化処理部24と、ブロック別圧縮暗号化処理部26と、インデックスデータテーブル作成処理部28と、データ管理保存処理部30と、ブロック別復号化処理部32と、閲覧処理部34と、ブロック検索処理部36とを備える。更に、該データ管理保存装置10は、上記のデータ管理保存処理部30により保存される情報を格納する、データ記憶装置40を備える。まず、スナップショット処理部22は、管理対象DB装置の各装置それぞれに格納されている元ファイルを対象とし、前述のようにスナップショット取得情報を取得する。このスナップショット取得は、手動で、あるいは自動で定期的に行われ、その時点における元ファィルの情報をスナップショット取得情報として取得することができる。ブロック化処理部24は、このように取得したスナップショット取得情報を、所定のレコード数毎のブロックに編成したファイル以下ブロック単位生成ファイルと呼ぶを生成する。各ブロックが有するレコード数は、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。このため、該閲覧は、通常1つのブロックに対するアクセスで対応することができ、処理対象のブロック数を抑えることで、該閲覧を能率よく行うことができる。次に、ブロック別圧縮暗号化処理部26は、このように編成されたブロック単位生成ファイルを、該編成のブロック単位で圧縮暗号化する。又、インデックスデータテーブル作成処理部28は、このようなブロック単位生成ファイル毎で、該ブロック単位生成ファイルに含まれるレコードを特定データでソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成する。データ管理保存処理部30は、ブロック単位で圧縮暗号化されたブロック単位生成ファイル、及び上記のインデックスデータテーブルをデータ記憶装置40に格納する処理を行う。又、該データ管理保存処理部30は、このように格納されている、所望のブロック単位生成ファイルを読み出す処理を行う。該データ記憶装置40には、HDD装置や、MT装置などが用いられている。次に、ブロック別復号化処理部32は、ブロック単位生成ファイルを閲覧し、元ファイルを閲覧する際に、該ブロック単位生成ファイルを編成しているブロック単位で、該ブロック単位生成ファイルの圧縮暗号化の伸張復号を行う。ブロック検索処理部36は、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがブロック単位生成ファイルにおいてどのブロックに格納されているか予測し、予測されたブロックの圧縮暗号化の伸張復号を行って該ブロックを検索する。これにより、検索対象のテーブルを逐次部分的に伸張復号を行いながら、検索結果を取得する。従って、圧縮暗号化の伸張復号処理は、必要最小限のブロックに限定して行うことが可能であり、検索及び閲覧時の処理速度の向上を図ることができる。続いて、閲覧処理部34は、クライアント装置5からの利用者の利用要求を受け付ける。又、該閲覧処理部34は、該検索結果を利用者の閲覧に供する。ここで、閲覧対象の情報の指示や、検索の指示は、利用者からクライアント装置5により閲覧処理部34に対して入力される。該閲覧処理部34は、この入力内容をブロック検索処理部36に伝達する。該ブロック検索処理部36はブロック別復号化処理部32に対して、この入力内容と、データ記憶装置40に保存されている該当のインデックスデータテーブルとに基づいて、圧縮暗号化の伸張復号処理を行う、ブロック単位生成ファイル、及び該ブロック単位生成ファイルにおけるブロックを指示する。すると、該ブロック別復号化処理部32は、指示されたブロック単位生成ファイルのブロックを、データ管理保存処理部30によってデータ記憶装置40から読み出し、且つ伸張復号処理を行って閲覧処理部34に出力する。この後、該閲覧処理部34は、伸張復号処理されたブロック単位生成ファイルに基づいて、クライアント装置5への閲覧を行う。図6は、本実施形態におけるデータ管理保存業務処理を示すフローチャートである。このフローチャートは、前述の図4のステップS104におけるデータ管理保存業務処理を示すものである。図6において、まず、ステップS110では、このデータ管理保存業務処理に関する諸設定を行う。このデータ管理保存業務処理は、本発明を適用したスナップショット取得を手動でも、又定期的日時で自動的に起動することができる。このステップS110では、このような手動あるいは自動の設定や、自動の場合の定期的日時の設定など、各種の設定を行う。次に、ステップS112では、本発明を適用したスナップショット取得や情報保存その他を行う、データ管理保存処理を行う。管理対象DB装置の各装置それぞれでは、様々な情報が時系列的に発生し、このような情報は、テーブル形式のファイル元ファイルで格納されている。このステップS112において、データ管理保存装置10は、これら元ファイルの情報を、所定形式のスナップショット取得情報として定期的にスナップショット取得し、後述するように本発明を適用してブロック化されたファィルブロック単位生成ファイルにより保存する。本実施形態は、上位システムとなる管理対象DB装置それぞれの、業務上の静止点において、スナップショットを行う。なお、このブロック単位生成ファイルは、ブロック単位で圧縮暗号化されている。このため、該ブロック単位生成ファイルは、大量保存及び長期保存が容易になっている。更には、高速アクセスや高速検索を可能としながら、暗号化によるデータ改ざん防止とセキュリティの確保を可能としている。ここで、OSの特権による管理によっても、データ改ざん防止とセキュリティの確保がある程度可能である。しかしながら、特権がある利用者であれば改ざんをすることが可能であるという限界がある。なお、本実施形態では、圧縮暗号化に加えて、OSの特権による管理によるデータ改ざん防止とセキュリティの確保を行っている。なお、類似情報の出現の頻度が高くなると、圧縮処理における圧縮率が向上する。本実施形態のブロック単位生成ファイルは、ブロック単位で類似情報の出現の可能性が高くなる。従って、本実施形態では圧縮率が向上される可能性が高くなっている。例えば、レコード単位での圧縮暗号化に比較して、圧縮率を向上することができる。図6において、続いてステップS114では、上述のようにステップS112で保存された情報を、スナップショットした時点における該当の元ファイルの情報の提供として、後日、閲覧に供することができる。例えば、税務監査の際、画面表示、印字出力、更にはCSV形式やXML形式などの所定ファイル形式に変換したファイル出力として、税務官の閲覧に供せられる。この閲覧の際には、必要な情報の検索、抽出する機能が備えられている。図7は、本実施形態におけるデータ管理保存処理を示すフローチャートである。このフローチャートは、前述の図6のフローチャートにおけるステップS112のデータ管理保存処理の内容を示したものである。このフローチャートにおいて、まずステップS130では、スナップショット処理部22において、管理対象DB装置の各装置それぞれの元ファィルの情報を、スナップショット取得情報として取得する。ステップS132では、ブロック化処理部24において、スナップショット取得情報に対して、所定のレコード数のブロックで編成するブロック化処理を行う。ステップS134では、ブロック別圧縮暗号化処理部26において、このようにブロックで編成するようにした、スナップショット取得したテーブルデータを該ブロック単位で圧縮暗号化する圧縮暗号化処理を行う。更に、ステップS136では、インデックスデータテーブル作成処理部28において、スナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理を行う。ステップS138では、上述のステップS134で圧縮暗号化した情報、及び上述のステップS136で作成したインデックスデータテーブルを、データ管理保存処理部30において、データ記憶装置40に格納するデータ管理保存処理を行う。図8は、本実施形態におけるスナップショット取得情報CSV形式ファイルとブロック単位生成ファイルの関係を示すデータ構成図である。図9は、該ブロック単位生成ファイルの構成を示すデータ構成図である。本実施形態のスナップショット処理部22は、前述の管理対象DB装置の各装置それぞれにおいてテーブル形式で格納されている、時系列的に発生するデータの元ファイルを、スナップショット取得情報として取得する。該スナップショット取得情報のファイル形式は、特に限定されるものではないが、この図8に示すように、CSV形式のファイルに変換されたものであってもよい。該スナップショット取得情報の情報は、本実施形態において、各ブロックがM個のレコードで構成される、複数ブロックに編成され、これによりブロック単位生成ファイルが生成される。このレコード数Mは、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。このため、該閲覧は、通常1つのブロックに対するアクセスで対応することができ、処理対象のブロック数を抑えることで、該閲覧を能率よく行うことができる。又、このブロック単位生成ファイルは、図9に示されるように、先頭にファイルヘッダ、尾端にファイルフッタを備え、これらの間に、スナップショット取得情報をブロック別に編成した情報が組み込まれる。ここで、CSV形式のファイルのスナップショット取得情報がK個のレコードを有するものであれば、Nは、K/Mの整数値プラス1となる。又、図示されるように、この最終ブロックN中に、CSV形式のファイルの元の情報における最終レコードが含まれることになる。又、図8及び図9に示されるように、各ブロックは、先頭にはブロックヘッダ、尾端にはブロックフッタを備える。これらブロックヘッダ及びブロックフッタには管理情報が格納され、これらブロックヘッダ及びブロックフッタにより、ブロック単位生成ファイルにおいて順に連続するブロックが順次連鎖されるようになっている。ブロックヘッダには、ブロック単位生成ファイルにおいて1つの前のブロックのアドレスが、ブロックフッタには、ブロック単位生成ファイルにおいて1つの後のブロックのアドレスが格納されている。ここで、これら図8及び図9では、各レコードが1社員の情報となっている。各レコードは、東京などの社員所属事業所名、経理や営業などの社員所属部署名、阿部誠や木村隆司などの社員名、東京都......や千葉県......などの社員住所の情報を含んでいる。図10は、本実施形態において定期的日時に生成するブロック単位生成ファイルを示すデータ構成図である。本実施形態では、スナップショットによる情報取得は、時系列的に行われる。又、毎月の特定日時、あるいは経理上や会計上の特定の月及び日時を定期的日時として設定し、自動的に、スナップショットによる情報取得を行うことができる。この図10では、毎月の特定日時定期的日時において、自動的にスナップショットによる情報取得を行う例を示している。該情報取得を行うと、毎月、該取得の日時における元ファイルの、CSV形式のファイルのスナップショット取得情報が取得される。更に、このように毎月、該取得のファイルに従って本発明が適用されたブロック化がなされた、ブロック単位生成ファイルが生成される。ここで、本実施形態では、あらかじめ設定した定期的日時において、過去のブロック単位生成ファイルに対して、月次単位で新たに取得されたスナップショット取得情報を合成することで、この時点での最新の圧縮暗号化されたブロック単位生成ファイルを生成するようにしている。合成され圧縮暗号化されたブロック単位生成ファイルは、データ管理保存処理部30による処理によってデータ記憶装置40に保存されることになる。このような合成されたブロック単位生成ファイルの生成は、例えば、過去のブロック単位生成ファイルを一旦復号化してから、これに新たなスナップショット取得情報圧縮暗号化なしのものを合成し、合成されたものを圧縮暗号化することで行うようにしてもよい。あるいは、新たなスナップショット取得情報をまず圧縮暗号化してから、これに対して、圧縮暗号化されている過去のブロック単位生成ファイルを復号化せず、そのまま合成し行うようにしてもよい。なお、このような合成は行わす、あらかじめ設定した定期的日時において、その都度新たに、圧縮暗号化されたブロック単位生成ファイルを生成するようにしてもよい。しかしながら、上述のような合成では、圧縮暗号化の処理量を抑制することができ、処理速度を向上することができる。次に、図11は、本実施形態におけるインデックスデータテーブルの構成を示すデータ構成図である。本実施形態において、インデックスデータテーブルには、対象になるブロック単位生成ファイルを、特定データ項目でソートしたレコード順列の情報が保存され、これにより、該ソートのレコード順列の情報が保存される。この図11の左側に示されるように、インデックスデータテーブルの先端にはインデックスヘッダが設けられ、続いて、上述のようにソートしたレコード順列の情報に従って、該当のレコード番号が順にインデックスレコードに保存される。このインデックスレコードの数は、対象になるブロック単位生成ファイルに含まれるレコード数と等しくなる。又、一連のインデックスレコードに続いて、インデックスデータテーブルの尾端にはインデックスフッタが設けられる。例えば、図11において、対象になるブロック単位生成ファイルに含まれるレコード数がMであれば、そのインデックスデータテーブルに保存されるインデックスレコードの数もMとなる。又、対象になるブロック単位生成ファイルを特定データ項目でソートしたとき、該ソート結果のブロックレコードの順序が、レコード3、レコード24、レコード1、レコード31......であれば、インデックスレコード1~3には順に、3、24、1、31のデータが保存される。ここで、このようなインデックスデータテーブルの情報は、ブロック単位生成ファイルにおけるレコード順列の情報であり、単にレコード番号のみである。従って、ブロック単位生成ファイルが圧縮暗号化されていれば、インデックスデータテーブルは圧縮暗号化せずとも機密性が確保される。但し、インデックスデータテーブルを圧縮暗号化すれば、該インデックスデータテーブルのデータ量を抑制でき、これを格納する記憶手段の記憶容量の抑制などが可能になる。図12は、本実施形態において作成されるブロック単位生成ファイルの一例の情報内容を示す一覧表である。図13は、この図12のブロック単位生成ファイルのレコードを社員番号でソートした情報内容を示す一覧表である。図14は、このようにソートした場合のインデックスデータテーブルを示すデータ構成図である。図8や図9により前述した、1つ乃至は複数のブロックで構成されるブロック単位生成ファイルにおいて、この図12に示される情報内容が保存されているものとする。ここでは説明の便宜上、レコード数は10で、レコード番号は1~10に抑えられているが、多数のレコードであれば、複数のブロックに保存されることになる。このような場合にも、本実施形態では、複数のブロックに亘ってレコード番号は連番となっている。次に、図13では、図12のブロック単位生成ファイルのレコードを社員番号でソートしている。従って、該ソートの結果、レコード番号が上から順に、1、9、7、2、10、3、4、5、8、6となっている。なお、ソート前の図12では、当然ながらレコード番号が上から順に、1~10である。ここで、図13はソートした後の情報内容を示す一覧表であるので、該図13のレコード番号の列は、該ソート後のレコード順序を示す。従って、該ソートのインデックスデータテーブルでは、このレコード順が保存されることになり、図14に示されるように、インデックスレコード1~10には、該レコード順に対応する、1、9、7、2、10、3、4、5、8、6のレコード番号のデータが順に保存される。次に、図15は、本実施形態における保存データ閲覧処理を示すフローチャートである。このフローチャートは、前述の図6のステップS114のステップS114の保存データ閲覧処理の内容を示すものである。このフローチャートにおいて、まず、ステップS160では、閲覧処理部34は、クライアント装置5から情報閲覧の指示入力を受け付けたり、情報の検索の指示入力を受け付けたりする。情報の検索の指示入力を受け付けた場合、ステップS162では、インデックスデータテーブルを用い、データ管理保存処理部30の処理によってデータ記憶装置40に格納されているテーブルのレコードを検索する際、ブロック検索処理部36は、該閲覧処理部34からの入力に応じて、まず対象レコードがどのブロックに格納されているか予測しつつ、ブロック別復号化処理部32により、予測されたブロックの圧縮暗号化の伸張復号を行ってから該ブロックにおける検索を行う。この検索結果は、該ブロック別復号化処理部32から閲覧処理部34を経て、クライアント装置5に出力される。これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張復号及び検索を行う。ステップS164では、データ記憶装置40に格納されている情報で、上述のように予測されたブロックの伸張復号を行う。続いて、ステップS166では、このように伸張復号されたブロックの情報を閲覧に供する。ここで、検索結果や並べ替え結果などを閲覧に供する場合、クライアント装置5は、1つ乃至は複数の対象のブロックの情報に基づいて、閲覧に供する情報を生成する。例えば、図16は、本実施形態においてこのような保存データ閲覧処理における閲覧画面を示す表示画面図である。この図において、20081204/標準DB/管理/組織別社員台帳とある表示行は、クライアント装置5から利用者が入力した閲覧希望の入力に従った、ブロック単位生成ファイルのファイル名を示す。又、この閲覧結果は、事業所、部署名、社員番号、社員名、住所の社員一覧リストとして表示されている。なお、本実施形態における閲覧結果は、このような画面表示に加えて、CSV形式やXML形式によるファイル出力によっても提供できるようになっている。図17は、このような保存データ閲覧処理における参照レコード群抽出を示すデータ構成図である。この図において、20081204/標準DB/管理/組織別社員台帳と、クライアント装置5から閲覧処理部34に対して閲覧対象が指示入力されると、閲覧処理部34及びブロック別復号化処理部32は、閲覧すべきファイル参照ファイルを見いだすと共に、該参照ファイルにおいて閲覧すべきブロック参照ブロックを見いだし、更には、閲覧すべきレコード群参照レコード群を見いだす。例えば、ある参照ファイルにおいて、X番目のレコードを閲覧する場合、このレコードが含まれるブロックのブロック番号Yは、以下のように算出することができる。ここで、aは、1ブロックあたりのレコード数である。Y=X-1/a1ここで、ブロックのフッタ内には、そのブロックの位置が格納されているテーブルが格納されている。従って、対象ブロックへのアクセスは、このフッタ内の情報を用いる。又、インデックスに格納されているレコード番号から、データへのアクセスは以下の1~3のようになる。1レコード番号より、以下の計算式でブロック番号を取得する。レコード番号-1/1ブロック内のレコード数1=ブロック番号ここで、レコード番号-1は、レコード番号が1相対であるための処理である。又、最後の1は、ブロック番号が1相対であるための処理である。レコード番号が10で、1ブロック内のレコード数が200の場合、9/2001=1となる。よって、ブロック番号は1となる。2データファイル内のフッタより、該当ブロック番号のデータ位置を取得する。3対象位置のブロックを読み込む。次に、図18は、本実施形態の保存データ閲覧処理における検索画面を示す表示画面図である。この図において背景側になっているウインドウでは、登録日、会員名、取扱部店名、銘柄名、市場、取扱銘柄、公表区分、売気配、売提示日、買気配、買提示日のデータを備えるレコードのリストが表示されている。又、選択表示されているウインドウでは、これらデータによって、前方一致、中間一致、完全一致などの選択をしながら検索が可能になっている。ここで、図12~図14により前述したインデックスデータテーブルにおいて、社員番号が6006である社員のレコードを、二分検索法により検索する例について説明する。この場合、検索キーは社員番号が6006となる。図14のインデックスデータテーブルにおいて、全インデックスレコード1~10の真ん中は、該図14中の1で図示されるように、インデックスレコード5であり、該インデックスレコード5にはレコード番号10が保存されている。図12のブロック単位生成ファイルにおいて、このレコード番号10のレコードを参照すると、社員番号は6025であり、検索キーの6006より大であると判定される。大と判定されたので、今度はインデックスレコード1~4を検索対象とし、この真ん中は、該図14中の2で図示されるようにインデックスレコード2であり、該インデックスレコード2には図14においてレコード番号9が保存されている。図12のブロック単位生成ファイルにおいて、このレコード番号9のレコードを参照すると、社員番号は1019であり、検索キーの6006より小であると判定される。小と判定されたので、今度はインデックスレコード3~4を検索対象とし、この真ん中は、該図14中の3で図示されるようにインデックスレコード3であり、該インデックスレコード3には図14においてレコード番号7が保存されている。図12のブロック単位生成ファイルにおいて、このレコード番号7のレコードを参照すると、社員番号は6006であり、検索キーの6006と一致と判定される。該一致判定により、検索結果として、図12のブロック単位生成ファイルにおける、レコード番号7のレコードを取得することになる。このように検索結果が得られた後には、ブロック別復号化処理部32において、検索されたレコードが含まれるブロックの復号化処理を行う。ここで、本実施形態では、検索されたレコードの情報と共に、例えば前述の図16の閲覧画面と同様に、復号化されたブロックの他のレコードも同時に閲覧に供することができる。例えば、検索されたレコードの情報に加えて、該レコードが含まれるブロックにおいて、該レコードの前後の複数のレコードも併せて閲覧に供することができる。なお、以上において、インデックスデータテーブルを用いた二分検索法による、ブロック単位生成ファイルのレコードの検索処理の例について説明した。ほぼ同様に、本実施形態では、インデックスデータテーブルを用いて、ブロック単位生成ファイルのレコードのソート処理も行うことが可能である。なお、本実施形態においては、ブロック単位生成ファイルが複数のブロックで構成される場合に、レコード番号は、複数ブロックに亘る連番を採用している。従って、関係する全レコードをより少ないデータ長で識別することができる。従って、インデックスデータテーブルを格納するために必要な記憶手段の記憶容量を抑えることが可能となり、システムのリソースを抑えることができる。例えば、個々のレコードを、そのレコードが存在するブロックの番号、及び該ブロック中におけるそのレコードの番号で表わすことも考えられる。しかしながら、この場合、これらブロック番号及びレコード番号の合計データ長は、本実施形態の場合に比べて長くなり冗長になる。なお、本実施形態において、インデックスデータテーブルのインデックスレコードのデータ長を、対象になるブロック単位生成ファイルの総レコード数に応じて可変長することもできる。この場合、ブロック単位生成ファイルの総レコード数に応じて、インデックスデータテーブルの記憶容量を抑えることができる。図19は本実施形態におけるバックアップ復元処理を示すフローチャートである。本実施形態では、データ管理保存装置10は、将来のクライアント装置5からの閲覧を目的として、管理対象DB装置の各装置それぞれにおけるテーブル形式のデータをスナップショット取得しデータ記憶装置40に保存している。ここで、このように保存されているデータにより、対象の装置に格納されている情報を、スナップショット取得の時点に復元することも考えられる。この図19は、このようなバックアップ復元処理を示すものである。なお、前述の図1においては、二点鎖線の矢印により、このようなバックアップ復元処理による元ファイルの復元が示される。ステップS180では、データ管理保存装置10の閲覧処理部34は、クライアント装置5からこのようなバックアップ復元要求の、利用者からの入力を受け付ける。ステップS182では、復元すべき装置のファイル、又、この復元に用いる、データ記憶装置40に保存されているファィルを見いだすなどの復元準備処理を行う。ステップS184では、復元に用いる、データ記憶装置40に保存されているファィルの復号化処理を行う。ステップS186では、復号化されたファイルを用いて、復元すべき装置のファイルを、利用者からのクライアント装置5における入力で指示された時点に復元する。なお、以上に説明したように、前述の図5に示されるデータ管理保存装置10における各処理部及びデータ記憶装置40は、図1や図2におけるデータ管理保存装置10において構成している。しかしながら、本実施形態は、このようなものに限定されるものではない。例えば、図1や図2の会計管理サーバ装置56などにおいて、複合的にデータ管理保存装置10を構成し、該会計管理サーバ装置56などにおいて図5に示されるデータ管理保存装置10における各処理部及びデータ記憶装置40を構成するようにしてもよい。会計管理サーバ装置56において複合的にデータ管理保存装置10を構成する場合、データ記憶装置40は、会計管理サーバ装置56が備えるデータベース装置や記憶装置に設けるようにしてもよい。図20は、本発明が適用された第1実施例の処理を示すフローチャートである。本実施例は、以上に説明した実施形態において、管理対象DB装置を、経理情報を少なくとも保存しているデータベースである会計管理サーバ装置56としている。又、前述の定期的日時を、経理業務上、情報が確定する日次及び月次の日時としている。このフローチャートは、前述の図4のフローチャート全体に対応するものである。又、この図4のフローチャートのステップS104であるデータ管理保存業務処理は、前述の図6のフローチャート全体に示されるとおりである。従って、本実施例の図20のフローチャートは、この図4のステップS104に図6のフローチャート全体を盛り込んだものである。更に、この図20に示されるように、ステップS112のデータ管理保存処理は、本実施例では、ステップS210の日次スナップショット処理、及びステップS212の月次情報合成処理によって構成されている。又、本実施例において以下に述べる第1の定期的日時及び第2の定期的日時の設定は、前述したステップS110における業務設定処理において行うことができる。なお、第1の定期的日時は日次、第2の定期的日時は月次としてもよいが、これらに限定されるものではない。例えば、第2の定期的日時を、第1の定期的日時より長期周期となる、決算時期の四半期次や年次などとしてもよい。上記のステップS210の日次スナップショット処理では、日次第1の定期的日時で、該データベースの情報のスナップショット取得、該取得の情報に対する前述したブロック分けの編成によるブロック単位生成ファイルの生成、及び、該ブロック単位生成ファイルの圧縮暗号化を行って、データ記憶装置40データ管理保存データベースに格納する。なお、このステップS210では、スナップショット取得から少なくともブロック分け編成までの処理を行うものである。例えば、圧縮暗号化は省いて、ブロック分け編成までの処理を行ったブロック単位生成ファイルをデータ記憶装置40データ管理保存データベースに格納するようにしてもよい。但し、圧縮暗号化を行うことで、該データ記憶装置40に必要な記憶容量の一層の低減や、セキュリティの安全性の一層の向上を図ることができる。又、上記のステップS212の月次情報合成処理では、月次第2の定期的日時で、日次で格納している複数の該ブロック単位生成ファイルから、月次単位の該ブロック単位生成ファイルを合成する。本実施例のこのファイル合成は具体的に限定されるものではなく、該ファイル合成に際して行われるブロック単位生成ファイルの合成処理や、インデックスデータテーブルの作成処理について具体的に限定されるものではない。例えば、これらブロック単位生成ファイルの合成処理、及びインデックスデータテーブルの作成処理は、該ファイル合成において、いずれか一方のみ行うものであってもよい。又、該ファイル合成の際のブロック単位生成ファイルの合成処理については、例えば、日次で得ている過去の対象期間の複数のブロック単位生成ファイルを一旦復号化してから、これらを合成し、合成されたものを圧縮暗号化することで行うようにしてもよい。あるいは、これら対象期間の複数のブロック単位生成ファイルを復号化せず、そのまま合成し行うようにしてもよい。該ファイル合成の際のインデックスデータテーブルの作成についても、具体的に限定されるものではない。このインデックスデータテーブル作成の処理については、日次で、過去の対象期間の複数のブロック単位生成ファイルの生成時に作成されたインデックスデータテーブルを合成し、これにより、月次単位のインデックスデータテーブルを作成してもよい。あるいは、月次で、ブロック単位生成ファイルを合成する際に、同時に新たに月次単位のインデックスデータテーブルを作成してもよい。ここで、図21は、本実施例が処理対象とする情報の一例を示すデータ構成図である。図20のステップS100や前述の図4のステップS100では、購買管理サーバ装置50、在庫管理サーバ装置51、及び販売管理サーバ装置52などによる、それぞれの該当業務において、様々な情報が発生している。このような業務別の情報の内、経理や会計に係わる諸費用情報は、ステップS102において、適宜会計管理サーバ装置56に集約され、該会計管理サーバ装置56において仕訳帳や総勘定元帳などが作成される。この図21や後述する図23では、このような会計管理サーバ装置56で取得されたり、作成されたりする情報を総称して明細会計情報としている。図21では、明細会計情報A1~A3は2011/5/1に、明細会計情報B1~B3は2011/5/30に、明細会計情報C1~C3は2011/5/31に、購買管理サーバ装置50、在庫管理サーバ装置51、及び販売管理サーバ装置52などから適宜会計管理サーバ装置56において集約され、作成された情報である。続いて、ステップS110では、定期的日時の手動あるいは自動の設定や、自動の場合の第1の定期的日時及び第2の定期的日時の設定など、各種の設定を適宜行う。なお、本実施例では、自動設定であり、又、定期的日時に関しては、日次スナップショット処理の日時設定日毎の時間設定第1の定期的日時設定や処理内容、月次情報合成処理の日時設定月毎の日時設定第2の定期的日時設定や処理内容の設定を行う。次に、ステップS112のステップS210の日次スナップショット処理では、図21の矢印D1~D3で示されるように、圧縮暗号化された日次会計情報E1~E3ブロック単位生成ファイルが生成され、データ記憶装置40に格納される。該生成は、日次第1の定期的日時で行われるものであり、会計管理サーバ装置56にある明細会計情報のスナップショット取得、該取得の情報に対するブロック分けの編成による日次会計情報ブロック単位生成ファイルの生成、及び、該日次会計情報の圧縮暗号化によるものである。続いて、ステップS112のステップS212の月次情報合成処理では、図21の矢印F1で示されるように、月次第2の定期的日時で、上述のように日次で格納している日次会計情報から、月次単位の月次会計情報ブロック単位生成ファイルを合成する。この図21の例では、2011年5月の月次会計情報を合成し生成しているが、この合成及び生成の処理は、例えば、翌月の2011年6月の1日に行う。本実施例では、スナップショット取得しながら圧縮暗号化によって取得される情報日次会計情報は日付毎であるが、毎月の月初めに前月のものが月次会計情報に合成されるので、後日の検索時には対象となるファイルの数が少なくなる。従って、検索処理の処理量が削減され、処理能率が向上される。ここで、本実施例は、会計情報が一日毎で確定する場合を想定したものである。次に、図22は、本発明が適用された第2実施例の処理を示すフローチャートである。本実施例は、上述の第1実施例のステップS112のデータ管理保存処理が、ステップS220の月次スナップショット処理により構成され、日次会計情報ブロック単位生成ファイルの合成は行わない。本実施例において、前述した定期的日時は、経理業務上、情報が確定する月次の日時となっている。ステップS110では、本実施例では自動を設定し、又、月次スナップショット処理の日時設定月毎の日時設定定期的日時設定や処理内容の設定を適宜行う。ここで、図23は、本実施例が処理対象とする情報の一例を示すデータ構成図である。図23では、明細会計情報K1~K3は2011/5/1に、明細会計情報L1~L3は2011/5/31に、明細会計情報M1~M3は2011/6/1に、明細会計情報N1~N3は2011/6/30に、購買管理サーバ装置50、在庫管理サーバ装置51、及び販売管理サーバ装置52などから会計管理サーバ装置56において適宜集約され、作成された情報である。本実施例の図22のステップS220の月次スナップショット処理では、図23の矢印P1、P2で示されるように、圧縮暗号化された月次会計情報Q1、Q2ブロック単位生成ファイルが生成され、データ記憶装置40に格納される。該生成は、月次定期的日時で行われるものであり、会計管理サーバ装置56にある明細会計情報のスナップショット取得、該取得の情報に対するブロック分けの編成による月次会計情報ブロック単位生成ファイルの生成、及び、該月次会計情報の圧縮暗号化によるものである。このように、本実施例では、ブロック単位生成ファイルの合成は行わず、ステップS220の月次スナップショット処理において、その都度新たに、圧縮暗号化されたブロック単位生成ファイルを生成するようにしている。このような本実施例と比較することで、合成処理を行う前述の第1実施例は、全体として圧縮暗号化の処理量を抑制することができ、処理速度を向上することができることがわかる。又、以上に説明したように、本実施例や前述の第1実施例では、検索その他に用いるインデックスデータテーブルの作成は、限られた期間の情報を対象に作成している。従って、このように期間を限らず、例えばRDBRelationalDataBase全体を対象にインデックスデータテーブルを作成する場合に比べて、格段に処理能率を向上することができる。ここで、インデックスデータテーブルは、前述の第1実施例では、日次で作成され、場合によっては月次でも合成ないしは新規作成される。又、本第2実施例では、インデックスデータテーブルは、月次で作成される。従って、インデックスデータテーブルは、分割されたものとなり、検索時には、利用するインデックスデータテーブルの数が増加する可能性が生じるが、通常の検索処理では問題は生じない。又、図21や図23における明細日付のような個々の情報の期日も1つの検索キーとし、検索する場合も考えられる。例えば、税務監査などでは、このように検索対象の情報の期間を限定するケースが多くなる。このような場合、これら実施例では、インデックスデータテーブルが分割されているので、個々のインデックスデータテーブルのデータ量は少なくなるので、検索キーの期日の情報が含まれるインデックスデータテーブルを選択することで、能率よく検索処理を行うことができる。ここで、本第2実施例は、会計情報が一ヶ月毎で確定する場合を想定し、情報量が大量な場合を想定したものである。