JP3640346B2 - データベース管理システムにおける集合述部および検索 - Google Patents
データベース管理システムにおける集合述部および検索 Download PDFInfo
- Publication number
- JP3640346B2 JP3640346B2 JP2001034814A JP2001034814A JP3640346B2 JP 3640346 B2 JP3640346 B2 JP 3640346B2 JP 2001034814 A JP2001034814 A JP 2001034814A JP 2001034814 A JP2001034814 A JP 2001034814A JP 3640346 B2 JP3640346 B2 JP 3640346B2
- Authority
- JP
- Japan
- Prior art keywords
- group
- computer
- predicate
- round radius
- tuple
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
- G06F16/244—Grouping and aggregation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24547—Optimisations to support specific applications; Extensibility of optimisers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24554—Unary operations; Data partitioning operations
- G06F16/24556—Aggregation; Duplicate elimination
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99937—Sorting
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、全般的にはコンピュータ実施されるデータベース管理システムに関し、具体的には、データベース管理システムの集合述部（aggregate predicate）および検索に関する。
【０００２】
【従来の技術】
データベースとは、コンピュータ化された情報記憶システムおよび情報検索システムである。たとえば、リレーショナル・データベース管理システム（ＲＤＢＭＳ）は、データの記憶および検索に関係技法を使用するデータベース管理システム（ＤＢＭＳ）である。リレーショナル・データベースは、データの行および列からなる物理テーブルに編成される。行は、形式的にはタプルまたはレコードと呼ばれる。データベースは、通常、多数の物理テーブルを有し、各物理テーブルが、通常は複数のタプルおよび複数の列を有する。物理テーブルは、通常は、半永久的な記憶のために磁気ディスク・ドライブまたは光ディスク・ドライブなどのランダム・アクセス記憶装置（ＲＡＳＤ）に格納される。
【０００３】
さらに、論理テーブルまたは「ビュー」を、物理テーブルに基づいて生成し、データベースを見る特定の方法を提供することができる。ビューによって、データベースの物理編成に影響せずに、行をある順序で配置することができる。
【０００４】
既存のデータベース・システムでは、集合述部サポートが使用可能でない。しかし、多くの応用分野が、集合述部を使用する検索機能を必要とする。たとえば、集合述部は、下記の状況に必要である。
・画像または文書に対する類似性検索。
・空間的オブジェクトに対する最近隣（nearest neighbor）検索。
【０００５】
既存のデータベース・システムでは、ユーザは、標準の関係演算子（＜、＜＝、＝、＜＞、＞、＞＝）および論理演算子（and、or、not）を使用することによって、照会の結果を制限することができる。これらの関係演算子および論理演算子のほかに、International Business Machines, CorporationのＤＢ２（登録商標）などのオブジェクト・リレーショナル・データベースでは、ユーザが、照会に使用することができ、照会最適化プログラムによって利用することができる述部を定義することができる。Ｗ．チェン（Chen）、Ｊ．−Ｈ．チョウ（Chow）、Ｙ．−Ｃ．ユウ（You）、Ｊ．グランボア（Grandbois）、Ｍ．ジョウ（Jou）、Ｎ．マットス（Mattos）、Ｂ．トラン（Tran）、Ｙ．ウォン（Wang）著、「High Level Indexing of User-Defined Types」、Proceedings of the 25th International Conference on Very Large Data Bases、Edinburgh、１９９９年９月、第５５４〜５６４ページ。
【０００６】
これらの述部は、他の個々の値から独立な、個々の値について真または偽になるスカラ述部である。たとえば、distance (customer.location、store.location) < 5などの条件を検討されたい。このdistance（距離）条件の場合、customer（顧客）およびstore（店舗）のlocation（位置）の任意の対に対して、distance条件によって、他の顧客または店舗の位置とは独立に、顧客の位置と店舗の位置の間の距離が５未満であるか否かが評価される（すなわち、条件が真または偽のいずれかとして評価される）。
【０００７】
既存のデータベース・システムは、スカラ関数と少数の総計関数の両方をサポートする。たとえば、スカラ関数の例が、abs（絶対値を返す）およびsqrt（引数の平方根を返す）である。総計関数は、値の集合（すなわち列）を操作し、スカラ値を返す。総計関数の例には、max（列内の最大の非ヌル値を返す）、min（列内の最小の非ヌル値を返す）、およびavg（列内の非ヌル値の平均を返す）が含まれる。スカラ関数と総計関数の主な相違は、総計関数が値の組を操作するのに対して、スカラ関数が引数として個々の値だけをとることである。最近、総計関数が、オンライン分析処理（ＯＬＡＰ）関数に一般化された。Ｆ．ゼムケ（Zemke）、Ｋ．クルカーニ（Kulkarni）、Ａ．ウィトカウスキ（Witkowski）、Ｂ．ライル（Lyle）著、「Introduction to OLAP Functions」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ３２ ＷＧ３−ＹＧＪ−ｎｎｎ、ＡＮＳＩ ＮＣＩＴＳ Ｈ２−９９−１５４、１９９９年４月１２日。ＯＬＡＰ関数は、総計関数である。ＯＬＡＰ関数の呼出しのそれぞれは、ＯＬＡＰ関数が適用される値の組を指定する関連ウィンドウを有する。
【０００８】
関数とは異なり、既存のデータベース・システムは、値の所与の組に関して個々の値の真または偽になる集合述部をサポートしない。多くの実世界の応用分野が、集合述部を必要とする。下記は、一般的な例の一部にすぎない。
１．所与の画像に似ている上位１０個の画像を見つける。
２．ある家に最も近い上位５個の断層はどれか。
３．所与の位置に最も近い病院はどれか。
４．各店舗について、先月の売上上位１０位までの製品を見つける。
【０００９】
これらの例は、いくつかの共通の態様を共有する。第１に、例のそれぞれに、集合述部が含まれる。たとえば、所与の位置に対する相対的な他の病院の位置と比較しなければ、ある病院がその所与の位置に最も近いかどうかを判定することはできない。第２に、例のすべてが、集合述部に基づく検索を必要とする。言い換えると、目標は、所与の病院がある位置に最も近いかどうかを知るために検査することではない。そうではなくて、所与の位置に最も近い病院（おそらくは多数の病院のグループから）を探しているのである。
【００１０】
【発明が解決しようとする課題】
したがって、当技術分野には、既存のデータベース・システムに集合述部を導入し、集合述部に基づく検索を可能にすることの必要が存在する。
【００１１】
【課題を解決するための手段】
上で説明した従来技術の制限を克服し、本明細書を読み、理解した後に明白になる他の制限を克服するために、本発明は、データベース管理システム内で集合述部および検索を可能にする、コンピュータ実施される技法のための方法、装置、および製造品を開示する。
【００１２】
本発明によれば、コンピュータ内でステートメントを実行して、コンピュータに接続されたデータ・ストア内のデータを操作する。まず、集合述部を有するステートメントを受け取る。その後、ステートメントを評価する時に、集合述部を処理してランク・データにする。さらに、評価には、早期終了（early termination）を有する拡張ソート演算子の実行が含まれる。
【００１３】
これから図面を参照するが、図では、同様の符号が図を通じて対応する部分を表す。
【００１４】
【発明の実施の形態】
本発明の実施形態の以下の説明では、本明細書の一部を形成し、本発明を実施することができる具体的な実施形態を例として示す添付図面を参照する。本発明の範囲から逸脱せずに構造的変更を行うことができるので、他の実施形態を使用することができることを理解されたい。
【００１５】
ハードウェア環境
図１に、本発明に従って使用することができる例示的コンピュータ・ハードウェア環境を示す。この例示的環境では、コンピュータ・システム１０２は、ハード・ディスク・ドライブ、フロッピ・ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、テープ・ドライブ、または他の装置など、１つまたは複数のリレーショナル・データベースを記憶する、１つまたは複数のデータ記憶装置１０４に接続された１つまたは複数のプロセッサからなる。
【００１６】
コンピュータ・システム１０２のオペレータは、標準的なオペレータ・インターフェース１０６を使用して、照会と称する、データベースに対するさまざまな検索機能および取出機能を実行するコマンドを表す電気信号を、コンピュータ・システム１０２との間で送受する。本発明の１実施形態では、これらの照会が、構造化照会言語（ＳＱＬ）標準規格に従い、リレーショナル・データベース管理システム（ＲＤＢＭＳ）ソフトウェアによって実行される機能を呼び出す。
【００１７】
ＳＱＬインターフェースは、ＲＤＢＭＳソフトウェアの標準言語に進化し、したがって、米国規格協会（ＡＮＳＩ）および国際標準化機構（ＩＳＯ）の両方によって採用されている。ＳＱＬインターフェースによって、ユーザが、対話的に、バッチ・ファイルで、またはＣおよびＣＯＢＯＬなどのホスト言語に埋め込んでのいずれかで、テーブルに対する関係演算を定式化できるようになる。ＳＱＬによって、ユーザがデータを操作できるようになる。
【００１８】
本発明の好ましい実施形態では、ＲＤＢＭＳソフトウェアに、International Business Machines, Corporationが提供するＤＢ２（登録商標）for Universal Database（ＵＤＢ）製品が含まれる。しかし、本発明が、すべてのデータベース・ソフトウェアに対する応用性を有することを、当業者は理解するであろう。
【００１９】
ＳＱＬステートメントが実行のために準備される時に、ＵＤＢ最適化プログラムが、ステートメントを分析し、要求を満足する代替方法を検討し、各代替案のコストを見積もり、最も低いコスト（処理要件および入出力要件に関して）を有する代替案を選択する。これを行う際に、最適化プログラムは、ステートメント実行のためのアクセス・プランを生成する。このアクセス・プランによって、要求を満足する方法（たとえば、索引を使用するか２つのテーブルからデータを結合することによるなど）が示される。アクセス・プランは、しばしば、１つまたは複数のテーブルまたは索引から処理ノード（たとえば結合ノード）を介して元のＳＱＬステートメントを満足する結果セットへデータがどのように流れるかを示すグラフとして示すことができる。
【００２０】
ＤＢ２（登録商標）ｆｏｒ ＵＤＢシステムの中心に、データベース・サービス・モジュール１０８がある。データベース・サービス・モジュール１０８には、リレーショナル・データベース・サービス（ＲＤＳ）１１０、データ・マネージャ１１２、バッファ・マネージャ１１４、およびＳＱＬコンパイラ／インタープリタなどの他のコンポーネント１１６を含む複数のサブモジュールが含まれる。これらのサブモジュールは、ＳＱＬ言語の機能すなわち、ユーザ・データおよびシステム・データの定義、アクセス制御、解釈、コンパイル、データベース検索、および更新をサポートする。
【００２１】
本発明は、全般的に、データベース・サービス・モジュール１０８の制御下で実行されるＳＱＬステートメントを使用して実施される。データベース・サービス・モジュール１０８は、ＳＱＬステートメントを取り出すか受け取り、このＳＱＬステートメントは、一般に、データ記憶装置１０４にテキスト・ファイルとして格納されるか、オペレータ・インターフェース１０６を介してモニタ１１８の前のオペレータによってコンピュータ・システム１０２に対話的に入力される。データベース・サービス・モジュール１０８は、コンピュータ・システム１０２による実行のためにＳＱＬステートメントから命令を導出または合成する。
【００２２】
一般に、ＲＤＢＭＳソフトウェア、ＳＱＬステートメント、およびそれから導出される命令のすべてが、たとえば１つまたは複数のデータ記憶装置１０４などのコンピュータ可読媒体内で具体的に実施される。さらに、ＲＤＢＭＳソフトウェア、ＳＱＬステートメント、およびそれから導出される命令のすべてが、コンピュータ・システム１０２によって読み取られ実行される時に、本発明を実施するか使用するのに必要なステップをコンピュータ・システム１０２に実行させる命令からなる。オペレーティング・システムの制御下で、ＲＤＢＭＳソフトウェア、ＳＱＬステートメント、およびそれから導出される命令を、実際の動作中に使用するためにデータ記憶装置１０４からコンピュータ・システム１０２のメモリにロードすることができる。
【００２３】
したがって、本発明は、標準的なプログラミング技法またはエンジニアリング技法もしくはその両方を使用して、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せを作る方法、装置、または製造品として実施することができる。本明細書で使用する用語「製造品」（または、その代替として「コンピュータ・プログラム製品」）は、すべてのコンピュータ可読装置、担体、または媒体からアクセス可能なコンピュータ・プログラムを含むことが意図されている。もちろん、当業者は、本発明の範囲から逸脱せずに、この構成に多数の変更を行うことができることを理解するであろう。
【００２４】
当業者は、図１に示された例示的環境が、本発明を制限する目的でないことを理解するであろう。実際、当業者は、本発明の範囲から逸脱せずに、他の代替ハードウェア環境を使用することができることを理解するであろう。
【００２５】
図２は、ＳＱＬステートメントを評価する処理を示す図である。ＳＱＬプログラム２００に、ＳＱＬステートメントが含まれる。コンパイラ２０２が、ＳＱＬプログラム２００を解釈済みコード２０４にコンパイルする。解釈済みコード２０４およびデータベース・ランタイム・ライブラリ２０６（たとえば、ストアド・プロシージャおよびユーティリティを含む）が、インタープリタ２０８に入力される。インタープリタ２０８の出力は、リレーショナル・データベース・マネージャ２１０にアクセスし、ＳＱＬステートメントによって要求されたデータをデータベース２１２から取り出すのに使用される。本発明の１実施形態では、本発明の一部が、コンパイラ内に常駐し、集合述部を含むＳＱＬステートメントをコンパイルして、拡張ソート演算子を含むアクセス・プランを形成する。
【００２６】
データベース管理システム内での集合述部および検索
本発明は、集合述部のための構文を提供する。さらに、本発明は、集合述部検索のためのアクセス技法を提供する。
【００２７】
具体的に言うと、ＳＱＬ言語は、ＳＱＬ照会またはＳＱＬステートメントに検索条件を含める能力を備える。検索条件（たとえばｘ＜５）は、ブール値をもたらす。本発明は、ＳＱＬステートメントの検索条件（たとえばＷＨＥＲＥ文節またはＨＡＶＩＮＧ文節）に含めることができる集合述部を定義することによって、ＳＱＬ言語を拡張する。ランク演算子を定義した後に、ＳＱＬ言語用のコンパイラが、そのランク演算子を処理できなければならない。したがって、本発明は、コンパイラが集合述部を含むＳＱＬステートメントのアクセス・プランに含めるrk_sort演算（すなわち、拡張されたソート操作）も提供する。
【００２８】
以下の説明は、次のように編成されている。
Ａ．データベース・システムへの集合述部の導入
Ｂ．集合述部の言語およびセマンティクス
Ｃ．集合述部検索のための拡張された索引方法およびアクセス方法
Ｄ．照会の例
Ｅ．流れ図
Ｆ．要約と本発明の追加の長所
【００２９】
Ａ．データベース・システムへの集合述部の導入
本発明は、いくつかの点でＤＢＭＳ（データ・ベース管理システム）での集合述部および検索に貢献する。第１に、本発明は、集合述部という概念によってＤＢＭＳで使用されるＳＱＬを拡張する。集合述部は、照会で従来のスカラ述部（すなわち関係演算子および論理演算子）と同一の形で使用することができる。第２に、本発明によって、集合述部のための柔軟な言語機構が設計される。集合述部は、プリミティブ述部または複合述部（論理演算子を伴う）のいずれかとすることができる。集合述部は、ウィンドウ指定によって決定される値の組を操作する。
【００３０】
第３に、本発明によって、明示的な束縛のないランク付き増分検索と、具体的な束縛（上位１０位など）を有するランク付き増分検索の両方をサポートする、集合述部のためのラン・タイム照会実行戦略が設計される。集合述部に基づいて検索を近似しようとするのではなく、本発明の戦略では、正しく集合述部に基づく検索の結果を計算する。
【００３１】
第４に、本発明によって、集合述部のランクがシステム定義関数だけを使用して計算される時の集合述部のための索引付け最適化戦略および照会最適化戦略が設計される。最後に、本発明によって、ランクがユーザ定義関数によって計算される集合述部のために索引付け最適化戦略および照会最適化戦略が拡張される。本発明は、集合述部に関する拡張可能な索引付けをサポートする。
【００３２】
本発明の使用には、以下を含む複数の長所がある。
・照会言語の機能強化された表現力。
・多くの応用分野に関する性能改善。
・データベース・システムのより広い適用度。
・集合述部に関するユーザ定義の検索技法。
【００３３】
本発明の主要な長所は、ユーザが、データベース・アプリケーションで集合述部に基づく検索を実行でき、よりよい性能を得ることができることである。より具体的な長所を、下で示す。
【００３４】
第１に、集合述部のＳＱＬ言語への導入は、ユーザに機能強化された表現力を与える。ユーザは、ＳＱＬ言語によって提供される総計関数を呼び出すアプリケーション・プログラムまたはストアド・プロシージャを使用して多少の集合述部をシミュレートすることができる可能性があるが、そのような手法は、使用可能度の問題と性能の問題を有する。これは、総計関数および集合述部が、異なる目的のために働くからである。総計関数の目的は、max、min、avg、count、またはoutなど、値の組に対してスカラ値を計算することである。集合述部の目的は、特定の集合特性を満足する値を検索することである。総計関数を用いると、使用可能度に関して、ユーザが上位５つの最も近いレストランを探したい場合に、ユーザは、レストランのランキングのデータを格納する明示的な列を作成した後に、その明示的なランキング列に対する条件を作成しなければならない。性能に関して、総計関数は、必ず計算される。その一方で、集合述部に基づく検索は、そのような計算を回避するか、制限することができる。
【００３５】
第２に、集合述部に基づく検索を直接にサポートすることによって、本発明は、多くの応用分野で性能改善をもたらすことができる。集合述部を評価する単純な手法は、集合述部のすべての可能な候補のランキングを計算し、その後、集合述部を満足する候補だけを選択することである。たとえば、上位５位までの最も近いレストランを見つけるには、単純な手法では、現在位置とすべてのレストランの位置との間の距離を計算し、その後、最短距離を用いて上位５つの最も近いレストランを選択することになる。本発明の１実施形態は、回答の正しさを保証しながら検索空間を制限する、集合述部のための検索機構を提供する。
【００３６】
第３に、本発明は、従来のスカラ述部（関係演算子および論理演算子）と集合述部の均一な取扱を提供する。その結果、索引付けおよび照会の最適化の既存のフレームワークを、集合述部に一般化することができる。たとえば、ローカル述部（local predicate）およびキー述部という概念は、スカラ述部と集合述部に同等に適用可能である。
【００３７】
第４に、本発明は、初めて、集合述部に関する拡張可能な索引付けをサポートする。さまざまな応用分野に関して、集合述部は、しばしば、ユーザ定義関数に基づくランキングを伴う。１実施形態では、データベース・システムが、集合述部に基づく検索方法を決定しない。この実施形態の場合、本発明は、アプリケーション開発者に権限を与え、その結果、アプリケーション開発者が、その専門領域の知識を利用して、集合述部に関する効率的な検索戦略を開発できるようになる。
【００３８】
総合的に、本発明からの使用可能度および性能の長所が、データベース技術をより広範囲の応用分野に適用することを可能にする。
【００３９】
Ｂ．集合述部の言語およびセマンティクス
本発明の１実施形態は、集合述部をサポートするためのＳＱＬ拡張を提供する。この手法では、スカラ述部と集合述部を均一な形で扱い、その結果、スカラ述部用の既存のインフラストラクチャを集合述部に使用できるようにする。
【００４０】
ｃ１＜ｃ２＋１０などのスカラ述部を検討されたい。スカラ述部の真の値を判定するためには、ｃ１とｃ２の値だけが必要である。これに対して、集合述部は、その真の値を判定するためにより多くの情報を必要とする。たとえば、上位５位までの給料を見つけるためには、以下の情報が必要である。
・集合述部に使用されるランキング：salary（給料）。
・所望の順序：上位５位の給料の降順または下位５位の給料の昇順。
・所望の回答の数：この場合は５つ。この数は、値が増分的に取り出され、いつでも停止または継続が可能である場合には省略することができる。
・集合述部が評価される対象の値の組（たとえば、あるテーブルのすべての給料の値、または各部署のすべての給料の値の組とすることができる）。
【００４１】
本発明では、新しい構文である集合述部を、ＳＱＬ言語の「検索条件」に定義する（説明を簡単にするために、以下の構文では複合集合述部を示さない。しかし、当業者は、本発明の範囲内で複合集合述部を使用することができることを理解するであろう）。拡張された構文は次の通りである。
【００４２】
述部は、スカラ述部または集合述部のいずれかとすることができる。さらに、集合述部の場合、ＲＡＮＫキーワード（すなわち集合述部識別子）によって、スカラ式が集合述部として識別される。ランキングの所望の順序は、ＡＳＣ（すなわち昇順）キーワードまたはＤＥＳＣ（すなわち降順）キーワード（すなわち結果順序付けインジケータ）に従って実行される。所望の結果の個数は、ＦＩＲＳＴ文節で指定される。ＦＩＲＳＴ文節が省略された場合には、すべての結果が、指定された順序で出力される。ＯＶＥＲ文節のウィンドウ指定が存在する場合には、これによって、集約を実行する方法が決定される（すなわち、集合述部が評価される対象の値の組が指定される）。集合ウィンドウが指定されない場合には、結果は、テーブル全体に対して集約される。
【００４３】
集合述部を評価する時には、まず、必要な情報のすべてを取り込む。その後、下で説明するその後の処理を実行する。
【００４４】
１特定の例として、name（名前）、dept（部署）、salary（給料）、およびage（年齢）という列がある、empという名前のテーブルがあると仮定する。次の例のＳＱＬステートメントは、上位５位の給料とそれに対応する名前を要求するステートメントである。
SELECT name,salary
FROM emp
WHERE RANK (salary) DESC FIRST 5
【００４５】
上のステートメントの場合、照会を評価する方法の１つは、すべてのレコードを取り出し、salaryに基づいてソートすることである。その後、上位５つを降順で返す。
【００４６】
各部署の上位５位までの給料を取り出すためには、次の例のＳＱＬステートメントを使用することができる。
SELECT dept,name,salary
FROM emp
WHERE RANK (salary) DESC FIRST 5 OVER(dept)
【００４７】
上では、ウィンドウ指定がdeptになっている。したがって、２つの部署がある場合には、各部署の上位５人の従業員が返される。
【００４８】
集合述部は、スカラ述部と一緒に使用することができる。次の例のＳＱＬステートメントを検討されたい。
SELECT dept,name,salary
FROM emp
WHERE RANK (salary) DESC FIRST 5 OVER (dept)
AND age < 25
【００４９】
集合述部とスカラ述部が同一レベルにあるので、上のＳＱＬステートメントのセマンティクスは、各部署でその部署内で上位５位までの給料を稼ぎ、年齢が２５歳未満の従業員の、部署、名前、および給料を見つけることである。
【００５０】
各部署の若い従業員の間で上位５位までの給料を見つけるには、次の例のＳＱＬステートメントを使用することができる。
SELECT dept,name,salary
FROM emp
WHERE age < 25
HAVING RANK (salary) DESC FIRST 5 OVER(dept)
【００５１】
ＨＡＶＩＮＧ文節が集合述部を有しない時に、ＨＡＶＩＮＧ文節内のすべてのスカラ述部の評価によって引き起こされる副作用がない場合に、それらのスカラ述部を、ＷＨＥＲＥ文節内の述部とマージできることに留意されたい。しかし、一般に、そのようなマージは、ＨＡＶＩＮＧ文節が少なくとも１つの集合述部を有する場合には実行されない）。
【００５２】
ＧＲＯＵＰ ＢＹ文節がある場合であっても、集合述部がそれ自体のグループ指定（ＯＶＥＲによって示される）を有するので、ＧＲＯＵＰ ＢＹ文節は問題なく集合述部と相互作用する。
【００５３】
給料の例で、上位第５位と上位第６位の給料が同一である場合に、１実施形態では、第６位の給料も回答セットに含まれる。この場合、ＲＡＮＫＧＡＰなどの追加キーワードを使用して、重複する項目（たとえば同一の給料）がある時にそれらを表示することを示す。もう１つの実施形態では、重複する項目が表示されない（たとえば、第５位の給料だけが表示され、第６位は表示されない）。
【００５４】
上の例では、分離された集合述部を検討した。スカラ述部と同様に、集合述部は、ＡＮＤ、ＯＲ、またはＮＯＴなどの論理演算子を使用して組み合わせることができる。そのような集合述部の組み合わせは、Ｒ．ファギン（Fagin）著、「Fuzzy Queries in Multimedia Database Systems」、Proceedings of the 1998 ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systemsでファギンによって検討されたものと異なることに留意されたい。Ｒ．ファギン（Fagin）の論文「Fuzzy Queries in Multimedia Database Systems」、Proceedings of the 1998 ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systemsに記載のものと同様の複合集合述部をサポートするために、以下の例の構文を使用することができる。
SELECT dept,name,salary
FROM emp
WHERE (RANK (salary) DESC AND RANK(age) ASC) FIRST 5 OVER(dept)
【００５５】
上のステートメントでは、部署ごとに、上位５人の若い高給取りの従業員を見つけようとする。複合集合述部のランキングは、各構成集合述部のランキングを互いに組み合わせる方法に依存する。１実施形態では、各構成集合述部に特定の重みを与えるための新しい構文が定義される（実際、上で示したファギンの論文では、各構成集合述部が、［０、１］の範囲のランキング値を備え、組み合わせ関数を使用して、構成集合述部のランキング値を計算する）。
【００５６】
もう１つの例として、distance（距離）が、２つの２次元点（たとえばｘ−ｙ平面内）の間のユークリッド距離を計算するユーザ定義関数（ＵＤＦ）であるものとする。次のステートメントは、例のＳＱＬステートメントのＷＨＥＲＥ文節内で「集合述部」を使用して、所与の位置から最も近い１０個のＡＴＭ（自動預金支払機）を見つける。
SELECT a.name,a.location,a.address
FROM ATM a
WHERE RANK ( distance(a.location,:whereIAm)) FIRST 10
【００５７】
直観的に、照会エンジンは、ＡＴＭテーブルのタプルを取り出し、ＷＨＥＲＥ文節のＵＤＦ呼出しの値に基づいてこれらのタプルをソートする。ソート順で上位１０個のタプルを、結果として返す。レコードが１０個未満の場合には、テーブル全体を返す。１実施形態では、重複するタプルは、上位１０個のリストの末尾に現れる場合に、結果セットから削除される。
【００５８】
ＷＨＥＲＥ文節に現れるほかに、集合述部は、次の例のＳＱＬステートメントに示されているように、ＨＡＶＩＮＧ文節にも現れることができる。
SELECT s.id,c.name,c.address,c.income
FROM customers c,storess
WHERE within (c.location,s.zone)= 1
HAVING RANK (c.income) FIRST COUNT(*) * 0.1 OVER(s.id)
【００５９】
このステートメントの結果セットには、store（店）ごとに、年収に関する顧客の上位１０％を表すタプルが含まれる。ＷＨＥＲＥ文節では、２つのテーブルの間の結合条件が指定され、ＨＡＶＩＮＧ文節では、店ごとに行われる集約が指定される。
【００６０】
Ｃ．集合述部検索のための拡張された索引方法およびアクセス方法
本発明の１実施形態は、集合述部検索のための拡張された索引方法およびアクセス方法を提供する。
【００６１】
以下は、既存のＳＱＬ言語の例である。
SELECT s.id,AVG(c.income)
FROM customers c,stores s
WHERE within(c.location,s.zone) = 1
GROUP BY s.id,s.expense
HAVING s.expense <= SUM(c.income) * 0.45
【００６２】
図３は、例のＳＱＬステートメントのための通常のアクセス・プラン３００を示す図である。ＪＯＩＮノードは、２つのテーブル（すなわちcustomersおよびstores）を結合することによって、結合タプルを作る。すなわち、「within(c.location,s.zone) = 1」が、ローカル述部として使用される。結合されたタプルは、指定されたＧＲＯＵＰ ＢＹ式（すなわちs.idおよびs.expense）に基づいて、ＳＯＲＴノードによってソートされる。ＧＲＯＵＰ ＢＹノードは、現在のグループ内のソート順の結合されたタプルを走査し、そのグループの総計関数（すなわちＡＶＧおよびＳＵＭ）を計算し、代表的なグループ化タプルをその出力ストリームにパイピングする。ＭＡＴＥＲＩＡＬＩＺＥノードが、最終的なフィルタリング（すなわち、s.expense <= SUM(c.income) * 0.45）を実行して、最終結果セットを生成する。
【００６３】
集合述部をサポートするために、本発明の１実施形態では、新しいアクセス・プラン演算子rk_sortを定義する。このrk_sortは、ＳＯＲＴノードのバリエーション（すなわち、拡張ソート演算子）である。rk_sort演算子は、４つの入力をとり、出力として、ランクによってソートされたタプルの組を作る。
【００６４】
最初の引数は、入力ストリームである。「ラウンド半径（round radius）」のために指定された列が、入力ストリームの各タプルに関連する。ラウンド半径の概念は、入力ストリームが複数のラウンドに分割され、ラウンドｎまでに、ラウンドｎの半径以下のスコアリング式を有する少なくともｋ個のタプルがある場合に、そのグループに属する残りのタプルを無視することによってそのグループのrk_sortを終了することができる場合の、rk_sort演算の早期終了を容易にするのに使用される。
【００６５】
図４は、ラウンド半径の説明に使用されるテーブル４００を示す図である。例として１次元検索を取り上げると、５００００ドル未満で上位５位までの給料を有する従業員について５人の従業員の名前を選択する場合、ラウンド半径は、図４のラウンド半径列４０２に示されているようにセットすることができる。具体的に言うと、本発明への入力は、当初はラウンド１から来る。これによって、所望のデータにあてはまる３人の従業員の名前が選択される。その後、ラウンド２のデータが来る。このデータは、特定のラウンドから来るものとしてタグを付けられるので、ラウンド半径によって、新しいラウンドが開始されることが示されることに留意されたい。また、あるラウンド内のレコードは、順序がソートされていない可能性があることに留意されたい。新しいラウンドで継続する前に、そのラウンドのレコードをソートし、その後、所望の数のレコードが選択された（この場合では５個）かどうかを判定する。３人の従業員の名前だけが選択されており、５が所望されるので、処理が継続される。その後、ラウンド２の３つの名前を処理し、所望のデータにあてはまるもう２人の従業員の名前（ApostolおよびJoan）が、ラウンド２から選択される。ラウンドのすべての項目を処理し（たとえば、ラウンド２では３レコード）、その後、所望の数のレコードが選択されたかどうかを判定する。この時点で、５人の従業員の名前が選択されている。したがって、レコードの処理を継続する必要はない。したがって、この例では、６レコードだけを処理した後に、５つの所望の従業員の名前が選択された。
【００６６】
直観的に、候補の検索は、内側から外側への「リング」のシーケンスに基づいて実行される。図５は、半径を表すリングの組５００を示す図である。具体的に言うと、リングに、図４に示された半径に対応する１、２、および３のラベルが付けられている。ラウンド半径には、問題の点とリングの外側の円の間の距離がセットされる。したがって、ラウンド半径の変更は、検索リングの変更を示す。たとえば、ラウンド１からラウンド２に移ると、評価される値は、リング２に含まれる値になる。「リング検索」が可能または使用可能でない場合には、入力ストリームのラウンド半径に無限大をセットし、その結果、タプルのすべてがrk_sort演算で評価されるようにする。
【００６７】
ラウンド半径は、データの分布を理解している人によってレコードに割り当てられる。データに関する統計は、たとえば、ＲＵＮＳＴＡＴＳなどの統計ユーティリティを実行することによって得ることができる。ラウンド半径は、列の値（たとえばsalary）に対応する。これを行った後に、アクセス・プランによって、処理のためにそのラウンド半径に基づいてレコードを取り出す。ラウンド半径に関連する列値に対して索引を作成する場合には、アクセス・プランでその索引を使用して、問題のラウンド半径内のレコードだけを取り出す。これによって、処理されソートされるレコードの量が減る。すなわち、ソートの早期終了がある。したがって、本発明の技法によって効率が改善される。
【００６８】
第２の引数rankは、検索のランクであり、これによって、結果セットのグループ・カーディナリティが決定される。すなわち、上位５位の給料を選択する例では、ランクが５である。ランクは、集合述部の数式（ＦＩＲＳＴに続く）から得られる。
【００６９】
第３の引数groupByListは、グループの形成を定義する式のリストである。たとえば、従業員の名前を部署によって選択する場合には、groupByListは部署になる。groupByListは、集合述部のウィンドウ指定（ＯＶＥＲに続く）から得られる。
【００７０】
第４の引数scoringExpは、集合述部の左側の式である。たとえば、salary<50000をscoringExpとすることができる。scoringExpは、集合述部のスカラ式（ＲＡＮＫに続く）から得られる。
【００７１】
rk_sort演算子の形式的なセマンティクスを、以下の擬似コードによって説明する。
rk_Sort(stream(roundRadius),rank,groupByList,scoringExp)=
１．すべてのグループについてラウンド番号を−１に初期化する。
２．While not ストリームの終り
ａ．ストリーム内の次に使用可能なタプルを取り出す
ｂ．Ｉｆ 新しいタプルの目標グループが凍結されている then 新しいタプルを破棄し、ステップ１に進む
ｃ．Ｉｆ タプルのラウンド半径（roundRadius）がグループ・ラウンド半径と異なる then
ｉ．グループ・ラウンド半径に新しい値をセットする
ｉｉ．Ｉｆ 現在のラウンド半径以下のスコアリング式（scoringExp）を有するタプルの数がランク（rank）以上である then 現在のグループを「凍結」し、１に進む
ｄ．GROUP BY リスト（groupByList）およびスコアリング式（scoringExp）の式に基づいて、ソートされたテーブルに新しいタプルを挿入する
３．まだ凍結されていないグループを凍結する。
４．ランクによってソートされたテーブルを、プランの次のステージにパイピングする
【００７２】
用語「凍結」は、このラウンドについてそれ以上レコードを調べる必要がないことを示すことに留意されたい。上の擬似コードを、下で図１６ないし１８の流れ図を使用して説明する。
【００７３】
Ｄ．照会の例
以下では、異なる集合述部のシナリオについてアクセス・プランを示す。すべてのテーブル操作の例において、rk_SORT演算子に渡されるラウンド半径は、無限大の値であり、絶対に変更されず、その結果、すべてのレコードが単一のラウンドで取り出される。これは、索引活用（index exploitation）の例にもあてはまり、活用される索引は、集合述部からの属性以外の属性に対して定義される。そのような場合には、いくつかのレコードをフィルタ・アウトするための部分的な索引活用があるが、ランキングに基づく早期終了のための索引活用はない。ランクに基づく早期終了のために索引を完全に活用できるようにするために、rk_SORT演算子は、ＩＳＣＡＮの後のＦＥＴＣＨ演算子の直後に現れ、集合述部はローカル述部として使用される。
【００７４】
以下は、単純な集合述部の例のＳＱＬステートメントである。
SELECT *
FROM customer c
WHERE RANK(dist(c.loc,:stl)) ASC FIRST 10
【００７５】
上のステートメントでは、ＳＴＬ（すなわちSanta Teresa Laboratory）に最も近い１０人の顧客（customer）が選択される。単純な集合述部のもう１つの例のＳＱＬステートメントを下に示す。
SELECT *
FROM customer c
WHERE RANK(c.income) DESC FIRST 10
【００７６】
上のステートメントでは、最も高い収入（income）を有する上位１０人の顧客が選択され、このステートメントでは、集合述部としてＵＤＦではなくテーブル属性（すなわち、customerテーブルのincome列）が使用されている。図６は、索引活用を有しないアクセス・プラン６００と、上の照会の両方が生成する索引活用があるアクセス・プラン６０２を示す図である。第２のステートメントは、customer.incomeの索引を活用できるように、customer.locではなくcustomer.incomeに対する索引を必要とすることに留意されたい。
【００７７】
索引活用がないアクセス・プラン６００では、ＴＳＣＡＮノードが、タプルについてcustomerテーブルを走査する。テーブル・レコードおよびラウンド半径が、ＴＳＣＡＮノードからrk_SORTノードに渡される。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個をＭＡＴＥＲＩＡＬＩＺＥノードにパイピングし、ＭＡＴＥＲＩＡＬＩＺＥノードは、パイピングされたタプルから属性を最終結果セットで返す。
【００７８】
索引活用がある場合、ＩＳＣＡＮノードは、ローカル述部としてdist(c.loc,:stl)を使用して、レコード識別子（ＲＩＤ）についてcustomer.loc索引を走査する。さらに、データの統計を知っているユーザによって提供される範囲ジェネレータが、範囲データをＩＳＣＡＮノードに供給する。その後、ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤからタプルを取り出し、テーブル・レコードおよびラウンド半径をrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットのために、パイピングされたタプルから属性を返す。
【００７９】
以下は、ブール式の集合述部に関する例のＳＱＬステートメントである。
SELECT *
FROM customer c
WHERE RANK(dist(c.loc,:stl)) ASC FIRST 10
AND c.income > 50000
【００８０】
上のステートメントでは、ＳＴＬ（すなわちSanta Teresa Laboratory）に最も近い１０人の顧客から、収入が５００００を超える顧客だけが選択される。図７は、loc属性に対する索引活用があるアクセス・プラン７００を示す図である。具体的に言うと、c.locに対する索引がある場合に、上のステートメントによって生成されるアクセス・プラン７００が、図７に示されている。述部c.income>50000が、rk_SORTノードに付加され、このノードに対する後フィルタとして働くことに留意されたい。具体的に言うと、ＩＳＣＡＮノードは、ローカル述部としてdist(c.loc, :stl)を使用することによって、customerテーブルの行のレコード識別子（ＲＩＤ）について索引を走査する。その後、ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤからタプルを取り出し、テーブル・レコードおよびラウンド半径をrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択し、後フィルタとしてc.income>50000を使用する。フィルタリングされた上位１０個のテーブル・レコードが、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットのために、パイピングされたタプルから属性を返す。
【００８１】
以下は、ＨＡＶＩＮＧ文節内の集合述部に関する例のＳＱＬステートメントである。
SELECT *
FROM customer c
WHERE c.income > 50000
HAVING RANK(dist(c.loc,:stl)) ASC FIRST 10
【００８２】
上のステートメントでは、収入が５００００を超え、ＳＴＬ（すなわちSanta Teresa Laboratory）に最も近い１０人の顧客が選択される。図８は、loc属性に対する索引活用があるアクセス・プラン８００を示す図である。上のステートメントについて生成される図８のアクセス・プラン８００は、前のステートメントのアクセス・プラン７００とほとんど同等であるが、述部c.income > 50000が、rk_SORTノードの前のＦＥＴＣＨノードに付加され、ＦＥＴＣＨノードに対する前フィルタとして働く。
【００８３】
具体的に言うと、ＩＳＣＡＮノードは、ローカル述部としてdist(c.loc, :stl）を使用して、customerテーブルのレコードのレコード識別子（ＲＩＤ）について索引を走査する。ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、前フィルタとしてc.income>50000を使用して、ＲＩＤからタプルを取り出す。rk_SORTノードは、テーブル・レコードおよびラウンド半径を受け取る。次に、rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択する。これらは、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８４】
代替案は、c.locではなくc.incomeに対する索引を活用し、その後、１ラウンドでランク付きソートを行うことである。これは、income属性に対する索引活用があるアクセス・プラン９００を示す図である図9に示されたアクセス・プラン９００をもたらす。具体的に言うと、ＩＳＣＡＮノードは、ローカル述部としてc.income>50000を使用して、customerテーブルのレコードのレコード識別子（ＲＩＤ）について索引を走査する。ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤからタプルを取り出す。rk_SORTノードは、テーブル・レコードおよびラウンド半径を受け取る。次に、rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択する。これらは、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８５】
どの索引が使用可能であるか、または、両方の索引が使用可能である場合に各述部の選択性見積もりがどれであるかに依存して、コンパイラは、２つのアクセス・プラン８００およびアクセス・プラン９００の間で選択することができ、また、索引が使用可能でない場合には、コンパイラは、図１０に示された簡単なテーブル走査のアクセス・プラン１０００を生成する。図１０は、索引活用なしのアクセス・プラン１０００を示す図である。アクセス・プラン１０００の場合、ＴＳＣＡＮノードは、フィルタとしてc.income>50000を使用して、タプルについてcustomerテーブルを走査する。ＴＳＣＡＮノードは、テーブル・レコードおよびラウンド半径をrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択する。これらは、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８６】
以下は、ＪＯＩＮ内のウィンドウに対する集合述部に関する例のＳＱＬステートメントである。
SELECT *
FROM customer c,stores s
WHERE RANK(dist(c.loc,s.loc)) ASC FIRST 10 OVER (s.id)
【００８７】
上のステートメントでは、すべてのstore位置について最も近い１０人の顧客が選択される。これによって生成されるアクセス・プランを、図１１、図１２、および図１３に示す。
【００８８】
図１１は、索引活用がなく、検索引数と外部テーブルの間の機能的依存性もないアクセス・プラン１１００を示す図である。具体的に言うと、あるＴＳＣＡＮノードが、テーブル・レコードについてcustomerテーブルを走査し、これらをＪＯＩＮノードに渡す。もう１つのＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらを、ラウンド半径と共にＪＯＩＮノードに渡す。次に、ＪＯＩＮノードが、受け取ったレコードを結合し、これらを、ラウンド半径と共にrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８９】
図１２は、索引活用はないが、検索引数と外部テーブルの間の機能的依存性があるアクセス・プラン１２００を示す図である。具体的に言うと、あるＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらをＪＯＩＮノードに渡す。もう１つのＴＳＣＡＮノードが、テーブル・レコードについてcustomerテーブルを走査し、これらを、ラウンド半径と共にrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＪＯＩＮノードに渡す。次に、ＪＯＩＮノードが、受け取ったレコードを結合し、これらをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとして、パイピングされたタプルから属性を返す。
【００９０】
図１３は、索引活用があり、検索引数と外部テーブルの間の機能的依存性があるアクセス・プラン１３００を示す図である。具体的に言うと、ＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらをＪＯＩＮノードに渡す。ＩＳＣＡＮノードが、ローカル述部としてdist(c.loc,s.loc)を使用してcustomerテーブルのレコード識別子（ＲＩＤ）について索引を走査し、これらを、ラウンド半径と共にＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤを使用してcustomerテーブルからタプルを取り出し、これらを、ラウンド半径と共にrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＪＯＩＮノードに渡す。次に、ＪＯＩＮノードは、受け取ったレコードを結合し、これらをＭＡＴＥＲＩＡＲＩＺＥノードに渡し、ＭＡＴＥＲＩＡＲＩＺＥノードは、最終結果セットとして、パイピングされたタプルから属性を返す。
【００９１】
以下は、ＧＲＯＵＰ ＢＹ文節を有するＪＯＩＮ内の集合述部に関する例のＳＱＬステートメントである。
SELECT s.id,sum(c.income)
FROM customer c,store s
WHERE within(c.loc,s.zone) = 1
GROUP BY s.id HAVING RANK(sum(c.income)) DESC FIRST 10
【００９２】
上のステートメントでは、最も高い総合累積収入を有する顧客にサービスする、上位１０位までの店が選択される。この場合、ランキングが各グループの総計関数に基づくので、早期終了のために索引を活用することはできない。その関数は、グループのすべてのレコードを取り出し、ソートするまでは評価できないので、ランキングは、その後に開始しなければならず、テーブル全体を走査する前に終了することができない。しかし、customer.locに対して定義された索引がある場合には、その索引を活用して、ランキングを開始する前にいくつかのレコードをフィルタ・アウトすることができる。図１４は、部分的索引活用があるアクセス・プラン１４００を示す図である。
【００９３】
具体的に言うと、あるＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらをＪＯＩＮノードに渡す。ＴＳＣＡＮノードが、ローカル述部として（within(c.loc,s.zone) = 1）を使用して、customerテーブルのレコード識別子（ＲＩＤ）について索引を走査し、これらを、ラウンド半径と共にＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤを使用してcustomerテーブルからタプルを取り出し、これらを、ラウンド半径と共にＪＯＩＮノードに渡す。次に、ＪＯＩＮノードが、受け取ったレコードを結合し、これらを、ラウンド半径と共にＳＯＲＴノードに渡す。ＳＯＲＴノードは、s.idによってタプルをソートし、これらを、ラウンド半径と共にＧＲＯＵＰ ＢＹノードに渡す。ＧＲＯＵＰ ＢＹノードは、総計関数を評価し、タプルをグループ化する。グループ化されたタプルおよびラウンド半径が、rk_SORTノードに渡される。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとして、パイピングされたタプルから属性を返す。
【００９４】
以下は、ＧＲＯＵＰ ＢＹ文節を伴う集合述部の例のＳＱＬステートメントである。
SELECT s.sizeRating,sum(c.purchases)
FROM customer c,store s
WHERE within(c.loc,store.loc) = 1
GROUP BY s.sizeRating
HAVING RANK(s.sizeRating) DESC FIRST 10
【００９５】
上のステートメントについて、storeテーブルのsizeRating属性が、ある外部レーティングによる、所与の店の顧客ベースのサイズを表すと仮定する。上のステートメントは、上位１０サイズ・グループのそれぞれの店の総売上を返す。この例の集合述部store.sizeRatingは属性であり、前の例のような総計関数ではないが、ランキングが個々のテーブル・レコードではなくグループ・レコードに対して実行されるので、上のステートメントは、store.sizeRatingに対する索引を活用することができない。したがって、このステートメントに対して生成されるアクセス・プランは、store.locに対して定義された索引がある場合にはアクセス・プラン１４００と同一になる。活用すべき索引がない場合には、アクセス・プランは、単純なテーブル走査アクセス・プランになる。
【００９６】
Ｅ．流れ図
図１５は、本発明を使用する処理を示す流れ図である。具体的に言うと、ブロック１５００は、集合述部を有する照会を作成することを表す。ブロック１５０２は、コンパイラが、集合述部を処理するために、拡張ソート演算子（rk_sort）を有するアクセス・プランを生成することを表す。ブロック１５０４は、アクセス・プランを実行し、それが実行される時に、集合述部を評価し、ランキング演算を実行することを表す。
【００９７】
図１６ないし１８は、集合述部を処理するための拡張ソート演算子（rk_sort）の処理を示す流れ図である。ブロック１６００は、拡張ソート演算子が、ストリーム（ラウンド半径を含む）、ランク、ＧＲＯＵＰ ＢＹリスト、およびスコアリング式を受け取ることを表す。ストリームは、タプルからなり、各タプルは、ラウンド半径の列値を有する。ランクは、集合述部の数式に対応し、ＧＲＯＵＰ ＢＹリストは、集合述部のウィンドウ指定に対応し、スコアリング式は、集合述部のスカラ式に対応する。
【００９８】
ブロック１６０２は、拡張ソート演算子が、すべてのグループについてグループ・ラウンド番号を−１に初期化することを表す。ブロック１６０４で、拡張ソート演算子が、ストリームの終りである（すなわち、すべてのタプルを処理した）かどうかを判定する。ストリームの終りである場合には、拡張ソート演算子は、ブロック１６２２に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６０６に継続する。
【００９９】
ブロック１６０６では、拡張ソート演算子が、ストリーム内の次に使用可能なタプルを取り出す。ブロック１６０８では、拡張ソート演算子が、タプルの目標グループが凍結されているかどうかを判定する。そうである場合には、拡張ソート演算子は、ブロック１６１０に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６１２に継続する。ブロック１６１０では、拡張ソート演算子が、タプルを破棄し、ブロック１６０４にループ・バックする。
【０１００】
ブロック１６１２では、拡張ソート演算子が、タプルのラウンド半径がグループ・ラウンド半径と異なるかどうかを判定する。そうである場合には、拡張ソート演算子は、ブロック１６１４に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６２０に継続する。
【０１０１】
ブロック１６１４では、拡張ソート演算子が、グループ・ラウンド半径に新しいラウンド半径をセットする。ブロック１６１６では、拡張ソート演算子（現在のグループ・ラウンド半径以下のスコアリング式を有するタプルの数）が、ランク（すなわちタプルの所望の個数）以上であるかどうかを判定する。そうである場合には、拡張ソート演算子は、ブロック１６１８に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６２０に継続する。ブロック１６１８では、拡張ソート演算子が、現在のグループを凍結する（すなわち、そのグループについてこれ以上タプルが処理されないことを示す）。その後、拡張ソート演算子は、ブロック１６０４にループ・バックする。
【０１０２】
ブロック１６２０では、拡張ソート演算子が、ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、ソートされたテーブルにタプルを挿入する。その後、拡張ソート演算子は、ブロック１６０４にループ・バックする。
【０１０３】
ブロック１６０４で、ストリームの終りに達した場合、拡張ソート演算子は、ブロック１６２２に継続し、まだ凍結されていないグループを凍結する。その後、拡張ソート演算子は、ランクによってソートされたテーブルを、アクセス・プランの次のステージにパイピングする。
【０１０４】
Ｆ．本発明の追加の長所
この節では、本発明の追加の長所を示す。これらの記述された長所は、例示のみのために提供され、本発明の長所のすべてを表すものではない。
【０１０５】
集合述部をサポートするための複数の手法が探求されてきた。１つの手法は、特定の応用分野を目標とする索引付け機構を開発することである。たとえば、Ｒ−木を使用する最近隣照会の評価が、ロウスポウロス（Nick Roussopoulos）、ケリー（Stephen Kelley）、およびビンセント（Frederic Vincent）著、「Nearest Neighbor Queries」、Proceedings of the 1995 ACM-SIGMOD International Conference on Management of Data、米国カリフォルニア州サンノゼで調査された。
【０１０６】
Ｄ．Ａ．ホワイト（White）およびＲ．ジェイン（Jain）著、「Similarity Indexing with the SS-tree」、Proceedings of the 12th IEEE International Conference on Data Engineering、１９９６年２月、第５１６〜５２３ページに記載のＳＳ−木などの、新しい索引付けデータ構造も開発された。この手法は、特定の領域で機能するが、新しい応用分野は、検索、並行性、および回復のために通常の木機構の新しい実装を必要とする。特定の応用分野のためのそのような木の実装のコストは高い。
【０１０７】
もう１つの手法は、最近隣検索およびランク付き検索をサポートする一般化された検索木を開発することである。この手法は、アオキ（Paul Aoki）著、「Generalizing ”Search” in Generalized Search Trees」に記載のＧｉＳＴの拡張によって例示される。この手法は、ユーザが木のトラバースのすべてのステップを制御できるようにすることによる拡張性という長所を有する。短所は、そのようなユーザ制御が、しばしばユーザ定義関数を介して達成されることである。木トラバースの各ステップでのユーザ定義関数の呼び出しは、大きい実行時オーバーヘッドを引き起こす可能性がある。
【０１０８】
第３の手法は、たとえばチャウドゥーリィ（Surajit Chaudhuri）およびグラバノ（Luis Gravano）著、「Evaluating Top-k Selection Queries」、Proceedings of the 25th VLDB Conference、１９９９年に記載のものなどの、上位ｋ位選択照会を範囲を使用する通常の選択照会に変形することである。この手法の主な問題は、上位ｋ位選択照会に対応する範囲照会をコンパイル時に決定する必要があることである。コンパイル時の推定が正しくない場合には、上位ｋ位選択照会に対する回答を得ることができない可能性がある。
【０１０９】
本明細書に記載の発明は、複数の長所を有する。第１に、本発明は、ユーザがランク付き検索を制御でき、領域固有の手法の短所が回避されるという意味で、拡張可能である。第２に、そのような制御が、基礎となるアクセス方法によって使用される一連の検索範囲を生成することによって、フレームワークの上位レベルで行われる。これによって、ＧｉＳＴでの手法の実行時オーバーヘッドが回避される。第３に、本発明は、動的であり増分的である。
【０１１０】
結論
これで本発明の好ましい実施形態の説明を終える。以下で、本発明を達成するためのいくつかの代替実施形態を説明する。たとえば、メインフレーム、ミニコンピュータ、またはパーソナル・コンピュータなどのすべての種類のコンピュータ、もしくは、タイム・シェアリング・メインフレーム、ローカル・エリア・ネットワーク、または独立型パーソナル・コンピュータなどのコンピュータ構成を、本発明と共に使用することができる。
【０１１１】
本発明の好ましい実施形態の前述の説明は、例示と説明のために提示された。網羅的であることまたは開示された正確な形態に本発明を制限することは、意図されていない。上記の教示に鑑みて、多数の修正形態および変更形態が可能である。本発明の範囲は、この詳細な説明によるのではなく、請求項によって制限されることが意図されている。
【０１１２】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１１３】
（１）コンピュータに接続されたデータ・ストア内のデータを操作するために前記コンピュータ内でステートメントを実行する方法であって、
集合述部を有するステートメントを受け取るステップと、
前記ステートメントを評価する時に、前記集合述部をランク・データに処理するステップと
を含む方法。
（２）前記集合述部が、検索条件に含まれる、上記（１）に記載の方法。
（３）前記集合述部が、数式を含む、上記（１）に記載の方法。
（４）前記集合述部が、順序付けインジケータを含む、上記（１）に記載の方法。
（５）前記集合述部が、ウィンドウ指定を含む、上記（１）に記載の方法。
（６）前記集合述部が、スカラ式を含む、上記（１）に記載の方法。
（７）評価が、拡張ソート演算子の実行を含む、上記（１）に記載の方法。
（８）前記拡張ソート演算子が、アクセス・プランの一部である、上記（７）に記載の方法。
（９）前記拡張ソート演算子の実行が、１つまたは複数のタプルを含むストリーム、ランク、０個以上のグループを含むＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含む、上記（７）に記載の方法。
（１０）前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄するステップをさらに含む、上記（９）に記載の方法。（１１）グループ・ラウンド半径を判定するステップと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、
前記グループ・ラウンド半径にそのラウンド半径をセットするステップと、
前記グループについて所望の数のタプルが識別された場合に、前記グループを凍結するステップと
をさらに含む、上記（９）に記載の方法。
（１２）前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入するステップをさらに含む、上記（９）に記載の方法。
（１３）前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結するステップをさらに含む、上記（９）に記載の方法。
（１４）データを操作するためにステートメントを実行する装置であって、
データを記憶するデータ・ストアを接続されたコンピュータと、
前記コンピュータによって実行される、集合述部を有するステートメントを受け取り、前記ステートメントを評価する時に、前記集合述部をランク・データに処理する、１つまたは複数のコンピュータ・プログラムと
を含む装置。
（１５）前記集合述部が、検索条件に含まれる、上記（１４）に記載の装置。
（１６）前記集合述部が、数式を含む、上記（１４）に記載の装置。
（１７）前記集合述部が、順序付けインジケータを含む、上記（１４）に記載の装置。
（１８）前記集合述部が、ウィンドウ指定を含む、上記（１４）に記載の装置。（１９）前記集合述部が、スカラ式を含む、上記（１４）に記載の装置。
（２０）評価が、拡張ソート演算子の実行を含む、上記（１４）に記載の装置。（２１）前記拡張ソート演算子が、アクセス・プランの一部である、上記（２０）に記載の装置。
（２２）前記拡張ソート演算子の実行が、１つまたは複数のタプルを含むストリーム、ランク、０個以上のグループを含むＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含む、上記（２０）に記載の装置。
（２３）前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄することをさらに含む、上記（２２）に記載の装置。
（２４）グループ・ラウンド半径を判定することと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、
前記グループ・ラウンド半径にそのラウンド半径をセットすることと、
前記グループについて所望の数のタプルが識別された場合に、前記グループを凍結することと
をさらに含む、上記（２２）に記載の装置。
（２５）前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入することをさらに含む、上記（２２）に記載の装置。
（２６）前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結することをさらに含む、上記（２２）に記載の装置。
（２７）集合述部を有するステートメントを受け取るステップと、
前記ステートメントを評価する時に、前記集合述部をランク・データに処理するステップと
を含む、コンピュータに接続されたデータ・ストア内のデータを操作するために前記コンピュータ内でステートメントを実行するための方法ステップを実行するために前記コンピュータによって実行可能な１つまたは複数の命令を実施する、コンピュータによって可読のコンピュータ・プログラム担体を含む製造品。
（２８）前記集合述部が、検索条件に含まれる、上記（２７）に記載の製造品。（２９）前記集合述部が、数式を含む、上記（２７）に記載の製造品。
（３０）前記集合述部が、順序付けインジケータを含む、上記（２７）に記載の製造品。
（３１）前記集合述部が、ウィンドウ指定を含む、上記（２７）に記載の製造品。
（３２）前記集合述部が、スカラ式を含む、上記（２７）に記載の製造品。
（３３）評価が、拡張ソート演算子の実行を含む、上記（２７）に記載の製造品。
（３４）前記拡張ソート演算子が、アクセス・プランの一部である、上記（３３）に記載の製造品。
（３５）前記拡張ソート演算子の実行が、１つまたは複数のタプルを含むストリーム、ランク、０個以上のグループを含むＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含む、上記（３３）に記載の製造品。
（３６）前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄するステップをさらに含む、上記（３５）に記載の製造品。
（３７）グループ・ラウンド半径を判定するステップと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、
前記グループ・ラウンド半径にそのラウンド半径をセットするステップと、
前記グループについて所望の数のタプルが識別された場合に、前記グループを凍結するステップと
をさらに含む、上記（３５）に記載の製造品。
（３８）前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入するステップをさらに含む、上記（３５）に記載の製造品。
（３９）前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結するステップをさらに含む、上記（３５）に記載の製造品。
【図面の簡単な説明】
【図１】本発明の実施形態のハードウェア環境を示し、具体的には、通常の分散コンピュータ・システムを示す概略図である。
【図２】ＳＱＬステートメントを評価する処理を示す図である。
【図３】例のＳＱＬステートメントの通常のアクセス・プラン３００を示す図である。
【図４】ラウンド半径の説明に使用されるテーブルを示す図である。
【図５】半径を表すリングの組を示す図である。
【図６】索引活用がないアクセス・プランと２つの照会の索引活用があるアクセス・プランを示す図である。
【図７】 loc属性に対する索引活用があるアクセス・プランを示す図である。
【図８】 loc属性に対する索引活用があるアクセス・プランを示す図である。
【図９】 income属性に対する索引活用があるアクセス・プランを示す図である。
【図１０】索引活用がないアクセス・プランを示す図である。
【図１１】索引活用がなく、検索引数と外部テーブルの間の機能的依存性もないアクセス・プランを示す図である。
【図１２】索引活用はないが、検索引数と外部テーブルの間の機能的依存性があるアクセス・プランを示す図である。
【図１３】索引活用があり、検索引数と外部テーブルの間の機能的依存性があるアクセス・プランを示す図である。
【図１４】部分的索引活用があるアクセス・プランを示す図である。
【図１５】本発明を使用する処理を示す流れ図である。
【図１６】集合述部を処理するための、拡張ソート演算子（rk_sort）の処理を示す流れ図である。
【図１７】集合述部を処理するための、拡張ソート演算子（rk_sort）の処理を示す流れ図である。
【図１８】集合述部を処理するための、拡張ソート演算子（rk_sort）の処理を示す流れ図である。
【符号の説明】
１０２ コンピュータ・システム
１０４ データ記憶装置
１０６ オペレータ・インターフェース
１０８ データベース・サービス・モジュール
１１０ リレーショナル・データベース・サービス（ＲＤＳ）
１１２ データ・マネージャ
１１４ バッファ・マネージャ
１１６ 他のコンポーネント
１１８ モニタ
２００ ＳＱＬプログラム
２０２ コンパイラ
２０４ 解釈済みコード
２０６ データベース・ランタイム・ライブラリ
２０８ インタープリタ
２１０ リレーショナル・データベース・マネージャ
２１２ データベース
３００ アクセス・プラン
４００ テーブル
４０２ ラウンド半径列
【発明の属する技術分野】
本発明は、全般的にはコンピュータ実施されるデータベース管理システムに関し、具体的には、データベース管理システムの集合述部（aggregate predicate）および検索に関する。
【０００２】
【従来の技術】
データベースとは、コンピュータ化された情報記憶システムおよび情報検索システムである。たとえば、リレーショナル・データベース管理システム（ＲＤＢＭＳ）は、データの記憶および検索に関係技法を使用するデータベース管理システム（ＤＢＭＳ）である。リレーショナル・データベースは、データの行および列からなる物理テーブルに編成される。行は、形式的にはタプルまたはレコードと呼ばれる。データベースは、通常、多数の物理テーブルを有し、各物理テーブルが、通常は複数のタプルおよび複数の列を有する。物理テーブルは、通常は、半永久的な記憶のために磁気ディスク・ドライブまたは光ディスク・ドライブなどのランダム・アクセス記憶装置（ＲＡＳＤ）に格納される。
【０００３】
さらに、論理テーブルまたは「ビュー」を、物理テーブルに基づいて生成し、データベースを見る特定の方法を提供することができる。ビューによって、データベースの物理編成に影響せずに、行をある順序で配置することができる。
【０００４】
既存のデータベース・システムでは、集合述部サポートが使用可能でない。しかし、多くの応用分野が、集合述部を使用する検索機能を必要とする。たとえば、集合述部は、下記の状況に必要である。
・画像または文書に対する類似性検索。
・空間的オブジェクトに対する最近隣（nearest neighbor）検索。
【０００５】
既存のデータベース・システムでは、ユーザは、標準の関係演算子（＜、＜＝、＝、＜＞、＞、＞＝）および論理演算子（and、or、not）を使用することによって、照会の結果を制限することができる。これらの関係演算子および論理演算子のほかに、International Business Machines, CorporationのＤＢ２（登録商標）などのオブジェクト・リレーショナル・データベースでは、ユーザが、照会に使用することができ、照会最適化プログラムによって利用することができる述部を定義することができる。Ｗ．チェン（Chen）、Ｊ．−Ｈ．チョウ（Chow）、Ｙ．−Ｃ．ユウ（You）、Ｊ．グランボア（Grandbois）、Ｍ．ジョウ（Jou）、Ｎ．マットス（Mattos）、Ｂ．トラン（Tran）、Ｙ．ウォン（Wang）著、「High Level Indexing of User-Defined Types」、Proceedings of the 25th International Conference on Very Large Data Bases、Edinburgh、１９９９年９月、第５５４〜５６４ページ。
【０００６】
これらの述部は、他の個々の値から独立な、個々の値について真または偽になるスカラ述部である。たとえば、distance (customer.location、store.location) < 5などの条件を検討されたい。このdistance（距離）条件の場合、customer（顧客）およびstore（店舗）のlocation（位置）の任意の対に対して、distance条件によって、他の顧客または店舗の位置とは独立に、顧客の位置と店舗の位置の間の距離が５未満であるか否かが評価される（すなわち、条件が真または偽のいずれかとして評価される）。
【０００７】
既存のデータベース・システムは、スカラ関数と少数の総計関数の両方をサポートする。たとえば、スカラ関数の例が、abs（絶対値を返す）およびsqrt（引数の平方根を返す）である。総計関数は、値の集合（すなわち列）を操作し、スカラ値を返す。総計関数の例には、max（列内の最大の非ヌル値を返す）、min（列内の最小の非ヌル値を返す）、およびavg（列内の非ヌル値の平均を返す）が含まれる。スカラ関数と総計関数の主な相違は、総計関数が値の組を操作するのに対して、スカラ関数が引数として個々の値だけをとることである。最近、総計関数が、オンライン分析処理（ＯＬＡＰ）関数に一般化された。Ｆ．ゼムケ（Zemke）、Ｋ．クルカーニ（Kulkarni）、Ａ．ウィトカウスキ（Witkowski）、Ｂ．ライル（Lyle）著、「Introduction to OLAP Functions」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ３２ ＷＧ３−ＹＧＪ−ｎｎｎ、ＡＮＳＩ ＮＣＩＴＳ Ｈ２−９９−１５４、１９９９年４月１２日。ＯＬＡＰ関数は、総計関数である。ＯＬＡＰ関数の呼出しのそれぞれは、ＯＬＡＰ関数が適用される値の組を指定する関連ウィンドウを有する。
【０００８】
関数とは異なり、既存のデータベース・システムは、値の所与の組に関して個々の値の真または偽になる集合述部をサポートしない。多くの実世界の応用分野が、集合述部を必要とする。下記は、一般的な例の一部にすぎない。
１．所与の画像に似ている上位１０個の画像を見つける。
２．ある家に最も近い上位５個の断層はどれか。
３．所与の位置に最も近い病院はどれか。
４．各店舗について、先月の売上上位１０位までの製品を見つける。
【０００９】
これらの例は、いくつかの共通の態様を共有する。第１に、例のそれぞれに、集合述部が含まれる。たとえば、所与の位置に対する相対的な他の病院の位置と比較しなければ、ある病院がその所与の位置に最も近いかどうかを判定することはできない。第２に、例のすべてが、集合述部に基づく検索を必要とする。言い換えると、目標は、所与の病院がある位置に最も近いかどうかを知るために検査することではない。そうではなくて、所与の位置に最も近い病院（おそらくは多数の病院のグループから）を探しているのである。
【００１０】
【発明が解決しようとする課題】
したがって、当技術分野には、既存のデータベース・システムに集合述部を導入し、集合述部に基づく検索を可能にすることの必要が存在する。
【００１１】
【課題を解決するための手段】
上で説明した従来技術の制限を克服し、本明細書を読み、理解した後に明白になる他の制限を克服するために、本発明は、データベース管理システム内で集合述部および検索を可能にする、コンピュータ実施される技法のための方法、装置、および製造品を開示する。
【００１２】
本発明によれば、コンピュータ内でステートメントを実行して、コンピュータに接続されたデータ・ストア内のデータを操作する。まず、集合述部を有するステートメントを受け取る。その後、ステートメントを評価する時に、集合述部を処理してランク・データにする。さらに、評価には、早期終了（early termination）を有する拡張ソート演算子の実行が含まれる。
【００１３】
これから図面を参照するが、図では、同様の符号が図を通じて対応する部分を表す。
【００１４】
【発明の実施の形態】
本発明の実施形態の以下の説明では、本明細書の一部を形成し、本発明を実施することができる具体的な実施形態を例として示す添付図面を参照する。本発明の範囲から逸脱せずに構造的変更を行うことができるので、他の実施形態を使用することができることを理解されたい。
【００１５】
ハードウェア環境
図１に、本発明に従って使用することができる例示的コンピュータ・ハードウェア環境を示す。この例示的環境では、コンピュータ・システム１０２は、ハード・ディスク・ドライブ、フロッピ・ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、テープ・ドライブ、または他の装置など、１つまたは複数のリレーショナル・データベースを記憶する、１つまたは複数のデータ記憶装置１０４に接続された１つまたは複数のプロセッサからなる。
【００１６】
コンピュータ・システム１０２のオペレータは、標準的なオペレータ・インターフェース１０６を使用して、照会と称する、データベースに対するさまざまな検索機能および取出機能を実行するコマンドを表す電気信号を、コンピュータ・システム１０２との間で送受する。本発明の１実施形態では、これらの照会が、構造化照会言語（ＳＱＬ）標準規格に従い、リレーショナル・データベース管理システム（ＲＤＢＭＳ）ソフトウェアによって実行される機能を呼び出す。
【００１７】
ＳＱＬインターフェースは、ＲＤＢＭＳソフトウェアの標準言語に進化し、したがって、米国規格協会（ＡＮＳＩ）および国際標準化機構（ＩＳＯ）の両方によって採用されている。ＳＱＬインターフェースによって、ユーザが、対話的に、バッチ・ファイルで、またはＣおよびＣＯＢＯＬなどのホスト言語に埋め込んでのいずれかで、テーブルに対する関係演算を定式化できるようになる。ＳＱＬによって、ユーザがデータを操作できるようになる。
【００１８】
本発明の好ましい実施形態では、ＲＤＢＭＳソフトウェアに、International Business Machines, Corporationが提供するＤＢ２（登録商標）for Universal Database（ＵＤＢ）製品が含まれる。しかし、本発明が、すべてのデータベース・ソフトウェアに対する応用性を有することを、当業者は理解するであろう。
【００１９】
ＳＱＬステートメントが実行のために準備される時に、ＵＤＢ最適化プログラムが、ステートメントを分析し、要求を満足する代替方法を検討し、各代替案のコストを見積もり、最も低いコスト（処理要件および入出力要件に関して）を有する代替案を選択する。これを行う際に、最適化プログラムは、ステートメント実行のためのアクセス・プランを生成する。このアクセス・プランによって、要求を満足する方法（たとえば、索引を使用するか２つのテーブルからデータを結合することによるなど）が示される。アクセス・プランは、しばしば、１つまたは複数のテーブルまたは索引から処理ノード（たとえば結合ノード）を介して元のＳＱＬステートメントを満足する結果セットへデータがどのように流れるかを示すグラフとして示すことができる。
【００２０】
ＤＢ２（登録商標）ｆｏｒ ＵＤＢシステムの中心に、データベース・サービス・モジュール１０８がある。データベース・サービス・モジュール１０８には、リレーショナル・データベース・サービス（ＲＤＳ）１１０、データ・マネージャ１１２、バッファ・マネージャ１１４、およびＳＱＬコンパイラ／インタープリタなどの他のコンポーネント１１６を含む複数のサブモジュールが含まれる。これらのサブモジュールは、ＳＱＬ言語の機能すなわち、ユーザ・データおよびシステム・データの定義、アクセス制御、解釈、コンパイル、データベース検索、および更新をサポートする。
【００２１】
本発明は、全般的に、データベース・サービス・モジュール１０８の制御下で実行されるＳＱＬステートメントを使用して実施される。データベース・サービス・モジュール１０８は、ＳＱＬステートメントを取り出すか受け取り、このＳＱＬステートメントは、一般に、データ記憶装置１０４にテキスト・ファイルとして格納されるか、オペレータ・インターフェース１０６を介してモニタ１１８の前のオペレータによってコンピュータ・システム１０２に対話的に入力される。データベース・サービス・モジュール１０８は、コンピュータ・システム１０２による実行のためにＳＱＬステートメントから命令を導出または合成する。
【００２２】
一般に、ＲＤＢＭＳソフトウェア、ＳＱＬステートメント、およびそれから導出される命令のすべてが、たとえば１つまたは複数のデータ記憶装置１０４などのコンピュータ可読媒体内で具体的に実施される。さらに、ＲＤＢＭＳソフトウェア、ＳＱＬステートメント、およびそれから導出される命令のすべてが、コンピュータ・システム１０２によって読み取られ実行される時に、本発明を実施するか使用するのに必要なステップをコンピュータ・システム１０２に実行させる命令からなる。オペレーティング・システムの制御下で、ＲＤＢＭＳソフトウェア、ＳＱＬステートメント、およびそれから導出される命令を、実際の動作中に使用するためにデータ記憶装置１０４からコンピュータ・システム１０２のメモリにロードすることができる。
【００２３】
したがって、本発明は、標準的なプログラミング技法またはエンジニアリング技法もしくはその両方を使用して、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せを作る方法、装置、または製造品として実施することができる。本明細書で使用する用語「製造品」（または、その代替として「コンピュータ・プログラム製品」）は、すべてのコンピュータ可読装置、担体、または媒体からアクセス可能なコンピュータ・プログラムを含むことが意図されている。もちろん、当業者は、本発明の範囲から逸脱せずに、この構成に多数の変更を行うことができることを理解するであろう。
【００２４】
当業者は、図１に示された例示的環境が、本発明を制限する目的でないことを理解するであろう。実際、当業者は、本発明の範囲から逸脱せずに、他の代替ハードウェア環境を使用することができることを理解するであろう。
【００２５】
図２は、ＳＱＬステートメントを評価する処理を示す図である。ＳＱＬプログラム２００に、ＳＱＬステートメントが含まれる。コンパイラ２０２が、ＳＱＬプログラム２００を解釈済みコード２０４にコンパイルする。解釈済みコード２０４およびデータベース・ランタイム・ライブラリ２０６（たとえば、ストアド・プロシージャおよびユーティリティを含む）が、インタープリタ２０８に入力される。インタープリタ２０８の出力は、リレーショナル・データベース・マネージャ２１０にアクセスし、ＳＱＬステートメントによって要求されたデータをデータベース２１２から取り出すのに使用される。本発明の１実施形態では、本発明の一部が、コンパイラ内に常駐し、集合述部を含むＳＱＬステートメントをコンパイルして、拡張ソート演算子を含むアクセス・プランを形成する。
【００２６】
データベース管理システム内での集合述部および検索
本発明は、集合述部のための構文を提供する。さらに、本発明は、集合述部検索のためのアクセス技法を提供する。
【００２７】
具体的に言うと、ＳＱＬ言語は、ＳＱＬ照会またはＳＱＬステートメントに検索条件を含める能力を備える。検索条件（たとえばｘ＜５）は、ブール値をもたらす。本発明は、ＳＱＬステートメントの検索条件（たとえばＷＨＥＲＥ文節またはＨＡＶＩＮＧ文節）に含めることができる集合述部を定義することによって、ＳＱＬ言語を拡張する。ランク演算子を定義した後に、ＳＱＬ言語用のコンパイラが、そのランク演算子を処理できなければならない。したがって、本発明は、コンパイラが集合述部を含むＳＱＬステートメントのアクセス・プランに含めるrk_sort演算（すなわち、拡張されたソート操作）も提供する。
【００２８】
以下の説明は、次のように編成されている。
Ａ．データベース・システムへの集合述部の導入
Ｂ．集合述部の言語およびセマンティクス
Ｃ．集合述部検索のための拡張された索引方法およびアクセス方法
Ｄ．照会の例
Ｅ．流れ図
Ｆ．要約と本発明の追加の長所
【００２９】
Ａ．データベース・システムへの集合述部の導入
本発明は、いくつかの点でＤＢＭＳ（データ・ベース管理システム）での集合述部および検索に貢献する。第１に、本発明は、集合述部という概念によってＤＢＭＳで使用されるＳＱＬを拡張する。集合述部は、照会で従来のスカラ述部（すなわち関係演算子および論理演算子）と同一の形で使用することができる。第２に、本発明によって、集合述部のための柔軟な言語機構が設計される。集合述部は、プリミティブ述部または複合述部（論理演算子を伴う）のいずれかとすることができる。集合述部は、ウィンドウ指定によって決定される値の組を操作する。
【００３０】
第３に、本発明によって、明示的な束縛のないランク付き増分検索と、具体的な束縛（上位１０位など）を有するランク付き増分検索の両方をサポートする、集合述部のためのラン・タイム照会実行戦略が設計される。集合述部に基づいて検索を近似しようとするのではなく、本発明の戦略では、正しく集合述部に基づく検索の結果を計算する。
【００３１】
第４に、本発明によって、集合述部のランクがシステム定義関数だけを使用して計算される時の集合述部のための索引付け最適化戦略および照会最適化戦略が設計される。最後に、本発明によって、ランクがユーザ定義関数によって計算される集合述部のために索引付け最適化戦略および照会最適化戦略が拡張される。本発明は、集合述部に関する拡張可能な索引付けをサポートする。
【００３２】
本発明の使用には、以下を含む複数の長所がある。
・照会言語の機能強化された表現力。
・多くの応用分野に関する性能改善。
・データベース・システムのより広い適用度。
・集合述部に関するユーザ定義の検索技法。
【００３３】
本発明の主要な長所は、ユーザが、データベース・アプリケーションで集合述部に基づく検索を実行でき、よりよい性能を得ることができることである。より具体的な長所を、下で示す。
【００３４】
第１に、集合述部のＳＱＬ言語への導入は、ユーザに機能強化された表現力を与える。ユーザは、ＳＱＬ言語によって提供される総計関数を呼び出すアプリケーション・プログラムまたはストアド・プロシージャを使用して多少の集合述部をシミュレートすることができる可能性があるが、そのような手法は、使用可能度の問題と性能の問題を有する。これは、総計関数および集合述部が、異なる目的のために働くからである。総計関数の目的は、max、min、avg、count、またはoutなど、値の組に対してスカラ値を計算することである。集合述部の目的は、特定の集合特性を満足する値を検索することである。総計関数を用いると、使用可能度に関して、ユーザが上位５つの最も近いレストランを探したい場合に、ユーザは、レストランのランキングのデータを格納する明示的な列を作成した後に、その明示的なランキング列に対する条件を作成しなければならない。性能に関して、総計関数は、必ず計算される。その一方で、集合述部に基づく検索は、そのような計算を回避するか、制限することができる。
【００３５】
第２に、集合述部に基づく検索を直接にサポートすることによって、本発明は、多くの応用分野で性能改善をもたらすことができる。集合述部を評価する単純な手法は、集合述部のすべての可能な候補のランキングを計算し、その後、集合述部を満足する候補だけを選択することである。たとえば、上位５位までの最も近いレストランを見つけるには、単純な手法では、現在位置とすべてのレストランの位置との間の距離を計算し、その後、最短距離を用いて上位５つの最も近いレストランを選択することになる。本発明の１実施形態は、回答の正しさを保証しながら検索空間を制限する、集合述部のための検索機構を提供する。
【００３６】
第３に、本発明は、従来のスカラ述部（関係演算子および論理演算子）と集合述部の均一な取扱を提供する。その結果、索引付けおよび照会の最適化の既存のフレームワークを、集合述部に一般化することができる。たとえば、ローカル述部（local predicate）およびキー述部という概念は、スカラ述部と集合述部に同等に適用可能である。
【００３７】
第４に、本発明は、初めて、集合述部に関する拡張可能な索引付けをサポートする。さまざまな応用分野に関して、集合述部は、しばしば、ユーザ定義関数に基づくランキングを伴う。１実施形態では、データベース・システムが、集合述部に基づく検索方法を決定しない。この実施形態の場合、本発明は、アプリケーション開発者に権限を与え、その結果、アプリケーション開発者が、その専門領域の知識を利用して、集合述部に関する効率的な検索戦略を開発できるようになる。
【００３８】
総合的に、本発明からの使用可能度および性能の長所が、データベース技術をより広範囲の応用分野に適用することを可能にする。
【００３９】
Ｂ．集合述部の言語およびセマンティクス
本発明の１実施形態は、集合述部をサポートするためのＳＱＬ拡張を提供する。この手法では、スカラ述部と集合述部を均一な形で扱い、その結果、スカラ述部用の既存のインフラストラクチャを集合述部に使用できるようにする。
【００４０】
ｃ１＜ｃ２＋１０などのスカラ述部を検討されたい。スカラ述部の真の値を判定するためには、ｃ１とｃ２の値だけが必要である。これに対して、集合述部は、その真の値を判定するためにより多くの情報を必要とする。たとえば、上位５位までの給料を見つけるためには、以下の情報が必要である。
・集合述部に使用されるランキング：salary（給料）。
・所望の順序：上位５位の給料の降順または下位５位の給料の昇順。
・所望の回答の数：この場合は５つ。この数は、値が増分的に取り出され、いつでも停止または継続が可能である場合には省略することができる。
・集合述部が評価される対象の値の組（たとえば、あるテーブルのすべての給料の値、または各部署のすべての給料の値の組とすることができる）。
【００４１】
本発明では、新しい構文である集合述部を、ＳＱＬ言語の「検索条件」に定義する（説明を簡単にするために、以下の構文では複合集合述部を示さない。しかし、当業者は、本発明の範囲内で複合集合述部を使用することができることを理解するであろう）。拡張された構文は次の通りである。
述部は、スカラ述部または集合述部のいずれかとすることができる。さらに、集合述部の場合、ＲＡＮＫキーワード（すなわち集合述部識別子）によって、スカラ式が集合述部として識別される。ランキングの所望の順序は、ＡＳＣ（すなわち昇順）キーワードまたはＤＥＳＣ（すなわち降順）キーワード（すなわち結果順序付けインジケータ）に従って実行される。所望の結果の個数は、ＦＩＲＳＴ文節で指定される。ＦＩＲＳＴ文節が省略された場合には、すべての結果が、指定された順序で出力される。ＯＶＥＲ文節のウィンドウ指定が存在する場合には、これによって、集約を実行する方法が決定される（すなわち、集合述部が評価される対象の値の組が指定される）。集合ウィンドウが指定されない場合には、結果は、テーブル全体に対して集約される。
【００４３】
集合述部を評価する時には、まず、必要な情報のすべてを取り込む。その後、下で説明するその後の処理を実行する。
【００４４】
１特定の例として、name（名前）、dept（部署）、salary（給料）、およびage（年齢）という列がある、empという名前のテーブルがあると仮定する。次の例のＳＱＬステートメントは、上位５位の給料とそれに対応する名前を要求するステートメントである。
SELECT name,salary
FROM emp
WHERE RANK (salary) DESC FIRST 5
【００４５】
上のステートメントの場合、照会を評価する方法の１つは、すべてのレコードを取り出し、salaryに基づいてソートすることである。その後、上位５つを降順で返す。
【００４６】
各部署の上位５位までの給料を取り出すためには、次の例のＳＱＬステートメントを使用することができる。
SELECT dept,name,salary
FROM emp
WHERE RANK (salary) DESC FIRST 5 OVER(dept)
【００４７】
上では、ウィンドウ指定がdeptになっている。したがって、２つの部署がある場合には、各部署の上位５人の従業員が返される。
【００４８】
集合述部は、スカラ述部と一緒に使用することができる。次の例のＳＱＬステートメントを検討されたい。
SELECT dept,name,salary
FROM emp
WHERE RANK (salary) DESC FIRST 5 OVER (dept)
AND age < 25
【００４９】
集合述部とスカラ述部が同一レベルにあるので、上のＳＱＬステートメントのセマンティクスは、各部署でその部署内で上位５位までの給料を稼ぎ、年齢が２５歳未満の従業員の、部署、名前、および給料を見つけることである。
【００５０】
各部署の若い従業員の間で上位５位までの給料を見つけるには、次の例のＳＱＬステートメントを使用することができる。
SELECT dept,name,salary
FROM emp
WHERE age < 25
HAVING RANK (salary) DESC FIRST 5 OVER(dept)
【００５１】
ＨＡＶＩＮＧ文節が集合述部を有しない時に、ＨＡＶＩＮＧ文節内のすべてのスカラ述部の評価によって引き起こされる副作用がない場合に、それらのスカラ述部を、ＷＨＥＲＥ文節内の述部とマージできることに留意されたい。しかし、一般に、そのようなマージは、ＨＡＶＩＮＧ文節が少なくとも１つの集合述部を有する場合には実行されない）。
【００５２】
ＧＲＯＵＰ ＢＹ文節がある場合であっても、集合述部がそれ自体のグループ指定（ＯＶＥＲによって示される）を有するので、ＧＲＯＵＰ ＢＹ文節は問題なく集合述部と相互作用する。
【００５３】
給料の例で、上位第５位と上位第６位の給料が同一である場合に、１実施形態では、第６位の給料も回答セットに含まれる。この場合、ＲＡＮＫＧＡＰなどの追加キーワードを使用して、重複する項目（たとえば同一の給料）がある時にそれらを表示することを示す。もう１つの実施形態では、重複する項目が表示されない（たとえば、第５位の給料だけが表示され、第６位は表示されない）。
【００５４】
上の例では、分離された集合述部を検討した。スカラ述部と同様に、集合述部は、ＡＮＤ、ＯＲ、またはＮＯＴなどの論理演算子を使用して組み合わせることができる。そのような集合述部の組み合わせは、Ｒ．ファギン（Fagin）著、「Fuzzy Queries in Multimedia Database Systems」、Proceedings of the 1998 ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systemsでファギンによって検討されたものと異なることに留意されたい。Ｒ．ファギン（Fagin）の論文「Fuzzy Queries in Multimedia Database Systems」、Proceedings of the 1998 ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systemsに記載のものと同様の複合集合述部をサポートするために、以下の例の構文を使用することができる。
SELECT dept,name,salary
FROM emp
WHERE (RANK (salary) DESC AND RANK(age) ASC) FIRST 5 OVER(dept)
【００５５】
上のステートメントでは、部署ごとに、上位５人の若い高給取りの従業員を見つけようとする。複合集合述部のランキングは、各構成集合述部のランキングを互いに組み合わせる方法に依存する。１実施形態では、各構成集合述部に特定の重みを与えるための新しい構文が定義される（実際、上で示したファギンの論文では、各構成集合述部が、［０、１］の範囲のランキング値を備え、組み合わせ関数を使用して、構成集合述部のランキング値を計算する）。
【００５６】
もう１つの例として、distance（距離）が、２つの２次元点（たとえばｘ−ｙ平面内）の間のユークリッド距離を計算するユーザ定義関数（ＵＤＦ）であるものとする。次のステートメントは、例のＳＱＬステートメントのＷＨＥＲＥ文節内で「集合述部」を使用して、所与の位置から最も近い１０個のＡＴＭ（自動預金支払機）を見つける。
SELECT a.name,a.location,a.address
FROM ATM a
WHERE RANK ( distance(a.location,:whereIAm)) FIRST 10
【００５７】
直観的に、照会エンジンは、ＡＴＭテーブルのタプルを取り出し、ＷＨＥＲＥ文節のＵＤＦ呼出しの値に基づいてこれらのタプルをソートする。ソート順で上位１０個のタプルを、結果として返す。レコードが１０個未満の場合には、テーブル全体を返す。１実施形態では、重複するタプルは、上位１０個のリストの末尾に現れる場合に、結果セットから削除される。
【００５８】
ＷＨＥＲＥ文節に現れるほかに、集合述部は、次の例のＳＱＬステートメントに示されているように、ＨＡＶＩＮＧ文節にも現れることができる。
SELECT s.id,c.name,c.address,c.income
FROM customers c,storess
WHERE within (c.location,s.zone)= 1
HAVING RANK (c.income) FIRST COUNT(*) * 0.1 OVER(s.id)
【００５９】
このステートメントの結果セットには、store（店）ごとに、年収に関する顧客の上位１０％を表すタプルが含まれる。ＷＨＥＲＥ文節では、２つのテーブルの間の結合条件が指定され、ＨＡＶＩＮＧ文節では、店ごとに行われる集約が指定される。
【００６０】
Ｃ．集合述部検索のための拡張された索引方法およびアクセス方法
本発明の１実施形態は、集合述部検索のための拡張された索引方法およびアクセス方法を提供する。
【００６１】
以下は、既存のＳＱＬ言語の例である。
SELECT s.id,AVG(c.income)
FROM customers c,stores s
WHERE within(c.location,s.zone) = 1
GROUP BY s.id,s.expense
HAVING s.expense <= SUM(c.income) * 0.45
【００６２】
図３は、例のＳＱＬステートメントのための通常のアクセス・プラン３００を示す図である。ＪＯＩＮノードは、２つのテーブル（すなわちcustomersおよびstores）を結合することによって、結合タプルを作る。すなわち、「within(c.location,s.zone) = 1」が、ローカル述部として使用される。結合されたタプルは、指定されたＧＲＯＵＰ ＢＹ式（すなわちs.idおよびs.expense）に基づいて、ＳＯＲＴノードによってソートされる。ＧＲＯＵＰ ＢＹノードは、現在のグループ内のソート順の結合されたタプルを走査し、そのグループの総計関数（すなわちＡＶＧおよびＳＵＭ）を計算し、代表的なグループ化タプルをその出力ストリームにパイピングする。ＭＡＴＥＲＩＡＬＩＺＥノードが、最終的なフィルタリング（すなわち、s.expense <= SUM(c.income) * 0.45）を実行して、最終結果セットを生成する。
【００６３】
集合述部をサポートするために、本発明の１実施形態では、新しいアクセス・プラン演算子rk_sortを定義する。このrk_sortは、ＳＯＲＴノードのバリエーション（すなわち、拡張ソート演算子）である。rk_sort演算子は、４つの入力をとり、出力として、ランクによってソートされたタプルの組を作る。
【００６４】
最初の引数は、入力ストリームである。「ラウンド半径（round radius）」のために指定された列が、入力ストリームの各タプルに関連する。ラウンド半径の概念は、入力ストリームが複数のラウンドに分割され、ラウンドｎまでに、ラウンドｎの半径以下のスコアリング式を有する少なくともｋ個のタプルがある場合に、そのグループに属する残りのタプルを無視することによってそのグループのrk_sortを終了することができる場合の、rk_sort演算の早期終了を容易にするのに使用される。
【００６５】
図４は、ラウンド半径の説明に使用されるテーブル４００を示す図である。例として１次元検索を取り上げると、５００００ドル未満で上位５位までの給料を有する従業員について５人の従業員の名前を選択する場合、ラウンド半径は、図４のラウンド半径列４０２に示されているようにセットすることができる。具体的に言うと、本発明への入力は、当初はラウンド１から来る。これによって、所望のデータにあてはまる３人の従業員の名前が選択される。その後、ラウンド２のデータが来る。このデータは、特定のラウンドから来るものとしてタグを付けられるので、ラウンド半径によって、新しいラウンドが開始されることが示されることに留意されたい。また、あるラウンド内のレコードは、順序がソートされていない可能性があることに留意されたい。新しいラウンドで継続する前に、そのラウンドのレコードをソートし、その後、所望の数のレコードが選択された（この場合では５個）かどうかを判定する。３人の従業員の名前だけが選択されており、５が所望されるので、処理が継続される。その後、ラウンド２の３つの名前を処理し、所望のデータにあてはまるもう２人の従業員の名前（ApostolおよびJoan）が、ラウンド２から選択される。ラウンドのすべての項目を処理し（たとえば、ラウンド２では３レコード）、その後、所望の数のレコードが選択されたかどうかを判定する。この時点で、５人の従業員の名前が選択されている。したがって、レコードの処理を継続する必要はない。したがって、この例では、６レコードだけを処理した後に、５つの所望の従業員の名前が選択された。
【００６６】
直観的に、候補の検索は、内側から外側への「リング」のシーケンスに基づいて実行される。図５は、半径を表すリングの組５００を示す図である。具体的に言うと、リングに、図４に示された半径に対応する１、２、および３のラベルが付けられている。ラウンド半径には、問題の点とリングの外側の円の間の距離がセットされる。したがって、ラウンド半径の変更は、検索リングの変更を示す。たとえば、ラウンド１からラウンド２に移ると、評価される値は、リング２に含まれる値になる。「リング検索」が可能または使用可能でない場合には、入力ストリームのラウンド半径に無限大をセットし、その結果、タプルのすべてがrk_sort演算で評価されるようにする。
【００６７】
ラウンド半径は、データの分布を理解している人によってレコードに割り当てられる。データに関する統計は、たとえば、ＲＵＮＳＴＡＴＳなどの統計ユーティリティを実行することによって得ることができる。ラウンド半径は、列の値（たとえばsalary）に対応する。これを行った後に、アクセス・プランによって、処理のためにそのラウンド半径に基づいてレコードを取り出す。ラウンド半径に関連する列値に対して索引を作成する場合には、アクセス・プランでその索引を使用して、問題のラウンド半径内のレコードだけを取り出す。これによって、処理されソートされるレコードの量が減る。すなわち、ソートの早期終了がある。したがって、本発明の技法によって効率が改善される。
【００６８】
第２の引数rankは、検索のランクであり、これによって、結果セットのグループ・カーディナリティが決定される。すなわち、上位５位の給料を選択する例では、ランクが５である。ランクは、集合述部の数式（ＦＩＲＳＴに続く）から得られる。
【００６９】
第３の引数groupByListは、グループの形成を定義する式のリストである。たとえば、従業員の名前を部署によって選択する場合には、groupByListは部署になる。groupByListは、集合述部のウィンドウ指定（ＯＶＥＲに続く）から得られる。
【００７０】
第４の引数scoringExpは、集合述部の左側の式である。たとえば、salary<50000をscoringExpとすることができる。scoringExpは、集合述部のスカラ式（ＲＡＮＫに続く）から得られる。
【００７１】
rk_sort演算子の形式的なセマンティクスを、以下の擬似コードによって説明する。
rk_Sort(stream(roundRadius),rank,groupByList,scoringExp)=
１．すべてのグループについてラウンド番号を−１に初期化する。
２．While not ストリームの終り
ａ．ストリーム内の次に使用可能なタプルを取り出す
ｂ．Ｉｆ 新しいタプルの目標グループが凍結されている then 新しいタプルを破棄し、ステップ１に進む
ｃ．Ｉｆ タプルのラウンド半径（roundRadius）がグループ・ラウンド半径と異なる then
ｉ．グループ・ラウンド半径に新しい値をセットする
ｉｉ．Ｉｆ 現在のラウンド半径以下のスコアリング式（scoringExp）を有するタプルの数がランク（rank）以上である then 現在のグループを「凍結」し、１に進む
ｄ．GROUP BY リスト（groupByList）およびスコアリング式（scoringExp）の式に基づいて、ソートされたテーブルに新しいタプルを挿入する
３．まだ凍結されていないグループを凍結する。
４．ランクによってソートされたテーブルを、プランの次のステージにパイピングする
【００７２】
用語「凍結」は、このラウンドについてそれ以上レコードを調べる必要がないことを示すことに留意されたい。上の擬似コードを、下で図１６ないし１８の流れ図を使用して説明する。
【００７３】
Ｄ．照会の例
以下では、異なる集合述部のシナリオについてアクセス・プランを示す。すべてのテーブル操作の例において、rk_SORT演算子に渡されるラウンド半径は、無限大の値であり、絶対に変更されず、その結果、すべてのレコードが単一のラウンドで取り出される。これは、索引活用（index exploitation）の例にもあてはまり、活用される索引は、集合述部からの属性以外の属性に対して定義される。そのような場合には、いくつかのレコードをフィルタ・アウトするための部分的な索引活用があるが、ランキングに基づく早期終了のための索引活用はない。ランクに基づく早期終了のために索引を完全に活用できるようにするために、rk_SORT演算子は、ＩＳＣＡＮの後のＦＥＴＣＨ演算子の直後に現れ、集合述部はローカル述部として使用される。
【００７４】
以下は、単純な集合述部の例のＳＱＬステートメントである。
SELECT *
FROM customer c
WHERE RANK(dist(c.loc,:stl)) ASC FIRST 10
【００７５】
上のステートメントでは、ＳＴＬ（すなわちSanta Teresa Laboratory）に最も近い１０人の顧客（customer）が選択される。単純な集合述部のもう１つの例のＳＱＬステートメントを下に示す。
SELECT *
FROM customer c
WHERE RANK(c.income) DESC FIRST 10
【００７６】
上のステートメントでは、最も高い収入（income）を有する上位１０人の顧客が選択され、このステートメントでは、集合述部としてＵＤＦではなくテーブル属性（すなわち、customerテーブルのincome列）が使用されている。図６は、索引活用を有しないアクセス・プラン６００と、上の照会の両方が生成する索引活用があるアクセス・プラン６０２を示す図である。第２のステートメントは、customer.incomeの索引を活用できるように、customer.locではなくcustomer.incomeに対する索引を必要とすることに留意されたい。
【００７７】
索引活用がないアクセス・プラン６００では、ＴＳＣＡＮノードが、タプルについてcustomerテーブルを走査する。テーブル・レコードおよびラウンド半径が、ＴＳＣＡＮノードからrk_SORTノードに渡される。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個をＭＡＴＥＲＩＡＬＩＺＥノードにパイピングし、ＭＡＴＥＲＩＡＬＩＺＥノードは、パイピングされたタプルから属性を最終結果セットで返す。
【００７８】
索引活用がある場合、ＩＳＣＡＮノードは、ローカル述部としてdist(c.loc,:stl)を使用して、レコード識別子（ＲＩＤ）についてcustomer.loc索引を走査する。さらに、データの統計を知っているユーザによって提供される範囲ジェネレータが、範囲データをＩＳＣＡＮノードに供給する。その後、ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤからタプルを取り出し、テーブル・レコードおよびラウンド半径をrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットのために、パイピングされたタプルから属性を返す。
【００７９】
以下は、ブール式の集合述部に関する例のＳＱＬステートメントである。
SELECT *
FROM customer c
WHERE RANK(dist(c.loc,:stl)) ASC FIRST 10
AND c.income > 50000
【００８０】
上のステートメントでは、ＳＴＬ（すなわちSanta Teresa Laboratory）に最も近い１０人の顧客から、収入が５００００を超える顧客だけが選択される。図７は、loc属性に対する索引活用があるアクセス・プラン７００を示す図である。具体的に言うと、c.locに対する索引がある場合に、上のステートメントによって生成されるアクセス・プラン７００が、図７に示されている。述部c.income>50000が、rk_SORTノードに付加され、このノードに対する後フィルタとして働くことに留意されたい。具体的に言うと、ＩＳＣＡＮノードは、ローカル述部としてdist(c.loc, :stl)を使用することによって、customerテーブルの行のレコード識別子（ＲＩＤ）について索引を走査する。その後、ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤからタプルを取り出し、テーブル・レコードおよびラウンド半径をrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択し、後フィルタとしてc.income>50000を使用する。フィルタリングされた上位１０個のテーブル・レコードが、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットのために、パイピングされたタプルから属性を返す。
【００８１】
以下は、ＨＡＶＩＮＧ文節内の集合述部に関する例のＳＱＬステートメントである。
SELECT *
FROM customer c
WHERE c.income > 50000
HAVING RANK(dist(c.loc,:stl)) ASC FIRST 10
【００８２】
上のステートメントでは、収入が５００００を超え、ＳＴＬ（すなわちSanta Teresa Laboratory）に最も近い１０人の顧客が選択される。図８は、loc属性に対する索引活用があるアクセス・プラン８００を示す図である。上のステートメントについて生成される図８のアクセス・プラン８００は、前のステートメントのアクセス・プラン７００とほとんど同等であるが、述部c.income > 50000が、rk_SORTノードの前のＦＥＴＣＨノードに付加され、ＦＥＴＣＨノードに対する前フィルタとして働く。
【００８３】
具体的に言うと、ＩＳＣＡＮノードは、ローカル述部としてdist(c.loc, :stl）を使用して、customerテーブルのレコードのレコード識別子（ＲＩＤ）について索引を走査する。ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、前フィルタとしてc.income>50000を使用して、ＲＩＤからタプルを取り出す。rk_SORTノードは、テーブル・レコードおよびラウンド半径を受け取る。次に、rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択する。これらは、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８４】
代替案は、c.locではなくc.incomeに対する索引を活用し、その後、１ラウンドでランク付きソートを行うことである。これは、income属性に対する索引活用があるアクセス・プラン９００を示す図である図9に示されたアクセス・プラン９００をもたらす。具体的に言うと、ＩＳＣＡＮノードは、ローカル述部としてc.income>50000を使用して、customerテーブルのレコードのレコード識別子（ＲＩＤ）について索引を走査する。ＩＳＣＡＮノードは、レコード識別子およびラウンド半径をＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤからタプルを取り出す。rk_SORTノードは、テーブル・レコードおよびラウンド半径を受け取る。次に、rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択する。これらは、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８５】
どの索引が使用可能であるか、または、両方の索引が使用可能である場合に各述部の選択性見積もりがどれであるかに依存して、コンパイラは、２つのアクセス・プラン８００およびアクセス・プラン９００の間で選択することができ、また、索引が使用可能でない場合には、コンパイラは、図１０に示された簡単なテーブル走査のアクセス・プラン１０００を生成する。図１０は、索引活用なしのアクセス・プラン１０００を示す図である。アクセス・プラン１０００の場合、ＴＳＣＡＮノードは、フィルタとしてc.income>50000を使用して、タプルについてcustomerテーブルを走査する。ＴＳＣＡＮノードは、テーブル・レコードおよびラウンド半径をrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルを選択する。これらは、ＭＡＴＥＲＩＡＬＩＺＥノードに渡され、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８６】
以下は、ＪＯＩＮ内のウィンドウに対する集合述部に関する例のＳＱＬステートメントである。
SELECT *
FROM customer c,stores s
WHERE RANK(dist(c.loc,s.loc)) ASC FIRST 10 OVER (s.id)
【００８７】
上のステートメントでは、すべてのstore位置について最も近い１０人の顧客が選択される。これによって生成されるアクセス・プランを、図１１、図１２、および図１３に示す。
【００８８】
図１１は、索引活用がなく、検索引数と外部テーブルの間の機能的依存性もないアクセス・プラン１１００を示す図である。具体的に言うと、あるＴＳＣＡＮノードが、テーブル・レコードについてcustomerテーブルを走査し、これらをＪＯＩＮノードに渡す。もう１つのＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらを、ラウンド半径と共にＪＯＩＮノードに渡す。次に、ＪＯＩＮノードが、受け取ったレコードを結合し、これらを、ラウンド半径と共にrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとしてパイピングされたタプルから属性を返す。
【００８９】
図１２は、索引活用はないが、検索引数と外部テーブルの間の機能的依存性があるアクセス・プラン１２００を示す図である。具体的に言うと、あるＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらをＪＯＩＮノードに渡す。もう１つのＴＳＣＡＮノードが、テーブル・レコードについてcustomerテーブルを走査し、これらを、ラウンド半径と共にrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＪＯＩＮノードに渡す。次に、ＪＯＩＮノードが、受け取ったレコードを結合し、これらをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとして、パイピングされたタプルから属性を返す。
【００９０】
図１３は、索引活用があり、検索引数と外部テーブルの間の機能的依存性があるアクセス・プラン１３００を示す図である。具体的に言うと、ＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらをＪＯＩＮノードに渡す。ＩＳＣＡＮノードが、ローカル述部としてdist(c.loc,s.loc)を使用してcustomerテーブルのレコード識別子（ＲＩＤ）について索引を走査し、これらを、ラウンド半径と共にＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤを使用してcustomerテーブルからタプルを取り出し、これらを、ラウンド半径と共にrk_SORTノードに渡す。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＪＯＩＮノードに渡す。次に、ＪＯＩＮノードは、受け取ったレコードを結合し、これらをＭＡＴＥＲＩＡＲＩＺＥノードに渡し、ＭＡＴＥＲＩＡＲＩＺＥノードは、最終結果セットとして、パイピングされたタプルから属性を返す。
【００９１】
以下は、ＧＲＯＵＰ ＢＹ文節を有するＪＯＩＮ内の集合述部に関する例のＳＱＬステートメントである。
SELECT s.id,sum(c.income)
FROM customer c,store s
WHERE within(c.loc,s.zone) = 1
GROUP BY s.id HAVING RANK(sum(c.income)) DESC FIRST 10
【００９２】
上のステートメントでは、最も高い総合累積収入を有する顧客にサービスする、上位１０位までの店が選択される。この場合、ランキングが各グループの総計関数に基づくので、早期終了のために索引を活用することはできない。その関数は、グループのすべてのレコードを取り出し、ソートするまでは評価できないので、ランキングは、その後に開始しなければならず、テーブル全体を走査する前に終了することができない。しかし、customer.locに対して定義された索引がある場合には、その索引を活用して、ランキングを開始する前にいくつかのレコードをフィルタ・アウトすることができる。図１４は、部分的索引活用があるアクセス・プラン１４００を示す図である。
【００９３】
具体的に言うと、あるＴＳＣＡＮノードが、テーブル・レコードについてstoreテーブルを走査し、これらをＪＯＩＮノードに渡す。ＴＳＣＡＮノードが、ローカル述部として（within(c.loc,s.zone) = 1）を使用して、customerテーブルのレコード識別子（ＲＩＤ）について索引を走査し、これらを、ラウンド半径と共にＦＥＴＣＨノードに渡す。ＦＥＴＣＨノードは、ＲＩＤを使用してcustomerテーブルからタプルを取り出し、これらを、ラウンド半径と共にＪＯＩＮノードに渡す。次に、ＪＯＩＮノードが、受け取ったレコードを結合し、これらを、ラウンド半径と共にＳＯＲＴノードに渡す。ＳＯＲＴノードは、s.idによってタプルをソートし、これらを、ラウンド半径と共にＧＲＯＵＰ ＢＹノードに渡す。ＧＲＯＵＰ ＢＹノードは、総計関数を評価し、タプルをグループ化する。グループ化されたタプルおよびラウンド半径が、rk_SORTノードに渡される。rk_SORTノードは、集合述部を評価し、タプルにランクを付け、上位１０個のタプルをＭＡＴＥＲＩＡＬＩＺＥノードに渡し、ＭＡＴＥＲＩＡＬＩＺＥノードは、最終結果セットとして、パイピングされたタプルから属性を返す。
【００９４】
以下は、ＧＲＯＵＰ ＢＹ文節を伴う集合述部の例のＳＱＬステートメントである。
SELECT s.sizeRating,sum(c.purchases)
FROM customer c,store s
WHERE within(c.loc,store.loc) = 1
GROUP BY s.sizeRating
HAVING RANK(s.sizeRating) DESC FIRST 10
【００９５】
上のステートメントについて、storeテーブルのsizeRating属性が、ある外部レーティングによる、所与の店の顧客ベースのサイズを表すと仮定する。上のステートメントは、上位１０サイズ・グループのそれぞれの店の総売上を返す。この例の集合述部store.sizeRatingは属性であり、前の例のような総計関数ではないが、ランキングが個々のテーブル・レコードではなくグループ・レコードに対して実行されるので、上のステートメントは、store.sizeRatingに対する索引を活用することができない。したがって、このステートメントに対して生成されるアクセス・プランは、store.locに対して定義された索引がある場合にはアクセス・プラン１４００と同一になる。活用すべき索引がない場合には、アクセス・プランは、単純なテーブル走査アクセス・プランになる。
【００９６】
Ｅ．流れ図
図１５は、本発明を使用する処理を示す流れ図である。具体的に言うと、ブロック１５００は、集合述部を有する照会を作成することを表す。ブロック１５０２は、コンパイラが、集合述部を処理するために、拡張ソート演算子（rk_sort）を有するアクセス・プランを生成することを表す。ブロック１５０４は、アクセス・プランを実行し、それが実行される時に、集合述部を評価し、ランキング演算を実行することを表す。
【００９７】
図１６ないし１８は、集合述部を処理するための拡張ソート演算子（rk_sort）の処理を示す流れ図である。ブロック１６００は、拡張ソート演算子が、ストリーム（ラウンド半径を含む）、ランク、ＧＲＯＵＰ ＢＹリスト、およびスコアリング式を受け取ることを表す。ストリームは、タプルからなり、各タプルは、ラウンド半径の列値を有する。ランクは、集合述部の数式に対応し、ＧＲＯＵＰ ＢＹリストは、集合述部のウィンドウ指定に対応し、スコアリング式は、集合述部のスカラ式に対応する。
【００９８】
ブロック１６０２は、拡張ソート演算子が、すべてのグループについてグループ・ラウンド番号を−１に初期化することを表す。ブロック１６０４で、拡張ソート演算子が、ストリームの終りである（すなわち、すべてのタプルを処理した）かどうかを判定する。ストリームの終りである場合には、拡張ソート演算子は、ブロック１６２２に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６０６に継続する。
【００９９】
ブロック１６０６では、拡張ソート演算子が、ストリーム内の次に使用可能なタプルを取り出す。ブロック１６０８では、拡張ソート演算子が、タプルの目標グループが凍結されているかどうかを判定する。そうである場合には、拡張ソート演算子は、ブロック１６１０に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６１２に継続する。ブロック１６１０では、拡張ソート演算子が、タプルを破棄し、ブロック１６０４にループ・バックする。
【０１００】
ブロック１６１２では、拡張ソート演算子が、タプルのラウンド半径がグループ・ラウンド半径と異なるかどうかを判定する。そうである場合には、拡張ソート演算子は、ブロック１６１４に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６２０に継続する。
【０１０１】
ブロック１６１４では、拡張ソート演算子が、グループ・ラウンド半径に新しいラウンド半径をセットする。ブロック１６１６では、拡張ソート演算子（現在のグループ・ラウンド半径以下のスコアリング式を有するタプルの数）が、ランク（すなわちタプルの所望の個数）以上であるかどうかを判定する。そうである場合には、拡張ソート演算子は、ブロック１６１８に継続し、そうでない場合には、拡張ソート演算子は、ブロック１６２０に継続する。ブロック１６１８では、拡張ソート演算子が、現在のグループを凍結する（すなわち、そのグループについてこれ以上タプルが処理されないことを示す）。その後、拡張ソート演算子は、ブロック１６０４にループ・バックする。
【０１０２】
ブロック１６２０では、拡張ソート演算子が、ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、ソートされたテーブルにタプルを挿入する。その後、拡張ソート演算子は、ブロック１６０４にループ・バックする。
【０１０３】
ブロック１６０４で、ストリームの終りに達した場合、拡張ソート演算子は、ブロック１６２２に継続し、まだ凍結されていないグループを凍結する。その後、拡張ソート演算子は、ランクによってソートされたテーブルを、アクセス・プランの次のステージにパイピングする。
【０１０４】
Ｆ．本発明の追加の長所
この節では、本発明の追加の長所を示す。これらの記述された長所は、例示のみのために提供され、本発明の長所のすべてを表すものではない。
【０１０５】
集合述部をサポートするための複数の手法が探求されてきた。１つの手法は、特定の応用分野を目標とする索引付け機構を開発することである。たとえば、Ｒ−木を使用する最近隣照会の評価が、ロウスポウロス（Nick Roussopoulos）、ケリー（Stephen Kelley）、およびビンセント（Frederic Vincent）著、「Nearest Neighbor Queries」、Proceedings of the 1995 ACM-SIGMOD International Conference on Management of Data、米国カリフォルニア州サンノゼで調査された。
【０１０６】
Ｄ．Ａ．ホワイト（White）およびＲ．ジェイン（Jain）著、「Similarity Indexing with the SS-tree」、Proceedings of the 12th IEEE International Conference on Data Engineering、１９９６年２月、第５１６〜５２３ページに記載のＳＳ−木などの、新しい索引付けデータ構造も開発された。この手法は、特定の領域で機能するが、新しい応用分野は、検索、並行性、および回復のために通常の木機構の新しい実装を必要とする。特定の応用分野のためのそのような木の実装のコストは高い。
【０１０７】
もう１つの手法は、最近隣検索およびランク付き検索をサポートする一般化された検索木を開発することである。この手法は、アオキ（Paul Aoki）著、「Generalizing ”Search” in Generalized Search Trees」に記載のＧｉＳＴの拡張によって例示される。この手法は、ユーザが木のトラバースのすべてのステップを制御できるようにすることによる拡張性という長所を有する。短所は、そのようなユーザ制御が、しばしばユーザ定義関数を介して達成されることである。木トラバースの各ステップでのユーザ定義関数の呼び出しは、大きい実行時オーバーヘッドを引き起こす可能性がある。
【０１０８】
第３の手法は、たとえばチャウドゥーリィ（Surajit Chaudhuri）およびグラバノ（Luis Gravano）著、「Evaluating Top-k Selection Queries」、Proceedings of the 25th VLDB Conference、１９９９年に記載のものなどの、上位ｋ位選択照会を範囲を使用する通常の選択照会に変形することである。この手法の主な問題は、上位ｋ位選択照会に対応する範囲照会をコンパイル時に決定する必要があることである。コンパイル時の推定が正しくない場合には、上位ｋ位選択照会に対する回答を得ることができない可能性がある。
【０１０９】
本明細書に記載の発明は、複数の長所を有する。第１に、本発明は、ユーザがランク付き検索を制御でき、領域固有の手法の短所が回避されるという意味で、拡張可能である。第２に、そのような制御が、基礎となるアクセス方法によって使用される一連の検索範囲を生成することによって、フレームワークの上位レベルで行われる。これによって、ＧｉＳＴでの手法の実行時オーバーヘッドが回避される。第３に、本発明は、動的であり増分的である。
【０１１０】
結論
これで本発明の好ましい実施形態の説明を終える。以下で、本発明を達成するためのいくつかの代替実施形態を説明する。たとえば、メインフレーム、ミニコンピュータ、またはパーソナル・コンピュータなどのすべての種類のコンピュータ、もしくは、タイム・シェアリング・メインフレーム、ローカル・エリア・ネットワーク、または独立型パーソナル・コンピュータなどのコンピュータ構成を、本発明と共に使用することができる。
【０１１１】
本発明の好ましい実施形態の前述の説明は、例示と説明のために提示された。網羅的であることまたは開示された正確な形態に本発明を制限することは、意図されていない。上記の教示に鑑みて、多数の修正形態および変更形態が可能である。本発明の範囲は、この詳細な説明によるのではなく、請求項によって制限されることが意図されている。
【０１１２】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１１３】
（１）コンピュータに接続されたデータ・ストア内のデータを操作するために前記コンピュータ内でステートメントを実行する方法であって、
集合述部を有するステートメントを受け取るステップと、
前記ステートメントを評価する時に、前記集合述部をランク・データに処理するステップと
を含む方法。
（２）前記集合述部が、検索条件に含まれる、上記（１）に記載の方法。
（３）前記集合述部が、数式を含む、上記（１）に記載の方法。
（４）前記集合述部が、順序付けインジケータを含む、上記（１）に記載の方法。
（５）前記集合述部が、ウィンドウ指定を含む、上記（１）に記載の方法。
（６）前記集合述部が、スカラ式を含む、上記（１）に記載の方法。
（７）評価が、拡張ソート演算子の実行を含む、上記（１）に記載の方法。
（８）前記拡張ソート演算子が、アクセス・プランの一部である、上記（７）に記載の方法。
（９）前記拡張ソート演算子の実行が、１つまたは複数のタプルを含むストリーム、ランク、０個以上のグループを含むＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含む、上記（７）に記載の方法。
（１０）前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄するステップをさらに含む、上記（９）に記載の方法。（１１）グループ・ラウンド半径を判定するステップと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、
前記グループ・ラウンド半径にそのラウンド半径をセットするステップと、
前記グループについて所望の数のタプルが識別された場合に、前記グループを凍結するステップと
をさらに含む、上記（９）に記載の方法。
（１２）前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入するステップをさらに含む、上記（９）に記載の方法。
（１３）前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結するステップをさらに含む、上記（９）に記載の方法。
（１４）データを操作するためにステートメントを実行する装置であって、
データを記憶するデータ・ストアを接続されたコンピュータと、
前記コンピュータによって実行される、集合述部を有するステートメントを受け取り、前記ステートメントを評価する時に、前記集合述部をランク・データに処理する、１つまたは複数のコンピュータ・プログラムと
を含む装置。
（１５）前記集合述部が、検索条件に含まれる、上記（１４）に記載の装置。
（１６）前記集合述部が、数式を含む、上記（１４）に記載の装置。
（１７）前記集合述部が、順序付けインジケータを含む、上記（１４）に記載の装置。
（１８）前記集合述部が、ウィンドウ指定を含む、上記（１４）に記載の装置。（１９）前記集合述部が、スカラ式を含む、上記（１４）に記載の装置。
（２０）評価が、拡張ソート演算子の実行を含む、上記（１４）に記載の装置。（２１）前記拡張ソート演算子が、アクセス・プランの一部である、上記（２０）に記載の装置。
（２２）前記拡張ソート演算子の実行が、１つまたは複数のタプルを含むストリーム、ランク、０個以上のグループを含むＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含む、上記（２０）に記載の装置。
（２３）前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄することをさらに含む、上記（２２）に記載の装置。
（２４）グループ・ラウンド半径を判定することと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、
前記グループ・ラウンド半径にそのラウンド半径をセットすることと、
前記グループについて所望の数のタプルが識別された場合に、前記グループを凍結することと
をさらに含む、上記（２２）に記載の装置。
（２５）前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入することをさらに含む、上記（２２）に記載の装置。
（２６）前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結することをさらに含む、上記（２２）に記載の装置。
（２７）集合述部を有するステートメントを受け取るステップと、
前記ステートメントを評価する時に、前記集合述部をランク・データに処理するステップと
を含む、コンピュータに接続されたデータ・ストア内のデータを操作するために前記コンピュータ内でステートメントを実行するための方法ステップを実行するために前記コンピュータによって実行可能な１つまたは複数の命令を実施する、コンピュータによって可読のコンピュータ・プログラム担体を含む製造品。
（２８）前記集合述部が、検索条件に含まれる、上記（２７）に記載の製造品。（２９）前記集合述部が、数式を含む、上記（２７）に記載の製造品。
（３０）前記集合述部が、順序付けインジケータを含む、上記（２７）に記載の製造品。
（３１）前記集合述部が、ウィンドウ指定を含む、上記（２７）に記載の製造品。
（３２）前記集合述部が、スカラ式を含む、上記（２７）に記載の製造品。
（３３）評価が、拡張ソート演算子の実行を含む、上記（２７）に記載の製造品。
（３４）前記拡張ソート演算子が、アクセス・プランの一部である、上記（３３）に記載の製造品。
（３５）前記拡張ソート演算子の実行が、１つまたは複数のタプルを含むストリーム、ランク、０個以上のグループを含むＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含む、上記（３３）に記載の製造品。
（３６）前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄するステップをさらに含む、上記（３５）に記載の製造品。
（３７）グループ・ラウンド半径を判定するステップと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、
前記グループ・ラウンド半径にそのラウンド半径をセットするステップと、
前記グループについて所望の数のタプルが識別された場合に、前記グループを凍結するステップと
をさらに含む、上記（３５）に記載の製造品。
（３８）前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入するステップをさらに含む、上記（３５）に記載の製造品。
（３９）前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結するステップをさらに含む、上記（３５）に記載の製造品。
【図面の簡単な説明】
【図１】本発明の実施形態のハードウェア環境を示し、具体的には、通常の分散コンピュータ・システムを示す概略図である。
【図２】ＳＱＬステートメントを評価する処理を示す図である。
【図３】例のＳＱＬステートメントの通常のアクセス・プラン３００を示す図である。
【図４】ラウンド半径の説明に使用されるテーブルを示す図である。
【図５】半径を表すリングの組を示す図である。
【図６】索引活用がないアクセス・プランと２つの照会の索引活用があるアクセス・プランを示す図である。
【図７】 loc属性に対する索引活用があるアクセス・プランを示す図である。
【図８】 loc属性に対する索引活用があるアクセス・プランを示す図である。
【図９】 income属性に対する索引活用があるアクセス・プランを示す図である。
【図１０】索引活用がないアクセス・プランを示す図である。
【図１１】索引活用がなく、検索引数と外部テーブルの間の機能的依存性もないアクセス・プランを示す図である。
【図１２】索引活用はないが、検索引数と外部テーブルの間の機能的依存性があるアクセス・プランを示す図である。
【図１３】索引活用があり、検索引数と外部テーブルの間の機能的依存性があるアクセス・プランを示す図である。
【図１４】部分的索引活用があるアクセス・プランを示す図である。
【図１５】本発明を使用する処理を示す流れ図である。
【図１６】集合述部を処理するための、拡張ソート演算子（rk_sort）の処理を示す流れ図である。
【図１７】集合述部を処理するための、拡張ソート演算子（rk_sort）の処理を示す流れ図である。
【図１８】集合述部を処理するための、拡張ソート演算子（rk_sort）の処理を示す流れ図である。
【符号の説明】
１０２ コンピュータ・システム
１０４ データ記憶装置
１０６ オペレータ・インターフェース
１０８ データベース・サービス・モジュール
１１０ リレーショナル・データベース・サービス（ＲＤＳ）
１１２ データ・マネージャ
１１４ バッファ・マネージャ
１１６ 他のコンポーネント
１１８ モニタ
２００ ＳＱＬプログラム
２０２ コンパイラ
２０４ 解釈済みコード
２０６ データベース・ランタイム・ライブラリ
２０８ インタープリタ
２１０ リレーショナル・データベース・マネージャ
２１２ データベース
３００ アクセス・プラン
４００ テーブル
４０２ ラウンド半径列
Claims (21)
- コンピュータに接続されたデータ・ストア内のデータを操作するために前記コンピュータ内でステートメントを実行する方法であって、
個々の値について真または偽を判断するための集合述部を有するステートメントを前記コンピュータのメモリにロードするステップであって、前記集合述部は、検索条件に含まれ、スカラ式と順序付けインジケータとを含む、前記ロードするステップと、
前記メモリにロードしたステートメントを実行するために前記データ・ストア内のデータにアクセスするステップと、
前記ロードしたステートメントを前記コンピュータによって実行する時に、前記集合述部に基づきランク付け処理するステップを含む方法であって、
前記実行は、拡張ソート演算子の実行を含み、前記拡張ソート演算子の実行は、１つまたは複数のタプルを含むストリーム、ランク、ＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含み、前記ストリームは複数のラウンドに分割され、グループ・ラウンド半径が各レコードに割り当てられており、
前記ランク付け処理するステップは、
前記グループ・ラウンド半径を前記コンピュータによって判定するサブステップと、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、前記グループ・ラウンド半径にそのラウンド半径を前記コンピュータによってセットし、前記グループについて所望の数のタプルが識別された場合に、前記グループを前記コンピュータによって凍結するサブステップと、
これにより、所定の数の真と判断される前記アクセスしたデータをランク付け処理するサブステップと
を含む、方法。 - 前記集合述部が、数式を含む、請求項１に記載の方法。
- 前記集合述部が、ウィンドウ指定を含む、請求項１に記載の方法。
- 前記拡張ソート演算子が、アクセス・プランの一部である、請求項１に記載の方法。
- 前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄するステップをさらに含む、請求項１に記載の方法。
- 前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入するステップをさらに含む、請求項１に記載の方法。
- 前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結するステップをさらに含む、請求項１に記載の方法。
- データを操作するためにステートメントを実行する装置であって、
データを記憶するデータ・ストアを接続されたコンピュータと、
個々の値について真または偽を判断するための集合述部を有するステートメントを前記コンピュータのメモリにロードする手段であって、前記集合述部は、検索条件に含まれ、スカラ式と順序付けインジケータとを含む、前記ロードする手段と、
前記メモリにロードしたステートメントを実行するために前記データ・ストア内のデータにアクセスする手段と、
前記ロードしたステートメントを前記コンピュータによって実行する時に、前記集合述部に基づきランク付け処理する手段を含む装置であって、
前記実行は、拡張ソート演算子の実行を含み、前記拡張ソート演算子の実行は、１つまたは複数のタプルを含むストリーム、ランク、ＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含み、前記ストリームは複数のラウンドに分割され、グループ・ラウンド半径が各レコードに割り当てられており、
前記ランク付け処理する手段は、
前記グループ・ラウンド半径を前記コンピュータによって判定する手段と、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、前記グループ・ラウンド半径にそのラウンド半径を前記コンピュータによってセットし、前記グループについて所望の数のタプルが識別された場合に、前記グループを前記コンピュータによって凍結する手段と、
これにより、所定の数の真と判断される前記アクセスしたデータをランク付け処理する手段と
を含む、装置。 - 前記集合述部が、数式を含む、請求項８に記載の装置。
- 前記集合述部が、ウィンドウ指定を含む、請求項８に記載の装置。
- 前記拡張ソート演算子が、アクセス・プランの一部である、請求項８に記載の装置。
- 前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄することをさらに含む、請求項８に記載の装置。
- 前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入する手段をさらに含む、請求項８に記載の装置。
- 前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結する手段をさらに含む、請求項８に記載の装置。
- コンピュータに接続されたデータ・ストア内のデータを操作するために前記コンピュータ内でステートメントを実行するプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記コンピュータに、
個々の値について真または偽を判断するための集合述部を有するステートメントを前記コンピュータのメモリにロードさせ、
前記メモリにロードしたステートメントを実行するために前記データ・ストア内のデータにアクセスさせ、
前記ロードしたステートメントを実行する時に、前記集合述部に基づきランク付け処理させるプログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記集合述部は、検索条件に含まれ、スカラ式と順序付けインジケータとを含み、
前記実行は、拡張ソート演算子の実行を含み、前記拡張ソート演算子の実行は、１つまたは複数のタプルを含むストリーム、ランク、ＧＲＯＵＰ ＢＹリスト、およびスコアリング式の受け取りを含み、前記ストリームは複数のラウンドに分割され、グループ・ラウンド半径が各レコードに割り当てられており、
前記ランク付け処理は、
前記コンピュータに、
前記グループ・ラウンド半径を判定させ、
前記タプルが前記グループ・ラウンド半径と異なるラウンド半径を有する時に、前記グループ・ラウンド半径にそのラウンド半径をセットさせ、前記グループについて所望の数 のタプルが識別された場合に、前記グループを凍結させ、
これにより、所定の数の真と判断される前記アクセスしたデータをランク付け処理させる
プログラムを記録したコンピュータ読み取り可能な記録媒体。 - 前記集合述部が、数式を含む、請求項１５に記載のコンピュータ読み取り可能な記録媒体。
- 前記集合述部が、ウィンドウ指定を含む、請求項１５に記載のコンピュータ読み取り可能な記録媒体。
- 前記拡張ソート演算子が、アクセス・プランの一部である、請求項１５に記載のコンピュータ読み取り可能な記録媒体。
- 前記コンピュータに、前記ストリーム内のタプルごとに、その目標グループが凍結されている場合に前記タプルを破棄させるプログラムをさらに記録した請求項１５に記載のコンピュータ読み取り可能な記録媒体。
- 前記コンピュータに、前記ＧＲＯＵＰ ＢＹリストの値およびスコアリング式の値に基づいて、前記タプルをランクによってソートされたテーブルに挿入させるプログラムをさらに記録した請求項１５に記載のコンピュータ読み取り可能な記録媒体。
- 前記コンピュータに、前記ストリーム内のすべてのタプルが処理された時に、まだ凍結されていないグループを凍結させるプログラムをさらに記録した請求項１５に記載のコンピュータ読み取り可能な記録媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/505165 | 2000-02-16 | ||
| US09/505,165 US6947934B1 (en) | 2000-02-16 | 2000-02-16 | Aggregate predicates and search in a database management system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001273327A JP2001273327A (ja) | 2001-10-05 |
| JP3640346B2 true JP3640346B2 (ja) | 2005-04-20 |
Family
ID=24009288
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001034814A Expired - Fee Related JP3640346B2 (ja) | 2000-02-16 | 2001-02-13 | データベース管理システムにおける集合述部および検索 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6947934B1 (ja) |
| JP (1) | JP3640346B2 (ja) |
| DE (1) | DE10103574A1 (ja) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6385604B1 (en) | 1999-08-04 | 2002-05-07 | Hyperroll, Israel Limited | Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements |
| US6408292B1 (en) | 1999-08-04 | 2002-06-18 | Hyperroll, Israel, Ltd. | Method of and system for managing multi-dimensional databases using modular-arithmetic based address data mapping processes on integer-encoded business dimensions |
| US20020029207A1 (en) | 2000-02-28 | 2002-03-07 | Hyperroll, Inc. | Data aggregation server for managing a multi-dimensional database and database management system having data aggregation server integrated therein |
| US8069193B2 (en) * | 2001-03-28 | 2011-11-29 | International Business Machines Corporation | Method and system for utilizing a generic scalar function to allow a column function to operate on row data |
| US7620615B1 (en) * | 2001-10-26 | 2009-11-17 | Teradata Us, Inc. | Joins of relations in an object relational database system |
| US7213011B1 (en) * | 2002-04-08 | 2007-05-01 | Oracle International Corporation | Efficient processing of multi-column and function-based in-list predicates |
| US7542962B2 (en) * | 2003-04-30 | 2009-06-02 | International Business Machines Corporation | Information retrieval method for optimizing queries having maximum or minimum function aggregation predicates |
| US7415461B1 (en) * | 2005-08-03 | 2008-08-19 | At&T Corp | Apparatus and method for merging results of approximate matching operations |
| US7512282B2 (en) * | 2005-08-31 | 2009-03-31 | International Business Machines Corporation | Methods and apparatus for incremental approximate nearest neighbor searching |
| US7814113B2 (en) * | 2006-11-07 | 2010-10-12 | University Of Washington Through Its Center For Commercialization | Efficient top-K query evaluation on probabilistic data |
| US7769755B2 (en) * | 2006-11-30 | 2010-08-03 | Microsoft Corporation | Efficient execution of aggregation queries |
| US10031938B2 (en) * | 2006-12-04 | 2018-07-24 | International Business Machines Corporation | Determining Boolean logic and operator precedence of query conditions |
| US7853603B2 (en) * | 2007-05-23 | 2010-12-14 | Microsoft Corporation | User-defined relevance ranking for search |
| US20090006431A1 (en) * | 2007-06-29 | 2009-01-01 | International Business Machines Corporation | System and method for tracking database disclosures |
| JP5377897B2 (ja) * | 2007-10-29 | 2013-12-25 | 株式会社日立製作所 | ストリームデータのランキングクエリ処理方法およびランキングクエリ処理機構を有するストリームデータ処理システム |
| US8335782B2 (en) * | 2007-10-29 | 2012-12-18 | Hitachi, Ltd. | Ranking query processing method for stream data and stream data processing system having ranking query processing mechanism |
| US9053466B2 (en) | 2007-10-31 | 2015-06-09 | International Business Machines Corporation | Publishing and subscribing to calendar events information via categorical mapping methodology |
| US8352470B2 (en) * | 2008-05-23 | 2013-01-08 | International Business Machines Corporation | Adaptive aggregation: improving the performance of grouping and duplicate elimination by avoiding unnecessary disk access |
| US9418107B2 (en) * | 2008-07-30 | 2016-08-16 | At&T Intellectual Property I, L.P. | Method and apparatus for performing query aware partitioning |
| US8204873B2 (en) * | 2009-08-26 | 2012-06-19 | Hewlett-Packard Development Company, L.P. | System and method for query expression optimization |
| US9665620B2 (en) | 2010-01-15 | 2017-05-30 | Ab Initio Technology Llc | Managing data queries |
| US9244976B1 (en) | 2010-12-16 | 2016-01-26 | The George Washington University and Board of Regents | Just-in-time analytics on large file systems and hidden databases |
| US9244975B2 (en) * | 2010-12-16 | 2016-01-26 | The George Washington University | Just-in-time analytics on large file systems |
| US9116955B2 (en) | 2011-05-02 | 2015-08-25 | Ab Initio Technology Llc | Managing data queries |
| US8660985B2 (en) * | 2012-04-11 | 2014-02-25 | Renmin University Of China | Multi-dimensional OLAP query processing method oriented to column store data warehouse |
| WO2015073003A1 (en) * | 2013-11-14 | 2015-05-21 | Hewlett-Packard Development Company, L.P. | Estimating data |
| CA3092699C (en) | 2013-12-06 | 2023-07-25 | Ab Initio Technology Llc | Source code translation |
| US9747331B2 (en) | 2014-10-06 | 2017-08-29 | International Business Machines Corporation | Limiting scans of loosely ordered and/or grouped relations in a database |
| US10437819B2 (en) | 2014-11-14 | 2019-10-08 | Ab Initio Technology Llc | Processing queries containing a union-type operation |
| US10176226B2 (en) * | 2014-11-26 | 2019-01-08 | Looker Data Sciences, Inc. | Relation aware aggregation (RAA) on normalized datasets |
| US10417281B2 (en) | 2015-02-18 | 2019-09-17 | Ab Initio Technology Llc | Querying a data source on a network |
| US10210210B2 (en) * | 2015-10-21 | 2019-02-19 | International Business Machines Corporation | Adaptive multi-index access plan for database queries |
| US11093223B2 (en) | 2019-07-18 | 2021-08-17 | Ab Initio Technology Llc | Automatically converting a program written in a procedural programming language into a dataflow graph and related systems and methods |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5367675A (en) | 1991-12-13 | 1994-11-22 | International Business Machines Corporation | Computer automated system and method for optimizing the processing of a query in a relational database system by merging subqueries with the query |
| US5412804A (en) | 1992-04-30 | 1995-05-02 | Oracle Corporation | Extending the semantics of the outer join operator for un-nesting queries to a data base |
| US5590324A (en) | 1995-02-07 | 1996-12-31 | International Business Machines Corporation | Optimization of SQL queries using universal quantifiers, set intersection, and max/min aggregation in the presence of nullable columns |
| US5761657A (en) | 1995-12-21 | 1998-06-02 | Ncr Corporation | Global optimization of correlated subqueries and exists predicates |
| US5713015A (en) | 1996-05-30 | 1998-01-27 | International Business Machines Corporation | Reordering of complex SQL queries involving GROUPBYs, joins, outer joins and full outer joins |
| US5884299A (en) | 1997-02-06 | 1999-03-16 | Ncr Corporation | Optimization of SQL queries involving aggregate expressions using a plurality of local and global aggregation operations |
| US5905982A (en) | 1997-04-04 | 1999-05-18 | International Business Machines Corporation | Handling null values in SQL queries over object-oriented data |
| US5794246A (en) * | 1997-04-30 | 1998-08-11 | Informatica Corporation | Method for incremental aggregation of dynamically increasing database data sets |
-
2000
- 2000-02-16 US US09/505,165 patent/US6947934B1/en not_active Expired - Lifetime
-
2001
- 2001-01-27 DE DE2001103574 patent/DE10103574A1/de not_active Ceased
- 2001-02-13 JP JP2001034814A patent/JP3640346B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001273327A (ja) | 2001-10-05 |
| DE10103574A1 (de) | 2001-08-30 |
| US6947934B1 (en) | 2005-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3640346B2 (ja) | データベース管理システムにおける集合述部および検索 | |
| US6529896B1 (en) | Method of optimizing a query having an existi subquery and a not-exists subquery | |
| US5963933A (en) | Efficient implementation of full outer join and anti-join | |
| US6965891B1 (en) | Method and mechanism for partition pruning | |
| US6278994B1 (en) | Fully integrated architecture for user-defined search | |
| US5367675A (en) | Computer automated system and method for optimizing the processing of a query in a relational database system by merging subqueries with the query | |
| US7882100B2 (en) | Database system with methodology for generating bushy nested loop join trees | |
| Cui et al. | Tracing the lineage of view data in a warehousing environment | |
| US5590324A (en) | Optimization of SQL queries using universal quantifiers, set intersection, and max/min aggregation in the presence of nullable columns | |
| US6219662B1 (en) | Supporting database indexes based on a generalized B-tree index | |
| JP3104708B2 (ja) | 関係データベースシステムの表を結合する方法 | |
| US6826562B1 (en) | Method of simplifying and optimizing scalar subqueries and derived tables that return exactly or at most one tuple | |
| US6105020A (en) | System and method for identifying and constructing star joins for execution by bitmap ANDing | |
| US6424967B1 (en) | Method and apparatus for querying a cube forest data structure | |
| US8285707B2 (en) | Method of querying relational database management systems | |
| US5619692A (en) | Semantic optimization of query order requirements using order detection by normalization in a query compiler system | |
| US7359922B2 (en) | Database system and methodology for generalized order optimization | |
| US6249783B1 (en) | Method and apparatus for efficiently executing built-in functions | |
| US6931390B1 (en) | Method and mechanism for database partitioning | |
| US6285996B1 (en) | Run-time support for user-defined index ranges and index filters | |
| CA2418163A1 (en) | Method of query transformation using window aggregation | |
| US7356542B2 (en) | DML statements for densifying data | |
| US20080065592A1 (en) | Method, system and computer-readable media for software object relationship traversal for object-relational query binding | |
| US20040220908A1 (en) | Information retrieval system and method for optimizing queries having maximum or minimum function aggregation predicates | |
| US20060161525A1 (en) | Method and system for supporting structured aggregation operations on semi-structured data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20040202 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20040205 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040308 Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040308 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20040308 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040309 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040916 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040916 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040916 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050105 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050105 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20050105 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050114 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3640346 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080128 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100128 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100128 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110128 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120128 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130128 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140128 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |