JP2000163446A

JP2000163446A - 拡張可能問い合わせ処理器

Info

Publication number: JP2000163446A
Application number: JP10355332A
Authority: JP
Inventors: Yuichi Aiba; 雄一相場; Atsushi Kitazawa; 敦北澤
Original assignee: NEC Corp; NEC Solution Innovators Ltd
Current assignee: NEC Corp; NEC Solution Innovators Ltd
Priority date: 1998-11-30
Filing date: 1998-11-30
Publication date: 2000-06-16

Abstract

(57)【要約】【課題】集合データ演算機能を提供するデータプロバ
イダを利用して問い合わせを処理する問い合わせ処理器
において、処理器内の内部データ等を変更せずに、デー
タプロバイダの提供する集合データや集合データ操作関
数の追加、変更を可能にする。【解決手段】各データプロバイダ12毎にメタデータイ
ンタフェース提供手段11を設け、プロバイダ12で管理さ
れるメタデータを獲得する為の統一したインタフェース
を提供する。解析手段14は問い合わせ13を解析して問い
合わせ構造モデル15を生成する処理に必要なメタデータ
を、手段11を利用して各データプロバイダ12から取得す
る。変換手段16は問い合わせ構造モデル15から問い合わ
せ実行表現17を生成する処理に必要なメタデータを、手
段11を利用して各データプロバイダ12から取得する。実
行手段18は問い合わせ実行表現17に従ってデータプロバ
イダ12の持つ集合データ操作関数を呼び出し、問い合わ
せの処理を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、検索条件を指定し
たデータ検索や、集合データ間の結合演算など様々な集
合データの関係・集合演算を指定した問い合わせ文を処
理する問い合わせ処理器に関し、特に、様々な集合デー
タ操作関数を提供する複数のデータプロバイダに対し
て、統合的な集合データ演算処理を指示した問い合わせ
を処理し、しかも、問い合わせ処理機能の拡張を容易に
行える拡張可能問い合わせ処理器に関する。

【０００２】

【従来の技術】何らかの共通性を持つ複数のデータを集
めたデータの集合を集合データと呼ぶ。集合データ演算
は、このような集合データに関係・集合演算を施して別
の（集合）データを得る処理であり、例えば、集合デー
タからデータを選び出す選択演算や、集合データ同士の
和・積演算、結合演算、あるいは集合データ中の要素数
を数える集計演算などがある。

【０００３】利用者から投入される問い合わせは、集合
データ演算処理をデータプロバイダに処理させ、その結
果を得ることを目的とし、決められた問い合わせ構文に
従って記述される。問い合わせ処理器は、このような利
用者からの問い合わせを受け取り、その内容を解釈し、
データプロバイダに集合データ演算を処理させ、その結
果を利用者に知らせる。この際、問い合わせを高速に処
理させるための最適化を施したりする。

【０００４】データプロバイダは、集合データを管理
し、集合データに対する演算処理の機能を提供するソフ
トウェアであり、例えば、データベース管理システムな
どがその一例である。

【０００５】データプロバイダは、各データプロバイダ
によって種類や数は相違し得るが、集合データ演算を処
理するための具体的な集合データ操作関数を用意してい
る。例えば、集合データの選択演算に対して、高速な検
索を可能とするための様々なインデックスサーチ関数を
用意する。また、集合データの結合演算に対しては、入
れ子ループ、ソートマージ、グレースハッシュ、索引結
合、ポインタ結合などに対応する集合データ操作関数を
用意する。問い合わせ処理器は、アクセスパスを考慮し
た集合データ操作関数を選択することにより問い合わせ
の最適化を行い、集合データ操作関数を順番に呼び出す
ことによって問い合わせの処理を進める。ここで、アク
セスパスとは、索引やポインタなど、レコードなどの探
索に用いる補助的な格納構造を言う。

【０００６】従来の問い合わせ処理の技術として、例え
ば、「問い合わせ処理方式」（特開平 5−189285号公
報) 、「リレーショナル・データベース・システムの問
合わせ文処理方法」（特開平 2−12461 号公報 (特許第
2510004 号))がある。これらの方式は、固定の集合デー
タ操作関数を提供するデータベース管理システム（デー
タプロバイダの１つ) を前提に、それに対する問い合わ
せ処理の最適化手段を提供する。これらの方式では、集
合データ操作関数は大きな変更・追加を行わないことを
想定しており、構文・意味解析、最適化を行うロジック
は固定的に問い合わせ処理系のプログラム中に埋め込ま
れている。従って、全く新しい集合データ操作関数を加
えたり変更したりする際には、データプロバイダだけで
なく、問い合わせ処理系のプログラム本体の書き換えを
行わなければならない。そのため、集合データ操作関数
の追加・変更が容易でなかった。

【０００７】イメージ・動画など様々な形態のマルチメ
ディアデータを集合データとして管理するためには、多
様な集合データ操作関数を提供する必要がある。例え
ば、イメージをデータベースとして管理するならば、イ
メージ検索関数を集合データ操作関数として用意する必
要がある。そこで、オブジェクト指向データベースの技
術に着目する。オブジェクト指向データベースでは、デ
ータの構造（クラス) を自由に定義し、それを専用に扱
う操作関数をカプセル化することができる。これによ
り、様々な構造のデータや集合データ操作関数を自由に
拡張することが可能である。

【０００８】オブジェクト指向データベースに対して、
問い合わせ処理の機能を持たせることにより、問い合わ
せ中に様々な形態の集合データ演算を指示することが可
能となる。「拡張可能データベースのユーザ定義手続き
解析器」（特開平 6−28405号公報) や「データベース
への問合せの解析方式」（特開平 2−217963号公報)で
は、オブジェクト指向データベースに対する問い合わせ
処理を実現している。

【０００９】ところが、このようにして様々な形態の集
合データ演算による問い合わせを実現しても、それを処
理する問い合わせ処理器自体が拡張可能でなければ、結
局のところ問い合わせ可能な集合データ演算には制限が
できる。問い合わせ処理系が拡張可能であるためには、
例えば、集合データ操作関数の追加・変更に対し容易に
対応できる機能、あるいは、最適化アルゴリズムを容易
に追加・変更できる機能などが必要となる。従来の問い
合わせ処理系にはこれらの機能がなく、例えば、最適化
アルゴリズムなどはプログラム中に直接組み込まれてい
るために、新たな最適化アルゴリズムの拡張が困難であ
った。

【００１０】これに対し、「データベース問い合わせ処
理方式」（特開平 3− 111974 号公報) では、外部から
最適化のためのルールを変更する手段を備えることによ
って、最適化ルールの追加・変更を容易にする。しか
し、この方式は最適化ルールの追加・変更のみを可能と
する部分的な改良に止まり、これだけでは例えば集合デ
ータ操作関数の追加・変更には対応できない。

【００１１】そもそも、多様な集合データ操作関数を想
定した場合、最適な実行フローを生成するルールは多岐
に渡り、全ての最適化ルールを１通りにまとめることは
困難と考えられる。場合によっては、問い合わせ処理系
の生成した実行フローは長い処理時間を要するかもしれ
ない。そこで、ユーザとしては問い合わせの投入の度に
異なる最適化を試したい。しかし、従来の問い合わせ処
理方式では、すべての問い合わせに対して同一の最適化
アルゴリズムや最適化ルールを適用しているため、問い
合わせ毎に異なる変換ルールに基づいて実行フローを生
成することはできなかった。

【００１２】一方、”Issues on Query Processing in
Distributed and Interoperable Information Systems
”(Proceedings of International Symposium on Coop
erative Database Systems for Advanced Application
s, Dec. 1996) や、”Towardsheterogeneous multimedi
a information systems: the garlic approach ”(Tech
nical Report, IBM Almaden Research Center, 1994)
では、１つのデータプロバイダ(Repository)だけでな
く、複数のデータプロバイダ(Repository)を利用して、
それらに跨る統合的な問い合わせを処理する。これら
は、ユーザから投入された１つの問い合わせを各Reposi
tory用の複数の副問い合わせに分割して各Repositoryに
要求し、結果をまとめて得る、といった仲介的なシステ
ム(Mediator)となっている。

【００１３】Mediatorは問い合わせの分割の際に、各Re
positoryの持つデータやデータ操作関数の情報を含むメ
タデータを参照する必要がある。前記の論文では、メタ
データを集中管理するメタデータマネージャを設ける
か、あるいはMediator中で直接メタデータを集中管理す
る。いずれの場合も、メタデータを更新することによ
り、Mediator本体のプログラムを改造することなく、Re
positoryやデータ操作関数を追加できる。なお、メタデ
ータを集中管理する点については特開平10−78968号公
報にも記載されている。

【００１４】ところが、メタデータを集中管理するため
には、全てのデータプロバイダの持つメタデータを、統
一した形式にマッピングしておかなければならない。そ
のため、Repositoryを追加する時だけでなく、個々のRe
positoryの持つデータやデータ操作関数を変更する度
に、集中管理されたメタデータを書き換えなければなら
ない。

【００１５】また、メタデータを参照する主体がMediat
orに限られているため、メタデータの参照インタフェー
スは内部的に隠されている。従って、外部からはメタデ
ータを参照できず、例えばメタデータを使った最適化ル
ールなどをユーザが記述することができない。

【００１６】

【発明が解決しようとする課題】本発明の第１の目的
は、集合データ演算機能を提供する様々なデータプロバ
イダを利用し、集合データ演算を指示した問い合わせを
処理する問い合わせ処理器において、問い合わせ処理器
のプログラムや内部データを変更せずに、データプロバ
イダの提供する集合データや集合データ操作関数の追加
・変更を可能とすることである。

【００１７】本発明の第２の目的は、問い合わせ処理器
のプログラム自体を変更することなく、問い合わせの実
行フローを最適化するためのルールを追加・変更可能と
し、更に、問い合わせ毎に異なる最適化ルールを適用可
能とすることである。

【００１８】

【課題を解決するための手段】本発明は上記第１の目的
を達成するために、各データプロバイダに関するメタデ
ータを参照するための統一したインタフェースを提供す
るメタデータインタフェース提供手段を各データプロバ
イダ毎に備え、また、上記第２の目的をも達成するため
に、問い合わせの最適化ルールを指定されたファイルに
格納する格納手段と、問い合わせ時に指定されたファイ
ルに格納された最適化ルールに基づいて問い合わせの実
行フローを生成する手段とを備えている。

【００１９】より具体的には、本発明の第１の拡張可能
問い合わせ処理器は、集合データ演算機能を提供するデ
ータプロバイダに対する問い合わせ文を処理する問い合
わせ処理器であって、データプロバイダ毎に存在し、各
データプロバイダの持つ集合データの性質及び各データ
プロバイダが提供する集合データ関数の性質を知るため
の統一したインタフェースを提供するメタデータインタ
フェース提供手段と、前記メタデータインタフェース提
供手段を利用し、入力された問い合わせ文の構文・意味
解析を行い、問い合わせに関する集合データと集合デー
タ演算処理の関係を表現した問い合わせ構造モデルを作
成する問い合わせ解析手段と、前記メタデータインタフ
ェース提供手段を利用し、問い合わせ構造モデルから、
各データプロバイダの持つ具体的な集合データ操作関数
と各集合データ操作関数の間で受け渡しするデータの流
れを表現した問い合わせ実行表現を生成する実行表現変
換手段と、問い合わせ実行表現に示された実行フローに
従って、各データプロバイダを呼び出して問い合わせを
実行する問い合わせ実行手段とを備えている。

【００２０】また本発明の第２の拡張可能問い合わせ処
理器は、上記第１の拡張可能問い合わせ処理器におい
て、実行表現変換手段に代えて、前記メタデータインタ
フェース提供手段を利用し、問い合わせ構造モデルから
複数の問い合わせ実行表現の候補を生成する実行表現候
補生成手段と、前記メタデータインタフェース提供手段
を利用し、前記実行表現候補生成手段によって生成され
た複数の問い合わせ実行表現の候補から１つの問い合わ
せ実行表現を選出する実行表現選択手段とを備えてい
る。

【００２１】さらに本発明の第３の拡張可能問い合わせ
処理器は、上記第２の拡張可能問い合わせ処理器におい
て、問い合わせ構造モデルを問い合わせ実行表現に変換
するための変換規則を、指示された変換規則ファイルに
格納する変換規則格納手段を備え、実行表現候補生成手
段の代わりに、前記メタデータインタフェース提供手段
を利用し、指示された変換規則ファイルに格納された変
換規則に基づいて、問い合わせ構造モデルから複数の問
い合わせ実行表現の候補を生成する規則参照変換手段を
備えている。

【００２２】ここで、集合データの性質とは、集合デー
タの名前や、属性の数や各属性の名前、型、あるいはそ
の集合データからデータを取り出すためのアクセスパス
などを意味し、集合データ関数の性質とは、集合データ
関数の名前や入力引数の数や型、出力の型などを意味す
る。

【００２３】本発明の第１及び第２の拡張可能問い合わ
せ処理器にあっては、各データプロバイダ毎にメタデー
タインタフェース提供手段が設けられているため、この
手段を介して、任意の時点で各データプロバイダに関す
るメタデータを参照できる。このため、問い合わせ処理
器中で予めメタデータを管理しておく必要がなくなる。
これにより、各データプロバイダの持つ集合データや集
合データ操作関数が追加・変更されても問い合わせ処理
器に反映する必要がなくなる。つまり、問い合わせ処理
器のプログラムや内部データを変更することなく、デー
タプロバイダの提供する集合データや集合データ操作関
数の追加・変更が可能となる。

【００２４】本発明の第３の拡張可能問い合わせ処理器
にあっては、問い合わせの実行フローを生成する最適化
のためのルールを、指定された変換規則ファイルに記録
する変換規則格納手段が設けられているため、ユーザは
変換規則格納手段を介して容易に最適化ルールを拡張、
すなわち追加・変更できる。また、規則参照変換手段に
より、ユーザは個別に最適化ルールを定義・格納した変
換規則ファイルを指定することができ、ユーザ固有の最
適化ルールに従った変換を行って問い合わせ実行表現を
生成することが可能となる。

【００２５】

【発明の実施の形態】本発明の第１の実施形態の構成例
を図１に示す。図１を参照すると、本例の拡張可能問い
合わせ処理器は、各データプロバイダ12毎のメタデータ
インタフェース提供手段11と、メタデータインタフェー
ス提供手段11を利用し、図示しないキーボード等の入力
装置から入力された問い合わせ13を解析して問い合わせ
構造モデル15を生成する問い合わせ解析手段14と、メタ
データインタフェース提供手段11を利用し、問い合わせ
構造モデル15から問い合わせ実行表現17を生成する実行
表現変換手段16と、問い合わせ実行表現17に示される実
行フローに従って各データプロバイダ12を呼び出して問
い合わせを実行し、結果を図示しない表示装置などに出
力する問い合わせ実行手段18とを含んでいる。

【００２６】データプロバイダ12は、リレーショナルデ
ータベース管理システムがその一例であるが、一般的に
は「データの集合を出力するもの」であれば良い。例え
ば或る指紋に近い指紋を持つ人を検索して出力する指紋
検索システムや、ファイル名を出力するUNIXのlsコマン
ドなどもデータプロバイダになり得る。

【００２７】メタデータインタフェース提供手段11は、
各データプロバイダ12について個々に設けられ、データ
プロバイダ12毎に管理されるメタデータを獲得するため
の統一したインタフェースを提供する。例えば、各デー
タプロバイダ12の持つ集合データの性質（集合データの
名前や、属性の数や各属性の名前、型、あるいはその集
合データからデータを取り出すためのアクセスパスな
ど）、及び各データプロバイダが提供する集合データ関
数の性質（集合データ関数の名前や入力引数の数や型、
出力の型など）を取得するインタフェースを提供する。

【００２８】ユーザから入力される問い合わせ13は、所
定の問い合わせ構文に従って記述されている。問い合わ
せ構文としては、SQL92 やそれを拡張したSQL3などが使
われる。勿論、SQL に限定されず、オブジェクト指向向
けのOQL など他の問い合わせ構文を使用することもでき
る。

【００２９】問い合わせ解析手段14は、ユーザから入力
された問い合わせ13を構文解析、意味解析し、問い合わ
せの構造を表現する問い合わせ構造モデル15を作成す
る。この問い合わせ構造モデル15では、問い合わせ中で
扱われる集合データの型や構造、集合データに対する演
算操作、問い合わせが要求する結果などの関連が表現さ
れている。問い合わせ解析手段14における構文解析で
は、例えば、SQL を想定した場合、問い合わせ中の“SE
LECT”や“FROM”といったキーワードや括弧、カンマ、
ピリオドなどの文字を検出し、その間にある文字列をテ
ーブル、カラム、関数に見立てて、問い合わせ構造モデ
ルの基本構造を作成する。次いで意味解析において、構
文解析で解析できなかった各文字列の情報を取り出す。
例えば、FROMの後に続く文字列がテーブル名であるかを
調べ、そのテーブルの情報（幾つのカラムで構成される
かなどの情報）を問い合わせ構造モデルに記録する。こ
の処理時に、メタデータインタフェース提供手段11を利
用し、データプロバイダ12のメタデータが参照される。

【００３０】例えば、FROMの後にある文字列がテーブル
の名前であることを判別するためには、「テーブルの名
前」と「テーブルを示す属性」を組にした情報が必要で
ある。また、カラム名と考えられる文字列であれば、各
テーブルにそのような名前のカラムがあるかを判定する
ために、テーブルとカラム名を組にした情報が必要であ
る。さらに、“Column.A＝10”などという述語であれ
ば、“＝”の左辺と右辺の型が合っている必要があるた
め、“Column”というカラム名と考えられる文字列につ
いて型を調べるが、そのためにはカラム名とデータ型が
組になった情報が必要である。問い合わせ解析手段14
は、これらの情報をメタデータインタフェース提供手段
11を利用してデータプロバイダ12から取得する。

【００３１】なお、どのメタデータインタフェース提供
手段11、つまりどのデータプロバイダからメタデータを
参照すべきかを制御する方法については、任意の制御方
法を採用することができる。最も簡単な方法は、全ての
データプロバイダ12に対して聞いて回る方法である。例
えば、“FROM TableA ”という文字列に対し、“Table
A”という名前のテーブルがあるかどうかを全てのデー
タプロバイダ12に対して問い合わせる。後述する関数に
関しても同様に、関数の名前を全データプロバイダ12に
問い合わせ、その関数を提供しているデータプロバイダ
12を特定する。テーブルとデータプロバイダの関係が確
定すれば、テーブル中のカラムの情報はそのプロバイダ
に問い合わせれば良いので、全データプロバイダ12に問
い合わせる必要はない。

【００３２】次に、実行表現変換手段16は、問い合わせ
構造モデル15をより詳細な集合データ操作関数と、集合
データ操作関数の間のデータ受け渡しの流れを表現する
問い合わせ実行表現17に変換する。この際にもメタデー
タインタフェース提供手段11を利用して、各データプロ
バイダ12の持つデータ操作関数に変換する。

【００３３】メタデータインタフェース提供手段11を利
用して実行表現変換手段16が参照するメタデータは、問
い合わせ中の述語を満たすデータを得るのにどんなアク
セスパス、関数を使えるかを調べるため、基本的には、
各テーブルに関係するアクセスパスの情報と関数の情報
である。例えば、“Column.A＝10”という述語に相当す
る問い合わせ構造モデル15を考えた場合、テーブルＡの
カラムColumnに張られているインデックスがあるかどう
か、インデックスサーチ関数を使って上記の述語に関す
る検索ができるかどうかを調べる。更に、この関数を使
ってどのようなデータが得られるかも調べる。なお、問
い合わせ解析手段14の意味解析の時点で各テーブルを持
つデータプロバイダ12が確定し、問い合わせ構造モデル
15に記録されているので、実行表現変換手段16は問い合
わせ構造モデル15の前記記録に基づき、利用するメタデ
ータインタフェース提供手段11、つまりデータプロバイ
ダ12を特定する。

【００３４】本実施形態の場合、問い合わせ構造モデル
15から問い合わせ実行表現17を生成する変換ルールは、
ルールとして明確に切り出されている訳ではなく、従来
の問い合わせのオプティマイザと同様に或る構造モデル
を与えると固定的に実行表現を生成するルーチン（プロ
グラム）として実行表現変換手段16にコード化されてい
る。勿論、後述する第３の実施形態と同様に（但し、１
セットの変換ルールだけであるが）、変換ルールを使用
する構成であっても良い。

【００３５】最後に、問い合わせ実行手段18は、問い合
わせ実行表現17に従って、各データプロバイダ12の持つ
集合データ操作関数19を呼び出して問い合わせの処理を
行う。問い合わせ構造モデル15から問い合わせ実行表現
17を生成する時点で、どの関数がどのデータプロバイダ
12によって提供されているかが確定し、問い合わせ実行
表現17に記録されているので、その記録に基づき、問い
合わせ実行手段18は呼び出し先のデータプロバイダ12を
判断する。

【００３６】次に、メタデータインタフェース提供手段
11の実施例について図２、図３を参照して説明する。

【００３７】問い合わせ処理器から見たデータプロバイ
ダの形態は３通りほど考えられる。第１の形態は、別の
計算機上で動作するプロセスであり、第２の形態は、同
一計算機内で動作するプロセスであり、第３の形態は、
問合わせ処理器にリンクされたライブラリ関数である。
メタデータインタフェース提供手段11は、このようなデ
ータプロバイダの形態の違いを吸収する。

【００３８】メタデータインタフェース提供手段11の第
１の形態を図２に示す。この形態では、問い合わせ処理
器21が動作する計算機22に設けられたライブラリ部23
と、データプロバイダ24が動作する計算機25に設けられ
た仲介部26との2 つのモジュールから構成される。但
し、計算機27上のデータプロバイダ28のように、データ
プロバイダが他計算機から直接全てのメタデータを獲得
できるインタフェースを持つ場合、その計算機27には仲
介部は必要ない。

【００３９】ライブラリ部23は問い合わせ処理器21にリ
ンクされる形で実現される。ライブラリ部23は、問い合
わせ処理器21から呼び出しを受けると、計算機接続網29
を介して、仲介部26またはデータプロバイダ28と通信を
行うことによりメタデータを獲得し、問い合わせ処理器
21に回答する。

【００４０】仲介部26は、データプロバイダ24のメタデ
ータが他計算機から獲得できない場合に必要となり、デ
ータプロバイダ24と同一の計算機25上のプロセスとして
実現される。仲介部26は、データプロバイダ24のインタ
フェースを使ってメタデータを獲得するか、あるいは、
データプロバイダ24のメタデータを独自に管理してお
き、ライブラリ部23からのメタデータ要求を受けると、
要求された情報を返却する。

【００４１】メタデータインタフェース提供手段11の第
２の形態を図３に示す。この形態では、問い合わせ処理
器31が動作する計算機32に設けられたライブラリ部33と
メタデータ管理部34とから構成される。但し、データプ
ロバイダ35のように、メタデータインタフェースを持つ
データプロバイダの場合、メタデータ管理部は必要な
い。

【００４２】データプロバイダ35のように、データプロ
バイダがメタデータインタフェースを持つ場合、ライブ
ラリ部33はデータプロバイダ35のメタデータインタフェ
ースを使ってメタデータを獲得し、問い合わせ処理器31
に回答する。データプロバイダ36のように、データプロ
バイダがメタデータインタフェースを持たない場合、メ
タデータ管理部34で独自にメタデータを管理しておき、
ライブラリ部33からプロセス間通信によってメタデータ
を要求する。

【００４３】メタデータインタフェース提供手段11の第
３の形態は第２の形態と構成上は同様である。但し、ラ
イブラリ部とデータプロバイダとの間がプロセス間通信
となるか、プロセス内での関数呼び出しとなるかの違い
がある。

【００４４】集合データの性質を知るためのメタデータ
インタフェースの具体例を以下に示す。（１）EnumerateProvider() ……全てのデータプロバイ
ダを列挙する。（２）EnumerateTable(ProviderID)……データプロバイ
ダを指定し、そのプロバイダの管理する全ての集合デー
タを列挙する。（３）QueryTable(TableID) ……集合データを指定する
と、その属性名などを取り出せるインタフェースを持つ
オブジェクトを作る。（４）EnumerateAccPath(TableID) ……集合データ（テ
ーブル）を指定すると、そのテーブルに張られている全
てのアクセスパスを列挙する。

【００４５】上記（１）のメタデータインタフェースを
使用することにより、問い合わせ処理器は全てのデータ
プロバイダを知ることができる。前述した通り、例え
ば、或る名前のテーブルがどのデータプロバイダに含ま
れるかを聞いて回るためには、全てのデータプロバイダ
を事前に認識する必要があり、その際にこのメタデータ
インタフェースが利用される。このメタデータインタフ
ェースを利用する場合、ライブラリ部は全データプロバ
イダ向けのブロードキャスト型の通信を行い、通信を受
け取ったデータプロバイダはそのライブラリ部に応答を
返し、ライブラリ部は応答のあったものを現存するデー
タプロバイダと認識し、例えば０から始めるIDなどを順
番に付加して列挙し、問い合わせ処理器に返却する。な
お、図２，図３のように仲介部26、メタデータ管理部34
が介在する場合、それらが応答を返すことになる。

【００４６】上記（２）のメタデータインタフェースを
使用することにより、問い合わせ処理器は、１つのプロ
バイダで管理されている全ての集合データを知ることが
でき、全てのプロバイダについて事前にこのメタデータ
インタフェースを使用して集合データを列挙しておけ
ば、例えば、或る名前のテーブル（集合データ）がある
かどうかの調査が高速に行える。なお、集合データを列
挙するとは、例えば集合データの情報を管理する構造体
そのものを列挙すること、集合データの情報を格納した
記憶領域へのポインタを列挙すること、あるいは、集合
データの情報を提供するメソッドを備えるオブジェクト
のポイントを列挙すること等を意味する。このメタデー
タインタフェースを利用して、或るデータプロバイダの
管理する全テーブル（集合データ）を列挙する場合、ラ
イブラリ部は指定されたデータプロバイダに対して、何
かしらの通信手段によって全テーブルの情報を貰う要求
を出す。この要求を受け取ったデータプロバイダは、自
分の管理する全てのテーブルの情報をメタデータから取
り出して、決められたフォーマットでライブラリ部に返
却する。ライブラリ部は、それらの情報を問い合わせ処
理器のアドレス空間上の適当な記憶領域に格納した後、
テーブルの数を問い合わせ処理器に返す。なお、図２，
図３のように仲介部26、メタデータ管理部34が介在する
場合、それらが情報をライブラリ部に返却することにな
る。

【００４７】上記（３）のメタデータインタフェース
は、上記（２）のメタデータインタフェースによって列
挙された集合データを対象とし、その中から指定した集
合データの属性名などを取り出すために使用される。具
体的には、上記（１）のデータプロバイダ列挙と上記
（２）の集合データ列挙を行うことによって、問い合わ
せ処理器のアドレス空間上の記憶領域に全てのデータプ
ロバイダの全ての集合データの情報が展開されていると
すると、まず、その中から集合データの名前を探し（例
えば、記憶領域上を端からサーチする）、そのIDを特定
する。次に、集合データのIDを指定して上記（３）のイ
ンタフェースにより、その情報を取り出すオブジェクト
を作成する。このオブジェクトは問い合わせ処理器と同
じアドレス空間上に作成される。このオブジェクトに
は、集合データ（テーブル）の持つ属性の情報を得るイ
ンタフェースがあり、属性名を指定してその型を入手す
ることができる。同様に、そのテーブルの持つカラムの
数やカラムの名前などの情報も取り出すことができる。

【００４８】上記（４）のメタデータインタフェースを
使用することにより、問い合わせ処理器は、或るプロバ
イダで管理されている或る集合データに張られている全
てのアクセスパスを知ることができる。このメタデータ
インタフェースを利用して、或るデータプロバイダの管
理する或るテーブル（集合データ）のアクセスパスを列
挙する場合、ライブラリ部は指定されたデータプロバイ
ダに対して、何かしらの通信手段によって当該テーブル
に張られた全てのアクセスパスの情報を貰う要求を出
す。この要求を受け取ったデータプロバイダは、自分の
管理するそのテーブルに関するアクセスパスの情報をメ
タデータから取り出して、決められたフォーマットでラ
イブラリ部に返却する。ライブラリ部は、それらの情報
を問い合わせ処理器のアドレス空間上の適当な記憶領域
に格納した後、アクセスパスの数を問い合わせ処理器に
返す。なお、図２，図３のように仲介部26、メタデータ
管理部34が介在する場合、それらが情報をライブラリ部
に返却することになる。

【００４９】集合データ関数の性質を知るためのメタデ
ータインタフェースの具体例を以下に示す。（５）EnumerateFunc(ProviderID) （６）FuncID(Funcname) （７）QueryFunc(FuncID)

【００５０】上記（５）のメタデータインタフェースを
使用すれば、或るデータプロバイダの提供する集合デー
タ関数の情報を記憶領域に展開し、その数などを知るこ
とができる。また、上記（６）のメタデータインタフェ
ースを使用すれば、上記記憶領域上を見ていくことによ
って、或る名前の集合データ関数の情報が入っている記
憶領域を見つけ、関数IDを得ることができる。そして、
上記（７）のメタデータインタフェースを使用すれば、
或る関数の性質を得るインタフェースを備えるオブジェ
クトを作成し、後にこのオブジェクトのインタフェース
を利用することによって、集合データ関数の性質を得る
ことができる。

【００５１】次に、問い合わせ解析手段14の実施例につ
いて説明する。

【００５２】問い合わせ解析手段14は、まず、決められ
た問い合わせ構文に従って問い合わせ13の解析を行い、
問い合わせ構造モデル15の枠組みとなるデータモデルを
作成する。すなわち、問い合わせ構文に従って、ネスト
的な問い合わせでは副問い合わせを切り出し、集合デー
タの名前と考えられる語彙や、サーチ条件となる述語と
考えられる語句を切り出す。

【００５３】この時、図４に示すような問い合わせ構造
モデルの枠組みを作成する。問い合わせは、１つまたは
複数の集合データ、述語、出力形式を関連付けたデータ
構造を基本単位としてモデル化する。ネスト的な問い合
わせでは、前記基本単位をネスト的に接続する。すなわ
ち、ある問い合わせの集合データの１つを副問い合わせ
で置き替え、前記の基本単位を階層的に接続したデータ
構造を作成する。

【００５４】次に、問い合わせ解析手段14は、集合デー
タの名前や述語中に現れる関数の名前を手がかりにメタ
データインタフェース提供手段11を用いることによっ
て、型の整合性などを調べる。また、この時調べたメタ
データの値を問い合わせ構造モデル15に挿入していく。

【００５５】次に、実行表現変換手段16の実施例につい
て説明する。

【００５６】まず、実行表現変換手段16が出力する問い
合わせ実行表現17について説明する。問い合わせ実行表
現17は、図５に示すように、問い合わせを処理するため
の具体的な処理の流れを表現したものである。各ボック
ス51〜53は各データプロバイダ12が提供する集合データ
操作関数を示し、インデックスなどのアクセスパスを利
用したサーチ関数や、複数の集合データを結合する具体
的な結合処理関数を示す。各ボックス51〜53は入出力が
接続されており、一方のボックスから出力された集合デ
ータは、それを入力とするもう一方のボックスの示す集
合データ操作関数によって処理される。図５の例では、
集合データＡからボックス51のIndex Search関数によっ
て取り出された集合データが、ボックス53のNested−lo
op Join関数によって処理される。このように問い合わ
せ実行表現17は集合データ操作関数とその間で受け渡さ
れるデータの流れを表現する。

【００５７】実行表現変換手段16の簡単な実施の例で
は、問い合わせ構造モデル15中の副問い合わせ毎に実行
表現へ変換し、変換された副問い合わせごとの実行表現
を、問い合わせ構造モデル15に従って接続することによ
り、問い合わせ全体の実行表現を作成する。

【００５８】そこで、副問い合わせを実行表現に変換す
る処理の例について説明する。まず、副問い合わせを表
すデータモデルから述語を取り出し、論理積・論理和を
セパレータとして部分述語に分解する。この時、一般的
には述語全体をCNF (Conjunctive Normal Form) の形式
に変形してから、部分述語に分解する。この方法で分解
した場合の実施の例について説明する。

【００５９】まず、各部分述語に現れる集合データを調
べ、同一の集合データ、または同じ組み合わせの複数の
集合データが現れるような部分述語をまとめておく。

【００６０】最初に、同一の集合データが１つだけ現れ
る部分述語の各々について、利用可能なアクセスパスと
関数（インデックスサーチ関数など) を決定する。この
際、メタデータインタフェース提供手段11を用いてアク
セスパス、関数の候補を取り出し、組み合わせ可能なア
クセスパスと関数の組に対して各部分述語がサーチ条件
として適合するかどうかを調べ、適合するアクセスパス
と関数の組を選択する。

【００６１】例えば、部分述語が”A.attr=10 ”( 集合
データＡの属性attrが10に等しい)というようなサーチ
条件を表していた場合、まず、集合データＡに張られた
インデックスなどのアクセスパス、インデックスサーチ
関数などの関数を候補として取り出す。次に、組み合わ
せが可能なアクセスパスと関数の組について、前記の部
分述語をサーチ条件として指定できるかを調べ、指定可
能であれば、そのアクセスパスと関数の組を利用可能な
アクセスパスと関数の組として決定する。以下、アクセ
スパスと関数との組を、アクセスパス関数と呼ぶ。同一
のアクセスパス関数とは、使用するアクセスパスと使用
する関数が同じでものを言う。

【００６２】次に、同一のアクセスパス関数を使用でき
る複数の部分述語を論理積で結合して１つの述語として
まとめる。更に、そのアクセスパス関数を用いて集合デ
ータを取り出すボックスを１つ形成し、まとめた述語を
そのアクセスパス関数のサーチ条件として指定する。こ
れにより、使用可能なアクセスパス関数のボックスが形
成される。

【００６３】１つの集合データに関しても、部分述語に
よって使用可能なアクセスパス関数が異なる場合、複数
の異なるアクセスパス関数のボックスが形成される。つ
まり、１つの集合データに対して異なるアクセスパス関
数でサーチを行うこととなる。この場合、異なるアクセ
スパス関数でサーチされた集合データの共通要素となる
集合データを取り出す必要がある。そこで、各アクセス
パス関数のボックスの出力となる集合データを、集合積
(Intersection)によってマージするボックスを１つ形成
する。

【００６４】また、部分述語によっては使用できるアク
セスパス関数のない場合があり、上記の方法では、それ
らの部分述語をサーチ条件としたアクセスパス関数のボ
ックスは形成されない。そこで、これらの部分述語は、
集合データの全要素について部分述語が真となるかどう
かを調べ、真となる要素だけを抽出するフィルタ条件と
して作用させる。そのため、使用できるアクセスパス関
数のない複数の部分述語を論理積で結合して１つの述語
としてまとめる。更に、その述語の示すフィルタ条件に
よって集合データをフィルタするボックスを形成し、最
終段のボックスの出力に接続する。

【００６５】以上により、単一の集合データが現れる部
分述語について、図６に示すような問い合わせ実行表現
が形成される。図６の例では、４つの部分述語が同一の
集合データＡだけを含んでいる。部分述語”A.attr1=1
0”と”A.attr2=30”にはそれぞれ異なるアクセスパス
関数のボックス61，62が形成され、それらの出力がInte
rsectionというボックス63でマージされる。更に、2 つ
の部分述語”A.attr3 <30”と”A.attr4 > 100 ”を論
理積で接続したフィルタ条件によってフィルタするボッ
クス64が最終段に接続されている。

【００６６】図６に示したような問い合わせ実行表現は
集合データごとに１つ形成される。これを集合データア
クセス表現と呼ぶこととする。

【００６７】次に、複数の集合データの現れる部分述語
について問い合わせ実行表現を生成する方法について説
明する。

【００６８】まず、同じ組み合わせの集合データが現れ
る部分述語を論理積で接続し、これを結合条件とする結
合演算のボックスを形成する。結合演算のボックスの入
力は、結合条件に現れる集合データとなる。この時点で
集合データの組み合わせごとに１つの結合演算ボックス
が形成される。

【００６９】但し、同一の集合データが異なる複数の結
合演算ボックスの入力となる場合は、図７に示すよう
に、結合演算ボックスを多段に接続する。まず、重複す
る集合データをいずれか１つの結合演算ボックスの入力
とし、次に、その結合演算ボックスの出力を別の結合演
算ボックスの入力として多段に接続する。

【００７０】このようにして、複数の集合データが現れ
る述語から結合演算のボックスが形成される。次に、各
結合演算のボックスの入力に、前記した集合データアク
セス表現 (集合データが単一で現れる述語について生成
しておいた問い合わせ実行表現) を接続することによ
り、図５に示したような問い合わせ実行表現を生成す
る。

【００７１】以上により、１つの副問い合わせを実行表
現に変換することができる。上記は副問い合わせに含ま
れる述語をCNF 形式に変形した場合の処理を説明した
が、実施の方法はこの例にとらわれない。最終的に問い
合わせ全体の実行表現を生成するためには、副問い合わ
せごとに変換された実行表現を、問い合わせ構造モデル
に従って接続する。これにより、例えば、図８に示すよ
うな問い合わせ実行表現が得られる。

【００７２】以上は、副問い合わせごとに実行表現に変
換した後に接続する例を示したが、複数の副問い合わせ
を１つの問い合わせにマージするような処理を、変換の
前に行っても良い。

【００７３】次に問い合わせ実行手段18の実施例につい
て説明する。

【００７４】問い合わせ実行手段18では、問い合わせ実
行表現17の表わす問い合わせ実行フローに従って各関数
を呼び出す。図５に示した問い合わせ実行表現を例とし
て、問い合わせ実行手段18の実施例の動作について説明
する。

【００７５】問い合わせ実行手段18は複数のモジュール
から構成される。問い合わせ実行表現を構成する各ボッ
クスに対応して、そのボックスの処理を担当するモジュ
ールがあり、それらのモジュールの全てを制御する実行
制御モジュールがある。図５に示した問い合わせ実行表
現の例に対しては、問い合わせ実行手段18は図９に示す
ような構成となる。問い合わせ実行表現に応じたモジュ
ールの作成は、例えば、以下のように行われる。

【００７６】先ず、問い合わせ実行手段１８において、
実行制御モジュール91を作成し、問い合わせ実行表現17
をそのモジュール91に通知する。モジュール91は問い合
わせ実行表現17の最上段の関数（ボックス53）を担当す
るモジュール92を作成し、そのモジュール92に問い合わ
せ実行表現17を通知する。モジュール92は通知された問
い合わせ実行表現17の最上段の関数（ボックス53）を、
自分が担当する関数として把握する。次にモジュール92
は、問い合わせ実行表現17から、自分が担当する最上位
の関数（ボックス53）を取り除き、その下段の問い合わ
せ実行表現を作る。この場合、問い合わせ実行表現はボ
ックス51とボックス52との２つの問い合わせ実行表現に
分かれる。そこで、まず、その１つの問い合わせ実行表
現の最上段の関数（ボックス51）を担当するモジュール
93を作成し、その問い合わせ実行表現を通知する。モジ
ュール93は通知された問い合わせ実行表現の最上段の関
数（ボックス51）を、自分が担当する関数として把握す
る。次にモジュール93は、通知された問い合わせ実行表
現から自分が担当する最上位の関数（ボックス51）を取
り除くと、問い合わせ表現が空になるので、下段のモジ
ュールは作成しない。同様にモジュール92は、他方の問
い合わせ実行表現の最上段の関数（ボックス52）を担当
するモジュール94を作成し、その問い合わせ実行表現を
通知する。モジュール94は通知された問い合わせ実行表
現の最上段の関数（ボックス52）を、自分が担当する関
数として把握する。次にモジュール94は、通知された問
い合わせ実行表現から自分が担当する最上位の関数（ボ
ックス52）を取り除くと、問い合わせ表現が空になるの
で、下段のモジュールは作成しない。

【００７７】次に、図９に示す構成を基に実行時動作に
ついて説明する。実行制御モジュール91は、問い合わせ
実行表現の最上段のボックス53を担当する結合演算担当
モジュール92に対して処理内容を知らせる。更に、処理
内容は、次の段のボックス51，52を担当する２つのモジ
ュール(Index Search 担当モジュール93、Full Scan担
当モジュール94) に知らされる。

【００７８】最下段のボックス51，52を担当する2 つの
モジュール93，94に処理が知らされると、これらのモジ
ュール93，94は、そのボックス51，52の該当関数を用い
て集合データを読み出し、１つ１つのデータに対して処
理を行う。処理したデータは上段のボックス53を担当す
る結合演算担当モジュール92に渡す。更に、結合演算担
当モジュール92は、２つの下段モジュール93，94から渡
されたデータに対して、該当結合演算処理関数を呼び出
して処理を行う。処理されたデータは実行制御モジュー
ル91に渡される。

【００７９】最下段のボックス51，52を担当するモジュ
ール93，94において、全てのデータを処理し終わると、
処理の終了を上段のボックス53を担当するモジュール92
に知らせていく。最終的に実行制御モジュール91に処理
終了が知らされると、実行制御モジュール91は結果をま
とめ、問い合わせの処理を終了する。

【００８０】本発明の第２の実施形態の構成例を図１０
に示す。図１０において、図１と同一符号は同一部分を
示し、101 は実行表現候補生成手段、102 は問い合わせ
実行表現、103 は実行表現選択手段、104 は問い合わせ
実行表現である。この第２の実施形態は、図１に示され
る第１の実施形態における実行表現変換手段16を、実行
表現候補生成手段101 と実行表現選択手段103 に置き換
えたものである。

【００８１】問い合わせ解析手段14によって生成された
問い合わせ構造モデル15は、実行表現候補生成手段101
に入力され、複数の問い合わせ実行表現102 に変換され
る。同じ問い合わせでも、複数の実行フローが考えられ
るため、この段階で複数の候補を生成しておく。なお、
問い合わせ構造モデル15から問い合わせ実行表現102を
生成する変換ルールは、ルールとして明確に切り出され
ている訳ではなく、従来の問い合わせのオプティマイザ
と同様に或る構造モデルを与えると固定的に実行表現を
生成するルーチン（プログラム）として実行表現候補生
成手段101 にコード化されている。勿論、後述する第３
の実施形態と同様に（但し、唯一の変換ルールだけであ
るが）、変換ルールを使用する構成であっても良い。

【００８２】更に、実行表現選択手段103 によって、問
い合わせ実行表現102 の複数の候補から１つが選択され
る。通常は、各集合データの要素数や選択率などを基
に、処理されるデータ数などを予測し（コスト計算) 、
問い合わせの処理時間を最短にするような問い合わせ実
行表現104 を選択する。

【００８３】選択した問い合わせ実行表現104 は問い合
わせ実行手段18に入力され、実行される。

【００８４】次に、実行表現候補生成手段101 及び実行
表現選択手段103 の実施例について説明する。

【００８５】本発明の第１の実施形態における実行表現
変換手段16の問い合わせ実行表現17を生成する過程で
は、いくつかの選択肢を生成することがある。例えば、
使用できるアクセスパス関数を決定する過程では、述語
によっては複数のアクセスパス関数が候補として挙がる
ことも考えられる。あるいは、前述した実行表現変換手
段16の実施例では、述語をCNF 形式に変換してから部分
述語への分解を行ったが、DNF 形式へ変換したり、変換
を行わないなどいくつか手法の選択肢がある。実行表現
候補生成手段101 は、複数の選択肢を生成する場面で、
各選択肢を記録しておき、それぞれについて問い合わせ
実行表現102 を生成していく点が、実行表現変換手段16
と相違する。そして、最終的に、複数の問い合わせ実行
表現102 を生成し、候補として出力する。

【００８６】実行表現選択手段103 は複数の問い合わせ
実行表現102 を入力とし、各問い合わせ実行表現102 に
ついて何らかの基準で評価を行い、比較する。比較の結
果、最善と考えられる１つの問い合わせ実行表現104 を
選択し、問い合わせ実行手段18に出力する。前述したよ
うに、通常は処理時間を最短にするものが選択される
が、リソース(CPUやディスクなど) の使用量(CPU消費時
間やディスクI/O の回数など) を最小にするものを選択
することも考えられる。

【００８７】ここでは、ディスクI/O 回数を最小にする
ものを選択する例について説明する。すなわち、問い合
わせ実行表現を構成するボックスの内、アクセスパス関
数を示すボックスの各々についてディスクI/O 回数を予
測して総計し、各問い合わせ実行表現102 について総デ
ィスクI/O 回数を見積もる。ディスクI/O 回数について
は、メタデータインタフェース提供手段11を介して予測
値を得る。このため、各アクセスパスに対し、予想ディ
スクI/O 回数を知るためのインタフェースを事前に用意
し、実行表現選択手段103 からそのインタフェースを利
用する。

【００８８】前述したようにEnumerateAccPath(TableI
D) によって問い合わせ処理器のアドレス空間中にアク
セスパスの情報が展開される。そこで、その中から注目
したいアクセスパスの名前を探し、そのIDを特定する。
次に、アクセスパスのIDを指定して、例えばQueryAccPa
th(AccPathID) などのインタフェースにより、その情報
を取り出すオブジェクトを作成する。このオブジェクト
は問い合わせ処理器と同じアドレス空間上に作成され
る。このオブジェクトには、ディスクI/O 回数を取り出
せるインタフェースがあり、そのインタフェースに述語
を渡してディスクI/O 回数を取り出す。ディスクI/O 回
数を知るためにアクセスパス毎に用意されたインタフェ
ースでは、例えば、次のようにしてディスクI/O 回数を
予測し、結果を返す。例えば、アクセスパスが B−Tree
インデックスで、述語が”A.attr=10”のような等式に
よるサーチ条件であった場合、インデックスの段数がデ
ィスクI/O 回数となる。これは、１ページに記録される
インデックスの数と集合データに含まれる要素数から決
定される。

【００８９】実行表現選択手段103 は、問い合わせ実行
表現102 ごとに、ディスクI/O 回数の合計を算出した結
果、ディスクI/O 回数の最も少ない問い合わせ実行表現
を特定し、問い合わせ実行手段18に渡す。

【００９０】本発明の第３の実施形態の構成例を図１１
に示す。図１１において、図１０と同一符号は同一部分
を示し、111 は変換規則格納手段、112 は変換規則ファ
イル、113 は規則参照変換手段、114 は問い合わせ実行
表現である。この第３の実施形態は、図１０の第２の実
施形態における実行表現候補生成手段101 を規則参照変
換手段113 に置き換え、新たに複数の変換規則ファイル
112 と変換規則格納手段111 を設けたものである。

【００９１】問い合わせ構造モデル15から問い合わせ実
行表現114 を生成するための変換規則は、複数用意され
ている。例えば、どのアクセスパス関数を利用するかを
選択する場合、Ｉ/O回数が最小になるものを選んだり、
あるいは別の観点（平均処理時間など）を基に決める方
法などがある。本実施形態では、このような最適化の観
点の違いに応じた最適化ルールを含む変換規則が複数用
意されている。

【００９２】変換規則は、変換規則格納手段111 を介し
て、複数存在する変換規則ファイル112 の内のユーザに
よって指定されたファイルに格納される。変換規則格納
手段111 を介して、指定した変換規則ファイル112 に対
し変換ルールの追加・変更を行うことも可能である。

【００９３】問い合わせ解析手段14によって生成された
問い合わせ構造モデル15は、規則参照変換手段113 に入
力され、複数の問い合わせ実行表現114 に変換される。
この時、規則参照変換手段113 は、指定された変換規則
ファイル112 に格納されている変換ルールを参照しなが
ら問い合わせ実行表現114 への変換を行う。

【００９４】規則参照変換手段113 によって生成された
複数の問い合わせ実行表現114 の候補は、実行表現選択
手段103 に入力され、１つの問い合わせ実行表現104 が
選ばれる。選ばれた問い合わせ実行表現104 は問い合わ
せ実行手段18に入力され、処理される。

【００９５】変換規則格納手段111 の最も簡単な例は、
テキストファイルを編集するテキストエディタである。
この場合、変換ルールはテキストで表現され、変換規則
ファイル112 はテキスト形式のファイルとなる。利用者
は、テキストエディタを介して変換ルールの追加・変更
を自由にできる。但し、テキスト形式の変換ルールは、
所定の記述方式に従って書かれる。

【００９６】変換ルールは、例えば、以下のように変換
元となるパターン(pattern) と、変換によって生成する
複数のパターン(pattern1, pattern2)とを組にして記述
する。ここで言うパターンとは、問い合わせ実行表現中
に現れる表現のパターンであり、以下の変換ルールで
は、ある表現パターン(pattern) を別の表現パターン(p
attern1 またはpattern2) に変換するためのルールを意
味する。 pattern : ｛ pattern1 ｜ pattern2 ｝

【００９７】この記述形式では、述語のCNF 化など、論
理和・積のパターンだけで変換できる場合を記述でき
る。しかし、有効なアクセスパス関数を決定するなど、
メタデータを調べる必要のある変換ルールは上記の記述
形態では難しい。そこで、以下のように、変換元となる
パターン(pattern) と、そのパターンを発見した際に処
理すべきコマンドの列(command1, command2)を組み合わ
せた記述形式が考えられる。 pattern : ｛ command1; command2; ・・｝

【００９８】ここで、上記コマンドとして、メタデータ
参照を行って有効なアクセスパス関数を決定するような
コマンドを使えば、上記表現により問い合わせ実行表現
を生成する変換ルールをユーザがきめ細かく記述でき
る。即ち、メタデータを使った最適化ルールなどをユー
ザが記述することができる。

【００９９】次に上記の変換ルールを参照して、規則参
照変換手段113 がどのように動作するかを説明する。

【０１００】規則参照変換手段113 は、問い合わせの投
入時などに指定された変換規則ファイル112 を読み込
み、そこに記述された変換ルールを取り込む。なお、変
換規則ファイル112 の指定は、例えば、問い合わせを投
入する際に、問い合わせ文と変換規則ファイル112 の名
前とを組にして、以下のように指定する。 ExecQuery( Query, RuleFile); 但し、Query: 問い合わせ文の入った記憶領域のポイン
タ RuleFile; 変換規則ファイルの識別子

【０１０１】規則参照変換手段113 は、問い合わせ構造
モデル15に対して、各変換ルールが適合するかどうか順
次調べていく。すなわち、問い合わせ構造モデル15中
に、各変換ルールの左辺に記述されているパターンに相
当する構造が、あるかどうかを調べていく。

【０１０２】適合する変換ルールがあれば、その変換ル
ールの右辺にあるコマンドを実行する。コマンドとして
は、述語の変形、有効なアクセスパスの取り出し、条件
判定、問い合わせ実行表現の生成など各種コマンドが用
意される。

【０１０３】複数の変換ルールが適合していた場合、処
理を分岐させ、複数の問い合わせ実行表現114 を生成す
る。規則参照変換手段113 は、全コマンドを処理すると
終了し、この間に生成した複数の問い合わせ実行表現11
4 を出力する。

【０１０４】

【発明の効果】以上説明したように本発明によれば、集
合データ演算機能を提供する複数のデータプロバイダに
対し、統合的な集合データ演算を指示した問い合わせを
処理する問い合わせ処理器において、問い合わせ処理器
のプログラムを変更することなく、データプロバイダの
提供するデータ操作関数の追加・変更を行うことが可能
となる。

【０１０５】また、請求項３，６記載の発明にあって
は、更に、問い合わせを実行するためのフローを生成す
る最適化ルールを拡張可能、すなわち、問い合わせ処理
器のプログラム自体を変更することなく、追加・変更す
ることが可能となる。更に、ユーザは個別に最適化ルー
ルを定義・格納した変換規則ファイルを指定することが
でき、ユーザ固有の最適化ルールに従った変換を行って
問い合わせ実行表現を生成することが可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態の構成例を示すブロッ
ク図である。

【図２】メタデータインタフェース提供手段の一実施例
を示すブロック図である。

【図３】メタデータインタフェース提供手段の別の実施
例を示すブロック図である。

【図４】問い合わせ構造モデルの構成例を示す図であ
る。

【図５】問い合わせ実行表現の構成例を示す図である。

【図６】１つの集合データに対する問い合わせ実行表現
の例を示す図である。

【図７】結合演算を多段にした問い合わせ実行表現の例
を示す図である。

【図８】副問い合わせを接続した問い合わせ実行表現の
例を示す図である。

【図９】問い合わせ実行手段の構成例を示すブロック図
である。

【図１０】本発明の第２の実施形態の構成例を示すブロ
ック図である。

【図１１】本発明の第３の実施形態の構成例を示すブロ
ック図である。

【符号の説明】

11…メタデータインタフェース提供手段 12…データプロバイダ 13…問い合わせ 14…問い合わせ解析手段 15…問い合わせ構造モデル 16…実行表現変換手段 17,102,104,114…問い合わせ実行表現 18…問い合わせ実行手段 19…集合データ操作関数 101 …実行表現候補生成手段 103 …実行表現選択手段 111 …変換規則格納手段 112 …変換規則ファイル 113 …規則参照変換手段

フロントページの続き (72)発明者北澤敦東京都江東区新木場一丁目18番６号日本電気ソフトウェア株式会社内Ｆターム(参考） 5B075 ND16 PP30 QR01 QR04 QR05 QT03 QT06 5B082 GA03 GA08

Claims

【特許請求の範囲】

【請求項１】集合データ演算機能を提供するデータプ
ロバイダに対する問い合わせ文を処理する問合わせ処理
器であって、各データプロバイダに関するメタデータを
参照するための統一したインタフェースを提供するメタ
データインタフェース提供手段を各データプロバイダ毎
に備えることを特徴とする拡張可能問い合わせ処理器。
【請求項２】前記メタデータは、各データプロバイダ
の持つ集合データの性質及び各データプロバイダが提供
する集合データ関数の性質を含むことを特徴とする請求
項１記載の拡張可能問い合わせ処理器。
【請求項３】問い合わせの最適化ルールを指定された
ファイルに格納する格納手段と、問い合わせ時に指定さ
れたファイルに格納された最適化ルールに基づいて問い
合わせの実行フローを生成する手段とを備えることを特
徴とする請求項２記載の拡張可能問い合わせ処理器。
【請求項４】集合データ演算機能を提供するデータプ
ロバイダに対する問い合わせ文を処理する問合わせ処理
器であって、データプロバイダ毎に存在し、各データプロバイダの持
つ集合データの性質及び各データプロバイダが提供する
集合データ関数の性質を知るための統一したインタフェ
ースを提供するメタデータインタフェース提供手段と、前記メタデータインタフェース提供手段を利用し、入力
された問い合わせ文の構文・意味解析を行い、問い合わ
せに関する集合データと集合データ演算処理の関係を表
現した問い合わせ構造モデルを作成する問い合わせ解析
手段と、前記メタデータインタフェース提供手段を利用し、問い
合わせ構造モデルから、各データプロバイダの持つ具体
的な集合データ操作関数と各集合データ操作関数の間で
受け渡しするデータの流れを表現した問い合わせ実行表
現を生成する実行表現変換手段と、問い合わせ実行表現に示された実行フローに従って、各
データプロバイダを呼び出して問い合わせを実行する問
い合わせ実行手段とを備えることを特徴とする拡張可能
問い合わせ処理器。
【請求項５】集合データ演算機能を提供するデータプ
ロバイダに対する問い合わせ文を処理する問合わせ処理
器であって、データプロバイダ毎に存在し、各データプロバイダの持
つ集合データの性質及び各データプロバイダが提供する
集合データ関数の性質を知るための統一したインタフェ
ースを提供するメタデータインタフェース提供手段と、前記メタデータインタフェース提供手段を利用し、入力
された問い合わせ文の構文・意味解析を行い、問い合わ
せに関する集合データと集合データ演算処理の関係を表
現した問い合わせ構造モデルを作成する問い合わせ解析
手段と、前記メタデータインタフェース提供手段を利用し、問い
合わせ構造モデルから、各データプロバイダの持つ具体
的な集合データ操作関数と各集合データ操作関数の間で
受け渡しするデータの流れを表現した複数の問い合わせ
実行表現の候補を生成する実行表現候補生成手段と、前記メタデータインタフェース提供手段を利用し、前記
実行表現候補生成手段によって生成された複数の問い合
わせ実行表現の候補から１つの問い合わせ実行表現を選
出する実行表現選択手段と、前記選出された問い合わせ実行表現に示された実行フロ
ーに従って、各データプロバイダを呼び出して問い合わ
せを実行する問い合わせ実行手段とを備えることを特徴
とする拡張可能問い合わせ処理器。
【請求項６】集合データ演算機能を提供するデータプ
ロバイダに対する問い合わせ文を処理する問合わせ処理
器であって、データプロバイダ毎に存在し、各データプロバイダの持
つ集合データの性質及び各データプロバイダが提供する
集合データ関数の性質を知るための統一したインタフェ
ースを提供するメタデータインタフェース提供手段と、前記メタデータインタフェース提供手段を利用し、入力
された問い合わせ文の構文・意味解析を行い、問い合わ
せに関する集合データと集合データ演算処理の関係を表
現した問い合わせ構造モデルを作成する問い合わせ解析
手段と、問い合わせ構造モデルを問い合わせ実行表現に変換する
ための変換規則を、指示された変換規則ファイルに格納
する変換規則格納手段と、前記メタデータインタフェース提供手段を利用し、指示
された変換規則ファイルに格納された変換規則に基づい
て、問い合わせ構造モデルから、各データプロバイダの
持つ具体的な集合データ操作関数と各集合データ操作関
数の間で受け渡しするデータの流れを表現した複数の問
い合わせ実行表現の候補を生成する規則参照変換手段
と、前記メタデータインタフェース提供手段を利用し、前記
規則参照変換手段によって生成された複数の問い合わせ
実行表現の候補から１つの問い合わせ実行表現を選出す
る実行表現選択手段と、前記選出された問い合わせ実行表現に示された実行フロ
ーに従って、各データプロバイダを呼び出して問い合わ
せを実行する問い合わせ実行手段とを備えることを特徴
とする拡張可能問い合わせ処理器。