(57)【要約】【課題】検索条件においてカラムに指定されている役割を反映させてデータ検索を行う構成を実現する。【解決手段】検索サーバ装置３は、検索の対象となる２以上のカラム名が指定され、カラム名ごとに主キー、外部キーといった役割が指定されるテーブル定義２を検索条件として入力し、テーブル定義２において特定の役割が指定されているカラム名（例えば、主キーが指定されているカラム名）が含まれるテーブルデータに対して加重値を加重して評価値を算出し、算出したテーブルデータごとの評価値に基づきテーブルデータの順位付けを行い、順位付けの結果をテーブル定義２の入力元に出力する。【選択図】図１
2012212212.tif 000002
【特許請求の範囲】
【請求項１】
複数の項目を含み、前記複数の項目のうちの任意の項目に、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられる項目データ
に対する検索を行うデータ検索装置であって、
前記複数種の役割の各々に対する係数値が定義される係数値定義情報を記憶する係数値定義情報記憶部と、
検索の対象となる２以上の項目が検索対象項目として指定され、検索対象項目ごとに役割が指定される検索条件を入力する検索条件入力部と、
前記検索条件において特定の役割が指定されている検索対象項目を優先検索対象項目として選択し、優先検索対象項目を前記特定の役割として含む加重対象項目データに対して所定の加重値を係数値に加重して評価値を算出する旨の加重ルールを生成する優先検索対象項目選択部と、
検索対象項目ごとに、検索対象項目を含む項目データを検索し、検索した項目データが前記加重対象項目データに該当しない場合は、検索した項目データにおける検索対象項目の役割を判断し、当該検索対象項目の役割に対応する係数値を用いて評価値を算出し、検索した項目データが前記加重対象項目データに該当する場合は、検索した項目データにおける検索対象項目の役割を判断し、前記加重ルールに従い、当該検索対象項目の役割に対応する係数値に前記加重値を加重して評価値を算出する検索実行部と、
前記検索実行部により算出された評価値に基づき、前記検索実行部により検索された項目データの順位付けを行い、項目データの順位付けの結果を示す検索結果を、前記検索条件の入力元に出力する検索結果出力部とを有することを特徴とするデータ検索装置。
【請求項２】
前記優先検索対象項目選択部は、
前記加重対象項目データに含まれる検索対象項目の役割が前記検索条件において当該検索対象項目に指定されている役割と一致する場合に、当該役割に対応する係数値に前記加重値を加重して評価値を算出する旨の加重ルールを生成し、
前記検索実行部は、
検索した項目データが前記加重対象項目データに該当する場合に、検索した項目データにおける検索対象項目の役割が前記検索条件において当該検索対象項目に指定されている役割と一致するか否かを判断し、役割が一致する場合に、当該役割に対応する係数値に前記加重値を加重して評価値を算出することを特徴とする請求項１に記載のデータ検索装置。
【請求項３】
前記優先検索対象項目選択部は、
前記検索条件において各検索対象項目に指定されている役割のうち、前記加重ルールを適用しない役割をルール適用外役割として指定し、
前記検索実行部は、
検索した項目データが前記加重対象項目データに該当する場合であっても、検索した項目データにおける検索対象項目の役割が前記ルール適用外役割に該当する場合は、当該役割に対応する係数値には前記加重値を加重しないことを特徴とする請求項１又は２に記載のデータ検索装置。
【請求項４】
前記係数値定義情報記憶部は、
前記複数種の役割に設けられている優先順位に従い、優先順位が高い役割ほど係数値が高くなる係数値定義情報を記憶し、
前記優先検索対象項目選択部は、
前記検索条件において最も優先順位が高い役割が指定されている検索対象項目を優先検索対象項目として選択することを特徴とする請求項１〜３のいずれかに記載のデータ検索装置。
【請求項５】
前記検索実行部は、
評価値の算出に用いる係数値が所定の閾値未満であれば、検索した項目データについて当該係数値を用いずに評価値を算出することを特徴とする請求項１〜４のいずれかに記載のデータ検索装置。
【請求項６】
係数値定義情報記憶部は、
相互に関連する２以上の項目データにおいて同一の検索対象項目が同一の役割として含まれている場合の係数値を重複係数値とし、前記重複係数値を他の係数値よりも低い値として定義する係数値定義情報を記憶しており、
前記検索実行部は、
検索した項目データに含まれている検索対象項目が、当該項目データと関連する検索済みの他の項目データに含まれており、当該検索対象項目の両項目データにおける役割が同一である場合に、検索した項目データについて、当該役割に対して前記重複係数値を適用して評価値を算出することを特徴とする請求項１〜５のいずれかに記載のデータ検索装置。
【請求項７】
前記検索実行部は、
前記重複係数値が所定の閾値未満であれば、検索した項目データについて前記重複係数値を用いずに評価値を算出することを特徴とする請求項６に記載のデータ検索装置。
【請求項８】
前記検索条件入力部は、
項目以外のデータ要素が検索データ要素として指定される検索条件を入力し、
前記検索実行部は、
検索データ要素を含む項目データを検索し、検索した項目データが前記加重対象項目データに該当しない場合は、検索した項目データにおける当該検索データ要素の役割を判断し、当該検索データ要素の役割に対応する係数値を用いて評価値を算出し、検索した項目データが前記加重対象項目データに該当する場合は、検索した項目データにおける当該検索データ要素の役割を判断し、前記加重ルールに従い、当該検索データ要素の役割に対応する係数値に前記加重値を加重して評価値を算出することを特徴とする請求項１〜７のいずれかに記載のデータ検索装置。
【請求項９】
前記データ検索装置は、
複数のカラムを含み、前記複数のカラムのうちの任意のカラムに、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられるテーブルデータ
に対する検索を行うことを特徴とする請求項１〜８のいずれかに記載のデータ検索装置。
【請求項１０】
前記検索条件入力部は、
検索の対象となる２以上のカラムが検索対象カラムとして指定され、いずれかの検索対象カラムに主キーとしての役割が指定される検索条件を入力し、
前記優先検索対象項目選択部は、
前記検索条件において主キーとしての役割が指定されている検索対象項目を優先検索対象項目として選択し、優先検索対象項目を主キーとして含む加重対象項目データに対して所定の加重値を係数値に加重して評価値を算出する旨の加重ルールを生成することを特徴とする請求項９に記載のデータ検索装置。
【請求項１１】
コンピュータが、
複数の項目を含み、前記複数の項目のうちの任意の項目に、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられる項目データ
に対する検索を行うデータ検索方法であって、
前記コンピュータが、前記複数種の役割の各々に対する係数値が定義される係数値定義情報を記憶する係数値定義情報記憶ステップと、
前記コンピュータが、検索の対象となる２以上の項目が検索対象項目として指定され、検索対象項目ごとに役割が指定される検索条件を入力する検索条件入力ステップと、
前記コンピュータが、前記検索条件において特定の役割が指定されている検索対象項目を優先検索対象項目として選択し、優先検索対象項目を前記特定の役割として含む加重対象項目データに対して所定の加重値を係数値に加重して評価値を算出する旨の加重ルールを生成する優先検索対象項目選択ステップと、
前記コンピュータが、検索対象項目ごとに、検索対象項目を含む項目データを検索し、検索した項目データが前記加重対象項目データに該当しない場合は、検索した項目データにおける検索対象項目の役割を判断し、当該検索対象項目の役割に対応する係数値を用いて評価値を算出し、検索した項目データが前記加重対象項目データに該当する場合は、検索した項目データにおける検索対象項目の役割を判断し、前記加重ルールに従い、当該検索対象項目の役割に対応する係数値に前記加重値を加重して評価値を算出する検索実行ステップと、
前記コンピュータが、前記検索実行ステップにより算出された評価値に基づき、前記検索実行ステップにより検索された項目データの順位付けを行い、項目データの順位付けの結果を示す検索結果を、前記検索条件の入力元に出力する検索結果出力ステップとを有することを特徴とするデータ検索方法。
【請求項１２】
複数の項目を含み、前記複数の項目のうちの任意の項目に、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられる項目データ
に対する検索を行うコンピュータに、
前記複数種の役割の各々に対する係数値が定義される係数値定義情報を記憶する係数値定義情報記憶ステップと、
検索の対象となる２以上の項目が検索対象項目として指定され、検索対象項目ごとに役割が指定される検索条件を入力する検索条件入力ステップと、
前記検索条件において特定の役割が指定されている検索対象項目を優先検索対象項目として選択し、優先検索対象項目を前記特定の役割として含む加重対象項目データに対して所定の加重値を係数値に加重して評価値を算出する旨の加重ルールを生成する優先検索対象項目選択ステップと、
検索対象項目ごとに、検索対象項目を含む項目データを検索し、検索した項目データが前記加重対象項目データに該当しない場合は、検索した項目データにおける検索対象項目の役割を判断し、当該検索対象項目の役割に対応する係数値を用いて評価値を算出し、検索した項目データが前記加重対象項目データに該当する場合は、検索した項目データにおける検索対象項目の役割を判断し、前記加重ルールに従い、当該検索対象項目の役割に対応する係数値に前記加重値を加重して評価値を算出する検索実行ステップと、
前記検索実行ステップにより算出された評価値に基づき、前記検索実行ステップにより検索された項目データの順位付けを行い、項目データの順位付けの結果を示す検索結果を、前記検索条件の入力元に出力する検索結果出力ステップとを実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ検索技術に関し、より具体的には、テーブルデータ（以下、単にテーブルともいう）等の複数の項目が含まれるデータに対するデータ検索技術に関する。
【背景技術】
【０００２】
システム統合などに伴って必要となるデータベースの統合処理では、異なるデータベースのテーブル間でデータの移行が必要であり、この際、各カラムの対応関係に従ってデータの内容を一方から他方へ反映するという処理が発生する。
このようなデータ移行をリアルタイムに実施するために、変更差分データのみを検出し、データ移行する方式（Ｃｈａｎｇｅ  Ｄａｔａ  Ｃａｐｔｕｒｅ）が利用されている。
このような移行方式では、連携元／連携先のテーブルの主キーのカラムが一致するか、１対１の対応が可能であることが必要となる。
【０００３】
前記データ連携処理を実現するためには、各テーブル間のカラムの対応関係を何らかの手段で検出して対応づける必要がある。
このような対応関係を検出する作業を自動化するために、スキーママッチング技術と呼ばれる技術が利用される。
スキーママッチング技術は、対応関係を検出する２個のテーブルやテーブルの集合体であるスキーマなどの構造を入力として受け取り、これらの２個の構造の間の対応関係を出力する。
以下では一例としてデータベースのテーブルとその子要素であるカラムを比較する場合について説明する。
【０００４】
スキーママッチング技術において、各テーブルのカラム間の対応関係を検出する際には、カラム名やデータ型、その他の情報を用いて複数の類似判定手法により複数の判定結果を生成し、それらの結果を総合的に判断して最終的な類似度を決定する方法が一般的である。
このため、一般的に処理量が多く時間のかかる処理となる。
社会インフラなどの大規模システム（数千テーブル程度を想定）の場合、データベースのテーブル情報を専用のデータベースなどに格納し、スキーマ情報の一元管理を実施することが一般的であるが、ある連携先テーブルに対して、データ連携可能な連携元テーブルについての情報が事前に得られていない場合、登録されたテーブルすべてに対してスキーママッチングを実施する必要があり、膨大な時間を要してしまう。
【０００５】
非特許文献１に記載の技術では、すべてのテーブルに対してスキーママッチング実施を避けるために全文検索エンジンを利用して、入力として与えた比較対象テーブルカラムと類似したカラムを持つテーブル群をスキーマ単位でまとめて出力として提供している。
ここでは、テーブル定義情報はデータ定義言語（ＤＤＬ：Ｄａｔａ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ）等で記載されて与えられており、通常の全文検索のように検索キーワードや検索クエリ文のような文字列ではなく、入力データとして構造を持ったデータをそのまま渡している点に特色がある。
非特許文献１では、テーブル構造に含まれるテーブル名、カラム名などを抽出して、これを列挙することにより検索キーワードを作成している。
また、あらかじめスキーマ情報ＤＢ内のテーブル情報に対して、全文検索用のインデックスを生成し、上記のとおり生成した検索キーワードを全文検索エンジンの入力として与えている。
出力された比較候補テーブル群に対して集約処理を施して、工夫されたＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）によってユーザに提示することで、ユーザはスキーママッチングを実施するテーブルを選択する。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ｋｕａｎｇ  Ｃｈｅｎ  ａｎｄ  Ｊａｙａｎｔ  Ｍａｄｈａｖａｎ  ａｎｄ  Ａｌｏｎ  Ｈａｌｅｖｙ：  Ｓｃｈｅｍｒ：  ａ  Ｓｃｈｅｍａ  Ｓｅａｒｃｈ  Ｅｎｇｉｎｅ  ｆｏｒ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｉｎｔｅｇｒａｔｉｏｎ，  ＡＣＭ  ＳＩＧＭＯＤ  ’０９
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来技術のスキーマ検索機能では、入力されたテーブル情報よりカラム名などを抽出して、一連の検索キーワードを作成し、全文検索エンジンに提供している。
例えば、注文テーブルが「注文ＩＤ、顧客名、商品コード、注文数」というカラムを持つ場合、全文検索エンジンに与えるキーワードは次のようになる。
“注文テーブル  ＯＲ  注文ＩＤ  ＯＲ  顧客名  ＯＲ  商品コード  ＯＲ  注文数”
このため、検索の入力になるテーブル内の各カラムは併記されているのみで重要度を判断する機能を有していないという課題がある。
データ連携を前提とする場合、主キーのカラムの重要度が高いと考えられるが、一般的に１個のテーブル内で主キーのカラムとなるのは数個程度である。
１カラムでテーブルのレコードが一意に特定されることが望ましいが、実際には複数カラムをあわせて一意となる場合も多く、複数カラムが主キーとなる場合が考えられるので、主キーは必ずしも１カラムで構成されるとはいえない。
大規模システムで使用されるテーブルのカラム数が１００カラム以上の場合あるが、全文検索キーワードをカラム名の列挙で示した場合、カラム数が１００カラム以上などの場合、相対的に主キーのカラムの重要度が低くなってしまう課題がある。
結果として、比較対象テーブルと属性カラムの一致は多いが、キーとなるカラムが一致していないテーブルが、検索結果として返却されると想定される。
また全文検索エンジンは、一般にキーワードの出現回数を、検索ランキングを決定する情報として利用しているために、例えば外部キーなどの複数テーブルで同名になりやすいキーが含まれている場合、検索ランキングの判断に外部キーが大きな影響を与えてしまうという課題がある。
【０００８】
この発明は、上記のような課題を解決することを主な目的の一つとしており、主キーや外部キーといった項目に指定されている役割を反映させてデータ検索を行う構成を実現することを主な目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るデータ検索装置は、
複数の項目を含み、前記複数の項目のうちの任意の項目に、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられる項目データ
に対する検索を行うデータ検索装置であって、
前記複数種の役割の各々に対する係数値が定義される係数値定義情報を記憶する係数値定義情報記憶部と、
検索の対象となる２以上の項目が検索対象項目として指定され、検索対象項目ごとに役割が指定される検索条件を入力する検索条件入力部と、
前記検索条件において特定の役割が指定されている検索対象項目を優先検索対象項目として選択し、優先検索対象項目を前記特定の役割として含む加重対象項目データに対して所定の加重値を係数値に加重して評価値を算出する旨の加重ルールを生成する優先検索対象項目選択部と、
検索対象項目ごとに、検索対象項目を含む項目データを検索し、検索した項目データが前記加重対象項目データに該当しない場合は、検索した項目データにおける検索対象項目の役割を判断し、当該検索対象項目の役割に対応する係数値を用いて評価値を算出し、検索した項目データが前記加重対象項目データに該当する場合は、検索した項目データにおける検索対象項目の役割を判断し、前記加重ルールに従い、当該検索対象項目の役割に対応する係数値に前記加重値を加重して評価値を算出する検索実行部と、
前記検索実行部により算出された評価値に基づき、前記検索実行部により検索された項目データの順位付けを行い、項目データの順位付けの結果を示す検索結果を、前記検索条件の入力元に出力する検索結果出力部とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、検索条件において特定の役割が指定されている項目を前記特定の役割として含む項目データに対して加重値を加重して評価値を算出するため、特定の役割が指定されている項目が含まれる項目データの評価値を高くすることができ、項目の役割を反映させたデータ検索を行うことができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態１に係るシステム構成例を示す図。
【図２】実施の形態１に係る検索サーバ装置の構成例を示す図。
【図３】実施の形態１に係るテーブル定義の入力例を示す図。
【図４】実施の形態１に係る入力されたテーブル定義の構造を示す図。
【図５】実施の形態１に係るクエリ分解部の動作例を示すフローチャート図。
【図６】実施の形態１に係る重要度判断表の例を示す図。
【図７】実施の形態１に係るクエリ分解部の出力イメージを示す図。
【図８】実施の形態１に係る検索処理のフローチャート図。
【図９】実施の形態２に係るテーブル定義の入力例を示す図。
【図１０】実施の形態２に係る重要度判断表及び追加要素判断表の例を示す図。
【図１１】実施の形態１に係る検索インデックスの例を示す図。
【図１２】実施の形態１に係る検索インデックス重みデータの例を示す図。
【図１３】実施の形態１に係る評価値の算出例を示す図。
【図１４】実施の形態１に係る評価値の算出例を示す図。
【図１５】実施の形態２に係るクエリ分解部の出力イメージを示す図。
【図１６】実施の形態１又は２に係る検索サーバ装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１２】
実施の形態１．
本実施の形態では、検索処理への入力としてデータベーステーブルのような構造を受け取り、構造に含まれる項目の重要度を考慮した検索結果を返却する装置および方法を説明する。
そして、本実施の形態では、検索インデックス作成時の重み付加方法、および検索を実行する時の検索インデックスの重み付けのＯＮ／ＯＦＦ操作、および検索自体に付与する重み、さらには検索結果集約時の重みを制御することにより、項目の重要度を検索結果に反映することが可能となる。
以下、図面を参照して、本実施の形態について説明する。
【００１３】
図１は、本実施の形態に係るシステム構成例を示す。
図１では、検索サーバ装置３においてテーブルデータを検索し、検索結果を検索クライアント装置１に提示する例を説明する。
つまり、検索クライアント装置１が検索条件としてテーブル定義２を検索サーバ装置３に与え、検索サーバ装置３が、テーブル定義２と類似する１つ以上のテーブルを検索し、検索結果をテーブル群４として、検索クライアント装置１に返却する。
スキーママッチング処理装置５は、検索クライアント装置１にて選択されたテーブル群４の中からユーザが選択した１つのテーブルと、テーブル定義２とのスキーママッチングを実行するものである。
スキーママッチング処理装置５は、本実施の形態に係る検索サーバ装置３の動作とは直接関係しないが、本実施の形態に係る検索サーバ装置３の出力を利用するシステムとして表したものである。
【００１４】
検索クライアント装置１は、検索サーバ装置３に対してテーブルの検索を要求する。
テーブル定義２は、検索クライアント装置１が検索サーバ装置３に与える検索条件のデータである。
【００１５】
検索サーバ装置３は、検索クライアント装置１からの検索要求をうけて、検索結果を返却する。
より具体的には、検索サーバ装置３は、検索の対象となる２以上のカラム名が指定され、カラム名ごとに主キー、外部キーといった役割が指定されるテーブル定義２を検索条件として入力する。
そして、検索サーバ装置３は、テーブル定義２において特定の役割が指定されているカラム名（例えば、主キーが指定されているカラム名）が含まれるテーブルデータに対して加重値を加重して評価値を算出し、算出したテーブルデータごとの評価値に基づきテーブルデータの順位付けを行い、順位付けの結果をテーブル定義２の入力元である検索クライアント装置１に出力する。
検索サーバ装置３は、図１に示すように、テーブル検索部３１とテーブル登録部３２に大別される。
テーブル検索部３１とテーブル登録部３２の詳細は、後述する。
なお、検索サーバ装置３は、データ検索装置の例である。
【００１６】
テーブル群４は、検索サーバ装置３が出力する検索結果である。
スキーママッチング処理装置５は、スキーママッチングを実行する。
【００１７】
本実施の形態において対象とするテーブルデータは、複数のカラム（項目）を含み、複数のカラムのうちの任意のカラムに、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられている。
データ処理のための複数種の役割としては、前述したように、例えば、主キー、外部キー、索引カラム等がある。
本実施の形態において対象とするテーブルデータは、項目データの例に相当する。
【００１８】
図２は、検索サーバ装置３の内部構成例を示す。
検索サーバ装置３は、テーブル検索部３１とテーブル登録部３２によって構成される。
【００１９】
テーブル検索部３１は、クエリ受信部３１０とクエリ分解部３１１と検索指示部３１２とインデックス重み付けＯＮ／ＯＦＦ部と検索実行部３１４と結果集約部３１５とクエリ返却部３１６と検索インデックス記憶部３１７によって構成される。
テーブル登録部３２は、テーブル情報登録部３２０と重複検出部３２１とスキーマ情報ＤＢ３２２と検索インデックス作成部３２３とインデックス重み付け設定部３２４から構成される。
テーブルデータは、スキーマ情報ＤＢ３２２に保管されている。
以下では、テーブル検索部３１から説明する。
【００２０】
テーブル検索部３１において、検索インデックス記憶部３１７は、検索インデックス３１４０と検索インデックス重みデータ３１４１を記憶する。
検索インデックス３１４０は、どのテーブルデータにどのカラム名が含まれているかを示す情報である。
図１１は、検索インデックス３１４０の例である。
図１１に示すように、検索インデックス３１４０では、カラム名ごとに、そのカラム名が含まれているテーブルの識別子と、そのカラム名がいずれのカラム種別（役割）としてテーブルに含まれているかが表される。
例えば、「注文ＩＤ」というカラム名は、テーブルＡ−Ａに主キーとして含まれており、また、テーブルＡ−Ｃに属性カラムとして含まれている。
検索インデックス重みデータ３１４１は、複数種のカラム種別（役割）の各々に対する係数値がインデックス重みとして定義される情報である。
図１２は、検索インデックス重みデータ３１４１の例である。
例えば、主キーに対してはインデックス重みとして「２．０」という係数値が定義され、外部キーに対してはインデックス重みとして「１．０」という係数値が定義されている。
なお、インデックス重みの値が大きいカラム種別が、テーブル検索において優先的な取り扱いとなる。
なお、検索インデックス重みデータ３１４１におけるカラム種別ごとのインデックス重みの値は、後述する重要度判断表３３に示されているインデックス重みの値と一致する。
また、重複カラムについては、後述する。
検索インデックス重みデータ３１４１は係数値定義情報の例に相当し、係数値定義情報たる検索インデックス重みデータ３１４１を記憶する検索インデックス記憶部３１７は係数値定義情報記憶部の例に相当する。
また、検索インデックス記憶部３１７が検索インデックス重みデータ３１４１を記憶する動作は、係数値定義情報記憶ステップの例に相当する。
【００２１】
以下では、テーブル検索部３１にて検索が実施される際の各要素の動作を説明する。
【００２２】
検索サーバ装置３は、検索クライアント装置１より検索入力としてテーブル定義２を受け取る。
テーブル定義２は、テーブル検索部３１内のクエリ受信部３１０によって受信される。
テーブル定義２は構造をもった情報であり、実施の形態１においてはデータベースのテーブル定義を想定する。
データベースのテーブル定義２は例えば図３に示すようにデータ定義言語（ＤＤＬ）にて渡される場合がある。
図３は注文テーブルのテーブル定義２の例（ＤＤＬによる記述例）を表しており、カラムとして「注文ＩＤ」と「顧客名」と「商品コード」と「注文数」が存在すること、および「注文ＩＤ」は単独で主キーであり、「商品コード」は商品テーブルの商品コードを参照する外部キーであること、および「顧客名」に対してデータベースの機能である索引が付与されていることを表している。
テーブル定義２は図３のようにデータ定義言語（ＤＤＬ）にて表現できるが、構造を表現できる形式であれば、どのような形式でもよく、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）の形式であってもよい。
クエリ受信部３１０は、例えば図３の形式のテーブル定義２を受け取り、これを解釈し、図４のような構造情報を取得する。
図４は図３のテーブル定義２（ＤＤＬ）の構造を解釈した結果を図として表現したものである。
このように、クエリ受信部３１０は、検索の対象となる２以上のカラム（項目）が指定され、検索対象のカラムごとに役割（主キー、外部キー等）が指定されるテーブル定義２を検索条件として入力しており、検索条件入力部の例に相当する。
また、クエリ受信部３１０がテーブル定義２を受信する動作が、検索条件入力ステップの例に相当する。
【００２３】
クエリ分解部３１１は、あらかじめ設定された重要度判断表３３に従い、クエリ受信部３１０が抽出した構造情報に含まれるカラム情報を重要度に従いグループ分けを実施し、前記各グループを検索する際の検索重み、および検索結果に対する重みを設定する。
【００２４】
図５にクエリ分解部３１１のフローチャートを示す。
また、重要度判断表３３の例を図６に示す。
図６の例では重要度順に主キー、外部キー、索引カラム、属性カラムを指定している。
図６の重要度判断表３３を以下にて説明する。
【００２５】
重要度順３３１は、カラム種別３３２に記載された役割の重要度を示しており、１から開始する連番にて設定されている。
インデックス重み３３３は、指定された重要度順３３１の順序に従ってテーブルごとに評価値を算出する際に、テーブルに出現するカラム名の役割に対して設定する重みを指定するものである。
前述したように、検索インデックス重みデータ３１４１（図１２）のインデックス重み３１４１ｂの値は、重要度判断表３３のインデックス重み３３３の値と一致している。
【００２６】
図６において表を分けて記載している重複カラムについて説明する。
スキーマ情報ＤＢ３２２に対してテーブル情報を登録する際に、同一スキーマ内で同名のカラムが同一の役割として検出された場合、そのカラムは重複カラムと判断される。
前記重複カラムと判断されたカラムについては、インデックス重みを図６の表に従って、１．０以下に設定する（図６の例では、０．５）。
例えば、スキーマ設計が非効率的な場合は、同じカラム名が同じスキーマの複数のテーブルにおいて同じ役割として重複して出現する場合がある。
このような場合に同じカラム名が同じ役割として出現する度に評価値を計上すると、このようなスキーマのテーブル群の評価値が実態以上に高くなってしまい、適正な検索結果とならない可能性がある。
このため、同一スキーマ内で同名のカラムが同一の役割として検出された場合には、２回目以降の検出に対する係数値を他の係数値よりも低く抑えるようにしている。
【００２７】
重要度判断表３３の内容は以下の理由により設定されており、図６の内容をデフォルト値とするが、変更も可能とする。
実施の形態１ではテーブル定義２はデータベーステーブルを想定しており、異なるデータベース間でのデータ移行を変更差分データ抽出技術の利用によって実施することを想定している。
このためデータ連携できるためには連携元と連携先のデータベーステーブルの主キーのカラムが一致しているか、１対１の関係であることが必要となる。
この状況下で最も重要なカラムは主キーのカラムである。
主キーのカラムはあるデータベーステーブルに含まれる各行のレコードデータを一意に識別する値をもったカラムである。
主キーは一般に複数カラムから構成される場合がある。
外部キーは他のデータベーステーブルの主キーを参照しているため、外部キーが存在するということは、これに対応する主キーが存在することになる。
このため外部キーのカラムの重要度を主キーのカラムの次に設定している。
索引カラムは図３のテーブル定義２（ＤＤＬ）の中では、顧客名に相当する。
データベースに索引を設定する理由は利用頻度の高いカラムについて検索速度を向上するためである。
つまり索引カラムは主キー、外部キーに次いで重要なカラムであると判断できる。
この他にユニークキーと呼ばれるものがあるが、これは主キーと同様にあるテーブルのレコードを一意に識別するという点で主キーと同等と判断しており、本実施の形態では主キーと特に区別しない。
その他のカラム種別を図６では属性カラムと表現しており、主キー、外部キー、索引カラムのいずれにもあてはまらないカラムを前記属性カラムとして分類する。
【００２８】
図５のフローチャートについて以下に説明する。
【００２９】
クエリ分解部３１１は、クエリ受信部３１０が提供する図４の構造情報を受け取る（Ｓ３１１１）。
次に、クエリ分解部３１１は、図６のような重要度判断表３３を参照し（Ｓ３１１２）、この重要度判断表３３をもとにして各カラム（注文ＩＤ、顧客名等）を重要度別にグループ分けする（Ｓ３１１３）。
図６の例では、主キー、外部キー、索引カラム、属性カラムに分類される。
重要度別に分類されたカラムグループごとに検索処理を実施するため、それぞれの検索処理に必要な情報をクエリ分解部３１１がＳ３１１４とＳ３１１５のステップを前記カラムグループ数だけ繰り返し実行することにより作成する。
以下では前記繰り返しの処理内容を説明する。
検索入力データとしては図４のテーブルを使用する。
Ｓ３１１４の最初のループでは、重要度順３３１が「１」である主キーが処理対象になり、図４の構造情報において主キーに分類されているカラムグループが処理される。
主キーの検索結果を基準として扱うため、Ｓ３１１４では、主キーに対しては、インデックス重みの値「１．０」を付与する。
つまり重み付けは実施しない。
Ｓ３１１５では検索キーワードが作成されるが、主キーについては、主キーのカラムグループに含まれているカラム名を列挙するのみとなる。
Ｓ３１１４の２回目のループでは、重要度順３３１が「２」である外部キーが処理対象になり、図４の構造情報において外部キーに分類されているカラムグループが処理される。
主キー以外のカラムについては、そのカラム数の逆数を検索集計重みとして割り当てる。
ここでは、外部キーのカラムの数の逆数がＳ３１１４にて検索集計重みとして割り当てられる。
主キー以外のカラムが検索において全件検出された場合に主キーが１件検出された場合と同じ効果にするために本重み付けを実施している。
Ｓ３１１５においては、検索キーワードを生成する。
ここでは、主キーが検出されたテーブルに対してインデックス重みに加重値を加重する旨の加重ルールが含まれる検索キーワードを生成する。
具体的には、主キーが含まれるテーブルと同じテーブルに外部キーのカラムが含まれる場合、その検索スコアを重要度判断表３３の重要度順３３１の値が「１」であるインデックス重み３３３で乗ずる、という検索キーワードとする。
加重するインデックス重み３３３は、ここでは主キーに対して割り当てるインデックス作成時の重み（つまり、「２．０」）となる。
ただし、Ｓ３１１５を実行している時点では、検索は実施されていないので、前記主キーが含まれるテーブル名はパラメータとして指定しておき、検索実行時に実際のテーブル名にて置換される。
２回目以降のループ処理はＳ３１１４とＳ３１１５に関する限り、２回目と同じ処理になる。
クエリ分解部３１１は、Ｓ３１１６にて未処理のカラムグループがないことを確認し、Ｓ３１１７にて処理結果を返却する。
処理結果は例えば図７に示す内容を持つ。
図７の検索実行内容情報について以下に説明する。
【００３０】
図７は検索の実行に必要な情報を検索指示部３１２に渡すためのデータ構造である。
図７の検索実行内容情報は、図４の構造情報に基づいて図５に示すフローが実施されて生成されたものである。
【００３１】
「検索順」の記載の順番で、検索実行部３１４による検索が実施される。
「検索カラムリスト」は「カラム種別」の種類別にグルーピングされたカラムグループを示す。
「カラム種別」は検索実行に必須の情報ではないが、図７の各行がどのカラム種別に対応するものであるのかを示すために記載した。
【００３２】
「インデックス重みＯＮ／ＯＦＦ」は、検索時に検索インデックス重みデータ３１４１に記述されている重みを有効化（ＯＮ）するか無効化（ＯＦＦ）するかを示す。
なお、原則として、主キー、外部キー、索引カラムに対してはインデックス重みをＯＮとし、属性カラムに対してはＯＦＦとする。
また、インデックス重みがＯＦＦとなったカラム種別は、「検索キーワード」に示される評価値の加重ルールも適用されない。
【００３３】
「検索集計重み」は検索処理において検出された件数の重みを制御するためのものである。
主キーのカラムが１件検出されたときと、それ以外のカラムが検出されたときは重要度が異なるため、主キー以外については全カラムが検出されたときに、主キー１カラムと同等の評価になるようにカラム数で除算した値を「検索集計重み」として使用している。
本重みを検索実行部３１４にて返却された検索結果に対するそれぞれの検索ポイント値に対して乗算することにより、各カラム種別に対する検索結果に重みをつけている。
例えば、あるテーブルにおいて、検索カラムリストに記述されているいずれか２つのカラムが、外部キーとして抽出された場合は、外部キーが２つなので、検索集計重みは「０．５」であり、各々のカラムのインデックス重みの値を０．５倍して評価値を算出する。
【００３４】
「検索キーワード」は、図５のＳ３１１５にて作成された検索キーワードを保持する。
「検索キーワード」は、主キーについては、各カラム名をＯＲで区切ったキーワードとしており、図４の例では「注文ＩＤ」のみであるため、「注文ＩＤ」のみが検索キーワードとして指定される。
但し、テーブル定義２において複数のカラムが主キーとして指定されている場合には、各カラムが検索キーワードとなる。
また、外部キーの「検索キーワード」では、「注文ＩＤ」が主キーとして含まれるテーブルで外部キーとなっているカラムに対しては、インデックス重み（図１２の例では、「１．５」）を２．０倍する旨が指定されている。
同様に、索引カラムの「検索キーワード」では、「注文ＩＤ」が主キーとして含まれるテーブルで索引カラムとなっているカラムに対しては、インデックス重み（図１２の例では、「１．２」）を２．０倍する旨が指定されている。
同様に、属性カラムの「検索キーワード」では、「注文ＩＤ」が主キーとして含まれるテーブルで属性カラムとなっているカラムに対しては、インデックス重み（図１２の例では、「１．０」）を２．０倍する旨が指定されている。
【００３５】
このように、クエリ分解部３１１は、テーブル定義２において特定の役割が指定されているカラム、具体的には、主キーの役割が指定されているカラム「注文ＩＤ」を選択し、選択した「注文ＩＤ」を主キーとして含むテーブル（加重対象項目データに相当）に対して加重値（図７の例では、「２．０」倍）をインデックス重みの係数値に加重して評価値を算出する旨の加重ルールが含まれる検索キーワードを生成する。
本実施の形態では、テーブル定義２において主キーの役割が指定されているカラム「注文ＩＤ」は、優先検索対象項目の例に相当する。
また、クエリ分解部３１１は、優先検索対象項目選択部の例に相当する。
また、クエリ分解部３１１の動作は、優先検索対象項目選択ステップの例に相当する。
【００３６】
検索指示部３１２は、クエリ分解部３１１が提供する図７の検索実行内容情報を受け取り、図７の内容に従って検索実行部３１４に検索実行を指示する。
検索指示部３１２は、クエリ分解部３１１が与える情報に従い、インデックス重み付けＯＮ／ＯＦＦ部３１３に指示を出し、検索実行部３１４が用いる検索インデックス重みデータ３１４１の有効化と無効化を変更する。
【００３７】
図８に検索指示部３１２とインデックス重み付けＯＮ／ＯＦＦ部３１３と検索実行部３１４の動作を説明するフローチャートを示す。
【００３８】
Ｓ３１２１では、検索指示部３１２が図７の検索実行内容情報を解釈する。
Ｓ３１２２では、検索指示部３１２が図７の「検索順」に指定された順番に検索実行順を決める。
つまり、検索指示部３１２は、未処理の検索処理のうち「検索順」が最小ものを選択する。
Ｓ３１２３では、検索指示部３１２が図７の「インデックス重みＯＮ／ＯＦＦ」に従い、インデックス重み付けＯＮ／ＯＦＦ部３１３を介して検索インデックス重みデータ３１４１の有効化もしくは無効化を実施する。
検索インデックス重みデータ３１４１が有効化されている場合で、インデックスの重みが１．０以下の場合、これを無視する設定も同時に実施する。
検索インデックス重みデータ３１４１は、後述するテーブル登録部３２内のインデックス重み付け設定部３２４にて設定されるが、同一スキーマ内に同名のカラムが同一の役割で存在した場合、２個目以降のカラムについて、インデックス重みは１．０以下に設定されるようになっており、これは外部キーなど同一スキーマに同名のカラムが多数存在する場合に検索結果に対する影響を防ぐために実施するものである。
Ｓ３１２４では、検索指示部３１２が図７の「検索キーワード」を検索実行部３１４に与え、検索実行を指示する。
２回目以降の検索時には１回目の検索で検出されたテーブル、つまり主キーを検索したときに主キーを含むテーブルとして検出されたテーブル名を「検索キーワード」に含める。
つまり、図７の「検索キーワード」内の（主キーと同一テーブル）部分を実際のテーブル名で置き換えることになる。
このため、Ｓ３１２４は１回目の検索結果より検索対象を絞り込むという効果を持つ。
また、２回目以降の検索時では、検索指示部３１２は、図７の「検索キーワード」とともに「検索カラムリスト」を検索実行部３１４に与え、「検索カラムリスト」内のカラムの検索を行わせる。
Ｓ３１２５では、検索指示部３１２が未処理のカラムグループの確認を実施し、Ｓ３１２６にて検索結果および、検索結果に対応する図７の「検索集計重み」の値を返却する。
【００３９】
ここで、図１３を参照して、検索実行部３１４の動作例を具体的に説明する。
なお、検索実行部３１４の動作は、検索実行ステップの例に相当する。
【００４０】
図１３の検索インデックス３１４０の内容は、図１１のものと同じである。
ここでは、検索実行部３１４は、図１３の検索インデックス３１４０を用いて、図７の検索実行内容情報及び図１２の検索インデックス重みデータ３１４１に従って、テーブルごとの評価値を算出する。
なお、テーブルＡ−Ａ、テーブルＡ−Ｂ、テーブルＡ−Ｃは、同じスキーマのテーブルであるとする。
【００４１】
テーブルＡ−Ａには、カラム「注文ＩＤ」が主キーとして含まれている。
図７の検索実行内容情報によれば、主キーに対してはインデックス重みはＯＮなので、検索インデックス重みデータ３１４１に従って、テーブルＡ−Ａには、評価値「２．０」が計上される。
テーブルＡ−Ｃには、カラム「注文ＩＤ」が含まれているが、属性カラムである。
図７の検索実行内容情報によれば、属性カラムに対してはインデックス重みはＯＦＦなので、テーブルＡ−Ｃには、評価値「１．０」が計上される。
【００４２】
テーブルＡ−Ａには、カラム「商品コード」が外部キーとして含まれている。
図７の検索実行内容情報によれば、外部キーに対してはインデックス重みはＯＮである。
また、テーブルＡ−Ａには、カラム「注文ＩＤ」が主キーとして含まれるため、図７の「検索キーワード」の評価点の加重ルールに従い、評価値が２．０倍になる。
このため、検索インデックス重みデータ３１４１に従って、テーブルＡ−Ａには、評価値「１．５×２．０＝３．０」が計上される。
テーブルＡ−Ｂには、カラム「商品コード」が主キーとして含まれている。
図７の検索実行内容情報によれば、主キーに対してはインデックス重みはＯＮである。
なお、テーブルＡ−Ｂには、カラム「注文ＩＤ」が主キーとして含まれてはいる訳ではないので、評価点の加重はなく、評価値「２．０」が計上される。
テーブルＡ−Ｃには、カラム「商品コード」が外部キーとして含まれている。
図７の検索実行内容情報によれば、外部キーに対してはインデックス重みはＯＮである。
なお、テーブルＡ−Ｃには、カラム「注文ＩＤ」が主キーとして含まれてはいる訳ではないので、評価点の加重はない。
また、同一スキーマ内のテーブルＡ−ＡとテーブルＡ−Ｃの両者において、カラム「商品コード」が外部キーとして含まれているので、テーブルＡ−Ｃのカラム「商品コード」は重複カラムとなり、重複カラムの評価値「０．５」が計上される。
【００４３】
テーブルＡ−Ａには、カラム「顧客名」が索引カラムとして含まれている。
図７の検索実行内容情報によれば、索引カラムに対してはインデックス重みはＯＮである。
また、テーブルＡ−Ａには、カラム「注文ＩＤ」が主キーとして含まれるため、図７の「検索キーワード」の評価点の加重ルールに従い、評価値が２．０倍になる。
このため、検索インデックス重みデータ３１４１に従って、テーブルＡ−Ａには、評価値「１．２×２．０＝２．４」が計上される。
テーブルＡ−Ｂには、カラム「顧客名」が含まれているが、属性カラムである。
図７の検索実行内容情報によれば、属性カラムに対してはインデックス重みはＯＦＦなので、テーブルＡ−Ｂには、評価値「１．０」が計上される。
【００４４】
テーブルＡ−Ａには、カラム「注文数」が含まれているが、属性カラムである。
図７の検索実行内容情報によれば、属性カラムに対してはインデックス重みはＯＦＦなので、テーブルＡ−Ａには、評価値「１．０」が計上される。
テーブルＡ−Ｃには、カラム「注文数」が索引カラムとして含まれている。
図７の検索実行内容情報によれば、索引カラムに対してはインデックス重みはＯＮである。
なお、テーブルＡ−Ｃには、カラム「注文ＩＤ」が主キーとして含まれてはいる訳ではないので、評価点の加重はなく、評価値「１．２」が計上される。
【００４５】
なお、図１３を用いた説明では、カラム「注文ＩＤ」が主キーとして含まれているテーブルＡ−Ａに、図７において外部キーとして指定されている「商品コード」が外部キーとして含まれている場合（及び図７において索引カラムとして指定されている「顧客名」が索引カラムとして含まれている場合）に、評価値を２．０倍する例を説明した。
これに対して、「検索キーワード」の条件解釈を緩和してもよい。
条件解釈の緩和の例を、図１４を用いて説明する。
【００４６】
図１４は、検索インデックス３１４０を示すが、図１３と異なり、テーブルＡ−Ａにはカラム「商品コード」が索引カラムとして含まれている例が示されている。
図７では、「商品コード」に対しては外部キーが指定されている。
このため、図１３を参照して説明した厳格な条件解釈を図１４に適用すると、カラム「商品コード」が外部キーとして含まれている訳ではないので、評価値の加重は行われず、テーブルＡ−Ａには索引カラムのインデックス重み「１．２」が計上される。
一方、緩和された条件解釈では、カラム種別は異なるものの、テーブルＡ−Ａには、図７で定義されているカラム「商品コード」が含まれるので、索引カラムのインデックス重みである「１．２」に加重係数「２．０」を加重して、「１．２×２．０＝２．４」が計上される。
このように、「検索キーワード」の加重ルールについて２種類のうちのいずれの方法を採用してもよい。
【００４７】
検索実行部３１４が、例えば、図１３又は図１４に示した手順によりテーブルごとに評価値を算出した後、結果集約部３１５が、検索実行部３１４からテーブルごとの評価値を取得し、評価値に対して、図７の「検索集計重み」により、重み付け集計を実施し、検索結果のランキングの最終決定を実施する。
つまり、検索実行部３１４は、「検索集計重み」による重み付け集計が行われた後の評価値をテーブル単位で合算し、合算値が大きい順にテーブルの順位付けを行い、順位付けに従ってテーブルが一覧表示されるリストをクエリ返却部３１６に渡す。
クエリ返却部３１６は、結果集約部３１５からのリストをテーブル群４として出力し、検索クライアント装置１に渡す。
なお、結果集約部３１５及びクエリ返却部３１６は、検索結果出力部の例に相当する。
また、結果集約部３１５及びクエリ返却部３１６の動作は、検索結果出力ステップの例に相当する。
【００４８】
検索クライアント装置１では、本システムの使用ユーザが受け取ったテーブル群４より、スキーママッチングを実施するデータベーステーブルを選択し、スキーママッチング処理装置５に渡す。
スキーママッチング処理装置５は、テーブル定義２と前記使用ユーザにより選択された前記データベーステーブルを入力としてスキーママッチング処理を実施する。
【００４９】
以下では、テーブル登録部３２にてデータベーステーブルが本システムに登録され、検索インデックスが作成される際の各要素の動作を説明する。
【００５０】
テーブル情報登録部３２０は、スキーマ情報ＤＢ３２２にデータベーステーブルを登録する作業の起点となる。
テーブル情報登録部３２０は、入力としてデータベーステーブル情報をデータ定義言語（ＤＤＬ）やＸＭＬファイルなどによって受け取り、重複検出部３２１に前記データベーステーブル情報を渡す。
【００５１】
重複検出部３２１では、スキーマ情報ＤＢ３２２の内容を確認し、前記データベーステーブル情報と重複する情報が既に登録されていないか否かを確認する。
このとき、重複検出部３２１は同一スキーマ内に前記データベーステーブル情報が示すテーブルの重複を確認する。
異なるスキーマに重複するテーブルがあっても問題としない。
スキーマ情報ＤＢ３２２には、データベーステーブル情報が格納される。
検索インデックス作成部３２３はテーブル情報登録部３２０より、データベーステーブル情報がスキーマ情報ＤＢ３２２に格納されたことの通知を受け、検索インデックス３１４０に対して前記データベーステーブル情報を追記するためにインデックス重み付け設定部３２４に情報を渡す。
【００５２】
インデックス重み付け設定部３２４は、登録された前記データベーステーブル情報の内容から図６に示すようなあらかじめ与えられた重要度判断表３３に従い、検索インデックス重みデータ３１４１に重みデータを書き込む。
このとき重複検出部３２１が同一スキーマ内に重複するデータベーステーブルを検出している場合は図６の表に従い、重み付けを「１．０」以下にして検索インデックス重みデータ３１４１に書き込む。
【００５３】
以上のように、本実施の形態によれば、データベーステーブルのような構造をもった実体を検索システムの入力として与えた場合に実体内の各項目の重要度を反映した検索が可能となる。
具体例としては、検索入力となったテーブルの主キーカラムに対して、同じく主キーカラムとなっており、さらに前記テーブル内の重要項目である外部キーカラムや索引対象カラムを多く含むテーブルを検索結果として返却することが可能となる。
また、登録されている検索対象のテーブル群の中に前記のようなテーブルがない場合でも、検索入力テーブルの主キーを重要カラムである外部キーカラムや索引対象カラムとなっているテーブルを検出し、さらに前記検索入力テーブルの他のカラムについても同一スキーマ内にできるだけ多く含むようなテーブル群の返却が可能となる。
【００５４】
なお、本実施の形態では、検索クライアント装置１は、複数のカラムで構成されるテーブルデータの検索を検索サーバ装置３に要求し、検索サーバ装置３は、検索結果として１つ以上のテーブルデータを検索クライアント装置１に提示する例を説明した。
しかし、テーブルデータ以外にも、複数の項目を含み、複数の項目のうちの任意の項目に、データ処理のための複数種の役割のうちのいずれかの役割が割り当てられる項目データであれば、本実施の形態に係る検索サーバ装置３は適用可能である。
【００５５】
本実施の形態では、
データベースのテーブルなど構造をもつ実体を入力として受け取り、あらかじめ登録された前記実体の集合の中から指定された手法で類似度を算出し、入力として与えられた前記実体と類似度の高いものの集合を類似度のランキング順にて返却する検索システムであって、
前記実体の集合の定義情報を格納するスキーマ情報ＤＢと、
スキーマ情報ＤＢ内の前記実体に対しての検索処理を実現するための検索インデックスを作成する検索インデックス作成部と、
前記検索インデックスを使用して検索を実施する検索実行部と、
入力された前記実体の構造を持つ定義情報より、その構造を解釈してあらかじめ与えられた前記実体のカラム種別の重要度情報をもとに重要な項目を抽出し、前記検索実行部に入力として提供し、あらかじめ設定された複数回の検索作業への入力項目と、前記検索作業に与える重み値を提供するクエリ分解部と、
前記クエリ分解部によって提供された検索作業を検索部に指示する検索指示部と、
検索実行時に検索インデックス上の重み付けの有効化と無効化を切り替える検索重み付けＯＮ／ＯＦＦ部と、
検索結果を集約する結果集約部と、
集約した結果を検索要求元に返却するクエリ返却部を持つスキーマ検索装置および方法を説明した。
【００５６】
また、本実施の形態では、
検索インデックス作成部は、あらかじめ設定された重み付け表に従い、前記実体の重要項目に対しては重み付け情報を付加して、検索インデックスを作成することを説明した。
【００５７】
また、本実施の形態では、
検索インデックス作成部は、検索インデックス作成において重み付けする項目と検索部により一致すると判断される項目が既に存在する場合にはこれを検知し、あらかじめ設定された重み付け表に従い、重み付けを最も低く設定することを説明した。
【００５８】
また、本実施の形態では、
検索重み付けＯＮ／ＯＦＦ部は、実行する検索処理が重要項目の検索であるか、その他の項目の検索であるかの情報を受け取り、この情報に従って、検索インデックスの重みの採用、不採用の切り替えを行うことを説明した。
【００５９】
また、本実施の形態では、
検索重み付けＯＮ／ＯＦＦ部は、実行する検索処理が重要項目の検索であるか、その他の項目の検索であるかの情報を受け取り、この情報に従って、検索インデックスの重みがあらかじめ設定した閾値以下であるとき、その検索対象を無視することを説明した。
【００６０】
また、本実施の形態では、
クエリ分解部は入力がデータベーステーブル情報である場合、主キー制約、外部キー制約にくわえて、テーブル索引制約に含まれるカラム、およびユニーク制約をもつカラムを重要カラムと判断することを説明した。
【００６１】
実施の形態２．
実施の形態１では、カラム名と、カラム名に割当てられている役割（主キー、外部キー等）とを用いて検索条件を与える例を説明した。
本実施の形態では、カラム名以外のデータ要素、具体的には、コメントや論理名等を用いて検索条件を与える例を説明する。
【００６２】
図９は、本実施の形態に係るテーブル定義２の例であり、データ定義言語（ＤＤＬ）にて提供された例を示す。
図９の例では、データ定義言語のＣＯＭＭＥＮＴ文にてカラムにコメント情報が付加されており、顧客名カラムに対して「客先名称」という情報が付加されている。
このように付加情報が得られる場合、図１０に示すように重要度判断表３３に情報を付加して記載することが可能である。
図１０の追加要素判断表では、コメントに加えて、論理名やテーブル名をカラムの検索情報として利用する際のインデックス重みと重要度順が指定されている。
また重要度判断表３３に対して検索ポイントを付加する際の追加重みが定義されている。
図１０の例では「０．６」と設定されている。
追加情報の重要度はユーザ判断として利用環境によって値を設定することが想定される。
【００６３】
重要度判断表３３は、インデックス重み付け設定部３２４において検索インデックス重みデータ３１４１を作成する際に使用されるため、図１０の追加要素判断表を重要度判断表３３の内容と同等に扱うことによって検索インデックス重みデータ３１４１の作成を実施する。
また、重要度判断表３３は検索実行時にクエリ分解部３１１によって参照されるため、図１０の追加要素判断表に従い、追加要素を考慮に含んだ検索が可能となる。
【００６４】
本実施の形態では、テーブル定義２においてコメント等がカラム名と対応付けられている場合は（図９の例では、コメント「客先名称」はカラム名「顧客名」と対応付けられている）、クエリ分解部３１１は、コメント等を、対応付けられているカラム名と同等に扱う。
つまり、クエリ分解部３１１は、図９のテーブル定義２の場合、図１５に示す検索実行内容情報を生成する。
図１５の検索実行内容情報では、コメント「客先名称」のレコードが設けられ、「カラム種別」が「顧客名」と同様に「索引カラム」となっている。
また、「インデックス重みＯＮ／ＯＦＦ」、「検索集計重み」及び「検索キーワード」も、「顧客名」のレコードと同様になっている。
検索指示部３１２とインデックス重み付けＯＮ／ＯＦＦ部３１３と検索実行部３１４は、図１５の検索実行内容情報に従って、実施の形態１と同様の動作を行う。
【００６５】
一方、テーブル定義２においてコメント等がいずれのカラム名とも対応付けられていない場合は、検索実行部３１４は、検索インデックス重みデータ３１４１内の追加要素判断表のインデックス重みの値及び追加重みを用いて、テーブルごとの評価値を算出する。
つまり、本実施の形態に係る検索インデックス重みデータ３１４１には、図１０の追加要素判断表のインデックス重みの値及び追加重みが反映されており、検索実行部３１４は、テーブル定義２において指定されているコメント等がテーブルに含まれている場合は、当該テーブルに対してコメント等についての評価点を計上する。
例えば、あるテーブルに、テーブル定義２において指定されている論理名が含まれている場合は、検索実行部３１４は、当該論理名が含まれている位置、カラムに関わらず、当該テーブルに対して「２．０×０．６＝１．２」を計上する。
なお、コメント、テーブル名の場合は、それぞれ「０．９」（１．５×０．６＝０．９）と「０．７２」（１．２×０．６＝０．７２）となり、「１．０」未満となるので、コメント、テーブル名については、繰り上げて「１．０」と計上してもよい。
また、テーブル定義２において主キーとして指定されているカラム名が主キーとして含まれているテーブルに、同じテーブル定義２において指定されているコメント等が含まれている場合は、評価値を「２．０」倍するようにしてもよい。
【００６６】
以上のように、本実施の形態によれば、検索対象のテーブルのカラム名の一致もしくは類似に加えて、追加の情報への考慮を追加することが可能であり、実施の形態１の効果をカラム名比較に限定せずに拡張することが可能である。
【００６７】
本実施の形態では、
入力のデータベーステーブル情報がコメントや論理名などを含んでいる場合、クエリ分解部と検索インデックス作成部はこれを項目一致のための情報として、検索クエリ作成や検索インデックス作成にするスキーマ検索装置および方法を説明した。
【００６８】
最後に、実施の形態１及び２に示した検索サーバ装置３のハードウェア構成例について説明する。
図１６は、実施の形態１及び２に示す検索サーバ装置３のハードウェア資源の一例を示す図である。
なお、図１６の構成は、あくまでも検索サーバ装置３のハードウェア構成の一例を示すものであり、検索サーバ装置３のハードウェア構成は図１６に記載の構成に限らず、他の構成であってもよい。
【００６９】
図１６において、検索サーバ装置３は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１及び２で説明した「検索インデックス記憶部３１７」は、例えば、ＲＡＭ９１４、磁気ディスク装置９２０により実現される。
また、実施の形態１及び２で説明した「スキーマ情報ＤＢ３２２」は、例えば、磁気ディスク装置９２０により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【００７０】
通信ボード９１５は、ネットワークに接続されている。
例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。
【００７１】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００７２】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００７３】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
検索サーバ装置３の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００７４】
上記プログラム群９２３には、実施の形態１及び２の説明において「〜部」（「検索インデックス記憶部３１７」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００７５】
ファイル群９２４には、実施の形態１及び２の説明において、「〜の判断」、「〜の検索」、「〜の抽出」、「〜の計算」、「〜の算出」、「〜の計上」、「〜の指定」、「〜の評価」、「〜の生成」、「〜の作成」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各要素として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１及び２で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００７６】
また、実施の形態１及び２の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１及び２で説明したステップ、手順、処理により、本発明に係る「データ検索方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１及び２の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１及び２の「〜部」の手順や方法をコンピュータに実行させるものである。
【００７７】
このように、実施の形態１及び２に示す検索サーバ装置３は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００７８】
１  検索クライアント装置、２  テーブル定義、３  検索サーバ装置、４  テーブル群、５  スキーママッチング処理装置、３１  テーブル検索部、３２  テーブル登録部、３３  重要度判断表、３１０  クエリ受信部、３１１  クエリ分解部、３１２  検索指示部、３１３  インデックス重み付けＯＮ／ＯＦＦ部、３１４  検索実行部、３１５  結果集約部、３１６  クエリ返却部、３１７  検索インデックス記憶部、３２０  テーブル情報登録部、３２１  重複検出部、３２２  スキーマ情報ＤＢ、３２３  検索インデックス作成部、３２４  インデックス重み付け設定部、３１４０  検索インデックス、３１４１  検索インデックス重みデータ。
【図１】
2012212212.tif 000003
【図２】
2012212212.tif 000004
【図３】
2012212212.tif 000005
【図４】
2012212212.tif 000006
【図５】
2012212212.tif 000007
【図６】
2012212212.tif 000008
【図７】
2012212212.tif 000009
【図８】
2012212212.tif 000010
【図９】
2012212212.tif 000011
【図１０】
2012212212.tif 000012
【図１１】
2012212212.tif 000013
【図１２】
2012212212.tif 000014
【図１３】
2012212212.tif 000015
【図１４】
2012212212.tif 000016
【図１５】
2012212212.tif 000017
【図１６】
2012212212.tif 000018