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

Description

本発明は、ＸＭＬ文書のような構造化文書が格納される構造化文書データベースを管理する構造化文書管理システムに係り、特に構造化文書をデータベースに格納するのに好適な構造化文書管理システム及びプログラムに関する。

構造化文書は、例えば特許文献１の背景技術の欄に記載されているように、当該文書の構造がタグと呼ばれる文字列で表現された文書として知られている。構造化文書は、意味付けされたタグによるデータの階層化や構造の自由な拡張性という特長を持ち、コンピュータでの処理に適している。構造化文書を格納し、且つ当該文書中の任意の構造を検索可能とするデータベースは構造化文書データベースと呼ばれる。また、構造化文書データベースを管理するシステムは構造化文書管理システムと呼ばれる。

構造化文書の代表として、ＸＭＬ（Extensible Markup Language）を使って記述された文書、つまりＸＭＬ文書が挙げられる。ＸＭＬ文書を格納する構造化文書データベースはＸＭＬデータベース（ＸＭＬＤＢ）と呼ばれ、ＸＭＬデータベースを管理する構造化文書管理システムはＸＭＬデータベース管理システム（ＸＭＬＤＢ管理システム）と呼ばれる。

ＸＭＬ文書は木構造を構成する要素（ノード）からなる。ノードは要素名（タグ）と内容（値）とから構成される。木構造はその根となる要素（ルートノード）から始まり、各要素が親子兄弟の関係で構成される。このようなＸＭＬ文書（構造化文書）の構造のために、当該ＸＭＬ文書内のある構造（あるノードを親とした構造）を１つのＸＭＬ文書（細分化されたＸＭＬ文書）として管理することができる。

このようなＸＭＬ文書をＸＭＬデータベースに格納して管理するために、ＸＭＬデータベース管理システムでは、コレクション及びシートと呼ばれる管理体系が用いられる。シートは一種のファイルであり、ＸＭＬ文書内のある構造（要素）を細分化されたＸＭＬ文書としてそのままの形式で格納する。一方、コレクションは、ファイルシステムのフォルダ或いはディレクトリに相当し、複数のシート（ＸＭＬ文書）を分類して管理するための管理ブロック（構造化文書管理ブロック）として用いられる。

コレクションの下位には、当該コレクションとは別のコレクション、またはシートを作成（登録）することが可能である。つまりコレクションは、ＸＭＬ文書と同様に木構造で階層的に管理することが可能でる。これに対し、シートの下位には、コレクション及びシートのいずれも登録することはできない。コレクションの階層構造（木構造のコレクション）では、最上位のコレクションは１つだけであり、ルートコレクションと呼ばれる。このコレクションの階層構造において、コレクションは枝を持つ節にも枝を持たない節（葉）にもなり得るが、シートは枝を持たない節（葉）にしかならない。

このような管理体系におけるシートとコレクションとの関係は、書類とバインダの関係に喩えることができる。つまりシートとコレクションを用いた管理体系では、シート（書類）を種類別にコレクション（バインダ）に分類して管理する方法が適用される。

この管理体系では、上述のようにコレクションの階層的な定義を許すことで、コレクション、ＸＭＬ文書内ノードをシームレスにＸＰａｔｈと呼ばれるパス情報で表現することができる。換言するならば、ＸＭＬ文書をＸＭＬデータベースに格納する場合、どの階層までをコレクションとし、どの階層以下を個々のＸＭＬ文書（つまりシート）として登録するかは、ユーザが任意に決めることができる。

さて、ＸＭＬデータベースに格納されるＸＭＬ文書を適切に管理する手法は、当該データベースに格納されるＸＭＬ文書の種類によって異なる。ＸＭＬ文書の種類は、集合型ＸＭＬ文書と統合型ＸＭＬ文書とに分類される。

集合型ＸＭＬ文書は、予め定められたフォーマットに従って作成されたＸＭＬ文書の集合を指す。集合型ＸＭＬ文書には、特許文献や従業員情報のような、規定のスキーマ構造を持ち、１文書のサイズが比較的小さなデータの集まりで構成されているＸＭＬ文書が該当する。

集合型ＸＭＬ文書は、コレクションを使用しない管理方法（方法１）及びコレクションを使用する管理方法（方法２）のいずれかの方法で管理されるのが一般的である。方法１は、コレクションへの分類を行わずに、全てのＸＭＬ文書を直接ルートコレクションに登録して管理する手法である。集合型ＸＭＬ文書は予め定められたフォーマットに従って作成されているためにＸＭＬ文書毎の構造の違いを考慮する必要がないことから、このようなルートコレクション下での一括した管理が可能となる。

方法２は、集合型ＸＭＬ文書を体系的に管理するのに用いられる。方法２を適用する場合、ＸＭＬ文書の種類別にコレクションが作成される。各ＸＭＬ文書は文書の種類に対応するコレクションに登録して管理される。コレクションを使用する場合、目的の文書が登録されているコレクションを直接パスで指定できるため、高速検索が可能となる。

図３は集合型ＸＭＬ文書３００の例を示し、図４は図３に示されるＸＭＬ文書３００の構造（ＸＭＬ構造）を示す。図３には、ＸＭＬ文書３００の構造の理解を容易にするために、ノード（タグ）毎に当該ノードに至るルートノードからのパス（ＸＰａｔｈ）が記述されている。図３に示されるＸＭＬ文書３００の場合、例えば従業員ノード３１０に着目して、当該従業員ノード３１０を親ノードとすると、個人ノード３２０-1〜３２０-nは当該従業員ノード３１０の子ノードとなる。

図３の集合型ＸＭＬ文書３００の場合、例えば、従業員ノード３１０をコレクション（従業員コレクション）として管理し、従業員ノード３１０の子ノードである個人ノード３２０-i（ｉ＝１〜ｎ）毎に、当該個人ノード３２０-iから構成される構造の細分化されたＸＭＬ文書４２０-iを従業員コレクション下のシートとして管理することが可能である。このＸＭＬ文書４２０-iでは、個人ノード３２０-iを親ノードとすると、その子ノードは氏名ノード３３１-i、性別ノード３３２-i、社員番号ノード３３３-i及び所属ノード３３４-iとなる。また、所属ノード３３４-iを親ノードとすると、その子ノードは事業部名ノード３４１-i及びＧｒ．名（グループ名）ノード３４２-iとなる。

また、個人ノード３２０-iを従業員コレクション下のコレクション（個人コレクション）として管理して、当該個人ノード３２０-iを親ノードとする子ノードである、氏名ノード３３１-i、性別ノード３３２-i、社員番号ノード３３３-i及び所属ノード３３４-iからそれぞれ構成される構造のＸＭＬ文書４３１-i，４３２-i，４３３-i及び４３４-iを個人コレクション下のシートとして管理することも可能である。また、図３の集合型ＸＭＬ文書３００全体を１つのＸＭＬ文書４１０として管理することも可能である。

一方、統合型ＸＭＬ文書は、異なる種類のＸＭＬ文書の集合を指す。統合型ＸＭＬ文書には、社内規定や法律の条文のような、ＸＭＬスキーマや文書型定義（Document Type Definition: DTD）によって文書のスタイルは決められていても、タグに指定する要素の内容までは規定されておらず、１文書のサイズが比較的大きいデータの集まりで構成されているＸＭＬ文書が該当する。例えば、「部」「章」「節」「項」のフォーマットを指定するためのスキーマ構造であって、記載する内容に関する指定のないスキーマ構造のＸＭＬ文書が該当する。

統合型ＸＭＬ文書には、コレクションとシートとに分割した管理方法（方法３）が適している。方法３では、ＸＭＬ文書の階層構造に合わせて、例えば最も頻繁に検索または更新が行われる単位にシートが作成される。その理由は、シート単位での検索はノード単位の検索よりも高速に実行され、更新時のロックはシート単位に実行されるためである。
特開２００６−１２７２３５号公報

上述のように、従来の構造化文書管理システムでは、コレクションの階層的な定義を許すことで、コレクション、及びＸＭＬ文書（構造化文書）内のノードをシームレスにパスで表現することができる。また、コレクションとシートとを組み合わせることによって、ＸＭＬデータベース（構造化文書データベース）におけるＸＭＬ文書を当該ＸＭＬ文書の種類に適合するように効率的に管理することができる。

しかし、このような管理を可能とするためには、構造化文書管理システムを利用するクライアント（クライアント端末）は、構造化文書（ＸＭＬ文書）の登録時に、構造化文書としては同じ構造であっても、コレクションを使用するか否か、つまり登録先がコレクションであるか或いはシートであるかによって、当該構造化文書が細分化された構造化文書毎に構造化文書データベースに格納する方法を逐次構造化文書管理システムに指示する必要がある。

本発明は上記事情を考慮してなされたものでその目的は、コレクション（構造化文書管理ブロック）を使用するか否かによってクライアント側が細分化された構造化文書の格納方法を意識することなく、構造化文書を効率的にデータベースに格納することができる構造化文書管理システム及びプログラムを提供することにある。

本発明の１つの観点によれば、複数の要素を含む構造化文書が格納される構造化文書データベースを管理する構造化文書管理システムが提供される。このシステムは、構造化文書に含まれる要素を、当該構造化文書において当該要素の子要素をなす当該要素とは別の要素によって構成される細分化されたＸＭＬ文書の集合を管理するための構造化文書管理ブロックとして登録することを示す要素定義情報を記憶する要素定義情報記憶手段と、前記データベース管理システムを利用するクライアントからの要素定義要求に応じ、当該要求によって指定される要素を前記構造化文書管理ブロックとして登録することを示す要素定義情報を前記要素定義情報記憶手段に設定する要素定義情報設定手段と、前記クライアントからの構造化文書の格納を指定する構造化文書格納要求に応じ、前記要素定義情報記憶手段から、当該要求によって指定される構造化文書に含まれている要素に対応する要素定義情報を検索する要素定義情報検索手段と、前記構造化文書格納要求によって指定された構造化文書を、前記要素定義情報検索手段による検索結果に基づいて、前記構造化文書管理ブロックと細分化されたＸＭＬ文書とに分割して前記データベースに格納するための処理を行う格納処理手段とを具備する。

本発明によれば、クライアントから要素定義要求が与えられた場合、当該要求によって指定される要素を構造化文書管理ブロックとして登録することを示す要素定義情報を要素定義情報記憶手段に設定し、クライアントから構造化文書格納要求が与えられた場合、当該構造化文書格納要求によって指定された構造化文書が、当該構造化文書に含まれている要素に対応する要素定義情報が要素定義情報記憶手段から検索できたかに基づいて、構造化文書管理ブロックと細分化されたＸＭＬ文書とに自動的に分割されてデータベースに格納される。これにより、クライアント側では、構造化文書管理ブロック（コレクション）を使用するか否かによって細分化された構造化文書の格納方法を意識することなく、構造化文書を効率的にデータベースに格納することができる。

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

ＸＭＬＤＢサーバ１０は、主メモリのようなメモリ１１を有するコンピュータ（データベースサーバコンピュータ）である。ＸＭＬＤＢサーバ１０は、ハードディスクドライブのような外部記憶装置４０と接続されている。この外部記憶装置４０は、ＸＭＬデータベース管理プログラム（ＸＭＬＤＢ管理プログラム）４１及びＸＭＬデータベース（ＸＭＬＤＢ）４２を格納する。

ＸＭＬＤＢ管理プログラム４１は、ＸＭＬＤＢサーバ１０によるＸＭＬＤＢ４２の管理、及びクライアント端末からの検索要求に基づく検索処理に用いられる。ＸＭＬＤＢ４２は構造化文書としてのＸＭＬ文書（ＸＭＬ形式の電子文書）を格納するデータベース（構造化文書データベース）である。ＸＭＬＤＢ４２に格納されているＸＭＬ文書は検索の対象となる。

本実施形態では、ＸＭＬＤＢサーバ１０によって構造化文書管理システムとしてのＸＭＬデータベース管理システム（ＸＭＬＤＢ管理システム）５０が実現される。図２はＸＭＬＤＢ管理システム５０の主として機能構成を示すブロック図である。ＸＭＬＤＢ管理システム５０は、登録パス情報テーブル（以下、ＲＰＴと称する）５１、登録パス情報テーブル操作部（以下、ＲＰＴ操作部と称する）５２、格納処理部５３、検索処理部５４、要求処理部５５及びＸＭＬデータベース操作部（ＸＭＬＤＢ操作部）５６を含む。

ＲＰＴ５１は、任意のパス毎に登録パス情報を保持する。登録パス情報は、パス情報（構造情報）及び登録種別情報の組を含む。パス情報は例えばＸＰａｔｈであり、ＸＭＬ文書内のノードの階層構造を表す構造情報である。登録種別情報は、当該登録種別情報と組をなすパス情報で特定されるノード（要素）をコレクション（構造化文書管理ブロック）として登録するか、当該ノード（要素）をシートとして登録するかを示すフラグ情報である。ＲＰＴ５１は例えばメモリ１１内に割り当てられた記憶領域に格納される。

ＲＰＴ操作部５２は、ＲＰＴ５１を対象とする各種の操作を行う。ＲＰＴ操作部５２は、登録パス情報定義部５２１及び登録パス情報検索部５２２を含む。登録パス情報定義部５２１は、例えばクライアント端末２０からの登録パス情報定義要求に応じて要求されたパスで特定されるノード（要素）をコレクションとするかを定義する登録パス情報（要素定義情報）をＲＰＴ５１に設定する登録パス情報定義操作（要素定義情報設定操作）を行う。登録パス情報検索部５２２は、例えばクライアント端末２０または格納処理部５３からの登録パス情報検索要求に応じて、要求されたパスに関する登録パス情報（要素定義情報）をＲＰＴ５１から検索する登録パス情報検索操作（要素定義情報検索操作）を行う。ＲＰＴ操作部５２は更に、例えばクライアント端末２０からの登録パス情報削除要求に応じて、要求された登録パス情報をＲＰＴ５１から削除するための登録パス情報削除操作を行う登録パス情報削除操作部（図示せず）を含む。

格納処理部５３は、クライアント端末２０からのＸＭＬ文書格納要求に応じてＸＭＬＤＢ４２にＸＭＬ文書を格納するための格納処理を行う。格納処理部５３は格納処理に際し、要求されたＸＭＬ文書の各要素の格納形式をＲＰＴ操作部５２に問い合わせる。格納処理部５３は、ＲＰＴ操作部５２への問い合わせに対して当該ＲＰＴ操作部５２から通知された格納形式に従ってＸＭＬ文書内の要素をＸＭＬＤＢ４２に格納する。

検索処理部５４は、クライアント端末２０からの検索要求（問い合わせ）に応じて、当該検索要求（問い合わせ）で指定された検索条件に合致するＸＭＬ文書をＸＭＬＤＢ４２から検索する。要求処理部５５は、クライアント端末２０からの各種の要求（コマンド）を解釈し、当該要求をＲＰＴ操作部５２、格納処理部５３または検索処理部５４に送出する。ＸＭＬＤＢ操作部５６は、格納処理部５３及び検索処理部５４がＸＭＬＤＢ４２にアクセスするのを可能とするインタフェースとして機能する。

本実施形態において、ＲＰＴ操作部５２、格納処理部５３、検索処理部５４、要求処理部５５及びＸＭＬＤＢ操作部５６は、図１のＸＭＬＤＢサーバ１０が外部記憶装置４０に格納されているＸＭＬＤＢ管理プログラム４１を当該サーバ１０内のメモリ１１に読み込んで実行することにより実現されるものとする。このプログラム４１は、コンパクトディスク、或いはＲＯＭのような、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム４１が、ネットワーク３０を介してＸＭＬＤＢサーバ１０にダウンロードされても構わない。

図３は、本実施形態においてＸＭＬＤＢ４２に格納されるＸＭＬ文書（集合型ＸＭＬ文書）３００の一例を示し、図４は図３に示されるＸＭＬ文書３００の構造（ＸＭＬ構造）を示す。図３には、ＸＭＬ文書３００の構造の理解を容易にするために、ノード（タグ）毎にＸＰａｔｈが記述されている。ＸＰａｔｈは、ノードの構造を表す（特定する）のに用いられる当該ノードに至るルートノードからのパスを表す構造情報である。

図３のＸＭＬ文書３００は、ＸＰａｔｈ「／従業員」で表される従業員ノード３１０を含む。また図３のＸＭＬ文書は、従業員ノード３１０の下位に、ＸＰａｔｈ「／従業員／個人」で表される複数（ｎ個）の個人ノード３２０-1〜３２０-nを含む。

また図３のＸＭＬ文書３００は、各個人ノード３２０-i（ｉ＝１〜ｎ）の下位に、ＸＰａｔｈ「／従業員／個人／氏名」「／従業員／個人／性別」「／従業員／個人／社員番号」及び「／従業員／個人／所属」でそれぞれ表される氏名ノード３３１-i、性別ノード３３２-i、社員番号ノード３３３-i及び所属ノード３３４-iを含む。また図３のＸＭＬ文書３００は、各所属ノード３３４-iの下位に、ＸＰａｔｈ「／従業員／個人／所属／事業部名」及び「／従業員／個人／所属／Ｇｒ．名」でそれぞれ表される事業部名ノード３４１-i及びＧｒ．名（グループ名）ノード３４２-iを含む。

但し、図３及び図４には、個人ノード３２０-1（ｉ＝１）の子ノードである、氏名ノード３３１-1、性別ノード３３２-1、社員番号ノード３３３-1及び所属ノード３３４-1だけが示されている。同様に図３及び図４には、所属ノード３３４-1（ｉ＝１）の子ノードである、事業部名ノード３４１-1及びＧｒ．名（グループ名）ノード３４２-1だけが示されている。

図３のＸＭＬ文書３００の例では、図４のＸＭＬ構造からも明らかなように、当該ＸＭＬ文書３００全体、つまり従業員ノード３１０（以下の全ノード）を、１つのＸＭＬ文書４１０として管理することができる。また、従業員ノード３１０を親ノードとすると、その子ノードである個人ノード３２０-i毎に、当該個人ノード３２０-i（以下の全ノード）を１つのＸＭＬ文書４２０-iとして管理することもできる。つまり、個人ノード３２０-iを親ノードとし、氏名ノード３３１-i、性別ノード３３２-i、社員番号ノード３３３-i及び所属ノード３３４-iの各ノードを当該個人ノード３２０-iの子ノードとする１つのＸＭＬ文書４２０-iとして管理することもできる。同様に、氏名ノード３３１-i、性別ノード３３２-i、社員番号ノード３３３-i及び所属ノード３３４-i（以下の全ノード）をそれぞれ１つのＸＭＬ文書４３１-i，４３２-i，４３３-i及び４３４-iとして管理することもできる。但し、ＸＭＬ文書４３１-i，４３２-i及び４３３-iは、それぞれ氏名ノード３３１-i、性別ノード３３２-i及び社員番号ノード３３３-iのみから構成される。

そこで、従業員ノード３１０をコレクション（構造化文書管理ブロック）として登録すると共に、従業員ノード３１０の子ノードである個人ノード３２０-1〜３２０-nをそれぞれ１つのＸＭＬ文書４２０-1〜４２０-nとして当該コレクション下のシートに登録して管理することも可能である。

また、従業員ノード３１０をコレクション（第１のコレクション）として登録すると共に、従業員ノード３１０の子ノードである個人ノード３２０-1〜３２０-nを第１のコレクション下の別のコレクション（第２のコレクション）として登録し、各個人ノード３２０-iの子ノードである氏名ノード３３１-i、性別ノード３３２-i、社員番号ノード３３３-i及び所属ノード３３４-iをそれぞれ１つのＸＭＬ文書４３１-i，４３２-i，４３３-i及び４３４-iとして第２のコレクション下のシートに登録することもできる。

次に、本実施形態の動作について説明する。
まず、図３に示されるＸＭＬ文書３００を対象とするクライアント端末２０側の文書格納処理について、コレクションを使用する場合を例に、図５のフローチャートを参照して説明する。

本実施形態では、従業員ノード３１０をコレクション（従業員コレクション）とし、個人ノード３２０-1〜３２０-n以下をそれぞれ１つのＸＭＬ文書４２０-1〜４２０-n（シート）としてＸＭＬＤＢ４２に格納するものとする。この場合、クライアント端末２０は、アプリケーション２１に従って、以下に述べる文書格納処理を実行する。

まずクライアント端末２０は、目的のコレクション（ここでは従業員コレクション）をＸＭＬＤＢ管理システム５０によって作成させるためのコレクション作成処理を実行する（ステップＳ１）。このコレクション作成処理においてクライアント端末２０は、ＸＭＬ文書４２０-1〜４２０-nをシートとして管理（格納）するのに用いられる従業員コレクションの作成要求を、ＸＭＬＤＢ管理システム５０（ＸＭＬＤＢサーバ１０）に対してネットワーク３０を介して発行する。

クライアント端末２０からの従業員コレクションの作成要求に対して、後述するようにＸＭＬＤＢ管理システム５０の格納処理部５３（ＸＭＬＤＢ操作部５６）によって従業員コレクションが正常に作成された場合、当該ＸＭＬＤＢ管理システム５０の要求処理部５５からクライアント端末２０に正常応答が通知される。するとクライアント端末２０は、所望の登録パス情報（例えば作成されたコレクションに対応する登録バス情報）をＸＭＬＤＢ管理システム５０によって定義（設定）させるための処理（登録パス情報定義処理）を実行する（ステップＳ２）。この登録パス情報定義処理においてクライアント端末２０は、ＸＭＬＤＢ管理システム５０に対して目的のパスに関する登録パス情報の定義要求（登録パス情報定義要求）を発行する。前述したように、登録パス情報はパス情報及び登録種別情報の組を含む。ここでは、パス情報としてＸＰａｔｈ「／従業員／個人」が用いられ、登録種別情報として「コレクション」を指定する情報が用いられる。

クライアント端末２０からの登録パス情報定義要求に対して、後述するようにＸＭＬＤＢ管理システム５０のＲＰＴ操作部５２によって登録パス情報定義が正常になされた場合、要求処理部５５からクライアント端末２０に正常応答が通知される。するとクライアント端末２０は、目的のＸＭＬ文書（ここではＸＭＬ文書３００）をＸＭＬＤＢ管理システム５０によってＸＭＬＤＢ４２に格納させるための処理（格納処理）を実行する（ステップＳ３）。この格納処理においてクライアント端末２０は、ＸＭＬ文書３００を対象とする格納要求（ＸＭＬ文書格納要求）をＸＭＬＤＢ管理システム５０に対して発行する。

次に、図５のフローチャートで示されるクライアント端末２０側の処理に対応してＸＭＬＤＢ管理システム５０で実行される処理について、図６のフローチャートを参照して説明する。

クライアント端末２０からＸＭＬＤＢ管理システム５０に対して発行された要求は、当該システム５０の要求処理部５５によって受け付けられる。要求処理部５５は、クライアント端末２０からの要求を受け付けると、当該要求の種別を判別する（ステップＳ１１）。

もし、クライアント端末２０からの要求がコレクション作成要求（ここでは、従業員コレクションの作成要求）の場合（ステップＳ１１）、要求処理部５５は、格納処理部５３に当該コレクション作成要求を送出する。すると格納処理部５３は、ＸＭＬＤＢ操作部５６にコレクション作成要求を送出する。ＸＭＬＤＢ操作部５６は、この要求を受け取るとコレクション（構造化文書管理ブロック）作成手段として機能して、要求されたコレクション（ここでは、従業員コレクション）をＸＭＬＤＢ４２内に作成する（ステップＳ１２）。

ＸＭＬＤＢ操作部５６は、コレクション作成が正常に行われた場合、格納処理部５３に正常である旨の応答を通知する。一方、コレクション作成が正常に行われなかった場合、ＸＭＬＤＢ操作部５６は格納処理部５３に不正要求である旨の応答を通知する。格納処理部５３は、ＸＭＬＤＢ操作部５６からの応答を要求処理部５５に通知する。要求処理部５５は、格納処理部５３からの応答をクライアント端末２０に通知する。

次に、クライアント端末２０からの要求が登録パス情報定義要求の場合（ステップＳ１１）、要求処理部５５は、ＲＰＴ操作部５２に当該登録パス情報定義要求を送出する。するとＲＰＴ操作部５２内の登録パス情報検索部５２２は、要求されたパスに関する登録パス情報がＲＰＴ５１に存在するかを調べる（ステップＳ１３）。

もし、要求されたパスに関する登録パス情報が存在しないならば（ステップＳ１３）、ＲＰＴ操作部５２内の登録パス情報定義部５２１は登録パス情報定義処理を実行して、ＲＰＴ５１に新たな登録パス情報を追加する（ステップＳ１４）。ここでは、登録パス情報のパス情報にＸＰａｔｈ「／従業員」が用いられ、登録パス情報の登録種別情報に「コレクション」を指定する情報が用いられる。ＲＰＴ操作部５２は、登録パス情報がＲＰＴ５１に追加されると、登録パス情報定義処理が正常に行われた旨の応答を要求処理部５５に通知する。

これに対し、要求されたパスに関する登録パス情報が既にＲＰＴ５１に存在するならば（ステップＳ１３）、ＲＰＴ操作部５２は不正要求である旨の応答を要求処理部５５に通知する。

要求処理部５５は、登録パス情報定義要求に対するＲＰＴ操作部５２からの応答をクライアント端末２０に通知する。

次に、クライアント端末２０からの要求が文書格納要求の場合（ステップＳ１１）、要求処理部５５は当該文書格納要求を格納処理部５３に送出する。すると格納処理部５３は、要求されたＸＭＬ文書（ここでは、図３に示されるＸＭＬ文書３００）の整合性をチェックする（ステップＳ１５）。この整合性チェックはＸＭＬ文書をＸＭＬＤＢ４２に格納する際に通常に行われている。このため整合性チェックの手法については説明を省略する。

格納処理部５３は、整合性チェックの結果が正常であるならば（ステップＳ１５）、要求されたＸＭＬ文書を、ＲＰＴ５１に保持されている登録パス情報定義に従って、コレクションとシート（細分化されＸＭＬ文書）とに分割してＸＭＬＤＢ４２に格納するためのＸＭＬ文書分割格納処理を実行する（ステップＳ１６）。このＸＭＬ文書分割格納処理の詳細については後述する。

さて本実施形態では、クライアント端末２０は、例えば登録パス情報定義要求を発行する前に、目的のパスに関する登録パス情報が既にＲＰＴ５１に存在するかを問い合わせるための登録パス情報検索要求を、ＸＭＬＤＢ管理システム５０に発行することができる。登録パス情報検索要求はパス情報を含む。

要求処理部５５は、クライアント端末２０からＸＭＬＤＢ管理システム５０に発行された要求が登録パス情報検索要求の場合（ステップＳ１１）、当該登録パス情報検索要求をＲＰＴ操作部５２に送出する。するとＲＰＴ操作部５２内の登録パス情報検索部５２２は、要求されたパスをパス情報として含む登録パス情報をＲＰＴ５１から検索するための登録パス情報検索処理を実行する（ステップＳ１７）。

要求された登録パス情報が検索できた場合、ＲＰＴ操作部５２は当該登録パス情報を登録パス情報検索要求に対する応答として要求処理部５５に通知する。これに対し、要求された登録パス情報が検索できなかった場合、ＲＰＴ操作部５２は当該登録パス情報が存在しない旨の応答を要求処理部５５に通知する。要求処理部５５は、ＲＰＴ操作部５２からの応答をクライアント端末２０に通知する。クライアント端末２０は、この通知内容、つまり登録パス情報検索結果を表示画面を介してユーザに通知することとにより、例えば検索された登録パス情報を削除する必要があるかの指示をユーザに入力させる。もし、登録パス情報の削除がユーザによって指示された場合、クライアント端末２０は登録パス情報削除要求をＸＭＬＤＢ管理システム５０に発行する。この場合、要求された登録パス情報が、ＲＰＴ操作部５２内の図示せぬ登録パス情報削除操作部によってＲＰＴ５１から削除される。なお、登録パス情報検索要求は、ＸＭＬ文書分割格納処理において、後述するように格納処理部５３によっても発行される。

次に、ＸＭＬ文書分割格納処理（ステップＳ１６）の詳細について、図７のフローチャートを参照して説明する。

格納処理部５３はＸＭＬ文書分割格納処理の最初で、ＲＰＴ操作部５２（内の登録パス情報検索部５２２）により登録パス情報検索処理を行わせる（ステップＳ２１）。即ち格納処理部５３は、要求されたＸＭＬ文書（ＸＭＬ文書３００）の構造を解析して、当該ＸＭＬ文書のルート（根）となるノード（つまり最上位の階層のノード）を特定するパス情報を含む登録パス情報の検索要求（登録パス情報検索要求）をＲＰＴ操作部５２に発行する。

ＲＰＴ操作部５２内の登録パス情報検索部５２２は、格納処理部５３から登録パス情報検索要求を受け取ると、要求されたノードを特定するパス情報を含む登録パス情報（つまり要求されたパスに関する登録パス情報）をＲＰＴ５１から検索するための処理を実行する。登録パス情報検索部５２２は、この処理の結果に基づき、要求されたパスに関する登録パス情報がＲＰＴ５１に存在するかを判定する（ステップＳ２２）。もし、要求されたパスに関する登録パス情報がＲＰＴ５１に存在しない場合、ＲＰＴ操作部５２は、その旨の応答を格納処理部５３に通知する。

もし、要求されたパスに関する登録パス情報がＲＰＴ５１に存在する場合、登録パス情報検索部５２２は、当該登録パス情報中の登録種別情報によってコレクションが指定されているかを判定する（ステップＳ２３）。そしてＲＰＴ操作部５２は、要求されたパスに関する登録パス情報が存在する旨と、当該登録パス情報によるコレクションの指定の有無とを格納処理部５３に通知する。

格納処理部５３は、ＲＰＴ操作部５２から、要求されたパスに関する登録パス情報が存在し、且つコレクションが指定されていることが通知された場合（ステップＳ２３）、要求されたＸＭＬ文書から、登録パス情報検索の対象となったパス（ここではルートノード）を親ノードとする子ノードをＸＭＬＤＢ４２に格納されるべき細分化されたＸＭＬ文書として取り出す（ステップＳ２４）。この取り出されたＸＭＬ文書を、クライアント端末２０から要求されたＸＭＬ文書と区別するために、ＸＭＬ文書’のように表現する。

格納処理部５３は、ステップＳ２４でＸＭＬ文書’が取り出される都度、当該ＸＭＬ文書’をＸＭＬＤＢ４２への格納が要求されたＸＭＬ文書’として、当該ＸＭＬ文書’を対象とする文書格納要求を、当該格納処理部５３自身に対して（再帰的に）発行する。これにより、ＸＭＬ文書’を対象とするＸＭＬ文書分割格納処理（ステップＳ２５）が（再帰的に）実行される。このＸＭＬ文書分割格納処理では、後述するようにＸＭＬＤＢ４２にＸＭＬ文書を格納する処理が行われる。

もし、ＸＭＬ文書’を対象とするＸＭＬ文書分割格納処理（ステップＳ２５）が正常に行われて、且つ同一のパスを親ノードとする子ノードの中に未処理の子ノードが存在するならば（ステップＳ２６）、その子ノードについて、ステップＳ２４及び２５の処理が行われる。つまり、同一のパスを親ノードとする全ての子ノードについて、ステップＳ２４及び２５の処理が繰り返される。

一方、要求されたパスに関する登録パス情報が存在しない場合（ステップＳ２２）、或いは当該登録パス情報は存在しても、コレクションが指定されていない場合（ステップＳ２３）、格納処理部５３は、要求されたパスで特定されるノードをＸＭＬ文書’として、ＸＭＬＤＢ４２内に作成されている、当該ノードの親ノードに対応するコレクションに格納させるためのＸＭＬ文書格納要求をＸＭＬＤＢ操作部５６に発行する。ＸＭＬＤＢ操作部５６は、格納処理部５３からのＸＭＬ文書格納要求を受けて、要求されたＸＭＬ文書’をＸＭＬＤＢ４２内の指定されたコレクションに格納する（ステップＳ２７）。

ＸＭＬＤＢ操作部５６は、ＸＭＬ文書格納処理が正常に行われた場合、格納処理部５３に正常である旨の応答を通知する。これに対してＸＭＬ文書格納処理が正常に行われなかった場合、ＸＭＬＤＢ操作部５６は格納処理部５３に不正要求である旨の応答を通知する。格納処理部５３は、当該格納処理部５３自身の処理の結果及びＸＭＬＤＢ操作部５６からの応答に基づき、クライアント端末２０に対して応答を返す。

次に、図７のフローチャートに従うＸＭＬ文書分割格納処理の具体例について説明する。本実施形態において、クライアント端末２０から要求されたＸＭＬ文書は、図３に示されるＸＭＬ文書３００である。また、ＲＰＴ５１には、当該ＸＭＬ文書３００のルートノードである従業員ノード３１０を特定するパス情報「／従業員」と「コレクション」を指定する要求種別情報の組を含む登録パス情報が存在する。

この場合、ＸＭＬ文書３００を対象とする文書格納要求に対しては、当該ＸＭＬ文書３００のルートノードが従業員ノード３１０であることから、ステップＳ２１〜Ｓ２３を経て従業員ノード３１０を親ノードとする子ノードの全て、即ち個人ノード３２０-1〜３２０-nがＸＭＬ文書４２０-1〜４２０-nとして順次取り出される（ステップＳ２４）。

ここで、個人ノード（個人要素）３２０-1がＸＭＬ文書４２０-1として取り出されたものとする。すると、ＸＭＬ文書４２０-1を対象とする文書格納要求が、格納処理部５３により当該格納処理部５３自身に対して発行される。これにより、ＸＭＬ文書３００に対するのと同様の処理がＸＭＬ文書４２０-1に対しても行われる。

ここで、ＸＭＬ文書４２０-1のルートノード（最上位のノード）である個人ノード３２０-1を特定するパス情報「／従業員／個人」を含む登録パス情報はＲＰＴ５１に存在しないか、或いは存在しても「コレクション」を指定していないものとする。この場合、ＸＭＬ文書４２０-1に関し、再帰的に行われるＸＭＬ文書分割格納処理（ステップＳ２５）の中で、ステップＳ２７に相当する処理が次のように行われる。まず、ＸＭＬ文書４２０-1のルートノードである個人ノード３２０-1の親ノードは、元のＸＭＬ文書３００のルートノードである従業員ノード３１０である。この従業員ノード３１０は、ＸＭＬＤＢ４２内にコレクション（従業員コレクション）として登録されている。そこで、ステップＳ２７に相当する処理では、ＸＭＬ文書４２０-1がＸＭＬＤＢ４２内の従業員コレクションに格納される。同様に、残りの個人ノード３２０-2〜３２０-nについても、それぞれＸＭＬ文書４２０-2〜４２０-nとして、再帰的に行われるＸＭＬ文書分割格納処理の中で、ＸＭＬＤＢ４２内の従業員コレクションに順次格納される。

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

また、上記実施形態では、ＲＰＴ５１はメモリ１１内に割り当てられた記憶領域に格納される。しかし、ＲＰＴ５１がＸＭＬＤＢ管理システム５０の再立ち上げ後も再利用可能なように、当該ＲＰＴ５１の内容が適宜（例えばＸＭＬＤＢ管理システム５０がレディ状態にある期間に）外部記憶装置４０の例えば所定領域（ＲＰＴ保存領域）に保存される構成とすると良い。この場合、ＸＭＬＤＢ管理システム５０の再立ち上げ（初期化）時に、外部記憶装置４０のＰＲＴ保存領域に保存されている情報をＲＰＴ５１としてメモリ１１にロードすれば良い。

また、上記実施形態では、登録パス情報（要素定義情報）が、パス情報に加えて登録種別情報を含んでいる。しかし、登録パス情報が、パス情報で特定されるノード（要素）をコレクション（構造化文書管理ブロック）として登録することを常に指定するものとするならば、必ずしも登録種別情報を含む必要はない。

また、上記実施形態では、クライアント端末２０がネットワーク３０を介してＸＭＬＤＢ管理システム５０のＸＭＬＤＢサーバ１０に接続されている。しかし、クライアント端末２０が直接にＸＭＬＤＢ管理システム５０のＸＭＬＤＢサーバ１０に接続されていても構わない。また、クライアント端末２０上で動作するのと同様のアプリケーションがＸＭＬＤＢサーバ１０上で動作する構成とすることにより、当該ＸＭＬＤＢサーバ１０が有するキーボード、ディスプレイ等をクライアント端末２０のように用いても、つまりＸＭＬＤＢサーバ１０をクライアント端末に兼用しても構わない。

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

本発明の一実施形態に係るクライアント−サーバシステムのハードウェア構成を示すブロック図。 図１に示されるＸＭＬＤＢ管理システム（ＸＭＬデータベース管理システム）の主として機能構成を示すブロック図。 ＸＭＬＤＢ（ＸＭＬデータベース）に格納されるＸＭＬ文書の一例を示す図。 図３に示されるＸＭＬ文書の構造を示す図。 同実施形態で適用されるクライアント端末側の文書格納処理の手順を示すフローチャート。 図５のフローチャートで示されるクライアント端末側の処理に対応してＸＭＬＤＢ管理システムで実行される処理の手順を示すフローチャート。 図６のフローチャートに含まれているＸＭＬ文書分割格納処理の手順を示すフローチャート。

符号の説明

１０…ＸＭＬＤＢサーバ（ＸＭＬデータベースサーバ）、２０…クライアント端末、４０…外部記憶装置、４１…ＸＭＬＤＢ管理プログラム（ＸＭＬデータベース管理プログラム）、４２…ＸＭＬＤＢ（ＸＭＬデータベース）、５０…ＸＭＬＤＢ管理システム（ＸＭＬデータベース管理システム、構造化文書管理システム）、５１…ＲＰＴ（登録パス情報テーブル、要素定義情報記憶手段）、５２…ＲＰＴ操作部（登録パス情報テーブル操作部）、５３…格納処理部、５４…検索処理部、５５…要求処理部、５６…ＸＭＬＤＢ操作部（ＸＭＬデータベース操作部、構造化文書管理ブロック作成手段）、５２１…登録パス情報定義部（要素定義情報設定手段）、５２２…登録パス情報検索部（要素定義情報検索手段）。

Claims (4)

1. 複数の要素を含む構造化文書が格納される構造化文書データベースを管理する構造化文書管理システムにおいて、
   構造化文書に含まれる要素を、当該構造化文書において当該要素の子要素をなす当該要素とは別の要素によって構成される細分化された構造化文書の集合を管理するための構造化文書管理ブロックとして登録することを示す要素定義情報であって、前記構造化文書管理ブロックとして登録される要素を含む構造化文書における当該要素へのパスを表すパス情報を含む要素定義情報を記憶する要素定義情報記憶手段と、
   クライアントからの要素定義要求に応じ、当該要求によって指定される要素を前記構造化文書管理ブロックとして登録することを示す要素定義情報を前記要素定義情報記憶手段に設定する要素定義情報設定手段と、
   前記クライアントからの構造化文書の格納を指定する構造化文書格納要求に応じ、前記要素定義情報記憶手段から、当該要求によって指定される構造化文書に含まれている要素に対応する要素定義情報を検索する要素定義情報検索手段と、
   前記構造化文書格納要求によって指定された構造化文書を、前記要素定義情報検索手段による検索結果に基づいて、前記構造化文書管理ブロックと細分化された構造化文書とに分割して前記データベースに格納するための構造化文書分割格納処理を行う格納処理手段と
   を具備し、
   前記格納処理手段は、前記構造化文書格納要求によって指定された構造化文書の根となる要素に対応する要素定義情報の検索を前記要素定義情報検索手段によって行わせ、前記要素定義情報検索手段によって前記要素定義情報が検索された場合、前記構造化文書格納要求によって指定された構造化文書から当該要素定義情報に対応する要素の子要素を細分化された構造化文書として順次取り出して、当該取り出された構造化文書の格納を指定する構造化文書格納要求を前記格納処理手段自身に対して与える動作を繰り返すことにより、前記構造化文書分割格納処理を再帰的に行う
   ことを特徴とする構造化文書管理システム。
2. 前記クライアントからの構造化文書管理ブロック作成要求に応じ、当該要求によって指定される構造化文書管理ブロックを前記データベース内に作成する構造化文書管理ブロック作成手段を更に具備することを特徴とする請求項１記載の構造化文書データベースシステム。
3. 前記格納処理手段は、前記構造化文書格納要求によって指定された構造化文書の根となる要素に対応する要素定義情報が検索されなかった場合、当該指定された構造化文書を、前記データベース内に作成されている、当該指定された構造化文書の根となる要素の親要素に対応する前記構造化文書管理ブロックに格納するための処理を行うことを特徴とする請求項２記載の構造化文書データベースシステム。
4. 複数の要素を含む構造化文書が格納される構造化文書データベースを管理するデータベースサーバコンピュータであって、構造化文書に含まれる要素を、当該構造化文書において当該要素の子要素をなす当該要素とは別の要素によって構成される細分化された構造化文書の集合を管理するための構造化文書管理ブロックとして登録することを示す要素定義情報であって、前記構造化文書管理ブロックとして登録される要素を含む構造化文書における当該要素へのパスを表すパス情報を含む要素定義情報が記憶される要素定義情報記憶手段と、要素定義情報設定手段と、要素定義情報検索手段と、格納処理手段とを備えたデータベースサーバコンピュータに、
   クライアントからの要素定義要求に応じ、当該要求によって指定される要素を前記構造化文書管理ブロックとして登録することを示す要素定義情報を、前記要素定義情報設定手段が前記要素定義情報記憶手段に設定するステップと、
   前記クライアントからの構造化文書の格納を指定する構造化文書格納要求に応じ、前記要素定義情報検索手段が、前記要素定義情報記憶手段から、当該要求によって指定される構造化文書に含まれている要素に対応する要素定義情報を検索するステップと、
   前記構造化文書格納要求によって指定された構造化文書を、前記検索するステップでの検索結果に基づいて、前記構造化文書管理ブロックと細分化された構造化文書とに分割して前記データベースに格納するための構造化文書分割格納処理を前記格納処理手段が行うステップであって、前記構造化文書格納要求によって指定された構造化文書の根となる要素に対応する要素定義情報の検索を前記要素定義情報検索手段によって行わせ、前記要素定義情報検索手段によって前記要素定義情報が検索された場合、前記構造化文書格納要求によって指定された構造化文書から当該要素定義情報に対応する要素の子要素を細分化された構造化文書として順次取り出して、当該取り出された構造化文書の格納を指定する構造化文書格納要求を前記格納処理手段自身に対して与える動作を繰り返すことにより、前記構造化文書分割格納処理を再帰的に行うステップと
   を実行させるためのプログラム。

Images