JP2019109782A - クエリ生成プログラム、クエリ生成方法およびクエリ生成装置 - Google Patents

Abstract

【課題】データ取得を実行するクエリの誤りを低減することを課題とする。【解決手段】クエリ生成装置は、それぞれが属性スキーマの集合である複数のカテゴリスキーマから、取得対象のデータを規定する出力対象テーブルが有する複数の出力項目の属性名に基づき、出力対象テーブルと対応付けるメインカテゴリスキーマを決定する。クエリ生成装置は、複数の出力項目のうち、メインカテゴリスキーマに対応付けられない出力項目である未対応項目に対し、メインカテゴリスキーマが有する複数の属性スキーマそれぞれの特性と関連付けられるカテゴリスキーマから、未対応項目と対応付けるサブカテゴリスキーマを決定する。クエリ生成装置は、メインカテゴリスキーマ、および、サブカテゴリスキーマに基づき、複数のカテゴリスキーマに対するクエリを生成する。【選択図】図４

Description

本発明は、クエリ生成プログラム、クエリ生成方法およびクエリ生成装置に関する。

近年、オープンデータ運動の進展に伴い、公共性の高いデータがオープンデータとして、広く一般に利用可能な形で公開されてきている。ユーザがオープンデータを活用する場合、所望する項目を設定した出力対象テーブルを生成し、出力対象テーブルの項目に合わせて、オープンデータに対するクエリを生成する。そして、ユーザは、クエリを実行することで、オープンデータから所望のデータを取得する。

"富士通のLOD技術"、［online］、富士通研究所、［２０１７年１０月１日検索］、インターネット（URL：http://www.fujitsu.com/jp/group/labs/resources/tech/techguide/list/lod/p06.html）

しかしながら、オープンデータの各テーブルの各項目と、ユーザが所望する出力対象のテーブルの各項目との対応付けの誤りなどが発生し、データを取得するためのクエリが間違って生成される。このため、オープンデータを有効利用できない状況が発生する。

例えば、出力対象テーブルの項目それぞれの対応付けを行う場合、オープンデータ内の利用可能な各テーブルから、対応付けのテーブルを順次決めていくことになるが、少数の項目から対応付けるテーブルの適否を判断する状況が発生する。このような状況で、特に、利用可能なテーブルの数が多く、かつ、対応付けの対象となる項目が一般的な名称である場合、対応付けを誤る可能性が高い。また、対応付けの適否について、項目の名称以外の情報を用いて判断する場合、オープンデータのサイズによっては、多大な時間とリソースが必要となる。

一つの側面では、データ取得を実行するクエリの誤りを低減することができるクエリ生成プログラム、クエリ生成方法およびクエリ生成装置を提供することを目的とする。

第１の案では、クエリ生成プログラムは、コンピュータに、それぞれが属性スキーマの集合である複数のカテゴリスキーマから、取得対象のデータを規定する出力対象テーブルが有する複数の出力項目の属性名に基づき、前記出力対象テーブルと対応付けるメインカテゴリスキーマを決定する処理を実行させる。クエリ生成プログラムは、コンピュータに、前記複数の出力項目のうち、前記メインカテゴリスキーマに対応付けられない出力項目である未対応項目に対し、前記メインカテゴリスキーマが有する複数の属性スキーマそれぞれの特性と関連付けられるカテゴリスキーマから、前記未対応項目と対応付けるサブカテゴリスキーマを決定する処理を実行させる。クエリ生成プログラムは、コンピュータに、前記メインカテゴリスキーマ、および、前記サブカテゴリスキーマに基づき、前記複数のカテゴリスキーマに対するクエリを生成する処理を実行させる。

一実施形態によれば、データ取得を実行するクエリの誤りを低減することができる。

図１は、実施例１にかかるシステムの全体構成例を示す図である。 図２は、テーブルの対応付けを説明する図である。 図３は、テーブルの対応付けの困難性を説明する図である。 図４は、実施例１にかかるクエリ生成装置の機能構成を示す機能ブロック図である。 図５は、出力対象情報ＤＢに記憶される情報を説明する図である。 図６は、カテゴリスキーマＤＢに記憶される情報を説明する図である。 図７は、付加情報ＤＢに記憶される情報を説明する図である。 図８は、カテゴリスキーマ決定後のサブカテゴリスキーマの決定例を説明する図である。 図９は、クエリの例を示す図である。 図１０は、全体的な処理の流れを示すフローチャートである。 図１１は、カテゴリスキーマの類似度計算処理の流れを示すフローチャートである。 図１２は、サブカテゴリスキーマの選択処理の流れを示すフローチャートである。 図１３は、カテゴリスキーマの継承関係を用いる例を説明する図である。 図１４は、ハードウェア構成例を説明する図である。

以下に、本願の開示するクエリ生成プログラム、クエリ生成方法およびクエリ生成装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、複数のＤＢ１とユーザ端末５とクエリ生成装置１０とがネットワークＮを介して相互に通信可能に接続される。なお、ネットワークＮは、有線や無線を問わず、インターネットなどの各種通信網を採用することができる。

複数のＤＢ１は、世界中で公開されるオープンデータを記憶するデータベースやデータベースサーバなどの一例である。ここで記憶されるデータは、ＬＯＤ（Linked Open Data）やナレッジグラフなどと呼ばれ、クラウドシステムなどを用いて一般的に公開されており、任意に利用することができる。本実施例では、ナレッジグラフを一例として説明する。

ユーザ端末５は、スマートフォン、パーソナルコンピュータ、サーバなどのコンピュータ装置の一例である。ユーザ端末５は、所望する項目を設定した出力対象テーブルを生成し、出力対象テーブルの項目に該当するデータをナレッジグラフから取得する。

クエリ生成装置１０は、ナレッジグラフからデータを取得するためのクエリを生成するコンピュータ装置の一例である。具体的には、クエリ生成装置１０は、ユーザ端末５から出力対象テーブルを受け付けて、出力対象テーブルに該当するデータをナレッジグラフから取得するためのクエリを生成する。そして、クエリ生成装置１０は、生成したクエリをユーザ端末５に送信する。この結果、ユーザ端末５は、クエリを実行することで、出力対象テーブルに該当するデータをナレッジグラフから取得できる。

ここで、ユーザ自身がクエリを生成する際に発生する、クエリ生成の困難性について説明する。具体的には、図２を用いて、ユーザ自身が、出力対象テーブルの各項目とナレッジグラフが有する各項目との対応付けについて説明する。図２は、テーブルの対応付けを説明する図である。

まず、ナレッジグラフについて説明する。ナレッジグラフは、複数のカテゴリスキーマを有する。各カテゴリスキーマは、ナレッジグラフから得られる属性の情報でありグラフで表現される属性スキーマと、カテゴリスキーマの名称であるカテゴリ名とを有する。すなわち、カテゴリスキーマは、ナレッジグラフによって表現される属性スキーマの集合であり、属性スキーマは、ナレッジグラフによって表現される属性の情報である。また、属性名は、ナレッジグラフでは属性スキーマの名称であり、出力対象テーブルの項目名であり、いずれも文字列である。

図２を用いて具体的に説明すると、図２のＡは、各カテゴリスキーマを含むナレッジグラフを示す。例えば、カテゴリ名が「サッカー選手」であるカテゴリスキーマは、属性スキーマとして、「名前、所属、生年、ポジション、利き足」を有する。ここで、「名前、所属、生年、ポジション、利き足」のそれぞれが属性名に該当する。また、図２のＢは、ユーザが生成する出力対象テーブルの例であり、「名前、所属チーム名、リーグ名、年齢、ポジション、利き足」のそれぞれが属性名に該当する。

このような状況において、ユーザは、クエリ発行のために、ナレッジグラフ中のカテゴリスキーマと出力対象テーブルとの対応付けを考える。具体的には、ナレッジグラフ中の各カテゴリスキーマと出力対象テーブルの対応を順次求める。このとき、一般的には、属性名間の対応関係は文字列の部分一致などの類似度指標を利用して最も適したものを選択し、どの順番でカテゴリスキーマを割り当てるかは、属性名の数に対する被覆率などといった指標を利用して決定する。

しかし、順次対応付けを行っていくと、少数の属性名から対応関係を判断する状況が生じる。この状況で、対応付けの対象となるカテゴリスキーマの数が多かったり、出力対象テーブルの属性名が一般的な名称であったりすると、対応付けを誤る可能性が高くなる。すなわち、一般的なユーザでは、正しく対応付けを行うことが難しい。

図３は、テーブルの対応付けの困難性を説明する図である。図３に示すように、出力対象テーブルの各属性名と各カテゴリスキーマの各属性スキーマとを比較し、属性名に対する被覆率を計算する。ここでは、カテゴリスキーマ「サッカー選手」が有する５つの属性スキーマのうち４つが出力対象テーブルの属性名と類似するので、被覆率が最も高いカテゴリスキーマとして、「サッカー選手」が選択される。

そして、ユーザは、カテゴリスキーマ「サッカー選手」の属性スキーマ「名前、所属、ポジション、利き足」のそれぞれを、出力対象テーブルの属性名「名前、所属チーム、ポジション、利き足」に対応付ける。

続いて、出力対象テーブルの各属性名と、「サッカー選手」以外の各カテゴリスキーマの各属性スキーマとを比較し、属性名に対する被覆率を計算する。ここでは、カテゴリスキーマ「バレーボールチーム」が有する３つの属性スキーマのうち２つが出力対象テーブルの属性名と類似するので、被覆率が次に高いカテゴリスキーマとして、「バレーボールチーム」が選択される。しかし、ここでは、「バレーボールチーム」ではなく「サッカーチーム」を選択することが正しい。このように、一般的な手法である被覆率だけでは、対応付けの誤りが発生するとともに、ユーザがその誤りに気付くのも難しい。

そこで、実施例１にかかるクエリ生成装置１０は、出力対象テーブルと対応付けるカテゴリスキーマを順次決定する際、メインカテゴリスキーマを決定した後、既に対応付けられたメインカテゴリスキーマのもつ属性スキーマの値域から対応付けの候補を列挙する。そして、クエリ生成装置１０は、列挙したカテゴリスキーマと出力対象テーブルの対応付けを計算し、対応付けるカテゴリスキーマ（サブカテゴリスキーマ）を決定する。

つまり、クエリ生成装置１０は、ナレッジグラフが有する各種情報を用いて、対応付け候補を絞り込んで、出力対象テーブルとの対応付けを行う。この結果、クエリ生成装置１０は、データ取得を実行するクエリの誤りを低減することができる。

［機能構成］
図４は、実施例１にかかるクエリ生成装置１０の機能構成を示す機能ブロック図である。図４に示すように、クエリ生成装置１０は、通信部１１、記憶部１２、制御部２０を有する。

通信部１１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部１１は、各ＤＢ１からナレッジグラフを取得し、ユーザ端末５から出力対象テーブルを取得し、ユーザ端末５にクエリを送信する。

記憶部１２は、データやプログラムを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、出力対象情報ＤＢ１３、ナレッジグラフ情報ＤＢ１４、カテゴリスキーマＤＢ１５、付加情報ＤＢ１６、選択情報ＤＢ１７、クエリＤＢ１８を記憶する。

出力対象情報ＤＢ１３は、ユーザが生成した出力対象テーブルを記憶するデータベースである。図５は、出力対象情報ＤＢ１３に記憶される情報を説明する図である。図５に示すように、出力対象情報ＤＢ１３は、「名前、所属チーム名、リーグ名、年齢、ポジション、利き足」のそれぞれを属性名とする出力対象テーブルを記憶する。つまり、ユーザは、ナレッジグラフから、「名前、所属チーム名、リーグ名、年齢、ポジション、利き足」のそれぞれに該当するデータを取得するクエリの作成を検討する。

ナレッジグラフ情報ＤＢ１４は、ナレッジグラフに関する情報を記憶するデータベースである。例えば、ナレッジグラフ情報ＤＢ１４は、クラウドシステム上における各カテゴリスキーマの格納位置などを記憶する。ここで記憶される情報は、管理者等が格納することもでき、ナレッジグラフから取得することもできる。

カテゴリスキーマＤＢ１５は、ナレッジグラフが有する各カテゴリスキーマに関する情報を記憶するデータベースである。図６は、カテゴリスキーマＤＢ１５に記憶される情報を説明する図である。図６に示すように、カテゴリスキーマＤＢ１５は、カテゴリ名が「サッカー選手」、「バレーボール選手」、「バレーボールチーム」、「サッカーチーム」の各カテゴリスキーマを記憶する。

また、カテゴリスキーマ「サッカー選手」は、属性スキーマとして、「名前、所属、生年、ポジション、利き足」を有する。同様に、カテゴリスキーマ「バレーボール選手」は、属性スキーマとして、「名前、所属、生年、ポジション、指高」を有する。カテゴリスキーマ「バレーボールチーム」は、属性スキーマとして、「チーム名、代表者、所属リーグ」を有する。カテゴリスキーマ「サッカーチーム」は、属性スキーマとして、「チーム名、代表者、所属リーグ、ホームタウン」を有する。

一例を挙げると、カテゴリスキーマＤＢ１５は、カテゴリ名が「サッカー選手＝特許太郎」であるカテゴリスキーマとして、「名前＝特許太郎、所属＝特許チーム、生年＝２００年１月１日、ポジション＝ＦＷ（フォワード）、利き足＝右」などを記憶する。また、カテゴリスキーマＤＢ１５は、カテゴリ名が「サッカーチーム＝特許チーム」であるカテゴリスキーマとして、「チーム名＝特許チーム、代表者＝山田太郎、所属リーグ＝国内プロリーグ、ホームタウン＝東京」などを記憶する。

付加情報ＤＢ１６は、ナレッジグラフから得られる属性に関する情報やカテゴリスキーマに関する情報を、ナレッジグラフと同様のグラフ形式で記憶するデータベースである。図７は、付加情報ＤＢ１６に記憶される情報を説明する図である。図７に示すように、付加情報ＤＢ１６は、各カテゴリスキーマについて、カテゴリスキーマのもつ属性スキーマの付加情報として、別名、重み、定義域、値域、計算式などを記憶する。

例えば、図７に示すように、付加情報ＤＢ１６は、カテゴリスキーマ「サッカー選手」の属性スキーマ「所属」の付加情報として、名前（name）の「所属」、別名（altname）の「所属チーム」、定義域（domain）の「サッカー選手」、値域（range）の「サッカーチーム」を記憶する。また、付加情報ＤＢ１６は、カテゴリスキーマ「サッカー選手」の属性スキーマ「生年」の付加情報として、第１項の「currentyear」、第２項として「生年」を記憶するとともに、「年齢」が「currentyear」−「生年」で計算（calc）できることを記憶する。

選択情報ＤＢ１７は、後述する制御部２０によって選択されたカテゴリスキーマを記憶するデータベースである。具体的には、選択情報ＤＢ１７は、出力対象テーブルに対応付けるカテゴリスキーマを記憶する。

クエリＤＢ１８は、後述する制御部２０によって生成されたクエリを記憶するデータベースである。具体的には、クエリＤＢ１８は、出力対象テーブルの各属性目に該当するデータを、データを記憶するカテゴリスキーマから取得するためのクエリを記憶する。

制御部２０は、クエリ生成装置１０全体を司る処理部であり、例えばプロセッサなどである。この制御部２０は、情報取得部２１、メイン選択部２２、サブ選択部２３、クエリ生成部２４を有する。なお、情報取得部２１、メイン選択部２２、サブ選択部２３、クエリ生成部２４は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。

情報取得部２１は、他の装置から各種情報を取得して記憶部１２の該当するＤＢに格納する処理部である。例えば、情報取得部２１は、ユーザ端末５から出力対象テーブルを取得して、出力対象情報ＤＢ１３に格納する。また、情報取得部２１は、ナレッジグラフ（各ＤＢ１）からカテゴリスキーマに関する情報を取得して、ナレッジグラフ情報ＤＢ１４に格納する。また、情報取得部２１は、ナレッジグラフ（各ＤＢ１）からカテゴリスキーマを取得して、カテゴリスキーマＤＢ１５に格納する。

メイン選択部２２は、それぞれが属性スキーマの集合である複数のカテゴリスキーマから、出力対象テーブルが有する複数の出力項目の属性名に基づき、出力対象テーブルに対するメインカテゴリスキーマを選択する処理部である。具体的には、メイン選択部２２は、各カテゴリスキーマの属性名と出力対象テーブルの属性名との類似度を算出し、各カテゴリスキーマと出力対象テーブルとの間の類似度を算出する。そして、メイン選択部２２は、類似度が最も大きいカテゴリスキーマを、メインカテゴリスキーマに決定する。

例えば、メイン選択部２２は、カテゴリスキーマ「サッカー選手」の各属性スキーマと出力対象テーブルの属性名の類似度を計算する。まず、メイン選択部２２は、サッカー選手の「名前」と最長部分一致する属性名を探して、類似度を計算する。ここでは、メイン選択部２２は、「LCS（サッカー選手．名前，出力対象テーブル．名前）／max（length（サッカー選手．名前），length（出力対象テーブル．名前））」で計算する。すなわち、メイン選択部２２は、「（LCS（サッカー選手．名前，出力対象テーブル．名前）＝２）／（max（length（サッカー選手．名前）＝２，length（出力対象テーブル．名前）＝２）＝２）」より、類似度＝「２／２」＝１を算出する。なお、「サッカー選手．名前」は、カテゴリスキーマ「サッカー選手」の属性名「名前」を表記したものである。

続いて、メイン選択部２２は、サッカー選手の「所属」と最長部分一致する属性名を探して、類似度を計算する。ただし、付加情報ＤＢ１６を参照すると、サッカー選手の「所属」は別名「所属チーム」を持つので、別名との類似度も計算して類似度が最大のものを選択する。ここでは、「LCS（サッカー選手．所属チーム，出力対象テーブル．所属チーム名）／max（length（サッカー選手．所属チーム），length（出力対象テーブル．所属チーム名））」の類似度が最も高い。すなわち、メイン選択部２２は、「（LCS（サッカー選手．所属チーム＝５，出力対象テーブル．所属チーム名＝６）＝５）／（max（length（サッカー選手．所属チーム）＝５，length（出力対象テーブル．所属チーム名）＝６）＝６」より、類似度＝「５／６」を算出する。

続いて、メイン選択部２２は、サッカー選手の「生年」と最長部分一致する属性名を探して、類似度を計算する。ただし、付加情報ＤＢ１６を参照すると、「年齢」から「生年」に変換可能であることから、「生年」と「年齢」のそれぞれについて類似度を計算して、類似度が最大のものを選択する。ここでは、「LCS（サッカー選手．年齢，出力対象テーブル．年齢）／max（length（サッカー選手．年齢），length（出力対象テーブル．年齢））」の類似度が最も高い。すなわち、メイン選択部２２は、「（LCS（サッカー選手．年齢＝２，出力対象テーブル．年齢＝２）＝２）／（max（length（サッカー選手．年齢）＝２，length（出力対象テーブル．年齢）＝２）＝２」より、類似度＝「２／２」＝１を算出する。

続いて、メイン選択部２２は、サッカー選手の「ポジション」と最長部分一致する属性名を探して、類似度を計算する。ここでは、「LCS（サッカー選手．ポジション，出力対象テーブル．ポジション）／max（length（サッカー選手．ポジション），length（出力対象テーブル．ポジション））」の類似度が最も高い。すなわち、メイン選択部２２は、「（LCS（サッカー選手．ポジション，出力対象テーブル．ポジション）＝５）／（max（length（サッカー選手．ポジション）＝５，length（出力対象テーブル．ポジション）＝５）＝５）」より、類似度＝「５／５」＝１を算出する。

続いて、メイン選択部２２は、サッカー選手の「利き足」と最長部分一致する属性名を探して、類似度を計算する。ここでは、「LCS（サッカー選手．利き足，出力対象テーブル．利き足）／max（length（サッカー選手．利き足），length（出力対象テーブル．利き足））」の類似度が最も高い。すなわち、メイン選択部２２は、「（LCS（サッカー選手．利き足，出力対象テーブル．利き足）＝３）／（max（length（サッカー選手．利き足）＝３，length（出力対象テーブル．利き足）＝３）＝３）」より、類似度＝「３／３」＝１を算出する。

そして、メイン選択部２２は、カテゴリスキーマ「サッカー選手」と出力対象テーブルの類似度を「出力対象テーブルに対する被覆率×各属性スキーマの類似度の平均値」で算出する。ここで、出力対象テーブルの６つの属性名のうち５つがカテゴリスキーマ「サッカー選手」の属性名と一致する（上記類似度が０以上）ので、被覆率は５／６となる。したがって、メイン選択部２２は、「（５／６）×（（１＋５／６＋１＋１＋１）／５）」＝０．８０５５を、カテゴリスキーマ「サッカー選手」と出力対象テーブルの類似度として算出する。

同様に、メイン選択部２２は、カテゴリスキーマ「バレーボール選手」の各属性スキーマと出力対象テーブルの属性名の類似度を計算する。具体的には、メイン選択部２２は、「バレーボール選手．名前」については「出力対象テーブル．名前」が完全に一致するので、類似度を「１」と算出する。また、メイン選択部２２は、「バレーボール選手．所属（別名：所属チーム）」については「出力対象テーブル．所属チーム名」と５文字が一致するので、類似度を「５／６」と算出する。メイン選択部２２は、「バレーボール選手．生年（計算可能：年齢）」については「出力対象テーブル．年齢」と完全一致するので、類似度を「１」と算出する。メイン選択部２２は、「バレーボール選手．ポジション」については「出力対象テーブル．ポジション」と完全一致するので、類似度を「１」と算出する。また、メイン選択部２２は、「バレーボール選手．指高」については「出力対象テーブル」に被覆する文字列が存在しないので、類似度を「０」と算出する。

そして、メイン選択部２２は、カテゴリスキーマ「バレーボール選手」と出力対象テーブルの類似度を「出力対象テーブルに対する被覆率×各属性スキーマの類似度の平均値」で算出する。ここで、出力対象テーブルの６つの属性名のうち４つがカテゴリスキーマ「バレーボール選手」の属性名と一致するので、被覆率は４／６となる。したがって、メイン選択部２２は、「（４／６）×（（１＋５／６＋１＋１＋０）／５）」＝０．５１１１１を、カテゴリスキーマ「バレーボール選手」と出力対象テーブルの類似度として算出する。

同様に、メイン選択部２２は、カテゴリスキーマ「バレーボールチーム」の各属性スキーマと出力対象テーブルの属性名の類似度を計算する。具体的には、メイン選択部２２は、「バレーボールチーム．チーム名」については、出力対象テーブルの「所属チーム名」と最長部分一致するので、類似度を「４／６」と算出する。メイン選択部２２は、「バレーボールチーム．代表者」については、部分一致する出力対象テーブルの属性名が存在しないので、類似度を「０」と算出する。メイン選択部２２は、「バレーボールチーム．所属リーグ」については、出力対象テーブルの「リーグ名」と最長部分一致するので、類似度を「３／５」と算出する。

そして、メイン選択部２２は、カテゴリスキーマ「バレーボールチーム」と出力対象テーブルの類似度を、「出力対象テーブルに対する被覆率×各属性スキーマの類似度の平均値」＝「（２／６）×（（４／６＋０＋３／５）／３）」＝０．１４０７４を、カテゴリスキーマ「バレーボールチーム」と出力対象テーブルの類似度として算出する。

同様に、メイン選択部２２は、カテゴリスキーマ「サッカーチーム」の各属性スキーマと出力対象テーブルの属性名の類似度を計算する。具体的には、メイン選択部２２は、「サッカーチーム．チーム名」については、出力対象テーブルの「所属チーム名」と最長部分一致するので、類似度を「４／６」と算出する。メイン選択部２２は、「サッカーチーム．代表者」については、部分一致する出力対象テーブルの属性名が存在しないので、類似度を「０」と算出する。メイン選択部２２は、「サッカーチーム．所属リーグ」については、出力対象テーブルの「リーグ名」と最長部分一致するので、類似度を「３／５」と算出する。メイン選択部２２は、「サッカーチーム．ホームタウン」については、部分一致する出力対象テーブルの属性名が存在しないので、類似度を「０」と算出する。

そして、メイン選択部２２は、カテゴリスキーマ「サッカーチーム」と出力対象テーブルの類似度を、「出力対象テーブルに対する被覆率×各属性スキーマの類似度の平均値」＝「（２／６）×（（４／６＋０＋３／５＋０）／４）」≒０．１０５５６を、カテゴリスキーマ「サッカーチーム」と出力対象テーブルの類似度として算出する。

このようして類似度を算出した後、メイン選択部２２は、類似度が最大かつ閾値（例えば０．１）を超えているカテゴリスキーマ「サッカー選手」をメインカテゴリスキーマに選択する。この結果、メイン選択部２２は、カテゴリスキーマ「サッカー選手」の属性スキーマ「名前、所属、生年、ポジション、利き足」のうち、類似度が１であった属性スキーマ「名前、所属、ポジション、利き足」を出力対象テーブルの属性名「名前、所属チーム名、ポジション、利き足」にそれぞれ対応付ける。

そして、メイン選択部２２は、この対応付けの情報や選択したカテゴリスキーマ「サッカー選手」に関する情報等を選択情報ＤＢ１７に格納し、サブ選択部２３にも通知する。なお、例えば閾値０．１以下の場合マッチするカテゴリスキーマなしと判定される。また、上記類似度の算出において、最長部分一致する属性名が複数ある場合は、類似度が最大のものが選択される。

図４に戻り、サブ選択部２３は、出力対象テーブルの属性名のうち、メインカテゴリスキーマに対応付けられない属性名それぞれに対し、メインカテゴリスキーマの特性に関する情報、および、決定候補となるカテゴリスキーマそれぞれの属性スキーマに関する情報に基づき、サブカテゴリスキーマを決定する処理部である。

具体的には、サブ選択部２３は、既に対応付けられたメインカテゴリスキーマのもつ属性スキーマのrangeからカテゴリスキーマの列挙を行い、類似度による対応付けを行う。そして、サブ選択部２３は、対応付けが失敗もしくは出力対象テーブルのすべての属性名がカテゴリスキーマと対応付けられたところで処理を終了する。

上記例では、サブ選択部２３は、出力対象テーブルのうち、メインカテゴリスキーマ「サッカー選手」の属性スキーマと対応していない属性名の集合（部分テーブル）について、サブカテゴリスキーマ候補「サッカーチーム」との類似度を計算する。

図８は、カテゴリスキーマ決定後のサブカテゴリスキーマの決定例を説明する図である。図８に示すように、カテゴリスキーマ「サッカー選手」の属性スキーマ「名前、所属、生年、ポジション、利き足」が出力対象テーブルの属性名「名前、所属チーム名、年齢、ポジション、利き足」のそれぞれに対応付けられたので、サブ選択部２３は、付加情報ＤＢ１６を参照して、カテゴリスキーマ「サッカー選手」の属性スキーマ「名前、所属、生年、ポジション、利き足」のそれぞれのrangeから次の対応付け候補を検索する。例えば、図８に示す状態の場合、サブ選択部２３は、カテゴリスキーマ「サッカーチーム」、カテゴリスキーマ「社長」、カテゴリスキーマ「サッカー選手」、カテゴリスキーマ「バレーボール選手」を、サブカテゴリスキーマ候補とする。

ただし、上記例では、サブ選択部２３は、「サッカー選手」が既に出力対象テーブルと対応付けられているため、サッカー選手をrangeとしてもつ「名前」から列挙される候補は除外するので、サッカーチームのみを候補とする。この場合、サブ選択部２３は、カテゴリスキーマＤＢ１５を参照して、カテゴリスキーマ「サッカーチーム」の属性スキーマ「チーム名、代表者、所属リーグ、ホームタウン」を特定する。

そして、サブ選択部２３は、出力対象テーブルの属性名「名前、所属チーム名、リーグ名、年齢、ポジション、利き足」のうち、メインカテゴリスキーマ「サッカー選手」と対応付けられていない属性スキーマ「リーグ名」について、上記類似度計算により、カテゴリスキーマ「サッカーチーム」がサブカテゴリスキーマとして選択可能か否かを判定する。なお、出力対象テーブルの属性名「所属チーム名」は、メインカテゴリスキーマ「サッカー選手」の属性スキーマ「所属」と対応しているが、「サッカーチーム」は「所属」のrangeであり、属性スキーマを共有する可能性があるので、類似度計算の対象とする。すなわち、サブ選択部２３は、出力対象テーブルの属性名「所属チーム、リーグ名」について、類似度判定を実行する。

具体的には、サブ選択部２３は、メイン選択部２２と同様の手法により、カテゴリスキーマ「サッカーチーム」の各属性スキーマと出力対象テーブルの属性名の類似度を計算する。例えば、サブ選択部２３は、「サッカーチーム．チーム名」については、出力対象テーブルの「所属チーム名」と最長部分一致するので、類似度を「４／６」と算出する。サブ選択部２３は、「サッカーチーム．代表者」については、部分一致する出力対象テーブルの属性名が存在しないので、類似度を「０」と算出する。サブ選択部２３は、「サッカーチーム．所属リーグ」については、出力対象テーブルの「リーグ名」と最長部分一致するので、類似度を「３／５」と算出する。サブ選択部２３は、「サッカーチーム．ホームタウン」については、部分一致する出力対象テーブルの属性名が存在しないので、類似度を「０」と算出する。

そして、サブ選択部２３は、類似度の判定対象である出力対象テーブルの属性名「所属チーム、リーグ名」がカテゴリスキーマ「サッカー選手」の属性スキーマと被覆（文字列の一致）しているので、被覆率を「（２／２）＝１」と算出する。また、メイン選択部は、各属性スキーマの平均値として、「（４／６＋０＋３／５＋０）／４≒０．３１６６７」を算出する。この結果、サブ選択部２３は、カテゴリスキーマ「サッカーチーム」と出力対象テーブルの類似度として、「出力対象テーブルに対する被覆率×各属性スキーマの類似度の平均値」＝「１×０．３１６６７＝０．３１６６７」を算出する。

続いて、サブ選択部２３は、サブカテゴリスキーマ候補であるカテゴリスキーマ「サッカーチーム」の類似度が閾値以上であることから、カテゴリスキーマ「サッカーチーム」をサブカテゴリスキーマに選択する。この結果、サブ選択部２３は、カテゴリスキーマ「サッカーチーム」の属性スキーマ「所属リーグ」を、出力対象テーブルの属性名「所属チーム名」に対応付ける。

そして、サブ選択部２３は、この対応付けの情報や選択したサブカテゴリスキーマ「サッカーチーム」に関する情報等を選択情報ＤＢ１７に格納し、なお、例えば閾値０．１以下の場合マッチするカテゴリスキーマなしと判定される。また、上記類似度の算出において、最長部分一致する属性名が複数ある場合は、類似度が最大のものが選択される。また、サブ選択部２３は、rangeが複数存在する場合、各カテゴリスキーマについて上記類似度を算出し、類似度が最も高いカテゴリスキーマをサブカテゴリスキーマに選択する。

クエリ生成部２４は、メイン選択部２２およびサブ選択部２３による対応付け結果に基づいて、クエリを生成する処理部である。具体的には、クエリ生成部２４は、メイン選択部２２によって選択されたカテゴリスキーマの属性スキーマと対応付けられるデータ、および、サブ選択部２３によって選択されたサブカテゴリスキーマの属性スキーマと対応付けられるデータから、出力対象テーブルの属性名に対応するデータを読み出して取得するクエリを生成する。

例えば、ナレッジグラフをLinked Dataとして格納している場合で考えると、ナレッジグラフのノード、エッジはＵＲＩ（Uniform Resource Identifier）で表現される。一例を挙げると、「サッカー選手」は「http://example/サッカー選手」などと表現される。そして、クエリ生成部２４は、「サッカー選手」および「サッカーチーム」の各カテゴリスキーマが選択されている場合に、クエリ言語としてSPARQLを利用して図９に示すSPARQLクエリを生成することができる。図９は、クエリの例を示す図である。そして、クエリ生成部２４は、図９に示すクエリをクエリＤＢ１８に格納したり、ユーザ端末５に送信したりする。なお、ユーザ端末５は、図９に示すクエリを実行することで、出力対象テーブルに該当するデータをナレッジグラフから取得することができる。

［処理の流れ］
次に、クエリ生成に関する処理の流れについて説明する。ここでは、全体的な処理、カテゴリスキーマの選択、サブカテゴリスキーマの選択の各処理について説明する。

（全体的な処理）
図１０は、全体的な処理の流れを示すフローチャートである。図１０に示すように、情報取得部２１は、ユーザ端末５から出力対象テーブルを取得して、出力対象情報ＤＢ１３に格納する（Ｓ１０１）。続いて、情報取得部２１は、ナレッジグラフからカテゴリスキーマに関する情報を取得して、カテゴリスキーマＤＢ１５に格納する（Ｓ１０２）。なお、情報取得部２１は、ナレッジグラフからナレッジグラフに関する情報を取得して、ナレッジグラフ情報ＤＢ１４に格納することもできる。

そして、メイン選択部２２は、カテゴリスキーマの類似度計算処理を実行し（Ｓ１０３）、類似度が最大かつ閾値を越えているカテゴリスキーマをメインカテゴリスキーマに決定する（Ｓ１０４）。

その後、サブ選択部２３は、類似度計算によるサブカテゴリスキーマの選択処理を実行し（Ｓ１０５）、クエリ生成部２４は、カテゴリスキーマと出力対象テーブルの対応情報に基づいてクエリを生成する（Ｓ１０６）。

（カテゴリスキーマの選択）
図１１は、カテゴリスキーマの類似度計算処理の流れを示すフローチャートである。この処理は、図１０のＳ１０３で実行される処理であり。

図１１に示すように、メイン選択部２２は、類似度の算出が完了していない場合（Ｓ２０１：Ｎｏ）、カテゴリスキーマＤＢ１５等から、類似度を調べていないカテゴリスキーマの情報を取得する（Ｓ２０２）。例えば、メイン選択部２２は、すべてのカテゴリスキーマについて出力対象テーブルとの類似度を調べたかを判定し、完了していない場合には、Ｓ２０２を実行し、完了している場合には、処理を終了して、図１０のＳ１０４が実行される。

続いて、メイン選択部２２は、対応関係の判定が完了しているか否かを判定する（Ｓ２０３）。例えば、メイン選択部２２は、取得したカテゴリスキーマのすべての属性スキーマについて、出力完了テーブルの属性名との対応関係を調べたか否かを判定する。

そして、メイン選択部２２は、対応関係の判定が完了していない場合（Ｓ２０３：Ｎｏ）、まだ対応関係を調べていない属性スキーマの情報を取得する（Ｓ２０４）。続いて、メイン選択部２２は、属性スキーマの情報を利用して出力対象テーブルの属性名と最長一致する属性スキーマを取得する（Ｓ２０５）。そして、メイン選択部２２は、最長一致する属性スキーマのうち最も類似度が高くかつ閾値を超えているものを対応する属性スキーマとする（Ｓ２０６）。その後、Ｓ２０３以降の処理が繰り返される。

一方、Ｓ２０３において、メイン選択部２２は、対応関係の判定が完了した場合（Ｓ２０３：Ｙｅｓ）、属性スキーマと出力対象テーブルの属性名の対応関係から、出力対象テーブルに対するカテゴリスキーマの被覆率を計算する（Ｓ２０７）。そして、メイン選択部２２は、属性スキーマの対応関係と被覆率から、出力対象テーブルとカテゴリスキーマの類似度を計算する（Ｓ２０８）。その後、Ｓ２０１に戻って以降の処理が繰り返される。

（サブカテゴリスキーマの選択）
図１２は、サブカテゴリスキーマの選択処理の流れを示すフローチャートである。この処理は、図１０のＳ１０５で実行される処理であり。

図１２に示すように、サブ選択部２３は、対応付けが完了していない場合（Ｓ３０１：Ｎｏ）、既に対応付けられたカテゴリスキーマの属性スキーマについて付加情報（range）から対応付け候補となるカテゴリスキーマを列挙する（Ｓ３０２）。例えば、サブ選択部２３は、出力対象テーブルにおいて対応付けが未完了の部分を示す部分テーブルのすべての属性名がカテゴリスキーマと対応付けられているかを判定し、完了していない場合には、Ｓ３０２を実行し、完了している場合には、処理を終了して、図１０のＳ１０６が実行される。

続いて、サブ選択部２３は、列挙したすべてのカテゴリスキーマについて、部分テーブルとの対応関係を調べたか否かを判定する（Ｓ３０３）。そして、サブ選択部２３は、対応関係の未調査が存在する場合（Ｓ３０３：Ｎｏ）、まだ対応関係を調べていないカテゴリスキーマを取得する（Ｓ３０４）。

その後、サブ選択部２３は、列挙したカテゴリスキーマのすべての属性スキーマについて部分テーブルとの対応関係を調べたか否かを判定する（Ｓ３０５）。そして、サブ選択部２３は、対応関係の未調査が存在する場合（Ｓ３０５：Ｎｏ）、まだ対応関係を調べていない属性スキーマの情報を取得する（Ｓ３０６）。続いて、サブ選択部２３は、属性スキーマの情報を利用して部分テーブルの属性名と名称が最長一致する属性スキーマを取得する（Ｓ３０７）。そして、サブ選択部２３は、名称が最長一致する属性スキーマから最も類似度が高く、かつ、類似度が閾値を超えているものを対応する属性スキーマとする（Ｓ３０８）。その後、Ｓ３０５以降の処理が繰り返される。

一方、Ｓ３０５において、サブ選択部２３は、対応関係の調査が完了した場合（Ｓ３０５：Ｙｅｓ）、属性スキーマの対応関係から部分テーブルに対するカテゴリスキーマの被覆率を計算する（Ｓ３０９）。そして、サブ選択部２３は、属性スキーマの対応関係と被覆率から部分テーブルとカテゴリスキーマの類似度を計算する（Ｓ３１０）。その後、Ｓ３０３に戻って以降の処理が繰り返される。

一方、Ｓ３０３において、サブ選択部２３は、対応関係の調査が完了した場合（Ｓ３０３：Ｙｅｓ）、属性名との新規対応関係をもつカテゴリスキーマが存在するか否かを判定する（Ｓ３１１）。ここで、サブ選択部２３は、属性名との新規対応関係をもつカテゴリスキーマが存在しない場合（Ｓ３１１：Ｎｏ）、処理を終了する。一方、サブ選択部２３は、属性名との新規対応関係をもつカテゴリスキーマが存在する場合（Ｓ３１１：Ｙｅｓ）、類似度が最大かつ閾値を超えているカテゴリスキーマをサブカテゴリスキーマとして選択する（Ｓ３１２）。その後、Ｓ３０１に戻って以降の処理が繰り返される。

［効果］
上述したように、クエリ生成装置１０は、付加情報をグラフ形式で柔軟に持つことができるカテゴリスキーマを有するナレッジグラフの特徴を有効的に利用する。そして、クエリ生成装置１０は、出力対象テーブルと対応付けるカテゴリスキーマを順次決定する際、メインカテゴリスキーマを決定した後、既に対応付けられたカテゴリスキーマのもつ属性スキーマの値域から対応付けの候補を列挙する。その後、クエリ生成装置１０は、列挙したカテゴリスキーマと出力テーブルの対応付けを計算し、対応付けるカテゴリスキーマ（サブカテゴリスキーマ）を決定する。

このように、クエリ生成装置１０は、カテゴリスキーマを絞り込みながら、出力対象テーブルに対応付けるカテゴリスキーマを選択することができる。したがって、クエリ生成装置１０は、データ取得を実行するクエリの誤りを低減することができる。また、クエリ生成装置１０は、出力対象テーブルの属性名それぞれに対するカテゴリスキーマの対応付けを、計算量を抑えつつ誤りを低減させて行うことができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

［類似度の算出式］
上記実施例で説明した類似度の算出式等は、あくまで例示であり、例示したものに限定されず、公知の様々な手法を採用することができる。また、カテゴリスキーマの数や閾値なども例示であり、任意に設定変更することができる。

［サブカテゴリスキーマ］
上記実施例では、メインカテゴリスキーマの選択後に、メインカテゴリスキーマが有する属性スキーマの値域（range）を用いて、対応付け候補のサブカテゴリスキーマを選択する例を説明したが、これに限定されるものではない。例えば、重みなど値域（range）以外の他の付加情報を用いて、対応付け候補のサブカテゴリスキーマを選択することもできる。

［継承関係］
例えば、ナレッジグラフの各カテゴリスキーマにクラスなどが設定されている場合、カテゴリスキーマ間で特性を引き継ぐ継承関係を有する場合がある。そのような場合に継承関係を用いて、対応付け候補となるカテゴリスキーマを絞り込むこともできる。

図１３は、カテゴリスキーマの継承関係を用いる例を説明する図である。図１３に示すように、カテゴリスキーマ「株式会社」の継承元がカテゴリスキーマ「会社」であり、カテゴリスキーマ「会社」の継承元がカテゴリスキーマ「組織」である例で説明する。この場合、クエリ生成装置１０は、カテゴリスキーマのうち類似度が最も高いカテゴリスキーマとして「株式会社」を特定したとする。

すると、クエリ生成装置１０は、サブカテゴリスキーマの選択に際して、カテゴリスキーマ「株式会社」を継承先とする継承元のカテゴリスキーマ「会社」に対して、類似度による判定を実行する。このとき、クエリ生成装置１０は、継承元のカテゴリスキーマが複数存在する場合は、各継承元のカテゴリスキーマについて類似度による判定を行う。このようにして、クエリ生成装置１０は、継承関係によって、対応付け候補のカテゴリスキーマを絞り込むこともできる。

図１３の例では、カテゴリスキーマ「株式会社」の属性スキーマ「株価時価総額」が出力対象テーブルの属性名「時価総額」に対応付けられた後、継承関係にあるカテゴリスキーマ「会社」の属性スキーマ「社長」が出力対象テーブルの属性名「社長」に対応付けられる。その後、更なる継承関係にあるカテゴリスキーマ「組織」の属性スキーマ「名前」が出力対象テーブルの属性名「名前」に対応付けられる。

また、クエリ生成装置１０は、対象のサブカテゴリスキーマに利用可能な属性スキーマが存在しない場合に、カテゴリスキーマの継承関係を用いて対応付け候補のカテゴリスキーマを絞り込む。例えば、クエリ生成装置１０は、類似度が閾値のカテゴリスキーマが存在しない場合に、メインカテゴリスキーマを継承先とするカテゴリスキーマをサブカテゴリスキーマに決定したり、メインカテゴリスキーマを継承先とする複数のカテゴリスキーマそれぞれについて上記類似度を算出してサブカテゴリスキーマを決定したりすることもできる。この結果、より適切な対応付けを行うことができる場合がある。

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［ハードウェア構成］
図１４は、ハードウェア構成例を説明する図である。図１４に示すように、クエリ生成装置１０は、通信インタフェース１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。

通信インタフェース１０ａは、他の装置の通信を制御するネットワークインタフェースカードなどである。ＨＤＤ１０ｂは、プログラムやデータなどを記憶する記憶装置の一例である。

メモリ１０ｃの一例としては、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。プロセッサ１０ｄの一例としては、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）等が挙げられる。

また、クエリ生成装置１０は、プログラムを読み出して実行することでクエリ生成方法を実行する情報処理装置として動作する。つまり、クエリ生成装置１０は、情報取得部２１、メイン選択部２２、サブ選択部２３、クエリ生成部２４と同様の機能を実行するプログラムを実行する。この結果、クエリ生成装置１０は、情報取得部２１、メイン選択部２２、サブ選択部２３、クエリ生成部２４と同様の機能を実行するプロセスを実行することができる。なお、この他の実施例でいうプログラムは、クエリ生成装置１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

１ ＤＢ
５ ユーザ端末
１０ クエリ生成装置
１１ 通信部
１２ 記憶部
１３ 出力対象情報ＤＢ
１４ ナレッジグラフ情報ＤＢ
１５ カテゴリスキーマＤＢ
１６ 付加情報ＤＢ
１７ 選択情報ＤＢ
１８ クエリＤＢ
２０ 制御部
２１ 情報取得部
２２ メイン選択部
２３ サブ選択部
２４ クエリ生成部

Claims (7)

1. コンピュータに、
   それぞれが属性スキーマの集合である複数のカテゴリスキーマから、取得対象のデータを規定する出力対象テーブルが有する複数の出力項目の属性名に基づき、前記出力対象テーブルと対応付けるメインカテゴリスキーマを決定し、
   前記複数の出力項目のうち、前記メインカテゴリスキーマに対応付けられない出力項目である未対応項目に対し、前記メインカテゴリスキーマが有する複数の属性スキーマそれぞれの特性と関連付けられるカテゴリスキーマから、前記未対応項目と対応付けるサブカテゴリスキーマを決定し、
   前記メインカテゴリスキーマ、および、前記サブカテゴリスキーマに基づき、前記複数のカテゴリスキーマに対するクエリを生成する
   処理を実行させることを特徴とするクエリ生成プログラム。
2. 前記複数のカテゴリスキーマそれぞれについて、各カテゴリスキーマが有する属性スキーマの名称である属性名と、前記出力対象テーブルの前記属性名との類似度を算出し、類似度が最も高いカテゴリスキーマを、前記メインカテゴリスキーマに決定する処理を、前記コンピュータに実行させることを特徴とする請求項１に記載のクエリ生成プログラム。
3. 前記メインカテゴリスキーマが有する複数の属性スキーマそれぞれの特性のうち、予め指定された特性と関連付けられるカテゴリスキーマが複数存在する場合、該当する複数のカテゴリスキーマそれぞれについて、各カテゴリスキーマが有する属性スキーマの名称である属性名と、前記出力対象テーブルの前記未対応項目の属性名との類似度を算出し、類似度が最も高いカテゴリスキーマを、前記サブカテゴリスキーマに決定する処理を、前記コンピュータに実行させることを特徴とする請求項２に記載のクエリ生成プログラム。
4. 前記類似度が閾値以上であるカテゴリスキーマが存在しない場合、前記メインカテゴリスキーマの特性を引き継ぐ継承関係にあるカテゴリスキーマから、前記サブカテゴリスキーマを決定する処理を、前記コンピュータに実行させることを特徴とする請求項３に記載のクエリ生成プログラム。
5. 前記出力対象テーブルが有する複数の出力項目それぞれに該当するデータを、前記メインカテゴリスキーマに記憶される複数のデータ、および、前記サブカテゴリスキーマに記憶される複数のデータから読み出すための前記クエリを生成することを特徴とする請求項１に記載のクエリ生成プログラム。
6. コンピュータが、
   それぞれが属性スキーマの集合である複数のカテゴリスキーマから、取得対象のデータを規定する出力対象テーブルが有する複数の出力項目の属性名に基づき、前記出力対象テーブルと対応付けるメインカテゴリスキーマを決定し、
   前記複数の出力項目のうち、前記メインカテゴリスキーマに対応付けられない出力項目である未対応項目に対し、前記メインカテゴリスキーマが有する複数の属性スキーマそれぞれの特性と関連付けられるカテゴリスキーマから、前記未対応項目と対応付けるサブカテゴリスキーマを決定し、
   前記メインカテゴリスキーマ、および、前記サブカテゴリスキーマに基づき、前記複数のカテゴリスキーマに対するクエリを生成する
   処理を実行することを特徴とするクエリ生成方法。
7. それぞれが属性スキーマの集合である複数のカテゴリスキーマから、取得対象のデータを規定する出力対象テーブルが有する複数の出力項目の属性名に基づき、前記出力対象テーブルと対応付けるメインカテゴリスキーマを決定する第１決定部と、
   前記複数の出力項目のうち、前記メインカテゴリスキーマに対応付けられない出力項目である未対応項目に対し、前記メインカテゴリスキーマが有する複数の属性スキーマそれぞれの特性と関連付けられるカテゴリスキーマから、前記未対応項目と対応付けるサブカテゴリスキーマを決定する第２決定部と、
   前記メインカテゴリスキーマ、および、前記サブカテゴリスキーマに基づき、前記複数のカテゴリスキーマに対するクエリを生成する生成部と
   を有することを特徴とするクエリ生成装置。

Images