データ管理保存システム
【課題】効率よくデータ圧縮することでリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、暗号化によるデータ改ざん防止とセキュリティの確保を可能とする。
【解決手段】スナップショット取得したＣＳＶ形式のファィルを、所定のレコード数毎のブロックに編成し、ブロック単位生成ファイルを生成する。各ブロックが有するレコード数Ｍは、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。生成したブロック単位生成ファイルは、圧縮・暗号化の後に保存する。各ブロックがレコード数Ｍとされているので、該ブロック単位生成ファイルの閲覧は、通常１つのブロックに対するアクセスで対応することができる。
【解決手段】スナップショット取得したＣＳＶ形式のファィルを、所定のレコード数毎のブロックに編成し、ブロック単位生成ファイルを生成する。各ブロックが有するレコード数Ｍは、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。生成したブロック単位生成ファイルは、圧縮・暗号化の後に保存する。各ブロックがレコード数Ｍとされているので、該ブロック単位生成ファイルの閲覧は、通常１つのブロックに対するアクセスで対応することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ管理保存システムに係り、特に、効率よくデータ圧縮することでリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とし、更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができるデータ管理保存方法、データ管理保存装置、又、これらデータ管理保存方法及びデータ管理保存装置を実施するためのコンピュータ・プログラムに関する。
【背景技術】
【０００２】
会計システムとして、ＳＡＰを代表とするＥＲＰ（Enterprise Resource Planning）への移行、メインフレームから分散系システムへの移行（ダウンサイジング）が見られ、分散系のＤＢ（Data Base）アプリケーションシステムも多く採用されている。当初、ＥＲＰシステムへの移行に伴って、税法で定められた取引明細等の長期保存は可能と思われた。
【０００３】
しかしながら、保存される情報が増加するにつれ、情報格納リソースを圧迫することになり、過去分はＭＴ（Magnetic Tape）等に退避することになる。会計情報は税法上７年間の保存義務があるが、ほとんどの企業は１〜２年分の情報しかオンラインでアクセスすることができず、これ以前の情報はＭＴその他オフラインで保存することになる。従って、国税審査官は、オンラインのシステム上にない情報についてはバッチでオフラインのものから必要なデータを出力してもらい、これをマイクロソフト社のＡＣＣＥＳＳなどの帳票オフィスソフトにインポートして監査を行っている。
【０００４】
又、会計情報などの重要な情報は、情報の改ざんや流出の対策を十分に講じる必要があり、長期保存で大量保存の情報であれば被害が膨大になるおそれもあり、なおさら徹底した対策を講じる必要がある。従って、高速アクセスや検索を可能としながらも、同時に、暗号化によるデータ改ざん防止とセキュリティの確保が十分になされる必要がある。
【０００５】
ここで、特許文献１では、バックアップ・プロセスの間でもユーザがシステムに無制限にアクセスすることができ、しかも再構成を必要としないスナップショット・バックアップ・イメージを、素早くかつ一貫的なバックアップとしてＭＴ上に作成できるようにするという技術が開示されている。
【０００６】
又、特許文献２では、ディスク使用効率の良い差分情報を使用したスナップショット管理手法でありながら、書き込み性能の劣化が無く、運用停止時間および運用再開時間を最小限に押さえる復元機能を持つスナップショット機能を有するスナップショット管理システムについて開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００１−５２０７７９号公報
【特許文献２】特開２０１０−７９３３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１及び特許文献２については、前述のような会計情報の特性について配慮されておらず、重要な大量情報の長期保存と、その高速アクセスや高速検索を可能としながらも、同時に、暗号化によるデータ改ざん防止とセキュリティの確保を十分に図る点については開示されていない。
【０００９】
データ圧縮については、過去１〜２年分の情報しかオンラインでアクセスすることができない記憶装置や処理装置などのリソースにおいて、税法上７年間の会計情報を保存するには、データ圧縮を徹底する必要がある。又、高い圧縮倍率でも、検索などのアクセス性能は十分確保しなければならないことは言うまでもない。
【００１０】
本発明は、前記従来の問題点を解決するべくなされたもので、データ管理保存システムに係り、特に、効率よくデータ圧縮することでリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とし、更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができるデータ管理保存システムを提供することを課題とする。
【課題を解決するための手段】
【００１１】
本発明は、時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得すると共に、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成してから、該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化して、データ管理保存データベースに格納し、スナップショットしたテーブルの閲覧の際には、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うようにしたことにより、該ブロックは、効果的に圧縮倍率が上昇する単位で編成することができ、リソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とすることができる。更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができる。
【００１２】
ここで、上述のようにスナップショット取得の対象になる、管理対象のデータベースに格納されているデータとしては、例えば、時系列的に発生するデータ（情報）で、テーブル形式で格納されているデータ（情報）がある。このようにテーブル形式のデータ（情報）であれば、一般に、レコード相互に類似するデータが多くなるため、本願発明におけるブロック単位での圧縮・暗号化の圧縮倍率がより一層上昇する。
【００１３】
又、スナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートした、レコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成し、該インデックスデータテーブルを前記データ管理保存データベースに格納するようにしたことにより、圧縮された情報のより一層の高速アクセスを可能とすることができる。
【００１４】
更には、上記のインデックスデータテーブルを用いて、前記データ管理保存データベースに格納の前記ブロック単位生成ファイルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測しつつ、予測されたブロックの前記圧縮・暗号化の伸張・復号を行ってから該ブロックにおいて検索を行うようにし、これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張・復号及び検索を行いながら、検索結果を閲覧に供するようにしたことにより、圧縮された情報のより一層の高速アクセスや高速検索を可能とすることができる。
【００１５】
更に、上記のインデックスデータテーブルが、複数のブロックに亘る連番のレコード番号の順列によって、前記レコード順列情報が保存されていることにより、該インデックスデータテーブルにおいてレコード順列情報のデータ量を抑制することができる。
【００１６】
又、上述のブロック単位生成ファイルの圧縮・暗号化を、予め設定された定期的日時の単位で合成し、前記データ管理保存データベースに格納することができる。この定期的日時は、対象システムの運用閑散時期や、対象情報の圧縮効率が向上する時期に設定することができる。
【００１７】
あるいは、前記スナップショット取得から少なくとも前記ブロック分け編成までの処理を、経理業務上、情報が確定する第１の定期的日時の単位で行うと共に、該第１の定期的日時より長期周期となる第２の定期的日時で、異なる該第１の定期的日時において前記ブロック分け編成されたブロック単位生成ファイルから、別のブロック単位生成ファイルを合成すると、対象情報の処理能率や圧縮効率を向上することができる。なお、上記の第１の定期的日時を、経理業務上、情報が確定する日次とし、上記の第２の定期的日時を、経理業務上、情報が確定する月次とすることもできる。あるいは、該第２の定期的日時を、上記の第１の定期的日時より長期周期となる、決算時期の四半期次や半期次や年次などとしてもよい。又、第１の定期的日時については、第２の定期的日時より短期周期となるものであればよく、日次に限定されるものではなく、場合によっては不定期であってもよい。
【００１８】
次に、本発明は、時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得するスナップショット処理部と、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成するブロック化処理部と、該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化するブロック別圧縮・暗号化処理部と、スナップショット取得したテーブル単位で、該テーブルに含まれるレコードを特定データでソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理部と、前記圧縮・暗号化の情報、及び該インデックスデータテーブルを格納するデータ管理保存データベースと、スナップショットしたテーブルの閲覧の際に、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うブロック別復号化処理部と、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測し、予測されたブロックの前記圧縮・暗号化の伸張・復号を行って該ブロックを検索し、これにより、検索対象のテーブルを逐次部分的に伸張・復号を行いながら、検索結果を取得するブロック検索処理部と、該検索結果を利用者の閲覧に供する閲覧処理部と、を備えたことにより、該ブロックを、効率よくデータ圧縮することができるように編成することで、リソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とすることができる。更には、該ブロックの圧縮・暗号化によって、データ改ざん防止とセキュリティの確保を可能とすることができる。
【００１９】
ここで、上述のようにスナップショット取得の対象になる、管理対象のデータベースに格納されているデータとしては、例えば、時系列的に発生するデータ（情報）で、テーブル形式で格納されているデータ（情報）がある。このようにテーブル形式のデータ（情報）であれば、前述のように、本願発明におけるブロック単位での圧縮・暗号化の圧縮倍率がより一層上昇する。
【００２０】
以上のデータ管理保存方法及びデータ管理保存装置は、コンピュータ・プログラムによって実現することができる。
【発明の効果】
【００２１】
本発明によれば、対象になる情報を、効率よくデータ圧縮することができるブロックに分割して、ブロック単位生成ファイルに編成することができる。従ってデータ圧縮効率を高めてリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現することができる。このようなデータ圧縮効率の向上及びリソースの削減によって、従来オフライン保存とされていた大量の情報のオンライン保存化を図ることによって、高速アクセスや高速検索を可能とすることができる。
【００２２】
更には、対象となる大量の情報は、ブロックに分割して編成した上で圧縮・暗号化されるので、データ改ざん防止とセキュリティの確保を可能とすることができる。
【００２３】
又、本発明のブロックは、スナップショット取得したテーブルデータを後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数により編成するようにしている。このようなブロック分けの編成は、後日閲覧する際の、アクセスや検索の便宜を図るためのインデックスデータテーブルを作成するのに好適である。例えば、このようにブロック分け編成されたレコードを、該レコード中の特定データ項目でソートした、レコード順列を示す情報が少なくとも保存されるインデックスデータテーブルを作成することも可能である。該インデックスデータテーブルを用いることで、ブロックの伸張・復号をする以前に、必要なレコードがどのブロックに存在するか把握することができ、必要なレコードを含む該当のブロックのみ伸張・復号することができ、情報の高速アクセスが可能になる。
【００２４】
又、閲覧対象の情報本体が格納されるブロック単位生成ファイル自体が、ＭＴなどに保存されオフラインであっても、インデックスデータテーブルにアクセスできれば、ブロック単位生成ファイル自体にアクセス以前に、必要なレコードが該ブロック単位生成ファイルにおいてどのブロックに存在するか把握することができる。従って、オフラインのブロック単位生成ファイルにおいて、最低限のブロックのみ読み出して伸張・復号すればよいので、能率よくアクセスや検索を行うことが可能となる。
【００２５】
なお、インデックスデータテーブルにおいて、複数のブロックに亘る連番のレコード番号の順列によって、レコード順列情報を保存するようにしてもよい。この場合、関係する全レコードをより少ないデータ長で識別することができる。従って、インデックスデータテーブルを格納するために必要な記憶手段の記憶容量を抑えることが可能となり、システムのリソースを抑えることができる。
【００２６】
更に、経理情報や会計情報などは、業務上、情報が確定する日次又は月次が存在するので、このような日次又は月次に、本発明を適用した定期的なスナップショット取得を行うようにすると、このスナップショット取得を自動的に行えるだけでなく、ブロック単位の圧縮・暗号化の圧縮率向上を図ることができる。
【００２７】
更には、定期的なスナップショット取得によって、スナップショット取得された情報が時系列に保存され、本発明のブロックに分割されることになる。通常検索する場合は、日時を絞って行うため、このような検索に好適な取得情報の保存やインデックスの作成時間の短縮を図ることができると共に、該検索のレスポンスの向上を図ることができる。
【図面の簡単な説明】
【００２８】
【図１】本発明が適用される実施形態のデータ管理保存システムが導入された企業基幹システムの全体的な構成を示すブロック図
【図２】上記企業基幹システムの全体的なハードウェアの構成を示すブロック図
【図３】前記企業基幹システムで用いられるコンピュータ装置のハードウェア構成を示すブロック図
【図４】前記実施形態における基幹業務を示すフローチャート
【図５】前記実施形態に用いられるデータ管理保存装置の構成を示すブロック図
【図６】前記実施形態におけるデータ管理保存業務処理を示すフローチャート
【図７】前記実施形態におけるデータ管理保存処理を示すフローチャート
【図８】前記実施形態におけるスナップショット取得情報（ＣＳＶ形式ファィル）とブロック単位生成ファイルの関係を示すデータ構成図
【図９】前記実施形態におけるブロック単位生成ファイルの構成を示すデータ構成図
【図１０】前記実施形態において定期的日時に生成するブロック単位生成ファイルを示すデータ構成図
【図１１】前記実施形態におけるインデックスデータテーブルの構成を示すデータ構成図
【図１２】前記実施形態において作成されるブロック単位生成ファイルの一例の情報内容を示す一覧表
【図１３】上記ブロック単位生成ファイルのレコードを「社員番号」でソートした情報内容を示す一覧表
【図１４】上記ブロック単位生成ファイル例を「社員番号」でソートした場合のインデックスデータテーブルを示すデータ構成図
【図１５】前記実施形態における保存データ閲覧処理を示すフローチャート
【図１６】上記保存データ閲覧処理における閲覧画面を示す線図
【図１７】上記保存データ閲覧処理における参照レコード群抽出を示すデータ構成図
【図１８】上記保存データ閲覧処理における検索画面を示す線図
【図１９】前記実施形態におけるバックアップ復元処理を示すフローチャート
【図２０】本発明が適用された第１実施例の処理を示すフローチャート
【図２１】上記実施例が処理対象とする情報の一例を示すデータ構成図
【図２２】本発明が適用された第２実施例の処理を示すフローチャート
【図２３】上記実施例が処理対象とする情報の一例を示すデータ構成図
【発明を実施するための形態】
【００２９】
以下図面を参照して、本発明の実施形態を詳細に説明する。
【００３０】
図１は、本発明が適用される実施形態のデータ管理保存システムが導入された企業基幹システムの全体的な構成を示すブロック図である。
【００３１】
この図において、企業の購買部門、資材部門、販売管理部門、会計部門それぞれにおいて、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６が設けられている。これら購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６は、いずれも分散系のＤＢ（Data Base）アプリケーションシステムにより構築され、又全体としてＥＲＰが適用されている。
【００３２】
購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２で発生する諸費用情報は、ＣＳＶ（Comma Separated Value）やＸＭＬ（extensible markup language）などの汎用形式、あるいは専用形式のファイル交換により、適宜会計管理サーバ装置５６に集約され、統合されていわゆる仕訳帳や総勘定元帳などが作成され、これらは会計情報として活用されている。
【００３３】
このような企業基幹システムにおいて、本実施形態のデータ管理保存装置１０が導入されている。これら購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６は、本実施形態のデータ管理保存装置１０が本発明を適用した管理の対象にする装置である。以下、これら装置を管理対象ＤＢ装置と呼ぶ。これら管理対象ＤＢ装置は、時系列的に発生するデータがテーブル形式のファイル（以下元ファイルと呼ぶ）で格納されている管理対象のデータベースを備えている。
【００３４】
又、データ管理保存装置１０は、これら元ファイルの情報を、本発明を適用して、ＣＳＶ形式やＸＭＬ形式など所定ファイル形式の情報（以下スナップショット取得情報と呼ぶ）にて定期的にスナップショット取得し、保存する。これにより、後日、スナップショットした時点におけるテーブルの情報を閲覧に供することができるようになっている。なお、この図１では、一点鎖線の矢印により、このようなナップショット取得情報を取得する処理が示される。
【００３５】
ここで、上記のスナップショット取得情報は、元ファイルのそのままのファイル形式であってもよい。あるいは、元ファイルの情報をバイナリデータとして直接取得するものであってもよい。更には、元ファイルの情報の実体的内容を、ＣＳＶ形式やＸＭＬ形式その他の汎用形式、あるいは専用形式に一旦変換したものであってもよい。
【００３６】
図２は、本実施形態の企業基幹システムの全体的なハードウェアの構成を示すブロック図である。
【００３７】
前述の図１に示した本実施例が対象とする企業基幹システムは、この図２に示されるように、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６、更にはデータ管理保存装置１０が相互に、ネットワーク１により接続されている。加えて、これら装置に接続するクライアント装置５も、ネットワーク１により接続されている。該接続により、前述のような汎用形式や専用形式のファイル交換がなされる。
【００３８】
なお、ネットワーク１は、特に限定されるものではない。公衆回線あるいは専用回線を用いるものでも、インターネットやＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）を用いるものでも、あるいはこれらを複合的に接続し構成するものであってもよい。
【００３９】
図３は、本実施形態の各装置に用いるコンピュータ装置のハードウェアの構成を示すブロック図である。
【００４０】
この図３においては、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６、更にはデータ管理保存装置１０の各装置として利用可能な、ある種のコンピュータ装置のハードウェア構成が示される。しかしながら、各装置は、このようなものに限定されるものではない。
【００４１】
図３の該コンピュータ装置は、ＯＳ（Operating System）は一例として米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）を搭載する、一般的なＰＣ（Personal Computer）装置であってもよく、特に限定されものではない。あるいは、ＰＣ装置以外のハードウェアを用いてもよく、例えばＥＷＳ（Engineering Work Station）などの、いわゆるワークステーションなどのハードウェアを用いるようにしてもよい。なお、この図において、ハードウェア構成は、説明の関係上一部抽象化されている。
【００４２】
この図において、コンピュータ装置は、ＣＰＵ（Central Processing Unit）３１０と、ＲＡＭ（Random Access Memory）３１１と、ＲＯＭ（Read Only Memory）３１２と、ＬＡＮ−Ｉ／Ｆ（Inter Face）３１３と、ＭＯＤＥＭ（modulator-demodulator）３１４と、種々のＩ／Ｆ３２０〜３２２とを有している。これらは、バス３０１によって相互接続されている。
【００４３】
なお、ＬＡＮ−Ｉ／Ｆ３１３は、ネットワーク１に対して接続するために用いられる。
【００４４】
又、バス３０１に対して、Ｉ／Ｆ３２０を介して、画面表示装置３３０が接続されている。又、バス３０３によって相互接続されている、キーボード３３１と、マウス３３２と、プリンタ装置３３３とは、バス３０１に対して、Ｉ／Ｆ３２１を介して接続されている。
【００４５】
更に、バス３０１に対して、Ｉ／Ｆ３２２を介して、ＨＤＤ（Hard Disc Drive）装置３４０と、ＣＤ（Compact Disc）ドライブ装置３４１と、ＦＤＤ（Floppy（登録商標） Disc Drive）装置３４２とが接続されている。これらはバス３０２によって相互接続されている。
【００４６】
以上のようなハードウェア構成において、記憶手段、又記憶装置は、ＲＡＭ３１１、ＲＯＭ３１２、ＨＤＤ装置３４０、ＣＤドライブ装置３４１、ＦＤＤ装置３４２などである。このような記憶手段や記憶装置において、ＣＰＵ３１０で実行される様々なプログラムや、本実施形態においてアクセスされるデータベースや諸ファイルやデータが保存され、電子的にアクセスができるようになっている。例えば、ＯＳや、データベースやＪＡＶＡ（登録商標)やＪＳＰ（Java（登録商標) Server Page）などのソフトウェア資源を利用する環境を提供するためのプログラム、本実施形態に係るアプリケーション・プログラム、又ウェブ・ブラウザ・プログラムは、ＨＤＤ装置３４０に格納されていて、実行時には、ＲＡＭ３１１に読み出されてＣＰＵ３１０によって実行される。なお、ＣＰＵ３１０で実行されるアプリケーション・プログラムには、ネットワーク１経由で取得される、ＪＡＶＡ（登録商標)のアプレットや、データ管理保存装置１０におけるＡＳＰ（Active Server Page）の機能によって提供されるものも含まれる。
【００４７】
又、ＯＳやアプリケーション・プログラムその他の実行に際して、オペレータは、画面表示装置３３０に表示出力される情報を参照しつつ、キーボード３３１によって文字入力や諸操作を行ったり、マウス３３２によって座標入力や諸操作の入力を行ったりする。例えば、マウス３３２によって、一覧表示される電子文書の選択をしたり、閲覧中の電子文書において、検索などの範囲指定を行ったり、その他、クリック操作や、いわゆるドラッグ・アンド・ドロップ操作により様々な操作を行ったりする。又、適宜、プリンタ装置３３３からは必要な情報を印字出力したりすることができる。言うまでもなく、これら諸出力や入力は、ＣＰＵ３１０で実行されるプログラムによって、電子的な処理によって行われるものである。
【００４８】
なお、ＣＤドライブ装置３４１やＦＤＤ装置３４２は、本願発明を適用して実施する際の、アプリケーション・プログラムのインストールや、その他のオフラインでの情報交換に用いられる。
【００４９】
図４は、本実施形態における基幹業務を示すフローチャートである。
【００５０】
このフローチャートにおいて、ステップＳ１００は、購買部門、資材部門、販売管理部門、会計部門その他における、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６の、業務別のシステム運用を示す。これら装置は、分散系のＤＢを構成しているが、必要に応じネットワーク１経由で相互に情報交換することができる。
【００５１】
次に、ステップＳ１０２は、本実施形態の企業基幹システムにおいて、これら購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６を連携させた、統合的なシステム運用を示す。特に、本企業基幹システムでは、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２で発生する諸費用情報を適宜会計管理サーバ装置５６に集約し、該会計管理サーバ装置５６において仕訳帳や総勘定元帳などを作成し、会計情報として活用している。
【００５２】
更に、ステップＳ１０４では、本発明を適用してスナップショットによるデータ管理保存業務処理を行う。これにより、税務監査その他の長期保存情報の閲覧を行うことができる。
【００５３】
ここで、これらステップＳ１００、Ｓ１０２及びＳ１０４のそれぞれのシステム運用は、概念としてこの順に成立するものであるが、実務として常に並行運用されている。この図は、あくまでこのようなシステム運用の概念を示すものである。
【００５４】
図５は、本実施形態に用いられるデータ管理保存装置の構成を示すブロック図である。
【００５５】
この図では、前述の図１や図２に示されたデータ管理保存装置１０の構成が示される。この図に示されるように、該データ管理保存装置１０は、スナップショット処理部２２と、ブロック化処理部２４と、ブロック別圧縮・暗号化処理部２６と、インデックスデータテーブル作成処理部２８と、データ管理保存処理部３０と、ブロック別復号化処理部３２と、閲覧処理部３４と、ブロック検索処理部３６とを備える。更に、該データ管理保存装置１０は、上記のデータ管理保存処理部３０により保存される情報を格納する、データ記憶装置４０を備える。
【００５６】
まず、スナップショット処理部２２は、管理対象ＤＢ装置の各装置それぞれに格納されている元ファイルを対象とし、前述のようにスナップショット取得情報を取得する。このスナップショット取得は、手動で、あるいは自動で定期的に行われ、その時点における元ファィルの情報をスナップショット取得情報として取得することができる。
【００５７】
ブロック化処理部２４は、このように取得したスナップショット取得情報を、所定のレコード数毎のブロックに編成したファイル（以下ブロック単位生成ファイルと呼ぶ）を生成する。各ブロックが有するレコード数は、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。このため、該閲覧は、通常１つのブロックに対するアクセスで対応することができ、処理対象のブロック数を抑えることで、該閲覧を能率よく行うことができる。
【００５８】
次に、ブロック別圧縮・暗号化処理部２６は、このように編成されたブロック単位生成ファイルを、該編成のブロック単位で圧縮・暗号化する。又、インデックスデータテーブル作成処理部２８は、このようなブロック単位生成ファイル毎で、該ブロック単位生成ファイルに含まれるレコードを特定データでソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成する。
【００５９】
データ管理保存処理部３０は、ブロック単位で圧縮・暗号化されたブロック単位生成ファイル、及び上記のインデックスデータテーブルをデータ記憶装置４０に格納する処理を行う。又、該データ管理保存処理部３０は、このように格納されている、所望のブロック単位生成ファイルを読み出す処理を行う。該データ記憶装置４０には、ＨＤＤ装置や、ＭＴ装置などが用いられている。
【００６０】
次に、ブロック別復号化処理部３２は、ブロック単位生成ファイルを閲覧し、元ファイルを閲覧する際に、該ブロック単位生成ファイルを編成しているブロック単位で、該ブロック単位生成ファイルの圧縮・暗号化の伸張・復号を行う。
【００６１】
ブロック検索処理部３６は、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがブロック単位生成ファイルにおいてどのブロックに格納されているか予測し、予測されたブロックの圧縮・暗号化の伸張・復号を行って該ブロックを検索する。これにより、検索対象のテーブルを逐次部分的に伸張・復号を行いながら、検索結果を取得する。従って、圧縮・暗号化の伸張・復号処理は、必要最小限のブロックに限定して行うことが可能であり、検索及び閲覧時の処理速度の向上を図ることができる。
【００６２】
続いて、閲覧処理部３４は、クライアント装置５からの利用者の利用要求を受け付ける。又、該閲覧処理部３４は、該検索結果を利用者の閲覧に供する。
【００６３】
ここで、閲覧対象の情報の指示や、検索の指示は、利用者からクライアント装置５により閲覧処理部３４に対して入力される。該閲覧処理部３４は、この入力内容をブロック検索処理部３６に伝達する。該ブロック検索処理部３６はブロック別復号化処理部３２に対して、この入力内容と、データ記憶装置４０に保存されている該当のインデックスデータテーブルとに基づいて、圧縮・暗号化の伸張・復号処理を行う、ブロック単位生成ファイル、及び該ブロック単位生成ファイルにおけるブロックを指示する。
【００６４】
すると、該ブロック別復号化処理部３２は、指示されたブロック単位生成ファイルのブロックを、データ管理保存処理部３０によってデータ記憶装置４０から読み出し、且つ伸張・復号処理を行って閲覧処理部３４に出力する。この後、該閲覧処理部３４は、伸張・復号処理されたブロック単位生成ファイルに基づいて、クライアント装置５への閲覧を行う。
【００６５】
図６は、本実施形態におけるデータ管理保存業務処理を示すフローチャートである。
【００６６】
このフローチャートは、前述の図４のステップＳ１０４におけるデータ管理保存業務処理を示すものである。
【００６７】
図６において、まず、ステップＳ１１０では、このデータ管理保存業務処理に関する諸設定を行う。このデータ管理保存業務処理は、本発明を適用したスナップショット取得を手動でも、又定期的日時で自動的に起動することができる。このステップＳ１１０では、このような手動あるいは自動の設定や、自動の場合の定期的日時の設定など、各種の設定を行う。
【００６８】
次に、ステップＳ１１２では、本発明を適用したスナップショット取得や情報保存その他を行う、データ管理保存処理を行う。
【００６９】
管理対象ＤＢ装置の各装置それぞれでは、様々な情報が時系列的に発生し、このような情報は、テーブル形式のファイル（元ファイル）で格納されている。このステップＳ１１２において、データ管理保存装置１０は、これら元ファイルの情報を、所定形式のスナップショット取得情報として定期的にスナップショット取得し、後述するように本発明を適用してブロック化されたファィル（ブロック単位生成ファイル）により保存する。本実施形態は、上位システムとなる管理対象ＤＢ装置それぞれの、業務上の静止点において、スナップショットを行う。
【００７０】
なお、このブロック単位生成ファイルは、ブロック単位で圧縮・暗号化されている。このため、該ブロック単位生成ファイルは、大量保存及び長期保存が容易になっている。更には、高速アクセスや高速検索を可能としながら、暗号化によるデータ改ざん防止とセキュリティの確保を可能としている。
【００７１】
ここで、ＯＳの特権による管理によっても、データ改ざん防止とセキュリティの確保がある程度可能である。しかしながら、特権がある利用者であれば改ざんをすることが可能であるという限界がある。なお、本実施形態では、圧縮・暗号化に加えて、ＯＳの特権による管理によるデータ改ざん防止とセキュリティの確保を行っている。
【００７２】
なお、類似情報の出現の頻度が高くなると、圧縮処理における圧縮率が向上する。本実施形態のブロック単位生成ファイルは、ブロック単位で類似情報の出現の可能性が高くなる。従って、本実施形態では圧縮率が向上される可能性が高くなっている。例えば、レコード単位での圧縮・暗号化に比較して、圧縮率を向上することができる。
【００７３】
図６において、続いてステップＳ１１４では、上述のようにステップＳ１１２で保存された情報を、スナップショットした時点における該当の元ファイルの情報の提供として、後日、閲覧に供することができる。例えば、税務監査の際、画面表示、印字出力、更にはＣＳＶ形式やＸＭＬ形式などの所定ファイル形式に変換したファイル出力として、税務官の閲覧に供せられる。この閲覧の際には、必要な情報の検索、抽出する機能が備えられている。
【００７４】
図７は、本実施形態におけるデータ管理保存処理を示すフローチャートである。
【００７５】
このフローチャートは、前述の図６のフローチャートにおけるステップＳ１１２のデータ管理保存処理の内容を示したものである。
【００７６】
このフローチャートにおいて、まずステップＳ１３０では、スナップショット処理部２２において、管理対象ＤＢ装置の各装置それぞれの元ファィルの情報を、スナップショット取得情報として取得する。
【００７７】
ステップＳ１３２では、ブロック化処理部２４において、スナップショット取得情報に対して、所定のレコード数のブロックで編成するブロック化処理を行う。
【００７８】
ステップＳ１３４では、ブロック別圧縮・暗号化処理部２６において、このようにブロックで編成するようにした、スナップショット取得したテーブルデータを該ブロック単位で圧縮・暗号化する圧縮・暗号化処理を行う。
【００７９】
更に、ステップＳ１３６では、インデックスデータテーブル作成処理部２８において、スナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理を行う。
【００８０】
ステップＳ１３８では、上述のステップＳ１３４で圧縮・暗号化した情報、及び上述のステップＳ１３６で作成したインデックスデータテーブルを、データ管理保存処理部３０において、データ記憶装置４０に格納するデータ管理保存処理を行う。
【００８１】
図８は、本実施形態におけるスナップショット取得情報（ＣＳＶ形式ファイル）とブロック単位生成ファイルの関係を示すデータ構成図である。図９は、該ブロック単位生成ファイルの構成を示すデータ構成図である。
【００８２】
本実施形態のスナップショット処理部２２は、前述の管理対象ＤＢ装置の各装置それぞれにおいてテーブル形式で格納されている、時系列的に発生するデータの元ファイルを、スナップショット取得情報として取得する。該スナップショット取得情報のファイル形式は、特に限定されるものではないが、この図８に示すように、ＣＳＶ形式のファイルに変換されたものであってもよい。
【００８３】
該スナップショット取得情報の情報は、本実施形態において、各ブロックがＭ個のレコードで構成される、複数ブロックに編成され、これによりブロック単位生成ファイルが生成される。このレコード数Ｍは、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。このため、該閲覧は、通常１つのブロックに対するアクセスで対応することができ、処理対象のブロック数を抑えることで、該閲覧を能率よく行うことができる。
【００８４】
又、このブロック単位生成ファイルは、図９に示されるように、先頭にファイルヘッダ、尾端にファイルフッタを備え、これらの間に、スナップショット取得情報をブロック別に編成した情報が組み込まれる。
【００８５】
ここで、ＣＳＶ形式のファイルのスナップショット取得情報がＫ個のレコードを有するものであれば、Ｎは、（Ｋ／Ｍ）の整数値プラス１となる。又、図示されるように、この最終ブロックＮ中に、ＣＳＶ形式のファイルの元の情報における最終レコードが含まれることになる。
【００８６】
又、図８及び図９に示されるように、各ブロックは、先頭にはブロックヘッダ、尾端にはブロックフッタを備える。これらブロックヘッダ及びブロックフッタには管理情報が格納され、これらブロックヘッダ及びブロックフッタにより、ブロック単位生成ファイルにおいて順に連続するブロックが順次連鎖されるようになっている。ブロックヘッダには、ブロック単位生成ファイルにおいて１つの前のブロックのアドレスが、ブロックフッタには、ブロック単位生成ファイルにおいて１つの後のブロックのアドレスが格納されている。
【００８７】
ここで、これら図８及び図９では、各レコードが１社員の情報となっている。各レコードは、「東京」などの社員所属事業所名、「経理」や「営業」などの社員所属部署名、「阿部誠」や「木村隆司」などの社員名、「東京都……」や「千葉県……」などの社員住所の情報を含んでいる。
【００８８】
図１０は、本実施形態において定期的日時に生成するブロック単位生成ファイルを示すデータ構成図である。
【００８９】
本実施形態では、スナップショットによる情報取得は、時系列的に行われる。又、毎月の特定日時、あるいは経理上や会計上の特定の月及び日時を定期的日時として設定し、自動的に、スナップショットによる情報取得を行うことができる。
【００９０】
この図１０では、毎月の特定日時（定期的日時）において、自動的にスナップショットによる情報取得を行う例を示している。該情報取得を行うと、毎月、該取得の日時における元ファイルの、ＣＳＶ形式のファイルのスナップショット取得情報が取得される。更に、このように毎月、該取得のファイルに従って本発明が適用されたブロック化がなされた、ブロック単位生成ファイルが生成される。
【００９１】
ここで、本実施形態では、あらかじめ設定した定期的日時において、過去のブロック単位生成ファイルに対して、月次単位で新たに取得されたスナップショット取得情報を合成することで、この時点での最新の圧縮・暗号化されたブロック単位生成ファイルを生成するようにしている。合成され圧縮・暗号化されたブロック単位生成ファイルは、データ管理保存処理部３０による処理によってデータ記憶装置４０に保存されることになる。
【００９２】
このような合成されたブロック単位生成ファイルの生成は、例えば、過去のブロック単位生成ファイルを一旦復号化してから、これに新たなスナップショット取得情報（圧縮・暗号化なしのもの）を合成し、合成されたものを圧縮・暗号化することで行うようにしてもよい。あるいは、新たなスナップショット取得情報をまず圧縮・暗号化してから、これに対して、圧縮・暗号化されている過去のブロック単位生成ファイルを復号化せず、そのまま合成し行うようにしてもよい。
【００９３】
なお、このような合成は行わす、あらかじめ設定した定期的日時において、その都度新たに、圧縮・暗号化されたブロック単位生成ファイルを生成するようにしてもよい。しかしながら、上述のような合成では、圧縮・暗号化の処理量を抑制することができ、処理速度を向上することができる。
【００９４】
次に、図１１は、本実施形態におけるインデックスデータテーブルの構成を示すデータ構成図である。
【００９５】
本実施形態において、インデックスデータテーブルには、対象になるブロック単位生成ファイルを、特定データ項目でソートしたレコード順列の情報が保存され、これにより、該ソートのレコード順列の情報が保存される。この図１１の左側に示されるように、インデックスデータテーブルの先端にはインデックスヘッダが設けられ、続いて、上述のようにソートしたレコード順列の情報に従って、該当のレコード番号が順にインデックスレコードに保存される。このインデックスレコードの数は、対象になるブロック単位生成ファイルに含まれるレコード数と等しくなる。又、一連のインデックスレコードに続いて、インデックスデータテーブルの尾端にはインデックスフッタが設けられる。
【００９６】
例えば、図１１において、対象になるブロック単位生成ファイルに含まれるレコード数がＭであれば、そのインデックスデータテーブルに保存されるインデックスレコードの数もＭとなる。又、対象になるブロック単位生成ファイルを特定データ項目でソートしたとき、該ソート結果のブロックレコードの順序が、レコード＃３、レコード＃２４、レコード＃１、レコード＃３１……であれば、インデックスレコード１〜３には順に、「＃３」、「＃２４」、「＃１」、「＃３１」のデータが保存される。
【００９７】
ここで、このようなインデックスデータテーブルの情報は、ブロック単位生成ファイルにおけるレコード順列の情報であり、単にレコード番号のみである。従って、ブロック単位生成ファイルが圧縮・暗号化されていれば、インデックスデータテーブルは圧縮・暗号化せずとも機密性が確保される。但し、インデックスデータテーブルを圧縮・暗号化すれば、該インデックスデータテーブルのデータ量を抑制でき、これを格納する記憶手段の記憶容量の抑制などが可能になる。
【００９８】
図１２は、本実施形態において作成されるブロック単位生成ファイルの一例の情報内容を示す一覧表である。図１３は、この図１２のブロック単位生成ファイルのレコードを「社員番号」でソートした情報内容を示す一覧表である。図１４は、このようにソートした場合のインデックスデータテーブルを示すデータ構成図である。
【００９９】
図８や図９により前述した、１つ乃至は複数のブロックで構成されるブロック単位生成ファイルにおいて、この図１２に示される情報内容が保存されているものとする。
【０１００】
ここでは説明の便宜上、レコード数は「１０」で、レコード番号は「＃１」〜「＃１０」に抑えられているが、多数のレコードであれば、複数のブロックに保存されることになる。このような場合にも、本実施形態では、複数のブロックに亘ってレコード番号は連番となっている。
【０１０１】
次に、図１３では、図１２のブロック単位生成ファイルのレコードを「社員番号」でソートしている。従って、該ソートの結果、レコード番号が上から順に、「＃１」、「＃９」、「＃７」、「＃２」、「＃１０」、「＃３」、「＃４」、「＃５」、「＃８」、「＃６」となっている。なお、ソート前の図１２では、当然ながらレコード番号が上から順に、「＃１」〜「＃１０」である。
【０１０２】
ここで、図１３はソートした後の情報内容を示す一覧表であるので、該図１３の「レコード番号」の列は、該ソート後のレコード順序を示す。従って、該ソートのインデックスデータテーブルでは、このレコード順が保存されることになり、図１４に示されるように、インデックスレコード１〜１０には、該レコード順に対応する、「＃１」、「＃９」、「＃７」、「＃２」、「＃１０」、「＃３」、「＃４」、「＃５」、「＃８」、「＃６」のレコード番号のデータが順に保存される。
【０１０３】
次に、図１５は、本実施形態における保存データ閲覧処理を示すフローチャートである。
【０１０４】
このフローチャートは、前述の図６のステップＳ１１４のステップＳ１１４の保存データ閲覧処理の内容を示すものである。
【０１０５】
このフローチャートにおいて、まず、ステップＳ１６０では、閲覧処理部３４は、クライアント装置５から情報閲覧の指示入力を受け付けたり、情報の検索の指示入力を受け付けたりする。情報の検索の指示入力を受け付けた場合、ステップＳ１６２では、インデックスデータテーブルを用い、データ管理保存処理部３０の処理によってデータ記憶装置４０に格納されているテーブルのレコードを検索する際、ブロック検索処理部３６は、該閲覧処理部３４からの入力に応じて、まず対象レコードがどのブロックに格納されているか予測しつつ、ブロック別復号化処理部３２により、予測されたブロックの圧縮・暗号化の伸張・復号を行ってから該ブロックにおける検索を行う。この検索結果は、該ブロック別復号化処理部３２から閲覧処理部３４を経て、クライアント装置５に出力される。これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張・復号及び検索を行う。
【０１０６】
ステップＳ１６４では、データ記憶装置４０に格納されている情報で、上述のように予測されたブロックの伸張・復号を行う。続いて、ステップＳ１６６では、このように伸張・復号されたブロックの情報を閲覧に供する。ここで、検索結果や並べ替え結果などを閲覧に供する場合、クライアント装置５は、１つ乃至は複数の対象のブロックの情報に基づいて、閲覧に供する情報を生成する。
【０１０７】
例えば、図１６は、本実施形態においてこのような保存データ閲覧処理における閲覧画面を示す表示画面図である。
【０１０８】
この図において、「２００８１２０４（／標準ＤＢ／管理／組織別社員台帳）」とある表示行は、クライアント装置５から利用者が入力した閲覧希望の入力に従った、ブロック単位生成ファイルのファイル名を示す。又、この閲覧結果は、「事業所」、「部署名」、「社員番号」、「社員名」、「住所」の社員一覧リストとして表示されている。
【０１０９】
なお、本実施形態における閲覧結果は、このような画面表示に加えて、ＣＳＶ形式やＸＭＬ形式によるファイル出力によっても提供できるようになっている。
【０１１０】
図１７は、このような保存データ閲覧処理における参照レコード群抽出を示すデータ構成図である。
【０１１１】
この図において、「２００８１２０４（／標準ＤＢ／管理／組織別社員台帳）」と、クライアント装置５から閲覧処理部３４に対して閲覧対象が指示入力されると、閲覧処理部３４及びブロック別復号化処理部３２は、閲覧すべきファイル（参照ファイル）を見いだすと共に、該参照ファイルにおいて閲覧すべきブロック（参照ブロック）を見いだし、更には、閲覧すべきレコード群（参照レコード群）を見いだす。
【０１１２】
例えば、ある参照ファイルにおいて、Ｘ番目のレコードを閲覧する場合、このレコードが含まれるブロックのブロック番号Ｙは、以下のように算出することができる。ここで、ａは、１ブロックあたりのレコード数である。
【０１１３】
Ｙ＝（Ｘ−１）／ａ＋１
ここで、ブロックのフッタ内には、そのブロックの位置が格納されているテーブルが格納されている。従って、対象ブロックへのアクセスは、このフッタ内の情報を用いる。
【０１１４】
又、インデックスに格納されているレコード番号から、データへのアクセスは以下の（１）〜（３）のようになる。
【０１１５】
（１） レコード番号より、以下の計算式でブロック番号を取得する。
（レコード番号−１）／１ブロック内のレコード数＋１＝ブロック番号
ここで、「（レコード番号−１）」は、レコード番号が１相対であるための処理である。又、最後の「＋１」は、ブロック番号が１相対であるための処理である。レコード番号が１０で、１ブロック内のレコード数が２００の場合、「９／２００＋１＝１」となる。よって、ブロック番号は１となる。
【０１１６】
（２） データファイル内のフッタより、該当ブロック番号のデータ位置を取得する。
【０１１７】
（３） 対象位置のブロックを読み込む。
【０１１８】
次に、図１８は、本実施形態の保存データ閲覧処理における検索画面を示す表示画面図である。
【０１１９】
この図において背景側になっているウインドウでは、「登録日」、「会員名」、「取扱部店名」、「銘柄名」、「市場」、「取扱銘柄」、「公表区分」、「売気配」、「売提示日」、「買気配」、「買提示日」のデータを備えるレコードのリストが表示されている。又、選択表示されているウインドウでは、これらデータによって、「前方一致」、「中間一致」、「完全一致」などの選択をしながら検索が可能になっている。
【０１２０】
ここで、図１２〜図１４により前述したインデックスデータテーブルにおいて、「社員番号」が「６００６」である社員のレコードを、二分検索法により検索する例について説明する。この場合、検索キーは「社員番号」が「６００６」となる。
【０１２１】
図１４のインデックスデータテーブルにおいて、全インデックスレコード１〜１０の真ん中は、該図１４中の（１）で図示されるように、インデックスレコード５であり、該インデックスレコード５にはレコード番号「＃１０」が保存されている。図１２のブロック単位生成ファイルにおいて、このレコード番号「＃１０」のレコードを参照すると、「社員番号」は「６０２５」であり、検索キーの「６００６」より大であると判定される。
【０１２２】
大と判定されたので、今度はインデックスレコード１〜４を検索対象とし、この真ん中は、該図１４中の（２）で図示されるようにインデックスレコード２であり、該インデックスレコード２には図１４においてレコード番号「＃９」が保存されている。図１２のブロック単位生成ファイルにおいて、このレコード番号「＃９」のレコードを参照すると、「社員番号」は「１０１９」であり、検索キーの「６００６」より小であると判定される。
【０１２３】
小と判定されたので、今度はインデックスレコード３〜４を検索対象とし、この真ん中は、該図１４中の（３）で図示されるようにインデックスレコード３であり、該インデックスレコード３には図１４においてレコード番号「＃７」が保存されている。図１２のブロック単位生成ファイルにおいて、このレコード番号「＃７」のレコードを参照すると、「社員番号」は「６００６」であり、検索キーの「６００６」と一致と判定される。
【０１２４】
該一致判定により、検索結果として、図１２のブロック単位生成ファイルにおける、レコード番号「＃７」のレコードを取得することになる。
【０１２５】
このように検索結果が得られた後には、ブロック別復号化処理部３２において、検索されたレコードが含まれるブロックの復号化処理を行う。
【０１２６】
ここで、本実施形態では、検索されたレコードの情報と共に、例えば前述の図１６の閲覧画面と同様に、復号化されたブロックの他のレコードも同時に閲覧に供することができる。例えば、検索されたレコードの情報に加えて、該レコードが含まれるブロックにおいて、該レコードの前後の複数のレコードも併せて閲覧に供することができる。
【０１２７】
なお、以上において、インデックスデータテーブルを用いた二分検索法による、ブロック単位生成ファイルのレコードの検索処理の例について説明した。ほぼ同様に、本実施形態では、インデックスデータテーブルを用いて、ブロック単位生成ファイルのレコードのソート処理も行うことが可能である。
【０１２８】
なお、本実施形態においては、ブロック単位生成ファイルが複数のブロックで構成される場合に、レコード番号は、複数ブロックに亘る連番を採用している。従って、関係する全レコードをより少ないデータ長で識別することができる。従って、インデックスデータテーブルを格納するために必要な記憶手段の記憶容量を抑えることが可能となり、システムのリソースを抑えることができる。
【０１２９】
例えば、個々のレコードを、そのレコードが存在するブロックの番号、及び該ブロック中におけるそのレコードの番号で表わすことも考えられる。しかしながら、この場合、これらブロック番号及びレコード番号の合計データ長は、本実施形態の場合に比べて長くなり冗長になる。
【０１３０】
なお、本実施形態において、インデックスデータテーブルのインデックスレコードのデータ長を、対象になるブロック単位生成ファイルの総レコード数に応じて可変長することもできる。この場合、ブロック単位生成ファイルの総レコード数に応じて、インデックスデータテーブルの記憶容量を抑えることができる。
【０１３１】
図１９は本実施形態におけるバックアップ復元処理を示すフローチャートである。
【０１３２】
本実施形態では、データ管理保存装置１０は、将来のクライアント装置５からの閲覧を目的として、管理対象ＤＢ装置の各装置それぞれにおけるテーブル形式のデータをスナップショット取得しデータ記憶装置４０に保存している。
【０１３３】
ここで、このように保存されているデータにより、対象の装置に格納されている情報を、スナップショット取得の時点に復元することも考えられる。この図１９は、このようなバックアップ復元処理を示すものである。なお、前述の図１においては、二点鎖線の矢印により、このようなバックアップ復元処理による元ファイルの復元が示される。
【０１３４】
ステップＳ１８０では、データ管理保存装置１０の閲覧処理部３４は、クライアント装置５からこのようなバックアップ復元要求の、利用者からの入力を受け付ける。ステップＳ１８２では、復元すべき装置のファイル、又、この復元に用いる、データ記憶装置４０に保存されているファィルを見いだすなどの復元準備処理を行う。
【０１３５】
ステップＳ１８４では、復元に用いる、データ記憶装置４０に保存されているファィルの復号化処理を行う。ステップＳ１８６では、復号化されたファイルを用いて、復元すべき装置のファイルを、利用者からのクライアント装置５における入力で指示された時点に復元する。
【０１３６】
なお、以上に説明したように、前述の図５に示されるデータ管理保存装置１０における各処理部及びデータ記憶装置４０は、図１や図２におけるデータ管理保存装置１０において構成している。しかしながら、本実施形態は、このようなものに限定されるものではない。例えば、図１や図２の会計管理サーバ装置５６などにおいて、複合的にデータ管理保存装置１０を構成し、該会計管理サーバ装置５６などにおいて図５に示されるデータ管理保存装置１０における各処理部及びデータ記憶装置４０を構成するようにしてもよい。会計管理サーバ装置５６において複合的にデータ管理保存装置１０を構成する場合、データ記憶装置４０は、会計管理サーバ装置５６が備えるデータベース装置や記憶装置に設けるようにしてもよい。
【実施例】
【０１３７】
図２０は、本発明が適用された第１実施例の処理を示すフローチャートである。
【０１３８】
本実施例は、以上に説明した実施形態において、管理対象ＤＢ装置を、経理情報を少なくとも保存しているデータベースである会計管理サーバ装置５６としている。又、前述の定期的日時を、経理業務上、情報が確定する日次及び月次の日時としている。
【０１３９】
このフローチャートは、前述の図４のフローチャート全体に対応するものである。又、この図４のフローチャートのステップＳ１０４である「データ管理保存業務処理」は、前述の図６のフローチャート全体に示されるとおりである。従って、本実施例の図２０のフローチャートは、この図４のステップＳ１０４に図６のフローチャート全体を盛り込んだものである。
【０１４０】
更に、この図２０に示されるように、ステップＳ１１２の「データ管理保存処理」は、本実施例では、ステップＳ２１０の「日次スナップショット処理」、及びステップＳ２１２の「月次情報合成処理」によって構成されている。又、本実施例において以下に述べる第１の定期的日時及び第２の定期的日時の設定は、前述したステップＳ１１０における業務設定処理において行うことができる。なお、第１の定期的日時は日次、第２の定期的日時は月次としてもよいが、これらに限定されるものではない。例えば、第２の定期的日時を、第１の定期的日時より長期周期となる、決算時期の四半期次や年次などとしてもよい。
【０１４１】
上記のステップＳ２１０の「日次スナップショット処理」では、日次（第１の定期的日時）で、該データベースの情報のスナップショット取得、該取得の情報に対する前述したブロック分けの編成によるブロック単位生成ファイルの生成、及び、該ブロック単位生成ファイルの圧縮・暗号化を行って、データ記憶装置４０（データ管理保存データベース）に格納する。
【０１４２】
なお、このステップＳ２１０では、スナップショット取得から少なくともブロック分け編成までの処理を行うものである。例えば、圧縮・暗号化は省いて、ブロック分け編成までの処理を行ったブロック単位生成ファイルをデータ記憶装置４０（データ管理保存データベース）に格納するようにしてもよい。但し、圧縮・暗号化を行うことで、該データ記憶装置４０に必要な記憶容量の一層の低減や、セキュリティの安全性の一層の向上を図ることができる。
【０１４３】
又、上記のステップＳ２１２の「月次情報合成処理」では、月次（第２の定期的日時）で、日次で格納している複数の該ブロック単位生成ファイルから、月次単位の該ブロック単位生成ファイルを合成する。
【０１４４】
本実施例のこのファイル合成は具体的に限定されるものではなく、該ファイル合成に際して行われるブロック単位生成ファイルの合成処理や、インデックスデータテーブルの作成処理について具体的に限定されるものではない。例えば、これらブロック単位生成ファイルの合成処理、及びインデックスデータテーブルの作成処理は、該ファイル合成において、いずれか一方のみ行うものであってもよい。
【０１４５】
又、該ファイル合成の際のブロック単位生成ファイルの合成処理については、例えば、日次で得ている過去の対象期間の複数のブロック単位生成ファイルを一旦復号化してから、これらを合成し、合成されたものを圧縮・暗号化することで行うようにしてもよい。あるいは、これら対象期間の複数のブロック単位生成ファイルを復号化せず、そのまま合成し行うようにしてもよい。
【０１４６】
該ファイル合成の際のインデックスデータテーブルの作成についても、具体的に限定されるものではない。このインデックスデータテーブル作成の処理については、日次で、過去の対象期間の複数のブロック単位生成ファイルの生成時に作成されたインデックスデータテーブルを合成し、これにより、月次単位のインデックスデータテーブルを作成してもよい。あるいは、月次で、ブロック単位生成ファイルを合成する際に、同時に新たに月次単位のインデックスデータテーブルを作成してもよい。
【０１４７】
ここで、図２１は、本実施例が処理対象とする情報の一例を示すデータ構成図である。
【０１４８】
図２０のステップＳ１００や前述の図４のステップＳ１００では、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２などによる、それぞれの該当業務において、様々な情報が発生している。このような業務別の情報の内、経理や会計に係わる諸費用情報は、ステップＳ１０２において、適宜会計管理サーバ装置５６に集約され、該会計管理サーバ装置５６において仕訳帳や総勘定元帳などが作成される。この図２１や後述する図２３では、このような会計管理サーバ装置５６で取得されたり、作成されたりする情報を総称して明細会計情報としている。
【０１４９】
図２１では、明細会計情報Ａ１〜Ａ３は「２０１１／５／１」に、明細会計情報Ｂ１〜Ｂ３は「２０１１／５／３０」に、明細会計情報Ｃ１〜Ｃ３は「２０１１／５／３１」に、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２などから適宜会計管理サーバ装置５６において集約され、作成された情報である。
【０１５０】
続いて、ステップＳ１１０では、定期的日時の手動あるいは自動の設定や、自動の場合の第１の定期的日時及び第２の定期的日時の設定など、各種の設定を適宜行う。なお、本実施例では、「自動」設定であり、又、定期的日時に関しては、「日次スナップショット処理」の日時設定（日毎の時間設定（第１の定期的日時設定））や処理内容、「月次情報合成処理」の日時設定（月毎の日時設定（第２の定期的日時設定））や処理内容の設定を行う。
【０１５１】
次に、ステップＳ１１２のステップＳ２１０の「日次スナップショット処理」では、図２１の矢印Ｄ１〜Ｄ３で示されるように、圧縮・暗号化された日次会計情報Ｅ１〜Ｅ３（ブロック単位生成ファイル）が生成され、データ記憶装置４０に格納される。該生成は、日次（第１の定期的日時）で行われるものであり、会計管理サーバ装置５６にある明細会計情報のスナップショット取得、該取得の情報に対するブロック分けの編成による日次会計情報（ブロック単位生成ファイル）の生成、及び、該日次会計情報の圧縮・暗号化によるものである。
【０１５２】
続いて、ステップＳ１１２のステップＳ２１２の「月次情報合成処理」では、図２１の矢印Ｆ１で示されるように、月次（第２の定期的日時）で、上述のように日次で格納している日次会計情報から、月次単位の月次会計情報（ブロック単位生成ファイル）を合成する。この図２１の例では、２０１１年５月の月次会計情報を合成し生成しているが、この合成及び生成の処理は、例えば、翌月の２０１１年６月の１日に行う。
【０１５３】
本実施例では、スナップショット取得しながら圧縮・暗号化によって取得される情報（日次会計情報）は日付毎であるが、毎月の月初めに前月のものが月次会計情報に合成されるので、後日の検索時には対象となるファイルの数が少なくなる。従って、検索処理の処理量が削減され、処理能率が向上される。
【０１５４】
ここで、本実施例は、会計情報が一日毎で確定する場合を想定したものである。
【０１５５】
次に、図２２は、本発明が適用された第２実施例の処理を示すフローチャートである。
【０１５６】
本実施例は、上述の第１実施例のステップＳ１１２の「データ管理保存処理」が、ステップＳ２２０の「月次スナップショット処理」により構成され、日次会計情報（ブロック単位生成ファイル）の合成は行わない。
【０１５７】
本実施例において、前述した定期的日時は、経理業務上、情報が確定する月次の日時となっている。ステップＳ１１０では、本実施例では「自動」を設定し、又、「月次スナップショット処理」の日時設定（月毎の日時設定（定期的日時設定））や処理内容の設定を適宜行う。
【０１５８】
ここで、図２３は、本実施例が処理対象とする情報の一例を示すデータ構成図である。
【０１５９】
図２３では、明細会計情報Ｋ１〜Ｋ３は「２０１１／５／１」に、明細会計情報Ｌ１〜Ｌ３は「２０１１／５／３１」に、明細会計情報Ｍ１〜Ｍ３は「２０１１／６／１」に、明細会計情報Ｎ１〜Ｎ３は「２０１１／６／３０」に、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２などから会計管理サーバ装置５６において適宜集約され、作成された情報である。
【０１６０】
本実施例の図２２のステップＳ２２０の「月次スナップショット処理」では、図２３の矢印Ｐ１、Ｐ２で示されるように、圧縮・暗号化された月次会計情報Ｑ１、Ｑ２（ブロック単位生成ファイル）が生成され、データ記憶装置４０に格納される。該生成は、月次（定期的日時）で行われるものであり、会計管理サーバ装置５６にある明細会計情報のスナップショット取得、該取得の情報に対するブロック分けの編成による月次会計情報（ブロック単位生成ファイル）の生成、及び、該月次会計情報の圧縮・暗号化によるものである。
【０１６１】
このように、本実施例では、ブロック単位生成ファイルの合成は行わず、ステップＳ２２０の「月次スナップショット処理」において、その都度新たに、圧縮・暗号化されたブロック単位生成ファイルを生成するようにしている。このような本実施例と比較することで、合成処理を行う前述の第１実施例は、全体として圧縮・暗号化の処理量を抑制することができ、処理速度を向上することができることがわかる。
【０１６２】
又、以上に説明したように、本実施例や前述の第１実施例では、検索その他に用いるインデックスデータテーブルの作成は、限られた期間の情報を対象に作成している。従って、このように期間を限らず、例えばＲＤＢ（Relational Data Base）全体を対象にインデックスデータテーブルを作成する場合に比べて、格段に処理能率を向上することができる。
【０１６３】
ここで、インデックスデータテーブルは、前述の第１実施例では、日次で作成され、場合によっては月次でも合成ないしは新規作成される。又、本第２実施例では、インデックスデータテーブルは、月次で作成される。従って、インデックスデータテーブルは、分割されたものとなり、検索時には、利用するインデックスデータテーブルの数が増加する可能性が生じるが、通常の検索処理では問題は生じない。
【０１６４】
又、図２１や図２３における明細日付のような個々の情報の期日も１つの検索キーとし、検索する場合も考えられる。例えば、税務監査などでは、このように検索対象の情報の期間を限定するケースが多くなる。このような場合、これら実施例では、インデックスデータテーブルが分割されているので、個々のインデックスデータテーブルのデータ量は少なくなるので、検索キーの期日の情報が含まれるインデックスデータテーブルを選択することで、能率よく検索処理を行うことができる。
【０１６５】
ここで、本第２実施例は、会計情報が一ヶ月毎で確定する場合を想定し、情報量が大量な場合を想定したものである。
【符号の説明】
【０１６６】
１…ネットワーク
５…クライアント装置
１０…データ管理保存装置
１２…管理対象サーバ装置
２２…スナップショット処理部
２４…ブロック化処理部
２６…ブロック別圧縮・暗号化処理部
２８…インデックスデータテーブル作成処理部
３０…データ管理保存処理部
３２…ブロック別復号化処理部
３４…閲覧処理部
３６…ブロック検索処理部
４０…データ記憶装置
５０…購買管理サーバ装置
５１…在庫管理サーバ装置
５２…販売管理サーバ装置
５６…会計管理サーバ装置
３０１〜３０３…バス
３１０…ＣＰＵ
３１１…ＲＡＭ
３１２…ＲＯＭ
３１３…ＬＡＮ−Ｉ／Ｆ
３１４…ＭＯＤＥＭ
３２０〜３２２…Ｉ／Ｆ
３３０…画面表示装置
３３１…キーボード
３３２…マウス
３３３…プリンタ装置
３４０…ＨＤＤ装置
３４１…ＣＤドライブ装置
３４２…ＦＤＤ装置
【技術分野】
【０００１】
本発明は、データ管理保存システムに係り、特に、効率よくデータ圧縮することでリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とし、更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができるデータ管理保存方法、データ管理保存装置、又、これらデータ管理保存方法及びデータ管理保存装置を実施するためのコンピュータ・プログラムに関する。
【背景技術】
【０００２】
会計システムとして、ＳＡＰを代表とするＥＲＰ（Enterprise Resource Planning）への移行、メインフレームから分散系システムへの移行（ダウンサイジング）が見られ、分散系のＤＢ（Data Base）アプリケーションシステムも多く採用されている。当初、ＥＲＰシステムへの移行に伴って、税法で定められた取引明細等の長期保存は可能と思われた。
【０００３】
しかしながら、保存される情報が増加するにつれ、情報格納リソースを圧迫することになり、過去分はＭＴ（Magnetic Tape）等に退避することになる。会計情報は税法上７年間の保存義務があるが、ほとんどの企業は１〜２年分の情報しかオンラインでアクセスすることができず、これ以前の情報はＭＴその他オフラインで保存することになる。従って、国税審査官は、オンラインのシステム上にない情報についてはバッチでオフラインのものから必要なデータを出力してもらい、これをマイクロソフト社のＡＣＣＥＳＳなどの帳票オフィスソフトにインポートして監査を行っている。
【０００４】
又、会計情報などの重要な情報は、情報の改ざんや流出の対策を十分に講じる必要があり、長期保存で大量保存の情報であれば被害が膨大になるおそれもあり、なおさら徹底した対策を講じる必要がある。従って、高速アクセスや検索を可能としながらも、同時に、暗号化によるデータ改ざん防止とセキュリティの確保が十分になされる必要がある。
【０００５】
ここで、特許文献１では、バックアップ・プロセスの間でもユーザがシステムに無制限にアクセスすることができ、しかも再構成を必要としないスナップショット・バックアップ・イメージを、素早くかつ一貫的なバックアップとしてＭＴ上に作成できるようにするという技術が開示されている。
【０００６】
又、特許文献２では、ディスク使用効率の良い差分情報を使用したスナップショット管理手法でありながら、書き込み性能の劣化が無く、運用停止時間および運用再開時間を最小限に押さえる復元機能を持つスナップショット機能を有するスナップショット管理システムについて開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００１−５２０７７９号公報
【特許文献２】特開２０１０−７９３３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１及び特許文献２については、前述のような会計情報の特性について配慮されておらず、重要な大量情報の長期保存と、その高速アクセスや高速検索を可能としながらも、同時に、暗号化によるデータ改ざん防止とセキュリティの確保を十分に図る点については開示されていない。
【０００９】
データ圧縮については、過去１〜２年分の情報しかオンラインでアクセスすることができない記憶装置や処理装置などのリソースにおいて、税法上７年間の会計情報を保存するには、データ圧縮を徹底する必要がある。又、高い圧縮倍率でも、検索などのアクセス性能は十分確保しなければならないことは言うまでもない。
【００１０】
本発明は、前記従来の問題点を解決するべくなされたもので、データ管理保存システムに係り、特に、効率よくデータ圧縮することでリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とし、更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができるデータ管理保存システムを提供することを課題とする。
【課題を解決するための手段】
【００１１】
本発明は、時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得すると共に、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成してから、該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化して、データ管理保存データベースに格納し、スナップショットしたテーブルの閲覧の際には、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うようにしたことにより、該ブロックは、効果的に圧縮倍率が上昇する単位で編成することができ、リソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とすることができる。更には、暗号化によるデータ改ざん防止とセキュリティの確保を可能とすることができる。
【００１２】
ここで、上述のようにスナップショット取得の対象になる、管理対象のデータベースに格納されているデータとしては、例えば、時系列的に発生するデータ（情報）で、テーブル形式で格納されているデータ（情報）がある。このようにテーブル形式のデータ（情報）であれば、一般に、レコード相互に類似するデータが多くなるため、本願発明におけるブロック単位での圧縮・暗号化の圧縮倍率がより一層上昇する。
【００１３】
又、スナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートした、レコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成し、該インデックスデータテーブルを前記データ管理保存データベースに格納するようにしたことにより、圧縮された情報のより一層の高速アクセスを可能とすることができる。
【００１４】
更には、上記のインデックスデータテーブルを用いて、前記データ管理保存データベースに格納の前記ブロック単位生成ファイルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測しつつ、予測されたブロックの前記圧縮・暗号化の伸張・復号を行ってから該ブロックにおいて検索を行うようにし、これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張・復号及び検索を行いながら、検索結果を閲覧に供するようにしたことにより、圧縮された情報のより一層の高速アクセスや高速検索を可能とすることができる。
【００１５】
更に、上記のインデックスデータテーブルが、複数のブロックに亘る連番のレコード番号の順列によって、前記レコード順列情報が保存されていることにより、該インデックスデータテーブルにおいてレコード順列情報のデータ量を抑制することができる。
【００１６】
又、上述のブロック単位生成ファイルの圧縮・暗号化を、予め設定された定期的日時の単位で合成し、前記データ管理保存データベースに格納することができる。この定期的日時は、対象システムの運用閑散時期や、対象情報の圧縮効率が向上する時期に設定することができる。
【００１７】
あるいは、前記スナップショット取得から少なくとも前記ブロック分け編成までの処理を、経理業務上、情報が確定する第１の定期的日時の単位で行うと共に、該第１の定期的日時より長期周期となる第２の定期的日時で、異なる該第１の定期的日時において前記ブロック分け編成されたブロック単位生成ファイルから、別のブロック単位生成ファイルを合成すると、対象情報の処理能率や圧縮効率を向上することができる。なお、上記の第１の定期的日時を、経理業務上、情報が確定する日次とし、上記の第２の定期的日時を、経理業務上、情報が確定する月次とすることもできる。あるいは、該第２の定期的日時を、上記の第１の定期的日時より長期周期となる、決算時期の四半期次や半期次や年次などとしてもよい。又、第１の定期的日時については、第２の定期的日時より短期周期となるものであればよく、日次に限定されるものではなく、場合によっては不定期であってもよい。
【００１８】
次に、本発明は、時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得するスナップショット処理部と、スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成するブロック化処理部と、該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化するブロック別圧縮・暗号化処理部と、スナップショット取得したテーブル単位で、該テーブルに含まれるレコードを特定データでソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理部と、前記圧縮・暗号化の情報、及び該インデックスデータテーブルを格納するデータ管理保存データベースと、スナップショットしたテーブルの閲覧の際に、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うブロック別復号化処理部と、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測し、予測されたブロックの前記圧縮・暗号化の伸張・復号を行って該ブロックを検索し、これにより、検索対象のテーブルを逐次部分的に伸張・復号を行いながら、検索結果を取得するブロック検索処理部と、該検索結果を利用者の閲覧に供する閲覧処理部と、を備えたことにより、該ブロックを、効率よくデータ圧縮することができるように編成することで、リソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現すると共に、高速アクセスや高速検索を可能とすることができる。更には、該ブロックの圧縮・暗号化によって、データ改ざん防止とセキュリティの確保を可能とすることができる。
【００１９】
ここで、上述のようにスナップショット取得の対象になる、管理対象のデータベースに格納されているデータとしては、例えば、時系列的に発生するデータ（情報）で、テーブル形式で格納されているデータ（情報）がある。このようにテーブル形式のデータ（情報）であれば、前述のように、本願発明におけるブロック単位での圧縮・暗号化の圧縮倍率がより一層上昇する。
【００２０】
以上のデータ管理保存方法及びデータ管理保存装置は、コンピュータ・プログラムによって実現することができる。
【発明の効果】
【００２１】
本発明によれば、対象になる情報を、効率よくデータ圧縮することができるブロックに分割して、ブロック単位生成ファイルに編成することができる。従ってデータ圧縮効率を高めてリソースの削減を図りながら、取引履歴等の情報の大量保存及び長期保存を実現することができる。このようなデータ圧縮効率の向上及びリソースの削減によって、従来オフライン保存とされていた大量の情報のオンライン保存化を図ることによって、高速アクセスや高速検索を可能とすることができる。
【００２２】
更には、対象となる大量の情報は、ブロックに分割して編成した上で圧縮・暗号化されるので、データ改ざん防止とセキュリティの確保を可能とすることができる。
【００２３】
又、本発明のブロックは、スナップショット取得したテーブルデータを後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数により編成するようにしている。このようなブロック分けの編成は、後日閲覧する際の、アクセスや検索の便宜を図るためのインデックスデータテーブルを作成するのに好適である。例えば、このようにブロック分け編成されたレコードを、該レコード中の特定データ項目でソートした、レコード順列を示す情報が少なくとも保存されるインデックスデータテーブルを作成することも可能である。該インデックスデータテーブルを用いることで、ブロックの伸張・復号をする以前に、必要なレコードがどのブロックに存在するか把握することができ、必要なレコードを含む該当のブロックのみ伸張・復号することができ、情報の高速アクセスが可能になる。
【００２４】
又、閲覧対象の情報本体が格納されるブロック単位生成ファイル自体が、ＭＴなどに保存されオフラインであっても、インデックスデータテーブルにアクセスできれば、ブロック単位生成ファイル自体にアクセス以前に、必要なレコードが該ブロック単位生成ファイルにおいてどのブロックに存在するか把握することができる。従って、オフラインのブロック単位生成ファイルにおいて、最低限のブロックのみ読み出して伸張・復号すればよいので、能率よくアクセスや検索を行うことが可能となる。
【００２５】
なお、インデックスデータテーブルにおいて、複数のブロックに亘る連番のレコード番号の順列によって、レコード順列情報を保存するようにしてもよい。この場合、関係する全レコードをより少ないデータ長で識別することができる。従って、インデックスデータテーブルを格納するために必要な記憶手段の記憶容量を抑えることが可能となり、システムのリソースを抑えることができる。
【００２６】
更に、経理情報や会計情報などは、業務上、情報が確定する日次又は月次が存在するので、このような日次又は月次に、本発明を適用した定期的なスナップショット取得を行うようにすると、このスナップショット取得を自動的に行えるだけでなく、ブロック単位の圧縮・暗号化の圧縮率向上を図ることができる。
【００２７】
更には、定期的なスナップショット取得によって、スナップショット取得された情報が時系列に保存され、本発明のブロックに分割されることになる。通常検索する場合は、日時を絞って行うため、このような検索に好適な取得情報の保存やインデックスの作成時間の短縮を図ることができると共に、該検索のレスポンスの向上を図ることができる。
【図面の簡単な説明】
【００２８】
【図１】本発明が適用される実施形態のデータ管理保存システムが導入された企業基幹システムの全体的な構成を示すブロック図
【図２】上記企業基幹システムの全体的なハードウェアの構成を示すブロック図
【図３】前記企業基幹システムで用いられるコンピュータ装置のハードウェア構成を示すブロック図
【図４】前記実施形態における基幹業務を示すフローチャート
【図５】前記実施形態に用いられるデータ管理保存装置の構成を示すブロック図
【図６】前記実施形態におけるデータ管理保存業務処理を示すフローチャート
【図７】前記実施形態におけるデータ管理保存処理を示すフローチャート
【図８】前記実施形態におけるスナップショット取得情報（ＣＳＶ形式ファィル）とブロック単位生成ファイルの関係を示すデータ構成図
【図９】前記実施形態におけるブロック単位生成ファイルの構成を示すデータ構成図
【図１０】前記実施形態において定期的日時に生成するブロック単位生成ファイルを示すデータ構成図
【図１１】前記実施形態におけるインデックスデータテーブルの構成を示すデータ構成図
【図１２】前記実施形態において作成されるブロック単位生成ファイルの一例の情報内容を示す一覧表
【図１３】上記ブロック単位生成ファイルのレコードを「社員番号」でソートした情報内容を示す一覧表
【図１４】上記ブロック単位生成ファイル例を「社員番号」でソートした場合のインデックスデータテーブルを示すデータ構成図
【図１５】前記実施形態における保存データ閲覧処理を示すフローチャート
【図１６】上記保存データ閲覧処理における閲覧画面を示す線図
【図１７】上記保存データ閲覧処理における参照レコード群抽出を示すデータ構成図
【図１８】上記保存データ閲覧処理における検索画面を示す線図
【図１９】前記実施形態におけるバックアップ復元処理を示すフローチャート
【図２０】本発明が適用された第１実施例の処理を示すフローチャート
【図２１】上記実施例が処理対象とする情報の一例を示すデータ構成図
【図２２】本発明が適用された第２実施例の処理を示すフローチャート
【図２３】上記実施例が処理対象とする情報の一例を示すデータ構成図
【発明を実施するための形態】
【００２９】
以下図面を参照して、本発明の実施形態を詳細に説明する。
【００３０】
図１は、本発明が適用される実施形態のデータ管理保存システムが導入された企業基幹システムの全体的な構成を示すブロック図である。
【００３１】
この図において、企業の購買部門、資材部門、販売管理部門、会計部門それぞれにおいて、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６が設けられている。これら購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６は、いずれも分散系のＤＢ（Data Base）アプリケーションシステムにより構築され、又全体としてＥＲＰが適用されている。
【００３２】
購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２で発生する諸費用情報は、ＣＳＶ（Comma Separated Value）やＸＭＬ（extensible markup language）などの汎用形式、あるいは専用形式のファイル交換により、適宜会計管理サーバ装置５６に集約され、統合されていわゆる仕訳帳や総勘定元帳などが作成され、これらは会計情報として活用されている。
【００３３】
このような企業基幹システムにおいて、本実施形態のデータ管理保存装置１０が導入されている。これら購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６は、本実施形態のデータ管理保存装置１０が本発明を適用した管理の対象にする装置である。以下、これら装置を管理対象ＤＢ装置と呼ぶ。これら管理対象ＤＢ装置は、時系列的に発生するデータがテーブル形式のファイル（以下元ファイルと呼ぶ）で格納されている管理対象のデータベースを備えている。
【００３４】
又、データ管理保存装置１０は、これら元ファイルの情報を、本発明を適用して、ＣＳＶ形式やＸＭＬ形式など所定ファイル形式の情報（以下スナップショット取得情報と呼ぶ）にて定期的にスナップショット取得し、保存する。これにより、後日、スナップショットした時点におけるテーブルの情報を閲覧に供することができるようになっている。なお、この図１では、一点鎖線の矢印により、このようなナップショット取得情報を取得する処理が示される。
【００３５】
ここで、上記のスナップショット取得情報は、元ファイルのそのままのファイル形式であってもよい。あるいは、元ファイルの情報をバイナリデータとして直接取得するものであってもよい。更には、元ファイルの情報の実体的内容を、ＣＳＶ形式やＸＭＬ形式その他の汎用形式、あるいは専用形式に一旦変換したものであってもよい。
【００３６】
図２は、本実施形態の企業基幹システムの全体的なハードウェアの構成を示すブロック図である。
【００３７】
前述の図１に示した本実施例が対象とする企業基幹システムは、この図２に示されるように、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６、更にはデータ管理保存装置１０が相互に、ネットワーク１により接続されている。加えて、これら装置に接続するクライアント装置５も、ネットワーク１により接続されている。該接続により、前述のような汎用形式や専用形式のファイル交換がなされる。
【００３８】
なお、ネットワーク１は、特に限定されるものではない。公衆回線あるいは専用回線を用いるものでも、インターネットやＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）を用いるものでも、あるいはこれらを複合的に接続し構成するものであってもよい。
【００３９】
図３は、本実施形態の各装置に用いるコンピュータ装置のハードウェアの構成を示すブロック図である。
【００４０】
この図３においては、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６、更にはデータ管理保存装置１０の各装置として利用可能な、ある種のコンピュータ装置のハードウェア構成が示される。しかしながら、各装置は、このようなものに限定されるものではない。
【００４１】
図３の該コンピュータ装置は、ＯＳ（Operating System）は一例として米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）を搭載する、一般的なＰＣ（Personal Computer）装置であってもよく、特に限定されものではない。あるいは、ＰＣ装置以外のハードウェアを用いてもよく、例えばＥＷＳ（Engineering Work Station）などの、いわゆるワークステーションなどのハードウェアを用いるようにしてもよい。なお、この図において、ハードウェア構成は、説明の関係上一部抽象化されている。
【００４２】
この図において、コンピュータ装置は、ＣＰＵ（Central Processing Unit）３１０と、ＲＡＭ（Random Access Memory）３１１と、ＲＯＭ（Read Only Memory）３１２と、ＬＡＮ−Ｉ／Ｆ（Inter Face）３１３と、ＭＯＤＥＭ（modulator-demodulator）３１４と、種々のＩ／Ｆ３２０〜３２２とを有している。これらは、バス３０１によって相互接続されている。
【００４３】
なお、ＬＡＮ−Ｉ／Ｆ３１３は、ネットワーク１に対して接続するために用いられる。
【００４４】
又、バス３０１に対して、Ｉ／Ｆ３２０を介して、画面表示装置３３０が接続されている。又、バス３０３によって相互接続されている、キーボード３３１と、マウス３３２と、プリンタ装置３３３とは、バス３０１に対して、Ｉ／Ｆ３２１を介して接続されている。
【００４５】
更に、バス３０１に対して、Ｉ／Ｆ３２２を介して、ＨＤＤ（Hard Disc Drive）装置３４０と、ＣＤ（Compact Disc）ドライブ装置３４１と、ＦＤＤ（Floppy（登録商標） Disc Drive）装置３４２とが接続されている。これらはバス３０２によって相互接続されている。
【００４６】
以上のようなハードウェア構成において、記憶手段、又記憶装置は、ＲＡＭ３１１、ＲＯＭ３１２、ＨＤＤ装置３４０、ＣＤドライブ装置３４１、ＦＤＤ装置３４２などである。このような記憶手段や記憶装置において、ＣＰＵ３１０で実行される様々なプログラムや、本実施形態においてアクセスされるデータベースや諸ファイルやデータが保存され、電子的にアクセスができるようになっている。例えば、ＯＳや、データベースやＪＡＶＡ（登録商標)やＪＳＰ（Java（登録商標) Server Page）などのソフトウェア資源を利用する環境を提供するためのプログラム、本実施形態に係るアプリケーション・プログラム、又ウェブ・ブラウザ・プログラムは、ＨＤＤ装置３４０に格納されていて、実行時には、ＲＡＭ３１１に読み出されてＣＰＵ３１０によって実行される。なお、ＣＰＵ３１０で実行されるアプリケーション・プログラムには、ネットワーク１経由で取得される、ＪＡＶＡ（登録商標)のアプレットや、データ管理保存装置１０におけるＡＳＰ（Active Server Page）の機能によって提供されるものも含まれる。
【００４７】
又、ＯＳやアプリケーション・プログラムその他の実行に際して、オペレータは、画面表示装置３３０に表示出力される情報を参照しつつ、キーボード３３１によって文字入力や諸操作を行ったり、マウス３３２によって座標入力や諸操作の入力を行ったりする。例えば、マウス３３２によって、一覧表示される電子文書の選択をしたり、閲覧中の電子文書において、検索などの範囲指定を行ったり、その他、クリック操作や、いわゆるドラッグ・アンド・ドロップ操作により様々な操作を行ったりする。又、適宜、プリンタ装置３３３からは必要な情報を印字出力したりすることができる。言うまでもなく、これら諸出力や入力は、ＣＰＵ３１０で実行されるプログラムによって、電子的な処理によって行われるものである。
【００４８】
なお、ＣＤドライブ装置３４１やＦＤＤ装置３４２は、本願発明を適用して実施する際の、アプリケーション・プログラムのインストールや、その他のオフラインでの情報交換に用いられる。
【００４９】
図４は、本実施形態における基幹業務を示すフローチャートである。
【００５０】
このフローチャートにおいて、ステップＳ１００は、購買部門、資材部門、販売管理部門、会計部門その他における、購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６の、業務別のシステム運用を示す。これら装置は、分散系のＤＢを構成しているが、必要に応じネットワーク１経由で相互に情報交換することができる。
【００５１】
次に、ステップＳ１０２は、本実施形態の企業基幹システムにおいて、これら購買管理サーバ装置５０、在庫管理サーバ装置５１、販売管理サーバ装置５２、及び会計管理サーバ装置５６を連携させた、統合的なシステム運用を示す。特に、本企業基幹システムでは、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２で発生する諸費用情報を適宜会計管理サーバ装置５６に集約し、該会計管理サーバ装置５６において仕訳帳や総勘定元帳などを作成し、会計情報として活用している。
【００５２】
更に、ステップＳ１０４では、本発明を適用してスナップショットによるデータ管理保存業務処理を行う。これにより、税務監査その他の長期保存情報の閲覧を行うことができる。
【００５３】
ここで、これらステップＳ１００、Ｓ１０２及びＳ１０４のそれぞれのシステム運用は、概念としてこの順に成立するものであるが、実務として常に並行運用されている。この図は、あくまでこのようなシステム運用の概念を示すものである。
【００５４】
図５は、本実施形態に用いられるデータ管理保存装置の構成を示すブロック図である。
【００５５】
この図では、前述の図１や図２に示されたデータ管理保存装置１０の構成が示される。この図に示されるように、該データ管理保存装置１０は、スナップショット処理部２２と、ブロック化処理部２４と、ブロック別圧縮・暗号化処理部２６と、インデックスデータテーブル作成処理部２８と、データ管理保存処理部３０と、ブロック別復号化処理部３２と、閲覧処理部３４と、ブロック検索処理部３６とを備える。更に、該データ管理保存装置１０は、上記のデータ管理保存処理部３０により保存される情報を格納する、データ記憶装置４０を備える。
【００５６】
まず、スナップショット処理部２２は、管理対象ＤＢ装置の各装置それぞれに格納されている元ファイルを対象とし、前述のようにスナップショット取得情報を取得する。このスナップショット取得は、手動で、あるいは自動で定期的に行われ、その時点における元ファィルの情報をスナップショット取得情報として取得することができる。
【００５７】
ブロック化処理部２４は、このように取得したスナップショット取得情報を、所定のレコード数毎のブロックに編成したファイル（以下ブロック単位生成ファイルと呼ぶ）を生成する。各ブロックが有するレコード数は、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。このため、該閲覧は、通常１つのブロックに対するアクセスで対応することができ、処理対象のブロック数を抑えることで、該閲覧を能率よく行うことができる。
【００５８】
次に、ブロック別圧縮・暗号化処理部２６は、このように編成されたブロック単位生成ファイルを、該編成のブロック単位で圧縮・暗号化する。又、インデックスデータテーブル作成処理部２８は、このようなブロック単位生成ファイル毎で、該ブロック単位生成ファイルに含まれるレコードを特定データでソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成する。
【００５９】
データ管理保存処理部３０は、ブロック単位で圧縮・暗号化されたブロック単位生成ファイル、及び上記のインデックスデータテーブルをデータ記憶装置４０に格納する処理を行う。又、該データ管理保存処理部３０は、このように格納されている、所望のブロック単位生成ファイルを読み出す処理を行う。該データ記憶装置４０には、ＨＤＤ装置や、ＭＴ装置などが用いられている。
【００６０】
次に、ブロック別復号化処理部３２は、ブロック単位生成ファイルを閲覧し、元ファイルを閲覧する際に、該ブロック単位生成ファイルを編成しているブロック単位で、該ブロック単位生成ファイルの圧縮・暗号化の伸張・復号を行う。
【００６１】
ブロック検索処理部３６は、前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがブロック単位生成ファイルにおいてどのブロックに格納されているか予測し、予測されたブロックの圧縮・暗号化の伸張・復号を行って該ブロックを検索する。これにより、検索対象のテーブルを逐次部分的に伸張・復号を行いながら、検索結果を取得する。従って、圧縮・暗号化の伸張・復号処理は、必要最小限のブロックに限定して行うことが可能であり、検索及び閲覧時の処理速度の向上を図ることができる。
【００６２】
続いて、閲覧処理部３４は、クライアント装置５からの利用者の利用要求を受け付ける。又、該閲覧処理部３４は、該検索結果を利用者の閲覧に供する。
【００６３】
ここで、閲覧対象の情報の指示や、検索の指示は、利用者からクライアント装置５により閲覧処理部３４に対して入力される。該閲覧処理部３４は、この入力内容をブロック検索処理部３６に伝達する。該ブロック検索処理部３６はブロック別復号化処理部３２に対して、この入力内容と、データ記憶装置４０に保存されている該当のインデックスデータテーブルとに基づいて、圧縮・暗号化の伸張・復号処理を行う、ブロック単位生成ファイル、及び該ブロック単位生成ファイルにおけるブロックを指示する。
【００６４】
すると、該ブロック別復号化処理部３２は、指示されたブロック単位生成ファイルのブロックを、データ管理保存処理部３０によってデータ記憶装置４０から読み出し、且つ伸張・復号処理を行って閲覧処理部３４に出力する。この後、該閲覧処理部３４は、伸張・復号処理されたブロック単位生成ファイルに基づいて、クライアント装置５への閲覧を行う。
【００６５】
図６は、本実施形態におけるデータ管理保存業務処理を示すフローチャートである。
【００６６】
このフローチャートは、前述の図４のステップＳ１０４におけるデータ管理保存業務処理を示すものである。
【００６７】
図６において、まず、ステップＳ１１０では、このデータ管理保存業務処理に関する諸設定を行う。このデータ管理保存業務処理は、本発明を適用したスナップショット取得を手動でも、又定期的日時で自動的に起動することができる。このステップＳ１１０では、このような手動あるいは自動の設定や、自動の場合の定期的日時の設定など、各種の設定を行う。
【００６８】
次に、ステップＳ１１２では、本発明を適用したスナップショット取得や情報保存その他を行う、データ管理保存処理を行う。
【００６９】
管理対象ＤＢ装置の各装置それぞれでは、様々な情報が時系列的に発生し、このような情報は、テーブル形式のファイル（元ファイル）で格納されている。このステップＳ１１２において、データ管理保存装置１０は、これら元ファイルの情報を、所定形式のスナップショット取得情報として定期的にスナップショット取得し、後述するように本発明を適用してブロック化されたファィル（ブロック単位生成ファイル）により保存する。本実施形態は、上位システムとなる管理対象ＤＢ装置それぞれの、業務上の静止点において、スナップショットを行う。
【００７０】
なお、このブロック単位生成ファイルは、ブロック単位で圧縮・暗号化されている。このため、該ブロック単位生成ファイルは、大量保存及び長期保存が容易になっている。更には、高速アクセスや高速検索を可能としながら、暗号化によるデータ改ざん防止とセキュリティの確保を可能としている。
【００７１】
ここで、ＯＳの特権による管理によっても、データ改ざん防止とセキュリティの確保がある程度可能である。しかしながら、特権がある利用者であれば改ざんをすることが可能であるという限界がある。なお、本実施形態では、圧縮・暗号化に加えて、ＯＳの特権による管理によるデータ改ざん防止とセキュリティの確保を行っている。
【００７２】
なお、類似情報の出現の頻度が高くなると、圧縮処理における圧縮率が向上する。本実施形態のブロック単位生成ファイルは、ブロック単位で類似情報の出現の可能性が高くなる。従って、本実施形態では圧縮率が向上される可能性が高くなっている。例えば、レコード単位での圧縮・暗号化に比較して、圧縮率を向上することができる。
【００７３】
図６において、続いてステップＳ１１４では、上述のようにステップＳ１１２で保存された情報を、スナップショットした時点における該当の元ファイルの情報の提供として、後日、閲覧に供することができる。例えば、税務監査の際、画面表示、印字出力、更にはＣＳＶ形式やＸＭＬ形式などの所定ファイル形式に変換したファイル出力として、税務官の閲覧に供せられる。この閲覧の際には、必要な情報の検索、抽出する機能が備えられている。
【００７４】
図７は、本実施形態におけるデータ管理保存処理を示すフローチャートである。
【００７５】
このフローチャートは、前述の図６のフローチャートにおけるステップＳ１１２のデータ管理保存処理の内容を示したものである。
【００７６】
このフローチャートにおいて、まずステップＳ１３０では、スナップショット処理部２２において、管理対象ＤＢ装置の各装置それぞれの元ファィルの情報を、スナップショット取得情報として取得する。
【００７７】
ステップＳ１３２では、ブロック化処理部２４において、スナップショット取得情報に対して、所定のレコード数のブロックで編成するブロック化処理を行う。
【００７８】
ステップＳ１３４では、ブロック別圧縮・暗号化処理部２６において、このようにブロックで編成するようにした、スナップショット取得したテーブルデータを該ブロック単位で圧縮・暗号化する圧縮・暗号化処理を行う。
【００７９】
更に、ステップＳ１３６では、インデックスデータテーブル作成処理部２８において、スナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理を行う。
【００８０】
ステップＳ１３８では、上述のステップＳ１３４で圧縮・暗号化した情報、及び上述のステップＳ１３６で作成したインデックスデータテーブルを、データ管理保存処理部３０において、データ記憶装置４０に格納するデータ管理保存処理を行う。
【００８１】
図８は、本実施形態におけるスナップショット取得情報（ＣＳＶ形式ファイル）とブロック単位生成ファイルの関係を示すデータ構成図である。図９は、該ブロック単位生成ファイルの構成を示すデータ構成図である。
【００８２】
本実施形態のスナップショット処理部２２は、前述の管理対象ＤＢ装置の各装置それぞれにおいてテーブル形式で格納されている、時系列的に発生するデータの元ファイルを、スナップショット取得情報として取得する。該スナップショット取得情報のファイル形式は、特に限定されるものではないが、この図８に示すように、ＣＳＶ形式のファイルに変換されたものであってもよい。
【００８３】
該スナップショット取得情報の情報は、本実施形態において、各ブロックがＭ個のレコードで構成される、複数ブロックに編成され、これによりブロック単位生成ファイルが生成される。このレコード数Ｍは、後日閲覧する際の、閲覧単位に含まれると予測されるレコード数程度以上とされている。このため、該閲覧は、通常１つのブロックに対するアクセスで対応することができ、処理対象のブロック数を抑えることで、該閲覧を能率よく行うことができる。
【００８４】
又、このブロック単位生成ファイルは、図９に示されるように、先頭にファイルヘッダ、尾端にファイルフッタを備え、これらの間に、スナップショット取得情報をブロック別に編成した情報が組み込まれる。
【００８５】
ここで、ＣＳＶ形式のファイルのスナップショット取得情報がＫ個のレコードを有するものであれば、Ｎは、（Ｋ／Ｍ）の整数値プラス１となる。又、図示されるように、この最終ブロックＮ中に、ＣＳＶ形式のファイルの元の情報における最終レコードが含まれることになる。
【００８６】
又、図８及び図９に示されるように、各ブロックは、先頭にはブロックヘッダ、尾端にはブロックフッタを備える。これらブロックヘッダ及びブロックフッタには管理情報が格納され、これらブロックヘッダ及びブロックフッタにより、ブロック単位生成ファイルにおいて順に連続するブロックが順次連鎖されるようになっている。ブロックヘッダには、ブロック単位生成ファイルにおいて１つの前のブロックのアドレスが、ブロックフッタには、ブロック単位生成ファイルにおいて１つの後のブロックのアドレスが格納されている。
【００８７】
ここで、これら図８及び図９では、各レコードが１社員の情報となっている。各レコードは、「東京」などの社員所属事業所名、「経理」や「営業」などの社員所属部署名、「阿部誠」や「木村隆司」などの社員名、「東京都……」や「千葉県……」などの社員住所の情報を含んでいる。
【００８８】
図１０は、本実施形態において定期的日時に生成するブロック単位生成ファイルを示すデータ構成図である。
【００８９】
本実施形態では、スナップショットによる情報取得は、時系列的に行われる。又、毎月の特定日時、あるいは経理上や会計上の特定の月及び日時を定期的日時として設定し、自動的に、スナップショットによる情報取得を行うことができる。
【００９０】
この図１０では、毎月の特定日時（定期的日時）において、自動的にスナップショットによる情報取得を行う例を示している。該情報取得を行うと、毎月、該取得の日時における元ファイルの、ＣＳＶ形式のファイルのスナップショット取得情報が取得される。更に、このように毎月、該取得のファイルに従って本発明が適用されたブロック化がなされた、ブロック単位生成ファイルが生成される。
【００９１】
ここで、本実施形態では、あらかじめ設定した定期的日時において、過去のブロック単位生成ファイルに対して、月次単位で新たに取得されたスナップショット取得情報を合成することで、この時点での最新の圧縮・暗号化されたブロック単位生成ファイルを生成するようにしている。合成され圧縮・暗号化されたブロック単位生成ファイルは、データ管理保存処理部３０による処理によってデータ記憶装置４０に保存されることになる。
【００９２】
このような合成されたブロック単位生成ファイルの生成は、例えば、過去のブロック単位生成ファイルを一旦復号化してから、これに新たなスナップショット取得情報（圧縮・暗号化なしのもの）を合成し、合成されたものを圧縮・暗号化することで行うようにしてもよい。あるいは、新たなスナップショット取得情報をまず圧縮・暗号化してから、これに対して、圧縮・暗号化されている過去のブロック単位生成ファイルを復号化せず、そのまま合成し行うようにしてもよい。
【００９３】
なお、このような合成は行わす、あらかじめ設定した定期的日時において、その都度新たに、圧縮・暗号化されたブロック単位生成ファイルを生成するようにしてもよい。しかしながら、上述のような合成では、圧縮・暗号化の処理量を抑制することができ、処理速度を向上することができる。
【００９４】
次に、図１１は、本実施形態におけるインデックスデータテーブルの構成を示すデータ構成図である。
【００９５】
本実施形態において、インデックスデータテーブルには、対象になるブロック単位生成ファイルを、特定データ項目でソートしたレコード順列の情報が保存され、これにより、該ソートのレコード順列の情報が保存される。この図１１の左側に示されるように、インデックスデータテーブルの先端にはインデックスヘッダが設けられ、続いて、上述のようにソートしたレコード順列の情報に従って、該当のレコード番号が順にインデックスレコードに保存される。このインデックスレコードの数は、対象になるブロック単位生成ファイルに含まれるレコード数と等しくなる。又、一連のインデックスレコードに続いて、インデックスデータテーブルの尾端にはインデックスフッタが設けられる。
【００９６】
例えば、図１１において、対象になるブロック単位生成ファイルに含まれるレコード数がＭであれば、そのインデックスデータテーブルに保存されるインデックスレコードの数もＭとなる。又、対象になるブロック単位生成ファイルを特定データ項目でソートしたとき、該ソート結果のブロックレコードの順序が、レコード＃３、レコード＃２４、レコード＃１、レコード＃３１……であれば、インデックスレコード１〜３には順に、「＃３」、「＃２４」、「＃１」、「＃３１」のデータが保存される。
【００９７】
ここで、このようなインデックスデータテーブルの情報は、ブロック単位生成ファイルにおけるレコード順列の情報であり、単にレコード番号のみである。従って、ブロック単位生成ファイルが圧縮・暗号化されていれば、インデックスデータテーブルは圧縮・暗号化せずとも機密性が確保される。但し、インデックスデータテーブルを圧縮・暗号化すれば、該インデックスデータテーブルのデータ量を抑制でき、これを格納する記憶手段の記憶容量の抑制などが可能になる。
【００９８】
図１２は、本実施形態において作成されるブロック単位生成ファイルの一例の情報内容を示す一覧表である。図１３は、この図１２のブロック単位生成ファイルのレコードを「社員番号」でソートした情報内容を示す一覧表である。図１４は、このようにソートした場合のインデックスデータテーブルを示すデータ構成図である。
【００９９】
図８や図９により前述した、１つ乃至は複数のブロックで構成されるブロック単位生成ファイルにおいて、この図１２に示される情報内容が保存されているものとする。
【０１００】
ここでは説明の便宜上、レコード数は「１０」で、レコード番号は「＃１」〜「＃１０」に抑えられているが、多数のレコードであれば、複数のブロックに保存されることになる。このような場合にも、本実施形態では、複数のブロックに亘ってレコード番号は連番となっている。
【０１０１】
次に、図１３では、図１２のブロック単位生成ファイルのレコードを「社員番号」でソートしている。従って、該ソートの結果、レコード番号が上から順に、「＃１」、「＃９」、「＃７」、「＃２」、「＃１０」、「＃３」、「＃４」、「＃５」、「＃８」、「＃６」となっている。なお、ソート前の図１２では、当然ながらレコード番号が上から順に、「＃１」〜「＃１０」である。
【０１０２】
ここで、図１３はソートした後の情報内容を示す一覧表であるので、該図１３の「レコード番号」の列は、該ソート後のレコード順序を示す。従って、該ソートのインデックスデータテーブルでは、このレコード順が保存されることになり、図１４に示されるように、インデックスレコード１〜１０には、該レコード順に対応する、「＃１」、「＃９」、「＃７」、「＃２」、「＃１０」、「＃３」、「＃４」、「＃５」、「＃８」、「＃６」のレコード番号のデータが順に保存される。
【０１０３】
次に、図１５は、本実施形態における保存データ閲覧処理を示すフローチャートである。
【０１０４】
このフローチャートは、前述の図６のステップＳ１１４のステップＳ１１４の保存データ閲覧処理の内容を示すものである。
【０１０５】
このフローチャートにおいて、まず、ステップＳ１６０では、閲覧処理部３４は、クライアント装置５から情報閲覧の指示入力を受け付けたり、情報の検索の指示入力を受け付けたりする。情報の検索の指示入力を受け付けた場合、ステップＳ１６２では、インデックスデータテーブルを用い、データ管理保存処理部３０の処理によってデータ記憶装置４０に格納されているテーブルのレコードを検索する際、ブロック検索処理部３６は、該閲覧処理部３４からの入力に応じて、まず対象レコードがどのブロックに格納されているか予測しつつ、ブロック別復号化処理部３２により、予測されたブロックの圧縮・暗号化の伸張・復号を行ってから該ブロックにおける検索を行う。この検索結果は、該ブロック別復号化処理部３２から閲覧処理部３４を経て、クライアント装置５に出力される。これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張・復号及び検索を行う。
【０１０６】
ステップＳ１６４では、データ記憶装置４０に格納されている情報で、上述のように予測されたブロックの伸張・復号を行う。続いて、ステップＳ１６６では、このように伸張・復号されたブロックの情報を閲覧に供する。ここで、検索結果や並べ替え結果などを閲覧に供する場合、クライアント装置５は、１つ乃至は複数の対象のブロックの情報に基づいて、閲覧に供する情報を生成する。
【０１０７】
例えば、図１６は、本実施形態においてこのような保存データ閲覧処理における閲覧画面を示す表示画面図である。
【０１０８】
この図において、「２００８１２０４（／標準ＤＢ／管理／組織別社員台帳）」とある表示行は、クライアント装置５から利用者が入力した閲覧希望の入力に従った、ブロック単位生成ファイルのファイル名を示す。又、この閲覧結果は、「事業所」、「部署名」、「社員番号」、「社員名」、「住所」の社員一覧リストとして表示されている。
【０１０９】
なお、本実施形態における閲覧結果は、このような画面表示に加えて、ＣＳＶ形式やＸＭＬ形式によるファイル出力によっても提供できるようになっている。
【０１１０】
図１７は、このような保存データ閲覧処理における参照レコード群抽出を示すデータ構成図である。
【０１１１】
この図において、「２００８１２０４（／標準ＤＢ／管理／組織別社員台帳）」と、クライアント装置５から閲覧処理部３４に対して閲覧対象が指示入力されると、閲覧処理部３４及びブロック別復号化処理部３２は、閲覧すべきファイル（参照ファイル）を見いだすと共に、該参照ファイルにおいて閲覧すべきブロック（参照ブロック）を見いだし、更には、閲覧すべきレコード群（参照レコード群）を見いだす。
【０１１２】
例えば、ある参照ファイルにおいて、Ｘ番目のレコードを閲覧する場合、このレコードが含まれるブロックのブロック番号Ｙは、以下のように算出することができる。ここで、ａは、１ブロックあたりのレコード数である。
【０１１３】
Ｙ＝（Ｘ−１）／ａ＋１
ここで、ブロックのフッタ内には、そのブロックの位置が格納されているテーブルが格納されている。従って、対象ブロックへのアクセスは、このフッタ内の情報を用いる。
【０１１４】
又、インデックスに格納されているレコード番号から、データへのアクセスは以下の（１）〜（３）のようになる。
【０１１５】
（１） レコード番号より、以下の計算式でブロック番号を取得する。
（レコード番号−１）／１ブロック内のレコード数＋１＝ブロック番号
ここで、「（レコード番号−１）」は、レコード番号が１相対であるための処理である。又、最後の「＋１」は、ブロック番号が１相対であるための処理である。レコード番号が１０で、１ブロック内のレコード数が２００の場合、「９／２００＋１＝１」となる。よって、ブロック番号は１となる。
【０１１６】
（２） データファイル内のフッタより、該当ブロック番号のデータ位置を取得する。
【０１１７】
（３） 対象位置のブロックを読み込む。
【０１１８】
次に、図１８は、本実施形態の保存データ閲覧処理における検索画面を示す表示画面図である。
【０１１９】
この図において背景側になっているウインドウでは、「登録日」、「会員名」、「取扱部店名」、「銘柄名」、「市場」、「取扱銘柄」、「公表区分」、「売気配」、「売提示日」、「買気配」、「買提示日」のデータを備えるレコードのリストが表示されている。又、選択表示されているウインドウでは、これらデータによって、「前方一致」、「中間一致」、「完全一致」などの選択をしながら検索が可能になっている。
【０１２０】
ここで、図１２〜図１４により前述したインデックスデータテーブルにおいて、「社員番号」が「６００６」である社員のレコードを、二分検索法により検索する例について説明する。この場合、検索キーは「社員番号」が「６００６」となる。
【０１２１】
図１４のインデックスデータテーブルにおいて、全インデックスレコード１〜１０の真ん中は、該図１４中の（１）で図示されるように、インデックスレコード５であり、該インデックスレコード５にはレコード番号「＃１０」が保存されている。図１２のブロック単位生成ファイルにおいて、このレコード番号「＃１０」のレコードを参照すると、「社員番号」は「６０２５」であり、検索キーの「６００６」より大であると判定される。
【０１２２】
大と判定されたので、今度はインデックスレコード１〜４を検索対象とし、この真ん中は、該図１４中の（２）で図示されるようにインデックスレコード２であり、該インデックスレコード２には図１４においてレコード番号「＃９」が保存されている。図１２のブロック単位生成ファイルにおいて、このレコード番号「＃９」のレコードを参照すると、「社員番号」は「１０１９」であり、検索キーの「６００６」より小であると判定される。
【０１２３】
小と判定されたので、今度はインデックスレコード３〜４を検索対象とし、この真ん中は、該図１４中の（３）で図示されるようにインデックスレコード３であり、該インデックスレコード３には図１４においてレコード番号「＃７」が保存されている。図１２のブロック単位生成ファイルにおいて、このレコード番号「＃７」のレコードを参照すると、「社員番号」は「６００６」であり、検索キーの「６００６」と一致と判定される。
【０１２４】
該一致判定により、検索結果として、図１２のブロック単位生成ファイルにおける、レコード番号「＃７」のレコードを取得することになる。
【０１２５】
このように検索結果が得られた後には、ブロック別復号化処理部３２において、検索されたレコードが含まれるブロックの復号化処理を行う。
【０１２６】
ここで、本実施形態では、検索されたレコードの情報と共に、例えば前述の図１６の閲覧画面と同様に、復号化されたブロックの他のレコードも同時に閲覧に供することができる。例えば、検索されたレコードの情報に加えて、該レコードが含まれるブロックにおいて、該レコードの前後の複数のレコードも併せて閲覧に供することができる。
【０１２７】
なお、以上において、インデックスデータテーブルを用いた二分検索法による、ブロック単位生成ファイルのレコードの検索処理の例について説明した。ほぼ同様に、本実施形態では、インデックスデータテーブルを用いて、ブロック単位生成ファイルのレコードのソート処理も行うことが可能である。
【０１２８】
なお、本実施形態においては、ブロック単位生成ファイルが複数のブロックで構成される場合に、レコード番号は、複数ブロックに亘る連番を採用している。従って、関係する全レコードをより少ないデータ長で識別することができる。従って、インデックスデータテーブルを格納するために必要な記憶手段の記憶容量を抑えることが可能となり、システムのリソースを抑えることができる。
【０１２９】
例えば、個々のレコードを、そのレコードが存在するブロックの番号、及び該ブロック中におけるそのレコードの番号で表わすことも考えられる。しかしながら、この場合、これらブロック番号及びレコード番号の合計データ長は、本実施形態の場合に比べて長くなり冗長になる。
【０１３０】
なお、本実施形態において、インデックスデータテーブルのインデックスレコードのデータ長を、対象になるブロック単位生成ファイルの総レコード数に応じて可変長することもできる。この場合、ブロック単位生成ファイルの総レコード数に応じて、インデックスデータテーブルの記憶容量を抑えることができる。
【０１３１】
図１９は本実施形態におけるバックアップ復元処理を示すフローチャートである。
【０１３２】
本実施形態では、データ管理保存装置１０は、将来のクライアント装置５からの閲覧を目的として、管理対象ＤＢ装置の各装置それぞれにおけるテーブル形式のデータをスナップショット取得しデータ記憶装置４０に保存している。
【０１３３】
ここで、このように保存されているデータにより、対象の装置に格納されている情報を、スナップショット取得の時点に復元することも考えられる。この図１９は、このようなバックアップ復元処理を示すものである。なお、前述の図１においては、二点鎖線の矢印により、このようなバックアップ復元処理による元ファイルの復元が示される。
【０１３４】
ステップＳ１８０では、データ管理保存装置１０の閲覧処理部３４は、クライアント装置５からこのようなバックアップ復元要求の、利用者からの入力を受け付ける。ステップＳ１８２では、復元すべき装置のファイル、又、この復元に用いる、データ記憶装置４０に保存されているファィルを見いだすなどの復元準備処理を行う。
【０１３５】
ステップＳ１８４では、復元に用いる、データ記憶装置４０に保存されているファィルの復号化処理を行う。ステップＳ１８６では、復号化されたファイルを用いて、復元すべき装置のファイルを、利用者からのクライアント装置５における入力で指示された時点に復元する。
【０１３６】
なお、以上に説明したように、前述の図５に示されるデータ管理保存装置１０における各処理部及びデータ記憶装置４０は、図１や図２におけるデータ管理保存装置１０において構成している。しかしながら、本実施形態は、このようなものに限定されるものではない。例えば、図１や図２の会計管理サーバ装置５６などにおいて、複合的にデータ管理保存装置１０を構成し、該会計管理サーバ装置５６などにおいて図５に示されるデータ管理保存装置１０における各処理部及びデータ記憶装置４０を構成するようにしてもよい。会計管理サーバ装置５６において複合的にデータ管理保存装置１０を構成する場合、データ記憶装置４０は、会計管理サーバ装置５６が備えるデータベース装置や記憶装置に設けるようにしてもよい。
【実施例】
【０１３７】
図２０は、本発明が適用された第１実施例の処理を示すフローチャートである。
【０１３８】
本実施例は、以上に説明した実施形態において、管理対象ＤＢ装置を、経理情報を少なくとも保存しているデータベースである会計管理サーバ装置５６としている。又、前述の定期的日時を、経理業務上、情報が確定する日次及び月次の日時としている。
【０１３９】
このフローチャートは、前述の図４のフローチャート全体に対応するものである。又、この図４のフローチャートのステップＳ１０４である「データ管理保存業務処理」は、前述の図６のフローチャート全体に示されるとおりである。従って、本実施例の図２０のフローチャートは、この図４のステップＳ１０４に図６のフローチャート全体を盛り込んだものである。
【０１４０】
更に、この図２０に示されるように、ステップＳ１１２の「データ管理保存処理」は、本実施例では、ステップＳ２１０の「日次スナップショット処理」、及びステップＳ２１２の「月次情報合成処理」によって構成されている。又、本実施例において以下に述べる第１の定期的日時及び第２の定期的日時の設定は、前述したステップＳ１１０における業務設定処理において行うことができる。なお、第１の定期的日時は日次、第２の定期的日時は月次としてもよいが、これらに限定されるものではない。例えば、第２の定期的日時を、第１の定期的日時より長期周期となる、決算時期の四半期次や年次などとしてもよい。
【０１４１】
上記のステップＳ２１０の「日次スナップショット処理」では、日次（第１の定期的日時）で、該データベースの情報のスナップショット取得、該取得の情報に対する前述したブロック分けの編成によるブロック単位生成ファイルの生成、及び、該ブロック単位生成ファイルの圧縮・暗号化を行って、データ記憶装置４０（データ管理保存データベース）に格納する。
【０１４２】
なお、このステップＳ２１０では、スナップショット取得から少なくともブロック分け編成までの処理を行うものである。例えば、圧縮・暗号化は省いて、ブロック分け編成までの処理を行ったブロック単位生成ファイルをデータ記憶装置４０（データ管理保存データベース）に格納するようにしてもよい。但し、圧縮・暗号化を行うことで、該データ記憶装置４０に必要な記憶容量の一層の低減や、セキュリティの安全性の一層の向上を図ることができる。
【０１４３】
又、上記のステップＳ２１２の「月次情報合成処理」では、月次（第２の定期的日時）で、日次で格納している複数の該ブロック単位生成ファイルから、月次単位の該ブロック単位生成ファイルを合成する。
【０１４４】
本実施例のこのファイル合成は具体的に限定されるものではなく、該ファイル合成に際して行われるブロック単位生成ファイルの合成処理や、インデックスデータテーブルの作成処理について具体的に限定されるものではない。例えば、これらブロック単位生成ファイルの合成処理、及びインデックスデータテーブルの作成処理は、該ファイル合成において、いずれか一方のみ行うものであってもよい。
【０１４５】
又、該ファイル合成の際のブロック単位生成ファイルの合成処理については、例えば、日次で得ている過去の対象期間の複数のブロック単位生成ファイルを一旦復号化してから、これらを合成し、合成されたものを圧縮・暗号化することで行うようにしてもよい。あるいは、これら対象期間の複数のブロック単位生成ファイルを復号化せず、そのまま合成し行うようにしてもよい。
【０１４６】
該ファイル合成の際のインデックスデータテーブルの作成についても、具体的に限定されるものではない。このインデックスデータテーブル作成の処理については、日次で、過去の対象期間の複数のブロック単位生成ファイルの生成時に作成されたインデックスデータテーブルを合成し、これにより、月次単位のインデックスデータテーブルを作成してもよい。あるいは、月次で、ブロック単位生成ファイルを合成する際に、同時に新たに月次単位のインデックスデータテーブルを作成してもよい。
【０１４７】
ここで、図２１は、本実施例が処理対象とする情報の一例を示すデータ構成図である。
【０１４８】
図２０のステップＳ１００や前述の図４のステップＳ１００では、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２などによる、それぞれの該当業務において、様々な情報が発生している。このような業務別の情報の内、経理や会計に係わる諸費用情報は、ステップＳ１０２において、適宜会計管理サーバ装置５６に集約され、該会計管理サーバ装置５６において仕訳帳や総勘定元帳などが作成される。この図２１や後述する図２３では、このような会計管理サーバ装置５６で取得されたり、作成されたりする情報を総称して明細会計情報としている。
【０１４９】
図２１では、明細会計情報Ａ１〜Ａ３は「２０１１／５／１」に、明細会計情報Ｂ１〜Ｂ３は「２０１１／５／３０」に、明細会計情報Ｃ１〜Ｃ３は「２０１１／５／３１」に、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２などから適宜会計管理サーバ装置５６において集約され、作成された情報である。
【０１５０】
続いて、ステップＳ１１０では、定期的日時の手動あるいは自動の設定や、自動の場合の第１の定期的日時及び第２の定期的日時の設定など、各種の設定を適宜行う。なお、本実施例では、「自動」設定であり、又、定期的日時に関しては、「日次スナップショット処理」の日時設定（日毎の時間設定（第１の定期的日時設定））や処理内容、「月次情報合成処理」の日時設定（月毎の日時設定（第２の定期的日時設定））や処理内容の設定を行う。
【０１５１】
次に、ステップＳ１１２のステップＳ２１０の「日次スナップショット処理」では、図２１の矢印Ｄ１〜Ｄ３で示されるように、圧縮・暗号化された日次会計情報Ｅ１〜Ｅ３（ブロック単位生成ファイル）が生成され、データ記憶装置４０に格納される。該生成は、日次（第１の定期的日時）で行われるものであり、会計管理サーバ装置５６にある明細会計情報のスナップショット取得、該取得の情報に対するブロック分けの編成による日次会計情報（ブロック単位生成ファイル）の生成、及び、該日次会計情報の圧縮・暗号化によるものである。
【０１５２】
続いて、ステップＳ１１２のステップＳ２１２の「月次情報合成処理」では、図２１の矢印Ｆ１で示されるように、月次（第２の定期的日時）で、上述のように日次で格納している日次会計情報から、月次単位の月次会計情報（ブロック単位生成ファイル）を合成する。この図２１の例では、２０１１年５月の月次会計情報を合成し生成しているが、この合成及び生成の処理は、例えば、翌月の２０１１年６月の１日に行う。
【０１５３】
本実施例では、スナップショット取得しながら圧縮・暗号化によって取得される情報（日次会計情報）は日付毎であるが、毎月の月初めに前月のものが月次会計情報に合成されるので、後日の検索時には対象となるファイルの数が少なくなる。従って、検索処理の処理量が削減され、処理能率が向上される。
【０１５４】
ここで、本実施例は、会計情報が一日毎で確定する場合を想定したものである。
【０１５５】
次に、図２２は、本発明が適用された第２実施例の処理を示すフローチャートである。
【０１５６】
本実施例は、上述の第１実施例のステップＳ１１２の「データ管理保存処理」が、ステップＳ２２０の「月次スナップショット処理」により構成され、日次会計情報（ブロック単位生成ファイル）の合成は行わない。
【０１５７】
本実施例において、前述した定期的日時は、経理業務上、情報が確定する月次の日時となっている。ステップＳ１１０では、本実施例では「自動」を設定し、又、「月次スナップショット処理」の日時設定（月毎の日時設定（定期的日時設定））や処理内容の設定を適宜行う。
【０１５８】
ここで、図２３は、本実施例が処理対象とする情報の一例を示すデータ構成図である。
【０１５９】
図２３では、明細会計情報Ｋ１〜Ｋ３は「２０１１／５／１」に、明細会計情報Ｌ１〜Ｌ３は「２０１１／５／３１」に、明細会計情報Ｍ１〜Ｍ３は「２０１１／６／１」に、明細会計情報Ｎ１〜Ｎ３は「２０１１／６／３０」に、購買管理サーバ装置５０、在庫管理サーバ装置５１、及び販売管理サーバ装置５２などから会計管理サーバ装置５６において適宜集約され、作成された情報である。
【０１６０】
本実施例の図２２のステップＳ２２０の「月次スナップショット処理」では、図２３の矢印Ｐ１、Ｐ２で示されるように、圧縮・暗号化された月次会計情報Ｑ１、Ｑ２（ブロック単位生成ファイル）が生成され、データ記憶装置４０に格納される。該生成は、月次（定期的日時）で行われるものであり、会計管理サーバ装置５６にある明細会計情報のスナップショット取得、該取得の情報に対するブロック分けの編成による月次会計情報（ブロック単位生成ファイル）の生成、及び、該月次会計情報の圧縮・暗号化によるものである。
【０１６１】
このように、本実施例では、ブロック単位生成ファイルの合成は行わず、ステップＳ２２０の「月次スナップショット処理」において、その都度新たに、圧縮・暗号化されたブロック単位生成ファイルを生成するようにしている。このような本実施例と比較することで、合成処理を行う前述の第１実施例は、全体として圧縮・暗号化の処理量を抑制することができ、処理速度を向上することができることがわかる。
【０１６２】
又、以上に説明したように、本実施例や前述の第１実施例では、検索その他に用いるインデックスデータテーブルの作成は、限られた期間の情報を対象に作成している。従って、このように期間を限らず、例えばＲＤＢ（Relational Data Base）全体を対象にインデックスデータテーブルを作成する場合に比べて、格段に処理能率を向上することができる。
【０１６３】
ここで、インデックスデータテーブルは、前述の第１実施例では、日次で作成され、場合によっては月次でも合成ないしは新規作成される。又、本第２実施例では、インデックスデータテーブルは、月次で作成される。従って、インデックスデータテーブルは、分割されたものとなり、検索時には、利用するインデックスデータテーブルの数が増加する可能性が生じるが、通常の検索処理では問題は生じない。
【０１６４】
又、図２１や図２３における明細日付のような個々の情報の期日も１つの検索キーとし、検索する場合も考えられる。例えば、税務監査などでは、このように検索対象の情報の期間を限定するケースが多くなる。このような場合、これら実施例では、インデックスデータテーブルが分割されているので、個々のインデックスデータテーブルのデータ量は少なくなるので、検索キーの期日の情報が含まれるインデックスデータテーブルを選択することで、能率よく検索処理を行うことができる。
【０１６５】
ここで、本第２実施例は、会計情報が一ヶ月毎で確定する場合を想定し、情報量が大量な場合を想定したものである。
【符号の説明】
【０１６６】
１…ネットワーク
５…クライアント装置
１０…データ管理保存装置
１２…管理対象サーバ装置
２２…スナップショット処理部
２４…ブロック化処理部
２６…ブロック別圧縮・暗号化処理部
２８…インデックスデータテーブル作成処理部
３０…データ管理保存処理部
３２…ブロック別復号化処理部
３４…閲覧処理部
３６…ブロック検索処理部
４０…データ記憶装置
５０…購買管理サーバ装置
５１…在庫管理サーバ装置
５２…販売管理サーバ装置
５６…会計管理サーバ装置
３０１〜３０３…バス
３１０…ＣＰＵ
３１１…ＲＡＭ
３１２…ＲＯＭ
３１３…ＬＡＮ−Ｉ／Ｆ
３１４…ＭＯＤＥＭ
３２０〜３２２…Ｉ／Ｆ
３３０…画面表示装置
３３１…キーボード
３３２…マウス
３３３…プリンタ装置
３４０…ＨＤＤ装置
３４１…ＣＤドライブ装置
３４２…ＦＤＤ装置
【特許請求の範囲】
【請求項１】
時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得すると共に、
スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成してから、
該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化して、データ管理保存データベースに格納し、
スナップショットしたテーブルの閲覧の際には、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うようにしたことを特徴とするデータ管理保存方法。
【請求項２】
請求項１のスナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートした、レコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成し、該インデックスデータテーブルを前記データ管理保存データベースに格納するようにしたことを特徴とするデータ管理保存方法。
【請求項３】
請求項２のインデックスデータテーブルを用いて、前記データ管理保存データベースに格納の前記ブロック単位生成ファイルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測しつつ、予測されたブロックの前記圧縮・暗号化の伸張・復号を行ってから該ブロックにおいて検索を行うようにし、
これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張・復号及び検索を行いながら、検索結果を閲覧に供するようにしたことを特徴とするデータ管理保存方法。
【請求項４】
請求項２又は請求項３の前記インデックスデータテーブルが、複数のブロックに亘る連番のレコード番号の順列によって、前記レコード順列情報が保存されていることを特徴とするデータ管理保存方法。
【請求項５】
請求項１乃至請求項４のいずれか１つにおける前記ブロック単位生成ファイルの圧縮・暗号化を、予め設定された定期的日時の単位で合成し、前記データ管理保存データベースに格納するようにしたことを特徴とするデータ管理保存方法。
【請求項６】
請求項１乃至請求項４のいずれか１つにおける前記スナップショット取得から少なくとも前記ブロック分け編成までの処理を、経理業務上、情報が確定する第１の定期的日時の単位で行うと共に、
該第１の定期的日時より長期周期となる第２の定期的日時で、異なる該第１の定期的日時において前記ブロック分け編成されたブロック単位生成ファイルから、別のブロック単位生成ファイルを合成することを特徴とするデータ管理保存方法。
【請求項７】
時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得するスナップショット処理部と、
スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成するブロック化処理部と、
該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化するブロック別圧縮・暗号化処理部と、
スナップショット取得したテーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理部と、
前記圧縮・暗号化の情報、及び該インデックスデータテーブルを格納するデータ管理保存データベースと、
スナップショットしたテーブルの閲覧の際に、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うブロック別復号化処理部と、
前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測し、予測されたブロックの前記圧縮・暗号化の伸張・復号を行って該ブロックを検索し、これにより、検索対象のテーブルを逐次部分的に伸張・復号を行いながら、検索結果を取得するブロック検索処理部と、
該検索結果を利用者の閲覧に供する閲覧処理部と、
を備えたことを特徴とするデータ管理保存装置。
【請求項８】
請求項１乃至請求項６のいずれか１つに記載のデータ管理保存方法、又は請求項７に記載のデータ管理保存装置を実施するためのコンピュータ・プログラム。
【請求項１】
時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得すると共に、
スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成してから、
該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化して、データ管理保存データベースに格納し、
スナップショットしたテーブルの閲覧の際には、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うようにしたことを特徴とするデータ管理保存方法。
【請求項２】
請求項１のスナップショットの際に、テーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートした、レコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成し、該インデックスデータテーブルを前記データ管理保存データベースに格納するようにしたことを特徴とするデータ管理保存方法。
【請求項３】
請求項２のインデックスデータテーブルを用いて、前記データ管理保存データベースに格納の前記ブロック単位生成ファイルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測しつつ、予測されたブロックの前記圧縮・暗号化の伸張・復号を行ってから該ブロックにおいて検索を行うようにし、
これにより、検索対象のテーブルに含まれるブロック単位に逐次部分的に伸張・復号及び検索を行いながら、検索結果を閲覧に供するようにしたことを特徴とするデータ管理保存方法。
【請求項４】
請求項２又は請求項３の前記インデックスデータテーブルが、複数のブロックに亘る連番のレコード番号の順列によって、前記レコード順列情報が保存されていることを特徴とするデータ管理保存方法。
【請求項５】
請求項１乃至請求項４のいずれか１つにおける前記ブロック単位生成ファイルの圧縮・暗号化を、予め設定された定期的日時の単位で合成し、前記データ管理保存データベースに格納するようにしたことを特徴とするデータ管理保存方法。
【請求項６】
請求項１乃至請求項４のいずれか１つにおける前記スナップショット取得から少なくとも前記ブロック分け編成までの処理を、経理業務上、情報が確定する第１の定期的日時の単位で行うと共に、
該第１の定期的日時より長期周期となる第２の定期的日時で、異なる該第１の定期的日時において前記ブロック分け編成されたブロック単位生成ファイルから、別のブロック単位生成ファイルを合成することを特徴とするデータ管理保存方法。
【請求項７】
時系列的に発生するデータが格納されている管理対象のデータベースの情報をスナップショット取得するスナップショット処理部と、
スナップショット取得した該情報を後日閲覧する際の、閲覧単位に含まれると予測される少なくともレコード数でブロック分けして編成して、ブロック単位生成ファイルを生成するブロック化処理部と、
該ブロック単位生成ファイルを該ブロック単位で圧縮・暗号化するブロック別圧縮・暗号化処理部と、
スナップショット取得したテーブル単位で、該テーブルに含まれるレコードを特定データ項目でソートしたレコード順列の情報が少なくとも保存されるインデックスデータテーブルを作成するインデックスデータテーブル作成処理部と、
前記圧縮・暗号化の情報、及び該インデックスデータテーブルを格納するデータ管理保存データベースと、
スナップショットしたテーブルの閲覧の際に、該ブロック単位で、該圧縮・暗号化の伸張・復号を行うブロック別復号化処理部と、
前記インデックスデータテーブルを用いて、前記データ管理保存データベースに格納のテーブルのレコードを検索する際、まず対象レコードがどのブロックに格納されているか予測し、予測されたブロックの前記圧縮・暗号化の伸張・復号を行って該ブロックを検索し、これにより、検索対象のテーブルを逐次部分的に伸張・復号を行いながら、検索結果を取得するブロック検索処理部と、
該検索結果を利用者の閲覧に供する閲覧処理部と、
を備えたことを特徴とするデータ管理保存装置。
【請求項８】
請求項１乃至請求項６のいずれか１つに記載のデータ管理保存方法、又は請求項７に記載のデータ管理保存装置を実施するためのコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−２５６１４４（Ｐ２０１２−２５６１４４Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１１−１２７９９３（Ｐ２０１１−１２７９９３）
【出願日】平成２３年６月８日（２０１１．６．８）
【出願人】（０００２００２５３）ＪＦＥシステムズ株式会社 (38)
【Ｆターム（参考）】
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２３年６月８日（２０１１．６．８）
【出願人】（０００２００２５３）ＪＦＥシステムズ株式会社 (38)
【Ｆターム（参考）】
[ Back to top ]