JP2009003541A - データベースのインデックス作成システム、方法及びプログラム - Google Patents

データベースのインデックス作成システム、方法及びプログラム Download PDF

Info

Publication number
JP2009003541A
JP2009003541A JP2007161524A JP2007161524A JP2009003541A JP 2009003541 A JP2009003541 A JP 2009003541A JP 2007161524 A JP2007161524 A JP 2007161524A JP 2007161524 A JP2007161524 A JP 2007161524A JP 2009003541 A JP2009003541 A JP 2009003541A
Authority
JP
Japan
Prior art keywords
keyword
document
index
partial
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007161524A
Other languages
English (en)
Other versions
JP4848317B2 (ja
Inventor
Itsusei Yoshida
一星 吉田
Daisuke Takuma
大介 宅間
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to JP2007161524A priority Critical patent/JP4848317B2/ja
Priority to US12/132,301 priority patent/US8190613B2/en
Publication of JP2009003541A publication Critical patent/JP2009003541A/ja
Application granted granted Critical
Publication of JP4848317B2 publication Critical patent/JP4848317B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/313—Selection or weighting of terms for indexing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】主記憶の容量の制限に拘わらず、大規模データベースのインデックスを高速に作成できるようにすること。
【解決手段】文書集合を互いに共通部分のない部分集合に分解する。分割してできた部分集合内で出現するキーワードの集合につき、キーワードのハッシュ値をある固定の整数値で割った余りでグルーピングし、各グループに対するインデックス・ファイルを作成する。文書の各部分集合毎に用意されたインデックス・ファイルについて、同じグループ番号をもつもの同士をマージする。こうして、個々のグループ番号に対応する統合されたインデックス・ファイルが生成される。インデックス・ファイルは、グループ番号の個数だけ存在し、まだ、文書集合の全体に対応するインデックスになっていない。そこで次に、そのようなグループ番号の個数だけあるインデックス・ファイルをさらにマージして、文書集合の全体に対応するインデックス・ファイルが生成される。
【選択図】図６

Description

この発明は、テキストマイニング等に使用されるデータベースに関し、特に、データベースのインデックス作成システム、方法及びプログラムに関するものである。
テキストマイニングの典型的な応用例では、テキストマイニングのシステムに対話的に検索条件を与え、その検索条件に相関の高いキーワードを見出す、ということが必要になる。
例えば、ＰＣコールセンターのコールログを対象とした分析をする際、特に、ある特定の製品に頻出する問題を見つけたいとする。この場合、その製品番号を絞込条件として検索を行い、ヒットした文書中のキーワードを数え上げることにより、その製品と一緒に言及されることの多いキーワードを見つけることになる。
また、テキストマイニング・システムでは、キーワードにカテゴリを予め付与することもできる。例えば、「発熱する」というキーワードに対して、「問題表現」というカテゴリを付与しておく。すると、キーワードの数え上げを、このカテゴリに属するキーワードのみに対して行うことによって、問題を効率よく見つけることが可能となる。
このように、対話的に検索条件を与えて、その結果を確認するようなテキストマイニングの応用例では、動的に与えられた文書集合中のキーワードの数え上げが必須である。数え上げ計算を高速に行うためのインデックス構造として、リレーショナル・データベースを利用することもできるが、検索条件とキーワードの出現頻度の相関分析を行う目的には、十分なパフォーマンスを提供するものではない。
そこで、このような目的に適合する、高速にマイニングを実行するためのインデックス構造及びアルゴリズムとして、本出願人に係る、特願２００５−３４９７１７号明細書に記載の技術がある。しかし、特願２００５−３４９７１７号明細書に記載されている技術だと、大規模データに対して、そこに記載されている索引構造を構築することが難しい。その主要な理由は、キーワードと、テキストマイニング・データベースに含まれる文書との関係を行列構造にマップする場合、データの規模が大きくなってその結果、データベースに含まれる文書の数が増えてくると、主記憶に全ての情報を保持することが出来なくなるからである。
すなわち、より具体的に述べると、高速にインデックスを構築するためには、キーワード文字列と、数値ＩＤとの対応を保持するマップが、主記憶上になくてはならない。また、キーワードから、対応する文書のポスティング・リスト(posting list、すなわち、文書ＩＤの配列）を検索する構造を、キーワードに対して何らかの順序（例えば、頻度順）で整列する必要があるが、この場合も、キーワード集合を保持するハッシュ構造を主記憶上に保持できないと、文書単位で分割されたインデックスのマージが困難になる。このことから、インデックス作成に必要なキーワードが全て主記憶上に保持できるような主記憶のサイズであることが本質的である。すると、主記憶のサイズは、いくら大きくても限界がある訳だから、主記憶のサイズにより、文書の集合に対してインデックス構造を作成できる、文書の数の限界が決まってくる。
ところで、米国特許第６５５３３８５号及び、http://uima-framework.sourceforge.net/ には、文書集合の各文書に自然言語処理などの技術を適用して情報を抽出し、所定のデータ構造にストアする、というフレームワークが記載されている。しかし、この開示技術も、一文書を処理して得られた情報を逐次的に処理する大規模データに関して、効率的にストアする技法については、示唆するものではない。
特開平９−２１２５２８号公報は、データベースを複数のデータ・セグメントに分割するステップを備える。これにおいて、各データ・セグメントは、データベース内の選定されたフィールドにて互いに異なるバリューを有するレンジに対応し、種々の記憶装置内にデータ・セグメントの各々を記憶するステップと、対応する各データ・セグメントを識別するためのセグメント・インデックスを記憶するステップと、選定されたフィールドの複数のレンジに対応するエントリを有するレンジ・インデックスを記憶するステップとを備え、レンジ・インデックス内の各エントリは、複数のデータ・セグメントに対し、当該レンジに対応するセグメント・インデックスを識別する。
特開２００３−２７１６４８号公報は、検索対象文書を複数のグループに分割し、グループのそれぞれについて、当該グループと、これに含まれる検索対象文書に出現するキーワードと、当該キーワードが出現する検索対象文書の数と、の情報を対応付けて記憶することを開示する。
このように、特開平９−２１２５２８号公報及び、特開２００３−２７１６４８号公報は、大規模な検索に対応するために、データベースを複数に分割して負荷分散することによって、検索を高速化することを教示する。しかし、ここに教示されている方法は、データベース検索に係るものであって、大規模テキストマイニング・データベースのインデックス作成に適用することはできない。
特願２００５−３４９７１７号明細書 米国特許第６５５３３８５号 特開平９−２１２５２８号公報 特開２００３−２７１６４８号公報 http://uima-framework.sourceforge.net/
この発明の目的は、コンピュータの主記憶の容量などの物理的制約に拘わらず、テキストマイニング・システムなどに使用される大規模データベースの文書に含まれるキーワードのインデックス作成を高速に処理することを可能ならしめるシステム、方法及びプログラムを提供することにある。
上記目的は、本発明に従い、データベースの文書を複数に分割し、その分割した各々の文書の集合に対して、インデックス作成処理を行って、部分インデックス・ファイルを作成し、そうして作成したインデックス・ファイルを、分割前のもとのデータベース全体のインデックスとなるようにマージすることによって達成される。
なお、本発明の文脈で、キーワードとは、単語やフレーズ等の抽出情報を表現する一般の文字列を示し、文書とは、その各々がいくつかのキーワードを含むある集計単位であり、テキストマイニング・システムなどに使用される大規模データベースは、そのような文書の有限集合を含む。そのような文書の単位の例として、コールセンターにおける一回の電話のログ、メールデータへースの１つのメール、Ｗｅｂデータにおける１つのＨＴＭＬファイル、ブログにおける１つの記事、などが挙げられる。
さて、本発明によれば、先ず、文書集合の全体は、互いに共通部分のない部分集合の和に分解される。
次に、上記で分割された各部分集合に対して、その部分集合内で出現するキーワードの集合を、キーワードのハッシュ値をある固定の整数値で割った余りでグルーピングし、これにより、各グループに対するインデックス・ファイルが作成される。この固定の整数値をグループ数と呼び、キーワードのハッシュ値を、そのグループ数で割った余りをグループ番号と呼ぶ。なお、グループ数は、文書集合の全体を分けた部分集合の数とは独立に、事前に決めておく。
次に、そのようにして文書の各部分集合毎に用意されたインデックス・ファイルについて、同じグループ番号をもつものどおしが、マージされる。これによって、個々のグループ番号に対応する統合されたインデックス・ファイルが生成される。しかし、そのようなインデックス・ファイルは、グループ番号の個数だけ存在し、まだ、文書集合の全体に対応するインデックスになっていない。そこで次に、そのようなグループ番号の個数だけあるインデックス・ファイルをさらにマージして、文書集合の全体に対応するインデックス・ファイルが生成される。
この発明によれば、文書集合の全体を分割し、その分割された部分集合において、キーワードに基づくグループ数の概念によりさらに処理を細分し、その細分化された単位で部分的なインデックスを生成するようにすることによって、限られた主記憶容量の範囲内でも、インデックス作成のためのキーワード・データをすべて主記憶容量にロードして高速処理することが可能となる。さらに、その後の統合したインデックス・ファイルを作成する処理は、大量の主記憶容量を要する訳ではないので、限られた主記憶容量のコンピュータ・システムでも、大規模なテキストマイニング・システムのデータベースのインデックスを高速に作成することが可能ならしめられる、という顕著な効果が得られる。
以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。
図１を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・パス１０２には、ＣＰＵ１０４と、主記憶（ＲＡＭ）１０６と、ハードディスク・ドライブ（ＨＤＤ）１０８と、キーボード１１０と、マウス１１２と、ディスプレイ１１４が接続されている。ＣＰＵ１０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標） ４、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１０６は、好適には、２ＧＢ以上の容量をもつものである。ハードディスク・ドライブ１０８は、テキストマイニング用大規模データベースとそのインデックス・ファイルを格納するために、２００ＧＢ以上の容量をもつものであることが望ましい。
ハードディスク・ドライブ１０８には、個々に図示しないが、オペレーティング・システム及びテキストマイニング用大規模データベースのデータが、予め格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃ ＯＳ（商標）などの、ＣＰＵ１０４に適合する任意のものでよい。
ハードディスク・ドライブ１０８にはまた、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）などの任意のプログラム言語処理系も格納されている。このプログラム言語処理系は、以下で説明する、テキストマイニング用データベースのインデックス作成のためのツールを作成し、維持するために使用される。使用するプログラム言語としては、ハッシュ・テーブルをサポートするものであことが望ましい。特にＪａｖａは、java.util.Hashtableなどのハッシュ・テーブルの機能を、ライブラリで提供する。Ｃ、Ｃ＋＋、Ｃ＃などの処理系でも同様の機能が提供されるが、もし所望の機能がない場合は、この分野の熟練した当業者なら、独自に作成することができるはずである。
ハードディスク・ドライブ１０８にはさらに、プログラム言語処理系でコンパイルするためのソースコードを書くためのテキスト・エディタ、及び、Ｅｃｌｉｐｓｅ（商標）などの開発環境を含んでいてもよい。
キーボード１１０及びマウス１１２は、オペレーティング・システムまたは、ハードディスク・ドライブ１０８から主記憶１０６にロードされ、ディスプレイ１１４に表示されたプログラム（図示しない）を起動したり、、文字を打ち込んだりするために使用される。
ディスプレイ１１４は、好適には、液晶ディスプレイであり、例えば、ＸＧＡ（１０２４×７６８の解像度）、またはＵＸＧＡ（１６００×１２００の解像度）などの任意の解像度のものを使用することができる。ディスプレイ１１４は、図示しないが、本発明に係るデータベース・インデックス作成ツールの操作画面を表示するために使用される。この画面に、キーボード１１０で所定のパラメータやファイル名を入力し、表示されている所定のボタンをマウス１１２でクリックすることにより、キーワード作成処理が開始される。
次に、図２を参照して、テキストマイニング用データベースの一般的な構造を説明する。図２に示すように、テキストマイニング用データベース２０２は、文書id = 1, 2, 3 ・・・を付与された複数の文書をもつ。そのような文書の単位の例として、コールセンターにおける一回の電話のログ、メールデータへースの１つのメール、Ｗｅｂデータにおける１つのＨＴＭＬファイル、ブログにおける１つの記事、などがある。文書の数は、多くの場合、１０万のオーダーであり、場合により、１００万以上のオーダーの文書をもつデータベースであることもある。
各文書には、テキストマイニングの分野で周知の技法により、当該文書から抽出された、１つまたはそれ以上のキーワードが関連付けられている。各文書からキーワードを抽出する技法は、特開２００１−８４２５０、特開２００２−２５１４０２、及び特開２００５−２４６４４０等に記述されている技法が知られているが、本発明の主題ではないので、ここでは詳述しない。図２の例では、id=1の文書から、phone, internet, mailが抽出されてid=1の文書に関連づけられ、id=2の文書から、mail, networkが抽出されてid=2の文書に関連づけられている。ここで、単一の文書内では、単一のキーワードは重複カウントされないことに留意されたい。
尚、図２では、キーワードの例として、英単語が示されているが、日本語その他の任意の言語で、構文解析によりキーワードを抽出する技術は確立しているので、本発明の適用範囲は、言語に限定されないことを理解されたい。
しかし、このままのデータ構造では、例えば、internetを含む文書のidを列挙することも、非常に時間がかかる。そこで、このような参照を高速化するために、図３以下で説明する、いくつかのインデックスが必要となる。
図３を参照すると、先ず、キーワード文字列からIDをひくためのインデックスKW2IDと、KW2IDへのポインタでIDからキーワード文字列をひくためのインデックスID2KW とが示されている。データ構造自体としては、プログラミング言語でJava(商標)を使用する場合、例えば、java.util.Hashtableを利用することができる。
各キーワード文字列は、KW2IDテーブルの keyword_i (i=1, 2, ..., k) に、ID(id_i)と一緒に格納される。key_len_i は、keyword_i の文字列長を格納する。例えば "CPU" なら key_len_iの値は3である。
キーワード文字列 wからIDをひくときは、wのハッシュ値iに対し、pointer_iの値が指し示す keyword_i を調べる。これが wと一致する場合は id_iが求めるIDになる。一致しない場合は、next_pointer_i が指し示す別のキーワードを調べ、 wと一致するかどうか調べる。これを wが見つかるまで繰り返す。next_pointer_i の値が、次のキーワードが存在しないことを示す値（例えば -1にしておく）の場合は、wはインデックスに登録されていないことになる。
IDからキーワード文字列をひくときは、ID2KW の pointer_iを読み（各pointer_iは8バイト固定長なので、IDがわかれば ID2KW 内の pointer_i の位置に直接とべる）、その pointer_iの値が指し示す KW2ID 内のキーワード文字列 keyword_iを読む。
次に、図４を参照して、キーワードから文書へのポインタを与えるインデックスである、K2Dについて説明する。図４において、ランク・テーブル４０２は、各々のキーワードと、そのキーワードの全文書中での出現頻度との対応を示す表である。ランク・テーブル４０２において、キーワードは実際は、internetのような具体的な文字列ではなく、図３でkeyword_iで示されている、キーワードのid値として格納されている。例えば、internetというキーワードは、図４によると、全文書中で、105672回現れる。ランク・テーブル４０２では、キーワードの欄は、その頻度で、降順にソートされている。
文書分布テーブル４０４は、各キーワード毎に、そのキーワードが現れる文書idの集合を配列している。例えば、文書分布テーブル４０４の１行目は、ランク・テーブル４０２の最初のキーワードinternetが現れる文書の文書idを配列している。なお、好適な実施例では、文書idは、４バイトからなる。通常文書idは非負整数で表すことが多いが、4バイトで整数を2の補数表現した場合には 0 から 2147483647 までの値を表現できる。したがって多くの場合4バイトで表現できる。むろん、必要に応じてより大きなバイト数を確保する実施方法もあり得る。
さて、ランク・テーブル４０２の出現頻度の欄は、対応する文書分布テーブル４０４の行に対するポインタの役目も果たす。例えば、internetというキーワードに対する出現頻度の欄は、文書分布テーブル４０４の対応する行である、{0,1,3,4,7...}をポインタ４１０で、指し示す。なお、{0,1,3,4,7...}は、文書idの並びで、文書分布テーブル４０４では、升目に入った数字であらわされているものである。同様に、windowsというキーワードに対する出現頻度の欄は、文書分布テーブル４０４の対応する行である、{1,2,5,7,8...}をポインタ４１２で、指し示す。
次に、図５を参照して、文書からキーワードへのポインタを与えるインデックスである、D2Kについて説明する。図５において、ポインタ・テーブル５０２は、単に、文書idを1から始まって最後の文書idまで、リストするものである。キーワード分布テーブル５０４は、各文書毎に、その文書から抽出されたキーワードのidの集合を配列するものである。例えば、図５では、文書idが1の文書から、100,102,270,564,1008, ...というキーワードidをもつキーワードが抽出されたことが示されている。同様に、文書idが2の文書から抽出されたキーワードのキーワードidは、7,64,195,197,700である。ポインタ・テーブル５０２の文書idの欄は、対応するキーワード分布テーブル５０４の対応する行を指し示す。例えば、文書idが1の欄は、キーワード分布テーブル５０４の、{100,102,270,564,1008...}という行を、ポインタ５１０で指し示す。同様に、文書idが2の欄は、キーワード分布テーブル５０４の、{7,64,195,197,700}という行を、ポインタ５１２で指し示す。なおここで、{100,102,270,564,1008...}などは、キーワードidの並びで、キーワード分布テーブル５０４では、升目に入った数字であらわされている。好適な実施例では、キーワードidも、４バイトからなる。
ここまでの説明で、これらのインデックス構造自体は、従来から知られており、この発明の特徴ではないことを理解されたい。ここから、従来技術では知られていない、本発明の説明を行うことにする。
先ず、本発明において、キーワード・グループ数Gという固定の整数値が選ばれる。この数Gは、次のように使用される。すなわち、任意のキーワードwに対して、あるハッシュ関数hashを作用させる。その結果をGで割った余りhを、キーワードのグループ番号と呼ぶことにする。
数式で書くと、h = hash(w) mod G となる。
Javaの記法では、h = hash(w) % G; である。
ここで使用するhash関数は、定義域が想定されるキーワードw全体に亘り、値が整数であるような任意のものでよい。例えば、これに限定されるものではないが、Javaで用意されている、HashCode()という関数を使用することができる。これは、下記のようなアルゴリズムで、長さnの文字列のハッシュ値を返す。
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
ここで、s[i] は文字列の i 番目の文字、n は文字列の長さ、^ はべき乗を示す。
次に、文書数による、データベースの文書の分割について説明する。本発明によれば、データベースの文書全体の集合 Dが
、D = D1∪D2∪...∪Dk のように、分割される。
このとき、任意のi≠jにつき、Di∩Dj = Φである。
数学的に言うと、集合 Dが、D1,D2,...,Dkに、直和分割される、ということになる。
例えば、データベースが、1000000個の文書からなる、
すなわち、D = {1,2,...,1000000} とすると、これを20分割して、
D1 = {1,2,...,50000}
D2 = {50001,50002,...,100000}
D3 = {100001,100002,...,150000}
.......
D20 = {950001,950002,...,1000000} となる。この例では、１つの部分集合が50000の文書を含むように分割されるが、コンピュータの主記憶の容量や、上記キーワード・グループの個数Gに応じて、別の値を選ぶこともできる。また、この例では、等しい文書数の部分集合に分割しているが、等しくない文書数の部分集合に直和分割してもよい。
次に上記のように分割された、１つの文書部分集合におけるインデックス作成処理について、図６のフローチャートを参照して説明する。これは、h番目のキーワード・グループについての処理である。上述したように、hというのは、キーワードのハッシュ値を、キーワード・グループの数Gで割った余りであるから、h = 0, 1, ..., G-1である。よって、図６のフローチャートは、１つの文書部分集合につき、hの値を変えながら、G回繰り返すことになる。なお、以下のフローチャートでは、説明の都合上、キーワード・グループを、キーワードのハッシュ値を、キーワード・グループの数Gで割った余りに1を加えた数として説明する。すると、h = 1, ..., Gである。というのは、ＣやＪａｖａでは、配列のインデックスは0から始まるので、h = 0, 1, ..., G-1の方がこれらのコンピュータ言語に馴染むが、説明の便宜上、少し直感的でなくなるためである。実装的には、h = 0, 1, ..., G-1でも、h = 1, ..., Gでも、どちらでもよいことに留意されたい。h = 1, ..., Gとした場合は、キーワード・グループの数Gで割った余りが0である場合を、キーワード・グループ1とする。
さて、図６において、先ず、当該の文書部分集合において、ステップ６０２で、まだ読み出されていない文書があるかどうかが、判断される。もしその判断が否定的であれば、全ての文書を読み出した、ということなので、図６のフローチャートは、終了する。まだまだ読み出されていない文書があると、ステップ６０４で、次の文書が、当該の文書部分集合から読み出される。
こうして１つの文書が読み出されると、ステップ６０６では、その文書のキーワードに関して、ハッシュが計算され、さらにそのハッシュ値についてGによる整数割り算が行われる。その余りの値がhであると、そのキーワードが、主記憶１０６（図１）中の所定のバッファメモリに保持され、その余りの値がh以外だと、単に無視される。図２に示されているように、１つの文書には通常、複数のキーワードが関連付けられているので、ステップ６０６では、ステップ６０４で読み出された１つの文書に関連付けられた全ての複数のキーワードにつき、ハッシュ値とそのGによる余りが計算される。なお、ステップ６０６では、折角１つの文書に関連付けられた、すべてのキーワードを処理するので、後の処理のため、そのハッシュ値のGによる整数割り算の余り値とともに、バッファメモリに保持しておけばよいように思われるかもしれない。しかし、通常、１つの文書部分集合に関連する全てのキーワードを保持するには、主記憶１０６の使用可能な容量は十分ではない。そこで、本発明によれば、１つのキーワード・グループhに属するキーワードのみが、主記憶１０６に保持される。
ステップ６０８では、このようにして、バッファメモリに保持された、キーワード・グループhのキーワードについて、インデックスの構築が行われる。ステップ６０８は、実際は、サブルーチンとしてあらわされるような詳細な処理を含むので、後で詳しく説明する。
ステップ６０８の処理が終わると、ステップ６０２の判断ステップに戻り、まだ読み出していない文書がある限り、ステップ６０４、６０６及び６０８を繰り返す。こうして全ての文書が読み出されると、ステップ６０２での判断が否定的になるので、そこで処理は終わる。キーワード・グループhに属するキーワード群について、インデックスの作成が完了すると、キーワード・グループhに属するキーワード群を保持していた主記憶１０６の領域が開放され、hが１つ増分され、図６のフローチャートの処理が、ステップ６０２から、文書部分集合の最初の文書から開始される。
こうして結局、図６のフローチャートの処理は、k個の文書部分集合毎に、G回実行されるので、結果的に、k × G回実行されることになる。
次に、図７を参照して、図６のステップ６０８のインデックス作成処理を詳細に説明する。図７において、ステップ７０２で、初期化、すなわち、設定ファイルから設定情報を主記憶１０６に読み込んだり、文書が格納されているファイルをオープンしたりする処理を行う。設定情報には、インデックスのファイルを書き出すためのディレクトリ名などの情報を含む。なお、図７のフローチャートが対象とするのは、１つの文書部分集合と、その文書部分集合の文書に関連付けられた、１つのキーワード・グループhに属するキーワード群であることに留意されたい。
より詳細に具体的に説明すると、初期化ステップ７０２では、ＫＷプラグイン、Ｋ２Ｄプラグイン及びＤ２Ｋプラグイン、という３つのプログインが初期化される。ここでプラグインという言い方をしたが、単に、個別の処理プロセスくらいの意味で理解してよい。ＫＷプラグインは、図３に示すインデックス構造を作成するためのものであり、Ｋ２Ｄプラグインは、図４に示すインデックス構造を作成するためのものであり、Ｄ２Ｋプラグインは、図５に示すインデックス構造を作成するためのものである。これらのプラグインは、好適な実施例では、Ｊａｖａ（商標）で書かれているが、Ｃ、Ｃ＋＋、Ｃ＃など、その他の任意の適当なプログラミング言語で作成することもできる。
ステップ７０４では、文書が残っているかどうか、すなわち、１つの文書部分集合において、まだ読み込む文書が残っているかどうかが判断される。まだ文書が残っているなら、processDocumentと名付けられたステップ７０６に進む。そうでなく、文書部分集合の全ての文書が読み出されたなら、Serializeと名付けられたステップ７０８に進む。
processDocumentと名付けられたステップ７０６について説明する。processDocumentは、１つの文書を引数とする。ステップ７０６において、読み出された、引数として与えられた文書に関して、ＫＷプラグインは、その文書に関連するキーワードに、文書部分集合でなく、文書集合全体に亘って一意的なＩＤを付与する。このとき、図６のステップ６０６で、１つのキーワード・グループhに属するキーワード群の情報が、主記憶１０６に、java.util.Hashtableなどのハッシュ構造でロードされているので、ＫＷプラグインは、そのキーワードで、規定されたメソッドを用いて、そのハッシュ構造に問い合わせする。
このとき、もし既にキーワードがそのハッシュ構造に既に存在していれば、そのキーワードのＩＤが返される。もし存在していなければ、キーワードに既に付与されている最後のＩＤに１を加えた値が、そのキーワードに付与され、そのキーワードとＩＤは、そのハッシュ構造に、規定されたメソッドを用いて登録される。また、その付与されたＩＤは、キーワードに既に付与されているＩＤとして、主記憶の所定位置に参照可能に上書き保持される。
このとき、問いあわせするのは、キーワード・グループhに属するキーワード群だけなのであるが、その問い合わせするもととなるキーワード自体が、ハッシュ関数とGによる割り算の計算でキーワード・グループhに属する、と分かっているので、上記キーワード・グループhに関するハッシュ構造にそのキーワードがないことが分かると直ちに、部分集合でない、文書集合全体を通して、そのキーワードが、今までなかったことがわかる。
これにより、キーワードをキーワード・グループに分けることの効果が明らかである。すなわち、もしこのようなキーワード・グループに分けないと、上記のような問い合わせを行うために、今まで出会ったキーワード全体を主記憶１０６にすべてロードしなくてはならないが、それは、データベースの文書数や主記憶のサイズを考慮すると、多くの場合、困難である。すると、そのようなキーワードとＩＤのハッシュ配列情報は、一旦ハードディスク１０８に配置して、部分的に読み出す必要があり、どうしても処理速度が著しく低下してしまう。本発明によれば、キーワードを、キーワード・グループに分けることにより、今まで出会ったキーワード全体を主記憶１０６にすべてロードすることが可能となり、キーワードＩＤの照会と付与の処理が高速化される。
さて、ＫＷプラグインは、この時点で、ハードディスク１０８上にオープンされているＫＷインデックス・ファイルに、キーワードとＩＤの対応を書き出す。ＫＷインデックス・ファイルのデータ構造は、図３に関連して既に説明したものである。なお、Ｋ２Ｄインデックス・ファイル（図４）、及びＤ２Ｋインデックス・ファイル（図５）とは異なり、ＫＷインデックス・ファイルは、全体の文書集合を通して、キーワード・グループ毎に１つ作成される。
Ｄ２Ｋプラグインは、processDocumentに引数として与えられた文書から、（文書ＩＤ、キーワードＩＤ）の組を、主記憶１０６に保管する。ここで、キーワードＩＤは、直前にＫＷプラグインが付与したものを使う。こうして、全ての文書を処理した後、当該部分文書のキーワード・グループhに関する、図５に示すような文書キーワード行列が、主記憶１０６上に構築されることになる。
processDocumentでは、Ｋ２Ｄプラグインは、何もしない。こうして処理は、ステップ７０４の判断に戻る。
次に、図７のフローチャートで、ステップ７０４で判断が否定的、すなわち、文書部分集合の全ての文書を読み出したと判断されると、serializeと書かれたステップ７０８で、Ｄ２Ｋプラグインは、主記憶１０６に保管されている文書キーワード行列を、Ｄ２Ｋインデックス・ファイル（図５）として、ハードディスク１０８に書き出す。Serializeステップ７０８では、ＫＷプラグインも、Ｋ２Ｄプラグインも、何もしない。
図７のフローチャートで、serializeステップ７０８の次に、postProcessと書かれたステップ７１０が実行される。postProcessステップ７１０では、Ｋ２Ｄプラグインが、Ｄ２Ｋプラグインを介して、Ｄ２Ｋが構築した文書キーワード行列を受け取り、転置行列構造（図４に示す、キーワード文書行列）であるＫ２Ｄインデックス・ファイルとして、ハードディスク１０８に書き出す。
分割されたインデックス・ファイルの作成処理は、これで完了であるが、Ｄ２Ｋから、転置行列構造としてのＫ２Ｄインデックスを作成する処理は、もう少し詳しく説明した方がよいと思われるので、図８と図９のフローチャートを参照して説明する。
図８を参照すると、ステップ８０２では、Ｋ２Ｄプラグインによって、key2docという空のテーブルが作成される。次にステップ８０４では、主記憶１０６上にＤ２Ｋプラグインによって構築された文書キーワード行列（ここでは、doc2keyと呼ぶ）文書ｉｄがリストされる。すなわち、ここでは、文書キーワード行列doc2keyが主記憶上に存在することが前提とされる。
なお、doc2key自体は、メモリ上に保持されている、好適にはＪａｖａで作成されたハッシュ・テーブルで、文書ｉｄをキーにして、キーワードｉｄの配列を返す。key2docも好適にはＪａｖａで作成されたハッシュ・テーブルであり、キーワードｉｄをキーにして、対応する文書ｉｄを返す。
ステップ８０６では、読み出していない文書ｉｄはまだあるかどうかが判断される。その判断が肯定的、すなわち、読み出していない文書ｉｄがまだあるなら、ステップ８０８で、次の文書ｉｄが読まれる。ステップ８１０で、doc2keyから、読み出した文書ｉｄに対応するキーワードのリスト（配列ともいう）Lが取得される。そうして、ステップ８１２では、リストL中のすべてのキーワードｉｄについて、すべての対（キーワードｉｄ,文書ｉｄ）をkey2docに入れる処理が行われる。こうして、ステップ８０６の判断に戻る。
ステップ８０６での判断が否定的、すなわち、すべての文書ｉｄが読み出されたなら、WriteIndexFilesという名前のサブルーチン８１４の処理が行われる。
図９は、WriteIndexFilesサブルーチンの詳細を示すフローチャートである。図９のステップ９０２では、key2docテーブルに登録されているキーワードｉｄがリストされる。ステップ９０４では、そのリスト中で、キーワードｉｄが、昇順にソートされる。
ステップ９０６では、読み出していないキーワードｉｄがまだ残っているかどうかが判断される。そして、読み出していないキーワードｉｄがまだ残っているなら、ステップ９０８で、次のキーワードｉｄが読まれる。
ステップ９１０では、key2docから、読み出したキーワードｉｄに対応する文書ｉｄのリストLが取得される。ステップ９１２では、（キーワードｉｄ,L.Length）の対が、ランク・テーブル・インデックスに書き出される。なお、L.Lengthというのは、リストLの長さをあらわす。ランク・テーブル・インデックスは、図４に、例示されているようなものである。
ステップ９１４では、リストLが、文書分布テーブル・インデックスに書き出される。文書分布テーブル・インデックスも、図４に例示されているようなものである。
こうしてステップ９０６の判断ステップに戻り、読み出していないキーワードｉｄがまだ残っている限り、ステップ９０８、９１０、９１２及び９１４が繰り返され、ステップ９０６の判断が否定的、すなわち、全てのキーワードｉｄが読み出されたと判断されると、処理は終了となる。
以上で、部分文書集合毎のキーワード・グループ別のＤ２Ｋインデックス・ファイル（図５）、及びＫ２Ｄインデックス・ファイル（図４）を作成する処理の説明が完了したので、次に、これらの個別のインデックスを統合して、文書集合全体に対応するインデックスを作成する処理について説明する。なお、図７のフローチャートに示す処理では、ＫＷインデックス・ファイルも作成されるが、この発明の好適な実施例では、ＫＷインデックスはもともと、文書集合全体に対応する単一のものとして作成されるので、マージする必要はないことを理解されたい。
次に、図１０を参照して、キーワード・グループh（h = 1...G）における、部分文書集合毎のＤ２Ｋインデックスのマージ処理について説明する。図１０のステップ１００２では、中間doc2keyインデックス・ファイルDh[1], Dh[2],..., Dh[k]がオープンされる。kは、部分文書集合の個数である。Dh[i]というのは例えば、部分文書集合Diの、キーワード・グループhにおけるＤ２Ｋインデックス・ファイルであり、その作成処理は、図７のフローチャートに関連して説明済みである。
次に、ステップ１００４では、空のインデックス・ファイルFMD[h]が作成される。次のステップ１００６では、変数i = 1とセットされ、ステップ１００８では、iがkに達したかどうかが判断される。iがkにまだ達してなければ、ステップ１０１０で、まだ読んでいない文書idが、Dh[i]に残っているかどうかが、判断される。
もしその判断が肯定的であるなら、ステップ１０１２で、Dh[i]から次の文書idが読まれる。そうして、ステップ１０１４で、Dh[i]から、読まれた文書idに対するキーワードidのリストLが取得される。次に、ステップ１０１６では、リストL中のすべてのキーワードidにつき、対(キーワードid,文書id)がFMD[h]に書き出される。その後処理は、判断ステップ１０１０に戻る。
ステップ１０１０で、Dh[i]の全ての文書idが読まれた、と判断されたら、ステップ１０１８で、iが1だけ増分されて、判断ステップ１００８に戻る。ここで、iがkを超えれば、処理は完了であり、iがkを超えていなければ、判断ステップ１０１０に進む。
図１０のフローチャートは、単一のキーワード・グループhに対する、中間的なＤ２Ｋインデックス・ファイルFMD[h]を作成する処理であった。従って、実際は、キーワード・グループ1からキーワード・グループGまでについてのG回の処理を、各々図１０のフローチャートで行うことにより、FMD[i](i = 1,2, ...,G)というG個の中間的なＤ２Ｋインデックス・ファイルが作成される。
次に、図１１のフローチャートを参照して、最終的なＤ２Ｋインデックス・ファイルを作成する処理について説明する。図５に示すように、Ｄ２Ｋインデックス・ファイルは、実質的には、ポインタ・テーブル(PT)と、キーワード分布テーブル(DT)とからなることに改めて留意されたい。
図１１を参照すると、ステップ１１０２では、中間doc2keyインデックス・ファイルFMD[1], FMD[2],...,FMD[G]がオープンされる。これは、図１０のフローチャートで説明した処理で作成したものである。
ステップ１１０６では、各FMD[i](i = 1,2, ...,G)から、文書idが小さい順に１つ文書idを読み、それをバッファにストアする、という処理が行われる。このバッファとは、主記憶１０６に確保された所定の領域である。
次にステップ１１０８では、バッファにまだ、読み出していない文書idがあるかどうかが判断され、もしあるなら、ステップ１１１０に進む。ステップ１１１０では、バッファに格納されている最小の文書idが選ばれ、それが仮にDIDとされる。例えば、DIDという変数に、最小の文書idを代入する。
ステップ１１１２では、DIDに対応するキーワード・リストが、FMD[i](i = 1,2, ...,G)のうちの、DIDを含むFMD[i]（複数ありえる）から取得され、それぞれ、単一のリストLにマージされる。そうして作成されたリストLは、DTに書き出される。
ステップ１１１４では、バッファから、DIDを除去する。より正確に言うと、DIDの値をもつ、文書idのエントリを除去する。そうして、さきほどのDIDを含んでいた、FMD[i]（複数ありえる）から、次の文書idを、やはり文書idが小さい順に読み、バッファにストアする、という処理が行われる。
このようにして、バッファにストアされた文書idのエントリがなくなるまで、ステップ１１１０、１１１２、及び１１１４が行われ、バッファにストアされた文書idのエントリがなくなって、判断ステップ１１０８での判断が否定的になると、処理は、ステップ１１１６に行く。
ステップ１１１６では、DTが上から順に読まれ、文書idを見つけた場所を単に記録するという処理で、PTが作成される。
次に、図１２を参照して、キーワード・グループh（h = 1...G）における、部分文書集合毎のＫ２Ｄインデックスのマージ処理について説明する。先ず、ステップ１２０２では、中間key2docインデックス・ファイルRh[1], Dh[1], ..., Rh[k], Dh[k]がオープンされる。kは、部分文書集合の個数である。Dh[i]というのは、部分文書集合Diの、キーワード・グループhにおける文書分布テーブル（図４）であり、また、Rh[i]というのは、部分文書集合Diの、キーワード・グループhにおけるランク・テーブル（図４）であり、それらの作成処理は、図７のフローチャートに関連して説明済みである。なお、図１０でも、Dh[i]という記号が使われており、そこでは、Dh[i]は、キーワード・グループhにおける、部分文書集合毎の中間doc2keyをあらわしていたが、Dh[i]という記号は、図１０及び図１２の各々で、仮変数ファイル名として使われているので、混乱はないものと思量する。
さて、ステップ１２０４では、空のインデックス・ファイルFMR[h],FMD[h]が作成される。ステップ１２０６では、各Rh[i]からキーワードidが１つ読まれ、それらが、バッファにストアされる。このバッファとは、主記憶１０６に確保された所定の領域である。ステップ１２０８では、バッファにキーワードidが残っているかどうかが判断される。もしまだ残っていれば、ステップ１２１０に進む。
ステップ１２１０では、バッファにストアされているキーワードidのうち、最小のキーワードidを選び、それをKIDとする処理が行われる。実際上、KIDという変数に、最小のキーワードidの値が代入される。
ステップ１２１２では、KIDを含むRh[i]中のKIDの出現頻度が合計される。このようなRh[i]は、複数あり得る。そうして、KIDとその合計頻度が、FMR[h]に書き出される。
ステップ１２１４では、KIDに対応する、Dh[i]中の文書idのリストが単一のリストLにマージされ、そのリストLが、FMD[h]に書き出される。
ステップ１２１６では、バッファからKIDが除去され、KIDを含んでいた全てのRh[i]から、次のキーワードidが読み出され、それらが、バッファにストアされる。こうして処理は、判断ステップ１２０８に戻り、バッファにキーワードidが残っている限り、ステップ１２１２、１２１４及び１２１６が繰り返される。
バッファに残っているキーワードidがなくなり、判断ステップ１２０８での判断が否定的になると、処理は完了である。このマージ処理によって作成されるインデックスFMR[h],FMD[h]は、入力のインデックスと全く同じフォーマットである。この時点では、キーワードはidの昇順に並び、頻度の降順には並んでいない。頻度順のソートは次の処理（図１３のフローチャートで示す処理）で行う。
図１２のフローチャートは、単一のキーワード・グループhに対する、中間的なＫ２Ｄインデックス・ファイルFMR[h],FMD[h]を作成する処理であった。従って、実際は、キーワード・グループ1からキーワード・グループGまでについてのG回の処理を、各々図１２のフローチャートで行うことにより、FMR[i], FMD[i](i = 1,2, ...,G)という、それぞれG個の中間的なＫ２Ｄインデックス・ファイルが作成される。
図１３は、図１２のフローチャートの処理で作成された、中間的なＫ２Ｄインデックス・ファイルFMR[i], FMD[i](i = 1,2, ...,G)から、文書集合全体に対応する最終的なＫ２Ｄインデックス・ファイルを作成する処理を示すフローチャートである。FMR[i]は、図４に示すランク・テーブルに相当し、FMD[i]は、図４に示す文書分布テーブル４０４に相当する。
図１３において、ステップ１３０２では、中間key2docインデックス・ファイルFMR[1], FMD[1],FMR[2], FMD[2],...,FMR[G], FMD[G]がオープンされる。
ステップ１３０４では、FMR[i]から、キーワードidが頻度でソートされたインデックス・ファイルFMRs[i]が作成される。このことは、i = 1, 2, ..., Gにつき、行われる。本発明によれば、FMR[i]は、単一のキーワード・グループiのみに対応するように作成されたものなので、それ単独だと、その全体を主記憶１０６に収めることができる程度の大きさである。従って、このソート処理は、主記憶上で、高速に行うことができる。ソートのアルゴリズムは、quick sort, Shell sortなど、既知の任意のソート・アルゴリズムを用いることができる。
ステップ１３０６では、変数iに1が代入される。判断ステップ１３０８では、変数iが、キーワード・グループの個数Gを超えていないかどうかが判断され、超えていないなら、CreateTempDTと名付けられたサブルーチン１３１０が実行され、ステップでiが1だけ増分されて、ステップ１３０８での判断が行われる。
ステップ１３０８で、iがGを超えた、と判断されると、CreateFinalIndexと名付けられたサブルーチン１３１４が実行されて、最終的なＫ２Ｄインデックス・ファイルの作成処理が完了する。
ここまでの説明では、最終的なインデックス作成の説明としては、完結していないので、次にステップ１３１０で示したサブルーチンCreateTempDTと、ステップ１３１４で示したサブルーチンCreateFinalIndexを順次、詳述する。
図１４は、サブルーチンCreateTempDTの処理を示すフローチャートである。図１４のステップ１４０２では、所与のiにつき、FMR[i], FMRs[i], FMD[i]がオープンされる。この所与のiとは、図１３のフローチャートで、ステップ１３０６で与えられ、ステップ１３１２で増分されているものである。また、FMR[i], FMRs[i], FMD[i]は、図１３のフローチャートで与えられているものと同じものである。
ステップ１４０４では、上記所与のiにつき、空のインデックス・ファイルFMDs[i]が作成される。そして、ステップ１４０６では、FMRs[i]に、まだ読み出されていないキーワードidがあるかどうかが、判断される。
そして、もしFMRs[i]に、まだ読み出されていないキーワードidがあるなら、処理は、ステップ１４０８に進み、ステップ１４０８では、FMRs[i]を読んで、次のキーワードid KID[1], KID[2], ..., KID[m]と、その頻度が取得される。
ステップ１４１０では、FMR[i]を読んで、KID[j] (j = 1,2,...,m)のポインタが取得される。次にステップ１４１２では、FMD[i]を読んで、KID[j] (j = 1,2,...,m)に対応する文書idのリストDLIST[j] が取得される。
ステップ１４１４では、DLIST[j] (j = 1,2,...,m)をFMDs[i]に書き出す処理が行われる。こうして処理は、判断ステップ１４０６に戻り、FMRs[i]に、まだ読み出されていないキーワードidがある限り、ステップ１４０８、１４１０、１４１２及び１４１４が行われ、判断ステップ１４０６で、FMRs[i]から全てのキーワードidが読まれた、と判断されたなら、サブルーチンCreateTempDTが完了する。
以上説明したように、所与のiにつき、サブルーチンCreateTempDTは、FMDs[i]を書き出すので、図１３で、i = 1,2,..,Gまでステップ１３１２すなわち、サブルーチンCreateTempDTの処理が完了し、ステップ１３１４、すなわちサブルーチンCreateFinalIndexが呼ばれる直前では、FMDs[i] (i = 1,2,...,G)が揃っていることになる。
図１５は、サブルーチンCreateFinalIndexの処理を示すフローチャートである。図１５のステップ１５０２では、中間key2docインデックス・ファイルFMRs[i], FMDs[i] (i = 1,2,...,G)がオープンされる。ステップ１５０４では、空のインデックス・ファイルRT及びDTが作成される。
ステップ１５０６では、各FMRs[i] (i = 1,2,...,G)から１つキーワードidが読み出され、バッファにストアされる。そうしてステップ１５０８では、バッファにキーワードidがまだあるかどうかが判断される。
バッファにまだキーワードidがあるなら、処理はステップ１５１０に進み、そこでは、バッファ中で最大の頻度をもつキーワードidが選択される。そのようなキーワードidの値を、KIDという変数値に代入し、KIDの所属するキーワード・グループpを確認する。そのようなキーワード・グループpは、KIDを値をもつキーワードidが取り出されたFMRs[i]のiの値を調べることによって、確認される。
ステップ１５１２では、KIDとその頻度が、RTに書き出される。次のステップ１５１４では、FMDs[p]において、KIDに対応する文書idのリストが読み取られ、そのリストがDTに書き出される。
次のステップ１５１６では、バッファからKIDの値をもつキーワードidが除去され、FMRs[p]から次のキーワードidが読み出され、バッファにストアされる。そうして処理は、判断ステップ１５０８に戻る。
ステップ１５０８で、バッファにキーワードidが残っている限り、ステップ１５１０、１５１２、１５１４及び１５１６が繰り返され、バッファにキーワードidが最早なくなると、図１５のフローチャートは、終わる。こうして、全体の文書集合に対応する最終的なインデックス・ファイルRTとDT（図４では、それぞれ、ランク・テーブル４０２と、文書分布テーブル４０４と示されている）が、ハードディスク１０８に書き出されたことになる。
以上、本発明を、一実施例に基づき説明したが、本発明の１つのキーポイントは、キーワードを、複数のキーワード・グループに分けることにより、インデックス作成処理の間、キーワード・グループ毎のKWインデックスの全体を、主記憶に保持することで、インデックス作成処理を高速化することができる。
逆に言うと、データベースに関連づけられたキーワードの数が多い場合、キーワード・グループの数を増やすことで、キーワード・グループ毎のKWインデックスのサイズを減らし、その全体が主記憶に収まるようになされる。
このような、部分インデックス・サイズのスリム化は、インデックス・ファイルのマージ処理においても、主記憶への効果的なロードを可能ならしめ、Ｄ２Ｋ及びＫ２Ｄマージ処理も容易にする。
Ｄ２Ｋ及びＫ２Ｄ以外の、適当な部分インデックス・ファイルのサイズを小さくしようとすると、部分文書集合のサイズを小さくすることが有効であることがある。こうして、部分文書集合のサイズと、キーワード・グループの数、という２つの調整パラメータを備えたことで、インデックス・ファイル作成の自由度が高まったのである。
なお、上記の実施例は、１つの文書からキーワードが構文解析などの手法で抽出され関連づけられている、テキストマイニング・データベースに関連して説明したが、１つの文書に、キーワードが関連付けられているタイプのデータベースであるなら、任意のデータベースに、本発明のインデックス作成技術を適用することができることを理解されたい。
本発明を実施するためのハードウェアのブロック図である。 データベースの各文書とキーワードの関係を示す図である。 データベースのＫＷインデックスの構造を示す図である。 データベースのＫ２Ｄインデックスの構造を示す図である。 データベースのＤ２Ｋインデックスの構造を示す図である。 部分文書集合の特定のキーワード・グループにおいて、部分インデックスを作成するためのフローチャートを示す図である。 図６のフローチャートにおける、メモリ上にストアされたキーワードからインデックスを作成するためのサブルーチンの処理のフローチャートの図である。 転置行列構造としてのＫ２Ｄインデックスを作成する処理のフローチャートを示す図である。 図８のフローチャートにおける、WriteIndexFilesサブルーチンの処理のフローチャートの図である。 部分文書集合毎のＤ２Ｋインデックスのマージ処理のフローチャートを示す図である。 最終的なＤ２Ｋインデックス・ファイルを作成する処理のフローチャートを示す図である。 部分文書集合毎のＫ２Ｄインデックスのマージ処理のフローチャートを示す図である。 文書集合全体に対応する最終的なＫ２Ｄインデックス・ファイルを作成する処理のフローチャートを示す図である。 図１３における、サブルーチンCreateTempDTの処理のフローチャートを示す図である。 図１４における、サブルーチンCreateFinalIndexの処理のフローチャートを示す図である。

Claims (17)

  1. 記憶手段をもつコンピュータの処理によって、個々の文書にキーワードが関連付けられた、複数の文書からなるデータベースのインデックスを作成する方法であって、
    前記データベースを、複数の部分文書集合に分割するステップと、
    前記個々の部分文書集合の個々の文書に関して、該文書に関連付けられたキーワードのハッシュ値を特定の数で割った余りの数（以下、キーワード・グループ番号と呼ぶ）に基づきグループ分けするステップと、
    前記部分文書集合の個々の文書を順次読み込んで、前記キーワード・グループ番号毎に第１の部分インデックス・ファイルを作成し、前記記憶手段に書き出すステップと、
    前記第１の部分インデックス・ファイルを前記記憶手段から読み込んで、同一のキーワード・グループ番号をもつもの同士でマージすることにより、複数の第２の部分インデックス・ファイルを作成し、前記記憶手段に書き込むステップと、
    前記複数の第２の部分インデックス・ファイルを前記記憶手段から読み込んで、マージすることにより、前記データベースに対応するインデックスを作成し、前記記憶手段に書き出すステップとを有する、
    方法。
  2. 前記データベースの個々の文書及び前記キーワードにはそれぞれ、前記データベースを通して一意的な文書ｉｄ及びキーワードｉｄが付与される、請求項１に記載の方法。
  3. 前記第１の部分インデックス・ファイルが、キーワードｉｄから文書ｉｄへのポインタを含むＫ２Ｄインデックスを有する、請求項２に記載の方法。
  4. 前記第１の部分インデックス・ファイルが、文書ｉｄからキーワードｉｄへのポインタを含むＤ２Ｋインデックスを有する、請求項２に記載の方法。
  5. 前記キーワードと前記キーワードｉｄの対応を示すＫＷインデックスを作成し、前記記憶手段に書き出すステップをさらに有する、請求項２に記載の方法。
  6. 前記ＫＷインデックスは、前記部分文書集合の個々の文書を順次読み出して、前記キーワード・グループ番号毎に、前記データベースに対応する単一のインデックス・ファイルとして順次書き出される、請求項５に記載の方法。
  7. 記憶手段をもつコンピュータの処理によって、個々の文書にキーワードが関連付けられた、複数の文書からなるデータベースのインデックスを作成するために、
    前記コンピュータをして、
    前記データベースを、複数の部分文書集合に分割するステップと、
    前記個々の部分文書集合の個々の文書に関して、該文書に関連付けられたキーワードのハッシュ値を特定の数で割った余りの数（以下、キーワード・グループ番号と呼ぶ）に基づきグループ分けするステップと、
    前記部分文書集合の個々の文書を順次読み出して、前記キーワード・グループ番号毎に第１の部分インデックス・ファイルを作成し、前記記憶手段に書き出すステップと、
    前記第１の部分インデックス・ファイルを前記記憶手段から読み込み、同一のキーワード・グループをもつもの同士でマージすることにより、複数の第２の部分インデックス・ファイルを作成し、前記記憶手段に書き出すステップと、
    前記複数の第２の部分インデックス・ファイルを前記記憶手段から読み込み、マージすることにより、前記データベースに対応するインデックスを作成し、前記記憶手段に書き出すステップとを実行させる、
    プログラム。
  8. 前記データベースの個々の文書及び前記キーワードにはそれぞれ、前記データベースを通して一意的な文書ｉｄ及びキーワードｉｄが付与される、請求項７に記載のプログラム。
  9. 前記第１の部分インデックス・ファイルが、キーワードｉｄから文書ｉｄへのポインタを含むＫ２Ｄインデックスを有する、請求項８に記載のプログラム。
  10. 前記第１の部分インデックス・ファイルが、文書ｉｄからキーワードｉｄへのポインタを含むＤ２Ｋインデックスを有する、請求項８に記載のプログラム。
  11. 前記キーワードと前記キーワードｉｄの対応を示すＫＷインデックスを作成し、前記記憶手段に書き出すステップをさらに有する、請求項８に記載のプログラム。
  12. 前記ＫＷインデックスは、前記部分文書集合の個々の文書を順次読み込んで、前記キーワード・グループ番号毎に、前記データベースに対応する単一のインデックス・ファイルとして順次書き出される、請求項１１に記載のプログラム。
  13. 個々の文書にキーワードが関連付けられた、複数の文書からなるデータベースのインデックスを作成するためのシステムであって、
    記憶手段と、
    主記憶と、
    前記データベースを、複数の部分文書集合に分割する手段と、
    前記個々の部分文書集合の個々の文書に関して、該文書に関連付けられたキーワードのハッシュ値を特定の数で割った余りの数（以下、キーワード・グループ番号と呼ぶ）に基づきグループ分けする手段と、
    前記部分文書集合の個々の文書を順次前記主記憶に読み込んで、前記キーワード・グループ番号毎に第１の部分インデックス・ファイルを作成し、前記記憶手段に書き出す手段と、
    前記第１の部分インデックス・ファイルを前記記憶手段から前記主記憶に読み込み、同一のキーワード・グループをもつもの同士でマージすることにより、複数の第２の部分インデックス・ファイルを作成し、前記記憶手段に書き出す手段と、
    前記複数の第２の部分インデックス・ファイルを前記記憶手段から前記主記憶に読み込みマージすることにより、前記データベースに対応するインデックスを作成し、前記記憶手段に書き出す手段とを有する、
    システム。
  14. 前記データベースの個々の文書及び前記キーワードにはそれぞれ、前記データベースを通して一意的な文書ｉｄ及びキーワードｉｄが付与される、請求項１３に記載のシステム。
  15. 前記第１の部分インデックス・ファイルが、キーワードｉｄから文書ｉｄへのポインタを含むＫ２Ｄインデックスを有する、請求項１４に記載のシステム。
  16. 前記第１の部分インデックス・ファイルが、文書ｉｄからキーワードｉｄへのポインタを含むＤ２Ｋインデックスを有する、請求項１４に記載のシステム。
  17. 前記キーワードと前記キーワードｉｄの対応を示すＫＷインデックスを作成し、前記記憶手段に書き出すステップをさらに有する、請求項１４に記載のシステム。
JP2007161524A 2007-06-19 2007-06-19 データベースのインデックス作成システム、方法及びプログラム Expired - Fee Related JP4848317B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007161524A JP4848317B2 (ja) 2007-06-19 2007-06-19 データベースのインデックス作成システム、方法及びプログラム
US12/132,301 US8190613B2 (en) 2007-06-19 2008-06-03 System, method and program for creating index for database

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007161524A JP4848317B2 (ja) 2007-06-19 2007-06-19 データベースのインデックス作成システム、方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2009003541A true JP2009003541A (ja) 2009-01-08
JP4848317B2 JP4848317B2 (ja) 2011-12-28

Family

ID=40137572

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007161524A Expired - Fee Related JP4848317B2 (ja) 2007-06-19 2007-06-19 データベースのインデックス作成システム、方法及びプログラム

Country Status (2)

Country Link
US (1) US8190613B2 (ja)
JP (1) JP4848317B2 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010191962A (ja) * 2009-02-13 2010-09-02 Fujitsu Ltd オントロジーの類似性行列の効率的な計算
JP2010262379A (ja) * 2009-04-30 2010-11-18 Nippon Telegr & Teleph Corp <Ntt> 情報検索方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体
JP2010266996A (ja) * 2009-05-13 2010-11-25 Hitachi Ltd データベース処理方法、データベース処理システム及びデータベースサーバ
JP2016177688A (ja) * 2015-03-20 2016-10-06 株式会社東芝 データ処理装置、データ処理方法およびコンピュータプログラム

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5594145B2 (ja) * 2008-11-26 2014-09-24 日本電気株式会社 検索装置、検索方法、及びプログラム
CN101546342B (zh) * 2009-05-08 2012-07-04 阿里巴巴集团控股有限公司 实现搜索服务的方法与***
US20130024459A1 (en) * 2011-07-20 2013-01-24 Microsoft Corporation Combining Full-Text Search and Queryable Fields in the Same Data Structure
KR20130049111A (ko) * 2011-11-03 2013-05-13 한국전자통신연구원 분산 처리를 이용한 포렌식 인덱스 방법 및 장치
US9256762B1 (en) * 2011-12-20 2016-02-09 Amazon Technologies, Inc. Securing a remote database
US8965921B2 (en) 2012-06-06 2015-02-24 Rackspace Us, Inc. Data management and indexing across a distributed database
US11416543B2 (en) * 2016-09-07 2022-08-16 International Business Machines Corporation Exam prefetching based on subject anatomy
US11189370B2 (en) * 2016-09-07 2021-11-30 International Business Machines Corporation Exam prefetching based on subject anatomy
CN106528510A (zh) * 2016-11-18 2017-03-22 山东浪潮云服务信息科技有限公司 一种数据处理的方法及装置
US11409820B1 (en) 2017-10-18 2022-08-09 Comake, Inc. Workflow relationship management and contextualization
US11157505B2 (en) 2017-10-18 2021-10-26 Comake, Inc. Dynamic presentation of searchable contextual actions and data
US10762060B1 (en) 2017-10-18 2020-09-01 Comake, Inc. Electronic file management
US10970349B1 (en) 2017-10-18 2021-04-06 Comake, Inc. Workflow relationship management and contextualization
US11314692B1 (en) 2017-10-18 2022-04-26 Comake, Inc. Workflow relationship management and contextualization
US11182437B2 (en) * 2017-10-26 2021-11-23 International Business Machines Corporation Hybrid processing of disjunctive and conjunctive conditions of a search query for a similarity search
US11354270B2 (en) 2020-03-09 2022-06-07 Microsoft Technology Licensing, Llc Searching for a hash string stored in an indexed array
US11947512B2 (en) 2022-02-22 2024-04-02 Microsoft Technology Licensing, Llc Feedback-based inverted index compression
US11645231B1 (en) * 2022-04-24 2023-05-09 Morgan Stanley Services Group Inc. Data indexing for distributed query execution and aggregation

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742807A (en) * 1995-05-31 1998-04-21 Xerox Corporation Indexing system using one-way hash for document service
US5973692A (en) * 1997-03-10 1999-10-26 Knowlton; Kenneth Charles System for the capture and indexing of graphical representations of files, information sources and the like
US6553385B2 (en) * 1998-09-01 2003-04-22 International Business Machines Corporation Architecture of a framework for information extraction from natural language documents
US6321232B1 (en) * 1998-12-18 2001-11-20 Xerox Corporation Method for creating a geometric hash tree in a document processing system
JP3353829B2 (ja) 1999-08-26 2002-12-03 インターナショナル・ビジネス・マシーンズ・コーポレーション 膨大な文書データからの知識抽出方法、その装置及び媒体
US6757675B2 (en) * 2000-07-24 2004-06-29 The Regents Of The University Of California Method and apparatus for indexing document content and content comparison with World Wide Web search service
GB2368670A (en) * 2000-11-03 2002-05-08 Envisional Software Solutions Data acquisition system
JP2002251402A (ja) 2001-02-26 2002-09-06 Mitsubishi Electric Corp 文書検索方法及び文書検索装置
JP4001283B2 (ja) * 2003-02-12 2007-10-31 インターナショナル・ビジネス・マシーンズ・コーポレーション 形態素解析装置および自然言語処理装置
JP2005246440A (ja) 2004-03-04 2005-09-15 Denso Corp 溶接方法
US7672956B2 (en) * 2005-04-29 2010-03-02 International Business Machines Corporation Method and system for providing a search index for an electronic messaging system based on message threads
JP4172801B2 (ja) 2005-12-02 2008-10-29 インターナショナル・ビジネス・マシーンズ・コーポレーション テキストからキーワードを検索する効率的なシステム、および、その方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010191962A (ja) * 2009-02-13 2010-09-02 Fujitsu Ltd オントロジーの類似性行列の効率的な計算
JP2010262379A (ja) * 2009-04-30 2010-11-18 Nippon Telegr & Teleph Corp <Ntt> 情報検索方法及び装置及びプログラム及びコンピュータ読み取り可能な記録媒体
JP2010266996A (ja) * 2009-05-13 2010-11-25 Hitachi Ltd データベース処理方法、データベース処理システム及びデータベースサーバ
JP2016177688A (ja) * 2015-03-20 2016-10-06 株式会社東芝 データ処理装置、データ処理方法およびコンピュータプログラム

Also Published As

Publication number Publication date
US8190613B2 (en) 2012-05-29
JP4848317B2 (ja) 2011-12-28
US20080319987A1 (en) 2008-12-25

Similar Documents

Publication Publication Date Title
JP4848317B2 (ja) データベースのインデックス作成システム、方法及びプログラム
US8533203B2 (en) Identifying synonyms of entities using a document collection
JP5138046B2 (ja) 検索システム、検索方法およびプログラム
US8027961B2 (en) System and method for composite record keys ordered in a flat key space for a distributed database
CN111258966A (zh) 一种数据去重方法、装置、设备及存储介质
US10678820B2 (en) System and method for computerized semantic indexing and searching
JP2009211263A (ja) 情報検索システム、方法及びプログラム
Parmar et al. Comparing linear search and binary search algorithms to search an element from a linear list implemented through static array, dynamic array and linked list
US8554696B2 (en) Efficient computation of ontology affinity matrices
JP2012104051A (ja) 文書インデックス作成装置
JP2009271819A (ja) 文書検索システム、文書検索方法および文書検索プログラム
JPWO2018012413A1 (ja) 類似データ検索装置、類似データ検索方法および記録媒体
JP2007048318A (ja) リレーショナルデータベースの処理方法およびリレーショナルデータベース処理装置
JP5380566B2 (ja) 言語処理装置、プログラムおよび方法
JP5494066B2 (ja) 検索装置、検索方法および検索プログラム
JP5184987B2 (ja) 索引情報作成装置、索引情報作成方法及びプログラム
JP5505207B2 (ja) 情報検索装置、情報検索方法及び情報検索プログラム
US20240211454A1 (en) Calculation device, calculation method, and recording medium
US11734244B2 (en) Search method and search device
JP5472929B2 (ja) 文書検索装置、文書検索方法及び文書検索プログラム
JP2018018279A (ja) 文書検索装置及びプログラム
JP6476638B2 (ja) 固有用語候補抽出装置、固有用語候補抽出方法、及び固有用語候補抽出プログラム
JP4061283B2 (ja) 字句をデータに変換する装置、方法及びプログラム
JPH08161351A (ja) 単語番号置換方法，インデックス作成方法，文書検索方法及び文書検索装置
Chang An efficient hash-based searching for specimens in the museum's exhibit

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090522

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20090522

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20090605

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090714

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090907

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20091110

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111017

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141021

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees