JPH09305622A

JPH09305622A - 文書検索機能を有するデータベース管理方法およびシステム

Info

Publication number: JPH09305622A
Application number: JP8117311A
Authority: JP
Inventors: Norihiro Hara; 憲宏原; Nobuo Kawamura; 信男河村; Kenichi Kitamura; 健一北村
Original assignee: Hitachi Software Engineering Co Ltd; Hitachi Ltd
Current assignee: Hitachi Software Engineering Co Ltd; Hitachi Ltd
Priority date: 1996-05-13
Filing date: 1996-05-13
Publication date: 1997-11-28
Anticipated expiration: 2016-05-13
Also published as: JP3653333B2

Abstract

(57)【要約】【課題】テーブルおよびそのテーブルに関連付けられ
た文書を格納したデータベースに対して、効率の高い文
書検索機能付きリレーショナルデータベース管理方法を
提供すること、かつ文書検索の際に用いる文書索引の容
量を削減することを課題とする。【解決手段】検索要求において文書検索条件に合致し
た文書145の文書番号集合を取得し、文書登録に際して
は登録文書の文書番号を登録する文書索引142と、文書
番号と対応するデータ144を一意に識別するデータ識別
子とを関連付け、検索処理において文書索引142を参照
することにより取得された文書番号集合を対応するデー
タ識別子集合に変換する変換テーブル141とからなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、文書検索機能を有
するデータベース管理方法およびデータベース管理シス
テムに関する。

【０００２】

【従来の技術】文書情報の蓄積、再利用の重要性に伴
い、売り上げデータ等と同じように文書情報そのものを
テーブル形式のデータベースとして格納管理し、任意の
文字列を入力して種々の条件で文書検索を行うデータベ
ース管理システムが望まれている。このため、データベ
ース内の論理的構造がテーブルの、行（ロー）、列（カ
ラム）から構成されるリレーショナルデータベースにお
いて、列に含まれるデータ型として文書格納のための文
書型を対応させ、その文書型列に対する検索処理という
形態で上記要求に応えるシステムが提供されている。そ
れらデータベース管理システムでは、行の格納形態であ
るレコード内のカラム対応部分に文書格納領域へのポイ
ンタを格納することによって、あたかも文書実体が行内
に存在しているかのように見せている。

【０００３】一方、一般の文書検索システムでは、大量
の文書を高速に検索するために、前処理で索引を作成す
る。文字列を入力して検索条件を満たす文書を確定する
ために、文書本体をすべてアクセスするのでは検索効率
が悪いからである。文書に含まれる文字列を文書から切
り出して、その文字列をキーとして索引を構成し、検索
時にその索引を用いることにより、文書本体へのアクセ
ス無しに効率的に検索条件を満たす文書を確定する。そ
の場合、文書からの文字列の切り出し方、すなわちキー
の構成方法が索引の容量に大きく影響する。切り出し文
字列として一文字を用いると、索引キーから文書へのポ
インタ付けが漏れなく行われ、検索条件判定の際に文書
本体をアクセスする必要がなくなる。しかし、索引容量
が莫大になり、結局検索効率の向上は十分には得られな
い。また、切り出し文字列長を増やしていくと、文書へ
のポインタ付けが荒くなり、それを補うため文書本体を
アクセスしなければならなくなってしまう。検索効率を
向上させるためには、文書へのポインタ付けの漏れがな
いように索引を作成し、かつその容量を減らすことが重
要となる。

【０００４】通常のリレーショナルデータベース管理シ
ステムでは、各行の列値をキーとする索引(インデクス)
を用いて検索効率の向上を図っている。索引の構造とし
てＢ木構造を持つＢ木インデクスがよく用いられる。イ
ンデクスキーから行（ロー）への関連付けは、行（ロ
ー）を一意に識別できる「行（ロー）識別子」によって
行われる。すなわち、インデクスはキーと行（ロー）識
別子から成るインデクスエントリによって構成される。
この「行（ロー）識別子」は、インデクスエントリの構
成要素であるとともに検索結果集合に対する集合演算処
理のような、リレーショナルデータベースに対するデー
タ処理の対象データである行の識別子として用いられ
る。「行（ロー）識別子」を用いて行本体への高速アク
セスが可能なように、「行（ロー）識別子」は、データ
ベースを格納するファイルのアクセス単位であるページ
のページ番号とページ内の行格納位置情報で構成される
ことが多い。

【０００５】

【発明が解決しようとする課題】従来、文書検索機能付
きリレーショナルデータベース管理システムでは、文書
索引の構成要素である文書へのポインタとして、Ｂ木イ
ンデクスと同様に、関連文書が属する行の「行（ロー）
識別子」を用いていた。そのため、文書索引から検索条
件を満たす「行（ロー）識別子」集合を取得し、これと
他カラムに対する検索条件からの結果集合との集合演算
等が可能となる。しかし、その場合、文書管理システム
の文書索引内で管理される文書へのポインタ、または文
書識別手段に比べ、一般にファイル全体の中の格納位置
を示す「行（ロー）識別子」のサイズの方が大きいた
め、文書索引の容量が莫大になり、結果的に検索効率の
低下を招いてしまうという問題があった。

【０００６】本発明は、これらの問題を解決するため、
格納文書を一意に認識でき、行識別子よりサイズの小さ
い「文書番号」を文書索引に用いることにより、文書索
引の容量を削減すると共に文書検索条件を伴う問合せ要
求に対する検索効率の高い文書検索機能付きリレーショ
ナルデータベース管理方法を提供することを目的として
いる。

【０００７】

【課題を解決するための手段】上記目的を達成するため
に、本発明におけるデータベース管理システムは、以下
の構成を有する。

【０００８】データベースの文書に文書オブジェクトを
登録する際に、当該文書オブジェクトを一意に識別し
て、文書索引に用いられる文書番号の割当てを行う手段
を有する文書番号管理部と、検索要求の際に、文書に対
応して作成された文書索引に基づいて、文書検索条件に
合致した文書オブジェクトの文書番号を集合の形で取得
する手段と、文書登録の際に書索引を管理する手段とを
有する文書索引管理部と、文書番号管理部によって格納
文書中の各文書オブジェクトに割り当てられた文書番号
と、文書オブジェクトに関連付けられているデータ中の
各データオブジェクトを一意に識別するためのデータ識
別子とを関連付ける変換テーブルを設け、検索操作の際
に文書索引管理部により取得された文書番号集合を関連
付けられているデータ識別子に変換する手段とを有する
変換テーブル管理部と、を備える。

【０００９】

【発明の実施の形態】以下、図を用いて本発明の実施の
一形態を詳細に説明する。本発明は、図１４に示す計算
機システムで実施される。図４の計算機システムは、中
央処理装置（ＣＰＵ）100、入出力端末（ＶＤＴ）200、
及びディスク装置300からなり、ディスク装置には、後
述するデ−タベ−ス（ＤＢ）4、及び本発明による処理
手順を実行するプログラム500が格納されている。プロ
グラム500は、ＣＰＵの主記憶に読み込まれて実行され
る。

【００１０】まず、図１３の本発明の概念図を説明す
る。本発明のデータベース管理システムでは、データの
属性値に対する条件式およびキーワードを伴う問合せ元
からの検索要求１を受け付けた際、キーワードを元に文
書145に対応して作成された文書索引142を参照し、その
キーワードを含む文書オブジェクトの文書番号(文書N
O.)(群)を取得する。そして、文書NO.に対応する変換テ
ーブル141のエントリ(文書NO.から算出される格納位置)
内に記憶してあるレコード識別子51(レコードID)(群)を
取得する。レコ−ド識別子51は、デ−タ144におけるデ
−タレコ−ド23の格納位置を示す情報であり、デ−タ内
のペ−ジの識別子とペ−ジ内の格納位置を格納したスロ
ットの番号とで構成される。取得したレコード識別子51
を持つ変換テーブル141の行には、検索要求1のキーワー
ドを含む文書オブジェクトがデ−タ144を介して関連付
けられている。

【００１１】また、検索要求１の条件式に含まれるデー
タの属性値に対応して作成された索引143を用いて、条
件式に合致した行のレコードID(群)を取得する。ここ
で、変換テーブル141を参照して得られたレコードIDの
集合を、先の索引143から得られたレコードIDを用いて
絞り込む。

【００１２】ここで、絞り込まれた結果に含まれるレコ
ードIDからページ20内に格納されているデータレコード
23(テーブルの行の格納形態)をアクセスし、検索結果と
して文書オブジェクトへのポインタなどを出力する
(5)。

【００１３】次に図１には、本発明のデータベース管理
システムの構成図が示してある。図１に示すように、本
発明のデータベース管理システムは、問合せ元からの問
合せ要求1を受付けて解析し、問い合わせ要求に応じて
データベース４の検索処理および更新処理を行うデータ
ベース処理部3から構成される。問合せ要求・結果処理
部2は、利用者からの問合せ要求1を受付けて解析し(12
1)、問合せ要求に対応したデータ処理の実行をデータベ
ース処理部3に要求し(122)、データベース処理部3から
問い合わせ結果を処理して(123)、問合せ元に問合せ結
果5を出力する。

【００１４】データベース処理部３は、問合せ要求・結
果処理部２からの要求に応じて、データベース４を検索
あるいは更新し、その結果を問合せ要求・結果処理部２
に返す。データベース４の検索あるいは更新処理を担当
するのが、文書索引管理部131、索引管理部133、データ
管理部134、変換テーブル管理部132、そして文書番号管
理部135である。

【００１５】ここで、図１における矢印は、検索要求の
際の処理の主な流れを示す。文書索引管理部131および
索引管理部133を用いることにより効率よく検索結果を
絞り込む。要求によっては、データ管理部134が検索結
果として絞り込まれたデータを参照する。文書番号管理
部は、文書登録の際に文書番号の割り当てを行う。

【００１６】本発明のデータベース管理システムで管理
されるデータベース4は、データベース操作対象である
データオブジェクトの集まりから成るデータ144、デー
タ144に対応して作成された索引143、データ144のデー
タオブジェクトそれぞれに関連付けられた文書オブジェ
クトの集まりから成る文書145、文書145に対応して作成
された文書索引142、そして上記文書145の文書オブジェ
クトとデータ144のデータオブジェクトとを論理的に結
び付けるための変換テーブル141からなる。

【００１７】データ144のデータオブジェクトの一例と
して、リレーショナル管理システムにおけるデータモデ
ルであるテーブルの構成要素である行が挙げられる。デ
ータ144のデータオブジェクト、すなわち本形態におけ
る行は、データベース４へのアクセス単位であるページ
中に、データレコードという形態で格納される。そのデ
ータレコードに対して、問合せ要求・結果処理部２の問
合せ処理実行制御122の指示によって、格納/読み出し等
を担当するのがデータベース処理部３のデータ管理部13
4である。検索高速化のためにしばしばデータに対して
索引143を作成し、検索時参照する。その索引143の参照
および更新処理を行うのが、索引管理部133である。

【００１８】本発明のデータベース管理システムでは、
文書をテーブルの列の属性値として提供するに当たり、
データ144と文書145とをそれぞれ別領域に格納して互い
に関連付ける。その関連付けの手段が変換テーブル141
である。また、文書高速検索手段として文書索引142を
有し、文書索引の維持管理をデータベース処理部３内の
文書索引管理部131が担当する。文書索引管理部131は、
文書検索要求に際し、文書索引142を参照することによ
り文書検索条件に合致した文書に関する情報を取得す
る。文書145内の文書オブジェクトは、データベース格
納時に文書番号管理部135によって割り当てられた文書
オブジェクトを一意に認識するための文書番号によって
識別される。文書索引管理部131は、文書オブジェクト
に関する情報として文書番号を取得する。

【００１９】テーブルの行の識別手段として、ある条件
等に合致した行集合に対して集合演算を施したり、特定
行をアクセスしたりするために、行に対応する格納デー
タレコードのレコード識別子（データ識別子）を用い
る。データオブジェクトと文書オブジェクトの関連付け
は、上記文書番号とレコード識別子を用いて行う。

【００２０】図２は、データ144の各ページ内における
データレコードの格納構造の一形態を示す図である。１
つのページ20内には、複数のデータレコード23が格納可
能であり、データレコード23のページ内の格納位置は、
スロット21により指示される。スロット21の領域には指
示するデータレコード23が格納されているページ20の先
頭からの格納位置が記憶される。ページ制御情報22は、
スロットの割当て状況などのスロット管理およびページ
内領域管理を行うためのものである。データレコード23
は、文書を属性値として持つ列(カラム)に対応する文書
フィールド24を含む。文書フィールド24は、文書を一意
に認識するための文書番号25および、文書本体をアクセ
スするためのポインタ（文書格納位置情報）26から成
る。文書番号25は、データレコード23と文書145中の各
文書オブジェクトとを論理的に結び付けるために用いら
れる。その文書番号25に対し、文書オブジェクトへのポ
インタ26は両者(データレコードと文書オブジェクト)を
物理的に結び付けるために用いられる。

【００２１】図３は変換テーブル141に格納されている
各レコード識別子の構成の一形態を示す図である。レコ
ード識別子51は、データレコード(図２の23)が格納され
るページ(図２の20)を一意に識別するためのページ識別
子31と、ページ内のデータレコード格納位置を特定する
ためのスロット(図２の21)を示すスロット番号32から成
る。スロット番号32は、ページ格納構造においてページ
制御情報(図２の22)側から順次番号付けされる。図３で
は、「ページ識別子＋スロット番号」という構造を採っ
ているが、「スロット番号＋ページ識別子」でもなんら
問題はない。レコード識別子51を用いてデータレコード
をアクセスする。データレコードへのアクセスは、この
レコード識別子のページ識別子51を用いて格納ページを
アクセスし、スロット番号32に対応するスロットに記録
されているデータレコード格納位置を取得することによ
って高速に行われる。

【００２２】図４は、文書索引および索引の具体例を示
す図である。図４のa)は、図１のデータベース4内の文
書索引142(図１３の概念図にも記述)の詳細構成例であ
る。また図４のb)は、図１のデータベース4内の索引143
(図１３の概念図にも記述)の詳細構成例である。

【００２３】文書索引142の中には各インデクスキーワ
ードに対応した複数の索引41が含まれる。ここで、先頭
の“本”はインデクスキーワードであり、それに続く文
書番号11、12、…、1nは、インデクスキーワード“本”
を含む文書オブジェクトの文書番号である。同様に、
“発”および“明”について図示のように登録されてい
る。この構造によりどんなキーワードが検索列としてや
ってきても文書オブジェクト本体をアクセスすることな
しに検索条件に合致した文書番号を取得できる。

【００２４】索引143の中には、属性値とその属性値を
持つ列(カラム)の行を示すレコードID(レコード識別子)
(群)から成る索引エントリ42が記録されている。属性値
を指定すると、容易にその属性値を持つレコードIDを取
得することができる。ここでは、索引エントリはテーブ
ル構造をとっているが、B木構造やハッシングを用いた
構造でもよい。

【００２５】図５は、変換テーブルの一例を示す図であ
る。これは、図１のデータベース4内の変換テーブル141
(図１３の概念図にも記述)の詳細例である。本変換テー
ブルは、上記文書索引によって取得した検索条件に合致
する文書番号を、リレーショナルデータベース管理シス
テムが種々の演算において採用するレコード識別子(図
３の30)に変換するためのものである。変換テーブル141
は、変換テーブルエントリ51により構成される。本形態
において変換テーブルエントリ51はレコード識別子(図
３の30)から構成される。

【００２６】そして、テーブル141は、複数の変換テー
ブルエントリ51の格納位置を文書番号から計算により容
易に特定できるような構造になっている。さらに具体的
に述べると、文書番号を１から順に格納領域をインクリ
メンタルに割り当てることにより、そのシリアルな文書
番号に対応するレコード識別子30が変換テーブルの対応
するエントリにマッピングされるようにする。その結
果、文書番号より変換テーブルのエントリをアクセス
し、エントリに記録してある対応レコード識別子を取得
できる。

【００２７】各変換テーブルエントリの構成要素がペー
ジ識別子とスロット番号からなるレコード識別子のみで
あり、文書番号やエントリ自身の情報などを必要としな
いことから、変換テーブルの容量を必要最小限に抑える
ことができる。さらに、文書索引内にレコード識別子を
持つ場合、文書索引内には同一レコード識別子が大量に
存在しそれがアクセス効率の低下を招く要因になること
から、変換テーブルを参照し文書番号からレコード識別
子に最終的に変換する方が効率よくアクセスすることが
できる。さらなる変換テーブルアクセス効率向上のた
め、変換テーブルはメモリに常駐させる方が望ましい。

【００２８】次に図２から図５で説明した一構成形態の
もとで、図６および図７を用いてデータベースの検索処
理について詳細に説明する。

【００２９】図６は、検索要求が問合せ元から入力され
た際の、データベース処理の詳細を示すフローチャート
であり、図１における問合せ実行制御122以降の処理に
ついて示している。まず、ステップ601において、要求
検索操作は文書索引を使用する検索であるかどうかを判
定する(図１の122)。文書索引の使用不使用の指定は、
図１の問合せ要求受付け・解析121において問合せ要求
に含まれる検索条件により決定される。(ここで図１で
のデータベース処理部3に制御が渡る。)ステップ601に
おいて文書索引使用指定の場合、ステップ602以降に進
み文書検索条件による検索実行を行う。文書索引の使用
の指定がない場合、ステップ609に進み、索引による検
索を行うかどうかの判断を行う。

【００３０】ステップ602に進んだ場合、図１の文書索
引管理部131が以下の処理を行う。文書索引をアクセス
し(ステップ602)、文書検索条件を満たす文書番号集合
を取得する(ステップ603)。次に、取得した文書番号の
集合を対応するレコード識別子の集合に変換するため
に、文書番号一つ一つを評価する。すなわち、ステップ
604において、文書番号集合に要素すなわち文書番号が
存在するかを判定する。文書番号が存在しない場合、文
書番号集合はすべてレコード識別子集合に変換完了した
とみなし、ステップ609に進む。

【００３１】集合要素である文書番号が存在する場合、
ステップ605以降により一文書番号の変換処理を行う。
変換処理は、図１の変換テーブル管理を通して行う。ス
テップ605において文書番号集合から一文書番号を取り
出す。そして、文書番号から変換テーブルの対応するエ
ントリの格納位置を算出し、変換テーブルの対応するエ
ントリをアクセスする(ステップ606)。そして、変換テ
ーブルのエントリからレコード識別子を取得する(ステ
ップ607)。取得したレコード識別子を変換結果としてレ
コード識別子集合１に追加する(ステップ608)。そし
て、ステップ604に戻り、残りの文書番号の変換を続行
する。

【００３２】文書番号集合の変換処理がすべて終了後、
または文書索引による検索処理を行わなかった場合、ス
テップ609において、索引を使った検索を行うかどうか
を判定する。索引を使った検索を行う場合、図１の索引
管理部133に処理制御が渡り以下の処理を行う。ステッ
プ610に進み索引をアクセスし、検索条件を満たすレコ
ード識別子集合２を取得する(ステップ611)。ステップ6
09において、索引を使用しないと判断した場合、ステッ
プ612に進む。ステップ612において、検索条件の組合せ
による集合演算を行う。具体的には、文書に対する検索
条件と索引を使うような検索条件のAND条件で問合せ要
求がなされている場合は、レコード識別子集合１とレコ
ード識別子集合２の積集合を結果レコード識別子集合と
する。

【００３３】また、OR条件の問合せ集合の場合には、レ
コード識別子集合１とレコード識別子集合２の和集合を
結果レコード識別子集合とする。どちらかの条件のみの
場合はレコード識別子集合の集合演算は行わず、そのま
ま結果レコード識別子集合とする。その後、ステップ61
3において、結果レコード識別子集合を用いて要求に応
じレコードをアクセスし(ステップ613)、結果として問
合せ元に返す(ステップ614)。

【００３４】図７は、本発明の検索動作説明図を示して
いる。これは、図６のフローチャートに従って説明した
検索時の具体例である。データベース4には、データ144
および文書145として、図７に示す「著者」列および
「文書」列（文書型）を持つテーブルが格納管理されて
いる。問合せ元が問合せ要求1として、「著者＝HARA」
かつ「"データベース"を含む」行の検索を要求する。処
理122において上記問合せ要求を受付けて解析し、アク
セス手段の決定を行う。本具体例では、「著者」列に索
引が定義され、文書索引が用意されているので、索引お
よび文書索引を用いて検索処理を行うことを決定する。

【００３５】そして、処理122において決定されたアク
セス手段に従って検索処理を以下のように制御する。ま
ず、文書索引管理部131において文書索引142をアクセス
し、検索条件合致文書番号(文書番号１、文書番号２)を
取得する(図６のステップ603に相当)。そして、変換テ
ーブル管理部132において、変換テーブル141を参照し、
先に取得した文書番号集合をレコード識別子集合（レコ
ード識別子n、レコード識別子m）に変換する(図６のス
テップ605からステップ608に相当)。次に、検索条件
「著者＝HARA」より、索引管理部133において索引143を
アクセスし、検索条件合致レコード識別子（レコード識
別子m、レコード識別子k）を取得する。検索結果処理部
123において、上記結果レコード識別子集合をマージし
(本実施例の場合、積集合を求める)(図６のステップ612
に相当)、最終結果レコード識別子mを取得し、検索結果
709として問合せ元に返す(図６のステップ614に相当)。

【００３６】以上によって、文書が格納された列「文
書」に対する文書検索条件を含む検索操作を、文書番号
からレコード識別子への容易な変換を用いて、他の列に
作成されている索引を利用するのと同じ要領で実行する
ことができた。また、索引と併用することで、結果集合
の縛り込みが効率的に行えた。ここでは、「文書」列以
外の列に作成されている一索引の利用例を示したが、検
索条件によっては複数索引を用いてもよい。また、デー
タベースへのI/O数等を加味して最適化を図り、適切な
索引を組合せて使用するようにしてもよい。

【００３７】次に、図８および図９を用いてデータベー
スへの登録操作について詳細に説明する。図９は、本発
明の登録操作フローチャートであり、図６同様に図１に
おける問合せ実行制御122以降の処理について示してい
る。

【００３８】新規データおよび新規文書の登録の際に、
まずデータベース処理部３では、ステップ801にて新規
文書番号の割り付けを行う。これは、図１の文書番号管
理部135が行う。文書番号の管理方法の一形態として、
文書番号を「採番カウンタ」で管理し、新規文書の登録
において「採番カウンタ」に＋１した値を文書番号とし
て割り当てる。その際「採番カウンタ」の値は＋１す
る。ここで、文書番号(採番カウンタ)を実現するために
必要なビット数（サイズ）は、レコード識別子を構成す
るページ識別子およびスロット番号を実現するためのビ
ット数（サイズ）よりも小さい。これは、レコード識別
子の割当てがまばらになるのに対して、文書番号は常に
順番に割り当てられることからも分かる。

【００３９】次に、データベース4に新規文書オブジェ
クトを格納する(ステップ802)。先程の新規文書番号お
よび新規文書格納位置を用いて、新規データレコードを
作成する(ステップ803)。新規データレコードの作成に
当たり、図２を用いて説明したデータレコード23の文書
フィールド24の文書番号25および文書オブジェクトへの
ポインタ26（文書オブジェクト格納位置）を設定する。
そして、新規データレコードを格納するためのページを
決定し(ステップ804)、格納ページ内のページ制御情報
から新規データレコードのためのスロットを割り当てて
もらい(ステップ805)、新規データレコードをページ内
に格納する(ステップ806)。格納ページおよびスロット
番号決定時、レコード識別子が確定する。

【００４０】データレコード格納後、文書列以外の列に
索引が存在するかを判定し(ステップ807)、存在する場
合その索引のメンテナンスをレコード識別子を用いて行
う(ステップ808)。さらに、ステップ809において、ステ
ップ801で割当てた文書番号を用いて文書索引のメンテ
ナンスを行う。文書番号から変換テーブルエントリの位
置を算出し(ステップ810)、変換テーブルエントリにス
テップ805までに確定したレコード識別子を設定する(ス
テップ811)。

【００４１】ここでは、索引のメンテナンス処理の後
に、文書索引のメンテナンスを行っているが、文書番号
の割当ておよびレコード識別子の確定が完了していさえ
すれば、索引および文書索引のメンテナンスの順序に制
約はない。もちろん両メンテナンス処理は処理高速化の
ため並列に実行することが望ましい。また、変換テーブ
ルエントリのメンテナンスも文書番号および対応レコー
ド識別子が確定した段階で行って構わない。

【００４２】図９は、本発明の登録操作説明図を示して
いる。これは、図８のフローチャートに従って説明した
登録時の具体例である。データベース４には、図７と同
様に「著者」列および「文書」列を持つテーブルがデー
タ144および文書145として格納管理されている。問合せ
元が問合せ要求1として、「著者＝NISHI」であり文書オ
ブジェクト「…。インターネットは、…。」を伴う新規
データの登録を要求する。処理121において上記問合せ
要求を受付けて解析する。そして、処理122において登
録処理を以下のように制御する。

【００４３】まず、データ管理部134において文書格納
を行うが、それに先立ち文書番号管理部135において文
書番号の割り付けを行い、「文書番号４」を取得する
(図８のステップ801に相当)。次に新規文書オブジェク
トをデータベース４に格納し(図８のステップ802に相
当)、そのポインタと「文書番号４」を用いてデータレ
コードの格納を行う(図８のステップ806に相当)。その
際、「レコード識別子p」が確定される。「著者」列に
索引が作成されていることから、インデクスキー「NISH
I」および「レコード識別子p」を用いて索引管理部133
において索引143のメンテナンス処理を行う(図８のステ
ップ808に相当)。それとともに、「文書番号４」を用い
て文書索引131において文書索引142のメンテナンス処理
を行う(図8のステップ809に相当)。またそれとともに、
変換テーブル管理部132において、「文書番号４」から
変換テーブルエントリ位置を算出し、エントリに「レコ
ード識別子p」を設定することにより、新エントリ設定
を完了する(図８のステップ811に相当)。

【００４４】以上によって、「著者＝NISHI」を含むデ
ータレコードと新規文書オブジェクト「…。インターネ
ットは、…。」とを関連付けて登録することができる。

【００４５】次に、図１０および図１１を用いてデータ
ベースからの削除操作について詳細に説明する。図１０
は、本発明の削除操作フローチャートであり、図６と同
様に図１における問合せ実行制御122以降の処理につい
て示している。データおよびそれに関連する文書の削除
の際に、まず、データベース処理部では、ステップ1001
にてレコード識別子を用いて削除対象となっているデー
タレコードの削除を行う。その際、関連する文書オブジ
ェクトの文書番号および文書格納ポインタを記憶してお
く。

【００４６】次に、ステップ1002にて先に記憶しておい
た文書格納ポインタを用いて文書オブジェクトの削除を
行う。そして、ステップ1003において削除データレコー
ドに関連する索引のメンテナンスを行う。すなわち、ス
テップ1003で索引が作成されているかどうかを判定す
る。索引がある場合、ステップ1004において列の値およ
び削除対象レコード識別子を用いて索引メンテナンス
(索引エントリの削除)を行い、ステップ1005に進む。索
引が存在しない場合、そのままステップ1005に進む。次
に、削除データレコードから記憶しておいた文書番号を
用いて文書索引のメンテナンスを行う(ステップ1005)。
さらに文書番号から変換テーブル位置を算出し(ステッ
プ1006)、変換テーブルエントリ内のレコード識別子を
初期化することにより、対応変換テーブルエントリを無
効化する(ステップ1007)。

【００４７】図１１は、本発明の削除操作説明図を示し
ている。これは、図１０のフローチャートに従って説明
した削除時の具体例である。データベース４には、図７
および図９と同様に「著者」列および「文書」列を持つ
テーブルがデータ144および文書145として格納管理され
ている。問合せ元が問合せ要求1として、「著者＝NISH
I」であるデータ(行)の削除を要求する。処理121におい
て上記問合せ要求を受付けて解析する。そして、処理12
2において削除処理を以下のように制御する。

【００４８】まず、データ管理部134において削除対象
レコードの「レコード識別子p」を確定し、データレコ
ードの削除を行う(図１０のステップ1001に相当)。そし
て、データレコードに格納されていた関連文書オブジェ
クトへのポインタを用い、対応する文書オブジェクトの
削除を行う(図１０のステップ1002に相当)。図１１に示
すように、データ144および文書145の削除対象レコード
および文書オブジェクトを点線で示してある。

【００４９】削除データレコードの「レコード識別子
p」、索引がはられている列の値、および削除データレ
コードに格納されていた関連文書オブジェクトの「文書
番号４」を用いて、索引管理部133にて索引メンテナン
ス処理を、文書索引管理部131において文書索引メンテ
ナンス処理を、さらに変換テーブル管理部132において
対応エントリの初期化をそれぞれ行う(図１０のステッ
プ1001、ステップ1004、ステップ1005にそれぞれ相
当)。対応エントリの初期化において、「文書番号4」か
ら変換テーブルの位置を算出しエントリ内の「レコード
識別子p」を初期化する。

【００５０】以上によって、削除要求処理を完了する。
図１１の流れからも分かるように、データレコード削除
の後、関連する文書番号および削除文書格納ポインタ、
索引キーが確定されているので、それらの処理を順次実
行する理由はない。これは、並列処理による高速化を意
味する。

【００５１】上述の実施形態では、文書番号割当て処理
を文書番号管理部135が行っているが、データベースへ
の文書格納を行うためのデータ管理部134が行っても構
わない。また、変換テーブルの実施形態に関しても、上
述のようなエントリの配列構造ではなく、Ｂ木構造であ
ってももちろん構わない。

【００５２】また、図１２に文書索引のさらなる一実施
形態を示す。図１２は、ビットマップ・インデクスを用
いた文書索引の例を示す図である。これは、図４におけ
る文書索引例とは別の実施形態である。図４の例では文
書索引が文字列をキーとする文書番号リストより構成さ
れていたのに対し、図１２の例では、文字列に対してビ
ットマップ・インデクスを作成する。格納文書オブジェ
クトそれぞれに１ビットを割り当てる。また、各ビット
は文書オブジェクト中の文字列に対応する。例えば、文
字列が“本”のビットマップ・インデクスにおいて、１
番目とｎ番目のビットが１であれば、１番目とｎ番目の
文書オブジェクトに“本”が含まれていることを意味す
る(1200)。

【００５３】ビットマップ・インデクスを用いた場合、
ビットマップの中の位置によって文書を識別する。最初
のビットが文書番号１を指し、ｎ番目のビットが文書番
号ｎを指す。本実施形態において、文書番号は１からシ
リアルに割当てられるため、ビットマップ・インデクス
による実現は容易であり、アクセスも効率的である。ま
た、ビットマップ・インデクスを用いた場合、検索結果
は一時的にビットマップの形態をとることになる。これ
は、テーブルに複数の文書列が定義され、その列おのお
のに検索条件が指定された問合せ要求が入力された場
合、複数の文書索引を用いた検索結果のAND/OR演算は、
レコード識別子に一旦変換しなくとも、ビットマップ同
士のビット演算で効率良く実現できることを意味する。
また、以上のことは、文書索引を用いた文書検索に縛ら
れることなく、ビットマップ・インデクスを用いた列に
おける高速検索への拡張も意味する。

【００５４】すなわち、文書属性を持たない列に対する
索引をビットマップ・インデクスで構築した場合でも、
本発明における変換テーブルを用いることにより、レコ
ード識別子（行識別子）とビットマップ・インデクス内
のビット位置との対応が容易にでき、かつ索引中にレコ
ード識別子を持たないことから索引の容量も小さく抑え
ることができる。

【００５５】文書は多数の文字列を含むため、文書索引
内には、同一文書番号が多数存在する。変換テーブルを
導入することにより、文書番号として最小サイズのもの
を採用することができ、レコード識別子を用いて文書索
引を構成するよりも、文書索引の容量を削減することが
できた。また、変換テーブルは、文書番号から対応レコ
ード識別子を取得する目的のみに用い、種々の問合せよ
りに関してレコード識別子から文書番号への逆変換はフ
ローチャートからも分かるように不要である。しかも、
文書番号からレコード識別子への変換は容易に実行する
ことができることから、文書を伴うデータの検索、登
録、又は削除操作が効率良く行うことができる。

【００５６】本発明における一形態として、データオブ
ジェクトと文書オブジェクトが１対１に対応する形態を
説明したが、別形態として、データオブジェクトと文書
オブジェクトとの関連は、多対１、１対多、多対多でも
構わない。また、データオブジェクト新規格納時におい
て、関連文書オブジェクトが決定あるいは格納されてい
なくともよい。その場合、データオブジェクトの文書フ
ィールドに、文書オブジェクト未決定情報（具体的には
null値）を記録しておけばよい。これらのことは、デー
タオブジェクトと文書オブジェクトとが、ユティリティ
におけるデータ一括登録などにおいて独立した運用が可
能であることを示している。文書オブジェクトの登録に
は一般にデータオブジェクトの格納に比べ多数のI/Oを
伴うため、データオブジェクトのみを先に一括登録し、
文書オブジェクトの登録は後回しにしておく、等という
運用も容易である。

【００５７】

【発明の効果】以上説明したように、本発明によれば、
格納文書の識別手段としてレコード識別子よりサイズの
小さい「文書番号」を採用し、文書索引内において文書
番号を用いて索引文字列との関連を管理し、検索時にそ
の「文書番号」と関連する行の「レコード識別子」とを
変換テーブルを用いて容易に「文書番号」から「レコー
ド識別子」に変換し、レコード識別子に条件式を適用す
ることにより、文書検索条件を伴う問合せ要求に対し効
率よく検索することができる。さらに、索引を併用する
ことにより、レコード識別子の絞り込みを効率的に行う
ことができる。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】データレコードの格納構造の一形態を示す図で
ある。

【図３】レコード識別子の構成の一形態を示す図であ
る。

【図４】文書索引の一形態を示す図である。

【図５】本発明の文書番号レコード識別子変換テーブル
構造の一例を示す図である。

【図６】発明の検索操作フローチャートである。

【図７】本発明の検索操作説明図である。

【図８】本発明の登録操作フローチャートである。

【図９】本発明の登録操作説明図である。

【図１０】本発明の削除操作フローチャートである。

【図１１】本発明の削除操作説明図である。

【図１２】ビットマップ・インデクスを用いた文書索引
の例である。

【図１３】本発明の概念図である。

【図１４】本発明を実施する計算機システムの構成図で
ある。

【符号の説明】

１：問合せ要求、１３１：文書索引管理部、１３２：変
換テーブル管理部、１３３：索引管理部、１３４：デー
タ管理部、１３５：文書番号管理部、２：問合せ要求・
結果処理部、３：データベース処理部、４：データベー
ス、１４１：変換テーブル、１４２：文書索引、１４
３：索引、１４４：データ、１４５：文書、５：問合せ
結果

───────────────────────────────────────────────────── フロントページの続き (72)発明者河村信男神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報・通信開発本部内 (72)発明者北村健一神奈川県横浜市中区尾上町６丁目81番地日立ソフトウェアエンジニアリング株式会社内

Claims

【特許請求の範囲】

【請求項１】計算機を用いて、文書オブジェクト、およ
び前記文書オブジェクトと関連付けられたデータオブジ
ェクトを管理するデータベース管理方法において、ａ）入力手段から入力された検索要求に含まれるキ−ワ
−ドを含む少なくとも１つの文書の番号に対応する少な
くとも１つの第１のレコ−ド識別子を抽出し、ｂ）前記検索要求に含まれる条件式を満たす属性値に対
応する少なくとも１つのデ−タレコ−ドの第２のレコ−
ド識別子を抽出し、ｃ）前記第２のレコ−ド識別子に合致する前記第１のレ
コ−ド識別子を選択し、ｄ）前記ステップｃ）で選択
されたレコ−ド識別子に対応するデ−タレコ−ド、及び
前記デ−タレコ−ドと関連付けられた文書オブジェクト
を抽出することを特徴とする文書検索機能を有するデー
タベース管理方法。
【請求項２】前記ステップａ）は、ａ１）前記キ−ワ−ドによって文書索引を検索して少な
くとも１つの文書番号を抽出し、ａ２）前記抽出された文書番号に対応する格納位置に格
納された前記第１のレコ−ド識別子を変換テ−ブルから
抽出することを特徴とする請求項１記載の文書検索機能
を有するデータベース管理方法。
【請求項３】文書オブジェクト、および前記文書オブジ
ェクトと関連付けられたデータオブジェクトを管理する
データベース管理システムは、ａ）入力手段から入力された検索要求に含まれるキ−ワ
−ドを含む少なくとも１つの文書の番号に対応する少な
くとも１つの第１のレコ−ド識別子を抽出する手段、ｂ）前記検索要求に含まれる条件式を満たす属性値に対
応する少なくとも１つのデ−タレコ−ドの第２のレコ−
ド識別子を抽出する手段、ｃ）前記第２のレコ−ド識別子に合致する前記第１のレ
コ−ド識別子を選択する手段、及びｄ）前記選択されたレコ−ド識別子に対応するデ−タレ
コ−ド、及び前記デ−タレコ−ドと関連付けられた文書
オブジェクトを抽出する手段を有することを特徴とする
文書検索機能を有するデータベース管理システム。
【請求項４】文書オブジェクト、および前記文書オブジ
ェクトと関連付けられたデータオブジェクトを管理する
ための、計算機で読み出し可能な記録媒体に格納された
データベース管理方法のプログラムは、ａ）入力手段から入力された検索要求に含まれるキ−ワ
−ドを含む少なくとも１つの文書の番号に対応する少な
くとも１つの第１のレコ−ド識別子を抽出し、ｂ）前記検索要求に含まれる条件式を満たす属性値に対
応する少なくとも１つのデ−タレコ−ドの第２のレコ−
ド識別子を抽出し、ｃ）前記第２のレコ−ド識別子に合致する前記第１のレ
コ−ド識別子を選択し、ｄ）前記ステップｃ）で選択
されたレコ−ド識別子に対応するデ−タレコ−ド、及び
前記デ−タレコ−ドと関連付けられた文書オブジェクト
を抽出することを特徴とする文書検索機能を有するデー
タベース管理方法プログラム。