JP7324808B2 - 計算機システム及びデータ検索支援方法 - Google Patents

Description

本発明は、複数のデータベースを用いたデータ検索技術に関する。

ビッグデータの解析では、新たな知見を得るために、複数種類のデータを組合せた解析が行われる。ユーザは、ＳＱＬを用いてデータベースから解析用のデータを取得する。

データベースに対するデータ検索を支援する技術としては、例えば、特許文献１に記載の技術が知られている。特許文献１には、「Ｗｅｂサーバ１０１を用いてデータベース１０２にアクセスするデータベースアクセス装置であって、該データベースアクセス装置は、ユーザが入力したＳＱＬをブラウザの操作画面から読み込み、読み込んだＳＱＬをもとに前記データベースをアクセスするデータベースアクセス部１０６と、該データベースアクセス部により実行されたＳＱＬを履歴ファイルに蓄積するＳＱＬ履歴蓄積部１０７と、前記履歴ファイルに蓄積したＳＱＬからユーザが入力したＳＱＬに近似するＳＱＬを検索するための手続きを作成し作成した手続きをクライアントに送信するＳＱＬ検索手続き作成部１０８を備え、前記クライアントのＳＱＬ作成を支援する。」ことが記載されている。

複数種類のデータを組み合わせた検索を行うためには、データ構造及びデータ項目を熟知しておくこと必要がある。また、近年、公的なオープンデータを利用したビッグデータ解析も行われている。公的なオープンデータの取得にあたっては使用目的等を明確に提示し、取得するデータ表及びデータ項目名を指定する必要がある。すなわち、事前検証ができない状況下でデータ項目を正確に指定する必要がある。したがって、これまでのデータ解析では、データ解析者の経験及び勘に依存しているという課題がある。

特開２００３－２２８５８６号公報

特許文献１に記載の技術は、過去のＳＱＬを提示して、目的とするＳＱＬの作成を支援する技術である。しかし、単一のデータベースに対する検索を前提としており、複数のデータベースを扱うビッグデータ解析には適用が難しい。

本発明は、複数のデータベースを組み合わせたデータ検索において、新たな知見を得られる可能性があるデータを取得するためのＳＱＬを提示する技術を実現する。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、データ種別が異なるデータを格納する複数のデータベースと接続する計算機システムであって、プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する計算機を含み、使用されたＳＱＬに関する情報を含むカタログを格納するカタログデータベースと、前記計算機システムを利用するユーザに関連する文献の情報を管理するための公知情報データベースと、を管理し、前記カタログは、前記ＳＱＬを実行したユーザの情報を含み、前記計算機システムは、ユーザ端末から、第１ＳＱＬを含む検索要求を受信した場合、前記第１ＳＱＬを実行し、前記第１ＳＱＬの実行結果を前記ユーザ端末に出力する第１処理と、前記カタログデータベースを参照して、前記複数のデータベースを結合してデータを検索するための検索条件であって、前記第１ＳＱＬの検索条件と類似する検索条件が定義された推奨ＳＱＬを少なくとも一つ選択する第２処理と、前記ユーザ端末に対して、少なくとも一つの前記推奨ＳＱＬを提示する第３処理と、を実行し、前記第２処理では、複数の前記推奨ＳＱＬが選択された場合、前記公知情報データベースを参照して特定される、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかに基づいて、複数の前記推奨ＳＱＬのランクを決定し、前記第３処理では、ランク付けされた、複数の前記推奨ＳＱＬを提示する。

本発明によれば、複数のデータベースを組み合わせたデータ検索において、新たな知見を得られる可能性があるデータを取得するためのＳＱＬを提示できる。上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

実施例１のシステムの構成例を示す図である。 実施例１の検索システムを構成する計算機のハードウェア構成の一例を示す図である。 実施例１のユーザＤＢに格納されるデータのデータ構造の一例を示す図である。 実施例１のユーザＤＢに格納されるデータのデータ構造の一例を示す図である。 実施例１のカタログＤＢに格納されるカタログのデータ構造の一例を示す図である。 実施例１の検索システムが実行する処理の一例を説明するフローチャートである。 実施例１の検索システムが受付又は出力するＳＱＬの一例を示す図である。 実施例２のシステムの構成例を示す図である。 実施例２のトレンドＤＢに格納されるデータのデータ構造の一例を示す図である。 実施例２のトレンドＤＢに格納されるデータのデータ構造の一例を示す図である。 実施例２のトレンドＤＢに格納されるデータのデータ構造の一例を示す図である。 実施例２の検索システムが実行する処理の一例を説明するフローチャートである。 実施例３のカタログ自動生成処理によって生成されるＳＱＬの一例を示す図である。

以下、本発明の実施例を、図面を用いて説明する。ただし、本発明は以下に示す実施例の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一又は類似する構成又は機能には同一の符号を付し、重複する説明は省略する。

本明細書等における「第１」、「第２」、「第３」等の表記は、構成要素を識別するために付するものであり、必ずしも、数又は順序を限定するものではない。

図面等において示す各構成の位置、大きさ、形状、及び範囲等は、発明の理解を容易にするため、実際の位置、大きさ、形状、及び範囲等を表していない場合がある。したがって、本発明では、図面等に開示された位置、大きさ、形状、及び範囲等に限定されない。

図１は、実施例１のシステムの構成例を示す図である。図２は、実施例１の検索システムを構成する計算機のハードウェア構成の一例を示す図である。

システムは、検索システム１００及びクライアント端末１０１から構成される。検索システム１００及びクライアント端末１０１は、図示しないネットワークを介して互いに接続される。ネットワークは、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）及びＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等であり、接続方式は有線及び無線のいずれでもよい。

クライアント端末１０１は、ユーザが使用する端末である。クライアント端末１０１は、図示しない、プロセッサ、主記憶装置、ネットワークインタフェース、入力装置、及び出力装置を有する。

クライアント端末１０１は、Ｗｅｂブラウザ１８０を介して、検索システム１００にアクセスし、データを検索する。Ｗｅｂブラウザ１８０は、検索条件入力部１９０、検索結果表示部１９１、及び推奨ＳＱＬ表示部１９２を含む。

検索条件入力部１９０は、データを検索するための検索条件が定義されたＳＱＬの入力を受付ける。検索条件入力部１９０は、ＳＱＬを含む検索要求を検索システム１００に送信する。検索結果表示部１９１は、検索システム１００から検索要求に対する検索結果を受信し、ユーザに提示する。ユーザは検索結果として取得したデータを用いてデータ解析を行う。推奨ＳＱＬ表示部１９２は、検索システム１００によって選択された推奨ＳＱＬをユーザに提示する。

なお、本明細書において、ＳＱＬとは、ＳＱＬ言語を用いて記述されたＳＱＬ文（コマンド）を意味する。また、検索条件は、ユーザＤＢ１５０から取得するデータ項目の組合せ及びユーザＤＢ１５０間の結合条件（ＪＯＩＮ）等を意味する。

検索システム１００は、ユーザＤＢ１５０に対するデータ検索を行うシステムであり、図２に示すような計算機２００から構成される。なお、検索システム１００は、ストレージシステム及びネットワークスイッチ等を含んでもよい。

計算機２００は、プロセッサ２０１、主記憶装置２０２、副記憶装置２０３、及びネットワークインタフェース２０４を有する。なお、計算機２００は、入力装置及び出力装置を有してもよい。

プロセッサ２０１は、主記憶装置２０２に格納されるプログラムを実行する。プロセッサ２０１がプログラムにしたがって処理を実行することによって、特定の機能を実現する機能部（モジュール）として動作する。以下の説明では、機能部を主語に処理を説明する場合、プロセッサ２０１が当該機能部を実現するプログラムを実行していることを示す。主記憶装置２０２は、メモリ等であり、プロセッサ２０１が実行するプログラム及びプログラムが使用するデータを格納する。副記憶装置２０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等であり、データを永続的に格納する。主記憶装置２０２に格納されるプログラム及びデータは、副記憶装置２０３に格納されてもよい。この場合、プロセッサ２０１が副記憶装置２０３からプログラム及びデータを読み出し、主記憶装置２０２にロードする。ネットワークインタフェース２０４は、ネットワークを介して他の装置と通信する。

検索システム１００は、アプリケーション制御部１１０、ユーザデータ格納部１１１、及びカタログ管理部１１２を含む。

ユーザデータ格納部１１１は、ユーザごとにデータ格納領域１４０を含む。データ格納領域１４０には、ユーザが登録又は外部より取得したデータを格納するユーザＤＢ１５０が格納される。

ユーザＤＢ１５０には、例えば、ユーザが公的機関に申請して取得した公的なオープンデータが格納される。図１には、ユーザＤＢ１５０の一例として、一般健診ＤＢ１５０－１及び介護ＤＢ１５０－２を示している。なお、本発明は、ユーザＤＢに格納されるデータの種別及びデータ構造に限定されない。

アプリケーション制御部１１０は、データの検索を行うアプリケーション１２０を制御する。

アプリケーション１２０は、データベースアクセス部１３０、カタログ保存指示部１３１、及び推奨ＳＱＬ問合せ部１３２を含む。

データベースアクセス部１３０は、検索要求に含まれるＳＱＬに基づいて、ユーザＤＢ１５０にアクセスし、データを検索する。カタログ保存指示部１３１は、カタログ管理部１１２に、検索要求に含まれるＳＱＬに関する情報をカタログ４００（図４を参照）として保存するように指示する。推奨ＳＱＬ問合せ部１３２は、推奨ＳＱＬを問い合わせる。

なお、アプリケーション１２０は、検索されたデータを用いたデータ解析を行う機能を有してもよい。

カタログ管理部１１２は、カタログ４００を管理し、カタログ４００から推奨ＳＱＬを選択する。カタログ管理部１１２は、カタログ保存部１６０及び推奨ＳＱＬ選択部１６１を含み、また、カタログＤＢ１７０を保持する。

カタログＤＢ１７０は、カタログ４００を格納するデータベースである。

カタログ保存部１６０は、カタログ保存指示部１３１からの指示にしたがって、カタログ４００を生成し、カタログＤＢ１７０にカタログ４００を格納する。推奨ＳＱＬ選択部１６１は、カタログＤＢ１７０に格納されるカタログ４００に含まれるＳＱＬの中から推奨ＳＱＬを選択する。

図３Ａ及び図３Ｂは、実施例１のユーザＤＢ１５０に格納されるデータのデータ構造の一例を示す図である。

図３Ａは、一般健診ＤＢ１５０－１に格納されるデータのデータ構造を示す。一般健診ＤＢ１５０－１は、テーブル３００を格納し、テーブル３００は、健診データＩＤ３０１、受診機関都道府県３０２、健診コード３０３、疾病分類３０４、及び医薬品コード３０５を含むエントリを格納する。一つのエントリが一つの健診データに対応する。なお、健診データに含まれるデータ項目（フィールド）は前述したものに限定されない。前述したデータ項目のいずれかを含まなくてもよいし、また、他のデータ項目を含んでもよい。

図３Ｂは、介護ＤＢ１５０－２に格納されるデータのデータ構造を示す。介護ＤＢ１５０－２は、テーブル３１０を格納し、テーブル３１０は、施設コード３１１、介護ランク３１２、原疾患コード３１３、及び性別３１４を含むエントリを格納する。一つのエントリが一人の介護認定データに対応する。なお、介護認定データに含まれるデータ項目（フィールド）は前述したものに限定されない。前述したデータ項目のいずれかを含まなくてもよいし、また、他のデータ項目を含んでもよい。

図４は、実施例１のカタログＤＢ１７０に格納されるカタログのデータ構造の一例を示す図である。

カタログＤＢ１７０は、複数のカタログ４００を格納する。カタログ４００には識別情報が付与されている。カタログ４００は、ＳＱＬ、ＳＱＬを用いて検索を行ったユーザのユーザ情報、検索対象のユーザＤＢ１５０の名称、及び検索の実行日時を含む。なお、カタログ４００には、他の情報が含まれてもよい。

本実施例では、ユーザが使用したＳＱＬをカタログ４００として管理する。これによって、ユーザが保持する検索知識を、検索システム１００を利用する全ユーザが共有できる。

図５は、実施例１の検索システム１００が実行する処理の一例を説明するフローチャートである。

ユーザは、クライアント端末１０１のＷｅｂブラウザ１８０を操作して、検索条件を入力し、検索の実行を指示する。この場合、クライアント端末１０１の検索条件入力部１９０が、ユーザに対応するアプリケーション１２０に対して検索条件を含む検索要求を送信する。

検索システム１００のアプリケーション１２０は、検索要求を受信した場合（ステップＳ５０１）、検索処理を実行する（ステップＳ５０２）。

具体的には、データベースアクセス部１３０が、検索要求に含まれるＳＱＬを用いて、ユーザに対応するデータ格納領域１４０に格納されるユーザＤＢ１５０にアクセスし、データを検索する。データベースアクセス部１３０は、検索結果をクライアント端末１０１に送信する。クライアント端末１０１の検索結果表示部１９１が検索結果を表示する。

次に、検索システム１００のアプリケーション１２０は、カタログ管理部１１２にカタログ４００を登録する（ステップＳ５０３）。

具体的には、カタログ保存指示部１３１が、カタログ管理部１１２に、検索要求に関する情報とともに登録要求を出力する。カタログ管理部１１２のカタログ保存部１６０は、情報に基づいてカタログ４００を生成し、カタログ４００に識別を付与し、カタログＤＢ１７０に格納する。

本実施例では、検索処理が実行されるたびに、カタログ４００が生成され、カタログＤＢ１７０に蓄積される。

次に、検索システム１００のアプリケーション１２０は、カタログ管理部１１２に推奨ＳＱＬの出力指示を送信することによって、推奨ＳＱＬを選択する（ステップＳ５０４）。出力指示には使用したＳＱＬが含まれる。

具体的には、推奨ＳＱＬ選択部１６１は、推奨ＳＱＬ問合せ部１３２から出力指示を受信した場合、複数のユーザＤＢ１５０を結合してデータを検索するための検索条件が定義されたＳＱＬを特定する。推奨ＳＱＬ選択部１６１は、出力指示に含まれるＳＱＬ及び特定されたＳＱＬの検索条件の類似度を算出する。推奨ＳＱＬ選択部１６１は、類似度に基づいて推奨ＳＱＬを選択し、推奨ＳＱＬ問合せ部１３２に送信する。例えば、類似度が最も大きいＳＱＬを推奨ＳＱＬとして選択してもよいし、類似度が大きい順に所定の数のＳＱＬを推奨ＳＱＬとして選択してもよいし、類似度が閾値より大きいＳＱＬを推奨ＳＱＬとして選択してもよい。

ここで、検索条件の類似度は、データ項目の組合せの一致度（データ項目の一致する）、及び、結合条件（構文）の一致度に基づいて算出される。なお、出力指示に含まれるＳＱＬのデータ項目を包含し、かつ、当該ＳＱＬの結合条件との一致度が高い結合条件である検索条件の類似度が高くなる算出アルゴリズムが設定されているものとする。

検索条件が類似する場合、検索目的も類似しているものと推測される。そこで、検索システム１００は、類似する検索条件が定義されたＳＱＬを有用な知見を得られる可能性がある推奨ＳＱＬとして提示する。

次に、検索システム１００のアプリケーション１２０は、クライアント端末１０１に推奨ＳＱＬを送信する（ステップＳ５０５）。その後、検索システム１００のアプリケーションは処理を終了する。

クライアント端末１０１の推奨ＳＱＬ表示部１９２は、受信した推奨ＳＱＬをユーザに表示する。

ここで、具体例を用いて推奨ＳＱＬの表示について説明する。図６は、実施例１の検索システム１００が受付又は出力するＳＱＬの一例を示す図である。

ＳＱＬ６００はユーザによって入力されたＳＱＬを表す。推奨ＳＱＬ６１０は、検索システム１００によって選択された推奨ＳＱＬを表す。

推奨ＳＱＬ６１０には、ＳＱＬ６００と異なる検索条件が定義される。ここで、検索条件が異なるとは、データ項目の組合せ及び結合条件の少なくともいずれかが異なることを意味する。一方、推奨ＳＱＬ６１０に定義される検索条件は、ＳＱＬ６００に定義される検索条件と類似する。すなわち、推奨ＳＱＬ６１０に定義される検索条件は、ＳＱＬ６００が対象とするデータ項目を包含し、かつ、ＳＱＬ６００の結合条件との一致度が高い結合条件を含む。

ＳＱＬ６００は、一般健診ＤＢ１５０－１に対する検索であるのに対し、推奨ＳＱＬ６１０は、一般健診ＤＢ１５０－１及び介護ＤＢ１５０－２に対する検索である。また、推奨ＳＱＬ６１０では、一般健診ＤＢ１５０－１の疾病分類３０４と介護ＤＢ１５０－２の原疾患コード３１３とを結合させる結合条件を使用していることがわかる。

このように、検索システム１００は、検索対象のユーザＤＢ１５０と何らかの関係性があるユーザＤＢ１５０を組み合わせたデータ検索を行うＳＱＬを提示する。これによって、ユーザは、関連性があるユーザＤＢ１５０のデータ項目の組合せ及び結合条件を確認することができる。すなわち、他のユーザの検索知識を取り入れた検索が可能となる。また、ユーザは、新たなユーザＤＢ１５０を参照することによって、有用なデータ項目の組合せを把握できる。例えば、介護ＤＢ１５０－２の介護ランク及び性別等を有用なデータ項目の組合せとして把握できる。

なお、ユーザは、推奨ＳＱＬ６１０をそのまま使用してもよいし、推奨ＳＱＬ６１０をアレンジしてもよい。ＳＱＬ６２０は、推奨ＳＱＬ６１０を参照したユーザが新たに入力したＳＱＬを表す。

ＳＱＬ６２０では、推奨ＳＱＬ６１０のデータ項目の組合せに、介護ランク３１２及び性別３１４が追加され、また、推奨ＳＱＬ６１０の結合条件から変更が加えられている。

実施例１によれば、新たな知見を得られる可能性があるデータを取得するためのＳＱＬを提示できる。これによって、ユーザＤＢ１５０について詳細な知識を有していなくても、複数のユーザＤＢ１５０を組み合わせたデータ検索が可能となる。

実施例２の検索システム１００は、複数の推奨ＳＱＬが選択された場合、ランク付けを行ってユーザに表示する。以下、実施例１との差異を中心に実施例２について説明する。

図７は、実施例２のシステムの構成例を示す図である。

実施例２では、カタログ管理部１１２の構成が一部異なる。具体的には、カタログ管理部１１２は、トレンドＤＢ１７１及び公知情報ＤＢ１７２を保持する。

トレンドＤＢ１７１は、検索条件の使用傾向を示すデータを格納するデータベースである。公知情報ＤＢ１７２は、論文及びパンフレット等、公知となっている情報を格納するデータベースである。検索システム１００は、外部のＷｅｂページ及び外部の文献データベース等を周期的にクロールすることによって情報を収集し、公知情報ＤＢ１７２に登録する。

図８Ａ、図８Ｂ、及び図８Ｃは、実施例２のトレンドＤＢ１７１に格納されるデータのデータ構造の一例を示す図である。

トレンドＤＢ１７１は、第１リンクテーブル８００、第２リンクテーブル８１０、履歴テーブル８２０を格納する。

第１リンクテーブル８００は、複数のユーザＤＢ１５０から取得するデータ項目の組合せを管理するテーブルであり、リンクＩＤ８０１、第１データベース名８０２、第１データ項目名８０３、第２データベース名８０４、及び第２データ項目名８０５を含むエントリを格納する。データ項目の一つの組合せに対して一つのエントリが存在する。

リンクＩＤ８０１は、データ項目の組合せの識別情報を格納するフィールドである。第１データベース名８０２及び第２データベース名８０４は、ユーザＤＢ１５０の名称を格納するフィールドである。第１データ項目名８０３及び第２データ項目名８０５は、ユーザＤＢ１５０に格納されるデータに含まれるデータ項目の名称を格納するフィールドである。

第２リンクテーブル８１０は、ユーザＤＢ１５０間の結合条件を管理するためのテーブルであり、リンクＩＤ８１１、第１データベース名８１２、第２データベース名８１３、及び結合条件８１４を含むエントリを格納する。一つのユーザＤＢ１５０間の結合条件に対して一つのエントリが存在する。

リンクＩＤ８１１は、ユーザＤＢ１５０間の結合条件の識別情報を格納するフィールドである。第１データベース名８１２及び第２データベース名８１３は、ユーザＤＢ１５０の名称を格納するフィールドである。結合条件８１４は、ＳＱＬに含まれる、ユーザＤＢ１５０間の結合条件を格納するフィールドである。

なお、トレンドＤＢ１７１には、第１リンクテーブル８００及び第２リンクテーブル８１０のいずれか一方のみが含まれてもよい。

履歴テーブル８２０は、データ項目の組合せ及び結合条件の使用履歴を管理するテーブルであり、リンクＩＤ８２１及び登録日時８２２を含むエントリを格納する。一回の使用に対して一つのエントリが存在する。

リンクＩＤ８２１は、リンクＩＤ８０１及びリンクＩＤ８１１のいずれかの識別情報を格納するフィールドである。登録日時８２２は、リンクＩＤ８２１に対応するデータ項目の組合せ又は結合条件を含むＳＱＬが実行された日時を格納するフィールドである。

実施例２の検索システム１００が管理するユーザＤＢ１５０及びカタログＤＢ１７０のデータ構造は実施例１と同一である。

実施例２では、検索システム１００が実行する処理の一部が異なる。図９は、実施例２の検索システム１００が実行する処理の一例を説明するフローチャートである。

ステップＳ５０１及びステップＳ５０２の処理は実施例１と同一である。

ステップＳ５０３では、カタログ４００の登録とともに、トレンドＤＢ１７１が更新される。具体的には、以下のような処理が実行される。

（Ｓ５０３－１）カタログ保存部１６０は、登録要求に含まれるカタログ４００からＳＱＬを取得し、取得したＳＱＬを解析することによって、データ項目の組合せ及び結合条件を特定する。

（Ｓ５０３－２）カタログ保存部１６０は、第１リンクテーブル８００を参照し、データ項目の組合せに一致するエントリが存在するか否かを判定する。

（Ｓ５０３－３）データ項目の組合せに一致するエントリが存在する場合、カタログ保存部１６０は、当該エントリのリンクＩＤ８０１から識別情報を取得する。カタログ保存部１６０は、履歴テーブル８２０にエントリを追加し、リンクＩＤ８２１に、取得した識別情報を設定し、登録日時８２２にＳＱＬの実行日時を格納する。データ項目の組合せに一致するエントリが存在しない場合、カタログ保存部１６０は、第１リンクテーブル８００にエントリを登録し、リンクＩＤ８０１に識別情報を設定する。また、カタログ保存部１６０は、追加されたエントリの各フィールドに値を設定する。カタログ保存部１６０は、追加されたエントリのリンクＩＤ８０１から識別情報を取得する。カタログ保存部１６０は、履歴テーブル８２０にエントリを追加し、リンクＩＤ８２１に、取得した識別情報を設定し、登録日時８２２にＳＱＬの実行日時を格納する。

（Ｓ５０３－４）カタログ保存部１６０は、第２リンクテーブル８１０を参照し、検索条件に一致するエントリが存在するか否かを判定する。

（Ｓ５０３－５）検索条件に一致するエントリが存在する場合、カタログ保存部１６０は、当該エントリのリンクＩＤ８１１から識別情報を取得する。カタログ保存部１６０は、履歴テーブル８２０にエントリを追加し、リンクＩＤ８２１に、取得した識別情報を設定し、登録日時８２２にＳＱＬの実行日時を格納する。検索条件に一致するエントリが存在しない場合、カタログ保存部１６０は、第２リンクテーブル８１０にエントリを登録し、リンクＩＤ８１１に識別情報を設定する。また、カタログ保存部１６０は、追加されたエントリの各フィールドに値を設定する。カタログ保存部１６０は、追加されたエントリのリンクＩＤ８１１から識別情報を取得する。カタログ保存部１６０は、履歴テーブル８２０にエントリを追加し、リンクＩＤ８２１に、取得した識別情報を設定し、登録日時８２２にＳＱＬの実行日時を格納する。

以上が、トレンドＤＢ１７１の更新処理の説明である。

ステップＳ５０４の処理は実施例１と同一である。ステップＳ５０４の処理の後に、検索システム１００のカタログ管理部１１２は、推奨ＳＱＬが一つであるか否かを判定する（ステップＳ５１１）。

推奨ＳＱＬが一つである場合、検索システム１００のカタログ管理部１１２は、アプリケーション１２０を介して、クライアント端末１０１に推奨ＳＱＬを送信する（ステップＳ５０５）。その後、検索システム１００のアプリケーションは処理を終了する。

推奨ＳＱＬが複数である場合、検索システム１００のカタログ管理部１１２は、複数のＳＱＬをランク付けする（ステップＳ５１２）。ランク付けの方法は後述する。

検索システム１００のカタログ管理部１１２は、アプリケーション１２０を介して、クライアント端末１０１に、ランク付けされた複数の推奨ＳＱＬを送信する（ステップＳ５１３）。その後、検索システム１００のアプリケーション１２０は処理を終了する。

ランク付けについて説明する。本実施例では、（１）検索条件の類似度、（２）検索条件のトレンド、及び（３）ＳＱＬを実行したユーザの信頼性の三つの指標に基づいて、推奨ＳＱＬのランクを決定する。

（１）検索条件の類似度
検索条件の類似度は、推奨ＳＱＬの選択時に算出される。カタログ管理部１１２は、ユーザが使用した検索条件に類似する検索条件のＳＱＬは検索目的が類似するものと推定し、類似度が大きい推奨ＳＱＬが優先的に表示されるようにランク付けを行う。

（２）検索条件のトレンド
検索条件のトレンドは、複数のユーザＤＢ１５０から取得するデータ項目の組合せ及びユーザＤＢ１５０間の結合条件の少なくともいずれか一方の使用傾向を表す。検索システム１００は、多くのユーザが使用する、データ項目の組合せ又は結合条件を含む検索条件が定義された推奨ＳＱＬが優先的に表示されるようにランク付けを行う。

ステップＳ５１２において、カタログ管理部１１２は、各推奨ＳＱＬの検索条件のトレンドを評価する指標を算出する。例えば、カタログ管理部１１２は、履歴テーブル８２０を参照し、月単位で、２ヶ月分の推奨ＳＱＬに定義される検索条件のデータ項目の組合せ及び結合条件の各々の使用回数を集計する。カタログ管理部１１２は、使用回数又は使用回数の増加率等を指標として算出する。カタログ管理部１１２は、使用回数が多い、又は、使用回数の増加率が正かつ大きい、データ項目の組合せ又は結合条件を含む検索条件が定義された推奨ＳＱＬが優先的に表示されるようにランク付けを行う。

データ項目の組合せのトレンドに着目したランク付けについて説明する。

最新月において、リンクＩＤ８０１が「Ｉ１」に対応するデータ項目の組合せを含む検索条件が定義されたＳＱＬの使用頻度は、リンクＩＤ８０１が「Ｉ２」に対応するデータ項目の組合せを含む検索条件が定義されたＳＱＬの使用頻度より小さいものとする。この場合、多くのユーザは、リンクＩＤ８０１が「Ｉ２」に対応するデータ項目の組合せに関係性があると判断して検索したものと推測され、リンクＩＤ８０１が「Ｉ２」に対応するデータ項目の組合せを含むＳＱＬは有益性が高いことが期待できる。そこで、カタログ管理部１１２は、「Ｉ２」に対応するデータ項目の組合せを含むＳＱＬが優先的に表示されるようにランク付けを行う。

最新月の使用回数の増加率を指標とした場合も同様のランク付けが行われる。また、検索条件のトレンドに着目したランク付けも同様の手法で行われる。

（３）ＳＱＬを実行したユーザの信頼性
検索システム１００を利用するユーザが文献を発表している場合、当該検索システム１００から得られた知見を利用しているものと推測される。また、検索システム１００を利用するユーザが発表した文献が、他の文献等で多数引用されている場合、文献の重要性が高いものと推測される。そこで、検索システム１００は、発表した文献の数及び引用数等に基づいてユーザの信頼性を評価し、信頼性の高いユーザが使用した推奨ＳＱＬが優先的に表示されるようにランク付けを行う。

ステップＳ５１２において、カタログ管理部１１２は、各推奨ＳＱＬの信頼性を評価する指標を算出する。例えば、以下のような処理が実行される。

（処理１）カタログ管理部１１２は、複数の推奨ＳＱＬの中から一つの推奨ＳＱＬを選択する。カタログ管理部１１２は、カタログＤＢ１７０を参照して、当該推奨ＳＱＬを使用したユーザを特定する。カタログ管理部１１２は、全ての推奨ＳＱＬについて同様の処理を実行する。

（処理２）カタログ管理部１１２は、特定されたユーザの中から一人のユーザを選択する。カタログ管理部１１２は、公知情報ＤＢ１７２を参照して、選択したユーザが発表した文献の数、及び、選択したユーザが発表した文献の引用数を算出する。なお、文献の数及び引用数を算出する場合に、集計単位を設定してもよい。例えば、月単位で算出する方法が考えられる。

（処理３）カタログ管理部１１２は、特定された全てのユーザについて処理が完了したか否かを判定する。特定された全てのユーザについて処理が完了していない場合、カタログ管理部１１２は、処理２に戻る。

（処理４）特定された全てのユーザについて処理が完了した場合、カタログ管理部１１２は、各ユーザの文献の発表数及び引用数に基づいて、各ユーザの信頼性を評価する指標を算出する。例えば、文献の発表数及び引用数の合計値及び平均値等を指標として算出する。また、カタログ管理部１１２は、文献の発表数及び引用数を変数とする数式を用いて指標を算出してもよい。

（処理５）カタログ管理部１１２は、指標の大きいユーザが使用した推奨ＳＱＬが優先的に表示されるようにランク付けを行う。

なお、カタログ管理部１１２は、（１）検索条件の類似度、（２）検索条件のトレンド、及び（３）ＳＱＬを実行したユーザの信頼性のいずれか一つを用いてランク付けを行ってもよいし、二つ以上を組み合わせてランク付けを行ってもよい。二つ以上を組み合わせてランク付けを行う場合、カタログ管理部１１２は、各指標のランクに重み付けを行って、最終的なランクを決定する。

実施例２によれば、複数の推奨ＳＱＬをランク付けして表示することによって、ユーザは、有用性が高い推奨ＳＱＬを参考にしてデータ検索を行うことができる。

実施例３の検索システム１００は、カタログＤＢ１７０に登録されたＳＱＬを解析し、解析結果に基づいて新たなＳＱＬを自動的に生成し、カタログＤＢ１７０に登録する。以下、実施例２との差異を中心に実施例３について説明する。

実施例３のシステムの構成は実施例２と同一である。実施例３の検索システム１００の機能構成は実施例２と同一である。また、実施例３の検索システム１００が保持する情報のデータ構造は実施例２と同一である。実施例３の検索システム１００が検索要求を受信した場合に実行する処理は実施例２と同一である。

実施例３では、カタログ保存部１６０が周期的にカタログ自動生成処理を実行する点が実施例２と異なる。カタログ自動生成処理としては以下の二つの処理方法が考えられる。

（処理方法１）カタログ保存部１６０は、カタログＤＢ１７０に格納されるカタログ４００に含まれるＳＱＬを取得し、複数のＳＱＬを比較等することによって、使用頻度が高い検索条件（データ項目の組合せ及び結合条件）を特定する。

カタログ保存部１６０は、部分的に一致する複数の検索条件に基づいて、新たな検索条件を生成する。具体的には、カタログ保存部１６０は、部分的に一致する複数の検索条件のデータ項目の組合せ及び結合条件を用いて、新たなデータ項目の組合せ及び結合条件を生成する。例えば、統合及び入換等の操作を行うことによって新たなデータ項目の組合せ及び結合条件が生成される。なお、カタログＤＢ１７０に存在するデータ項目の組合せ及び結合条件は除外される。

カタログ保存部１６０は、新たなデータ項目の組合せ及び結合条件を用いて、ＳＱＬを生成し、当該ＳＱＬを含むカタログ４００をカタログＤＢ１７０に登録する。なお、カタログ４００のユーザ情報には検索システム１００を設定し、実行日時には生成日時を設定する。

図１０は、実施例３のカタログ自動生成処理によって生成されるＳＱＬの一例を示す図である。

カタログＤＢ１７０に、ＳＱＬ１００１、ＳＱＬ１００２、及びＳＱＬ１００３に関するカタログ４００が登録されているものとする。この場合、健診コード３０３、疾病分類３０４、医薬品コード３０５、介護ランク３１２、及び性別３１４には関連性があると推測される。そこで、カタログ保存部１６０は、全てのデータ項目を含むＳＱＬ１０１０を生成する。

（処理方法２）カタログ保存部１６０は、トレンドＤＢ１７１を参照し、使用頻度が高い検索条件（データ項目の組合せ及び結合条件）を特定する。

カタログ保存部１６０は、部分的に一致するデータ項目の組合せ及び結合条件を用いて、新たなデータ項目の組合せ及び結合条件を生成する。例えば、統合及び入換等の操作を行うことによって新たなデータ項目の組合せ及び結合条件が生成される。なお、カタログＤＢ１７０に存在するデータ項目の組合せ及び結合条件は除外される。

カタログ保存部１６０は、新たなデータ項目の組合せ及び結合条件を用いて、ＳＱＬを生成し、当該ＳＱＬを含むカタログ４００をカタログＤＢ１７０に登録する。なお、カタログ４００のユーザ情報には検索システム１００を設定し、実行日時には生成日時を設定する。

実施例３によれば、データ項目の組合せ及び検索条件のトレンドを反映したＳＱＬを自動的に生成し、登録することによって、有用なデータ検索を実現できるＳＱＬを提示できる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

１００ 検索システム
１０１ クライアント端末
１１０ アプリケーション制御部
１１１ ユーザデータ格納部
１１２ カタログ管理部
１２０ アプリケーション
１３０ データベースアクセス部
１３１ カタログ保存指示部
１３２ 推奨ＳＱＬ問合せ部
１４０ データ格納領域
１５０ ユーザＤＢ
１６０ カタログ保存部
１６１ 推奨ＳＱＬ選択部
１７０ カタログＤＢ
１７１ トレンドＤＢ
１７２ 公知情報ＤＢ
１８０ Ｗｅｂブラウザ
１９０ 検索条件入力部
１９１ 検索結果表示部
１９２ 推奨ＳＱＬ表示部
２００ 計算機
２０１ プロセッサ
２０２ 主記憶装置
２０３ 副記憶装置
２０４ ネットワークインタフェース
８００ 第１リンクテーブル
８１０ 第２リンクテーブル
８２０ 履歴テーブル

Claims (10)

1. データ種別が異なるデータを格納する複数のデータベースと接続する計算機システムであって、
   プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する計算機を含み、
   使用されたＳＱＬに関する情報を含むカタログを格納するカタログデータベースと、前記計算機システムを利用するユーザに関連する文献の情報を管理するための公知情報データベースと、を管理し、
   前記カタログは、前記ＳＱＬを実行したユーザの情報を含み、
   前記計算機システムは、
   ユーザ端末から、第１ＳＱＬを含む検索要求を受信した場合、前記第１ＳＱＬを実行し、前記第１ＳＱＬの実行結果を前記ユーザ端末に出力する第１処理と、
   前記カタログデータベースを参照して、前記複数のデータベースを結合してデータを検索するための検索条件であって、前記第１ＳＱＬの検索条件と類似する検索条件が定義された推奨ＳＱＬを少なくとも一つ選択する第２処理と、
   前記ユーザ端末に対して、少なくとも一つの前記推奨ＳＱＬを提示する第３処理と、を実行し、
   前記第２処理では、複数の前記推奨ＳＱＬが選択された場合、前記公知情報データベースを参照して特定される、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかに基づいて、複数の前記推奨ＳＱＬのランクを決定し、
   前記第３処理では、ランク付けされた、複数の前記推奨ＳＱＬを提示することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記第２処理では、前記第１ＳＱＬにおける前記複数のデータベースから取得するデータ項目の組合せと、複数の前記カタログの各々に含まれるＳＱＬにおける前記複数のデータベースから取得するデータ項目の組合せとの一致度、及び、前記第１ＳＱＬにおける前記複数のデータベース間の結合条件と複数の前記カタログの各々に含まれるＳＱＬにおける前記複数のデータベース間の結合条件との一致度から算出される類似度に基づいて、少なくとも一つの前記推奨ＳＱＬを選択することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記第２処理では、複数の前記推奨ＳＱＬが選択された場合、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかと、複数の前記推奨ＳＱＬの各々の前記類似度と、に基づいて、複数の前記推奨ＳＱＬのランクを決定することを特徴とする計算機システム。
4. 請求項２に記載の計算機システムであって、
   検索条件の使用傾向を管理するための履歴データベースを管理し、
   前記第２処理では、複数の前記推奨ＳＱＬが選択された場合、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかと、前記履歴データベースを参照して特定される、複数の前記推奨ＳＱＬの各々の検索条件の使用傾向と、に基づいて、複数の前記推奨ＳＱＬのランクを決定することを特徴とする計算機システム。
5. 請求項２に記載の計算機システムであって、
   前記カタログデータベースを参照し、使用頻度が高い検索条件を特定し、
   特定された複数の前記検索条件を用いて生成される検索条件が定義されたＳＱＬを生成し、
   生成された前記ＳＱＬに関する情報を含む前記カタログを生成し、前記カタログデータベースに登録することを特徴とする計算機システム。
6. データ種別が異なるデータを格納する複数のデータベースと接続する計算機システムが実行するデータ検索支援方法であって、
   前記計算機システムは、
   プロセッサ、前記プロセッサに接続される記憶装置、及び前記プロセッサに接続されるネットワークインタフェースを有する計算機を含み、
   使用されたＳＱＬに関する情報を含むカタログを格納するカタログデータベースと、前記計算機システムを利用するユーザに関連する文献の情報を管理するための公知情報データベースと、を管理し、
   前記カタログは、前記ＳＱＬを実行したユーザの情報を含み、
   前記データ検索支援方法は、
   前記計算機が、ユーザ端末から、第１ＳＱＬを含む検索要求を受信した場合、前記第１ＳＱＬを実行し、前記第１ＳＱＬの実行結果を前記ユーザ端末に出力する第１のステップと、
   前記計算機が、前記カタログデータベースを参照して、前記複数のデータベースを結合してデータを検索するための検索条件であって、前記第１ＳＱＬの検索条件と類似する検索条件が定義された推奨ＳＱＬを少なくとも一つ選択する第２のステップと、
   前記計算機が、前記ユーザ端末に対して、少なくとも一つの前記推奨ＳＱＬを提示する第３のステップと、を含み、
   前記第２のステップは、複数の前記推奨ＳＱＬが選択された場合、前記計算機が、前記公知情報データベースを参照して特定される、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかに基づいて、複数の前記推奨ＳＱＬのランクを決定するステップを含み、
   前記第３のステップは、前記計算機が、ランク付けされた、複数の前記推奨ＳＱＬを提示するステップを含むことを特徴とするデータ検索支援方法。
7. 請求項６に記載のデータ検索支援方法であって、
   前記第２のステップは、前記計算機が、前記第１ＳＱＬにおける前記複数のデータベースから取得するデータ項目の組合せと、複数の前記カタログの各々に含まれるＳＱＬにおける前記複数のデータベースから取得するデータ項目の組合せとの一致度、及び、前記第１ＳＱＬにおける前記複数のデータベース間の結合条件と複数の前記カタログの各々に含まれるＳＱＬにおける前記複数のデータベース間の結合条件との一致度から算出される類似度に基づいて、少なくとも一つの前記推奨ＳＱＬを選択するステップを含むことを特徴とするデータ検索支援方法。
8. 請求項７に記載のデータ検索支援方法であって、
   前記第２のステップは、複数の前記推奨ＳＱＬが選択された場合、前記計算機が、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかと、複数の前記推奨ＳＱＬの各々の前記類似度と、に基づいて、複数の前記推奨ＳＱＬのランクを決定するステップを含むことを特徴とするデータ検索支援方法。
9. 請求項７に記載のデータ検索支援方法であって、
   前記計算機システムは、検索条件の使用傾向を管理するための履歴データベースを管理し、
   前記第２のステップは、複数の前記推奨ＳＱＬが選択された場合、前記計算機が、複数の前記推奨ＳＱＬの各々を実行したユーザに関連する文献の数及び当該文献の引用件数の少なくともいずれかと、前記履歴データベースを参照して特定される、複数の前記推奨ＳＱＬの各々の検索条件の使用傾向と、に基づいて、複数の前記推奨ＳＱＬのランクを決定するステップを含むことを特徴とするデータ検索支援方法。
10. 請求項７に記載のデータ検索支援方法であって、
    前記計算機が、前記カタログデータベースを参照し、使用頻度が高い検索条件を特定するステップと、
    前記計算機が、特定された複数の前記検索条件を用いて生成される検索条件が定義されたＳＱＬを生成するステップと、
    前記計算機が、生成された前記ＳＱＬに関する情報を含む前記カタログを生成し、前記カタログデータベースに登録するステップと、を含むことを特徴とするデータ検索支援方法。

Images