JP4510041B2 - 文書検索システム及びプログラム - Google Patents

Description

本発明は、２次記憶装置の文書記憶領域に格納されている文書を文字列索引を用いて検索する文書検索システムに係り、特に文字列索引を構成するのに用いられる文字列を当該文字列索引に格納するのに好適な文書検索システム及びプログラムに関する。

一般に、データベース管理システム（ＤＢＭＳ）に代表される大規模なデータ検索システムでは、２次記憶装置（データベース）に格納されているデータの検索速度を向上させるために索引（インデックス）が使用される。索引とは、検索対象のデータから抽出される情報を検索に適したデータ構造で保持するものであり、データの検索を高速化する仕組みであるといえる。索引には幾つかの種類がある。索引は、検索対象データから抽出されるデータの種類によって分類されるのが一般的である。代表的な索引として、例えば数値索引及び文字列索引が知られている。

索引のデータ構造には、２次記憶装置（に確保されている索引記憶領域）に記憶された場合に効率的に参照や更新を行うのに適した構造が用いられる。このようなデータ構造として、例えばＢＴｒｅｅ（Ｂ木）が知られている。ＢＴｒｅｅのような索引のデータ構造では、例えば特許文献１に記載されているように、２次記憶装置への書き込み及び当該２次記憶装置からの読み出しが、ページと呼ばれる一定サイズのかたまりの単位で行われる。

一般に文字列索引では、当該索引に格納可能な文字列の長さ（格納可能文字列長）Ｌが予め指定される。格納可能文字列長は文字数で表される。データ検索システム（文書検索システム）は、文字列長がＬ以下のデータ（文書）については当該データ全体を索引に格納し、Ｌよりも文字列長が長いデータについては先頭のＬ文字までを索引に格納する。
特開２００４−３４１９２６号公報

上述のような文字列索引を適用する文書検索システムでは、文字列索引へ格納可能な文字列の長さ（格納可能文字列長）Ｌよりも長い文字列をキー（検索条件）として検索を行った場合、当該文字列索引だけでは検索条件に合致するデータを検索することができない。このような場合、文書検索システムは、検索対象のデータ自体を参照して最終的な判定を行う必要がある。つまり、文字列索引以外のデータを参照する必要がある。このため、従来の段書検索システムは、文字列索引だけで検索条件に合致するデータを検索することができない場合、リソース使用量や処理時間が増えてしまうという問題がある。

このような問題を緩和するために、格納可能文字列長Ｌを大きくすることが考えられる。ところが、格納可能文字列長Ｌを大きくすると、文字列索引自体のデータ量が増えて、当該文字列索引を格納するのに必要な２次記憶装置の記憶容量（リソース使用量）の増加を招く。つまり、検索高速化のためには格納可能文字列長Ｌを大きくしたいが、当該格納可能文字列長Ｌを大きくすると文字列索引に必要なリソース使用量が増加してしまう。

本発明は上記事情を考慮してなされたものでその目的は、文字列索引に格納される文字列の長さを、リソース使用量を増加させることなく実質的に増加することができる文書検索システム及びプログラムを提供することにある。

本発明の１つの観点によれば、文字列索引格納手段に格納された、一定の文字列数を上限とする単位に分割して管理される文字列索引であって、文書格納手段に格納される文書から抽出された文字列が、当該文書に対応付けて、且つ当該文字列を構成する文字の順序に基づいて順序付けされた配列で格納された文字列索引を利用して、文字列をキーとした文書検索を行う文書検索システムが提供される。このシステムは、前記単位毎に、前記文書格納手段に格納される文書から抽出された当該単位内に格納されるべき文字列の間で、先頭から共通する予め定められた一定文字数を上限とする文字列を共通部文字列として検出する共通部文字列検出手段と、前記検出された共通部文字列の文字列長を表す共通部文字列長情報を、当該共通部文字列が検出された前記単位に対応付けて前記文字列索引に格納して管理する共通部文字列長管理手段と、前記単位内に格納されるべき文字列のうち、先頭文字列については当該先頭文字列の先頭から前記一定文字数を上限とする文字列を前記単位内の該当位置に格納し、残りの文字列については前記検出された共通部文字列に後続する前記一定文字数を上限とする文字列を前記単位内の該当位置に格納する文字列処理手段と、前記単位内の先頭位置に格納されている文字列と当該単位に対応付けて前記文字列索引に格納されている共通部文字列長情報とに基づいて、当該共通部文字列長情報の示す前記共通部文字列を取得して、当該共通部文字列の後ろに当該単位内の前記先頭位置以外の位置に格納されている文字列を連結することにより、当該単位内の前記先頭位置以外の位置に本来格納されるべき文字列を復元して、文字列をキーとした文書検索を行う検索手段とを具備する。

本発明によれば、順序付けされた文字の順序に基づいて順序付けされた文字列の配列においては、隣接する文字列同士は文字列の先頭文字が一致する可能性が高いという性質があり、特に文字列数が増加するに従って、このような先頭文字が一致する文字列数が増加するだけでなく、文字列間で一致する文字数も増加する性質を利用して、文字列索引内の一定の単位毎に、当該単位内の先頭位置には、対応する文書から抽出された文字列の先頭から一定文字数を上限とする文字列を格納し、残りの位置には、当該単位内で共通の文字列（共通部文字列）を重複して格納せずに、当該共通の文字列に後続する一定文字数を上限とする文字列を格納することにより、文字列索引に必要なリソース使用量を抑制しながら、当該文字列索引により多くの文字を格納すること、つまり当該文字列索引に格納される文字列の実質的な長さを増加することが可能となり、文字列索引を利用した文書検索速度の向上を図ることができる。

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

データベースサーバ１０は、ハードディスクドライブのような２次記憶装置４０と接続されている。この２次記憶装置４０は、データベース管理プログラム４１及びデータベース４２を格納する。

データベース管理プログラム４１は、データベースサーバ１０によるデータベース４２の管理、及びクライアント端末からの検索要求に基づく検索処理（文書検索処理）に用いられる。本実施形態では、データベースサーバ１０によってデータベース管理システム５０が実現される。

データベース４２は、文書部４２１と索引部４２２とを含む。文書部４２１は、検索の対象となる複数の文書（電子化文書）を格納するのに用いられる記憶領域（文書記憶領域）である。文書は、文字列を含むデータである。索引部４２２は、文書部４２１に格納されている文書を検索するための文字列索引を格納するのに用いられる記憶領域（索引記憶領域）。この索引部４２２に、文字列索引に加えて数値索引が格納されても構わない。

図２は、本実施形態で適用される文字列索引のデータ構造例を示す。文字列索引に格納される文字列は、データベース４２の文書部４２１に格納される文書から抽出される。文字列を構成する文字間には、例えば対応する文字コードの大小に基づき順序関係が決められている。この文字間の順序関係に基づき、文字列の順序関係が決められる。本実施形態では以下に述べるように、このような順序関係に従って整列された文字列の並びにおいては、隣接する文字列同士は共通の文字列（開始文字列）で始まる確率が高いという性質を利用している。このような性質は、例えば電話帳における氏名の配列からも容易に理解される。

図２の例では、文字列索引はＢＴｒｅｅを用いて格納される。文字列索引内では、各文字列はその順序関係に従って昇順に整列される。この整列された文字列は、ページと呼ばれる複数の領域に分割して格納される。ページは、２次記憶装置４０から／への読み出し／書き込みの単位である。

各ページはヘッダのみ、またはヘッダ及び１個以上のレコードから構成される。ここで、ヘッダのみから構成されるページを、便宜的にヘッダ及び０個のレコードから構成されると表現するならば、ページはヘッダ及び０個以上のレコードから構成されると表現できる。

ヘッダは、当該ヘッダを含むページに関する情報（ヘッダ情報）を格納する。本実施形態では、ヘッダは、格納可能文字列長Ｌ、レコード数及び共通部文字列長Ｎの各情報を格納（設定）するフィールド、即ち格納可能文字列長フィールド２０１、レコード数フィールド２０２及び共通部文字列長フィールド２０３を含む。レコードは、文書位置、文字列長及び文字列の各情報を格納（設定）するフィールド、即ち文書位置フィールド２１１、文字列長フィールド２１２、及び文字列フィールド２１３を含む。レコードは固定長である。

格納可能文字列長Ｌは、対応する文字列索引（ページ）内のレコード１つに格納可能な文字列の最大文字数を示す。レコード数は、対応するページに格納されているレコードの数を示す。共通部文字列長Ｎは本実施形態に特徴的な情報であり、対応するページに格納されている各レコード内の文書位置の情報（文書位置フィールド２１１の情報）で示される文書（各レコードの指す文書）間で共通の開始文字列（共通部文字列）の文字数を示す。

文書位置は、レコード内で当該文書位置（の情報）と組をなす文字列を含む（文字列が使われている）文書及び当該文字列の文書内の位置を表す識別子である。ここでは簡単のため、文書位置が上記文字列を含む文書を特定する文書番号であるとする。文字列長（文字列長フィールド２１２に格納される文字列長）は、レコード内で当該文字列長と組をなす文書位置（の情報）で示される文書の文字数である。

文字列は、レコード内で当該文字列と組をなす文書位置（の情報）で示される文書の例えば先頭からＬ文字である。Ｌよりも短い文字列をレコード中に格納する場合には、当該レコード中の余っている領域に、文字が格納されていないことを示す特別な値が格納される。この特別な値を終端文字と呼ぶ。ここでは、レコード中の上記余っている領域に、その領域に対応する文字数分の終端文字が格納される。

文字列索引を用いた検索処理においては、検索条件（キー）となる文字列（検索条件文字列）の文字列長がＬ以下であれば、文字列索引を用いて検索条件文字列と各レコード内の文字列とを比較するだけで、目的の検索条件文字列で始まる文書の文書位置を特定することができる。

一方、検索条件文字列の文字列長がＬを超えている場合、従来技術では、文字列索引を用いるだけでは、検索条件文字列のうちの先頭からのＬ文字で始まる文書の文書位置しか特定できない。このため従来技術では、特定された文書位置で示される文書と検索条件文字列とを比較することで、当該文書が検索条件文字列で始まるか否かを判定する必要がある。つまり従来技術では、文字列索引を用いるだけでは目的の文書の文書位置の候補しか求めることができず、最終判定には文字列索引の文書位置で示される文書の内容を参照する必要がある。したがって従来技術では、文字列索引に加えて文書を参照する分だけ処理時間が長くなる。

これに対して本実施形態では、共通部文字列長Ｎの適用により、後述するように格納可能文字列長Ｌを増やすことなく、つまり文字列索引に文字列を格納するのに必要なリソース使用量を増やすことなく、文字列索引に格納される文字列の文字数を実質的（等価的）にＮ文字増やすことができる。これにより、検索条件文字列の文字列長がＬ＋Ｎまでは、文字列索引を用いるだけで目的の文書の文書位置を特定することが可能となる。

ＢＴｒｅｅでは、各ページ（または各ページの格納場所を示す情報）は木構造の葉をなしており、木構造の索引によって管理される。このため、データベース４２の文書部４２１に格納される文書を指すレコードを格納するのに用いられるページは、周知のように、ＢＴｒｅｅの木構造を、当該木構造の最上位の索引（ルート索引）から、索引（文字列）と文書の内容（文字列）との間の順序関係に基づいて辿ることにより決定することができる。

図３Ａは図１に示されるデータベース管理システム５０の機能構成を示すブロック図である。データベース管理システム５０は、文書格納処理部５１、文字列格納処理部５２、検索処理部５３、要求処理部５４及びデータベース操作部５５の各処理部を含む。これらの各部５１乃至５５は、図１のデータベースサーバ１０が２次記憶装置４０に格納されているデータベース管理プログラム４１を読み込んで実行することにより実現される。このプログラム４１は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム４１が、ネットワーク３０を介してデータベースサーバ１０にダウンロードされても構わない。

文書格納処理部５１は、クライアント端末２０からの文書格納要求に応じてデータベース４２の文書部４２１に文書を格納するための処理を行う。文字列格納処理部５２は、データベース４２の索引部４２２に構築（格納）されている索引（文字列索引）に、文書部４２１に格納される文書を検索するのに用いられる文字列（索引文字列）を格納（設定）するための処理を主として行う。

検索部５３は、クライアント端末２０からの検索要求（問い合わせ）に応じて、当該検索要求（問い合わせ）で指定された検索条件（キーワード）を含む文書（の位置）を、索引部４２２に格納されている文字列索引に基づいて検索する。

要求処理部５４は、クライアント端末２０からの各種の要求（コマンド）を解釈し、当該要求を文書格納処理部５１、文字列格納処理部５２または検索部５３に送出する。データベース操作部５５は、文書格納処理部５１、文字列格納処理部５２及び検索部５３がデータベース４２にアクセスするのを可能とするインタフェースとして機能する。但し、以下では説明の簡略化のために、文書格納処理部５１、文字列格納処理部５２及び検索部５３が直接データベース４２にアクセスするものとする。

データベース管理システム５０は文書検索処理機能を有している点で、文書検索システムであるといえる。

図３Ｂは、図３Ａに示される文字列格納処理部５２の構成を示すブロック図である。文字列格納処理部５２は、文字列順序判定部６１、ヘッダ処理部６２、レコード処理部６３、共通部文字列検出部６４及び文書読込部６５を含む。

文字列順序判定部６１は、文書格納処理部５１によってデータベース４２の文書部４２１に文書が格納される際に、当該文書から抽出された当該文書を検索するのに用いられる文字列（索引文字列）と、既に文字列索引に格納されている文字列との間の順序関係を、当該両文字列を構成する文字の間の順序関係に基づいて判定する。

ヘッダ処理部６２は、レコードの追加（挿入）／レコードの削除時に当該レコードに対応するページのヘッダを処理する。ヘッダ処理部６２は、共通部文字列長管理部６２０を含む。共通部文字列長管理部６２０は、各ページのヘッダに含まれている共通部文字列長フィールド２０３の値（共通部文字列長）を管理する。

共通部文字列長管理部６２０は、レコード処理部６３によるレコードの挿入／削除時に、共通部文字列検出部６４による共通部文字列長検出に応じて当該レコードに対応するページのヘッダに含まれている共通部文字列長フィールド２０３の値（共通部文字列長）を変更する。共通部文字列長管理部６２０は、共通部文字列長減少部６２１と共通部文字列長増加部６２２とを含む。共通部文字列長減少部６２１は、レコード処理部６３（レコード挿入部６３１）によるレコードの挿入時に共通部文字列長を減少変更する。共通部文字列長増加部６２２は、レコード処理部６３（レコード削除部６３２）によるレコードの削除時に共通部文字列長を増加変更する。

レコード処理部６３は、レコードを追加（挿入）する処理（レコード挿入処理）、レコードを削除する処理（レコード削除処理）、及びレコードの追加／削除に伴って既登録のレコードの文字列フィールド２１３の値（文字列）を変更する処理（文字列変更処理）を実行するための文字列処理手段として機能する。レコード処理部６３は、レコード挿入処理を実行するレコード挿入部６３１とレコード削除処理を実行するレコード削除部６３２と文字列変更処理を実行する文字列変更部６３３とを含む。

共通部文字列検出部６４はレコード処理部６３によるレコード挿入／削除に応じて前記共通部文字列を検出する。文書読込部６５は、既登録レコードの文字列フィールド２１３の値を変更する必要がある場合に、当該既登録レコードの文書位置フィールド２１１によって指定される文書（つまり既登録レコードが指す文書）をデータベース４２の文書部４２１から読み込む。文字列フィールド２１３の値の変更が必要な既登録レコードは、後述するように、レコード挿入部６３１による先頭レコード位置に新規レコードが挿入（追加）される場合の、当該先頭レコード位置の旧レコード（レコード０）である。文字列フィールド２１３の値の変更が必要な既登録レコードはまた、レコード削除部６３２によって削除されるレコードに対応するページ内の残りのレコードのうち、共通部文字列長増加部６２２による増加前の共通部文字列長と文字列フィールド２１３に格納されている文字列の長さとを加えた長さが文字列長フィールド２１２の示す文字列長より短いレコードである。

次に、データベース管理システム５０において、データベース４２へ／からの文書の格納（追加）／削除時に実行される、文字列索引内のあるページＰを対象とする文字列格納（追加）／削除処理について、図４に示すページＰの状態遷移図を参照して説明する。なお、図４（ａ）に、ページＰにおけるヘッダ及びレコードのフォーマットを示す。

まず、時刻ｔ０おいて、文書番号が「０」で内容が「ＡＢＣＤＥ」という１個目の文書がデータベース４２の文書部４２１に格納（登録）されたものとする。この場合、レコード数は１個であることから、図４（ｂ）に示すように、ページＰのヘッダ内のレコード数フィールド２０２に「１」が格納される。

本実施形態では、格納可能文字列長Ｌが「３」である場合を前提としているものとする。この場合、図４（ｂ）に示すように、ページＰのヘッダ内の格納可能文字列長」フィールド２０１には「３」が格納される。

また、ページＰ内のｉ番目（ｉ＝０，１，２…）のレコード位置に格納されるレコードをレコードｉと表現すると、文書番号０の文書に対応するレコードは、図４（ｂ）に示すように、ページＰの先頭レコード位置（０番目のレコード位置）にレコード０として格納される。レコード０の文字位置フィールド２１１には、当該レコード０に対応する文書の文書番号である「０」が格納される。また、レコード０の文字列長フィールド２１２及び文字列フィールド２１３には、それぞれ、文書番号０の文書の文字数である「５」及び当該文書の先頭から格納可能文字列長Ｌで指定される文字数（３文字）の文字列「ＡＢＣ」が格納される。

時刻ｔ０ではページＰ内のレコード数はレコード０の１個のみであり、ページＰ内のレコード数がレコード０の１個である間、当該レコード０の文字列フィールド２１３の値「ＡＢＣ」（つまりレコード０に格納されている文字列「ＡＢＣ」）全体がページＰ内の全レコード（に対応する文書）の間に共通の文字列（共通部文字列）となる。このため、ページＰのヘッダの共通部文字列長フィールド２０３には、図４（ｂ）に示すように、共通部文字列長Ｎとして「３」が格納される。このように、ページＰにおけるレコード０（先頭レコード）の文字列フィールド２１３には、文書内容の一部を格納するという他のレコードと同様の役割に加え、共通部文字列を保持するという役割がある。なお、以降の説明では、レコードの文字列フィールド２１３の値、つまりレコード（の文字列フィールド２１３）に格納されている文字列を、レコードの文字列と表現することもある。

次に、時刻ｔ０より後の時刻ｔ１において、文書番号が「１」で内容が「ＡＢＣＤＥＦ」という２個目の文書がデータベース４２の文書部４２１に格納されたものとする。この文書番号１の文書に対応するレコードは、図４（ｃ）に示すようにページＰ内のレコード０の次のレコード位置（１番目のレコード位置）にレコード１として格納（挿入）される。このレコード挿入位置は、詳細を後述する文字列順序判定処理によって決定される。

なお、文書番号１の文書の内容が例えば「ＡＢＣＤ」であるならば、文字列順序判定処理により、ページＰ内のレコードの配列は、図４（ｃ）とは逆となる。即ち、文書番号０の文書に対応するレコード０は先頭レコード位置（０番目のレコード位置）から次のレコード位置（１番目のレコード位置）に移動され、文書番号１の文書に対応するレコードがレコード０として先頭レコード位置に格納される。

時刻ｔ１ではページＰ内のレコード数はレコード０及びレコード１の２個となる。この場合、図４（ｃ）に示すように、ページＰのヘッダ内のレコード数フィールド２０２の値が「１」から「２」に変更される。

レコード１の文字列フィールド２１３には、従来技術であれば、当該レコード１に対応する文書の内容のうちの先頭３文字である「ＡＢＣ」が格納されることになる。しかし本実施形態では、先頭レコードであるレコード０の文字列「ＡＢＣ」と共通部文字列長フィールド２０３の値「３」とから現時点の共通部文字列が「ＡＢＣ」であることがわかるので、以下に述べる処理の実行によって、共通部文字列「ＡＢＣ」に後続する３文字「ＤＥＦ」が、レコード１の文字列フィールド２１３に格納される。

まず、現時点の共通部文字列「ＡＢＣ」とレコード１の文書位置フィールド２１１が指す文書番号１の文書（レコード１に対応する文書）の内容「ＡＢＣＤＥＦ」とが先頭文字から順に比較される。この比較により、新たな共通部文字列は現時点の共通部文字列と同じ「ＡＢＣ」であると認識される。したがって、ページＰのヘッダの共通部文字列長フィールド２０３の値は、図４（ｃ）に示されるように「３」のままである。

一方、レコード１の文書位置フィールド２１１及び文字列長フィールド２１２には、それぞれ、当該レコード１に対応する文書の文書番号である「１」及び当該文書の文字数である「６」が格納される。また、レコード１の文字列フィールド２１３には、レコード１に対応する文書から共通部文字列（共通文字列）である「ＡＢＣ」を取り除いて残った部分の先頭３文字である「ＤＥＦ」、つまり共通部文字列「ＡＢＣ」に後続する、格納可能文字列長Ｌで指定される文字数（３文字）の文字列「ＤＥＦ」が格納される。

ここで、レコード１の文字列「ＤＥＦ」は、当該レコード１に対応する文書の先頭から６（Ｌ＋Ｎ＝３＋３）文字の文字列のうちの共通部文字列「ＡＢＣ」が省略された文字列であるといえる。この共通部文字列「ＡＢＣ」は、上記したように、レコード０の文字列「ＡＢＣ」と共通部文字列長フィールド２０３の値「３」とから特定される。

検索部５３は、共通部文字列「ＡＢＣ」とレコード１の文字列「ＤＥＦ」（文字列フィールド２１３の値）とを連結することにより、当該レコード１に対応する文書の先頭から６文字「ＡＢＣＤＥＦ」を復元して、当該復元された文字列を用いて、当該レコード１に対応する文書（の位置）を検索することができる。よって、レコード１（を含むページＰ）は、格納可能文字列長Ｌ（＝３）により当該レコード１（の文字列フィールド２１３）に格納される文字列が３文字に制限されながら、当該レコード１に対応する文書を検索するのに用いることが可能な文字列（実効文字列）として、当該文書の先頭から共通部文字列長Ｎ（＝３）だけ拡張された６文字の文字列「ＡＢＣＤＥＦ」を実質的に保持しているといえる。

次に、時刻ｔ１より後の時刻ｔ２において、文書番号が「２」で内容が「ＡＢＧ」という３個目の文書がデータベース４２の文書部４２１に格納されたものとする。この文書番号２の文書に対応するレコードは、図４（ｄ）に示すようにページＰ内のレコード１の次のレコード位置（２番目のレコード位置）にレコード２として格納（挿入）される。このレコード挿入位置は、文字列順序判定処理によって決定される。

時刻ｔ２ではページＰ内のレコード数はレコード０、レコード１及びレコード２の３個となる。この場合、図１２（ｄ）に示すように、ページＰのヘッダ内のレコード数フィールド２０２の値が「２」から「３」に変更される。

また時刻ｔ２では、先頭レコードであるレコード０の文字列ＡＢＣと共通部文字列長フィールド２０３の値「３」とから現時点の共通部文字列が「ＡＢＣ」であることがわかる。そこで、現時点の共通部文字列「ＡＢＣ」とレコード２に対応する文書（文書番号２の文書）の内容「ＡＢＧ」とが先頭文字から順に比較される。この比較により、新たな共通部文字列は「ＡＢ」であると認識される。したがって、ページＰのヘッダの共通部文字列長フィールド２０３の値は、図４（ｄ）に示されるように「３」から「２」に変更される。明らかなように、格納可能文字列長Ｌと共通部文字列長Ｎとの間には、Ｎ≦Ｌの関係が成立する。

一方、レコード２の文書位置フィールド２１１及び文字列長フィールド２１２には、それぞれ、当該レコード２に対応する文書の文書番号である「２」及び当該文書の文字数である「３」が、図４（ｄ）に示されるように格納される。ここで、レコード２に対応する文書から共通部文字列である「ＡＢ」を取り除いて残った部分は「Ｇ」の１文字であり、格納可能文字列長Ｌで指定される文字数（３文字）より少ない。このため、この「Ｇ」１文字及び終端文字２文字がレコード２の文字列フィールド２１３に格納される。なお、図４（ｄ）では、終端文字は省略されている。

上述のように、時刻ｔ２では、共通部文字列長Ｎが「３」から「２」に１減少する。この時点において、レコード１の文字列フィールド２１３の値は、当該レコード１に対応する文書の先頭からの文字列のうち旧共通部文字列長である３文字「ＡＢＣ」に後続する３文字「ＤＥＦ」である。このレコード１の文字列フィールド２１３の値が、共通部文字列長Ｎが１減少されるのに応じて、レコード１に対応する文書の先頭からの文字列のうち新共通部文字列長である２文字「ＡＢ」に後続する３文字「ＣＤＥ」に変更される。この変更後の文字列「ＣＤＥ」は、データベース４２の文書部４２１に格納されている、レコード１に対応する文書を参照することなく、旧共通部文字列「ＡＢＣ」及びレコード１の旧文字列（文字列フィールド２１３の旧値）「ＤＥＦ」から簡単に特定できる。

次に、時刻ｔ２より後の時刻ｔ３において、文書番号が「２」の文書が削除され、図４（ｅ）に示すようにレコード２が削除されたものとする。この場合、ページＰ内のレコード数はレコード０及びレコード１の２個となり、ページＰのヘッダ内のレコード数フィールド２０２の値が「３」から「２」に変更される。

ここで、ページＰ内に残されているレコード０及びレコード１各々の文字列フィールド２１３の値を比較することにより、図４（ｅ）に示すように、共通部文字列長フィールド２０３の値を「３」に戻すことができる。この仕組みについては後述する。

共通部文字列長が増加した場合、ページＰ内のレコード０を除くレコード（ここではレコード１）の文字列フィールド２１３に格納されている文字列が左にシフトされる。シフト数は、共通部文字列長の増加文字数、つまり新共通部文字列長「３」と旧共通部文字列長「２」との差である１文字である。図４（ｅ）には、レコード１の文字列フィールド２１３の内容が１文字だけ左シフトされた状態が示されている。このシフトにより空きとなった文字列フィールド２１３の領域（ここでは１文字分の領域）には、終端文字が格納される。

また、データベース４２の文書部４２１からレコード１に対応する文書の内容「ＡＢＣＤＥＦ」を読み込むならば、上述の空きとなった領域に当該文書の先頭から６文字目の文字「Ｆ」を格納することもできる。これによりページＰ内の状態を時刻ｔ１と全く同じ状態に復元することができる。

上述のように、文書を削除した場合には、共通部文字列長を増加させる処理、更には共通部文字列長を増加させたことに伴って生じた文字列フィールド２１３内の空き領域へ該当する文書内の文字列を格納する処理を行うことができる。これらの処理により、文書の検索に用いることが可能な文字列の長さを格納可能文字列長Ｌよりも増やせるため、検索部５３による当該文字列をキーワードとする文書検索速度が一層向上する。但し、これらの処理は、実行されなくてもページＰ内に矛盾は生じないので、省略可能である。つまり、文書検索速度を優先させる場合にのみ、これらの処理を実行しても良い。

以上のように処理された文字列索引のページＰにおいては、レコード０の文字列フィールド２１３の先頭からＮ（Ｎ≦Ｌ）文字の文字列（つまり共通部文字列）と、他のレコードｉ（ｉは０より大きい整数）の文字列フィールド２１３に格納されている最大Ｌ文字の文字列とを連結することにより、最低で当該レコードｉに対応する文書の先頭からＬ文字の文字列、最高で当該文書の先頭からＬ×２文字の文字列を、当該ページＰ内の情報だけで復元することができる。つまりレコードｉ（を含むページＰ）は、最高で当該レコードｉに対応する文書の先頭Ｌ×２文字までの情報を保持することができるといえる。これにより、最大で長さがＬ×２文字までの検索条件文字列での検索を文字列索引内だけで完結させることができる。よって本実施形態においては、従来技術と比較して、格納可能文字列長Ｌよりも長い文字列をキーとする検索時の文書参照回数が削減して検索速度が向上する。

次に、文字列順序判定部６１による文字列順序判定処理について、図５のフローチャートを参照して説明する。まず、順序判定の対象となる文字列が文字列＃１及び＃２であり、当該文字列＃１及び＃２の長さ（文字数）が、それぞれＬ１及びＬ２であるものとする。また、Ｌ１及びＬ２のうち小さい方の値をｍｉｎ（Ｌ１，Ｌ２）で表すものとする。明らかなように、Ｌ１＝Ｌ２の場合には、Ｌ１及びＬ２のいずれをｍｉｎ（Ｌ１，Ｌ２）で表しても構わない。

文字列順序判定部６１は、変数Ｌｋにｍｉｎ（Ｌ１，Ｌ２）を代入すると共に、変数ｉを初期値１に設定する（ステップＳ１）。次に文字列順序判定部６１は、Ｌｋがｉ以上であるかを判定する（ステップＳ２）。もし、Ｌｋがｉ以上である場合、文字列順序判定部６１は文字列＃１のｉ文字目（ｉ番目の文字）と文字列＃２のｉ文字目（ｉ番目の文字）との間の順序関係を、次のように判定する。

まず文字列順序判定部６１は、例えば文字列＃１のｉ文字目の順序が文字列＃２のｉ文字目よりも前であるか（文字列＃１のｉ文字目＜文字列＃２のｉ文字目）を判定する（ステップＳ３）。一般に文字列を表現するのに用いられる文字（文字コード）の間には、例えば文字コードの大小に基づく順序関係が予め定められている。このため、ステップＳ３の判定は可能である。

もし、文字列＃１のｉ文字目の順序が文字列＃２のｉ文字目り文字よりも前でないならば（ステップＳ３）、文字列順序判定部６１は、文字列＃１のｉ文字目の順序が文字列＃２のｉ文字目よりも後であるか（文字列＃１のｉ文字目＞文字列＃２のｉ文字目）を判定する（ステップＳ４）。

もし、文字列＃１のｉ文字目の順序が文字列＃２のｉ文字目よりも後でないならば（ステップＳ４）、つまり文字列＃１のｉ文字目と文字列＃２のｉ文字目とが同一順序ならば、文字列順序判定部６１は、変数ｉを１増加して（ステップＳ５）、ステップＳ２に戻る。

一方、文字列＃１のｉ文字目の順序が文字列＃２のｉ文字目よりも前であるならば（ステップＳ３）、文字列順序判定部６１は、文字列＃１の順序が文字列＃２よりも前である（文字列＃１＜文字列＃２）と判定する（ステップＳ６）。

また、文字列＃１のｉ文字目の順序が文字列＃２のｉ文字目よりも後であるならば（ステップＳ４）、文字列順序判定部６１は、文字列＃１の順序が文字列＃２よりも後である（文字列＃１＞文字列＃２）と判定する（ステップＳ７）。

次に、ステップＳ２において変数ｉがＬｋ以下でないと判定されたならば、文字列順序判定部６１は、文字列＃１及び＃２のｉ文字目同士が先頭からＬ文字目まで全て同一順序であると判定する。この場合、文字列順序判定部６１は、Ｌ１とＬ２とが等しいかを判定する（ステップＳ８）。

もし、Ｌ１とＬ２とが等しいならば、文字列順序判定部６１は、文字列＃１及び文字列＃２は同一順序である（文字列＃１＝文字列＃２）と判定する（ステップＳ９）。これに対し、Ｌ１とＬ２とが等しくないならば、文字列順序判定部６１はＬ１とＬ２との大小を判定する（ステップＳ１０）。

もし、Ｌ１の方が小さいならば、文字列順序判定部６１は文字列＃１の順序が文字列＃２よりも前であると判定する（ステップＳ６）。これに対してＬ１の方が小さくないならば、つまりＬ２の方が小さいならば、文字列順序判定部６１は文字列＃１の順序が文字列＃２よりも後であると判定する（ステップＳ７）。

文字列順序判定部６１は、上述の順序判定を、データベース４２の文書部４２１に文書が格納される際に、当該文書の文字列とページＰ内のレコードの文字列との間で、例えばページＰ内の先頭レコードから順に実行する。これにより、文書部４２１に格納される文書を指す新規レコードの挿入位置を決定することができる。なお、文書の文字列との間の順序判定に用いられるページＰ内のレコードの順番を例えば２分探索法によって決定することも可能である。この２分探索法は、順序判定を効率的に行うための手法として従来から良く知られているため、説明を省略する。

次に、クライアント端末２０からの要求に応じて、データベース管理システム５０内の文書格納処理部５１がデータベース４２の文書部４２１に新たに文書（新規文書）を格納（追加）する場合に、文字列格納処理部５２によって実行される文書格納時処理について、図６のフローチャートを参照して説明する。

まず、文字列格納処理部５２内の文字列順序判定部６１は、データベース４２の索引部４２２に格納されている文字列索引内のいずれのページを対象として文書格納時処理を行うかを従来技術と同様に決定する。ここでは、新規文書の先頭の文字列に最も近い順序関係の文字列を先頭文字列とする文書を指すレコードが格納されるページ、例えばページＰが文書格納時処理の対象となるページとして決定されたものとする。

文字列格納処理部５２のヘッダ処理部６２は、ページＰのヘッダのレコード数フィールド２０２を参照して、レコード数が「０」であるかを判定する（ステップＳ１１）。

もし、レコード数が「０」である場合、ヘッダ処理部６２はページＰのヘッダの共通部文字列長フィールド２０３の新たな値（共通部文字列長）を示す変数Ｎ_newに、格納可能文字列長Ｌ及び新規文書の文字数のうち小さい方の値ｍｉｎ（Ｌ，新規文書の文字数）を代入する（ステップＳ１２）。この値ｍｉｎ（Ｌ，新規文書の文字数）は、共通部文字列検出部６４によって検出される。

レコード挿入部６３１は、新規文書に対応する（新規文書を指す）レコードをページＰに挿入するためのレコード挿入処理（ステップＳ１３）を実行する。図４の例では、文書番号が「０」の文書＃０の格納時に、ステップＳ１２及びＳ１３が実行される。ステップＳ１３（レコード挿入処理）の詳細は後述する。

一方、レコード数が「０」でない場合、つまりページＰに１つ以上のレコードが格納されている場合、共通部文字列検出部６４はページＰ内のレコード０（先頭レコード）の文字列（文字列フィールド２１３の内容）と新規文書の先頭からＬ文字の文字列とを先頭文字から順に比較することにより、先頭から共通する文字列部分の文字数を求め、その文字数をＮ_new（変更後の共通部文字列長）とする（ステップＳ１４）。次に共通部文字列検出部６４は、Ｎ_newが、ページＰのヘッダの共通部文字列長フィールド２０３の現在の値（つまり変更前の共通部文字列長）Ｎ_old以上であるかを判定する（ステップＳ１５）。

もし、Ｎ_newがＮ_old以上である場合、共通部文字列検出部６４は、Ｎ_newへＮ_oldを代入する（ステップＳ１６）。即ち共通部文字列検出部６４は、共通部文字列長フィールド２０３の現在の値（旧値）Ｎ_oldをそのまま新値Ｎ_newとする。これに対し、Ｎ_newがＮ_old未満である場合、共通部文字列長管理部６２０内の共通部文字列長減少部６２１は後述する共通部文字列長減少処理（ステップＳ１７）を実行する。

ステップＳ１６及びＳ１７のいずれが実行された場合にも、レコード処理部６３のレコード挿入部６３１は、ステップＳ１２が実行された場合と同様にレコード挿入処理（ステップＳ１３）を実行する。図４の例では、文書番号が「１」の文書の格納時には、ステップＳ１６及びＳ１３が実行されて、文書番号が「２」の文書の格納時には、ステップＳ１７及びＳ１３が実行される。

次に、レコード挿入処理（ステップＳ１３）の詳細な手順について、図７のフローチャートを参照して説明する。
まず本実施形態では、図１に示されるデータベースサーバ１０が有する主メモリのようなメモリ（図示せず）内に、新規レコード用の一時領域が確保されているものとする。この一時領域は、文書位置フィールド２１１、文字列長フィールド２１２及び文字列フィールド２１３を有する。

レコード挿入部６３１は、新規レコード用一時領域の文字列長フィールド２１２及び文書位置フィールド２１１に、それぞれ、新規文書の文字数及び文書番号を格納する（ステップＳ２１）。次にレコード挿入部６３１は、新規レコードの挿入位置（挿入レコード位置）が０番目のレコード位置（先頭レコード位置）であるかを判定する（ステップＳ２２）。ページＰに格納されているレコードの数が０の場合、つまりページＰのヘッダ部のレコード数フィールド２０２の値が０の場合、新規レコードの挿入位置は０番目のレコード位置となる。これに対し、レコード数が０を超えている場合（つまりページＰに既に１つ以上のレコードが格納されている場合）の新規レコードの挿入位置は、文字列順序判定部６１による順序判定処理により決定される。

もし、新規レコードの挿入位置が０番目のレコード位置（先頭レコード位置）の場合（ステップＳ２２）、レコード挿入部６３１は、新規レコード用一時領域の文字列フィールド２１３に新規文書の先頭からＬ文字の文字列を格納する（ステップＳ２３）。このＬの値は、ページＰのヘッダ部の格納可能文字列長フィールド２０１の値（格納可能文字列長）によって示される。

次にレコード挿入部６３１は、現在のレコード数が０を超えているかを判定する（ステップＳ２４）。もし、現在のレコード数が０を超えていない場合、つまり０の場合、レコード挿入部６３１はページＰのヘッダのレコード数フィールド２０２の値を１増加して（ステップＳ３０）、レコード挿入処理を終了する。図４の例では、文書番号０の文書の格納時には、上記ステップＳ２１乃至Ｓ２３及びＳ３０が実行されて、０番目のレコード位置に新規レコードがレコード０として格納される。

これに対し、現在のレコード数が０を超えている場合、つまり新規レコードが現在のレコード０（旧レコード０）に代わって新レコード０となる場合（ステップＳ２４）、レコード挿入部６３１は旧レコード０の文字列長（文字列長フィールド２１２の値）がＬを超えているかを判定する（ステップＳ２５）。

もし、旧レコード０の文字列長がＬを超えているならば（ステップＳ２５）、レコード挿入部６３１は文書読込部６５及び文字列変更部６３３を起動する。文書読込部６５は、旧レコード０の文書位置フィールド２１１で指定される文書番号の文書、つまり旧レコード０が指す文書（旧レコード０に対応する文書）の内容をデータベース４２の文書部４２１から読み込む（ステップＳ２６ａ）。すると文字列変更部６３３は、旧レコード０の文字列フィールド２１３に、文書読込部６５によって読み込まれた文書の先頭からＮ_new＋１文字目以降のＬ文字を格納する（ステップＳ２６ｂ）。ここで、読み込まれた文書の先頭からＮ_new＋１文字目以降の文字数がＬ文字に満たない場合、旧レコード０の文字列フィールド２１３に生じる空き領域に終端文字が格納される。

これに対し、旧レコード０の文字列長がＬを超えていないならば（ステップＳ２５）、レコード挿入部６３１は文字列変更部６３３のみを起動する。文字列変更部６３３は、旧レコード０の文字列フィールド２１３の内容を左へＮ_new文字だけシフトし、その右側に生じた空き領域に終端文字を格納する（ステップＳ２７）。

一方、ステップＳ２２で新規レコードの挿入位置が０番目のレコード位置（先頭レコード位置）でないと判定された場合、レコード挿入部６３１は新規レコード用一時領域の文字列フィールド２１３に、新規文書の先頭からＮ_new＋１文字目以降のＬ文字を格納する（ステップＳ２３）。

レコード挿入部６３１は、ステップＳ２６ｂ、ステップＳ２７及びステップＳ２８のいずれが実行された場合にも、ステップＳ２９に進む。このステップＳ２９においてレコード挿入部６３１は、ページＰにおける新規レコードの挿入位置以降のレコードを１つずつ次のレコード位置へ移動し、当該挿入位置へ上記一時領域内の文書位置フィールド２１１、文字列長フィールド２１２及び文字列フィールド２１３から構成される新規レコードを格納する。そしてレコード挿入部６３１は、ページＰのヘッダのレコード数フィールド２０２の値を１増加して（ステップＳ３０）、レコード挿入処理を終了する。

図４の例では、文書番号が「１」の文書及び文書番号が「２」の文書のそれぞれの格納時に、ステップＳ２１，Ｓ２２，Ｓ２８，Ｓ２９及びＳ３０が実行される。これにより、文書番号１の文書の格納時には、新規レコード１の文字列フィールド２１３に、当該文書の文字列「ＡＢＣＤＥＦ」におけるＮ_new＋１（＝３＋１＝４）文字目以降の文字列して、図４（ｃ）に示されるように「ＤＥＦ」が格納される。同様に文書番号２の文書の格納時には、新規レコード２の文字列フィールド２１３に、当該文書の文字列「ＡＢＧ」におけるＮ_new＋１（＝２＋１＝３）文字目以降の文字列して、図４（ｄ）に示されるように「Ｇ」が格納される。

次に、共通部文字列長減少処理（ステップＳ１７）の詳細な手順について、図８のフローチャートを参照して説明する。図４の例では、この共通部文字列長減少処理（ステップＳ１７）は、文書番号が「２」の文書の格納時に実行される。

まず共通部文字列長減少部６２１は、処理対象レコードの位置を表す変数ｉに初期値１を代入する（ステップＳ３１）。次に共通部文字列長減少部６２１は、変数ｉが、ページＰのヘッダのレコード数フィールド２０２の値、つまりレコード数よりも小さいかを判定する（ステップＳ３２）。

もし、変数ｉがレコード数よりも小さいならば、共通部文字列長減少部６２１はページＰには未処理のレコードが存在すると判定する。この場合、共通部文字列長減少部６２１は文字列変更部６３３を起動する。

すると文字列変更部６３３は、「Ｎ_old−Ｎ_new」の値を「ｄｉｆｆ」と表現するものとすると、ページＰ内のレコードｉ（ｉ番目のレコード）の文字列フィールド２１３の内容（つまりレコードｉの文字列）を右へｄｉｆｆ文字だけシフトする（ステップＳ３３）。本実施形態において、先頭レコードはレコード０（０番目のレコード）であり、ステップＳ３３の処理の対象外となる。

次に文字列変更部６３３は、レコードｉの文字列のシフトで生じた、当該レコードｉの文字列フィールド２１３の空き領域（ｄｉｆｆ文字分の空き領域）へ、レコード０の文字列フィールド２１３に格納されている文字列の先頭Ｎ_old文字のうちｄｉｆｆで示される文字数の終端側の文字を格納する（ステップＳ３４）。これにより、図４における文書番号２の文書の格納時の例では、レコード１（ｉ＝１）の文字列フィールド２１３の内容が、図４（ｃ）に示される「ＤＥＦ」から図４（ｄ）に示される「ＣＤＥ」に変更される。

すると共通部文字列長減少部６２１は変数ｉを１インクリメントして（ステップＳ３５）、ステップＳ３２の判定処理を再び実行する。共通部文字列長減少部６２１は、上記ステップＳ３３乃至Ｓ３５がページＰ内のレコード０を除く全レコードについて実行された結果、変数ｉがレコード数以上となると（ステップＳ３２）、ステップＳ３６に進む。

ステップＳ３６において共通部文字列長減少部６２１は、ページＰのヘッダの共通部文字列長フィールド２０３をＮ_newに変更する。図４における文書番号２の文書の格納時の例では、ヘッダの共通部文字列長フィールド２０３が、図４（ｃ）に示される「３」から図４（ｄ）に示される「２」に変更される。共通部文字列長減少部６２１は、ステップＳ３６を実行すると、共通部文字列長減少処理を終了する。

次に、文書の削除に伴って当該文書に対応するページＰ内のレコードを削除するレコード削除処理の手順について、図９のフローチャートを参照して説明する。このレコード削除処理は、図４の例では、文書番号が「２」の文書の削除時に実行される。

まずヘッダ処理部６２は、ページＰのヘッダのレコード数フィールド２０２の値を「１」減らす（ステップＳ４１）。レコード削除部６３２は、削除対象のレコードより後ろにレコードが存在するならば、当該後ろの全レコードを、それぞれ１つ前のレコード位置に移動する（ステップＳ４２）。これにより、削除対象のレコードが削除される。

なお、削除対象のレコードがレコード０の場合、レコード削除部６３２はレコード移動に先行して、文字列変更部６３３により文字列変更処理を行わせる。この文字列変更処理では、レコード０の文字列の先頭のＮ_old文字（現在の共通部文字列長Ｎによって示される数の文字）と次のレコード１の文字列とが連結される。そして、レコード１の文字列フィールド２１３の内容が、連結された文字列の先頭Ｌ文字に変更される。このＬ文字は、レコード１が指す文書の先頭からＬ文字の文字列を表す。

レコード削除部６３２はレコード移動（ステップＳ４２）を実行すると、共通部文字列検出部６４を起動する。すると共通部文字列検出部６４は、変更後の共通部文字列長を表す変数Ｎ_newにＬを代入すると共に、処理対象レコードの位置を表す変数ｉに初期値１を代入する（ステップＳ４３）。

次に共通部文字列検出部６４は、変数ｉが、ページＰのヘッダのレコード数フィールド２０２の値（つまりレコード数）よりも小さいかを判定する（ステップＳ４４）。もし、変数ｉがレコード数よりも小さいならば、共通部文字列検出部６４はページＰには未処理のレコードが存在すると判定する。この場合、共通部文字列検出部６４は、ページＰにおけるレコード０の文字列フィールド２１３の内容のうちＮ_old＋１文字目以降の文字列とレコードｉの文字列フィールド２１３の内容（レコードｉの文字列）とを比較することによって、両者の先頭部分の共通文字列の文字数を検出し、当該検出された文字数を「ｔｅｍｐ」とする（ステップＳ４５）。

次に共通部文字列検出部６４は、Ｎ_old＋ｔｅｍｐの値がＮ_newよりも小さいかを判定する（ステップＳ４６）。もし、Ｎ_old＋ｔｅｍｐの値がＮ_newよりも小さいならば、共通部文字列検出部６４は当該Ｎ_newをＮ_old＋ｔｅｍｐに代入する（ステップＳ４７）。そして共通部文字列検出部６４は、変数ｉを１インクリメントして（ステップＳ４８）、ステップＳ４４に戻る。これに対し、Ｎ_old＋ｔｅｍｐの値がＮ_new以上であるならば、共通部文字列検出部６４はステップＳ４７をスキップして、ステップＳ４８を実行する。

共通部文字列検出部６４は、上記ステップＳ４５以降の処理をページＰ内のレコード０を除く全レコードについて実行した結果、変数ｉがレコード数以上となると（ステップＳ４４）、ステップＳ４９に進む。このステップＳ４９において共通部文字列検出部６４は、現在のＮ_newがＮ_oldを超えているかを判定する。

レコード削除部６３２は、共通部文字列検出部６４によるステップＳ４９での判定の結果を受けて、Ｎ_newがＮ_oldを超えているならば共通部文字列長増加部６２２を起動する。すると共通部文字列長増加部６２２は、ページＰのヘッダの共通部文字列長フィールド２０３の値（共通部文字列長Ｎ）を増加するための共通部文字列長増加処理（ステップＳ５０）を実行する。これにより、レコード削除処理は終了する。これに対し、Ｎ_newがＮ_oldを超えていないならば、そのままレコード削除処理は終了する。

図４の例では、文書番号２の文書が削除された場合、レコード０のＮ_old＋１（＝２＋１＝３）文字目以降の文字列「Ｃ」とレコード１（ｉ＝１）の文字列「ＣＤＥ」との間の先頭部分の共通文字列の文字数ｔｅｍｐとして「１」が取得される（ステップＳ４６）。この場合、Ｎ_old＋ｔｅｍｐの値は「３」であり、その時点の変数Ｎ_newの値「Ｌ」、つまり「３」に一致する。したがって、ステップＳ４７の判定結果は「ＮＯ」となり、変数Ｎ_newの値は「３」に維持される。この場合、ステップＳ４９の判定結果は「ＹＥＳ」となって、共通部文字列長増加処理（ステップＳ５０）が実行され、後述するようにヘッダの文字列フィールド２１３がＮ_newの値「３」に変更される。

次に、共通部文字列長増加処理（ステップＳ５０）の詳細な手順について、図１０のフローチャートを参照して説明する。
まず共通部文字列長増加部６２２は、処理対象レコードの位置を表す変数ｉに初期値１を代入する（ステップＳ６１）。次に共通部文字列長増加部６２２は、変数ｉが、ページＰのヘッダのレコード数フィールド２０２の値（レコード数）よりも小さいかを判定する（ステップＳ６２）。

もし、変数ｉがレコード数よりも小さいならば（ステップＳ６２）、共通部文字列長増加部６２２はページＰには未処理のレコードが存在すると判定する。この場合、共通部文字列長増加部６２２は文字列変更部６３３を起動する。

すると文字列変更部６３３は、「Ｎ_new−Ｎ_old」の値を「ｄｉｆｆ」と表現するものとすると、ページＰ内のレコードｉの文字列フィールド２１３の内容（レコードｉの文字列）を左にｄｉｆｆ文字だけシフトする（ステップＳ６３）。このステップＳ６３において文字列変更部６３３は、レコードｉの文字列のシフトで生じた、当該レコードｉの文字列フィールド２１３の空き領域（ｄｉｆｆ文字分の空き領域）へｄｉｆｆで示される文字数の終端文字を格納する。

文字列変更部６３３はステップＳ６３を実行すると、共通部文字列長増加部６２２に制御を戻す。すると共通部文字列長増加部６２２は、変数ｉを１インクリメントして（ステップＳ６４）、ステップＳ６２に戻る。

共通部文字列長増加部６２２は、文字列変更部６３３による上記ステップＳ６３の処理がページＰ内のレコードｉを除く全レコードについて実行された結果、変数ｉがレコード数以上となると（ステップＳ６２）、ステップＳ６５に進む。このステップＳ６５において共通部文字列長増加部６２２は、ページＰのヘッダの共通部文字列長フィールド２０３をＮ_newに変更する。これにより、共通部文字列長増加処理は終了する。

図４の例では、文書番号２の文書が削除された場合、ｄｉｆｆの値は、Ｎ_new−Ｎ_old＝３−２＝１であることから、図４（ｄ）に示されるレコード１の文字列「ＣＤＥ」がｄｉｆｆで示される文字数、即ち１文字だけ、左へシフトされる（ステップＳ６３）。これにより、レコード１の文字列は、図４（ｅ）に示されるように「ＤＥ」となる。また、Ｎ_new＝３であることから、ヘッダの共通部文字列長フィールド２０３は、図４（ｅ）に示されるように「３」に変更される。

［第１の変形例］
次に、上記実施形態の第１の変形例について説明する。
上記実施形態では、共通部文字列長増加処理において、レコードｉの文字列の左シフトで生じた、当該レコードｉの文字列フィールド２１３の空き領域に終端文字が格納される。この場合、レコードｉは、最高でも当該レコードｉが指す文書の先頭からＬ×２文字までの情報を保持することができない。

そこで、レコードｉが、最高で当該レコードｉが指す文書の先頭からＬ×２文字までの情報を実質的に保持することを可能とするための、第１の変形例で適用される共通部文字列長増加処理について、図１１のフローチャートを参照して説明する。

まず共通部文字列長増加部６２２は、図１０のフローチャート中のステップＳ６１及びＳ６２とそれぞれ同一の処理ステップＳ７１及びＳ７２を実行する。ステップＳ７２において、変数ｉがレコード数よりも小さいと判定された場合、共通部文字列長増加部６２２は、レコードｉの文字列長フィールド２１２の値（つまりレコードｉが指す文書の文字数）が「現在の共通部文字列長（旧共通部文字列長）Ｎ_old＋レコードｉの文字列の長さ」を超えているかを判定する（ステップＳ７３）。

もし、レコードｉの文字列長フィールド２１２の値が「Ｎ_old＋レコードｉの文字列の長さ」を超えているならば（ステップＳ７３）、共通部文字列長増加部６２２は文書読込部６５及び文字列変更部６３３を起動する。文書読込部６５は、レコードｉの文書位置フィールド２１１が指す文書の内容をデータベース４２の文書部４２１から読み込む（ステップＳ７４）。すると文字列変更部６３３は、読み込まれた文書の内容のうち先頭Ｎ_new文字に後続する文字列の先頭Ｌ文字を、レコードｉの文字列フィールド２１３へ格納する（ステップＳ７５）。もし、先頭Ｎ_new文字に後続する文字列が格納可能文字列長Ｌに満たない場合、文字列変更部６３３は、文字列フィールド２１３の空き領域にその空き領域の文字数分の終端文字を格納する。

これに対し、レコードｉの文字列長フィールド２１２の値が「Ｎ_old＋レコードｉの文字列の長さ」を超えていないならば（ステップＳ７３）、共通部文字列長増加部６２２は文字列変更部６３３のみを起動する。文字列変更部６３３は、「Ｎ_new−Ｎ_old」の値を「ｄｉｆｆ」と表現するものとすると、図１０のフローチャートのステップＳ６３と同様に、レコードｉの文字列フィールド２１３の内容を左へｄｉｆｆ文字だけシフトし、その右側に生じた空き領域に終端文字を格納する（ステップＳ７６）。

文字列変更部６３３はステップＳ７５及びＳ７６のいずれを実行した場合にも、共通部文字列長増加部６２２に制御を戻す。すると共通部文字列長増加部６２２は変数ｉを１インクリメントして（ステップＳ７７）、ステップＳ７２に戻る。

共通部文字列長増加部６２２は、文字列変更部６３３による上記ステップＳ７５またはＳ７６の処理がページＰ内のレコード０を除く全レコードについて実行された結果、変数ｉがレコード数以上となると（ステップＳ７２）、ステップＳ７８に進む。このステップＳ７８において共通部文字列長増加部６２２は、ページＰのヘッダの共通部文字列長フィールド２０３の値をＮ_newに変更する。これにより、共通部文字列長増加処理は終了する。

このように上記実施形態の第１の変形例で適用される共通部文字列長増加処理では、レコードｉ（ｉ＞０）の文字列長フィールド２１２の値が「Ｎ_old＋レコードｉの文字列の長さ」を超えている場合、当該レコードｉが指す文書を読み込む必要はあるものの、レコードｉは、共通部文字列長フィールド２０３の示す共通部文字列長Ｎ（Ｎ_new）とレコード０の文字列とから特定される最大Ｌ文字の共通部文字列、及び当該レコードｉの最大Ｌ文字の文字列とから、最高で当該レコードｉが指す文書の先頭からＬ×２文字までの情報を格納可能文字列長Ｌを増やすことなく実質的に保持することが可能となる。これにより、検索部５３による文字列索引を利用した文書検索速度が一層向上する。

［第２の変形例］
次に、上記実施形態の第２の変形例について説明する。
上記実施形態では、共通部文字列は、同一ページ内の先頭のレコード０（が指す文書）の文字列を基準に、ヘッダの共通部文字列長フィールド２０３と当該レコード０の文字列フィールド２１３とによって、当該ページ内の全レコードに共通の文字列（共通部文字列）が管理される。この場合、ページ内の例えば１つのレコードが指す文書の文字列によって、共通部文字列長が制限される可能性がある。図４の例では、文書番号２の文書の格納時には、当該文書の文字列「ＡＢＧ」により、共通部文字列長が格納可能文字列長Ｌに一致する「３」から「２」に減少する。

第２の変形例の特徴は、同一ページ内で隣接するレコードｓ及びｓ＋１（ｓ＝０，１，２…）毎に、レコードｓ（が指す文書）の文字列を基準に、当該両レコードｓ及びｓ＋１に共通の文字列（共通部文字列）が管理される点にある。

図１２は、第２の変形例におけるページＰの状態遷移図を示す。図１２において、図４と同様の部分には同一符号を付してある。
図１２（ａ）は、ページＰにおけるヘッダ及びレコードのフォーマットを示す。図１２の例では、ヘッダには共通部文字列長フィールドが存在せず、各レコードに共通部文字列長フィールド２１０が設けられている。

図１２（ｂ）は、時刻ｔ０において、文書番号が「０」で内容が「ＡＢＣＤＥ」という１個目の文書がデータベース４２の文書部４２１に格納された場合の、ページＰの状態を示す。時刻ｔ０では、ページ内の０番目のレコード位置（先頭レコード位置）に文書番号０の文書を指すレコード０が格納される。この図１２（ｂ）の状態は、図４（ｂ）に示されるヘッダの共通部文字列長フィールド２０３の値が、レコード０の共通部文字列長フィールド２１０の値となった点を除いて、図４（ｂ）と同様である。

図１２（ｃ）は、時刻ｔ１において文書番号が「１」で内容が「ＡＢＣＤＥＦ」という２個目の文書が文書部４２１に格納された場合のページＰの状態を示す。時刻ｔ１では、ページ内の１番目のレコード位置に文書番号１の文書を指すレコード１が格納される。文書番号１の文書の先頭の５文字の文字列「ＡＢＣＤＥ」は、先行するレコード０が指す文書の文字列「ＡＢＣＤＥ」と一致する。しかし、この文字列「ＡＢＣＤＥ」の文字数５は格納可能文字列長Ｌ＝３を超えている。このため、レコード０の共通部文字列長フィールド２１０の値は格納可能文字列長Ｌ＝３に一致する「３」のままであり、レコード０の文字列フィールド２１３の値は「ＡＢＣ」のままである。一方、レコード１の文字列フィールド２１３には、文書番号１の文書の先頭からＬ＋１文字（つまり４文字）以降のＬ文字（３文字）「ＤＥＦ」が格納される。また、レコード１の共通部文字列長フィールド２１０には「３」が格納される。

図１２（ｃ）から明らかなように、レコード１は、先行するレコード０の共通部文字列長フィールド２１０の値「３」及び当該レコード０の文字列フィールド２１３の値「ＡＢＣ」から特定される共通部文字列「ＡＢＣ」と、当該レコード１の文字列フィールド２１３の値「ＤＥＦ」とにより、実質的に文字列「ＡＢＣＤＥＦ」を保持しているといえる。

なお、時刻ｔ０では、レコード０の共通部文字列長フィールド２１０に値を格納せずに、時刻ｔ１で、当該フィールド２１０に共通部文字列長として「３」を格納しても良い。

図１２（ｄ）は、上記実施形態と同様に、時刻ｔ２において文書番号が「２」で内容が「ＡＢＧ」という２個目の文書が文書部４２１に格納された場合のページＰの状態を示す。時刻ｔ２では、ページ内の２番目のレコード位置に文書番号２の文書を指すレコード２が格納される。

時刻ｔ２ではページＰ内のレコード数はレコード０、レコード１及びレコード２の３個となる。この場合、図１２（ｄ）に示すように、ページＰのヘッダ内のレコード数フィールド２０２の値が「２」から「３」に変更される。この時点において、レコード２に先行するレコード１は、前記したように文字列「ＡＢＣＤＥＦ」を実質的に保持している
そこで時刻ｔ２では、レコード２に先行するレコード１が実質的に保持している文字列「ＡＢＣＤＥＦ」と、当該レコード２に対応する文書（文書番号２の文書）の内容「ＡＢＧ」とが先頭文字から順に比較される。この比較により、隣接するレコード１及び２（がそれぞれ指す文書）に共通な文字列（共通部文字列）は「ＡＢ」であると認識される。この場合、レコード１の共通部文字列長フィールド２１０の値は図１２（ｄ）に示されるように「２」に変更される。このとき、レコード０の共通部文字列長フィールド２１０の値は変更されない点に注意する。なお、時刻ｔ１では、レコード１の共通部文字列長フィールド２１０に値を格納せずに、時刻ｔ２で、当該フィールド２１０に共通部文字列長として「２」を格納しても良い。

一方、レコード２の文書位置フィールド２１１及び文字列長フィールド２１２には、それぞれ、当該レコード２に対応する文書の文書番号である「２」及び当該文書の文字数である「３」が、図１２（ｄ）に示されるように格納される。またレコード２の文字列フィールド２１３には、先行するレコード１との間で共通する文字列（共通部文字列）「ＡＢ」に後続する１文字「Ｇ」が格納される。

上述したように第２の変形例では、隣接するレコード毎に共通部文字列（共通部文字列長）を管理することにより、新規レコードが挿入（追加）されても、既登録の隣接するレコードの共通部文字列に何ら影響を及ぼすことはない。このため第２の変形例によれば、上記実施形態に比べて、ページＰ内のレコード数−１だけ余分に共通部文字列長フィールドを必要とするものの、各レコードが実質的に保持可能な文字列長を増やすことが可能となる。特にレコード数が多い場合には、隣接するレコード、即ちレコードｓ及びレコードｓ＋１（ｓ＝０，１，２…）の間で、先頭１文字が共通の文字列数が増えるだけでなく、先頭２文字目以降が共通の文字列数も増え、つまり共通の文字列長も増加する可能性が高くなるため、この効果は大きくなる。しかも、各レコードに格納される文字列の長さは、格納可能文字列長Ｌを超えることはない。

なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係るクライアント−サーバシステムのハードウェア構成を示すブロック図。 同実施形態で適用される文字列索引のデータ構造例を示す図。 図１に示される文書検索システムの機能構成を示すブロック図。 図３Ａに示される文字列格納処理部５２の構成を示すブロック図。 同実施形態における文字列索引内のあるページを対象とする文字列格納／削除処理を説明するための当該ページの状態遷移図。 同実施形態における文字列順序判定処理の手順を示すフローチャート。 同実施形態において文字列索引のあるページに対して実行される文字列格納処理の手順を示すフローチャート。 上記文字列格納処理で実行されるレコード挿入処理の詳細な手順を示すフローチャート。 上記文字列格納処理で実行される共通部文字列長減少処理の詳細な手順を示すフローチャート。 同実施形態におけるレコード削除処理の手順を示すフローチャート。 上記レコード削除処理で実行される共通部文字列長増加処理の詳細な手順を示すフローチャート。 上記実施形態の第１の変形例で適用される共通部文字列長増加処理の手順を示すフローチャート。 上記実施形態の第２の変形例で適用される文字列索引内のあるページを対象とする文字列格納処理を説明するための当該ページの状態遷移図。

符号の説明

１０…データベースサーバ、２０…クライアント端末、４０…２次記憶装置、４１…データベース管理プログラム、４２…データベース、５０…データベース管理システム（文書検索システム）、５１…文書格納処理部、５２…文字列格納処理部、５３…検索部、５４…要求処理部、６１…文字列順序判定部、６２…ヘッダ処理部、６３…レコード処理部（文字列処理手段）、６４…共通部文字列検出部、６５…文書読込部、２０１…格納可能文字列長フィールド、２０２…レコード数フィールド、２０３，２１０…共通部文字列長フィールド、２１１…文書位置フィールド、２１２…文字列長フィールド、２１３…文字列フィールド、４２１…文書部、４２２…索引部、６２０…共通部文字列長管理部、６２１…共通部文字列長減少部、６２２…共通部文字列長増加部、６３１…レコード挿入部（文字列挿入手段）、６３２…レコード削除部（文字列削除手段）、６３３…文字列変更部。

Claims (2)

1. 文字列索引格納手段に格納された文字列索引であって、文書格納手段に格納される文書から抽出された文字列が、当該文書に対応付けて且つ当該文字列を構成する文字の順序に基づいて順序付けされた配列で格納された文字列索引を利用して、文字列をキーとした文書検索を行う文書検索システムにおいて、
   文書格納手段に格納される文書から抽出された、前記文字列索引に格納されるべき隣接する文字列毎に、先頭から共通する予め定められた一定文字数を上限とする文字列を共通部文字列として検出する共通部文字列検出手段と、
   前記検出された共通部文字列の文字列長を表す共通部文字列長情報が設定された共通部文字列長フィールドと、前記文字列索引に格納されるべき隣接する文字列のうち、先頭文字列については当該先頭文字列の先頭から前記一定文字数を上限とする文字列が設定され、残りの各文字列については、先行する隣接文字列との間で先頭から共通する前記検出された共通部文字列に後続する前記一定文字数を上限とする文字列が設定された、前記一定文字数に一致するサイズの文字列フィールドとを含むレコードを、前記文字列索引の該当位置に格納する文字列処理手段と、
   前記文字列索引の第１の位置に先行する第２の位置が存在する場合、前記第２の位置に格納されているレコードの文字列フィールドに設定されている文字列と前記第２の位置に対応付けて前記文字列索引に格納されているレコードの共通部文字列長フィールドに設定されている共通部文字列長情報とに基づいて、当該共通部文字列長情報の示す前記共通部文字列を取得して、前記第１の位置に格納されているレコードの文字列フィールドに設定されている文字列を、前記取得した共通部文字列の後ろに連結することにより、前記第１の位置に本来格納されるべき文字列を復元して、文字列をキーとした文書検索を行う検索手段と
   を具備することを特徴とする文書検索システム。
2. 文字列索引格納手段に格納された文字列索引であって、文書格納手段に格納される文書から抽出された文字列が、当該文書に対応付けて且つ当該文字列を構成する文字の順序に基づいて順序付けされた配列で格納された文字列索引を利用して、文字列をキーとした文書検索を行うコンピュータを、
   文書格納手段に格納される文書から抽出された、前記文字列索引に格納されるべき隣接する文字列毎に、先頭から共通する予め定められた一定文字数を上限とする文字列を共通部文字列として検出する共通部文字列検出手段と、
   前記検出された共通部文字列の文字列長を表す共通部文字列長情報が設定された共通部文字列長フィールドと、前記文字列索引に格納されるべき隣接する文字列のうち、先頭文字列については当該先頭文字列の先頭から前記一定文字数を上限とする文字列が設定され、残りの各文字列については、先行する隣接文字列との間で先頭から共通する前記検出された共通部文字列に後続する前記一定文字数を上限とする文字列が設定された、前記一定文字数に一致するサイズの文字列フィールドとを含むレコードを、前記文字列索引の該当位置に格納する文字列処理手段と、
   前記文字列索引の第１の位置に先行する第２の位置が存在する場合、前記第２の位置に格納されているレコードの文字列フィールドに設定されている文字列と前記第２の位置に対応付けて前記文字列索引に格納されているレコードの共通部文字列長フィールドに設定されている共通部文字列長情報とに基づいて、当該共通部文字列長情報の示す前記共通部文字列を取得して、前記第１の位置に格納されているレコードの文字列フィールドに設定されている文字列を、前記取得した共通部文字列の後ろに連結することにより、前記第１の位置に本来格納されるべき文字列を復元して、文字列をキーとした文書検索を行う検索手段と
   として機能させるためのプログラム。

Images