JP2002510088A

JP2002510088A - 予め演算されたビューの処理

Info

Publication number: JP2002510088A
Application number: JP2000541606A
Authority: JP
Inventors: ラーサ，エス．コルビー，; リチャード，エル．コール，; エドワード，ピー．ハスラム，; ナシジャザイェリ，; ギャルトジョンソン，; ウィリアム，ジェイ．マッケーナ，; デイヴィッド，ジー．ジュニアウィルハイト，
Original assignee: インフォミックスソフトウェア，インコーポレイテッド
Priority date: 1998-03-27
Filing date: 1999-03-25
Publication date: 2002-04-02
Also published as: US20010013030A1; CA2326513C; CA2326513A1; AU3198599A; WO1999050762A1; US6480836B1; US6594653B2; US20020077997A1; BR9909896A; EP1066574A4; EP1066574A1; AU761900B2; US6493699B2

Abstract

(57)【要約】データベースについてのユーザークエリーに返答するために予め演算されたビューを処理するための方法と装置が記載される。予演算のストラトジの有効性についてのユーザーデータベースクエリー９０は、ユーザーデータベースクエリー履歴に基づき、データベース１０４に対する全ての可能なビューから成るひとつのサブセットから構成される分析スペースを定義することによって、および、分析スペースにおけるビューを特徴付けることによって応答され得る。ストラクチャは、クエリー書換えファシリティ９２の能力に基づき、データベースに対する全ての可能なビューから成るひとつのサブセットから構成される分析スペースに賦課でき、分析スペースにおけるビューを、特徴付けることができる。コスト公式が、データベースに含まれたデータのユーザ定義サブセットに基づき、分析スペースへ適用することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

関連出願とのクロスリファレンス本出願は、下記の同時出願に基づく優先権を主張し、これら出願は引用により
本明細書中に組み込まれ、それらは：米国特許仮出願第６０，０７９，６７９号
、１９９８年３月２７日出願、発明の名称「アドバイザを利用することによりデ
ータベースクエリーに返答するためのシステムと方法」；米国特許仮出願第６０
，０７９，６７０号、１９９８年３月２７日出願、発明の名称「生成された候補
ビューを利用することによりデータベースクエリに返答するためのシステムと方
法」；米国特許仮出願第６０，０７９，６７１号、１９９８年３月２７日出願、
発明の名称「集積サーバを利用することによりデータベースクエリに返答するた
めのシステムと方法」；および、米国特許仮出願第０９／０４９，７８４号、１
９９８年３月２７日出願、発明の名称「リレーショナルデータベースクエリを書
換えるためのシステムと方法」；である。

【０００２】本出願は、データベースについてのユーザークエリーに応答して予め演算され
たビューを（管理を含み）処理することに関する。

【０００３】

【従来の技術】

データベースは、通例、適度に充分に定義された一定の目的に関係するデータ
の集合である。データは、普通には、メタデータによって定義される既知のフォ
ーマットを有する。データベースでのデータは、普通には、データベース管理シ
ステムによって格納され、取出され、そして修正される。リレーショナルデータ
ベース管理システムは、情報をテーブル中に、データの行と列で格納し、検索を
行う。リレーショナルデータベースでは、テーブルの行は、普通には、レコード
（個別の項目についての情報の集合）をテーブルし、列は、普通には、フィール
ド（レコードの特定の属性）をテーブルす。リレーショナルデータベース管理シ
ステムは、一方のテーブルでのフィールドからの情報を、他方のテーブルの対応
するフィールドでの情報と突合わせることによって、および、両テーブルからの
データを組合せる第３のテーブルを作成することによってデータベースについて
のユーザークエリーに応答できる。例えば、一方のテーブルが、フィールド EMP
LOYEE-ID（従業員ＩＤ）、 LAST-NAME （姓）、 FIRST-NAME（名）、 DEPT-ID（
部門ＩＤ）、 SALARY（給与）と HIRE-DATE（採用日）、含み、別のテーブルが
、フィールド DEPT-ID（部門ＩＤ）, DEPT-NAME（部門名称）と、LOCATION（場所）を含む場合、リレーショナルデータベース管理システムは、特定の場所における部門で働いている全ての従業員の名前を見出すために、２つのテーブルで
DEPT-ID（部門ＩＤ）フィールドを突合わすことができる。

【０００４】ユーザは、普通には、データ・サブ言語（例えば、ＳＱＬ）を使用してリレー
ショナルデータベースにクエリーを発し、更新し、および管理する。データ・サ
ブ言語は、データにアクセスする特化された目的のために別のコンピュータ言語
と関連して使用され得るひとつである。Relational Technology, Inc. (ASK/Ing
res) からのＱＵＥＬと Digital Equipment Corporation からのＲＤＭＬを含め
、多くのリレーショナルデータ・サブ言語がある。ＳＱＬは、リレーショナルデ
ータベースへのアクセスのために正式に標準化され、広く実装され使用される、
しかし、ＳＱＬには多くの変形がある（例えば、California 州 Menlo Park の
Informix Software, Inc. からのＲＩＳＱＬ（登録商標））。

【０００５】リレーショナルデータベースモデルでは、データの基本単位は、関係である。
ＳＱＬでは、その関係はテーブルによってテーブルされる。関係は、普通には、
ひとつ以上の属性（ＳＱＬでは列としてテーブルされる）から構成され、その各
々は、データの種類（例えば、文字列、整数、浮動小数点数）に関連する。デー
タは、普通には、テーブル中のタプル（ＳＱＬの行）に格納される。

【０００６】図１Ａ−１Ｄを参照すると、リレーショナルデータベースのテーブル、製品、
売上、時間、および成果のテーブルが、属性の列と、これらの属性に関するデー
タの行を含む。例えば、図１Ａの製品のテーブルは、製品ＩＤ、製品種類、およ
びバーコードを含む。特定の操作が、これらのテーブルに実行できる。そのよう
な操作のひとつは選択（selsction）であり、テーブル中の特定の行を識別する。選択は、普通には、述語が真である行を識別するよう、テーブルをフィルタす
るの使用されるひとつ以上の述語を指定することによってなされる。述語は、普
通には、ＳＱＬクエリーのWHERE文に見出せる。例えば、選択操作は、製品ＩＤの１の選択を要求でき、それは、製品のテーブルの第１行を選択することになろ
う。リレーショナルデータベースモデルでの別の操作は、結合 (join) と呼ばれ
る。結合操作は、２つのテーブルからのデータを組合せる方式であり、それは、
普通には、これらのテーブルでのデータ間の関係に基づく。製品のテーブルは、
製品種類を製品ＩＤによって識別し、売上テーブルは、各製品ＩＤ／時間（時間
キー）組合せに関連するドルの総額を識別する。製品テーブルと売上テーブルと
は、製品ＩＤの列により結合できる。売上テーブルは、各行で時間キーにも関連
し、時間テーブルは、各時間キーで日に関係する。その故に、売上テーブルと時
間テーブルとは、時間キーの値により結合できる。

【０００７】図２は、ファクトテーブルとその次元テーブルとの間の関係を示す。ファクト
テーブルと次元テーブルとは、詳細テーブルのサブセットである。ファクトテー
ブルは、イベント（例えば、売上イベント）を記録する詳細テーブルである。売
上イベント（例えば、時間、店、および製品）に関係する情報が格納されるテー
ブルは、関連するファクトテーブルの次元テーブルである。例えば、時間テーブ
ル、店テーブル、および製品テーブルは、売上テーブルに関連する次元テーブル
である。クラスのアウトボード (Class outboard)（次元の次元）テーブルは、個別のテーブルで繰返される情報（製品とクラスとの間の関係）による冗長性を
削除する。この特徴は、正規化と称される。

【０００８】リレーショナルデータベースモデルにおける別の概念は、関数的従属性である
。関数的従属性は、データベースのテーブルにおける値の列間の多数からひとつ
への関係である。列ｘから列ｙへの関数的従属性は、２つの行がｘ列に対して同
じ値を有する場合、その２つの行がｙ列に対しても同じ値を有する必要がある制
約条件である。関数的従属性は、データベース管理者等のユーザによって明示し
て宣言されることができる。

【０００９】更に、リレーショナルデータベースモデルは、集合のクエリーを提供し、それ
は、普通には、SUM または COUNT、およびオプションで GROUP BY 文のような集
合関数を使用して、データベースのテーブルにおける行の集計 (summarization)
つまり併合を要求するクエリーである。集合体テーブルは、普通には、他のデータベースのテーブルから詳細レベルのレコードを集計つまり併合するテーブル
である。

【００１０】ＳＱＬは、ユーザが仮想テーブル（「ビュー」）を定義し、その定義をデータ
ベースにメタデータとして保存することを可能にする。ビューは、通例、それが
必要とされる（例えば、ＳＱＬステートメントがビューを参照する際）まで、物
理的に具現化（すなわち「予め演算」）されない。ビューについてのメタデータ
は、ビューの名称、各列の名前とデータ種類、およびビューが作成するデータを
記述するＳＱＬテキスト等の情報を含むことができる。ビューについてのメタデ
ータは、普通には、データベースのメタデータに格納されるが、ユーザがビュー
で見るであろう実際のデータは、普通には、物理的には格納されない。むしろ、
データは、普通には、ビューの行が抽出される詳細テーブルに格納される。予め
演算されたビューの場合、データは、普通には、関連する予め演算されたテーブ
ルに格納される。一般に、操作は、詳細テーブルに対して実行できる場合と全く
同様に、ビューに対して実行できる。

【００１１】ユーザは、何単位のシリアルＸが１９９９年１月１日に売られたか等のような
情報を要求できる。そのクエリーの結果は、製品テーブル（図１Ａ）、売上テー
ブル（図１Ｂ）、および時間テーブル（図１Ｃ）から抽出できる。しかし、種々
のテーブルから各質問への返答を抽出することは非常に非効率であり、多くの時
間がかかってしまう。効率を高めるために、データベース管理者は、もっともよ
く尋ねられそうな質問を予測し、これらの質問が実際に尋ねられる前に、これら
のありそうな質問への返答を含むテーブルを予め演算できる。例えば、店のデー
タベース管理者は、頻繁に尋ねられる質問が、所定製品の売上の１日の期間での
総額（合計＿ドル）であると判定できる。従って、データベース管理者は、予め
演算されたテーブル（図１Ｄ）とそのテーブルに関連する予め演算されたビュー
を創成できる。

【００１２】データベース管理者は、普通、尋ねられそうな全ての共通する質問を予知する
ことは期待されず、全てのクエリーが分かったとした場合でさえ、全ての結果を
予め演算する／具現化することは実行できそうにない。クエリーが出され、返答
が予め演算されたテーブルから直ちに利用可能でない場合、そのようなクエリー
に対する返答は、普通には、ひとつ以上の詳細テーブルから抽出され、プロセス
は、非常に多くの時間を要し、多大の演算を要するかもしれない。

【００１３】

【課題を解決するための手段】

本発明は、データベースについてのユーザークエリーに返答するために予め演
算されたビューを処理するための方法と装置を特徴とする。

【００１４】一つの局面によると、予演算のストラトジの有効性についてのユーザーデータ
ベースクエリーは、ユーザーデータベースクエリー履歴に基づき、データベース
に対する全ての可能なビューから成るひとつのサブセットから構成される分析ス
ペースを定義することによって、および、分析スペースにおけるビューを特徴付
けることによって、応答される。

【００１５】別の局面によると、構造は、クエリー書換えファシリティの能力に基づき、デ
ータベースに対する全ての可能なビューから成るひとつのサブセットから構成さ
れる分析スペースに賦課され、分析スペースにおけるビューが特徴付けられる。

【００１６】第３の局面によると、データベースに対する全ての可能なビューから成るひと
つのサブセットから構成される分析スペースが定義され、コスト公式が、データ
ベースに含まれたデータから成るひとつのユーザ定義サブセットに基づき、分析
スペースへ適用される。

【００１７】第４の局面によると、２つ以上の成分ビューの組合せから構成される候補ビュ
ーを含む分析スペースが定義され、分析スペースにおけるビューが特徴付けられ
る。

【００１８】第５の局面によると、データベースについてのユーザークエリーが分析され、
ユーザークエリーに基づき候補ビューが生成される。

【００１９】第６の局面によると、本発明は、サーバ上に格納されたデータベースについて
のユーザークエリーに返答するためのシステムを特徴とし、サーバ内へ統合され
、ユーザークエリーに応答するよう構成された、クエリー処理システムと、サー
バ内へ統合され、データベースについてのユーザークエリーの予め演算された結
果を処理するよう構成された、クエリー処理システムとを備える。

【００２０】別の局面では、本発明は、サーバ上に格納されたデータベースについてのユー
ザークエリーに返答するための方法を特徴とし、サーバで受取られたユーザーク
エリーへ応答する工程と、サーバで、データベースについてのユーザークエリー
の予め演算された結果を処理する工程とを含む。

【００２１】本発明の利点には、以下がある。

【００２２】本発明は、システムの独特な性能とスペース要件を満足させるよう予め演算さ
れた集合体の最適セットを創成し評価することによりデータベース管理者を支援
する。本発明は、ユーザークエリー履歴に基づき、予演算のストラトジの有効性
の分析を提供する。本発明は、詳細データのユーザ定義サブセットについての分
析を実行でき、分析時間を低減する。本発明は、サブスペースでひとつ以上の候
補ビューを包摂するビューを考慮するよう分析で使用される候補ビューのスペー
スを細分できる。本発明は、スペース内の他のビューに対して、予め演算された
ビューまたは候補ビューのコスト利益分析が判定できるようにする分析スペース
についてのストラクチャを定義できる。

【００２３】エンドユーザおよびアプリケーションは、それらが常に有するように、データ
ベースへクエリーし続けることができ、クエリー書換えファシリティは、既存集
合体を利用するようクエリーを変換する。本発明は、クエリーが提出される方式
に影響せず、データベース管理者がデータベースの集合体性能をチューニングす
ることを可能にする。加えて、全ての集合体関連メタデータは、次元内の階層関
係を含む、データベースシステムのカタログ内へ統合される。

【００２４】本発明は、アドバイジングファシリティが、現在は存在しないが、予め演算で
きて、書換えファシリティによってユーザークエリーを書換えるよう使用される
、ビューについてのアドバイスを提供することを可能にし、それによって、クエ
リー処理性能を改善する。本発明は、アドバイザリファシリティが、ユーザーク
エリー履歴に基づき、全ての可能な予め演算されたビューのサブセットだけを分
析することを可能にする。候補ビューは、ＳＱＬで生成でき、ＳＱＬが関連する
予め演算されたビューを創成するために直接使用できるようにする。候補ビュー
は、候補ビューが生成されるクエリーを書換えることにも書換えファシリティに
よって使用可能であってもよい（ビューが予め演算されている場合）。

【００２５】集合情報は、データベースに対する全ての他のメタデータと共に、システムの
テーブルに格納され、全てのデータベース活動の知識を集中化させる。この統合
の結果は、予め演算されたビューが使用されるか否かに拘らず、クエリーの編集
(compilation) と最適化のために拡張 (enhanced) メタデータを使用する一貫性と能力である。例えば、集合体テーブルデータが詳細データと同期していない
場合、システムは、即座にそれについて知り、（そうするよう要求されない限り
）クエリーを書換えるのにテーブルを使用しない。加えて、最適化ストラトジは
、最大限の統合の結果としてクエリー処理システムに既知である。サーバの統合
は、予め演算されたテーブルが自動的に維持されることを可能にする。この特徴
は、ユーザがＳＱＬインタフェースを使用してアドバイザリとメタデータ情報と
へアクセスすることも可能にする。この特徴は、アドバイザリファシリティがサ
ーバに配置されたクエリー処理能力を使用することも可能にし、フロントエンド
ツールが予め演算されたビューの処理システムの能力を使用できるよう可能にす
る。本発明の局面によると、予め演算されたデータは、予め演算された結果と詳
細データとの間の関係（例えば、外部キーの関係）の定義を可能にするテーブル
に格納される。サーバ統合は、クエリー処理システムがデータベースサーバによ
って提供される論理的および物理的データベース設計オプションへアクセスする
ことも可能にする。

【００２６】他の特徴と利点は、図面と特許請求の範囲を含む、以下の説明から明白になる
であろう。

【００２７】

【発明の実施の形態】I. 概観Ａ．予め演算されたビューを管理するシステムと方法の一般的特徴図３を参照すると、ひとつの実施の形態で、クライアント１０は、データスト
ア１６（例えば、California 州 Menlo Park の Informix Software, Inc. から
入手可能な Red Brick Warehouse のようなデータウエアハウス）に含まれたデータにアクセスするためにクエリーをデータベースサーバ１２へネットワーク１
４上で送ることができる。データベースサーバ１２は、クエリー処理システム１
８を含み、それは、他方、予め演算されたビューの処理システム２０を含む。ク
エリー処理システム１８は、クエリーをクライアント１０からネットワーク１４
上で受取り、予め演算されたビューの処理システム２０の支援により、要求され
た情報に対応するデータをデータストア１６からクライアント１０へ返送するこ
とによって、受取ったクエリーを執行する。予め演算されたビューの処理システ
ム２０は、意志判定支援クエリーに対する予め演算された集合体データへの組織
的なアプローチを提供する。各クエリーが執行される前に、予め演算されたビュ
ーの処理システム２０は、コスト基準の分析を実行し、クエリー性能を改善する
ためにクエリーが捕捉され (intercept) 書換えられるべきか否か判定する。加えて、予め演算されたビューの処理システム２０は、クエリー執行についての統
計をログし、データベース管理者が既存の集合ストラテジがどれだけ効率的に働
いているか判定し、現行集合ストラテジを改善する方法を判定する。

【００２８】意志判定支援環境では、データの標準モデルは、次元スペースで点に関連する
ファクトのそれである。小売環境では、例えば、各売上は特定の時間に、特定の
店で、および、特定の製品に発生する。この例では、各売上イベントは、ファク
トであり、３次元のスペース（製品、店、時間）での点で発生する。各次元は、
通例、階層を形成し：製品は、例えば、細かさの最細レベルで製品種類と、最粗
レベルで製品カテゴリとを持つ２レベル階層であってよい。多次元データモデル
は、次元における点（例えば、製品の種類）とこれらの点の属性（例えば、製品
の色）との間を区別する。集合体は、普通には、次元スペースで点につき、可能
な限り次元的属性に置かれた制約を持ち、演算される。

【００２９】リレーショナルデータベースでの集合体処理は、普通には、次元的制約に基づ
き認定するファクトの記録を取出すこと、規定された次元で点に対する値によっ
て記録をグループ化すること、および、各グループへ集合体関数を適用すること
を包含する。高度に能率的なクエリー処理システムでさえ、何十億ものファクト
と関連する次元記録を必要とする集合体クエリーは、演算することに非常に高く
つくことが多い。予めの演算は、集合体処理で劇的な性能増加 (gain) の結果と
なることが多く、細かさのひとつのレベルでの集合体結果は、より粗い細かさで
の集合体を演算（ロールアップ）することに使用できることが多い。これは、全
ての可能な集合体を予め演算する必要性をなくす。

【００３０】以下に詳細に説明するように、予め演算されたビューの処理システム２０は、
クエリー書換えシステム（書換え器）、クエリーのログと分析のファシリティ（
アドバイザ）、および、拡張メタデータファシリティ（メタデータ層）を含む。
書換え器は、集合体テーブルを使用してユーザのデータベースクエリーを書換え
ることを捕捉し試み；書換え器は、クライアントアプリケーションとエンドユー
ザに透過的 (transparently) にクエリーを書換える。アドバイザは、既存の集合体テーブルのサイズと相対的な利益、および創成することに有用であろう可能
性（候補）の集合体テーブルについてのアドバイスをクエリーしてもよい。メタ
データ層は、データベースオブジェクトとその関係についての情報を格納する。

【００３１】Ｂ．データベースオブジェクト図４は、ビュー３０、データベーステーブル３２、および階層３４の間の関係
を示す。一般的に、ビュー３０は、クライアントクエリーをデータストア１６上
で定義する。予め演算されたビュー３６は、クエリーを定義し、予め演算された
テーブル３８へリンクされ、テーブルは、クエリーの予め演算された結果を含む
データベースのテーブルである。換言すると、予め演算されたビューで定義され
たクエリーは、クエリーがクエリー処理システム１８によって受取られる前に演
算される。対照的に、アドバイザによって生成された候補ビュー４２を含む、正
規ビュー４０によって定義されたクエリーに対する結果は、正規ビューが参照さ
れる度毎に演算されねばならない。操作では、予め演算されたビュー３６で定義
されたクエリーは自動的に予め計算でき、そうでなければ、データベース管理者
は、関連する予め演算されたテーブル３８を在住させねばならない。データベー
ス管理者は、例えば、テーブル管理ユーティリティ (TMU) LOAD DATA 操作、または、ＳＱＬの "INSERT INTO … SELECT" ステートメントを使用して、テーブルを在住させてもよい。管理者は、次に、予め演算されたテーブル３８の内容を
反映するクエリーテーブル現を含む、関連する予め演算されたビュー３６を創成
できる。定義後に、クエリー処理システム１８は、詳細テーブル４６での変更を
反映するよう予め演算されたテーブル３８を自動的に更新でき、予め演算された
ビュー（とその関連する予め演算されたテーブルと）を使用するようユーザーク
エリーも書換えできる。

【００３２】集合体テーブル４４は、関連する予め演算された集合体ビュー４５で定義され
た「集合体クエリー」の結果を格納する予め演算されたテーブルであり、それは
、集合体テーブルと下にある詳細テーブル４６のセットとの間の集合体関係を定
義する。予め演算されたビューの定義は、詳細テーブル４６と予め演算された結
果を含む集合体テーブル４４との間の意味のリンクを確立する。一般的に、集合
体テーブル４４は、詳細テーブル４６に含まされた情報より粗い細かさ（すなわ
ち、より少ない行）を有する情報を含む。例えば、小売データベースでは、取引
レベルのデータは、売上領収書詳細テーブルに格納された個別の売上領収書の形
態であるかもしれない。売上領収書のテーブルでの記録は、一定の時間期間にわ
たり集合でき、集合体テーブルのセット（例えば、日次売上テーブルおよび月次
売上テーブル）を作出する。

【００３３】集合体クエリーは、普通には、詳細テーブル４６に含まれたファクトのデータ
を集合するために（例えば、所定の時間期間にわたる売上合計） SUM または CO
UNT のような標準のＳＱＬ関数を使用する。他の集合クエリーは、大きな次元テ
ーブル（例えば、四半期と年、または市区と地域の別個の組合せ）から次元デー
タの別個の行を選択するために GROUP BY 文を使用する。これらの方式では、集
合クエリーは、細かい細かさのデータの行を粗い細かさの行のグループ内へ「ロ
ールアップ」する。クエリー書換えシステムによって提供される性能増加は、こ
れらのロールアップの予めの演算から抽出される。追加の性能増加は、ビューの
列をグループ化することより粗い細かさの列を含む、追加のロールアップを必要
とするクエリーを書換えるクエリー書換えシステムの能力によって達成される。
換言すれば、クエリー書換えシステムは、ビューで定義されたクエリーと一致し
ない大多数のクエリーを書換えることに使用できる。例えば、ビューは、月の列
によってグループ化された行を答申するクエリーを定義するかもしれないが、そ
れでも、このビューは、四半期と年の列によってグループ化されたクエリーを書
換えることに使用できる、これは、これらの列のいずれもがビューによって定義
されたクエリーで命名されていない事実に関らずである。このロールアップ能力
は、それぞれ、月、四半期、および年によってグループ化された３つの個別のビ
ュー、または全ての３つの列によってグループ化されたひとつの非常に広いビュ
ーを創成しなくてはならないことからデータベース管理者を解放する。

【００３４】ウエアハウスデータに固有である階層３４（すなわち、関数的従属性）は、予
め演算されたビューで定義されない列へのロールアップを可能にする。階層は、
値の列によって共有される多数からひとつへの関係である。換言すれば、列Ｘか
ら列Ｙへの階層は、２つの行がＸ列に対して同じ値を有する場合、Ｙ列に対して
同じ値を有するその２つの行を必要とする制約である。列は、同じテーブルまた
は異なるテーブルにあってもよい。例えば、店のテーブルで店番号の列と都市の列との間に階層が存在する場合、店番号の列での値が Store_56 である場合は
必ず、都市の列での値は、Los Angeles である。都市には多くの店があり得るが
、所定の店はひとつの都市にだけあり得るので、この関係は、多数対１である。
同様に、店のテーブルでの都市の列は、市場のテーブルでの地域の列と多数対１
の関係を持ち得る（例えば、都市が Los Angeles である場合、地域は常に West
（西部）である）。

【００３５】階層は、細かい細かさの列によってグループ化される予め演算されたビュー３
６が粗い細かさの列によってグループ化されるクエリーを書換えることに使用さ
れることを可能にする。例えば、店番号から都市への階層の存在は、店番号の値
が別個の都市の値へグループ化されることを可能にする。予め演算されたビュー
３６が、店番号によってグループ化される場合、同じビューがこれらの列のひと
つまたは両方について制約するクエリーを書換えることに使用できるので、都市
によってグループ化される別のビューを創成する必要はない。クエリー書換えシ
ステムは、予め演算されたビューの定義の範囲を越えるロールアップを必要とす
るクエリーを書換えるよう、階層３４をインテリジェントに使用する。

【００３６】２種類の階層には、クエリー処理システムにとり黙示的に既知であるもの、お
よび、データベース管理者によって明示的に宣言されねばならないものがある。

【００３７】主キー／外部キーの関係経路、または、ヌルにできない無二の列の定義からの
結果に従う階層は、クエリー処理システムにとり黙示的に既知である。結果とし
て、例えば、Perkey が、例えば、Period（期間）のテーブルを参照する外部キーの列である場合、例えば、Sales.Perkey の列によってグループ化されるビューは、期間のテーブルにおける列のいずれの組合せによってグループ化されるク
エリーを書換えることに自動的に使用され得る。この特徴は、アウトボードテー
ブル（すなわち、次元テーブルによって参照されるテーブル）における列によっ
てグループ化されるクエリーにも適用する。例えば、Storekey が Store（店）のテーブルを参照する外部キーの列であり、Store.Mktkey が Market（市場）の
テーブルを参照する外部キーの列である場合、Sales.Storekey の列によってグループ化されるビューは、店および市場のテーブルにおける列のいずれの組合せ
によってグループ化されるクエリーを書換えることに自動的に使用され得る。

【００３８】他の階層は、明示的に宣言されねばならない。例えば、ビューが期間のテーブ
ルでの月の列によってグループ化され、月から四半期へおよび四半期から年へ従
属性が存在する場合、両従属性が宣言される必要がある。それらが宣言された後
に、クエリー書換えシステムは、同じ予め演算されたビューを３つの列のいずれ
の組合せによってグループ化されるクエリーを書換えることに使用できる。これ
らの依存性を宣言することは、アドバイザの性能も改善する。階層を宣言するメ
カニズムは、CREATE HIERARCHY コマンドである。CREATE HIERARCHY ステートメ
ントは、関数的従属性を満足し、列が所属するテーブルを識別する一対の列を命
名する。

【００３９】図５Ａと５Ｂとを参照すると、ひとつの実施の形態で、小売のデータベースス
キーマは、売上詳細テーブル５０、期間次元テーブル５２、店次元テーブル５４
、製品次元テーブル５６、販売促進次元テーブル５８、市場次元テーブル６０、
クラス次元テーブル６２を含む。市場テーブルとクラステーブル６０、６２は、
アウトボードテーブルである。売上テーブルでのドルの列は、日別、店別、製品
別、販売促進別の合計を示す。例えば、詳細テーブルでの単一行は、１９９９年
１月２日、San Jose Roasting Company が、＄９５の全粒豆の Aroma Roma コー
ヒーをカタログクーポンを使用する顧客に売ったことを記録できる。ユーザが、
ある時間期間別、ある店別または地理的領域別（例えば、日別、地域別、または
、月別、州別）の売上合計を要求するクエリーを定例的に提出する場合、データ
ベース管理者は、日別、店別の全ての製品と全ての販売促進に対する売上合計を
含めて、店売上テーブル６４を定義するかもしれない。この集合体テーブルは、
詳細売上テーブルと同じ関係を店次元テーブル５４、期間次元テーブル５２とへ
保持するであろうが、しかし、小売のスキーマでの他の次元を参照しないであろ
う。

【００４０】図６を参照すると、特定の四半期中の特定の製品に対する売上合計を比較する
レポートを求める小売売上アナリストのクエリーに関する実施の形態で、データ
ベース管理者は、予め演算されたビューを以下のように創成できる。特定の四半
期中の特定の製品に対する売上合計を比較するレポートを求める反復されたアナ
リストのクエリーを予知して、データベース管理者は、CREATE TABLE ステートメント７０を使用して製品売上の集合体テーブルを創成する（工程７２）。デー
タベース管理者は、INSERT ステートメント７４を使用して製品売上テーブルを在住させる（工程７６）。データベース管理者は、次に、CREATE VIEW ステート
メント７８を使用して、製品売上集合体テーブルに関連する予め演算されたビュ
ーを創成する（工程８０）。クエリー書換えシステムは、次に、以下のように、
ユーザークエリーを捕捉できる： select prod_name, qtr, sum(dollars) as total_sales from sales, product, period where sales.prodkey = product.prodkey and sales.classkey = product.classkey and sales.perkey = period.perkey group by prod_name, qtr; クエリー書換えシステムは、これらのクエリーを製品売上の集合体テーブルの走
査で置換えできる。クエリー書換えシステムは、テーブル名称を割当て、結合属
性を書換え、およびクエリー性能を著しく改善する方式でクエリーをテーブルす
。

【００４１】本発明は、データベース管理者とユーザの両方へ追加の予め演算された機能性
を提供する。詳細には、本発明は、データベース管理者がどの予め演算されたビ
ューを創成し維持するかを判定するためのインテリジェントな方法を提供する。
大規模なデータウエアハウスにおいて全ての次元での全ての点の組合せに対して
集合体を予め演算し維持することは非実用的であるので、この特徴は特に有用で
ある。

【００４２】II. 機能的構成要素Ａ．メタデータ層１．概観メタデータ層（以下に詳細に説明する）は、集合体テーブルの定義を格納し、
他のシステム構成要素（例えば、書換え器、アドバイザ、およびデータベースサ
ーバ１２）がこれらの定義にアクセスすることを可能にする。メタデータ層は、
予め演算されたビューと次元的階層とについての情報を格納し、各予め演算され
たテーブルの状態をそれが演算された源の詳細テーブルに関して追跡する。次元
的階層は、次元での点についての集合体から同じ次元における粗い細かさの他の
点へのロールアップのような、多次元のデータベース機能性を本発明が与えるこ
とを可能にする。

【００４３】２．予め演算されたテーブルと予め演算されたビューメタデータ層の特徴の中には、以下の予め演算されたテーブルと予め演算され
たビューを支援する特徴がある。メタデータ層は、データベース管理者によって
アクセス可能である、予め演算されたテーブルの定義と関係とについての情報を
維持する。メタデータ層は、予め演算されたテーブルがＳＱＬにより定義される
ことも可能にする。メタデータ層は、各予め演算されたテーブルがその関連する
詳細テーブルと同期にあるか否か（すなわち、予め演算されたテーブルが予め演
算されたビューの定義を正確に反映するか否か）を追跡する。この特徴は、シス
テムが、予め演算されたテーブル内への挿入と、関連する詳細テーブルとさもな
ければ予め演算されたテーブルを無効にするであろう操作とに併せての更新とを
取扱えるようにする。メタデータ層は、予め演算されたテーブルの列と関連する
詳細テーブルの列との間のマッピングを識別する。メタデータ層は、グループ化
の列と集合体テーブルに対する集合列とを識別する。メタデータ層は、各集合の
列に対する集合体テーブル現（例えば、min(dollars) および sum(units)）を識
別する。メタデータ層は、予め演算されたテーブルがそこにインデックスを作ら
せ、外部キー／主キーの制約条件をそれに対して定義させることを可能にする。
これらの特徴は、予め演算されたテーブルがデータベーススキーマ内へ接続され
、スター印や他の指標をそこに作らせることを可能にし、クエリー処理速度を改
善する。メタデータ層は、予め演算されたテーブル間の関係を識別でき、書換え
器が別の予め演算されたテーブルからひとつの予め演算されたテーブルを演算で
きるようにする。メタデータ層は、任意の次元的階層、ファクト集合体テーブル
（ファクトテーブルからファクトを集合するテーブル）、および次元的に予め演
算されたテーブル（グループ化の列だけを含むテーブル）が定義されることを可
能にする。

【００４４】３．階層上記で説明したように、次元的階層は、CREATE HIERARCHY ステートメントを使用して規定される。例えば、次の階層定義を考える： create hierarchy type-to-category (from product(type) to product(category)); このＳＱＬコマンドは、種類とカテゴリの列が製品次元での点であり、種類の列
につきグループ化された（Sum(dollars) のような）集合体がカテゴリの列についての（互換性のある）集合体へロールアップすることに使用できる、ファクト
をテーブルすメタデータを創成する。CREATE HIERARCHY ステートメントをインタプリートする別の方式は、２つの列間の関数的従属性の宣言としてである。

【００４５】正規化を解いた (denormalized) 次元テーブルが（性能の理由で）既存の場合
、CREATE HIERARCHY ステートメントは単一のテーブルからの列を参照する。階層は、異なるテーブルの列間でも規定できる。本例のスキーマが正規化次元テー
ブルを有すると仮定する。製品次元は、次のような２つのテーブルに表すことが
できる。

【００４６】 product (prodkey, pname, type, category-key) class (category-key, category, category-desc) この場合、種類とカテゴリとの間の階層は、次のように定義されよう： create hierarchy type-to-category (from product(type) to class(category)); これらの列は異なるテーブルにあるので、結合がこのロールアップを実行するこ
とに必要とされ、従って、メタデータ層は、外部キー−主キーの結合制約が製品
のテーブルとクラスのテーブルとの間に存在する必要がある。これらの結合制約
は、書換え器が第２クラスのロールアップを実行できるようにする。

【００４７】メタデータ層は、主キーの列と同じテーブルの別の列との間の階層のような、
黙示の階層（関数的従属性）も、移行性によって暗示される従属性と同様に暗示
する。明示と黙示の階層は、書換え器が小さいセットの予め演算された集合体を使用して大きなクラスのクエリーに返答することを可能にする。

【００４８】Ｂ．書換え器 (Rewriter) データベース管理者は、予め演算されたテーブルを創成し、予め演算されたテ
ーブルをローディングし（または、既存の予め演算されたテーブルを使用し）、
および予め演算されたテーブルの厳密な内容を反映するクエリーテーブル現と関
連する予め演算されたビューを定義する。データベース管理者は、予め演算され
たどのビューが存在するかを必然的に知るが、しかし、データベースのユーザは
、この情報を知る必要はない。クエリーがユーザによって提出される場合、クエ
リー書換えシステムは、データベース管理者によって創成された予め演算された
ビューを評価し、可能な場合、元のユーザークエリーに参照されたテーブルより
、普通には、ずっと小さい集合体テーブルに含まれた情報を選択するようクエリ
ーを書換える。可能な場合、結合は単純化または排除され、詳細データと集合体
データとの間に発生する合同の程度に依存して、クエリー応答時間は、非常に加
速される。その上、以下に説明するように、クエリーとビューの定義が厳密に一
致しない場合でさえ、クエリーは、予め演算されたビューに対して書換えられ得
る。

【００４９】予め演算されたビューが落とされるか、または追加される場合に、ユーザがマ
ニュアルでクエリーを書換えるか、またはそのクエリーを変更する必要もなく、
書換え器は、比較的小さなセットの予め演算されたビューの観点でユーザークエ
リーを書換える。書換え器は、予め演算された集合体を使用するよう、集合体ク
エリーを捕捉し、各クエリーを書換えることを試みる。この書換えは、ブロック
毎の基準でなされ、union/ intersect/ except（併合／交差／除外）クエリーで
のブロックと同様に、相関するサブクエリーを含む。書換え器は、可能な書換え
中から選択するためにコスト基準のアルゴリズムを使用する。書換え器は、両種
類のロールアップを実行できる。書換え器は同次元で細かい細かさの集合体から
粗い細かさの集合体へ能率的にロールアップできるので、予め演算された集合体
の全数は低減できる。集合体が次元での点に対応するキーでない (non-key) およびキーの列の両方につきグループ化される場合、これらのロールアップが実行
できる。書換えは透過的に実行され、それによって、ユーザを集合体処理の詳細
から隔離する。従って、集合体がデータベースから落とされるか、またはデータ
ベースに追加される場合に、ユーザークエリーが変更される必要はない。

【００５０】Ｃ．アドバイザアドバイザは、どのテーブルを予め演算するかを提案し、クエリー履歴の分析
に基づき既存の予め演算されたテーブルの有効性を判定する。アドバイザは、デ
ータストア１６に対するユーザークエリーの活動をログするファシリティも提供
する。ログされたクエリーから、データベース管理者は、データストア１６にお
ける既存の予め演算されたテーブルの使用を分析でき、クエリー性能を改善でき
る新規ビュー（候補ビュー）の創成の可能性を識別できる。

【００５１】データストア１６が問合せられる際に、アドバイザは、書換え器によって書換
えられたクエリーと、適切な集合体テーブルが存在したとすれば書換えから利益
を得るであろうクエリーと、をログする。時間期間の後に、データベース管理者
は、アドバイザによって創成されたクエリー統計レポート（テーブル）によって
集合体クエリーログを分析できる。ひとつのレポート（RBW_PRECOMPVIEW_UTILIZ
ATION のテーブル)が、データベースにおける既存の予め演算されたビューの使用についての情報を提供する。別のレポート（RBW_PRECOMPVIEW_CANDIDATES のテーブル）が、ユーザークエリー履歴と既存の予め演算されたビューとに基づき
アドバイザが提案する最適のセットの予め演算されたビューについて情報を提供
する。

【００５２】アドバイザシステムテーブルは、ログに格納された情報の詳細な分析から生成
される。分析は、データストア１６に対する実際のクエリー履歴により最適セッ
トの集合体テーブルを判定するアルゴリズムに基づく。分析の一部として、利益
が、各既存ビューと各候補ビューとへ割付けられる。アドバイザシステムテーブ
ルでの BENEFIT （利益）の列は、関連する詳細テーブルまたは次善のビューよりむしろ予め演算されたビューによりクエリーを処理することによって節約され
る行の数；と同様に、（既存ビューに対して）ビューが使用された回数、または
（候補ビューに対して）ビューが使用されたであろう回数、を反映するコスト尺
度である。

【００５３】アドバイザのログするメカニズムは、提出された各ユーザの集合体クエリーを
検査する。予め演算されたテーブルが存在しない場合、ログするメカニズムは、
どの候補の予め演算されたテーブルが在る場合、クエリーに返答することに有用
であろうかを記録するであろう。生成された候補は、普通には、クエリーと厳密
な一致ではないが、むしろユーザークエリーと同じ次元（または、これらの次元
のどれかのサブセット）を包含する広範囲のユーザークエリーに（ロールアップ
により）、能率的に返答することに使用され得るものである。このように、アド
バイザは、格納される必要のある予め演算されたテーブルの数を低減する。換言
すれば、実際のクエリー履歴に基づき、アドバイザは、全ての可能な予め演算さ
れたテーブル（例えば、次元と次元に沿う点の全ての組合せにつきグループ化さ
れた予め演算されたテーブル）のサブセットのインテリジェントな具現化（予め
演算）を可能にする。

【００５４】予め演算されたテーブルが存在し、書換え器が存在する予め演算されたテーブ
ルを使用するようクエリーを変換する場合、アドバイザのログするメカニズムは
、予め演算されたテーブルの使用度についての情報を記録する。アドバイザが予
め演算に対する候補として更に能率的な（存在しない）予め演算されたテーブル
を提案できる場合、この候補もログされるであろう。

【００５５】アドバイザは、アドバイザをデータベースサーバと統合させることによって可
能になされたリレーショナルＳＱＬ基準のインタフェースを特徴とする。データ
ベース管理者はＳＱＬコマンドを使用して、アドバイザ特定のテーブルにアクセ
スし、既存の予め演算されたテーブルの利用についての情報と、創成されるべき
候補の予め演算されたテーブルについての情報とを取得する。アドバイザは、分
析されなくてはならない予め演算されたテーブルのセットを、全ての可能な予め
演算されたテーブルの小さなサブセットに、限定するためのメカニズムも特徴と
する。加えて、既存の、可能性のある候補の予め演算されたテーブルを分析する
間に、アドバイザは、ログされた参照カウントとひとつの予め演算されたテーブ
ルの別のものによっての（書換え器を使用しての）書換え性とを使用する。

【００５６】Ｄ．サーバの統合本発明は、ひとつの意味で、データベースサーバへ最大限に統合される予め演
算されたビューを支援し、性能最適化の範囲とメタデータをサーバと共有する能
力とを増大させる。クエリーは、捕捉され、ソフトウエアの個別の断片によって
でなく、データベースサーバ１２によって書換えられる。

【００５７】最大限の統合の利点の中には、以下がある。集合情報は、データベースに対す
る全ての他のメタデータと共にシステムのテーブルに格納され、全てのデータベ
ース活動の知識を集中化する。この統合の結果は、予め演算されたビューが使用
されるか否かに拘らず、クエリーの編集と最適化のために拡張メタデータを使用
する一貫性と能力である。例えば、集合体テーブルデータが詳細データと同期し
ていない場合、システムは、即座にそれについて知り、（そうするよう要求され
ない限り）クエリーを書換えることにテーブルを使用しない。加えて、最適化ス
トラテジは、最大限の統合の結果としてクエリー処理システム１８は知られてい
る。

【００５８】III. 詳細な操作Ａ．概観図７Ａと７Ｂを参照すると、ひとつの実施の形態で、データベース管理者は、
以下のように、クエリー処理システム１８によって使用される集合戦略を絶えず
改善できる。操作では、ユーザは、クエリーをデータベースサーバ１２へネット
ワーク１４上で送る（工程９０）。当初、データベース管理者は、ひとつ以上の
予め演算されたテーブルを創成したかもしれず、してないかもしれない。予め演
算されたテーブルが創成されなかった場合、書換え器は、クエリーを書換えでき
ない；その代わり、クエリー処理システム１８は、クエリーを執行するよう、デ
ータストア１６の詳細テーブル４６へ直接アクセスする。ひとつ以上の予め演算
されたテーブルが創成されている場合、書換え器は、予め演算されたテーブルを
使用してクエリーを書換えることを試みる（工程９２）。アドバイザは、書換え
器によって書換えられたクエリーに対して（工程９６）、および、適切な予め演
算されたテーブルが存在する場合に、書換えから利益を得るであろうクエリーに
対して（工程９７）レポートを生成し（メタデータ層のログ９４に格納する）。
時間期間後に（戻しのループ９８でテーブルす）、データベース管理者は、アド
バイザによって創生された統計レポート（テーブル）にクエリーることによって
クエリーログを分析するようアドバイザを使用できる（工程１００）。アドバイ
ザシステムテーブルにクエリーすることからの学習情報に基づき、データベース
管理者は、新規の予め演算されたテーブルを追加する（定義し、在住させる）こ
と、または、既存の予め演算されたテーブルを落とすことによって、既存の予め
演算されたテーブルセットを修正する（工程１０２）。データベース管理者は、
新規の予め演算されたテーブルの各々に対する予め演算されたビューも創成する
（工程１０４）。

【００５９】この方法によって、クエリー性能は改善するが、しかし、ユーザは同じセット
の詳細テーブル４６に繰返しクエリーるので、データベーススキーマのユーザの
見解は変わらない。

【００６０】Ｂ．メタデータ層メタデータ層は、２レベルの外部インタフェースを有する、つまり、データベ
ース管理者が集合体テーブルの情報を定義するＲＩＳＱＬ拡張、および、データ
ベースサーバ１２の他の構成要素と通信するためのプログラムのインタフェース
である。メタデータ層は、全てのメタデータ情報を追跡し、そのメタデータ情報
の異なる外部ビューを、システムテーブルによりデータベース管理者へ、コンパ
イラへ、およびローダへ提供する。ひとつの実施の形態で、メタデータ情報は、
データベース管理者によってのみＲＩＳＱＬを使用して創成され、修正されるこ
とができる。

【００６１】１．外部ユーザーインターフェース上記のように、集合テーブルを定義するプロセスは、集合データを格納するた
めに使用されるテーブルの作成と、その後、集合テーブルのデータと詳細テーブ
ルのデータの間の関係を定義する集合ビューの定義とを含む。データベース管理
者は次の表現をもつ集合テーブルの定義を作成できる： CREATE VIEW[view_name]AS[query_expression]USING[ table_name]([ table_column_name]) ここで view_name は具体化されたビューの名前であり、table_nameは集合テーブルの名前であり、またtable_column_nameは集合テーブルの列のリストであり、その集合テーブルは、仮にSELECTステートメントとして表されたとするとクエ
リー表現によって返される列と一対一で順序よく対応する。ひとつの実施の形態
でquery_expressionは次の形に制限される： SELECT[grouping_column, or aggr_column] FROM[table_name_list] WHERE[join_predicate_list] GROUP BY[grouping_column] GROUP BY 列において指定された列はグルーピング列である。SELECT リストに
おけるグルーピング列は GROUP BY 節で指定された列と正確に一致していなけれ
ばならない。集合列は aggr(expr) の形の列であり、ここで aggr() は SUM()、
MIN()、 MAX()、COUNT()、あるいは COUNT(DISTINCT()) のひとつであり、また
expr は、詳細テーブル、数字、またはその両方におけるひとつまたは複数の列から導かれる単純な表現である。この実施の形態で WHERE 節は、FROM 節にリス
トされたテーブルに関連する結合述語のみ含むことができる。結合述語は外部キ
ー／主キー関係を通じてのみテーブルを結合できる。更に、これらの外部キー／
主キー結合述語はクエリー表現において指定された詳細テーブルから外側に向か
ってのみ指定できる。この方法で、詳細テーブルは、それが結合の中心（すなわ
ち、外部キー／主キー関係はその位置から外側を指す）にあるので、あるいは全
ての集合列が導出されるテーブルがあるので識別される。

【００６２】集合テーブルの生成があるので、集合テーブルを落とすのは２段階のプロセス
となる。最初にデータベース管理者は、DROP VIEW 表現を使用する集合テーブル
と関連付けられたビューを落とす。次いでデータベース管理者は DROP TABLE 表
現を使用して集合テーブル自身を落とす。

【００６３】図８を参照して小売り状況で説明すると、売上スキーマ１１０は、多数の列か
らなる主キー１１４（timekey, mktkey, prodkey）と、ドル１１６とトランザク
ション１１８の列を一緒に持つ売上ファクトテーブル１１２を含む。売上ファク
トテーブル１１２は、時間テーブル１２０とマーケットテーブル１２２によって
表される時間次元とマーケット次元を有する。時間テーブル１２０は、日列１２
６、月列１２８、および年列１３０と同様に、主キー１２４（timekey）を有する。時間テーブル１２０は、日数から月数、月数から年数にと、多数対１への写
像があるので、逆正規化される。マーケットテーブル１２２は、地域アウトボー
ドテーブル１３２を含む（すなわち次元の次元）。

【００６４】ある実施例では、集合テーブル sales1_agg は、時間とマーケットの両方によ
る集合によって、次のように作り出される： create table sales1_agg( tkey int not null, mkey int not null, sum_dollars int, primary key (tkey,mkey), foreign key (tkey) reference Market); create view agg1view as select timekey,mktkey,sum(dollars) from sales group by timekey,mktkey using sales1_agg(tkey,mkey,sum_dollars); キー列による集合は、時間あるいはマーケットの次元のいずれによっても単純な
ロールアップが可能である。例えば、地域ごとの全売上げ、あるいは月別、年別
の売上げを要求するクエリーは、sales1_agg aggregate table から計算される。キー列による集合の別の利点は、スター指標が集合テーブルに生成されること
である。例えばスター指標は sales1_agg(tkey,mkey) に生成されることが可能である。これらの次元上で制約されるクエリーは集合テーブル上のスター結合に
よってもたらされる。

【００６５】他の実施例において、集合テーブル sales2_agg は、次のように非キー列によ
る集合によって生成される： create table sales2_agg( day int not null, sum_dollars int, primary key(day)); create view agg2view as select day, sum(dollars) from sales, time where sales.timekey=time.timekey group by day using sales2_agg(day,sum,dollars); sales2_agg 集合次元テーブルは、日毎にグループ化された売上げと時間から、日付と合計(dollar)を選ぶクエリーに答えるために用いられる。すなわちsale
s2_agg は売上げテーブルから時間テーブルへの結合を除去する。しかし月別の全売上げを計算するために、時間テーブルは各々の日の数字についてその月を選
び出すために結合されなければならない。すなわち日はユニーク列ではないので
、特別な別のプロセスが必要となる。

【００６６】非キーロールアップの実行は、次元の集合テーブルを定義することによって改
善できる。上の実施例では列 (day,month,year) と日付の主キーを持つ time_ag
g テーブルがクエリーの性能を改善するであろう。関連付けられたスター指標と
ともに、sales2_agg から time_agg への外部キー／主キー関係が加算される。この場合、クエリーが年毎の全売上げ（クエリーに売上げと時間をネーミングす
る）を訊ねると、sales2_agg と time_agg を使用するためにそのクエリーが書換えられ、そしてクエリーが出されるときにスター結合が使用される。

【００６７】データベース管理者は、非キー列から他の列へロールアップが可能となるロー
ルアップ階層を、次のように定義することができる： CREATE HIERARCHY[hierarchy_name](FROM[f_table(f_col)] TO[t_table(t_col)]ONfkname) この表現は、データベース管理者が、同じテーブルにあるかどうかという、２つ
の列間の多数とひとつの関係を定義できるようにする。階層は、DROP HIERARCHY
表現を用いて落とされる。

【００６８】２．外部APIの仕様 Meta Data Layerは、どの具体化ビューがクエリーに関係するか、そして、ある列が他へロールアップされるかどうか、その場合どのようにしてロールアップ
されるか、を書換え器が判定できるようにすることによって、クエリーの書換えを支援する。

【００６９】ある実施の形態では、どの具体化ビューがクエリーに関係するかを判定するた
めに、クエリー処理システムは Meta Data Layer にクエリーにあるテーブルのリストを送り、その Meta Data Layer は、互換性のある集合テーブルのリスト（解析ツリー、列マッピング、およびそれらが正当なものかどうか、を含む）を
返す。集合テーブルは、もし上でクエリーが定義されている（FROM節で）テーブ
ルが、クエリーでのこれらのテーブルのサブセットである場合、クエリーと互換
性がある。別の実施の形態では、クエリー処理システムは、Meta Data Layerに対して、与えられた詳細テーブルに構築されたすべての集合をリクエストするこ
ともできる。

【００７０】ロールアップ（階層）情報と外部キー／主キー関係の組み合わせは、ある列が
他の列にロールアップされるかどうかを判定するために使用される。

【００７１】 Meta Data Layer は特定のシステムテーブルを管理する。

【００７２】 RBW_VIEWSテーブルは、ビューが具体化されるかどうかについての情報と、具体化ビューについての他の一般情報を追跡する。RBW_VIEWSテーブルは次の列を含む。すなわち、NAME、CREATOR、PRECOMPVIEW、PRECOMPVIEW_TABLE、DETAIL_TA
BLE、VALID、およびCOMMENTである。PRECOMPVIEW列はテーブルが具体化されるか
どうかを示す。PRECOMPVIEWが偽であれば、PRECOMPVIEW_TABLE、DETAIL_TABLE、
VALIDはすべて NULL である。PRECOMPVIEW が真であれば、PRECOMPVIEW_TABLE は、ビューがその中に具体化されるテーブルの名前を示し；DETAIL_TABLE は、その上で集合テーブルが定義される詳細テーブルを示し、そして VALID は具体化ビューにあるデータが詳細テーブルにあるデータと同期しているか否かを示す
。

【００７３】 RBW_PRECOMPVIEWCOLUMNS テーブルは集合テーブルと詳細テーブルにある列の関係を表示する。RBW_PRECOMPVIEWCOLUMNS テーブルは次の列、つまりTABLE_COL
UMN、 VIEW、および VIEW_COLUMN を含む。このテーブルを使用すると、適当なビューとビュー列のマッピングは、その集合テーブル (TABLE_COLUMN) にある列
と集合テーブル名 (TABLE) を与えられて同定されることができる。

【００７４】 RBW_COLUMNS テーブルは列のデータ形式についての情報を与える：RBW_VIEWTE
XT テーブルは列（すなわち列がグルーピング列か、集合列かどうか、および集合列の表現）についての付加情報を与える。

【００７５】 RBW_HIERARCHIES テーブルは列関係をリストしてロールアップ階層を追跡する
。RBW_HIERARCHIES テーブルは次の列：NAME、FROM_TABLE、FROM_COLUMN、TO_TA
BLE、TO_COLUMN、およびCONSTRAINT_NAME を含んでいる。CONSTRAINT_NAME列は、FROM_TABLE 列が TO_TABLE 列と同じならば NULL であろう。

【００７６】３．内部の特徴 Meta Data Layer はシステムカタログにある構造（ブロックタイプ）のファミ
リを格納する。ある構造のファミリは予め演算されたされたテーブル列定義に一
致し、他の構造のファミリはロールアップ階層定義に一致する。階層定義ブロック形式は主キー／外部キー関係構造にゆるやかに基づいている。階層定義とロ
ールアップ階層の両者は固定サイズであり、多数のインスタンスが単一ブロック
に適合している。

【００７７】データベース管理者がビュー定義を加えるかあるいは落とすとき、あるいは階
層定義を加えるかあるいは落とす場合は常に、システムカタログはその変更を反
映して修正される。これらの構造は外部キー／主キー関係を真似ているため、そ
のアクセス方法は類似している。

【００７８】 Meta Data Layer は、データを取出すために書換え器へ少なくとも２つのインターフェースを提供する。一番目のものは与えられた詳細テーブルに関連づけられた、予め演算されたされたテーブルのリストを取出す。二番目のものは
、ロールアップパスが２つの列の間に存在するかどうかを判定する。もし存在す
れば、Meta Data Layer はロールアップパスのリストを生成する。もしFROM_COL
UMNが主キーか、またはゼロでないユニーク列であれば、あるいはFROM_COLUMNか
らTO_COLUMNへ、または機能的従属関係の移行セットを通じて、定義されたロールアップがあれば、ロールアップは可能である。

【００７９】Ｃ．書換え器書換え器の詳細な記載は、引用により本明細書中へ組み込まれた、米国特許出
願第０９/０４９，７８４号,１９９８年３月２７日出願、発明の名称「リレーシ
ョナルデータベースクエリーを書き換えるための方法」で提供される。

【００８０】Ｄ．アドバイザ上記のように、アドバイザは、予め演算されたされたどのテーブルが最大のクエリー性能の改善を与えるか、そしてこれらテーブルが現在も存在するか否か
を判定するに際して、データベース管理者を支援する。アドバイザはクエリーの
どのタイプが書換え器によって書くことができるかを正確に知っているので、アドバイザは、データベースに構築されるべき予め演算されたされたビューの種
類を、直接示唆することができる。アドバイザは、潜在的な予め演算されたビュ
ーと、存在するビューの価格−利益解析とを提供する。アドバイザは、データベ
ースに対する集合クエリーのログをアクティブにする能力も与える。ログファイ
ルはログが可能となるときか、システムがスタートアップするとき、あるいはデ
ータベース管理者によってアクティブになったときに作られる。この情報からデ
ータベース管理者は、データベース中の既存集合の使用を分析でき、また書換え
器とともにそれを生成するための可能性のある新しい集合を評価でき、クエリー
性能を改善できる。

【００８１】図９に示すように、アドバイザはユーザーのデータベースクエリー１４０をク
エリープロセスシステム１８から受け取る。アドバイザは書換え器によって書換えられたクエリーのためにログレコードを作り出し、またもし適当な集合テー
ブルが存在すれば書換えられることから恩恵を蒙るであろうクエリーのためにロ
グレコードを生成する。そして Meta Data Layer のログ９４にこれらのレコードを格納する。アドバイザは、他のメタデータ同様に、階層３４に関する情報のようなログレコードを、ひとつかあるいはそれ以上の候補ビュー４２を生成す
るために利用する。候補ビュー４２と予め演算されたビュー３６についての情報
もログ９４に格納される。

【００８２】アドバイザはまた、アドバイザシステムテーブル(RBW_PRECOMPVIEW_ CANDITATESおよびRBW_PRECOMPVIEW_UTILIZATION)を含む統計要約１４２を作るた
めにメタデータ情報を使用する。データベース管理者はアドバイザシステムテー
ブルにクエリーすることによって、ログ９４に含まれる情報を解析できる。アド
バイザシステムテーブルへのクエリーの結果は、データベース管理者によるクエ
リーを受ける新規のあるいは一時的なテーブルへ挿入されることができる。

【００８３】１．クエリー情報のログレコードアドバイザクエリーログレコードがイネーブルであるとき、アドバイザは、予
め演算されたビュー３６のデータにアクセスするために書換えられる全クエリー
をログする。アドバイザはまた、クエリーを書換えるために使用される候補ビュ
ー４２がもしあれば、これををログする。データベース管理者はRBW_PRECOMPVIE
W_CANDIDATESテーブルにクエリーをすることによって候補ビューにアクセスでき
る。アドバイザはまた、アドバイザログファイルへ、相関のあるサブクエリーに
ついての情報をログする。相関のあるサブクエリーは同じクエリーを多数回異な
る値で行う。クエリーの中の他のテーブルに関係（主キー／外部キー関係を経由
して）していないサブクエリーまたはテーブルを含むクエリーは、もし適当な予
め演算されたビューが存在していたときはこれらクエリーが書換えられるとして
も、ログされない。

【００８４】図１０の、ひとつの実施の形態を参照すると、アドバイザは次のようにログレ
コードを生成する。アドバイザはユーザークエリー（工程１５０）の個々の集合
クエリーブロックを分析、解析する。集合クエリーブロックが、存在する予め演
算されたビュー（工程１５２）を使用するために書換え器によって書換えられた
場合、ログレコードが作り出される。もし書換えられたクエリーが付加的集合（
工程１５４）を含まなかった場合、ログレコードは、集合クエリーブロック（工
程１５６）を書換えるために使用された予め演算されたビューのＳＱＬテキスト
を含むように生成される。同じログレコードが、もし書換えられたクエリーが付
加的集合を含むが（工程１５４）、より良好な候補ビューがクエリー性能にさら
なる改善を勧めなかった（工程１５８）場合、生成される（工程１５６）；もし
良好な候補が推薦されれば（工程１５８）ログレコードは候補ビューのＳＱＬテ
キストを含むように生成される（工程１６０；部分一致候補ビュー生成）。もし
Rewiterが集合クエリーブロックを書換えずに（工程１５２）候補ビューが推薦されれば（工程１６２）、ログレコードは候補ビューのＳＱＬテキストを含むよ
うに生成される（工程１６０；一致なしの候補ビュー生成）。もしRewiterが集合クエリーブロックを書換えず（工程１５２）さらに候補ビューが推薦されなか
った場合（工程１６２）、ログレコードはされない（工程１６４）。

【００８５】次の情報はログファイルに格納される：タイムスタンプ；データベース名；詳
細テーブル識別子；クエリーに回答するために使用するビューの識別子（さもな
ければ NULL ）；ロールアップ情報；クエリーのためのまたクエリー内部の個々
の集合ブロックのための経過時間；この集合ブロックのためのＳＱＬテキスト。

【００８６】２．候補ビューの生成候補ビュー生成プロセスは、集合クエリーブロックの解析を含み、それは、も
し予め演算されたビューが作り出されれば、予め演算されたビューが集合クエリ
ーを書換えるために使用されるべきであると示唆されるかどうかを、判定するた
めのものである。このプロセスの最終結果は、予め演算されたビュー定義の選択
部分を定義するＳＱＬテキストである。この定義を使用して作り出された予め演
算されたビュー（組み合わされた集合テーブルと共に）は、クエリーブロックを
実行するときに使用されることが保証される（より良好な予め演算されたビュー
が無く、すべての必要なビューの正当性とクエリー書換えセットテーブルがイネ
ーブルであるとして）。

【００８７】図１１を参照すると、クエリーブロックＢ、それが組み合わされたクエリーＱ
、および階層グラフＦＧが示されているが、書換え器が集合クエリーブロックを書換えず、候補ビューが推奨されなかった場合には（一致しない候補ビュー生
成）、候補ビュー定義Ｖは次のように生成されよう。

【００８８】最初に、アドバイザが、正規の予め演算されたビュー定義を生成することが可能かどうかを判定する（工程１９０）。 ”正規の”予め演算されたビューの定義は、システムによって支援される予め演算されたビューのクラスに依存し、
この定義は支援される予め演算されたビューのクラスにおける変更に適合するよ
うに修正される。加えて、アドバイザはクエリーブロックが生成される予め演算されたブロックを使用するために書換えられるかどうかを判定する。ひとつの
実施の形態では、ビュー定義は次の条件のいずれかが真であれば作り出される：（i）BのFROM節はサブクエリーあるいは同じテーブルの多数発生を含む；（ii）BのFROM節は予め演算されたのビューテーブルかシステムテーブルを含む；（iii）ブロックBは行ポインタ、segids、あるいはサブクエリーのどれかの列
を参照する；（ix）Qのどのブロックも外部結合、リセットバイ、ブレークバイを持つか、あるいは予め演算されたビューを参照するとき；（v）Bのプロジェクトリストがある特徴を持っているとき（その特徴はGROUP
BYによって変換されない）。

【００８９】（vi）Bの外部キー／主キー述語がサブクエリーを参照する；（vii）雪片スタイルのグラフはBのためには構築されない。この条件をチェッ
クするために、外部キー／主キーの述語と、FROM節にあるテーブルを使用して、
結合グラフを構築する。ふたつのテーブルAとBの間の外部キー／主キーの述語は
、参照しているテーブル（述語に外部キーを含むテーブル）から参照したテーブ
ル（主キーを含むテーブル）まで、エッジスターティングとして表される。結合
の中心を見つける（すなわち収入エッジが無いノード）；これは候補ファクトテ
ーブル（F）である。残りのノードが候補ファクトテーブルから到達可能であるかどうか、ノードがひとつ以上の収入エッジをもたないかどうかを判定する。結
合グラフ（JG）、ファクトテーブル（F）、および外部キー／主キー述語（P1）があとで使うために格納され（viii）クエリーの集合表現は、予め演算されたビューの定義において許容で
きる集合のクラスに入る；（ix）このブロックへ関係するサブクエリーに集合がある；（x）BのGROUP BYリストは予め演算されたビューの定義の許容できるGROUP BY
節を構成しない；（xi）グルーピングリストＧ（Bのオリジナルグルーピングリストと異なることもある）が次のように構築されることはできない。G1を次から成るリストとし
て定義する：Bのテーブルを参照するすべての列は非外部キー／主キー述語に現れ、SELECTリスト、およびBのグルーピングリスト、は集合表現の内部の列参照を無視する。G1の ”グラフ互換”バージョンであるリストGを構築する（下の工
程２０６および２０８を参照）。もしそのようなGが構築できるなら、それを今後使用するために格納する。

【００９０】第２に、アドバイザはビュー定義Vを次のように生成する（プロセス１９２）。すべてのテーブルをVのFROM節にあるBのFROM節に置く（工程１９４）。WHERE 節に全ての外部キー／主キー述語（P1）を置く（工程１９６）。SELECTリストに
BとGの集合表現の全てを置く（工程２００）。SELECT表現を生成するためにこれ
らの構成要素の全てを組み合わせる（工程２０２）。アドバイザは次のようにG1
からグラフ互換リストGを構築する（プロセス２０４）。Bの全てのグルーピング
列をGに入れる（工程２０６）。また、集合表現内部の列参照を無視して、非結合述語とBのSELECTリストにある全ての列参照をGに入れる（工程２０７）。Gに列を持つテーブルのリストＴを構築する（工程２０８）。Gに列を持つ個々のテーブルのために（繰り返し工程２０９，２１０，２１１）、そのテーブルの主キ
ーがGにあるかどうかを判定する（工程２１２）。もしそうならそのテーブルの全ての他の列をGから外す（工程２１４）；そうでなければ列のどれかひとつが非階層エレメントであるかどうかを決める（工程２１６）。もしそうならそのテ
ーブルの全ての列を外し、そのテーブルの主キーでそれらを置き換える（工程２
１８）。最後に、階層グラフFGに含まれる情報をベースとしたGに残っている列の幾つかのサブセットに機能的に依存しているGに個々の列を移動する。

【００９１】図１２を参照すると、クエリーブロックＢ、それが組み合わされたクエリーＱ
、および階層グラフFGが示されているが、付加集合とより良い候補を含んだ書換
えクエリーが推奨される場合は、候補ビュー定義Vは次のように生成される。

【００９２】第一に、ADVISORは正規の予め演算されたビュー定義を生成することが可能かどうかを決める（工程２３０）。 ”正規の”予め演算されたビューの定義は、システムによって支援される予め演算されたビューのクラスに依存し、この定義
は支援される予め演算されたビューのクラスにおける変更に適合するように修正
されうる。加えて、アドバイザはクエリーブロックが生成される予め演算されたブロックを使用するために書換えられるかどうかを判定する。ある実施の形態
では、ビュー定義は次の条件のいずれかが真ならば作り出される：（i）BのFROM節はいかなる予め演算されたビューをも含まない；（ii）Bはrowids、segids、あるいはsegnamesを参照する；（iii）Bは集合表現を持つひとつ以上の予め演算されたビューを有する；（iv）Bはひとつ以上の予め演算されたビューを持ち、そのいずれも集合表現を持たない；（v）Bは、FROM節にひとつ以上のテーブルを持つサブクエリーを有するか、あ
るいは予め演算されたビューを参照するサブクエリーを有するか、あるいは集合
表現を持つサブクエリーを有するか、あるいはそのSELECTリストが単純な列参照
ではない表現を持つサブクエリーを有する。

【００９３】（vi）リバースエンジニアB1のための候補ビュー（B、予め演算されたビュー定義、およびBのFROM節にあるサブクエリーを構成することによって作られる）は、非一致候補ビュー生成に関連して、上述の候補ビュー生成プロセスを使用し
て作られることはできない（工程１９２）。

【００９４】もし非一致候補ビュー生成テストが、上の工程（vi）で生成されたリバースエ
ンジニアクエリーB1をパスするならば、アドバイザはB1から非一致候補ビューを生成する（工程２３２）。

【００９５】３．統計報告書の生成ａ．概観上記のように、データベース管理者は、同じクエリーに答える他のビューに関
連する個々のビューの利用状況を理解し、個々のビューのコストと利益の感覚を
磨くためにアドバイザを使用できる。データベース管理者は、アドバイザを集合
クエリーの性能を改善する方法を決めるために使用することもできる；特に、ア
ドバイザはどのビューを生成するべきか、いくつのビューを作るべきかというこ
とをデータベース管理者に推奨できる。解析の範囲は一日単位に、また特定の詳
細なテーブルに絞ることができる。アドバイザは与えられた日付の範囲内で特別
に詳細なテーブルを参照するクエリーのためのログファイルを隅から隅まで調べ
る。もしデータベース管理者が一日の範囲を特定しないならば、アドバイザは特
定の詳細テーブルを参照するクエリーのために存在するアドバイザログファイル
全てを隅から隅まで調べる。特別に詳細なテーブルに関連した個々のビューのた
めに、報告書は、ビュー名、利用数（ビューがクエリーに答えるために使用され
る総回数）、ロールアップカウント数（（階層関係を答えるために使用されたビ
ューの総回数）、およびビューのサイズを含む。アドバイザはまた、特別に詳細
なテーブルに関連した全ての具体化ビューと候補ビューのために、ログファイル
を走査することによって、あるいはRBW_VIEWSシステムテーブルにクエリーすることによって、ビューのユニークリストを生成する。アドバイザは、解析スペー
スを定義するために、また従属グラフを生成するために、このリストを使用する
。その後それは、同じクエリーに答える他のビューに関して、グラフにおけるあ
る予め演算されたビューの利益を計算するためにコストの公式に適用される。

【００９６】 RBW_PRECOMPVIEW_CANDIDATESテーブルは、あるクエリーの性能を改善する新規
予め演算されたビューを生成する利益を解析するために使用される情報を含む。
この情報はまた、どの予め演算されたされたビューを生成すべきであるかを判定
する際に、データベース管理者によって利用される。RBW_PRECOMPVIEW_CANDIDAT
ESテーブルは、ログされるクエリーに基づく個々の可能性のある候補ビューのた
めの一行と、個々の存在するビューのための一行を含む。 RBW_PRECOMPVIEW_CANDIDATESテーブルは次の列を含む：

【００９７】

【表１】 SAMPLE_VIEW_NAME列は、データベース管理者がアドバイザのクエリーの性能を
改善するために小さなデータセットの上でアドバイザ解析を実行することを可能とする。SAMPLE_VIEW_NAME列上に制限されたとき、アドバイザのクエリーの範囲は列に参照されたビューの名前に制限される。データベース管理者は、デー
タベースにあるデータの代表的サンプルを含むところのサンプルビューを作るべ
きであり、そのサンプルビューは次のような特徴を持っている：詳細テーブルの
行のサブセットへ写像する；詳細テーブルの個々の列に一致する列を有する；お
よびサンプルビューの列のデータ形式は、詳細テーブルのデータ形式に正確に一
致する。

【００９８】 RBW_PRECOMPVIEW_CANDIDATESテーブルは、あるクエリーの性能を助けるために
新しいビューを作り出しながら、データベース管理者を案内するために使用され
る。

【００９９】例えば、データベースが集合テーブルを含まないと仮定し、データベース管理
者は、何が最も利益に結びつく集合ビューであるか、Sales tableに生成すべき集合ビューはどれか、を知りたがっていると仮定しよう： Select reference_count,benefit,text,seq From rbw_precompview_candidates Where detail_table_name='SALES'; 上の解析の範囲はさらに一日の範囲に絞られる： Select reference_count,benefit,text,seq From rbw_precompview_candidates Where detail_table_name='SALES' and start_date=('1996-01-01' ) and end_date=('1996-03-30'); RBW_PRECOMPVIEW_UTILIZATIONテーブルは、特定の詳細テーブルのために作り出された予め演算されたのビューの値を解析するデータベース管理者によって使
用される情報を含む。それはまた、特定のビューの利用に対する洞察と、同じク
エリーに答える他のビューに関するビューのコストと利益を提供する。RBW_PREC
OMPVIEW_UTILIZATIONテーブルは、データベースで定義された全ての正当な予め演算されたビュー用の一行を持ち、そのビューはデータベース管理者によって正
当な状態にセットされるビューを含んでいる。 RBW_PRECOMPVIEW_UTILIZATIONテーブルは、次の列を含んでいる。

【０１００】

【表２】

【０１０１】 NON_EXACT_MATCH_COUNT列は、幾つかの付加的集合が必要とされたクエリーへの回答を数えるために、何回データベースにあるビューが使用されたを同定する
。この列のカウントが高ければ、他の予め演算されたビューがクエリー性能を改
善できるであろうことを示唆する。正確な一致は、予め演算されたビューに付加
的集合を実行することなしに、クエリーが予め演算されたビューによって回答さ
れるときに起きる。そのクエリーに対する幾つかの予想があり得るし（例えば、
Where節かHaving節）、また幾つかのフォーマッティングがあり得るが（例えば、Order By節）、特別な集合はない（例えば、Group By、Sum、Min、またはMax ）。例えば、日数の粗さを持った詳細テーブル、月数の粗さを持ったそのテーブ
ル上で定義された予め演算されたビュー、およびいずれもドルの総計を含む詳細
テーブルと予め演算されたビューを考慮する。一年間で何ドルが生み出されたか
に関するクエリーは月次テーブルによって回答されるが、直接回答されることは
ない--更なる集合がクエリーに回答するために計算されなければならない。

【０１０２】一年間のドル総計についてクエリーに回答するために予め演算されたビューが
アクセスされるたびに、NON_EXACT_MATCH_COUNT列は１だけ増分される。もしクエリーへの回答が、予め演算されたビューにあるものと正確には一致しないとき
は、付加的集合が実行されるときや他のテーブルへの結合が起きるときも含むが
、その列は増分される。

【０１０３】 RBW_PRECOMPVIEW_UTILIZATIONテーブルは、ある特定のベーステーブルのために具体化されたビューのためのビュー利用情報を記述する。例えば、データベー
ス管理者はUtilizationテーブルに、Salesテーブル上に存在するビューがいかに
うまく利用されているかを見るためにクエリーすることができる： select name, reference_count, rollup_count From rbw_precompview_utilization Where detail_table_name='SALES'; 上記の解析の範囲は、さらに日の範囲に絞ることができる： select name, reference_count, rollup_count From rbw_precompview_utilization Where detail_table_name='SALES'; start_date=date('1996-01 -01') and end-date=date('1996-03-30'); [start_date, end_date]列に制限が無い場合、解析の範囲は全ての存在するア
ドバイザ Logファイルになろう。他の実施例として、データベース管理者は、セ
ールスに存在するビューのためのビュー利用状況、ビュー利益、およびビューサ
イズを知るためにクエリーを出すことができる： select name, reference_count, benefit, size From rbw_precompview_utilization Where detail_table_name='SALES';

【０１０４】ｂ．解析スペース定義図１３を参照すると、ひとつの実施の形態において、アドバイザは次のように
解析スペースを定義する。スタートすると、アドバイザはHash-Directory を生成する（工程１７０）。アドバイザは既存の予め演算されたビューを持ってHash
-Directory に在住する（工程１７２）。アドバイザは、特定の日の範囲内の日付を持つ、ログ６４に格納されているログクエリーの全てを同定する。アドバイ
ザは、特定の詳細テーブルを参照するクエリーのために同定されたクエリーを抽
出する（工程１７６）。個々の特定の詳細テーブルを参照するクエリーのために
アドバイザは、グルーピング列への参照を含むクエリー構造を生成する（工程１
７８）。

【０１０５】アドバイザはクエリーをグルーピング列によって分類して、各クエリーがその
グルーピング列上に置かれた適切なスロットに細分化されるようにする（工程１
８０）。不一致があるとき、そのグルーピング列が他と異なる場合には、アドバ
イザは Hash-Directory にその要素を加え；他方、もしその集合表現が異なる場
合には、アドバイザは集合表現のリストに集合表現を加える。個々の候補ビュー
については、アドバイザは集合経過時間のトラックと、ビューへの参照回数をキ
ープする。この点でアドバイザは Hash-Directory にある各要素のためにＳＱＬ
テキストを生成する（工程１８２）。

【０１０６】ｃ．解析スペース上に構造をインポーズする図１３を参照して、ビュー定義が Hash-Directory の各要素のために生成され
たあと、アドバイザは書換え器の能力上に築かれた従属グラフを構築する（工程
２４０）。グラフの２つの要素は、もしひとつの要素のビュー定義が２番目の要
素のビュー定義の見地から書換えられるならば、指示されたエッジによって関連
付けられる。グラフは候補ビューのひとつ以上のペアレントノードを生成するこ
とによって完成される。ペアレントノードはそのチャイルドノードに比較してよ
り細かい粗さのノードである。グラフを引き伸ばすためにひとつのパスが、２つ
以上のノードを組み合わせることによってペアレントノードを生成するために、
リーフノードからルートノードへと作られる。ペアレントノードは、組み合わさ
れたグルーピング列を含む。リーフノードを除いた個々のレベルで、２つ以上の
チルドレンの組み合わせを通じて生成されたノードがあり、ログファイルの処理
から作られるアクチャルノードがある。ひとつの実施の形態では、もし、ノード
のひとつがアクチャルノードであったなら、その場合に限り、すなわちこれはグ
ラフにおけるノード数を最小化するので、ふたつのノードがペアレントを作るた
めに組み合わされる。グラフのルートノードはデータの最も少ない粗さを表す（
すなわち、ファクトテーブル）。

【０１０７】ｄ．コスト対利益解析の実行従属グラフが生成された後、アドバイザは、同一のクエリーに答えるために使
用された他のビューと比較したときの個々のビューの利益を判定するために、従
属グラフへコストの公式を適用する（工程２４２；図１３）。コストモデルは、
各ビューと関連づけられたスペースコスト（すなわち、行数）を持つ指示された
グラフを、入力として仮定している。ここで使用されたように、グラフの２つの
要素（ビュー）の間の従属関係は≦で記号付けがされている。グラフの要素ａ，
ｂに関しては、ａ≦ｂのときのみ、ｂはａのアンセスタである。もしC(v)がビュ
ーvのコストであるとすると、従属グラフのノードのセットSに関するビューvの利益、B(v,S)、は次のように定義される：

【０１０８】

【式１】ここで、各々についてw≦u、ビューuについてもしC(v)＜C(u)ならばBw＝C(v)-
C(u)、これはw≦uのようなSにおける最小コストであり；一方、B_w＝０である。このようにvの利益は、それ自身を含む、ビューを評価するコストをいかに改善できるかを考えることによって計算される。vがカバーする各ビューwに代わって
、vを使ってwを評価するコストは、wを評価するための最も安い方法をオファーされたSからのどのビューでも構わないが、それを使ったコストと比較される。もしvのコストがコンペティタのコストよりも少なければ、その差は、実現されたビューとしてvを選択する利益の一部分を表わす。総利益B(v,S)はビューw全体
に渡っての合計であり、wを評価するためにvを使用する利点がある。

【０１０９】利益計算に使用されるべきである従属グラフノードのセットSは、次の方法を使用して生成される。

【０１１０】 S=[root fact table node] for(i=0;i<number of nodes in dependency graph;i+ +)[ select a view "v" in graph such that V is not in S and such that B(v,S) is maximized; S=S union [node representing "v"] ] グラフにおけるビューが、クエリーで要求される確率と同じ確率を持つという
見込みはない。ビューがクエリーされる頻度を表す確率は、それゆえに各ビュー
と関連している。ビューvの確率は、グラフにおける全てのビューへの参照の全回数を越える、vへの参照の全回数である。処理された行数の見地から測定されるべきビューvの利益をノーマライズするために、確率Pr_vはvへの全参照回数として再定義される（グラフにおける全てのビューへの全参照回数を越えるvへの全参照回数とは対照的に）。この公式のもとで、ビューのセットＳと関連するビ
ューvの利益B(v,S)は次式で与えられる：

【０１１１】

【式２】予め演算されたビューのサイズはすでにビューにおける行数から判定されてい
る。候補ビューのサイズは未知であるからアドバイザはこれらのビューのサイズ
を評価しなければならない。ある実施の形態では、アドバイザは、統計モデルの
上にコストモデル−詳細データの小さなサブセットであるが−を走らせることに
よって、候補ビューのサイズを評価する。データベース管理者は詳細データ（ビ
ューとして）のサブセットを定義でき、その上にコストモデルが走る。この方法では、実際にビューを具体化することによって、候補ビューのサイズが評価さ
れる。データベース管理者はまたアドバイザに、ビューによってそのテーブル上
に表される詳細テーブルのサンプルを与える。

【０１１２】他の実施の形態では、サンプリングと解析的方法が、グラフにおける最大要素
の具体化から、異なるビューのサイズを計算するために使用される（すなわち各
次元での最大属性によってグループ化するビュー）。第３の実施の形態では、ア
ドバイザは、クエリー実行時間におけるポテンシャルビューサイズをダイナミックに計算する。他の実施の形態では、データベース管理者はアドバイザに、次
元の各属性のためのある数の確定値と、全ての可能で興味ある相関値を与える；
この情報からアドバイザはグラフにおける各ビューのサイズを評価する。

【０１１３】コストの公式が従属グラフへ適用されたあと、アドバイザは、データベース管理者によってクエリーされるかもしれない統計報告書を生成する（工程２４４
）。

【０１１４】４．アドバイザシステムテーブルのクエリー結果翻訳予め演算されたビューを生成するときに、コストと利益がトレードオフの関係
になることが常である。コストはディスクスペース、生成時間、ロード時間、管
理時間である。利益はより良いクエリー性能である。ユーザーは常により早い性
能を好む。データベース管理者はこのトレードオフを評価すべきであり、どの予
め演算されたビューが生成されるべきでどれが消去されるべきであるかを判定し
なければならない。アドバイザシステムテーブル上でのクエリーは、データベー
ス管理者がこれらの判定をするときに役に立つ。

【０１１５】 RBW_PRECOMPVIEW_UTILIZATIONとRBW_PRECOMPVIEW_CANDIDATESテーブルのBENEF
IT列は、与えられたアドバイザ runのビューのために相対的な利益の測定を提供する。BENEFIT列の数は、対応する予め演算されたビューで処理される必要の無い、行数の測定である。

【０１１６】 RBW_PRECOMPVIEW_UTILIZATIONとRBW_PRECOMPVIEW_CANDIDATESテーブルのSIZE 列は、予め演算されたビューあるいは候補ビューにおける行数を特定することで
ある。一般に小さな行数を持ったビューは、より大きな行数を持つビューほどに
は高くつかない。REDUCTION_FACTOR列は詳細テーブルに関するビューサイズの比
を与える。ビューのサイズとリダクションファクタの両者は、特別なビューのコ
ストと利益を評価するときに考慮されるべきである。

【０１１７】 REFERENCE_COUNT列は予め演算されたビューが何回使用されたか（RBW_PRECOMP
VIEW_UTILIZATIONテーブル）あるいは使用されていたであろうか（RBW_PRECOMPV
IEW_CANDIDATESテーブル）を特定する。一般にもしこの数字が小さければ、関係
するビューはデータベースとして特に有益とは言えない。

【０１１８】つまり、それ自身によるいかなる特定の列における良い数字も、一般にビュー
を生成する、あるいは消去する理由を強いることにはならない。代わりにビュー
に関連する全ての数字は、そのビューの数字を評価するときに、ともに考慮され
るべきである。加えて特殊なビューのための結果は、与えられた詳細テーブルの
ための全てのビューの前後関係において考慮されるべきである。

【０１１９】他の実施の形態は請求の範囲内にある。例えば上記実施の形態の多くは集合ク
エリーと予め演算された集合クエリーの前後関係において説明された。本発明は
他の実行に同様に適用する。このように集合を含まない予め演算されたビューは
、予め演算されたビュー処理システム２０によって定義され生成されることがで
き、また書換え器とアドバイザによって使用されることができる。

【０１２０】他の実施の形態では、データベース管理者は、ある回数以上参照されたビュー
、または時間のしきい値を越える集合実行時間（すなわち各クエリーの集合ブロ
ックのビュー参照経過時間の合計）を持ったビューへのアドバイザの問い合わせ
を制限することができる。その代わりに従属グラフはノードの最小数（しかし許
容できる）へ制限することができる。

【０１２１】更なる他の実施の形態は請求の範囲内にある。

【図面の簡単な説明】

【図１Ａ】製品テーブル、売上テーブル、時間テーブル、および予め演算されたテーブル
の図式である。

【図１Ｂ】製品テーブル、売上テーブル、時間テーブル、および予め演算されたテーブル
の図式である。

【図１Ｃ】製品テーブル、売上テーブル、時間テーブル、および予め演算されたテーブル
の図式である。

【図１Ｄ】製品テーブル、売上テーブル、時間テーブル、および予め演算されたテーブル
の図式である。

【図２】ファクトテーブルとその関連する次元との図式である。

【図３】ネットワーク上でデータベースサーバへ連結されたクライアントの図式である
。

【図４】ビュー、テーブル、および階層間の関係の図式である。

【図５Ａ】集合体の店＿売上テーブルを含む、小売スキーマの図式である。

【図５Ｂ】売上テーブルとその関連する次元の図式である。

【図６】集合体テーブルと、関連する予め演算されたビューとを創成する方法の図式で
ある。

【図７Ａ】予め演算されたビューを管理する方法のフロー図である。

【図７Ｂ】データベースサーバの構成要素の図式である。

【図８】集合体テーブルと、その関連する次元との間の外部キー／主キーの関係の図式
である。

【図９】クエリー情報にログし、ログ、階層、および候補と予め演算されたビューとに
関する情報に含まれた情報を含む、メタデータに基づき、候補ビューと要約の統
計とを生成するよう構成されたアドバイザの図式である。

【図１０】少なくとも一部分はユーザ集合体クエリーブロックに基づき、ログレコードを
生成する方法である。

【図１１】少なくとも一部分はユーザークエリー履歴に基づき、候補ビューと統計レポー
トとを生成する方法のフロー図である。

【図１２】少なくとも一部分はユーザークエリー履歴に基づき、候補ビューと統計レポー
トとを生成する方法のフロー図である。

【図１３】少なくとも一部分はユーザークエリー履歴に基づき、候補ビューと統計レポー
トとを生成する方法のフロー図である。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号６０／０７９，６７０ (32)優先日平成10年３月27日(1998．3．27) (33)優先権主張国米国（ＵＳ） (31)優先権主張番号０９／０４９，７８４ (32)優先日平成10年３月27日(1998．3．27) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＢＲ，ＣＡ，ＪＰ，ＭＸ (72)発明者コール，リチャード，エル．アメリカ合衆国，カリフォルニア州，ロスガトス，ジョンソンアヴェニュー 300 (72)発明者ハスラム，エドワード，ピー．アメリカ合衆国，カリフォルニア州，サンフランシスコ， 22エヌディストリート 3738 (72)発明者ジャザイェリ，ナシアメリカ合衆国，カリフォルニア州，サンタクララ，サラトガアヴェニュー 141 ナンバー123ビー (72)発明者ジョンソン，ギャルトアメリカ合衆国，カリフォルニア州，キャンベル，レイルウェイアヴェニュー 500 ナンバー102 (72)発明者マッケーナ，ウィリアム，ジェイ．アメリカ合衆国，カリフォルニア州，サンタクルーズ，エルムストリート 211 (72)発明者ウィルハイト，デイヴィッド，ジー．ジュニアアメリカ合衆国，カリフォルニア州，サンタクララ，ヴィスタクラブサークル 1543 ナンバー303 Ｆターム(参考） 5B075 ND04 ND34 PP12 PP26 PQ02 QT06 UU06 【要約の続き】

Claims

【特許請求の範囲】

【請求項１】データベースについてのユーザークエリーに返答するために
予め演算されたビューを処理する方法であって、予演算ストラトジの有効性についてのユーザデータベースクエリーに応答して
、ユーザーデータベースクエリー履歴に基づき、前記データベースに対する全て
の可能なビューのサブセットから構成される分析スペースを定義する工程と、前記分析スペースにおける前記ビューを特徴付ける工程とを含む方法。
【請求項２】データベースについてのユーザークエリーに返答するために
予め演算されたビューを処理する方法であって、前記データベースについてのユーザークエリーを分析する工程と、前記ユーザークエリーに基づき候補ビューを生成する工程とを含む方法。
【請求項３】データベースについてのユーザークエリーに返答するために
予め演算されたビューを処理する方法であって、前記データベースに対する全ての可能なビューから成るひとつのサブセットで
構成される分析スペースを定義する工程と、前記データベースに含まれる前記データから成るひとつのユーザ定義サブセッ
トに基づき、前記分析スペースへコスト公式を適用する工程とを含む方法。
【請求項４】データベースについてのユーザークエリーに返答するために
予め演算されたビューを処理する方法であって、２つ以上の成分ビューの組合せで構成される候補ビューを含む分析スペースを
定義する工程と、前記分析スペースにおけるビューを特徴付ける工程とを含む方法。
【請求項５】データベースについてのユーザークエリーに返答するために
予め演算されたビューを処理する方法であって、クエリー書換えファシリティの能力に基づき、前記データベースに対する全て
の可能なビューから成るひとつのサブセットで構成される分析スペース上にスト
ラクチャを賦課する工程と、前記分析スペースにおける前記ビューを特徴付ける工程とを含む方法。
【請求項６】更に、受取られたユーザークエリーに対するログ記録を生成
する工程を含む、請求項１、２、３、４または５に記載の方法。
【請求項７】ユーザークエリーに対するログ記録を生成する工程は、前記
クエリーが予め演算されたビューを使用するよう書換えられたか否かを判定する
工程を含む、請求項６に記載の方法。
【請求項８】ログ記録を生成する工程は、書換えられたユーザークエリー
が集合を含むか否かを判定する工程を含む、請求項６に記載の方法。
【請求項９】ログ記録を生成する工程は、ユーザークエリーを書換えるた
めに使用され得る候補ビューを識別する工程を含む、請求項６に記載の方法。
【請求項１０】クエリーに対して生成された前記ログ記録は、前記クエリ
ーを書換えるために使用される予め演算されたビューについての情報を含む、請
求項６に記載の方法。
【請求項１１】前記候補ビューは、ＳＱＬで生成される、請求項２に記載
の方法。
【請求項１２】前記候補ビューは、メタデータに基づき生成される、請求
項２に記載の方法。
【請求項１３】前記候補ビューは、前記データベースにおける関数的従属
性に基づき生成される、請求項１２に記載の方法。
【請求項１４】メタデータは、ユーザ規定の階層を含む、請求項１２に記
載の方法。
【請求項１５】前記候補ビューは、クエリー処理システムの能力に基づき
生成される、請求項２に記載の方法。
【請求項１６】前記分析スペースは、クエリー書換えファシリティの能力
に基づき定義される、請求項１、３または４に記載の方法。
【請求項１７】前記クエリー書換えファシリティは、前記分析スペース上
にストラクチャを賦課するよう構成される、請求項１６に記載の方法。
【請求項１８】前記賦課されたストラクチャは、前記分析スペースにおけ
るビュー間の階層関係を示すグラフを含む、請求項５または１７に記載の方法。
【請求項１９】前記分析スペースは、ビュー間の階層関係に基づき定義さ
れる、請求項１、３または４に記載の方法。
【請求項２０】前記定義された分析スペースは、ユーザークエリー履歴に
基づき生成される候補ビューを含む、請求項１、３または４に記載の方法。
【請求項２１】前記分析スペースにおける前記ビューを特徴付ける工程は
、予め演算されたビューの利用状況の測度を発生する工程を含む、請求項１、４
または５に記載の方法。
【請求項２２】前記分析スペースにおける前記ビューを特徴付ける工程は
、現行の予演算ストラトジの有効性を反映するレポートを生成する工程を含む、
請求項１、４または５に記載の方法。
【請求項２３】前記分析スペースにおける前記ビューを特徴付ける工程は
、創成され得る候補ビューについての情報を含むレポートを生成する工程を含む
、請求項１、４または５に記載の方法。
【請求項２４】前記分析スペースにおける前記ビューを特徴付ける工程
は、前記分析スペースにおける他のビューに対する候補ビューの利点の測度を発
生する工程を含む、請求項１、４または５に記載の方法。
【請求項２５】前記分析スペースにおける前記ビューを特徴付ける工程は
、前記分析スペースへコスト公式を適用する工程を含む、請求項１、４または５
に記載の方法。
【請求項２６】データベースについてのユーザークエリーに返答するため
に予め演算されたビューを処理するための装置であって、クエリープロセッサと、ユーザーデータベースクエリー履歴に基づき、前記データベースに対する全て
の可能なビューから成るひとつのサブセットから構成される分析スペースを定義
することによって、および、前記分析スペースにおける前記ビューを特徴付ける
ことによって、予演算ストラトジの有効性についてのユーザーデータベースクエ
リーに応答するよう構成されるアドバイザとを備える装置。
【請求項２７】データベースについてのユーザークエリーに返答するため
に予め演算されたビューを処理するための装置であって、クエリープロセッサと、前記データベースについてのユーザークエリーを分析し、前記ユーザークエリ
ーに基づき候補ビューを生成するよう構成される予め演算されたビュープロセッ
サとを備える装置。
【請求項２８】データベースについてのユーザークエリーに返答するため
に予め演算されたビューを処理するための装置であって、クエリープロセッサと、クエリー書換えファシリティの能力に基づき、前記データベースに対する全て
の可能なビューから成るひとつのサブセットからストラクチャされる分析スペー
ス上に構造を賦課し、前記分析スペースにおける前記ビューを特徴付けるよう構
成されるアドバイザとを備える装置。
【請求項２９】データベースについてのユーザークエリーに返答するため
に予め演算されたビューを処理するための装置であって、クエリープロセッサと、前記データベースに対する全ての可能なビューから成るひとつのサブセットか
ら構成される分析スペースを定義し、前記データベースに含まれる前記データの
ユーザ定義サブセットに基づき、前記分析スペースへコスト公式を適用するよう
構成されるアドバイザとを備える装置。
【請求項３０】サーバ上に格納されたデータベースについてのユーザーク
エリーに返答するためのシステムであって、前記サーバ内へ統合され、ユーザークエリーに応答するよう構成されるクエリ
ー処理システムと、前記サーバ内へ統合され、前記データベースについてのユーザークエリーの予
め演算された結果を処理するよう構成される、クエリー処理システムとを備えるシステム。
【請求項３１】前記クエリー処理システムは、予め演算されたビューを演
算するよう構成される、請求項３０に記載のシステム。
【請求項３２】前記クエリー処理システムは、前記データベースでの変更
を反映するために予め演算されたビューを更新するよう構成される、請求項３０
に記載のシステム。
【請求項３３】前記クエリー処理システムは、予め演算されたビューを管
理するよう構成される、請求項３０に記載のシステム。
【請求項３４】前記クエリー処理システムは、予め演算されたビューを使
用してユーザークエリーを書換えるよう構成される書換え器を含む、請求項３０
に記載のシステム。
【請求項３５】前記クエリー処理システムは、予め演算されたビューとユ
ーザークエリー履歴とに関する情報をユーザへ提供するよう構成される、請求項
３０に記載のシステム。
【請求項３６】前記クエリー処理システムは、予演算ストラトジの有効性
を分析するよう構成されるアドバイザを含む、請求項３０に記載のシステム。
【請求項３７】前記クエリー処理システムは、ユーザークエリー履歴に基
づき、前記データベースに対する全ての可能なビューのサブセットから構成され
る分析スペースを定義するよう構成される、請求項３０に記載のシステム。
【請求項３８】前記クエリー処理システムは、候補ビューを生成するよう
構成される、請求項３０に記載のシステム。
【請求項３９】前記クエリー処理システムは、データベースのメタデータ
を利用するよう構成される、請求項３０に記載のシステム。
【請求項４０】前記クエリー処理システムは、関数的従属性を利用するよ
う構成される、請求項３０に記載のシステム。