JP2015102971A - 文書管理システム、文書管理システムにおける情報処理装置、文書管理方法及びプログラム - Google Patents

Abstract

【課題】文書管理システムにおいて、データベースの使用量を削減して、低コストかつ効果的にファイル実体を管理する。【解決手段】文書のファイル実体とその属性情報とを管理する第１のサーバと、文書のファイル実体は管理するがその属性情報は管理しない第２のサーバと、通信可能な情報処理装置であって、受信した文書のファイル実体の管理を前記第１のサーバ及び前記第２のサーバに指示するファイル実体処理手段と、受信した文書の属性情報の管理を前記第１のサーバに指示する属性情報処理手段と、を備え、前記ファイル実体処理手段は、前記第１のサーバに格納されているファイル実体に対するアクセスが一定期間ない場合に、当該ファイル実体の削除を前記第１のサーバに対し指示する、ことを特徴とする。【選択図】図５

Description

本発明は、文書管理システム上で管理する文書のファイル実体及び属性情報を管理する技術に関する。

一般的な文書管理システムでは、クライアントＰＣから登録されるファイルに紐付いた属性（例えばファイル名、サイズ等）の情報をキーにして、目的とするファイルを検索する検索機能を、データベースを用いて提供することが多い。その際、ファイル実体はファイルサーバで管理し、属性情報はデータベースサーバで管理するといった手法が採られたり、もしくは、ファイル実体と属性情報の両方ともデータベースサーバで管理するといった手法が採られる。また、特許文献１のようにファイル実体を登録時用と長期保存用とで別々の保管場所を用意し、どちらか一方で管理するということも提案されている。

特開２００６−２６８７０１号公報

ここで、ファイル実体のみをファイルサーバ上で管理する手法の場合は、ファイルサーバは安価でかつ大容量であるため有効的な管理方法と言える。しかし、文書管理をする上で必要な属性情報がデータベースサーバ上にあるため、データベースサーバ内の属性情報を取得した上でファイルサーバへのアクセスが行なわれるのでパフォーマンスが低下してしまうという難点がある。

また、ファイル実体と属性情報の両方をデータベースサーバで管理する手法の場合は、データベースサーバへのアクセスだけで完結するため、パフォーマンスは良い。しかし、データベースサーバはファイルサーバとは違って比較的高価であり、かつ容量も大きくはないためコストが高くなってしまう。

本発明に係る情報処理装置は、文書のファイル実体とその属性情報とを管理する第１のサーバと、文書のファイル実体は管理するがその属性情報は管理しない第２のサーバと、通信可能な情報処理装置であって、受信した文書のファイル実体の管理を前記第１のサーバ及び前記第２のサーバに指示するファイル実体処理手段と、受信した文書の属性情報の管理を前記第１のサーバに指示する属性情報処理手段と、を備え、前記ファイル実体処理手段は、前記第１のサーバに格納されているファイル実体に対するアクセスが一定期間ない場合に、当該ファイル実体の削除を前記第１のサーバに対し指示する、ことを特徴とする。

本発明によれば、文書管理システムにおいて、データベースの使用量を削減して、低コストかつ効果的にファイル実体を管理することが可能となる。

文書管理システムの構成の一例を示す図である。 文書管理システムを構成するサーバ群内の各種サーバ及びクライアントＰＣのハードウェア構成を示す図である。 文書管理システムのソフトウェア構成を示す図である。 ユーザ情報管理テーブルの一例を示す図である。 実施例１に係る、ファイル実体及び属性情報の登録処理の流れを示すフローチャートである。 実施例１に係る、属性情報管理テーブルの一例を示す図である。 ファイル実体管理テーブルの一例を示す図である。 実施例１に係る、ＷｅｂサーバからクライアントＰＣへファイル実体を送信する処理の流れを示すフローチャートである。 実施例１に係る、ファイル実体をＤＢのファイル実体管理テーブルから削除する処理の流れを示すフローチャートである。 実施例２に係る、属性情報管理テーブルの一例を示す図である。 実施例２に係る、ファイル実体管理テーブルにファイル実体を格納しておく期間をアクセス可能なユーザ数に応じて設定・管理するためのテーブルの一例を示す図である。

以下、本発明を実施するための形態について図面を用いて説明する。

なお、以下に述べる実施例は説明の便宜上、本発明に関連する最低限のハードウェア構成、ソフトウェア構成、データ構成、及び処理フローを記載しているが、本発明の範囲は以下の説明において特に記載がない限り、これらの態様に限られるものではない。

（システム構成）
図１は、本実施例に係る文書管理システムの構成の一例を示す図である。本実施例に係る文書管理システム１００は、ネットワーク１１０上にクライアントＰＣ１０１（１）、１０１（２）、・・・、１０１（Ｎ：自然数）が接続されており、さらにサーバ群１０２が接続されている。そして、クライアントＰＣ１０１とサーバ群１０２とは、ネットワーク１１０を介して相互に通信可能となっている。なお、ネットワーク１１０は、例えばインターネットまたはイントラネット回線を表す。

サーバ群１０２は、Ｗｅｂサーバ１０３、データベースサーバ（以下、ＤＢ）１０４、ファイルサーバ（以下、ＦＳ）１０５で構成される。

Ｗｅｂサーバ１０３は、クライアントＰＣ１０１からのリクエストを受け付け、レスポンスを返却するサーバである。本明細書では、Ｗｅｂサーバ１０３を、クライアントＰＣ１０１からのＨＴＴＰリクエストに対するレスポンスを処理するＨＴＴＰサーバと、ＤＢ１０４やＦＳ１０５への橋渡しを担い、データの加工等を行なうアプリケーションサーバをまとめたものとして扱う。実際のＷｅｂサーバの構成が、ＨＴＴＰサーバとアプリケーションサーバのように別々の構成であっても構わないが、本実施例では説明の簡略化のため１つのサーバとして記載する。

ＤＢ１０４は、ファイル実体及びファイルの属性情報を管理するサーバであり、ファイルの検索や抽出を行なうサーバである。本実施例においては、ＯＳが提供するファイルシステム上に直接構築するものを指すのではなく、データベース管理プログラムを用いて構築した高速かつ安定したデータ管理を行なうサーバを指す。

ＦＳ１０５は、ファイル実体を管理するサーバである。ＦＳ１０５は、ファイル実体を管理するための記憶装置としての役割を有するため、一般的には高度な演算能力や描画能力は求められない。そのため、同じ容量のデータを扱う場合は、ＤＢ１０４と比べて入出力の処理能力が低い。

（クライアントＰＣ及び各種サーバのハードウェア構成）
図２は、文書管理システム１００を構成するサーバ群１０２内の各種サーバ（１０３〜１０５）、及びクライアントＰＣ１０１のハードウェア構成を示す図である。

サーバ群１０２内の各種サーバ（１０３〜１０５）及びクライアントＰＣ１０１は、一般的な情報処理装置のハードウェア構成を有するものとし、まとめて情報処理装置２００と記すこととする。

ＣＰＵ２０１は、情報処理装置２００の演算／制御を司る。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリとして実行プログラムの領域や該プログラムの実行エリア並びにデータエリアとして機能する。実行プログラムは、後述する外部メモリ２１３からＲＡＭ２０２に読み出されて実行される。

プログラムＲＯＭ２０３は、情報処理装置２００の機器制御を行なうシステムプログラムの基本ソフト（ＯＳ）を格納する。Ｗｅｂサーバ１０３におけるプログラムＲＯＭ２０３には、クライアントＰＣ１０１から送信されたリクエストを受信してリクエストに応じた処理を行なうプログラムや、ＤＢ１０４又はＦＳ１０５に処理を指示するためのプログラムが格納される。ＤＢ１０４におけるプログラムＲＯＭ２０３には、Ｗｅｂサーバ１０３からの依頼に応じた処理を行なうためのデータベース管理プログラムが格納される。

データＲＯＭ２０４は、情報処理装置２００の機能を提供するために必要な情報等を格納する。情報処理装置２００の機能を提供するために必要な情報としては、例えばＤＢ１０４においては、クライアントＰＣ１０１から登録されるファイル実体や属性情報、またクライアントＰＣ１０１の認証情報等が考えられる。なお、データＲＯＭ２０４の代わりに後述する外部メモリ２１３を用いる場合もある。

ネットワークコントローラ（ＮＣ）２０５は、ネットワーク１１０に接続され、ネットワーク１１０上の他の機器との通信制御処理を実行する。

キーボードコントローラ２０６は、後述するキーボード２１１からのキー入力を制御する。

ディスプレイコントローラ２０７は、情報処理装置２００内の情報を後述のディスプレイ２１２の画面に表示するために画像データを展開し、その表示の制御を行なう。

ディスクコントローラ２０８は、外部メモリ２１３への読み書きを制御するコントローラであり、例えばＤＢ１０４においては、管理するファイル実体やその属性に関する情報（以下、属性情報）、クライアントＰＣ１０１の認証情報等の入出力を制御する。

キーボード２１１は、情報処理装置２００を操作するユーザが入力操作を行なう。例えば、本実施例においてサーバ群１０２のメンテナンス作業をする場合は、後述するディスプレイ２１２に表示される情報を見ながらキーボード２１１を操作することが考えられる。

ディスプレイ２１２は、例えばＬＣＤなどの表示装置である。

外部メモリ２１３は、アプリケーションプログラムや各種データ保存用に用いるＨＤＤなどの外部記憶装置である。本実施例におけるアプリケーションプログラムとは、例えばＷｅｂサーバ１０３における各処理部、またＤＢ１０４におけるデータベース管理プログラムのようなソフトウェアプログラムを表す。

（文書管理システムのソフトウェア構成）
図３は、本実施例に係る文書管理システムのソフトウェア構成を示す図である。

Ｗｅｂサーバ１０３における各処理部は、プログラムＲＯＭ２０３等より読み込まれてＲＡＭ２０２に展開されるＷｅｂアプリケーションプログラム、または該プログラムの一部として動作する。すなわち、Ｗｅｂアプリケーションプログラムは、Ｗｅｂサーバ１０３のＣＰＵ２０１を各処理部３０５〜３０７として機能させるためのものである。同様にＤＢ１０４、及びＦＳ１０５においても、ＣＰＵ２０１が各プログラムによって各管理部３０８〜３１０、及び３１１として機能する。

ただし、図３に示されているのは、本発明の説明に必要な機能のみであって、ここに記されている以外の一般的な文書管理機能を、クライアントＰＣ１０１やサーバ群１０２は備えているものとする。以下、各処理部について説明する。

クライアントＰＣ１０１には、リクエスト送信部３０１とレスポンス受信部３０２が存在する。

リクエスト送信部３０１は、ネットワーク１１０上のサーバ群１０２に処理のリクエストを送信する通信モジュールである。

レスポンス受信部３０２は、リクエスト送信部３０１によって依頼した処理に対するサーバ群１０２からのレスポンスを受信する通信モジュールである。

Ｗｅｂサーバ１０３には、リクエスト受信部３０３、レスポンス送信部３０４、ファイル実体処理部３０５、属性情報処理部３０６、認証情報処理部３０７が存在する。

リクエスト受信部３０３は、ネットワーク１１０上のクライアントＰＣ１０１から送信されたリクエストを受信する通信モジュールである。

レスポンス送信部３０４は、リクエスト受信部３０３によって受信したリクエストに対して処理を行なった結果をレスポンスとしてクライアントＰＣ１０１に送信する通信モジュールである。

ファイル実体処理部３０５は、後述するファイル実体管理テーブル、又はＦＳ１０５のファイルシステム上に記録されるファイル実体を、クライアントＰＣ１０１からの要求に従って処理するモジュールである。

属性情報処理部３０６は、後述する属性情報管理テーブル上に記録されるファイルの属性情報をクライアントＰＣ１０１からの指示に従って処理するモジュールである。

認証情報処理部３０７は、クライアントＰＣ１０１からリクエストを受けた時に、当該クライアントＰＣ１０１が文書管理システム１００に登録されたユーザであることを判定するための認証処理を行なうモジュールである。

ＤＢ１０４には、認証情報管理部３０８、属性情報管理部３０９、ファイル実体管理部３１０が存在する。

認証情報管理部３０８は、ユーザＩＤ、ユーザ名、メールアドレス、パスワードといったユーザ認証に必要な情報をユーザ情報管理テーブルによって管理するモジュールである。図４は、ユーザ情報管理テーブルの一例を示す図である。「ユーザＩＤ」は、ユーザ毎に発行される内部ＩＤであり、文書管理システム１００上で一意となるユーザ識別子である。「ユーザ名」は、ユーザを識別するために付けられる名前であり、主に画面表示時に使用される。「メールアドレス」は、文書管理システム１００からクライアントＰＣ１０１への通知の送信等で使用される。「パスワード」は、クライアントＰＣ１０１が文書管理システム１００にログインする際に必要となるパスワードであり、認証情報処理部３０７によって自動発行してもよいしクライアントＰＣ１０１で任意に設定してもよい。クライアントＰＣ１０１が文書管理システム１００のユーザが利用する端末として登録されていれば、上述のようなユーザ情報管理テーブルにおいて対応するユーザ情報が管理されていることになる。

属性情報管理部３０９は、文書ＩＤ、文書名、ファイル実体格納場所フラグ、ＦＳ上のファイル実体パスといったデータを、後述する属性情報管理テーブルによって管理するモジュールである。

ファイル実体管理部３１０は、文書ＩＤ、ファイル実体、最終アクセス日時といったデータを、後述するファイル実体管理テーブルによって管理するモジュールである。

また、ＦＳ１０５にもファイル実体管理部３１１が存在し、一般的にはＯＳが提供するファイルシステム上に直接構築される。

（ファイル実体及び属性情報の文書管理システム１００への登録処理）
次に、クライアントＰＣ１０１からの文書（文書ファイル）の登録要求に従って行なわれる、ファイル実体及び属性情報の文書管理システム１００への登録処理について説明する。

図５は、本実施例に係る、ファイル実体及び属性情報の登録処理の流れを示すフローチャートである。

ステップ５０１において、Ｗｅｂサーバ１０３のリクエスト受信部３０３は、クライアントＰＣ１０１のリクエスト送信部３０１によって送信された、登録要求に係る文書のファイル実体及び属性情報を受信する。

ステップ５０２において、属性情報処理部３０６は、受信した属性情報をＤＢ１０４に登録する。具体的には、属性情報管理部３０９に対し受信した属性情報の登録を指示し、指示を受けて属性情報管理部３０９は属性情報管理テーブルに属性情報を登録する。図６は、本実施例に係る、属性情報管理テーブルの一例を示す図である。テーブルの各行が１レコードであり、文書ＩＤ、文書名、ファイル実体格納場所フラグ、ＦＳ上のファイル実体パス、といった情報が含まれる。

「文書ＩＤ」は、Ｗｅｂサーバ１０３がクライアントＰＣ１０１からファイルを受信し属性情報管理テーブルに新規文書として登録される時に属性情報処理部３０６によって自動的に割り振られるＩＤであり、これにより文書管理システム上で一意に識別される。各文書ＩＤが単独で一意に識別可能でなくても、別のＩＤとの組み合わせ等により文書管理システム上で一意なＩＤとなっていれば構わない。

「文書名」は、クライアントＰＣ１０１から新規文書を登録する際（Ｗｅｂサーバ１０３にファイルを送信する際）に、ユーザが任意に設定することができる。

「ファイル実体格納場所フラグ」は、ファイル実体の格納場所を示すフラグであり、本実施例では、値「１」がＦＳ１０５のみに格納されていることを表し、値「２」がＤＢ１０４とＦＳ１０５の両方に格納されていることを表す。これにより、登録されているファイル実体が、ＦＳ１０５のファイル実体管理部３１１のみで格納・管理されているのか、ＦＳ１０５内のファイル実体管理部３１１に加え、ＤＢ１０４内のファイル実体管理部３１０でも格納・管理されているのかが把握される。

「ＦＳ上のファイル実体パス」は、ＦＳ１０５上のファイル実体管理部３１１でファイル実体が管理されている場合の、格納場所としてのフルパスを示す。本実施例に係る文書管理システム１００では、登録される文書のファイル実体は常にＦＳ１０５に格納されているので、この「ＦＳ上のファイル実体パス」には必ず格納先を表すパスの情報が入ることになる。ＦＳ１０５内のファイル実体管理部３１１のみでファイル実体を管理している場合においてファイル実体を取得するときは、この「ＦＳ上のファイル実体パス」が参照されて、パスの示す先に置かれるファイルが取得される。一方、ＤＢ１０４内のファイル実体管理部３１０でもファイル実体が管理されている場合においてファイル実体を取得するときは、上述の文書ＩＤをキーとして、後述するファイル実体管理テーブルの該当レコードを検索することでファイル実体が取得される。つまり、ＤＢ１０４にもファイル実体がある文書の場合、パスの情報は使われない。

このような属性情報管理テーブルによって、ＤＢ１０４に登録される文書の属性情報が管理される。

図５のフローチャートの説明に戻る。

ステップ５０３において、ファイル実体処理部３０５は、受信したファイル実体をＤＢ１０４に登録する。具体的には、ファイル実体管理部３１０に対し受信したファイル実体の登録を指示し、指示を受けてファイル実体管理部３１０は、ファイル実体管理テーブルにファイル実体を登録する。図７は、ファイル実体管理テーブルの一例を示す図である。テーブルの各行が１レコードであり、文書ＩＤ、ファイル実体、最終アクセス日時、といった情報が含まれる。

「文書ＩＤ」は、上述の属性情報管理テーブルにおける文書ＩＤと同じである。この文書ＩＤをキーに属性情報管理テーブルとファイル実体管理テーブルのデータが紐付けられる。

「ファイル実体」は、クライアントＰＣ１０１から受信した文書ファイルの実体データである。一般的なデータベース管理システム（ＤＢＭＳ）においてファイル実体をデータベースサーバに格納する場合は、ラージ・オブジェクト（ＬＯＢ）と呼ばれるバイナリやキャラクターを格納するデータ型が使用される。

「最終アクセス日時」は、ファイル実体管理テーブルで管理されるファイル実体に対してクライアントＰＣ１０１からのアクセス要求があった最後の日時の情報である。この「最終アクセス日時」で示される日時が現在から一定以上の期間が経過した場合（日時が古くなった場合）、常駐プロセスやバッチファイル等による定期的なファイル実体削除処理によって、該当レコードが削除される。

このようなファイル実体管理テーブルによって、ＤＢ１０４に登録される文書ファイルの実体が管理される。

図５のフローチャートの説明に戻る。

ステップ５０４において、ファイル実体処理部３０５は、ＤＢ１０４に登録したファイル実体をＦＳ１０５にも登録する。具体的には、ファイル実体管理部３１１に対し受信したファイル実体の複製の登録を指示し、指示を受けてファイル実体管理部３１１は、ＦＳ１０５内のファイルシステム上にファイル実体（複製）を格納する。この時点で一時的に、ＤＢ１０４とＦＳ１０５の両方にファイル実体が存在することになる。

ステップ５０５において、属性情報処理部３０６は、ステップ４０４でＦＳ１０５のファイルシステム上に格納されたファイル実体のパスをＤＢ１０５に登録する。具体的には、属性情報管理部３０９に対しファイル実体のパスの登録を指示し、指示を受けて属性情報管理部３０９は上述の属性情報テーブルにおける「ＦＳ上のファイル実体パス」に当該ファイル実体のパスを登録する。

ステップ５０６において、属性情報処理部３０６及びファイル実体処理部３０５は、ステップ５０２〜５０５までの処理によって、ＤＢ１０４とＦＳ１０５に登録（格納）すべきデータが正しく登録（格納）されたかどうかをそれぞれ判定する。いずれも正しく登録されていればステップ５０７に進む。一方、いずれかが正しく登録されていなければステップ５０９に進む。

ステップ５０７において、属性情報処理部３０６及びファイル実体処理部３０５は、登録確定処理を行なう。これにより、属性情報管理テーブル及びファイル実体管理テーブルの該当レコードにおける登録がそれぞれ確定される。

ステップ５０８において、レスポンス送信部３０４は、登録要求に係る文書のファイル実体とその属性情報が文書管理システム１００（ＤＢ１０４及びＦＳ１０５）に問題なく登録されたことを、クライアントＰＣ１０１に通知する。

ステップ５０９において、属性情報処理部３０６及びファイル実体処理部３０５は、それぞれ属性情報及びファイル実体の登録取り消し処理を行なう。具体的には、属性情報管理部３０９に対し属性情報の取り消しが、ファイル実体管理部３１０に対しファイル実体の登録取り消しがそれぞれ指示される。指示を受けて属性情報管理部３０９は属性情報管理テーブルの該当レコードから当該属性情報を削除し、ファイル実体管理部３１０はファイル実体管理テーブルの該当レコードから当該ファイル実体を削除する。

ステップ５１０において、ファイル実体処理部３０５は、ＦＳ１０５のファイルシステム上に格納されたファイル実体（ステップ５０９で登録取り消し処理がなされた属性情報に紐付くファイル実体（複製））を削除する。

ステップ５１１において、レスポンス送信部３０４は、登録要求に係る文書のファイル実体とその属性情報が文書管理システム１００（ＤＢ１０４及びＦＳ１０５）に正しく登録されなかったこと（登録の失敗）を、クライアントＰＣ１０１に通知する。

以上が、文書のファイル実体及び属性情報の登録処理（エラー処理を含む）の内容である。

（ファイル実体のクライアントＰＣへの送信処理）
次に、クライアントＰＣ１０１から文書管理システムへのファイル実体の取得要求に従って行なわれる、Ｗｅｂサーバ１０３からクライアントＰＣ１０１へのファイル実体の送信処理について説明する。

図８は、本実施例に係る、Ｗｅｂサーバ１０３からクライアントＰＣ１０１へファイル実体を送信する処理の流れを示すフローチャートである。

ステップ８０１において、Ｗｅｂサーバ１０３のリクエスト受信部３０３は、クライアントＰＣ１０１のリクエスト送信部３０１によって送信された、文書管理システム１００に登録されているファイル実体の取得要求を受信する。この取得要求には、文書ＩＤなど、当該取得要求に係る文書を特定するための情報が含まれる。

ステップ８０２において、ファイル実体処理部３０５は、受信した取得要求に従い、ＤＢ１０４のファイル実体管理部３１０に対し、当該取得要求に係る文書のファイル実体を要求する。

ステップ８０３において、属性情報処理部３０６は、当該取得要求に係る文書のファイル実体の格納場所を示す情報（以下、格納場所情報）を取得する。具体的には、ＤＢ１０４内の属性情報管理テーブルにアクセスし、上述の「ファイル実体格納場所フラグ」を参照して、当該取得要求に係る文書のファイル実体がどこで管理されているのかを示す上述のフラグ値（１or２）を取得する。

ステップ８０４において、属性情報処理部３０６は、取得した「ファイル実体格納フラグ」の値をチェックし、ファイル実体の格納先がＦＳ１０５のみであるのかＤＢ１０４にも格納されているのかを判定する。当該取得要求に係る文書のファイル実体の格納先がＦＳ１０５のみであればステップ８０５に進む。一方、ＤＢ１０４にもファイル実体が格納されていればステップ８１２に進む。前述のとおり、ＤＢ１０４にファイル実体が格納されているということは、一定期間内に対象文書のファイル実体へのアクセス要求があったことを示している。これに対し、ファイル実体の格納先がＦＳ１０５のみであれば、一定期間内に対象文書のファイル実体へのアクセス要求がなかったことを示している。

ステップ８０５において、属性情報処理部３０６は、当該取得要求に係る文書の、属性情報管理テーブルにおける該当レコードの「ＦＳ上のファイル実体パス」を取得する。

ステップ８０６において、ファイル実体処理部３０５は、ステップ８０５で取得した「ＦＳ上のファイル実体パス」を用いて、ＦＳ１０５に対してファイル実体の取得を要求する。

ステップ８０７において、ファイル実体処理部３０５は、当該取得要求に係るファイル実体をＦＳ１０５から受け取る。

ステップ８０８において、レスポンス送信部３０４は、ＦＳ１０５から取得したファイル実体をクライアントＰＣ１０１に送信する。送信されたファイル実体は、クライアントＰＣ１０１のレスポンス受信部３０２によって受信される。

ステップ８０９において、ファイル実体処理部３０５は、これまで一定期間アクセスがなかった為にＦＳ１０５にしか格納されていなかった、当該取得要求に係る文書のファイル実体をＤＢ１０４に再登録する。具体的には、ファイル実体管理部３１０に対し対象文書のファイル実体の再登録を指示し、指示を受けてファイル実体管理部３１０は、ファイル実体格納テーブルに当該文書のファイル実体を再び登録する。

ステップ８１０において、属性情報管理部３０９は、属性情報管理テーブルにおける該当するレコードの「ファイル実体格納場所フラグ」の値を更新（本実施例では「１」から「２」に変更）する。この更新処理により、以後はＤＢ１０４にもファイル実体が格納されている文書として、文書管理システム１００上扱われることになる。

ステップ８１１において、属性情報処理部３０６及びファイル実体処理部３０５は、再登録の確定処理を行なう。これにより、属性情報管理テーブル及びファイル実体管理テーブルの該当レコードにおける再登録がそれぞれ確定される。

ステップ８１２において、ファイル実体処理部３０５は、当該取得要求に係る文書のファイル実体をＤＢ１０４から取得する。

ステップ８１３において、レスポンス送信部３０４は、ＤＢ１０４から取得したファイル実体をクライアントＰＣ１０１に送信する。送信されたファイル実体は、クライアントＰＣ１０１のレスポンス受信部３０２によって受信される。

以上が、ファイル実体のクライアントＰＣへの送信処理（エラー処理を含む）の内容である。

（ファイル実体の削除処理）
次に、ＤＢ１０４に格納・管理されているファイル実体に対して一定期間アクセスがない場合に、当該ファイル実体をＤＢ１０４から削除する処理について説明する。図９は、本実施例に係る、ファイル実体をＤＢ１０４のファイル実体管理テーブルから削除する処理の流れを示すフローチャートである。この削除処理は、常駐プロセスやバッチファイル等による定期的なチェックによって実施されることを想定している。

まず、ステップ９０１において、ファイル実体処理部３０５は、ＤＢ１０４内のファイル実体管理テーブルから全レコードの文書ＩＤをリストアップし、ファイル実体管理テーブルにおいてファイル実体が格納されている文書の一覧を抽出する。

ステップ９０２において、ファイル実体処理部３０５は、リストアップされた全文書の最終アクセス日時をチェックし、一定期間ファイル実体に対するアクセスがなされていない文書の文書ＩＤをリストアップする。なお、一定期間は、例えば文書管理システム１００内で設定された固定の期間としてもよいし、利用契約単位で設定できるようにしてもよい。

ステップ９０３において、ファイル実体処理部３０５は、一定期間アクセスがないとして抽出された文書のファイル実体を、ファイル実体管理テーブルから削除する。具体的には、ファイル実体管理部３１０に対し該当する文書のファイル実体の削除を指示し、指示を受けてファイル実体管理部３１０は、ファイル実体管理テーブルの該当するレコードからファイル実体を削除する。

ステップ９０４において、属性情報処理部３０６は、ファイル実体が削除された文書について、属性情報管理テーブルの該当するレコードにおける「ファイル実体格納場所フラグ」の値を更新する。すなわち、本実施例では「２」から「１」にフラグ値が変更される。この処理によって、以降にこの文書のファイル実体にアクセスがされた時は、ファイル実体がＦＳ１０５でのみ管理されていることがわかる。

ステップ９０５において、ファイル実体処理部３０５及び属性情報処理部３０６は、ファイル実体管理テーブル及び属性情報管理テーブルの更新確定処理を行なう。

ステップ９０６において、ファイル実体処理部３０５は、ステップ９０２で一定期間アクセスなしの文書としてリストアップされた文書ＩＤについて、ファイル実体の削除処理がすべて完了したかどうかを判定する。未処理の文書ＩＤがあればステップ９０３に戻り、削除処理を続行する。一方、すべてのリストアップされた文書ＩＤについてファイル実体の削除処理が完了していれば、本処理を終える。

以上がファイル実体の削除処理の内容である。この処理によって、ファイル実体に対して一定期間アクセスがない文書のファイル実体が定期的にＤＢ１０４から削除される。

本実施例によれば、文書管理システムにおいて、データベースの使用量を削減でき、低コストかつ効果的にファイル実体を管理することが可能となる。

実施例１では、ファイル実体に対し一定期間アクセスがない文書については、データベースサーバ内のファイル実体管理テーブルから該当するファイル実体が自動で削除されるようにしていた。しかしながら、ファイル実体へのアクセス数はその文書にアクセス可能なユーザ数に比例する可能性が高く、そしてアクセス可能なユーザ数は文書毎に異なることも少なくない。そこで、文書にアクセス可能なユーザ数に応じて、ファイル実体管理テーブルに登録しておく期間を文書毎に変更可能にする態様について、実施例２として説明する。なお、実施例１と共通する点については省略ないしは簡略化し、以下では差異点を中心に説明するものとする。

図１０は、本実施例に係る、属性情報管理テーブルの一例を示す図である。図６のテーブルにおける項目（文書ＩＤ、文書名、ファイル実体格納場所フラグ、ＦＳ上のファイル実体パス）に加え、「アクセス可能ユーザ数」の項目が追加されている。この「アクセス可能ユーザ数」は、該当レコードにおける文書のファイル実体へのアクセスが可能なユーザの数を表している。

なお、ファイル実体へのアクセスレベルを別テーブルで管理するなど、アクセス可能なユーザ数を複数のテーブルで分けて管理するようにしてもよい。

図１１は、本実施例に係る、ファイル実体管理テーブルにファイル実体を格納しておく期間をアクセス可能なユーザ数に応じて設定・管理するためのテーブル（以下、ＤＢ格納期間管理テーブル）の一例を示す図である。

「アクセス可能ユーザ数」は、上述の属性情報管理テーブルにおけるアクセス可能ユーザ数と同じである。

「ＤＢ格納期間」は、ファイル実体管理テーブルにおいてファイル実体を、アクセスのない状態でどのくらいの期間格納しておくのかを示す情報であり、アクセス可能ユーザ数に対応付けて規定されている。図１１に示す例では、ファイル実体へのアクセス可能ユーザ数が０〜１０人の場合は３日間、１１〜２０人の場合は５日間、２１〜３０人の場合は１０日間といった具合に、アクセスのないファイル実体をＤＢ１０４で管理されることになる。

上述した図１０に示す属性情報管理テーブルと図１１に示すＤＢ格納期間管理テーブルを用いて前述したファイル実体の削除処理（図９を参照）を行なうことにより、文書毎にＤＢからファイル実体を削除するまでの期間を柔軟に変えることが可能となる。

本実施例によれば、ファイル実体管理がより柔軟に行なえるようになり、効率的な文書の管理が可能となる。

（その他の実施例）
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (9)

1. 文書のファイル実体とその属性情報とを管理する第１のサーバと、文書のファイル実体は管理するがその属性情報は管理しない第２のサーバと、通信可能な情報処理装置であって、
   受信した文書のファイル実体の管理を前記第１のサーバ及び前記第２のサーバに指示するファイル実体処理手段と、
   受信した文書の属性情報の管理を前記第１のサーバに指示する属性情報処理手段と、
   を備え、
   前記ファイル実体処理手段は、前記第１のサーバに格納されているファイル実体に対するアクセスが一定期間ない場合に、当該ファイル実体の削除を前記第１のサーバに対し指示する、
   ことを特徴とする情報処理装置。
2. 前記属性情報には、前記第１のサーバと前記第２のサーバの両方にファイル実体が格納されているのか、前記第２のサーバのみにファイル実体が格納されているのかを示す格納場所情報が含まれ、
   前記属性情報処理手段は、前記ファイル実体処理手段からの指示に従って前記第１のサーバからファイル実体が削除されると、前記格納場所情報の更新を前記第１のサーバに指示する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記ファイル実体処理手段は、ファイル実体へのアクセス要求を受信した時に、
   要求に係るファイル実体が前記第１のサーバに格納されていれば前記第１のサーバから当該要求に係るファイル実体を取得してレスポンスし、
   要求に係るファイル実体が前記第１のサーバに格納されていなければ前記第２のサーバから当該要求に係るファイル実体を取得してレスポンスする、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記ファイル実体処理手段は、ファイル実体へのアクセス要求を受信した時に、要求に係るファイル実体が前記第１のサーバに格納されていなかった場合、前記第２のサーバから当該要求に係るファイル実体を取得して、前記第１のサーバに対し当該ファイル実体の再登録を指示する、
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記属性情報処理手段は、前記ファイル実体処理手段からの指示に従って前記第１のサーバにファイル実体が再登録されると、前記格納場所情報の更新を前記第１のサーバに指示することを特徴とする請求項４に記載の情報処理装置。
6. ファイル実体へのアクセスが可能なユーザの数を管理する手段をさらに備え、
   前記ファイル実体処理手段は、ファイル実体に対するアクセス可能ユーザ数に応じて前記第１のサーバにおいてファイル実体を格納する期間をファイル実体毎に設定する、
   ことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 請求項１乃至６のいずれか１項に記載の情報処理装置、前記第１のサーバ、及び前記第２のサーバを少なくとも含む文書管理システム。
8. 文書のファイル実体とその属性情報とを管理する第１のサーバと、ファイル実体は管理するが属性情報は管理しない第２のサーバと、通信可能な情報処理装置が実行する方法であって、
   受信した文書のファイル実体の管理を前記第１のサーバ及び前記第２のサーバに指示するファイル実体処理ステップと、
   受信した文書の属性情報の管理を前記第１のサーバに指示する属性情報処理ステップと、
   を含み、
   前記ファイル実体処理ステップには、前記第１のサーバに格納されているファイル実体に対するアクセスが一定期間ない場合に、当該ファイル実体の削除を前記第１のサーバに対し指示するステップを含む、
   ことを特徴とする方法。
9. コンピュータを、請求項１乃至６のいずれか１項に記載の情報処理装置として機能させるためのプログラム。

Images