JP4405493B2 - 構造化文書管理システム及びプログラム - Google Patents

Description

本発明は、構造化文書に加えて当該構造化文書に付随するバイナリデータを管理する構造化文書管理システム及びプログラムに関する。

タグと呼ばれる文字列で文書の階層的な構造が記述された文書は構造化文書と呼ばれている。構造化文書はコンピュータでの処理に適している。構造化文書の代表として、ＸＭＬ（Extensible Markup Language）を使って記述された文書（ＸＭＬ文書）が良く知られている。ＸＭＬ文書を格納し、格納されたＸＭＬ文書の検索が可能なデータベースは、ＸＭＬデータベース（ＸＭＬＤＢ）と呼ばれる。

ＸＭＬデータベースで、イメージデータのようなバイナリデータを管理する手法として、従来から以下の３つの手法が知られている。

＜手法１＞
ＯＳ（オペレーティングシステム）のローカルファイルとしてバイナリデータを保存し、ＸＭＬ文書に当該バイナリデータ（ローカルファイル）のファイル名などの情報を保存して管理する。

＜手法２＞
バイナリデータを文字列化してＸＭＬのテキスト情報として保存する（例えば、特許文献１参照）。

＜手法３＞
ＲＤＢ（リレーショナルデータベース）で、バイナリデータを管理する。ここでは、バイナリデータは、ＢＬＯＢ（Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ）と呼ばれるバイナリデータ格納用の列（カラム）に保存可能である。
特開２００３−３１６７６７号公報

上記手法１では、トランザクション管理ができない、または複雑になる。その理由は次の通りである。手法１では、ＸＭＬ文書だけをＸＭＬデータベースに登録し、バイナリデータはＯＳ上のローカルファイルとして管理される。このため、バイナリファイルも含めたトランザクションを実現しようとすると、上位アプリケーションが複雑になる。例えば、ＸＭＬデータベースにＸＭＬ文書を格納するに当たり、関連するバイナリファイルを同一のトランザクションで管理するようなケースで、リカバリ処理などが複雑になる。

手法２では、バイナリデータが文字列として表現される。このため、テキスト情報が極端に増加する。つまり手法２では、管理する情報が増えてしまい、ＸＭＬ文書の取り出し自体の性能劣化を招く。また、文字列化した情報をバイナリデータに戻す処理が必要になる。

手法３では、事前にＢＬＯＢ型の列を用意しておく必要がある。また、この手法は同一行の同一カラムに複数のバイナリデータを登録することができない。

本発明は上記事情を考慮してなされたものでその目的は、構造化文書に付随するバイナリデータを当該構造化文書の変更を必要とせずに管理でき、バイナリデータの登録／取得が高速で行える構造化文書管理システム及びプログラムを提供することにある。

本発明の１つの観点によれば、構造化文書の集合を格納する構造化文書データベースを備えた構造化文書管理システムが提供される。このシステムは、クライアント端末からのバイナリデータ登録要求に従い、当該クライアント端末から要求された構造化文書に付随されるべきバイナリデータをそのままの形で前記構造化文書データベースに格納するバイナリデータ格納手段と、前記構造化文書データベースに格納されている構造化文書に付随する全てのバイナリデータを、当該構造化文書に対応させて前記構造化文書データベースに格納される管理情報によって、当該構造化文書と関連付けて管理する関連付け手段と、クライアント端末からのバイナリデータ取得要求に従い、当該クライアント端末から要求された構造化文書に対応させて前記構造化文書データベースに格納されている前記管理情報に基づいて、当該管理情報によって当該構造化文書と関連付けられている全てのバイナリデータを特定し、当該特定されたバイナリデータを前記構造化文書データベースから取得するバイナリデータ取得手段とを具備する。

本発明によれば、構造化文書に付随させるべきバイナリデータを、当該構造化文書に何ら変更を加えることなしに、当該構造化文書とは別の情報（管理情報）を用いて当該構造化文書と関連付けて管理することにより、構造化文書データベースへのバイナリデータ（特に複数のバイナリデータ）の登録及び当該構造化文書データベースからのバイナリデータ（特に複数のバイナリデータ）の取得が高速で行える。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係るＸＭＬ文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図である。図１のクライアント−サーバシステムは、ＸＭＬ文書管理システム１０と、クライアント端末２０を含む複数のクライアント端末（クライアント）とから構成される。各クライアント端末上では、ＸＭＬ文書管理システム１０を利用するアプリケーション（アプリケーションプログラム）が動作する。クライアント端末２０を含む複数のクライアント端末は、ローカルエリアネットワーク（ＬＡＮ）のようなネットワーク３０を介して、ＸＭＬ文書管理システム１０と接続されている。なお、図１では、クライアント端末２０以外のクライアント端末は省略されている。

ＸＭＬ文書管理システム１０は、構造化文書としてのＸＭＬ文書を管理するＸＭＬ文書管理サーバ（サーバコンピュータ）１１と、当該サーバ１１が有する外部記憶装置、例えば磁気ディスク装置（以下、ＨＤＤと称する）１２とから構成される。ＨＤＤ１２は、ＸＭＬ文書管理プログラム１２１及びＸＭＬ文書データベース１２２を格納する。

ＸＭＬ文書管理プログラム１２１は、ＸＭＬ文書及び当該ＸＭＬ文書に付随するバイナリデータをＸＭＬ文書データベース１２２に格納して管理する処理をＸＭＬ文書管理サーバ１１に実行させるのに用いられる。ＸＭＬ文書データベース１２２は、ＸＭＬ文書の集合及び当該ＸＭＬ文書に付随するバイナリデータを保存する。ＸＭＬ文書データベース１２２は更に、当該データベース１２２に格納されるＸＭＬ文書に基づいて作成される索引データも保存する。この索引データは、ＸＭＬ文書を検索するのに用いられる。

次に、ＸＭＬ文書管理システム１０で適用される、ＸＭＬ文書及び当該ＸＭＬ文書に付随するバイナリデータの管理の原理について順次説明する。

（１）ＸＭＬ文書管理
まず、ＸＭＬ文書管理の原理について図２を参照して説明する。ＸＭＬ文書管理システム１０では、ＸＭＬ文書は、従来から良く知られているように図２に示されるツリー構造で管理される。この管理は、ディレクトリを用いた、ＯＳのファイルシステムにおけるファイル管理に相当する。図２では、“ｉｄ”がそれぞれ“１”及び“２”のＸＭＬ文書２０１及び２０２が、“公開特許＿２００５”で示されるノードの下位に登録されている。同様に、“ｉｄ”が“１０”のＸＭＬ文書２１０が、“公開特許＿２００６”で示されるノードの下位に登録されている。ＸＭＬ文書２０１，２０２及び２１０は、例えばＸＭＬで記述された特許文書である。

ＸＭＬ文書２０１及び２０２は、“／”で示されるルート→“公開特許＿２００５”のパスを辿ることにより取得（検索）可能である。ＸＭＬ文書２１０は、“／”で示されるルート→“公開特許＿２００６”のパスを辿ることにより取得（検索）可能である。このような検索条件としてのパスは、ＸＱｕｅｒｙに代表されるクエリを用いて指定可能である。クエリ（ＸＱｕｅｒｙ）では、ＸＭＬ文書内のタグで表される構造も指定可能であり、これによりＸＭＬ文書に含まれているタグ情報やテキスト情報を取り出すことも可能である。

（２）バイナリデータ管理
次に、バイナリデータ管理の原理について図３を参照して説明する。本実施形態では、テキストとしてのＸＭＬ文書（ＸＭＬデータ）に付随するバイナリデータは、ＸＭＬ文書とは別のデータとして管理されて、ＸＭＬ文書と同様にＸＭＬ文書データベース１２２に格納される。図３の例では、バイナリデータ２１１がＸＭＬ文書２０１に付随し、バイナリデータ２２０Ａ〜２２０ＣがＸＭＬ文書２１０に付随している状態が示されている。ここでは、バイナリデータ２１１は特許文書としてのＸＭＬ文書２０１に付随する特許図面のイメージデータであり、バイナリデータ２２０Ａ〜２２０Ｃは特許文書としてのＸＭＬ文書２１０に付随する特許図面のイメージデータである。

本実施形態では、バイナリデータがＸＭＬ文書に付随していることを管理するために、ＸＭＬ文書とは別の情報（後述するファイルレコード）が用いられる。この情報を用いた関連付けにより、バイナリデータ及びＸＭＬ文書を何ら加工することなく、バイナリデータがＸＭＬ文書に付随していることを管理できる。ここで、ＸＭＬ文書とバイナリデータの例としては、上述のＸＭＬ形式の特許文書と特許図面のイメージデータの他に、ＸＨＴＭＬファイル（ＸＭＬ形式でＨＴＭＬ（HyperText Markup Language）を表現したファイル）とイメージデータ、バイナリデータのプロパティ情報を表したＸＭＬ文書と当該バイナリデータなどが挙げられる。

図４は図１に示されるＸＭＬ文書管理システム１０の主として機能構成を示すブロック図である。ＸＭＬ文書管理システム１０は、ＸＭＬ文書データベース１２２に加えて、ＸＭＬ文書特定部４０１、管理情報生成部４０２、保存用ページ確保部４０３、バイナリデータ格納部４０４、関連付け部４０５、管理情報読み込み部４０６及びバイナリデータ取得部４０７の各処理部を含む。これらの処理部４０１〜４０７の機能については後述する。

処理部４０１〜４０７は、図１のＸＭＬ文書管理サーバ１１がＨＤＤ１２に格納されているＸＭＬ文書管理プログラム１２１を読み込んで実行することにより実現されるものとする。このプログラム１２１は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム１２１が、ネットワーク３０を介してＸＭＬ文書管理サーバ１１にダウンロードされても構わない。

ＸＭＬ文書データベース１２２には、ＸＭＬ文書（ＸＭＬデータ）及びバイナリデータを格納するのに用いられるデータ領域としてのエクステント領域４１０が確保されている。エクステント領域４１０は、図１に示すＨＤＤ１２が有する物理ディスクによって提供されるもので、エクステント４１１〜４１３を含む複数のエクステントから構成される。ＸＭＬ文書データベース１２２にはまた、エクステント領域４１０に格納されているＸＭＬ文書（ＸＭＬデータ）及びバイナリデータを内部的にファイルとして管理するファイルテーブル４２０が格納される。

このように本実施形態では、ＸＭＬ文書（ＸＭＬデータファイル）及びバイナリデータ（バイナリファイル）を、ファイルテーブル４１０とエクステントとで管理する。このような管理手法は、ＯＳのファイルシステムで採用されている。つまり本実施形態では、ＯＳのファイルシステムとは別に、ＸＭＬ文書（ＸＭＬデータファイル）及びバイナリデータを管理するための独自のファイルシステムを採用している。

ここで、本実施形態で使用される用語について説明する。
（ａ）エクステント
エクステントとは、指定されたサイズで確保された物理的に連続するページ領域を指す。

（ｂ）ファイル
ファイルとは、データベース（ＸＭＬ文書データベース１２２）に格納される「論理的な」まとまり（つまり論理的に１つの意味を持つデータ集合）ごとに割り当てた管理単位である。ファイルは物理的には、１つ、もしくは複数のエクステントから構成される。ファイルは、初期エクステントサイズで作成され、データの追加に応じて、エクステント単位で拡張される。

（ｃ）ファイルテーブル
ファイルテーブル（ファイルテーブル４２０）は、エクステント領域（エクステント領域４１０）に格納されているファイルを管理するためのテーブルである。ファイルテーブルは、ファイルを管理するためのファイルレコードと呼ばれるレコードをファイル数分格納する。ファイルレコードのデータフォーマットについては後述する。

ファイルテーブルも１つのファイルである。このためファイルテーブルは、１つ、もしくは複数のエクステントから構成される。例えば、図４に示すファイルテーブル４２０は、エクステント４２１及び４３１を含む複数のエクステントから構成される。エクステント４２１には、ファイルレコード４２２及び４２３が格納されている。エクステント４３１には、ファイルレコード４３２を含む複数のファイルレコードが格納されている。ファイルレコード４３２は、例えば後述するＸＭＬデータファイル＃１を管理する。

「ファイル」についての説明の欄でも述べたように、本実施形態では、ファイル内のページを物理ディスクに確保する（割り当てる）方式として、エクステント方式が適用される。この方式では、ファイルは、複数の物理的に連続な領域、つまりエクステントによって構成される。ファイルに対するデータ追加に伴って当該ファイルのための領域が不足する場合には、エクステント単位で新たな連続領域が確保される。

図５は、ファイルレコード（例えばＸＭＬデータファイル＃１のファイルレコード）のデータフォーマットを示す。ファイルレコードは、当該ファイルレコードによって管理されるファイルのＩＤ（ファイルＩＤ）、ファイル名、当該ファイルを構成するエクステントの数（エクステント数）及びバイナリデータ（バイナリファイル）のＩＤ（バイナリファイルＩＤ）を含むヘッダ情報と、ファイルを構成するエクステントに関する情報（エクステント情報）とを保持する。エクステント情報は、ファイルを構成するエクステント数分存在する。ファイルレコードに保持されるヘッダ情報及びエクステント情報から構成される情報を管理情報（ファイル管理情報）と呼ぶ。

ＸＭＬデータファイルを管理するファイルレコード（ＸＭＬデータファイルのファイルレコード）の場合、バイナリファイルＩＤには、当該ＸＭＬデータファイルに最初に付随させられたバイナリファイルのバイナリファイルＩＤが用いられる。また、バイナリファイルを管理するファイルレコード（バイナリファイのファイルレコード）の場合、バイナリファイルＩＤには、当該ファイルの次にＸＭＬデータファイルに付随させられたバイナリファイルのバイナリファイルＩＤが用いられる。

図６は、図５のファイルレコードで管理されるＸＭＬデータファイル＃１の論理イメージと物理ディスク（エクステント領域４１０）上の位置との関係の一例を示す。ここでは、ＸＭＬデータファイル＃１は、エクステント＃１、エクステント＃２及びエクステント＃３の３つのエクステントから構成される。物理ディスク上では、エクステント＃１、エクステント＃２及びエクステント＃３は必ずしも連続していない。但し、エクステント＃１、エクステント＃２及びエクステント＃３内では、そのエクステントを構成する複数のページ（物理ページ）は連続している。

図７は、図６に示されるＸＭＬデータファイル＃１のエクステント＃１、エクステント＃２及びエクステント＃３に関するエクステント情報の一例を示す。図７の例では、エクステント＃１、エクステント＃２及びエクステント＃３は、それぞれ連続する５ページ、１０ページ及び１１ページから構成される。エクステント＃３のみが、空きページ（１ページ分の空きページ）を有する。

次に本実施形態の動作について、（１）バイナリデータの登録処理、（２）バイナリデータの取り出し処理を例に、順に説明する。

（１）バイナリデータの登録処理
まず、バイナリデータの登録処理について、図８のフローチャート及び図９のＸＭＬ文書データベース１２２の状態を示す図を参照して説明する。

今、クライアント端末２０のユーザが、ある検索条件に合致するＸＭＬ文書（のファイルＩＤ）を取得して、当該（ファイルＩＤで指定される）ＸＭＬ文書（ＸＭＬデータファイル）にバイナリデータを付随（追加）させたいものとする。この場合、ユーザはクライアント端末２０を操作して、ＸＭＬ文書管理システム１０に対するＸＭＬデータ検索を要求するクエリ（例えばＸＱｕｅｒｙ）を当該クライアント端末２０からネットワーク３０経由で送出させる。

ＸＭＬ文書管理システム１０のＸＭＬ文書特定部４０１は、クライアント端末２０からのクエリを受け取ると当該クエリを解析し、例えば索引を用いた周知の検索手法により、当該クエリで指定された検索条件（パス）に合致するＸＭＬ文書のファイルＩＤを特定（取得）する（ステップＳ１）。ここでは、バイナリデータの追加対象となるＸＭＬデータファイル＃１のファイルＩＤが特定されたものとする。このファイルＩＤは、図９（ａ）に示されるファイルレコード４３２のヘッダ情報に含まれている。

ＸＭＬデータファイル（ＸＭＬ文書）＃１のファイルＩＤが特定されると、ユーザはクライアント端末２０を操作して、特定されたファイルＩＤで指定されるＸＭＬデータファイル＃１にバイナリデータを付随させることを指示するバイナリデータ登録要求を、当該クライアント端末２０からＸＭＬ文書管理システム１０に送出させる。

ＸＭＬ文書管理システム１０の管理情報生成部４０２は、クライアント端末２０からのバイナリデータ登録要求に従い、要求されたバイナリデータの保存用ファイル（バイナリデータファイル）の管理情報を生成する（ステップＳ２）。このステップＳ２において管理情報生成部４０２は、ファイルテーブル４２０を構成するエクステント内の空きページを探す。管理情報生成部４０２は、生成された管理情報を保持するファイルレコードを、この空きページに登録する。ここでは、図９（ａ）に示されるように、エクステント４２１内の空きページに、要求されたバイナリデータの保存用ファイル（バイナリファイル）の管理情報を保持するファイルレコード４２４が登録されるものとする。この時点では、ファイルレコード４２４のヘッダ情報を構成するファイルＩＤ（ここではバイナリファイルＩＤ）、ファイル名、エクステント数及びバイナリファイルＩＤのうち、エクステント数及びバイナリファイルＩＤは生成されていない。また、ファイルレコード４２４のエクステント情報も生成されていない。

管理情報生成部４０２による管理情報生成が行われると、ＸＭＬ文書管理システム１０の保存用ページ確保部４０３は、クライアント端末２０から要求されたバイナリデータ（の実データ）の保存用ページ（エクステント）を、エクステント領域４１０から確保する（ステップＳ３）。ここでは、図９（ｂ）に示されるように、エクステント４１１〜４１３が保存用ページ４３０として確保されたものとする。

するとＸＭＬ文書管理システム１０のバイナリデータ格納部４０４は、クライアント端末２０から要求されたバイナリデータ（ファイルレコード４２４によって管理されるバイナリファイルの実データ）を、ステップＳ３で確保された保存用ページ４３０に図９（ｃ）において矢印９０で示すように格納する（ステップＳ４）。このとき管理情報生成部４０２は、保存用ページ４３０を構成するエクステント４１１〜４１３へのバイナリデータの格納状況に基づき、ファイルレコード４２４のヘッダ情報中にエクステント数を設定すると共に、ファイルレコード４２４中にエクステント４１１〜４１３に関するエクステント情報を設定する。

保存用ページ４３０にバイナリデータが格納されると（ステップＳ４）、ＸＭＬ文書管理システム１０の関連付け部４０５は、ファイルレコード４２４のヘッダ情報中のファイルＩＤ、つまりファイルレコード４２４によって管理されるバイナリデータ（バイナリファイル）のファイルＩＤを、ステップＳ１で特定されたＸＭＬデータファイル＃１のファイルＩＤに関連付ける（ステップＳ５）。この関連付けは次のように行われる。

まず、上記特定されたファイルＩＤを含むファイルレコード４３２（ＸＭＬデータファイル＃１のファイルレコード４３２）のヘッダ情報中に、バイナリファイルＩＤが設定されていないものとする。この場合、関連付け部４０５は、ファイルレコード４２４によって管理されるバイナリファイルのデータ、つまりステップＳ４で保存用ページ４３０に格納されたバイナリデータが、ＸＭＬデータファイル＃１に最初に付随させられるデータであると判定する。

すると関連付け部４０５は、ＸＭＬデータファイル＃１のファイルＩＤが設定されているファイルレコード４３２のヘッダ情報中に、ファイルレコード４２４によって管理されるバイナリファイルのファイルＩＤをバイナリファイルＩＤとして設定する。これにより、ファイルレコード４２４によって管理されるバイナリファイルのファイルＩＤが、ＸＭＬデータファイル＃１のファイルＩＤに直接関連付けられる。

これに対し、ＸＭＬデータファイル＃１のファイルレコード４３２のヘッダ情報中にバイナリファイルＩＤが既に設定されているものとする。この場合、関連付け部４０５は、ファイルレコード４２４によって管理されるバイナリファイルのデータが、ファイルレコード４３２のヘッダ情報中のバイナリファイルＩＤによって指定されるバイナリファイルのデータよりも後にＸＭＬデータファイル＃１に付随させられるデータであると判定する。

すると関連付け部４０５は、ファイルテーブル４２０を参照することにより、ファイルレコード４３２のヘッダ情報中のバイナリファイルＩＤから、当該バイナリファイルＩＤをファイルＩＤとして持つファイルレコードを辿る。このように関連付け部４０５は、ＸＭＬデータファイル＃１のファイルレコード４３２から始まり、ファイルレコードのヘッダ情報中のバイナリファイルＩＤから、当該バイナリファイルＩＤをファイルＩＤとして持つ別のファイルレコードを辿る動作を、バイナリファイルＩＤがヘッダ情報中に設定されていないファイルレコードに到達するまで繰り返す。バイナリファイルＩＤがヘッダ情報中に設定されていないファイルレコードは、起点となったファイルレコード４３２によって管理されるＸＭＬデータファイル（つまりＸＭＬデータファイル＃１）に前回付随されたバイナリファイルを管理する。

関連付け部４０５は、バイナリファイルＩＤがヘッダ情報中に設定されていないファイルレコードに到達した時点で、そのファイルレコードのヘッダ情報中に、ファイルレコード４２４によって管理されるバイナリファイル（つまりＸＭＬデータファイル＃１に新たに付随されるバイナリファイル）のファイルＩＤをバイナリファイルＩＤとして設定する。

これにより、ファイルレコード４２４によって管理されるバイナリファイル（今回ＸＭＬデータファイル＃１に付随されたバイナリファイル）のファイルＩＤが、ＸＭＬデータファイル＃１のファイルＩＤを起点とするチェーン（ファイルＩＤのチェーン）により関連付けられる。ここで、上記チェーンにより関連付けられるバイナリファイルのファイルＩＤの順序は、当該バイナリファイルの登録順に一致する。

このように本実施形態においては、ＸＭＬデータファイル＃１に付随する全てのバイナリファイルのファイルＩＤが、これらのファイルのファイルレコードを用いて作成されるファイルＩＤのチェーン（つまり、ＸＭＬデータファイル＃１のファイルＩＤを起点とする当該ＸＭＬデータファイル＃１に付随する全てのバイナリファイルのファイルＩＤのチェーン）により、当該バイナリファイルの登録順に管理される。この管理のために、ＸＭＬデータファイル＃１を何ら変更する必要がなく、したがって当該ＸＭＬデータファイル＃１に付随する複数のバイナリファイルのデータ（バイナリデータ）のＸＭＬ文書データベース１２２への高速登録が可能となる。また、上述のファイルＩＤ管理の適用により、ＸＭＬデータファイル＃１のファイルＩＤが特定されるならば、この特定されたファイルＩＤを起点とするチェーンを辿るだけで、当該ＸＭＬデータファイル＃１に付随する全てのバイナリファイルのファイルＩＤを高速で取得することが可能となる。

なお、ＸＭＬデータファイル＃１に付随するバイナリファイルのファイルＩＤを当該ＸＭＬデータファイル＃１のファイルＩＤに関連付ける手法は、上述のチェーンを用いた手法に限らない。例えば、ＸＭＬデータファイル＃１に付随するバイナリファイル（バイナリデータ）のファイルＩＤを管理するための（管理情報を保持する）バイナリ管理ファイルを用いることにより、上述の関連付けを次のように実現することも可能である。

バイナリ管理ファイルは、例えばＸＭＬデータファイル＃１に最初に付随されるバイナリファイルの登録時にＸＭＬ文書データベース１２２（の例えばエクステント領域４１０）内に作成される。このとき、バイナリ管理ファイルのファイルＩＤが、ＸＭＬデータファイル＃１を管理するファイルレコード４３２のヘッダ情報中に、上述のバイナリファイルＩＤに代えて設定される。これにより、バイナリ管理ファイルは、ＸＭＬデータファイル＃１に対応させてＸＭＬ文書データベース１２２に格納されることになる。

バイナリ管理ファイルには、ＸＭＬデータファイル＃１に新たにバイナリファイルが付随される都度、そのバイナリファイルのファイルＩＤが格納される。つまりバイナリ管理ファイルは、ＸＭＬデータファイル＃１に付随する（関連付けられる）全てのバイナリファイルのファイルＩＤ一覧（管理情報）を保存するのに用いられる。これにより、ＸＭＬデータファイル＃１のファイルレコード４３２に設定されているバイナリ管理ファイルのファイルＩＤに基づき、当該バイナリ管理ファイルを参照するだけで、当該ＸＭＬデータファイル＃１に付随する全てのバイナリファイルのファイルＩＤを取得することが可能となる。

（２）バイナリデータの取り出し処理
次に、バイナリデータの取り出し処理について、図１０フローチャートを参照して説明する。

今、クライアント端末２０のユーザが、ある検索条件に合致するＸＭＬ文書（のファイルＩＤ）を取得して、当該（ファイルＩＤで指定される）ＸＭＬ文書（ＸＭＬデータファイル）に付随しているバイナリデータを取得したいものとする。この場合、ユーザはクライアント端末２０を操作して、ＸＭＬ文書管理システム１０に対するＸＭＬデータ検索を指示するクエリ（例えばＸＱｕｅｒｙ）を当該クライアント端末２０からネットワーク３０経由で送出させる。

ＸＭＬ文書管理システム１０のＸＭＬ文書特定部４０１は、クライアント端末２０からのクエリを受け取ると、前記ステップＳ１と同様に、当該クエリの示す検索条件に合致するＸＭＬ文書（取得対象となるＸＭＬ文書）のファイルＩＤを特定（取得）する（ステップＳ１１）。ここでは、ＸＭＬデータファイル＃１のファイルＩＤが特定されたものとする。

ＸＭＬデータファイル＃１のファイルＩＤが特定されると、ユーザはクライアント端末２０を操作して、特定されたファイルＩＤで指定されるＸＭＬデータファイル＃１に付随するバイナリデータを取得することを指示するバイナリデータ取得要求を、当該クライアント端末２０からＸＭＬ文書管理システム１０に送出させる。

ＸＭＬ文書管理システム１０の管理情報読み込み部４０６は、クライアント端末２０からのバイナリデータ取得要求に従い、要求されたファイルＩＤ（つまり、ステップＳ１１で特定されたファイルＩＤ）と関連付けられている、全てのバイナリデータ（バイナリファイル）のファイルＩＤを、次のようにして取得する（ステップＳ１２）。まず管理情報読み込み部４０６は、上記特定されたファイルＩＤが設定されているファイルレコード（に保持されている管理情報）をファイルテーブル４２０から読み込む。ここでは、ＸＭＬデータファイル＃１のファイルレコード４３２が読み出される。管理情報読み込み部４０６は、このファイルレコード４３２のヘッダ情報中のバイナリファイルＩＤから、当該バイナリファイルＩＤのバイナリファイルを管理するファイルレコードを辿るというように、バイナリファイルを管理するファイルレコードを辿る動作を繰り返すことにより、バイナリファイルＩＤのチェーンを辿る。これにより管理情報読み込み部４０６は、上記特定されたファイルＩＤと関連付けられている、全てのバイナリファイルのファイルＩＤを当該バイナリファイルの登録順に取得する。

ＸＭＬ文書管理システム１０のバイナリデータ取得部４０７は、管理情報読み込み部４０６によって取得されたファイルＩＤで特定されるバイナリファイルの実データを次のようにしてエクステント領域４１０から取得する（ステップＳ１３）。まずバイナリデータ取得部４０７は、取得されたファイルＩＤのバイナリファイルを管理するファイルレコードをエクステント領域４１０から読み込む。バイナリデータ取得部４０７は、このファイルレコードのヘッダ情報中のエクステント数と、当該ファイルレコード中のエクステント数分のエクステント情報とに基づき、エクステント領域４１０内の該当するエクステントから目的とするバイナリファイルの実データ（バイナリデータ）を取得する。取得されたデータはクライアント端末２０に返される。

なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、上記実施形態では、構造化文書としてＸＭＬ文書を例にとって説明したが、これに限るものではない。本発明は、例えば、ＳＧＭＬ（Standard Generalized Markup Language）文書のようなＸＭＬ文書以外の構造化文書にも同様に適用できる。

また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係るＸＭＬ文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図。 同実施形態で適用されるＸＭＬ文書管理の原理を説明するための図。 同実施形態で適用されるバイナリデータ管理の原理を説明するための図。 図１に示されるＸＭＬ文書管理システム１０の主として機能構成を示すブロック図。 同実施形態で適用されるファイルレコードのデータフォーマットを示す図。 図５のファイルレコードで管理されるＸＭＬデータファイルの論理イメージと物理ディスク上の位置との関係の一例を示す。 図６に示されるＸＭＬデータファイルの各エクステントに関するエクステント情報の一例を示す図。 同実施形態におけるバイナリデータの登録処理の手順を示すフローチャート。 上記バイナリデータの登録処理時におけるＸＭＬ文書データベース１２２の状態を示す図。 同実施形態におけるバイナリデータの取り出し処理の手順を示すフローチャート。

符号の説明

１０…ＸＭＬ文書管理システム（構造化文書管理システム）、１１…ＸＭＬ文書管理サーバ（ＸＭＬ文書管理サーバコンピュータ）、１２１…ＸＭＬ文書管理プログラム、１２２…ＸＭＬ文書データベース（構造化文書データベース）、４０１…ＸＭＬ文書特定部（構造化文書特定手段）、４０２…管理情報生成部、４０３…保存用ページ確保部、４０４…バイナリデータ格納部、４０５…関連付け部、４０６…管理情報読み込み部、４０７…バイナリデータ取得部、４１０…エクステント領域、４２０…ファイルテーブル。

Claims (3)

1. 構造化文書の集合を格納する構造化文書データベースと、
   バイナリデータを構造化文書識別情報によって識別される指定の構造化文書に付随して登録することを要求するためのクライアント端末からのバイナリデータ登録要求に従い、当該クライアント端末から要求された前記指定の構造化文書に付随されるべきバイナリデータを管理するための、ファイル識別情報及びバイナリデータ識別情報との対が設定可能なヘッダ情報を含むバイナリデータの管理情報であって、当該バイナリデータを識別するためのバイナリデータ識別情報が前記ファイル識別情報として設定され、且つ当該ファイル識別情報と対をなすバイナリ識別情報が未設定のヘッダ情報を含むバイナリデータの管理情報を生成して、当該バイナリデータの管理情報を前記構造化文書データベースに格納する管理情報生成手段と、
   前記クライアント端末から要求された前記指定の構造化文書に付随されるべきバイナリデータを前記構造化文書データベースに格納するバイナリデータ格納手段と、
   前記指定の構造化文書に付随されるべきバイナリデータが前記構造化文書データベースに格納された際に、前記構造化文書データベースに格納されている管理情報のうち、前記指定の構造化文書を識別する構造化文書識別情報がファイル識別情報として設定され、且つ当該ファイル識別情報と対をなすバイナリデータ識別情報が未設定のヘッダ情報を含む構造化文書の管理情報、または前記指定の構造化文書に付随されるべきバイナリデータに先行して前記構造化文書データベースに格納された前記指定の構造化文書に付随する別のバイナリデータを識別するバイナリデータ識別情報がファイル識別情報として設定され、且つ当該ファイル識別情報と対をなすバイナリデータ識別情報が未設定のヘッダ情報を含むバイナリデータの管理情報を対象に、前記指定の構造化文書に付随されるべきバイナリデータを識別するバイナリデータ識別情報を、当該管理情報のヘッダ情報中に前記ファイル識別情報と対をなすバイナリデータ識別情報として設定することにより、当該バイナリデータ識別情報が設定された管理情報によって、前記指定の構造化文書に付随されるべきバイナリデータを前記指定の構造化文書と関連付ける関連付け手段と、
   構造化文書識別情報によって識別される指定の構造化文書に付随するバイナリデータを取得するためのクライアント端末からのバイナリデータ取得要求に従い、前記指定の構造化文書を識別する構造化文書識別情報を前記ファイル識別情報として含む当該要求された構造化文書の管理情報を起点として、当該管理情報中のバイナリデータ識別情報から、当該バイナリデータ識別情報をファイル識別情報として含むバイナリデータの管理情報を辿る動作を繰り返すことにより、当該構造化文書と関連付けられている全てのバイナリデータを、当該構造化文書に付随して前記構造化文書データベースに格納された順に特定し、当該特定されたバイナリデータを前記構造化文書データベースから取得するバイナリデータ取得手段と
   を具備することを特徴とする構造化文書管理システム。
2. 前記クライアント端末からの検索要求に従い、前記構造化文書データベースに格納されている構造化文書の集合から当該検索要求で指定された検索条件に合致する構造化文書を特定する構造化文書特定手段を更に具備し、
   前記指定の構造化文書が、前記クライアント端末からの前記検索要求に従って特定された構造化文書である
   ことを特徴とする請求項１記載の構造化文書管理システム。
3. 構造化文書データベースに格納される構造化文書を管理するコンピュータに、
   バイナリデータを構造化文書識別情報によって識別される指定の構造化文書に付随して登録することを要求するためのバイナリデータ登録要求がクライアント端末から与えられる都度、当該クライアント端末から要求された前記指定の構造化文書に付随されるべきバイナリデータを管理するための、ファイル識別情報及びバイナリデータ識別情報との対が設定可能なヘッダ情報を含むバイナリデータの管理情報であって、当該バイナリデータを識別するためのバイナリデータ識別情報が前記ファイル識別情報として設定され、且つ当該ファイル識別情報と対をなすバイナリ識別情報が未設定のヘッダ情報を含むバイナリデータの管理情報を生成して、当該バイナリデータの管理情報を前記構造化文書データベースに格納するステップと、
   前記クライアント端末から要求された前記指定の構造化文書に付随されるべきバイナリデータを前記構造化文書データベースに格納するステップと、
   前記指定の構造化文書に付随されるべきバイナリデータが前記構造化文書データベースに格納される都度、前記構造化文書データベースに格納されている管理情報のうち、前記指定の構造化文書を識別する構造化文書識別情報がファイル識別情報として設定され、且つ当該ファイル識別情報と対をなすバイナリデータ識別情報が未設定のヘッダ情報を含む構造化文書の管理情報、または前記指定の構造化文書に付随されるべきバイナリデータに先行して前記構造化文書データベースに格納された前記指定の構造化文書に付随する別のバイナリデータを識別するバイナリデータ識別情報がファイル識別情報として設定され、且つ当該ファイル識別情報と対をなすバイナリデータ識別情報が未設定のヘッダ情報を含むバイナリデータの管理情報を対象に、前記指定の構造化文書に付随されるべきバイナリデータを識別するバイナリデータ識別情報を、当該管理情報のヘッダ情報中に前記ファイル識別情報と対をなすバイナリデータ識別情報として設定することにより、当該バイナリデータ識別情報が設定された管理情報によって、前記指定の構造化文書に付随されるべきバイナリデータを前記指定の構造化文書と関連付けるステップと、
   構造化文書識別情報によって識別される指定の構造化文書に付随するバイナリデータを取得するためのクライアント端末からのバイナリデータ取得要求に従い、前記指定の構造化文書を識別する構造化文書識別情報を前記ファイル識別情報として含む当該要求された構造化文書の管理情報を起点として、当該管理情報中のバイナリデータ識別情報から、当該バイナリデータ識別情報をファイル識別情報として含むバイナリデータの管理情報を辿る動作を繰り返すことにより、当該構造化文書と関連付けられている全てのバイナリデータを、当該構造化文書に付随して前記構造化文書データベースに格納された順に特定し、当該特定されたバイナリデータを前記構造化文書データベースから取得するステップと
   を実行させるためのプログラム。

Images