(57)【要約】【課題】文書ファイルの登録、更新、削除処理のパフォーマンスを低下させずに、空き容量や使用容量の更新や確認を可能とすることを目的とする。【解決手段】ストレージの使用可能容量に関するレコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードとを、空き容量テーブルに登録する。そして、空き容量テーブルに登録された複数のレコードを合算し、ストレージの空き容量を取得することによって課題を解決する。【選択図】図１０
2015203963.tif 000002
【特許請求の範囲】
【請求項１】
ストレージの使用可能容量に関するレコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードとを、空き容量テーブルに登録する登録手段と、
前記登録手段により登録された複数のレコードを合算し、前記ストレージの空き容量を取得する空き容量取得手段と、
を有する情報処理装置。
【請求項２】
前記ストレージの使用可能容量を示すキャビネット容量と前記空き容量取得手段により取得された前記空き容量とに基づいて、前記ストレージの使用容量を取得する使用容量取得手段を更に有する請求項１記載の情報処理装置。
【請求項３】
前記文書ファイルの操作処理とは、前記文書ファイルの登録処理、前記文書ファイルの更新処理、前記文書ファイルの削除処理である請求項１又は２記載の情報処理装置。
【請求項４】
前記空き容量テーブルに含まれる複数の増減レコードをベースレコードに併合し、前記複数の増減レコードを削除する併合手段を更に有する請求項１乃至３何れか１項記載の情報処理装置。
【請求項５】
前記併合手段は、前記空き容量テーブルに含まれる対象とする複数の増減レコードをロックし、ロックに成功した場合、前記対象とする複数の増減レコードをベースレコードに併合し、前記対象とする複数の増減レコードを前記空き容量テーブルから削除する請求項４記載の情報処理装置。
【請求項６】
ストレージの使用可能容量に関する増減レコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードとを、空き容量テーブルに登録する登録手段と、
前記登録手段により登録された複数の前記増減レコードを合算し、前記ストレージの空き容量を取得する空き容量取得手段と、
を有する文書管理システム。
【請求項７】
前記ストレージの使用可能容量を示すキャビネット容量と前記空き容量取得手段により取得された前記空き容量とに基づいて前記ストレージの使用容量を取得する使用容量取得手段を更に有する請求項６記載の文書管理システム。
【請求項８】
情報処理装置が実行する情報処理方法であって、
ストレージの使用可能容量に関するレコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードを空き容量テーブルに登録する登録ステップと、
前記登録ステップにより登録された複数のレコードを合算し、前記ストレージの空き容量を取得する空き容量取得ステップと、
を含む情報処理方法。
【請求項９】
文書管理システムが実行する情報処理方法であって、
ストレージの使用可能容量に関する増減レコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードとを、空き容量テーブルに登録する登録ステップと、
前記登録ステップにより登録された複数の前記増減レコードを合算し、前記ストレージの空き容量を取得する空き容量取得ステップと、
を含む情報処理方法。
【請求項１０】
コンピュータに、
ストレージの使用可能容量に関するレコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードとを、空き容量テーブルに登録する登録ステップと、
前記登録ステップにより登録された複数のレコードを合算し、前記ストレージの空き容量を取得する空き容量取得ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、文書管理システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
文書管理システムでは、ストレージの利用容量を制限したり、アクセス制御や利用方法に応じてカスタマイズしたりするために、ストレージを区分けして管理する場合が多い。この区分けの呼び方はシステムによって異なり、例えば、キャビネットやライブラリといった呼称が使われる（以下、キャビネットという）。
キャビネットの属性情報には、キャビネットが使用できるストレージの容量を定義したキャビネット容量と、キャビネットが実際に使用しているストレージ容量を示す使用容量とがある。キャビネット容量と使用容量とは、利用上限を越えて文書ファイルが登録されないようにチェックしたり、ユーザーがキャビネットの状況を即時に確認したりするために保持される。
使用容量は、文書ファイルの登録、更新、削除が行われるたびに変化するものであり、かつ、タイムラグが許容できない。そのため、文書ファイルの登録、更新、削除が行われるたびに算出され、値の更新が行われていた（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−３１６６２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
以下、図１〜図３を用いて、文書管理システムの一例について述べる。
図１は、文書管理システムのデータ構造をイメージで示した図である。テナント３００は主にクラウド型システム等で用いられるデータの境界を示している。クラウド型のシステムでは１つのシステム環境の中に複数企業やユーザーを同居させるマルチテナント方式をとっており、各企業やユーザーのデータが混合することを避けるために、企業やユーザー毎の論理的な境界（テナント間の論理的な境界）を設けている。例えば、境界３００はテナントの論理的な境界を示す。各テナントが利用可能なリソース（計算能力やストレージ容量など）は、クラウドサービスを提供している会社と各テナントとの間の契約に依存する。また、文書管理システムでは、ストレージの利用容量を制限したり、アクセス制御や利用方法に応じてカスタマイズしたりするために、各テナント内で更にストレージを区分けして管理する場合が多く、この区分けがキャビネットである。境界３０１、３０２、３０３はキャビネットの境界を示す。キャビネット内にはフォルダ３１１や文書ファイル３２１が多数存在している。また、キャビネット内のフォルダやファイルには複数のユーザー又はシステムがアクセスする。文書管理システムでは、キャビネット毎にストレージ容量を割り当てることができる。例えば、企業がテナントとしてクラウドサービスの文書管理システムを利用する場合、テナント内に部署単位でキャビネットを作成し、各部署のキャビネットごとにストレージ使用可能容量を割り当てるといった運用が可能になる。
【０００５】
図２は、キャビネットの属性情報を保管する、データベース上のテーブル（以下、テーブルという）の一例を示す図である。テナントＩＤ列４０１は、図１の３００で示したテナントを識別するＩＤである。キャビネットＩＤ列４０２は、図１の３０１、３０２、３０３で示したテナント内のキャビネットを識別するＩＤである。テナントＩＤ列４０１とキャビネットＩＤ列４０２とによって、システム内で一意のキャビネットが特定されることになる。最大サイズ列４０３は、ストレージの使用可能容量を示すキャビネット容量を保管する列である。使用容量列４０４は、キャビネットの使用容量を保管する列である。使用容量列４０４の値は、文書ファイルの登録、更新、削除といった処理が行われる度に変化することになる。また、キャビネット属性情報テーブルは、キャビネットの属性情報を管理する際にも参照、更新される。
【０００６】
図３は、文書ファイル更新処理の一例を示すフローチャートである。まず、クライアント端末から更新する文書ファイルがアップロードされると、文書管理システムのアプリケーションプログラムがＣＰＵによって呼び出される。アプリケーションプログラムは、記憶装置から読み込まれ、メモリに格納した上で、ＣＰＵによって実行される。そして、ＣＰＵは、まず、アップロードされた文書ファイルを受信する（Ｓ５０１）。ここで、ＣＰＵは、文書ファイルの更新によって文書ファイルを上書きしてしまう前に、文書管理システム内の既存文書の情報を取得しておく（Ｓ５０２）。その後、文書ファイルの更新を行う（Ｓ５０３）。より具体的に説明すると、ステップＳ５０３において、ＣＰＵは、文書ファイルを記憶装置に保管すると共に関連する属性情報をデータベースに格納し、既存の文書ファイルを削除する。そして、ＣＰＵは、Ｓ５０２で取得した既存文書ファイルの情報とアップロードされた更新文書ファイルの情報とからファイルサイズの増減を算出する（Ｓ５０４）。ファイルサイズの増減は、プラス値、即ちファイルサイズが大きくなる場合もあれば、マイナス値、即ちファイルサイズが小さくなる場合もある。そして、ＣＰＵは、ファイルサイズが増加したかどうかを判定し（Ｓ５０５）、増加する場合はキャビネットの空き容量を図２のキャビネット属性情報テーブルから算出して取得する（Ｓ５０６）。ＣＰＵは、空き容量を、最大サイズ列４０３の値から使用容量列４０４の値を減算することで算出する。そして、ＣＰＵは、キャビネットに文書ファイルを保管できる空き容量があるかどうかの判定を行う（Ｓ５０７）。判定処理は、Ｓ５０６で取得した空き容量内に、Ｓ５０４で算出したファイルサイズの増加量が収まるかどうかを判定するものであり、Ｓ５０５でファイルサイズが減少する場合にはＳ５０６、Ｓ５０７は行う必要が無い。空き容量があれば、ＣＰＵは、キャビネット属性情報テーブルの使用容量列４０４の値を更新し（Ｓ５０８）、データベースの更新処理をコミットする（Ｓ５０９）。また、空き容量がなければ、ＣＰＵは、データベースの更新処理を破棄し、Ｓ５０２で取得しておいた既存文書の情報に基づいて更新前の状態に戻す（Ｓ５１０）。
【０００７】
なお、ここでは文書ファイルの更新処理について述べたが、文書ファイルの登録処理や文書ファイルの削除処理も類似の処理が行われる。文書ファイルの登録では常にファイルサイズが増加し、文書ファイルの削除では常にファイルサイズが減少することになり、Ｓ５０８のような使用容量の更新処理が行われる。また、文書ファイルをバージョン管理する場合には、ＣＰＵ１０２は、保管するバージョンの上限数等も考慮し、ファイルサイズの増減を算出することになる。
【０００８】
図１で示したように、キャビネット内には多くの文書ファイルが存在し、複数のユーザーやシステムがアクセスする。一方、キャビネットの使用容量はデータベースで管理されており、キャビネットに紐付く属性であるため、図２で示したようなキャビネット属性情報テーブルを用いて一元的に保管されている。そして、図３で示したように、文書ファイルの登録、更新、削除処理はキャビネットの使用容量に影響するため、その都度、キャビネットの使用容量情報を更新する必要がある。そのため、アクセスが集中すると、文書ファイルの登録、更新、削除処理が同時に行われ、図３のＳ５０８で示したような使用容量の更新処理も同時に行われるケースが多くなる。このような場合、ある処理がデータベースの使用容量情報を更新するためレコードをロックすると、その間、他の処理はロックが解除されるのを待つことになる。その結果、文書ファイルの登録、更新、削除処理のパフォーマンスが低下するといった課題が発生してしまう。
【０００９】
本発明は、文書ファイルの登録、更新、削除処理のパフォーマンスを低下させずに、空き容量や使用容量の更新や確認を可能とすることを目的とする。
【課題を解決するための手段】
【００１０】
そこで、本発明の情報処理装置は、ストレージの使用可能容量に関するレコードと、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードとを、空き容量テーブルに登録する登録手段と、前記登録手段により登録された複数のレコードを合算し、前記ストレージの空き容量を取得する空き容量取得手段と、を有する。
【発明の効果】
【００１１】
本発明によれば、文書ファイルの登録、更新、削除処理のパフォーマンスを低下させずに、空き容量や使用容量の更新や確認を可能とすることができる。
【図面の簡単な説明】
【００１２】
【図１】文書管理システムのデータ構造をイメージで示した図である。
【図２】キャビネットの属性情報を保管するデータベース上のテーブルの一例を示す図である。
【図３】文書ファイル更新処理の一例を示すフローチャートである。
【図４】情報処理装置のハードウェア構成の一例を示す図である。
【図５】システム構成の一例を示す図である。
【図６】文書管理システムのソフトウェア構成の一例を示す図である。
【図７】キャビネット属性情報を保管するテーブルの一例を示す図である。
【図８】キャビネットの空き容量を保管するテーブルの一例を示す図である。
【図９】空き容量テーブルに空き容量の増減レコードを追加した一例を示す図である。
【図１０】文書ファイル更新処理のフローチャートである。
【図１１】キャビネットの空き容量を算出する際のＳＱＬ文の一例を示す図である。
【図１２】キャビネット容量変更処理の一例を示すフローチャートである。
【図１３】キャビネット使用容量算出処理の一例を示すフローチャートである。
【図１４】空き容量の増減レコードマージ処理の一例を示すフローチャートである。
【図１５】空き容量の増減レコードマージ後の空き容量テーブルの一例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施形態について図面に基づいて説明する。
【００１４】
図４は、情報処理装置のハードウェア構成の一例を示す図である。情報処理装置は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下、Ｉ／Ｏという）インタフェース１０６、通信インタフェース１０７を備えている。また、情報処理装置内の各構成要素はシステムバス１０１を介して互いに接続されている。ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＣＤ−ＲＯＭドライブ１１２、フレキシブルディスクドライブ（ＦＤＤ）１１３がある。図４には示されていないが、記憶装置１０４としては、磁気テープドライブ、ＤＶＤ−ＲＯＭ、ＵＳＢメモリ等が使用されてもよい。
本実施形態に係るプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納され、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、ＲＯＭから読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。ＣＰＵ１０２が、プログラムに基づき処理を実行することによって、情報処理装置の機能及び後述するフローチャートの処理が実現される。
【００１５】
ビデオインタフェース１０５は、ディスプレイ装置１１４への表示出力を制御する。ディスプレイ装置１１４には、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより情報処理装置に対する動作指令等を行う。ポインティングデバイス１１６は、操作者による操作に応じて、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置とを兼ねることになる。
通信インタフェース１０７は、ネットワーク１１７を通して外部機器との通信を行う。ネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等がある。また、通信インタフェース１０７は、ローカルプリンタ１１８等の他デバイスとの通信も行う。
【００１６】
図５は、システム構成の一例を示す図である。ネットワーク２０１には、サーバーコンピュータ（以下、サーバーという）２０２、クライアントパーソナルコンピュータ（以下、クライアント端末という）２０３、タブレット端末２０４が接続されている。ネットワーク２０１には、ＬＡＮ、ＷＡＮ、インターネット等がある。クライアント端末２０３及びタブレット端末２０４といったクライアント端末は、ネットワーク２０１を通じてサーバー２０２と通信を行う。なお、本実施形態において、クライアント端末２０３、タブレット端末２０４、サーバー２０２は何れも、図４にて示した情報処理装置の構成を有するものとする。但し、図４の構成に限定するものではなく、他の機能を備えていてもよい。また、サーバー２０２は、単体のコンピュータに限らず、ラックマウント型のシステムであってもよい。
【００１７】
本実施形態に係る文書管理システムはサーバー２０２で動作し、クライアント端末２０３やタブレット端末２０４といったクライアント端末からサーバー上のデータにアクセスされる形態を想定している。但し、文書管理システムが、サーバー２０２及びクライアント端末２０３又は２０４で処理を分担して行ったりする形態もありえる。
ここで、文書管理システムとは、主に電子文書や電子化された紙文書を保管、管理するコンピュータ上のシステムのことを意味する。文書管理システムにおいて、電子文書や電子化された紙文書はコンピュータ上のファイル形式で保管される。したがって、文書管理システムで扱う電子文書は、文字による文書コンテンツに限定されず、画像や動画コンテンツ等、ファイル形式で保管されるデータを全て含むものとする（以下、ファイル形式で保管される電子文書を文書ファイルという）。
本実施形態に係る文書管理システムがサーバー２０２で動作する形態の一例では、サーバー２０２上に、データベース、アプリケーションサーバー、Ｗｅｂサーバーといったサーバーアプリケーションがインストールされる。クライアント端末２０３、２０４上には、Ｗｅｂブラウザ又は専用のクライアントアプリケーションがインストールされる。クライアント端末２０３、２０４から、サーバー２０２へデータの取得リクエストが発信されると、サーバー２０２上のＷｅｂサーバーがクライアント端末からのリクエストを受信する。そして、アプリケーションサーバーがリクエスト内容を解釈して必要なデータをデータベースから取得する。そして、アプリケーションサーバーは、Ｗｅｂサーバーを通して、取得したデータをクライアント端末２０３、２０４へ送信する。クライアント端末２０３、２０４では、データを受信すると、Ｗｅｂブラウザ又は専用のクライアントアプリケーションが、取得したデータをクライアント端末のディスプレイ装置１１４に表示する。
【００１８】
図６は、文書管理システムのソフトウェア構成の一例を示す図である。リクエスト受信／レスポンス送信部６０１は、クライアント端末２０３、２０４からのリクエストを、受信する処理と、クライアント端末２０３、２０４へのレスポンスを送信する応答処理とを行う。キャビネット管理部６０２は、リクエスト受信／レスポンス送信部６０１から受信したキャビネットに関する参照や編集処理を行う。文書ファイル／フォルダ管理部６０３は、リクエスト受信／レスポンス送信部６０１から受信したフォルダや文書ファイルに関する参照、登録、更新、削除処理等を行う。データベースアクセス部６０４は、キャビネット管理部６０２や文書ファイル／フォルダ管理部６０３の処理内容に基づいてデータベースの参照、登録、更新、削除処理等処理を行う。マージ処理部６０５は、レコードのマージ処理（併合処理）を行う。
【００１９】
図７は、キャビネット属性情報を保管するテーブル（キャビネット属性情報テーブル）の一例を示す図である。テナントＩＤ列７０１は、図１の３００で示したテナントを識別するＩＤである。キャビネットＩＤ列７０２は、図１の３０１、３０２、３０３で示したテナント内のキャビネットを識別するＩＤである。テナントＩＤ列７０１とキャビネットＩＤ列７０２とによって、システム内で一意のキャビネットが特定されることになる。最大サイズ列７０３は、キャビネット容量を保管する列である。列７０１、列７０２、列７０３は、図２の列４０１、列４０２、列４０３と同じである。但し、図２の使用容量列４０４は、図７のキャビネット属性情報テーブルにはなく、空き容量の情報を保管するテーブル（図８の空き容量テーブル）に該当する内容が格納される。
【００２０】
図８は、キャビネットの空き容量に関する情報を保管するテーブル（空き容量テーブル）の一例を示す図である。テナントＩＤ列８０１はテナントを識別するＩＤである。キャビネットＩＤ列８０２はキャビネットを識別するＩＤである。図７のキャビネット属性情報テーブルと同じように、テナントＩＤ列８０１とキャビネットＩＤ列８０２とによって、システム内で一意のキャビネットが特定されることになる。データタイプ列８０３は空き容量テーブルのレコード種別を示す列である。レコード種別が０のレコードは、空き容量を示す値のベースとなるレコードであることを示している。レコード種別が０のレコードは、各キャビネットに必ず１レコード存在し、複数レコードになることはない。空き容量列８０４は、キャビネットの空き容量を保管する列である。図２では、使用容量を保管していたが、文書ファイルの登録、更新、削除処理では、図３のＳ５０６で示したように空き容量の問合せが多い。そこで、空き容量列８０４において空き容量を保管している。
【００２１】
図９は、図８の空き容量テーブルに空き容量の増減レコードを追加した一例を示す図である。テーブルの各列は図８と同じである。レコード９０１は、図８で示したように空き容量のベースとなるレコードである。レコード９０２は、文書ファイルが登録又は更新された場合等に挿入されるレコードを示している。レコード９０２のデータタイプ列８０３に保管されたレコード種別は２であるが、これは文書ファイルの増減を示すレコードであることを示している。空き容量列８０４に保管されたレコード９０２の値−６５３０は、文書ファイルが登録又は更新されたことによってファイルサイズが６５３０バイト増加し、空き容量が６５３０バイト減少したことを意味している。レコード９０３は、文書ファイルが削除又は更新された場合等に挿入されるレコードを示している。空き容量列８０４に保管されたレコード９０３の値１０００は、文書ファイルが削除又は更新されたことによってファイルサイズが１０００バイト減少し、空き容量が１０００バイト増加したことを意味している。レコード９０４は、キャビネットに割り当てられた容量が変更された場合に挿入されるレコードを示している。データタイプ列８０３に保管されたレコード種別は１であるが、これはキャビネットに割り当てられたストレージ容量の増減を示すレコードであることを示している。キャビネット容量を変更した場合、図７の最大サイズ列７０３が変更され、変更されたキャビネット容量の増減値が空き容量テーブルにも挿入される。空き容量列８０４に保管されたレコード９０４の値２００００００は、キャビネットのストレージ最大容量が２００００００バイト増加したことによって、空き容量も２００００００バイト増加したことを意味している。
【００２２】
図１０は、文書ファイル更新処理のフローチャートである。大まかな処理の流れは、図３の文書ファイル更新処理の例と同じであるが、後述のキャビネットの空き容量を取得する処理（Ｓ１００６）と、空き容量テーブルに増減レコードを挿入する処理（Ｓ１００８）との内容が異なる。
図１０において、まず、クライアント端末２０３、２０４から更新する文書ファイルがアップロードされると、文書管理システムのアプリケーションプログラムがＣＰＵ１０２によって呼び出される。アプリケーションプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。
まず、リクエスト受信／レスポンス送信部６０１は、アップロードされた文書ファイルを受信する（Ｓ１００１）。文書ファイル／フォルダ管理部６０３は、文書ファイル更新によって文書ファイルが上書きされてしまう前に既存文書ファイルの情報を取得しておき（Ｓ１００２）、文書ファイルの更新を行う（Ｓ１００３）。より具体的に説明すると、ステップＳ１００３において、文書ファイル／フォルダ管理部６０３は、文書ファイルを記憶装置１０４に保管すると共に関連する属性情報をデータベースに格納し、既存の文書ファイルを削除する。そして、文書ファイル／フォルダ管理部６０３は、Ｓ１００２で取得した既存文書ファイルの情報とアップロードされた更新文書ファイルの情報とからファイルサイズの増減を算出する（Ｓ１００４）。ファイルサイズの増減は、プラス値、即ちファイルサイズが大きくなった場合もあれば、マイナス値、即ちファイルサイズが小さくなった場合もある。文書ファイル／フォルダ管理部６０３は、ファイルサイズが増加したかどうかを判定する（Ｓ１００５）。増加した場合は、キャビネット管理部６０２は、キャビネットの空き容量を図９の空き容量テーブルから取得する（Ｓ１００６）。図９で示したように、空き容量テーブルには、各キャビネットに関して空き容量のベースとなるレコード（各キャビネットに割り当てられた最大ストレージ容量の増減に関するレコード）９０１，９０４と、文書ファイルの追加・変更・削除による容量の増減を示すレコード９０２，９０３と、が存在する。したがって、キャビネットの空き容量はそれらを合算した値である。各キャビネットに割り当てられた最大ストレージ容量の増減に関するレコードは、ストレージの使用可能容量に関するレコードの一例である。文書ファイルの追加・変更・削除による容量の増減を示すレコードは、文書ファイルの操作処理に係るストレージの使用容量の増減を示す増減レコードの一例である。
【００２３】
ステップＳ１００６において、キャビネット管理部６０２がキャビネットの空き容量を算出する際のＳＱＬ文の例を図１１で示す。図１１のＳＱＬ文１１０１にあるＣＡＢＩＮＥＴ＿ＳＰＡＣＥは、空き容量テーブルのテーブル名である。したがって、ＳＱＬ文１１０１は、空き容量テーブルから設定されたキャビネットに関連するレコードの空き容量値を合算し、取得することを示している。キャビネット管理部６０２は、データタイプ列８０３には関係なく、設定されたキャビネットに該当するレコードの空き容量列８０４の値を合算して合計値を求めることで、キャビネットの空き容量を取得することができる。
【００２４】
図１０の説明に戻り、文書ファイル／フォルダ管理部６０３は、キャビネットに文書ファイルを保管できる空き容量があるかどうかの判定を行う（Ｓ１００７）。判定処理は、Ｓ１００６で算出して取得したキャビネットの空き容量に、Ｓ１００４で算出したファイルサイズの増加量が収まるかどうかを判定するものであり、Ｓ１００５でファイルサイズが減少する場合にはＳ１００６、Ｓ１００７は行う必要が無い。Ｓ１００７で空き容量があると判定した場合、キャビネット管理部６０２は、文書ファイルの追加・変更・削除による容量の増減レコードを空き容量テーブルに挿入し（Ｓ１００８）、データベースの更新処理をコミットする（Ｓ１００９）。Ｓ１００８で挿入されるレコードは、ファイルサイズが増加する場合は図９のレコード９０２のようにマイナス値が入り、ファイルサイズが減少する場合は図９のレコード９０３のようなプラス値が入ることになる。ステップＳ１００７で空き容量がないと判断された場合、文書ファイル／フォルダ管理部６０３は、データベースの更新処理を破棄する（Ｓ１０１０）。上記フローチャートの処理において、データベースへのアクセスはデータベースアクセス部６０４によって行われる。リクエスト受信／レスポンス送信部６０１、キャビネット管理部６０２、文書ファイル／フォルダ管理部６０３がデータベースアクセス部６０４を使ってデータベースにアクセスする。
【００２５】
なお、ここでは文書ファイルの更新処理について述べたが、文書ファイルの登録処理や文書ファイルの削除処理も類似の処理が行われる。文書ファイルの登録では常にファイルサイズが増加し、文書ファイルの削除処理では常にファイルサイズが減少することになり、Ｓ１００８のような空き容量増減レコードの挿入処理が行われる。また、文書ファイルをバージョン管理する場合には、文書ファイル／フォルダ管理部６０３は、保管するバージョンの上限数等も考慮し、ファイルサイズの増減を算出することになる。
このように、ステップＳ１００８で行われる処理は、図３のステップＳ５０８と異なり、文書ファイルの追加・変更・削除による容量の増減レコードをテーブルへ挿入する処理である。したがって、レコードのロック解除待ちは発生せず、文書ファイルの登録、更新、削除処理のパフォーマンスは低下しない。
【００２６】
図１２は、キャビネット容量変更処理の一例を示すフローチャートである。キャビネット容量変更処理は、図６のキャビネット管理部６０２によって実行され、データベースへの処理はデータベースアクセス部６０４によって実行される。キャビネット容量を変更する場合も、キャビネットの空き容量に変更が生じるため、空き容量を管理する必要がある。図１２において、まず、キャビネット管理部６０２は、図７で示したキャビネット属性情報テーブルのレコードを取得すると同時にロックする（Ｓ１２０１）。レコードをロックするのは、同時にキャビネット属性情報を更新する処理が行われた場合の不整合を避けるための排他処理が必要となるためである。キャビネット管理部６０２は、レコードのロックができたかどうかを判定し（Ｓ１２０２）、ロックできなかった場合は、排他エラーを返す（Ｓ１２０３）。キャビネット管理部６０２は、ロックできた場合は、変更サイズがプラス値、即ち容量を増加させるのか、変更サイズがマイナス値、即ち容量を減少させるのかを判定する（Ｓ１２０４）。キャビネット管理部６０２は、変更サイズがプラス値の場合は、ステップＳ１２０８へ進む。キャビネット管理部６０２は、変更サイズがマイナス値であった場合は、空き容量テーブルから現在のキャビネット空き容量を取得する（Ｓ１２０５）。空き容量の取得処理は、図１０のステップＳ１００６の処理と同じである。そして、キャビネット管理部６０２は、変更サイズの絶対値、即ち減少するサイズと空き容量とを比較する（Ｓ１２０６）。キャビネット管理部６０２は、減少するサイズが空き容量より大きい場合は、使用容量よりもキャビネット容量が小さくなってしまうため更新不可エラーとする（Ｓ１２０７）。キャビネット管理部６０２は、減少するサイズが空き容量より小さい場合は、Ｓ１２０８に進む。Ｓ１２０８において、キャビネット管理部６０２は、Ｓ１２０１で取得したキャビネット属性情報テーブルの最大サイズ列７０３の値と、変更サイズと、を合算し、合算した値でキャビネット属性情報テーブルの最大サイズ列７０３の値を更新する。次に、キャビネット管理部６０２は、空き容量テーブルに増減レコードを挿入し（Ｓ１２０９）、データベースへの更新処理をコミットする（Ｓ１２１０）。ステップＳ１２０９では、図９のレコード９０４のようなレコードが挿入される。
このように、キャビネット容量の変更処理においても、ステップＳ１２０９の通り空き容量の変更をレコード挿入で行うため、空き容量テーブルのレコードのロック解除待ちは発生せず、文書ファイルの登録、更新、削除処理のパフォーマンスは低下しない。また、キャビネット属性情報テーブルは、文書ファイルの登録、更新、削除処理では参照する必要がないため、パフォーマンスには影響しない。
【００２７】
図１３は、キャビネット使用容量算出処理の一例を示すフローチャートである。キャビネット使用容量算出処理は、図６のキャビネット管理部６０２で実行され、データベースへの処理はデータベースアクセス部６０４で実行される。図２に示すキャビネット属性情報テーブルにあった使用容量列４０４を、図８で示した空き容量テーブルでは空き容量列８０４としたため、キャビネット管理部６０２は、使用容量を算出する場合は、キャビネット容量から空き容量を減算することになる。Ｓ１３０１において、キャビネット管理部６０２は、空き容量テーブルからキャビネットの空き容量を取得する。この処理は図１０のステップＳ１００６と同様である。また、Ｓ１３０２において、キャビネット管理部６０２は、キャビネット属性情報テーブルの最大サイズ列７０３からキャビネット容量を取得する。そして、Ｓ１３０３において、キャビネット管理部６０２は、キャビネット容量から空き容量を減算して使用容量を求める（使用容量取得）。
【００２８】
図１４と図１５とで、空き容量の増減レコードマージ処理について説明する。図９、図１０のステップＳ１００８や図１２のステップＳ１２０９で説明したように、空き容量に増減があった場合は、空き容量テーブルに増減レコードが挿入されて行く。空き容量の取得は図１１のＳＱＬ文１１０１で行われるため、増減レコードが多数あっても、空き容量取得処理のパフォーマンスはほとんど低下しない。但し、文書管理システムの運用を続けて行き、増減レコードが膨大な数になった場合は、空き容量算出処理のパフォーマンスが低下する可能性がある。そのため、定期的に増減レコードを削減する処理が必要となる。
【００２９】
図１４は、空き容量の増減レコードマージ処理の一例を示すフローチャートである。増減レコードマージ処理は、図６のマージ処理部６０５で実行される。但し、具体的には、空き容量テーブルの更新処理はキャビネット管理部６０２で実行される。データベースの処理はデータベースアクセス部６０４で実行される。図１４において、マージ処理部６０５は、空き容量テーブルの更新対象レコードをロックし（Ｓ１４０１）、ロックが成功したかどうかを判定する（Ｓ１４０２）。マージ処理部６０５は、ロックが失敗した場合には、排他エラーとする（Ｓ１４０３）。マージ処理部６０５は、ロックが成功した場合は、空き容量テーブルからキャビネットの空き容量を取得する（Ｓ１４０４）。この処理は図１０のステップＳ１００６と同様である。次に、マージ処理部６０５は、ステップＳ１４０４で取得した空き容量の値で、空き容量テーブルのベースとなるレコード更新する（Ｓ１４０５）。ベースとなるレコードとは、図８で説明したデータタイプ列８０３の値が０のレコードのことであり、マージ処理部６０５は、このレコードの空き容量列８０４の値を更新する。そして、マージ処理部６０５は、空き容量テーブルの増減レコードを削除する（Ｓ１４０６）。増減レコードとは、図８で説明したデータタイプ列８０３の値が１又は２のレコードのことである。最後にマージ処理部６０５は、データベースの更新処理をコミットする（Ｓ１４０７）。
【００３０】
図１５は、空き容量の増減レコードマージ後の空き容量テーブルの一例を示す図である。図１５の空き容量テーブルの内容は、図９に示した空き容量テーブルの増減レコードをベースレコードにマージした内容になっている。レコード１５０１はベースレコードで、ステップＳ１４０４で取得した空き容量がレコード１５０１の空き容量列８０４の値１１９７６３１０として保管されている。点線１５０２は削除されたレコードを示している。図９の増減レコードの値がベースレコードに集約され、削除されていることを示している。
図１４と図１５とで示した空き容量の増減レコードマージ処理は図６のマージ処理部６０５が実行するが、マージ処理部６０５の実行方法として様々な方法が考えられる。例えば、スケジューラの時間指定や間隔指定によって定期的にマージ処理を実行する方法や、定期的に増減レコードの件数を確認又は文書ファイルの更新処理回数をカウントして所定の件数を上回っていた場合にマージ処理を実行する方法等がある。更に、図１２のキャビネット容量変更処理や、使用容量の参照等、図１３のキャビネット使用容量処理が実行されるタイミングに行うといった方法もある。
以上によって、文書ファイル登録、更新、削除処理のパフォーマンスを低下させずに、キャビネットの使用容量の更新や確認を行うことができる。
なお、本実施形態では、図８、図９のように空き容量を管理するテーブルを用いたが、使用容量を管理するテーブルを用いてもよい。
【００３１】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００３２】
１０２  ＣＰＵ、２０２  サーバーコンピュータ
【図１】
2015203963.tif 000003
【図２】
2015203963.tif 000004
【図３】
2015203963.tif 000005
【図４】
2015203963.tif 000006
【図５】
2015203963.tif 000007
【図６】
2015203963.tif 000008
【図７】
2015203963.tif 000009
【図８】
2015203963.tif 000010
【図９】
2015203963.tif 000011
【図１０】
2015203963.tif 000012
【図１１】
2015203963.tif 000013
【図１２】
2015203963.tif 000014
【図１３】
2015203963.tif 000015
【図１４】
2015203963.tif 000016
【図１５】
2015203963.tif 000017