JPH09510565A - データベース問い合わせシステム - Google Patents

Abstract

(57)【要約】 構造的にも意味的にも正しい（また、意味的に正しいSQL を生成すべくSQL ジェネレータによって処理されることができる）問い合わせのみユーザが入力するのを許容する問い合わせアシスタントを含むデータベース問い合わせシステムである。対話ボックスの使用を通して、ユーザは、ユーザが容易に理解する中間的な英語のような言語で問い合わせを入力する。問い合わせエキスパートシステムは、問い合わせか作られているときにその問い合わせを監視し、そして、データベースの構造についての情報を使用して、誤った問い合わせを作成するような対話ボックスにおける選択を許可しないことによって、ユーザが意味的に不正確な問い合わせを構築するのを防止する。変換及びパターン代用の集合を使用して、中間言語を構造的にも意味的にも正しいSQL 問い合わせに変換するSQL ジェネレータが、また、設けられる。中間言語は、複雑ではあるが、同時に理解しやすいSQL 問い合わせを表すことができる。中間言語は、また、SQL 問い合わせに容易に変換されるように設計される。問い合わせアシスタント及びSQL ジェネレータに加え、管理者が基となるデータベースに概念層を追加するのを許容する管理機能が設けられ、ユーザがデータベースに問い合わせをするのをより容易にする。この概念層は、コラム及びテーブルの代替名、標準的な及び複合的な結合を指定する経路、仮想テーブル及びコラムの定義、並びにユーザアクセスに関する制限を含むことができる。

Description

【発明の詳細な説明】 データベース問い合わせシステム 発明の背景 本発明はデータベース問い合わせシステムに関し、特に構造的且つ意味的に正 しい問い合わせを会話的に生成するようにユーザをガイドするデータベース問い 合わせツールに関する。 エンド・ユーザ・ワークステーションはたえず増大する割合で物理的に中央デ ータベースに接続されつつある。しかしながら、これらのデータベースに含まれ る情報にアクセスするために、ユーザは、多くの場合はストラクチャード・クエ リー・ラングエッジ（SQL）である標準化された問い合わせ言語を用いて問い合 わせを作成しなければならない。大部分の情報システム組織は、それらユーザの SQL を試みかつ教えることは非生産的であると考えている。その結果、データベ ースから望まれる情報の設計用のより直観的な方法を用いて、ユーザのためにSQ L を作成するツールに対する関心が増大している。これらのツールは一般にSQL ジェネレータと呼ばれている。 今日の市場にある大部分のSQL ジェネレータは、SQL の複雑性をユーザに隠し ているように見える。真実は、これらのツールは検索できる情報の範囲を厳しく 制限することによりこれを達成している。より重要なことには、これらのツール はユーザが正しくない結果を極めて容易に得るようにさせている。SQL の複雑性 からユーザを遮蔽する既存の技術設計は次の３つのカテゴリに分類できる：ポイ ント・アンド・ショット・メニュー；自然言語システム；及び自然言語メニュー ・システム。製品／技術のこれらのカテゴリの各々は 、SQL の複雑性からユーザを真に遮蔽することを妨げる構造的欠陥を有している 。 Ｉ．エンド・ユーザ・問い合わせ・言語としてのSQL の限界 SQL は、全体として、非常に複雑である。いくつかの情報要求は非常に単純な SQL ステートメントにより満足され得る。例えば、データベースから顧客名とジ ップコードにより格納されたニューヨークの顧客の電話のリストを生成するため に、以下のSQL ステートメントが使用され得る。 この例において、SELECTコマンドはどのフィールドを使用するかを規定し、WH ERE コマンドはデータベースレコードが選択される条件を規定し、ORDER BYのキ ーワードは出力がどのようにして格納されるべきかを規定している。FROMのキー ワードはどのテーブルにフィールドが配置されているかを規定する。残念ながら 、そのような単純なSQL では要求される情報の比較的小さい割合しか満足されな い。 多くの情報ニーズは、非常に単純な問い合わせであっても、複雑なSQL 問い合 わせを必要とする。例えば、バックオーダ上に２つより多い製品を持つ注文のリ ストを生成することを要求されるSQL ステートメントは： このSQL ステートメントは２つのSELECTクローズを含み、１つは他にネストさ れている。この情報要求がこの種のネスティング（相互に関連するサブ問い合わ せとして知られる）を必要とするということをユーザが知る為には、ユーザが関 連する計算について幾分の理解があることを暗に意味している。しかしながら、 数学者及びコンピュータの分野の人々以外では、殆どのユーザはこのことに慣れ ていない。以下はより複雑なSQL 構成を必要とするデータベース問い合わせのい くつかの例である。 GROUP BY：特別の問い合わせのおよそ75％はSQL 内のGROUP BYステートメント を要求する。例は次のものを含む： 部による全体売上を示せ（Show total seles by division.） ミルフォード・ファニチャーへの寝室セットの１月の売上を示せ（Show janua ry sales of bedroom sets to Miford Furniture.） サブ問い合わせ：以下はSQL 内でネストされたWHERE クローズとして現れるサ ブ問い合わせ構成を要求するデータベースの例である： 10才以下の子供を持ちカレッジ基金を持たない顧客を示せ（Show customers t hat have children under age 10 and do not have a college fund.） 受注残に関する２ラインアイテム以上の注文を示せ（Show orders that have more than 2 line items on backorder.） HAVING：以下はHAVING構成を要求するデータベースの例である： 今年から今日までの支出合計が15,000,000ドルを超える部に従業員による今年 から今日までの支出を示せ（Show ytd expenses by employee for divisions th at have total ytd expenses over $15,000,000.） 100,000 を超える全体の未収金を持つセールスマンの名前及びマネージャーを 示せ（Show the name and manager of salesmen that have total outstanding receivable of more than $100,000.） CREATE VIEW：以下はCREATE VIEW シンタックスを要求するデータベースの例 である： 全体の割合で顧客による今年から今日までの売上を示せ（Show ytd sales by customer with percent of total.） 25000 ドル以下の今年から今日までの売上合計が私のセールスマンの何パーセ ントか？（What percent of my salesmen have total ytd sales under $25000 ？） UNION：以下はUNION構成を要求するデータベースの例である： 製品名により分類されたニューヨークのセールスマンに対するコネチカットの セールスマンの今年から今日までの売上を示せ（Show ytd sales for Connectic ut salesmen compared to New York salesmen sorted by product name.） セールスマンにより分類された昨年のQ1売上と比較してQ1売上を示せ（Show Q 1 sales compared to last year Q1 sales sorted by salesman.） こうして、共通の情報要求が、この情報を必要とするビジネスマンの理解を遥 かに越えるような複雑なSQL を必要とする。 SQL の複雑性よりも大きい問題は、文法的に正しい問い合わせはしばしば誤っ た答えを生成することである。SQL は文脈自由（コン テックス フリー）な言語であり、バッカス・ノーマン・フォーム(BNF)により 完全に記載されることができるものであるか、又は文脈自由な文法である。しか しながら、多くの構造的には正しいSQL ステートメントが意味的には正しくない 答えを生み出すので、言語の構造を学習することは十分ではない。この問題は図 1A〜Ｇに示されるテーブルを有するデータベースを用いて幾つかの例により示さ れる。もしユーザがデータベースに以下のSQL 問い合わせで問い合わせると： 次の結果が生成される。 このレポートの第２のコラムは各顧客の全注文量を示しているように見える。 しかしながら、その数は正しくない。これに対し、以下の問い合わせ は次の正しい結果を有む。 両SQL は構造的には正しいが、２番目のもののみが全注文ドルの数を生成する 。この問題は、選択及び合計の機能を遂行する前に、SQL プロセッサはその問い 合わせ中のすべてのテーブル上でクロスプロダクトジョインを遂行するという事 実から生じる。第１の問い合わせにおいて、次の３つのテーブルが使用されてい る：Customer（顧客データを伴う顧客リスト）；Order（ドル量を伴う注文のリ スト）；及びLine item(注文上の個々ラインアイテム)。注文テーブルは全体の ドルを有し、各注文に対して複数のラインアイテムがあるので、SQL プロセッサ のジョイニングスキームはラインアイテムの各場合の注文に対する全体のドルを 含む分離したレコードを生成する。Customerにより合計されると、これは正しく ない結果を生成する。Line item テーブルが問い合わせに含まれていない場合、 適正な結果が得られる。ユーザがデータベースが設計されている方法とSQL がそ の問い合わせ動作を遂行する方法とを理解していない限 り、ユーザはこのタイプのエラーが結果に生じるか生じないかを確信することが できない。問い合わせか２つより多いテーブルを利用するときはいつでも、この タイプのエラーが起こり得る。 大部分の情報システムのユーザは、２つの異なる結果の集合を生じるようなデ ータベース問い合わせツールを使用することを躊躇する。なぜならそれらに対す るものは同一の情報要求（即ち、各顧客に対する全体の注文ドル）であるからで ある。実際には、すべてのデータベース問い合わせツールはこの欠点を持つ。 この問題のより正式なステートメントは、情報システムのために受け入れ可能 なSQL ステートメントの集合がSQL におけるステートメントの集合よりはるかに 小さいことである。ステートメントのこのより小さい集合は文脈自由な文法とし て殆ど定義できない。 II．POINT-AND-SHOOT QUERY TOOLS 多くのSQL ゼネレータ製品は“ポインアンドシュート”(point and shoot)問 い合わせ器具である。このクラスの製品は使用者に対して使用者に一連のポイン トアンドシュートメニュー選択を提供することによって、直接SQL ステートメン トに入る必要性をなくする。使用者の選択に応じて、ポインアンドシュートメニ ュー問い合わせ器具がSQL ステートメントを生成し、それを実行しそしてその結 果を使用者に示し、使用者からSQL の複雑性をかばうように見せる。この製品の クラスの例はマイクロソフトアクセス、Gupata's Quest，Borland's Paradox 及 びOracle's Data Query を含んでいる。 かかる製品は使用者をSQL 構文から保護されているけれども、その製品は単な るSQL 問い合わせを制限するかもしくは使用者にその複雑なSQL 構成の背後にあ る理論を理解することを要求する。さらに、上に論じた前後関係無用のSQL 文法 を目標とするから、使用者が正しくない解答を得ることも容易であり一般である 。以下にポイ ントアンドシュート問い合わせ器具についてこの種の代表的な一般の２，３の問 い合わせ器具に類似した一般のインターフェースを示す数種の例について述べる 。図2Aのスクリーンは使用者がピックリストの中から図1Aのカスタマテーブルを 選択した後を示す。このスクリーンは選択されたテーブルと、他の３つのボック ス、SELECT，WHERE 及びORDER BYに対する１つを示す。もしも使用者が“Fields ”ボックスもしくは“Sort Order”ホックスを選んだときはカスタマテーブルに おけるフィールドのリストがあらわれる。使用者は“Fields”及び“Sort Order ”ボックスが満たされるように選択する。この例においては使用者はNEME，STAT E 及びBALANCE フィールドが表示されるように選択しNAME及びSTATE によって分 類する。これが図2Bのスクリーンを生成する。 いつでも使用者は図2Cのように生成されたSQL ステートメントを見るように選 択できる。使用者の選択と発生するSQL との間には１対１の対応がある。編集さ れたSQL ステートメントのWHERE クローズを満たすために、使用者は“Conditio n”ボックスを選択し、図2Dの対話ボックスを満たしcondition に入る。これは 図2Eに示す複雑な問い合わせ設計を生成する。そこで使用者はOKボタンを押して 問い合わせに入り図2Fに示す結果を得る。 単一テーブルに対する単なるSELECT，WHERE 及びORDER BYを含む問い合わせに 対しては、使用者はSQL を知ることなしにまたは生成されたSQL を見ることなし に容易にSQL ステートメントを生成し実行することができる。 不幸にも使用者の問い合わせのごく少部分のみがこの単一である場合には、多 くのデータベースの問い合わせはさらに複雑なSQL を含む。この点を説明するた めには、上の例と同じ情報を見たいが回復した情報が80,000＄以上のすべてのセ ールスマンの未払の収支を もったセールスマンのカスタマに回復できるデータに限定して考える。もし使用 者がこの問い合わせが２つの付加的なSQL クローズ（GROUP BYクローズ及びHAVI NGクローズ）を必要とするならば、問い合わせ（図2Gに示す）は容易に構成され る。しかし小数の使用者はSQL をそうすることは充分に理解している。 多くのポイントアンドシュート問い合わせ器具は副問い合わせCREATEVIEW及び UNION のごとく他の複雑なSQL 構成は取扱いできない。使用者にとって他の構成 を生成する（直接にSQL ステートメントに入る以外に）ことは提供されない。他 の複雑な構成を発生する方法を提供するこれらの生成物使用者に“Subquery”も しくは“UNION”もしくは“CREATE VIEW”釦を押すことを要求する。勿論充分に 如何にして充分に問い合わせを副問い合わせにする関係計算を熟知しているか他 の複雑なSQL 構成を使用するユーザのみが正しく釦を押すことを知っている。 他の困難性はデータが１つ以上のテーブルから来る場合に遭遇する。図2Hに示 すように、使用者はどうしてテーブルを一緒に結合するかを指定することを要求 される。典型的な使用者の問い合わせは少くとも３つのテーブルを含む。テーブ ルを一緒にするときの発生する問題はつぎのごとくである。 テーブルを一緒にするに用いる列が同じ名を持たない、 ２つのテーブル間の適合な接合が多重の列を含む、 ２つのテーブルを接合する２つの方法がある、 ２つのテーブルを直接接合する１つの方法が存在しない、したがって問い合わ せには直接用いられない他の方法を通じて行なう必要がある。 要するに、ポイントアンドシュート問い合わせ器具は使用者を構造的誤りから 防ぐが使用者がSQL 理論を理解することがまだ必要と される。point-and-shoot メニュー製品の他の臨界的な制限はすでに述へたよう に関連不用のSQL 語を目標とすることである。全注文ドルを探索する使用者は上 に述べた正しいSQL ステートメント（４）としての誤りのSQL ステートメント（ ３）を発生することができる。かくしてこれらの製品は構造的に正しいSQL を発 生することができるが意味的に正しいSQL である必要はない。単に関連計算に熟 知している使用者のみ構造的にも意味的にも正しいSQL を発生させる選択を確保 することができる。しかし多くの情報系の使用者は関連的な計算を知らない。さ らに問い合わせが接合を必要とすることから誤りを発生する数々の方法があり、 これがまた結果的には正しいフォーマットをもつが誤った答をもつことにもなる 。 III．自然語問い合わせ器具 自然語製品は使用者をSQL の複雑性から保護するために種々のアプローチを使 用する。自然語製品は使用者に会話英語もしくは他の自然語で情報に対する要求 をすることを可能にする。自然語製品は入力の意味を推論するために第１のメカ ニズムを、入力の意味に対応するデータベース素子を示すために第２のメカニズ ムをSQL を発生するために第３のメカニズムを使用する。 自然語製品の例はNatural Language Inc．からNatural Language及びIntellig ent Business SystemsからのEasy talk（U．S．Patent No．5,197,005 Shwartz et al に開示される）を用いる。 図3Aは自然語問い合わせ方式に対するサンプルスクリーンを示し、使用者問い 合わせ、答、他のSQL の問い合わせ要求及びSQL を示している。 相互作用の系列はつぎのごとくである。 （１）英語問い合わせからは関係のない使用者のタイプ（先月の５つの最も共 通な欠点は何か？） （２）ソフトウェアが問い合わせを書き換えて使用者がその正確さを証明する （June，1991に最も発生した５つの欠点は何か？） （３）スペリングエラーがあったか、または使用者の問い合わせがあるあいま いさを含むか、ソフトウェアが使用者と問い合わせを明らかにしたか（以上の例 においては必要がない） （４）ソフトウェアが結果を表示する。 自然語問い合わせ具の魅力は使用者がその情報を自分の言語で要求として表わ すことができることである。しかし２，３の欠点をこうむる。第１に、使用者が 入力した問い合わせの一部に対してのみ正しい答をあたえることである。ある場 合には、使用者が問い合わせを再構成するために書換えることが容易である、し かし使用者はシステムが受け入れる方式を失敗させることがありうる。第２に、 それは装置にすることが困難である、適用に数ヶ月を必要とし、しばしば自然語 の売り手からのコンサルトサービスを必要とする。最大の設置障害は同義語の莫 大な数及び他の言語の構成が自由な形の入力に接近するために入力することであ る。 妥協案として、多くの自然語の売り手は、設置の間は、特殊の問い合わせをコ ードして使用者に質問リストを介して行うことを勧めている。例えば図3Bはあら かじめ定義された問い合わせはリストを含む単一スクリーンを示している。使用 者はリストから直接問い合わせをすすめるか、それをすすめる前に問い合わせに 僅かの変更をすることを選択できる。勿論、問い合わせを変えれば変えるほど自 然語方式は問い合わせを理解できなくなるように思われる。 操作自然語製品の説明のために、Schwartz，et al の開示した自然語方式の構 成が例として用いられる。この方式の構成を図４に示す。Meaning Representati onはSchwartz et alの焦点である。問い合わせMeaning Representationは使用者 の問い合わせの意味を維持 するために設計される、問い合わせあらわすに用いる語（及び言語）及びデータ ベースの構成とは独立に設計される。 同じMeaning Representationは使用者が“Show total ytd sales for each cu stomer？”“What were the sales to each of my client's this year to date ? あるいは“Montrez les vendes……”（仏語）を言うかどうかを生成しなけ ればならない。さらに、同じMeaning Representationは（１）データベースのカ ストマフィールドにytd sales を維持するフィールドがあること、（２）各個々 のオーダーが探索され、分類され、そして各カスタマに対してytd sales を計算 合計することもしくは（３）カスタマによるytd sales が簡単でデータベースに 利用できないかどうかを生成しなければならない。 この構成に対する最初の道理は単一の基準形式の中にどちらか１つを選ぶべき 使用者の問い合わせのmany-to-one mapping をそなえることである。多くの干渉 規則が辞書レベルにおける使用者の問い合わせを処理するに必要であるよりも基 準形式を処理するに必要となる。この概略はSchwartz，“Applied Natural Lang uge”，1987に詳細に述べられている。 NLI（National Language Interface）は自然語問い合わせをMeaning Represen tationに変換するに対応している。Query Analyzerそれ自体は問い合わせの構造 ・意味解析、スペリングコレクション、代名詞的な基準、省略解答、あいまいな 解答に対する処理、公称データの処理、データ及び時間基準の解答、使用者を明 白な対話及び多くの他の機能に引き入れる可能性を含んでいる。一旦最初のMean ing Representationが発生すると、Context Expert System はそれを解析してプ ロノミナル・レフェレンツ、インターセンテンシャル・レファレンツを満たして 問い合わせの他の省略素子を解決する。 この問題の詳細な点についてはS．Shwartz参照のこと。 問い合わせは“Show ytd sales dollars sorted by salesrep and customer” に対するMeaning Representationは SALES：TIME（YTD）；DOLLARS，TOTAL SALESMAN：SORT（１） CUSTOMER：SORT（２） 再びこのmeaning representationは実際のデータベースとは無関係である。Da tabase Expert はこのmeaning representationをとってその実際のデータベース 構造を解析し、meaning representationの最も適合したデータベース素子に配置 してRetrieval Specification を生成する。total ytd sales dollars，YTD＿SA LES をもつ列を含むテーブルCUSTOMERS を有するデータベースに対しては、Retr ieval Specification は COSTOMER．YTD＿SALES SALESMAN NAME：SORT（１） CUSTOMER NAME：SORT（２） もしYTD＿SALES 列が異なるテーブルか、図が詳細なオーダーレコードから計 算されなければならない時はRetrieval Specification は異なるであろう。 NLI(及びContext Expert)及びDBESの機能は単独に必要である。なぜなら自由 型式の言語入力が正式とは反対に許されるからである。もしも正式、文脈自由の 命令が自由型式の自然語よりも用いられたら、上記処理の何れも要求されないで あろう。Retrieval Specification は正式の文脈自由の指令語に等価である。 Navigator はRetrieval Specification に関連するテーブルに最小のスパンを 見出すために標準グラフ理論アルゴリズムを用いる。これはテーブルに対してジ ョインパスを定義する。MQL Generator はそこでMQL と呼ばれるDBMS−独立問い合わせ語に問い合わせを構成する。SQL Generator モジュールはそこでMQL をDBMS−specific SQLに翻訳する。単に構造 的に意義的に有効なSQL を生成することを保証するに必要な達識のすべてはMQL Generator モジュールの必要な部分である。システムが構造的に意義的に有効な SQL を発生することかできないときはRetrieval Specification を拒否するのは このモジュールの責任である。 IV．自然言語メニューシステム（Natural Language Menu System） 自然言語メニューシステムは、ポイント・アンド・シュート(Point-and-shoot )方式による問い合わせツールと自然言語問い合わせツールとの折衷(Cross)であ る。さらに、この自然言語メニューシステムは、メニュー・インターフェースと 特殊なタイプの自然言語プロセッサとを一組にする。この場合、自由形式の自然 言語をユーザに入力させる代わりに、形式的な問い合わせ言語を規定するような 文脈自由文法（Context-free Grammer）が作成される。しかしながら、この形式 的な問い合わせ言語においては、ユーザは、コマンド・インターフェースを通し て問い合わせを入力する代わりに、一回につき一つの語に対して問い合わせを作 成する。上記の文法は、文章における全ての可能な第１番目の語を決定するため に使用される。ユーザは、作成されたリストから一つの語を選定する。さらに、 上記の文法は、文章における全ての可能な第２番目の語を決定するために使用さ れる。このような処理は、一つの完全な文章が作成されるまで続行する。 自然言語メニューシステムは、当該ユーザのみが、サブ言語において構造的に 有効な文章を生成するのを保証する手段を提供するであろう。しかしながら、こ れらの文章は、同文章の全てが意味論的に有効であるようなサブ言語の部類に対 して意味論的に有効であり 得ることが保証されるのみである。このような部類のツールに関する他の不都合 な点は、同ツールが、コンピュータによるデータベースの問い合わせに対して不 適切であることである。文法を実行するために必然的に要求されるリカーシィブ ・アルゴリズム(Recursive Algorithm)についてのコンピュータによる要求は莫 大なものでなる。さらに、サブ問い合わせを支持する上で上記の文法が充分であ るためには、この文法は、コンピュータによる負担に加えて、おそらく巡回式の 文法（Cyclic Grammar）にすることが必要になるであろう。最終的に、直接的な 選択手順でもってユーザを制限するという概念は、現代のグラフィック形のユー ザ・インタフェースに関する一般の約束ごととは両立しない。換言すれば、デー タベースの問い合わせの際に上記タイプのインタフェースを備えているユーザは 、一つの問い合わせに対して最初の語でもって強制的に始められ、この問い合わ せの最後の語まで連続的に続行することに異議を唱えるであろう。上記ユーザは 、一切のバックアップを必要とせずに一つの問い合わせの最中に複数の語を付加 することが可能になることを要求すると共に、さまざまな順番で複数の節を入れ ることが可能になることを要求する。発明の要約 従来技術の問題点は、検索可能な情報の範囲を制限することなく、SQL の複雑 性をユーザに見えないようにすることが可能な本発明のシステム及び方法によっ て解決される。本発明のシステム及び方法の中で最も重要な点は、間違った結果 が取り消され得ることである。 本発明の原理に従えば、ユーザに対し構造的にも意味論的にも有効な問い合わ せのみ（及び、意味論的に有効なSQL を作成する目的 でSQL 生成ルーチン(SQL Generator)により処理され得る問い合わせも含む）を 入れることを可能にするような問い合わせアシスタント(Query Assistant)が設 けられる。上記ユーザは、問い合わせアシスタントを介して入れた問い合わせを 言い替えることは決してしない。上記ユーザは、対話形式のボックスを使用する ことによって、同ユーザが容易に理解し得るような英語形式の中間言語にて問い 合わせを入れる。問い合わせエキスパート・システムは、一つの問い合わせが確 立される際に当該問い合わせを監視する。さらに、上記の問い合わせエキスパー ト・システムは、データベースの構造に関する情報を使用して、意味論的に間違 った問い合わせが確立されるのを阻止する。このような問い合わせエキスパート ・システムの機能は、間違った問い合わせが作成されるような対話形式のボック スの選択を不許可にすることによって遂行される。さらに、上記中間言語を、構 造的にも意味論的にも正しいSQL 問い合わせに変換するために、一揃いの変形及 びパターン置き換えを使用するようなSQL 生成ルーチンが設けられる。 上記中間言語は、同時に理解し易い形式でもって複雑なSQL 問い合わせを表示 する。上記中間言語はまた、容易にSQL 問い合わせに変換されるように設計され る。ユーザがデータベースに対する問い合わせを容易に行えるようにするために 、問い合わせアシスタントやSQL 生成ルーチンの他に、基本となるデータベース に対し管理部(Administrator)が概念的レイヤ（Conceptual Layer）を付加する ことを可能にするような管理機能が設けられる。このような概念的レイヤには、 列（Column）やテーブルに対する選択的な名前、パスを特定するための基準や複 雑な結合、仮想テーブルや仮想テーブル用の定義、及び、ユーザのアクセスに対 する制限が含まれ得る。図面の簡単な説明 図1A〜1Gは、明細書中に示される幾つかの例に使用される標本的なデータベー スのテーブルである。 図2A〜1Hは、ポイント・アンド・シュート方式による問い合わせツールに関す る典型的な画面表示の状態を示す図である。 図3Aは、自然言語問い合わせツールに関する典型的な画面表示の状態を示す図 である。 図3Bは、予め定義された複数の問い合わせに対し使用されるような自然言語デ ータベースによる問い合わせツールに関する典型的な画面表示の状態を示す図で ある。 図４は、自然言語問い合わせツールに関する高レベルのアーキテクチャを示す ブロック図である。 図５は、本発明による高レベルのアーキテクチャを示すブロック図である。 図６は、図1A〜1G中のテーブルの図形表示と、これらの図形表示の相互関係を 示す図である。 図７は、問い合わせアシスタントを示すブロック図である。 図８は、問い合わせアシスタントのユーザ・インタフェースの制御の流れを示 すフローチャートである。 図９は、ユーザ・インタフェースの初期状態の画面を示す図である。 図10Ａ〜10Ｇは、問い合わせアシスタントを用いた問い合わせを確立するため にユーザと相互作用を行う対話形式のボックスを示す図である。 図11Ａ及び11Ｂは、SQL 生成ルーチンの制御の流れを示すフローチャートであ る。詳細な説明 Ｉ．概説 図５は、本発明の原理を実施するためのインテリジェント・問い合わせシステ ムに係る高レベルのアーキテクチャを示すブロック図である。このブロック図は 、２つの部分、すなわち、問い合わせシステム１及び概念的レイヤ２により構成 される。前者の問い合わせシステム１は、データベース３から引き出される情報 からなる。この種の情報は、テーブルや列に関する情報、及び、より直観的なア クセスをユーザに提供するための管理部から入ってくる情報を含む。問い合わせ システム１は、意味論的にも正しい結果を生成すると考えられる複数の問い合わ せに対してのみ当該問い合わせを確立する点でユーザを制限するような問い合わ せを行うSQL やデータベースに関する一般的な知識だけでなく、概念的レイヤ２ から入ってくる情報も使用する。 問い合わせシステム１は、さらに、２つの主たる構成要素、すなわち、問い合 わせアシスタント10及びSQL 生成ルーチン20からなる。ユーザは、メニューに基 づいた問い合わせアシスタント10を作成する。この問い合わせアシスタント10は 、容易に理解することが可能な文の形式を有する問い合わせ用中間言語を用いて ステートメントを作成する。SQL 生成ルーチン20は、上記中間言語を目的言語( 本実施例では、SQL)に変換する。問い合わせを言い替える（または、再構築する ）ためにユーザが決して質問されることはないという必要条件を満足させるため に、何が有効なSQL 問い合わせであって何が有効なSQL 問い合わせでないかとい うことに関する専門的知識が、アシスタント10に備わっている。 SQL 生成ルーチン20は、この種の専門的知識を有していない。ユーザは、上記 SQL 生成ルーチン20に対して直接問い合わせを提示す ることができるけれども、意味論的に有効なSQL が作成されるという保証はない 。ただし、上記の専門的知識の幾つかをSQL 生成ルーチン20に取り入れることは 、論理的に可能である。しかしながら、ユーザに対し、有効なSQL のみが作成さ れ得ることを保証するためには、現在利用することが不可能な自然言語の能力が 必要になるであろう。 II．概念的レイヤ データベースは、一つまたは複数のテーブルから構成することが可能である。 この一つまたは複数のテーブルの各々は、一つまたは複数の列、及び、一つまた は複数の行(Row)を有している。この種のテーブルの例を次に示す。 上記の小さなテーブルの例においては、３つの列と３つの行を含む一つのテー ブルが挙げられている。最上部の行は、単に列の名称であり、データベース・テ ーブルにおける一つの行を考慮しているわけではない。ここで、「行」という用 語は、データベースの応用分野では同じように度々使用される「レコード（Reco rd）」という用語に置き換えることが可能である。また一方で、「列」という用 語は、「フィールド(Field)」という用語に置き換えることが可能である。これ ら２つの組の用語の基本的な差異は、リスト形態の一覧、または広げたシート状 のテーブルの形態を有する一覧によってデータが見られる場合に行及び列という 用語が度々使用される点と、一度に一つのレコードの単位からなる書式形態の一 覧によってデ ータが見られる場合にフィールド及びレコードの用語が使用される点との違いで ある。 データベースは、２つ以上のテーブルを具備することが可能である。この種の テーブルの簡単な例に対し、各人（Person）によって作成される購入品のリスト をまとめたパーチャス(Purchases)とよばれる別のテーブルが付加される。 ここでは、データベース内に含まれるテーブルに関する幾つかの構造情報が、 データベースと一緒に記憶される。テーブルの列の名称、及び、列に記憶される データの構造が２つ以上存在する場合、上記の構造情報は、複数のテーブルの名 称を含む。上記の２種のテーブルの例において、（この例を説明する目的で）第 １のテーブルには、「パーソン（Person）」という名称が付与されており、第２ のテーブルには、「パーチャス(Purchases)」という名称が付与されている。「 パーソン」という名称の第１のテーブルには、３つの列が存在する。すなわち、 英数字のデータを含む「ネーム（Name）」の列、２つの文字からなる英数字のデ ータを含む「ステート(State)」の列、及び、５つの文字からなる英数字のデー タまたは数字で表現したデータとして記憶され得る「ジップ(Zip)」の列が存在 する。さらに、「パーチャス」という名称の第２のテーブルにも、３つの列が存 在する。すなわち、英数字のデータを含む「ネーム」 の列、英数字のデータを含む「プロダクト(Product)」の列、及び、数字で表現 したデータを含む「クオンティティ（Quantity）」の列が存在する。 さらに、複数のテーブルの各々に対する主キー（Primary Keys）が、データベ ースと一緒に記憶される。大抵のデータベース・システムにおいては、各々の行 は、唯一無二に識別可能でなければならない。一つの列が上記主キーを生成する か、あるいは、複数の列が協働して上記主キーを生成する。この主キーは、複数 の列の内容が結合した場合でもテーブル内の各行を識別するようになっている。 前述の「パーソン」という名称のテーブルでは、各々の行における「ネーム」の 列は唯一無比である。したがって、この場合、「ネーム」は主キーの列になり得 る。しかしながら、「パーチャス」という名称のテーブルでは、複数のジョン（ John）とパット(Pat)が存在するので、「ネーム」によって各々の行を唯一無二 に識別することはできない。この種のテーブルでは、「ネーム」の列と「プロダ クト」の列とが一緒になって各々の行を識別することにより、協働して主キーを 生成する。 上記の例においては、２つのテーブル間で「ネーム」という名称の共通の列に 基づく暗黙の関係が存在する。バージニアン州民がオレンジを何個購入するかを 決定するために、ユーザは、「パーソン」という名称のテーブルを調べ、ジョン のみがバージニアン州民であることを見い出す。そして、上記ユーザは、「パー チャス」という名称のテーブルまで出向き、ジョンが４個のオレンジを購入した ことを見い出す。幾つかのデータベース管理者(Database Managers)は、あから さまに、それぞれ異なる名称を有する２つの列に対し上記の関係が存在するため の状況も含むような上記の関係に関する情報を記憶する。 前述の例は非常に単純である。それゆえに、ユーザは、データベースがどのよ うな情報を保持していたか、及び、これらの情報がどのように関係していたかを 容易に理解することができる。しかしながら、実社会の問題は、それほど単純で はない。図1A〜1Gに表示されたデータベースの例は、多くの実社会の問題の複雑 さに比べて幾分単純化されているけれども、データベース内に何が含まれている かをユーザが理解したり、同ユーザがどのようにして有意味な問い合わせを立案 したりするかが、いかに難しいことであるかを示すきっかけとなる。データベー スの実際の意味が、このデータベースを確立する際に使用される名称に関する一 般の約束ごとと相反するものである場合、ユーザの困難さは特に深刻になる。例 えば、図1Aのカスタマー・テーブル（Customer Table）、及び、図1Bのプロダク ト・テーブル(Product Table)は、両方共「ネーム」という名称の列を有してい るにもかかわらず、前者のカスタマー・テーブルは、後者のプロダクト・テーブ ルとは直接関係していない。しかしながら、これらの２つのテーブルは、「カス タマー（Customer）」→「オーダー(Order)」→「ライン アイテム(Line Item) 」←「プロダクト(Product)」のパスを介して関係している（すなわち、「カス タマー」は「オーダー」を有しており、「オーダー」は「ライン アイテム」を 有しており、そして、「ライン アイテム」は「プロダクト」を有している）。 基本となるデータベースの複雑性からユーザを保護するために、知識の豊富な 管理部は、概念的レイヤを定義することが可能である。この概念的レイヤには、 テーブルの名称とキー、及び、列の名称と種類からなる基本的なデータベースの 構造に加えて、外部キー（Foreign Keys）、名称の置き換え、テーブルと列の記 述、陰のテーブルと列(Hidden Tables and Columns)、及び、結合パスの定義と 非等価結合(Non-equijoins)も含まれ得る。 概念的レイヤを作り上げるための全ての形式の情報は、定義されたアイテムと して、データベースと並行して記憶される。さらに詳しくいえば、これらの情報 は、単純なテキスト・ファイル、上記の情報自体が有するデータベースの構造、 よりコンパクトな翻訳済みのフォーマット(Compiled Format)、または、他の類 似するタイプの情報記憶部に記憶される。データベースが問い合わせに対する処 理を行うように指定された場合、問い合わせアシスタント１は、基本的なデータ ベースの構造に対するアクセスを遂行する。このような基本的なデータベースの 構造は、ユーザが意味論的に正しい問い合わせを書式化するのを援助することを 目的として、データベース管理者が提供するものである。二者択一的に、上記ユ ーザは、拡張された一揃いの概念的情報を含むような選択をすることも可能であ る。この場合、問い合わせアシスタント１は、より直観的な問い合わせツールを エンド・ユーザ（End User）に提供するために、上記の拡張された一揃いの概念 的情報を使用することができる。 上記の概念的情報は、問い合わせシステム動作の期間中、この問い合わせシス テム内部の一揃いの記号テーブルに記憶される。問い合わせアシスタント10は、 管理部により指定される環境に適合するような一揃いの選択の対象をユーザに提 供するために、上記の概念的情報を使用する。さらに、SQL 生成ルーチン20は、 一続きの変換を介してSQL 問い合わせを作成するために、上記の概念的情報を使 用する。 Ａ．フォーリン・キー あるテーブルのフォーリン・キー(foreign key)は、これらが他のテーブルに どのように関連しているかを規定している。２つのテーブルは、第１のテーブル のフォーリン・キーを第２のテーブルの プライマリ・キー(primary key)にマッピングすることによって結合される。第 １のテーブルのフォーリン・キーは、当該フォーリン・キーを形成するコラムと 、第２のテーブルのプライマリ・キーを第１のテーブルのフォーリン・キーとマ ッチングさせることによって第１のテーブルと結合することができる第２のテー ブルの名前とによって規定される。 上記の例において、フォーリン・キー「名前（Name）」をもつ購入品(Purchas es)テーブルは、ブライマリ・キー「名前（Name）」をもつ人（Person）テーブ ルと結合され得る。 もし２つのテーブルがそれぞれのフォーリン・キー及びプライマリ・キーに基 づいて結合されたならば、以下のような新しいテーブルが作成される。 この新しいテーブルを作成するために、各々の「名前」コラムにおいて同じ値 をもつ２つのテーブルの各々からのロウが組み合わせられている。これを１対多 (One-to-Many)関係と称する。一つの人 ロウ毎にそれぞれ多くの購入品ロウがある。また、一つのテーブルの各ロウ毎に それぞれ別のテーブルに関連した一つのロウのみが規定されていることを指示す る１対１（One-to-One）関係であってもよい。１対多関係及び１対１関係は、オ プショナルであってもよい。もしオプショナルであったならば、第２のテーブル において関連したロウがなくてもよい。図示の実施例では、概念層におけるフォ ーリン・キーに従って、アドミニストレータは、フォーリン・キーによって結合 されたテーブル間にこれら４つのタイプの関係（１対多関係、オプショナルの１ 対多関係、１対１関係、オプショナルの１対１関係）のうちいずれが存在するか を指定することができる。ある種のデータベース管理システムでは、テーブルが プライマリ・キーを多重的にもつことができるものである。この場合、アドミニ ストレータは、いずれのプライマリ・キーにフォーリン・キーが結合されるべき かを指定しなければならない。 図６は、図1A〜図1Gにおける各テーブル間の関係を示したものである。各線は ２つのテーブル間の関係を表し、各線の終端の矢印はオプショナルの１対多関係 を示している。例えばSALESPEOPLE テーブルとCUSTOMERS テーブルの間には、各 セールスマンによって扱われた多くの顧客をもつ１対多関係がある。図1A〜図1G の各テーブル例と図６に例示する関係を用いると、各フォーリン・キーに対する 概念層の定義は以下のようになるであろう。 上記の表は、概念層に存在するかも知れないフォーリン・キーデータを表して いる。この表は一例として記載されている。表の見出しの下の１番目のロウによ れば、SALESPERSON#コラムにより定義されるフォーリン・キーをもつCUSTOMERS テーブルがある。このフォーリン・キーは、オプショナルの１対多関係によるSA LESPEOPLE テーブルの１番目のプライマリ・キー（Primary key コラムの「１」 ）に関連する。言い換えると、SALESPEOPLE テーブルの各ロウ毎に、SALESPERSO N#に従うCUSTOMERS テーブルにおいて０又はそれ以上の関連するロウがある。 図６においてCODES テーブルとPRODUCTSテーブルの間並びにVENDORS テーブル とPR0DUCTSテーブルの間の各線の傍にあるは、当該テーブル間に２つの１対多 関係があることを示している。これは、上記のフォーリン・キーの表において見 ることができる。PRODUCTSからVENDORS へ結合するフォーリン・キーと、PRODUC TSからCODESへ結合するフォーリン・キーの２組がある。 Ｂ．名前の置き換え 名前の置き換えは、データベース構造において定義されているよ うなテーブルの名前もしくはコラムの名前をユーザに呈示するためのより直観的 な別の名前と置き換える処理である。これは、限られたネーミング能力（すなわ ち一つのワードのみ）を提供するにすぎないデータベース管理システムを取り扱 う時に、特に有用である。この処理は主として２つの目的をもっている。第１に 、アドミニストレータに対して、より理解し易い任意のデータベースでユーザが 情報を入手し易いようにさせることである。第２に、同じ名前をもっているが関 連していない（例えば、図1AのCUSTOMERS テーブルの「名前」コラムと図1BのPR ODUCTSテーブルの「名前」コラムのように）異なるテーブルから各コラムを識別 するのに当該処理を用いることができるようにすることである。さらに、各テー ブルに対して複数の名前及び単一の名前を与えることができる。 例えば、図1Aのテーブルを用いると、当該テーブルに対して単一の名前及び複 数の名前をCUSTOMER及びCUSTOMERS としてそれぞれ定義することができると共に 、以下のようにユーザに対してより案内を行い易く且つ衝突を識別するためのフ ィールドを新たに命名することができる。 Ｃ．テーブル及びコラムの記述 種々のテーブル及びコラムの記述は、ユーザにとって理解し易くするために概 念層に含ませることができる。例えば、CUSTOMERテーブルは、「当社の顧客に関 するアドレス及び信用情報を含む記録」といった関連する記述を有していてもよ い。この場合、ユーザが問い合わせ中にそのCUSTOMERテーブルを選択すると、そ の記述がユーザインタフェース又は類似の装置のステータスライン上に現れるで あろう。同じタイプの情報は、問い合わせ中に使用するかも知れないコラムが選 択された時に各コラム毎に格納され得る。 Ｄ．隠されたテーブル及びコラム データベースの設計において、データベーステーブルを関連付ける際に重要で あるがそのデータベース上で問い合わせを行おうとしている末端のユーザによっ て使用されないようなコラムを追加することは、時折必要となる。例えば、図1A 、図1D及び図1Eにおける各テーブルのSALESPERSON#コラムは、Paul Williams が 、American Butcher Block／Barn Door Furniture のセールスマンであることを 知りさえすれば十分である末端のユーザにとっては重要ではない。末端のユーザ は、容易にテーブルを関連付けるのに用いるための自己の内部数が１であること を知る必要はない。従って、概念層の一部として、アドミニストレータは幾つか のコラムを隠しそれによってユーザが問い合わせを行う際に当該コラムを表示し たり或いは使用することができないようにすることができる。あるコラムが隠さ れても、それは依然として別のテーブルと結合するのに用いることができる。こ の同じ技術は、末端のユーザがプライベートなデータ又は保護されたデータを表 示するのを防止するのに用いることができ、また、困惑させたり或いは不必要で あるかも知れないデータベースの詳細からユーザを保護するのに用いることがで きる。 場合によっては、他のテーブルを一緒に結合するのに用いられる テーブル或いは末端のユーザにとって重要でないテーブルが存在する。従って、 概念層の一部として、アドミニストレータは幾つかのテーブルを隠しそれによっ てユーザが問い合わせを行う際に当該テーブルを表示したり或いは使用すること ができないようにすることができる。しかしながら、隠されたテーブルは、問い 合わせシステムによって実際に問い合わせを行うのに用いることができる。それ は、末端のユーザから隠された詳細な層にすぎない。さらに、以下に詳細に記載 されるように、仮想コラム／テーブル技術が用いられると、コラムは、末端のユ ーザに対する表示のために、他のテーブルの要素として含まれることができる。 元のコラム及び／又はテーブルを隠すことによって、アドミニストレータは、実 際において任意のコラムを一つのテーブルから別のテーブルへ移動させることが できる。 ユーザが語義的に正しい問い合わせを行う際に含ませることができる要素が指 定されると、問い合わせアシスタントはその隠されたテーブル及びコラムを指定 する必要はないであろう。 Ｅ．仮想テーブル 仮想テーブルは、ユーザに対し、分離したデータベーステーブルとして現れる 構成概念である。仮想テーブルは、アドミニストレータによって、特定の条件に 合うロウに限定されたデータベーステーブルのサブセットとして定義される。先 ず、仮想テーブルは、その基となっている実際のテーブルに含まれる全てのフィ ールドをもっているが、記録されたサブセットのみを包含する。例えば、アドミ ニストレータは、ステータスフィールドが文字「Ｂ」を包含しているORDERSテー ブルから全ての記録を含む仮想テーブルBACKORDERSを定義することができるであ ろう。そして、ユーザがそのBACKORDERSテーブルに対して問い合わせを行うと、 ユーザはバックオーダース テータスをもつそれらのオーダーにアクセスするのみとなるであろう。 アドミニストレータは、目標言語(この場合SQL)の条件節に従って仮想テーブ ルを定義する。上記の例において、BACKORDERSテーブルは“ORDERS WHERE ORDER S．STATUS ＝‘Ｂ’”として定義されるであろう。このようにして、仮想テーブ ルのSQL 発生部分は単純なテキストの置き換えによって達成される。同様に、当 該条件は、SQL 又は他の目標言語の条件と等価な内部表現形式で格納され得るで あろう。 条件節が無くても仮想テーブルを定義することは可能である。その場合、仮想 テーブルの基となっているテーブルの複写が用いられる。しかしながら、アドミ ニストレータは、コラムを仮想テーブルの基となっているテーブルから隠し、仮 想コラムを仮想テーブルに付加してそれに明確な特性を与えることができる。例 えば、仮想テーブルを元のテーブルに基づいて作成しコラムの半分を元のテーブ ル内に隠しコラムの残りの半分を仮想テーブル内に隠すことで、単一のテーブル を末端のユーザが使用できるように２つに分割することができるであろう。 Ｆ．仮想コラム 概念層は、仮想コラムに対する定義を含むこともできる。仮想コラムは、ユー ザにはテーブルの実際のコラムであるように見える新しいコラムである。データ を含む代わりに、仮想コラムが包含している値は、問い合わせが行われる時に算 出される。計算を行うフィールドあるいはコラムを他のテーブルに付加するフィ ールドを付加することができる。仮想コラムについては６つの主な使用形態があ る。 （１）一つのテーブルから別のテーブルへの項目の移動／複写。 種々のデータベース設計の要因に起因して、ユーザの概念モデルにおけるテーブ ルよりも多くのテーブルが物理的データベースに存在することがある。図1A〜図 1Gの例において、末端のユーザは、オーダーをLINE ITEM，ORDERで要求されてい るような多重テーブルにおける多重ロウとして考慮していないかも知れないであ ろう。アドミニストレータは、ユーザはオーダーテーブルの一部としてLINE ITE M のフィールド（すなわち、製品、オーダーされた量、バックオーダーされた量 、倉庫等）を見るべきであることを概念層で特定することができる。コラムがそ こから移動されようとしているテーブルとコラムがそこへ移動されようとしてい るテーブルとの間にプライマリ・キー／フォーリン・キーの関係が存在するとい う限定を１回だけ行うことで、コラムを一つのテーブルから別のテーブルへ移動 させることができる。これらの関係は図６において矢印の付いた線として示され ている。 （２）計算によって定義された仮想コラムの作成。仮想コラムは、アドミニス トレータによって、テーブル内にあるコラムに対して計算を行うことにより作成 することができる。例えば、図1Fにおいて“SHIP DATE ORDER DATE”として定義 されるORDERSテーブルにTURNAROUNDコラムを付加することができる。これによっ てユーザは、オーダーに対するターンアラウンド時間がどのくらいであるかを示 すよう要求した問い合わせを、その問い合わせの計算を実現に特定する必要もな く容易に作成することができるようになるであろう。 （３）DBMS特定機能を用いて定義された仮想コラムの作成。使用されているデ ータベース管理システム（DBMS）の目標とする言語は、特別な方法でユーザに情 報を提供するのに使用され得るであろう特定のフォーマット又は他のデータ処理 操作をもっていてもよい。たとえSQL ジェネレータがSQL を生成するよう設計さ れていたとし ても、SQL の実施態様はDBMSとは異なる。 ルックアップ（Lookup）機能の付加により、他のテーブルからのコラム或いは 同じテーブルのコラムを付加するために明確な結合を定義することができる。ル ックアップ機能は、仮想コラムを定義するのに用いることができ、パラメータと して、フォーリン・キーコラム（これは、当該仮想コラムが置かれようとしてい るテーブル、あるいはそれが仮想テーブルならばベーステーブル、に対するフォ ーリン・キーコラムである。）と、参照コラム（これは、フォーリン・キーが参 照しようとするテーブル内のコラムである。）をもっている。残りの３つの使用 形態は、現問い合わせシステムによって向けられていない複雑性を回避するため にこの機能を用いるものである。 （４）代替のフォーリン・キーによってひきおこされる複雑性の除去。テーブ ルは、代替のフォーリン・キーによって表される多重の結合方法をもつことがあ る。これはユーザにとって混同の原因となり得る。例えば、図1A〜図1Gのテーブ ルを用いると、PRODUCT テーブル（図1B）は２つのフォーリン・キー、VENDOR# 及びALT VENDOR# をもっている。データベースをアクセスする際にユーザを助け るために、アドミニストレータは、VENDORの名前とALT VENDORの名前に対してPR ODUCT テーブル内で仮想コラムを定義するであろう。これによってユーザは、多 重テーブル内で情報を捜し出すといった方法をとることなくVENDORの名前を容易 に見つけ出すことができるようになる。しかしながら、これは概して問い合わせ システムを混同させることになる。なぜならば、テーブルを結合するのに２つの フォーリン・キーが用いられているからである。VENDORの名前の仮想コラムとAL T VENDORの名前の仮想コラムの各々に対してルックアップ機能を用いることによ り、ユーザに売主の名前と代替の売主の 名前を与える一方で各コラムに対して異なるフォーリン・キーの結合を特定する ことができる。仮想コラムの定義は以下のようになるであろう。 （５）コードテーブルによってひきおこされる複雑性の除去。これは、上述し た（４）代替のフォーリン・キーの場合の特別な場合である。多くのデータベー スはコードテーブルをもっており、その目的は、名前と幾つかのコードの各々に ついての情報を格納することである。テーブルはそれ自体、コード識別情報を包 含しているにすぎない。もし単一のテーブルがコードに関する情報に対して同じ テーブルを使用する多重コードコラムを有しているならば、代替のフォーリン・ キーに関わる問題を含んでいる可能性がある。よって、ユーザは、“status id ＝‘007’，type id ＝‘002’”で製品を要求する代わりに、“status＝‘open ’，type＝‘wholesale’”で製品を要求することになるであろう。ルックアッ プ方法を用いると、テキストのステータス及びタイプに対して２つの仮想コラム を製品テーブルに付加することができる。 （６）自己参照テーブルによってひきおこされる複雑性の除去。例えば、従業 員テーブルにおいて各従業員は、自分自身が従業員である管理者をもっているか も知れない。管理者コラムは従業員テーブルを再び参照する。ルックアップ機能 を用いると、各従業員、管理者、名前、給料等に対する仮想コラムは、従業員テ ーブルに付加され得る。実際に問い合わせを行うためには自己結合が要求される であろう。EMP と命名されるテーブルとそのEMP テーブルに関連するフォーリン ・キーであるMGR コラムとに対して従業員テーブルの例を用いると、仮想コラム の定義は以下のようになる。 Ｇ．結合経路定義（Join path definition） ある状況において、複数の経路を通して２つのテーブルを結合することが可能 である。例えば、図1A〜1Gに示すテーブルでは、「SALESPEOPLE」テーブルは２ つの異なる経路を通して「ORDERS」テーブルと結合できる。これは図６中に簡単 に見られる。矢印の方向に従って、「SALESPEOPLE」は直接「ORDERS」に接続さ れるか、又は、それらは「CUSTOMERS」を経由して「ORDERS」に接続することが できる。データベースの問い合わせでは、結合が達成される方法は、異なる意味 と共に異なる結果を生み出す。 （１）もし、「SALESPEOPLE」が直接に「ORDERS」テーブルと結合されると、 その結果は、どの販売員がオーダを処理したかを表示するであろう。 （２）もし、「SALESPEOPLE」が「CUSTOMERS」を経由して「ORDERS」と結合さ れると、その結果は、オーダをした客に対する現在の販売員が表示されるであろ う。 アドミニストレータ(Administrator)は、もし必要であれば、概念的レイヤー に、各対のテーブルに対する１組の結合経路を加えることができる。もし、複数 の結合経路が定義されれば、各結合のテキスト記述が更に含まれる。問い合わせ が発生すると、システムは、ユーザに、容易に理解できる方法で、ユーザが結合 のどのタイプ を選ぶかを促す。上述の例では、ユーザが「SALESPEOPLE」と「ORDERS」テーブ ルを結合する問い合わせを発生すると、問い合わせアシスタント(Quety Assista nt)は以下のダイアログボックスを生成する。 ここで、選択にあるテキストはアドミニストレータにより定義され、システム により取られ使用された結合経路と関連付けられる。 もし、与えられた１対のテーブルに対する結合経路が定義されていなければ、 問い合わせが生じた時、最短経路がシステムにより使用される。これは、ミニマ ル・スパニング・トリー・アルゴリズム（minimal spaning tree algolithm）又 は、同様な周知の技術を使用することにより決定できる。 Ｈ．非等結合（Non-equijoins） 先行する例により説明したテーブル結合は、等しく結合されてきた。これらは 、各テーブルのカラムでの値が等しいこと（即ち、SALESPERSON#＝SALESPERSON# 、但し、カラム名は同一である必要はない。）に基づいて、２つのテーブルが一 緒に組み合わせ又は結合されることから、等結合(equijoins)と呼ばれる。図示 した例では、アドミニストレータは、更に、概念的レイヤーの中に、特定の条件 が満たされたときに、２つの異なるテーブルからの行を結合するであろうテーブ ル間の非等結合関に対する定義を供給する。例えば、他の「ORDTYPE」テーブル は、異なる範囲でドル総計のオーダの異 なる分類を供給する、図1A〜1Gの例に加えることができる。 非等結合を使用して、「ORDERS」テーブルからのレコードは、ORDER＿DOLLARS ＜＝LOW(「ORDTYPE」テーブルからの）＜＝HIGHであるとき、「ORDTYPE」テー ブルからのレコードと結合することができる。等しい関係に代えて、値の範囲に 基づく関係がある。 アドミニストレータは、非等結合をSQL 条件としてレコードする。上記の例に 対しては、アドミニストレータは、「ORDERS」は、ORDTYPE(ここで、ORDERS．OR DER＿DOLLARS＞＝ORDTYPR．Low AND ORDERS，ORDER＿DOLLARE ＜ORDTYPE．High) と結合されるべきであるということを特定する。非等結合を特定するための処理 は、正しさを保証するために問い合わせアシスタント（Query Assistant）10と 同様な方法で実行されるということも明らかになるであろう。その条件は、中間 言語から目的言語SQL への変換の間に直接使用されるように、SQL にストアされ る。しかしながら、作業者（artisan）にとっては、その条件は、SQL 条件又は 他の目的言語と等価な内部表現にストアされることは明らかである。 III．問い合わせアシスタント（QUERY ASSISTANT） 図７は、問い合わせアシスタント（Query Assistant）10のブロック図を示す 。これは、問い合わせアシスタント・ユーザ・インターフェース（Query Assist ant User Interface）（QUAI）11と、問い合わせアシスタント・エキスパート・ システム（Query Assistant Expert system）（QAES）12の２つの要素を具備す る。QAUI11は、ユーザに対する問い合わせの現在の状態を表示し、意味修正問い 合 わせを構成するために、ユーザに１セットの選択を供給する機能を実行する。 Ａ．問い合わせアシスタント・ユーザ・インターフェース（Query Assistant User Interface）（QUAI） QAUI11は、中間言語の問い合わせを組み立てるために、ユーザ及びQAES12と相 互作用する。インターフェースを通して、ユーザは、問い合わせを開始し、問い 合わせを組み立て、問い合わせを動かし、その結果を見る。図８は、QAUI11の制 御の基本フローを示す。ユーザがステップ50で問い合わせを開始すると、ステッ プ52で、QAUI11は、ブラックボード(blackboad)を初期化するためにQAES12を呼 出し、ステップ54−58で、QAES12の規則により限定されるように、問い合わせ現 在の内容に基づいて１セットの選択をユーザに連続的に与える。ステップ60でユ ーザが選択をした後、システムQAUI11は、ユーザが問い合わせをクリアすること を選択をしたかどうかを判定し（ステップ62）、Noであれば、ユーザが問い合わ せの実行又はキャンセルを選択したかを判定し、（ステップ66）、ブラックボー ドはステップ68で更新され、中間言語表現はステップ70で更新される。これは、 ユーザが問い合わせをともにクリアするか（ステップ64で中間言語表現がクリア された場合のステップ62）、又は、問い合わせがキャンセル又は実行される（ス テップ66）まで継続され、この場合は、適正な実行がなされる。 図９は、ユーザにQAUI11により与えられる初期スクリーン110 を示す。初期ス クリーンは、ユーザ問い合わせ（User Query）ウインドウ112(ここで、中間言語 の問い合わせは成立している)と、SQL 問い合わせ(SQL Query)ウインドウ114(こ こで、ユーザ問い合わせに等価なSQL は、ユーザ問い合わせが組み立てられた後 に表示される）と、結果（Result）ウインドウ116(ここで、その結果は、SQL Query がデータベース・マネッジメント・システムに供給された後、表示される ）と、メニュー（menu）バー118（データベースの選択、概念的レイヤーの選択 、リポート発生器のインターフェース、問い合わせのセーブ及びロード、現在の 問い合わせのクリア、現在の問い合わせの実行、システム・デフォルトのセット 等々をユーザに許す、１セットのドロップ・ダウン・メニューへのアクセスを供 給する。）との４つの領域を有する。 ユーザは、問い合わせヘッディング(Query heading)の下のドロップ・ダウン ・メニューから問い合わせアシスタント10を選択することにより、それを実行す ることができる。これは、問い合わせアシスタント10が操作できる問い合わせの 種々のタイプを掲載した問い合わせ選択メニューをもたらす。これは、問い合わ せの範囲、操作可能な中間言語、及び、問い合わせアシスタント10に設立された 問い合わせ発生ルーチンに基づいている。選択的に、アドミニストレータは、概 念的レイヤーを特定することにより、所定のデータベース上で、ユーザが使用す ることかできる問い合わせの種類を制限することかできる。もし、ユーザが１種 類の問い合わせのみに制限されると、問い合わせリストは無視される。図示の例 では、問い合わせ選択メニューは次のものを含む。 「Show...」問い合わせは、全問い合わせのほぼ99％をカバーし、あるカラム を見、又は、そのカラム上の計算を行う基本的コマンドである。他の問い合わせ は、パーセンテージ及び比較計算のための特別なタイプである。所望のタイプの 結果（result）は、表示中 の問い合わせ引用句から明らかである。これは、困難な問い合わせ概念を理解に 容易にするための中間言語の設計に多少依存する。 ユーザが「Show...」問い合わせを選択すると、（図10Ａに示す）クリエート ・ショー・クローズ・ダイアログ(Create Show Clause dialog)ボックス120 が 表示される。これは、ユーザと問い合わせアシスタントとの間の相互作用の基本 手段である。図中の表示のため、ユーザにより選択されたアイテムはボルド体で あり、選択されなかったアイテムはイタリック体である。選択可能なアイテムを 識別する他の方法は、選択できないアイテムを明るい影又は異なる色で表す「グ レイ・アウト」又は、選択可能なアイテムのみが表示されるように、選択不可能 なアイテムの表示を禁止することを含む。（あるアイテムが選択可能か否かの） 選択状態は、QAUI11により、又は、QAES12を呼び出すことにより特定される。処 理規則はQAUIにより管理され、そして、選択可能なテーブル、カラム、及び、操 作を定義するエキスパートシステム規則によりQAES12により管理される。処理規 則は、以下のものを含むが、これらに限定されるものではない、 １．問い合わせの条件又は短いオーダは、表示されるものが特定されるまで、 特定できない、 ２．個々のカラムは、それがハイライトされるまで、選択されることができな い、 ３．問い合わせは、何かがエンターされる前に実行することはできない、 ４．アイテムは、デリートすべき少くとも１つのアイテムが存在するまで、デ リートすることができない。 クリエート・ショー・クローズ・ダイアログ・ボックス120 の選択指定ウイン ドウ121 は、ユーザに、問い合わせのどのセクション 又はクローズがエンターされるかを指定することを許可する。ウインドウ121 は 、区分の「示せ（Show）」121a、「対して(For)」121b、「により分類された(So rted By)」121c及び「全体の％と共に(With % of Total)」121dを含む。ユーザ は、他のクローズが特定される前に、少くとも１つのカラムが示されるために指 定されるべきことを除いて、どの特定なオーダ中のセクションも指定する必要は ない。例えば、ユーザは、特定の１つのカラムを特定し、そこで、「For」セク ション121bを満たし、示すべき更なるカラムの指定に戻り、そこで、「Sorted B y」セクション121cその他を選択することにより、「Sorted By」カラムを指定し ても良い。 ダイアログボックス120 の制御セクション122 は、問い合わせを実行し、問い 合わせをクリアし、問い合わせの生成をキャンセルし、計算を示すカラムを生成 することをシステムに指示することができる１組の選択ボタン122a−ｄを含む。 計算は、以下に更に詳細に説明される。 アイテム選択ウインドウ123 では、ユーザは、いかなる仮想テーブル又はカラ ム及びいかなる名称置換を含んで、概念的レイヤー中で特定されたように、テー ブルとカラムを選択することができる。どの隠されたテーブル及びカラムも隠さ れる。アイテム選択ウインドウ123 は、テーブル選択ウインドウ（table select ion windoh）124、カラム選択ウインドウ（column selection window）125、記 述ボックス（description box）126、及び選択（Select）及び全選択（Select A ll）ボタン127a及び127bを含む。例示の目的で、図10Ａは、いくつかの隠された テーブルと、リネームされたカラムと、「CUSTOMERS」テーブル上のカウントと して仮想的レイヤー中に定義されて生成された「THE COUNT OF CUSTOMERS」カラ ムと共に、図1A〜1Gのテーブルを使用している。ハイライトされたバーをテーブ ル選択ウインドウ124 中のテーブルからテーブルへ移動することにより、ハイラ イトされたテーブルのために利用可能なカラムのリストが、カラム選択ウインド ウ125内に表示される。選択（Select）及び全選択（Select All）ボタン127a，1 27bは、示すべきカラムを選択することをユーザに許す。記述(Description)ボッ クス126 は、ハイライトされたテーブル又はカラムのための、記述が概念的レイ ヤー中に存在するか否かの記述を示す。 ユーザは、カラム修正ウインドウ128 中の選択されたカラムを修正することが できる。「示す（show）」クローズのために選択されたカラムは、表示ウインド ウ129 にリストされる。ユーザは、総計ボタン13ａ−ｈを介して、選択されたカ ラム又は選択されないカラムに対して、総計計算（即ち、カウント、合計、平均 、最小、最大）を適用することができる。 ユーザが（テーブル選択ウインドウ124 のテーブル、又はカラム選択ウインド ウ125 のカラムを）選択をした後、QAUI11は、ブラックボード13を更新するため 、及び、新たな１セットの許可される選択を要求するため、QAES12と連絡をとる 。加えて、初期画面110 のユーザ問い合わせウインドウ112 は、中間言語中のあ る点での問い合わせを反映するため更新される。もし、ユーザによりされた選択 が、選択可能又は選択不可能になるためのあるアイテムに起因するならば、記述 ボックス120 はそれを反映するために更新される。例えば、図10Ｂは、ユーザが 、表示のため、「CUSTORERS」テーブルの「CUSTORER BALANCE」カラムを選択し 、（表示ウインドウ129 中に示されるカラムにより表示される）カラムを修正す ることを更に選択をした後の、記述ボックス120 を示す。これに応じて、QAUI11 は、いくつかの方法で記述ボックス120 を修正した。第１に、今、総計ボタン13 0a−ｈは、選択可能である。QAES12は、「CUSTOMER B ALANCE」が数値であり、総計をその上に位置されることが意味上正しくない問い 合わせを生成するものではないことを判定したことに基づいて、これらのボタン が選択可能であることをQAUI11に通報してある。ユーザが代わりに「CUSTORE NA ME」を選択すると、総計の他のタイプが数値カラムを要求することから、QAES12 は、単に、「Count」ボタン130cと「None」ボタン130hを選択可能にする。さら に、「Show」セクションが示すべきものを有することから、セクション指定ウイ ンドウ121 の「For」及び「Sorted By」セクション121b，121cが、制御セクショ ン122 中の「Run Query」コマンド122aであるように、今、選択される。初期画 面110 のユーザ問い合わせウインドウ112 は、今、「SHOW CUSTORER BALANCE」 ストリングを収納する。 図10Ｃは、ユーザがCUSTOMER BALANCE（Average ボタン130eを介して）の平均 を見つけるため質問し、表示のため別のコラムを選択する用意をした後のダイア ログボックス120 の状態を示す。平均の集約は数字のコラムに置かれているので 、全ての列は一緒に平均化される。それ故、one-to-many テーブルへの結合は許 されず、同様に集約できる他の数字のコラムのみが選択される。これはQAUI11の 要求によりQAES12によって決定され、全ての他のテーブルと全ての非数字のコラ ムが選択できなくなった場合にダイアログボックス120 で見ることが出来る。別 のテーブルから仮想数字のコラムが与えられたなら、結合は許されていないので 選択可能ではない。もしユーザがCREDIT LIMITを選択したなら、QAUI11は、集約 が求められ、そしてどの集約をユーザが使いたいか要求するダイアログボックス を掲示することをQAES12によって知らされる。 ユーザーは、存在するコラムから実際に計算された結果を見ることもできる。 この場合、ユーザーは計算ボタン122dを選択できる。 この選択は、図10Ｄに示されているように、QAUI11に計算ダイアログボックス13 5 を表示させる。計算ダイアログボックスｂは、ユーザーがコラムの計算を組み 立てる(build)ことを許す。QAUI11は、どのテーブル、コラム、及び操作が同じ ようにここで選択可能かQAES12に要求する。図10Ｄに示された計算ダイアログボ ックスｂの状態は、新らしい問い合わせの開始のようである。しかしながら、計 算は数字のコラムで生じなければならないので、全ての非数字分野は選択可能で はない。この規則はQAES12に蓄積される。 ユーザがセクション指定窓121 のSort By セクション121cを選択した時、QAUI 11は図10Ｅに示されているSorted By ダイアログボックス140 を表示する。この ダイアログはCreate Show Clauseダイアログボックス120 に大変類似している。 他のダイアログボックスのように、QAUI11は、ユーザが使用するために“Sort B y”セクションにおいてどのコラムが選択できるか特定するためにQAES12と共に 動作する。発生したコラムTHE COUNT OF CUSTOMERSは、問い合わせの結果をソー トするために使えない実際に集約した計算のため、選択できない。 結果に係る条件を置くために使われているFor セクションは、事実上より手続 き的である。もしユーザがセクション指定窓121 においてFor セクション121bを 選択するなら、QAUI11はユーザーに、図10Ｆに示されているフォームの一連のCr eate For Clause ダイアログボックスを与える。これは“For”クローズの創造 で利用可能な選択のリストを提供する。図10Ｆは、第１のCreate For Clause ダ イアログボックス150 を示す。利用可能な選択のリストは、選択窓151 で与えら れる。表示されたリストはユーザがFor クローズを介して動かすと変化する。ダ イアログボックス150 において、ユーザは列の“THAT HAVE”又は“THAT HAVE N OT”条件に対する問い合 わせの結果を限定する条件を置くため選択できる。ユーザが条件をまとめるに際 し、コラムに入ることを求められたとき、図10Ｇに示された第２のCreate For C lause ダイアログボックス160 は、テーブル、コラム、及び先のダイアログボッ クスに似たやり方で選択可能又は選択不可能のどちらかに指定された操作と共に 表示される。このようなやり方でユーザは、最初から最後まで条件クローズを組 み立てる。 全体のセクションのWithパーセンテージは、問い合わせの最後に“WITH PERCE NT OF TOTAL”を加えるための単なるフラッグである。これは、もし問い合わせ がいくつかのコラムによってソートされたなら、結果として各列に数値の場に係 るトータルのパーセントを提供する。 他の三つの型の問い合わせは、類似のやり方でQAUI11により扱われる類似のセ クションを持っている。 （１．何パーセントの...もっている...問い合わせは三つのセクションを持って おり、“何パーセントの...”セクション。“With...”セクションと“Have... ”セクション。“何パーセントの...”セクションにおいて、ユーザは概念の層 を介して見られるデータベースにおけるテーブルを選択することを求められる。 “With...”と“Have...”両者のセクションは、上記“For...”クローズにおけ るような条件を求める。 ２．比較する...に対して...問い合わせは次のセクションを持っている。“Co mare...”，“Against...”，“Sort by...”、そして二つの“For...”セクシ ョン。問い合わせは、それらの各々の“For...”セクションにおいて、それらの 上に置かれた条件を持つことができる数字のコラム又は計算を比較する。結果は “Show...”問い合わせと同じようにソートされる。QAUI11は各セクションを上 記検討した“Show...”，“For...”、及びSort by”セクションに対しQAES12に よりセットされた選択されたものに置かれた追加の条件で同様に扱う。 ３．Show...パーセントとしての...は、QAUI11によりComareと同じように扱わ れ...“Compare”が“Show...”で置き換えられ、また“against”が“as a per centage”として置き換えられることを除く問い合わせ。この問い合わせは比較 問い合わせの特別な種類である。） 問い合わせのセクションは目標言語SQL の種々の部分に関係する。しかしなが ら、“Show”，“Compare”，“That Have”その他 のような実際の用語は、用いられる中間言語の特色である。以下により十分に検 討されるように、中間言語は目標言語の見地から指定される。それ故、QAUI11は 、単に意味的に正しい問い合わせを案出する際、ユーザを案内するために特定の 中間言語で指定される。 Ｂ．問い合わせ支援エキスパートシステム（QAES） QAES12は内部状態情報を維持し、問い合わせを創りだすに際し何が許可可能な ユーザの選択であるか決めるためにQAUI11により呼び出される。図７を参照する と、QAES12はBlackboard13の状態に基づくBlackboard13とQuery Expert14を含ん でおり、意味的に正しい問い合わせを案出する際、ユーザは何が出来て何が出来 ないかQAUI11に伝える。Query Expert14はQAUI11に黒板（blackboard）へのアク セスを提供し、Blackboard13の現在の状態を与えられ、意味的に正しい問い合わ せを組み立てるためどのような選択がユーザに利用可能か示す思考力を具体的に 表現する。 １．Blackboard 黒板は、データを掲示し読み取るための中心的な場所を表すデータ構成の概念 の形である。本発明では、Blackboard13はシステムの現状についての情報を含ん でいる。問い合わせはユーザーによって案出されるので、Blackboard13はユーザ ーによりなされた選択を反映させるために修正される。リストに挙げられた変更 内で、Blackboard13は次の情報を維持する。 ・問い合わせは創られているかどうか ・問い合わせの型（Show、何％の、その他） ・現在のクローズ（Show，For，Subquery，Sorted By、その他） ・何がユーザにより選択できるかの選択の現在のセット（バックアップの性能 のため） ・現在のクローズ、全体の問い合わせ、及び補助的問い合わせの 各々のために選択されたテーブルのセット） ・カウント操作に関係するテーブル、もしあったとして（単に一つである） ・集約操作に関係するテーブル（単に一つである） ・計算操作に関係するテーブル（単に一つである） ・仮想テーブルコラムのためのベーステーブル／仮想テーブル関係 ・各条件条項を規定するストリング（即ち、For，With，Have） データにアクセスし、操作するために、次の手順が提供される。 ・黒板を初期化する（これは問い合わせの前に、零または存在しない状態への 全ての変化をセットする） ・問い合わせの型をセットする ・現在のクローズをセットする ・選択可能なテーブル、コラム、及び操作の現在のセットをバックアップする 。 ・選択可能なテーブル、コラム、及び操作のセットのバックアップを元に戻す ・現在のクローズ、全体の問い合わせ、及び補助的問い合わせの各々のために 選択されたテーブルのセットにテーブルを加える ・現在のクローズ、全体の問い合わせ、及び補助的問い合わせの各々のために 選択されたテーブルのセットからテーブルを取り除く ・現在のクローズ、全体の問い合わせ、及び補助的問い合わせの各々のために 選択されたテーブルのリストを読む ・カウント操作と関係するテーブルを読み／書き／クリアする ・集約操作と関係するテーブルを読み／書き／クリアする ・計算操作と関係するテーブルを読み／書き／クリアする ・ベーステーブルを読み／書きする−仮想コラムのための仮想テーブル関係 ・全体の中間言語問い合わせと各条件クローズを含むストリングからテキスト を加え／取り除く（即ち、For，With，Have） 黒板の物理的実行のための可能な方法は、限定はされないが、カプセル化され た変数のセット、データベース蓄積、又は対象蓄積を有し、適当なアクセス手順 を持っている。 ユーザーが問い合わせを組み立てる過程において、各選択をした後、Blackboa rd13は問い合わせの現在の状態を反映させるために更新され、そしてQuery Expe rt14は、ユーザーが次にどのような選択をするべきか決めるために更新された情 報を用いる。 ２．Query Expert Query Expert14は、Blackboard13に蓄積された情報、及び、何が問い合わせを 組み立てるときユーザーが次に選択する事が出来る利用可能なテーブル、コラム 、そして操作かをQAUI11に伝えるため、現在のデータベースアプリケーションに ついて概念の層からの情報を利用する。 Query Expert14は、現在のデータに対する一組の規則の適用によりこの決定を 行う。このシステムに用いられる規則は、もし...それから...陳述、の一組によ って描かれた実施態様において表現されているが、規則は述語論理、または類似 のエキスパートシステム技術による、前方または後方連鎖エキスパートシステム により手続き的に実行できることは、当業者には明らかである。 Query Expert14は、問い合わせの現在の状態に基づいてユーザーにより選択さ れるかどうか決めるため、各テーブルと各テーブルのコラムを調べる。 Query Expert14はまた、選択されたテーブル及び／又はコラムが 集約又は計算操作において用いることが出来るかどうか決める。加えて、条件付 きの“For...”クローズの作成の間、Query Expert14は更なる検討を行う。 Query Expert14は、問い合わせの各セクションの組み立ての間、幾つかの類似 の、及び幾つかの異なった規則を用いる。上記“Show...”問い合わせの各セク ションのために、意味的に正しい問い合わせを生じさせるに際し、どのようなコ ラム、及び操作をユーザが選択出来るか指定するため、Query Expertにより採用 されている規則は以下にセットされている。 １．“Show...”セクション。以下はどのようなテーブル、コラム、及び操作 がユーザにより選択可能かを決めるために使われている規則のセットである。規 則内で用いられている用語“current clause”は、全体のShow...queryを参照す る。現在のクローズは、比較に使われている二つの別個のセクションを持った他 の三つの型の問い合わせにおいて重要になる。これらのセクションの各々は、規 則のベースのために別個のクローズである。 TABLES：データベース中の各テーブルのため、もし次のテーブル規則が全て真実 であれば、テーブルは選択可能である。形if．．Then TRUE の規則は最後にElse FALSEを意味する、そしてif．．Then FALSEの後にElse TRUE を同様に意味する 。概念の層によると、隠されたテーブルは選択のために使用者には与えられない が、しかし、隠されていないテーブルの仮想コラムが隠されているテーブルに基 づいている場合は規則により処理される。もし、隠されたテーブルが選択できな ければ、それに依存している仮想テーブルは選択できない。 COLUMNS ：Table(ｘ)の全てのColumn（ｘ）のために、もし以下のColumn規則が 間違っていなければ、コラムは選択可能であり、他は 出来ない。 COMPUTATION ：同じ規則が、真実であるColumn（ｘ）コラムに係る、追加のComp utation 規則231を受け入れる計算におけるテーブルとコラムの使用に適用する 。 AGGREGATE OPERATION ：選択されるコラムColumn（ｙ）のために選択可能な名集 約操作Aggregate（ｘ）（即ち、カウント、トータル、最小、最大、平均）のた め、以下のAggregate規則が真実である。 SPECIAL RULE：Special 規則251 は、Column（ｘ）が表示のために選択されたと き適用される。Special 規則251 は、選択されたコラムに関し集約操作に入るこ とをユーザに求める。 ２．“Sort By...”セクション。問い合わせを分類するため選択されたコラム については如何なる計算も集計も許されない。他の点では、規則は同様な少しの 変化を伴なった“Show...”セクションと同様である。Table rule 210は同様で あるが、一方Computation，Aggregate、及びSpecial rule 231，240 及び251 は 適用されない。最後に、Column rule 223 は適用されない、その理由は、“Sort By...”セクションはグループ順を規定するのを援助するからである。そしてSo rt By コラムによって分類するため集計をするで あろう。従って、集計が既に適用されていても、Sort By コラムは集計され得な いし集計されるべきでない。コラムが数値であっても数値でなくてもかまわず、 テーブルは選択可能である。 ３．“For...”セクションは前の２つのセクションから幾分異なっている。Fo r 条件を選択すると、ユーザは継続するよう選択の一群を供給する一連の対話ボ ックスを通して導かれる。異なる規則が、条件を作成するプロセスにおいて、異 なる点において適用する。従って、ユーザによっていかなる項目が選択可能であ るかの知識は２つの形式に含まれる。まず第１に、指令の手続きリストがあり、 その指令はユーザにFor クロウズを作成するように指示し、第２には、Show及び Sort By クロウズと同様な方法でテーブル、コラム及び操作に対して特別な時間 に適用された一群の規則がある。 For クロウズを創造するようユーザを指導するに用いられる手続きの知識の擬 似コードの表示は以下に示される。擬似コードにおいて明快に述べなかったけれ ども、すべての選択がユーザによってなされた後、Blackboard13は更新され、現 在の問い合わせはユーザに対する表示のため更新される。For クローズの作成の 間はいつでも、ユーザもまた問い合わせ（黒板をクリアしてスタートする）をク リア、ステップの支援（なされた最後の選択を取り消し）または問い合わせを急 ぐこと（もし適当な点があれば）、が可能である。擬似コードは条件クロウズ型 式のある一組を包むように示されるが、しかしながら、どのようにして追加の条 件型式が容易に追加できるか職人にとっては明らかであろう。擬似コードに従っ て、QAUI11がFor＿Clause＿Top＿Level＿Control 手続をFor クロウズの創作を 開始するように呼び出す。下記のChoose＿entity機能はテーブル又はコラムを選 択するよう用いられ、下記により詳細に記載されている。 手順For ＿Clause＿Top＿Level＿Control 310 は、処理されるべきANDs又はOR s がなくなる迄、For クロウズの結合的部分を創作するループである。 上記擬似コードにおいて、機能Choose＿Entityは規定されていない。この機能 は知識の第２のタイプを用いている。この機能は一組のパラメータと共に呼称さ れており、これ等のパラメータを基礎にして、ユーザはいずれかのテーブル又は コラムを選択することを求めている。その他のクロウズに関しては、この情報は 、どの選択をユーザがなし得るかを区別する方法でユーザに与えられている。QA ES12は、その他のクロウズにおけるように、テーブル及びコラムに対し一組の規 則を適用することによって、どのような選択をユーザはなし得るか決定する。 しかしなから、For クロウズに対する規則の根拠には追加の要素が存在する。 この規則の根拠はパラメータChoose＿Entityによって明記される特別の環境を含 むよう拡張されている。このパラメータは、この擬似コードにおいては、コンマ によって分離されたストリングにおける条件のリストの形状を採用している。QA ES12に通知する条件の２つの形式が存在し、どのような対話項目の形式をユーザ が選択するか及びそれにより表示すべきどのような対話ボックスの 形式を選択するかである。そして、それらは規則における条件である。項目のパ ラメータの形式は次のものを包含する： Entity−ユーザはテーブルを選択することを必要とすると表示する、 Attribute −ユーザはコラムを選択することを必要とすると表示する、 Numeric Attribute −ユーザは単に数字のコラムを選択できることを表示する 、 もし、ユーザがテーブルを選択することを必要とするとき、それらは表示され ないから、規則はコラムに適用されない。条件型式のパラメータは： NMD−テー ブルはNo More Detailedであることができ、他のすべてのテーブルは現在のクロ ウズの状態にある NLD−テーブルはNo Less Detailedであることができ、次いですべての他のテ ーブルは現在のクロウズになる Detail−テーブルは現在のクロウズにおいて最も詳細なテーブルでなければな らない For Table −テーブルは同一又はFor クロウズにおけるテーブルと１対１でな ければならない OFENT −テーブルは同一又は現在のクロウズのテーブルと１対１でなければな らない NOTENT−テーブル同一又は現在のクロウズのテーブルと１対１であってはなら ない。 １対多数の関係においては、その関係の多数側のテーブルは１側のテーブルよ り一層詳細である。先に検討したように、用語“current clause”はShow...que ryにおける全問い合わせを実際に参照する。現在のクロウズは、比較に用いられ る２つの分離したセクションを有する問い合わせのその他の３つの型式において 重要となる。 それらのセクションのそれぞれは、規則の根拠の目的に対する分離したクロウズ である。For クロウズに用いられた規則の根拠は以下に述べられる。 TABLES：Table rule 211-214が適用される。さらに、下記のTable Parameter 規則が適用される。 ４．“With percent of Total”チェックボックス。もし２つのことが真実で あれば：（１）Showクロウズにおける最後の項が数字であり、かつ（２）Sort B y クロウズにおいて明記された分類が存在すれば、ユーザはこのフレーズを問い 合わせの終に加えることができる。 同じ規則の集合は、先のセクションQAUI11において検討されたように、その他 の３つの問い合わせ型式の等価なセクションにおいて用いられる。これらの問い 合わせは、問い合わせにおけるエリプスによって表現された各クロウズと一緒の ２つのクロウズ問い合わせと考えられる。Blackboard13は現在のクロウズに設定 され、現在のクロウズを参照する規則はユーザによって構築されたクロウズを用 いる。規則は主として次の警告と共にShow...queryと同様である。 １．What percent of...have...queriesにおいては、“What percent of...” セクションはデータベースにおいて１つのテーブルに限定されているので適用さ れる実際の規則はない。“With...”及び“Have...”セクションはShow...query における“For...”セク ションと同様である。 ２．Compare...against...queries においては、“Compare...”及び“Agains t...”セクションは集計及び計算を含む数字のコラムに制限される。また、各セ クションにおいて、集計又は計算の単に１つのコラムが存在できる。“For...” 及び“Sort By...”クロウズはShow...queriesにおけるそれと同様な規則集合を 使用する。 ３．Show...as a percentage of...queries において、“Show...”and“as a percentage of...”セクションは集計及び計算を含む数字コラムに限定される 。また、各セクションにおいて、集計又は計算の単に１つのコラムが存在し得る 。“’For...”及び“Sort By...”クロウズはShow...queriesにおけるそれと同 様な規則集合を使用する。 それぞれ図1A，1F、及び1Gから及び図６に示した関連と共に、３つのテーブル CUSTOMERS，ORDERS 及びLINE＿ITEMS を含む不正確な問い合わせを公式化する機 会を持つことから、Query Assistant 10がいかにしてユーザを守るかを図解する ために、ユーザが不正確な問い合わせを試みるステップが記載される。第１に、 ユーザはQuery Assistant 10にたよるであろう、そしてShow...queryを選択する であろう。この点において、何もまだ選択されていないから、テーブルとコラム のすべては選択可能であろう、しかしながら、Run Query box は選択可能でなく 、問い合わせのその他のセクションも、Showセクションに何かが存在するまで選 択可能でない。次にユーザは表示のためCUSTOMERS テーブルにおいてコラムName を選択する。再び、規則を適用した後、テーブルとコラムのすべては選択可能と なる。これは規則の根拠によって示される。その理由はすべてのテーブルはCUST OMERS と結合できるからであり規定された集計はなかった。次に、ユーザは表示 のためORDERSテーブルからOrder Dollar S を選択する。すべてのテーブルとコラムはなお同じ理由で選択可能である。 次に、ユーザはOrder Dollars を限定するため選択する。規則を適用した後、 QAES12は、Order Dollars は数字であり他に集計はないから、いかなる集計もOr der Dollars に適用され得ることを示す。次に、ユーザはTotal on Order Dolla rsを選択する。規則を適用後、QAES12は、Table rule 213のため、LINE＿ITEMS ，PRODUCT，CODE，and VENDORテーブルはもはや選択可能でないと決定する。ま た、ORDERSテーブルにおいて単に数字コラムが選択可能であり、それらは、Colu mn rule 223 及びSpecial rule 251によって書き取らされたように集計されねば ならない。 最後に、CUSTOMERS テーブルのコラムは選択可能であるか、Aggregate rule 2 42のため、集計され得ない。一度、集計がORDER DOLLARS についてなされた時、 ユーザはLINE＿ITEMS テーブルを選択することは許されない、従って、不正確な 問い合わせは公式化され得ない。同様に、もしLINE＿ITEMS テーブルにおけるコ ラムがTotal on Order Dollersを求めるのに先立って選択されたならば、Order Dollars はAggregate rule 243のため集計されることができなかった。 より一層複雑な問い合わせは同じ方法で処理される。各ユーザの選択の後、QA ES12からQAUI11は知識に基づく役に立つ選択のリストを提供する。ここに知識と はほぼデータベースと情報を有し、情報は概念の積み重ねに含まれるものである 。それはすべての適用可能なテーブル、コラム及び動作に規則を適用し、選択可 能な項目のリストを決定する。For クロウズの創作の間、進行上の構成要素は導 入され、動作の方法は実質的に同一である。 IV．中間言語 前述の通り、一連の意味的に有効な問い合わせを文脈に自由(contex-free)な 文法で記述することは不可能だから、中間言語に関する文法はなく、ユーザ選択 を創るのに使用されない。むしろ、中間言語は問い合わせアシスタント（以下、 クイリアシスタントともいう）（Query Assistant）10 によってユーザに提供さ れるテンプレート及び選択によって定義される。テンプレートは画面定義であっ て、その内容（即ち、ピックリスト及び活性要素対不活性要素）はQAES12の別の モジュールによってドライブされる。正確に言えば、中間言語の定義は問い合わ せアシスタント10による発生が可能な問い合わせと言うことになる。 しかし、中間言語のデザインはボトム(SQL発生器20)によってドライブされ、 トップ（問い合わせアシスタント10）によってはドライブされない。クイリシス テム（Query System）１のアーキテクチャは、中間言語を出来る限り目標言語(S QL)に類似させると共に、より容易に理解できる一連の言語構成を作るようにし てSQL 発生器20による処理量を最小限にするようにデザインする。中間言語のデ ザインに当たっては、中間言語の言語構成を使って意味的に正しい問い合わせの 形成を実施し、次いでこれによってSQL 発生器20のデザインを更に簡素化できる ようにクイリアシスタント10を構成する。 自然言語システムでは、自然言語の表示をSQL のような目標言語に変換する場 合に問題がある。本発明では、中間言語が斯うした処理を含むようにデザインさ れているから、中間言語の目標言語への変換は簡単になる。中間言語は、目標言 語(図示の実施例に於けるSQL)から始めて、幾つかの修正を行うことによってデ ザインされる。 先ず、SQL ではそれぞれGROUP BY，HAVING，FROM文によって特定 されるグルーピング及びテーブル仕様構成は削除されるから、ユーザはそれらを 特定する必要がなくなる。むしろ、この情報は問い合わせから容易に推論される 。例えば、もしユーザが表示に関してカラムを選べば、そのカラムを含むテーブ ルはテーブル仕様（即ち、FROM文）に含まれていることが必要である。ユーザが プライマリキーを選択せずにテーブルのカラムを見ることを選択すれば、そのユ ーザは一緒にグループ化されたカラム結果を見たいと思っているのだから、同じ 値は隣接の出力列にあり、デュープリケイトは捨てられる。このことはSQL のGR OUP BY文に特定されているが、推論することが可能である。SQL のHAVING文は、 特別な文であって、GROUP BYアイテムに対してWHERE 文として働く。これもまた 、どのカラムがグルーピングカラムであって、そしてそれらが特殊条件を備えて いれば容易に推論される。 第２に、結合仕様は条件文から削除される。SQL はそのWHERE 文（即ち、WHER E COSTOMER．COSTOER#＝ORDER．CUSTOMER#）に於ける結合の明確な定義を要求す る。この情報は、もし必要であれば問い合わせを形成するが、それが中間言語に よる問い合わせの一部を形成するものではない時には、推論することもできるし 、又は特に要求することができる。 第３に、特殊で、且つ容易に理解し得るパターン（文字列）は、中間言語によ ってサポートされるサブクイリ（subquery）の各々の形に関して定義される。例 えば、英字パターン“MORE THAN2〈category〉”は、特殊なSQL サブクイリ拡張 を持つように定義することが出来る。 第４に、目標言語の残りの部分は、一緒に配列したとき理解し得る文を形成す る容易に理解できる語又は句によって置き換えられる。例えば、SQL を使用して “SELECT”は“SHOW”で置き換え、“WH ERE”は“For”で置き換え、“ORDER BY”は“SORTED BY”で置き換える。 最後に、類義語は種々の語、句、及び構成が用意される。目標言語構成は、問 い合わせが容易に理解し得る文章でなければならない場合、作られる問い合わせ 文の形によっては中間言語に於いて異なるかの知れない。また、このことはユー ザが、例えば日付（即ち、1994年１月１日、01／01／94等）、範囲（ｘとｙの間 、＞ｘ且つ＜ｙ、先月等）、限定（＞、〜より大きく、〜以上又は等しく等）に 限らず概念を複数の方法で特定することを可能にする。 Ｖ．SQL 発生器 上述の中間言語のデザインが決まれば、SQL 発生器20は２つの基本機能を実行 することだけが必要となる。先ず第１に、目標言語中で明確に要求されている問 い合わせの不明確部分、例えばSQL のGROUP BY文、又はWHERE 文中の明確な結合 部を推論するのに必要な機能である。この情報は中間言語のデザインによっては 容易に推論される。第２に、SQL 発生器20は類似語を解読し、より容易に理解し 得る中間言語をパターンの置き換えによる一連の変換を介してよりフォーマルな 目標言語に変換する必要がある。そのパターンは中間言語にその基本的な外観と 感触を与える一連のパターンである。 内部的には、中間言語はデータベースアプリケーションとは独立の成分と、デ ータベースアプリケーションに特定な成分とを有している。アプリケーションに 独立な成分は、パターンを置き換え変換に使用する一連のパターンと、不明確情 報の推論に使用する一連ルーチンによって代表される。アプリケーションに特定 な成分は、SQL 発生器20の基本機能に使用される情報を含む概念階層によって代 表される。 SQL 発生器20は、中間言語に於いて何が意味的に有効な問い合わ せか、何がそうではないかを判断する専門的知識を有してはいない。もし、ユー ザがクイリアシスタント10をバイパスして中間言語の構文を用いて直接問い合わ せを行えば、ユーザは従来のポイント−シュート式の問い合わせツールを用いて 得られると同様の不正確な結果を得ることになる。 Ａ．制御の流れ 図11Ａ及び11ＢはSQL 発生器10の制御の流れを示す流れ図である。各制御段階 を以下に詳しく述べる。SQL 発生器20は中間言語入力に対して一連の変換を実施 し、SQL ステートメントを形成する。これら変換の一つが失敗すれば、エラーメ ッセージが表示される。エラーメッセージは入力された問い合わせが中間言語の 一部でない場合（即ち、クイリアシスタント10によって発生されたものではない 場合）にだけ表示される。SQL 発生器20は中間言語による問い合わせを入力とし て取り込み、以下に述べる処理段階を適用し、出力としてSQL ステートメント形 成する。 処理段階402 では、中間言語による問い合わせはトークン化（字句解析記号化 ）され、構造リストに変換される。各々の構造は問い合わせの中の１トークンに 関する情報を有している。１トークンは通常は語であるが、句であることも可能 である。この処理段階では、句読ビットは排除されるが、引用符内の如何なるも のも文字列に交換され、各トークンを分類するための最初の試行が実施される。 処理段階404 及び406 では、中間言語による問い合わせは内部字句フォーマッ ト(internal lexical format)に変換される。この変換は連続的なパターン整合 変換を介して行われる。文はこれ以上整合したパターンが無くなるまで一連のパ ターンと比較される。字句変換パターン整合子(matcher)について、以下に詳し く述べる。整合の結果得られた内部字句フォーマットは、幾つかの点で中間言語 フォーマットと異なっている。 （ａ）同一構成に関する中間言語内の類似語は、単一の矛盾のない構成に変え られる（即ち、“HAS”及び“HAVE”は“HAVE”になる）。 （ｂ）テーブル及びカラムに対する類似語は概念階層（conceptual layer）で 特定されている名前を利用し、カラム名をTable＿Name．Column＿Name形式の完 全に適格なカラム名に変換することによって変更する。 （ｃ）日付はジュリアン（Jukian）日付フォーマットに変換する。 （ｄ）無関係なカンマ及びANDs（条件文中のものは除く）は削除する。 （ｅ）条件文は、外部ファイルにアスキーテキストとして記憶されている１以 上の前もって定義されているWHERE 文と整合するように変更される。 （ｆ）特殊な記号は、“what percent of...”，“show...as a % of...”， “compare...”等の問い合わせ文の始め及び中間を限定するように挿入する。 （ｇ）特殊な記号は、全てのFOR 文の目的を限定するように挿入する。 （ｈ）無視し得る語として指定されたある種の語（即ち、The，That 等）は削 除される。 これ以上のパターン整合が不可能な時、制御の流れは処理段階408 へと移行し 、そこでCREATE VIEW ステートメントが必要かどうかを決める。もし必要であれ ば、処理段階410 及び412 に於いて、SQL 発生器20は要求された画面を発生する ためのサブルーチンとして再帰呼出しされる。画面が表示されると、SQL 発生器 20への再帰呼 出しは終了する。CREATE VIEW（SQL構成）は、パーセンテージ計算を要求するか 、又は２つのデータベースの分離受信（即ち、比較）を要求する中間言語による 問い合わせに関して必要となる。クイリアシスタント10が発生するCREATE VIEW ステートメントを要求する問い合わせ文の形式は、所定の固定セットであって、 SQL 発生器20はCREATE VIEW 発生を要求する問い合わせ文形を含んでいる。Ｘ及 びＹが数値を形成する独立の問い合わせである場合、要求される問い合わせ文形 の一例は“Compare X and Y”である。SQL 発生器20に対する各再帰呼出し中、 パターン整合が行われ、新たに導入されるアイテムを変換する。次いで、制御の 流れは処理段階414 に移る。 処理段階414 では、内部字句フォーマットは内部SQL フォーマットに変換され る。このフォーマットはSQL 言語により近似する一連のデータ構造である。内部 SQL フォーマットは問い合わせ文を種々のSQL ステートメント要素に適合した一 連の文字列に分ける。これら要素には、SELECTカラム、WHERE 文、ORDER BYカラ ム、GROUP カラム、HAVING文フラグ、FROMテーブル／別称対、JOINs が含まれる 。この段階で、SELECTとORDER BYセクションはセットされているが、WHERE 文は 次の段階に於ける処理のための字句フォーマットに保持される。その他の要素は 必要に応じて以下の処理段階でセットされる。 処理段階416 及び418 を確認するために、字句のWHERE フレーズは外部のアス キーファイルに記憶されている一連のパターンと比較される。整合が見出されれ ば、外部ファイルにある置き換えパターンが内部SQL フォーマットに於ける構造 を表すのに使用される。このようにして、WHERE 文は中間言語からそれに等価な 内部SQL フォーマットに変換される。 内部SQL 構造にテーブルリファレンスがカラムとして導入されると、それらは 処理段階420 に於いてカラムリファレンスに変換される。これは“show custome rs”のような問い合わせがなされと時に起こる。また、この段階で実際のテーブ ルリファレンスは概念階層情報を用いて、もしテーブル名及び実際のテーブル条 件が有ればそれを含めて拡張され、内部SQL 構造に追加される。 SELECT文中にはカラムが無く、ORDER BY文中にカラムが有る場合には、それら は処理段階422 に於いてSELECT文に追加される。処理段階424 では、ジュリアン 日付が適当なSQL 構文によって特定されている日付に変換される。次に、処理段 階426 に於いて、実際のカラムは原文置換（textual substitution）によって概 念階層で定義されている表現に拡張される。これは実際のカラム表現がSQL 表現 又はDBMSによって理解されるその他の表現に従って定義されるからである。この 処理段階で、実際のカラム表現はWHERE 文に加えられ、参照（Lookup）コマンド は単にWHERE 文中にもう一つの結合条件を作る。 処理段階428 では、SELECT及びWHERE 文中の各テーブルに別称を与えることに よって、SQL ステートメントのFROM文が作られる。但し、処理段階416 及び418 のパターン整合中に定義されたサブクイリは無視する。処理段階430 では、ORDE R BY文は、カラム名から位置リファレンスに変換される。ある種のSQL インプリ メンテイション（実行）はORDER BY文のカラム名を受け付けず、SELECT文中のカ ラム位置（即ち、１，２等）を要求する。この処理段階では、ORDER BY文中のカ ラム名がそれぞれのカラムの順序番号に置き換えられる。 処理段階432 では、要求された結合に関し、ナビゲーションパスが計算される 。この計算は上述の最小スパンのツリーを用いて行わ れる。これは２つのテーブル間の最短結合パスを見出すのに一般に使用される技 術であるが、その他の技術も同様に十分に働く。更に追加のテーブルが要求され れば、それらは追加される。また、ユーザが指定しないディフォルトベースでも 、最短結合パスが形成される。しかし、もしユーザがアドミニストレータによっ て、前もって定義された別の結合パスを指定し、概念階層に入力しておけば、そ のパスが使用される。処理段階434に於いて、新たなテーブルが要求されれば、 それらは処理段階436 に於いてFROM文に追加される。次いで、処理段階438 で、 WHERE 文結合ステートメントが内部SQL 構造内で作成される。 処理段階440 では、SELECTが必要に応じて、SELECT DISTINCT に変換される。 これは、問い合わせ文がそのSHOW文中にプライマリキーを含まず、非数値のカラ ム(即ち、Show Customer State and Customer City)だけがある場合に要求され る。プライマリキーはCUSTMERSテーブル中でCustomer Number and Customer Nam e として定義されている。SELECT DISTINCT は明確なセットに対する問い合わせ を制限し、リスト順にカラムによって結果を分類する。SELECT単独で使用すれば 、テーブルの全ての列に関して１出力ラインが得られる。 処理段階442 では、GROUP BY文及び推論されたSUMsが内部SQL に加えられる（ 必要に応じて）。これは、問い合わせ文がそのSHOW文中にプライマリキーを含ま ず、数値カラム（即ち、Show Customer State and Customer Balance）がある場 合に要求される。プライマリキーはCUSTMERSテーブル中でCustomer Number であ り、そしてこの場合、Customer Number は数値フィールドである。ユーザの望み は、状態によるbalance を見ることである。GROUP BYとSUM を含まなければ、CU STOMERS テーブル中の全ての列に対する結果ラインが 得られる。この処理段階は数値フィールドをSUM 表現中に置き、そして全ての非 数値フィールドをGROUP BY文に置く。例えは、上記問い合わせは以下のSQL を作 る。 処理段階444 では、COUNTsは必要に応じてCOUNT(＊)に変換される。これは、 ユーザがテーブルに関するカウントを要求した場合、SQL 変換として要求される 。例えば、“Show The Count of Customers”と言う問い合わせは、次のSQL コ ードを作る。 最後に、処理段階446 に於いて、内部SQL フォーマットは、それを簡単なパー サに通すことによって原文SQL に変換される。 Ｂ．パターン整合 処理段階404 及び418 はパターン整合及び置換技術を用いて、中間言語の変換 を行う。これらの処理段階は、他のどの処理段階よりも中間言語の定義に役立っ ている。これらのパターン／置換の組を修正することによって、中間言語は別の フレーズを用いた違った外観と感触を呈するようになる。従って、クイリアシス タント10はそうしたフレーズを作ることが出来なければならない。更に、パター ンを追加することによって、ユーザには類似概念を登録するためのより多くの方 法が与えられ（クイリアシスタント10を使用しない場合）、そして更に種々のタ イプのサブクイリが定義できる。パターンとして定義された全ての新しいタイプ のサブクイリに関して、ク イリアシスタント10のWHERE 文発生機能は、その能力を与えるために修正する必 要がある。 SQL 発生器20で用いられる２つのタイプのパターン、処理段階404 で使用され た第１のタイプは単純な置換であるが、処理段階416 でWHERE 文の変換に使用さ れた第２のタイプは、新たな構成とサブクイリを導入することが出来るから、も っと複雑である。 １．字句変換パターン整合 処理段階404 の字句変換パターン整合に於いて、問い合わせ文のテキスト文字 列はパターンと比較され、もし問い合わせ文のサブストリングがパターンと整合 すれば、サブストリングはそれと関連した置換文字列によって置き換えられる。 パターンは、 PRIORITY SUBSTITUTION ＜＿PATTERN の形を取る。 PRIORITYは全ての数値が０より大きいか、又は０に等しい#PRIORITY-? WITH ? の形を取るパターンに関する優先順位である。これは#PRIORITY-1 パターン以前 に処理される全ての#PRIORITY-0 パターンを有するパターン整合子(pattern mat cher)に対して順序を与える。与えられた優先順位内で、パターンはリスト順に 適用される。もし、パターンが優先順に始まらない場合は、そのパターンは最近 に読み取ったパターンと同じ優先順位を有している（即ち、全てのパターンが次 の優先指定が行われるまで、同じ優先順位を有している）。 PATTERN は整合性を見出すために問い合わせ文と比較されるものである。以下 のキー記号と共に問い合わせ文中の語と直に整合する原文要素は： ｛｝ 又は（or） 〔〕 単一フレーズ 〜 オプション !???x 何れとも整合する変数、ｘは数字 !ENTx 何れのテーブル名とも整合するテーブル変数、パター中に複数カラム がある場合、ｘは数字 !ATTx 何れのカラム名とも整合するカラム変数、パター中に複数コラムがあ る場合、ｘは数字 !VALx 何れの数値も整合する数値変数、パター中に複数の数値がある場合、 ｘは数字 !FUNCTIONx カラムに適用可能な関数（即ち、SUM，AVG等）と整合する関数変 数、パター中に複数の関数がある場合、ｘは数字である。 SUBSTITUTIONは置換テキストである。!???x，!ENTx，!ATTx、又は!VALx の全 ての場合、PATTERN 中の変数に関連したテーブル、カラム又は数値によって置き 換えられる。 例えば、パターン“PRIORITY-0 AND THAT HAVE＜＿｛[AND HAVE][AND HAS]｝ ”はフレーズ“AND HAVE”と“AND HAS”は、フレーズ“AND THAT HAVE”に対す る類似語で有り、従って置換されることを示す。角括弧はフレーズを意味し、大 括弧は複数の類似語を意味する。“#PRIORITY-0”は優先順位０を持つパターン を定義するから、このルールは優先順位１が規定する以前に適用する。 もう一つの例は“(!ATTI>=!???1 and !ATT1<=!???2)<_｛[!ATT1 BETWEEN !??? 1 AND !???2][!ATT1 FROM !???1 TO !???2]｝”である。この場合、パターンは “BALANCE BETWEEN 10000 AND 50000”又は“BALANCE FROM 10000 T0 50000”の 形の文字列に整合し、そしてパターンを“BALANCE >= 10000 AND BARANCE <= 50 000”で置換する。これらパターンの形から明らかなように、SQL 発生器にとっ て理解可能な中間言語は、異なる語又は句を認識するために、こ れらパターンを変更するか、又は新たなパターンを追加してことによって簡単に 変更することが出来る。 図示の実施例の処理段階404 で用いた一連のパターン（即ち、中間言語の一例 ）を以下に示す。 SQL 発生器20が始動すると、上記パターンは外部テキストファイルから読み出 される。パターンは、各パターンに関して優先順位、テキスト文字列としてのパ ターン、及びテキスト文字列としての置換を含む構造に記憶される。パターン整 合子を結合する構造及び操作は従来技術に於いても良く知られており、前述の能 力を与える多くの技術の何れも本発明の範囲に属するものである。 ２．字句のWHERE の内部SQL フォーマットへの変換 処理段階416 に於いて、一連のパターンは問い合わせ文のWHERE 文をSQL に変 換するのに使用される。これらのパターンは中間言語が取り扱うことが出来る問 い合わせ文の形式の拡大を助け、サブクイリを要求するSQL 構造にしばしばマッ ピングを行う。追加のパターンを加えることによって、中間言語はより複雑な形 のSQL 問い合わせ文を表すように拡大される。 これまでのパターン整合処理段階と同様に、この段階では、問い合わせ文中の WHERE 文のテキスト文字列をパターンと照合する。WHERE 文は左から右に向かっ てパターンと照合される。整合した場合、整合サブストリングはWHERE 文の文字 列から除かれ、そして内部SQL フォーマットは定義された置換に従って補充され る。この処理は、WHERE 文が空になるまで進行する。パターンは事前に特定され た順序で適用される。パターンは次の形を取る。 PATTERN[ ]SUBSTITUTION** これまでのパターン整合子を既に経験しているから、これまでの パターン整合子中のものに類似のPATTERNSは、｛｝記号又は［］フレーズ記号の 必要がないことを受け入れる。ここで記号［］及び**は、パターン及び置換の異 なる部分を示すのに使用した単なる記号である。変数と結合する!???x，!ENTx， !ATTx，!VALx、及び!FUNCTIONxに加えて、何れの数値制限子（即ち、＞，＜，＜ ＝，＞＝，＜＞）とも整合する数値制限変数である!!NUM＿CONSTRx、及び数値カ ラムと整合する NUM＿ATTxが有る。 SUBSTITUTIONは、内部SQL 構造に追加される要素、即ち、SELECTテーブル、FR OMテーブル／別称の一対の組、WHERE 文、JOINs を含んでいる。また、置換セク ションで使用される幾つかのキーワードかある。即ち、 BIND!ENTx パターン整合子はWHERE 文の文字列をパターンと比較 し、整合した部分を取り除き、更に残りの部分を比較 しながら連続して整合を行う。これは結合変数BIND!E NTx に保持されているテーブルをWHERE 文の文字列と の整合に使用する変数LAST-ENTITY に結合する。 LAST-ENTITY これは現在のパターン整合以前の最も最近に整合し たパターンに見られる最後のテーブルを含む。従って 、これは整合した最後のパターンで整合する最後のテ ーブルである。パターンはBINDコマンドを使用して次 に整合されるパターンに対して何がLAST-ENTITY であ るかをセットすることが出来る。パターン整合子の開 始時、SQL 発生器によって処理される最後のテーブル をセットする。 ADD ＿TO＿SELECT !ATTx or !NUM＿ATTx これは!ATTx or !NUM ATTx変数中のカラムを内部SQL 表示のSELECT文に追加 することを明示する。 !ALIASx SQL に於いて、FROM文は情報を含むテーブルを定義し 、そしてもしテーブルが１つ以上有れば、その他の文 が使用出来るよう、一般にテーブルに別称を与えるこ とを要求する。一般に、変換は別称がTxの形を取るよ うに行われる。ここでｘは数値である。例えば、FROM 文は典型的には“FROM Customer T1，Order T2”フォ ーマットを有している。ここで、T1，T2は別称である 。従って、SELECT文は“SELECT NAME．T1，ORDER＿DO LLAR．T2．”と言うフォーマットを持つことが出来る 。これは異なるテーブルのカラムが同一名を有してい る場合の混乱を防止する。!ALIASx と置換中に出会っ たとき、!ALIASx はSQL 構造に記憶するために発生さ れる。一般に複数の別称があるから、ｘは数値である 。異なるｘ毎に、違った別称が発生される。 PKT !ENTx これは、もし!ENTx が概念階層中で定義されている実 際のテーブルを含んでいる場合、!ENTx 中のテーブル 又はベーステーブルの何れかを返す。 PK !ENTX これは、!ENTx 変数中のテーブルのプライマリキーを 返す。 COL この段階で、!ATTx AND !NUM＿ATTx変数中に記憶され たカラムはtable．column 形式に完全に適格である。 COL !ATTx はカラム位置を返す。 TABLE TABLE !ATTx or !NUM＿ATTxは完全に適格なカラム名 のテーブル位置を返す。 一例として以下のパターンを参照されたい。 上記例の第１行は整合のためのパターンを含み、“Table ＿refl＞＝１ Table ＿ref2”を含む文字列と整合する。ここで table＿refsはテーブル名、又は概念 階層に記憶されている実際のテーブルである。文字列は前述の処理段階404 に於 ける前のパターン整合及び置換中にこのフォーマットに入れられる。第２行はこ のパターンの整合以前にSQL 発生器20によって参照された最後のテーブルのベー ステーブルを有するFROMステートメントを作り、そして別称を作る。第５行は前 の別称とはっきり異なる別称を有する!ENT2 のベーステーブルを持つFROM文を作 る。第８行は第２行及び第５行と同様である。第９行、第10行は必要な内部SQL に於ける結合を明示している。それぞれに別称を持つ第８行、第９行で明示され ているテーブルは第８行のFROM文で明示されているテーブルに結合されねばなら ない。最後に、第11行では!ENT2 は更に次のパターン整合のためのLAST-ENTITY として結合される。 それ故、もし整合される文が“ORDERS >= 1 PRODUCTS”を含み、LAST-ENTITY に記憶され、参照される最後のテーブルがCUSTOMERSであれば、その結果得られ る内部SQL フォーマットは次のようにな る。 図示の実施例の処理段階416に於いて（中間言語の一例に対して）用いられる 一連のパターンを以下に示す。 SQL 発生器20が始動すると、上記パターンは外部テキストファイルから読み出 される。これらパターンは、各パターンに関してパターン文字列及び置換文字列 を含む構造に記憶される。パターン整合子を結合する構造及び操作は従来技術に 於いても良く知られており、前述の能力を与える多くの技術の何れも本発明の範 囲に属するものである。整合子は挿入句の形で入れられたWHERE 文に出会うと、 再帰的に呼出される。 Ｃ．結合パス 処理段階 432〜436 は、結合パスの計算、FROM文への新たなテーブルの追加、 WHERE 文に於ける明確な結合の包含を要求する。結合パスの計算は、アドミニス トレータがユーザの選択用に概念階層に別の結合パスを定義しない限り、２つの テーブルの間の最短結合パ スを作る。矢印の方向がprimary key＿＞foreign keyの関係を示している図６の データベース構造を用いて、最短の結合パスは以下のようにして容易に計算する ことが出来る。 先ず初めに、プライマリキーテーブルのテーブルが構成され、フォーリンキー テーブルは、全てのprimary key＿＞foreign keyリンク、フォーリンキーテーブ ルでなければ、結合チェインの中の次のテーブル、そしてプライマリキーテーブ ルからフォーリンキーテーブルに至るまでに通過する結合の数に従う。このテー ブルは概念階層から得るフォーリンキー情報を用いるか、又はテーブル間の関係 をユーザに問い合わせすることによって構成することが出来る。 第２に、テーブル中のprimary key＿＞foreign key対に従って結合されるテー ブルに関して、通過出来るパスを計算する。次に、結合する２つのテーブルのpr imary key＿＞foreign keyパスに共通な細目の最も少ないテーブル（The Least Detailed Table＝LDT）を見出す。LDT はグラフに関するテーブルである。１対 多数の関係では、１テーブルがLDT である。もし複数のパスを通る場合には、複 数のLDT があり、結合数の総和が最も小さいテーブルが選択される。もし、テー ブルからテーブルへの跳び数が等しければ、アドミニストレータがユーザの選択 する結合パスを定義するのに特に適当である。何も定義されない場合、パスの内 の一つが任意に選択される。最後に、プライマリキーprimary key＿＞foreign k ey関係に従ってLDT までの結合パスを計算することが出来る。そして、必要なら ば、何れのテーブルも共通LDT でないならば、foreign key＞ primary keyに従 って結合の第２テーブルへの戻りパスを計算することが出来る。 上述の手続きによって、図６のデータベースに関して以下のテーブルを構成す ることが出来る。 上記テーブルのSALESPEOPLE からORDERSへの結合パスを見つけるために、先ず 通過可能なパスを計算する。SALESPEOPLE に関しては、２つの通過可能なパス[S ALESPEOPLE CUSTOMER ORDERS LINE ＿ITEM]及び[SALESPEOPLE ORDERS LINE＿ITE M]がある。ORDERSに関しては、１つのパス[ORDERS LINE＿ITEMS]がある。SALESP EOPLE に関して見出されるパスの何れかを用いるSALESPEOPLE 及びORDERSに対す る共通のLDT はORDERSである。SALESPEOPLE からORDERSへは２つのパスが有るか ら、一つは[SALESPEOPLE ORDERS]パスを用いて跳び数を計算し、もう一つは[SAL ESPEOPLE CUSTOMER ORDERS]パスを使用して跳び数を計算する。概念階層にパス の定義がなければ、SQL 発生器により短いパスを使用する。 もう一つの例として、ORDERSからPRODUCTSへの結合パスを見つける。先ず、同 様の方法で通過可能なパスを計算する。これによって、ORDERSにはパス[ORDERS LINE＿ITEMS]が、PRODUCTSにはパス[PRODUCTS LINE＿ITEMS]が与えられる。これ らのパスに対する共通のLD T は、LINE＿ITEMS である。ORDERSからLINE＿ITEMS へのテーブルに従い、次い でPRODUCTSに戻れば、結合パス[ORDERS LINE＿ITEMS PRODUCT]が計算される。こ の技術は、良く知られた幾つかの従来技術の一つであり、本発明はこの結合パス 計算に限定されるものではない。 上述の最後の例では、LINE＿ITEMS テーブルは結合パスを作る中で導入されて いる。前記処理段階436 は、結合パスを計算する過程で導入される新たなテーブ ルを、内部SQL 構造のFROM文に追加している。また、新たなテーブルに対する別 称が含まれている。 SQL は結合がWHERE 文に明確に与えられることを要求しており、これは処理段 階436 で実行される。プライマリ及びフォーリンキーカラムは、アドミニストレ ータ、又はユーザへの問い合わせ後クイリシステム１の何れかによって概念階層 に記憶される。情報を用いて、以下のステートメントをWHERE 文に含ませて、上 記例の結合を表すことが出来る。即ち、ORDERS，PRODUCTS，LINE＿NUMBERの別称 がT1，T2，T3であれば、“WHERE T1．PRODUCT#＝T2．PRODUCTS# ANDT2．PRODUCT # T3．PRODUCT#”と表せる。 Ｄ．中間言語のSQL への変換例 以下の例は、“SHOW CUSTOMER NAME FOR CUSTOMERS THAT HAVE ORDERS OF ANY PRODUCT SORTED BY CUSTOMER CITY”と言う形式で中間言語で書かれた問い合わ せ文をSQ Lコードに変換する処理段階を示す。 先ず、処理段階402 に於いて、紹介文をそれぞれのユニットにトークン化する 。ここでは、＜＞によって示す。 <SHOW><CUSTOMER NAME><FOR><CUTOMERS><THAT HAVE><ORDERS><OF ANY><PRODUCT> <SORTED BY><CUSTOMER CITY> これらはトークン化した語及び句である。この区別け処理は継続 されるが、次の処理段階の目的から、トークンを囲む＜＞は含まれない。次に処 理段階404 及び406 に於いて、問い合わせ文は第１の一連のパターンに対して適 用される。上記問い合わせ文はパターン512，556，559，57Ｌ及び581 と整合す る。 パターンは、先ず優先順序で適用され、次いで外部テキストファイルに於ける 位置の順序に従って適用される。全てのパターンの優先順位は２又は５であるか ら、上記パターンがリストされる順序が適用される順序である。それ故、パター ン512 が適用され、そして問い合わせ文は以下のようになる。 SHOW CUSTMERS．NAME OFENTITY!! CUSTOMERS WHERE ORDERS OF ANY PRODUCTS SORTED BY CUSTOMERS．CITY キーワードOFENTITY!!は、後で内部SQL フォーマットへの変換に使用され、そ してCUSTOMERS．NAME はエンティティ（テーブル）であるCUSTOMERS のカラムで あることを示す。最後のパターンが適用された後、パターン556 及び559 はもは や整合しない。また、新たなパターンは整合せず、それ故パターン571 及び581 が残る。高い優先順位を持つパターン571 を適用することによって、問い合わせ 文は次のようになる。 SHOW CUSTMERS．NAME OFENTITY!! CUSTOMERS WHERE ORDERS OF ANY PRODUCTS ORDERBY CUSTOMERS．CITY 新たなパターンは整合せず、そして整合するパターンは一つだけである。それ を適用すると、次のようになる。 SHOW CUSTMERS．NAME OFENTITY!! CUSTOMERS WHERE ORDERS >=1 PRODUCTS ORD ERBY CUSTOMERS．CITY 処理段階 408〜412 はこの問い合わせ文には適用できない。何故なら、この種 の問い合わせ文に必要なCREATE VIEW コマンドが無いからである。もし、この問 い合わせ文がCREATIVE VIEW SQL 構文を 要求する一連の特定な問い合わせ文であれば、SQL 発生器20は再帰呼出しをして CREATIVE VIEW コマンドを作るだろう。CREATIVE VIEW は必要ないから、変換の ための新たな語又は句は導入されなかった。処理段階414 では問い合わせ文はSQ L 成分に分解され、問い合わせ文は次のようになる。 選択文に追加された最終テーブルはテーブルCUSTOMERS によるものであるから 、変数LAST-ENTITY はCUSTOMERS に対してセットされる。最終パターン整合で導 入されたキーワードOFENTITY!!はLAST-ENTITY を決定する際に有用である。 処理段階 416〜418 に於いて、WHERE 文“ORDERS 〉=1 PR0DUCTS”は上に示し たパターンに適用され、パターン605 と１つの整合を作る。このパターンを適用 することによって、問い合わせ文に対する内部SQL 構造はつぎのようになる。 変数LAST-ENTITY はテーブルPRODUCTSに割り当てられる。 処理段階420 に於いて、SELECT部にテーブル名があれば、それは全てのテーブ ルカラムを含むように拡張する。また、どんな実際テーブルも拡張される。この 例は該当しないが、拡張は簡単な置き換えによって実行される。 処理段階422 に於いて、SORT BY 部のカラムは、もしカラムがSELECTになけれ ば、SELECTに追加される。この処理は内部SQL のSELECT部を： SELECT CUSTOMERS．CITY，CUSTOMERS．NAME に変換する。 この例にはデータがないから、処理段階424 のデータ変換機能は適用できない 。同様に、処理段階426 に於ける拡張するための実際カラムがない。 もし、FROM文に対して、別称を明示する必要があれば、処理段階428 で別称が 作られる。この問い合わせはWHERE 文の適用中に別称を作ったが、その他のテー ブルはFROM文には追加されなかった。その時、別称は他のセクションに置き換え られる。内部SQL は： 処理段階430 に於いて、ORDER BY文は変換されて： ORDER BY 1 となる。 処理段階432 では、必要な結合は内部SQL から計算される。それらの結合は、 ここでは“JOIN Table Alias”ステートメントによって示され、それらのテーブ ルはFROM文にリストされているテーブルを結合するのに必要でる。結合パスの計 算に関して前に述べたように、ステートメント： から作られる結合パスは次のようになる。 ［CUSTOMERS ORDERS］and［ORDERS LINE＿ITEMS PRODUCTS］ 次に、処理段階434 及び436 に於いて、結合パス計算は新たなテーブルLINE＿ ITEMS を導入したから、このテーブルは別称を付けて、 FROM ORDERS T3，LINE＿ITEMS T4 を作るために、FROM文に追加する必要がある。 処理段階438 では、結合パス及び概念階層に於けるフォーリンキー情報から、 結合を作り、そしてそれをWHERE 文に追加して、以下のWHERE 文を作る。 処理段階 440〜444 はこの例には適用できない。最後に、処理段階446 に於い て、次のように表される内部SQL 構造、即ち： は原文SQL に変換される。内部SQL 構造の上記の表示は問い合わせ文に対する適 当な原文構造である。内部構造から問い合わせ原文への変換過程は文を組み合わ せ、単純なパーサを通過させる平凡な処理段階である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，Ｍ Ｗ，ＭＸ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＩ，ＳＫ，ＴＪ，ＴＴ，ＵＡ，ＵＳ， ＵＺ，ＶＮ 【要約の続き】 基となるデータベースに概念層を追加するのを許容する 管理機能が設けられ、ユーザがデータベースに問い合わ せをするのをより容易にする。この概念層は、コラム及 びテーブルの代替名、標準的な及び複合的な結合を指定 する経路、仮想テーブル及びコラムの定義、並びにユー ザアクセスに関する制限を含むことができる。

Claims (1)

1. 【特許請求の範囲】 １．所定の構造を有するデータベースについて、目標問い合わせ言語で、意味 的に正確な問い合わせを、ユーザとの対話形式で作成するデータベース問い合わ せシステムであって、 該所定の構造を含め該データベースについての概念情報を記憶する概念層マネ ージャと、 中間問い合わせ言語で該データベースに対する意味的に正確なデータベース問 い合わせを構築するための許容セレクションの集合をユーザに提供する問い合わ せアシスタントと、 前記問い合わせアシスタントから前記中間問い合わせ言語で問い合わせを受け 取り、前記問い合わせを該目標問い合わせ言語に変換する問い合わせジェネレー タと、 を具備するデータベース問い合わせシステム。 ２．前記問い合わせアシスタントは、 データベース問い合わせの現状態についての状態情報を保持する記憶手段と、 問い合わせを構築するため及び該ユーザの選択に基づき前記記憶手段を更新す るための許容セレクションの集合を該ユーザに指示するユーザインタフェースと 、 前記記憶手段に保持された前記状態情報と前記概念マネージャによって記憶さ れた前記概念情報とを解析することによって、前記許容セレクションの集合を前 記ユーザインタフェースに指定する問い合わせエキスパートと、 を具備する、請求の範囲第１項記載のデータベース問い合わせシステム。 ３．前記記憶手段は、更に、 状態変数の集合と、 前記状態変数を追加し、削除し、及び修正するアクセスルーチンの集合と、 を具備する、請求の範囲第２項記載のデータベース問い合わせシステム。 ４．前記記憶手段は、更に、 前記状態情報を収容する状態データベースと、 前記状態データベースに追加し、前記状態データベースから削除し、及び前記 状態データベースを修正するデータベースアクセスルーチンの集合と、 を具備する、請求の範囲第２項記載のデータベース問い合わせシステム。 ５．前記許容セレクションの集合は、非許容セレクションの集合に対し相互に 排他的であり、かつ、全てのコラムオペレーションと、全てのデータベーステー ブルと、意味的に正確なデータベース問い合わせを構築する上で該ユーザが次に 選択する可能性がある前記データベース情報マネージャによって保持されるコラ ムと、の部分集合である、請求の範囲第２項記載のデータベース問い合わせシス テム。 ６．前記ユーザインタフェースは、前記許容セレクションの集合と前記非許容 セレクションの集合とを表示し及び視覚的に区別する、請求の範囲第５項記載の データベース問い合わせシステム。 ７．前記ユーザインタフェースは、色によって視覚的に区別する、請求の範囲 第６項記載のデータベース問い合わせシステム。 ８．前記ユーザインタフェースは、前記非許容セレクションの集合を表示する ことなく、前記許容セレクションの集合を該ユーザに表示することのみによって 、問い合わせを構築するための前記許容 セレクションの集合を該ユーザに指示する、請求の範囲第５項記載のデータベー ス問い合わせシステム。 ９．前記ユーザインタフェースは、タイプ特性によって視覚的に区別する、請 求の範囲第６項記載のデータベース問い合わせシステム。 10．前記問い合わせエキスパートは手順論理からなる、請求の範囲第２項記載 のデータベース問い合わせシステム。 11．前記問い合わせエキスパートは、ルールに基づくエキスパートシステムで ある、請求の範囲第２項記載のデータベース問い合わせシステム。 12．前記目標問い合わせ言語は構造化問い合わせ言語(SQL)である、請求の範 囲第１項記載のデータベース問い合わせシステム。 13．前記概念情報はテーブル、コラム、及び関係情報を具備する、請求の範囲 第１項記載のデータベース問い合わせシステム。 14．前記テーブル及びコラム情報は、該所定の構造から自動的に読み取られる 、請求の範囲第13項記載のデータベース問い合わせシステム。 15．前記概念情報は、更に、フォーリンキー、テーブル結合経路、非等結合用 テーブル結合表現、仮想テーブル定義、仮想コラム定義、テーブル記述子、コラ ム記述子、隠しテーブル、及び隠しコラム、のうちの１つ又はそれ以上を具備す る、請求の範囲第13項記載のデータベース問い合わせシステム。 16．前記概念情報は、更に、仮想コラム定義を具備する、請求の範囲第13項記 載のデータベース問い合わせシステム。 17．前記仮想コラム定義は、結合オペレーションを定義するための、プライマ リキーレファレンス及びフォーリンキーレファレンスを収容する、請求の範囲第 16項記載のデータベース問い合わせシス テム。 18．前記概念情報は、更に、非等結合用テーブル結合表現を具備する、請求の 範囲第13項記載のデータベース問い合わせシステム。 19．前記問い合わせジェネレータは、連続変換の集合により、前記中間言語問 い合わせを前記目標言語に変換する、請求の範囲第１項記載のデータベース問い 合わせシステム。 20．前記連続変換の集合のうちの少なくとも１つはパターン代用による変形で ある、請求の範囲第19項記載のデータベース問い合わせシステム。 21．前記変形の集合は、 構造変形の集合と、 推論情報を含むための変形の集合と、 パターン代用による変形の集合と、 を具備する、請求の範囲第19項記載のデータベース問い合わせシステム。 22．所定の構造を有するデータベースについて、目標問い合わせ言語で、意味 的に正確な問い合わせを、ユーザとの対話形式で作成するデータベース問い合わ せシステムであって、 該所定の構造を含め該データベースについての情報を記憶する記憶手段と、 中間問い合わせ言語で前記現データベースに対するデータベース問い合わせを 構築するための許容セレクションの集合を該ユーザに提供することによって、意 味的に正確なデータベース問い合わせを構築する問い合わせ作成手段と、 前記中間問い合わせ言語を該目標問い合わせ言語に変換する問い合わせ変換手 段と、 を具備するデータベース問い合わせシステム。 23．目標データベース言語から中間データベース言語を作成する方法であって 、 推論されうる該目標データベース言語から構文を除去するステップと、 該中間データベース言語に含まれるべき目標データベース言語の条件構文の各 タイプを新規なパターンと交換するステップと、 該目標データベース言語におけるキーワードを新規なパターンと交換するステ ップと、 該中間データベース言語における構文のためにシノニムの集合を定義するステ ップと、 を具備する方法。 24．推論されうる目標データベース言語からの前記構文がグループ化構文及び 結合構文を含む、請求の範囲第23項記載の、目標データベース言語から中間デー タベース言語を作成する方法。 25．所定の構造を有するデータベースについて、目標問い合わせ言語で、意味 的に正確な問い合わせを、ユーザとの対話形式で作成するデータベース問い合わ せシステムであって、 中間問い合わせ言語で該データベースに対する意味的に正確なデータベース問 い合わせを構築するための許容セレクションの集合をユーザに提供する問い合わ せアシスタントと、 前記問い合わせアシスタントから前記中間問い合わせ言語での問い合わせを受 け取り、前記問い合わせを該目標問い合わせ言語に変換する問い合わせジェネレ ータと、 を具備するデータベース問い合わせシステム。 26．データベース管理システム（DBMS）において実現されるデータベースにつ いて、問い合わせ言語で、意味的に正確な問い合わせを、ユーザとの対話形式で 作成するデータベース問い合わせシステ ムであって、該DBMSは目標問い合わせ言語での問い合わせを受入れ、該データベ ースは所定の構造を有し、該構造についての情報は該DBMSによって保持され、該 システムは、 中間問い合わせ言語で該データベースに対する意味的に正確なデータベース問 い合わせを構築するための許容セレクションの集合を該ユーザに提供する問い合 わせアシスタントであって、前記許容セレクションが該データベース構造につい ての情報から少なくとも一部決定されるものと、 前記問い合わせアシスタントから前記中間問い合わせ言語での問い合わせを受 け取り、前記問い合わせを該目標問い合わせ言語に変換する問い合わせジェネレ ータと、 を具備するデータベース問い合わせシステム。