JP2010067213A - 検索対象列決定装置及び方法 - Google Patents

Abstract

【課題】検索キーワードのデータ構造上の特徴から全文検索の対象とすべきカラムを動的に絞ることにより、全文検索時の応答性能を向上することを可能とする。
【解決手段】検索対象列決定装置１０において、入力部１１はユーザ指定の検索キーワードを入力する。データ型解析部１２１は、入力部１１によって入力された検索キーワードのデータ構造上の特徴（例えばデータ型）を解析する。検索対象列検出部１２４は、リレーショナルデータベース（ＲＤＢ）２１に格納されている検索の対象となるテーブルの各カラムのうち、前記解析された検索キーワードのデータ構造上の特徴（例えばデータ型）に合致するカラムを、前記検索対象列として検出する。
【選択図】 図１

Description

本発明は、リレーショナルデータベース（Relational Database: ＲＤＢ）を対象とした、キーワードによる全文検索を行う全文検索技術に係り、特に、入力されたキーワード（検索キーワード）から検索対象列を決定する検索対象列決定装置及び方法に関する。

ＲＤＢ（に格納されているテーブル）を対象とする全文検索を実行するシステムとして、ＲＤＢ管理システム（Relational Database Management System: ＲＤＢＭＳ）が知られている。ＲＤＢＭＳに対するユーザからの検索要求には、例えば特許文献１に記載されているように、構造化照会言語（Structure Query Language: ＳＱＬ）が用いられるのが一般的である。しかし、ＳＱＬ技術に習熟していない一般ユーザにとって、検索要求にＳＱＬ（ＳＱＬ文）を用いることは困難である。

そこで近年は、ユーザが入力したキーワード（検索キーワード）から、アプリケーション（アプリケーションプログラム）の処理により、ＲＤＢに格納されているテーブル（ＲＤＢ内のテーブル）を対象とする全文検索を要求するＳＱＬ文を自動生成することが行われている。ＲＤＢ内のテーブルを対象とする全文検索では、ユーザが入力した検索キーワード（入力キーワード）に基づいて、当該テーブルの全列(全カラム)に対して検索を行うのが一般的である。このため、全文検索の対象となるテーブルのテーブル名を「table」とし、当該テーブルの全列を(a)，(b)及び(c)とし、検索キーワードを「VALUE」とすると、例えば
SELECT * FROM (table)
WHERE
(a) LIKE‘%VALUE’ or
(b) LIKE‘%VALUE’ or
(c) LIKE ・・
のようなＳＱＬ文が生成される。なお、WHERE文内の「LIKE ‘%VALUE’」は、周知のように、検索キーワード「VALUE」を末尾に含むものを検索条件とすることを示す。
特開２００３−３２３４３２号公報

上述のように従来技術においては、ユーザによって入力されたキーワード（検索キーワード）に基づいてＲＤＢ内のテーブルを対象とする全文検索を行うには、当該キーワードから、当該テーブルの全列を検索対象とするＳＱＬ文を生成するのが一般的であった。このため従来技術は、ユーザにとってＳＱＬ技術に習熟する必要はないものの、検索キーワードが増えると組み合わせ爆発を起こしてしまい、応答性能を低下させるという問題があった。また従来技術は、テーブルに格納されているデータ量によっても性能に大きな影響を与える。

そこで、これらの問題を解消するために検索範囲を絞る方法が考えられる。例えば、検索対象列を外部定義ファイルに記述し、それに基づいて検索する方法である。

しかしながら、外部定義ファイルを用いる手法では、当該外部定義ファイルを開発者が作成しなければならないために手間が掛かるだけでなく、静的に定義されるために検索キーワードに応じて動的に検索対象列を変更できないという別の問題がある。

本発明は上記事情を考慮してなされたものでその目的は、リレーショナルデータベース（ＲＤＢ）に格納されているテーブルを検索キーワードに基づいて全文検索する際に、当該検索キーワードのデータ構造上の特徴から全文検索の対象とすべきカラムを動的に絞ることにより、全文検索時の応答性能を向上することを可能とする検索対象列決定装置及び方法を提供することにある。

本発明の１つの観点によれば、リレーショナルデータベースに格納されているテーブルを対象とした、検索キーワードによる全文検索を行う全文検索システムにおいて、前記全文検索の対象とすべき前記テーブル内のカラムである検索対象列を決定する検索対象列決定装置が提供される。この検索対象列決定装置は、ユーザ指定の検索キーワードを入力する入力手段と、前記入力手段によって入力された検索キーワードのデータ構造上の特徴を解析する解析手段と、前記リレーショナルデータベースに格納されている検索の対象となるテーブルの各カラムのうち、前記解析手段によって解析された前記検索キーワードのデータ構造上の特徴に合致するカラムを、前記検索対象列として検出する検索対象列検出手段とを具備することを特徴とする。

本発明によれば、リレーショナルデータベース（ＲＤＢ）に格納されているテーブルを検索キーワードに基づいて全文検索する際に、当該検索キーワードのデータ構造上の特徴から全文検索の対象とすべきカラムを動的に絞ることができ、これにより全文検索時の応答性能を向上することができる。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る検索対象列決定装置１０を含む全文検索システムの構成を示すブロック図である。

図１において、全文検索システムは、検索対象列決定装置１０に加えて、ＲＤＢ／ＲＤＭＢＳ（リレーショナルデータベース／リレーショナルデータベース管理システム）２０と、クライアント装置３０と、アプリケーション実行機構４０とから構成される。

ＲＤＢ／ＲＤＭＢＳ２０は、ＲＤＢ２１とＲＤＢＭＳ２２とから構成される。ＲＤＢ２１は、テーブル２１１を含む複数のテーブルを格納する。ＲＤＢ２１はまた、テーブル定義情報２１２を格納する。テーブル定義情報２１２はテーブル２１１の構造を定義する。テーブル定義情報２１２は、テーブル２１１の各カラムのカラム名、当該カラムのデータ型、データの長さ（文字数または桁数）の上限値、及び当該データ型のカテゴリ名（分類名）を保持する。ＲＤＢ２１は、当該ＲＤＢ２１に格納されているテーブル２１１以外の各テーブル（図示せず）の構造を定義するテーブル定義情報（図示せず）をも格納する。

ＲＤＢＭＳ２２は、ＲＤＢ２１に格納されているテーブル２１１及びテーブル定義情報２１２等を管理すると共に、アプリケーション実行機構４０から与えられるＳＱＬ文による検索要求に従い、当該ＳＱＬ文の示す検索を実行する。ＲＤＢＭＳ２２は、ＳＱＬ文の示す検索の結果をアプリケーション実行機構４０に返す。

クライアント装置３０は、ＲＤＢ２１（内のテーブル）を対象とする全文検索のためのユーザによる入力操作（例えばキーワードの入力操作）、及び当該全文検索の結果の出力（例えば表示出力）等に用いられる。

アプリケーション実行機構４０は、クライアント装置３０からの入力に応じてアプリケーション（アプリケーションプログラム）４１を実行する。アプリケーション実行機構４０は特に、ユーザの入力操作によって入力された全文検索のための検索キーワード（つまりユーザ指定の検索キーワード）がクライアント装置３０から与えられた場合、当該キーワードからＲＤＢ／ＲＤＭＢＳ２０（内のＲＤＢＭＳ２２）に対する検索要求のためのＳＱＬ文を生成する。アプリケーション実行機構４０は、このＳＱＬ文の生成のために検索対象列決定装置１０を利用する。つまりアプリケーション実行機構４０は、検索キーワードを検索対象列決定装置１０に渡して当該キーワードのデータ構造上の特徴に適合する検索対象列を問い合わせることで、当該検索対象列決定装置１０から決定された検索対象列の情報を取得する。アプリケーション実行機構４０は、取得された検索対象列の情報に基づいて、ＲＤＢ２１内の検索対象となるテーブルから検索キーワードに合致するデータを検索するためのＳＱＬ文を生成する。

検索対象列決定装置１０は、アプリケーション実行機構４０からの問い合わせによって当該アプリケーション実行機構４０から渡された検索キーワードを解析することにより、当該検索キーワードのデータ構造上の特徴に適合する、全文検索の対象とすべき、ＲＤＢ２１内のテーブル（ＲＤＢ２１に格納されているテーブル）のカラム（検索対象列）を決定する。

検索対象列決定装置１０は、入力部１１、判定部１２、出力部１３、制御部１４、テーブル構造情報記憶部１５及びテーブル構造情報生成部１６を含む。入力部１１は、アプリケーション実行機構４０からの問い合わせによって当該アプリケーション実行機構４０から渡された検索キーワード（ユーザ指定の検索キーワード）を入力する。

判定部１２は、入力部１１によって入力された検索キーワードを解析して当該キーワードのデータ構造上の特徴（例えばデータ型と長さ）を判定し、当該キーワードのデータ構造上の特徴に適合し、且つ全文検索の対象とすべき、ＲＤＢ２１内のテーブルの検索対象列を決定するように構成されている。判定部１２は、データ型解析部１２１、データ型判定部１２２、キーワード長検出部１２３及び検索対象列検出部１２４を含む。

データ型解析部１２１は、入力部１１によって入力された検索キーワードのデータ型を解析する。データ型判定部１２２は、データ型解析部１２１によるデータ型の解析結果に基づき、検索キーワードのデータ構造上の特徴としての当該キーワードのデータ型を判定する。キーワード長検出部１２３は、検索キーワードのデータ型が数値型または文字列型の場合、検索キーワードを解析して、当該キーワードの他のデータ構造上の特徴としての当該キーワードの長さ（桁数または文字数）を検出する。検索対象列検出部１２４は、検索キーワードの解析結果（つまりデータ型の判定結果、またはデータ型の判定結果と当該キーワードの長さ）に基づき、テーブル構造情報記憶部１５に格納されているテーブル構造情報から、当該キーワードのデータ構造上の特徴に適合し、且つ全文検索の対象とすべき、ＲＤＢ２１内のテーブルの上記検索対象列を検出する。

出力部１３は、判定部１２によって決定された検索対象列の情報をアプリケーション実行機構４０に返す。
制御部１４は、入力部１１によって入力された検索キーワードを判定部１２に渡すことによって、当該検索キーワードに適合する検索対象列を決定させ、その決定結果（決定された検索対象列の情報）を出力部１３に渡す。

テーブル構造情報記憶部１５は、ＲＤＢ２１内のテーブルの構造を表すテーブル構造情報を格納する。テーブル構造情報は、ＲＤＢ２１内のテーブルを構成するカラム毎に、そのカラムのデータ型と、長さ（文字数または桁数）に関する制限値（上限値）とを含む。テーブル構造情報記憶部１５に格納されるテーブル構造情報は、テーブル２１１の構造を表すテーブル構造情報１５０を含む。

テーブル構造情報生成部１６は、ＲＤＢ２１内のテーブルのテーブル定義情報からテーブル構造情報を生成する。テーブル構造情報生成部１６は、生成されたテーブル構造情報をテーブル構造情報記憶部１５に格納する。

図２は、図１に示されるテーブル２１１の一例を示す。図２に示すテーブル２１１は、例えば、テーブル名（つまり当該テーブル２１１を指定する情報）が「table」の従業員テーブルである。テーブル２１１は、例えば、カラム名がそれぞれ「EmpNo」、「Name」、「Birth」及び「Age」の、４つのカラム（項目、列）２１１ａ、２１１ｂ、２１１ｃ及び２１１ｄから構成される。カラム２１１ａ及び２１１ｂは、それぞれ、従業員番号（EmpNo）及び名前（Name）を設定するのに用いられる。カラム２１１ｃ及び２１１ｄは、それぞれ、生年月日（Birth）及び年令（Age）を設定するのに用いられる。

カラム名が「EmpNo」のカラム２１１ａのデータ型は文字列型（VARCHAR）であり、データの長さ（文字数）の上限として８文字が指定されている。カラム名が「Name」のカラム２１１ｂのデータ型も文字列型（VARCHAR）であり、データの長さの上限として４０文字が指定されている。カラム名が「Birth」のカラム２１１ｃのデータ型は日付型（date）であり、データの長さに特別な制限は設定されていない。カラム名が「Age」のカラム２１１ｄのデータ型は数値型（NUMBER）であり、データの長さの上限として３桁が指定されている。

図２に示されるテーブル２１１の構造は、ＲＤＢ２１に格納されているテーブル定義情報２１２によって定義される。このテーブル定義情報２１２は、テーブル２１１の定義時に、当該テーブル２１１のテーブル名（table）に対応付けてＲＤＢ２１に格納される。

図３は、図１に示されるテーブル構造情報記憶部１５に格納されるテーブル構造情報のうち、図２に示されるテーブル２１１の構造を表すテーブル構造情報１５０の一例を示す。図３の例では、テーブル構造情報１５０はテーブル形式のデータ構造を有している。しかし、テーブル構造情報１５０が必ずしもテーブル形式のデータ構造を有している必要はなく、例えばリスト形式のデータ構造を有していても構わない。

図３に示されるテーブル構造情報１５０は、図２に示すテーブル２１１のカラム２１１ａ〜２１１ｄのカラム名（つまりカラム２１１ａ〜２１１ｄを指定する情報）に対応付けて、当該カラム２１１ａ〜２１１ｄのデータ型、データの長さ（文字数または桁数）の上限値、及び当該データ型のカテゴリ名（分類名）を保持する。図３の例では、データ型のカテゴリ名として、「文字列型」、「日付型」及び「数値型」の３種が用いられている。このように、「カラムのデータ型」として定義できるものは、通常のＲＤＢで定義されるデータ型がそのまま用いられる。また図３の例では、「日付型」の場合、データの長さは固定であることから、データの長さの上限値は設定されていない。

次に、図１の全文検索システムにおける動作について、検索対象列決定装置１０の動作を中心に説明する。
まず、ＲＤＢ／ＲＤＭＢＳ２０内のＲＤＢＭＳ２２によるテーブル定義時の動作について説明する。
今、ＲＤＢＭＳ２２が、ＲＤＢ２１にテーブル２１１（データが設定されていない空のテーブル２１１）を登録するものとする。この場合、ＲＤＢＭＳ２２はまず、テーブル２１１のテーブル名（ここではtable）に対応付けて当該テーブル２１１のテーブル定義情報２１２をＲＤＢ２１に登録する。その後、ＲＤＢＭＳ２２は、テーブル定義情報２１２によって定義される構造の、空のテーブル２１１をＲＤＢ２１に登録する。

次に、検索対象列決定装置１０内のテーブル構造情報生成部１６によるテーブル構造情報生成処理について、図４のフローチャートを参照して説明する。
検索対象列決定装置１０内の制御部１４は、適宜（例えば検索対象列決定装置１０の起動時に）テーブル構造情報生成部１６に対してテーブル構造情報生成を要求する。するとテーブル構造情報生成部１６は、テーブル構造情報生成処理を開始する。

テーブル構造情報生成部１６はまず、ＲＤＢＭＳ２２を介してＲＤＢ２１を参照することにより、テーブル構造情報が生成されていないテーブルのテーブル定義情報（つまり未処理のテーブル定義情報）を検索する（ステップ４０１）。ここでは、テーブル定義情報２１２が検索されたものとする。

このように、未処理のテーブル定義情報（テーブル定義情報２１２）が検索できたならば（ステップ４０２がＹｅｓ）、テーブル構造情報生成部１６は、検索されたテーブル定義情報２１２に基づいてテーブル構造情報を生成する（ステップ４０３）。このステップ４０３においてテーブル構造情報生成部１６は、検索されたテーブル定義情報２１２（つまり、テーブル２１１のテーブル名「table」に対応付けられているテーブル定義情報２１２）から、テーブル２１１を定義する情報として、カラム毎に、カラム名、データ型、データの長さの上限値、及び当該データ型のカテゴリ名（分類名）を抽出する。そしてテーブル構造情報生成部１６は、抽出された情報に基づき、テーブル定義情報２１２で定義されたテーブル２１１のテーブル構造を表す、図３に示すようなテーブル構造情報１５０を生成する。

テーブル構造情報生成部１６は、生成されたテーブル構造情報１５０をテーブル構造情報記憶部１５に格納する（ステップ４０４）。するとテーブル構造情報生成部１６はステップ４０１に戻って、ＲＤＢ２１から未処理のテーブル定義情報を検索する。そして、未処理のテーブル定義情報が検索できたならば（ステップ４０２がＹｅｓ）、テーブル構造情報生成部１６は前述のように、検索されたテーブル定義情報に基づいてテーブル構造情報を生成する（ステップ４０３）。これに対し、未処理のテーブル定義情報が検索できなかったならば（ステップ４０２がＮｏ）、テーブル構造情報生成部１６はテーブル構造情報生成処理を終了する。

なお、制御部１４がＲＤＢＭＳ２２によるテーブル定義動作を監視し、当該テーブル定義動作を検出した場合に、テーブル構造情報生成部１６に対してテーブル構造情報の生成を要求するようにしても構わない。

その後、ユーザがクライアント装置３０を操作して、検索キーワードとして用いられるべき文字列を入力したものとする。このときユーザは、検索の対象となるテーブル、例えばテーブル２１１（のテーブル名）を指定する情報（対象テーブル指定情報）をも入力したものとする。

入力されたキーワード（検索キーワード）及び対象テーブル指定情報は、クライアント装置３０からアプリケーション実行機構４０に送られる。アプリケーション実行機構４０は、クライアント装置３０から送られたキーワード（検索キーワード）及び対象テーブル指定情報に基づいてアプリケーション４１を実行することにより、当該対象テーブル指定情報で指定されるテーブル（ここではテーブル２１１）を検索対象（全文検索の対象）として、当該キーワード（検索キーワード）に基づく全文検索をＲＤＢ／ＲＤＭＢＳ２０（内のＲＤＢＭＳ２２）に実行させるためのＳＱＬ文を生成する。

従来技術では、検索対象となるテーブル（ここではテーブル２１１）の全カラム（全列)に対して検索を行うのに必要なＳＱＬ文が生成される。しかし本実施形態では、以下に述べるように、検索キーワードのデータ構造上の特徴に適合するカラム（検索対象カラムまたは検索対象列）に絞って検索を行うのに必要なＳＱＬ文が生成される。

このようなＳＱＬ文の生成のために、アプリケーション実行機構４０は、クライアント装置３０から送られた検索キーワード及び対象テーブル指定情報を検索対象列決定装置１０に渡し、当該検索対象列決定装置１０に対して当該キーワードのデータ構造上の特徴に適合する検索対象カラム（検索対象列）を問い合わせる。

すると検索対象列決定装置１０は、検索対象列決定処理を実行する。この検索対象列決定装置１０による検索対象列決定処理について、図５のフローチャートを参照して説明する。

まず検索対象列決定装置１０内の入力部１１は、アプリケーション実行機構４０から検索対象列決定装置１０に渡された検索キーワード及び対象テーブル指定情報を入力する（ステップ５０１）。このステップ５０１において、入力部１１は、入力された検索キーワード及び対象テーブル指定情報を検索対象列決定装置１０内の制御部１４に渡す。制御部１４は、入力部１１から検索キーワード及び対象テーブル指定情報を受け取ると、当該検索キーワード及び対象テーブル指定情報を検索対象列決定装置１０内の判定部１２に渡して、当該検索キーワードに適合する検索対象列を決定することを要求する（ステップ５０２）。

判定部１２は、制御部１４から検索キーワード及び対象テーブル指定情報（つまり入力部１１によって入力された検索キーワード及び対象テーブル指定情報）を受け取ると、以下の手順により当該キーワードのデータ構造上の特徴に適合する検索対象カラムを決定する。

まず判定部１２内のデータ型判定部１２２は、入力された検索キーワードをデータ型解析部１２１に渡して、当該検索キーワードのデータ型を問い合わせる。するとデータ型解析部１２１は、検索キーワードのデータ型を解析し、当該検索キーワードがいずれのデータ型にマッチするかを判定するためのデータ型解析処理を実行する（ステップ５０３）。この検索キーワードのデータ型の解析には、例えばＪａｖａ（登録商標）の周知のプログラムを用いることができる。

以下、データ型解析部１２１によるデータ型解析処理（ステップ５０３）の手順の詳細について図６のフローチャートを参照して説明する。まずデータ型解析部１２１は、検索キーワードのデータ型を解析するために、当該検索キーワードを文字列（デフォルトのデータ型である文字列型のデータ）とみなして、当該文字列を例えば数値型に変換するための「Integer.parseInt(キーワード)」という周知のプログラム（以下、第１のプログラムと称する）を実行する（ステップ６０１）。

第１のプログラム中の括弧（ ）内には、検索キーワードが設定される。例えば、検索キーワードが“123”の場合、第１のプログラムとして「Integer.parseInt(“123”)」が実行される。

もし、第１のプログラム中の括弧（ ）内に設定されているデータ（ここでは検索キーワード）が数値型でない場合に当該第１のプログラムが実行されると、プログラム例外が発生する。これに対し、第１のプログラム中の括弧（ ）内に設定されているデータが数値型である場合に当該第１のプログラムが実行されると、当該データ（文字列と見なされたデータ）は数値型に変換され、プログラム例外は発生しない。

そこでデータ型解析部１２１は、第１のプログラムの実行によりプログラム例外が発生したか否かにより（ステップ６０２）、検索キーワードが数値型以外であるか（ステップ６０３）、或いは数値型であるか（ステップ６０４）を判定する。

データ型解析部１２１は、検索キーワードが数値型以外であると判定した場合（ステップ６０３）、当該検索キーワードのデータ型を解析するために、当該検索キーワードを文字列とみなして、当該文字列を例えば“yyyy/MM/dd”形式の日付型に変換するための「new SimpleDateFormat(“yyyy/MM/dd”).parse(キーワード)」という周知のプログラム（以下、第２のプログラムと称する）を実行する（ステップ６０５）。

第２のプログラム中の括弧（ ）内には、検索キーワードが設定される。もし、第２のプログラム中の括弧（ ）内に設定されているデータ（ここでは検索キーワード）が日付型（“yyyy/MM/dd”形式の日付型）でない場合に当該第２のプログラムが実行されると、プログラム例外が発生する。これに対し、第２のプログラム中の括弧（ ）内に設定されているデータが日付型（“yyyy/MM/dd”形式の日付型）である場合に当該第２のプログラムが実行されると、当該データ（文字列と見なされたデータ）は日付型に変換され、プログラム例外は発生しない。

そこでデータ型解析部１２１は、第２のプログラムの実行によりプログラム例外が発生したか否かにより（ステップ６０６）、検索キーワードが日付型（“yyyy/MM/dd”形式の日付型）以外であるか（ステップ６０７）、或いは日付型（“yyyy/MM/dd”形式の日付型）であるか（ステップ６０８）を判定する。

データ型解析部１２１は、検索キーワードが日付型以外であると判定した場合（ステップ６０７）、つまり第１及び第２のプログラムの実行で全てプログラム例外が発生したために、当該検索キーワードが数値型でも日付型でもないと判定した場合（ステップ６０３，６０７）、当該検索キーワードをデフォルトのデータ型である文字列型と判定する（ステップ６０９）。データ型解析部１２１は、上述のデータ型の解析によってステップ６０４，６０８または６０９で判定されたデータ型を、検索キーワードのデータ型の解析結果として判定部１２内のデータ型判定部１２２に通知して（ステップ６１０）、データ型解析処理を終了する。

データ型判定部１２２は、データ型解析部１２１から通知された検索キーワードのデータ型（データ型解析結果であるデータ型）を受け取ると、当該データ型が、例えば日付型であるかを判定する（ステップ５０４）。もし、検索キーワードのデータ型が日付型でないならば（ステップ５０４がＮｏ）、データ型判定部１２２はデータ型解析部１２１から通知された検索キーワードのデータ型が、数値型もしくは文字列型であると判定する。

もし、検索キーワードのデータ型が数値型または文字列型であるならば（ステップ５０４がＮｏ）、データ型判定部１２２は当該検索キーワードのデータ型と当該検索キーワードとをキーワード長検出部１２３に渡して、当該検索キーワードの長さ（文字数または桁数）を問い合わせる。キーワード長検出部１２３は、データ型判定部１２２からの問い合わせに応じて検索キーワードを解析し、当該検索キーワードを構成する文字列または数値列の長さ（文字数または桁数）を検出する（ステップ５０５）。

キーワード長検出部１２３は、検出された検索キーワードの長さをデータ型判定部１２２に通知する。するとデータ型判定部１２２は、検索キーワードのデータ型（文字列型または数値型）、長さ（キーワード長）及び対象テーブル指定情報を検索対象列検出部１２４に渡して、当該キーワードのデータ構造上の特徴に適合する検索対象カラムを決定することを要求する。

これに対し、検索キーワードのデータ型が日付型であるならば（ステップ５０４がＹｅｓ）、データ型判定部１２２は当該検索キーワードのデータ型（日付型）及び対象テーブル指定情報を検索対象列検出部１２４に渡して、当該キーワードのデータ構造上の特徴に適合する検索対象カラムを決定することを要求する。

検索対象列検出部１２４は、データ型判定部１２２により渡された対象テーブル指定情報によって指定されるテーブル（ここではテーブル２１１）に対応付けてテーブル構造情報記憶部１５に格納されているテーブル構造情報、つまり対象テーブル構造情報（ここではテーブル構造情報１５０）から、データ型判定部１２２により渡された検索キーワードのデータ型（または検索キーワードのデータ型と長さ）の示す当該検索キーワードのデータ構造上の特徴に適合するカラムを検索対象列として検出する（ステップ５０６）。ここでは、検索キーワードのデータ型が日付型（数値型及び文字列型以外）であるために（ステップ５０４がＹｅｓ）、データ型判定部１２２により検索キーワードの長さ（を示す情報）が渡されていない場合には、検索キーワードのデータ型に一致するカラムが検索キーワードのデータ構造上の特徴に適合するカラム（検索対象列）として検出される。これに対し、検索キーワードのデータ型が数値型または文字列型であるために（ステップ５０４がＮｏ）、データ型判定部１２２により検索キーワードの長さ（を示す情報）が渡されている場合には、検索キーワードのデータ型に一致し、且つ長さ（文字数または桁数）に関する制限値（上限値）が当該検索キーワードの長さ以上のカラムが検索キーワードのデータ構造上の特徴に適合するカラム（検索対象カラム）として検出される。

検索対象列検出部１２４は、検出された検索対象列をデータ型判定部１２２に通知する。データ型判定部１２２は、検索対象列検出部１２４から通知された検索対象カラム（検出結果）を制御部１４に渡す。

制御部１４は、データ型判定部１２２から渡された検索対象カラム、つまり検索対象列検出部１２４によって検出された検索対象列を検索対象列決定装置１０内の出力部１３に渡す（ステップ５０７）。出力部１３は、この検索対象カラムを、アプリケーション実行機構４０からの問い合わせに対して検索対象列決定装置１０によって決定された検索対象カラム（検索対象列）として、当該アプリケーション実行機構４０に返す（ステップ５０８）。

アプリケーション実行機構４０は、検索対象列決定装置１０内の出力部１３から検索対象カラムが返されると、当該検索対象カラムと、先の問い合わせ時に当該検索対象列決定装置１０に渡した検索キーワード及び対象テーブル指定情報とに基づいて、当該検索キーワードのデータ構造上の特徴に適合するカラム（検索対象カラム）に絞って検索を行うのに必要なＳＱＬ文を生成する。

アプリケーション実行機構４０は、生成されたＳＱＬ文を用いてＲＤＢ／ＲＤＭＢＳ２０内のＲＤＢＭＳ２２に対して検索を要求する。このＳＱＬ文は、従来技術とは異なり、検索対象となるテーブル（ここではテーブル２１１）の全カラムを検索対象とするものではなく、検索キーワードのデータ構造上の特徴に適合するカラムのみを検索対象とする。つまり本実施形態においては、全文検索において検索対象となるテーブルの全カラムに対して検索を行う場合に比べ、検索キーワードのデータ構造上の特徴に応じて検索対象カラムを動的に絞ることができる。これにより本実施形態においては、ＲＤＢ２１に対する無駄な検索要求の発生を減らして、当該ＲＤＢ２１内のテーブルを全文検索する際の応答性能を向上することができる。

次に、検索対象列決定装置１０による検索対象カラムの決定、及び決定された検索対象カラムに基づくアプリケーション実行機構４０によるＳＱＬ文の生成の具体例について、検索キーワードが「YAMADA」、「1935/06/17」、及び「77」である場合を例に順次説明する。ここでは、検索対象となるテーブルが、テーブル名「table」の図２に示す構造のテーブル２１１であるものとする。

［検索キーワードが「YAMADA」である場合］
まず、検索キーワードが例えば「YAMADA」である場合の検索対象カラムの決定及びＳＱＬ文の生成について説明する。

検索キーワードが「YAMADA」である場合、検索対象列決定装置１０内の判定部１２に含まれているデータ型解析部１２１では、第１のプログラムとして、「Integer.parseInt(“YAMADA”)」が実行される（ステップ６０１）。この第１のプログラム中の括弧（ ）内に設定されている検索キーワード「YAMADA」は数値型ではないため、プログラム例外が発生し（ステップ６０２がＹｅｓ）、検索キーワード「YAMADA」は数値型以外であると判定される（ステップ６０３）。

するとデータ型解析部１２１では、第２のプログラムとして、「new SimpleDateFormat(“yyyy/MM/dd”).parse(“YAMADA”)」が実行される（ステップ６０５）。この第２のプログラム中の括弧（ ）内に設定されている検索キーワード「YAMADA」は日付型ではないため、プログラム例外が発生し（ステップ６０６がＹｅｓ）、検索キーワード「YAMADA」は数値型でも日付型でもないデータ型、つまり文字列型であると判定される（ステップ６０９）。この場合、キーワード長検出部１２３によって、検索キーワード「YAMADA」の長さ（文字数）として「６」が検出される。

このように、検索キーワード「YAMADA」のデータ型が文字列型（VARCHAR）で長さが「６」の場合、検索対象列検出部１２４は、テーブル２１１を全文検索する際の検索対象カラムとして、テーブル構造情報１５０（図３参照）から、文字列型（VARCHAR）で且つ長さが「６」以上のカラムを検出する。ここでは、テーブル構造情報１５０によって示される４つのカラムのうち、カラム名が「EmpNo」のカラム２１１ａ（図２参照）が、データ型が文字列型（VARCHAR）で長さ（文字数）の上限が「８」であり、カラム名が「Name」のカラム２１１ｂ（図２参照）が、データ型が文字列型（VARCHAR）で長さ（文字数）の上限が「４０」である。このため、カラム名が「EmpNo」のカラム２１１ａと、カラム名が「Name」のカラム２１１ｂ（図２参照）とが、検索対象カラムとして検出（決定）される。

この場合、アプリケーション実行機構４０は、次のようなＳＱＬ文
SELECT * FROM (table)
WHERE
EmpNo LIKE‘%YAMADA%’or
Name LIKE‘%YAMADA%’
を生成する。

図７は、検索キーワードが「YAMADA」（つまり文字列）である場合の、検索対象カラムの絞り込みのイメージを、生成されるＳＱＬ文と対比させて示す。

［検索キーワードが「1935/06/17」である場合］
次に、検索キーワードが例えば「1935/06/17」（つまり日付）である場合の検索対象カラムの決定及びＳＱＬ文の生成について説明する。

検索キーワードが「1935/06/17」である場合、第１のプログラムとして、「Integer.parseInt(“1935/06/17”)」が実行される（ステップ６０１）。この第１のプログラム中の括弧（ ）内に設定されている検索キーワード「1935/06/17」は数値型ではないため、プログラム例外が発生し（ステップ６０２がＹｅｓ）、検索キーワード「1935/06/17」は数値型以外であると判定される（ステップ６０３）。

すると第２のプログラムとして、「new SimpleDateFormat(“yyyy/MM/dd”).parse(“1935/06/17”)」が実行される（ステップ６０５）。この第２のプログラム中の括弧（ ）内に設定されている検索キーワード「1935/06/17」は日付型であるため、プログラム例外は発生せず（ステップ６０６がＮｏ）、検索キーワード「1935/06/17」は日付型であると判定される（ステップ６０８）。日付型の場合、データの長さは固定であるため、キーワード長検出部１２３による長さ（文字数または桁数）の検出は行われず、日付型（データ型）のみで、検索対象カラムが検出される。

テーブル構造情報１５０（図３参照）は、テーブル名が「table」のテーブル２１１が、日付型のカラムとして、カラム名が「Birth」のカラム２１１ｃ（図２参照）を含むことを示している。この場合、検索対象カラムとして、カラム名が「Birth」のカラム２１１ｃが検出されるため、次のようなＳＱＬ文
SELECT * FROM (table)
WHERE
Birth LIKE‘%1935/06/17%’
が生成される。

図８は、検索キーワードが「1935/06/17」（つまり日付）である場合の、検索対象カラムの絞り込みのイメージを、生成されるＳＱＬ文と対比させて示す。

［検索キーワードが「77」である場合］
次に、検索キーワードが例えば「77」（つまり数値）である場合の検索対象カラムの決定及びＳＱＬ文の生成について説明する。

検索キーワードが「77」である場合、第１のプログラムとして、「Integer.parseInt(“77”)」が実行される（ステップ６０１）。この第１のプログラム中の括弧（ ）内に設定されている検索キーワード「77」は数値型あるため、プログラム例外は発生せず（ステップ６０２がＮｏ）、検索キーワード「77」は数値型であると判定される（ステップ６０４）。この場合、検索キーワード「77」の長さ（桁数）として「２」が検出される。

このように、検索キーワード「77」のデータ型が数値型（NUMBER）で長さが「２」の場合、テーブル構造情報１５０（図３参照）から、検索対象カラムとして、数値型（NUMBER）で且つ長さが「２」以上のカラムが検出される。ここでは、カラム名が「Age」のカラム２１１ｄ（図２参照）が、データ型が数値型（NUMBER）で長さ（桁数）の上限が「３」であるため、検索対象カラムとして検出（決定）される。

この場合、次のようなＳＱＬ文
SELECT * FROM (table)
WHERE
Age LIKE‘%77%’
が生成される。

図９は、検索キーワードが「77」（つまり数値）である場合の、検索対象カラムの絞り込みのイメージを、生成されるＳＱＬ文と対比させて示す。

上記実施形態では、ユーザがクライアント装置３０を操作して検索キーワードとして用いられるべき文字列を入力する場合に、検索の対象となるテーブル（対象テーブル）を指定する情報（対象テーブル指定情報）をも入力するものとしている。しかし、検索の対象となるテーブルは必ずしも指定する必要がない。つまり、対象テーブル指定情報は必ずしも入力される必要はない。

ユーザによって対象テーブルが指定されず、したがってクライアント装置３０からアプリケーション実行機構４０に送られる情報に対象テーブル指定情報が含まれていない場合、当該アプリケーション実行機構４０は、ＲＤＢ２１に格納されている全てのテーブルを対象テーブル（検索の対象）とする。この場合、判定部１２（内の検索対象列検出部１２４）による検索対象列の検出（決定）は、ＲＤＢ２１に格納されている全てのテーブルのテーブル定義情報に基づいて行われる。

また上記実施形態では、データ型のカテゴリ名（分類名）として、「文字列型」、「日付型」及び「数値型」の３種が用いられている。しかし、これらの３種に加えて、「期間」、「真偽値」、「URI(識別可能な一意性のある文字列)」などを用いても良い。「期間」、「真偽値」、「URI」のいずれの場合にも、キーワード長検出部１２３による検索キーワードの長さの検出は必要ない。つまり上記実施形態と同様に、検索キーワードが「数値型」または「文字列型」の場合だけ、当該検索キーワードの長さが検出されれば良い。

なお、検索キーワードが「数値型」または「文字列型」の場合でも、当該検索キーワードの長さは必ずしも検出される必要はない。つまり、検索キーワードが「数値型」または「文字列型」の場合でも、検索キーワードのデータ型に一致するカラムが検索キーワードのデータ構造上の特徴に適合するカラム（検索対象列）として検出される構成であっても構わない。この場合、キーワード長検出部１２３は不要となる。但し、検索キーワードが上述の「数値型」または「文字列型」の場合には、データの長さが検索キーワードより短い「数値型」または「文字列型」のカラムも検索の対象となるため、上記実施形態と比べて全文検索時の応答性能が低下する。それでも、検索対象列が絞られるため、従来技術よりも全文検索時の応答性能は向上する。

図１０は、図１に示される全文検索システムの実現例を示すブロック図である。
まず図１０（ａ）は、全文検索システムがコンピュータ５０１によって実現されている場合のシステム構成を示す。図１０（ａ）の例では、検索対象列決定装置１０、ＲＤＢ／ＲＤＭＢＳ２０、クライアント装置３０及びアプリケーション実行機構４０は、コンピュータ５０１に存在する。つまり検索対象列決定装置１０、ＲＤＢ／ＲＤＭＢＳ２０、クライアント装置３０及びアプリケーション実行機構４０は、いずれもコンピュータ５０１によって実現される。

図１０（ｂ）は、全文検索システムが、コンピュータ５０２及び５０３によって実現されている場合のシステム構成を示す。図１０（ｂ）の例では、検索対象列決定装置１０、クライアント装置３０及びアプリケーション実行機構４０はコンピュータ５０２に存在し、ＲＤＢ／ＲＤＭＢＳ２０はコンピュータ（データベースサーバコンピュータ）５０３に存在する。コンピュータ５０２及び５０３は、ローカルエリアネットワークやインターネットのようなネットワーク６０１により相互接続されている。

図１０（ｃ）は、全文検索システムが、コンピュータ５０４及び５０５によって実現されている場合のシステム構成を示す。図１０（ｃ）の例では、検索対象列決定装置１０、ＲＤＢ／ＲＤＭＢＳ２０及びアプリケーション実行機構４０はコンピュータ５０４に存在し、クライアント装置３０はコンピュータ５０５に存在する。コンピュータ５０４及び５０５はネットワーク６０２により相互接続されている。

図１０（ｄ）は、全文検索システムが、コンピュータ５０３，５０５及び５０６によって実現されている場合のシステム構成を示す。図１０（ｄ）の例では、検索対象列決定装置１０及びアプリケーション実行機構４０はコンピュータ５０６に存在する。一方、ＲＤＢ／ＲＤＭＢＳ２０は、図１０（ｂ）のシステム構成と同様にコンピュータ（データベースサーバコンピュータ）５０３に存在し、クライアント装置３０は、図１０（ｃ）のシステム構成と同様にコンピュータ５０５に存在する。コンピュータ５０３及び５０６はネットワーク６０３により相互接続され、コンピュータ５０５及び５０６はネットワーク６０４により相互接続されている。なお、コンピュータ５０３，５０５及び５０６が１つのネットワークにより相互接続されていても構わない。

図１０（ｅ）は、全文検索システムが、コンピュータ５０５，５０７及び５０８によって実現されている場合のシステム構成を示す。図１０（ｅ）の例では、検索対象列決定装置１０はコンピュータ５０７に存在し、ＲＤＢ／ＲＤＭＢＳ２０及びアプリケーション実行機構４０はコンピュータ５０８に存在する。一方、クライアント装置３０は、図１０（ｃ）のシステム構成と同様にコンピュータ５０５に存在する。コンピュータ５０５及び５０８はネットワーク６０５により相互接続され、コンピュータ５０７及び５０８はネットワーク６０６により相互接続されている。なお、コンピュータ５０５，５０７及び５０８が１つのネットワークにより相互接続されていても構わない。

図１０（ｆ）は、全文検索システムが、コンピュータ５０３，５０５，５０７及び５０９によって実現されている場合のシステム構成を示す。図１０（ｆ）の例では、検索対象列決定装置１０は、図１０（ｅ）のシステム構成と同様にコンピュータ５０７に存在する。また、ＲＤＢ／ＲＤＭＢＳ２０は、図１０（ｂ）のシステム構成と同様にコンピュータ５０３に存在し、クライアント装置３０は、図１０（ｃ）のシステム構成と同様にコンピュータ５０５に存在する。一方、アプリケーション実行機構４０はコンピュータ５０９に存在する。コンピュータ５０３及び５０７はネットワーク６０７により相互接続され、コンピュータ５０３及び５０９はネットワーク６０８により相互接続されている。一方、コンピュータ５０５及び５０９はネットワーク６０９により相互接続されている。なお、コンピュータ５０３，５０５，５０７及び５０９が１つのネットワークにより相互接続されていても構わない。

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

本発明の一実施形態に係る検索対象列決定装置を含む全文検索システムの構成を示すブロック図。 図１に示されるテーブルの一例を示す図。 図２に示されるテーブルの構造を表すテーブル構造情報の一例を示す図。 同実施形態におけるテーブル構造情報生成処理の手順を示すフローチャート。 同実施形態における検索対象列決定処理の手順を示すフローチャート。 図５のフローチャート中のデータ型解析処理の手順の詳細を示すフローチャート。 検索キーワードが文字列である場合の、検索対象カラムの絞り込みのイメージを、生成されるＳＱＬ文と対比させて示す図。 検索キーワードが日付である場合の、検索対象カラムの絞り込みのイメージを、生成されるＳＱＬ文と対比させて示す図。 検索キーワードが数値である場合の、検索対象カラムの絞り込みのイメージを、生成されるＳＱＬ文と対比させて示す図。 図１に示される全文検索システムの実現例を示すブロック図。

符号の説明

１０…検索対象列決定装置、１１…入力部、１２…判定部、１３…出力部、１４…制御部、１５…テーブル構造情報記憶部、１６…テーブル構造情報生成部、２０…ＲＤＢ／ＲＤＭＢＳ（リレーショナルデータベース／リレーショナルデータベース管理システム）、２１…ＲＤＢ（リレーショナルデータベース）、２２…ＲＤＢＭＳ（リレーショナルデータベース管理システム）、３０…クライアント装置、４０…アプリケーション実行機構、４１…アプリケーション（アプリケーションプログラム）、１２１…データ型解析部、１２２…データ型判定部、１２３…キーワード長検出部、１２４…検索対象列検出部、１５０…テーブル構造情報、２１１…テーブル、２１２…テーブル定義情報、５０１〜５０９…コンピュータ、６０１〜６０９…ネットワーク。

Claims (5)

1. リレーショナルデータベースに格納されているテーブルを対象とした、検索キーワードによる全文検索を行う全文検索システムにおいて、前記全文検索の対象とすべき前記テーブル内のカラムである検索対象列を決定する検索対象列決定装置であって、
   ユーザ指定の検索キーワードを入力する入力手段と、
   前記入力手段によって入力された検索キーワードのデータ構造上の特徴を解析する解析手段と、
   前記リレーショナルデータベースに格納されている検索の対象となるテーブルの各カラムのうち、前記解析手段によって解析された前記検索キーワードのデータ構造上の特徴に合致するカラムを、前記検索対象列として検出する検索対象列検出手段と
   を具備することを特徴とする検索対象列決定装置。
2. 前記解析手段は、前記検索キーワードのデータ構造上の特徴として、当該キーワードのデータ型を解析し、
   前記検索対象列検出手段は、前記検索キーワードの前記データ構造上の特徴に合致するカラムとして、少なくとも、前記解析手段によって解析された前記検索キーワードのデータ型に合致するカラムを検出する
   ことを特徴とする請求項１記載の検索対象列決定装置。
3. 前記リレーショナルデータベースにテーブルが登録される際に前記リレーショナルデータベースに格納される、当該テーブルの構造を定義するテーブル定義情報に基づき、当該テーブルの構造を表すためのテーブル構造情報であって、当該テーブルの各カラムを指定する情報に対応付けて、少なくとも当該カラムのデータ型を保持するテーブル構造情報を生成するテーブル構造情報生成手段と、
   前記テーブル構造情報生成手段によって生成されたテーブル構造情報を当該テーブル構造情報によって構造が表されるテーブルを指定する情報に対応付けて格納するテーブル構造情報記憶手段とを更に具備し、
   前記検索対象列検出手段は、前記解析手段によって解析された前記検索キーワードのデータ型に合致するカラムを、前記検索の対象となるテーブルを指定する情報に対応付けて前記テーブル構造情報記憶手段に格納されている前記テーブル構造情報から検出する
   ことを特徴とする請求項２記載の検索対象列決定装置。
4. 前記解析手段によって解析された前記検索キーワードのデータ型が数値型または文字列型の場合、当該検索キーワードのキーワード長を検出するキーワード長検出手段を更に具備し、
   前記テーブル構造情報生成手段によって生成される前記テーブル構造情報は、少なくとも、前記カラムのデータ型が前記数値型または文字列型の場合、当該カラムのデータ型に加えて、データの長さの上限値を保持しており、
   前記検索対象列検出手段は、前記解析手段によって解析された前記検索キーワードのデータ型が前記数値型または文字列型の場合、前記検索の対象となるテーブルの各カラムのうち、データ型が前記数値型または文字列型のカラムであって、且つデータの長さの上限値が前記キーワード長検出手段によって検出されたキーワード長以上のカラムを、前記検索の対象となるテーブルを指定する情報に対応付けて前記テーブル構造情報記憶手段に格納されている前記テーブル構造情報から検出する
   ことを特徴とする請求項３記載の検索対象列決定装置。
5. リレーショナルデータベースに格納されているテーブルを対象とした、検索キーワードによる全文検索を行う全文検索システムに設けられた、入力手段、解析手段及び検索対象列検出手段を備えた検索対象列決定装置において、前記全文検索の対象とすべき前記テーブル内のカラムである検索対象列を決定するための検索対象列決定方法であって、
   前記入力手段がユーザ指定の検索キーワードを入力するステップと、
   前記解析手段が、前記入力された検索キーワードのデータ構造上の特徴を解析するステップと、
   前記検索対象列検出手段が、前記リレーショナルデータベースに格納されている検索の対象となるテーブルの各カラムのうち、前記解析された前記検索キーワードのデータ構造上の特徴に合致するカラムを、前記検索対象列として検出するステップと
   を具備することを特徴とする検索対象列決定方法。

Images